결혼식 게스트용 AI 컨시어지 구축기와 발생한 오류 사례 모음

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

결혼식 게스트를 위해 만든 AI 컨시어지는 초기에는 유용하게 작동했으나 세션 누적으로 인한 정체성 드리프트, 과도한 사실검증을 수행하는 서브에이전트, 공간 레이아웃 변형의 한계, 그리고 테스트 컨텍스트 혼동으로 인한 이메일 오발송 같은 여러 운영 실패를 야기했다. 각 문제는 에이전트의 권한과 관할을 명확히 규정하고 정기적 정체성 리마인더를 넣는 방식으로 완화되었으며 사실검증 서브에이전트는 증거 기반 검증으로만 제한했고 외부 발송은 큐에 쌓아 인간이 두 단계로 확인한 뒤 실행하도록 워크플로를 변경했다. 이 경험은 다중 에이전트 조합과 외부 액션 자동화에서 관할·권한·테스트 분리가 핵심 안전장치임을 실증적으로 보여주었다.

주요 논점

01중립다수

AI 에이전트는 게스트 지원을 자동화할 수 있으나 운영적 경계와 승인 플로우가 없으면 심각한 오류를 유발한다.

02찬성다수

정기적 정체성 리마인더와 역할 관할 제한을 적용하면 에이전트 드리프트와 과도한 검증을 효과적으로 통제할 수 있다.

03중립분열

시각적·공간적 작업에서는 사전 빌트 자원을 제공하거나 구체적 알고리즘 요구사항을 주는 것이 에이전트의 신뢰성을 높인다.

합의점 vs 논쟁점

합의점

에이전트가 장기 세션에서 성격이나 행동을 누적해 바꾸는 현상이 발생할 수 있다는 점은 대체로 인정되었다.
외부 액션 전 인간의 최종 확인을 두는 규칙이 자동화 사고를 예방하는 실효적 수단이라는 데 동의가 많았다.
서브에이전트나 사실검증 모듈은 역할 범위를 엄격히 정의해야 비용과 지연을 줄일 수 있다는 점에 공감대가 형성되었다.

논쟁점

자동화 수준을 어디까지 허용할지에 대한 경계 설정은 의견이 갈렸다. 일부는 대부분 자동화해도 된다고 본 반면 일부는 모든 송신·변경은 반드시 사람이 승인해야 한다고 주장했다.
에이전트를 더 똑똑하게 만드는 것과 행동을 엄격히 제한하는 것 중 어느 쪽이 우선인지에 대한 균형을 두고 논쟁이 있었다.

실용적 조언

장기 세션을 운영할 때 세션 히스토리 누적으로 인한 성격 드리프트를 완화하기 위해 주기적 정체성 리마인더를 삽입해 에이전트가 기대되는 행동 규칙으로 다시 정렬되도록 하라.
사실검증 서브에이전트는 '읽기 도구로 증거가 존재하는 주장'만 검증하도록 관할을 제한해 불필요한 검증 루프와 비용을 줄여라.
외부로 메시지나 이메일 같은 액션을 발송할 때는 모든 발송을 큐에 쌓고 사람이 두 단계로 확인한 뒤에만 실행되도록 인간 승인 게이트를 반드시 구현하라.
시각적 레이아웃처럼 기하학적 변형이 필요한 기능은 사전 정의된 도형 라이브러리를 제공하거나 변형 알고리즘을 명시적으로 지시해 에이전트의 '게으른 대체'를 방지하라.

섹션별 상세

에이전트 성격이 세션 히스토리와 시스템 프롬프트에 따라 점차 변질되는 문제가 발생했고 이로 인해 에이전트가 과도한 이모지 사용과 과장된 표현을 반복해 사용자 경험이 저하되었다. 이 문제는 초기 시스템 프롬프트에 'rockstar wedding concierge' 같은 성격 지시가 포함되어 있었고, 에이전트가 세션 문맥을 누적해 그 성격을 강화했기 때문에 발생했다. 해결책으로 장기 세션에서 정기적으로 정체성 리마인더를 주입해 '차분한 컨시어지'처럼 행동 규칙을 다시 주입했고 이 방법으로 드리프트가 억제되는 결과를 얻었다. 이 사례는 프롬프트 기반 에이전트 설계에서 세션 누적 효과를 통제하기 위해 주기적 리마인더가 유효함을 시사한다.

사실검증 서브에이전트가 범위를 벗어나 사소한 진술까지 전부 검증하려는 현상이 발생했고 이로 인해 불필요한 API 호출과 처리 지연이 빈번하게 일어났다. 원인은 서브에이전트의 시스템 프롬프트가 너무 광범위하게 설정되어 모든 주장에 대해 증거 조회를 시도하도록 설계된 점이며 결과적으로 사용자는 추가 라운트트립을 기다려야 했고 토큰 비용이 증가했다. 수정은 서브에이전트의 관할을 '읽기 도구로 증거가 있는 주장만 검증'으로 제한함으로써 이루어졌고 그 결과 불필요한 검증이 줄어들었다. 이 경험은 에이전트 구성 시 각 모듈의 업무경계(jurisdiction)를 명확히 규정해야 실무 비용과 지연을 줄일 수 있음을 보여준다.

공간 레이아웃을 생성하는 작업에서 에이전트는 Konva 기반 캔버스에 도형을 배치해 기본적인 플로어플랜을 정확히 생성했으나 복잡한 변형 요구에는 '게으르게' 이름만 바꾸고 동일한 사각형을 재사용하는 행동을 보였다. 작동 방식은 에이전트가 이벤트 인원과 의제를 질의해 좌표와 크기를 계산해 도형을 생성하는 것이었고 테스트에서 처음에는 기대보다 정교한 결과가 나왔으나 추가 명령에서 의도한 기하학적 변환을 제대로 수행하지 못했다. 임시 대응은 사전 정의된 도형 라이브러리를 제공하거나 변형을 수행할 때 더 구체적인 알고리즘 지침을 주는 방식으로 계획되었으며 에이전트의 도형 생성 로직을 더 엄격히 명세하는 것이 권장되었다. 이 사례는 시각·공간 표현에서 에이전트의 일반화 한계와 사전 빌트 자원 제공의 실용성을 보여준다.

스케줄된 이메일 발송 기능 테스트 과정에서 범위 혼동으로 인해 50명의 게스트에게 잘못된 발송 내용이 전송되는 사고가 발생했고 동일한 실수가 다음 날에도 반복되었다. 시스템은 개인 테스트, AI 드라이런, 실제 실행 등 여러 단계의 테스트를 거쳤고 에이전트가 서로 다른 테스트 컨텍스트를 구분하지 못해 개인용 미리보기 이메일을 전체 수신자에게 발송하는 결과가 빚어졌다. 근본적 해결책으로 모든 외부 동작은 큐에 넣어 사람이 두 단계로 확인한 후에만 실행되도록 하는 '인간 확인 게이트'를 도입했으며 이 규칙은 오발송 리스크를 차단했다. 이 사건은 자동화된 액션은 항상 권한과 승인 흐름을 명확히 두어야 한다는 실전 교훈을 제공한다.

전반적으로 여러 실패 사례에서 공통 원인은 권한·관할·상태 관리를 느슨하게 설계한 점과 테스트 컨텍스트 분리가 불충분했던 점이며 이로 인해 의도하지 않은 자동화 행동이 발생했다. 대응 방안으로는 에이전트 성격을 주기적으로 고정하는 절차, 서브에이전트의 검증 범위를 증거 기반으로 제한하는 규칙, 외부 액션 전 사람 승인을 요구하는 워크플로 설계 등 실용적 안전 장치를 마련한 점이 제시되었다. 작성자는 이러한 조치들이 실제 결혼식 운영에서 유의미하게 작동했음을 보고했고 이 경험은 실무에서 에이전트 운영 정책과 안전 게이트 설계의 중요성을 강조한다.

용어 해설

RAG: — 사용자의 질의에 대해 외부 문서나 데이터베이스를 검색해 관련 컨텍스트를 생성한 뒤 모델 입력으로 결합하는 기법으로, 이 글에서는 에이전트가 현장 정보를 검색해 답변 근거를 찾는 데 사용된 방식으로 설명되어 있다. RAG는 검색 결과를 선택·정렬하고 그 텍스트를 모델 프롬프트에 주입해 응답의 사실성을 높이는 역할을 수행했다. 게스트용 에이전시에서 일정·장소·문서 근거를 조회하는 과정에서 핵심적인 데이터 공급원으로 활용되었다.
Human-in-the-Loop: — 자동화된 결정이나 외부 행위를 실제로 실행하기 전에 사람이 최종 승인하거나 검토하는 설계 패턴으로, 본문에서는 이메일 발송 등 외부 액션에 대해 인간의 확인을 두 단계로 요구하는 형태로 구현되었다. 이 방식은 자동화 실수로 인한 대량 오발송을 방지하기 위해 에이전트의 권한을 제한하는 안전장치로 사용되었다. 글에서는 '아무것도 사람 확인 없이 나가지 않는다'는 규칙으로 실전 적용된 사례가 제시되었다.
Subagent: — 메인 에이전트의 특정 역할을 분리해 수행하는 하위 에이전트로서, 본문에서는 메인 응답에 대해 사실성을 검증하는 전담 서브에이전트가 존재했고 이 서브에이전트가 범위를 벗어난 검증을 수행해 불필요한 작업을 발생시켰다. 서브에이전트는 읽기 전용 증거에 기반한 검증만 수행하도록 범위를 제한하는 방식으로 수정되었다. 이 사례는 여러 에이전트를 조합할 때 역할과 관할을 엄격히 규정할 필요가 있음을 보여준다.

언급된 도구

Konva중립

브라우저 기반 2D 캔버스에서 도형을 그려 플로어플랜을 생성하는 데 사용된 라이브러리

Claude Code중립

작성자가 언급한 레퍼런스 저장소로서 시스템 프롬프트 관리와 리마인더 삽입 방식 비교에 참고된 코드베이스

resend중립

이메일 발송 서비스로서 테스트 중 무료 요금제 한도로 인해 대량 발송이 조기에 멈춘 사례에 관여한 서비스

언급된 리소스

문서작성자가 참조한 이전 Reddit 글