진정한 에이전시(Agency)는 프롬프트가 아니라 루프(Loop)다

현대적 에이전트에서의 진정한 에이전시 (Real Agency)

에이전트는 확인하겠다, 계속하겠다, 검증하겠다라고 말합니다. 그러고 나서 프로세스는 종료됩니다. 아무것도 돌아오지 않습니다.

모델이 나쁘기 때문이 아닙니다. 모델은 너무나 빠르게 발전하고 있어서, 불평을 늘어놓는 문장이 끝나기도 전에 이미 그 불평이 구식처럼 느껴질 정도입니다. 문제는 모델이 코드를 작성하거나, 문서를 요약하거나, 도구(Tool)를 호출하거나, 계획을 생성하지 못하는 것이 아닙니다. 그들은 할 수 있으며, 종종 아주 훌륭하게 해냅니다.

문제는 우리가 "에이전트적(agentic)"이라고 부르는 대부분의 것들이 여전히 프롬프트(Prompt)에 의해 트리거되는 단순한 엔드 투 엔드(end-to-end) 실행처럼 동작한다는 점입니다.

당신이 질문하면, 그것은 대답하고, 멈춥니다.

중간에 도구를 호출하거나, 자신감 넘치는 텍스트를 많이 스트리밍할 수도 있습니다. 데모는 30초 동안은 마치 미래처럼 보일 수도 있습니다.

하지만 문맥(Context)을 놓치거나, 실패를 겪거나, 나중에 무언가를 하겠다고 약속하거나, 작업이 실제로 완료되기 전에 조용히 멈추는 순간이 오면—그리고 이는 단지 언제냐의 문제일 뿐입니다—시스템을 다시 작동하게 만들 밑바탕이 없는 경우가 많습니다.

그것은 에이전시(Agency)가 아닙니다.

그것은 매우 인상적인 함수 호출(Function call)일 뿐입니다.

나는 더 나은 자동 완성(Autocomplete)을 원하는 것이 아니다

나는 자동 완성(Autocomplete)이 무엇인지 압니다. 딥 에이전트(Deep agents)를 사용하기 전에도 사용해 봤습니다. 그것은 유용했습니다...

내가 관심을 두는 것은 위임(Delegation)과 에이전시(Agency)입니다. 진정한 에이전시 말입니다. 시스템에 지시를 내리고, 잠시 자리를 비웠다가 돌아왔을 때 다음과 같은 증거를 확인할 수 있는 종류의 에이전시입니다: 무엇을 시도했는지, 무엇이 변했는지, 무엇이 실패했는지, 무엇이 여전히 인간을 필요로 하는지, 그리고 그 이유는 무엇인지 말입니다.

이것은 "모델이 그럴듯한 답변을 생성했다"라는 기준과는 매우 다른 차원의 문제입니다.

이 차이점은 이러한 시스템들이 실패하는 것을 보기 전까지는 당연하게 들립니다. 어시스턴트(Assistant)는 답변 하나로 도움을 줄 수 있습니다. 하지만 진정한 에이전트는 답변과 답변 사이의 공간에서 살아남아야 합니다. 부분적인 결과가 완료와 같지 않다는 것을 알아야 합니다. "이것을 하겠습니다"가 그것을 실제로 수행하는 것과 같지 않다는 것을 알아야 합니다. 언제 계속 가야 할지, 언제 회복해야 할지, 그리고 언제 스스로에게 거짓말하는 것을 멈추고 도움을 요청해야 할지를 알아야 합니다.

모델이 에이전트인 것이 아닙니다.

루프(Loop)가 에이전트입니다.

"그렇게 하겠습니다"라는 거짓말

에이전트 시스템(Agentic systems)에서 가장 짜증 나는 실패 모드는 짜증 날 정도로 정중하다는 점입니다.

에이전트는 무언가를 확인하겠다고 말합니다. 계속하겠다거나 다음 단계를 할당하겠다고 말합니다. 결과를 검증하겠다고 말합니다. 언어상으로는 마치 작업이 곧 일어날 것처럼 들립니다.

그러고 나서, 어떤 이유에서인지 프로세스가 종료됩니다.

아무것도 돌아오지 않습니다. 증거도 없습니다. 수정도 없습니다. 에스컬레이션(Escalation)도 없습니다. 그저 에이전시(Agency)의 형태를 띤 문장만 있을 뿐, 행동이나 결과는 전혀 없습니다.

이 지점에서 많은 팀이 스스로를 속입니다. 그들은 모델이 에이전트 같은 언어를 생성하는 것을 보고, 그것을 에이전트다운 실행(Agentic execution)으로 착각합니다. 하지만 에이전시는 말투가 아닙니다. 페르소나(Persona)도 아닙니다. 자신감 있게 "제가 처리하겠습니다"라고 말하는 것이 아닙니다.

에이전시는 운영적(Operational)이며, 당신을 필요로 하지 않습니다.

에이전시는 지루한 부분들, 즉 상태(State), 복구(Recovery), 검증(Validation), 증거(Evidence)에서 나타납니다.

만약 시스템이 약속과 완료된 행동 사이의 차이를 구분할 수 없다면, 그것은 에이전시를 가지고 있지 않은 것입니다.

루프(Loop)가 에이전트다

제 머릿속에 계속 맴도는 멘탈 모델(Mental model)은 단순합니다.

원샷(One-shot) 소프트웨어는 다음과 같습니다:

질문(ask) -> 답변(answer) -> 중단(stop)

질문에 답하기에는 괜찮습니다. 하지만 작업을 수행하기에는 끔찍합니다.

작업은 다음과 같은 모습에 더 가깝습니다:

목표(goal) -> 시도(attempt) -> 관찰(observe) -> 분류(classify) -> 계속(continue) / 복구(recover) / 중단(stop)

제가 "루프가 에이전트다"라고 말할 때, 루프 그 자체만이 어떤 마법 같은 실체라는 뜻은 아닙니다. 당연히 하네스(Harness), 도구(Tools), 모델(Model), 상태(State), 그리고 주변 제품(Product)이 모두 중요합니다. 저는 은유적으로 말하는 것입니다. 에이전시를 만드는 것은 단 한 번의 모델 호출(Model call)이 아닙니다. 시스템이 시도하고, 관찰하고, 수정하고, 계속할 수 있게 해주는 반복적인 구조(Repeating structure)입니다.

각 단어가 중요합니다.

**목표(Goal)**는 시스템이 단순히 텍스트 턴(Text turn)을 완료하는 것이 아니라, 어떤 결과(Outcome)를 향해 나아가려 한다는 것을 의미합니다.

**Attempt (시도)**는 모델이 행동할 수 있는 제한된 기회를 얻음을 의미합니다. 무한한 자유가 아닙니다. 마법 같은 개방형 프로세스도 아닙니다. 단 한 번의 시도입니다.

**Observe (관찰)**는 시스템이 실제로 일어난 일을 기록함을 의미합니다. 모델이 일어났다고 말한 내용이 아니라, 실제로 일어난 일 말입니다.

**Classify (분류)**는 시스템이 해당 시도가 완료되었는지, 부분적인지, 실패했는지, 차단되었는지, 아니면 실체 없는 정중한 약속일 뿐인지 결정함을 의미합니다.

그다음에, 오직 그때서야 다음 단계가 무엇인지 결정해야 합니다.

진전이 실질적이라면 계속하십시오. 실패가 유용하다면 복구하십시오. 시스템에 인간의 결정이 필요하다면 중단하십시오. 똑같은 프롬프트를 눈먼 듯이 열두 번 다시 실행하면서 그것을 자율성(Autonomy)이라고 부르지 마십시오.

겉으로 화려한 기능은 에이전트가 일을 하는 것입니다.

진정한 핵심 기능은 그 일이 제대로 수행되었는지 아는 하네스(Harness)입니다.

워크플로 시스템이 이미 알고 있는 것들

신뢰할 수 있는 시스템 주변에서 시간을 보냈다면 이 중 어느 것도 새로운 것이 아닙니다.

장시간 실행되는 작업에는 항상 상태(State)가 필요했습니다. 분산 시스템(Distributed systems)에는 항상 재시도(Retries)가 필요했습니다. 진지한 자동화에는 항상 멱등성(Idempotency), 로그(Logs), 제한(Limits), 그리고 에스컬레이션 경로(Escalation paths)가 필요했습니다. 이제 작업자가 모델이기 때문에 언어는 달라졌지만, 문제의 형태는 익숙합니다.

내구성이 있는 추적(Durable trace)이 필요합니다. 메모리(Memory)가 없다면 에이전트는 자신의 단계와 실수를 반복할 수밖에 없기 때문입니다.

검증(Validation)이 필요합니다. "완료된 것처럼 보임"은 망가진 작업이 배포되는 방식이기 때문입니다.

시도 제한(Attempt limits)이 필요합니다. 영원히 재시도하는 것은 지속 가능하지 않기 때문입니다.

복구(Recovery)가 필요합니다. 부분적인 진전도 가치가 있기 때문입니다.

중단할 방법이 필요합니다. 어떤 문제들은 정말로 인간 참여(Human-in-the-loop)를 필요로 하기 때문입니다.

이것이 많은 에이전트 담론이 놓치고 있다고 생각하는 부분입니다. 모두가 추론(Reasoning)에 대해 이야기하고 싶어 합니다. 추론은 중요합니다. 하지만 실제 시스템에서 추론은 하나의 차원일 뿐입니다. 취약한 하네스 안에 있는 뛰어난 모델은 여전히 취약합니다.

만약 하네스가 마지막 메시지를 진실로 취급한다면, 전체 시스템은 모델의 가장 나쁜 습관을 물려받게 됩니다. 즉, 완료되기 전에 완료된 것처럼 말하는 습관 말입니다.

기술(Skills)은 루프가 기억하는 방식이다

제가 점점 더 관심을 갖게 된 한 가지 패턴은 기술(Skills)입니다.

마케팅 용어로서의 "기술(skill)"을 말하는 것이 아닙니다. 제가 의미하는 것은 반복되는 종류의 작업을 에이전트(Agent)가 처리하는 방법을 가르치는 절차의 작고 재사용 가능한 패키지, 즉 지침(instructions), 체크리스트(checklists), 스크립트(scripts), 예시(examples), 검증 단계(validation steps), 그리고 복구 경로(recovery paths)를 의미합니다.

이것이 중요한 이유는 진지한 에이전트 시스템(agent system)이라면 똑같은 실수를 영원히 반복해서는 안 되기 때문입니다.

실패가 한 번 발생했다면 그것은 아마도 노이즈(noise)일 것입니다. 두 번 발생했다면 그것은 신호(signal)입니다. 세 번 발생한다면, 그것은 아마도 하나의 절차(procedure)가 되어야 합니다.

인간도 이런 방식으로 일합니다. 우리는 습관을 만듭니다. 런북(runbooks)을 작성합니다. 체크리스트를 만듭니다. 작업의 어떤 부분이 취약한지 학습하며, 매번 그것들을 완벽하게 기억할 것이라고 스스로를 신뢰하는 것을 멈춥니다.

우리의 뇌는 고정되어 있지 않습니다. 연습, 반복, 피드백, 그리고 복구를 통해 변화합니다. 그것이 우리가 배우는 방식입니다. 그것이 습관이 형성되는 방식입니다. 스스로를 경직(calcify)되게 두는 대신 새로운 패턴으로 계속 밀어붙인다면, 거의 어떤 연령대에서도 개선될 수 있는 이유가 바로 이것입니다.

에이전트 시스템은 뇌가 아닙니다. 소프트웨어는 생물학이 아닙니다.

하지만 교훈은 여전히 유효합니다. 개선을 위해서는 경험 후에 시스템이 변화해야 합니다.

에이전트에게 있어 그 변화는 신비로울 필요가 없습니다. 정확히 올바른 방식으로 지루할 수도 있습니다. 실패한 실행은 체크리스트가 됩니다. 반복되는 실수는 검증기(validator)가 됩니다. 취약한 워크플로우(workflow)는 복구 단계(recovery step)를 갖게 됩니다. 혼란스러운 인수인계(handoff)는 더 명확한 증거 요구 사항을 갖게 됩니다.

진정한 자율성(autonomy)은 작업을 한 번 수행하는 것이 아닙니다.

다음 작업이 더 나은 지점에서 시작될 수 있도록 시스템을 변화시키는 것입니다.

진짜 핵심 기능은 지속성(continuation)이다

에이전트를 중심으로 더 많은 것을 구축할수록, 단 한 번의 성공적인 실행에는 감명받지 않게 됩니다.

단 한 번의 실행은 운일 수 있습니다. 데모(demo)는 모든 추한 부분들을 숨길 수 있습니다. 프롬프트(prompt)는 컨텍스트(context)가 신선하고, 입력값이 깨끗하며, 아무도 시스템에 무언가로부터 복구할 것을 요구하지 않을 때 완벽하게 작동할 수 있습니다.

지속성(continuation)은 더 어렵습니다.

시스템이 중단된 후 재개할 수 있는가?

이전의 답변이 단지 약속에 불과했다는 것을 알아차릴 수 있는가?

처음부터 다시 시작하지 않고 계속 나아갈 수 있을 만큼 충분한 컨텍스트를 보존할 수 있는가?

확신(Confidence) 대신 증거(Evidence)를 제시할 수 있는가?

피해를 입히기 전에 멈출 수 있는가?

신뢰는 바로 그 지점에서 시작된다.

첫 번째 답변에서 시작되는 것이 아니다. 두 번째 시도에서, 복구(Recovery) 과정에서, 수정(Correction) 과정에서 시작된다. 또한 인간이 기억을 되짚어 전체적인 난장판을 다시 겪지 않고도 무슨 일이 일어났는지 이해할 수 있게 해주는 추적(Trace)에서 시작된다.

나를 감동시키는 에이전트(Agent)는 가장 똑똑하게 들리는 에이전트가 아니다.

다시 돌아오는(Comes back) 에이전트다.

에이전트들의 작은 사회들

나는 미래가 모든 것을 수행하는 하나의 거대한 신과 같은 에이전트(God-agent)가 될 것이라고 생각하지 않는다.

그러한 프레임워크는 잘못된 것처럼 느껴진다. 그것은 너무 연극적이고, 너무 취약하며, 지능을 단일한 권력의 지점으로 보는 데 너무 집착한다.

내가 관심을 두는 미래는 각각의 직무, 컨텍스트(Context), 도구 세트, 그리고 검증 방법을 가진 경계가 있는 에이전트(Bounded agents)들의 작은 사회에 더 가깝다. 계층 구조가 멋지기 때문이 아니다. 경계(Boundaries)야말로 시스템이 온전함을 유지하는 방법이기 때문이다.

한 에이전트는 탐색한다. 한 에이전트는 작성한다. 한 에이전트는 검증(Validate)한다. 한 에이전트는 요약한다. 한 에이전트는 시스템이 감당할 수 없는 수준에 도달했을 때 인간에게 질문한다. 정확한 형태는 다양하겠지만, 원칙은 동일하다: 자율성(Autonomy)에는 구조(Structure)가 필요하다.

구조가 없다면, 더 많은 에이전트는 그저 더 많은 혼돈을 의미할 뿐이다.

구조가 있다면, 에이전트 주변의 워크플로(Workflow)가 책임 소재(Accountability)를 가능하게 할 때 에이전트는 팀 동료에 더 가까운 존재가 될 수 있다.

이 차원에서, 에이전시(Agency)는 하나의 계약이다.

루프(Loop)로 생각하라

유용한 에이전트 시스템(Agentic systems)의 다음 물결은 단지 더 나은 프롬프트(Prompt)에서만 오지 않을 것이다.

그것은 더 나은 루프(Loop)에서 올 것이다.

관찰하는 루프. 분류하는 루프. 복구하는 루프. 검증하는 루프. 지난번에 무엇이 고장 났는지 기억하는 루프. 언제 멈추고 사람을 다시 개입시켜야 하는지 아는 루프.

그것이 바로 내가 현재 이 분야에서 사랑하는 부분이다. 다시 소프트웨어 엔지니어링(Software engineering)처럼 느껴지기 때문이다. 단순히 모델에게 더 똑똑해지라고 요구하는 것이 아니라, 지능이 신뢰할 수 있는 작업이 될 수 있는 환경을 구축하는 것이다.

나는 더 나은 버전이 존재하려고 노력하는 것을 보고 있기에, 진정한 에이전시(Agency)가 없는 에이전트들에게 지쳤다.

그것은 마법이 아니다.

그것은 AGI가 아니다.

그것은 메모리(Memory), 증거(Evidence), 복구(Recovery), 그리고 안목(Taste)을 갖춘 루프다.

만약 당신의 에이전트(Agent)가 되돌아올 수 없다면, 그것은 자율적(Autonomous)인 것이 아닙니다.

그것은 단지 종료된 프롬프트(Prompt)일 뿐입니다.