AI에이전트엔지니어링

종료 버튼을 누르면 그때부터 진짜가 시작됩니다. 롤플레이 훈련 챗봇을 직접 만들면서 가장 오래 붙잡고 있던 부분은 AI 고객의 말투도, 화면 디자인도 아니었습니다. 대화가 끝난 다음 "그래서 이 사람은 잘한 건가, 못한 건가"를 어떻게 판정하느냐였습니다. 채점이 없으면 롤플레이는 그냥 심심풀이 대화로 끝납니다. 반대로 채점이 엉성하면 훈련하는 사람이 시스템을 신뢰하지 않게 되고, 결국 아무도 쓰지 않습니다. 이 글은 이 채점 로직을 어떤 의도로 설계했는지, 왜 "정답 하나"로 매기지 않기로 했는지를 코드 설계 관점에서 자세히 정리합니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 10-7편 ← 이전: 10-6 퀴즈 풀 사전생성 / 다음 → 10-8 혼자 쓰는 챗봇의 현실 10-5 AI 고객 페르소나 프롬프트 엔지니어링 10-6 퀴즈 풀 사전생성 10-7 대화가 끝나면 채점한다 (현재 글) 10-8 혼자 쓰는 챗봇의 현실 11-1 KMS 프로젝트가 실사 이후로 밀리는 이유 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2 실시간 음성에 MCP가 필요한 이유 3-3 스트리밍 중 MCP 초고속 데이터 룩업 3...

출제 버튼을 누를 때마다 LLM을 부르면 안 됩니다. 롤플레이 학습 챗봇에 도메인 퀴즈 기능을 붙이면서 가장 먼저 내린 결정이 이것이었습니다. 언뜻 보면 "문제 하나 만들어 줘"는 LLM에게 가장 쉬운 일처럼 보입니다. 하지만 사용자가 퀴즈를 풀 때마다 매번 모델을 호출하는 구조는, 만들어 놓고 보니 셋 다 나쁜 선택이었습니다. 느리고, 돈이 들고, 품질이 흔들립니다. 이 글은 그래서 퀴즈를 미리 만들어 풀(pool)로 저장하기로 한 이야기입니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 10-6편 ← 이전: 10-5 AI 고객 페르소나 프롬프트 엔지니어링 / 다음 → 10-7 대화가 끝나면 채점한다 10-4 멀티 LLM 백엔드 스위칭 10-5 AI 고객 페르소나 프롬프트 엔지니어링 10-6 퀴즈 풀 사전생성 (현재 글) 10-7 대화가 끝나면 채점한다 10-8 혼자 쓰는 챗봇의 현실 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2 실시간 음성에 MCP가 필요한 이유 3-3 스트리밍 중 MCP 초고속 데이터 룩업 3-4 통화 중 외부 API 도구 호출 3-5 실시간 세션 관리 — 통화 맥락·고객 데이터 Part ...

롤플레이 챗봇을 직접 만들면서 가장 오래 붙잡고 있었던 건 아키텍처도, RAG도 아니었습니다. AI 고객의 성격이었습니다. 처음 만든 AI 고객은 너무 착했습니다. 사업담당자 역할로 제가 어설프게 답해도 "아, 정말 좋네요"라며 다 받아 주더군요. 연습이 되질 않았습니다. 이 글은 그 착한 AI 고객을 어떻게 훈련용 상대로 다듬어 갔는지, 페르소나 프롬프트를 튜닝한 실패와 수정의 기록입니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 10-5편 ← 이전: 10-4 멀티 LLM 백엔드 스위칭 / 다음 → 10-6 퀴즈 풀 사전생성 10-3 RAG 파이프라인과 로컬 임베딩 10-4 멀티 LLM 백엔드 스위칭 10-5 AI 고객 페르소나 프롬프트 엔지니어링 (현재 글) 10-6 퀴즈 풀 사전생성 10-7 대화가 끝나면 채점한다 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2 실시간 음성에 MCP가 필요한 이유 3-3 스트리밍 중 MCP 초고속 데이터 룩업 3-4 통화 중 외부 API 도구 호출 3-5 실시간 세션 관리 — 통화 맥락·고객 데이터 Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편) 4-1 동적...

처음에는 로컬 Ollama 하나면 충분하다고 생각했습니다. 신입·경력직이 특정 B2B 도메인을 롤플레이로 익히도록 만든 이 챗봇은 어차피 필자 혼자, 길어야 두세 명이 돌려 볼 물건이었으니까요. API 키를 발급받고 요금을 걱정할 것도 없이, 노트북에서 gemma3:12b 하나 띄워 두고 AI 고객과 대화하면 그만이라고 봤습니다. 그런데 어느 날 여러 대화 턴이 거의 동시에 들어오는 상황을 흉내 내다가, 모델이 통째로 죽었습니다. 이 글은 그 사건에서 출발해, LLM 백엔드를 하나로 못 박지 않고 Claude CLI·Gemini API·로컬 Ollama 세 갈래로 벌려 두고 런타임에 갈아끼우게 만든 과정을 트러블슈팅 로그로 정리합니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 10-4편 ← 이전: 10-3 RAG 파이프라인과 로컬 임베딩 / 다음 → 10-5 AI 고객 페르소나 프롬프트 엔지니어링 10-2 전체 아키텍처 한 장 10-3 RAG 파이프라인과 로컬 임베딩 10-4 멀티 LLM 백엔드 스위칭 (현재 글) 10-5 AI 고객 페르소나 프롬프트 엔지니어링 10-6 퀴즈 풀 사전생성 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2...