AWS가 공개한 Pizza Bot이 이번 주말 개발자 커뮤니티에서 다시 주목받았습니다. 계속 바라보는 chat이 아니라 All·Unread·Action이라는 inbox 구조로 에이전트를 다루는 오픈소스 앱입니다. scheduled·webhook task, background worker, specialist delegation, human approval, persistent state를 지원합니다. 초기 버전은 Amazon 내부에서 2,000명 이상이 썼습니다.

핵심 UX 아이디어가 좋습니다.

사람: 일을 맡김
Agent: 백그라운드 실행
완료: Unread
사람 판단 필요: Action

왜 inbox인가: 채팅은 같이 있어야 한다

AWS 블로그의 문장이 정확합니다. "이메일을 보내고 답이 올 때까지 outbox를 쳐다보지 않는다." 스레드는 참석해야 하는 세션이 아니라 돌아와서 보는 일의 단위입니다.

live chat 전제: 양쪽이 같이 있다 (빠른 교환엔 맞음)
긴 작업: 몇 분 걸림 + 중간 승인 대기 + 부재 중 스케줄 실행
→ 채팅 전제가 깨짐
inbox 전제: 맡기고 딴짓하다가 읽을 것·정할 것만 본다

The Register의 표현을 빌리면 이메일처럼 쓰는 것입니다. 끝난 일은 Unread, 결정할 일은 Action, 전체 기록은 All. 옆의 Activity 패널에는 specialist에게 넘긴 일과 transcript가 보입니다.

구조: 서버가 일을 들고 있다

4층:
Client (Electron·브라우저·터미널)
  → Server (HTTP, run manager)
    → Runtime (DeepAgents/LangGraph, stateful)
      → Storage (SQLite + 파일: 체크포인트·스레드·첨부)
        + MCP servers + skill workers + 선택한 모델 provider

특징:
- 스레드가 대화+에이전트 상태의 durable 집
- 닫고·고치고·옮겨도 run이 이어짐 (checkpoint 덕분)
- 폴더 1개에 전부 (백업 단위가 명확)
- 자격증명은 OS secret store, 원격은 토큰+허용 origin 필수

모델은 가리지 않습니다. Anthropic·Bedrock·Gemini·OpenAI·OpenRouter, 로컬 Ollama까지. AWS 서비스가 아니라 커뮤니티 프로젝트라 SLA·지원이 없다는 점도 명시돼 있습니다. Bedrock 종속이 아니라서 AWS 마케팅과도 거리가 있다는 분석도 있습니다.

스킬 구조도 눈여겨볼 만합니다. 메인 generalist + SKILL.md specialist. 회의 준비 스킬은 캘린더·CRM·문서 도구만, 브라우저 자동화 스킬은 브라우저만. 짧은 도구 목록이 핵심입니다. 스킬이 특정 도구 전에 승인을 요구할 수도 있고, 그 pause는 durable이라 한 시간 뒤 다른 기기에서 답해도 됩니다.

반대 의견도 같이 보기

InfoWorld·HFS의 지적도 공정하게 적어둡니다. inbox가 나쁜 일을 안 보이게 할 수 있다는 것입니다. 채팅창에서 지켜보면 탈선을 바로 보는데, inbox는 안 좋은 것도 안 보입니다.

chat: 탈선 즉시 보임, 대신 계속 봐야 함 (babysitting)
inbox: 판단할 때만 보면 됨, 대신 나쁜 일을 늦게 봄
→ 정답이 아니라 trade-off, 둘 다 두고 용도를 나누는 게 현실적

옵저버빌리티 글의 execution 묶기가 여기서 필요합니다. 안 봐도 되는 구조일수록 기록은 촘촘해야 합니다.

CodeBridge Mini Lab: 4상태부터 설계하기

브리프의 액션을 그대로 가져옵니다. streaming text보다 상태가 먼저입니다.

장시간 Agent UI 4상태:
[ ] Task: 맡긴 일 (누가·언제·무엇을)
[ ] Status: 진행 중 (어디까지 왔는지)
[ ] Action Required: 멈춘 곳 (승인·답변 대기)
[ ] Result: 끝난 일 (읽음·안 읽음 구분)

적용 순서:
1. 우리 일 1개를 4상태로 나눠본다 (예: 주간 리서치)
2. 승인 지점 1개를 정한다 (어디서 멈출지)
3. Unread·Action 알림을 붙인다 (언제 볼지)
4. 채팅은 질문용으로만 남긴다 (긴 작업은 inbox로)

OpenDots 글의 approval card와 gh-aw 글의 Queue가 같은 모양입니다. 멈추고 이어가는 지점이 UI가 되는 시대입니다.

결론: 대화에서 일로

한 줄로 정리합니다.

10분·1시간짜리 일에 채팅창은 좁다. conversation에서 work queue로.

Pizza Bot의 질문은 명확합니다. 에이전트를 계속 볼 것인가, 맡기고 볼 것만 볼 것인가. 답은 둘 다입니다. 짧은 것은 채팅, 긴 것은 inbox. 오늘 할 일은 하나입니다. 우리 가장 긴 에이전트 작업 1개를 4상태로 나눠보는 것. 그 4칸이 다음 UI가 됩니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

일에 맞는 화면을 직접 만들고 AI와 연결하는 연습이 필요하다면, 대화로 웹사이트를 만들고 배포하는 과정이 이 글의 4상태 UI와 바로 이어집니다.