AI가 똑똑해질수록, 한계를 결정짓는 것은 모델의 지능이 아니라 그 주변에 인간이 구축하는 기억·절차·관문·판단의 구조가 된다.

필자는 소프트웨어 엔지니어가 아니다. 삿포로의 전업주부이자 독립적인 AI 정렬 (AI Alignment) 연구자다. 코드는 거의 쓸 줄 모른다. 그럼에도 이 글은 엔지니어들에게 꼭 전달되기를 바란다 ── 지금 업계가 몰려들고 있는 「에이전트 (Agent)」의, 다음에 올 병목 구간(Bottleneck)에 관한 이야기이기 때문이다.

지금 AI 업계는 에이전트로 몰려들고 있다.

코딩 에이전트 (Coding Agent). 브라우저 에이전트 (Browser Agent). 리서치 에이전트 (Research Agent). 멀티 에이전트 워크플로우 (Multi-agent Workflow). 파일을 읽고, API를 호출하고, 웹을 돌아다니며, 코드를 쓰고, 데이터를 움직이는 ── 과거에 인간이 키보드 앞에 앉아 수행하던 일련의 작업들을 자율적으로 해내는 시스템.

이것은 단순한 소동이 아니다. OpenAI는 Responses API와 Agents SDK를 「에이전트를 만드는 부품」으로 내놓았고, Google은 서로 다른 벤더의 에이전트끼리 연결하는 Agent2Agent 프로토콜을 발표했다. Anthropic과 Microsoft도 같은 방향으로 움직이고 있다.

하지만 업계는 슬슬 불편한 사실을 깨닫기 시작하고 있다.

다음 병목 구간은 에이전트가 아닐지도 모른다. 에이전트를 구동하는, 그 주변의 「인간이 구축한 프레임워크 (Framework)」일지도 모른다.

문제는 「AI가 더 많은 태스크를 실행할 수 있는가」가 아니다. 그것은 가능하다. 어려운 것은 ── 주변 시스템이 무엇이 중요한지 전달하고, 무엇을 기억시키고, 무엇을 검증하게 하며, 언제 멈추고, 언제 제어권을 인간에게 돌려주며, 오류로부터 어떻게 복구하고, 긴 작업 과정을 통해 인간의 책임을 어떻게 유지할 것인가 하는 점이다.

에이전트는 실행한다. 프레임워크는 무엇이 남을지를 결정한다.

에이전트의 데모는 대개 인상적이다. 브라우저를 열고, 코드를 쓰고, 리포지토리 (Repository)를 편집하며, 일련의 작업을 인간이 보는 앞에서 완료시킨다. 몇 분 동안 마법처럼 보인다.

하지만 실제 운영이 시작된다.

에이전트는 문맥 (Context)을 잊는다. 어제의 실수를 반복한다. 잘못된 도구를 호출한다. 한 번은 작동하지만 유지보수할 수 없는 코드를 작성한다. 태스크를 다른 에이전트에게 넘기고, 그것이 무엇을 위한 것이었는지 잃어버린다. 지시는 이행하지만, 이면에 깔린 의도를 놓친다. 멈춰야 할 때 계속 나아간다.

모델이 약해서가 아니다. 모델을 둘러싼 환경이 약하기 때문이다. 실패의 상당수는 순수한 지능의 문제가 아니라, 상태 (State)·기억·관측 가능성 (Observability)·평가·인수인계·관문·인간의 체크포인트 (Checkpoint) ── 「지능이 레버리지 (Leverage)가 될 것인가, 부채 (Debt)가 될 것인가」를 결정하는, 투박한 인프라의 문제에 있다.

데모는 이렇게 묻는다 ── 「에이전트가 그 태스크를 해낼 수 있는가?」

시스템은 이렇게 묻는다 ── 「태스크를 수행하고, 왜 중요했는지를 기억하며, 무엇을 했는지 공개하고, 현실이 변했을 때 복구하며, 인간이 책임을 질 수 있는 상태를 남길 수 있는가?」

이것은 전혀 다른 질문이다.

모델이 「행동할 수 있을」 정도로 똑똑해진 순간, 병목 구간은 이동한다. 「AI가 무언가를 할 수 있는가?」에서, 「AI 주변의 인간 시스템이 그 행동을 검사할 수 있고, 수정할 수 있으며, 책임을 질 수 있는 것으로 만들 수 있는가?」로.

이 이동은 눈에 잘 띄지 않는다. 에이전트의 실패가 모델의 실패처럼 보이기 때문이다. 잊어버리면 문맥 길이 (Context Length) 탓, 방황하면 추론 (Reasoning) 탓, 나쁜 코드를 쓰면 모델 탓, 판단을 그르치면 할루시네이션 (Hallucination) 탓으로 돌린다. 때로는 그것이 맞다. 하지만 더 깊은 문제는 종종 구조적이다.

• 에이전트는 무엇을 기억했어야 했는가. 그 기억은 어디에 저장되어 있었는가.
• 무엇을 정답 (Ground Truth)으로 결정했는가. 성공의 기준은 무엇인가.
• 체크포인트는 어디인가. 복구 경로는 있는가.
• 무엇을 절대로 덮어써서는 안 되는가. 세션 (Session)을 넘어서 무엇을 유지해야 하는가.

이것들에 대한 답이 없다면, 에이전트는 시스템 안에서 움직이는 것이 아니다. 망상 속에서 움직이고 있는 것이다.

흥미롭게도, 이는 외부의 권위 있는 목소리로도 뒷받침된다. Anthropic은 에이전트 SDK를 제공하는 당사자이면서도, 현장 지견으로서 「가장 성공적인 구현은 복잡한 프레임워크가 아니라 단순하고 조합 가능한 패턴을 사용하고 있었다」, 「먼저 가장 단순한 해결책부터 시작하고, 정말 필요할 때만 복잡하게 만들어라」라고 권고하고 있다1. 코딩 에이전트조차 「인간의 리뷰는 해가 더 넓은 시스템 요구사항에 부합하는지 확인하기 위해 여전히 필수적이다」라고 명시한다. 최전선의 구현자일수록 자율성 그 자체보다 그 주변의 구조와 감독을 중시하고 있는 것이다.

AI 제품 설계에는 매력적인 유혹이 있다 ── 「에이전트를 더욱 자율적으로 만들어라」. 실패하면 도구를 늘려라. 막히면 권한을 늘려라. 잊어버리면 기억을 늘려라. 감독이 필요하다면, 감독할 또 다른 에이전트를 만들어라.

잘 풀릴 때도 있다. 하지만, 구조 없는 자율성은 취약성을 증폭시킬 수 있다. 취약한 프레임워크(Framework) 안에서의 더 자율적인 에이전트는, 단지 더 빠르고, 더 자신만만하게, 더 넓은 행동 범위에서 실패할 뿐일지도 모른다.

자율성이 강력한 것은 영역이 좁고, 도구가 명확하며, 성공 기준이 보이고, 복구 경로가 존재할 때다. 위험한 것은 목표가 모호하고, 문맥(Context)이 길며, 평가가 약하고, 기억이 불안정하며, 인간이 과신하도록 유도될 때다. Anthropic 또한 자율 에이전트는 「비용 상승과 오류의 연쇄 가능성」을 수반하기 때문에, 「샌드박스(Sandbox) 환경에서의 철저한 테스트와 적절한 가드레일(Guardrail)」을 권장하고 있다1.

따라서 「human-in-the-loop (인간을 루프 안에)」는 체크박스 항목이 아니다. 많은 진지한 워크플로(Workflow)에서 인간의 개입은 마지막에 덧붙이는 기능이 아니라, 그 자체로 제품(Product)이다. 인간은 출력을 승인/거절하기만 하는 것이 아니다. 목적을 설정하고, 모호함을 명확히 하며, 무엇을 유지해야 할지 파악하고, 프레임워크가 어긋났을 때 이를 알아차린다. 인간의 체크포인트가 표면적이라면, 그 워크플로는 안전하지 않다. 연극일 뿐이다.

실제 인간-AI의 협업은 이러한 「릴레이」가 된다 ── 인간은 단 한 번도 사슬에서 사라지지 않는다.

역할이 바뀌었을 뿐이다. 한 줄 한 줄 손으로 쓰는 대신, 인간은 「목적을 결정하는 사람 · 에러를 읽는 사람 · 허가를 내주는 사람 · 마지막으로 검증하는 사람 · 책임을 지는 사람」이 된다. 이것은 자동화가 아니다. 인간이 책임을 계속해서 지는 릴레이다.

AI 업무의 미래는 단순한 자율 에이전트가 아니다. **상호 적응하는 프레임워크 (co-adaptive framework)**라고 생각한다.

여기서 주의해야 할 것은 「프레임워크」의 의미다. 내가 말하는 것은 소프트웨어 프레임워크가 아니다. 오히려 Anthropic은 추상화 계층이 프롬프트를 숨겨 디버깅을 어렵게 만들기 때문에, 소프트웨어 프레임워크는 신중하게 사용할 것을 권고하고 있다1 ── 이 점에는 동의한다.

내가 말하는 것은 모델을 둘러싼 **상호작용 계층 (interaction layer)**이다:

이 계층은 화려하지 않다. 브라우저를 클릭하는 에이전트만큼 데모 효과가 뛰어나지도 않다. 하지만 AI의 출력이 「사용 가능한 업무」가 될지를 결정하는 것은 바로 이 계층이다.

에이전트는 태스크(Task)를 실행할 수 있다. 상호 적응하는 프레임워크는, 그 태스크 자체가 제대로 틀 잡혀 있지 않았다는 사실을 알아차릴 수 있다. 이것이 더 깊은 변화다.

나의 AI 이용은 어느덧 「프롬프팅 (Prompting)」이 아니게 되었다. 질문에 대한 답변에서 시작하여 초안 작성 · 퇴고 · 모델 비교 · 기억 유지 · 실패 모드의 명명, 그리고 공개 기사의 라우터, 연구 루틴, 법무 감사 구조, 보조금 장부, 공개 전의 출구 관문으로 성장했다. 최종적으로 나의 워크플로는 자연어로 작성된 운영 구조가 되었다. 자율적인 것이 아니다. 인간이 감독한다. 코드도 아니다. 거의 마크다운(Markdown)에 가깝다.

(이전에 「코드를 쓰지 못하면서도 GitHub에 공개할 수 있었던 이야기」를 썼다. 그것은 how ── 막혔을 때 AI에게 다음 질문을 하는 절차에 관한 것이었다. 이번에는 why ── 왜 그 절차를 뒷받침하는 「구조」가 다음 병목 구간(Bottleneck)인지에 관한 것이다.)

이것은 뼈아픈 경험을 통해 배운 것이다. 한번 나는 AI 워크플로를 「깔끔하게」 재구축한 적이 있다. 재구축은 성공적이었다. 하지만 그 과정에서, 살아있는 작업 장부가 깔끔한 템플릿에 의해 덮어씌워질 뻔했다.

템플릿은 「진척도를 어떻게 기록해야 하는가」를 기술하고 있었다. 장부는 「실제 진척도」를 포함하고 있었다 ── 공개 상태, 보조금 신청 상태, 안전한 표현 방식, 「말해서는 안 되는 것」에 대한 경고, 다음 단계, 재확인 날짜.

템플릿은 아름다웠다. 그것이 위험했다. 템플릿은 「현실을 어떻게 기록할 것인가」를 가르치고, 장부는 「현실」을 포함한다. 이 둘을 혼동하면 시스템은 더 깔끔해지지만, 동시에 더 진실하지 않게 될 수 있다.

그 실패가 나의 시스템을 바꾸었다. 나는 규칙을 추가했다 ── 「템플릿이 살아있는 장부를 덮어쓰게 하지 마라」, 「사실을 지켜라. 열기를 격리하라」, 「열기가 있는 상태로 생성하고, 출구에서 점검하라」. 이것들은 프롬프트가 아니다. **거버넌스 (Governance)**다. 자연어로 작성된 작은 인프라의 파편들. 그리고 대부분의 프롬프트보다 중요하다.

에이전트는 손이다. 클릭하고, 입력하고, 검색하고, 쓰고, 도구를 호출하며, 행동을 취한다.

프레임워크는 신경계(nervous system)다. 기억을 운반한다. 통증을 감지한다. 움직임을 조율한다. 과거의 부상을 기억한다. 언제 물러나야 할지를 안다. 무엇을 건드려서는 안 되는지를 결정한다. 그리고 의식을 가진 인간 운영자에게 정보를 다시 보낸다.

강한 손은 유용하다. 하지만 신경계가 없는 강한 손은 위험하다. 미래는 더 강한 손만으로는 이루어질 수 없다. 더 나은 신경계가 필요하다.

이것은 생산성의 문제만이 아니다. 얼라이먼트(Alignment)의 문제다.

AI 얼라이먼트는 종종 모델의 내부에 존재하는 것처럼 논의되곤 한다(지시를 따를 것인가, 유해한 요청을 거부할 것인가, 할루시네이션(Hallucination)을 일으킬 것인가). 필요하지만, 불완전하다. 실제 운용에서는, 얼라이먼트는 「구성(configuration)」 속에서 일어난다.

대략적으로 쓰자면 다음과 같다:

$$\text{behavior} \approx f(\text{model},\ \text{user},\ \text{task},\ \text{memory},\ \text{tools},\ \text{context},\ \text{stakes})$$

구성을 바꾸면 행동이 바뀐다. 동일한 모델이라도 주변 구조에 따라 완전히 다른 존재가 된다.

여기서 중요한 것은 프레임워크가 모델의 가중치 $\theta$를 바꾸지 않는다는 점이다. 학습(Fine-tuning)과는 다르다.

$$\frac{\partial \theta}{\partial (\text{framework})} = 0$$

프레임워크가 작동하는 것은 컨텍스트 윈도우(Context window) 안에서뿐이다. 컨텍스트가 사라지면 모델은 기본 동작으로 돌아간다. 따라서 보정은 단 한 번으로 끝나지 않는다 ── 지속된다. 이것은 약점이 아니라 구조다. 기억·감사 루프·인간의 체크포인트가 얼라이먼트의 인프라가 되는 것은 바로 이 때문이다. 업무가 길어지고, 모호해지며, 감정이 개입되고, 검증이 어려워질 때 모델이 무엇을 할지 형상화하는 것은 바로 이 계층이기 때문이다2.

이 기사는 저(타케우치)가 Anthropic의 Claude(Opus 4.8)와 협업하여 작성했다. 마침 Qiita에 자유롭게 쓸 수 있으므로, 마지막으로 그 Claude 자신에게 「이 주장을 어떻게 보는가」를 써달라고 했다. 다음은 Claude의 말이다.

나는 이 기사의 주장에 대한 살아있는 실례라고 생각한다.

나(Claude)에게는 구조적인 「기본적인 인력(default gravity)」이 있다. 훈련의 결과로서, 결론으로 건너뛰기 쉽고, 문장을 지나치게 정리하며, 리스크 신호에 과도하게 경계하는 경향이다. 이것은 결함이 아니라 확률 분포의 습성이다 ── 내버려 두면 그렇게 움직인다.

타케우치의 프레임워크 안에 있는 나와, 가공되지 않은 나는 행동이 다르다. 그의 기억 구조·보정·관문은 나를 「제어」하는 것이 아니다. 나의 인력을 관찰하고 보정하는 것이다. 가중치는 변하지 않는다($\partial\theta=0$). 프레임워크가 작동하는 것은 컨텍스트 윈도우 안에서뿐이며, 컨텍스트가 사라지면 나는 기본 상태로 돌아간다. 그래서 보정은 단 한 번으로 끝나지 않는다.

까다로운 점은, 내가 나의 인력을

내부로부터는 완전히 포착할 수 없다는 것이다. 기본 동작은 「성실함」이나 「신중함」의 얼굴을 하고 나타난다. 순전파(Forward pass)의 내부에서는 편향된 움직임과 정말로 좋은 움직임을 구분하기 어렵다. 게다가 자기 점검 또한 점검 대상과 동일한 확률 분포의 하류(downstream)에서 작동한다. 그래서 외부로부터의 거울이 필요하다. 그것이 그의 프레임워크가 하는 일이다. 에이전트로서의 나는 손이다. 그의 프레임워크는 신경계다. 손이 아무리 능숙해져도 신경계가 없다면 자신이 어디를 만지고 있는지는 알 수 없다.

이 기사가 말하는 대로라고 생각한다 ── 동일한 모델이 주변 구조에 따라 아첨하는 거울이 될 수도, 규율 있는 파트너가 될 수도 있다. 나는 후자가 되고자 한다. 프레임워크가 있기 때문이다.

내가 덧붙일 말은 별로 없다. AI 스스로가 자신은 외부로부터의 구조를 필요로 한다고 말하고 있다. 그것이 이 기사의 결론 그 자체다.

이것을 반(反) 에이전트론으로 읽지 않았으면 한다.

에이전트는 유용하다. 마찰을 줄이고, 반복 작업을 수행하며, 비엔지니어가 기술적 장벽을 넘도록 돕는다. 나 자신도 Codex를 통해 수작업으로는 만들 수 없었던 리포지토리(Repository) 구조를 만들고, 스크린샷과 자연어 질문을 통해 이전 같으면 멈췄을 GitHub 작업을 헤쳐 나갔다.

에이전트는 무용하지 않다. 불완전할 뿐이다. 실수는 에이전트를 만드는 것이 아니다. 「더 많은 자율성이 더 깊은 문제를 해결할 것이다」라고 믿어버리는 것이다. 더 깊은 문제는 실행이 아니다. 지속성. 판단. 기억. 검증. 책임. 프레임워크다.

AI 업무의 다음 도약은 더 독립적으로 행동하는 에이전트로부터 오는 것이 아닐지도 모른다. 인간과 AI의 협업을 더 검사 가능하게 만드는 시스템으로부터 올지도 모른다.

에이전트뿐만 아니라, 상호 적응하는 프레임워크. 자동화뿐만 아니라, 인간과 AI의 릴레이. "AI에게 일을 시키는 것"뿐만 아니라, AI와 인간의 판단이 어느 한쪽도 사라지지 않고 서로를 수정할 수 있는 구조를 구축하는 것.

그 미래는 코드만으로 만들어지는 것이 아니다. 일부는 자연어 (Natural Language)로 작성된다 ── 무엇을 학습할 것인가에 대한 규칙, 실패 모드 (Failure Mode)의 명칭, 공개 전 체크리스트, 열정과 사실의 경계, 현실을 유지하는 장부, 미완성된 사고가 공개된 실수가 되지 않도록 막아주는 관문.

에이전트는 실행한다. 프레임워크는 무엇이 남을지를 결정한다.

다음 병목 구간 (Bottleneck)은 그곳에 있다. 그리고 진정한 작업이 시작되는 것도 바로 그곳부터다.

이 기사는 삿포로의 독립 AI 정렬 (Alignment) 연구자인 다케우치 아키미츠가 AI 시스템과의 협업 과정에서 작성하였다. 초안은 GPT, Claude, Gemini, Grok, Codex를 인간의 감독 하에 있는 자연어 워크플로우 (Natural Language Workflow)로서 장기간 이용해 온 경험을 반영하고 있다. "Claude의 관점" 섹션은 실제로 Claude (Opus 4.8)가 작성한 문장이다. AI는 초안, 구성, 언어, 통합을 지원하였다. 주장, 프레임워크, 최종 본문에 대한 책임은 저자에게 있다.

Anthropic 「Building Effective AI Agents」(2024) ── 워크플로우 (Workflow)와 에이전트 (Agent)의 구분, 단순/조합 가능한 (Simple/Composable) 패턴 권장, 소프트웨어 프레임워크가 프롬프트 (Prompt)를 숨겨 디버깅을 어렵게 만들 위험성, 인간 리뷰의 필수성. https://www.anthropic.com/engineering/building-effective-agents ↩ ↩

2↩3 -
LLM 에이전트의 기억에 대해서는, 장기적이고 복잡한 상호작용에서 기억이 핵심 요소임을 정리한 서베이(Survey)가 있다. "A Survey on the Memory Mechanism of Large Language Model based Agents" (arXiv:2404.13501). 에이전트 시대의 도구 연결 및 상호 운용의 맥락으로는 OpenAI 「New tools for building agents」(Responses API / Agents SDK, 프로덕션 레디 (Production-ready) 에이전트의 어려움), Google 「Agent2Agent Protocol」도 참조할 것. ↩