크루 서비스 — 오픈 준비 계획 (응대 구조 · 헤비/라이트 · 최소 도구)

2026-08-22. 형 지시 3건에 딥리서치 3건을 붙여 나온 계획입니다.
참조로 주신 Grok Bot · Cursor /goal · Hermes Bot Mode 를 1차 문서로 확인했고,
그 위에 우리 저장소(~/Projects/teamai)와 라이브 DB를 직접 조회해 대조했습니다.

⚠️ 계획보다 먼저 읽으실 것이 있습니다 — 오픈을 막는 실물 결함 5개가 나왔습니다(§5).
그중 셋은 "만들어야 하는 것"이 아니라 이미 있는데 끊겨 있거나, 있으면 안 되는 것입니다.

0. 세 질문에 대한 답 — 한 줄씩

형의 질문	답
단독·다자방에서 어떤 구조 어떤 상태로 응대하나	기본은 침묵. 1:1은 부르면 답하고, 다자방은 리더가 다음 사람을 호명하는 방식으로 돌린다. 라운드 기본 1·최대 3
모든 일을 헤비하게 하지 않으려면	판정을 앞단 라우터에 두지 않는다. 사용자가 어느 방을 열었는지가 이미 등급이다. 지금 라이브인 라우터는 삭제
최소 도구를 어떻게 준비하나	3개만: 스케줄 티커 · 도달 배선 · 한국어 로컬 검색. 알림톡·캘린더·범용 검색벤더는 1호에서 뺀다

1. 참조 3개에서 실제로 건진 것

	확인된 것	우리가 쓰는 방식
Hermes Bot Mode (Nous, 08-18)	봇 로스터, 봇마다 역할·고정 모델·기억·스킬. @멘션 핸드오프. 협업 방 2~6명, 메시지당 최대 3라운드	방 인원과 라운드 상한의 실물 수치를 그대로 참고
Grok Bot (xAI, 08 베타)	그룹 2~6봇, 봇들이 스스로 누가 답할지 판단, @멘션이 override. 봇끼리 비동기 깨우기	그런데 라운드 상한·발언 순서·침묵 규칙이 문서에 아예 없습니다. 폭주 방지책이 프롬프트 권고 한 줄뿐 — 베끼면 안 되는 쪽
Cursor /goal	목표를 붙들고 이벤트에 반응해 스스로 일을 집어 듦	종료 판정(목표 달성/미달/불가)을 우리 1:1 작업 상태에 이식

Grok Bot 문서는 원문을 직접 받아 확인했지만, 그 페이지들이 회사명을 "SpaceXAI"로 표기하고
과금 안내가 cursor.com을 가리키는 이상이 있었습니다. 그래서 Grok 쪽 세부는 낮은 신뢰도로
다루고, 수치는 Hermes와 플랫폼 3사 기본값·학술 실측에 기댔습니다.

2. ① 응대 구조 — 기본값은 침묵입니다

왜 침묵이 기본인가 (실측)

IBM Research가 슬랙 그룹에 브레인스토밍 봇을 넣은 실험에서 사용자 평가:
"봇이 대화를 장악했다. 다른 사람이 참여할 공간을 안 만들어주는 현학적인 학생 같았다."
참가자 72.2%가 "직접 불렀을 때만 답하는" 반응형을 선호했습니다.
플랫폼 3사 기본값이 전부 침묵입니다. Teams는 "기본적으로 그룹 채팅·채널의 에이전트는
직접 @멘션됐을 때만 메시지를 받는다", Slack은 app_mention 스코프, Discord는 아예
메시지 내용을 안 보내는 것으로 강제합니다.

그래서 우리 기본 판정은 "아무도 안 나선다"입니다. 크루가 자발적으로 끼어드는 건
기본이 아니라 특권적 예외입니다.

1:1 방 — 상태 5개

대기 ──(내 메시지)──▶ 응대 ──(도구·시간 필요)──▶ 작업 중
 ▲                      │                          │
 │                      └──(짧게 끝남)──┐          │
 │                                       ▼          ▼
 └────────────── 보고 ◀───────────── 종료 판정
 │
 └──(약속한 시각 도래)── 선발화

핵심은 작업 중 → 보고를 무엇으로 끊느냐입니다. Cursor·Claude Code 방식을 그대로 씁니다 —
끝났나 / 아직인가 / 불가능한가 3분류를 LLM이 판정 + 진전이 없으면 중단.

상한만으로는 안전이 안 만들어집니다. LangGraph의 재귀 상한이 25 → 1000 → 10007로
계속 풀린 게 그 증거입니다. 안전은 상한이 아니라 종료 판정에 있습니다.

다자방 — 리더가 다음 사람을 호명합니다

여기서 제가 원래 그렸던 설계를 바꿨습니다. "진행자가 발언 순서를 정한다"가 근거가 없었습니다.

LLM은 "다음에 누가 말해야 하나"를 못 맞춥니다 — 다자 대화에서 GPT-4o의 다음 화자 예측
정확도가 46.0%로 우연(50%)보다 낮고, 다른 코퍼스에선 zero-shot LLM 28.10 vs 랜덤 45.91로
랜덤에 집니다. 순서 계산을 시키는 설계는 시작부터 틀립니다.

검증된 대안이 있습니다. 사람의 대화 규칙(현재 화자가 다음 화자를 지명, 없으면 자기선택)을
그대로 구현한 실험에서, 이 방식이 대화 붕괴가 유의하게 적었고(χ²=42.171, p<0.001)
인간 평가 7.45점 — 균등 배분 5.89, 자유 자기선택 4.61을 크게 이겼습니다.

안건 없음
   │  내가 방에 한 줄 던짐
   ▼
리더 선정   ← 이 안건에 누가 맞나 (관련성 판정 1회. LLM이 잘하는 일)
   │
   ▼
라운드 1   리더가 말하고 → 끝에 다음 사람을 호명 ("@숫자, 이건 네가 봐야 할 것 같은데")
   │       호명 안 하면 그 라운드는 거기서 끝
   ▼
결론 카드 + 버튼 2~3개

같은 라운드에 같은 크루가 두 번 말하지 못합니다. 무한 루프 실사고에 대한 표준 처방입니다.
라운드 기본 1 · 리더가 필요하다고 하면 2 · 하드캡 3. Hermes가 3으로 잡은 것과 같은 선입니다.
방 인원은 2~6명. Hermes·Grok 둘 다 같은 수치입니다.
내가 중간에 끼어들면 진행 중 라운드를 즉시 중단하고 내 말이 우선입니다.
1:1에 있던 크루가 다자방에 불려 나가도 호칭은 영역 기본값 그대로입니다(설계서 §3).

이 설계로도 안 되는 것 — 정직하게

안 불린 크루는 못 끼어듭니다. 전원에게 "할 말 있냐"를 물으면 품질은 오르지만 인원배 비용입니다.
비용이 인원에 비례합니다. 다자 시스템은 1:1 대비 토큰 약 15배를 쓰고, 토큰 사용량이
성능 분산의 80%를 설명합니다. 헤비 유저 월 3,100원은 1:1 트래픽 기준값이라 다자방에선 안 버팁니다.
🔴 합의가 오히려 정답을 부술 수 있습니다. 다자 토론에서 순응의 57~77%가 정답→오답
방향이고, 내용 없는 근거에도 20~39%가 오답을 채택합니다. ICML 2024 결론은
"현재 형태의 다자 토론 시스템은 self-consistency·앙상블을 신뢰성 있게 못 이긴다"입니다.
→ "여럿이라 낫다"는 우리 제품 전제에 지금 증거가 없습니다. §7에서 다시 다룹니다.

3. ② 헤비/라이트 — 판정을 앞단에 두지 않습니다

가르는 축은 "어려움"이 아니라 "몇 턴이 도는가"

라이브 DB 실측으로 레버를 쟀습니다.

축	실제 레버	근거
여럿이 필요한가(팬아웃)	17.7배	메시지 실측 crew 3,407 : user 192
답이 길어야 하는가(모델 티어)	12.5배	1.12원(grok) → 14.00원(sonnet-5)
도구를 쓰는가	1.9배	지식 주입 시 입력 +4,500토큰
되돌릴 수 없는가	현재 0	발송·결제·게시 도구가 아직 없음

그리고 턴 수는 사용자가 어느 방을 열었는지로 이미 결정돼 있습니다.
1:1을 열면 라이트, 여럿 있는 방을 열면 헤비입니다. 판정할 게 없습니다.

내용으로 판정하는 건 실측으로 실패했습니다

실사용 메시지 145건에 지금 라이브인 라우터 로직을 그대로 돌려봤습니다.

진짜 헤비 요청("팀원과 상의해서~" 23건, 16%)을 0% 잡았습니다
헤비로 잡은 유일한 1건은 여행 추천 = 오탐
길이는 무의미: "이 프로젝트를 팀 차원에서 분석해줘"(19자·헤비) vs
"덧붙이자면 운동도 고려해야 해요"(18자·라이트). 중앙값 17자, 250자 이상 0건

CLAUDE.md 사고 ③(길이·번호목록·키워드로 복잡도 판정)이 지금 라이브에서 돌고 있습니다.
그때 폐기한 그 게이트가 이 저장소에 살아 있습니다.

앞단 라우터를 제대로 만들어도 답이 안 됩니다 — 전용 라우터도 오판 6.8%, 값싼 범용 모델은 17.2%,
비용은 가장 싼 1:1 턴의 13~27% 오버헤드이고, teamai엔 스트리밍이 없어 그 지연이 전부
사용자에게 노출됩니다. GPT-5 출시 사고도 정확히 "라우터를 항소 불가능하게 만든 것"이었습니다.

그래서: 라우터를 지우고, 이미 짜여 있는 위임 승낙을 되살립니다

저장소에 "크루가 위임을 제안 → 사용자가 수락/거절" 기구가 이미 짜여 있는데(legacy),
신 함수가 그 파라미터를 안 받아 죽어 있습니다. 앱은 지금도 그 API를 호출하고 있습니다.

이 구조가 세 방식의 장점만 가집니다 — 판정은 크루가 답변을 만들면서 같이 하고(추가 호출 0,
지연 0), 집행은 사용자 탭 1회. 오판했을 때 손해가 탭 한 번입니다.

등급	무엇으로 정해지나	모델	크루 수	목표
라이트	1:1 방을 열었다	크루 DB에 배정된 모델 그대로	1	첫 응답 < 2초
보통	여럿 있는 방	동일	N명 순차	첫 크루 < 2초
헤비	크루가 제안 + 내가 수락 탭	동일	리더 + 팀	진행표시 후 < 60초

모델은 등급이 아니라 캐스팅이 정합니다. 라우터가 모델을 갈아끼우면 "배역을 주는 서비스"의
핵심이 깨집니다. 크루 203개에 이미 티어별 모델이 배정돼 있습니다(70/81/49/3).

1호는 라이트 + 보통만으로 엽니다. 헤비 경로는 지금도 죽어 있어 잃을 게 없습니다.

4. ③ 최소 도구 — 3개

판정 기준: 크루가 배역상 이미 말하게 되어 있는 문장을 못 지키게 만드는가.

넣는 것

① 스케줄 티커 — 2일
pg_cron + pg_net 설치(둘 다 지금 미설치) + reminders 테이블 + 1분 주기 잡 하나가
때가 된 행만 집는 구조. 크론식은 영원히 1개라 사용자가 몇 명이든 무료 한도에 안 걸립니다.

evidence_utterance 컬럼이 이 설계의 핵심입니다. 사용자가 자기 입으로 말한 원문이
있어야만 행이 생기게 하면, "약속한 적 없는 알림 금지"가 프롬프트가 아니라 스키마로
강제됩니다. 비어 있으면 발송 안 함. 잔소리 즉사를 DB가 막습니다.

없으면 부도나는 약속: 과외 선생의 "숙제 다 했니?", 김대리의 "그 건 오늘까지였는데요",
여자친구의 기념일 — 선발화 크루 전부. 이게 없으면 이 서비스는 그냥 챗봇입니다.

⚠️ 무료 플랜은 1주 무활동이면 프로젝트가 멈추고 pg_cron도 같이 죽습니다.
외부에서 하루 1회 깨우는 크론을 반드시 겹쳐 두십시오. 안 하면 룰 #4의 "조용한 죽음"이 그대로 재발합니다.

② 도달 배선 3층 — 3일
인앱 알림(테이블 이미 있음, 0행) → 안드로이드 FCM → 이메일 폴백.
FCM 발송기는 이미 구현돼 있습니다(구 함수에). 앱이 부르는 신 함수로 옮기고 웹 가드만
치면 됩니다. 신규 개발이 아니라 재배선입니다.

없으면: ①을 만들어도 아무도 못 듣는 알람입니다.

③ 한국어 로컬 검색 (네이버 + 카카오) — 1.5일
네이버 검색 API 일 25,000회 무료, 카카오 로컬 일 10만회 무료. 둘 다 0원입니다.

서양 검색 벤더는 한국 동네 정보를 구조적으로 못 물어옵니다. 돈 문제가 아니라 경로가
없습니다 — cafe.naver.com/robots.txt는 구글·빙 포함 전면 차단이고, 블로그는 ClaudeBot·
GPTBot·PerplexityBot을 콕 집어 막습니다. Brave는 2026-02에 무료 티어도 없앴습니다.

없으면 부도: 옆집 아줌마의 "주말에 바람 쐬러 갔다 와" — 장소를 못 대면 빈말입니다.
그리고 지금 크루 목록엔 '부산로컬가이드'가 검색 없이 LLM 기억만으로 답하고 있습니다.
폐업한 가게를 추천하는 게 최악입니다.

합계 6.5일 + 버퍼 = 10일. 월 운영비 증가 0원.

빼는 것 — 그리고 크루가 대신 할 말

뺄 것	왜	크루가 할 말
카카오 알림톡	건당 13원 + 사업자등록·템플릿 심사 5~10일. 템플릿 고정문구가 페르소나를 죽입니다 — 여자친구가 "고객님께 안내드립니다"체로 말할 수 없음	(앱 알림으로 대체)
브랜드메시지(구 친구톡)	친구톡은 2025-12-31 종료. 비친구 발송은 채널친구 5만 조건	—
구글 캘린더 연동	sensitive 스코프 검수 + 연 1회 재인증, restricted면 CASA $500~4,500	"달력에 직접 넣진 못하지만, 저한테 말해두시면 그날 제가 먼저 말 걸게요."
범용 검색벤더	한국 로컬을 못 물어오니 돈값 0	"해외 자료나 최신 뉴스는 아직 직접 못 찾아봐요. 링크 주시면 같이 볼게요."
iOS 웹푸시	홈화면 추가 필수가 2026년에도 유지	"아이폰이시면 알림이 안 가서 여기 남겨둘게요."

도구 없이 되는 것 — 의외로 많습니다

과외 선생의 숙제 출제·채점·진도 기록·주간 요약은 전부 LLM + DB입니다(외부 도구 0).
옆집 아줌마의 험담 받아주기, 여자친구의 기념일 계산, 참모단 판정 카드도 마찬가지입니다.

크루 가치의 대부분은 ①스케줄 하나로 열립니다. 검색은 세 번째입니다.

5. 🔴 오픈을 막는 실물 결함 5개 — 계획보다 먼저

전부 라이브 코드·DB에서 확인한 것입니다. 셋은 "만들 것"이 아니라 이미 있는데 끊겼거나
있으면 안 되는 것입니다.

#	무엇	실측	조치
P0-1	알림이 한 번도 나간 적 없음	FCM 발송기가 구 함수에만 있고 앱은 신 함수를 호출. `notifications` 0행, `action_plans` 0행	발송기를 신 함수로 이식
P0-2	푸시 서비스가 웹에서 깨짐	`push_notification_service.dart`가 `Platform.isAndroid`를 웹 가드 없이 사용(108·127·163행). 웹이 본진인데	`kIsWeb` 가드
P0-3	금지된 게이트가 라이브	길이·키워드 복잡도 라우터가 헤비를 0% 잡고 87%를 헤비로 밀어올림	라우터 삭제
P0-4	가장 싼 메시지가 500 남	fast path가 fal 제공자에 의존하는데 실측 HTTP 401, try/catch 없어 예외가 밖으로 터짐. "안녕"이 실사용의 10%	fast path 제거
P0-5	대소문자 하나로 경량 분기 전체가 죽은 코드	`complexity === 'TRIVIAL'`인데 실제 값은 `'trivial'` → 항상 false. "ㅋㅋ"도 헤비 처리	라우터와 함께 제거

부수 결함: 모델 티어 상수가 DB 배정과 완전히 다른 2중 모델 선택계로 존재.
user_fcm_tokens 테이블이 라이브엔 있는데 마이그레이션엔 없음(스키마 드리프트).

6. 일정 — 10일

일	무엇	완료 판정
1	P0-3·4·5 제거 (라우터·fast path)	"안녕"이 500 안 나고 1:1이 2초 내 응답
2	P0-2 웹 가드 + P0-1 발송기 이식	웹 빌드 성공 + 내 기기로 테스트 푸시 1건 도달
3~4	스케줄 티커 (`pg_cron`·`pg_net`·`reminders`·`evidence_utterance`)	5분 뒤 알림을 걸고 실제로 받음
5	외부 keep-alive 크론	주말 지나고도 티커 살아 있음
6~7	도달 3층 (인앱·FCM·이메일 폴백)	iOS 계정에서 이메일로 도달 확인
8~9	네이버 + 카카오 검색 도구	옆집 아줌마가 실제 존재하는 가게를 댐
10	위임 승낙(수락 탭) 복원	크루 제안 → 탭 → 다자방 전환 1회 성공

그 다음이 형이 말한 그 테스트(크루 발화 길이 실측)입니다 — 위가 정리돼야 측정값이 의미를 갖습니다.

7. 정직하게 — 제품 전제를 건드리는 구멍 하나

§2에서 나온 것을 다시 올립니다. "여럿이 붙으면 더 나은 답이 나온다"는 전제에 지금 증거가
없습니다. 다자 토론에서 순응의 57~77%가 정답을 오답으로 바꾸고, ICML 2024는 현재 형태의
다자 토론이 단순한 방법을 신뢰성 있게 못 이긴다고 결론냈습니다. 리더가 종합하는 순간
그 편향이 매끈한 한 문단으로 세탁됩니다.

다만 이게 이 제품을 죽이지는 않습니다. 우리가 파는 게 "더 정확한 답"이 아니라
"의견이 갈리는 걸 보는 것"이기 때문입니다. 그래서 다자방의 성공 지표를 정확도가 아니라
갈림이 실제로 발생한 비율로 잡아야 합니다 — 크루 셋이 다 같은 말을 하면 그 방은 실패입니다.
이건 베타에서 셀 수 있습니다.

그 외 못 하는 것 3개: iOS 사용자는 1호에서 선발화를 못 받습니다(이메일이 유일한 임시방편) /
앱 밖에 있을 때 크루가 미리 일을 해두는 건 안 됩니다 — 1호의 "수행"은 정시에 말 걸기 +
물어보면 찾아주기까지입니다 / 네이버 카페·블로그 본문은 못 읽습니다(제목·요약·링크만).

8. 형이 정할 것 — 2개

① P0-3~5(라우터 계열) 즉시 삭제해도 되는가. 지금 헤비를 0% 잡고 있어 지워도 잃을 기능이
없다는 게 실측이지만, 지우면 다자방 자동 승격이 사라집니다(수락 탭으로 대체). 제 추천은 삭제.

② 다자방을 1호에 넣을 것인가. 비용 15배 + 위 전제 구멍 때문입니다.
(ㄱ) 넣는다 — 이 제품의 그림 자체라 빼면 남는 게 얇아짐 / (ㄴ) 1호는 1:1만, 다자는 베타 후.
제 추천은 (ㄱ)이되 방 인원을 3명으로 제한하고 갈림 발생률을 측정하는 것입니다.