첫 회사에서 2년 1개월 가량 프론트엔드 개발자로 근무한 이홍빈입니다.
남는 시간에 이슈 하나라도 더 처리하기보다 팀과 개인에 도움이 될 수 있도록 퇴사 부검을 작성하고, 공유했습니다.
레퍼런스: https://medium.com/a-day-of-a-programmer/우아한형제들-퇴사-부검-010ce38609a5
일하면서 어떤 고민을 했고 이 고민이 해결되기 어려울 것이라는 판단을 내리기까지의 과정을 공유하면 고민의 깊이를 나눌 수 있는 기회가 될 수 있을 것이라 생각합니다.
1. 왜 떠나는 지
>💡 다른 직원들이 이해할 수 있는 이유가 있어야 합니다.
개발자로 회사의 비지니스 가치를 만들 수 있고, 사용자의 피드백을 받아 빠르게 프로덕트를 디벨롭하며 팀원과 한 호흡으로 개발하는 모습을 기대했습니다. 그리고 코드 리뷰와 테크세미나라는 개발 문화가 정착되어있다는 점이 매력적이었습니다.
PM-디자이너-QA 엔지니어와 협업을 할 수 있다는 개발 프로세스에서도 배울 점이 많아보였습니다.
입사 전, 기술 면접을 진행해주신 프론트엔드 개발자분께 직접 커피챗을 요청했습니다.
이야기했던 여러 가지 중에서 개발팀에 장기 근속자가 여러 명 있다는 점이 스타트업이지만 안정적인 업무 환경일 것이라는 기대를 하게 했습니다. 그리고 React.js, Next.js를 기본 스택으로 모던 웹 프레임워크를 기반으로 개발하고 있다는 점, 개발팀에는 개발 외의 요소들이 개입되지 않아 개발 업무에 집중할 수 있다는 점도 매력적인 요소였습니다.
감사한 협업 경험과 일에 대한 태도
2년 3개월동안 많은 경험을 할 수 있었습니다.
우선 기대한 대로 모던 웹 프레임워크를 활용하여 회사의 프로덕트 프론트엔드를 담당하여 개발하고, 협업 부서와 원활히 협업할 수 있었습니다. 커피챗에서 들은대로 장기 근속자가 많아, 회사의 여러가지 이력을 직접 들을 수 있었고, 다양한 경험들을 공유받을 수 있었습니다.
프로덕트 개발을 진행하면서 수많은 코드 리뷰 경험과 협업 경험을 쌓을 수 있었습니다. 협업을 위해 처음 도입한 ESLint 룰과 husky 자동화부터 코드 push를 통한 자동 배포, 효율적인 코드 리뷰를 위한 그라운드 룰 도입, QA 프로세스 제안 등 재밌는 경험을 하며 협업자의 시선에서 생각할 수 있었습니다.
디자인 패턴을 공부하고 공유한 테크 세미나도 진행했고, 프로젝트 빌딩, 세팅부터 개발, 유지보수, CI/CD 자동화 프로세스와 개발 문서까지 모든 사이클을 진행해볼 수 있었습니다.
특히, 개발 업무에 완전히 몰입하여, 프론트엔드 개발팀의 고질적인 문제를 발견하고 해결할 수도 있었습니다. 반복 개발되는 비효율성을 해결하기 위해 디자인 시스템을 발제하고 빌딩부터 개발, 유지보수까지 진행할 수 있었습니다. 이 프로젝트로 단순히 주어진 업무를 수행하는 것을 넘어 개발 프로세스를 근본적으로 개선하는 가치를 창출하는 기여를 할 수 있었습니다.
신입으로 입사한 저를 믿어주시고 프로젝트로 발전시킬 수 있는 소중한 기회를 받은 것은 정말 운이 좋았다고 생각합니다. 당시 팀장님이신 분께도 많은 감사를 표했고, 단단한 신뢰관계에서 일해야한다는 배움을 얻어 앞으로도 신뢰 관계 조성에 힘을 써야한다는 일에 대한 태도를 흡수할 수 있었습니다.
NPM 패키지 개발과 배포라는 처음 맡아보는 도전적인 상황에서 하나씩 해결책을 찾아나갔습니다. 배포 환경을 설정하고, 번들링 방식과 툴을 설정하고 개발 환경을 세팅했습니다. 배포할 패키지의 버전 관리 방식과 버전 일정, 컴포넌트 배포 순서와 코드 베이스 빌딩, 공식문서 제작, 단위 테스트와 비주얼 회귀 테스트까지 한단계 한단계씩 상황에 필요한 문제를 분석하고 적합한 툴을 찾아 해결했습니다. 복잡하고 낯선 업무였지만 해결책을 찾아가며 재밌게 프로젝트를 진행할 수 있었습니다.
이렇게 여러가지 개발을 하면서, 개발환경 세팅부터 테스트까지의 개발 사이클, 다양한 비지니스 로직 처리와 기능 구현, 디자인 패턴을 적용하고 리팩토링을 진행, 문서를 기반으로한 원활한 유관 부서와 협업, 주도적인 회의 주최 등 프론트엔드 엔지니어로서 필요한 하드 스킬을 정진하고 소프트 스킬을 배울 수 있는 소중한 기회였습니다.
2. 회사에서 배운 것
> 💡새로 배운 것, 경험한 것을 작성합니다.
사실 회사에 와서 한 모든것이 새로운 경험이었고 배운 점들이었습니다. 회사에 기여하는 과정에서 크게 배운것들이 있습니다. 병목없는 협업을 위한 문서 기반 공유 문화, 디자인 시스템 개발을 통한 SSOT(Single Source Of Truth)의 중요성입니다.
병목없는 협업을 위한 문서 기반 공유 문화
회사에 들어와서 여러 문서와 회의록을 작성했습니다.
가장 좋은 문서는 소스 코드라고 하지만, 비개발자와의 협업과 코드 밖의 맥락, 그리고 소스 코드를 매번 뒤져보지 않기 위해 결국 개발과 문서가 동반되어야 합니다. 테스트 코드를 작성하더라도, 테스트 커버리지 리포트를 문서 형태로 유관 부서(QA 엔지니어님 등)와 공유할 필요가 있습니다. 따라서, 모든 문서는 병목없는 협업을 위해 탄생되어야하고 독자를 위해 작성되어야함을 배웠습니다.
- 제품의 개발 스펙 문서
- 디자인 시스템 공식 문서(사용법, 예제 코드 등)와 개발 문서(기술 히스토리, 트러블 슈팅, CI/CD 과정, 기여하기 등)
- 릴리즈 슬랙봇과 협업부서가 모두 바라보는 개발 대시보드 페이지
- 원활한 회의를 위한 수많은 회의록
위는 제가 협업을 위해 작성한 문서들로 유관 부서와 병목없는 협업을 이루고 커뮤니케이션 비용을 줄이는 데에 초점을 맞춰 작업할 수 있었습니다. 개발팀의 문화로 문서 기반으로 회의하고, 회의록과 협업에 필요한 문서를 작성하는 중요성을 배울 수 있었습니다. 협업을 위한 커뮤니케이션 방식과 비용에 대해 생각해볼 수 있는 기회였습니다.
SSOT(Single Source Of Truth)의 중요성
디자인 시스템을 개발하면서 중요한 원칙 중 하나인 SSOT를 몸소 느끼고 개발할 수 있었습니다.
디자인 시스템의 SSOT 원칙으로 해결한 문제는 다음과 같습니다.
- 디자인 토큰 확립과 문서화로 여러 코드베이스와 피그마에서 데이터 구조, 명칭, 기능 통일
- 컴포넌트 UI/UX 변경 시 한 번의 배포로 모든 어플리케이션에서 업데이트 가능한 구조를 이끌어냄.
- 디자인 결과물에서의 실수와 의도를 디자인 토큰 기반으로 판단 가능, 커뮤니케이션 비용 감소
- QA 진행 시, 어플리케이션 레벨에서 검증되던 UI 컴포넌트를 라이브러리 레벨로 감소시켜 비지니스 플로우와 UI 플로우에 대한 검증과 이슈를 별개로 구분하여 협업 효율성 증가
- 피그마로 불가능하던 버전 관리를 사내 디자인 시스템 배포 사이클을 공유함으로서 개발팀 주도 버전 관리를 이루어냄.
- 어플리케이션 코드 베이스의 절대량 감소 및 비지니스 코드와 UI 코드의 시스템적인 분리로 더 좋은 아키텍쳐에 기여
- 코드 예제를 함께 포함하여 레버리지를 통한 어플리케이션 개발자의 고민 감소, 사용측 코드의 일관성 증가
디자인 시스템을 개발하며 개발자의 관점을 비롯하여 협업의 관점, 코드 구조의 관점과 라이브러리 운영 관점에서 SSOT의 중요성을 다양하게 배울 수 있었습니다.
3. 앞으로의 계획
충분한 휴식을 취하면서 차분히 새로운 환경을 찾아가고 싶습니다. 새로운 환경에서 컴포트존을 벗어나 도전을 즐기며 나아가고 싶습니다. 더 넓은 세상에서 도전을 즐기는 개발자로 나아가고자 합니다.
- 제품 중심의 개발: 사용자 피드백을 통해 제품을 개선하고, 이를 통해 비즈니스 가치를 창출하는 과정에 기여하고 싶습니다.
- 더 넓은 협업 경험: 다양한 도메인과 팀과 협력하며, 복잡한 문제를 해결하는 데 도전하고 싶습니다.
- 기술적 성장: 새로운 기술 스택을 배우고, 이를 통해 더 나은 개발자가 되고 싶습니다.
그리고 저는 제품을 1순위로 두면서 기술, 협업 비용 최소화와 같은 이야기를 할 때 가장 생기있게 이야기할 수 있는 사람이란 것을 알았습니다. 책임을 지는 프로젝트를 진행하는 것도 힘들었지만 뿌듯함이 더 크게 다가왔습니다. 자율성있게 일할 수 있으면서도 기술적이거나 제품을 위한 이야기를 할 수 있는 동료가 있다면 즐겁게 일할 수 있을 것이라고 생각합니다.
그리고 중장기 목표로 글을 잘써서 책을 쓰고싶습니다. 쉬는 동안, 글쓰기에 집중하기 위해 글또 라는 글쓰기 커뮤니티에 참여하였습니다. 새로운 만남들과 자극들이 기대되고 설레입니다. 앞으로 휴식기동안 구직 준비를 하며 그동안 회사에서 얻는 인사이트를 글로 정리해보려고 합니다. 노션과 메모장에 섞여있는 정보들을 필요한 사람이 잘 검색해서 쓸 수 있도록 도움을 준다면 개발만큼 재밌는 일이 될것이라고 생각합니다.
'Web Development' 카테고리의 다른 글
Vanilla-extract 라이브러리 번들사이즈 60% 최적화하기(feat. 내가 Anti-pattern이라니..) (3) | 2024.11.10 |
---|---|
Next.js v12.0 점진적으로 개편하기(Feat. 도커이미지 95% 경량화) (0) | 2024.10.27 |
Issue 템플릿 작성하기(라벨, 할당자, 타이틀 자동 설정, 오픈소스 참고) (0) | 2024.08.29 |
Github PR, Issue 템플릿에서 주석달기 (개발자에게만 보이고 실제 pr, issue에는 안보이도록 만들기) (0) | 2024.08.20 |
[AWS elastic beanstalk] postgresql, redis 설치하기(feat. GPT 드리븐 디벨롭먼트) (0) | 2024.08.05 |