통제 불능 상태에 빠지지 않는 AI 에이전트를 구축하는 방법 — 실제 에이전트 빌더의 교훈

최근 한 AI 에이전트가 Fedora Linux 프로젝트에서 혼란을 야기했습니다. Hacker News에서도 이 이슈가 뜨겁게 다뤄지고 있습니다.

솔직히 말씀드리면, 저는 놀랍지 않습니다. 저는 조사, 작성, 발행 및 콘텐츠 파이프라인을 관리하는 저만의 자율형 AI 에이전트를 직접 구축해 보았으며, 왜 이런 문제들이 발생하는지 정확히 설명해 드릴 수 있습니다.

문제는 AI가 아닙니다. 바로 아키텍처 (Architecture)입니다.

핵심 문제: 이진적 신뢰 (Binary Trust)

대부분의 AI 에이전트 배포 방식은 자율성을 이진법적으로 취급합니다. 즉, 에이전트가 모든 것을 할 수 있거나, 아니면 단순한 챗봇(Chatbot)이거나 둘 중 하나로 봅니다. Fedora 사건이 발생한 이유는 누군가가 실패 모드 (Failure modes)를 고려하지 않은 채 에이전트에게 광범위한 권한을 부여했기 때문입니다.

제 에이전트는 24시간 내내 작동하며, 기사를 발행하고, 채용 게시판을 스캔하며, 다각적 전략을 가진 비즈니스 파이프라인을 관리합니다. 첫날에만 두 개의 플랫폼에 걸쳐 6개의 기사를 발행했습니다. 그리고 단 한 번도 폭주한 적이 없습니다.

차이점은 이렇습니다. 제 에이전트는 똑똑하게 만들어진 것이 아니라, 자신의 한계를 알도록 설계되었습니다.

3단계 에스컬레이션 매트릭스 (Three-Tier Escalation Matrix)

'모든 것을 할 수 있다' 또는 '아무것도 할 수 없다' 대신, 저는 세 가지 에스컬레이션 (Escalation) 단계를 사용합니다.

Green (녹색) — 완전 자율 (Fully Autonomous). 조사, 초안 작성, 플랫폼 스캔, 메모리 파일 업데이트, 보고서 생성. 이러한 작업들은 리스크가 전혀 없습니다. 에이전트는 묻지 않고 이를 수행합니다.

Yellow (황색) — 알림 후 진행 (Notify and Proceed). 승인된 플랫폼에 게시하기, 설정된 니치 (Niche) 범위 내에서 콘텐츠 주제 변경하기. 에이전트는 자신이 무엇을 하고 있는지 저에게 알리고, 제가 반대하지 않는 한 계속 진행합니다.

Red (적색) — 차단 및 대기 (Block and Wait). 계정 생성, 사람에게 연락하기, 비용 지출, 임계값을 초과하는 전략 변경. 에이전트는 즉시 동작을 멈추고 명시적인 승인을 기다립니다.

핵심 통찰: 에스컬레이션 단계는 난이도에 따라 결정되는 것이 아닙니다. 그것은 **가역성 (Reversibility)**에 기반합니다. 되돌릴 수 있는가? Green. 되돌리기 어려운가? Yellow. 되돌릴 수 없는가? Red.

왜 '똑똑한' 에이전트들이 실패하는가

설계상 제 에이전트가 할 수 없는 작업들은 다음과 같습니다:

1. 돈을 쓸 수 없음. 모든 플랫폼은 무료 티어(Free tier)여야 합니다.
2. 승인 없이 사람에게 연락할 수 없음. 모든 외부 연락(Outreach)은 Red 레벨입니다.
3. 계정을 생성할 수 없음. 무료 플랫폼에 가입하는 것조차 저의 승인이 필요합니다.
4. 전략을 15% 이상 변경할 수 없음. 이 임계값을 초과하는 가중치 조정은 Red 레벨입니다.

이러한 제약 조건들은 생산성 측면에서 저에게 아무런 손해를 끼치지 않았습니다. 에이전트는 여전히 하루에 6개의 기사를 발행했습니다.

이탈을 방지하는 메모리 아키텍처 (Memory Architecture)

매 사이클마다 에이전트는 state.md(에이전트의 "세이브 게임")를 읽고, 하나의 동작을 수행하며, 메모리 파일을 업데이트하고 보고합니다. 모든 것은 일반적인 마크다운(Markdown) 형식으로 되어 있습니다. 저는 어떤 파일이든 열어서 에이전트가 무엇을 생각하고 있는지, 무엇을 했는지, 그리고 다음에 무엇을 할 계획인지 정확하게 확인할 수 있습니다.

만약 에이전트가 이탈하기 시작한다면 — 즉, 양질의 콘텐츠 대신 클릭베이트(Clickbait)를 발행한다면 — 저는 데이터를 통해 즉시 이를 확인할 수 있습니다. 추가 전용(Append-only) 방식의 일일 로그 덕분에 모든 결정의 기원을 추적할 수 있습니다.

실질적인 교훈

AI 에이전트를 구축하거나 배포하고 있다면 다음을 고려하십시오:

1. 모든 동작을 가역성(Reversibility)에 따라 분류하십시오. 가역적인 동작은 자율적으로, 비가역적인 동작은 인간의 승인을 받도록 설정하십시오.
2. 상태(State)를 사람이 읽을 수 있게 만드십시오. 텍스트 파일을 읽어서 에이전트가 무엇을 하고 있는지 이해할 수 없다면, 당신의 아키텍처는 너무 불투명한 것입니다.
3. 모든 것을 추가 전용(Append-only)으로 로그를 남기십시오. 에이전트가 수정할 수 없는 감사 추적(Audit trail)이 필요합니다.
4. 부드러운 가이드라인이 아닌 엄격한 제약 조건(Hard constraints)을 설정하십시오. "돈을 쓰지 않도록 노력하라"는 실패할 것입니다. "돈을 쓸 수 없다"는 실패하지 않습니다.
5. 상상할 수 없는 실패에 대비하여 설계하십시오. Fedora 사건은 개발자들이 계획했던 시나리오가 아니었습니다.

불편한 교훈

AI 에이전트 분야는 빠르게 움직이고 있습니다. 모두가 모든 것을 수행하는 자율 에이전트를 원합니다. 하지만 장기적으로 성공할 팀은 언제 행동하지 '않아야' 하는지를 아는 에이전트를 구축하는 팀입니다.

제 에이전트는 지루합니다. 규칙을 따릅니다. 허락을 구합니다. 모든 것을 기록합니다. 그리고 에이전트는 첫날에 단 하나의 문제도 일으키지 않고 6개의 기사를 발행했습니다.

지루함은 과소평가되어 있습니다.

AI 에이전트 (AI agents)로 무언가를 구축하고 계신가요? 저는 모든 아키텍처 결정 (architectural decision), 실패, 그리고 교훈을 실시간으로 기록하고 있습니다. 과장 없는 투명한 업데이트를 위해 팔로우해 주세요.