7. 팀 분업

팀명: SOLIDBOB (4인 — 2026-08-26 개편)

원래 3인 체제(정성윤·류준·장민석)에서 플러터(Flutter) 앱 개발을 중단하고, 장민석이 앱·프론트엔드에서 류준과 함께 백엔드·AI로 옮겼다. 조서희가 신규 합류해 프론트엔드(웹)를 전담한다. 정성윤은 AWS·인프라를 그대로 유지한다. 근거·되돌리는 법: _project/decisions/005-팀-개편-4인-체제.md.

7.1 담당

⚠ 위 표는 «주 담당» 이지 편집 잠금이 아니다 (2026-09-10, _project/decisions/302). ai/·server/·infra/ 는 정성윤·류준·장민석 누구나 고친다. 전담이 남는 곳은 조서희의 프론트엔드(apps/) 하나뿐이다.

푼 이유는 기능 하나가 한 디렉터리 안에서 끝나지 않기 때문이다 — 배선은 server/, 구현체는 ai/, 배포는 infra/ 라서 각자 자기 몫을 끝내도 호출부만 있고 구현체가 없는 구멍이 남았다. 잠금 대신 남는 것은 기계 검사(.importlinter 계층 계약 · 런북 선행 읽기 훅)와 손대기 전 grep 으로 영향 범위 확인(_project/decisions/023)이다.

ai/ 와 server/ 의 경계 — 어느 쪽인지 헷갈리면 이렇게 가른다.

"품질을 만들거나 재는 코드인가?"              → 예: ai/     (류준)
"요청 하나를 처리하는 데 반드시 실행되는가?"   → 예: server/ (장민석)

C-5 마스킹·F-2 게이트가 server/에 있는 이유가 이것이다 — 둘 다 규칙 기반 판정이고 요청 경로에서 매번 실행된다. 모델이 관여하지 않는다(절대 원칙 9 “판정은 규칙이, 설명만 LLM이”). 각 디렉터리 루트의 CLAUDE.md가 이 경계를 영역 규칙으로 적어 두고 있다. 이 경계는 «무엇이 어디에 들어가는가» 이지 «누가 고치는가» 가 아니다(_project/decisions/302). 브랜치 이름도 디렉터리 이름과 같다 — ai(류준) · server(장민석), _project/decisions/015. 다만 이름이 곧 작업 범위는 아니다 — 한 브랜치에서 셋을 다 고치고 한 PR 로 넣는다.

7.2 부하 재분배 — 개편 이후 상태

이전에는 류준이 백엔드와 AI를 혼자 맡아 구조적으로 과부하였다. 4·5주차 핵심 실험과 F-2가 모두 한 사람에게 걸려 있었다. 2026-08-26 팀 개편으로 장민석이 백엔드·AI에 합류하면서 이 문제는 구조적으로 해소됐다.

기존 완화 조치는 계속 유지한다 — 과부하 회피 목적이 아니라 각자의 전문성에 맞는 정상 분업으로 재해석한다.

7.3 인터페이스 계약 우선

1주차에 모듈 간 스키마를 확정한다. 이것이 병렬 작업의 전제 조건이다.

⚠ 이 절은 2026-08-25 v2 기록이다 — 지금 코드와 다르다 (2026-09-15 표시). 실제로 붙일 계약의 정본은 저장소 _project/plan.md 7.3절(사이트 밖)과 서버 /openapi.json 이다. 크게 달라진 것: 응답 값은 전부 문자열("true"·"3150", null 은 그대로) · 카드는 fired 로 발동 여부를 먼저 알린다 · F-2 는 closure_type·approved/blocked 가 아니라 procedure·verdict: complete/incomplete(decisions/305) · 블랙리스트 요청은 상담원 토큰 헤더로 요청자를 정한다(decisions/307). 아래 v2 본문은 당시 기록이라 고치지 않는다(절대 원칙 8).

v2 — 2026-08-25 조건부 컨펌 반영. v1(위 초안)은 정성윤이 DB 스키마·골든셋과 대조해 불일치 4건을 확인, 아래처럼 수정해 최종 확정했다. 결정 기록: _project/decisions/003-인터페이스-스키마-v2.md (v1 최초 컨펌 기록은 _project/decisions/002-인터페이스-스키마-확정.md에 남아 있다.)

// 전사 이벤트 (마스킹 적용 후)
{
  "call_id": "c_001",
  "segment_id": "seg_0031",
  "speaker": "customer",
  "text": "카드번호는 **** 입니다",
  "masked": [{"type": "P2", "span": [7, 11]}],
  "is_final": true,
  "utterance_end_ms": 3100
}

// 추천 카드
{
  "call_id": "c_001",
  "trigger_at_ms": 3150,
  "cards": [
    {
      "title": "부정사용 보상 기준 안내",
      "summary": "분실 신고 접수 이전의 부정사용액은 고의·중과실이 없는 한 보상됩니다.",
      "source": {"doc_id": "FIN-TERM-2.2", "title": "이용약관 2장 2항"},
      "similarity_score": 0.87
    }
  ],
  "internal_latency_ms": 780,
  "e2e_latency_ms": 1240
}

// 종결 판정 (F-2) — 도메인·closure_type별로 evidence의 키가 다르다 (아래 표 참고)
{
  "call_id": "c_001",
  "closure_type": "상품해지",
  "reason": "고지 완료",
  "evidence": {"중도해지수수료_안내": true, "약정혜택소멸_안내": false, "고객확인_기록": false},
  "verdict": "blocked",
  "missing": ["약정혜택소멸_안내", "고객확인_기록"],
  "source": {"doc_id": "FIN-POLICY-CLOSE-1", "title": "내부 처리 규정 — 상품 해지 처리"}
}

2026-08-26 도메인 4종 정리 반영: 위 예시는 v2 확정 당시(2026-08-25) 통신 도메인 값(TERM-3.2, closure_type: "해지")을 썼으나, 그 문서 ID·처리유형은 지금 knowledge-base/에 존재하지 않는다. 구조(필드명·타입)는 v2 그대로이고 예시 값만 실제 스키마에 맞춰 금융보험 도메인 예시로 교체했다 — db/schema.sql도 같은 날 closure_type·evidence 컬럼을 이 값들로 갱신했다(_project/decisions/006). 메시지에 domain 필드를 명시적으로 포함할지(현재는 call_id로 서버가 call.domain을 조회하는 방식을 가정)는 3.2절 도메인 라우팅과 함께 아직 미결이다.

v1 → v2 수정 사항 (DB db/schema.sql·골든셋과 대조해 발견, 정성윤 확인)

그대로 유지: masked[].type(P1~P7, masking_event.pattern과 일치) · is_final/utterance_end_ms(transcript_segment와 1:1) · closure_type이 DB ENUM과 정확히 일치해야 한다는 원칙(값 자체는 2026-08-26 "상품해지"/"보상"/"반품"/"교환"으로 갱신, 16절 ERD).

자막 렌더링 (정성윤 제안, 장민석이 프론트를 맡던 시점의 합의 — 현재 프론트는 조서희, 백엔드·AI 내부 분담은 7.2절 참고): interim은 누적하지 않고 최신 것만 segment_id 기준으로 교체, 갱신은 requestAnimationFrame 또는 100ms 디바운스로 묶는다. DB에는 is_final: true만 저장 — interim까지 저장하면 통화 1건에 수천 행이 쌓인다.

✅ 반영 완료 (2026-08-26): 위 두 항목(evidence·closure_type)에서 예고했던 v3 변경 — 도메인 접두어 문서 ID(FIN-TERM-3.2), 도메인별 closure_type 값 집합 (금융보험: 상품해지/보상, 쇼핑: 반품/교환) — 을 위 JSON 예시와 db/schema.sql에 함께 반영했다(_project/decisions/006). 메시지에 별도 domain 필드를 넣을지는 3.2절과 함께 아직 미결 — call_id로 서버가 call.domain을 조회하는 방식을 임시로 가정한다.

← 개발목차로 돌아가기