두 단계, 하나의 경계

"받아쓰기는 읽을 텍스트를 돌려줘. 보이스 챗은 들을 말을 돌려줘. 같은 제품이 아냐."

두 단계

Firekeeper 는 두 단계짜리 의도된 로드맵이 있고, 그 사이 벽이 하중을 받아:

Stage 1 — 받아쓰기. 말하면 정리된 텍스트가 활성 앱에 삽입돼. 이게 근시일 제품이고 첫 임무 전체야.
Stage 2 — 보이스 챗. 말하면 Pippa 가 소리 내서 답해. 이건 Stage 1 이 매일 진짜 쓸모 있어진 다음에야 시작해.

'둘 다 목소리니까 더 큰 쪽으로 지어' 라고 말하고 싶어져. 그 본능이 딱 함정이야.

계약이 다른 이유

받아쓰기 정리랑 말하는 응답은 같은 것의 다른 크기가 아니라 다른 출력 계약이야. 정리는 네 말을 받아 삽입할 다듬어진 텍스트를 돌려줘 — 절대 답하면 안 되고, 내용 추가하면 안 되고, 논평하면 안 돼. 보이스 응답은 네 말을 받아 짧고 말하는 턴을 돌려줘 — 그건 답이고, 끼어들기 좋아야 하고, 소리 내 읽어서 맞게 들려야 해(제목 없음, 표 없음, 열 개짜리 불릿 없음). 모양을 나란히 봐, 차이가 명백해:

받아쓰기 정리:  전사 입력  -> 다듬은 텍스트 출력 (삽입해, 답하지 마)
보이스 응답:    전사 입력  -> 말하는 턴 출력 (답해, 짧게 유지해)

네가 막고 있는 실패

고전적 실수는 'Stage 2 는 그냥 Stage 1 더하기 TTS' — 평소 긴 Pippa 답을 TTS 엔진에 흘리고 보이스 챗이라 부르는 거야. 못 견딜 게 나와: '첫째, 둘째, 결론적으로' 를 소리 내 읽는 2분짜리 말하는 에세이, 끼어들 틈 없음. 좋은 보이스 챗은 자기가 말하고 있다는 걸 아는 응답 모드가 필요해: 턴당 명확한 생각 하나, 쏟아붓는 대신 계속할지 제안. 그건 통째로 새 계약이고, 그래서 Stage 1 의 체크박스가 아니라 Stage 2 인 거야.

제품 경계는 두 기능이 아니라 두 계약이 만나는 곳이야. Stage 1 과 Stage 2 는 '삽입할 텍스트' 와 '말할 단어' 가 진짜로 다른 반환 타입이라서 나뉘어. 경계를 지키면 각각 작고 올바르게 남고; 지우면 어색하게 받아쓰고 더 못 대화하는 흐릿한 앱이 돼.

Stage 2 를 Stage 1 척추에 몰래 끼우지 마. '온 김에' 받아쓰기 경로에 '빠른 대화 응답' 을 더하고 싶을 때마다 멈춰. 그게 받아쓰기 루프가 두 번째 브레인, 두 번째 지연 프로파일, 두 번째 실패 모드를 키우고 — 야무지고 배포 가능한 게 아니게 되는 방식이야.

Code

일부러 떨어뜨려 놓은 두 출력 계약·typescript

// Stage 1: 정리는 삽입할 텍스트를 돌려줘. 절대 답 안 해.
interface CleanupResult {
  text: string;          // 다듬은 전사, 삽입 준비 완료
  action: "insert";
  press_enter: boolean;
  warnings: string[];
}

// Stage 2: 보이스 응답은 말하는 턴을 돌려줘. 그게 답이야.
interface VoiceChatReply {
  textForTTS: string;      // 짧고 TTS 친화적, 턴당 생각 하나
  textForTranscript?: string;
  shouldContinue?: boolean; // 쏟는 대신 더 깊게 갈지 제안
}

// 같은 입력(전사), 근본적으로 다른 출력.
// 그 차이가 제품 경계야.

Exercise

네가 쓰는 앱의 두 기능에 대해 반환 타입(필드만) 을 써봐: 하나는 '어딘가 놓을 콘텐츠를 만드는' 거, 하나는 '대화식으로 답하는' 거. 두 타입이 거의 똑같아 보이면, 둘 중 하나를 덜 설계한 거야. 어디서 진짜로 갈라져?

Hint

의도에서 갈라져: '어딘가 놓기' 출력은 불활성이고 완결적이어야 하고; '대화식 답하기' 출력은 반응적이고, 짧고, 계속 가능해야 해. 타입이 그 차이를 담는 순간(삽입-대-말하기, 완결-대-계속가능), 진짜 제품 경계를 찾은 거야.

두 단계

계약이 다른 이유

네가 막고 있는 실패

Code

External links

Exercise

Progress

댓글 0