함께 일하는 법¶
우리가 일하는 방식을 한 문장으로 줄이면, 마일스톤이 방향을 잡고, 스프린트가 리듬을 만들고, FDD(기능 단위 문서)가 무엇을 완성으로 볼지 정의한다는 것이다. 처음엔 평범한 스프린트로 굴렸지만, 돌아보니 우리가 하던 건 "애자일을 빙자한 워터폴"에 가까웠다. 그래서 한 번 갈아엎고 지금의 형태로 복원했다 — 이 페이지는 그 결과물이자, 새로 합류한 사람이 "여긴 어떻게 일하지?"에 답을 얻는 곳이다.
일하는 방식¶
가장 큰 변화는 역할을 순서대로 줄세우지 않는다는 점이다. 예전엔 디자인이 끝나야 FE가, FE가 끝나야 BE가 움직였다. 지금은 한 기능 안에서 DE·FE·BE·QA가 동시에 붙는다. 그래서 단위가 "스프린트 기간"이 아니라 "기능"이고, 평가도 "얼마나 많이 쳐냈나"가 아니라 "무엇을 끝냈고 어떤 가치를 전달했나"로 본다. MVP라도 소프트웨어 품질은 초기 시장 반응과 신뢰에 곧장 연결되기 때문에, 속도보다 완성도를 앞에 둔다.
병렬에는 대가가 있다. 각자 동시에 달리다 보면 문서·정보 공유가 한 박자만 늦어도 불일치·중복·통합 지연이 생긴다. 주 1회 미팅으로는 이 간극을 못 메운다. 그래서 비동기 커뮤니케이션을 기본값으로 둔다 — 진행 현황은 Notion, 대화 로그는 Slack, 코드 맥락은 GitHub PR, 시간 기록은 Jira Time Log에 남긴다.
왜 스프린트에서 마일스톤+FDD로 바꿨나¶
옛 방식과 지금 방식을 나란히 두면 차이가 분명하다. 핵심은 운영 단위가 "기간"에서 "기능"으로, 관리의 초점이 "처리량"에서 "완성"으로 옮겨갔다는 것이다.
| 구분 | 기존 (스프린트·기간 중심) | 개선 (마일스톤+FDD·기능 중심) |
|---|---|---|
| 운영 단위 | 스프린트(1~2주, 일정 중심) | 마일스톤(3~4주, 목표 중심) + FDD |
| 관리 초점 | 얼마나 많이 처리했나 | 어떤 기능을 완성했나 |
| 작업 기준 | 역할별 분리(순차) | 기능별 병렬(DE/FE/BE/QA 동시) |
| 협업 구조 | 역할 의존 높음(대기 발생) | 의존 낮음, 기능 단위 자율 |
| 배포 기준 | 스프린트 종료 | 마일스톤 완성 시점 |
| 지향 | 속도 | 품질·완성도 |
Jira 운영 규칙¶
작업은 마일스톤(Epic) → 기능(Story) → 역할 Task(DE/FE/BE/QA)로 쪼개고, Epic 본문에는 목표·범위·일정과 연관 문서 링크를 적어 둔다.
소통의 종착점은 Jira로 정했다. Slack·Figma·Discord 어디서 논의가 시작됐든, 최종 결정과 리소스는 Jira 코멘트·첨부로 박제한다. 채팅에 흘려두면 며칠 뒤엔 사라지기 때문이다. 그래서 디자인 산출물(.svg·.fig·.zip)이나 개발 리소스(.json·.env.example·링크)도 Slack이 아니라 Jira 첨부 탭에 붙인다.
일정은 세 겹으로 본다. 큰 마일스톤(시작·종료·배포일)은 Jira에, 디자인·개발·QA·회의 같은 세부 일정은 Google Calendar(Notion 임베드, 무료)에, 그리고 모두가 모이는 공용 허브는 Notion에 둔다. 스프린트는 더 이상 별도 단위가 아니라 마일스톤 안의 세부 일정으로 재정의됐다.
워크플로도 한 번 손봤다. 기본 3단계(To Do→In Progress→Done)로는 "정보가 부족해 멈춤", "QA 피드백 대기" 같은 중간 상태를 담을 수 없어 추적이 끊겼다. 그래서 다음처럼 넓혔다:
공식 완료는 Claim Fix를 검증(Validate)한 뒤 Close 시점이다. 로그인 계정·접근 권한은 tools-accounts에 정리해 뒀다.
문서 문화 (FDD 중심)¶
병렬로 일하려면 "이 기능이 뭔지" 모두가 같은 그림을 봐야 한다. 그 그림이 FDD다. 로그인·스터디룸·수업노트처럼 덩치 있는 기능은 각각 하나의 독립 FDD 페이지를 갖고, 요구사항·예외처리·UI·API·테스트 기준·변경로그를 그 한 곳에 모은다.
FDD는 한 번 쓰고 끝나는 문서가 아니라 계속 자라는 문서다. 킥오프 때 프로토 수준으로 골격만 잡아두고, 각 포지션이 작업을 끝낼 때마다 자기 섹션을 채워 넣는다. 또 Figma·Swagger·ERD·FE 문서를 대체하려는 게 아니라 그것들을 연결하는 허브 역할을 한다 — 각 FDD는 Jira Story와 1:1로 묶인다. 우리가 가장 경계하는 건 회의나 Slack에서 나온 논의가 문서로 이어지지 않는 단절이다. 그 단절이 곧 온보딩·인수인계 비용으로 돌아오기 때문이다.
AI 협업¶
코드와 문서 작업에 Claude Code 같은 AI 에이전트를 1급 동료로 쓴다. 어떻게 쓰는지에 대한 전사 공통 원칙은 ai-collaboration에 모아뒀고, 각 직무 hub는 거기에 자기 영역 적용만 덧붙인다.
회고에서 반복되는 것들¶
회고 때마다 비슷한 이야기가 돈다. 계속 가져가고 싶은 것은 팀별로 방향성을 함께 고민하는 discussion과, FDD에 상세 기획을 담아 전달하는 습관이다. 반복해서 걸리는 문제는 기능별 담당자·진행 상황이 한눈에 안 보이는 것, 기획과 작업 사이의 텀, 문서가 흩어지는 것, Jira 관리가 느슨해지는 것이다. 그래서 시도해보는 것들은 공통 문서로 담당자·진행·우선순위를 가시화하기, 모각작·모각코 같이 모여서 일하는 문화, 그리고 프론트-백이 막힐 때 짧게라도 실시간으로 대화하기다.