들어가며
UI 설계에서 우리는 사용자 시나리오로부터 구현이 지켜야 할 약속 세 가지를 도출했습니다: 가설 카드의 3단계 상태, 시각 자료 5종과 필수 항목, 분석 단계의 실황 중계. 이 문서는 그 약속을 지키는 AI 에이전트를 어떻게 구성할지를 다룹니다.
먼저 범위를 선언합니다. 이 문서는 기존 구현(4개 워커 멀티 에이전트, 의도 enum 라우팅, 턴게이트)을 백지화하는 게 아니라 개정합니다. 유지되는 것: 멀티 에이전트 골격, 턴게이트의 경량/중량 분기, 관측 스팬 체계. 바뀌는 것: 의도 enum 라우팅 폐기, 검증 에이전트의 2층 분리, 기억 관리자 신설. 기존 설계 문서와 충돌하면 본 문서가 우선합니다.
중심 원칙: 모델은 부품, 축적물이 자산
AI 연구 70년의 교훈을 정리한 유명한 에세이가 있습니다. 리처드 서튼의 "The Bitter Lesson" - 사람이 도메인 지식을 시스템 구조에 새겨 넣는 접근은, 장기적으로 항상 범용 방법과 더 큰 계산량에 패배해 왔다는 관찰입니다. 우리에게 번역하면: 마케팅에 특화된 파인튜닝 모델이나 하드코딩된 판단 로직을 만드는 순간, 다음 세대 범용 LLM이 나올 때마다 그것은 자산이 아니라 부채가 됩니다.
그래서 구조를 이렇게 가릅니다. 판단은 항상 그 시점의 최고 LLM이 하고, 우리는 판단에 먹일 재료와 판단을 채점할 기준만 쌓습니다. LLM은 판사이고, 우리가 쌓는 것은 판례집과 법전입니다. 판사는 언제든 더 좋은 판사로 교체되지만 판례집은 우리 것이고, 판사가 좋아질수록 같은 판례집에서 더 좋은 판결이 나옵니다.
이 원칙의 실무 판별법은 간단합니다. "이 에이전트에서 모델을 빼면 무엇이 남는가?" 남는 것이 버전 관리되는 파일들(프롬프트, 루브릭, 스키마, 정책)이면 잘 설계된 것이고, 남는 것이 코드에 박힌 판단 로직이면 다시 설계해야 합니다.
에이전트 구성: 세 개의 세계
에이전트를 나누는 정당한 이유는 네 가지뿐입니다: 도구가 다르거나, 컨텍스트를 격리해야 하거나, 병렬로 돌 수 있거나, 실패 방식이 달라서. 이 기준으로 나누면 세 개의 세계가 나옵니다.
런타임: 사용자가 기다리는 동안 도는 것
컨설턴트 (중앙). 유일하게 사용자와 말하는 존재입니다. 대화의 목소리는 하나여야 합니다 - 문단마다 다른 사람과 말하는 느낌이 들면 컨설팅이 아닙니다. 의도 해석과 라우팅도 여기서 하는데, 방식이 바뀝니다. 기존의 의도 enum(고정 분류표 + 분기문)은 경계 케이스에서 오라우팅을 내고, 모델이 좋아져도 분류표가 병목이 됩니다. 대신 "각 전문가가 언제 적합한지"를 서술한 문서를 컨설턴트가 읽고 판단합니다. 도구 설명서를 읽고 도구를 고르는 것과 같은 방식이고, 서술 문서는 코드가 아니라 버전 관리되는 데이터입니다. 애매하면 되묻고, 가벼운 질문은 위임 없이 즉답합니다(턴게이트의 Quick-Lookup 유지).
분석가. 도구 경계: 지표 쿼리와 통계 계산. 원칙 하나가 중요합니다 - 모든 숫자는 도구가 계산하고, LLM은 계산하지 않고 인용만 합니다. 진단과 평가가 모두 분석가의 일입니다. 평가 전용 에이전트는 없습니다. 평가란 "가설 카드가 앵커로 붙은 분석"일 뿐이고, 이것이 UI에서 "평가는 단계가 아니라 상태"라고 결정한 것의 에이전트 버전입니다.
전략가. 도구 경계: 트렌드 정리본과 마케터 휴리스틱의 ES 검색. 분석가의 사실과 검색된 근거를 엮어 가설 후보를 만듭니다 - 실행 내용, 기간, 예측 범위, 그리고 근거 ID 목록까지. 검색을 별도 에이전트로 빼지 않는 이유: 무엇을 검색할지와 검색 결과로 무엇을 주장할지는 같은 맥락 안에서 판단되어야 하며, 쪼개면 전달 과정에서 뉘앙스가 유실됩니다.
작성자. 실행물 제작 전담: 콘텐츠 실험안, 마케팅 문구, 보고용 브리프. 사용자가 산출물을 원할 때만 조건부로 호출됩니다. 기존 구성과의 결정적 차이 - 작성자는 일반 답변의 문장을 쓰지 않습니다. 그것은 컨설턴트의 일입니다.
분석가와 전략가는 도구가 달라 병렬로 돕니다. UI의 실황 중계에서 "지표 조회 중"과 "트렌드 스캔 중"이 동시에 올라가는 것이 바로 이 병렬 실행의 중계입니다.
에이전트 사이의 전달물은 자유 텍스트가 아니라 구조화된 스키마입니다(UI의 시각 자료 스키마와 같은 형태). 근거 ID가 구조로 흘러야 다음 절의 게이트가 기계적으로 대조할 수 있습니다. 이 핸드오프 스키마도 모델을 바꿔도 살아남는 자산 목록에 들어갑니다.
게이트: 답변이 사용자에게 닿기 전에
기존 설계의 "검증 에이전트" 하나를 성격이 다른 두 층으로 쪼갭니다. 이 분리가 이 문서에서 가장 중요한 변경입니다.
코드 게이트 (LLM 아님). 형식과 존재만 검사합니다: 시각 자료 필수 항목이 채워졌는가, 인용된 트렌드·휴리스틱 ID가 실제 도구 반환값에 존재하는가, 예측이 범위 형식인가, 규제 금칙어가 없는가. "코드는 유지보수가 힘들지 않냐"는 걱정이 나올 수 있는데, 코드가 썩는 것은 코드 안에 판단("어떤 답이 좋은 답인가")을 박을 때입니다. 이 층에는 판단이 없습니다. 있냐/없냐만 봅니다. 계약을 검사하는 몇백 줄짜리 코드는 모델이 백 번 바뀌어도 유효합니다.
심판 (LLM Judge). 코드가 못 보는 의미를 봅니다: 인용은 있는데 그 근거가 정말 이 주장을 지지하는가(업계에서 groundedness/faithfulness라 부르는 검증), 말투가 브랜드를 해치는가, 편향이나 비하가 섞였는가.
여기서 "환각이 환각을 거를 수 있냐"는 질문이 나옵니다. 절반은 맞는 걱정입니다 - 같은 문제를 같은 방식으로 두 번 풀면 같이 틀립니다. 하지만 심판은 문제를 다시 푸는 게 아니라 정답지를 들고 채점합니다. 정답지는 LLM의 기억이 아니라 ES에 저장된 실제 데이터이고, 심판의 과제는 "이 주장이 세상에서 참인가"(어려움)가 아니라 "이 주장이 이 문서에 적혀 있는가"(훨씬 쉬움)입니다. 검증은 생성보다 쉽다는 비대칭이 있어서, 같은 급의 모델이라도 채점자 역할에서는 훨씬 덜 틀립니다.
그래도 심판을 맹신하지 않습니다. 심판도 성적표를 받습니다 - 마케터가 라벨한 사례가 쌓이면 심판 판정과 사람 판정의 일치율을 재고, 일치율이 떨어지면 루브릭을 고칩니다.
실행 시점은 비용과 지연의 문제입니다: 코드 게이트는 모든 답변에 인라인(밀리초 단위라 부담 없음), 심판은 고부담 출력에만 인라인(가설 카드 생성, 작성자의 문구처럼 밖으로 나가는 것), 일반 답변은 오프라인에서 샘플링 채점합니다.
마지막 겹은 사람입니다. 가설 카드는 사용자 승인 없이 생기지 않습니다(human-in-the-loop). 코드 게이트, 심판, 심판의 성적표, 사람 승인 - 어느 한 겹도 완벽하지 않지만 구멍의 위치가 서로 다릅니다. 안전공학에서 스위스 치즈 모델이라 부르는 다층 방어이고, 우리 검증 체계의 사고방식입니다.
백그라운드: 사용자가 기다리지 않는 것
기억 관리자. 대화가 끝나면 그 대화에서 남길 것을 두 층의 파일로 승격합니다: 사용자 층(브랜드 톤, 선호, 금기)과 캠페인 층(목표, 외부 요인, 배운 것). 대화 자체는 메모리를 갖지 않습니다 - 대화는 캠페인 안에서 자유롭게 생기고 사라지는 존재이기 때문입니다(UI 결정과 동형). 파일 기반을 택한 진짜 이유는 검색이 아니라 거버넌스입니다: 팀이 열어보고, 잘못 저장된 것을 고치고, 버전 관리할 수 있습니다. 임베딩 벡터 덩어리는 아무도 감사할 수 없습니다.
저장은 게이트를 거칩니다: 사실/피드백/맥락의 형식 강제, 출처 발화 링크 필수, 사용자의 농담이나 악의적 입력이 검증 없이 사실로 승격되는 것 방지. 파일마다 크기 상한(약 2,000자)을 두고, 넘치면 기억 관리자가 압축합니다. 매 턴 컨텍스트에는 사용자 층 + 해당 캠페인 층만 항상 로드됩니다 - 작아서 부담이 없고, 그래서 상한이 필요합니다.
수집 파이프라인 (배치). 트렌드 정리본을 만드는 세계입니다: 영상 해석(멀티모달), 왜 터졌나 구조화, 생애 단계 판정, 그리고 밈의 원출처 리스크 플래그. 런타임과 완전히 분리되어 있고 주기도 다릅니다(일간 시그널, 주간 심층). 런타임 에이전트는 영상을 직접 보지 않고 이 정리본만 검색합니다.
피드백을 판례로: "실무에 못 쓴다"의 변환
마케터의 "이 답변은 실무에 못 쓴다"는 주관적 피드백을 규칙(if-then)으로 손수 번역하려는 순간 유지보수 지옥이 시작됩니다 - 그것이 바로 썩는 특화 로직입니다. 대신 세 단계로 갑니다.
- 루브릭으로 분해. "못 쓴다"는 사실 몇 개의 차원입니다: 실행 가능성(내일 아침에 뭘 하라는 건지 구체적인가), 근거 충실성(groundedness), 시의성(피로 단계 트렌드를 추천하지 않았는가), 검증 가능성(지표·기간·범위 명시), 앵커 적합성(이 캠페인 목표에 맞는가). 루브릭 자체가 버전 관리되는 데이터입니다.
- 심판이 채점. 각 차원을 점수 + 사유로 채점합니다(LLM-as-a-Judge). 기존 평가 하네스의 확장이지 신규 시스템이 아닙니다.
- 골든셋으로 축적. "못 쓴다"고 라벨된 답변은 사유와 함께 회귀 테스트 케이스가 됩니다. 이후 프롬프트·모델·파이프라인의 모든 변경은 이 사례집을 통과해야 배포됩니다. 코드의 테스트 주도 개발과 같은 구조(eval-driven development)입니다. 주관이 객관이 되는 방법은 규칙화가 아니라 누적된 판례에 대한 재현 검증입니다.
부트스트랩. 사용자가 생기기 전 골든셋은 빕니다. 초기 사례집은 UI 문서의 장면 대본에서 시나리오별 모범/불량 답변을 우리가 작성하고, 협력 마케터가 라벨하는 세션으로 만듭니다. 이 세션이 심판 루브릭의 첫 검증도 겸합니다.
휴리스틱 카드 형식. 마케터 암묵지는 "조건 - 행동 - 예외 - 출처(누가, 언제)" 구조의 카드로 수집합니다. 형식만 지금 확정하고, 수집 절차(인터뷰 대상·주기·큐레이션 담당)는 별도 운영 계획으로 갑니다.
안전성: 두 겹과 한국 특수성
- 하드 필터 (코드 게이트 소속). 한국 규제는 LLM 판단에 맡기면 안 되는 층입니다: 뷰티는 화장품법상 의약품 오인 표현("치료", "재생") 금지, 푸드는 허위·과장 광고 제한, 협찬·광고 표기 의무. 정책 파일(버전 관리되는 데이터)로 관리합니다.
- 회색지대 (심판 소속). 브랜드 톤 저해, 편향·비하, 경쟁사 비방, 민감 이슈 편승.
- 밈 리스크는 수집 시점에. 원출처가 문제인 밈(혐오 커뮤니티 발, 논란 인물 연관)은 답변 시점에 잡기 어렵습니다. 수집 파이프라인이 정리본에 리스크 플래그를 붙여 추천을 원천 차단합니다.
실패 카탈로그: 미리 적어두는 망가지는 방법들
관측 체계(OpenInference 스팬 + Phoenix)는 대시보드가 아니라 이 카탈로그를 감시하는 눈입니다. 각 항목은 감지 신호(스팬에서 자동 확인), 골든셋 테스트 케이스, 발생 시 대응을 갖습니다.
| 실패 모드 |
방어 |
| 근거 날조 - 인용한 트렌드가 검색 결과에 없음 |
코드 게이트가 ID 실존 대조. 가장 중요한 자동 검증 |
| 숫자 암산 - LLM이 지표를 계산하다 틀림 |
원천 봉쇄: 계산은 도구만, LLM은 인용만 |
| 뒷북 추천 - 피로 단계 트렌드를 상승이라 말함 |
정리본의 생애 단계 필드와 답변 대조 |
| 앵커 이탈 - 캠페인 A 방에서 B 데이터로 답변 |
방의 캠페인 ID와 도구 호출 파라미터 대조 |
| 단정 예측 - 범위 없이 "+15%" |
코드 게이트의 형식 검사에서 거부 |
| 메모리 오염 - 농담·주입 공격이 사실로 저장 |
저장 게이트 + 메모리 파일이 사람이 읽는 파일이라 감사 가능 |
| 루프 폭주 - 도구 무한 재호출 |
스텝 상한 + 스팬 알람 |
카탈로그는 살아있는 문서입니다. 실제 장애가 날 때마다 항목이 추가됩니다 - 이것도 판례 축적입니다.
강등 경로. 전문가가 타임아웃되면 컨설턴트가 부분 결과로 답하되 한계를 고지합니다("트렌드 대조는 이번에 못 했습니다"). 실황 중계 UI 덕분에 어느 단계까지 진행됐는지 사용자가 이미 보고 있어서, 강등을 정직하게 보여줄 수 있습니다. 모델 전체 장애 시에는 조회성 답변만 제공합니다.
거버넌스 루프: 전체를 묶는 것
관측(스팬) → 채점(심판 + 루브릭) → 축적(골든셋·메모리·휴리스틱) → 승격(반복되는 판례를 정책과 기준서로 명문화) → 회귀(모든 변경은 골든셋 통과 후 배포). 판례가 쌓이면 법조문으로 승격되는 사법 시스템과 같은 구조입니다.
모델이 업그레이드되면 어떻게 되나? 판사만 바뀌고 루프는 그대로 돕니다. 골든셋 점수가 오르는 것을 확인하고 배포하면 됩니다. 특화 시스템에게 모델 업그레이드는 재작업이지만, 우리에게는 무료 성능 향상입니다. 이것이 "LLM에 판단을 맡기고 우리는 거버넌스와 암묵지를 축적한다"의 구현입니다.
마치며: 모델을 바꿔도 살아남는 것들
이 설계의 성공 기준은 단순합니다. 모델 교체 시 코드 변경 0, 그리고 아래 자산 목록이 계속 자라는가.
역할 프롬프트 · 라우팅 서술 문서 · 핸드오프 스키마 · 메모리 파일(사용자·캠페인 층) · 평가 루브릭 · 안전 정책 파일 · 골든셋 · 실패 카탈로그 · 휴리스틱 카드 · 트렌드 정리본.
열 개 전부 사람이 읽고 고칠 수 있는 데이터입니다. 코드는 이 데이터를 흘려보내는 배관이고, 모델은 갈아끼우는 펌프입니다.
다음 단계: 팀 리뷰 → 라우팅 서술 문서 + 핸드오프 스키마 작성 → 코드 게이트 검사 항목 확정 → 루브릭 v1 + 골든셋 부트스트랩 세션 → 기억 관리자 저장 게이트 구현.
참고한 사고 틀: The Bitter Lesson(서튼) - 왜 판단을 범용 모델에 맡기는가 / 검증 비대칭 - 왜 심판이 성립하는가 / LLM-as-a-Judge와 메타 평가 - 심판 운영법 / Groundedness(RAG 평가) - 근거 충실성의 업계 표준 / 스위스 치즈 모델 - 왜 겹겹이 거르는가 / Human-in-the-loop - 어디에 사람을 두는가 / Eval-driven development - 배포의 규율 / Build-Measure-Learn(린 스타트업) - 제품이 사용자에게 시키는 일.
들어가며
UI 설계에서 우리는 사용자 시나리오로부터 구현이 지켜야 할 약속 세 가지를 도출했습니다: 가설 카드의 3단계 상태, 시각 자료 5종과 필수 항목, 분석 단계의 실황 중계. 이 문서는 그 약속을 지키는 AI 에이전트를 어떻게 구성할지를 다룹니다.
먼저 범위를 선언합니다. 이 문서는 기존 구현(4개 워커 멀티 에이전트, 의도 enum 라우팅, 턴게이트)을 백지화하는 게 아니라 개정합니다. 유지되는 것: 멀티 에이전트 골격, 턴게이트의 경량/중량 분기, 관측 스팬 체계. 바뀌는 것: 의도 enum 라우팅 폐기, 검증 에이전트의 2층 분리, 기억 관리자 신설. 기존 설계 문서와 충돌하면 본 문서가 우선합니다.
중심 원칙: 모델은 부품, 축적물이 자산
AI 연구 70년의 교훈을 정리한 유명한 에세이가 있습니다. 리처드 서튼의 "The Bitter Lesson" - 사람이 도메인 지식을 시스템 구조에 새겨 넣는 접근은, 장기적으로 항상 범용 방법과 더 큰 계산량에 패배해 왔다는 관찰입니다. 우리에게 번역하면: 마케팅에 특화된 파인튜닝 모델이나 하드코딩된 판단 로직을 만드는 순간, 다음 세대 범용 LLM이 나올 때마다 그것은 자산이 아니라 부채가 됩니다.
그래서 구조를 이렇게 가릅니다. 판단은 항상 그 시점의 최고 LLM이 하고, 우리는 판단에 먹일 재료와 판단을 채점할 기준만 쌓습니다. LLM은 판사이고, 우리가 쌓는 것은 판례집과 법전입니다. 판사는 언제든 더 좋은 판사로 교체되지만 판례집은 우리 것이고, 판사가 좋아질수록 같은 판례집에서 더 좋은 판결이 나옵니다.
이 원칙의 실무 판별법은 간단합니다. "이 에이전트에서 모델을 빼면 무엇이 남는가?" 남는 것이 버전 관리되는 파일들(프롬프트, 루브릭, 스키마, 정책)이면 잘 설계된 것이고, 남는 것이 코드에 박힌 판단 로직이면 다시 설계해야 합니다.
에이전트 구성: 세 개의 세계
에이전트를 나누는 정당한 이유는 네 가지뿐입니다: 도구가 다르거나, 컨텍스트를 격리해야 하거나, 병렬로 돌 수 있거나, 실패 방식이 달라서. 이 기준으로 나누면 세 개의 세계가 나옵니다.
런타임: 사용자가 기다리는 동안 도는 것
컨설턴트 (중앙). 유일하게 사용자와 말하는 존재입니다. 대화의 목소리는 하나여야 합니다 - 문단마다 다른 사람과 말하는 느낌이 들면 컨설팅이 아닙니다. 의도 해석과 라우팅도 여기서 하는데, 방식이 바뀝니다. 기존의 의도 enum(고정 분류표 + 분기문)은 경계 케이스에서 오라우팅을 내고, 모델이 좋아져도 분류표가 병목이 됩니다. 대신 "각 전문가가 언제 적합한지"를 서술한 문서를 컨설턴트가 읽고 판단합니다. 도구 설명서를 읽고 도구를 고르는 것과 같은 방식이고, 서술 문서는 코드가 아니라 버전 관리되는 데이터입니다. 애매하면 되묻고, 가벼운 질문은 위임 없이 즉답합니다(턴게이트의 Quick-Lookup 유지).
분석가. 도구 경계: 지표 쿼리와 통계 계산. 원칙 하나가 중요합니다 - 모든 숫자는 도구가 계산하고, LLM은 계산하지 않고 인용만 합니다. 진단과 평가가 모두 분석가의 일입니다. 평가 전용 에이전트는 없습니다. 평가란 "가설 카드가 앵커로 붙은 분석"일 뿐이고, 이것이 UI에서 "평가는 단계가 아니라 상태"라고 결정한 것의 에이전트 버전입니다.
전략가. 도구 경계: 트렌드 정리본과 마케터 휴리스틱의 ES 검색. 분석가의 사실과 검색된 근거를 엮어 가설 후보를 만듭니다 - 실행 내용, 기간, 예측 범위, 그리고 근거 ID 목록까지. 검색을 별도 에이전트로 빼지 않는 이유: 무엇을 검색할지와 검색 결과로 무엇을 주장할지는 같은 맥락 안에서 판단되어야 하며, 쪼개면 전달 과정에서 뉘앙스가 유실됩니다.
작성자. 실행물 제작 전담: 콘텐츠 실험안, 마케팅 문구, 보고용 브리프. 사용자가 산출물을 원할 때만 조건부로 호출됩니다. 기존 구성과의 결정적 차이 - 작성자는 일반 답변의 문장을 쓰지 않습니다. 그것은 컨설턴트의 일입니다.
분석가와 전략가는 도구가 달라 병렬로 돕니다. UI의 실황 중계에서 "지표 조회 중"과 "트렌드 스캔 중"이 동시에 올라가는 것이 바로 이 병렬 실행의 중계입니다.
에이전트 사이의 전달물은 자유 텍스트가 아니라 구조화된 스키마입니다(UI의 시각 자료 스키마와 같은 형태). 근거 ID가 구조로 흘러야 다음 절의 게이트가 기계적으로 대조할 수 있습니다. 이 핸드오프 스키마도 모델을 바꿔도 살아남는 자산 목록에 들어갑니다.
게이트: 답변이 사용자에게 닿기 전에
기존 설계의 "검증 에이전트" 하나를 성격이 다른 두 층으로 쪼갭니다. 이 분리가 이 문서에서 가장 중요한 변경입니다.
코드 게이트 (LLM 아님). 형식과 존재만 검사합니다: 시각 자료 필수 항목이 채워졌는가, 인용된 트렌드·휴리스틱 ID가 실제 도구 반환값에 존재하는가, 예측이 범위 형식인가, 규제 금칙어가 없는가. "코드는 유지보수가 힘들지 않냐"는 걱정이 나올 수 있는데, 코드가 썩는 것은 코드 안에 판단("어떤 답이 좋은 답인가")을 박을 때입니다. 이 층에는 판단이 없습니다. 있냐/없냐만 봅니다. 계약을 검사하는 몇백 줄짜리 코드는 모델이 백 번 바뀌어도 유효합니다.
심판 (LLM Judge). 코드가 못 보는 의미를 봅니다: 인용은 있는데 그 근거가 정말 이 주장을 지지하는가(업계에서 groundedness/faithfulness라 부르는 검증), 말투가 브랜드를 해치는가, 편향이나 비하가 섞였는가.
여기서 "환각이 환각을 거를 수 있냐"는 질문이 나옵니다. 절반은 맞는 걱정입니다 - 같은 문제를 같은 방식으로 두 번 풀면 같이 틀립니다. 하지만 심판은 문제를 다시 푸는 게 아니라 정답지를 들고 채점합니다. 정답지는 LLM의 기억이 아니라 ES에 저장된 실제 데이터이고, 심판의 과제는 "이 주장이 세상에서 참인가"(어려움)가 아니라 "이 주장이 이 문서에 적혀 있는가"(훨씬 쉬움)입니다. 검증은 생성보다 쉽다는 비대칭이 있어서, 같은 급의 모델이라도 채점자 역할에서는 훨씬 덜 틀립니다.
그래도 심판을 맹신하지 않습니다. 심판도 성적표를 받습니다 - 마케터가 라벨한 사례가 쌓이면 심판 판정과 사람 판정의 일치율을 재고, 일치율이 떨어지면 루브릭을 고칩니다.
실행 시점은 비용과 지연의 문제입니다: 코드 게이트는 모든 답변에 인라인(밀리초 단위라 부담 없음), 심판은 고부담 출력에만 인라인(가설 카드 생성, 작성자의 문구처럼 밖으로 나가는 것), 일반 답변은 오프라인에서 샘플링 채점합니다.
마지막 겹은 사람입니다. 가설 카드는 사용자 승인 없이 생기지 않습니다(human-in-the-loop). 코드 게이트, 심판, 심판의 성적표, 사람 승인 - 어느 한 겹도 완벽하지 않지만 구멍의 위치가 서로 다릅니다. 안전공학에서 스위스 치즈 모델이라 부르는 다층 방어이고, 우리 검증 체계의 사고방식입니다.
백그라운드: 사용자가 기다리지 않는 것
기억 관리자. 대화가 끝나면 그 대화에서 남길 것을 두 층의 파일로 승격합니다: 사용자 층(브랜드 톤, 선호, 금기)과 캠페인 층(목표, 외부 요인, 배운 것). 대화 자체는 메모리를 갖지 않습니다 - 대화는 캠페인 안에서 자유롭게 생기고 사라지는 존재이기 때문입니다(UI 결정과 동형). 파일 기반을 택한 진짜 이유는 검색이 아니라 거버넌스입니다: 팀이 열어보고, 잘못 저장된 것을 고치고, 버전 관리할 수 있습니다. 임베딩 벡터 덩어리는 아무도 감사할 수 없습니다.
저장은 게이트를 거칩니다: 사실/피드백/맥락의 형식 강제, 출처 발화 링크 필수, 사용자의 농담이나 악의적 입력이 검증 없이 사실로 승격되는 것 방지. 파일마다 크기 상한(약 2,000자)을 두고, 넘치면 기억 관리자가 압축합니다. 매 턴 컨텍스트에는 사용자 층 + 해당 캠페인 층만 항상 로드됩니다 - 작아서 부담이 없고, 그래서 상한이 필요합니다.
수집 파이프라인 (배치). 트렌드 정리본을 만드는 세계입니다: 영상 해석(멀티모달), 왜 터졌나 구조화, 생애 단계 판정, 그리고 밈의 원출처 리스크 플래그. 런타임과 완전히 분리되어 있고 주기도 다릅니다(일간 시그널, 주간 심층). 런타임 에이전트는 영상을 직접 보지 않고 이 정리본만 검색합니다.
피드백을 판례로: "실무에 못 쓴다"의 변환
마케터의 "이 답변은 실무에 못 쓴다"는 주관적 피드백을 규칙(if-then)으로 손수 번역하려는 순간 유지보수 지옥이 시작됩니다 - 그것이 바로 썩는 특화 로직입니다. 대신 세 단계로 갑니다.
부트스트랩. 사용자가 생기기 전 골든셋은 빕니다. 초기 사례집은 UI 문서의 장면 대본에서 시나리오별 모범/불량 답변을 우리가 작성하고, 협력 마케터가 라벨하는 세션으로 만듭니다. 이 세션이 심판 루브릭의 첫 검증도 겸합니다.
휴리스틱 카드 형식. 마케터 암묵지는 "조건 - 행동 - 예외 - 출처(누가, 언제)" 구조의 카드로 수집합니다. 형식만 지금 확정하고, 수집 절차(인터뷰 대상·주기·큐레이션 담당)는 별도 운영 계획으로 갑니다.
안전성: 두 겹과 한국 특수성
실패 카탈로그: 미리 적어두는 망가지는 방법들
관측 체계(OpenInference 스팬 + Phoenix)는 대시보드가 아니라 이 카탈로그를 감시하는 눈입니다. 각 항목은 감지 신호(스팬에서 자동 확인), 골든셋 테스트 케이스, 발생 시 대응을 갖습니다.
카탈로그는 살아있는 문서입니다. 실제 장애가 날 때마다 항목이 추가됩니다 - 이것도 판례 축적입니다.
강등 경로. 전문가가 타임아웃되면 컨설턴트가 부분 결과로 답하되 한계를 고지합니다("트렌드 대조는 이번에 못 했습니다"). 실황 중계 UI 덕분에 어느 단계까지 진행됐는지 사용자가 이미 보고 있어서, 강등을 정직하게 보여줄 수 있습니다. 모델 전체 장애 시에는 조회성 답변만 제공합니다.
거버넌스 루프: 전체를 묶는 것
관측(스팬) → 채점(심판 + 루브릭) → 축적(골든셋·메모리·휴리스틱) → 승격(반복되는 판례를 정책과 기준서로 명문화) → 회귀(모든 변경은 골든셋 통과 후 배포). 판례가 쌓이면 법조문으로 승격되는 사법 시스템과 같은 구조입니다.
모델이 업그레이드되면 어떻게 되나? 판사만 바뀌고 루프는 그대로 돕니다. 골든셋 점수가 오르는 것을 확인하고 배포하면 됩니다. 특화 시스템에게 모델 업그레이드는 재작업이지만, 우리에게는 무료 성능 향상입니다. 이것이 "LLM에 판단을 맡기고 우리는 거버넌스와 암묵지를 축적한다"의 구현입니다.
마치며: 모델을 바꿔도 살아남는 것들
이 설계의 성공 기준은 단순합니다. 모델 교체 시 코드 변경 0, 그리고 아래 자산 목록이 계속 자라는가.
역할 프롬프트 · 라우팅 서술 문서 · 핸드오프 스키마 · 메모리 파일(사용자·캠페인 층) · 평가 루브릭 · 안전 정책 파일 · 골든셋 · 실패 카탈로그 · 휴리스틱 카드 · 트렌드 정리본.
열 개 전부 사람이 읽고 고칠 수 있는 데이터입니다. 코드는 이 데이터를 흘려보내는 배관이고, 모델은 갈아끼우는 펌프입니다.
다음 단계: 팀 리뷰 → 라우팅 서술 문서 + 핸드오프 스키마 작성 → 코드 게이트 검사 항목 확정 → 루브릭 v1 + 골든셋 부트스트랩 세션 → 기억 관리자 저장 게이트 구현.
참고한 사고 틀: The Bitter Lesson(서튼) - 왜 판단을 범용 모델에 맡기는가 / 검증 비대칭 - 왜 심판이 성립하는가 / LLM-as-a-Judge와 메타 평가 - 심판 운영법 / Groundedness(RAG 평가) - 근거 충실성의 업계 표준 / 스위스 치즈 모델 - 왜 겹겹이 거르는가 / Human-in-the-loop - 어디에 사람을 두는가 / Eval-driven development - 배포의 규율 / Build-Measure-Learn(린 스타트업) - 제품이 사용자에게 시키는 일.