[Sprint 백엔드 초급 프로젝트 13일차] Monew 중간 프로젝트 회고
Monew 중간 프로젝트 회고
1. 프로젝트 시작
이번 중급 프로젝트에서 Monew 서비스를 개발했다. 여러 뉴스 출처를 기반으로 관심사별 뉴스를 제공하고, 댓글, 알림, 활동 내역, 백업/복구까지 포함된 서비스였다. 나는 이 프로젝트에서 팀장 역할과 뉴스 기사 조회, 삭제, 뉴스 기사 뷰 등록, 백업/복구, CI/CD, AWS 운영 환경 관리를 담당했다.
처음에는 맡은 기능 범위도 넓고, 팀장 역할까지 함께 해야 해서 부담이 컸다. 초급 프로젝트 때보다 기능도 많았고, 단순 CRUD를 넘어서 배치, 배포, 백업/복구, 운영 환경까지 함께 고려해야 했기 때문이다. 그래서 프로젝트 초반에 기능 구현보다 서로 간의 충돌이나 기능 개발 중 다른 것에 신경이 쏠리는 것을 방지하기 위해 팀 규칙, 회의 방식, 역할 분담, 문서화 방식 등을 정리하는데 집중했다. 생각해보면 이 과정이 있었기에 각자 맡은 역할을 명확하고 수월하게 진행할 수 있었던 것 같다.
2. 좋았던 점
가장 좋았던 점은 팀원들 간의 큰 의견 충돌 없이 프로젝트를 진행할 수 있었다는 것이다. 각자 맡은 도메인이 명확했고, 매일 정기 회의에서 어제 한 일과 오늘 할 일을 공유하면서 진행 상황을 맞춰갈 수 있었다. 문제가 생기면 회의에서 바로 공유했고, 필요한 경우 담당자를 정해 해결하는 방향으로 잡았다.
초기에 계획했던 일정에 맞춰 대부분의 기능을 구현할 수 있었다는 점도 좋았다. 물론 중간중간에 예상하지 못한 오류나 배포 환경 문제가 있었지만 팀 전체가 각자의 역할을 끝까지 책임지려는 분위기였기 때문에 프로젝트가 수월하게 진행되었다고 느꼈다.
개인적으로는 뉴스 기사 목록 조회, 커서 페이지네이션, 백업/복구, CI/CD, AWS 배포까지 다양한 영역을 경험할 수 있었던 점이 좋았다. 하나의 기능을 구현하는 것에서 끝나는 것이 아니라 그 기능이 실제 배포 환경에서 정상적으로 동작하는지까지 확인해볼 수 있었다.
3. 배운 점
프로젝트에서 배운 점은 로컬에서 정상 동작하는 코드가 배포 환경에서도 그대로 동작한다고 보장할 수 없다는 것을 다시 한 번 느꼈다. 로컬에서는 문제없이 실행되던 기능도 ECS, RDS, S3, IAM 권한, 환경 변수, 포트 설정, 메모리 설정 같은 요소에 따라 배포 환경에서 실패할 수도 있다는 것이다.
처음에는 오류가 발생하면 코드부터 의심했다. 하지만 AWS ECS 배포 과정에서 RDS 보안 그룹, S3 환경 변수 파일, 컨테이너 포트 설정 같은 코드 바깥 부분의 요소들이 서비스 동작에 직접적인 영향을 주는 것을 경험했다. 이 과정을 통해 백엔드 개발은 애플리케이션 로직만 작성하는 것이 아니라 실제 서비스가 실행되는 환경까지 함께 이해해야 한다는 것을 다시 한 번 배웠다.
또 하나 기억에 남는 것은 팀원들이 진행한 K6 부하 테스트, Prometheus와 Grafana 기반 커스텀 메트릭 대시보드를 보면서 성능 테스트와 모니터링을 간접적으로 배울 수 있었다.
4. 기억에 남는 경험
가장 기억에 남는 경험은 뉴스 기사 복구 기능을 구현한 뒤 블로그 글을 정리하다가 문제를 발견한 일이다.
처음에는 S3에 백업된 뉴스 기사 데이터를 읽어 DB에 없는 뉴스 기사만 복구하면 된다고 생각했다. 그런데 블로그 글로 정리하면서 다시 보니, 뉴스 기사 자체만 복구하면 article_interests 매핑 정보가 복구되지 않는다는 문제가 보였다. 이 상태라면 복구된 뉴스 기사는 DB에 존재하지만 어떤 관심사와도 연결되지 않기 때문에 관심사 기반 필터링 조회에서 누락될 수 있었다.
이 경험에서 문서화가 단순 기록을 남기는 행동이 아니라는 것을 느꼈다. 구현한 코드를 말로 정리하다 보니, 지나쳐 버렸던 데이터 간의 관계가 보였다. 이후 백업 DTO에 관심사 ID 목록을 추가하고, 복구 시 기사와 관심사 매핑까지 함께 복구하도록 수정했다.
앞으로 기능 구현 후에는 흐름을 문서로 정리하면서 빠진 부분이 없는지 다시 점검하는 습관을 꾸준히 유지해야겠다고 느꼈다.
5. 아쉬웠던 점
가장 아쉬웠던 점은 코드 리뷰에 적극적으로 참여하지 못한 점이다. 내가 맡은 기능 구현과 배포 작업에 집중하다보니 PR 리뷰 알림을 늦게 확인하는 경우가 있었다.
또한, 코드 리뷰를 후 merge된 후에도 배포 환경에서 오류가 발생하는 경우가 있었다. 이때 코드 리뷰는 코드 스타일과 로직을 보는 것뿐만 아니라 실제 실행 환경에서 어떤 문제가 발생할 수 있는지에 대해서도 함께 고려해야 한다는 것을 느꼈다. 다음 프로젝트부터는 더 적극적으로 PR 참여하고 싶다.
팀장 역할에도 아쉬움이 있다. 프로젝트 초반에는 의견을 제시할 때 기준을 명확히 말하기 보다는 조심스럽게 되묻는 경우가 많았다. 물론 팀원들의 의견을 존중하려는 의도였지만, 팀장이라면 먼저 판단 기준을 제시하고 팀원들이 더 쉽게 결정할 수 있도록 도와야 한다는 점을 배웠다.
6. 프로젝트에서 개선하고 싶은 점
첫째, 코드 리뷰를 더 적극적으로, 잘 참여하고 싶다. 특히 코드 로직과 예외 상황, 배포 환경, 데이터 정합성, 성능 문제까지 함께 확인하는 리뷰를 하고 싶다.
둘째, 팀장 역할을 맡게 된다면 더 명확하게 기준을 제시하고 싶다. 팀원들의 의견을 묻는 것도 중요하지만, 결정이 필요한 상황에서 선택지를 정리하고 판단 기준을 먼저 제시하는 방식으로 팀원들의 의사결정을 돕고 싶다.
팀 Notion 주소
[SB10-5팀] Sprint Spring 백엔드 중급 팀 프로젝트
Leave a comment