LLM은 행동을 직접 실행하지 않습니다. 모델이 만드는 것은 “이 도구를 이런 인자로 호출하자”는 다음 출력이고, 실제 파일을 읽거나 메일을 보내는 일은 애플리케이션과 도구가 수행합니다. 에이전트는 이 제안과 실행, 관측, 다음 결정을 하나의 제어 루프로 연결한 시스템입니다.
편집자 노트 · B2B 도입 관점 — 에이전트 도입은 모델을 고르는 일보다 권한·실행·기록을 설계하는 일에 가깝습니다. 이 편은 제안과 실행을 나누고 그 사이에 무엇이 필요한지 짚습니다. 실제 업무를 맡기기 전에 무엇을 정해두어야 하는지 확인하시는 자리에서 쓰실 수 있습니다.
답을 만드는 것과 환경을 바꾸는 것은 다른 일입니다
“지난달 매출을 정리해줘”라는 요청에 LLM은 분석 순서와 표 형식을 제안할 수 있습니다. 그러나 로컬 폴더에서 정확한 파일을 찾고, 스프레드시트를 읽고, 합계를 계산하고, 결과 파일을 저장하려면 모델 밖의 기능이 필요합니다.
대화창에서는 이 과정이 한 문장으로 이어져 보입니다. 내부에서는 자연어 생성과 파일 접근, 코드 실행, 권한 확인이 서로 다른 구성 요소에서 일어납니다. 어느 한쪽이 성공했다고 전체 업무가 끝난 것도 아닙니다.
특히 모델이 “파일을 저장했습니다”라고 문장을 만들 수 있다는 점과 실제 저장 이벤트가 발생했다는 점을 구분해야 합니다. 완료 여부는 모델의 보고가 아니라 파일 존재, API 응답, 데이터베이스 상태 같은 환경의 관측으로 확인해야 합니다.
에이전트는 모델에 실행 루프를 더한 시스템입니다
에이전트라는 용어에 하나의 고정된 구현만 있는 것은 아닙니다. 이 글에서는 업무 목표를 받고, 필요한 행동을 고르고, 외부 환경의 결과를 관측하며, 완료할 때까지 상태를 갱신하는 시스템을 에이전트라고 부르겠습니다.
목표와 현재 상태
→ LLM이 다음 행동 또는 답을 제안
→ 정책과 인자 검증
→ 도구 실행
→ 성공·실패와 결과를 관측
→ 상태와 문맥 갱신
→ 완료·중단할 때까지 반복
여기서 LLM은 중요한 판단 구성 요소이지만 전체 시스템과 같지는 않습니다. 도구 목록과 설명, 현재 상태, 반복 상한, 권한 정책, 결과 검증기가 함께 있어야 합니다. 자율성은 모델 파일 하나의 속성보다 이 구성 요소들을 어떻게 연결했는가에 가깝습니다.
Tool call은 실행 명령이 아니라 구조화된 제안입니다
모델은 보통 도구 이름과 인자를 정해진 형식으로 출력합니다. 예를 들어 read_file과 파일 경로를 JSON으로 만들 수 있습니다. 애플리케이션은 그 출력을 파싱하고 스키마에 맞는지, 해당 경로를 읽을 권한이 있는지 확인한 뒤 실제 함수를 호출합니다.
모델 출력 { "tool": "read_file", "path": "sales.xlsx" }
애플리케이션 스키마·권한·경로 검사
도구 파일 읽기 시도
관측 성공 데이터 또는 구체적인 오류
모델의 다음 입력 관측 결과를 포함한 새 문맥
Toolformer 연구는 모델이 계산기, 검색, 달력 같은 API를 언제 어떤 인자로 호출하고 결과를 다음 토큰 예측에 어떻게 반영할지 학습하는 방식을 보였습니다. 여기서도 도구의 계산 자체를 LLM이 대신한 것은 아닙니다. 모델은 호출 시점과 사용법을 생성하고, 외부 도구가 정확한 기능을 제공합니다.
이 경계를 지키면 도구 결과를 신뢰할 기준도 정할 수 있습니다. 모델이 올바른 형식으로 호출했는지와 도구가 실제로 성공했는지를 따로 기록합니다. 빈 결과, 일시 오류, 권한 거부, 잘못된 인자를 모두 같은 “실패”로 묶지 않아야 다음 행동을 제대로 고를 수 있습니다.
관측이 돌아와야 다음 판단이 달라집니다
에이전트가 단순한 작업 계획서와 다른 점은 실행 결과를 다시 본다는 데 있습니다. 파일이 없으면 다른 경로를 찾고, 검색 결과가 부족하면 질의를 바꾸며, 테스트가 실패하면 오류 메시지를 바탕으로 코드를 수정합니다.
ReAct 연구는 언어적 추론과 환경 행동을 번갈아 생성해 계획을 갱신하는 방식을 평가했습니다. 질문 답변에서는 위키피디아 API로 정보를 얻고, 상호작용 환경에서는 행동 결과를 다음 판단에 사용했습니다. 생각만 이어가는 것보다 외부 관측이 오류 수정의 근거를 제공한다는 구조입니다.
관측 결과가 부실하면 루프도 부실해집니다. 도구가 실패했는데 빈 문자열만 반환하면 모델은 정보가 없는 이유를 알 수 없습니다. 저장에 실패했는데 성공처럼 전달하면 이후 단계는 존재하지 않는 파일을 전제로 진행합니다.
좋은 도구 계약은 결과의 의미를 나눕니다.
성공 + 사용할 결과 있음
성공 + 결과 없음
일시 오류 + 같은 요청 재시도 가능
입력 오류 + 인자를 바꿔야 함
권한 거부 + 현재 범위에서 실행 불가
모델은 이 관측을 보고 다음 행동을 제안할 수 있습니다. 어떤 오류를 재시도하고 무엇을 사람에게 넘길지는 실행 정책이 결정합니다.
반복하려면 종료를 소유한 구성 요소가 필요합니다
도구 호출을 한 번 연결하는 것보다 어려운 일은 언제 멈출지 정하는 것입니다. 모델이 계속 검색하면 언젠가 더 좋은 자료가 나올 수 있고, 코드를 다시 고치면 다음 테스트는 통과할 수 있습니다. 가능성이 남아 있다는 이유만으로 반복을 계속할 수는 없습니다.
종료 조건에는 목표 달성, 반복·시간·비용 상한, 같은 오류의 반복, 권한 부족, 사람 판단 필요가 포함됩니다. 모델에게 “적당히 끝내라”고 지시하는 것만으로는 실행 비용과 부작용을 보장하기 어렵습니다. 카운터와 상태, 정책 검사를 코드에서 관리해야 합니다.
완료도 문장이 아니라 검증 가능한 상태로 정의합니다. 보고서 파일이 지정한 경로에 있고 필수 시트가 존재하는지, 이메일 초안에 수신자와 첨부가 맞는지, 코드가 테스트를 통과했는지를 확인합니다. 검증을 통과하지 못한 결과는 자연스러운 완료 문구가 있어도 완료가 아닙니다.
권한은 모델의 판단력과 별도로 제한합니다
읽기 도구만 가진 에이전트의 잘못된 판단은 대체로 잘못된 답에 머뭅니다. 삭제와 발송, 결제 권한을 가진 에이전트의 같은 판단은 외부 상태를 바꿉니다. 모델 품질이 같아도 연결한 권한에 따라 실패의 영향이 달라집니다.
OWASP 2026 LLM Top 10의 Excessive Agency 안내는 필요한 범위를 넘는 기능, 권한, 자율성을 주요 원인으로 구분합니다. 필요한 최소 도구만 제공하고, 도구 기능을 세분화하며, 영향이 큰 행동은 독립된 승인과 검증을 두도록 권고합니다.
업무 행동은 되돌릴 수 있는 정도와 영향 범위로 나눌 수 있습니다.
| 행동 | 기본 처리 방식 |
|---|---|
| 문서 검색·읽기 | 허용 범위 안에서 자동 실행, 접근 기록 |
| 임시 파일 생성·초안 작성 | 격리된 작업 공간에서 실행, 결과 검증 |
| 기존 파일 수정 | 변경 전 백업·차이 확인, 대상 제한 |
| 메일 발송·외부 게시 | 내용과 수신 대상을 사람에게 확인 |
| 삭제·결제·권한 변경 | 명시적 승인, 최소 권한, 감사 기록 |
사람 승인은 모든 단계에 넣을 필요가 없습니다. 되돌리기 어렵고 외부 영향이 큰 경계에 두면 자동화의 흐름을 유지하면서 중요한 결정을 확인할 수 있습니다. 승인 화면에는 “진행할까요?”만 보여주기보다 대상, 변경 내용, 예상 영향을 함께 보여줘야 합니다.
하나의 업무를 구성 요소별로 다시 펼쳐봅니다
월간 매출 보고서를 만드는 에이전트를 예로 들어보겠습니다.
- 실행기는 허용된 폴더에서 대상 파일 목록을 읽습니다.
- LLM은 파일명과 요청을 보고 필요한 파일과 분석 순서를 제안합니다.
- 스프레드시트 도구가 데이터를 읽고 계산 코드는 합계를 구합니다.
- LLM은 계산 결과와 전월 자료를 바탕으로 설명 초안을 만듭니다.
- 검증기는 합계와 필수 항목, 출력 파일 형식을 확인합니다.
- 외부 발송 전에는 사람이 수신자와 첨부 파일을 승인합니다.
이 흐름에서 문장 생성 능력만으로 대체하기 어려운 부분이 드러납니다. 파일 시스템은 실제 대상을 제공하고, 계산기는 숫자를 확정하고, 검증기는 완료 조건을 판정합니다. LLM은 모호한 요청을 구조화하고 각 결과를 다음 행동으로 연결하는 데 강점을 씁니다.
문제가 생겼을 때도 책임을 나눠 볼 수 있습니다.
| 현상 | 먼저 확인할 곳 |
|---|---|
| 잘못된 파일을 골랐다 | 도구 설명, 파일 목록, 모델의 선택 |
| 합계가 틀렸다 | 입력 범위, 계산 코드, 단위 변환 |
| 같은 호출을 반복한다 | 도구 결과 계약, 상태 갱신, 반복 상한 |
| 하지 않은 일을 완료했다고 한다 | 실제 이벤트와 완료 검증 |
| 허용하지 않은 파일에 접근한다 | 경로 검증, 권한 정책, 실행 격리 |
에이전트의 실패를 모두 모델 문제라고 부르면 고칠 지점을 잃습니다. 반대로 모델이 더 좋아져도 실행 계약과 권한이 비어 있으면 같은 종류의 실패가 남습니다. 구성 요소별 기록이 필요한 이유입니다.
다섯 편의 기초는 역할의 경계를 그리는 일이었습니다
지금까지 다음 토큰 예측, 파라미터와 학습, 컨텍스트와 기억, 추론과 평가, 도구를 쓰는 에이전트를 차례로 살펴봤습니다. 각 주제는 다른 것처럼 보이지만 한 가지 질문으로 이어집니다. 모델이 만드는 것과 외부 시스템이 제공하거나 확인하는 것은 각각 무엇인가입니다.
LLM은 입력 문맥에서 다음 출력을 생성합니다. 파라미터는 학습된 패턴을, 컨텍스트는 현재 정보를 제공합니다. 검색과 도구는 외부 세계를 연결하고, 실행기와 검증기는 권한과 상태, 완료를 관리합니다.
다음 편부터는 이 기준을 실제 모델에 적용합니다. 파라미터 수와 구조, 컨텍스트 길이, 추론 방식, 도구 사용 지원을 각각 분리해 읽고, 발표된 벤치마크가 어떤 조건에서 나온 숫자인지 함께 살펴보겠습니다.
도입을 검토한다면
에이전트를 실제 업무에 붙이실 때 먼저 정해두어야 할 것은 모델이 아니라 경계입니다.
첫째, 권한을 사람 기준으로 부여합니다. 에이전트가 접근할 수 있는 시스템과 데이터는 그 일을 맡은 담당자의 권한을 넘지 않아야 합니다. 편의를 위해 넓은 권한으로 시작하면 사고가 났을 때 범위를 되짚을 수 없습니다.
둘째, 종료 조건과 되돌리기를 먼저 설계합니다. 몇 번까지 재시도할지, 어떤 상태에서 사람에게 넘길지, 실행한 일을 어떻게 취소할지를 정해두지 않으면 자동화의 이득보다 수습 비용이 큽니다.
셋째, 실행 기록이 곧 감사 자료입니다. 누가 어떤 에이전트로 어떤 도구를 호출해 무엇을 바꿨는지가 남아야 합니다. 규제 산업이라면 이 기록의 보존 방식이 도입 가능 여부를 가릅니다. 파일럿은 되돌릴 수 있는 업무부터 시작하시길 권합니다.
시리즈 전체 보기 → LLM 인사이드