채팅창을 벗어난 에이전트 — Ambient Agent와 승인 4종의 설계

챗봇 UI에는 구조적 제약이 하나 있다. 한 번에 한 가지 대화만 가능하다. 에이전트가 3분짜리 리서치를 도는 동안 그 창에서는 다른 일을 시킬 수 없고, 사용자는 앉아서 기다리거나 창을 떠난다.

이 제약을 정면으로 다룬 것이 2025년 5월 LangChain의 첫 공식 개발자 컨퍼런스 Interrupt였다. 1일차는 핸즈온, 2일차는 도입 사례로 구성됐고, 발표 전반을 관통한 명제가 **"여러 에이전트를 동시에 실행하되 필요할 때만 사람을 부른다"**였다. 그런데 사람을 부르는 순간 승인 UI·상태 관리·프런트엔드가 따라오고, 자료는 그 대가를 숨기지 않는다 — "간단한 이메일 어시스턴트도 복잡해진다."

이 글은 그 전환과 대가를 함께 본다. 앞 편에서 병목이 품질로 옮겨 갔다는 진단을 했고, 여기서는 제품 형태 쪽 변화를 다룬다. 승인 게이트를 어디에 놓을 것인가는 자율성의 상한을 오류 비용으로 긋는 문제의 제품 버전이기도 하다.

이 글은 2025년 5월과 7월의 자료를 정리한 것이다. 제품명·기능 구성은 그 시점의 것이며, 이후 갱신되지 않았다.

용어 정리

앞 편의 용어표에서 이 글이 쓰는 행만 추리고, 제품 이름을 더했다.

무엇이 발표됐나 — 실무 영향도로 정렬

열다섯 항목 중 ★ 표시가 여덟이고, 그중 넷(Evaluation·Observability 셋)이 평가·관측 편 소관이다. 이 글이 맡는 것은 Memory·Agent Inbox·3대 명제·Ambient Agent 넷이다.

다음 분기 계획을 바꿀 만한 것 다섯

오른쪽 열이 전부 조직 행위라는 점이 이 표의 성격을 말한다. 다섯 중 어느 것도 "라이브러리를 업그레이드하라"가 아니다. 3번의 "승인 필요 액션 목록을 먼저 정의"가 특히 그런데, 이것은 코드 작업이 아니라 합의 작업이고 대개 코드보다 오래 걸린다.

오픈소스가 회사가 된 이유

도식은 다섯 마디인데 표도 다섯 행이지만, 표에만 "성격" 열이 있다. 도식이 시간 순서를 그린다면 표는 각 시점에서 무엇이 달라졌는지를 적는데, 세로로 읽으면 하나의 방향이 나온다 — 프로토타이핑 → 실행 구조 → 관측 → 운영 → 노코드. 아래로 갈수록 개발자에게서 멀어진다.

"Building an LLM app is easy at first... but getting to production is hard."

키노트 슬라이드는 이것을 곡선으로 그렸다. 프로토타입 구간에서 우상향하다가 프로덕션 경계에서 급락한 뒤 다시 오르는 형태다. 오픈소스가 회사가 된 이유를 한 장으로 설명한 셈인데, 급락 구간에 필요한 것들(관측·평가·배포·승인 UI)이 전부 오픈소스 라이브러리로는 채우기 어려운 것들이기 때문이다.

Agent의 미래 3대 명제

2번이 이 시리즈에서 가장 자주 인용되는 명제다. "프롬프트는 단 하나의 문자열이 아니다."

이 문장이 관점을 바꾸는 이유는 작업 단위를 바꾸기 때문이다. 프롬프트가 문자열이면 개선 작업은 문장을 고치는 일이고, 조립 대상이면 무엇을 넣고 무엇을 뺄지 정하는 일이 된다. 후자에서는 검색 결과를 몇 개 넣을지, 대화 이력을 어디서 자를지, 도구 응답을 요약할지가 전부 같은 층위의 결정이 된다. 앞 편의 배팅 우선순위 2위가 이것이다.

명제 2를 뒷받침하는 기능 다섯이 함께 제시됐다.

다섯 중 둘(HITL·Durable Execution)이 아래 Email Assistant의 뼈대가 된다. 그리고 이 둘은 짝으로만 성립하는데, 실행을 멈추려면 멈춘 지점의 상태를 어딘가에 저장해야 하기 때문이다 — 그 인과는 체크포인터와 HITL 편에 상태 전이도와 함께 있다.

명제 3에 붙은 것이 새 직무 정의다.

네 재료가 기존 직무 넷에 하나씩 대응한다는 점이 이 정의의 주장이다. 어느 하나의 확장이 아니라 교집합이라 기존 조직도에 자리가 없고, 그래서 "팀 스포츠"라는 표현이 따라 나온다.

생태계 지도

도식은 노드 여덟인데 표는 여섯 행이다. 표에만 있는 것이 Arcade와 Studio V2인데, 둘 다 플랫폼 트리에 매달리지 않고 옆에 붙는 것들이라 도식에 자리가 없었다. Arcade의 위치는 별도로 그려졌다 — 왼쪽에 AI 시스템(모델·에이전트 프레임워크), 오른쪽에 Tools & MCP Servers(Calendar·Gmail·Drive·Slack·Notion 등), 그 사이에 Tool Management + Authentication Gateway를 놓는 구조다. 도구 인증을 에이전트마다 다시 짜지 않으려면 중간에 계층이 하나 필요하다는 것이 이 그림의 주장이고, 같은 문제를 사내 지식베이스에 적용한 것이 MCP RAG의 3중 방어 구조다.

왜 채팅 UX를 벗어나야 하나

네 번째 행의 세 효용 중 셋째가 이 절의 숨은 논지다.

①과 ②는 HITL을 비용으로 놓고 그 값어치를 설명한다 — 사람을 부르는 대신 안전과 신뢰를 얻는다는 거래다. 그런데 ③은 성격이 다르다. 사람의 개입이 장기 메모리로 회수되면 개입 횟수 자체가 시간이 지나며 줄어든다. HITL을 고정 비용이 아니라 감소하는 비용으로 설계할 수 있다는 뜻이고, 아래 메모리 루프가 그 구현이다.

Email Assistant 레퍼런스 아키텍처

컨퍼런스 핸즈온과 7월 자료 양쪽에 동일하게 등장하는 구조도다. "에이전트 제품의 최소 완성형"으로 반복 인용된다.

사람의 승인 행위가 두 갈래로 재사용된다. 하나는 실제 발송이고, 다른 하나는 회귀 테스트 자산이다.

도식에서 F가 G와 H로 동시에 갈라지는 지점이 그것이다. 이 분기가 값을 하는 이유는 평가 데이터셋 구축이 별도 프로젝트가 되지 않기 때문이다 — 사람이 "이 초안 괜찮다"고 누른 순간 그것이 곧 정답 레이블이 된다. 운영이 곧 평가 데이터 수집인 구조이고, 평가·관측 편의 온라인 평가가 여기서 이어진다.

Triage Router와 Interrupt 4종

Triage Router는 일반적인 쿼리 라우터와 비슷하지만 Interrupt의 종류를 라우팅한다는 점이 다르다.

1차 분기는 Triage Router의 판정이다.

2차 분기는 Response Agent의 각 도구 호출 앞에서 사람이 고르는 네 갈래다.

도식은 분기가 두 층인데 표는 3행과 4행으로 나뉘어 일곱 갈래다. 도식이 Response Agent 아래 세 도구를 그리는 반면 표는 그 도구 앞에 놓이는 승인 선택지 넷을 편다 — 도식은 무엇을 실행하는가를, 표는 실행 직전에 사람이 무엇을 할 수 있는가를 말한다. 두 층이 곱해지므로 실제 경로 수는 도식만 봐서는 나오지 않는다.

승인을 Yes/No 이분법으로 만들면 사람이 매번 처음부터 다시 지시해야 한다.

edit(인자만 고침)과 respond(방향만 알려줌)를 분리한 것이 이 패턴의 핵심이다. "아니오"만 있으면 사람은 거절한 뒤 자기가 직접 하거나 프롬프트를 다시 쓰게 되고, 그러면 에이전트를 쓰는 의미가 절반 사라진다. 네 갈래는 거절의 이유를 구조화한 것이고, 그 구조가 아래 메모리 루프의 입력이 된다.

사람의 개입을 학습 신호로 회수한다

핵심 문구는 **"Human Feedback > Memory Update"**와 **"Learn preferences over time"**이다. 네 단계 중 2번이 가장 어려운 자리인데, edit으로 고쳐진 인자 하나를 "이 사람은 회의를 오후에 잡는 것을 선호한다"로 일반화하는 일이 자동으로 되지 않기 때문이다. 개별 수정을 선호로 승격하는 규칙이 없으면 메모리는 수정 로그가 될 뿐이다.

그리고 그 대가

HITL을 제대로 넣으면 제품 신뢰도는 올라가지만, 가장 단순한 어시스턴트조차 상태·분기·UI가 붙으면서 복잡해진다.

원 자료가 이 경고를 명시적으로 남겼다는 점이 중요하다. "Interrupt를 넣자"는 결정은 그래프에 노드 하나를 추가하는 일이 아니라 프런트엔드 작업과 상태 관리 비용을 동반하는 결정이다. 위 표 두 번째 행이 그것을 말한다 — 승인 선택지가 워크플로마다 다르면 프런트엔드가 그 차이를 알아야 하고, 그러면 백엔드와 프런트엔드 사이에 계약이 하나 더 생긴다.

여기까지가 제품 형태의 전환이다. 채팅창에서 나와 배경으로 가고, 위험한 지점에서만 사람을 부르고, 그 개입을 선호로 회수한다.

그런데 이 구조를 세우고 나면 답할 수 없는 질문이 하나 남는다. "이 에이전트, 잘 되고 있나요?" 라우팅이 틀린 것인지 도구 선택이 틀린 것인지 최종 문장이 나쁜 것인지가 구분되지 않으면 이 질문에 답할 방법이 없고, 승인 데이터가 쌓여도 무엇을 개선했는지 말할 수 없다. 다음 편에서 평가 지점을 세 계층으로 쪼개고, 오프라인·온라인·루프 세 방식을 목적별로 가른다.