OpenAI Realtime 프롬프트 토큰 사전 검증

마지막 업데이트 2026-09-12

현재 구현, DynamoDB 검토, 공통 변수 영향도 재검증, 런타임 안전망을 한 문서로 정리한다.

1. 문제와 목표

활동 지침은 DynamoDB 원문 그대로 OpenAI에 전달되지 않는다. #{공통_룰} 같은 전역 프롬프트 변수, 사용자·아바타 프리셋, 활동별 변수까지 전개된 최종 지침이 Realtime 세션 입력이 된다. 따라서 개별 행의 원문 길이만 확인하면 실제 제한 초과를 놓칠 수 있다.

2. OpenAI 계약과 한도 해석

공식 참고: Realtime conversations, gpt-realtime model, Create Realtime client secret. 수치가 서로 다른 시점의 문서·서비스 계약 사이에서 바뀔 수 있으므로 검증 결과에는 model과 검증 시각을 함께 남겨야 한다.

3. 수동 검증 흐름 미채택 설계안

아래는 위 현행 반영 박스에서 설명한, 구현되지 않은 OpenAI 왕복 방식입니다. 설계 의도 기록으로만 남겨 둡니다.

1. apps/web/components/pages/prompt-test.tsx의 “검증” 버튼이 instruction, variables, userId, avatarId를 전송한다.
2. apps/web/app/api/prompt-test/validate-instructions/route.ts가 인증, 필수 필드, 원문 1,000,000자 상한을 확인한다.
3. 모든 전역 프롬프트 변수를 읽고, 선택 사용자·아바타의 프리셋과 활동 변수를 합쳐 실제 수업의 buildActivityInstruction과 같은 순서로 전개한다.
4. apps/web/lib/voice-agent/realtime-instruction-validation.ts가 model gpt-realtime, 10초 TTL, 15초 요청 timeout으로 client secret 생성을 요청한다.
5. 2xx는 통과, instruction 관련 400과 토큰 문구는 too_long, 그 외 400은 rejected, 비-400은 provider_unavailable로 분류한다.
6. 응답의 임시 시크릿 값은 결과 객체에 넣지 않고 즉시 폐기한다. UI에는 변수 전개 후 문자 수와 provider 판정만 표시한다.

4. 빠진 게이트 2026-09-08 상당수 해소

5. DynamoDB 행 검토와 토큰 컬럼의 효용

권장하는 것은 단일 tokenCount가 아니라 검증 스냅샷이다.

validation: {
  status: "passed" | "too_long" | "rejected" | "stale",
  model: "gpt-realtime",
  providerLimitTokens: 16384,
  providerProvidedTokens: 12345,
  expandedChars: 21000,
  contentHash: "sha256(finalExpandedInstructions)",
  promptVariablesHash: "sha256(referencedVariableVersions)",
  toolSchemaHash: "sha256(effectiveTools)",
  validatedAt: 1788390000
}

프롬프트 변수 행의 contentTokenEstimate는 진단용으로 둘 수 있지만, 그 값이 통과했다고 해서 종속 활동이 통과한 것은 아니다. 신뢰 가능한 상태는 활동별 최종 전개본의 provider 판정과 해시다.

6. 변경 유형별 재검증 범위

7. 권장 운영 구조: 사전 검증 중심의 하이브리드

1. 편집 시 빠른 추정: 로컬 tokenizer/문자 수로 경고만 제공한다. 모델별 차이 때문에 저장 허용의 최종 근거로 사용하지 않는다.
2. 저장 시 provider 검증: 활동 수정은 해당 활동, 공통 변수 수정은 모든 직접 종속 활동을 큐에 넣어 최종 전개본을 검증한다.
3. 검증 결과 캐시: model + 최종 지침 hash + tool schema hash가 같으면 재호출하지 않는다. 결과가 모두 통과한 뒤 저장을 확정하거나, 대량 영향 변경은 draft→검증→publish 상태로 분리한다.
4. 세션 시작 시 저비용 확인: 최종 전개본 hash와 통과 스냅샷만 비교한다. 일치하면 바로 시작하고, stale/cache miss일 때만 provider 검증을 호출한다.
5. 장애 정책: 기존에 통과한 동일 hash가 있으면 OpenAI 검증 서비스 일시 장애에도 시작 가능하다. 새 hash가 미검증이면 fail closed 또는 관리자 override를 정책으로 명시한다.

효율 판단: 매 세션 provider 검증은 동일 지침에 대한 중복 네트워크 호출, 최대 15초 추가 대기 가능성, rate limit 및 provider 장애 결합을 만든다. 반면 저장 시 검증은 변경 횟수에 비례한다. 세션 횟수가 편집 횟수보다 훨씬 많으므로 사전 검증이 기본 경로로 더 효율적이다.

8. “거부되면 LLM으로 줄이고 시작” 방안 검토

허용 가능한 형태는 관리자용 보조 흐름이다: 초과 지침 탐지 → 축약 초안 생성 → 원문 대비 의미 diff/필수 규칙 체크 → 회귀 대화 평가 → 사람이 승인 → 새 버전 저장 → 종속 활동 재검증. 운영 세션에서는 승인된 버전만 사용한다.

9. 검증 증거

자동 테스트 — 2026-09-03

• apps/web/lib/voice-agent/realtime-instruction-validation.test.ts: 6/6 통과 — 요청 body, 2xx, 16,384 초과 분류, 일반 400, 503, secret 비노출·timeout signal
• apps/web/app/api/prompt-test/validate-instructions/route.test.ts: 8/8 통과 — 최종 변수 전개, too_long 전달, 입력 상한, 필수값, API key, 404, OpenAI 요청 예외→502
• 합계 14/14 통과. 테스트의 OpenAI 응답은 mock이며 실제 provider를 호출하는 배포 환경 smoke test는 아직 없다.

운영 로그 확인 — provider 거부 건수

• ppi-livekit-20260831_1000-1000.log 237,373행에서 OpenAI, gpt-realtime, invalid_request_error, session.instructions, 16,384 제한 문구를 검색했으나 직접 거부 로그는 0건이었다.
• 이 파일의 logger는 모두 livekit.* 서버 계층이었다. JS_FAILED: agent worker left the room과 작업 할당 실패는 있었지만 OpenAI 거부로 귀속할 수 없다.
• 따라서 “관측 0건”이지 “실제 운영 0건 확정”은 아니다. 실제 건수 집계에는 같은 기간의 ppi-agent 애플리케이션 로그가 필요하다.

10. 남은 위험과 다음 단계

• 현재 검증 버튼은 선택 사항이라 저장·세션 시작을 막지 않는다.
• 선택한 사용자·아바타 한 조합만 검사하므로 모든 프리셋 조합의 최대 길이를 보장하지 않는다.
• 실제 OpenAI 요청 smoke test와 배포 브라우저 UI 검증이 없다.
• 공식 모델 페이지 수치와 내부 공유 수치가 달라 한도를 상수 하나로 고정하면 다시 오래될 수 있다.
• 검증 성공 로그는 지침 본문·임시 시크릿을 저장하지 말고, memberId, templateId, hashes, model, 결과, provider token 수치만 구조화해 남겨야 한다.

우선순위: ① 활동 저장 게이트 ② 공통 변수 영향도 재검증 큐 ③ DynamoDB 검증 스냅샷 ④ 세션 시작 hash 확인 ⑤ provider 거부 구조화 로그 ⑥ 관리자용 축약 제안 워크플로.

관련 문서