1. 개요
입사한지 드디어 3개월 차다. 9월 20일에 신입 사원 OJT (On the Job Training) 발표를 마쳤고, 첫 연휴를 맞이했다. 3개월 간의 생활을 뒤돌아보고, 내가 배운 것들과 아쉬운 것들, 그리고 앞으로 내가 가져야할 자세에 대해 짚어보려고 한다. 재직 중인 회사에 붙기 위해 어떤 준비를 했고, 일정은 어떻게 흘러 갔는지 등을 필두로 풀어보려고 한다.
2. 입사를 위해
2022년 회고록에는 전반적으로 취업을 준비하기 위해 했던 과정들이 적혀 있는데, 여기는 오토에버라는 회사에 오기 위해 했던 것들을 적어봤다. 모든 절차는 팀 바이 팀이므로, 팀 내 사정에 따라 상황이 모두 다를 수 있다. 코테 문제부터, 면접 참여 인원, 면접 난이도 모두 팀 바이 팀이다. 그러니 만일 회고록을 활용한다면 적절히 참고 정도 하길 바란다. 애초에 회사에서 민감하게 다루는 항목들은 기재하지 않았으며, 모두 공개되었던 자료들을 내가 했던 생각과 적절히 섞어서 기재한 것이다. 내가 어떤 것들을 했는지 돌아보기 위한 용도로 적은 것임을 타 독자들에게 당부한다.
1지망은 내가 지금까지 해오던 백엔드 직무를, 2지망은 C++ 위주의 업무인 내비 개발 직무를 지원했는데, 결과적으로 백엔드 직무로 2023년도 3분기 입사자가 되었다.
1) 채용 일정
2023년도 2분기 채용 공고는 다음과 같았다.
채용 공고 기간 : 2023-04-18 ~ 2023-05-02
코딩테스트 : 2023-05-13
온라인 인성 검사 : 2023-05-13
코딩테스트 합격 : 2023-05-26
온라인 1차 면접 : 2023-06-01
온라인 1차 면접 합격 : 2023-06-14
채용 검진 : 2023-06-19
온라인 2차 면접 : 2023-06-22
최종 합격 : 2023-06-29
입사일 : 2023-07-10
** 꽤 길었지만, 붙어서 다행이다.
2) 자소서
공고 기간에는 이력서를 제출하게 되는데, 이력서에는 자소서를 포함한 전공 수업 및 기술 스택도 함께 적게 된다. 내 경우엔 원래 성적이 좋은 편이라 전공 수업 중 백엔드와 관련된 “인터넷 프로토콜”, “데이터베이스”, “알고리즘”, “컴퓨터 구조”, “자료구조” 등 A+을 받은 수업들 위주로 기입했다. 기술 스택의 경우 실제 업무에 사용해봤던 기술들을 다 적어봤다. JD에 기입된 기술만 적어볼까 하다가, 일할 때 사용했던 기술들을 모두 적어두면 면접 때 재밌게 얘기할 수 있을 것이라고 생각했다.
** 주로 Java, Golang 위주의 프레임워크와 ORM, Container로 운영할 때의 OS와 협업을 위한 툴, API 스타일들을 위주로 적었으며, 대체로 이런 기술들은 창업을 시도했을 때와 외주에 사용되었던 기술들이었다.
자소서는 1) 현대오토에버의 해당 직무에 지원한 이유와 앞으로 현대오토에버에서 키워나갈 커리어 계획, 2) 지원 직무와 관련하여 어떠한 역량을 갖고 있는지와 그 역량을 갖추기 위해 수행한 구체적인 노력과 경험, 이렇게 2개의 항목으로 이뤄져 있었다.
1번의 경우, 오토에버라는 회사를 알게된 경위 → 내가 갖고 있는 역량 → 회사의 현 상황과 내 역량의 일치로 기대할 수 있는 것 → 업무에서 해보고 싶은 것의 순서로 기재했다. JD를 보면 MSA라는 키워드가 많았다. 나는 업무로 Monolithic 형태로 밖에 해보지 않았기에 k8s 위주의 업무에 관심이 많았고, MSA에서 Kafka 와 같은 대용량 이벤트 스트림을 해보고 싶었다. 따라서 이와 같은 부분들 녹여냈다.
2번의 경우, Diary 상에 기재한 여러 항목들을 압축해서 작성했다. 예를 들면, Cubrid 오픈 소스 기여, 헬스토피아, 42서울의 간단한 소개와 활동 내역들을 내 역할을 기반으로 작성했다.
3) 코딩테스트
코딩테스트 유형을 알아보기 위해 여러 블로그 글들을 찾아봤는데, 난이도 편차도 컸고, 문제 유형도 시기마다 다 달랐던 것 같다. 그리고 실제로 코딩테스트를 응시해봤던 입장으로는 이전 글들이 딱히 도움이 되지는 않았다.
내 경우엔 가장 어려운 문제가 아무리 잘 쳐줘도 실버2 정도 되는 수준이었다. 문제 유형은 대체로 그리디 위주였는데, 난이도와 유형 모두 내가 블로그에서 찾아봤던 것과는 거리가 있었다.
그래프, 자료구조, 구현 위주로 준비했기에, 그리디 문제를 많이 풀지는 못 했지만 크게 무리가 있는 난이도는 아니었던 것으로 기억한다. 개인적인 견해로는 대체로 IT 서비스 회사를 준비하던 입장이라면 못 풀면 안 되는 문제들이었다고 생각했고, 올솔했다. 어느 회사든 코딩테스트를 보게 되면 항상 복기 후에 리뷰를 했었는데, 마찬가지로 복기했었고 꽤나 중요하게 작용하는 듯 했다.
4) 면접
다른 블로그 글들을 보면 전공 지식 질문을 한다든가, 코테 리뷰를 한다든가 후기가 많은데, 내 경우엔 내 경험을 질문 받는데 대체로 1, 2차 모두 면접 시간을 소모했다.
아무래도 특이한 이력들이 많아서 그러지 않을까 싶다. 예를 들면, 고등학교 자퇴, 2회 창업 시도, 서비스 백엔드 개발 리드 포지션 및 운영 경험, 수익 창출로 시작해서 여기에 달릴 꼬리 질문을 생각하면 다른 잡다한 질문이 끼어들 여지는 크게 없었다.
나도 예상한대로 면접 자체는 순도 높은 형태였다고 생각했고, 다른 면접관 분들과의 경험도 좋았지만 특히 팀장님과의 면접 경험이 너무나도 나이스했다. 도움이 됐던 부분은 개발과 기술을 바라보는 주관, 그리고 개발자로서 가져야할 태도에 대한 견해였고, 이러한 것들을 평소에 꾸준히 생각해왔던 것이 잘 전달된 것 같았다.
5) 소감
이전 2022년 회고록을 보면 알다시피 최선책으로는 싸피 + 현차를 노리던 입장이었으나, 싸피 일정이 틀어진 부분 때문에 커리어 계획에 약간의 차질이 생겼다. 다른 IT 서비스 회사에서 탈락하고, 엔픽셀과 오토에버만 남은 입장에서 솔직하게 오토에버가 훨씬 좋은 선택지였기에 굉장히 절실해졌다.
본의 아니게 채용 검진 비장하게 받으러 갔고, 2차 면접 준비에 보다 공을 들였던 기억이 난다. 그리고 면접에서는 생각보다 팀장님의 태도와 가치관이 건강하다고 느꼈고, 다른 기업들에 비해 면접 경험이 가장 좋았다고 생각해서 막바지라도 절실하게 마음 먹게 된 것에 감사하게 되었던 것 같다.
특히 싸피를 붙었다고 해도 현차에 원하는 공고가 떠야 했었는데, 9월이 되어보니 현차에는 내가 원하는 공고가 올라오지 않았기에 오토에버에 올 수 있음에 굉장히 감사하게 되었다. 만일 싸피를 택했다면 내년 상반기 IT 서비스 기업 공채가 올라오기 전까지 또 교육만 받는 입장이었텐데, 다시 생각해봐도 아찔하다.
좋은 팀에 좋은 동료들과 이전보다 훨씬 좋은 대우 받으면서 일할 수 있게 해준 오토에버라는 회사에 늘 감사하게 생각한다. 그렇기에 여력이 되는 데까지 내가 할 수 있는 것들을 펼쳐보려고 한다. 스타트업에서의 마인드를 그대로 추구할 수는 없겠지만, 업무 환경에 적절하게 녹여서 여전히 사냥개 포지션을 추구해볼 생각이다. 특히 큰 기업이더라도 주눅들지 말고 목소리 내라고 해주셨던 조문옥 CTO님의 당부처럼, 해야할 얘기라고 판단이 된다면 받아들여지든 아니든 내 목소리를 내서 더 나은 결과를 낼 수 있게 해보려고 한다.
처한 환경이 달라졌으니 분명이 접하게 되는 기술과 그 맥락도 다를 텐데, 이 기회를 살려 그만큼 더 성장할 수 있었으면 한다. 스스로도 그런 성장을 얻을 기회를 마주하기 위해 노력해야겠다고 느꼈다.
3. OJT
1) 개요
입사 직후에 겪은 서비스 장애 덕분에 일반 운영 업무 외에도, 모니터링, 성능 측정, 장애 분석 등을 파악한다고 업무 선임들과 멘토 (PM)님과 굉장히 바쁜 시간을 보냈던 것 같다.
그런 와중에도 업무 선입과 멘토님들 간의 협의에서 내가 수행해야할 OJT 프로젝트를 결정해주시긴 했지만, 생각보다 빨리 끝난 탓에 내가 만든 것을 고도화할지 다른 부족한 것을 채울지 고민을 했었다. 업무적인 지식이 받쳐줘야 조금 더 고도화가 가능하겠다 싶었는데, 이러한 도움을 구할 수 있는 선임분들은 다들 장애 대응에 바빠서 고도화는 사용성이 갖춰졌을 때 노리는 것으로 가능성만 열어뒀다. 그래서 붕 뜨는 시간을 채우기 위해 OJT 기간에 추가적으로 해보면 좋은 프로젝트를 찾아나섰다.
다른 동기들처럼 업무를 위해 코드를 파악하고 주석을 달고 있는 것도 좋은 선택지 중에 하나였지만, 서비스 아키텍쳐라는 큰 그림은 이미 이해를 했고 세세한 코드의 동작이 어렵게 명시되어 있던 것이 아니기 때문에 충분히 코드를 칠 때 봐도 늦지 않겠다는 각이 섰다. 그렇기에 팀 내에 없는 것을 찾아보려고 했다. 외주 프로젝트를 할 때나 새롭게 프로젝트를 열어보려고 할 때마다 반복되는 셋업 코드를 치는 것이 번거로웠던 기억이 나는데, 이 때 보일러 플레이트를 만들어서 해결했던 것이 생각났다.
팀 내에 보일러 플레이트 코드가 있냐고 물어봤지만, 그렇지 않다는 답변을 받았다. 그리고 어떤 코드 컨벤션이나 아키텍쳐 템플릿이 있는지도 물어봤지만, 그렇지 않다고 했다. 해볼만한 것이 생겼고, 업무 선임과 멘토님과 협의해보면서 이를 OJT로 해보는 것으로 결정했다.
OJT로는 Blocking으로 사용되는 Monolithic 아키텍쳐에서 사용하기 좋은 보일러 플레이트를 만들었다. 내부적으로 보완하면 좋을 점들을 의식해서 여러 기술들과 컨벤션을 정의했다. 예를 들면, 컴파일 타임에서 쿼리 검증을 위한 JPA와 이를 동적으로 구성하기 위한 QueryDSL 및 가이드, 로컬 개발 환경 의존성을 낮추기 위한 Embedded Redis와 Redis Cluster 구성 가이드, 지속적으로 큐를 생성하여 이용하는 형태를 개선한 RabbitMQ 이용 방안, 백오피스에서 사용할만한 GraphQL 등을 녹여냈다. 내가 만든 보일러 플레이트는 CQRS + DDD 아키텍쳐를 기반으로 구성했고, 5000 라인 가까이 작성했다.
그렇게 작성을 하고 나니, MSA 형태에서도 동작할 수 있는 Non-Blocking 보일러 플레이트를 만들어보면 어떨까 하는 생각이 들었다. 시간이 꽤 남았기에 가능할 법 하다고 생각했다. 취지는 이전 Blocking 형태의 보일러 플레이트를 만드는 것과 동일했기에 별도의 허락은 구하지 않고 착수했다. 많은 데이터가 오가는 부분에서 데이터량에서 득을 보고, 동적 압축을 추구할 수 있도록 gRPC를 작성하고 가이드라인을 마련해봤다. 또한 Blocking 작업을 찾아낼 수 있도록 BlockHound를 적용하고, 개발 환경 별로 다르게 동작할 수 있도록 구성을 달리 했다. QueryDSL과 Redis 역시 Reactive 한 형태로 동작할 수 있게 R2DBC와 Reative Redis Cluster를 구성했고, 테스트 코드를 위해 Rollback이 가능하도록 별도의 Transactoional Operator를 만들었다. Spring MVC, Spring WebFlux, gRPC 등이 별도의 포트로 구동되어 있어서, 하나의 포트로 운용하면서 API 명세까지 제공 받기 위해 Spring Boot를 Armeria로 감쌌다. 마찬가지로 CQRS + DDD 아키텍쳐로 구성했고, 5000 라인 정도 작성했다.
2) 소감
2달 반 정도의 기간동안 3개의 프로젝트를 하면서 업무에 적응해봤다. 예상했던 것 보다 굉장히 빠르게 시간이 갔다. 대체로 내가 보낸 2달 반이 기존 업무의 노선과는 거리가 조금 있다보니, 업무적으로도 이해도를 많이 늘렸다고는 하지만 가야할 길이 멀다고 느껴진다.
혼자 있는 시간이 조금 있었던 만큼 약간은 멀리서 흐름을 볼 수 있었다. 사내에 어떤 점이 없고, 어떤 것들이 있으면 좋겠는지 느낀 부분들이 있다. 잘 돌아가는 프로그램에서도 좋은 점과 보완하면 좋은 점들을 느끼기도 했고, 대체로 내가 맡아서 개선할 수 있는 점들이 많아보여서 좋았다.
그런 의미에서 Boiler Plate들은 굉장히 과감한 프로젝트였다. 사내에는 없는 개념이었기 때문이다. 처음에는 보일러 플레이트가 없을 때 왜 없지 라는 고민을 많이 했지만, 그럼에도 어떤 이유가 되었든 보일러 플레이트가 없을 때의 단점보다는 있을 때의 장점이 훨씬 많다고 생각했다. 내가 갖고 있는 여러 기술의 선택지들 중에서 사내에 적용된 기술 중에 부족한 점은 어떤 것들인지, 있는 것들 중에서도 문제점은 어떤 것들이 있는지 파악하려고 노력했다. 그렇게 선택된 기술들을 녹여내어 프로젝트를 구성했고, 실제로도 신규 프로젝트를 시작할 때 이용이 될 수 있도록 가이드라인을 상세히 작성하려고 해봤다.
내가 그리는 가장 최적의 시나리오는 이 프로젝트가 팀 내에서 밝혀졌을 때 관심이 있는 개발자들이 모여서 여러 논의를 하고, 수정할 부분은 수정하고, 덧댈 부분은 덧대고, 없을 부분은 없애는… 보일러 플레이트를 가다듬어서 완성도 있는 기틀을 만드는 것이었다. 러닝 커브와 같은 여러 문제를 생각했을 때는 이 프로젝트들이 반영될 가능성이 매우 낮음에도, 일부의 기술이라도 조금씩 차용되어서 이용된다면 그것만으로도 성공이라고 생각하고 있다.
이와 같은 면 외에도 개인적으로도 성장한 부분이 있었다. MSA를 스스로 고민하고, 어떤 아키텍쳐가 좋은지 고민을 해보는 시간이 많았다. 그 과정에서 gRPC가 어떤 장점을 갖고 있는지, Non-Blocking이라는 개념이 왜 등장했고 왜 필요한지, 물리적으로 분리된 서비스의 인스턴스들의 동기화를 위한 SAGA 패턴 등을 생각하고 배울 수 있었다.
아쉬웠던 점이라고 한다면 비즈니스 로직을 녹일 기회가 없으니 SAGA 패턴을 직접 구현해보지 못한 점, 아키텍쳐를 명확하게 생각하지 않아 Hexagonal 아키텍쳐가 더 나아보이는데도 DDD를 적용 했다는 점이 아쉬웠다.
개발 환경 세팅부터 개발을 원활하게 할 수 있도록 주변 환경을 구성하기 위한 고군분투가 정말 많았는데, 그래도 2달 반이 정말 의미있게 지나간 것 같다. 앞으로 MSA를 개발하면서 겪을 난관들을 통해 성장할 모습을 기대하고, 상황에 걸맞는 해결책을 낼 수 있도록 꾸준히 노력해야겠다고 생각했다.
4. 향후 계획
능숙하게 업무를 쳐내는 것 (즉, 적응하는 것)이 1차적인 목표이다. 이 부분은 시간이 지나면 해결될 수 있는 부분이라고 생각하는 만큼, 그 이후를 바라봤을 때는 크게 3가지를 준비해야 문제 없이 개발 및 운영 측면에서 리드를 하게 될 수 있다고 생각한다. 평타라도 칠 수 있었으면 좋겠다.
1) 문제 풀이
기술적인 부분들은 적용할 기회가 많아보여서 큰 문제가 되지 않는데, 비즈니스 로직을 풀어낼 시간이 많이 없는 부분은 문제라면 문제가 될 수 있을 것 같다. 이 부분을 알고리즘 문제 풀이로 완벽히 풀어낼 수는 없겠지만, 충분히 새로운 비즈니스를 마주했을 때 빠르게 적응할 수 있을만한 (간극을 거의 없애는) 역량으로는 만들 수 있을 것이라 생각한다.
얼마 전에 Solidarite CTO인 친구를 만났다. 여러 얘기를 주고 받긴했지만, 요즘 내가 매일 퇴근 후에 문제 풀이를 하고 있다는 얘기를 했었는데 이를 되게 좋게 봤었다. 당연히 프로그래밍에 도움이 되는 것들이니까 좋은 점은 맞지만, 왜 좋게 보는지 문득 궁금해서 물어봤다. 기술적인 부분은 시간이 지날수록 트렌드를 타고 바뀌는 부분이 많은데, 알고리즘 문제 풀이는 대체로 불변한 역량이라서라는 답을 들을 수 있었다.
비슷하게는 생각한 적이 있는데, 이렇게 명확한 문장으로 들으니 더 그만 둘 수 없게 되었다. solved.ac 기준으로 카테고리 역량을 수치적으로 분석해서, 부족한 부분 위주로 평균치를 끌어 올려야겠다고 생각했다. 당장은 그리디를 풀고 있는데, 이후 노선으로 DP까지 정해놓고 약 3개월 간 정복해가야겠다.
2) Kubernetes
MSA하면 뺴놓을 수 없는 기술일 것이다. k8s를 써본적이 없거나 공부를 안 해본 것은 아니지만, 실무에서 사용해볼만큼의 깊이가 있지는 않다고 생각한다. 그런 취지에서 CKA를 취득하려고 했었는데, 지금이 딱 적기라고 생각한다. k8s를 써볼만한 환경이 갖춰져가고 있다고 생각하고 있다. 10월과 11월은 대체로 k8s를 학습하고, 업무에서 사용해볼 수 있도록 공부해볼 예정이다. 약 3~6개월 내에 자격증 취득까지 해볼 수 있도록 도전도 해볼 예정이다.
3) Effective Java
프로그래밍 언어를 습득할 때 단순히 공통된 문법을 배우는 것은 크게 어렵지 않다. 문제는 그 윗 단계인데, 언어가 가진 고유한 특성을 이해하고, 그 동작 원리를 이해하여야 문제가 발생하지 않는 코드를 작성할 수 있다. 현재 업무에서 이용하는 언어가 Java인 만큼, Effective Java를 통해 앞서 말한 단계에 안착할 수 있을 것이라 생각한다. 업무에서 사용되는 코드가 적절한지 적절하지 않은지 판단하여 개선하고, 내가 작성한 코드에 확신과 근거를 갖기 위해선 Effective Java를 읽고 실사례에 빗대어 이해할 수 있도록 예시를 직접 만들어보고 적용하는 과정이 필요하다고 생각한다. 이러한 이유 때문에 42 내에 유능한 동료들과 스터디를 하고 있는데, 8월부터 시작한 이 스터디를 내년 2월까지는 마치는 것이 목표이다.