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

🌱 3주차 회고 (2026.04.26)

돌아보기

기후부 캠페인 성황리에 종료!

월요일에 배포한 동네걷기 기후부 캠페인이 성황리에 잘 마무리되었다!

캠페인 마지막 날 모달	캠페인 종료 후 UI 전환 성공

마지막 날의 보상은 스탬프 모달 후 종료 안내 바텀시트가 올라온 뒤 마일스톤 위의 나무아이콘이 사라져야했고

마지막 날의 자정이 지나 홈화면에 들어오면 기후부 캠페인 관련 코드가 싹 걷어지고 기존의 기본 UI 로 돌아와야했는데 다행히 둘 다 무사히 성공했다.

위 영상은 혹시라도 코드가 걷어질 때 기존 화면에 문제가 생길까봐 바로 써보면서 찍어둔 영상이다. 무사히 코드가 걷어진 걸 확인하고 나서도 불안해서 1시간 정도는 계속 이벤트 로깅을 관찰하고 온콜대기를 했다. 하지만 정말 다행히도 그런 불행은 일어나지 않았다...ㅎㅎ

첫 과제로 진행하고 배포한 기후부 캠페인의 반응이 굉장히 좋았다.

당근은 기후에너지환경부, 한국환경보전원과 '탄소중립·녹색성장 대국민 인식 제고 및 정보 제공 협력을 위한 업무협약'을 30일 체결한다고 밝혔다.
...
이는 세 기관이 지난 20~26일 '지구를 위한 동네걷기' 캠페인을 진행해 총 47만4844명이 참여한 성과를 기반으로 진행한다.

출처: https://www.etnews.com/20260430000061

동네걷기 캠페인의 성과를 기반으로 4월 30일에 당근이 기후에너지환경부, 한국환경보전원과 '탄소중립·녹색성장 대국민 인식 제고 및 정보 제공 협력을 위한 업무협약'을 체결한다는 내용의 보도자료까지 발표되었다.

이렇게 좋은 성과가 나온 프로모션을 개발해서 배포할 수 있었던 게 뿌듯하고 기쁜 걸 넘어서 엄청 신기한 기분이다. 코드 리뷰 꼼꼼히 봐주시고 배포 마지막까지 함께 엣지케이스 대응해주시며 믿고 맡겨주신 버디께 정말 감사한 마음이다.

---

이슈 대응과 재발방지책 제안

기후부 캠페인이 진행되는 동안 모니터링을 지속했다. 그리고 중간에 한 번 이슈를 겪어 죄책감과 책임감을 많이 느낀 일이 있었다.

캠페인 둘째 날, 진행 날짜 정책값이 잘못 설정되어 일부 유저들에게 이벤트 종료 바텀시트가 미리 노출되는 이슈가 있었다. 캠페인 진행 날짜를 API로 받아오는 구조이다 보니 그 값이 어디서 관리되는지 충분히 확인하지 못했던 것이 원인이었다.

해당 이슈의 확인이 늦어 당일 연차 휴가 중이셨던 버디가 발견하시고 수습해주시고 말았다. 확인이 늦은 것, 버디의 온콜을 늦게 확인해 결국 휴가 중이신 버디가 수습하게된 점이 너무 죄송스럽고 반성되어, 이 사건을 계기로 개인으로서는 에러 모니터링 뿐만 아니라 의도한 대로 사용자 이벤트가 집계되고 있는지 사용자 모니터링도 함께 해야겠다고 다짐했고, 팀에는 재발방지책을 제안드렸다.

PRD 단계에서 정책성 값의 관리 주체를 명시하자는 것이었다. 이런 값들은 운영 중에 변경될 수 있는데, 어디서 제어되는지가 PRD에 명시되어 있다면 엔지니어가 검토 단계와 배포 단계에서 한 번 더 의식해서 확인할 수 있겠다고 생각했다.

서버에서 받아오는 값이라고 해서 모두 백엔드 DB에서 관리되는 게 아니라는 것과 다른 경로로도 조작될 수 있다는 것을 알게 된 좋은 러닝 포인트였다. 그리고 이슈를 추적하면서 빅쿼리로 이벤트 로깅 집계를 확인하는 방법도 새로 학습했다.

---

리팩토링 방향성 잡기

이번 주 동안은 동네걷기 도메인의 리팩토링 포인트도 함께 정리했다. 아무리 다양한 프로모션이 진행되더라도 바뀌지 않을 비즈니스 로직의 뼈대를 발라내고, 도메인의 본질적인 복잡도가 어디에 있는지 짚어보는 작업이었다. 기후부 캠페인을 구현하면서 느껴지는 복잡도들을 중간중간에 메모해두었었는데 리팩토링 방향성에 도움이 됐다.

만보기 대시보드의 흐름을 그림으로 그려가며 정리해봤는데, 어디에서 강한 결합이 생겨있고 어떤 로직들이 서로 다른 관심사를 가진 채 섞여있는지 명확하게 보였다. 역시 전체 플로우를 파악할 때 그림으로 그려보는 게 가장 좋은 방법인 것 같다.

이렇게 정리한 리팩토링 포인트들을 버디에게 공유드렸고, 공감대가 있었던 부분을 내가 맡아 리팩토링하기로 했다. 매일 아침 버디께 싱크 공유를 드리며 날카로운 피드백을 받고 추상화를 거듭하다 보니 본질적인 문제로 추상화해 재정의할 수 있었다.

테크스펙 초안을 쓰는 데 생각보다 오래 걸렸지만, 작성하면서 스스로 의문이 생기고 설계의 빈틈이 보여서 계속 보완해나간 시간이었다.

이 때 기분이 좋았던 일이 하나 있었는데, 테크스펙을 작성하다가 이전에 비슷한 고민으로 팀원분이 작성하셨던 문서를 발견했다. 풀이 방법은 달랐지만 문제 정의와 아이디어 시작까지 비슷하게 도출되었다는 게 신기하고 뿌듯했다. 내가 문제 정의를 제대로 하고 있었구나 하고 확인받는 느낌이었달까!

---

첫 온콜 대응

이번 주에는 첫 온콜 대응도 해봤다(?) 내가 맡은 동네걷기 도메인은 아니었고, 다른 프론트엔드 분들이 출근하시기 전에 백엔드 분이 발견한 이슈를 보고 원인을 파악해 출근 중이신 팀분들께 원인을 공유드렸다. 칭찬 받았따.

내 도메인이 아니어도 가장 의심가는 원인을 생각해 코드 흐름을 따라가서 원인을 짚어낼 수 있었다는 게 뿌듯했다.

---

정리

이번 주에 주로 한 일은 기후캠페인 모니터링과 함께 기존 코드의 복잡도가 뭉쳐있는 부분을 리팩토링하기 위해 설계하는 일이었다.

잘한 점

• 캠페인 둘째 날 발생한 정책값 이슈에 대해 단순 수습에 그치지 않고, PRD 단계에서 정책성 값의 관리 주체를 명시하자는 팀 차원의 재발방지책을 제안드렸다.

• 동네걷기 도메인의 플로우를 그림으로 그려가며 정리해서, 결합과 관심사 분리 지점을 명확히 짚어내고 리팩토링 포인트를 도출했다.

• 매일 아침 버디에게 싱크 공유를 드리며 더 나은 풀이방법을 위해 마인드맵을 그려가며 추상화를 거듭한 끝에, 더 본질적인 문제로 재정의할 수 있었다. 꽤 뿌듯한 과정이었어서 작성하고있는 테크스펙을 나중에 따로 포스팅할 수 있으면 좋겠다.

• 이전에 팀원분이 비슷한 고민으로 작성하신 테크스펙을 발견했는데, 문제 정의와 핵심 아이디어까지 비슷하게 도출되어서 내 문제 정의 방향성에 확신을 얻었다.

• 내 도메인이 아닌 영역의 온콜 이슈를 출근 시간 전에 원인 파악해서 팀에 공유드렸다. 칭찬도 받아서 뿌듯했다.

아쉬운 점

• 캠페인 진행 날짜를 API로 받아오는 구조였는데, 그 값이 어디서 관리되는지 충분히 확인하지 않고 넘어갔던 것이 이슈의 직접적인 원인이었다.

• 테크스펙 공유가 늦어졌다. 점심 직후에 드리려고 했는데, 작성하다 보니 스스로 의문점과 설계의 빈틈이 계속 보여 보완하다가 퇴근 시간이 거의 다되어서야 공유드릴 수 있었다.

• 설계와 아이디어를 다듬는 단계에서 시간이 너무 오래 걸린다는 느낌을 받았다.

• 고정 일정이 많은 날은 회의 사이사이에 생각의 맥락이 끊겨, 깊이 몰입해야 하는 작업의 진척이 더뎠다.

다음 주 개선 방향

• 테크스펙이나 설계 문서를 공유할 때, 100% 완성도를 추구하기보다 이른 단계에서 초안을 공유하고 피드백을 받아 발전시키는 방향으로 일해보기

• 회의가 많은 날은 짧은 호흡의 작업을, 연속 시간이 확보된 날은 깊은 사고가 필요한 설계 작업을 배치하는 식으로 요일별 작업 성격을 맞춰 배분해보기

• 설계를 하고 리팩토링을 하는 업무에는 뽀모도로나 타이트한 시간 관리가 없어도 될 것 같다. 오히려 시간 측정이 몰입도를 방해한다는 생각이 들었다. 태스크를 잘게 쪼개 구현을 빠르게 쳐내야하는 환경일 때만 다시 시행하고 리팩토링 주간에는 뽀모도로를 통한 시간 추적 및 관리를 폐기한다.