[Sprint 백엔드 초급 프로젝트 2일차] 프로젝트 2일차, 프로젝트 구조와 방향 구체화
프로젝트 2일차, 프로젝트 구조와 방향 구체화
실제 개발에 필요한 구조와 방향을 구체화했다.
초기 세팅 범위부터 패키지 구조, ERD 검토, SQL 작성, 이슈 카드 세분화까지 개발 시작 전 정리되어야 할 기준들을 하나씩 확정했다.
초기 세팅 범위
가장 먼저 정리한 건 초기 세팅 범위였다.
내 생각은 분명했다. 기능 구현에 들어가기 전에 공통 개발 환경부터 맞춰야 이후 충돌을 줄일 수 있다는 점이었다. 이 부분에 대해 팀원들도 전부 동의했고, 초기 세팅 담당을 정한 뒤 필요한 작업들을 구체적으로 나눴다.
논의 결과, PostgreSQL과 MongoDB는 Docker로 실행 환경을 맞추고, 코드래빗은 PR 리뷰 효율을 위해 초기에 붙이기로 했다. 여기에 OpenAPI, 공통 예외 처리, 로깅의 최소 골격도 먼저 만들어두자는 방향으로 결정했다.
패키지는 도메인 중심
두 번째로는 패키지 구조를 정했다. 이 부분도 내가 먼저 방향을 제안했고, 팀원들은 전부 좋다고 해줬다.
기능 구현 전에 패키지 구조가 정리되지 않으면 코드가 어디에 들어가야 하는지부터 흔들리기 쉽다. 특히 이번 프로젝트처럼 사용자, 기사, 관심사, 댓글, 알림처럼 도메인이 분명한 서비스에서는 처음부터 구조를 애매하게 잡으면 나중에 유지보수가 훨씬 어려워질 수 있다.
논의 끝에 우리 팀은 도메인 구조를 기본으로 하고, 각 도메인 아래에 dto, entity, controller, service, repository를 두는 방식으로 정리했다. 공통 예외 처리나 OpenAPI, 로깅 설정은 global 패키지에 두기로 했다. 또 article_interests 같은 조인 테이블은 독립적인 entity라기보다 관계 표현에 가깝기 때문에, 비즈니스 기능 기준으로 각 도메인에 배치하기로 했다.
ERD 검토
세 번째는 ERD 초안 검토였다. 이 부분도 내가 먼저 기준을 잡아 이야기했고, 팀원들도 같은 방향이 괜찮다고 판단했다.
오늘 ERD를 검토하면서 가장 중요하게 본 건 “이 값을 정말 테이블에 저장해야 하는가?”였다. 예를 들어 기사의 view_count, comment_count는 조회 이력과 댓글 데이터로부터 계산 가능한 값이다. 그래서 이를 기사 테이블에 중복 저장하는 것은 불필요한 역정규화라고 보고 삭제하기로 논의했다. 같은 이유로 comment_statistics 테이블도 별도로 두지 않기로 했다
또 사용자와 관심사 관련 제약도 조금 더 분명하게 정리했다. users.nickname, users.password, interest.name의 길이 조건을 다시 확인했고, 알림 테이블의 resource_id는 resource_type과 실제로 일치하는지 비즈니스 로직에서 검증이 필요하다는 피드백도 반영하기로 했다.
검토한 ERD를 바탕으로 SQL 작성
이 부분 역시 내가 먼저 “검토된 ERD 기준으로 SQL을 이어서 맞추자”는 식으로 이야기했고, 팀원들이 전부 동의하면서 빠르게 넘어갔다.
추가로 interests.subscriber_count에는 DEFAULT 0을 넣기로 했다. 이런 작은 설정이 사소해 보일 수 있지만, 실제로는 초기 데이터 처리나 조회 안정성 면에서 꽤 중요하다.
이슈 카드 세분화
다섯 번째는 이슈 카드와 간트 차트 작성 방식이었다. 이 부분도 내가 먼저 세분화 방향을 제안했고, 팀원들이 좋다고 해줬다.
처음에는 기능 단위로만 이슈를 나누면 될 것 같았지만, 실제로는 그렇게 하면 진행 상황을 정확히 파악하기 어렵다.
그래서 R&R 기준으로 구현 범위를 나누되, 필요하면 controller, service, repository 수준까지 더 잘게 쪼개기로 했다. label도 Feature, Fix, Refactor, H(예상 소요 시간) 중심으로 정리했다.
요구사항의 TDD 적용 여부
여섯 번째는 팀원 질문에서 시작된 이야기였다. 요구사항에 TDD가 적혀 있으니, 정말 TDD 방식으로 프로젝트를 진행해야 하는지에 대한 질문이 나왔다.
내 생각은, 프로젝트 요구사항을 그대로 따르는 것도 중요하지만, 팀이 지금 감당 가능한 방식으로 해석하고 적용하는 것도 중요하기 때문에 이번 프로젝트에서는 형식적인 TDD 자체보다 기능을 구현하면서 테스트 코드를 함께 작성하는 방향이 더 현실적이라는 쪽이었다. 그래서 그 방향으로 이야기했고, 결국 팀도 그쪽으로 정리됐다.
MongoDB 초기 설정
일곱 번째는 MongoDB 초기 설정과 배포 방식에 대한 논의였다.
논의 내용은 주로 개발 환경에서 Docker 이미지를 쓸지, 운영 환경에서는 Atlas나 다른 방식을 고려할지에 대한 이야기였다. 강사님 권장 방향은 개발 환경에서는 Docker 공식 이미지를 사용하는 쪽이고, 운영 환경은 추후에 선택지를 비교해 보자는 정도로 정리됐다. 후보로는 MongoDB Atlas, EC2 위 컨테이너, DocumentDB 같은 선택지가 언급됐다.
오늘 회의 이후 진행 상황
회의만 하고 끝난 건 아니다. 지금은 뉴스 기사 단건 조회 구현에 들어간 상태다. 설정한 docker를 컨테이너로 띄워서 DataGrip과 연동시켰고, Controller 메서드까지 작성했다.
팀 Notion 주소
[SB10-5팀] Sprint Spring 백엔드 중급 팀 프로젝트
Leave a comment