Cursor, Claude Code, Codex를 사용하여 코드를 작성하고, 코드를 검색하고, 파일을 편집하고, 테스트가 통과할 때까지 반복 실행하는 모습을 지켜본 적이 있다면 이미 AI 에이전트를 사용해 본 것이다. AI 에이전트들은 다영한 형태를 갖고 있지만, 공통적인 특징이 있다. 질문하면 답변하는 대화 방식이 아니라 자체적으로 실행 단계를 계획하고, 각 작업에 필요한 도구를 호출하여 결과가 나오게 만들고, 그 과정속에 전략을 조정한다. AI 에이전트는 컴퓨터와 상호 작용하는 새로운 방식이다.
현대 에이전트 = LLM + Context + 도구¶
현대 에이전트 시스템의 핵심은 공식 하나로 표현될 수 있다.
에이전트 = LLM + Context + 도구LLM은 에이전트의 추론 엔진이다. - 단순히 모델 매개변수 집합이 아니라, 의도 파악, 추론, 계획 수립, 판단을 담당하는 에이전트의 핵심 의사결정 시스템이다. LLM의 능력은 사전 학습을 통해 습득한 세계 지식과 언어 능력, 그리고 사후 학습을 통해 인코딩된 의사결정 전략에서 비롯된다.
컨텍스트는 에이전트가 활용할 수 있는 정보의 집합이다. - 단순히 모델에 입력되는 텍스트 뿐만 아니라, 각 의사 결정 시점에서 에이전트가 사용할 수 있는 모든 정보, 예를 들어 환경, 사용자 기억, 도메인 지식, 에이전트 자체의 상태, 그리고 작업 진행 상황까지 포함한다. 마치 사람이 의사 결정을 내릴 때 상황을 파악하고, 관련 경험을 떠올리고, 참고 자료를 살펴보는 것처럼, 에이전트의 컨텍스트 창에는 그 순간에 사용할 수 있는 정보가 담겨 있다.
도구는 에이전트의 작업 인터페이스이다. - 단순하게 호출 가능한 API 함수 몇 개가 아니라, 미리 정의된 도구 호출부터 필요에 따라 불러오는 스킬, 즉석에서 새로운 기능을 생성하는 코드 작성, 하위 에이전트에게 작업 위임, 외부 이벤트에 응답하는 것까지 에이전트가 수행할 수 있는 모든 방식을 포함한다.
에이전트는 추론 엔진 + 작업 컨텍스트 + 액션 인터페이스의 조합이다. 모델은 추론하고 결정을 내리고, 컨텍스트는 이런 결정에 필요한 정보들을 제공하고, 도구는 결정이 외부 세계에 영향을 미치는 인터페이스를 제공한다.
| 직관 | 에이전트 구성요소 | 역할 |
|---|---|---|
| 추론 엔진 | LLM | 현재 정보를 바탕으로 가능한 모든 선택지 중에서 가장 적절한 행동을 선택하며 "다음에 무엇을 해야 할지"를 결정하는 의사결정 논리 |
| 업무 환경 | Context | 에이전트가 이용할 수 있는 모든 정보, 즉 에이전트가 관찰하고, 읽고, 기억할 수 있는 정보와 접근할 수 있는 시스템에 대한 정보 |
| 액션 인터페이스 | 도구 | 에이전트가 수행할 수 있는 모든 작업, 즉, 메시지 전송부터 코드 실행, 인터페이스 제어에 이르기까지 사용 가능한 모든 수단을 설명 |
다음은 다양한 유형의 에이전트가 위에서 언급한 세 가지와 어떻게 다른지 비교해본다.
| 에이전트 제품 | 업무 환경 | 액션 인터페이스 | 전략 |
|---|---|---|---|
| 코딩 에이전트 | 요구사항 문서, 코드 리포, 터미널 환경 | 개방형 과제(내부 추론, 코드 검색, 읽기/쓰기, 명령어 실행 등) | 점진적 개발: 요구사항 이해 -> 관련 코드 검색 -> 코드 수정 -> 테스트 및 검증 -> 디버깅 및 수정 |
| 검색 에이전트 | 웹 자료, 학술 데이터베이스, 로컬 파일 | 개방형 문제(내부 추론, 검색 쿼리, 웹 읽기, 요약 생성) | 반복적 심화: 기존 정보를 바탕으로 검색 방향을 조정하고, 점진적으로 완전한 보고서를 종합한다. |
| 컴퓨터 제어 에이전트 | 컴퓨터 화면, 브라우저 페이지, 파일 시스템 | 개방형(내부 추론, 입력, 클릭, 스크롤, 스크린샷, 코드 실행 등) | 시각적 인지 + 조작: 화면 관찰 -> 목표 요소 식별 -> 동작 수행 -> 결과 확인 |
| 전화 도우미 상담원 | 휴대폰 화면, 설치된 앱 | 개방형(내부 추론, 클릭, 스와이프, 타이핑, 앱 실행 등) | 의도 파악 + 앱 제어: 사용자 요구사항 파악 -> 대상 앱 찾기 -> 작업 수행 -> 완료 확인 |
| 개인 작업 에이전트 | 사용자 계정 정보, 과거 청구서, 서비스 제공업체 지식 기반 | 개방형 과제(내부 추론, 전화 걸기, 이메일 보내기, 양식 작성, 사용자 확인) | 단계별 작업 실행: 정보 수집 -> 협상 전략 수립 -> 서비스 제공업체 연락 -> 협상 -> 결과보고 |
이런 시스템들은 세 가지 공통된 특징을 가지고 있다.
고정된 세트에서 선택하는 것이 아니라 임의의 자연어와 코드를 생성할 수 있는 개방적인 실행 공간이다.
행동하기 전에 계획을 세우는 내부 추론 기능이다.
피드백에 따라 전략을 조정하는 지속적인 상호 작용 기능이다.
이런 기능들은 추론 엔진, 작업 컨텍스트 그리고 액션 인터페이스 즉, LLM, Context, 도구의 상호 작용에서 비롯된다.
도구: 에이전트의 액션 인터페이스¶
도구는 에이전트와 외부 세계를 연결하는 다리 역할을 한다. 도구를 통해 에이전트는 수동적인 관찰자에서 검색, 파일 작성, 코드 실행, API 호출, 메시지 전송, 인터페이스 조작 등을 수행할 수 있느 능동적인 시스템을 변모한다. 도구가 없다면 에이전트는 텍스트 생성에만 국한되게 되고, 도구를 사용하면 외부 시스템에 대한 조작이 가능해진다.
에이전트가 세상과 상호작용하는 방향에 따라 5가지 유형으로 도구를 분류할 수 있다. 각 유형의 대표적인 시나리오를 살펴보자.
인지 도구: 에이전트가 정보에 접근할 수 있게 해준다. 검색 엔진은 실시간 웹 데이터를 제공하고, 파일 시스템은 로컬 문서를 읽으며, API와 데이터베이스는 외부 서비스 및 기업 핵심 데이터에 연결된다.
실행 도구: 에이전트가 외부 시스템에서 작업을 수행할 수 있게 해준다. 코드 실행, 파일 작업, 시스템 명령 및 외부 API 호출을 통해 구체적인 행동으로 옮길 수 있다.
협업 도구: 에이전트가 다른 에이전트와 작업을 분담할 수 있다. 예를 들어, 전문적인 작업을 서브 에이전트에게 위임하거나, 주요 의사 결정 지점에서 사람의 확인을 요청하거나, 다중 에이전트 시스템에서 작업을 조정할 수 있다.
이벤트 트리거 도구: 에이전트가 직접 호출하는 것이 아니라, 외부 입력으로 전달되어 에이전트가 작업을 시작하도록 트리거하는 역할을 한다. 예를 들어 새로운 이메일이 수신되거나, 예약된 시간이 도래하거나, 다른 시스템에서 웹훅 콜백이 발생하는 경우, 이러한 이벤트가 에이전트를 활성화하고 추론 및 조치를 시작하게 한다. 에이전트를 도구를 직접 호출하지는 않지만, 외부 세계와 상호 작용하는 채널 역할을 하므로 포괄적인 도구 시스템에 포함된다.
사용자 커뮤니케이션 도구: 에이전트와 사용자가 소통하는 채널이다. 실행 도구가 외부 세계를 변화시키는 반면, 커뮤니케이션 도구는 정보를 전달한다. 즉, 문자 메시지, 음성 통화, 이메일 등을 통해 에이전트의 진행 상황이나 사전에 점검할 메시지를 전달하는 역할을 한다.
그외 함수 호출이 있는데, 이것은 LLM 에이전트의 핵심 기능이다. 이 기능을 통해 모델은 구조화된 방식으로 외부 도구를 호출할 수 있으며, LLM을 단순한 텍스트 생성기에서 외부 인터페이스를 통해 작동할 수 있는 지능형 시스템으로 변화시킨다.
날씨를 조회하기 위한 API 수준의 4단계 프로세스를 간략하게 표현하면 아래와 같다.
1단계: 도구 정의
모델이 사용할 수 있는 외부 도구(함수)의 이름과 입력 매개변수 형식을 정의하여 전달한다.
tools: [{
name:"get_weather",
parameters: {
city:"string"
}
}]
2단계: 도구 호출 결정
사용자의 요청을 분석 한 후, 필요한 도구를 실행하기 위해 함수 이름과 인수를 지정하여 요청.
assistant: {
tool_calls" [{
function: "get_weather",
arguments: {city:"Seoul"}
}]
}
3단계: 실행 결과를 대화에 추가
시스템이 실제로 해당 외부 API나 함수를 실행하고, 그 결과값을 다시 AI의 대화 문맥(Context)에 전달.
tool: {
tool_call_id:"call_1",
content:'{"temp":28, "sky":"clear"}'
}
4단계: 최종 응답 생성
전달받은 실행 결과를 바탕으로 사용자가 이해하기 쉬운 최종 답변을 작성하여 응답.
assistant: {
content: "오늘 서울 날씨는 28°C."
}개발자는 도구를 정의하고 호출을 실행하기만 하면 된다. 모델 자체가 호출 여부, 호출할 도구, 전달할 인수를 결정한다.
에이전트용 도구를 설계할 때는 범용성을 유지하고 LLM에 유연성을 제공해야 한다. 예를 들어 이런것이다. 작업 노트를 기록하는 도구 대신에 파일 읽기/쓰기 도구를 제공하고, 숫자 계산을 위한 전용 계산기 대신에 파이썬 코드 인터프리터를 제공한다. 범용 도구를 통해 에이전트는 기본적인 기능을 조합하여 문제를 창의적으로 해결할 수 있다.
LLM: 에이전트의 추론 엔진¶
대규모 언어 모델(LLM)은 에이전트의 의사결정의 핵심이다. 사용자다 요청하면, 사용자의 실제 의도를 추론해야 한다(사용자가 말하는 내용과 실제로 원하는 내용이 다른 경우가 많기 때문). 그런 다음 모호하거나 복잡한 작업을 실행 가능한 단계로 분해한다. 실행 과정 전반에 걸쳐 다음에 무엇을 할지, 도구를 호출할지 여부, 어떤 도구를 사용할지, 그리고 어떤 인수를 사용할지 등 지속적인 의사결정을 내린다. 이러한 이해-계획-실행 능력은 사전 학습을 통해 축적된 지식에서 비롯되며, 워크플로와 자율 에이전트 모두가 의존하는 기반이 된다.
LLM 에이전트의 독특한 능력 중 하나는 내부 추론 능력이다. 에이전트는 행동하기 전에 계획을 세우고 작업을 추론할 수 있다. 이는 외부 환경을 변경하지 않으면서도 이후의 행동을 현저하게 개선한다. 이러한 능력은 사전 학습(방대한 양의 인터넷 텍스트를 활용한 초기 학습으로, 모델은 이를 통해 언어 패턴과 세상에 대한 지식을 학습합니다)에서 비롯된다. 모델은 수학적 법칙, 인과 관계, 문제 분해 전략 등 인간 지식에 내재된 추론 패턴을 활용한다. 따라서 에이전트의 추론은 맹목적인 시행착오가 아니라 구조화된 지식 체계를 기반으로 한다.
이러한 구조화된 추론 덕분에 LLM 에이전트는 사전 예시 없이도 완전히 새로운 작업을 처리할 수 있다. 제로샷과 퓨샷이라는 두 가지 개념이 이를 잘 보여준다. 직접적인 예로 제로샷 일반화가 있다. 에이전트는 이전에 접해본 적 없는 작업에 직면했을 때, 예시 없이도 이미 알고 있는 지식을 재조합하여 작업을 처리한다. 예를 들어, 에이전트가 양자 물리학에 관한 시를 쓰도록 명시적으로 학습한 적이 없더라도, 언어와 물리학에 대한 기존 지식을 바탕으로 그럴듯한 시를 만들어낼 수 있다.
몇 가지 예시만 있으면 LLM 에이전트는 소수 예시 학습(Few-shot Adaptation )도 수행할 수 있다. 즉, 프롬프트에서 두세 번의 예시만으로도 새로운 작업 패턴을 학습할 수 있다. 예를 들어, “사용자 댓글 -> 감정 레이블” 예시를 몇 개만 보여주면 새로운 댓글의 감정을 분류할 수 있다. 제로샷(zero-shot)은 예시 없이 작업을 해결하는 것을 의미하고, 소수 예시 학습은 적은 수의 예시를 통해 패턴을 학습하는 것을 의미한다.
모델을 에이전트로 활용하기: 모델 자체가 제품이 될 때¶
‘모델을 에이전트로 활용하는’ 패러다임은 AI 에이전트 개발의 최신 방향이다. 고급 모델은 사후 학습(특히 강화 학습)을 통해 도구 호출 기능을 기본적으로 내장한다. 언제, 어떤 도구를, 어떤 인수로 호출할지 등 모든 것을 모델이 결정하므로 수동 조정이 필요하지 않다. 그렇다고 프레임워크 계층의 중요성이 떨어지는 것은 아니다. 오히려 모델이 강력할수록 주변 하네스의 중요성이 더욱 커진다. 에이전트 맥락에서 하네스는 모델의 기능을 안정적인 작업 실행으로 전환하는 엔지니어링 인프라이다. 여기에는 컨텍스트 관리, 도구 인터페이스, 안전 제약 조건, 검증 및 수정 메커니즘이 포함된다.
모델의 의사결정 권한이 클수록 잘못된 결정의 영향이 커지므로, 신뢰성을 유지하기 위해서는 더욱 세밀한 제약 조건, 검증 및 수정이 필요하다. 모델 제공업체의 진정한 이점은 "프레임워크를 간소화하는 것"이
하지만 모델이 계속해서 발전한다면, 오늘날의 하네스는 결국 모델에 흡수될까? 연구자들은 특정 영역에 대한 이해를 시스템에 반복적으로 인코딩하여 단기적인 성과를 거두었지만, 결국 컴퓨팅 능력과 데이터에 따라 확장되는 일반적인 방법, 즉 검색과 학습에 뒤처지게 되었다. 이러한 관점에서 볼 때, 하네스에 내재된 제약 조건, 검증, 수정 사항 중 얼마나 많은 부분이 모델이 내재화해야 할 "인간의 사전 지식"일까? 방향은 지지하되, 속도에 대해서는 현실적인 태도를 유지해야 한다. 방향성 측면에서, 모델이 하네스의 일부를 계속해서 흡수할 것이라는 점은 의심의 여지가 없다. 과거에는 외부 오케스트레이션에 의존했던 도구 호출과 장기 계획 수립이 이제는 모델의 기본 기능이 되었다. 하지만 실제로는 이러한 흡수 속도가 직관보다 훨씬 느리다. 학습에는 몇 달이 걸리며, 어떤 모델도 실제 기업의 모든 제약 조건과 선호도를 단 한 번의 학습으로 내재화할 수는 없다. 모델의 역량 한계는 바로 하네스가 가치를 창출하는 지점이다. 따라서 하네스 엔지니어링은 시간 척도에 따른 실천이다. 모델이 아직 안정적으로 수행할 수 없는 부분은 하네스가 우선적으로 보완하고, 모델이 새로운 계층을 내재화할 때마다 하네스는 해당 계층을 제거하고 다음 역량 영역을 지원한다.
에이전트 학습 매커니즘: 상황 적응에서 지속적인 업데이트까지¶
앞서 살펴본 논의에서는 강화 학습이 도구 사용 정책을 모델의 기본 기능으로 내재화하는 방법을 보여주었다. 하지만 에이전트의 행동 변화는 학습 중에만 발생하는 것은 아니다. 업데이트가 발생하는 위치와 지속 시간에 따라 이러한 변화는 세 가지 상호 보완적인 경로로 이해할 수 있다. 즉, 작업 내 맥락적 적응, 외부 아티팩트에 대한 작업 간 업데이트, 그리고 학습 주기 중 매개변수 업데이트이다.

컨텍스트 어댑테이션(Context Adaptation)은 모델의 가중치를 직접 수정하지 않고, 지시사항, 프롬프트, 상황 정보 등을 동적으로 조절하여 모델에 적응시키는 방법이다. 이 방법은 현재 작업 내에서 이뤄진다. 상태 및 검색 결과가 컨텍스트에 입력되면 모델은 즉시 동작을 조정할 수 있지만, 세션의 영구 상태를 변경하지는 않는다. 컨텍스트 어댑테이션의 장점은 속도와 낮은 비용이며, 컨텍스트 윈도우와 정보 구성 방식의 제약으로 한계는 존재한다.
변경 사항이 여러 작업에 걸쳐 발생할수록 시스템은 외부 아티책트를 업데이트 할 수 있다. 사실과 경험은 지식 문서로 정리할 수 있고, 언어로 표현 가능한 전략은 프롬프트 또는 스킬로 작성할 수 있으며, 결정론적 절차와 제약 조건은 프로그램과 하네스에 인코딩할 수 있다. 이런 아티팩트는 감사 및 수정이 가능하고 이런 작업을 하려면 에이전트는 실행 시 컨텍스트 또는 인터페이스를 통해 아티팩트에 접근해야 한다.
컨텍스트: 에이전트의 작업 환경¶
컨텍스트는 에이전트가 의사 결정 시점에서 사용할 수 있는 정보의 집합이다. 사람도 의사 결정을 내릴 때 지침, 설명서, 최신 데이터와 같은 자료가 필요한 것처럼, 에이전트의 컨텍스트 윈도우는 에이전트가 사용할 수 있는 정보를 담는 공간이다. 컨텍스트는 아래처럼 구성된다.
시스템 프롬프트: 사용자가 대화 중에 입력하는 프롬프트가 아니라, 시스템 프롬프트를 의미한다. 시스템 프롬프트는 개발자가 작성하며 대화가 끝날 때까지 유지된다. 이는 에이전트의 정체성, 권한 및 행동 규칙을 정의하는 '업무 설명’이다. 시스템 프롬프트를 신중하게 작성함으로써 에이전트의 작동 방식을 결정할 수 있다. 그리고 시스템 프롬프트에는 세션 간에 유지되는 사용자 메모리와 동적으로 주입되는 환경 상태가 포함된다.
Execution Tool: 에이전트가 사용할 수 있는 도구의 이름,기능 설명 및 매개변수 형식을 정의한다. 이 정의가 없으면 에이전트는 어떤 도구도 인식하지 못한다. Execution Tool은 시스템 프롬프트와 함께 대화 전체에서 변경되지 않는 정적 접두사를 구성한다.
사용자 메시지: 사용자의 입력을 의미한다. 사용자 메시지에는 RAG(Retrieval-Augmented Generation)를 통해 동적으로 검색된 외부 지식이 포함될 수 있다. 이는 훈련 데이터 범위를 넘어서는 정보나 도메인 지식을 포괄한다.
어시스턴트 메시지: 모델이 미리 생성한 응답이다. reasoning(일관성과 의사 결정의 가능성을 유지하는 내부 사고 과정), content(사용자에 응답할 콘텐츠)로 구성될 수 있다. 예를 들어서 에이전트가 도구를 호출하기로 결정한 경우에는 일반적으로 tool_calls만 표시되고, 최종 답변을 제공할 때도 이것만 표시된다.
Tool Calling: 에이전트 프레임워크가 도구를 실행한 후 반환되는 출력이다. 이 결과는 에이전트의 다음 추론 단계에 대한 기반이 되며, 에이전트가 실수를 반복하는 대신 결과로부터 학습할 수 있도록 해준다.
시스템 프롬프트 + Execution Tool은 정접 접두사를 구성하고, 나머지 3개 항목은 모든 상호 작용마다 증가하는 동적 메시지 기록을 구성한다. 그리고 이것들이 합쳐저서 LLM 추론의 컨텍스트를 구성하게 된다.