안녕하세요, 데이트팝 백엔드 개발자 이찬영입니다.

킥오프에서 Lottie를 선택하고 기술 스택을 결정한 뒤, 이제 "언제까지 만들 것인가"를 정하는 Preview 회의 단계입니다. Preview 회의는 개발팀 전체가 모여 각자의 작업을 구체화하고 일정을 추정하는 자리입니다. 혼자 추정하면 놓치기 쉬운 부분을 팀이 함께 검토합니다.

Preview 회의 전 준비: 개발기능정의서

Preview 회의 전에 먼저 할 일이 있습니다. 킥오프에서 정한 방향을 실제 개발 작업으로 나누는 것입니다.

개발기능정의서는 필요한 기능을 구체적인 개발 항목으로 정리한 문서입니다.

예를 들어 "지도 화면 개선"이라는 큰 목표는 이렇게 실제 코드로 구현할 작업들로 나뉩니다:

  • 지도 API 연동
  • Lottie 애니메이션 처리
  • 필터링 로직 구현
  • 위치 기반 데이터 로딩

각 항목마다 필요한 일수를 추정하는데, 이를 스토리 포인트라고 부릅니다. 우리 팀에서는 1포인트를 1일로 계산합니다.

저는 백엔드 작업을 보며 총 28포인트, 즉 28일이 필요하다고 추정했습니다.

추정은 혼자가 아닌 팀으로

일정 추정은 두 단계로 진행됩니다.

1단계: 개인 추정
먼저 각자 맡을 작업에 필요한 일수를 개별적으로 추정합니다. 처음엔 "혹시 모르니 여유있게 잡자"는 생각도 들었습니다. 예상보다 시간이 걸리면 어쩌나 하는 걱정 때문이었습니다.

2단계: 팀 검토
그런데 Preview 회의의 핵심은 여기서부터입니다. 팀 전체가 모여 각자의 추정을 함께 검토합니다.

팀장님이 제 추정을 하나씩 확인하며 질문하셨습니다. 처음엔 "못 믿으시나" 싶었는데, 다른 팀원들의 추정도 똑같이 검토하는 걸 보고 이해했습니다. 이건 감시가 아니라 코드 리뷰의 일정 버전이었습니다.

팀 검토를 거치니 이런 일들이 일어났습니다:

  • iOS 개발자: "이 부분은 프론트에서 처리할 수 있어요"
  • Android 개발자: "이 작업은 제가 먼저 끝내야 진행 가능하죠?"
  • 팀장님: "이건 라이브러리 쓰면 더 빨라요"

혼자 추정할 때 못 봤던 것들이 보이기 시작했습니다. 결과적으로 몇몇 작업의 일정이 조정되었고, 작업 간 의존성도 명확해졌습니다.

최종적으로 확정된 28포인트는 팀 전체의 검토를 거친 결과입니다.

Preview 회의의 목적

Preview 회의는 프로젝트의 구체적인 실행 계획을 세우는 자리입니다.

킥오프에서 "무엇을, 왜"를 정했다면, Preview에서는 "누가, 언제까지, 어떻게"를 정합니다. 프로젝트의 목표를 확인하고, 개발팀이 같은 방향을 바라보고 있는지 점검하는 시간이기도 합니다.

회의 결과:

  • 전체 28포인트 (28일) 작업
  • 2주 스프린트 × 2회로 진행
  • 각 스프린트별 목표 설정
  • 작업 간 의존성 확인

이제 본격적인 스프린트가 시작됩니다.

백엔드 개발 준비: FastAPI 선택

Preview 회의 이후 본격적인 개발 전, 백엔드 프레임워크를 결정해야 했습니다.

FastAPI vs Django Rest Framework

두 프레임워크를 비교했고, FastAPI를 선택했습니다.

비교 포인트:

  • 비동기 처리: FastAPI는 네이티브 async/await 지원, DRF는 제한적
  • 성능: FastAPI가 Starlette 기반으로 더 빠름
  • API 문서화: FastAPI는 Swagger UI 자동 생성, DRF는 수동 설정 필요
  • 학습 곡선: FastAPI가 더 낮음 (미니멀한 구조)
  • 개발 속도: 2주 스프린트에서 FastAPI가 빠른 프로토타이핑에 유리

선택 이유:

  1. 성능: 지도 데이터 요청이 많아 비동기 처리가 필수적
  2. 협업: Swagger 자동 생성으로 프론트엔드와 API 스펙 공유가 용이
  3. 일정: 2주 스프린트 안에 빠른 프로토타이핑이 가능

Django도 훌륭한 프레임워크지만, 이번 프로젝트의 요구사항(고성능 API + 빠른 개발)에는 FastAPI가 더 적합했습니다.

Preview 회의 전까지 다른 부서의 요청사항도 처리하며 개발 준비를 마쳤습니다.

Preview를 마치며

Preview 회의를 거치며 막연했던 프로젝트가 구체적인 일정과 작업으로 나뉘었습니다.

28일, 2주 스프린트 2번. 쉽지 않은 도전이지만, 혼자가 아닙니다. 팀 전체가 제 일정을 검토해주었고, 제가 놓친 부분을 다른 팀원들이 짚어주었습니다. 작업 간 의존성을 함께 파악하고, 현실적인 일정을 만들어냈습니다.

Preview 회의에서 배운 것:

1. 추정은 혼자 하는 게 아닙니다
팀 검토를 통해 더 정확한 일정이 나옵니다. 내가 놓친 부분을 동료가 발견하고, 과대/과소 추정을 함께 조정합니다.

2. 일정은 감시가 아니라 계획입니다
"언제까지 할 거야?"가 아니라 "어떻게 도울까?"의 시작점입니다. 작업 간 의존성을 파악하고, 서로 협력할 지점을 찾는 과정입니다.

3. Preview는 킥오프와 다릅니다
킥오프가 "왜, 무엇을"이라면, Preview는 "누가, 언제, 어떻게"입니다. 큰 그림을 구체적인 실행 계획으로 만드는 단계입니다.

프로젝트는 8월 26일 출시를 목표로 하고 있습니다. 좋은 팀원들과 함께라면 목표를 달성할 수 있을 것입니다.

다음 글에서는 첫 번째 스프린트 경험을 공유하겠습니다.