1년차 백엔드 개발자의 퇴사 회고 a.k.a 이직 후기 인트로

앞선 이야기

- 서른 살, 돈이 벌고 싶다가 개발이 하고 싶어진 이야기

- 33살 문과 비전공자 국비지원 개발자 신입 취업 후기

- 잘하기보다 자라기 - 0년 차 주니어 개발자의 2023년 회고

 

입사

첫출발

2023년 여름, 개발자로서 첫 커리어를 시작했다.

어떤 회사

누구나 알만한 회사는 아니었지만, 설명하면 대충 거의 다 아는, 그런 회사에 입사했다. 이 회사는 스프링 클라우드를 사용하는 MSA 구조를 가지고 있었고, 레디스와 카프카를 활용하고 있었다. 전체 시스템 TPS도 6-7만 가량으로 많은 트래픽도 발생하고 있었다. 신입 자바 개발자로서 이보다 더 좋은 기술 스택을 갖춘 곳으로 들어가기란 힘들 것 같았다.

 

신입으로서 첫 직장을 가질 때 가졌던 마음은 '뭐가 됐든 성장할 수 있는 곳에 가면 된다'라는 것이었다. 내가 세운 기준은 스프링을 사용하고 JPA를 사용하는 곳이었는데, 이 회사는 그보다 훨씬 과분한 곳이었다.

에피소드

원래는 주니어 개발자를 뽑을 생각이 없었다고 했다. 이전에 몇 번 데인 경험이 있었다는 걸 지내면서 알게 되었다.

 

감사하게도 당시 팀장님이 나를 좋게 봐주셨다. 회사와 딜을 쳐서 마지막으로 믿어보기로 한 사람이 나였다고 한다.

 

도대체 왜? 라는 게 궁금했다. 당시 팀장님 이야기로는 '개발을 하면서 질문을 하는 사람'이어서라고 했다. 그 점에서 블로그에 틈틈이 작성했던 글들이 도움이 되었던 것 같다.

 

그런데 그게 기분 좋으면서도 묘하게 서늘한 그런 느낌이었다. 게다가 내 자리는 선임 티오이기도 했다. 첫날부터 수습 기간 내내 나를 증명해야 하는 치열한 시간들을 보냈다.

입사와 퇴사 사이

기술과 개발에 대해서

레거시가 있었지만 신규 프로젝트들은 전부 마이크로 서비스 아키텍처 내에서 구성하고 있는 회사였다. 내가 속한 코어 개발 팀은 레거시보다는 신규 프로젝트를 주 업무로 했다. 그래서 자연스럽게 MSA 구조를 접하고 EDA 기반에서 서비스 개발을 시작할 수 있었다.

 

각각의 마이크로 서비스(M 서비스)에 대해서 도메인 서비스라고 불렀다. 주요 도메인 별로 서비스가 분리되어 있기 때문에 내가 맡은 부분에 대한 자율과 책임을 스스로 지는 업무 환경이었다. 팀 전체의 컨벤션을 따르는 선에서 내가 맡은 서비스에는 무한한 자율성이 보장된다. 덕분에 여러 가지 시도를 할 수가 있었다.

 

나의 경우에는 특히 테스트에 많은 시간과 노력을 들였다. 올해 초에 수강했던 ATDD 과정에서 배운 것들을 현업에서 정말 마음껏 활용했다. 초반에는 단위 테스트를 위주로 작성했지만 후반으로 갈 수도 개인적으로 인수 테스트를 선호하게 되었다. 결론적으로 BDD 방식으로 Cucumber를 사용해 테스트를 작성하는 습관을 들였다.

 

테스트가 많아지면 문제가 되는 것 중 하나는 CI 과정에서 테스트가 도는데 시간이 많이 걸린다는 점이다. M 서비스로 각자가 온전히 하나의 서비스를 맡으면 좋은 점은 그 오랜 시간을 기다리는 사람은 나 뿐이라는 점이다. 내가 맡은 서비스에 한해서는 테스트 코드를 얼마나 작성하든 신경쓰지 않는다. 빌드 시간이 길어지더라도 괜찮다. 덕분에 6개 가량의 서비스를 신규 개발부터 배포하고 도맡아 운영까지 하면서 1200개 이상의 테스트 코드를 작성할 수 있었다.

 

구조적인 측면에서는 기본적으로 레이어드 아키텍처를 사용했지만, 필요에 따라 클린 아키텍처를 적절히 도입해 사용했다. 이외도, 도메인 주도 개발 방법론을 이용해 프로젝트를 리팩토링하는 경험, 좋은 로깅을 위한 애플리케이션 수준에서의 로깅 시스템 개발 경험 등 내 서비스에 한해서 이것저것을 시도해 보고 지지고 볶으며 개인적인 성장 기회도 가질 수 있었다.

일에 대해서

회사에서는 개발만 잘해서는 안 된다. 일에 대한 태도, 프로 의식, 비즈니스 요구를 충족시키는 능력 등 다양한 요소가 중요하다. 이 회사에서 일하면서 배운 가장 큰 교훈은 바로 "개발을 잘하는 것"과 "일을 잘하는 것"은 다르다는 점이었다.

 

회사에서 나는 경력상 가장 어린 개발자였다. 주니어라고 해도 대부분 3, 4년 차였고, 그 외에는 7, 8년 차 이상의 시니어분들이 전부였다. 이 분들과 일하며 개발을 일로서 한다는 것에 대해 많은 배움을 얻을 수 있었다.

개발을 잘하는 것과 일을 잘하는 것

이전 글 항해 플러스 백엔드 5기 1~5주차 현실 100% 회고 (1+1=N) 에서도 작성했지만 개발자란 뭘 하는 사람일까에 대해서 꾸준히 고민해던 것 같다.

 

확실한 건 개발을 잘하는 것과 일을 잘하는 것은 다르다는 점이다. 개발자는 결국 회사 비즈니스에 있어서 기여를 하고, 그에 따라 보상을 받는 사람이 아닐까 싶다.

 

그렇게 본다면 코드 작성은 수많은 도구 중 하나일 것이다. 다만 개발자는 코드를 통해 비즈니스 요구 사항을 풀어내고 가치를 만들어낼 뿐이다.

 

어쩌면 가장 최신의 기술을 배워온 신입 개발자로서 코드를 작성하거나 문제에 대해 유연한 해결책을 제시하는 점에서는 나보다 경력이 훨씬 많은 사람들보다 내가 좀 더 잘했을 수 있다고 생각한다. 사실 처음에는 그게 아쉬운 부분이기도 했다. 그런데 일을 하면서 비즈니스 개발을 하는 사람들의 방식과 노하우를 많이 배울 수 있었다.

 

기억에 남는 한 시니어 분이 있다. 이 분은 10년 이상을 공공기관 같은 곳에서 일을 하셔서 코딩 스타일이나 접근이 그렇게 세련되지는 않았다. 그런데 회사 비즈니스에 대해 이해하는 게 정말 탁월한 것 같았다. 그걸 정의하고 분석해서 일을 만들어 내고 다른 부서와 협력하며 문제를 풀어내는 방식이 남달랐다. 이런 분들과 업무를 함께 하면서 개발자로서 일을 한다는 것에 대해서 새로운 관점도 많이 얻게 되고 일하는 개발자로서의 성장도 많이 했다고 생각한다.

 

결국 프로란 무엇일까?

 

어떤 상황에서든 결과물을 만들어내는 사람일 것이다. 도구를 탓하거나 환경을 탓할 수 없다. 주어진 상황에서 회사의 가치를 끌어내기 위해서 최선의 노력을 하는 것. 그런 프로를 지향하게 됐다.

팀워크의 중요성

팀으로 일하는 법도 배웠다.

슈퍼 개발자 얘기를 종종 듣곤 했다. 20년 전에는 팀에서 꼭 한 명씩 슈퍼 개발자가 있는데, 자신이 쓰는 노하우나 기술을 알려주지 않고, 혼자서 뚝닥 다 해놓는다고. 그런데 지금 개발 문화나 환경은 어떨까. 개발자 혼자만 잘한다고 해서 프로젝트가 성공하지 않는다. 기획팀, QA팀, 그리고 이 회사 같은 경우에는 현장에서 일하는 정말 많은 부서들과 협업하여 공동의 목표를 위해 으쌰으쌰 하는 게 중요했다.

 

약 15년 전 넥슨에서 출시한 근본 게임으로 어둠의 전설이라는 게임이 있는데, 거기에 '대형'이라는 개념이 있다. 게임에는 다양한 직업의 캐릭터들이 있고 함께 사냥을 하면서 경험치를 획득할 수 있다. 사냥을 할 때 플레이어들은 '대형'을 펼친다. 대형이란 각기 다른 직업을 가진 캐릭터들이 특정한 포지션을 잡고 정해진 위치에서 자신의 역할을 수행하는 것을 의미한다. 예를 들어, 전사는 앞에서 적의 공격을 막아내고, 마법사는 후방에서 마법 공격을 시전 하며, 힐러는 팀원들의 체력을 회복시키는 것이다. 

 

https://minimob.tistory.com/709

 

개발자로서 팀워크를 한다고 하면 나는 추억속의 어둠의 전설과 이 장면이 종종 떠오른다. 회사에서도 각자가 자신의 일을 하면서 서로를 지원해줄 때 좋은 시너지 효과를 얻을 수 있다. 

 

천부적인 개발자보다 팀 플레이어로서의 개발자가 더 빛난다고 생각한다. 

 

문제 해결 역량

종합하면 결국 개발자는 문제를 푸는 사람이다. 여기서 여기서 문제란 좁은 의미에서는 알고리즘이나 자료구조와 같은 정형화된 문제들 뿐만 아니라, 훨씬 더 넓은 의미로서 현업에서 맞닥뜨리는 다양한 문제들을 의미한다.

 

기술적인 구현일 수도 있고, 비즈니스의 가치 증진을 위한 과제 해결일 수도 있으며, 사람들과의 협업 문제일 수도 있다. 때로는 문제의 답이 명확하지 않기도 하고 차악의 선택을 해야 하는 경우도 있다. 따라서 개발자로서의 실제 문제를 잘 푼다는 것은 현실 세계에서 마주하는 문제를 잘 정의하고, 분석하고, 최적의 해결 방식을 찾아내는 역량을 의미한다. 또한, 문제를 해결하기 전과 후를 비교했을 때 더 나은 가치를 제공할 수 있는 능력을 의미한다.

일 잘하는 개발자로 성장하기

이 회사의 경험들은 내가 개발자라는 기술자로서의 기본기를 다지는 것뿐만 아니라, 일을 잘하는 법, 그리고 팀으로 협업하는 법을 가르쳐 주었다.

혼자 방구석에서 고민했다면 얻을 수 없었을 소중한 시간들이었다.

성장과 인정

우수사원 선정

2024년 우수사원으로 선정되었다.

 

우수사원 선정은 연례 행사가 아니고, 대규모 프로젝트가 끝난 시점에서 특별히 지정된 행사로서 이루어졌다. 감사하게도 내가 선발되었다.

 

근데... why?

그런데 정말 궁금했다. 그래서 물어봤다.

 

선정 당시 팀장님과 그룹장님께서 해주신 칭찬의 말들은 내가 회사에서 어떤 모습으로 비쳤는지 알 수 있는 좋은 기회였다.

 

"무엇을 시키든 기대 이상의 결과를 가져왔던 사람"

"어떤 것이든 믿고 맡길 수 있는 사람"

 

정말 과찬을 받았다.

 

어떤 점이 좋게 보였을지 몇 가지 포인트에서 생각해보았다.

질문하는 습관

나는 좀 물음표 살인마 같이 느껴질 정도로 많은 질문을 하는 편이다. 업무고 기술이고 코드고 할 것 없이, 궁금한 점은 바로바로 해결하려고 했다. 요구 사항을 받은 시점부터 궁금한 점은 일단 다 물어보았다.

 

그러다 보니 가끔씩 내가 고개를 갸우뚱하며, 흐음... 쓰읍... 이러고 있으면 옆에 'ㅋㅋㅋㅋ또 왜?!' 라면서 활발한 토론을 시작하는 경우가 많았는데, 생각해 보면 참 좋은 업무 환경이었다고 생각한다.

회사의 특성상 서비스가 분리되어 내가 맡은 일 아니면 관심을 아예 꺼도 사실 상관이 없이 돌아가는 상황이긴 했다. 주니어이기 때문에 그리고 내가 맡은 것만 잘하면 돼라는 식으로 해도 문제가 없었다. 그런데 호기심이 발동할 때마다 굳이 참지 않았다. 

 

"레디스를 이렇게 사용하는 이유는 무엇인가요?"
"클러스터링은 어떻게 되어있고 어떤 모드를 사용하고 있나요?"
"이렇게 되면 이런 문제가 있을 것 같은데 어떤 대책이 있나요?"

사실 회사에서 엄청난 기여를 하고 싶다기보다는 성장 욕심이 컸던 것 같다.

어떤 면에서는 '회사에서 개발을 하는 사람'이라는 본캐에 좀 더 충실하고자 했던 거기도 하다. 내가 가장 잘 성장할 수 있는 그라운드는 현재로서는 여기니까.

내가 성장할 수 있던 부분도 있지만, 덕분에 맡은 서비스를 개발하고 운영하는데 큰 문제없이 잘 해낼 수 있었다고 생각한다.

문서화

문서화를 엄청 열심히 했다. 내심으로는 결국 내가 편하고자 하는 이유도 있었다. 퇴사할 때 내가 편하기, 다음에 누가 물어볼 때 답변하기 편하기, 미래의 내가 이해하기 편하기 위해서였다.

 

업무 시작하는 시점부터, 중간 과정을 거의 전부 기록하고 정리했다. 모든 것을 다 기록한다기보다는 해당 프로젝트에 대한 요구 사항을 내 나름대로 해석한 것, 기술적인 과제들, 그리고 결정의 이유 과정, 남은 이슈들 등을 중심으로 기록했다. 관리자 입장에서는 이런 내가 투명하게 비쳤던 것 같다.

 

자부하건대, 공용 업무 프로젝트 정리에서는 최강이라고 자부할 수 있을 것 같다. 리뷰도 열심히 했는데, 회사에는 정기적인 코드 리뷰 같은 것들은 없었지만, 가까이서 일하는 팀장님들, 팀원들에게 이슈가 있을 때마다 자리로 불러서 코드를 설명하고 리뷰를 부탁하곤 했다.

 

그리고 덕분에... 인수인계 문서 작성하는데 정말 편했다!!!

안정적인 서비스

결국 핵심은 안정적인 서비스 제공이다. 오너이자 메인테이너로서 총 6개, 기타 관련 작업을 한 프로젝트까지 하면 10개 넘는 프로젝트를 수행하면서 테스트 코드는 1200개 이상 작성했다.

 

어쨌든 테스트 코드 = 안정성, 어느 정도 맞는 공식이다. 나는 왜 이렇게 테스트 코드에 집착했나? 사연이 있기는 하다.

 

학원에서 파이널 프로젝트를 할 때였다. 당시 프런트엔드를 담당하던 한 친구가 계속 내가 구현한 기능에 뭐가 안된다 할 때마다, 컨텍스트 스위칭이 자주 발생하는 경험을 했다. 개발 효율성도 떨어지고 개인 개발 경험에 있어서도 좋지 않았다. 그때부터, 아 내가 짠 코드에 대한 최소한의 검증이 필요하다는 것을 깨달았고 그러려면 어떻게 해야 할지를 고민했던 것 같다.

 

회사에서 실제 QA 팀이 있고 개발 사이클에서 당연히 QA 과정이 포함되긴 하지만, 프런트엔드와의 협업, 그리고 다른 서비스와의 통신 과정에서 내가 제공하는 API에 대한 보장은 백엔드 개발자로서 당연한 책임의 범위에 속한다. 자연스럽게 테스트와 개발을 한 묶음으로 보는 습관을 가지게 되었다. 때로는 TDD로 작성하고, 때로는 반드시 TDD는 아니었지만, 모든 프로젝트에서 평균 커버리지 80% 이상을 유지했다.

 

테스트에 대한 경험과 노하우가 어느 정도 쌓이다 보니 나눠줄 것이 생기기도 했다.

 

그래서 회사에서 몇몇 아티클을 작성해 공유하기도 하고 그랬다.

 

 

그런데도 회사의 1년 넘게 테스트 코드를 짜는 사람은 나밖에 없었다. 그래서인지 QA 과정에서도 내 부분이 상대적으로 적게 나오고 항상 좀 빨리 끝난 경향이 있다. 테스트 기반으로 개발을 하니 서비스 자체도 안정적일 수밖에 없는 건 당연하다. 이 점이 좋은 성과로 이어질 수 있던 포인트가 아니었나 싶다.

퇴사

회사가 성장할 수 있는 환경을 충분히 잘 갖추고 있었다는 점에서 감사하다.

포인트를 정리해 보자면 이런 점이 좋았다.

• 언제든 질문해도 잘 대답해 주는 시니어가 있다는 점
• 나를 알아봐 주고 인정해 주는 상사가 있다는 점
• 엄청 도전적인 환경은 아니더라도 백엔드 개발자로서 챌린지 한 여러 문제들을 만날 수 있는 환경이었다는 점
• 기타 복지들 1: 점심, 저녁, 야근 비용 제공, 모니터 2대, 맥북 프로
• 기타 복지들 2: 걸어서 10분 안에 도착할 수 있는 거리

그래서 왜 떠나는지? 크게 두 가지 이유를 생각했다. 🙌🏻

떠남의 이유를 찾아보자

1. 성장 가능성

회사의 환경 덕분에 다양한 기술 스택을 익힐 수 있었고, 여러 문제들을 해결하며 백엔드 개발자로서의 기초를 다질 수 있었다. 하지만, 더 많은 문제를 풀고 도전을 만나는 데 대한 갈증이 생겼다. 이를 위해서는 더 많은 데이터와 트래픽을 다루는 환경에서 일해야 한다고 생각했다.

지난 학기에 수강한 '인공지능 수업' 중에 몬테카를로 트리 탐색 전략이라는 것이 있다. 이 전략은 문제를 해결할 때 탐사(Explore)와 활용(Exploit)의 균형을 맞추는 것이 중요하다는 점을 강조한다. exploit은 이미 알고 있는 정보를 활용하여 최적의 결정을 내리는 것이고, explore는 새로운 정보를 얻기 위해 모험을 감행하는 것이다.

https://medium.com/analytics-vidhya/the-epsilon-greedy-algorithm-for-reinforcement-learning-5fe6f96dc870

위 그림은 exploit과 explore 사이에서 선택을 해야 하는 상황을 보여준다. 로봇이 평소 가던 식당과 새로 생긴 식당 사이에서 고민하고 있는 모습이다.

첨부한 그림은 몬테카를로 탐색 전략을 잘 보여준다. 로봇이 익숙한 장소(The Usual Place)와 새로 오픈한 장소(Grand Opening) 중 어디로 갈지 고민하고 있다. 이는 우리가 매일의 선택에서 익숙한 길을 가느냐, 새로운 길을 탐험하느냐를 결정하는 순간을 상징적으로 나타낸다.

1년 차 개발자로서 현재 업무가 어느 정도 익숙해졌지만, 어떤 면에서는 현재의 회사가 컴포트 존으로 다가오기도 했다.

 

나는 이제 막 개발을 시작한 주니어 개발자로서 모험의 비중이 더 높여야 하는 시기라고 생각했다. 그런 면에서 더 넓은 시야를 가지고 새로운 문제와 직면하고 싶었고, 새로운 영역으로 나를 던질 시기가 왔구나,라고 생각했다.

 

그 한 가지 방법은 보다 더 큰 회사로 가는 것이다.

 

2. 도전

더 큰 회사에 가보고 싶어졌다.

 

대기업이 항상 답은 아닐 것이다. 하지만 많은 사람들이 대기업에 취업하려고 하는 이유는 분명히 있다. 복지와 처우 문제 외에도 인재 밀도를 그 이유로 꼽고 싶다. 그리고 더 많은 기회가 있을 거라는 점도.

 

당신은 당신이 가장 많은 시간을 함께 보내는 다섯 사람의 평균이다
- 짐론 (사업가)

여기서 다섯 사람이 반드시 지인이거나 회사 사람일 필요는 없다. 하지만 환경이 중요하다는 맥락에서 볼 때 회사는 분명 많은 시간을 보내는 장소임에 틀림없다.

 

그러면 내 평균을 올리고 싶다면? 당연한 얘기지만 탁월한 사람들 사이에 섞여있는 것이다.

 

같은 맥락에서 박재성 님이 역량을 갖춘 개발자가 되는 좋은 방법에 대해서 다음과 같이 이야기한 건 우연이 아닐 것이다. 

 

역량을 갖추고 인정받는 개발자가 되는 가장 좋은 방법은 주변에 뛰어난 역량 있는 개발자와 함께 하는 것이다.

이런 점을 고려할 때, 대기업이란 곳을 가보고 싶다는 생각을 하게 되었다. 지금의 회사에서도 이만큼 성장할 수 있었는데, 더 큰 회사로 가면 얼마나 더 성장할 수 있을까, 하는 생각을 했던 것 같다.

 

그런데 과거 수능 입시에 겪은 실패 경험이 떠올랐다. 고등학교 1, 2학년 때는 나름 좋은 성적을 유지했지만, 고3 때 원하는 만큼 성적이 나오지 않았다. 재수할 자신은 없었고, 성적에 맞춰 대학을 갔다. 결과적으로 보면 덕분에 인문학을 하며 내 적성을 발견할 수 있었고, 숨마쿰라우데로 졸업하면서 후회 없는 대학 생활을 할 수 있던 것은 참 축복이었다고 생각한다. 그렇지만 가끔 친구들에게 "너는 재수했어야 했다"는 말을 들을 듣곤 했는데, 돌이켜보면 내가 도전을 회피했던 것은 아닌가 하는 생각도 든다. 🤔

 

현재 시점에서도 그 상황이 겹쳐졌다.

 

나는 지금에 안주하며 대기업에 도전하는 것을 회피한 것은 아닐까라는 생각이 들었다. 개발자로서의 장기적인 커리어를 생각했을 때 지금이 아니면 그런 도전을 할 시기가 또 있을까 싶었다.

그래서 퇴사를 결심했다. 

 

그런데... 

이직 인트로

퇴사를 결정하기 전에는 사실 이직이 확정된 상태가 아니었다. 

 

그런데 감사하게도 퇴사 후 1주일 뒤 넥슨으로 새롭게 출근하게 됐다.

 

 

가게 되는 팀은 백엔드 코어 도메인 중 하나로, 백엔드 개발자로서 꼭 한 번쯤은 겪어보고 싶었던 팀이었다. 장기적인 커리어를 생각해도 정말 좋은 경험치를 쌓을 수 있을 거라는 확신이 드는 팀이다.

 

넥슨 채용을 준비하고 그 과정을 거치면서 회사에 대한 핏을 발견하게 된 부분이 있다. 그래서 점점 더 과몰입하게 되었고 거기에 좋은 운까지 겹쳐 원하는 결과를 얻을 수 있었다.

 

퇴사를 마음먹으며 가졌던 마음 가짐은 취준생으로 치열한 삶을 리플레이해 보자! 였는데 감사하게도 환승 이직을 할 수 있었다.

 

입사부터 퇴사하고 이직까지 딱 1년이다. 

 

설레는 부분이 있다. 

 

 

 

이직과 새 회사에 대한 회고는 조금 더 시간이 지나고 작성하려고 한다. 

 

---

 

 

끝.