🐤 25년 9월 회고
들어가며
개발 관련
- 사내 신규 솔루션 마이그레이션 집중 (10월 내 구 솔루션 전환 목표)
- 토스 클린 코드 공식 문서 정독
- claude.md, .cursorrule 등 생산성 도구 관심 갖고 사용해보기
그 외 (커뮤니케이션)
- 스프린트 시작 전, 명확한 일정 공유를 위한 태스크 상세화 시도
- 『바바라 민토, 논리의 기술』 읽고 9월 경험에 대한 생각 정리
- 『함께 자라기』 읽고 인사이트 한 가지 업무에 적용하기
입사한 지 어느덧 두 달, 9월은 제품팀 안에서 '함께' 일하는 방식을 배워나간 한 달이었다. 때로는 맡은 기능을 빠르게 구현하려는 욕심에 엣지 케이스를 놓쳐 재작업을 하기도 했고, 동료와의 공유 과정에서 삐걱거릴 때도 있었다. 하지만 매주 진행되는 팀 회고를 통해 동료들과 함께 고민하며 개선점을 찾고 액션 포인트를 도출할 수 있었다. 이번 회고를 통해 겪었던 시행착오를 공유하고, 10월에는 이를 어떻게 개선해 나갈지 이야기하고자 한다.
지난 2개월간의 성과
수습 기간이었지만 나름의 성과도 있었다. 팀 노션 페이지의 일부를 가져왔다.
크고 작은 32개의 기능을 배포했다. 그 과정에서 문제의 원인이 프론트엔드인지 백엔드인지 몰라 헤매기도 했지만, 동료들의 도움 덕분에 빠르게 원인을 파악하고 하나씩 해결해 나갈 수 있었다.
이전 회사에서 가장 갈망했던 경험 중 하나는 바로 레거시 코드를 다루는 경험이었다. 감사하게도 소위 말하는 '답이 없는' 수준의 레거시 코드는 아니었지만, 동료들이 과거에 작성한 코드를 수정하는 프로젝트를 맡으며 적절한 난이도의 과제를 마주할 수 있었다. 덕분에 더 큰 재미를 느끼며 프로젝트를 진행했고, 다가올 4분기에는 새로운 프로젝트와 병행하며 더 성장할 기회가 생겨 기대가 크다. 4분기에는 이 경험들을 바탕으로 성과를 잘 정리해보고, 남은 10월과 11월은 공부에 더 집중하려 한다.
10월부터는 신규 솔루션 사용을 팀에 적극적으로 권장하고, 기존 솔루션은 점진적으로 사용 중단해 나갈 예정이다!
"함께" 잘 일하기 위한 노력
1. 예측 가능성 높은 개발자가 되기 위한 노력, 일정 산정
약 2개월 전, 특정 화면을 PDF로 출력하는 기능을 구현한 경험이 있다. 단일 및 다중 내보내기를 모두 포함하는 기능이었다.
당시 스프린트 플래닝에서 '넉넉하게 1주일'을 예상했지만, 결과적으로 3주가 소요됐다. 물론 데일리 미팅에서 지연 상황을 빠르게 공유하긴 했지만, 티켓의 무게를 고려했을 때 스프린트 플래닝 이후 스펙을 명확히 정리하여 PO에게 따로 공유했다면 어땠을까 하는 아쉬움이 남는다.
예상보다 일정이 3배나 지연된 경험을 교훈 삼아, 9월에는 다음과 같은 두 가지 방식을 시도했다.
팀의 시도: 개발 스펙 회의
함께 일하는 동료 프론트엔드 개발자 분의 주도로 '개발 스펙 회의'를 시작했다.
위 이미지처럼 각자 맡은 태스크를 가져와 일정을 재산정하고 개발자 간의 싱크를 맞추는 시간을 가졌다. 이 회의를 통해 '4시간'으로 예상했던 '고객 관리 중개사별 필터 보기' 기능의 소요 시간을 '2일'로 현실적으로 조정할 수 있었다.
다음 회의부터는 기획 문서를 기반으로 구체적인 구현 방식까지 논의해보기로 했다. '일정을 더 날카롭게 산정할 수 있겠다'는 장점이 있지만, '미팅 시간이 늘어날 수 있다'는 단점도 예상된다. 우선은 팀 차원에서 함께 시도하며 가장 효율적인 방법을 찾아가기로 했다.
개인의 시도: 주간 사전 플래닝
주말에 시간을 내어 다가올 스프린트 미팅을 미리 준비해보았다. 공유할 태스크의 일정을 미리 상세하게 정리해두니, 실제 회의에서 훨씬 자신감 있고 명확하게 일정을 공유할 수 있었다.
2. 동료의 편의를 고려한 QA 요청 방식을 찾아보다
우리 팀은 별도의 QA팀이 없어, 개발자가 1차 확인 후 PO나 디자이너에게 QA를 요청하는 방식으로 협업한다. 이 과정에서 더 나은 소통 방식을 고민하게 된 계기가 있었다.
2-1. 안티패턴: "동료가 바쁘니까, 한번에 모아서 QA를 요청하자"
현재 우리 팀 PO님은 PO, 애자일 코치, 디자인 등 1인 다역을 수행하며 매우 바쁘게 일하고 있다. 이런 상황에서 9월에 진행한 '매물 페이지 디자인 개편' 작업에서 나의 미숙한 판단이 있었다.
나름 규모가 큰 이 티켓을 나는 아래와 같이 4개의 하위 태스크로 나누었다.
겉보기에는 4개로 간단해 보이지만, 실제로는 필터 적용, 개별/전체 초기화, 디자인 시스템 컴포넌트 구현 등 복잡한 요구사항이 얽혀 있었다.
가장 큰 실수는, 1번을 제외한 2, 3, 4번 기능을 모두 개발한 뒤에야 한꺼번에 QA를 요청했다는 점이다. PO님이 바쁘시다는 생각에 작은 단위로 자주 요청하기가 망설여졌기 때문이다. 하지만 이로 인해 약 8일이라는 긴 시간 동안 PO는 내 작업물의 진행 상황을 전혀 알 수 없었고, 8일 뒤에 방대한 양의 QA를 마주하며 큰 혼란을 겪었다. 버그도 많았다.
다행히 기능은 잘 마무리되었지만, 이 경험은 스프린트 회고에서 중요한 논의점으로 다뤄졌다. 이후 PO님이 추천해주신 『함께 자라기』라는 책에서 실마리를 찾을 수 있었다.
2-2. 개선하기: "동료가 바쁘니까, 더 작게 쪼개서 빠르게 공유하자"
198p 고객에게 매일 가치를 전하라.
책을 읽고 "아, 매일 가치를 만드는 데 집중해야겠구나." 하는 통찰이 있었다. 여기서의 고객은 최종 사용자뿐만 아니라, 내 결과물을 기다리는 내부 동료도 포함된다고 생각했다. 그래서 매일 내가 만든 결과물을 동료에게 공유하기로 다짐했다.
이를 위해 Amplify의 Preview 기능 자동화가 필요하다고 판단했다. 이 아이디어를 동료 개발자분께 제안했고, 동료분께서 흔쾌히 자동화 설정을 도와주셨다. 덕분에 이제는 PR을 생성할 때마다 자동으로 프리뷰 환경이 구축되고 URL이 생성된다. 이 환경을 활용해 '매물 보내기 페이지' 작업부터는 작은 단위로 결과물을 공유하기 시작했다.
그런데 여기서 또 문제가 발생했다.
문제의 핵심은 '내가 기능을 어떻게 쪼갰는지' 사전에 QA 담당자와 공유하지 않았기 때문에 발생한 혼란이었다.
위와 같이 내 나름대로 태스크를 4가지로 쪼갰지만, 이 기준을 PO님과 미리 공유하지 않았다. 요청받는 사람 입장에서는 아무런 맥락 없이 슬랙으로 '3번 기능 확인해주세요', '4번 기능 확인해주세요' 같은 요청을 받으면 혼란스러울 수밖에 없다. 어느 정도로 꼼꼼하게 QA를 해야 하는지, 다른 기능(1, 2, 4번)이 왜 구현되지 않았는지에 대한 불필요한 질문이 오갈 수도 있다.
내 방식이 동료를 편하게 하는 것이 아니라 오히려 더 많은 신경을 쓰게 만드는 방식이었음을 깨달았다.
그래서 10월부터는 이렇게 해보려 한다.
특정 기능이 크다고 판단되면, 먼저 하위 티켓으로 상세히 쪼갠 뒤 데일리 미팅 후 QA 담당자와 따로 싱크를 맞춰 업무의 맥락을 공유하고 개발을 진행하려 한다. 정답은 없겠지만, 우리 팀에 가장 잘 맞는 최적의 방법을 계속 모색하려고 한다.
결국 핵심은 '함께' 일하는 동료에 대한 '배려'이다. 리더는 나보다 훨씬 바쁘고, 동료는 자신의 일만으로도 벅찰 수 있다는 점을 항상 기억해야 한다.
마치며
9월은 '빠르게 실패하고 피드백하며 배우는' 과정의 연속이었다. 이 과정을 통해 팀 안에서 함께 성장하는 법을 익힐 수 있었다. 다시 한번 동료들에게 감사한 마음을 전한다. 다가오는 10월에는 동료들이 나와 함께 일할 때 조금 더 편안함을 느낄 수 있도록 노력하고 싶다. 그러기 위해선 결국 개발 실력이 뒷받침되어야 한다. 다시 한번 마음을 다잡고 열심히 공부하려 한다.
10월의 액션 포인트
- 기존 사내 코드 SSR 전환을 위해 Next.js 학습 (2주 집중 학습)
- 기본적인 SQL문 학습
- 오픈 닥터 웹/앱 마이그레이션을 위해 Flutter-web 공부하기