7년차에 접어든 현재와 미래

 2024년 3월이 되면서 만 6년이 지나고 7년차가 되었다. 또한 5월에 접어들면서 현 팀으로 이동한 지도 만 3년이 되었다. 이전 글에 이어지는 제목을 지어볼까 했으나 조금 더 큰 범위의 글로 남겨두는게 좋을 것 같아서 제목을 다르게 지었다. 내용은 이어지게 시작하면서, 현재 가지고 있는 생각에 대해 남겨보면서 마치려고 한다.

파트 이동

 2022년 중반, 정산 프로젝트를 마무리하는 과정에서 할 일이 마땅치 않았던 시기가 있었다. 일하면서 배운게 많았다는 생각을 갖고 있기도 하고, 과거 타노스를 경험한 시기 (2년차 회고 글 - 2년차 시작 부분) 에서 실제로 일이 없었던 적이 있었던 나로서는 이 상황이 약간 힘든 시기였다. 또 '정산에 갇혀 있다' 는 생각도 일부 있었고, 다른 도메인들에 대해서도 뻗어 나가고 싶었다. 그래서 이 시기에 바로 해야할 일이 보였던 옆 파트에 가고 싶다는 이야기를 리더 분께 드리기도 했었다. 우여곡절 끝에 3개월 뒤 주문 시스템 중 일부를 담당하는 새로운 파트가 만들어지며 나도 그 파트로 이동했다.

 신설된 파트 구성원들은 전부 비슷한 연차였는데 나는 파트 리더 분의 다음 연차의 팀원이었다. 이 시기에 했던 고민이 나와 비슷한 연차에 벌써 리딩, 매니징을 하고 있는 분들이 생기기도, 이미 계시기도 했어서 '나도 그런 역할을 수행해야 하는가?' 에 대한 것이었다. 아마 그 당시 눈치를 채셨을지도 모르지만, 그 영향으로 파트 구성 초기에 평소와 다르게 나름 적극적으로 여러 의견을 내기도 했었다. 후술할 내용이지만 현재는 이와 같은 고민을 접고 다른 방향으로 나아가기로 했다.

파트 이동 후 한 일

1) 주문 이벤트 발행 시스템 재설계

 공개된 자료에서 확인할 수 있어서 대체한다. (https://d2.naver.com/helloworld/9581727)

2) Write operation 들을 단일 DB -> 분산 DB 로의 전환

 현 팀의 목표는 단일 DB 를 의존하고 있는 서비스를 분산 DB 로 이관하는 것인데, 큰 단위의 작업들은 이미 완료되거나 진행되고 있는 상태였다. 하지만 어느 범위로 묶을 수 없는 작은 단위의 Write operation, 즉, 쓰기 기능들이 있었다. 우리 파트는 이와 같은 기능들을 찾아내고 그것들을 새로운 코드 베이스로 해당 기능을 이관하는 과정에서, 코드 자체의 개선 및 분산 DB 를 이용하도록 하는 작업을 진행했다.

 http api, batch, consumer 등 다양한 기능들을 작업하면서 현재 구성되어 있는 주문 도메인을 더 파악할 수 있었다. 개인적으로 만족하는 건 바로 이 부분이다. 정산 작업을 할 때는 단일 레포에서 벗어나지 못하는 상황이었지만 지금에 와서는 여러 레포들을 참고하고, 파악하고, 관여하며, 조금 더 큰 범위에서 이 시스템을 알아가고 기여를 할 수 있다는 생각이 들며 자신감이 더 생겼다. (정산 시기에는 코로나 비대면 + 이동 초기로 인한 소극적인 의견 피력도 영향이 있었다.)

3) 오픈소스 기여, 라이브러리 개발, 사내 발표 등

 정산을 거쳐 현 파트에 오면서까지 가장 좋았던 경험은 오픈소스에 기여하는 경험이다. 학교를 다닐 때만 해도 회사 생활을 하면 오픈소스를 실무에 적용해보면서 잘못되거나 필요한 부분을 직접 기여할 수 있을 것으로 기대했다. 하지만 막 입사를 하고 나서 마주친 현실은, 기여는 꿈도 꿀 수 없고 마이너 버전조차 쉽게 올릴 수 없는 상황이었다.
 첫 시작은 정산이었다. 당시 spring-kafka 를 전혀 모르는 상태로 작업을 들어갔는데, 일부 필요한 부분만 검색하는 것은 너무 한계가 있는 접근으로 느꼈다. 그래서 공식 문서를 처음부터 끝까지 읽기 시작했고 그 과정에서 발견한 오탈자를 수정하는 것부터 시작했다. 이후 spring-data-jdbc, spring-cloud-stream 등의 문서들도 필요한 부분들을 읽으며 수정했고, 현재는 여러 문서 오탈자 수정들을 넘어 사내에서 공개한 오픈소스도 관리하는 경험도 하고 있다.

 현 팀에서 관리하는 사내외 라이브러리가 있다. spring 등 유명한 라이브러리들을 사용하면서 나는 내부 코드를 보는 것을 좋아하고 거기서 차용해온 방식들도 있었는데, 이 과정에서 든 대한 생각은 '사용자의 사용성을 고려하면서 코드 스타일을 맞추고 버그를 최소화하는 완벽한 상태를 어떻게 만들었고 보장할까?' 였다. 마침 사내 라이브러리를 담당하시는 분이 비슷한 연차이기도 하고 혼자 유지보수를 진행하고 계셔서, 올려주시는 PR 등에 리액션을 누르며 관심을 표했다. 코로나 시국이 조금씩 완화되면서 오프라인에서 만날 기회가 생겨 조심스럽게 참여 의견을 드렸고, 작은 범위부터 진행을 시작했다. 다행히 이슈가 없이 현재까지 잘 흘러와서 현재는 공개된 라이브러리에 신규 기능을 추가하는 단계까지 진행되었고, 이 과정에서 라이브러리 레벨에서의 테스트와 문서의 중요성도 한 번 더 생각하게 되었다.

 마지막으로는 곧 사내 발표를 앞두고 있다. 대면은 아닌 온라인 영상을 통한 공유이고 주제는 팀 이동 후 경험한 'kafka consumer 애플리케이션에서의 재시도 전략과 기타 팁들' 이다 (정확한 제목은 아니다). 이전에 워크샵에서 팀 내 공유를 해보았고, 상위 조직으로 온라인 공유를 거쳐 이제는 사내 전체까지 대상이 확대되었는데, 비록 내용이 거창하진 않지만 입사 초와 팀 이동 초의 자신이 없던 내 마음가짐을 되돌아보면 감회가 새롭다.

현재 나의 생각, 그리고 미래

 앞서 언급했던 '리딩, 매니징 역할을 수행해야 하는가?' 라는 고민에 대해서는 현재 '그러한 역할을 지금은 할 수 없다' 는 생각을 가지고 있다. 한계를 정해놓고 생각한다는 지적이 있을 수도 있지만, 이미 잘 하고 계시는 분들을 보면 그 정도까지는 불가능하다는 생각이 있기 때문이다. 애초에 고민을 했던 이유도 '비슷한 연차에 그런 역할을 잘 수행하고 있는 사람들이 있다' 인데, 사실 더 크게 보면 나보다 더 많은 경험을 하신 분들도 아직 실무자로 계신 분들이 많다.

 그렇다면 이 팀과 주변 사람들 사이에서 나는 어떤 역할을 맡아야 할까? 지금 나의 결론은 개발 외적인 측면에서는 잘 이끌어 나갈 수 있게 보조하고, 개발 측면에서는 이끄는 역할을 하는 것이다. 리딩, 매니징을 역할을 하시는 모습을 보면, 지금의 나는 큰 범위에서 연관지어서 생각하고 일을 진행하도록 관리하는 역할을 하진 못할 것 같다. 하지만 큰 그림을 보다 보면 일부 놓치는 부분이 발견될 수 있는데 그런 부분을 찾아내고 의견을 내는 것이 현재 내 역할이라고 생각한다.
 여태까지 나는 내가 못한다, 운이 좋아서 들어왔다는 생각을 가지고 있었다. 여러 업무들을 진행하고 다양한 책들을 읽으면서 이제는 어느 정도 경험은 있고 도움이 될 수 있다는 생각으로 바뀌었다. 이제 나도 적은 연차라고 볼 수도 없고 그만큼의 경험이 있으므로, (아니라고 생각하실 수도 있지만) 어느 정도 의견에 힘이 들어가고 다른 구성원 분들이 존중해준다는 느낌도 들고 있다. 내가 경험한 부분에 대해, 그리고 경험을 기반으로 의견을 제시하면 나름 수용이 되고 있다. 조금 더 양질의 코멘트를 할 수 있도록 노력하는 것이 지금으로써는 최선이다.
 더 선배인 분께서 한마디 씩 힌트를 주시거나 빈틈을 이야기하시면 아! 하는 경험도 많이 있었는데 나도 그러한 역할을 하는 사람이 될 수 있어야 겠다는 생각을 천천히 하고 있다. 어떤 분과 이야기하면서 '큰 줄기가 있는 개발자' 에 대해 이야기를 했었는데, 흔들리지 않고 '왜, 어떻게' 를 모두 명확하게 답을 제시할 수 있으면서 이끌어 갈 수 있는 사람을 지향하고 싶다.

 나는 내가 하는 일이 회사의 매출에 일정 부분 기여하는 드러나는 일을 하는 것이 좋은 것 같다. 그리고 최종 사용자와 만날 기회가 없는 시스템보다는 그 반대를 더 선호한다. 그렇다면 이 다음으로 매출이 있는 서비스 조직을 찾아보아야 하는데, 조직 이동 후 3년 간 신규 기능을 출시해보는 경험을 하지는 않았으므로 '신규 기능에 대해 사업/개발 측면 모두를 만족시키면서 잘 개발할 수 있을까?' 에 대한 약간의 걱정이 있다. 추가로 현 회사에서의 서비스 조직은 내가 경험한 바로는 개발적인 부분을 많이 포기해야 하므로, (가능할지도 모르는 일이지만) 내부 이동이 맞는 선택일까에 대한 생각도 있다. 그렇다고 해서 이직을 생각하기에는 알고리즘이 너무 취약하므로 불가능하다 (앞서 운이 좋아서 들어왔다는 생각이 이 부분이다). 바로 앞의 미래에 대해서는 크게 생각해본 적이 없지만, 당장은 현 팀에서 굉장히 만족하고 있는 상황이므로 지금은 더 오래 있고 싶다.

 더 먼 미래에는 리더를 할 수도 있을 것이다. 주변에는 비슷한 연차에 벌써 리더를 원하여 외모와 같은 외적인 부분에서부터 시작하여 관련 서적을 읽으며 내적인 부분까지 준비하는 분도 계신다. 여태까지 '운, 기회가 주어질 때 준비가 되어 있는 사람이어야 한다', '최소한 자격으로 떨어지진 않아야 한다' 는 마음가짐으로 미리 준비하는 자세로 임했는데, 그렇게 생각한다면 지금부터 관련 서적을 읽으며 준비를 하는게 맞을 것이다. 사실 연봉의 측면을 생각하면 준비하는게 맞다는 생각이 있긴 하지만, 지금은 개발 지식을 더 갖추는게 우선이라고 생각한다. 내 주변 연령대의 개발자는 선배 개발자들보다 많으므로, 나보다 뛰어난 리더 역할을 수행할 사람들은 더 많을 것이다. 물론 개발자들도 그만큼 많겠지만, 현재 크게 뒤쳐지지 않는 상황에서 굳이 미지의 리딩 역할을 먼저 계발할 필요가 있을까에 대한 생각이 있다.

 미루고 미루다보니 팀 이동 마지막 회고를 5월에 쓰는 일이 펼쳐졌는데, 쓰고 보니 생각도 정리하고 미래도 고민해보는 겸으로 시기가 중요하진 않은 것 같다. 여태까지의 회고에서는 지금과 같이 역할, 위치에 대해 고민한 내용이 없어서 이번이 유독 마지막 부분이 더 길었던 것 같다. 올해 말, 내년의 내 생각은 어떻게 될지 궁금해진다.