들어가며
8주간의 DND 여정과 어디GO의 MVP 개발이 공식적으로 마무리되었다. 첫 글에서 무엇을 만들었는지 이야기했다면, 이번 글에서는 그 과정 속에서 무엇을 배우고 느꼈는지를 KPT 회고를 바탕으로 정리하려고 한다.
Keep
프로젝트의 과정과 결과에 아쉬움이 있지만, 과정 속에서 분명히 얻은 것들이 있었다. 개인의 기술적 성장과 팀에 기여했던 경험을 중심으로 정리했다.
1. 인프라 전반적인 경험
이번 프로젝트에서 가장 크게 성장한 부분을 꼽으라면 단연 인프라 파트다. AWS 위에 VPC 네트워크를 설계하고, 보안을 고려해 EC2는 Public Subnet에, RDS는 Private Subnet에 배치하는 등 Best Practice를 직접 적용해봤다. 또한 GitHub Actions로 CI/CD 파이프라인을 구축하며 코드 푸시부터 배포까지의 전 과정을 자동화했다. 이 과정에서 겪은 수많은 트러블슈팅(ARM 아키텍처 호환성, IAM 권한 문제 등)은 AWS와 Docker에 대한 이해도를 크게 높여준 계기가 되었다.
2. 안정적인 데이터 파이프라인 구축
매일 수천 건의 공공데이터를 수집하는 기능은 서비스의 핵심이었다. 단순히 @Scheduled로 API를 호출하는 것을 넘어, 대용량 데이터를 안정적으로 처리하기 위해 Spring Batch를 도입했다. Chunk 지향 처리, Job 실패 시 재시작 기능 등 Spring Batch의 핵심 가치를 직접 경험하며 안정적인 ETL 파이프라인을 내 손으로 완성했다는 점은 큰 성취였다.
3. 생산성을 높여준 도구의 적극적인 활용
코드 리뷰 문화가 정착되지 않은 상황에서 코드 품질을 유지하기 위해 AI 코드 리뷰 툴인 CodeRabbit을 적극적으로 활용했다. PR을 올리면 10분 내에 리뷰를 받을 수 있어, 컨벤션부터 잠재적인 버그까지 빠르게 피드백을 받고 수정하는 사이클을 만들 수 있었다.
CodeRabbit 리뷰
또한 개발 후반부에 도입한 Sentry는 예상치 못한 런타임 에러를 실시간으로 추적하고 Slack으로 알림을 보내주어, 큰 불편을 겪기 전에 문제를 인지하고 빠르게 대응하는 기반이 되어 주었다.
Slack으로 받은 Sentry 알림
4. 적극적인 문서화와 정보 공유
팀원 모두가 같은 정보를 바라보는 것이 원활한 협업의 시작이라 믿는다. 이를 위해 노션(Notion)을 적극적으로 활용하여 API 명세, 각종 가이드 등을 꾸준히 문서화하고 팀원들에게 공유했다.
Notion에 작성한 참고자료
특히 팀원에게 필요한 정보를 최대한 조사하여 슬랙에 공유함으로써, 불필요한 커뮤니케이션 비용을 줄이고자 노력했다.
5. 주도적인 팀 기여와 문제 해결
주어진 역할에만 머무르지 않고, 팀의 문제를 해결하기 위해 주도적으로 움직였다. 프로젝트 후반 팀원 간의 소통이 부족하다고 느껴 데일리 스크럼을 제안했고 이를 통해 팀원간 소통 문제를 일부 해결할 수 있었다.
또한 프론트엔드 개발자와 논의가 필요한 사항(기능 구현 방식, API 명세 변경 등)에 대해서는 슬랙 채널에서 적극적으로 의견을 나누었다.
기능 구현 관련 논의
API 명세 변경 관련 논의
그 외에도 SNS 홍보물 제작과 같은 작업도 주도적으로 담당하며 팀에 기여하고자 했다.
Problem
팀과 개인의 관점에서 아쉬웠던 점들을 되짚어봤다. 이를 통해 프로젝트의 결과가 만족스럽지 않았던 원인을 찾으려고 했다.
1. 목표, 소통, 개선 시스템의 부재
가장 큰 아쉬움은 공동의 목표와, 그 목표를 위한 시스템이 부재했다는 점이다. 프로젝트 전체의 비전에 대한 팀원 간의 합의가 부족했고, 이는 점차 참여도와 몰입도의 차이로 이어졌다. 단적인 예로, 주간 회의 시간을 정할 때 6명 전원이 가능한 시간이 한 시간도 없는 경우가 다반사라 회의를 하는 것도 쉽지 않았다.
소통 시스템의 부재도 문제를 악화시켰다. 많은 논의들이 공개 채널이 아닌 개인간의 DM으로 오가면서 서로의 진행 상황을 파악하기 어려웠다. DND 운영진이 가이드로 제시한 주간 미션도 제대로 활용하지 못했다. 특히, 중간 회고를 통해 문제점을 도출하고도 이를 개선하려는 후속 조치가 전혀 없었던 점은 뼈아팠다. 결국 ‘문제를 인지하고도 해결하지 않는’ 팀의 관성은 프로젝트 막바지에 큰 어려움으로 돌아왔다.
2. 데드라인 없는 개발과 방치된 작업들
Jira를 적극적으로 활용하지 않았고, ‘언제까지 무엇을 하자’는 명확한 데드라인 설정도 없었다. ”API는 언제까지 완성하고, 연동은 언제까지 시작하자” 와 같은 구체적인 마일스톤이 부재하다 보니 작업은 계속해서 지연되었다. 결국 마감 기한이 임박해서야 한 팀원이 맡은 기능이 전혀 구현되지 않았다는 사실을 알게 되었고, 일부 기능은 미구현 상태로 프로젝트를 마무리해야 했다.
3. 코드 리뷰 문화의 부재
처음 몇 번 팀원에게 코드 리뷰를 요청했지만, 피드백을 받기까지 며칠씩 걸리는 일이 반복되었다. 촉박한 기한 때문에 결국 동료 코드 리뷰는 포기하고 CodeRabbit으로 이를 대체하였다. 팀원과 기술적인 논의를 하고, 더 나은 코드를 만들어나가는 경험의 부재는 큰 아쉬움으로 남는다.
4. ‘언젠가 하겠지’라며 미뤄뒀던 기술 부채
Flyway 도입을 계속 미루다 결국 적용하지 못했다. “새로운 기술을 학습할 시간이 부족하다”며 DDL을 직접 실행하는 방식을 택했지만, 그건 나의 핑계였던 것 같다. 지금 생각해보면 Flyway를 초기에 도입하여 DB 스키마 변경 이력을 처음부터 관리하는 것이 장기적으로는 훨씬 효율적이었을 것 같다. 또한 개발 일정에 쫓겨 모니터링 시스템 구축과 성능 테스트를 진행하지 못한 것도 기술적인 부채로 남았다.
Try
이번 프로젝트의 아쉬움을 발판 삼아, 다음 프로젝트에서 시도해 볼 것들을 구체적으로 정리했다.
1. 투명한 소통과 명확한 마일스톤 설정
다음 팀 프로젝트에서는 본격적인 개발에 앞서 반드시 팀의 규칙을 정할 것이다.
- 팀 그라운드 룰 설정: ”주 1회 회의 필수 참석”, “모든 논의는 공개 채널에서”, “PR은 24시간 내 리뷰” 등 구체적인 규칙을 설정하여 최소한의 협업 문화를 구축하겠다.
- 데일리 스크럼 도입: 프로젝트 초기부터 매일 정해진 시간에 짧게 데일리 스크럼을 진행하여, 서로의 진행 상황과 이슈를 신속하게 공유하겠다.
- 스프린트 도입: 전체 프로젝트를 1~2주 단위의 스프린트로 나누고, 각 스프린트마다 명확한 데드라인과 목표를 설정하겠다. 협업 툴을 활용해 모든 작업을 투명하게 관리하고 주기적으로 진행 상황을 점검하겠다.
2. 기술 부채를 남기지 않는 습관
프로젝트의 안정성과 직결되는 기술은 ‘나중에’가 아닌 ‘처음부터’ 도입하는 것을 원칙으로 삼겠다. 또한 프로젝트 기간 중 일부를 기술 부채를 해결하는 날로 정해, 평소 미뤄두었던 부채를 완전히 해결하는 것도 좋을 것 같다.
지금 하고있는 문서화 작업이 끝나면 곧바로 모니터링 시스템을 구축하고, 부하 테스트를 진행하여 시스템의 성능을 객관적으로 측정하고 개선해나가는 사이클을 경험해보고자 한다.
3. 더 나은 아키텍처에 대한 고민
현재는 단일 EC2 인스턴스에서 애플리케이션을 실행하는 단순한 구조다. 다음 스텝으로는 Nginx를 리버스 프록시로 도입하여 무중단 배포를 구현하고, 시스템의 안정성을 한 단계 높이는 아키텍처 고도화를 진행할 계획이다.
마치며
어디GO는 아쉬움이 많이 남는 프로젝트다. 여태 해왔던 프로젝트들과는 달리 개발 외적인 부분에서 고민이 많기도 했다. 8주가 끝나고 디벨롭 계획을 세우는 다른 일부 팀들을 보니 씁쓸함도 조금 있다. 하지만 실패 속에서 더 많은 것을 배운다는 말처럼, 이번 경험은 ‘좋은 팀’에 대해 고민을 해볼 수 있는 기회이기도 했다.