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