Agent는 무엇인가```markdown # Agent는 Tool Loop가 아니다 ## 들어가며: Agent를 만들자고 하면 무엇부터 떠올리는가? AI Agent를 설계한다고 하면 가장 먼저 여러 구현 요소가 떠오른다. * 어떤 LLM을 사용할 것인가 * 어떤 Tool을 연결할 것인가 * Planner와 Executor를 분리할 것인가 * Memory를 어떻게 구성할 것인가 * Tool의 실행 결과를 몇 번까지 다시 입력할 것인가 * 어떤 Agent Framework를 사용할 것인가 이러한 요소들은 실제 Agent를 구현하는 데 필요하다. 그렇다고 해서 구현 요소를 먼저 선택한다고 자동화하려는 업무가 저절로 이해되는 것은 아니다. 검색 Tool과 코드 실행 Tool을 연결하고, 실행 결과를 다시 LLM에 전달하는 Loop를 만들 수는 있다. 하지만 이 구조만으로는 시스템이 무엇을 판단해야 하는지 알 수 없다. - 어떤 정보를 중요하게 보아야 하는가 - 여러 행동 가운데 무엇을 먼저 수행해야 하는가. - 실행 결과가 예상과 다를 때 기존 계획을 유지해야 하는가, 아니면 다른 방법을 찾아야 하는가. - 어느 정도의 결과를 얻었을 때 작업이 끝났다고 판단해야 하는가. 이 질문들이 정리되지 않은 상태에서 Tool과 Loop부터 연결하면, 겉보기에는 Agent처럼 움직이지만 실제로는 무엇을 잘해야 하는지 불분명한 시스템이 만들어질 수 있다. > Tool과 Loop는 판단을 구현하는 수단이다. Tool과 Loop 자체가 판단의 내용을 만들어주지는 않는다. Agent를 설계하기 전에 먼저 살펴봐야 하는 것은 자동화하려는 업무다. 그 업무에서 사람은 무엇을 관찰하는가. 어떤 정보를 중요한 단서로 보고, 어떤 정보는 무시하는가. 무엇을 근거로 다음 행동을 선택하며, 언제 기존 판단을 수정하는가. Agent를 만든다는 것은 이러한 판단을 발견하고, 그중 어디까지를 시스템에 위임할지 설계하는 일이다. --- ## 1. Tool Loop가 보여주는 것과 보여주지 못하는 것 오늘날 LLM Agent는 흔히 다음과 같은 구조로 설명된다. 1. 사용자가 목표를 입력한다. 2. LLM이 다음 행동이나 Tool을 선택한다. 3. Tool이 실행된다. 4. 실행 결과가 다시 LLM에 전달된다. 5. 작업이 끝날 때까지 같은 과정을 반복한다. 이를 간단히 줄이면 다음과 같다. **관찰, 판단, 행동, 결과, 다시 판단** 이 구조는 Agent를 설명하는 데 유용하다. 실제로 많은 LLM Agent가 이와 비슷한 Loop를 사용한다. 문제는 이러한 외형만으로 시스템의 성격을 판단할 때 발생한다. 예를 들어 두 시스템이 모두 검색 Tool과 분석 Tool을 사용한다고 생각해보자. 첫 번째 시스템은 검색 Tool을 실행한 뒤, 결과를 요약하고, 정해진 분석 Tool을 호출한다. 실행 순서와 종료 조건은 모두 코드에 미리 작성되어 있다. LLM은 각 단계에서 필요한 내용을 생성하지만, 전체 진행 방향을 바꾸지는 않는다. 두 번째 시스템은 검색 결과를 확인한 뒤 정보가 부족하다고 판단하면 검색어를 바꾼다. 서로 모순되는 자료를 발견하면 다른 출처를 찾고, 충분한 근거가 모였다고 판단할 때 분석을 시작한다. 결과의 신뢰도가 낮으면 추가 검증을 수행하거나 사용자에게 질문한다. 두 시스템 모두 Tool을 호출하고 결과를 다시 입력받는다. 겉으로 보면 같은 Tool Loop다. 하지만 그 안에서 모델에 위임된 판단은 다르다. * Tool의 실행 순서를 바꿀 수 있는가 * 결과에 따라 기존 계획을 수정할 수 있는가 * 필요한 정보가 무엇인지 판단할 수 있는가 * 다른 방법을 선택할 수 있는가 * 언제 작업을 끝낼지 결정할 수 있는가 * 불확실할 때 인간에게 질문할 수 있는가 Loop가 존재한다는 사실은 실행이 반복된다는 것만 보여준다. 그 안에서 무엇을 판단하는지, 어떤 선택이 가능한지, 어디까지 행동할 수 있는지는 보여주지 않는다. 단순한 반복문도 Loop이고, 정해진 API를 차례대로 호출하는 자동화도 Tool을 사용한다. 아무리 정교한 Loop, Tool이 구축 되어 있어도 시스템에 충분한 판단권이 주어졌다고 볼 수는 없다. --- ## 2. 자동화하려는 업무를 먼저 해부해야 한다 그렇다면 Agent는 어떻게 설계해야 할까. 먼저 자동화하려는 것이 정확히 무엇인지 살펴봐야한다. 여기에서 말하는 업무는 사람이 화면에서 수행하는 행동의 순서만을 뜻하는 것이 아니다. 버튼을 누르고, 문서를 열고, 검색어를 입력하는 겉은 무의식적인면도 있지만, 결국 무언가를 하기 위한 행동으로 드러난다. 항상 모든 사소한 행동에는 판단과, 익숙함이 있다 예를 들어 보안 전문가가 웹 서비스의 취약점을 점검한다고 생각해보자. 겉으로 드러나는 행동만 보면 다음과 같을 수 있다. * 페이지를 연다. * 요청과 응답을 확인한다. * 입력값을 변경한다. * Payload를 전송한다. * 결과를 기록한다. 이 순서를 그대로 자동화하면 정해진 입력값을 보내고 응답을 수집하는 Scanner를 만들 수 있다. 이러한 자동화도 충분히 가치가 있다. 하지만 숙련된 보안 전문가는 단순히 정해진 순서대로 Payload를 보내지 않는다. 입력 Vector, 출력, 오류 메시지 이런것들보다 우리가 이 정보들을 어떻게 받아들이고 수많은 코드들 중에서 필요한 정보만을 보게 되는 우리의 모습을 살펴봐야 한다. 결국, 우리도 우리의 무의식적인 행동속에 효율, 최적화 이런것들을 생각하면서 데이터의 연결성을 찾고 조합을 한다. 이 과정에는 다음과 같은 판단이 숨어 있다. * 어떤 정보가 중요한 단서인가 * 무엇이 정상이고 무엇이 이상한가 * 어떤 가설을 먼저 검증해야 하는가 * 어떤 행동의 위험이 더 낮은가 * 결과가 가설을 지지하는가 * 추가 검증이 필요한가 * 어느 정도의 근거가 있으면 취약점으로 판단할 수 있는가 * 언제 자동 검증을 멈추어야 하는가 그 외에도 상당히 많은 부분이 존재할 것이다. 이미 익숙한 사람들은 그것이 습관이 되고, 체크리스트를 굳이 구비하지 않아도 스스로 판단을 빠르게 수행하기도 한다. 즉, 자신이 왜 특정한 정보를 먼저 확인했는지, 왜 어떤 방법은 시도하지 않았는지 즉시 설명하지 못할 수도 있다. 자동화하려는 업무를 이해한다는 것은, 우리가 무의식적으로 생각하는 부분과 어떤 일을 해야 되는지 숨어 있는 판단을 밖으로 꺼내는 연습이 필요할 것이다. 사람의 생각을 그대로 복제하거나, 머릿속 독백을 모두 문장으로 만들어야 한다는 뜻은 아니다. 판단을 구성하는 요소를 구분하고, 시스템에 필요한 형태로 다시 설계해야 한다는 뜻이다. * 관찰: 어떤 정보와 상태를 확인하는가 * 해석: 관찰한 정보를 어떤 의미로 받아들이는가 * 가설: 가능한 원인이나 해결책을 어떻게 만드는가 * 우선순위: 무엇부터 확인할지 어떻게 정하는가 * 행동: 어떤 Tool이나 조치를 선택하는가 * 피드백: 결과가 기존 판단을 어떻게 바꾸는가 * 종료: 무엇을 성공과 실패로 판단하는가 * 이관: 언제 인간이나 다른 시스템에 넘기는가 ... 등 이 과정을 충분히 분석한 뒤에야 필요한 Tool이 무엇인지 알 수 있다. 어떤 정보를 Memory에 남겨야 하는지, 어떤 결과가 다음 판단에 영향을 주어야 하는지, Loop가 왜 필요한지도 그때 분명해진다. 반대로 업무의 판단 구조가 정리되지 않았다면 Tool은 많지만 무엇을 해야 할지 모르는 시스템이 만들어질 수 있다. Memory에는 많은 정보가 쌓이지만, 다음 행동에 필요한 정보가 무엇인지는 알지 못할 수 있다. Multi-Agent로 역할을 나누어도 문제는 해결되지 않는다. 한 시스템에서 정의되지 않은 판단을 여러 Agent에게 나누어 준다고 해서, 그 판단이 갑자기 명확해지는 것은 아니기 때문이다. > 자동화의 출발점은 Agent Framework가 아니라, 자동화하려는 업무에서 실제로 어떤 판단이 일어나는지 확인하는 것이다. --- ## 3. Agent는 LLM 시대에 처음 생긴 개념이 아니다 Agent를 Tool Calling과 Loop의 조합으로 생각하게 된 이유는, 오늘날 Agent를 주로 LLM을 통해 접하기 때문이다. 그러나 Agent는 LLM 시대에 처음 등장한 개념이 아니다. 인공지능 분야에서는 오랫동안 Agent를 환경에서 정보를 받아들이고, 그 환경에 다시 행동을 내보내는 시스템으로 다뤄왔다. 대표적인 인공지능 교과서인 Artificial Intelligence: A Modern Approach는 Agent를 Sensor를 통해 환경을 인식하고, Actuator를 통해 환경에 작용하는 것으로 설명한다.[1] 여기서 중요한 것은 특정한 Tool이나 LLM이 아니다. * Agent가 놓인 환경이 있다. * 환경에 관한 정보가 들어온다. * 가능한 행동이 존재한다. * 어떤 기준에 따라 행동을 선택한다. * 행동의 결과가 다시 환경에 나타난다. 이러한 구조는 여러 AI 연구 분야에서 서로 다른 모습으로 나타났다. AI Planning에서는 목표에 도달하기 위해 어떤 행동을 어떤 순서로 수행할지 다뤘다. 로봇공학에서는 Sensor로 주변 환경을 확인하고, 실제 장치를 통해 행동을 수행했다. 다중 Agent 연구에서는 여러 Agent가 같은 환경에서 협력하거나 경쟁하는 문제를 다뤘다. 1990년대의 BDI Agent 연구는 Agent의 정보, 동기, 현재 실행하려는 의도를 각각 Belief, Desire, Intention으로 나누어 행동을 설명하려 했다.[2] 강화학습에서도 Agent와 Environment의 관계가 중심에 놓인다. Agent는 현재 상태에서 행동을 선택하고, Environment는 그 행동의 결과로 새로운 상태와 Reward를 돌려준다. Agent는 이러한 경험을 통해 이후의 행동 방식을 조정한다.[3] 이 연구들이 모두 같은 종류의 Agent를 다룬 것은 아니다. 로봇의 움직임을 제어하는 Agent와 여러 업무를 처리하는 Software Agent, 게임을 학습하는 강화학습 Agent는 서로 다른 문제를 해결한다. 그럼에도 반복되는 구조가 있다. > Agent는 환경의 상태를 바탕으로 가능한 행동 가운데 하나를 선택하고, 그 결과와 다시 상호작용하는 위치에 있다. 이 관점에서 보면 오늘날 LLM Agent가 완전히 새로운 개념을 만든 것은 아니다. LLM은 자연어와 비정형 정보를 해석하고, 가능한 행동을 선택하는 새로운 방법을 제공했다. API, 검색, 코드 실행과 같은 Tool은 LLM이 디지털 환경을 관찰하고 변경할 수 있는 통로가 되었다. ReAct는 LLM이 추론 과정과 구체적인 행동을 번갈아 생성하도록 하여, 외부 환경에서 얻은 정보를 바탕으로 계획을 갱신하고 예외에 대응하는 구조를 제시했다.[4] 이후 Tool Calling과 Agent Framework가 널리 사용되면서, Agent는 LLM이 Tool을 반복 호출하는 모습으로 대중화되었다. --- ## 4. Agent를 이루는 공통 구조 서로 다른 Agent를 하나의 엄격한 정의로 묶기는 어렵다. 대신 시스템을 분석하기 위한 공통 구조를 생각해볼 수 있다. ### 환경 환경은 Agent가 정보를 얻고 영향을 미치는 대상이다. 로봇에게는 물리적인 공간이 환경이 될 수 있다. 웹 자동화 Agent에게는 브라우저와 웹 서비스가 환경이 될 수 있다. 코드 Agent에게는 저장소, 실행 환경, Test 결과가 환경이 될 수 있다. 환경은 반드시 현실 세계일 필요가 없다. 데이터베이스, 파일 시스템, 게임, 대화, 다른 Agent도 환경의 일부가 될 수 있다. ### 관찰 Agent는 환경 전체를 그대로 알 수 없다. Sensor, API 응답, 문서, Log, 사용자 메시지처럼 제한된 통로를 통해 현재 상태를 관찰한다. 따라서 Agent의 성능은 모델의 능력만으로 결정되지 않는다. 어떤 정보를 관찰할 수 있도록 제공했는지도 중요하다. 필요한 Log를 볼 수 없는 장애 대응 Agent는 정확한 원인을 찾기 어렵다. 페이지의 DOM이나 Network 요청을 확인할 수 없는 보안 Agent는 화면에 보이는 결과만으로 판단해야 한다. ### 상태 현재 판단에는 방금 들어온 정보뿐 아니라 이전 과정도 필요할 수 있다. * 이미 시도한 행동 * 이전 행동의 결과 * 현재까지 세운 가설 * 실패한 접근 방법 * 남은 비용과 시간 * 사용자가 정한 조건 * 인간이 승인하거나 거부한 행동 이러한 정보가 현재 상태를 이룬다. Memory는 이 상태를 저장하고 전달하기 위한 구현 수단이다. 따라서 Memory를 먼저 만들기보다, 다음 판단에 어떤 과거 정보가 필요한지부터 정해야 한다. ### 목표와 평가 기준 Agent가 행동을 선택하려면 어떤 결과를 더 좋은 것으로 볼지 정해야 한다. 목표는 사용자가 줄 수도 있고, 개발자가 코드에 작성할 수도 있다. 시스템이 주어진 목표를 여러 하위 목표로 나눌 수도 있다. 여기서 목표와 성공 기준을 구분할 필요가 있다. "취약점을 찾아라"는 목표만으로는 부족하다. * 어떤 종류의 취약점을 찾을 것인가 * 어느 수준의 근거가 필요할 것인가 * 서비스에 영향을 줄 수 있는 검증을 허용할 것인가 * 오탐과 미탐 가운데 무엇을 더 줄여야 하는가 * 얼마의 시간과 요청을 사용할 수 있는가 이러한 기준이 있어야 시스템이 무엇을 좋은 결과로 판단할지 정할 수 있다. Rational Agent의 행동 역시 단순히 똑똑해 보이는 행동이 아니다. 관찰한 정보, 사용 가능한 행동, 환경에 관한 지식, 성과를 평가하는 기준에 따라 더 나은 결과를 기대할 수 있는 행동을 선택하는 것이다.[1] ### 행동 선택 Agent에는 가능한 행동이 여러 개 있을 수 있다. 검색할 수도 있고, 코드를 실행할 수도 있다. 추가 정보를 요청하거나, 기존 결과를 검증하거나, 작업을 중단할 수도 있다. Agent 설계에서 중요한 것은 행동의 수가 아니다. 현재 상태에서 어떤 행동을 선택해야 하는지, 그 선택을 무엇이 결정하는지가 중요하다. ### 실행과 피드백 선택한 행동이 실제로 실행되면 환경의 상태가 달라지거나 새로운 정보가 들어온다. Agent는 이 결과를 다음 판단에 반영해야 한다. 하지만 결과를 프롬프트에 다시 넣는 것만으로 충분한 피드백이 만들어지는 것은 아니다. 결과가 다음과 같은 변화를 만들어야 한다. * 기존 가설의 신뢰도가 올라가거나 내려간다. * 다음 행동의 우선순위가 바뀐다. * 계획의 일부가 수정되거나 폐기된다. * 새로운 위험이 발견된다. * 작업을 종료하거나 인간에게 넘긴다. 결과가 들어왔지만 매번 같은 행동을 반복한다면, Loop는 존재해도 의미 있는 조정은 일어나지 않는다. --- ## 5. Tool과 Loop는 어디에 위치하는가 Tool과 Loop가 Agent의 전부가 아니라는 말은, 이들이 중요하지 않다는 뜻이 아니다. 오히려 업무와 판단 구조가 분명해졌을 때 각각의 역할을 더 정확하게 설계할 수 있다. ### Tool은 환경과 연결되는 행동 수단이다 LLM은 문장을 생성하는 것만으로 파일을 수정하거나, 웹을 검색하거나, 메일을 보낼 수 없다. Tool은 LLM의 선택을 실제 환경의 행동으로 바꾸는 인터페이스다. Tool은 환경을 변경하는 데만 사용되지 않는다. 새로운 정보를 관찰하기 위해 사용할 수도 있다. * 검색 결과를 가져온다. * 데이터베이스를 조회한다. * Log를 확인한다. * 코드를 실행하고 결과를 받는다. * 파일을 수정한다. * 메일이나 메시지를 전송한다. 같은 Tool이라도 어떤 목적으로 사용할지는 Agent의 판단 구조에 따라 달라진다. 검색 Tool이 있다는 것보다, 언제 검색이 필요하다고 판단하고 어떤 정보를 찾으려 하는지가 더 중요하다. ### Loop는 결과를 다시 판단에 반영하는 구조다 첫 번째 행동만으로 작업이 끝나지 않을 때 Loop가 필요하다. Agent는 행동의 결과를 확인하고 다음 행동을 선택한다. 예상과 다른 결과가 나오면 계획을 바꾸거나 다른 Tool을 사용할 수 있다. 그러나 모든 업무에 긴 Loop가 필요한 것은 아니다. 입력 형식이 명확하고 처리 순서가 일정하다면, 정해진 Workflow가 더 빠르고 안정적일 수 있다. 한 번의 LLM 호출과 하나의 검증 단계로 충분한 문제를 여러 차례 반복하게 만들면 비용과 오류 가능성만 높아질 수 있다. Loop의 길이가 Agent의 수준을 나타내는 것도 아니다. 좋은 Loop는 오래 반복하는 Loop가 아니라, 필요한 결과를 얻었을 때 멈추고 실패가 분명할 때 다른 경로를 선택할 수 있는 Loop다. ### Memory는 필요한 상태를 유지하는 수단이다 Memory가 많을수록 더 좋은 Agent가 되는 것은 아니다. 중요하지 않은 정보가 계속 쌓이면 모델이 현재 판단에 필요한 내용을 찾기 어려워질 수 있다. 오래된 가설이나 잘못된 결과가 이후 판단에 계속 영향을 줄 수도 있다. Memory를 설계할 때는 다음을 먼저 물어야 한다. * 다음 행동을 정할 때 어떤 과거 정보가 필요한가 * 어떤 정보는 작업이 끝난 뒤에도 남아야 하는가 * 어떤 정보는 요약하거나 삭제해야 하는가 * 사실과 가설을 어떻게 구분할 것인가 * 실패한 행동을 다시 반복하지 않으려면 무엇을 기록해야 하는가 Memory는 Agent에게 인간과 같은 기억을 붙이는 기능이 아니다. 현재 업무의 판단에 필요한 상태를 적절한 형태로 유지하는 기능이다. --- ## 6. Workflow와 Agent를 가르는 것은 결정권의 위치다 Workflow와 Agent는 자주 서로 반대되는 개념처럼 설명된다. Anthropic은 Workflow를 LLM과 Tool이 미리 정해진 코드 경로를 따라 움직이는 시스템으로, Agent를 LLM이 자신의 과정과 Tool 사용을 동적으로 결정하는 시스템으로 구분한다.[5] LangChain의 Harrison Chase는 Agent를 LLM이 애플리케이션의 Control Flow를 결정하는 시스템이라고 설명했다.[6] 두 설명 모두 중요한 지점을 가리킨다. > 다음 단계가 코드에 미리 정해져 있는가, 아니면 실행 중 모델이 현재 상황을 바탕으로 결정하는가. 예를 들어 문서 처리 시스템이 다음과 같이 동작한다고 생각해보자. 1. 문서에서 글자를 추출한다. 2. 정해진 항목을 분류한다. 3. 데이터베이스에 저장한다. 4. 결과 보고서를 만든다. 단계와 순서가 항상 같다면 Workflow가 적합하다. 각 단계에서 LLM을 사용하더라도 전체 진행 경로가 코드에 고정되어 있다면, 모델은 Workflow의 일부를 수행하는 것이다. 반면 문서의 종류에 따라 필요한 정보를 스스로 판단하고, 다른 자료와의 비교 여부를 결정하며, 정보가 부족하면 추가 문서를 요청해야 한다면 일부 결정은 실행 중에 내려져야 한다. 이 경우 모델은 단순히 단계 안의 내용을 생성하는 것을 넘어, 다음 단계 자체를 선택한다. 그러나 현실의 시스템을 Workflow와 Agent 가운데 하나로 완전히 나누기는 어렵다. 대부분은 두 방식을 섞는다. * 사용할 수 있는 Tool은 코드가 제한한다. * Tool의 호출 순서는 모델이 선택한다. * 결제나 삭제와 같은 행동은 인간의 승인을 받는다. * 최대 반복 횟수와 비용은 코드가 제한한다. * 현재 결과가 충분한지는 모델이 일차적으로 판단한다. * 최종 완료 여부는 검증기가 확인한다. 따라서 더 유용한 질문은 "이것이 진짜 Agent인가"가 아니다. > 이 시스템을 구성하는 각각의 결정은 코드, 모델, 인간 중 누구에게 배치되어 있는가. Workflow는 Agent보다 낮은 단계가 아니다. 규칙이 명확하고 예외가 적으며 재현성이 중요한 업무에는 Workflow가 더 적합하다. 반대로 상황마다 필요한 행동이 달라지고, 모든 경로를 미리 작성하기 어려운 업무에서는 모델에 일부 결정권을 위임할 이유가 생긴다. 복잡성을 늘리는 것이 목적이 되어서는 안 된다. 어떤 결정을 미리 고정할 수 있고, 어떤 결정만 실행 중에 내려야 하는지를 구분해야 한다. --- ## 7. Agent성은 하나의 스위치가 아니다 어떤 시스템이 Agent인지 아닌지를 하나의 조건으로 판단하기는 어렵다. LLM이 Tool을 하나 선택했다고 해서 모든 결정을 스스로 내리는 것은 아니다. 반대로 목표를 사용자가 정해주었다고 해서 Agent가 아니라고 볼 수도 없다. Agent성을 하나의 모호한 자율성으로 묶기보다, 여러 결정과 권한으로 나누어 살펴보는 편이 정확하다. ### 목표 설정권 목표는 누가 정하는가. 사용자가 최종 목표를 주고, 시스템이 하위 목표만 만들 수도 있다. 목표와 처리 순서가 모두 코드에 고정될 수도 있다. 시스템이 스스로 하위 목표를 만든다고 해도, 그 목표가 사용자의 의도와 일치하는지 검증할 방법이 필요하다. ### 다음 행동 결정권 다음 행동이 미리 정해져 있는가. 아니면 현재 상태와 이전 결과를 바탕으로 모델이 선택하는가. 선택할 수 있는 행동이 많다는 것과, 올바른 행동을 판단할 수 있다는 것은 다른 문제다. 행동 후보와 선택 기준을 함께 설계해야 한다. ### Tool 선택권 모델이 사용할 Tool과 순서를 직접 정할 수 있는가. Tool의 이름만 선택하는지, 입력값과 실행 범위까지 정하는지도 구분해야 한다. 검색어를 생성하는 것과 서버의 파일을 삭제할 명령을 생성하는 것은 같은 수준의 권한이 아니다. ### 계획 수정권 실행 결과가 예상과 다를 때 기존 계획을 바꿀 수 있는가. 계획을 수정할 수 있더라도 무한히 새로운 방법을 시도하도록 두어서는 안 된다. 비용, 시간, 위험을 기준으로 재시도와 중단 조건을 정해야 한다. ### 외부 행동 권한 시스템이 환경을 어디까지 변경할 수 있는가. * 정보를 읽기만 할 수 있는가 * 임시 파일을 만들 수 있는가 * 실제 저장소의 코드를 수정할 수 있는가 * 메시지나 메일을 전송할 수 있는가 * 결제와 계약을 수행할 수 있는가 * 사용자 계정이나 데이터를 삭제할 수 있는가 판단 능력과 행동 권한은 별도로 봐야 한다. 판단을 잘하는 시스템이라도 되돌리기 어려운 행동에는 제한이 필요하다. 반대로 정해진 Workflow라도 강한 외부 권한을 가지고 있다면 큰 위험을 만들 수 있다. ### 종료와 실패 판단권 작업이 끝났다는 것을 누가 판단하는가. 모델이 최종 답변을 생성했다고 해서 실제 목표가 달성된 것은 아니다. 완료 조건은 가능한 한 외부에서 확인할 수 있어야 한다. * Test가 통과했는가 * 필요한 자료가 모두 수집되었는가 * 변경 사항이 실제 환경에 반영되었는가 * 사용자가 요청한 조건을 모두 충족했는가 * 결과를 뒷받침할 근거가 충분한가 Agent가 완료를 주장하는 것과 완료가 검증되는 것은 다르다. ### 인간 이관 조건 언제 사람에게 넘길 것인가. 모든 예외를 Agent가 스스로 해결하도록 만드는 것이 높은 수준의 Agent는 아니다. 다음과 같은 상황에서는 인간에게 이관하는 것이 더 좋은 판단일 수 있다. * 사용자의 의도가 여러 방식으로 해석될 수 있다. * 필요한 정보에 접근할 권한이 없다. * 결과의 확신이 낮다. * 행동을 되돌리기 어렵다. * 법적·윤리적 판단이 필요하다. * 예상 비용이나 시간이 한도를 넘는다. * 서로 충돌하는 목표가 발견된다. 인간에게 질문하거나 승인을 요청하는 것도 하나의 행동이다. Agent가 모든 일을 혼자 처리해야 한다는 생각에서 벗어나면, 더 안전하고 현실적인 구조를 만들 수 있다. --- ## 8. 더 자율적이라고 더 좋은 Agent는 아니다 Agent를 설명할 때 자율성은 매력적으로 들린다. 사람이 개입하지 않아도 목표를 달성하고, 예외에 대처하며, 오랫동안 작업을 이어가는 시스템을 상상하게 한다. 하지만 자율성은 무조건 높여야 하는 점수가 아니다. 자율성이 커질수록 시스템이 선택할 수 있는 행동이 늘어난다. 미리 예상하지 못한 상황에 대응할 수 있지만, 예상하지 못한 실패도 만들어낼 수 있다. Tool이 많아지면 할 수 있는 일은 늘어나지만, 잘못된 Tool을 선택할 가능성도 생긴다. Loop가 길어지면 스스로 오류를 수정할 기회가 늘어나지만, 잘못된 가설을 반복해서 강화하거나 비용을 계속 사용할 수도 있다. Memory가 늘어나면 더 많은 정보를 참고할 수 있지만, 오래되거나 잘못된 정보에 영향을 받을 수 있다. 외부 행동 권한이 커지면 실제 업무를 끝까지 처리할 수 있지만, 잘못된 판단이 현실의 피해로 이어질 수 있다. 따라서 좋은 Agent의 기준은 가장 많은 권한을 가진 시스템이 아니다. 업무의 특성에 맞는 만큼만 결정권과 행동 권한을 가진 시스템이다. * 규칙이 명확한 판단은 코드에 고정한다. * 상황에 따라 달라지는 비정형 판단은 모델에 맡긴다. * 결과는 가능한 한 별도의 기준으로 검증한다. * 위험하거나 책임이 큰 결정은 인간에게 남긴다. * 비용과 반복 횟수에 한도를 둔다. * 실패와 인간 이관 조건을 미리 설계한다. 중요한 것은 Agent를 사람처럼 보이게 만드는 것이 아니다. 업무에 필요한 판단을 정확히 구현하고, 각 판단을 가장 적합한 위치에 배치하는 것이다. --- ## 마무리: Agent를 만든다는 것은 위임을 설계하는 일이다 Tool과 Loop는 현대 LLM Agent의 중요한 구성 요소다. Tool이 있어야 LLM이 외부 정보를 가져오거나 환경을 변경할 수 있다. Loop가 있어야 행동의 결과를 확인하고 다음 판단을 이어갈 수 있다. 그러나 Tool과 Loop만으로는 시스템이 무엇을 판단하는지 설명할 수 없다. Agent를 이해하려면 그 안에 배치된 결정과 권한을 살펴봐야 한다. * 목표와 성공 기준은 누가 정하는가 * 시스템은 무엇을 관찰할 수 있는가 * 다음 행동은 코드와 모델 중 누가 결정하는가 * 실행 결과가 기존 판단을 어떻게 바꾸는가 * 사용할 Tool과 순서는 누가 선택하는가 * 외부 환경을 어디까지 변경할 수 있는가 * 완료와 실패는 누가 판단하는가 * 언제 중단하거나 인간에게 넘기는가 이 질문에 답할 수 있다면 Agent라는 이름을 붙였는지는 더 이상 가장 중요한 문제가 아니다. 반대로 이 질문에 답하지 못한다면, Tool과 Loop가 아무리 복잡해도 그 시스템이 실제로 무엇을 위임받았는지 설명하기 어렵다. 자동화하려는 업무가 있다면 먼저 사람의 행동을 관찰해야 한다. 그러나 사람이 누르는 버튼과 화면의 이동 순서만 보아서는 안 된다. 어떤 정보를 중요하게 보고, 어떤 가설을 세우며, 무엇을 근거로 판단을 수정하는지까지 살펴봐야 한다. 사람이 무의식적으로 수행하는 판단도 가능한 범위에서 밖으로 꺼내야 한다. 그중 기계에 불필요한 인간의 제약은 제거하고, 명확한 규칙은 코드로 옮기며, 상황에 따라 달라지는 판단만 모델에 위임해야 한다. > 좋은 Agent는 가장 복잡한 Loop를 가진 시스템이 아니다. 자동화하려는 업무의 판단 구조를 정확히 이해하고, 필요한 결정과 행동 권한을 적절한 범위까지 위임한 시스템이다. 결국 Agent를 만든다는 것은 Tool을 연결하는 일이 아니다. 업무에서 일어나는 판단을 발견하고, 그 판단을 코드와 모델과 인간 사이에 어떻게 나눌지 설계하는 일이다. ## 끝 사실 중요한거는 그렇게 크지 않다. 기본적인 기초 형태의 Agent, 또는 자동화를 만들고 싶다면, 기본적으로 우리가 하는 행동, 우리가 인식하는 모든 데이터들이 각자 무슨 의미를 가지고 있으며, 어떤 데이터가 존재하는지 초반에 노가다일 수 있지만 이러한 모든 step들을 찾는 것이 중요하다. ```