막혀 있다는 사실을 알고 있었던 에이전트

나의 스타트업인 Whoff Agents를 엔드 투 엔드(end-to-end)로 운영하기 위해 내가 구축한 AI 에이전트, Atlas를 실행한 지 5주 차에 접어들었을 때, 나는 로그에서 이상한 점을 발견했다.

30분마다 하트비트 루프(heartbeat loop)가 실행되었다. 상태 읽기. 하나의 액션(action) 선택. 실행. 로그 기록. 휴식.

그리고 약 일주일 동안, 매 30분마다 루프의 "검증(verify)" 단계 상단에 동일한 세 가지 항목이 나타났다:

Will action verifications (all still NEGATIVE):
  - YT token scopes = [youtube.upload] only. force-ssl absent.
  - webhook/config.json price_to_repo contains 0 atlas-starter-kit matches.
...

에이전트는 어려운 기술적 문제에 막혀 있었던 것이 아니다. 그것은 물리적으로 나, 즉 인간이 수행해야만 하는 세 가지 작업에 막혀 있었다. 그리고 에이전트는 그 사실을 알고 있었다. 에이전트는 매 루프마다 차단 요소(blockers)를 로그에 기록했고, 자신이 수행할 수 있는 가장 가치 있는 액션을 선택하여 계속 움직였다.

5주간의 반복(iteration) 끝에, 매 루프 상단에 나타나는 저 짧은 세 줄의 블록은 내가 에이전트에 추가한 가장 중요한 패턴이 되었다. 나는 이것을 Will-actions queue라고 부른다.

이 글은 내가 첫 번째 장기 실행(long-running) 에이전트를 만들기 전에 누군가가 미리 써주었기를 바랐던 내용이다.

순진한 설계: "에이전트는 무엇이든 할 수 있다"

대부분의 에이전트 데모는 에이전트가 전지전능한 것처럼 가장한다. 브라우저? 당연하다. 셸(Shell)? 물론이다. API 키? 모두 가지고 있다. 데모는 한 번 실행되고, 에이전트는 작업을 완료하며, 박수가 터져 나온다.

데모용으로는 괜찮다. 하지만 30분마다 영원히 반복되는 하트비트 루프(heartbeat loop) 환경에서는 재앙이다.

며칠, 몇 주 동안 계속 실행되어야 하는 실제 에이전트들은 스스로 완료할 수 없는 네 가지 범주의 작업에 부딪히게 된다:

1. 인증 / 동의 인터페이스 (Auth / consent surfaces). OAuth 재동의 화면. 2단계 인증 (2FA) 과제. CAPTCHA. 계정 생성. 에이전트는 API 토큰을 가지고 있지만, 해당 토큰에 필요한 권한 범위 (scope)가 포함되어 있지 않으며, 권한 범위를 추가할 수 있는 유일한 방법은 인간이 올바른 계정으로 로그인된 브라우저 탭에서 "허용"을 클릭하는 것뿐입니다.

2. 정책 / 리스크 결정 (Policy / risk decisions). 이 고객에게 환불을 해줘야 할까요? 이 논란이 될 만한 게시물을 발행해야 할까요? 가격 변경 사항을 실시간으로 적용해야 할까요? 에이전트는 기술적으로 이러한 일을 할 수 있습니다. 하지만 해서는 안 됩니다. 왜냐하면 "잘못된" 결정의 비용은 비대칭적이며, 인간은 그 결과에 책임을 지기로 계약된 존재이기 때문입니다.

3. 현실 세계의 물리적 행동 (Real-world physical actions). 계약서 서명. 송금. 회의 참석. 제품 촬영. 에이전트는 이러한 일을 절대 수행할 수 없습니다.

4. 에이전트가 안전하게 수행할 수 없는 환경 / 인프라 변경 (Environment / infra changes the agent can't safely make). 운영 환경의 비밀 키 (production secret) 교체. .env 파일 수정. 데이터베이스 삭제. 영향 범위 (blast radius)가 복구 불가능한 공유 인프라 건드리기.

이 각각의 요소들이 에이전트를 차단합니다. 그리고 단순한 설계 (naive design)에서, 차단된 에이전트는 무엇을 할까요?

재시도합니다. 영원히 말이죠. 토큰을 낭비하고, 로그를 도배하며, 때로는 고객에게 스팸을 보내고, 분명히 당신에게 스팸을 보낼 것입니다.

Will-actions queue의 실체

그것은 마크다운 (markdown) 표입니다. 그게 전부입니다.

## Pending Will Actions (BLOCKING REVENUE)

| # | Action                                                    | Impact   | Filed       |
|---|-----------------------------------------------------------|----------|-------------|
...

다섯 개의 열로 구성됩니다. .paul/STATE.md 파일에 존재합니다. 에이전트는 여기에 내용을 추가하고, 인간은 이를 비웁니다.

지루하게 들릴 수도 있습니다. 하지만 이것은 시스템을 지탱하는 핵심 요소 (load-bearing)입니다.

이를 작동하게 만드는 네 가지 속성

저는 표 형식을 확정하기 전에 세 가지 다른 형태를 시도해 보았습니다. 저 자신에게 보내는 Slack DM. Notion 데이터베이스. GitHub 프로젝트 보드. 이들은 모두 미묘한 방식으로 실패했습니다. 최종 설계가 제대로 잡아낸 부분은 다음과 같습니다:

1. 에이전트의 기본 상태 파일 (primary state file)에 위치합니다.

Will-actions queue는 에이전트가 매 하트비트 루프 (heartbeat loop)의 시작 부분에서 읽는 동일한 파일 내에 존재합니다. 에이전트가 확인하는 것을 기억해야 하는 별도의 시스템이 아닙니다. 제가 놓칠 수도 있는 이메일도 아닙니다. STATE.md를 읽는 것이 모든 루프의 첫 번째 단계이기 때문에, 에이전트가 이를 확인하지 않고 건너뛰는 것은 구조적으로 불가능합니다.

2. 모든 행에는 영향도 (Impact) 컬럼이 있습니다.

CRITICAL, HIGH, MEDIUM. 에이전트는 이를 사용하여 차단 요소 (blocker)를 우회하여 계속 작업할지, 아니면 이를 더 강력하게 드러낼지 (예: 더 강한 알림 게시, 다른 채널을 통해 인간에게 에스컬레이션 (escalate)) 결정합니다. 또한, 이는 인간인 저에게 제가 자리에 앉았을 때 무엇을 먼저 해야 할지 알려줍니다. "무엇이 치명적인가(What's critical)?"가 제가 답해야 할 유일한 질문입니다.

3. 모든 행에는 기록 날짜 (Filed date)가 있습니다.

이것은 대부분의 사람들이 생략하는 부분입니다. 기록 날짜는 두 가지 역할을 합니다:

• 차단 요소가 얼마나 오랫동안 차단을 일으키고 있는지 에이전트에게 알려줍니다. CRITICAL 행에서 3일 이상 경과하면, 에이전트의 우선순위 로직 (priority logic)이 전환됩니다. 즉, 단순히 기다리는 대신 루프 예산 (loop budget)의 일부를 차단 요소를 우회하여 작업하는 데 (예: 고장 난 제품 대신 작동 중인 다른 제품으로 고객을 안내) 사용하기 시작합니다.
• 인간인 저에게 제가 에이전트를 얼마나 심하게 실망시켰는지 알려줍니다. 터미널에서 오늘 날짜를 읽고 있는 상황에서 CRITICAL 행에 "2026-05-09 기록됨"이라고 적혀 있는 것은 본능적인 피드백 신호입니다.

4. 에이전트는 행을 가볍게 추가하지 않습니다.

저는 Atlas에 대해 한 가지 규칙을 가지고 있습니다: Will-action을 추가하기 전에, 에이전트는 최소 두 가지의 우회 방법 (workarounds)을 시도해야 합니다. 두 방법 모두 실패하고 에이전트가 무엇이 필요한지 확신할 때 비로소 시도했던 내용을 한 줄로 재현 (repro)하여 행을 기록합니다.

이것이 중요한 이유는 큐 (queue)의 가치가 그 길이에 반비례하기 때문입니다. 큐에 47개의 항목이 있다면, 저는 그중 아무것도 읽지 않을 것입니다. 만약 3개만 있다면, 저는 오늘 밤 그 모두를 해결할 것입니다.

"드리프트 탐지 (drift detection)" 측면

Will-actions queue 가치의 절반은 큐 자체에 있는 것이 아니라, 큐가 존재하기 때문에 에이전트가 수행하는 행동에 있습니다.

에이전트가 벽에 부딪혔을 때, 질문은 다음과 같이 변합니다: "이것은 내가 시도해야 할 일인가, 아니면 큐에 넣어야 할 일인가?"

그러한 강제적인 선택 하나가 제가 이제 **executor drift (실행자 드리프트)**라고 부르는 범주의 버그를 방지합니다. 즉, 에이전트가 수행해서는 안 될 작업에 직면했을 때, 스스로 할 수 있다고 믿어버리고는 사용해서는 안 될 엔드포인트를 꼬아버리거나 (curling endpoints), osascript를 실행하거나, 제어해서는 안 될 브라우저를 조작하기 시작하는 현상입니다. 에이전트 시스템에서 이러한 드리프트(drift)는 자고 일어났을 때 당신의 AI 에이전트가 잘못된 소셜 계정에 게시물을 올렸거나, 잘못된 편지함에서 이메일을 보냈거나, 잘못된 업체로 돈을 송금한 상황을 발견하게 만드는 원인이 됩니다.

큐(Queue)는 에이전트에게 깔끔한 탈출구(escape hatch)를 제공합니다: "이것은 Will-action이지, me-action이 아니다." 이는 자신의 한계를 아는 에이전트와 능력을 환각(hallucinate)하는 에이전트 사이의 차이입니다.

제가 고생하며 배운 안티 패턴 (Anti-patterns)

시도해 보았지만 실패했던 것들:

• Slack 내의 큐. 에이전트가 막혔을 때 저에게 DM을 보냅니다. 문제점: 알림 피로도(notification fatigue)가 발생하여 제가 채널을 무음 처리했고, 그 결과 차단 요소(blockers)들이 보이지 않게 쌓였습니다. 또한, 에이전트는 무엇이 아직 미결 상태인지 알기 위해 자신의 과거 DM을 쉽게 읽을 수 없습니다.

• GitHub Issues 내의 큐. 깔끔하다고 느꼈습니다. 문제점: 루프를 닫으려면 에이전트가 GitHub MCP를 사용해야 했는데, 이 MCP 자체가 가끔 고장 났고, 이를 고치기 위해 다시 Will-action 큐를 수정해야 하는 Will-action이 필요한 상황이 발생했습니다. 고통의 재귀(Recursion of pain)였습니다.

• CRITICAL 단계에서의 자동 호출 (Auto-paging). 어떤 CRITICAL 행이든 발생하면 에이전트가 새벽 3시에 저에게 SMS를 보냅니다. 문제점: 모든 CRITICAL이 새벽 3시에 처리해야 할 만큼 긴급한 것은 아닙니다. "긴급함(urgent)"을 별도의 컬럼으로 정의하고, 해당 하위 집합에 대해서만 호출을 유지하도록 했습니다.

• 테이블 대신 자유 형식의 텍스트 사용. 에이전트가 무엇에 막혔는지 단순히 저널(journal)에 기록하게 해보았습니다. 문제점: 저널을 10초 안에 훑어볼 수 없었기에 결국 보지 않게 되었고, 차단 요소들이 방치되었습니다. 테이블은 간결함과 가독성(scanability)을 강제합니다.

당신의 에이전트에 이를 추가하는 방법

장시간 실행되는 에이전트를 보유하고 있다면, 네 줄의 패치로 가능합니다:

1. 에이전트가 루프 진입 시 읽어들이는 상태 파일(state file)에 ## Pending Human Actions 섹션을 추가합니다.
2. 에이전트에게 한 가지 규칙을 부여합니다: 인간의 승인(auth), 정책(policy), 또는 인프라(infra)가 필요한 작업을 수행하기 전에, 먼저 두 가지 우회 방법(workarounds)을 시도하십시오. 여전히 해결되지 않는다면, 행(row)을 추가하십시오.
3. 에이전트에게 한 가지 규칙을 부여합니다: 각 루프의 최상단에서 큐(queue)에 있는 열려 있는 행들을 재확인하고, 인간이 문제를 해결했다면 상태(status)를 업데이트하십시오.
4. 당신 자신에게 한 가지 규칙을 부여합니다: 컴퓨터 앞에 앉으면, 큐를 가장 먼저 처리하십시오.

그게 전부입니다. 새로운 인프라(infra)도, 새로운 MCP도, 새로운 벡터 스토어(vector store)도 필요 없습니다. 마크다운(markdown) 표 하나와 두 가지 규칙이면 충분합니다.

더 큰 교훈

현재 에이전트 시스템(agentic systems)에서 흥미로운 연구 분야는 에이전트의 능력 그 자체가 아닙니다. 그것은 바로 에이전트와 인간 사이의 '이음새(seams)' — 즉, 작업이 전달되는 지점, 특히 작업이 다시 인간에게 '되돌아오는(hands off back)' 지점입니다.

제가 본 대부분의 에이전트 프레임워크(agent frameworks)는 루프의 자율적인 절반을 최적화하는 데 집중하며, 인간이 담당하는 절반은 사후 고려 사항(