문제되는 내용이 포함되어 있을 경우 수정/삭제 하겠습니다.

🌱 2주차 회고 (2026.04.20)

돌아보기

⬇️ 4/20 배포된 내 첫 배포 기후주간 캠페인 화면 ㅎㅎ

배포 전	배포 후

이번 한 주는 일주일 뒤면 바로 배포가 나갈 [ 동네걷기 X 기후환경부 기후주간 캠페인 ] 을 구현하는 주간이었다. 저번주 동안 익힌 기존 코드베이스 이해를 기반으로 프로모션 기간 1주일 동안만 UI를 변경하다가 기간이 지나면 바로 기존 UI로 돌아가야했다. 그만큼 금방 걷어질 코드기도 하고, 설정한 시간이 지나면 바로 기존 코드로 돌아와 문제없이 동작해야했으므로 다른 코드에 영향을 주지 않게 작업해야했다.

그리고 이 과정에서 간단한 요구사항에 비해 생각 못한 엣지케이스가 구현 중 계속 터져나왔다. 생각보다 동네걷기라는 서비스의 특성상 만보기와 같은 네이티브 기능으로 파생되는 복잡도나 리워드와 같은 다른 외부 맥락과의 강결합으로 인해 고려해야하는 점들이 많았다. 저번 주의 온보딩 주간동안 코드베이스를 간략하게 파악했을 때는 전혀 생각못했던 복잡도에서 많이 헤맸던 것 같다.

그래도 다른 코드에 영향이 안 가게 작업하다 보니 코드베이스의 이해도가 확실히 더 깊어졌고 작업 대상이었던 홈화면의 흐름을 꽤 확실히 숙지할 수 있었던 것 같다.

또, 직접 API 스펙을 yaml 파일로 작성해 제안드리고 PRD 와 피그마를 보면서 헷갈리는 점은 바로바로 질문드리는 등 백엔드, PD, PM 분들과 함께 협업하는 것에 익숙해질 수 있었다. 그리고 구현하다가 설계 방향에 있어서 임의로 결정하고 리뷰받기에는 변경사항이 커질 수도 있는 부분들은 작업 전 버디에게 바로 논의드리고, 매일 작업 현황을 공유하는 등 싱크를 꾸준히 맞추려고 노력했고 버디에게 칭찬받을 수 있었다.

월요일과 화요일은 11시가 넘어 퇴근했는데, 이는 구현의 범위가 절대적으로 많았다기 보다는 기존 코드베이스의 흐름을 완전히 이해해야 다른 코드에 영향을 안 주는 작업이 가능했기 때문에 이해하고 설계를 고민하는데에 시간이 많이 든 탓이었다. 큰 이슈가 없었는데도 예상한 시간보다 훨씬 오래걸려 야근을 하게된 점은 스스로 꽤 아쉽고 주눅이 들었다. 이대로면 체력도 문제지만 계속 야근이 습관이 되고 목표한 시간 내에 일을 쳐내지 못하면 정말 예기치 못한 이슈가 터졌을 때 야근이라는 카드를 쓸 수가 없기 때문이다. 신뢰가고 예측 가능한 인력이 되자는 목표를 위해서는 확실히 개선해야하는 점이었다.

수요일에는 버디와 싱크를 맞추고 코드를 함께 점검하는 시간을 가졌고 목요일, 금요일에는 사내 앱에 직접 배포해 PD, PM 의 QA를 받았다. QA 를 편하게 하실 수 있도록 작성했던 플러그인 코드가 뿌듯했다. 정확히는 뿌듯했었다. 금요일 퇴근 직전 버그를 발견하기 전까지...

QA 마지막 날인 금요일, 퇴근 시간을 앞두고 작은 버그 하나를 발견했다. 발견 당시에는 사소해 보였지만 원인을 추적하다 보니 결국 내가 QA 편의를 위해 작성했던 플러그인 코드에서 출발한 문제였다. QA 가 끝나면 지울 코드라는 생각에 학습 비용을 들이지 않겠다고 판단해 클로드에게 많이 맡겼었는데, 그 과정에서 외부 상태를 오버라이드해서 데이터를 주입하는 구조를 별 거부감 없이 accept 한 것이 화근이었다.

"어차피 지울 코드"라는 이유로 비즈니스 로직과 QA 로직이 한 데 섞여버렸고, 이로 인해 간헐적으로 상태가 꼬이는 문제가 발생하고 있었다. 운이 나빴다면 발견하지 못하고 그대로 배포될 뻔한 버그였다.

이미 6시가 가까워진 시간이었고 PR 리뷰도 끝나서 나는 접근성 개선 같은 소소한 작업만 마저 할 거라고 공유드렸던 상황이었다. 혼자 수습해보고 싶은 마음이 잠시 들었지만, 월요일이 배포라는 점을 생각하면 늦더라도 빨리 공유드리는 게 맞다고 판단했다. 죄송한 마음으로 버디에게 말씀드렸는데 곧장 자리로 오셔서 함께 코드를 봐주셨다.

가장 감사하면서도 죄송했던 건, 내가 당황해서 흐름을 따라가는 속도가 느려졌는데도 버디는 단 한 번도 재촉하지 않으시고 내가 끝까지 스스로 이해하고 정리할 수 있게 기다려주셨다는 점이다. 이미 퇴근 시간이 한참 지난 시간이었는데 옆에서 묵묵히 같이 남아주셨다.

집에 돌아오는 길에 이 사건을 곱씹으면서 한 주 동안 내가 어디까지를 스스로 했고 어디서부터 클로드에게 손을 놓았는지 돌이켜봤다. 초반 코드베이스 학습과 전체 플로우 설계는 직접 했지만, 구현을 시작하면서 러프했던 설계의 구멍을 마주칠 때마다 클로드를 부르기 시작했고, QA 플러그인부터는 거의 위임에 가까운 상태가 되어 있었다. 단순히 클로드를 많이 썼다는 게 문제가 아니라, 그 과정에서 "왜 이 설계인가"에 대한 판단을 스스로 내리지 않은 채 accept를 눌렀던 순간들이 있었다는 게 진짜 문제였다.

입사 전부터 다짐했고 원온원 때 버디께도 말씀드렸던 방향과 어긋나 있었다. 구현 속도라는 핑계로 설계의 고삐를 놓쳐버린 셈이다. 앞으로는 클로드에게 코드 생성을 맡기더라도 그 설계가 왜 그 모양이어야 하는지는 내가 직접 답할 수 있는 상태여야 accept를 누르겠다고, 그리고 테스트용이나 임시 코드라도 비즈니스 로직과 섞이는 순간엔 학습 비용을 들여서라도 스스로 이해하고 짜야겠다고 다짐했다.

일요일에도 배포 전 마지막 점검을 했다. 이 김에 플러그인 제거와 함께 리팩토링과 접근성 개선, 트리거 조건분기를 다시 정리하다가 또 새로운 케이스 하나가 눈에 들어왔다. 시간이 늦어 일요일에는 공유드리지 못하고 월요일 아침에서야 말씀드려 함께 해결했다. 엣지케이스를 배포 직전까지 계속 새로 발견하고 있다는 점은 분명히 반성해야 할 부분이다. 다음 과제부터는 구현 시작 전 설계 단계에서 엣지케이스 정리에 더 많은 시간을 쓰기로 마음먹었다.

우당탕탕 정신없었던 첫 배포지만 오전 11시에 배포했는데 3시간 정도 지난 오후 2시에 이미 이벤트 참여 댓글이 1만개 가까이 달릴 정도로 생각보다 뜨거운 관심을 받았다. 기사까지 났다!

정리

잘한 점

• 매일 일찍 출근해 하루 할 일을 정리하고 업무 중의 시간 측정 및 퇴근 전 하루 회고 작성 루틴을 계속 유지하고 있다.
• API 스펙을 직접 설계하고 닐과 논의하며 GET 없이 POST 하나로 가는 의견을 냈다.
• 다른 코드에 영향이 가지 않도록 신경 쓰면서 작업한 결과 웹뷰 기반의 코드베이스 이해도가 한층 깊어졌다.
• 구현 일정이 늦어지지 않게 풀리지않는 문제들은 30분만 혼자 고민해보고 버디에게 도움을 요청하는 시간 관리 룰을 적용했다.
• 버디 QA에서 프로모션 기간 내 깔끔하게 걷어지도록 작성한 점, QA용 플러그인을 꼼꼼히 만들고 진행상황을 중간중간 공유한 점에 대해 좋은 피드백을 받았다.
• 퇴근 직전에 발견한 상태 꼬임 이슈를 늦은 시간이라도 망설이지 않고 바로 버디에게 보고드려 함께 해결할 수 있었다.
• 한 주 동안 어디서부터 클로드에게 의존하기 시작했는지 스스로 흐름을 되짚어보며 점검했다.
• 사실 첫 과제라서 과제를 주실 때까지만 해도 버디가 함께 구현할 생각이었는데 생각보다 내가 꼼꼼히 구현해나가고 공유도 꾸준히 해서 나에게 맡겨주셨다고 했다. 엄청 뿌듯하고 기쁜 일이었다!

아쉬운 점

• 월요일과 화요일 모두 11시 넘어 퇴근했다. 큰 이슈가 없었음에도 예상보다 훨씬 오래 걸렸다는 점에서 자기 능력에 대한 과신이 있었다고 생각한다.
• 뽀모도로와 시간 트래킹이 무너졌다. 마음이 급해지면 가장 먼저 놓는 도구가 되어버렸다.
• 수요일 브랜치 머지 실수 여파와 vite 캐시 꼬임 디버깅으로 메인 업무 시간이 너무 밀렸다.
• QA용 플러그인을 "어차피 지울 코드"라는 생각으로 클로드에게 완전히 맡겼고, 외부 상태 오버라이딩 제안에 거부감 없이 accept 했다. 그 결과 비즈니스 로직과 QA 로직이 섞이며 간헐적인 상태 꼬임이 발생했다.
• 원온원에서 온보딩 기간 동안엔 클로드 사용을 지양하고 손코딩을 해보겠다고 말씀드렸는데, 기한이 다가오자 그 다짐과 어긋난 자신을 발견했다.
• 엣지케이스를 배포 전날까지 계속 새로 발견하고 있었다. 조기에 더 꼼꼼히 정리하지 못한 점이 아쉽다.

다음 주 개선 방향

• 가용 시간을 지금까지 잡아온 것의 절반으로 본다. 온보딩 기간임을 인정하고, 일정을 공유할 때도 이 기준으로 보수적으로 잡는다.
• QA 도구라도 메인 코드의 상태 관리에 손을 대는 순간 학습 비용을 들여야 하는 영역이다.
• 클로드에게 코드 생성을 맡기더라도 설계만큼은 확실히 내가 고삐를 쥐고 구현적인 코드 생성만 맡긴다. 어떤 것을 내가 잡고 어떤 것을 맡길지의 감각을 키워나간다.
• 엣지케이스 정리를 구현 시작 전 단계로 앞당긴다. (PRD 엔지니어 검토 단계에서부터 리뷰해 PM,PD 분들과도 더 적극적으로 소통하자.)
• 배포 직전에 새로 발견되는 케이스가 줄어들도록 설계 단계에서 시간을 더 쓴다.

2주차 회고글은 기후 캠페인이 배포되고 난 후 올리는 게 좋을 것 같아서 비공개 처리를 해두었다가 3주차가 끝난 지금에서야 공개로 돌리게 되었다