위메프 백엔드 개발 1년 회고

recordsbeat·2021년 8월 25일
29
post-thumbnail

서문

작년, 이 맘때 즘 면접에서 어버버하고 속으로 '망했다'라고 생각했던 찰나, 과제를 부여받아 며칠간 작성 후 제출하였다. 이후 합격 통보 메일을 받았는데 이는 내가 개발자라는 커리어를 통해 처음으로 도전하고 얻은 성과였다.

지금 와서 돌이켜보면 운이 엄청 좋아서 합격했다. 당시 면접이 끝나고 기억나는 질문과 그에 대한 답변을 하나씩 대조해보았을 때 내가 얼마나 헛소리를 많이 했는지 깨달았다. 가끔 면접을 참관하는 데 위와 비슷한 질문이 나온다. 아직도 이 질문에 속으로 대답을 못 하는 경우 매우 뜨끔하기도 하다. (게으른 탓)

과제도 마찬가지다. 당시에는 아무 고민 없이(혹은 모르고) 작성했던 코드가 코드리뷰 당시에 칭찬받기도 했다. 팀에 합류하고 나서 가끔 입사 지원자분들의 과제를 리뷰하였는데 이를 계기로 내 과제가 깊은 고민 없이 만들어졌단 걸 단 번에 알아차릴 수 있었다.

SI(는 아니었지만 비슷했던)회사, 스타트업을 지나 처음으로 규모 있는 그리고 체계가 잡힌 회사에서 일하게 되었다. 덕분에 이슈관리 툴, 깃 플로우 정책, 재택으로 인한 화상미팅과 메신저 협업 등등 소위말해 IT 회사에서 개발자가 할만 한 것들은 대부분 해봤다.

짧은 시간임에도 불구하고 기억에 남는 경험 몇 가지가 떠올라 해당 포스트와 함께 공유하고자 한다.

시도와 성장

스크럼과 회고 그리고 KPT

Agile 개발방법론을 취하는 조직은 모두 스크럼, 스프린트, 회고를 진행할 것이다. 우리도 마찬가지였다. 매일 아침에 가벼운 스크럼 시간을 갖는다. 이슈가 있거나 우선순위에 대한 변동이 생겨야 할 경우는 따로 회의를 진행했다. 스프린트는 2주 단위로 진행되었다. 2주가 지나면 스프린트 마지막 날에 회고를 진행하였고 이때 그간의 일감들과 이슈를 공유하였다.

스크럼 회고 동안 KPT(Keep - 유지할 것, Problem - 문제점, Try - 시도할 것) 에 관한 각자의 내용을 공유하였는데 개인적으로 이 시간이 꽤나 의미있었다. 사업부나 기획에서 몰려오는 요구사항들만 쳐내다 보면 프로젝트는 기형이 되어서 무너지기 마련이다. 소위 말하는 레거시화(?)가 진행되는 것이다. 그러나 우리는 기능구현에만 만족하지 않고 이 시간을 사용하여 아키텍처에 대한 고민을 시작하였다.

단편적인 예로 트랜잭션 스크립트에 국한되어있던 프로젝트를 도메인 모델링 방식으로 리팩토링하게 되었고 이를 토대로 MSA 전환에 대한 전략 등 많은 토론과 실행이 있었다. 글로만 알았던 도메인을 실제 프로젝트에서 정의하고 제한하며 한 발자국 클린 아키텍처에 가까워진 느낌이었다.

당연히 개발 일정에 의해 모든 주제가 토론으로 이어지거나 해소되지는 않았다. 그러나 이슈를 공론화함으로써 적어도 한 번쯤 아키텍처에 대한 고민한 것임에는 틀림없다.

스터디와 토론

입사한 지 얼마 안 되었을 때 그룹장님이 제안하였다. 주 1회마다 스터디 발표를 진행하자는 것이었다. 이는 정식 업무로 채택되었고 발표 준비를 위해 야근을 할 경우 추가 근무로 인정이 되었다. 약 10명이 두 팀으로 나뉘어 매주 1번씩 로테이션을 돌아가며 발표자료를 준비하였다. 개인으로 보면 한 달에 한 번 정도 스터디와 발표를 준비하는 식이었다. 처음에는 자바 개발자들의 필수 교양서와 같은 '이펙티브 자바'를 선정하여 스터디하고 공유하는 식이었다. 이후에는 개인 서적, 관심사 혹은 업무 간 발생했던 이슈와 해결책 등을 발표하기도 하였다.

실제로 이 시간은 스스로 쌓아왔던 Java 기술부채를 해소하는 데 큰 역할을 하였다. (예시로 필자 블로그의 Thread, GC 관련 글이 있다.) 스터디 한 내용을 팀원에게 전달하기 위해 내용을 일정 수준 이상 이해해야 했고 발표자료를 준비하는 중이나 심지어 발표하는 중에도 추가적인 궁금증이 생겨났다.

반대로 팀원들의 발표를 들을 때도 상당히 의미가 있었다. 물론 어려운 내용도 있었지만, 대부분의 발표는 어느정도 알아들을 수 있었다. 발표 이후에는 질문과 토론을 통해 내용 보충이 이루어졌고 이따금 현업에 적용될 수 있는지도 고민해보았다. 실제로 TDD에 관한 발표와 토론 이후 팀에서 TDD를 적용하기로 하였고 이를 통해 테스트 코드에 대한 전반적인 개념 그리고 TDD의 의미를 구체적으로 이해할 수 있었다.

고무적이었던 것은 누구도 대충하지 않았다. (사실 내가 제일 대충한 것 같아 죄스러운 마음이 크다.) 과장해서 이야기하자면 공짜로 지식을 얻어먹었다. 이 때문에 팀원의 발표 주제에 영감을 받아 스터디 주제를 정하는가 하면 겹치지 않는 주제를 고르려고 애쓰기도 하였다.

블로그 운영 간 기계적으로 타 블로그와 중복되는 내용을 써놓게 된다거나 할당량 채우듯 글을 기고하게 되는 것을 경계하였다. 그 와중 팀 스터디는 순수 지식의 습득과 전달을 위한 '진짜 공부'가 되었다. 나는 '진짜 공부'를 시작하게 된 것이 위메프에서 얻은 가장 큰 산물이라 생각한다.

시너지란

모르면 용감하다 했던가. 팀에 합류한 지 얼마 되지 않았을 때 프로젝트 코드를 보고 실망했었다. 최신 라이브러리를 사용한 코드, 높은 수준의 추상화, 다형성을 띤 메소드와 클래스 등 온갖 상속과 제네릭 코드가 난무하는, 소위 '있어 보이는 코드'를 기대했던 탓이다.

이 실망감은 역시 얼마 가지 않아 사라졌다. 물론 라이브러리의 최신화, 추상화, 다형성 등 모두 중요하지만 우리는 이것 외에도 신경 써야 할게 너무 많다. 프로젝트 관점에서 바라보면 인프라, 성능, 아키텍처 등 먼저 고려해야 할 것들이 있었고 이는 단순히 소스 코드를 잘 짠다고 해서 해결되는 문제가 아니었다. 또한 다수의 인원이 동시에 개발하는 프로젝트에서 최소한의 컨벤션 이상을 강제를 하게 될 경우 코드 리뷰나 일정에 대한 비용 역시 무시 못 할 것이었다. 당시 나는 단일 DB, 단일 서버 애플리케이션 개발만 하다 왔었기에 이와 같은 시야를 갖지 못했다. 그러나 이를 계기로 개발이란 것은 관점에 따라 여러 가지 형태로 나타난다는 점을 깨달았다.

경력 좀 있던 A 팀원분은 장애처리와 디버깅에 굉장히 능하였다. 장애가 발생하면 APM 내지 로그를 확인하여 빠르게 에러 내용을 파악하였다. 이후에는 원인을 찾아내어 담당 개발분에 공유하였는데 이 과정이 놀라울 정도로 빨랐다.

또 다른 B 팀원분은 굉장히 섬세하게 아키텍처 구성, 데이터 모델을 정의하였다. 가끔 페어 프로그래밍을 하다 보면 생기는 고민거리들이 있었는데 기존에 어렴풋이 알던 개념을 현업에 맞게 구체적인 예시를 들어 주는 경우가 많았다. 한 예를 들자면 도메인 드리븐 모델링 리팩토링을 진행할 때였다. 당시 도메인이라는 개념에 대해 모두가 익숙지 않았던 상황이라 모델을 정의하기 어려운 상황이었는데, B 팀원분이 며칠간 계속해 자료조사와 예시를 찾아서 제시하였고 이를 통해 적합한 도메인 모델과 레이어 통신 아키텍처를 구성하게 되었다. 해당 프로젝트는 내가 제안했음에도 불구하고 B 팀원분이 주도적으로 결과물을 만들어낸 것이었다.

그 외 C 팀원 분은 대용량 처리 간 벤치마킹과 자원 모니터링에 굉장히 능하였고 또 다른 팀원 D 분은 지속해서 개발 프로세스와 팀 문화에 대한 방향을 제시하며 얘기만 듣던 것들을 실제로 도입하게 되었다. (KPT나 페어 프로그래밍, TDD 등이 그 예시다.)

농구처럼 개발팀에도 스윙맨 (포지션을 자유자재로 바꿔가며 슈퍼플레이를 보여주는 선수) 이 존재할 수 있다. 다만, 현실에서 스윙맨은 굉장히 드물기도 하고 존재한다고 하여도 물리적으로 한 두 사람이 전반적인 개발 프로세스를 이끌어가기는 힘들다.
반대로 조직의 관점으로 팀을 바라보면 이야기가 달라진다. 내가 몸 담던 팀의 인원들은 고유하게 보여줄 수 있는 능력과 관심사를 가지고 있었다. 이는 개개인의 개발 관점을 보완해주는 주춧돌이 되었고, 프로젝트를 넘어 팀 개발 프로세스에 전반적인 시너지를 일으키는 장치가 되었다.

마무리

사실 이 포스트가 공개될 즘이면 위메프에서 퇴사일을 확정 지었을 것이다. 위메프에서 1년이란 시간은 짧은 경력의 잦은 이직 중에서 노다지를 만난 것처럼 큰 양분이 되는 순간이었다.

장점만 늘어놓은 글이 되어 팀을 홍보(?)하는 것처럼 보일 수도 있겠지만, 어느 대기업 IT팀과 견주어도 손색이 없을 정도로 큰 시너지를 보여주는 조직이라고 자부한다.

필자의 케이스처럼 주니어 레벨(혹은 중고신입)이 성장하기에 더할 나위 없이 좋은 근무 환경이었으며 어떠한 이슈라라도 거리낌 없이 공유하고 토론할 수 있는 자리였다. 실제로 근 1년간의 포스트들을 보면 모두 위메프 현업 간 일어난 일을 바탕으로 쓰인 것들이다.

이 모든 것은 나의 성장에 탄탄한 디딤돌이 되었고, 좋은 기회를 통해 N 사로 이직하게 되었다. 짧은 기간 동안 나의 성장에 기여해준 그룹장님과 팀원분들에게 무한한 감사의 말을 남기며 포스트를 마친다.

profile
Beyond the same routine

5개의 댓글

comment-user-thumbnail
2021년 8월 31일

이직 축하해요~~

1개의 답글
comment-user-thumbnail
2021년 9월 4일

멋진 글 감사합니다. 코드 뿐만 아니라 기획과 업무 프로세스에 대한 깊은 이해가 필요하겠군요. 저에겐 아직 엄두도 안나는 영역이지만 1인분을 해낸다는 것이 결코 만만하지 않다는 것을 알게되는 것 같습니다. 이직 축하드려요 :)

1개의 답글
comment-user-thumbnail
2022년 6월 26일

위메프 개발 포지션 컬처핏에 대해 궁금했는데 많은 것들을 보고 갑니다. 좋은글 감사합니다!

답글 달기