Gem3Park — 주차장 인터폰 음성 AI

주차장 인터폰으로 걸려 온 방문 차량의 전화를 AI가 받아, 동·호수와 방문 목적을 확인하고 주차 관제 시스템에 출입 명령을 보낸다. 확신할 수 없으면 차단기를 열지 않고 상담원에게 넘긴다.

전화망(Asterisk PBX)부터 실시간 오디오 처리, STT·LLM·TTS 연동, 상태 기반 대화 제어, 주차 관제 API 연동, 운영 모니터링 웹, 장애 복구 자동화까지 혼자 설계·개발·배포·운영했다. 2026년 2월 첫 커밋 이후 실제 현장 통화를 받으며, 운영 로그와 녹음에서 드러난 인식 오류를 하나씩 구조로 막아 왔다.

목차: 1. 개요 · 2. 만든 것 · 3. 시스템 구성 · 4. 통화 처리 흐름 · 5. 운영 지표 · 6. 기술적 도전 · 7. 연혁 · 8. 배포·운영 · 9. 품질 · 10. 결정 기록 · 11. 한계 · 12. 역량

1. 서비스 개요

1.1 풀어야 했던 문제

1.2 통화 한 건에서 일어나는 일

1. 운전자가 인터폰을 누르면 SIP 통화가 Asterisk에 들어오고, AudioSocket으로 TypeScript Relay에 음성이 흐른다.
2. 안내 음성이 나간 뒤 Relay가 필요한 정보(동·호수, 방문 목적)를 하나씩 묻는다.
3. 발화마다 Google STT가 전사하고, 같은 청취 창에서 Gemini 3.5 Transcribe Live가 병렬로 듣는다.
4. 동·호수는 현장 허용 목록과 0 하나 차이 위험 쌍 검사를 통과해야 채택된다. 방문 목적은 규칙과 LLM 판정 체인을 거친다.
5. 정보가 확정되면 주차 관제 API에 출입 명령을 보내고, 끝까지 확정되지 않으면 상담원에게 인계한다.
6. 통화가 끝나면 명령·대화·토큰·오디오 처리·검증 결과를 구조화된 요약으로 남기고, 모니터링 웹이 이를 실시간으로 보여 준다.

2. 만든 것

3. 시스템 구성

flowchart LR
    Caller["운전자 / 인터폰"] -->|SIP| PBX["Asterisk PBX"]
    PBX -->|AudioSocket PCM| Relay["TypeScript Relay"]
    Relay --> STT["Google Cloud STT<br/>(주 경로)"]
    Relay --> Live["Gemini 3.5 Transcribe Live<br/>(병렬 보조)"]
    STT --> Gate["guided 상태<br/>슬롯 충족 판정"]
    Live --> Gate
    Gate -->|누락 시 같은 턴 WAV| Assist["Gemini 오디오 재전사"]
    Assist --> Validate["파서 · 허용 목록 · 모호성 가드<br/>· 방문 목적 판정"]
    Gate --> Validate
    Validate -->|검증된 슬롯만| Flow["상태 기반 대화 제어"]
    Flow --> TTS["Google Cloud TTS"]
    TTS --> Relay
    Flow -->|출입 명령| API["주차 관제 API"]
    Flow -->|상담원 인계| PBX
    Relay --> Summary["통화 종료 요약 · 로그 · 녹음"]
    Summary --> Monitor["모니터링 웹<br/>(사설망 HTTPS)"]

• Relay가 통화 하나의 모든 단계를 소유한다. 모델 호출은 단계별로 분리해 지연·오류·비용을 따로 관측하고 교체한다.
• STT는 Google이 주 경로다. Gemini 3.5 Transcribe Live는 같은 청취 창에서 병렬로 돌며, Google 결과에서 빠진 정보만 표준 라벨로 보충한다.
• LLM은 판단을 넘겨받지 않는다. 출입 여부는 상태 기계와 허용 목록이 정하고, LLM은 표현 이해와 누락 보완에만 쓴다.
• 모니터링 웹은 공개 인터넷에 열지 않고 운영자의 사설망(tailnet) 안에서만 HTTPS로 연다.

4. 통화 처리 흐름

4.1 동·호수 확정

flowchart TD
    A["발화"] --> B["Google STT 전사 + N-best"]
    B --> C{"허용 목록에 있나"}
    C -->|없음| D["같은 턴 WAV를 Gemini가 재전사"]
    D --> C2{"허용 목록에 있나"}
    C2 -->|없음| R["재질문<br/>(미스 1회는 한도에서 제외)"]
    C -->|있음| E{"0 하나 차이 위험 쌍인가"}
    C2 -->|있음| E
    E -->|아님| OK["채택"]
    E -->|위험| F["Gemini 같은 턴 전사 우선"]
    F --> G{"두 결과가 같은가"}
    G -->|같음| OK
    G -->|다름| H["호출자에게 확인"]
    H -->|확인 실패| R
    R -->|한도 초과| AG["상담원 인계"]

• 출입 명령을 만들기 직전에 같은 허용 목록 검사를 한 번 더 한다. 중간 경로에서 섞인 값도 여기서 막힌다.
• 모호성이 풀리지 않은 상태에서는 출입 명령을 만들지 않는다(fail-closed).

4.2 방문 목적 판정

모든 단계는 같은 표준 라벨 9개(택배·배달, 픽업, 가족·지인, 상가 방문, 업무, 공사, 응급, 아파트 시설, 일반 방문) 중 하나만 돌려줄 수 있고, 그 밖의 답은 알 수 없음으로 처리한다.

5. 운영 지표

아래 표는 기간과 측정 목적이 서로 달라 합산하지 않는다.

5.1 외부 명령 응답 (2026-02-22 ~ 06-04 보존 로그)

성공률은 주차 관제 API의 응답 기준이며, 차단기가 물리적으로 열렸는지 잰 값이 아니다.

5.2 누락 정보 보조 전사 (2026-07-31 ~ 08-05, 통화 종료 요약 640건)

24.2%는 보조 결과가 빈 슬롯에 들어간 적용률이다. 전사 정확도나 최종 성공률 향상 폭이 아니다.

5.3 최근 처리 결과 (2026-09-28 ~ 10-01, 426통화)

실패 20건 중 16건이 "동호수 재질문 횟수 초과"였다. 이 결과가 6.10의 자기 정정 복구 작업으로 이어졌다.

5.4 방문 목적 텍스트 모델 비교 (9월 실제 발화 300건, 호출 545회)

기준값은 통화가 최종 전송한 방문 목적이며 사람이 검수한 정답이 아니다. 정확도는 비슷하고 지연이 크게 짧아서, 방문 목적 텍스트 호출만 3.6-flash로 옮겼다.

6. 기술적 도전과 해결

각 항목은 문제 → 원인 → 해결 → 검증 → 결과 순서로 정리했다. 결과는 코드와 로그가 뒷받침하는 범위까지만 적었다.

6.1 전화망 음질을 AI가 처리할 수 있는 스트림으로

• 문제: 통화마다 8kHz 또는 16kHz로 들어오는 PCM과 24kHz TTS 출력을 그대로 이으면 STT 입력 규격이 흔들리고 재생 속도가 통화 시간축과 어긋난다.
• 해결: 수신 코덱을 감지해 8kHz는 16kHz로 올리고 필터·게인을 건 뒤 STT에 넘긴다. TTS 출력은 통화 코덱에 맞게 내리고 20ms 청크로 나눠 큐에 넣는다. 소켓 backpressure가 생기면 drain까지 멈추고 큐 상한을 넘은 오래된 청크는 버린다.
• 검증: 8kHz 320바이트·16kHz 640바이트 청크가 각각 20ms인지, 리샘플링 길이·출력 코덱·첫 청크 전송을 로그로 확인한다.
• 결과: STT에는 일관된 16kHz를, Asterisk에는 실시간 속도의 프레임을 돌려주고, 느린 소켓 때문에 재생 지연이 끝없이 쌓이지 않게 했다.

6.2 방문 목적 인식 실패를 단계별로 복구

• 문제: 짧거나 간접적인 방문 목적이 한 번의 STT 결과에서 빠지면 정상 방문도 unknown이 됐다. 그렇다고 불확실한 목적을 자동 승인할 수는 없다.
• 해결: 4.2의 판정 체인을 만들었다. 재질문 한도 직전에는 통화 전체 발화로 의미 판정을 한 번 더 하고, 그래도 없으면 원음을 오디오로 판정한다. 끝까지 unknown이면 상담원에게 넘긴다.
• 검증: 판정마다 시도 여부, 고른 WAV, 모델, 라벨, 오류를 통화 요약에 남긴다. 단위 테스트가 텍스트 판정 helper와 full-call WAV 우선·rolling WAV 폴백 선택을 검증한다.

6.3 STT가 놓친 정보만 같은 턴 원음으로 다시 듣기

• 문제: 첫 발화뿐 아니라 재질문·확인 턴에서도 STT가 동·호수나 방문 목적을 비우거나 잘못 들었다.
• 해결: 모든 guided 턴에서 STT와 현재 상태를 먼저 검사하고, 필요한 정보가 남았을 때만 같은 턴 WAV를 Gemini에 한 번 보내 전사만 받는다. 반환된 전사문도 기존 파서·허용 목록을 그대로 통과해야 하고, 이미 확정된 값은 덮어쓰지 않는다. 턴 단위 single-flight, timeout·abort, 늦게 온 결과 폐기를 관리한다.
• 검증: 완전한 STT일 때 호출 생략, 중복 요청 방지, timeout·세션 종료, 슬롯 충돌, 허용 목록 미스를 테스트한다. 관측 기록에는 전사 원문 없이 trigger·적용 슬롯·지연·오류 코드만 남긴다.
• 결과: 5.2의 지표. Gemini가 실패해도 기존 재질문·상담원 인계 흐름은 막히지 않는다.

6.4 잘못 들은 동·호수가 출입 명령으로 이어지지 않게

• 해결: SIP별 phrase hint와 숫자 보정은 인식 후보를 고르는 데만 쓰고, 실제 출입 가능 여부는 현장 허용 목록이 정한다. 텍스트에서 못 찾으면 최근 발화 WAV를 다시 전사하고, 출입 명령 직전에 같은 검사를 한 번 더 한다.
• 검증: 판정을 text_allowlist_match/miss, audio_allowlist_match/miss로 구분해 기록한다. 단위 테스트가 비허용 동·호수가 든 출입 명령 생성을 거부하는지 검증한다.

6.5 생성형 응답에 기대던 재질문을 상태 기계로

• 문제: LLM이 재질문의 내용과 시점을 모두 정하면 이미 받은 정보를 다시 묻거나 매번 다른 흐름이 나왔다.
• 해결: 동·호수·방문 목적 슬롯을 상태로 두고, 비어 있는 항목만 묻는 결정론적 질문을 LLM보다 먼저 고른다. 재질문 횟수를 제한하고, 한도를 넘거나 Gemini가 429·503을 돌려주면 상담원 인계로 바꾼다.

6.6 프로세스는 살아 있는데 전화가 끊길 때

• 문제: Asterisk와 Relay가 모두 떠 있어도 SIP 등록이 Rejected에 머물면 인입 전화가 바로 끊겼다. 일시적인 401 인증 실패 뒤 재등록 시도가 멈춘 것이 원인이었다.
• 해결: watchdog을 프로세스 → Asterisk CLI 응답 → PJSIP 등록 3단계로 만들었다. 등록 이상이면 전체 재시작보다 pjsip reload를 먼저 하고, 복구되지 않을 때만 Asterisk를 재시작한다. systemd timer가 40초마다 실행하고, 재시작은 5분 창 안에서 최대 3회로 제한한다.
• 검증: Rejected·Unregistered·No response·Maximum retries를 비정상으로 판정하는 parser를 별도 스크립트로 테스트하고, 복구 절차를 runbook으로 남겼다.

6.7 0 하나 차이인 호수의 오승인 막기 (2026-08)

• 문제: 호출자는 1006호라고 했는데 106호로 확정된 통화가 있었다.
• 원인: Google N-best 후보 중 하나만 쓰고 나머지를 버렸고, 106호도 허용 목록에 있어서 그대로 통과해 Gemini 검증을 건너뛰었다. 이 단지 허용 목록에는 0 하나를 넣거나 빼면 서로 바뀌는 쌍이 15개 동에 75개 있었다(101↔1001부터 106↔1006까지 여섯 유형).
• 해결: 턴마다 N-best를 비공개로 보존하고, 위험 쌍이 걸린 턴은 Gemini 같은 턴 전사를 우선한다. 두 결과가 다르면 호출자에게 확인받고, 확인이 안 되면 재질문한다. 모호성이 풀리지 않으면 출입 명령을 막는다.
• 검증: 당시 npm test 614개 통과, 배포 전 시나리오 게이트를 runbook으로 정리했다.
• 남은 것: 공백 없이 붙은 STT 결과(101호출입 형태)가 가드를 우회하는 경로가 남아 있다(11장).

6.8 Gemini 3.5 Transcribe Live: 관측 → 보조로 단계 승격 (2026-08 ~ 09)

• 배경: Google STT를 바꾸지 않고 두 번째 귀를 붙일 수 있는지 확인하고 싶었다. 3.5 Live는 N-best를 주지 않아서 주 경로로는 쓸 수 없었다.
• 순서: PoC → 통화 결과에 영향 없는 관측 전용 shadow → 동·호수 전용 보조 → 모든 청취 창에서 Google과 병렬 실행. Google에서 방문 목적을 못 찾으면 VAD 종료 시점부터 최대 3초 기다렸다가 표준 라벨만 보충한다.
• 측정:
  • 사전 replay(사람이 확인한 감사 통화 3건, 발화 창 5개): 문장 일치 4/5, 동·호수 3/3, 목적 3/3. 재생 종료 후 지연 122~225ms(중앙값 204ms, 3개 창)
  • 운영 반영 직후(통화 5건, 청취 창 8개): 성공 7/8, timeout 1, 목적 일치 7/7, 성공 결과 지연 평균 1.02초
• 해석: 표본이 작아 정확도를 주장하지 않는다. 테스트 계획의 다음 합격 단계(offline 300턴, shadow 1,000창·7일)는 아직 기록이 없다.

6.9 분류 호출의 48%가 timeout이던 문제 (2026-09)

• 문제: 9월 28일 실측에서 방문 목적 분류 호출 77회 중 37회(48%)가 2.0초 timeout으로 버려졌다.
• 원인: thinking 토큰이 작은 출력 한도(maxOutputTokens 32)를 먼저 다 써 버려 응답이 비거나 잘렸다.
• 해결: thinking 토큰 여유분(512)을 별도로 두고, 5.4의 비교를 근거로 방문 목적 텍스트 호출만 Gemini 3.6-flash로 옮겼다. 대화 LLM 기본값은 3.7-flash로 두고, 정확히 HTTP 503일 때만 3.6으로 한 번 폴백한다.
• 함께 한 것: 외부 결정 모델 Jev를 판정 체인 앞에 shadow로 붙였다. 키워드로 풀리지 않은 9월 발화 442건 offline 재생에서 67건(15.2%)을 확정했고, 그중 63건(94.0%)이 통화의 최종 목적과 같았다(지연 p50 205ms). 기준값이 사람 검수 정답이 아니어서 active 전환은 보류했다.

6.10 자기 정정한 동·호수를 복구하고, 한 번의 미스로 끊기지 않게 (2026-10)

• 문제: 호출자가 동·호수를 말하다 고쳐 말한 통화에서 Gemini는 정정까지 맞게 들었지만, 파서가 첫 매치만 써서 허용 목록에서 거절됐다. 그 미스가 재질문 한도를 다 써 상담원으로 넘어갔다. 5.3의 실패 20건 중 16건이 이 유형(동호수 재질문 초과)이었다.

• 해결: 발화 안의 허용 후보가 하나뿐일 때만 채택하는 추출기와 세 가지 복구 금지 규칙을 넣었다. 허용 목록 미스 턴 1회는 재질문 한도에서 빼는 설정(GUIDED_ALLOWLIST_MISS_GRACE_TURNS, 기본 1)을 추가했다.

• 검증: npm test 771개 통과(변경 전 736개). 07-30 이후 저장 발화 11,738건(미스 460건)에 새 파서를 재생했다.

  	복구	최종 발급과 일치	불일치	확인 불가
  복구 금지 규칙 없이	16	8	4	4
  복구 금지 규칙 적용 (배포본)	9	8	0	1

  금지 규칙이 없으면 잘못된 복구 4건이 생겨서 규칙을 넣은 판을 배포했다. 미스 턴 면제는 통화 흐름 단위라 재생으로 잴 수 없어 단위·브리지 테스트로만 검증했다.

6.11 운영 모니터링 웹을 다시 만들기 (2026-09)

• 문제: 한 통화를 보려면 Relay 로그, Asterisk 로그, 통화 요약 파일, 녹음을 따로 찾아야 했고, 프로그램이 채택한 전사·공급자 원문·사람이 들은 내용을 구별할 화면이 없었다.
• 해결:
  • 통화 검색: 기간·결과·녹음 유무·검수 상태·전사 내용으로 찾는다. 날짜별 영속 인덱스와 커서 페이지네이션을 쓴다.
  • 녹음 재생: HTTP Range, ±5초 이동, 배속, A–B 반복. 청취 창 단위로 "이 구간 듣기"를 제공한다.
  • 검수 기록: revision을 별도 파일에 원자적으로 저장하고, 동시 수정은 409로 막는다.
  • 공급자 비교: 녹음과 전사 쌍의 해시가 맞을 때만 보여 준다.
  • 사이트 설정 편집, SSE 증분 갱신.
• 보안: 서버 사용자 파일 + scrypt 해시, 8시간 세션, HttpOnly·Secure·SameSite=Strict 쿠키, 쓰기 요청 CSRF 검사, viewer·reviewer·admin 역할과 장소 범위, 로그인 시도 제한. 공개 터널 없이 운영자 사설망 안에서만 TLS 1.3 HTTPS로 연다.
• 검증: 단위 21개, Playwright E2E 5개(axe로 WCAG 2.2 AA 자동 검사), HTTPS 통합 1개. 합성 인덱스 10만 건에서 목록 API p95 14.45ms(warm 캐시, 단일 클라이언트이므로 부하 성능은 아님).
• 결과: 2026-09-12 운영 반영, 녹음 12,002건 인덱싱, 실제 HTTPS 브라우저 접속 확인.

7. 개발 연혁

8. 배포와 운영

8.1 운영 방식

• 프로세스: Relay와 모니터링 웹을 PM2로 관리한다. graceful shutdown으로 진행 중인 통화 처리를 정리한다.
• 전화망 감시: systemd timer watchdog이 40초마다 Asterisk와 PJSIP 등록을 확인하고, reload → 제한된 restart 순서로 복구한다.
• 기능 단계 배포: 새 인식·판정 경로는 observe/shadow → assist → active 순서로 올린다. 통화 결과에 영향을 주기 전에 관측 필드로 효과와 실패를 먼저 본다.
• 모델 전환: 모델과 경로는 환경 변수로 바꾼다. 대화 LLM, 방문 목적 텍스트 모델, 오디오 전사 모델을 따로 정할 수 있다.
• 재현 도구: 저장된 발화와 WAV로 파서·판정을 다시 돌리는 replay 스크립트로 배포 전 효과와 부작용을 잰다(6.10).

8.2 운영하며 배운 것

• "살아 있음"과 "전화를 받을 수 있음"은 다르다. 프로세스 생존만 보던 health check를 SIP 등록까지 넓혔다.
• 허용 목록에 있다고 맞는 값은 아니다. 실제로 있는 다른 세대로 잘못 들을 수 있어서 위험 쌍을 따로 다룬다.
• 정확도만큼 지연이 결과를 바꾼다. 같은 정확도라도 timeout 안에 오지 않으면 운영에서는 틀린 것과 같았다(5.4).
• 복구 규칙은 복구 수보다 오복구 0이 먼저다. 금지 규칙 없이 16건을 살리는 판보다 9건을 살리고 오복구가 없는 판을 배포했다.
• 수치는 측정 대상과 함께 적는다. 적용률·응답 성공률·기준값 일치율을 정확도처럼 말하지 않는다.

9. 품질과 테스트

아직 통합 테스트로 묶지 못한 경로: 텍스트·오디오 판정이 모두 실패한 뒤 실제 상담원 연결, 외부 명령 전송 직전 허용 목록 차단, 블랙리스트 통화 분기, VAD의 실제 발화 종료.

10. 기술 스택과 결정 기록

11. 한계와 다음 단계

재현성 제약: Asterisk dialplan과 PJSIP 설정은 저장소 밖에서 관리되므로 저장소만으로는 SIP 수신부터 상담원 인계까지의 전체 환경을 재현할 수 없다.

12. 이 프로젝트로 증명한 역량