아무튼서로알아들었으면된거아닌가요

정확한지는 모르겠고, 아무튼 알아들었어요.

네. 진짜 프로젝트 이름이 이겁니다.

ASAD는 라이브 통역과 현장 응대를 위한 AI 통역 보조 서비스입니다.

정식 명칭은 아무튼서로알아들었으면된거아닌가요입니다. 줄여서 ASAD라고 부릅니다. 왜 ASAD냐고요? 풀네임을 매번 타이핑하다가는 통역보다 프로젝트 이름 입력이 더 오래 걸리기 때문입니다.

이 프로젝트의 목표는 거창하게 "언어의 장벽을 혁신적으로 제거"하는 것이 아닙니다.

그냥 이겁니다.

A: 뭐라고 했어요?

B: 대충 이런 말이래요.

A: 아 이해했어요.

ASAD: 아무튼 서로 알아들었으면 된 거 아닌가요?

다만 실제 구현은 이름만큼 대충 만들지 않았습니다. 그랬다가는 날짜 하나 잘못 번역해서 예약이 날아가고, 이름 하나 잘못 알아들어서 사람 하나가 갑자기 다른 사람이 되는 기적을 보게 됩니다.

---

그래서 이게 뭐 하는 물건인가요

ASAD에는 크게 두 가지 모드가 있습니다.

1. Live Interpretation

한 사람이 계속 말하고, 사람이 통역하는 상황을 보조합니다.

예:

• 설교
• 강연
• 회의
• 인터뷰
• 기타 "말은 계속 나오는데 통역사의 뇌는 하나뿐인" 상황

ASAD가 하는 일:

• 놓치기 쉬운 문맥 붙잡기
• 고유명사와 용어 기억하기 (한 번 정해진 이름 표기는 세션 내내 흔들리지 않습니다)
• 성경 구절 참조 잡기
• 한국어의 뒤늦게 등장하는 술어 때문에 통역사가 영혼까지 기다리지 않도록 문장 골격 보조하기
• 말장난, 관용어, 문화적 표현 감지하기
• 이미 통역사가 말해버린 문장을 뒤늦게 몰래 갈아엎지 않기

즉, 통역사를 없애는 AI가 아니라 통역사 옆에서 메모 잘하는 매우 과몰입한 조수에 가깝습니다.

시작 전에 고를 것은 언어 한 쌍뿐입니다

예전에는 시작하기 전에 설교 모드냐 일반 모드냐를 먼저 정해야 했습니다. 아무도 말을 꺼내기 전에, 나중에 바꿀 수도 없이요.

지금은 고를 게 이것뿐입니다.

[ 말하는 언어 ]  →  [ 통역할 언어 ]

[        통역 시작        ]

상황(예배·강연·회의·대화·행사)은 ASAD가 말에서 읽어냅니다. 성경 구절이 잡히는지, 어떤 용어가 얼마나 자주 나오는지, 어떤 담화 표현이 쓰이는지, 준비 시트에 뭐라고 적혀 있는지, 그리고 어차피 보내던 통역 요청에 모델이 얹어 보내주는 판단까지 — 여섯 갈래 신호를 합쳐서 정합니다. 상황 판단 때문에 모델을 한 번 더 부르지는 않습니다.

콘솔 위쪽에 Auto · Worship 처럼 지금 무엇으로 보고 있는지 떠 있고, 마음에 안 들면 거기서 한 번에 바꿀 수 있습니다. 바꿀 일이 없는 게 정상입니다.

한 문장 잘못 나왔다고 상황이 휙휙 바뀌지는 않습니다. 새 후보가 기존 판단을 일정 점수 이상 앞질러야만 넘어갑니다. 지나가는 말 한마디로 예배가 회의가 되면 그게 더 이상한 일이니까요.

2. Counter Mode

두 사람이 창구나 현장에서 마주 앉아 서로 다른 언어를 쓰는 상황을 위한 모드입니다.

직원은 /counter를 열고 QR 코드를 띄웁니다. 방문자는 자기 휴대폰으로 QR을 찍고 자기 언어를 고릅니다. 앱 설치는 없습니다. 회원가입도 없습니다. 인간은 이미 충분히 많은 회원가입을 하고 있습니다.

그다음 양쪽이 채팅 또는 음성으로 대화합니다.

예:

• 민원실
• 안내 데스크
• 접수창구
• 병원 접수
• 행사 안내
• 기타 "상대방 말은 모르겠는데 일단 업무는 끝내야 하는" 장소

---

이름은 대충인데 왜 내부는 이렇게 진지한가요

통역은 틀려도 웃고 넘길 수 있는 문장과 틀리면 일이 터지는 문장이 섞여 있습니다.

"제주도 날씨 좋네요"가 조금 이상하게 번역되는 건 인류가 감당할 수 있습니다.

하지만 아래는 아닙니다.

• 3시가 13시가 됨
• 150,000원이 15,000원이 됨
• 좌영춘가 갑자기 자영춘가 됨
• 9월 12일이 12월 9일이 됨

그래서 ASAD는 번역 문장을 예쁘게 만드는 것보다 언제 확정했고, 무엇이 위험하고, 사용자가 어디를 다시 확인해야 하는지를 중요하게 봅니다.

Live가 지키는 것

• Temporal locking: 이미 통역사가 말했을 가능성이 높은 문장은 뒤늦게 슬쩍 수정하지 않습니다.
• 확정 / 예상 분리: 아직 확정되지 않은 예상 출력은 확정 번역과 다르게 보입니다.
• 짧은 thought unit: 소설을 써주는 게 아니라 실제 입 밖으로 꺼낼 수 있는 길이로 제시합니다.
• 한국어 지연 구조 대응: 핵심 술어가 문장 맨 끝에서 뒤늦게 등장하는 한국어의 장난질에 대응합니다.
• 고유명사 교정: 이름이나 용어를 한 번 수정하면 이후 흐름에 반영합니다.
• 성경 본문 보호: 모르면 성경을 새로 집필하지 않습니다. 기본값은 reference-only입니다.

Counter가 지키는 것

• 양쪽 화면에 양쪽 언어를 함께 표시합니다.
• 자주 쓰는 빠른 문구는 고정 번역으로 처리할 수 있습니다.
• 숫자, 날짜, 시간, 금액, 이름처럼 사고 나기 좋은 값은 다시 확인하기 쉽게 만듭니다.
• 음성 인식 결과를 전송 전에 직접 수정할 수 있습니다.
• 번역에 실패하면 실패했다고 말합니다. 아무 문자열이나 번역인 척 내밀지 않습니다.
• 어느 쪽이 끝내든 양쪽 화면이 알아서 빠져나갑니다. 방문자 화면은 종료 안내로 넘어가고(브라우저가 허용하면 탭까지 닫습니다), 직원 화면은 시작 화면으로 돌아갑니다. 끝난 대화를 그대로 띄워둔 기기만큼 위험한 물건이 없습니다. 다음 손님은 새 QR로 새로 시작하면 됩니다.

---

한국교회 통역 봉사자를 위한 특화

ASAD는 원래 "말은 계속 나오는데 통역사의 뇌는 하나뿐인" 모든 상황을 돕습니다. 그중 한국교회 예배 통역은 유독 조건이 까다롭습니다.

• 신학 용어는 틀리면 교리가 틀립니다. 칭의가 "의로움" 정도로 뭉개지면 그날 설교의 절반이 증발합니다.
• 청중은 한국인만이 아닙니다. 유학생, 이주 노동자, 관광객이 같은 예배당에 앉아 있습니다. 중국어 통역이 필요한 순간이 옵니다.
• 통역자는 대개 봉사자입니다. 프로가 아닙니다. 프로의 실수를 줄여주는 도구와 봉사자가 감당할 수 있게 해주는 도구는 다른 물건입니다.

그래서 교회 특화 팩이 있습니다. 기존 엔진을 뜯어고친 게 아니라, 교회라는 상황에 맞는 층을 올린 것입니다.

• 신학 용어집 팩 (data/theological-glossary.json): 한국어 신학 용어 79개의 영어·중국어 표준 번역. 통역 파이프라인이 용어를 찾을 때 이 팩을 가장 먼저 봅니다. 준비 시트에 적힌 봉사자의 선택이 그보다 우선합니다. 봉사자가 정한 것은 표준도 못 바꿉니다.
• 교회 모임 프리셋: 예배·설교·기도회·성경공부·수련회. 상황 자동 판단이 "예배"를 잡아내면, 그 안에서 지금이 어떤 모임인지까지 구분합니다. 기도회는 기도 제목의 흐름으로, 성경공부는 질문과 나눔으로 돕습니다.
• 성경 구절 표기 강제: 모든 구절 참조는 1 Peter 2:9 형태의 장:절 표기로 정규화됩니다. 모델이 내놓은 구절은 로컬에서 실제로 들은 구절과 대조해서 검증 표시를 답니다. 못 들은 구절을 아는 척하지 않습니다. 기존 "모르면 새로 쓰지 않는다" 원칙의 실행 버전입니다.

파일럿 계획은 docs/church-pilot.md에 있습니다. 3개 교회, 4주. 재는 건 세 가지입니다. 용어 정확도, 통역사 만족도, Counter Mode 안내데스크 활용도.

---

현재 화면들

경로	인간이 여기서 하는 일
/	시작합니다. 모든 실수의 출발점입니다.
/live	라이브 통역 콘솔
/counter	현장 응대 직원 화면
/c/...	QR을 찍고 들어오는 방문자 화면
/prep	화자, 본문, 용어 등을 미리 넣어 AI에게 예습을 시킵니다
/booth-preflight	믹서 입력, 신호 레벨, mix-minus 등을 점검합니다. 공연 시작 후 깨닫지 마세요
/remote-mic	컴퓨터 QR을 찍은 휴대폰(iPhone·Android)이 무선 마이크가 되는 화면 (원격 마이크, 같은 Wi-Fi 불필요)
/sessions	저장한 세션 복기 및 내보내기
/diagnostics	"왜 안 되지?"를 감정이 아니라 데이터로 확인하는 곳

홈 화면에서는 라이브 통역, 현장 응대, 준비 시트, 부스 사전 점검, 지난 세션으로 바로 들어갈 수 있습니다.

---

언어 지원

언어에 대해 아는 것은 src/lib/languages.ts 한 곳에 모여 있습니다. 태그, 문자 체계, 쓰기 방향, 띄어쓰기 여부, 인식기별 지원 수준, 크롬 기기 내 번역기 코드, 그리고 그 언어를 어디에 내놓아도 되는지까지 전부요.

예전에는 이 정보가 다섯 군데에 흩어져 있었고, 그래서 Counter에는 25개 언어가 있는데 Live는 한국어→영어 하나뿐이었습니다. 이제 Live도 같은 목록에서 언어 쌍을 고릅니다.

현재 25개 언어가 들어 있습니다.

• 한국어
• 영어
• 중국어 간체 / 번체
• 일본어
• 베트남어
• 태국어
• 인도네시아어
• 러시아어
• 우즈베크어
• 몽골어
• 네팔어
• 크메르어
• 미얀마어
• 타갈로그어
• 스페인어
• 프랑스어
• 독일어
• 포르투갈어
• 아랍어
• 힌디어
• 벵골어
• 우르두어
• 터키어
• 위구르어

방문자에게는 언어 이름을 한국어가 아니라 각 언어의 자기 표기(endonym) 로 보여줍니다.

예를 들어 중국어 사용자가 언어 선택 화면에서 굳이 중국어라는 한글부터 해독해야 한다면 이미 UX가 패배한 겁니다.

번체 중국어와 "되는 척"에 대하여

zh-CN과 zh-TW는 읽는 사람 입장에서 서로 다른 글입니다. 그런데 Whisper 계열 음성 인식 API는 언어는 고르게 해주지만 문자 체계는 고르게 해주지 않습니다. zh만 받습니다.

그래서 번체를 고른 방문자가 간체로 받아적혀 있는데도 시스템은 "성공"이라고 보고하는 일이 생깁니다.

지금은 이렇게 처리합니다.

1. 레지스트리가 그 한계를 variant-lossy라고 명시합니다. 숨기지 않습니다.
2. 문자 체계를 못 지키는 경로는, 지킬 수 있는 경로보다 뒤로 밀립니다. OpenAI만 설정된 배포에서 번체를 고르면 브라우저 인식으로 먼저 갑니다.
3. 그래도 그 경로밖에 없으면 화면에 그렇게 적힙니다. 조용히 넘어가지 않습니다.
4. 번역 쪽에도 목표 문자 체계를 프롬프트에 못박습니다. "Chinese"라고만 하면 모델은 간체를 내놓으니까요.

이건 중국어 전용 땜질이 아닙니다. 원인이 "태그가 담고 있는 문자 정보를 공급자 API가 표현하지 못한다"이기 때문에, 같은 모양의 다른 언어 쌍도 같은 규칙으로 처리됩니다.

브라우저 SpeechRecognition 지원 수준은 언어와 브라우저마다 다릅니다. 일부 언어는 음성보다 텍스트 입력이 더 안정적입니다. 브라우저 제조사들이 모두 같은 세상에 사는 것처럼 API를 지원해 주면 좋겠지만 현실은 그렇지 않습니다.

Counter 음성 인식은 기본 경로가 실패했을 때 선택적으로 Hugging Face Whisper STT fallback도 사용할 수 있습니다.

언어별로 어떤 인식기가 실제로 그 언어를 처리할 수 있는지는 src/providers/stt/capability.ts에 선언되어 있습니다. 처리할 수 없는 인식기에는 아예 연결을 시도하지 않습니다.

위구르어는 현재 타이핑 전용입니다. 이 스택에 설정된 어떤 인식기도 위구르어를 받지 않기 때문에, 마이크 버튼을 보여 주고 실패하게 두는 대신 처음부터 텍스트 입력을 정상 경로로 안내합니다. 위구르어는 아랍 문자를 쓰지만 아랍어가 아니고, 튀르크어족이지만 우즈베크어나 터키어도 아닙니다. 그 셋 중 어느 쪽으로도 라우팅되지 않습니다.

---

This is the beginning of the README. Read the rest at the original. Read the full README ↗