[Sprint 백엔드 중급 프로젝트 1일차] 스프링 백엔드 중급 프로젝트 시작, 팀 규칙부터 정리
스프링 백엔드 중급 프로젝트 시작, 팀 규칙부터 정리
이번에 스프링 백엔드 중급 프로젝트에서 팀장을 맡게 됐다. 프로젝트를 시작하면서 가장 먼저 한 일은 기능 구현이 아니라 팀 규칙을 정리하는 것이었다.
사실 처음에는 “아직 요구사항 정리도 안 했는데 규칙부터 정해야 하나?”라는 생각도 있었다. 그런데 요구사항을 분석하고 요구사항 정의서를 작성하고 바로 이어서 ERD를 작성하는 데까지 시간이 많이 걸리기 때문에 빠르게 끝낼 수 있는 것부터 끝내는 것이 좋다고 생각이 들었다.
그래서 우리 팀은 프로젝트 초기에 협업 방식, 기술 규칙, 커밋/브랜치/PR 규칙, 회의 방식까지 먼저 정리했다.
선택한 프로젝트 주제
우리 팀이 선택한 주제는 모뉴(MoNew)다.
여러 뉴스 API를 통합해서 사용자에게 맞춤형 뉴스를 제공하고, 댓글과 알림 같은 소셜 기능까지 포함하는 서비스다.
단순히 CRUD에서 끝나는 프로젝트가 아니라 뉴스 기사 수집 배치, 관심사 기반 필터링, 댓글과 알림, 사용자 활동 내역, 그리고 백업/복구 기능까지 포함되어 있다. 특히 기사 데이터의 백업과 복구, 그리고 활동 내역 조회 최적화처럼 단순 기능 구현 보다 고민이 필요할 것 같았다.
협업과 소통 도구
소통은 Discord, 팀 문서는 Notion, 코드 협업은 GitHub를 사용하기로 했다. 정기 회의는 평일 오전 10시에 진행하고, 매일 “어제 한 일 / 오늘 할 일”을 공유하기로 했다. 회의록은 서기를 돌아가면서 작성하되, 구현 관련 데일리 스크럼은 각자 작성 후 서기가 다듬는 방식으로 정리했다.
또 강사님 피드백을 통해 초기에 정해야 할 세팅도 확인했다. DB 세팅, Docker, 코드래빗 설정, GitHub-Discord 연동 같은 작업도 빨리 담당자를 정해야 했다. 기능 구현만 프로젝트의 시작이라고 생각하기 쉬운데, 실제로는 이런 초기 세팅이 전체 생산성을 꽤 많이 좌우한다.
팀 규칙을 먼저 정한 이유
우리 팀이 정한 규칙은 거창하지 않았다. 오히려 기본적이지만 꼭 필요한 것들에 가까웠다.
먼저 커뮤니케이션 규칙으로는 불참해야 할 일이 생기면 하루 전에 말하기, 문제가 생기면 즉시 공유하기, 회의록을 돌아가면서 작성하기 같은 내용을 정했다. 또 코드 측면에서는 Google Java Style Guide를 적용하고, 메소드마다 주석을 작성하기로 했다. Git 규칙도 함께 정리해서 커밋 메시지 템플릿, 브랜치 전략, PR 템플릿, 리뷰 방식까지 통일했다.
요구사항 정의서 작성
팀 규칙을 정한 뒤에는 요구사항 정의서 작성에 들어갔다. 이 단계에서는 단순하게 제공된 문서를 읽는 작업이 아니라, 우리 팀 프로젝트의 언어로 다시 정리하는 과정이었다.
이전에 초급 프로젝트를 진행했을때 보다 구현 기능 범위가 더 넓어졌기 때문에 요구사항을 정리하기 전에는 어떤 구조인지, ERD를 어떻게 구성해야 할지 판단하기 어려웠다.
요구사항 정의서를 작성하면서 팀 전체 구현 범위에 대해 확인할 수 있었고, 세부 기능 분리에도 훨씬 쉬워졌다.
역할 분담 나누기
팀 규칙과 요구사항 정리가 끝난 뒤, R&R을 나눴다.
이 순서로 진행한 이유는 요구사항 정의서를 만들지 않고 R&R을 만들게 되면 균등하게 배분한 것처럼 보이더라도 실제 난이도나 범위가 달라질 수 있다. 반대로 요구사항을 먼저 정리하면 각 부분의 연결 관계가 보이니 누가 어떤 부분을 맡을 것인지 분명하게 정할 수 있다.
- 박정현: 뉴스 기사 관리(삭제, 목록 조회, 백업 및 복구, CI/CD, AWS 관리)
- 박나경: 댓글 + 알림 관리
- 박린: 관심사 관리
- 박성국 : 뉴스 기사 관리(엔티티 설계, API 수집)
- 이규빈 : 사용자 + 활동 내역 관리
각자 맡은 영역이 비교적 분명해서, 이후 작업을 이슈로 나누거나 일정 계획을 잡을 때 기준점이 생겼다.
팀장을 맡고 나서 제일 먼저 보인 내 문제
이번에 팀장을 맡으면서 협업 문서나 역할 분담만큼이나 크게 느낀 게 하나 있었다. 바로 내 말버릇이다.
나는 의견을 말할 때 끝을 분명하게 맺지 못하고 흐리거나, “이런 방향도 괜찮을 것 같은데… 어떤가요?”처럼 계속 되묻는 습관이 있었다. 조심스럽게 말하려는 의도였지만, 팀장 역할에서는 이 습관이 썩 좋은 방식은 아니라는 걸 느꼈다.
이번 프로젝트를 하면서 내가 고쳐야 할 점은 분명해졌다.
- 의견을 묻더라도 먼저 기준을 제시할 것
- 말끝을 흐리기보다 “~데, 다른 의견이 있으신가요?”처럼 명확하게 말할 것
팀 Notion 주소
[SB10-5팀] Sprint Spring 백엔드 중급 팀 프로젝트
Leave a comment