2년 개발자 인생 회고록

개발자로서 2년 간 어떻게 지내왔고 앞으로 어떻게 살아야 하는가에 대한 이야기

작년에 미루고 미루다 못했던 회고를 2년이 지난 지금이 되서야 하게 됩니다. 사실 1년 간의 인생에서도 적을 내용이 없지 않았던 건 아닌데 막상 쓰려고 보니 회고를 적기 위해 기억을 끄집어 내는 느낌이라 회고에도 진정성이 없을 것 같아 회고를 미뤘었는데, 올해엔 퇴사라는 이슈도 있었고 마침표를 찍기에 적절한 시기인 것 같아 올해는 적어보기로 했습니다. 회고 내용은 큼지막한 이벤트를 중심으로 어떤 일이 있었는지 정리하고 느낀 점이 있는 일들은 좀 더 자세히 기록하기로 했습니다.

썸네일은 만 나이로 통일되며 제 나이를 자주 헷갈리곤 하는데 그러다 나이 검색을 하면서 문득 저 짤이 생각났고 그래서 추가하게 되었습니다. 큰 의미는 없습니다.

입사 및 커리어 시작

2022년 1월 직장을 구하게 되어 개발자로서의 커리어를 시작하게 되었습니다. 입사 이전에 이것 저것 준비하긴 했지만 첫 직장이라 그런지 긴장도 많이 하고 설렘도 가득 했습니다. 처음 몇 주는 출근이 즐거워서 누가 시키지도 않았는데 일찍이 출근해서 자리를 채웠습니다.

새로운 기술 스택 학습

기존에 React만 알던 저는 새로운 기술 스택인 Next.js와 Redux를 학습해야만 했습니다. SSR과 전역 상태에 대한 개념이 전무했던 당시의 저는 이 개념들을 모두 습득했다고 생각했지만 소스 코드를 확인할 때에는 여전히 버벅거렸습니다. 돌이켜보면 이 과정에선 방대한 소스코드를 해석하는 능력과 프로젝트 구조 이해하기 등과 같이 개발 전반에 필요한 능력들을 기를 수 있었던 것 같습니다. 물론 앞으로도 꾸준히 늘려야 할 능력이기도 하죠.

그리고 멀지 않아 새로운 전역 상태 관리 라이브러리인 Recoil과 React Query로 마이그레이션을 진행하게 되었습니다. 전역 상태 관리에 대한 인사이트가 많지 않았던 저는 적용 과정에선 단순히 보일러 플레이트가 줄고 활용이 간편해졌다 정도의 장점만 느꼈던 것 같습니다. 지나고 나서 개인적인 아쉬움에 변경 전 후의 장단점을 비교하며 그때의 선택을 이해하는 과정을 거치고 비로소 이를 이해하게 되었던 것 같습니다. 이 과정이 전역 상태의 의미에 대해 깊게 생각해 본 계기가 되었던 것 같습니다.

디자인 시스템 개발

처음으로 Storybook을 다루게 됩니다. 나이브하게 생각했던 디자인 시스템의 개념을 더 나아가 본질적인 의미를 생각해보고 다양한 컴포넌트 디자인을 학습하며 확장성과 사용성 사이의 고민도 해보는 계기가 되었습니다. 그리고 이 과정에서 불필요한 컴포넌트들을 개발하기도 했습니다. 사용하지 않거나 시스템으로 관리될 필요성이 적은 컴포넌트들을 패키지에 추가하는 불상사가 일어나기도 했습니다. 이 과정에선 어떤 컴포넌트가 디자인 시스템으로 활용될 수 있는 가에 대해 생각해보는 계기가 되었던 것 같습니다.

중간엔 Tree Shaking 이슈를 만나 이를 해결하기 위해 번들링 개념과 다양한 번들러에 대한 학습도 하게 되었습니다. 지금 다시 봐도 아쉬운 수준의 소스 코드들이지만 이를 통해 단순 구현 목적 외에 필요한 할 다양한 개념들을 접하게 되었고 이를 통해 어느 정도 눈이 트였던 것 같습니다. 동기 부여도 충분히 되었던 것 같네요.

5개월 간의 리부트 프로젝트

서비스 유지보수를 진행하다 보니 리부트 계획에 맞춰 새로운 프로젝트를 시작하게 되었습니다. 리부트 프로젝트는 기존 IP를 유지한 상태로 다른 정책을 갖춘 형태의 프로젝트이기에 기존 도메인을 어느 정도 이해하면서 새로운 개념을 습득하는 과정이 있었습니다.

기능 개발

새롭게 생긴 기능들을 개발하는 과정에서는 기술적인 내용보다는 팀원들과 함께 서비스를 만들면서 필요한 다양한 소프트스킬의 중요성에 대해 인지하게 되었습니다. 기능 개발을 시작하면서 기획 및 디자인 공유가 완료되면 일정 산정을 진행하게 되는데 개발 초기엔 팀 내 시니어 개발자께서 이를 산정해주셨지만 그 분이 퇴사하신 이후 이를 자체적으로 산정하게 되면서 일정 산정의 기준 대상과 개발 과정에서의 불확실성을 고려하여 산정하는 방식을 어느 정도 깨닫게 되었던 것 같습니다.

개발 과정에서는 같은 프론트엔드 파트와 다른 파트(백엔드, 디자인 등)와의 커뮤니케이션 방식에 대해 고민하는 시간을 가질 수 있었습니다. 커뮤니케이션 공통적으론 상황 설명을 할 때 요약할 부분을 고려하는 것과 다른 파트의 커뮤니케이션에선 자신만의 언어를 없애고 공유가 가능한 수준의 언어를 활용하는 것을 배웠습니다. 결과적으로 이러한 고민들이 좀 더 나은 커뮤니케이션 방식을 만들었다고 생각하고 아직 부족하지만 이전보다는 비교적 간결하고 단순하게 의견을 전달할 수 있게 되었다고 생각합니다.

도메인 이해하기

입사 이전부터 입사 직후까지는 도메인에 대해 이해할 필요성에 대해서 체감하지 못했습니다. 개인적으로 서비스 개발을 하면서 도메인 이해의 중요성은 해당 기능을 왜 개발해야 하는 지에 대해서 고민할 수 있는 능력과 관련되어 있다는 생각을 하게 되었습니다. 본인이 개발하는 서비스가 어떤 서비스인지 알지 못하면서 더 나은 서비스를 만들기 위한 생각을 할 수 있을까를 생각해본다면 그건 다소 어려움이 있지 않을까 싶습니다.

DX 개선하기

무릇 모든 개발자들이 효율성을 추구하듯이 가장 관심이 많은 부분은 개발자 경험에 대한 내용이었습니다. 서비스 개발을 하면서 중간 중간에 개발 프로세스 일부분을 자동화 시키며 좋은 개발자 경험에 대한 욕심이 생겼던 것 같습니다.

프로젝트 구조 개편

입사 초기에 구축되어 있던 프로젝트 구조는 React 프로젝트를 기준으로 구조화 된 프로젝트이기에 Next.js로 이전을 진행하면서 다소 어색한 프로젝트 구조를 갖게 되었습니다. 기존엔 하나의 도메인과 관련되어 있는 페이지 및 컴포넌트들이 하나의 도메인 디렉토리 내에서 관리되었는데 Pages 기반 라우팅을 지원하는 Next.js의 특성 때문에 도메인 페이지와 관련 컴포넌트들이 다른 디렉토리로 분리되어 있는 상황이 발생했습니다.

크게 문제라고 생각이 드는 부분은 아닐 수 있지만 하나의 도메인 개발을 진행하면서 여러 디렉토리를 오며가며 개발을 진행하는 것이나 추후 관리에서도 이름을 통일하여도 관련된 소스 코드들을 찾기 위해서 사소한 귀찮음이 발생하는 부분은 개인적으론 비효율적이라고 판단했던 것 같습니다. 그래서 Next.js의 페이지 확장자를 지정할 수 있는 next.config.js 옵션인 pageExtensions 을 지정하여 같은 도메인인 소스 코드를 한 곳에서 관리할 수 있도록 변경하였습니다. 이제 더 이상 하나의 도메인과 관련된 소스 코드를 찾기 위해서 다른 폴더를 찾을 일은 없었고 팀 전체적으로 개발 경험에 긍정적인 영향을 주었던 것 같습니다.

브랜치 전략 개선

브랜치 전략에 대해서 고민해본 적이 있나요? 거대한 프로덕트를 운영하는 큰 기업에서는 이러한 시스템이 너무도 잘 구축되어 있을 수도 있고, 작은 스타트업의 경우엔 이러한 고민을 할 여유조차 없을 수도 있습니다. 우리가 사용한 가장 유명한 브랜치 전략인 Git flow는 꽤나 많은 기업에서 사용하고 있을 가능성이 높지만 해당 전략을 구상한 Vincent Driessen은 2020년에 다음과 같은 언급을 한 적이 있습니다.

Git flow가 고안된 이후 많은 시간이 흘렀고, Git flow는 만병통치약이 아니다. 상황에 맞춰 적합한 워크플로우를 적용하라.

서비스 개발을 진행하면서 기존의 Git flow는 지속적인 배포를 진행하는 저희 팀에겐 큰 이점이 없었으며 rebase 를 사용하는 저희 팀에겐 오히려 불편함을 주는 상황이 생기기도 했습니다. 그래서 이를 Develop-less workflow로 개선을 진행했고 결과적으로 보다 직관적으로 Git 브랜치를 다룰 수 있었습니다. 자세한 내용은 Git flow, 왜 적용했나요?를 확인해주시면 감사하겠습니다.

배포 자동화

배포 자동화라고 거창하게 말하기엔 작지만 실제 개발 과정에선 큰 도움이 되었던 배포 자동화를 진행했었습니다. 배포 진행 시 자동화에 부담을 가져 수동으로 배포를 진행했던 백엔드 API 서버와 프론트엔드 서비스 라이브 배포를 제외한 개발 서버 및 어드민은 잦은 배포를 진행하기 일쑤였고 긴 시간은 아니지만 배포를 기다렸다 서버를 재시작하는 행위는 다소 비효율적이라는 생각이 들었습니다.

이를 해결하기 위해 GitHub에서 제공하는 Actions를 활용하여 병합된 내용에 대해 자동으로 배포를 진행하는 프로세스를 구축하였습니다. 이를 통해 개발을 진행하면서 개발 서버 업데이트가 가능한 단위의 병합 사항이 개발 서버에 누락되는 경우가 없어졌고 다른 구성원들이 개발 서버 업데이트 내용을 빠르게 업데이트 받을 수 있는 결과를 만들었습니다. 또한 매 배포마다 신경쓰지 않아도 되었기에 이를 인지하는 시간도 절약할 수 있었으며 재택을 진행하는 현재에선 IP 제한을 둔 현재의 상황에서도 원격으로 개발을 진행할 수 있는 환경을 만들 수 있었습니다.

퇴사

올해를 마무리로 지금 다니는 회사에서 퇴사를 하게 되었습니다. 사실 이번 퇴사를 통해 이렇게 정리할 수 있는 시간을 가지게 된 것도 있는데 여러모로 저를 다시 돌아보기에 적절한 시기인 것 같습니다. 2년 간의 시간에서 느낀 점과 아쉬웠던 점을 정리할까 합니다.

느낀 점

• 스타트업의 매력이 무엇인가에 대해 어느 정도는 체감한 것 같다.
  • 나에게 많은 권한이 주어질 수도 있고 이에 현실적인 제약이 있을 수도 있다. 주어진 상황에 맞춰 최선을 다하는 것이 어디에 있든 중요한 것 같다.
• 개발은 사람이 하는 것이다.
  • 소프트스킬은 생각보다 꽤나 중요하다. 개발 역량을 늘리는 것도 중요하지만 업무를 함에 있어 마음가짐을 잘 갖추도록 노력하자.
• 같이 일하기 좋은 사람은 누구인가에 대해 꾸준히 고민하자.
  • 소프트스킬에서 이어지는 내용이며 좋은 사람들과 일하고 싶다면 본인부터 좋은 사람이 될 수 있도록 하자.

아쉬운 점

• 현실을 이해하며 절충선 만들기.
  • 현실적인 제약에 대해 당연하게 받아들이기 어려웠던 순간이 많았던 것 같다. 다음부터는 좀 더 유연하게 이를 받아들일 수 있을 것 같다.
• 깊은 학습은 중요하다.
  • 당연한 이야기지만 얕게 학습할 수록 사용한 기술 혹은 방법론에서 발생할 수 있는 문제점은 더욱 크게 되돌아온다.
• 함께 해결하기 위한 준비를 더 잘해보자.
  • 팀원들과 함께 해결하기 위해선 보다 더 괜찮은 협업 방식이 있을 것이다. 내가 했던 노력이 전부였다고 생각하기 보단 더 나은 방법을 고민하자.

빠르면 빨랐던 약 2년 간의 기간 동안 꽤나 많은 것을 배웠고 아쉬웠던 순간들도 있었습니다. 앞으로 있을 약간의 시간 동안 불완전함을 채워 완전함에 가까워질 수 있도록 노력할 것 같습니다. 그땐 보다 더 나은 사람이 되어 있을 것이라고 생각하면서 회고를 마무리 하겠습니다.