2년 개발자 인생 회고록

작년에 미루고 미루다 못했던 회고를 2년이 지난 지금에서야 하게 됐다. 사실 1년 동안에도 적을 내용이 없었던 건 아닌데, 막상 쓰려고 하면 기억을 억지로 끄집어내는 느낌이 들었다. 그러다 보니 글에 진정성이 없을 것 같아서 계속 미뤘던 것 같다.

근데 올해는 퇴사라는 큰 이벤트도 있었고, 개인적으로도 마침표를 찍기에 적절한 시기라고 느꼈다. 그래서 이번엔 늦더라도 한 번 정리해보기로 했다. 회고는 큼지막한 이벤트를 중심으로 어떤 일이 있었는지 정리하고, 느낀 점이 있었던 일들은 조금 더 자세히 기록하는 방식으로 써보려고 한다.

입사 및 커리어 시작

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

새로운 기술 스택 학습

기존에 React만 알고 있던 나는 새로운 기술 스택인 Next.js와 Redux를 학습해야 했다. SSR이나 전역 상태에 대한 개념이 전무했던 당시에는 “이해했다”라고 생각했는데, 막상 소스 코드를 읽을 때는 여전히 버벅거렸던 기억이 난다.

돌이켜보면 이 과정에서 단순히 기술 스택 하나를 배운 게 아니라, 방대한 소스 코드를 해석하는 능력이나 프로젝트 구조를 이해하는 감각 같은 개발 전반에 필요한 역량을 키울 수 있었던 것 같다. 물론 이건 앞으로도 계속 쌓아야 하는 능력이라고 생각한다.

그리고 멀지 않아 전역 상태 관리 도구를 Recoil과 React Query로 마이그레이션하는 작업도 진행했다. 그때의 나는 전역 상태에 대한 인사이트가 깊지 않아서, “보일러플레이트가 줄고 사용이 편해졌다” 정도만 장점으로 느꼈던 것 같다.

시간이 지나고 나서야 변경 전후의 장단점을 비교해보고, 그때 왜 그런 선택을 했는지를 다시 이해하는 과정을 거치면서 비로소 조금씩 정리가 됐다. 결과적으로는 이 경험이 전역 상태의 의미를 더 깊게 생각해보는 계기가 됐다.

디자인 시스템 개발

처음으로 Storybook을 다루게 됐다. 처음에는 디자인 시스템을 조금 나이브하게 이해하고 있었는데, 일을 진행하면서 “디자인 시스템이 본질적으로 뭐지?” 같은 질문을 하게 됐고, 다양한 컴포넌트 디자인을 접하면서 확장성과 사용성 사이의 고민도 해보게 됐다.

다만 이 과정에서 불필요한 컴포넌트를 만들기도 했다. 실제로 거의 사용되지 않거나 시스템으로 관리될 필요가 적은 컴포넌트까지 패키지에 포함시키는 일이 있었고, 그걸 나중에 되돌아보면서 꽤 아쉬움이 남았다. 그럼에도 이 경험 덕분에 어떤 컴포넌트가 디자인 시스템의 구성 요소가 될 수 있는가를 생각해볼 수 있었다.

중간에는 Tree Shaking 이슈도 마주했고, 이걸 해결하기 위해 번들링 개념과 다양한 번들러를 학습하게 됐다. 지금 다시 보면 코드나 접근 방식이 아쉬운 부분도 많지만, “구현만 하면 된다”에서 벗어나 개발에 필요한 개념을 넓히는 데 도움이 됐던 경험이었다. 그때 충분히 동기부여가 됐던 것도 기억난다.

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

서비스 유지보수를 진행하다가 리부트 계획에 맞춰 새로운 프로젝트를 시작하게 됐다. 리부트 프로젝트는 기존 IP를 유지한 상태에서 정책을 새로 가져가는 형태였고, 그래서 기존 도메인을 어느 정도 이해하면서도 새로운 개념을 학습해야 하는 과정이 있었다.

기능 개발

새로운 기능을 개발하는 과정에서는 기술적인 성장도 있었지만, 그보다 더 크게 느꼈던 건 소프트스킬의 중요성이었다. 팀원들과 함께 서비스를 만드는 과정에서 커뮤니케이션이나 일정 관리 같은 것들이 생각보다 훨씬 큰 영향을 준다는 걸 체감했다.

특히 일정 산정이 그랬다. 초기에는 팀 내 시니어 개발자가 일정 산정을 도와주셨는데, 그분이 퇴사한 이후에는 우리끼리 산정을 해야 했다. 그 과정에서 일정 산정의 기준이 무엇인지, 그리고 개발 과정에 있는 불확실성을 어떻게 고려해야 하는지를 조금씩 깨닫게 된 것 같다.

개발 과정에서는 프론트엔드끼리의 커뮤니케이션뿐 아니라, 다른 파트(백엔드/디자인 등)와 이야기하는 방식도 고민하게 됐다. 상황을 설명할 때는 요약할 부분을 먼저 잡아주는 게 중요했고, 다른 파트와의 커뮤니케이션에서는 “프론트엔드만 쓰는 언어”를 줄이고 공유 가능한 언어로 말하는 것이 중요하다는 걸 배웠다.

아직 부족하다고 느끼지만, 그래도 이전보다는 좀 더 간결하게 의견을 전달할 수 있게 됐다고 생각한다.

도메인 이해하기

입사 이전부터 입사 직후까지는 도메인을 이해해야 한다는 필요성을 크게 체감하지 못했다. 근데 시간이 지나며 도메인 이해의 중요성은 결국 **“왜 이 기능을 만들어야 하는지 고민할 수 있는 능력”**과 연결된다는 생각이 들었다.

내가 만드는 서비스가 어떤 서비스인지 모르면서 더 나은 서비스를 만들기 위한 고민을 할 수 있을까? 생각해보면 그건 꽤 어렵다. 이때부터는 도메인을 이해하려는 노력 자체를 이전보다 의식적으로 하려고 했던 것 같다.

DX 개선하기

개발자라면 다들 효율성을 추구하듯, 나도 자연스럽게 **개발자 경험(DX)**에 관심이 많았다. 서비스 개발을 하면서 중간중간 개발 프로세스 일부를 자동화하고 개선하면서, “이런 쪽을 더 잘해보고 싶다”는 욕심이 생겼던 것 같다.

프로젝트 구조 개편

입사 초기에 구축돼 있던 프로젝트 구조는 React 프로젝트 기준으로 구조화돼 있었다. 그래서 Next.js로 이전하면서 구조가 좀 어색해졌고, 특히 Pages 기반 라우팅을 사용하는 Next.js 특성 때문에 도메인 페이지와 관련 컴포넌트가 서로 다른 디렉토리에 분리되는 상황이 발생했다.

크게 문제라고 생각하지 않을 수도 있지만, 하나의 도메인을 개발할 때마다 여러 디렉토리를 오가야 했고, 추후 유지보수에서도 관련 코드를 찾기 위해 사소하게 귀찮은 순간들이 계속 생겼다. 이런 사소한 불편함이 누적되는 게 개인적으로는 비효율적이라고 느꼈다.

그래서 next.config.js에서 pageExtensions를 지정해 같은 도메인 관련 소스 코드를 한 곳에서 관리할 수 있도록 변경했다. 이후에는 같은 도메인 소스를 찾기 위해 폴더를 헤맬 일이 줄었고, 팀 전체적으로도 개발 경험에 긍정적인 영향을 줬던 것 같다.

브랜치 전략 개선

브랜치 전략에 대해 고민해본 적이 있을까? 큰 기업은 이미 체계가 잘 잡혀 있을 수도 있고, 작은 조직은 그런 고민을 할 여유가 없을 수도 있다.

우리가 사용하던 Git flow는 많은 기업에서 흔히 쓰는 전략이지만, 이 전략을 구상한 Vincent Driessen은 2020년에 이런 말을 했다.

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

우리는 지속적인 배포를 진행하는 팀이었고, rebase를 자주 쓰는 방식과도 맞물리면서 Git flow가 오히려 불편함을 주는 상황이 생겼다. 그래서 브랜치 전략을 Develop-less workflow 형태로 개선했고, 결과적으로 더 직관적으로 Git 브랜치를 다룰 수 있었다.

자세한 내용은 Git flow, 왜 적용했나요?를 참고해주면 좋겠다.

배포 자동화

“배포 자동화”라고 거창하게 말하기엔 작지만, 실제 개발 과정에서는 꽤 큰 도움이 됐던 개선도 있었다.

API 서버나 프론트엔드 라이브 배포처럼 신중함이 필요한 부분은 수동으로 진행했지만, 개발 서버나 어드민은 비교적 잦은 배포가 필요했다. 배포를 기다리고 서버를 재시작하는 과정은 매번 긴 시간이 드는 건 아니었지만, 반복되면 확실히 비효율적이었다.

이를 해결하기 위해 GitHub Actions를 활용해 병합된 내용을 자동으로 배포하는 프로세스를 구축했다. 그 결과 개발 서버에 반영돼야 할 변경 사항이 누락되는 경우가 줄었고, 다른 구성원들도 변경 내용을 더 빠르게 확인할 수 있게 됐다.

무엇보다 매번 배포를 “신경 써야 하는 일”로 두지 않아도 되면서, 그걸 인지하고 챙기는 시간 자체가 줄어든 게 가장 만족스러웠다. 재택을 하는 상황에서는 IP 제한이 있는 환경에서도 원격으로 개발하기가 한결 편해졌던 것도 의미가 있었다.

퇴사

올해를 마무리로 지금 다니는 회사에서 퇴사를 하게 됐다. 이번 퇴사 덕분에 이렇게 정리할 시간을 가지게 된 것도 있고, 여러모로 나 자신을 다시 돌아보기에 적절한 시기라는 생각이 들었다. 2년 동안 느낀 점과 아쉬웠던 점을 간단하게 정리해보려고 한다.

느낀 점

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

아쉬운 점

• 현실을 이해하며 절충선 만들기
  • 현실적인 제약을 당연하게 받아들이기 어려웠던 순간이 많았다. 다음에는 조금 더 유연하게 받아들이고, 그 안에서 선택지를 찾을 수 있을 것 같다.
• 깊은 학습은 중요하다
  • 당연한 얘기지만 얕게 학습할수록 사용한 기술이나 방법론의 문제점이 더 크게 되돌아온다는 걸 체감했다.
• 함께 해결하기 위한 준비를 더 잘해보자
  • 팀원들과 함께 문제를 해결하려면 더 괜찮은 협업 방식이 분명 있을 텐데, 내가 했던 노력이 전부였다고 생각하기보다 더 나은 방법을 계속 고민해야겠다.

빠르면 빨랐던 약 2년 동안 꽤 많은 걸 배웠고, 아쉬웠던 순간들도 있었다. 앞으로 생길 시간 동안 불완전함을 조금씩 채워가며 더 나은 사람이 되려고 한다.

그땐 지금보다 더 단단한 사람이 되어 있을 거라고 믿으면서, 회고를 마무리해보려고 한다.