팀을 옮긴 후 2년 반을 돌아보기 (1) - 이동 과정

 '개발자의 글쓰기' 라는 책을 읽고, 개발자의 블로그는 소재 의식(자기만의 관점이나 생각) 에 따라 작성하는게 좋다는 내용에 영감을 얻어 시작해본다. 이 블로그의 마지막 포스트가 '2년차의 마지막에 처음 써보는 개발자 회고 (2018-2019)', 무려 2019년 12월에 작성한 글이었는데 벌써 4년이 지났다. 오랜만에 글을 읽어보니 4년 전의 나는 지금보다 글쓰기를 잘했던 것 같고 당시의 감정에 비하면 의외로 차분하게 글을 써 내려간 것으로 보인다. 그간 소속하고 있는 팀도 달라졌고 그만큼의 다양한 이야깃거리도 있었지만, 이번에는 이전 팀에서 왜 이동했는지와 이동한 이후의 경험들, 그리고 현재의 생각들도 남겨보려고 한다.

이동하고 싶었던 이유

 이유는 여러 가지가 있었다. 기억나는 대로 나열해보면 다음과 같다. (현재 해당 조직의 상황은 다르다. 당시 기준의 기억임을 감안하길 바란다.)

• 사용하는 기술이 너무 오래되었고, 정체되어 있다.
• (위와 이어서) 새로운 것에 대한 코멘트를 기대하기 어렵다.
• 서비스의 발전 방향이 나의 생각과 일치하지 않는다.
• 조직이 불안정하다.

각각의 세부 내용들은 너무 길어지지 않게 생략한 것들도 있다.

1) 사용하는 기술이 너무 오래되었고, 정체되어 있다.

 나는 국내에서 손꼽히는 오래된 서비스 개발팀에 있었다. 메인 코드 베이스에 대해 단순 JDK 기준으로만 봤을 때 2010년 대 초반 버전이었고, 사용하는 웹 프레임워크 기술 중 구글에서도 결과가 나오지 않는 것이 있었다. 내가 입사한 2018년 당시 Java 1.8, Spring boot 2.0 등 최신 기술 스택 도입을 시도한 새로운 코드 베이스도 만들어지고 있었다. 편의를 위해 이 코드 베이스는 '2018 레포' 로 칭하겠다. 원래 의도는 기존 오래된 코드 베이스를 2018 레포로 완전히 옮겨오려는 계획이었지만 어떠한 이유로 추진 동력이 없어졌다. 그리하여 메인 코드 베이스도 2018 레포도 별도 운영 상태로 존재했다.

 얼마 후 2018 레포에 서킷브레이커를 추가해야 할 일이 생겼다. hystrix 는 지원이 중단되는 분위기였고 대안인 resilience4j 는 boot 2.1 이상을 요구했다. 당시 최신은 2.3 이었지만, 2.1 로 버전업을 진행하면서도 MySQL driver 버전업으로 인한 오류 등 몇 가지 이슈가 발견되었다. 버전업으로 인한 서비스 장애로 이어질 수 있었기 때문에 이후 버전업은 아예 없었다. (애당초 버전업 작업 자체가 입사 이래 처음 있던 일이었다.) 그 후 다양한 새로운 프로젝트들을 진행하면서 다양한 코드 베이스들이 새로 생겨났다. 기존 메인, 2018 레포, 기능 컴포넌트1, 기능 컴포넌트2, ... 등 이전에 만들어 둔 것들에 대한 버전업 등의 개선을 진행하지 못한 채 새로운 기술을 도입한 개별 레포만 늘어나는 형태가 된 것이다.

 오래된 기술 스택을 그대로 유지한다면 누가 새로 들어오고 싶어할까, 기존 사람들도 계속 힘든게 아닌가 하는 생각이 있었다.

2) 새로운 것에 대한 코멘트를 기대하기 어렵다.

 바로 위에서 예시로 든 boot 버전업과 같은 비교적 작은 작업과, kafka 를 새로 도입하는 큰 작업을 진행할 때 조언을 구하기 어려운 환경이었다고 생각했다. 여태까지 내가 진행했던 업무들이 기반이 되어 나를 믿어주었다는 생각이 들어 감사하기도, 또 죄송하기도 하지만, 여러 오류를 겪은 후 든 어린 생각으로는 "누군가 조언해 줄 사람이 있었으면 어땠을까?" 였다.

3) 서비스의 발전 방향이 나의 생각과 일치하지 않는다.

 기존 서비스에 대해 새로운 시도를 해보려는 프로젝트를 진행했었는데 개인적으로는 그와 같은 방향으로의 발전을 기대했었다. 하지만 상위 조직에서나 서비스 운영팀 내부에서나 이 오래된 서비스에 손대는 것을 더 이상 원하지 않았고, 수익을 기대할 수 있는 새로운 형태의 서비스를 만들어내길 원했다. 이 부분은 이전 회고글의 '내부 신규 서비스 과제 2' 에 해당하는데, 4개월 내로 새로운 서비스를 출시해야 한다는 이유로 여러 가지 타협을 거치며 (개인적으로 생각하기엔) 출시 당시에 이도 저도 아닌 결과물을 내놓았다.

 여러 가지 개선 과정을 거치긴 했지만, 도저히 이 서비스에는 마음이 가질 않았다. 자랑이라고 할 수는 없지만 사내에서 쿠폰까지 제공해주었는데도 운영 환경에서는 유료 결제도 해보지 않았다. 이미 이렇게 마음이 떠나 있었지만 상위 조직에서는 기존 서비스에 대해선 손 댈 생각이 없어보였고, 새로 만들어낸 서비스에 대한 추가 프로젝트들만 진행하던 중이었다.

4) 조직이 불안정하다

 원래 기존 오래된 코드 베이스를 2018 레포로 완전히 옮겨오려는 계획이었지만, 상위 조직이 바뀌고 그에 따라 내가 소속해 있는 팀 구성원들도 많이 바뀌게 되면서 추진 동력이 사라졌다고 생각한다. 중간에 2018 레포를 실패로 보는 일도 있었는데, 2018 레포가 없었으면 기존 오래된 코드 베이스에서 어떻게 신규 서비스를 만들었을지 막막하다.

 앞서 언급한 상위 조직이 바뀌고, 팀 구성원들도 바뀌는 과정에서 스트레스를 많이 받았다. 단적으로 당시 카카오톡 상태메시지는 "뭐하러 다니는거지" 였다.

 불안정과 별개로 성과 평가에 대한 불만도 있었다. 아직까지도 2019년이 가장 열심히 업무를 진행했던 시기라고 생각하는데, 해당 년도에 대한 평가가 기대에 미치지 못하니 그 다음 해인 2020년은 개인적으로 동력을 잃었었다. 조직 차원에서는 유의미한 결과를 내지 못하고 작은 업무들만 했다고 판단했을 수도 있다.

배경 지식 - 회사의 조직 이동 제도에 대해

 우리 회사에는 공식 조직 이동 제도가 있다. 내가 지원할 당시에는 새로운 사람을 원하는 팀들이 매달 신청을 했는데, 해당 팀에서는 무슨 일을 하고/할 것이고, 어떤 기술을 사용하며, 어떤 분위기와 마음가짐으로 운영되는지를 간단하게 소개하는 내용들을 적어두었다. 지원자는 여러 팀들 중 자신과 맞을 것 같은 팀을 선택하여 지원하면 된다. ppt 양식에 자신이 어떤 일을 해왔고 어떤 강점이 있는지 기술하여 제출하면, 해당 팀에서 서류 -> 1차 면접 -> 2차 면접을 거치며 합격을 하는 과정이다. 기존 팀이 정말 어려운 상황이 아니라면 합격 후에는 이동을 제한할 수 없다.

 이 설명을 먼저 하는 이유는, 사실 나는 2번의 지원을 거쳐 마지막 지원에 현재 팀으로 이동을 했기 때문이다.

지원 과정

첫 번째 지원

 2019년도 성과 결과가 나온 후, 한 번의 이의 제기까지 진행했지만 받아들여지지 않았다. 당시에는 너무 분했고 여기서 얼마나 더 열심히 해야 더 나은 평가를 받을 수 있을지 모른다고 생각했다. 그리하여 바로 지원했다.

 다행히도 2019년도에 주어진 일도 내가 개인적으로 진행한 일도 많은 상태였어서 지원서에 기입할 내용은 많았다. 나는 시작이 자바 개발자가 아니었고 기초가 부족하다고 생각하기 때문에 자신감은 없었지만, 내가 한 업무들에 대해서 설명을 잘 하면 되는 사내 이동에 대해서는 그래도 가능성이 있지 않을지 싶었다.

 서류는 바로 통과했고 얼마 뒤 1차 면접이 잡혔다. 면접관으로는 지원 팀 리더 분과 팀원 한 분이었는데, 자기소개부터 내가 어떤 일을 해왔고 그 일을 하면서 어떤 개발적인 부분을 진행했는지에 대해 설명했다. 몇 가지 질문도 받았는데, 아직까지도 답변하지 못한 기억나는 질문은 "spring-cloud 제품군을 써봤나요?" 다. 그 당시에 이름만 들어본 수준이고 사용할 일이 전혀 없었다고 답변했던 것으로 기억한다.

 1차 면접이 끝나고 몇 주 뒤 합격 소식과 함께 2차 면접 일정이 잡혔다. 1차는 대면으로 진행했지만, 코로나 초기였으므로 2차는 zoom 으로 진행했다. 2차 면접에서는 현재 서비스 시스템 구성도를 A4 용지에 그리면서 설명했었고, 다른 기억은 없지만 굉장히 공격적인 내용을 내가 말했던게 아직도 기억이 난다. "서비스 개발자를 위해 기술 성장에 대한 시간을 보장해주어야 한다". 지금 생각해보면 상위 조직을 이끄는 입장에서는 말이 안되는 이야기다. 회사가 기술 스택의 성장을 위해, 왜곡해서 이야기하면 개인의 성장을 위해 희생해야 한다는 주장이나 마찬가지였다. 아직까지도 면접관으로 들어오신 분들을 기억하는데, 그 분들은 나를 기억하지 않았으면 좋겠다는 마음도 있다.

 2차는 떨어졌다. 외부에 말할 때는 BE 직군을 뽑다가 다음 달에 FE 직군을 뽑는 것으로 공고가 바뀌어서 떨어진 것 같다고 이야기 했고, 실제로 공고가 바뀌긴 했지만 사실 본질은 내 답변에 있었다고 생각한다. 어찌됐든 떨어졌고, 2020년은 흘러갔다.

두 번째 지원

 2020년 4분기에 단독 프로젝트를 맡았다가 엎어졌다. 지금 생각해보면 무슨 깡으로 그 많은 새로운 것들을 해보겠다고 나섰던 건지 모르겠지만, 당시에는 위에서도 이야기 했듯 "누군가 조언해 줄 사람이 있었으면 어땠을까?", 즉 브레이크를 잡아줄 누군가를 원했다.

 조직 이동 공고를 보면서 코멘트를 해줄, 브레이크를 잡아줄 사람이 많은 곳이 보였다. 해당 팀은 사내에서 기술 공유를 많이 하던 팀이었다. 처음 해당 공고를 봤을 때는 한창 단독 프로젝트도 진행하고 있던 시기기도 했고, "나 같은 사람을 뽑을까" 라는 생각으로 지원을 하지 않았다. 한 달이 지나고 프로젝트가 엎어진게 확실해진 후 안 되더라도 지원은 해보자는 마음으로 지원했다.

 이번에도 서류는 바로 통과했고 1차 면접에 들어갔다. 코로나 확산세가 잠시 줄어든 시점이었어서 운이 좋게 대면 면접으로 진행했다. (지난 2차에서 비대면으로 떨어졌기 때문에 대면을 더 선호했다.) 기억에 남는 질문은 분산 DB 설계 시 어떤 기준으로 분산을 할 것인가, github issue, pr 에서 sequence 가 같이 증가하는데 이걸 어떻게 설계할 것인가 였다. 다행히 당시의 팀에서 이미 하고 있던 것들이었기 때문에 그에 맞추어 답변을 했다. 답변을 못한 기억나는 질문으로는 java instrumentation 이 있다.

 다행히 2차 면접까지 가게 되었다. 그 사이 코로나가 다시 확산되어 불안하게도 비대면 면접을 진행했다. 이번에는 그 사이에 진행한 DB connection pool 관련한 내용을 이야기하고 질문을 받기도 했다. 기억으로는 굉장히 얼버무렸던 것 같은데 합격하여 현재 팀으로 왔다. 지나고보면 현재 팀이 DB 와 밀접하게 관련된 일을 하고 있어 가산점이 있었지 않았나 싶기도 하다.

합격과 이동 사이 기간

 지원은 2020년 11월, 최종 합격은 2021년 2월 중순이었고 이동은 5월 1일이었다. 원칙 상 현재 팀에서는 나의 지원 사실과 합격 여부를 모르기에 내가 직접 리더 분께 말씀드려야 하는 상황이었다. 당시 성과 평가까지 겹쳤던 시기라 말씀드리기 모호한 상태에다 비대면인 상황이었는데, 개인 성과 평가 결과가 나온 당일 출근하신 리더 분께 따로 이야기를 드렸다. 개인적으로 원한이나 이런건 없었기 때문에 말씀드리면서도 죄송스러운 마음이었다.

 팀 전체로 나의 이동 사실이 공유되었고 나는 진행하고 있던 업무의 마무리와 간단한 작업들을 진행하며 시간을 보냈다. 또한 이동할 팀에서 코틀린을 사용하게 될 것 같아 코틀린을 미리 공부해두었다. 그리고 개인적으로 벌여 놓은 작업들이 많아서 인수인계 할 필요성을 느꼈기 때문에, 3년 간 진행했던 업무들을 되짚어 보면서 팀 내부 위키 공간에 어떤 의도로 작업을 했는지에 대해 남겨두기도 했다. 아쉽지만 코로나 확산세가 잠잠해지지 않아 비대면으로 마지막 인사를 하고, 감사 메일을 보내고 나왔다.

1부 끝 - 잡담

• 너무 이전 조직에 대해 좋지 않게 이야기한 것 같지만 현재와는 다를 것이고, 이전 팀원 분들하고도 아직 잘 지내고 있다.
• 이미 본문에도 적긴 했지만 현재의 생각과는 다른 부분들이 있다.
• 추가로 2020년에 일을 안 한 것처럼 보일거 같은데.. 서비스에 대한 애정만 없던 것이지 일은 열심히 했다.
• 넷플릭스는 퇴사 시 부검 메일 (Postmortem email) 을 보내는 문화가 있다는데, 늦었지만 아마 이 글이 대신할 것 같다.

('개발자의 글쓰기' 에서 빠져나갈 구멍을 만들어두라고 한 내용이 있어서 남기는 것은 아니다)

다음 글 (2부) - 팀을 옮긴 후 2년 반을 돌아보기 (2) - 이동 후 처음으로 한 일