1. 개발 인원 소개
사람마다 도메인 하나를 소유한다. 자기 도메인의 로드맵이 자기 작업의 기준이고, 범위 · 마일스톤 · 작업 큐 · 완료 기준이 전부 거기에 있다. 소유 폴더 밖은 자기 것이 아니다.
infra/ · .github/ · docker-compose · AWS
전원이 딛는 바닥. 의존이 없는 대신 전원의 선행 조건이 된다.
역할 상세 →2. 역할 분담
| 담당 | 도메인 | 담당 업무 | 기술 스택 |
|---|---|---|---|
| 재우 A 이재우 팀장 |
인프라 · 총괄 | AWS · 배포 · CI/CD · GitHub 설정 · 스키마 관리. 총괄로서 인터페이스 리뷰 · 통합 · 발표 | Docker, GitHub Actions, EC2, S3, SES, SQS |
| 우정 B 이우정 |
백엔드 | 인증 · 권한, 공고 · 지원자 · 평가 API, 단계 전환, 검색 · 인덱스 튜닝, 파일 · 메일 코드 | FastAPI, PostgreSQL |
| 소연 D 박소연 |
프론트엔드 | React 뼈대 · 공통 컴포넌트, 전 화면 구현과 API 연동, 칸반 드래그 · 낙관적 업데이트, 반응형 | React, Vite, TypeScript, Vercel |
| 수택 E 진수택 |
에이전트 | 이력서 구조화 추출 · 요약, 도구 호출 에이전트, 에이전트 API와 UI 스펙, (여유) 음성 입력 · RAG | Claude API (Python SDK) |
| 민아 C 김민아 |
앱 (모바일) | 모바일 네이티브 앱 — 로그인, 공고 · 지원자 조회, 단계 변경, 평가 작성, 이력서 열람 | Flutter, Dart, Android |
3. 의존 구조
아래로 갈수록 남이 기다리는 쪽이다. 이 순서가 곧 일정의 임계경로이고, 각 도메인의 리스크 대응도 여기서 나온다.
재우 A 인프라 — 아무에게도 의존하지 않는다. 그래서 전부의 선행 조건이 된다. 여기가 밀리면 나머지 넷이 대기한다.
우정 B 백엔드 — 인프라의 접속 정보와 AWS 리소스를 받고, 클라이언트 3종에 API를 제공한다. 여기가 늦으면 나머지 전부가 목데이터에 갇힌다.
소연 D 프론트엔드 — 초반 두 마일스톤을
목데이터로 진행해 백엔드를 기다리지 않는다. 대신 목데이터 필드명을 ERD와 동일하게
맞춰 연동이 필드 교체만으로 끝나게 했다.
민아 C 앱 — 소비만 하고 제공은 없다.
격리 수준이 가장 높아 앱이 실패해도 다른 파트가 멈추지 않는다.
수택 E 에이전트 — 백엔드 API를 도구로 호출하는 동시에, 지원서 접수 흐름이 부를 요약 생성 함수를 백엔드에 제공한다. 함수 시그니처는 두 오너 간 인터페이스 PR로 합의한다.
에이전트와 앱은 초기 버전(09. 04.) 범위 밖이다. 두 트랙 모두 코어 기능이 항상 우선이고, 코어 데모는 두 트랙 없이도 완결된다. 그래서 전환기(∼09. 04.) 동안 두 담당자는 자기 트랙과 병행해 백엔드 큐를 나눠 맡았다 — 앱 담당자의 경우 자기 트랙의 선행 조건인 지원자 API를 본인 손으로 푸는 구조였다.
4. 협업 방식
2026. 08. 24. 작업 풀 + 팀장 지시서 발행 체계에서 도메인 오너제로 전환했다. 리뷰 병목이 팀장 한 명에게 몰리는 구조를 없애는 것이 목적이었다.
자기 큐를 스스로 소화한다
오너위에서부터 순서대로. 선행이 안 풀렸으면 건너뛰고 다음 것. 큐가 비면 오너가 로드맵을 갱신해 채운다 — 단 마일스톤 범위 안에서. 범위 자체를 바꾸는 건 팀장 합의.
자기 도메인 PR은 자기가 머지
오너 · 수시남의 폴더나 공용 파일이 안 섞였고, PR 본문에 검증 결과가 있고, CI가 초록이면 스스로 머지한다. CI 빨간불 = 머지 불가가 오너제의 안전망이다.
남의 도메인은 고치지 않는다
전원다른 도메인에서 문제를 발견하면 직접 고치지 말고 이슈로 남긴다. 소유자가 아닌 디렉토리를 임의로 리팩터링하지 않는다.
팀장 검수 사이클
매주 금요일 최소 1회스키마 · API 문서 · 공용 문서 · 도메인 경계를 넘는 PR은 팀장 승인이 필요하다. 금요일 검수에 걸리도록 목요일까지 올린다. 다른 도메인이 대기 중인 급한 PR은 수시 요청.
공용 파일은 아무도 직접 안 고친다
전원목업 원본 · ERD · API 문서 · 공용 모델 파일이 해당한다. 팀 채널을 거쳐 팀장이 반영한다. 스키마 확정 후 변경은 전원 합의로만.
30분 룰
전원30분 넘게 막히면 혼자 붙들지 말고 팀 채널에 묻는다. 1인 1도메인 구조에서 혼자 오래 막히는 것이 가장 큰 지연 요인이기 때문이다.
5. 발표 시 각자 말할 것
상세는 각 역할 상세 페이지의 발표 포인트 절. 전원 공통으로 자기 도메인의 문서화와 발표 자료 본인 파트를 맡는다.
| 담당 | 도메인 | 대표 주제 1개 |
|---|---|---|
| 재우 A 이재우 | 인프라 · 총괄 | 배포 파이프라인 · 권한 모델 + 리뷰 병목을 구조로 푼 과정 |
| 우정 B 이우정 | 백엔드 | 상태 전환 규칙을 DB와 코드 중 어디서 강제했는가 + 인덱스 튜닝 전후 수치 |
| 소연 D 박소연 | 프론트엔드 | 드래그 실패 시 낙관적 업데이트를 어떻게 롤백했는가 |
| 수택 E 진수택 | 에이전트 | 도구 호출 에이전트 — 왜 쓰기 도구에만 확인 단계를 강제했는가 |
| 민아 C 김민아 | 앱 | 같은 API로 웹 · 앱 두 클라이언트 — 클라이언트 추가에 서버 변경이 몇 줄이었는가 |