🐤 25년 8월 회고

들어가며

오픈 닥터 제품팀에 7월에 입사해 온보딩을 마치고, 8월부터 본격적으로 내부 솔루션 마이그레이션 업무를 담당하게 되었다. DB와 백엔드 코드를 틈틈이 살펴보며 비즈니스 로직을 파악하고 있지만, 로직이 복잡해 헤맬 때가 많았다. 다행히 동료들과 사수분의 도움으로 빠르게 적응해나가고 있다. 🙏🏼

8월 한 달간 일하며 가장 크게 느낀 것은 필요한 기능을 빠르고 정확하게 만드는 역량과 일정을 예측하고 준수하는 훈련이 시급하다는 점이었다. 우리는 2주 단위로 스프린트 플래닝 미팅을 진행한다. 8월 동안 내가 공유했던 예상 개발 일정은 실제로는 최소 1.5배에서 최대 2배까지 소요되었다. 이 간극을 줄이는 것을 수습 기간의 핵심 목표로 삼아야겠다고 다짐했다. PO님께서 이 문제를 해결하기 위한 방향을 제시해주셔서 진심으로 감사했고, 남은 수습 기간에 철저히 연습해 볼 생각이다.

일정이 밀리는 원인은 복합적이다. 이 글에서는 이슈 트리(Issue Tree)를 활용해 문제를 구조적으로 분석해보고, 이를 바탕으로 9월에 어떻게 성장해 나갈지 계획을 공유하고자 한다.

1. Git, 이론에서 실전으로

이전에도 Git을 사용해봤지만, 이번 달처럼 그 중요성과 깊이를 체감한 적은 없었다. 이론으로만 알던 개념들이 실제 협업 과정에서 어떻게 작동하는지 깨닫게 된 한 달이었다.

오픈 닥터의 브랜치 전략 및 병합 방식

우리 팀은 git-flow 전략을 간소화하여 활용하고 있다.

• main: 실제 운영 중인 프로덕트의 소스 코드를 관리한다.
• develop: 다음 배포 버전에 포함될 기능들이 쌓여있는 브랜치다.
• feature: 여러 기능이 조합된 큰 규모의 작업을 진행할 때 사용한다. 예를 들어 '특정 페이지 디자인 개편'처럼 컴포넌트, 레이아웃, 기능 구현이 모두 필요한 경우 별도의 feature 브랜치를 생성하고, 그 안에서 feat/, fix/ 등의 작은 브랜치를 만들어 작업한다.

개별 작업 브랜치는 코드 리뷰를 거친 후, feature 또는 develop 브랜치로 병합된다. 이후 정해진 시간에 develop의 코드를 main으로 병합하여 최종 배포를 진행한다.

실수 덕분에 알게 된 git reflog의 소중함

최근 3일간 작업했던 달력 컴포넌트와 관련 기능을 통째로 날려버리는 아찔한 실수를 했다. 꼬인 브랜치를 정리하는 과정에서 실수로 작업 브랜치를 삭제해버린 것이다. 절망적인 순간, git reflog라는 명령어를 통해 죽다 살아났다.

git reflog는 HEAD 포인터가 변경될 때마다(예: 커밋 생성, 브랜치 변경, reset 등) 그 기록을 로컬에 남겨두는 명령어다. 덕분에 실수로 사라진 커밋의 '발자취'를 추적하고 복구할 수 있다.

예시: 실수로 동료의 커밋을 날렸을 때

$ git log --pretty=oneline
fdf4fc3344e67ab068f836878b6c4951e3b15f3d 동료의 커밋
cac0cab538b970a37ea1e769cbbde608743bc96d 내 커밋

동료의 커밋을 실수로 삭제해버렸다고 가정해보자.

$ git log --pretty=oneline
cac0cab538b970a37ea1e769cbbde608743bc96d 내 커밋

reflog를 활용해서 삭제 혹은 누락된 커밋을 확인할 수 있다.

$ git reflog
1a410ef HEAD@{0}: reset: moving to cac0cab
fdf4fc3 HEAD@{1}: commit: 동료의 커밋

HEAD@1에 동료의 커밋(fdf4fc3)이 기록되어 있는 것을 확인하고, git switch -c <복구할-브랜치명> fdf4fc3 명령어로 해당 커밋을 기반으로 한 새 브랜치를 만들어 작업을 되살릴 수 있다. 이 방법으로 3일간의 작업을 무사히 복구했던 경험은 Git 명령어의 중요성을 다시 한번 깨닫게 해주었다. git merge와 Rebase의 동작 원리나 다른 실수들은 별도의 기술 포스트로 자세히 다뤄볼 예정이다.

2. 일정 예측 실패, 원인을 파고들다

"왜 나는 일정을 지키기 어려울까?"라는 질문에 답을 찾기 위해, 온보딩 교육에서 배운 이슈 트리(Issue Tree)를 활용해 원인을 분석해 보았다.

문제를 크게 '계획'과 '실행' 단계로 나누어 내가 놓치고 있던 부분을 파악했다.

• 계획 단계의 문제점

1. 개발 외 시간 미반영: 2주간의 미팅, 리뷰 등 개발 외 시간을 고려하지 않고 순수 개발 시간만으로 일정을 산정했다.
2. 기존 코드 파악 부족: 기능을 수정하거나 개선할 때, 관련된 기존 코드의 복잡도를 파악하지 않은 채 일정을 계획했다.

• 실행 단계의 문제점

1. 소극적인 질문: 기존 구현 방식을 이해하는 과정에서 막히는 부분이 있을 때, 더 적극적으로 질문하여 시간을 단축하지 못했다.
2. 부족한 테스트 습관: 기능 구현 후, 다양한 엣지 케이스에 대한 꼼꼼한 테스트가 부족하여 QA 단계에서 예상치 못한 수정 사항이 발생했다.

이 분석을 통해 얻은 4가지 포인트를 바탕으로, 다음 스프린트에서는 더 정확하게 일정을 산정하고 실행의 완성도를 높여보려 한다. 팀 회고에서 PO님께서 "개발자가 예상한 시간의 2배, 익숙하지 않다면 3배까지 여유를 두고 일정을 산정하며 그 간극을 줄여나가라"는 현실적인 조언을 주셨다. 이 팁을 적극적으로 활용해 볼 것이다.

3.성장의 밑거름, 동료들의 피드백

입사 한 달이 조금 지난 시점에 수습 중간 피드백을 받는 시간이 있었다. 개인적으로 피드백을 두려워하지 않고 성장의 기회로 삼는 점을 나의 큰 장점으로 생각한다.

PO님께서 만들어주신 부드러운 분위기 속에서, 동료들이 한 명씩 돌아가며 CSS(Continue / Stop / Start) 프레임워크를 기반으로 귀한 피드백을 나눠주었다.

이런 귀한 피드백을 받을 수 있었다. 혼자 일하면서 간절했던 피드백을 이렇게 받을 수 있다니 진심으로 감사했다. 위의 피드백을 기반으로 업무 체크리스트를 만들면 되겠다는 인사이트가 있었고 그래서 만들어봤다. 앞으로 더 많은 피드백이 있겠지만 업무 체크리스트만 잘 관리하면 해결할 수 있지 않을까 싶어 공유해본다.

혼자 일할 때는 결코 얻을 수 없었던, 간절했던 피드백이었다. 이 피드백을 놓치지 않고 실제 행동으로 옮기기 위해 곧바로 업무 체크리스트를 만들었다.

주변에서는 나를 '파워 J'라고 하지만, 이렇게 구체적인 장치를 마련하지 않으면 기존의 습관을 고치기 어렵다고 느꼈다.

하반기 동안 이 체크리스트를 꾸준히 다듬으며, 함께 일하기 편한 동료로 성장해 나가기로 다짐한다.

---

마치며

8월은 수많은 시행착오를 통해 팀 안에서 함께 일하는 방식을 배우고 익히는 귀중한 시간이었다. 도움을 준 동료들에게 다시 한번 감사하며, 9월에는 더 나은 동료가 되기를 기대해본다.

• 9월 액션 포인트

개발 관련

• 사내 신 솔루션으로 마이그레이션 기능 빠르게 쳐내기 (10월 구솔루션 사용하지 않기 위해 달리자)
• 토스 클린 코드 공식문서 1회독 (9월)
• CLAUDE.MD나 .cursorrule 같은 설정 관심가지고 사용해보기

그외 (커뮤니케이션)

• 스프린트 시작 미팅 전에 명확한 일정 공유를 위해 업무 쪼개는 과정이 실행 시도
• 바바라 민토 논리의 기술 읽고 9월에 느낀점 정리
• 함께 자라기 책 읽고 한 가지 인사이트 적용해보기