2020년 회고록

들어가며

어느덧 2020년도 굉장히 빠른 속도로 끝이 났다. 2020년을 한마디로 정의하기 참으로 어려울 것 같지만, 아마도 『중니어의 고민』 이라는 말로는 어느 정도 설명할 수 있을 것 같다. 중니어는 진 “the 유르마무” 유림님께 먼저 들은 단어인데 주니어도 아니지만, mid level 개발자도 아닌 어정쩡한 상태의 개발자를 가리키는 말이라고 한다.

멘탈이 나가버릴 때도 많았지만, 팀장인 그분2에게 볶음을 당하며 조금씩 앞으로 나아갔던 것 같다. 볶일 때는 몰랐지만, 돌이켜보니 볶는 내용이 작년에 비해 확실히 달라진 부분이 있었다. 아마 위에도 쓰여 있는 중니어 정도 위치에 있는 팀원을 위한 배려였을 거라 생각한다.

그렇기 때문에, 이 회고는 아마도 올해 진행한 프로젝트에 대한 회고와 중니어의 고민이 주된 내용을 차지할 것 같다. 혹시라도 비슷한 고민을 하고 계시는 분이 있다면 주저 말고 고민을 나누었으면 좋겠다. 어느 대신관이 이야기했듯 함께라면 우리는 강하기 때문이다.

1. 올해 진행했던 프로젝트들

• GraphQL

  올해 진행했던 프로젝트 중 제법 큰 비중을 차지하고 있는 프로젝트이다. 다른 회사에서 cloud API혹은 front API server 등등 여러 이름으로 불리는, API를 생산하는 쪽과 사용하는 쪽의 입장차이를 완화시킬 수 있는 일종의 완충지대 역할을 기대하며 도입했다. GraphQL 도입 과정은 별도 글에 정리해 두었다.

  GraphQL server를 통해 토이프로젝트가 아닌 실제 production level의 백엔드 서버를 배포하고 운영하는 경험(metric 분석, 성능 개선 등)을 쌓고 있으며, infra 문제 해결을 위해 k8s도 어느 정도 들여다볼 수 있었다. 같이 일했던 파트너 덕분에 좋은 개발 습관이나 다르게 생각하는 법을 배울 수 있던 것도 큰 수확이다.

  무엇보다 bottom-up으로 진행하는 일이 실제로 서비스의 일부가 되어 배포할 수 있을 때까지 무엇을 고민해야 하고 stakeholder들을 어떻게 설득해야 하는지 배울 수 있어 기억에 남는다. 지금 와서 생각해보면 잘 설득하지는 못했던 것 같아 아쉬운 부분이 있다.

• odc-frontend refactoring

  나름 대규모의 코드 변경이 있었는데, GraphQL client를 적용하면서 거의 모든 페이지를 대상으로 refactoring을 진행했다.

  GraphQL client

  우선은 오랜 염원이었던 API의 model, response 타입을 auto generation 하여 strict 하게 타입 체크를 할 수 있게 되었다. graphql-codegen을 이용하니 간단하게 적용할 수 있었다. 더는 model과 API response의 타입을 수동으로 관리할 필요가 없어졌고, 이 말은 API server와 client 간의 model 타입 불일치를 막을 수 있게 되었다는 뜻이다.

  그다음은 GraphQL server와 소통을 담당할 client library를 선정했다. 사실 relay.js를 적용하고 싶었으나 그분2가 반대 의사를 표시했다. 코드 수정량이 많아지고 팀원들이 relay.js 자체를 학습하는 비용이 클 것 같다는 판단이 있어서였다. 그래서 결국 apollo client를 사용하게 되었으며, 자연스럽게 odc-frontend에는 apollo client에서 제공하는 client cache가 적용되었다. 적용하기까지 우여곡절이 있었으나 운영팀에서 성능에 대해 만족하고 있어 다행이라고 생각한다. 다만 2021년 Q1에 진행할 프로젝트에는 relay.js를 사용할 생각이다(이에 대해서는 따로 포스팅할 예정이다).

  Apollo client까지 붙이고 보니, 자연스럽게 그 존재의 의미가 애매했던 redux가 제거되었다. Redux는 과거에 일이 없어서 일을 만들기 위해 적용한 라이브러리였는데, 결자해지 할 수 있어서 속이 엄청 후련했다. 다시는 이런 바보 같은 이유로 일을 하지 말아야겠다고 생각하는 좋은 계기가 되었다.

  Refactoring 과정에서 얻은 교훈

  GraphQL client를 적용하며 함께 진행했던 refactoring을 통해 얻게 된 교훈도 있다.

  1. Context는 사라지고 코드만 남는다.

     우아한 테크 러닝을 듣다가 김민태님으로부터 듣게 된 말이다. 지금도 상당히 좋아하는 말이기도 하다. 이번 refactoring을 진행하면서 일관적이지 않은 설계/코드를 비롯해 이른바 숨은 로직 때문에 많은 고통을 받았다. 분명히 같은 기능인데 전혀 다른 구조로 짜여있다던지, 쓸모없는 방어 코드, 직관적이지 않은 default 값 등등 많은 지뢰가 있었다. 당연히 refactoring을 진행하시는 분들은 이 코드의 문맥(context)을 알기 위해 많은 문서와 slack 대화를 찾아다녀야 했으며, 이런 노력에도 불구하고 몇 개의 지뢰를 밟을 수 밖에 없었다.

  2. 작업 내용을 jira ticket에 꼼꼼히 기록하는 것이 좋다.

     위에 써놓은 문맥을 파악하는 과정에서 얻은 교훈이다. Commit message에는 어떠한 티켓을 처리한 내용인지 티켓 번호는 남아있으나, 정작 그 티켓을 찾으니 내용이 너무나 부실하여 끝내 코드의 존재 이유를 밝혀내지 못한 케이스도 있었다. “프로그램의 리스트를 구현한다”가 뭐야

  3. UI를 테스트하는 자동화된 도구가 어느 정도는 필요하다.

     Component에 필요한 GraphQL query를 작성할 때 필요한 field를 빠트리는 일이 종종 있었다. 이 빠트린 값들은 component의 훌륭한 방어 코드와 환상의 하모니를 이루어 버그를 드러내지 않았다. 이런 버그들을 운영팀의 제보로 hotfix를 진행했던 일이 두어 번 정도 있었다. 한때 component에 대한 unit test는 UI 혹은 기획이 자주 바뀌기 때문에 무의미한 일이라고 생각할 때가 있었다. 하지만 이번 작업을 통해 적절한 수준의 자동화된 unit test가 필요하다는 교훈을 얻게 되었다.

• ODK frontend server

  그분2의 아이디어로 시작한 프로젝트이다. 7년짜리 legacy(하지만 돈을 잘 벌고 있는) 서비스를 어떻게 점진적으로 개선해 나갈 수 있는지 볼 수 있었다. 마치 시니어는 이런 존재다라고 말하는 듯한 일 처리 방식이었다. 나는 하지 못했던, 주변을 설득하고 현재 상태에 맞는 적당한 솔루션을 찾아 테스트하고 같이 일할 동료들에게 전파하는 등 일이 되게 만드는 것이 무엇인지 옆에서 잘 볼 수 있었다. 물론 ‘일이 되게 만드는’ 동안 그분2는 굉장히 고통스러워하셨지만.

  

  작게 살펴보면, 동료들과 작업하면서 접근성과 semantic web에 대해 많은 리뷰를 주고받을 수 있어서 의미가 있었다. 해당 분야가 범위가 방대하기도 하거니와 정답이 없고, 두 요소를 신경 쓰지 않더라도 일단은 동작하기 때문에 소홀히 생각하기 쉬운 부분이라고 생각한다. 그래서 이 프로젝트를 통해 주고받은 접근성과 semantic web에 대한 리뷰들이 더 값지게 느껴지는 것 같다.

  다만 릴리즈할 때를 제외하고는 크게 기여하지 못해 아쉬운 프로젝트이기도 하다. 하지만 2021년에는 굉장히 활발히 진행될 것만 같아 그때는 열심히 기여해 보아야겠다. 이 프로젝트가 ondemandkorea를 어떠한 아이디어를 통해 어떻게 개선하고 있는지 그분2께서 손수 여기에 잘 정리해 놓으셨다.

• yoshi, waluigi

  연초 팀에서 필요한 부분을 채우기 위해 두 개의 프로젝트를 진행했다. 하나의 프로젝트는 방치되고 있어 2021년에 강력하게 드라이브를 걸어볼 생각이고, 하나의 프로젝트는 잘 사용하고 있다.

  yoshi

  Cypress로 구축한 e2e test tool을 github actions와 연동하여 주기적으로 자동화된 테스트를 실행할 수 있게 만들어 놓은 프로젝트이다. 현재의 업무 프로세스에서는, 개발팀이 빠르게 개발을 끝냈다 하더라도 QA팀의 일정에 맞춰 배포 시점이 결정되어 continuous delivery가 쉽지 않은 부분이 있었다. 그래서 sanity test 정도를 자동화해놓으면 QA팀은 테스트가 자동화된 만큼 시간을 더 쓸 수 있으니 배포 일정을 빠르게 가져갈 수 있지 않을까… 라는 그분2의 생각이 있어 진행한 프로젝트이다(C사에서 비슷한 걸 만들어보셨다고 한다).

  

  동작 자체는 의도한 대로 문제없이 되고 있으나, ODK frontend server 이후 commit 없이 방치되고 있어 안타깝다. 컨셉은 좋았기 때문에 2021년에는 좀 더 강력하게 해당 프로젝트를 추진해볼 생각이다.

  waluigi

  와루이지, 왈루기, 출근 알람기, 리뷰 독촉기 등 여러 가지 이름으로 불리고 있는 프로젝트이다. 이 프로젝트를 진행하면서 github api v4를 통해 작업하였고, 스스로가 GraphQL에 대한 확신을 갖게 되는 side effect도 있었다.

  기능은 매우 간단해서 오전 10시, 오후 4시에 pull request 별로 리뷰어에게 멘션을 걸어 팀 채널에 webhook을 보내는 것이다. 지정한 리뷰어가 리뷰를 모두 마쳤거나, merge 가능한 상태가 되면 pull request 작성자에게 멘션을 걸어준다. Google calendar와 연동해서 특정 키워드를 넣고 휴가를 가면 그 팀원에게는 멘션을 보내지 않는 소소한 기능도 있다.

  

  가끔 팀원들이 티켓을 만들어 기능 업데이트를 요청하는 경우도 있었는데 덕분에 각 프로젝트가 진행되는 방식을 간접적으로 알 수 있는 부분도 재미있었다.

• Payment feature

  연초부터 백엔드팀의 제권님과 범준님께서는 기존에 있던 결제 프로세스를 크게 개선하고 싶어 하셨다. 앞으로 늘어나게 될 서비스와 pg사에 대한 준비와 유연한 결제 모델이 필요했기 때문이다. 그렇게 시작된 ODX payment system을 구축하는 프로젝트팀의 일원으로 참여하였다.

  결론부터 말하자면, 원래 목표의 50%밖에 달성하지 못했다. 서비스 릴리즈 일정이 2021년 3월에서 2021년 Q3로 밀린 까닭도 있었지만, 결정적인 이유는 개발팀이 마감 일정에 맞출 수 있다는 보장이 없었기 때문이라고 생각한다. 개발팀이 일정을 지킬 수 없었던 이유는 수많은 요인이 얽혀있어 무엇 문제라고 꼬집을 수는 없다. 다만 내가 생각하는 이유는 소통이다.

  Client에 기능을 붙일수록 기획, API, 디자인이 안맞는 부분이 생긴다는 느낌을 받았다. 우리 팀의 특성상 기획, API, 디자인을 모아 제품을 만들기 때문에 이런 상황을 더 잘 보았을 수도 있다고 생각한다. 이런 상황에 대해 프로젝트 주간 회의 때 흥분하여 발언한 적도 있었는데 정말 후회하고 있는 일 중 하나이다. 언젠가 프로젝트를, 혹은 팀을 리드하게 될 때를 위해서라도 반드시 고쳐야 하는 성격이라고 생각한다.

2. 올해는 어떻게 일했을까?

• 나는 어떠했는가

  1. 굉장히 주관적인 통계

  

  글을 쓰고 있는 12월 29일 기준, 1년간 858 commit, 하루 평균 2.36 commit을 했다. Commit 단위의 명확한 기준이 없고 그 숫자가 프로젝트에 기여한 정도를 나타내지는 않기 때문에, 이 숫자는 의미가 없을 수도 있다고 생각한다(놀지는 않았네? 정도로 생각하고 있다). 그럼에도, 7개의 회사 프로젝트에 기여 했기 때문에 그것을 위안으로 삼고 있다.

  개인 프로젝트는 생각보다 많이 기여하지 못했다. Rescue time bot, github report bot을 비롯해 개인 블로그도 만족스러운 commit 수는 아니다.

  2. 칸반과 스크럼 - 무엇을 느꼈는가

  8월 즈음에 동료인 병대님의 도움으로 팀 전체가 칸반과 스크럼반, 스크럼을 경험해 보았다. 물론 매뉴얼대로 100% 완벽하게 시도한 것은 아니었고 일부 룰은 팀의 상황에 맞게 바꾸었지만, 오히려 그것이 훨씬 좋은 결정이었다고 생각한다. 이 세 가지 프로세스를 경험하며 얻은 것들이 몇 가지 있다. 팀의 규칙과 내가 혼자서 지키는 자신의 규칙 정도 일 것 같다.

  일단 팀에서는 상황에 맞게 프로세스를 적용하기로 했다. 상황에 따른 프로세스는 다음과 같다.

  프로젝트 상태	프로세스	다른팀의 관여
  PoC를 위한 bottom-up 개발	스크럼	없음
  PoC 종료 후 도입논의	스크럼반	스펙, 일정
  도입 후 운영	칸반	릴리즈 관리

  팀의 룰과는 별개로, 내가 스스로 정한 규칙은 바로 작업 전 일정추산과 추산한 일정을 지키는 것이었다. 그러기 위해서 몇 가지 룰과 간단한 도구 하나를 사용했다.

  1. 릴리즈 일정을 정할 때는 테스트, QA 과정에서의 버그를 수정하는 시간도 필요하기 때문에 20% 정도의 buffer를 잡는다. 만약 buffer로 잡은 시간이 남는다면 코드의 퀄리티를 개선한다.
  2. 그 외 개별 티켓은 buffer 없이 일정을 잡는다.
  3. 티켓을 진행할 때 timer를 이용해 작업 시간을 측정한다. 측정한 시간이 오차가 날 수도 있으며, 이를 바탕으로 다음번 비슷한 티켓의 일정을 추산할 때 오차를 줄여나간다.
  4. 티켓 진행 전이나 진행 중에 티켓의 내용이 크다는 것을 느끼면 그 즉시 티켓의 작업을 세분화한다.

  Rough 한 룰이지만 지키기 위해 노력했고 일정 추산에 대한 오차를 조금씩 수정할 수 있게 되었다. 나중에는 PM들과 협의하기가 한결 쉬워졌고, 일정을 협의할 때 API가 늦거나 하는 변수를 고려해 예측한 일정을 말할 수 있었다.

  하나 더 느낀 점은 일정 추산에 대한 연습은 결코 경험으로 얻어질 수 없다는 것이다. 일정 추산에 대한 연습은 주니어, 시니어를 막론하고 다분히 의도적인 수련을 해야 얻을 수 있는 능력인 것 같다. 그렇기 때문에 앞으로도 일정 추산에 대한 연습은 반드시 이어나갈 예정이다.

  참고로 해당 프로세스에 대한 경험은 팀 동료인 김지훈님(a.k.a. Professor K)님의 블로그에 잘 정리되어있다.

  3. 이제는 번아웃 극복 방법을 찾아야 한다

  이번 해에도 어김없이 찾아온 번아웃을 극복하거나 막을 방법을 찾아야한다고 느꼈다. (사실 회사의 사정인지 내 잘못인지 모르겠지만) 일을 할 때 엄청나게 몰아쳐서 한 다음 지치는 패턴이 반복되었던 것 같고, 이를 바꿀 방법을 고민하기 시작했다. 물론 감정 제어의 중요성도 깨닫게 되었다.

  팀의 인원이 적은 편은 아니지만, 그렇다고 많은 편도 아니어서 프로젝트가 한창 바쁠 때는 한두 명만 빠져도 바로 차이가 드러나는 것을 경험했다. 내가 그런 상황을 만든 적이 몇 번이 있었고, 그럴 때마다 같이 일하는 동료들이 그만큼의 일을 더 해야 했기 때문에 다시는 그런 상황을 만들고 싶지 않다. 더 정확히, 책임감 없는 사람으로 보이기 싫다는 마음이 강하게 들었다.

  그분2가 취미를 가져보라고, 개발 이외의 활동을 해보는 게 어떻겠냐고 제안을 주시기도 했다. 음악 같은 것을 말씀하셨는데, 어린 시절의 기억 때문에 악기를 다루기가 힘들 것 같다. 그래서 최근에는 인문학, 철학과 관련한 책을 읽고 있다.

• 동료들과는 어떻게 지냈는가

  올해는 나만 잘하는 것이 아닌, 동료들과 함께 자라는것에도 관심을 기울였다. 동료들의 개인적인 사정에도 일정 부분 이해하고 공감하려고 노력을 했으며, 때로는 동료가 겪고 있는 문제를 그분2를 통해 해결하기 위해 노력했다.

  최근에는 한 동료의 요청으로 2주마다 한 번씩 주기적인 1 on 1 인터뷰를 진행하고 있다. 2달 정도 진행하였는데 생각보다 동료의 만족도가 높아서 당분간 계속 진행할 생각이다. 특히 적당히 볶아주셔서 감사합니다라는 피드백을 받았을 때 그동안의 피드백과 같이 정했던 action item이 헛되지 않았다는 생각이 들어서 안심했다.

  일을 진행할 때는 동료들에게 적절하면서도 좋은 경험을 해볼 수 있는 태스크를 만들어주기 위한 시도를 했다. 혼자서 일정 시간 노력을 기울이면 해결할 수 있으면서도 포기할 정도로 어려운 일은 주지 않기 위해 신경을 썼는데, 이 일만 하더라도 상당히 어려운 일이었다.

  특히 프로젝트를 리드하는 상황에서 함께하는 동료가 능력이 뛰어날 때 가장 많이 고민했던것 같다. 이때는 동료가 그 능력을 마음껏 발휘할 수 있도록 sandbox를 만들어 주는 일에 집중했는데, 어떻게 비쳤는지는 잘 모르겠다.

  다른 프로젝트를 진행하는 동료가 진행하는 일이 다른 팀과의 관계 때문에 부드럽게 진행되지 않으면 방법을 같이 고민하거나 해결하는 역할도 조금씩 수행했다.

  물론 나만 이렇게 생각하고 있을 수도 있기 때문에, 이 부분은 조만간 질문지를 만들어 개인적으로 인터뷰를 진행할 생각이다. 이 인터뷰를 통해 더 세세한 피드백을 듣고 개선할 수 있지 않을까 기대하고 있다. 이와는 별개로 다른 프로젝트를 진행하느라 접점이 많이 없었던 동료들에게는 상대적으로 적은 관심을 쏟을 수밖에 없어서 아쉬웠다.

• 다른팀 동료들과는 어떻게 지냈는가

  어쩌다 보니 bottom-up으로 진행하는 일을 맡게 되면서 다른 팀 동료들과도 이야기할 기회가 많이 생겼었다. 주로 PM팀, 백엔드팀과 일에 대한 이야기를 많이 하게 되었는데, 그때마다 상황을 풀어서 쉽게 설명하려고 노력을 많이 했다. 좋아하는 표현은 아니지만 “그들의 언어”로 말하기 위해 신경을 많이 쓴 것 같다. 도중에 같은 팀 동료에게 “PM에게 너무 아이 대하듯 이야기하지 말라”는 피드백을 받을 정도로 과도하게 신경을 썼는데, 당사자에게는 “쉽게 설명해 주셔서 좋았는데요”라는 말을 듣고 안심한 적도 있었다.

  하지만 GraphQL을 도입할 때도 그랬듯이 겉이 바뀌지 않는 기술적인 변화에 대해 정당성을 설파하는 일이 쉽지 않았다. “음, 일단은 알겠는데, 그래서 API 서버가 하나 더 늘어나면 무엇이 좋아지나요?”라는 PM의 질문에 선뜻 대답하지 못했다. 무턱대고 “하게 해주세요!”라고 할 수도 없지 않은가.

  

  사실 PM 입장에서는 제품을 구현한 기술이 무엇이든 동작 자체가 중요하기 때문에(이는 사용자도 마찬가지다), 내 주장에 선뜻 동의하기가 힘들었을 수도 있을 거라 생각한다. 이런 부분들은 미래를 위해 반드시 개선되어야 할 부분이다.

  백엔드팀의 애영님과 많은 이야기를 나누었고(앞으로도 많이 이야기해야 하는 상대이기도 하다) 그 과정에서 백엔드팀이 제품을 바라보는 관점을 이해할 수 있어서 좋았다. 다행히 애영님도 프런트팀의 관점에서 서비스를 이해하려는 노력을 계속해주셨고(앞으로도 그러시리라 믿는다) 이를 통해 시간이 갈수록 서로를 배려하려고 하는 무언가를 쉽게 느낄 수 있었다.

  마찬가지로 올 한해에 같이 일했던 다른 팀 분들에게도 질문지를 만들어 인터뷰를 진행할 생각이다.

• 회사에 직접적으로 이익이 되는 일을 했는가

  올해는 회사의 필요에 의해서라기보다는 스스로가 만들어낸 내실을 다지는 일들을 더 많이 했다. 그렇기 때문에 내가 했던 일이 회사에 직접적인 이익이 되었느냐라고 묻는다면 ‘글쎄…’라고 대답할 수밖에 없을 것 같다. GraphQL을 도입했다고 해서 ondemandchina라는 서비스가 매출이 늘어난 것은 아니니까. 오히려 마지막 분기에 진행했던 payment feature가 일정이 밀리면서 매출에 기여할 기회를 놓쳐버린 것 같아 정말 아쉽다.

3. ‘중니어’로 가는길

2020년은 3년 경력의 4년 차 개발자로 일했던 한해였다. 일을 할 때 있어서 예전과는 다르다는 것을 느꼈는데, 이전만큼 성장한다는 느낌을 받지 못했고 무언가 한 번씩 다 해봤던 일 같았다. 그렇기 때문에 GraphQL 같은 해보지 않은 일들에 대해 집착하고 밀어붙였던 것 같다. 이 문제로 그분2와 여러 번 상담을 하기도 했다. 안 그래도 바쁜 사람에게 정답이 없는 문제로 상담을 요청해 놓고 정답을 주지 않는다고 혼자 불만을 갖던 때도 있었으니, 굉장히 바보 같았던 일이다.

위에도 쓰여 있듯, 중니어 레벨로 접어들었다는 신호였지만 유림님의 발표를 듣기 전까지는 깨닫지 못하고 있었던 것 같다. 이 발표 듣자마자 가슴 한쪽에서 무엇인지 모를 울렁거림이 느껴졌고, 이를 통해 내가 문제를 확실히 정의하지 못했지만 유림님과 비슷한 고민을 하고 있음을 깨닫게 되었다. 이에 대한 유림님의 발표 슬라이드도 있으니 비슷한 고민을 하고 있다면 읽어보는 게 좋을 것 같다.

• 충분히 성장했음을 느끼지 못했다

  단도직입적으로 올해는 실력과 지식의 성장이 둔화되었다는것을 느낄 수 있었다. 유림님의 말마따나 comfort zone에 머물려고만 했던 것은 아닌가 고민이다. 한창 이 문제로 고민하고 있을 때 outsider님과 진행했던 인터뷰는 더 많은 생각을 하게 만들었다.

  정확히 어떻게 하고 계신지 모르고 있지만 공부하면서 체감상 성장속도가 줄어든다는 느낌은 자연스러운 것 같습니다. 자연스럽다는 의미는 지식이 쌓이고 있지만 분야도 넓어지고 깊이도 깊어지는데다가 하나를 새로 익힌다는 것에 예전보다 더 많은 노력이 든다고 생각하기 때문입니다. “Coding Confidence vs Competence” 그림처럼 된다고 생각합니다. 주변의 시니어는 대단해보이고 주변의 이제 새로 시작하는 사람은 금방 따 라오는 것 같고요.

  

  ‘충분히 잘하고 있는데 자신감이 떨어진 것인가’라는 질문을 스스로 매번 하고 있지만 아직은 ‘그렇다’라고 하기 힘들다. 분명히 나와 일하는 동료들을 보면 다들 연차와 관계없이 능력이 뛰어나기 때문에 더 그렇게 느껴지는 부분이 있는 것 같다. 분명한 위기다.

• 나태함과 게으름

  충분히 성장을 못 했다는 것은 충분히 노력하지 않았다는 말과도 일맥상통하는 것 같다. 그분2나 백엔드팀의 경업님 같은 경우 “레벨이 올랐으니 다음 레벨을 위해 필요한 경험치가 늘어나는 것은 자연스러운 거다.”라는 말씀을 하시지만 잘 생각해보면 결국 경험치가 늘어난 만큼 내가 노력을 하지 않았다는 뜻이 된다. 물론 두 분은 그런 의도로 말씀하신 것은 아니었겠지만 말이다.

  올해 나태했던 이유가 어려 가지가 있겠지만 제일 큰 것은 번아웃과 토이 프로젝트에 흥미를 잃은 것이 아닐까 싶다. 프로젝트의 목표가 분명히 눈에 보이지 않고 추상적이었던 탓이라고 생각한다. 그러다 보니 혼자서 막 달리다가 ‘이게 뭐 하는 거지?‘라는 생각이 들면서 멈춰서기를 반복했던 것 같다. 독서의 경우 책을 읽고 반드시 기록을 남기자는 생각에서 몇 권 정도의 book report를 썼는데, 오히려 이 부분이 부담되어 독서를 피하게 된 것 같다. 겨우겨우 책을 읽고 book report를 쓰게 되면 그에 따른 보상심리가 평소보다 크게 발동하여 다음 책을 읽기까지 시간이 오래 걸리기도 했다.

• 어떤 개발자가 될 것인가?

  막연하지만 몇 가지 떠오르는 action item을 정리해 보자면 다음과 같다.

  1. 주어진 일정에 책임감 있게 태스크 끝내기
  2. 나뿐만 아니라 동료의 퍼포먼스까지 신경 쓰기
  3. 팀 혹은 조직의 문화나 업무 프로세스에 관여해보기
  4. 팀에 도움이 될만한 추상화된 무언가를 만들어보기(각 프로젝트의 반복 로직에 대한 helper library 등)
  5. 회사의 업무에 방해가 되는 blocker가 있다면 어떻게 제거할 수 있을지 고민해보고, 실질적인 해결책을 제시해 blocker를 해결하기

  우선 1번은 당연히 해야 하는 일인 것 같다. 개인적인 생각으로 개발자가 일정과 책임감을 빼면 아무것도 남지 않는다고 생각한다. 2번은 지금도 조금씩 연습하고 있는 부분이다. 팀에 병대님과 그분2가 있었기 때문에 드러내놓고 하지는 않고 조심스레 하고 있었는데 생각 보다 볶임을 원하시는 분들이 많아 좀 더 적극적으로 해볼 생각이다. 3번부터는 도전의 영역인 것 같다. 이제는 개발의 프로세스나 조직 문화에 대한 고민도 하면서 jira의 그래프를 수시로 들여다보는 습관을 들여야 할 것 같다.

  5번의 경우 그분2와 outsider님이 요구하신 부분이기도 한데, 생각해보았을 때 2021년의 가장 이상적인 목표인 것 같다. 아마도 1~4번까지 모두 이 목표를 위한 전초단계라고 생각한다. 2021년에 위의 action item들을 모두 달성한다면 팀에서 1인분은 할 수 있지 않을까라는 작은 소망을 가져본다.

4. 그 밖의 일들

• Outsider님의 퇴사

  11월 말 개발팀 전체를 리드하시던 outsider님이 퇴사하셨다(그곳에서 행복하신가요). 갑작스럽게 들은 이야기라 충격이 있었는데 내 생각 이상으로 outsider님과 유대감이 쌓였던 것 같다. 하지만 outsider님과 식사 자리에서 그간 고민하셨던 부분(매니저 자리는 생각도 하지 못했다, 생각보다 일의 결정이 늦다 등), 성장이 멈춘 것 같은 느낌을 받을 때가 많았다는 말씀을 들었을 때 같은 개발자로서 100% 이해할 수 있었다. 머리로 이해한 것과는 별개로 여전히 아쉬운 것은 마찬가지였지만.

• 프로젝트 리드

  Outsider님이 퇴사하시면서 급작스럽게 하나의 프로젝트의 리드를 맡아달라는 제안을 받았다. 짧게 고민한 끝에 제안을 받아들였고, 백엔드팀의 애영님과 함께 outsider님이 원래 진행하고 계셨던 프로젝트 중 하나를 리드하게 되었다. 팀이 어떤 형태로 만들어질지 결정된 것은 아니지만 이제부터 본격적으로 팀을 리딩하는 일도 고민해 보아야 할 것 같다.

  특히 병대님께서 팀으로 돌아오셔서 업무 프로세스를 개선하는 과정이 굉장히 인상 깊었기 때문에 이런 부분(팀의 문화를 만들고 업무프로세스도 개선해보고)도 경험을 한번 해보고 싶다는 생각이 들었다.

  생각보다 빠른 감은 있지만 이런 상황이 예의 바르게 물어보고 찾아오는 것은 아니기 때문에 겸허히 받아들였다. 다행히 함께해주실 분이 매우 유능하신 분이라 개인적으로는 크게 안심하고 있다.

• 피드백 받아보기

  그동안 막연한 형태로 피드백을 받고 있었는데 팀 동료 중 한 분이 피드백을 요청하면서 질문지를 들고 오신 것에 매우 놀랐다. 그래서 그것을 벤치마킹하여 Q3부터는 질문지를 준비해서 피드백을 받기 시작했다. 이렇게 받은 피드백을 수집하면 좋은 자료가 될 것 같아 충분한 숫자가 모였을 때 전체적으로 정리를 한번 해볼 생각이다.

• 읽었던 책들

  • 익스트림 프로그래밍
  • 프로그래밍 수련법
  • 유닉스의 탄생
  • 소프트웨어 장인
  • 실리콘밸리의 팀장들
  • 라틴어 수업
  • 로마법 수업
  • 한동일의 공부법
  • 소프트 스킬
  • 어서와, 리더는 처음이지?

5. 마치며

• 아쉬운 것들

  • 2019년 회고록에 있었던 2020년 계획
    • 꾸준한 운동 (필라테스, 자전거 2000km 타기)
      • COVID-19에도 불구하고 필라테스는 가능할 때마다 꾸준히 받았다. 감량 목표도 달성했다.
    • 영어(화상 영어를 고민중)
      • 전혀 지키지 못했다. 아쉬운 부분.
    • 블로그 글(독서록 포함)을 꾸준히 작성하기
      • 한 달에 한 번 정도 작성한 것 같은데 횟수를 늘려야 할 것 같다. 50% 정도의 목표를 달성한 것 같다.
    • 기술적인 내용으로 발표하기
      • 사내 LTE는 진행했지만, 외부 발표를 하지 못했다. 그렇기 때문에 30% 정도의 목표만 달성했다고 생각한다.
    • Haskell, Rust 공부하기
      • Rust는 사내 스터디를 진행했고, 그것으로 끝이었다. 아마 무언가 명확한 목표 없이 책만 읽고 준비했던 탓인 것 같다. Haskell의 경우 전혀 손대지 못했다. 대체 이 목표를 왜 세웠는지 모를 정도로 애매하게 마무리되었다.
  • 책을 많이 읽지 못한 것
  • 팀의 프로젝트 중 하나인 player 프로젝트의 코드를 많이 들여다보지 못한 것. Player 프로젝트를 진행하셨던 분들이 많이 고생해 주셨는데 제대로 따라가지 못한 느낌이 들어 마음에 걸린다.

• 내년의 목표

  • ReasonML이 가장 유력하지만, 새로운 언어로 간단한 서비스 만들어보기
  • 위에 쓰여 있듯 1인분을 할 수 있는 개발자로 거듭나기
  • 컴퓨터 프로그램의 구조와 해석 1독 하기
  • 개발과 관련 없는 책을 50% 이상 포함하여 20권의 책 읽기
  • 블로그에 20회 이상의 글쓰기