AI 에이전트는 어떻게 판단하고 행동할까: LLM, 도구, 관찰, 반복 구조

게시 2026/07/27

By woolam

조회 47 분읽는 시간

AI 에이전트라는 말을 자주 듣지만, 정확히 무엇을 가리키는지는 선뜻 설명하기 어려웠다. 처음에는 ChatGPT보다 조금 더 자율적이고 성능이 좋은 AI 모델 정도로 생각했다. 질문에 답하는 데서 그치지 않고 알아서 여러 일을 처리하니, 모델 자체에 특별한 능력이 더해진 것처럼 보였다.

그런데 구조를 하나씩 살펴보니 관점이 달라졌다. AI 에이전트를 이해하려면 모델의 성능만 보는 것이 아니라, 모델이 어떤 규칙 아래 어떤 도구를 사용하고 그 결과를 어떻게 다음 판단에 반영하는지를 함께 봐야 했다.

이번 글에서는 직접 에이전트를 구현하거나 운영한 경험을 다루기보다, 백엔드 개발자의 관점에서 AI 에이전트의 구성 요소와 실행 흐름을 학습한 내용을 정리한다.

AI 에이전트는 특별한 하나의 AI 모델이 아니다. LLM이 도구를 사용하고 실행 결과를 관찰하면서 목표 달성까지 판단과 행동을 반복하도록 구성한 시스템이다.

1. 일반 챗봇과 AI 에이전트는 무엇이 다를까

LLM은 기본적으로 입력된 문맥을 바탕으로 다음에 올 텍스트를 생성한다. 질문을 설명하고, 코드를 제안하고, 문서를 요약하는 일에 강하다. 하지만 텍스트를 생성하는 능력만으로는 실제 환경의 파일을 읽거나 테스트를 실행할 수 없다.

예를 들어 다음과 같이 요청했다고 해보자.

프로젝트의 테스트를 실행하고,
실패 원인을 분석한 뒤,
코드를 수정하고 다시 검증해줘.

일반 챗봇은 테스트 실행 방법, 로그를 확인할 위치, 예상되는 수정 방법을 설명할 수 있다. 반면 코드 에이전트는 권한과 도구가 주어졌다면 다음 작업을 실제로 수행할 수 있다.

프로젝트 파일과 빌드 설정을 조회한다.
테스트 명령을 실행한다.
실패 로그를 읽고 원인을 좁힌다.
관련 코드를 수정한다.
테스트를 다시 실행한다.
성공 여부와 변경 내용을 보고한다.

차이는 답변의 길이나 모델의 지능보다 실행 환경과 반복 구조에 있다. 챗봇의 기본 산출물은 대화 속 답변이다. 에이전트의 산출물은 수정된 파일, 실행된 테스트, 생성된 이슈처럼 외부 환경에 남는 작업 결과가 될 수 있다.

물론 에이전트도 사용자에게 결과를 설명한다. 중요한 점은 설명하기 전에 필요한 행동을 선택하고, 그 행동의 결과를 다시 확인할 수 있다는 것이다.

2. AI 에이전트의 전체 실행 흐름

AI 에이전트의 동작을 가장 단순하게 펼치면 다음과 같다.

사용자 목표 입력
→ 현재 상황 분석
→ 계획 또는 다음 행동 결정
→ 도구 선택 및 실행
→ 실행 결과 관찰
→ 목표 달성 여부 판단
→ 완료되지 않았다면 다시 행동 결정

에이전트는 LLM의 판단만으로 끝나지 않는다. 지침과 메모리를 참고해 도구를 실행하고, 결과를 관찰한 뒤 완료 여부를 확인하는 반복 구조로 움직인다.

사용자의 목표를 받은 에이전트가 처음부터 완벽한 전체 경로를 아는 것은 아니다. 우선 현재 상황에서 필요한 행동을 고르고, 실행 결과가 예상과 맞는지 확인한다. 결과가 다르면 계획을 수정하고 다음 행동을 선택한다.

백엔드 시스템에 비유하면 단일 함수 호출보다 상태를 확인하며 수렴하는 제어 루프에 가깝다. Kubernetes를 명령어가 아니라 조정 루프로 이해하기에서 정리했던 것처럼, 현재 상태와 원하는 상태의 차이를 확인하고 다음 행동을 결정한다는 점이 닮아 있다. 다만 에이전트의 판단은 확률적인 LLM에 의존하므로, 종료 조건과 검증 장치가 더욱 중요하다.

3. 에이전트를 이루는 핵심 구성 요소

전체 흐름을 이해하고 나니 LLM, 지침, 계획, 도구, 메모리가 각각 왜 필요한지 조금 더 분명하게 보였다. 이 요소들은 독립적으로 존재하기보다 반복 실행 안에서 서로 연결된다.

LLM: 요청을 해석하고 다음 행동을 결정한다

LLM은 사용자의 요청을 이해하고, 현재까지 확인한 정보를 바탕으로 다음 행동을 결정한다. 어떤 파일을 먼저 찾아야 하는지, 테스트 실패 로그에서 무엇을 살펴봐야 하는지, 이제 작업을 끝내도 되는지를 판단한다.

LLM을 에이전트의 두뇌라고 비유할 수는 있다. 그러나 이 비유만으로는 실제 역할이 충분히 드러나지 않는다. LLM이 직접 파일 시스템에 손을 뻗어 파일을 고치거나 운영체제에서 명령을 실행하는 것은 아니다. LLM은 주어진 문맥 안에서 다음에 사용할 도구와 그 입력을 선택하는 의사결정기에 가깝다.

실제 도구 호출과 결과 전달은 에이전트를 둘러싼 실행 시스템이 담당한다. 따라서 같은 LLM을 사용하더라도 연결된 도구와 권한, 실행 환경에 따라 에이전트가 할 수 있는 일은 크게 달라진다.

Instructions: 에이전트의 행동 정책을 정한다

Instructions는 에이전트가 따라야 할 역할과 규칙이다. 단순히 원하는 답변 형식을 적는 프롬프트를 넘어, 작업 범위와 금지 사항을 정의하는 행동 정책으로 볼 수 있다.

코드 에이전트라면 다음과 같은 지침이 포함될 수 있다.

- 기존 코드 스타일을 유지한다.
- 요청받은 범위 밖의 파일은 수정하지 않는다.
- 테스트를 실행해 변경 사항을 검증한다.
- 데이터 삭제나 배포와 같은 작업은 사용자 승인을 받는다.

첫 번째와 세 번째 규칙은 결과의 일관성과 품질을 높인다. 두 번째와 네 번째 규칙은 행동 범위를 제한해 위험을 줄인다. 결국 지침은 에이전트에게 무엇을 잘하라고 알려주는 동시에, 무엇을 하지 말아야 하는지도 명확히 하는 장치다.

다만 지침을 적어두었다고 해서 항상 지켜진다고 가정해서는 안 된다. 지침은 모델의 판단에 영향을 주지만, 파일 쓰기 범위나 배포 권한처럼 중요한 제한은 샌드박스와 승인 절차 같은 시스템 수준 통제로도 보장해야 한다. 이 실행 계층이 궁금하다면 AI 에이전트의 Harness에 대한 기술적 고찰에서 지침, 도구, 샌드박스의 관계를 함께 볼 수 있다.

Planner: 큰 목표를 실행 가능한 단계로 나눈다

Planner는 큰 목표를 작은 작업으로 나누고 실행 순서를 정한다. 예를 들어 배포 실패를 분석하는 요청은 다음처럼 분해할 수 있다.

배포 상태 확인
→ 실패한 단계와 로그 수집
→ 애플리케이션 오류인지 인프라 오류인지 분류
→ 설정 또는 코드 수정안 결정
→ 검증 환경에서 재실행
→ 배포 전 사용자 승인

이렇게 단계가 나뉘면 에이전트는 당장 필요한 정보와 완료 조건을 더 쉽게 찾을 수 있다. 긴 작업에서 초기 요구사항을 놓치는 문제도 줄일 수 있다.

모든 에이전트에 Planner라는 별도 모듈이 존재하는 것은 아니다. 단순한 구조에서는 하나의 LLM 호출이 계획 수립과 다음 행동 결정을 함께 맡을 수 있다. 복잡한 작업에서는 먼저 전체 계획을 만들고, 실행 중 관찰 결과에 따라 계획을 갱신하는 구조를 사용할 수 있다.

계획은 고정된 정답이라기보다 현재 정보를 바탕으로 만든 작업 가설에 가깝다. 실행 결과가 예상과 다르면 계획도 바뀌어야 한다.

Tools: 판단을 실제 환경의 행동으로 바꾼다

Tools는 에이전트가 외부 환경에서 실제 행동을 하게 만드는 기능이다. 목적에 따라 다음과 같은 도구가 연결될 수 있다.

웹 검색과 페이지 조회
파일 검색, 조회, 수정
터미널 명령과 테스트 실행
외부 API 호출
데이터베이스 조회
GitHub 이슈, 브랜치, PR 작업

여기서 중요한 점은 LLM이 직접 명령어를 실행하는 것이 아니라는 사실이다. LLM은 사용할 도구와 입력을 제안하고, 실행 시스템은 허용된 범위 안에서 해당 도구를 호출한다. 실행 결과는 다시 LLM이 읽을 수 있는 형태로 전달된다.

그래서 에이전트의 실제 능력은 모델 성능만으로 정해지지 않는다. 파일 조회 도구만 있으면 코드를 읽고 설명할 수는 있어도 수정할 수 없다. 쓰기 권한이 프로젝트 내부로 제한되어 있으면 운영 서버 파일은 건드릴 수 없다. 데이터베이스에 읽기 전용 권한만 주면 분석은 가능하지만 데이터를 변경할 수 없다.

이 구조는 Spring AI의 Tool Calling과도 연결된다. Spring AI 실전: Tool Calling 설계와 멀티 모델 활용 전략에서 살펴본 것처럼, 모델이 내부 규정을 추측하게 두기보다 필요한 데이터를 조회하는 도구를 명시적으로 제공하면 판단 근거와 책임 경계를 더 분명히 만들 수 있다.

Memory: 작업 맥락을 유지하되 오래된 정보는 경계한다

에이전트의 메모리는 크게 단기 메모리와 장기 메모리로 나눠볼 수 있다.

단기 메모리는 현재 작업을 이어가기 위한 문맥이다.

현재 대화와 사용자 요구사항
방금 확인한 로그
실행한 명령어와 테스트 결과
현재 작업 계획
이미 시도했지만 실패한 방법

장기 메모리는 여러 작업에서 다시 활용할 수 있는 정보다.

사용자의 선호와 작업 방식
프로젝트 구조와 코드 컨벤션
기술적 의사결정과 ADR
과거 오류의 원인과 해결 기록
반복적으로 적용하는 보안 규칙

장기 메모리는 매번 같은 설명을 반복하는 비용을 줄인다. 하지만 모든 정보를 저장하는 것이 항상 좋은 것은 아니다. 오래된 프로젝트 구조, 이미 폐기된 기술 결정, 잘못 분석한 오류 원인이 남아 있으면 이후 판단을 오히려 흐릴 수 있다.

따라서 메모리에는 무엇을 저장할지뿐 아니라 언제 갱신하고 삭제할지, 현재 작업과 얼마나 관련 있는지를 판단하는 과정이 필요하다. 장기 메모리의 검색이라는 관점에서는 RAG는 LLM에게 지식을 학습시키는 기술이 아니다와 온톨로지와 AI 세컨드 브레인에서 정리한 검색·관계 구조도 함께 연결해서 볼 수 있다.

Observation: 실행 결과를 다음 판단의 입력으로 바꾼다

Observation은 도구 실행 결과를 에이전트가 다시 확인하는 단계다. 다음과 같은 정보가 모두 관찰 결과가 될 수 있다.

테스트 42개 성공
특정 테스트 1개 실패와 스택 트레이스
파일을 찾을 수 없음
명령 실행 권한 부족
환경변수 누락
API 응답의 예상하지 못한 상태 코드

도구를 한 번 호출하는 것만으로는 에이전트의 작업이 완성되지 않는다. 테스트를 실행했다면 성공했는지 확인해야 하고, 파일을 수정했다면 의도한 내용이 반영됐는지 다시 읽어야 한다. 예상과 다른 결과가 나왔다면 다음 행동도 바뀌어야 한다.

도구 호출 자체보다 실행 결과를 다시 판단에 반영하는 구조가 에이전트를 에이전트답게 만든다. 관찰이 빠지면 여러 도구를 순서대로 호출하더라도 그저 자동화 스크립트와 비슷해질 수 있다.

Agent Loop: 판단, 행동, 관찰을 반복한다

앞의 요소들이 실제 작업에서 연결되는 지점이 Agent Loop다.

판단
→ 행동
→ 결과 관찰
→ 다음 판단

목표가 완료되지 않았다면 이 과정은 반복된다. 테스트가 실패하면 로그를 읽고 코드를 다시 수정한다. 필요한 파일을 찾지 못하면 검색 범위를 바꾼다. 요청 조건을 모두 충족했다면 반복을 끝내고 결과를 보고한다.

반복에는 반드시 완료 조건과 중단 조건이 필요하다. 그렇지 않으면 같은 명령을 계속 실행하거나, 작은 오류를 고치려다 요청 범위를 벗어나거나, 비용과 시간이 끝없이 늘어날 수 있다.

완료 조건은 “관련 테스트가 모두 통과하고 기존 응답 형식이 유지됨”처럼 검증 가능한 형태가 좋다. 중단 조건은 “같은 오류가 반복됨”, “허용된 실행 시간을 초과함”, “운영 데이터 변경 승인이 필요함”처럼 더 진행해서는 안 되는 상태를 정의한다.

4. ReAct는 판단과 행동을 어떻게 연결할까

ReAct는 Reasoning과 Acting을 결합한 패턴이다. 에이전트가 현재 상황을 판단한 뒤 행동하고, 그 결과를 관찰해 다음 행동을 정하는 흐름을 설명한다.

Thought
→ Action
→ Observation
→ Thought
→ Action

여기서 Thought를 모델의 상세한 내부 추론을 그대로 외부에 공개한다는 뜻으로 이해할 필요는 없다. 실제 시스템에서는 사용자가 확인할 수 있는 간단한 계획이나 행동 이유만 보여주고, 내부 추론은 노출하지 않을 수 있다. 중요한 것은 판단과 행동 사이에 관찰 결과가 들어간다는 구조다.

설정 파일을 확인하는 상황을 예로 들면 다음과 같다.

설정 파일 위치 확인 필요
→ 파일 검색 도구 실행
→ application.yml 발견
→ 데이터베이스 설정 확인 필요
→ 파일 조회
→ 환경변수 참조 확인

처음부터 application.yml의 위치와 내용을 모두 알고 답한 것이 아니다. 검색 결과를 관찰하면서 다음 행동을 구체화했다. 이처럼 ReAct는 긴 계획을 한 번에 생성하고 그대로 실행하는 방식보다, 작은 판단과 검증을 연결해 불확실성을 줄이는 실행 흐름으로 이해할 수 있다.

Agent Loop가 판단·행동·관찰의 반복 구조를 넓게 설명한다면, ReAct는 LLM의 판단과 도구 사용을 그 반복 안에서 연결하는 대표적인 접근이라고 볼 수 있다.

5. 코드 에이전트는 실제로 어떻게 작업할까

Claude Code나 Codex 같은 코드 에이전트에 다음 요청을 했다고 가정해보자.

상품 검색 API에 카테고리 필터를 추가해줘.
기존 응답 형식은 변경하지 말고,
관련 테스트도 작성해줘.

겉으로 보면 카테고리 조건 하나를 추가하는 간단한 요청이다. 하지만 실제 코드 변경까지 가려면 여러 단계가 필요하다.

코드 에이전트는 코드를 한 번 생성하고 끝내지 않는다. 테스트가 실패하면 로그를 분석하고 코드 변경 단계로 돌아가며, 성공한 뒤에도 요구사항 충족 여부를 최종 확인한다.

1단계: 요구사항과 제약 조건 파악

에이전트는 먼저 해야 할 일과 바꾸면 안 되는 것을 분리한다.

상품 검색에 카테고리 조건을 추가해야 한다.
기존 응답 DTO와 JSON 형식은 유지해야 한다.
새 필터 동작을 검증하는 테스트가 필요하다.
기존 검색 조건과 함께 사용될 때의 조합 방식도 확인해야 한다.

특히 “기존 응답 형식은 변경하지 말라”는 문장은 구현 방향을 제한하는 중요한 완료 조건이다.

2단계: 프로젝트 구조 탐색

관련 파일 이름을 추측해 바로 수정하기보다 프로젝트 구조를 먼저 읽는다. Controller, Service, Repository, DTO, 테스트 파일을 찾고 기존 검색 조건이 어떤 계층에서 조합되는지 확인한다.

Spring Boot 프로젝트라면 Controller에서 쿼리 파라미터를 받고, Service에서 조건을 정리하고, Repository나 QueryDSL 쿼리에서 실제 필터를 적용할 수 있다. 그러나 프로젝트마다 책임 배치가 다르므로 기존 패턴을 먼저 확인해야 한다.

3단계: 수정 범위와 계획 결정

탐색 결과를 바탕으로 변경 파일을 좁힌다. 예를 들어 요청 DTO에 선택적 categoryId를 추가하고, Repository 검색 조건에 카테고리 조건을 연결하며, 통합 테스트에 필터 성공·결과 없음·다른 조건과 조합하는 경우를 추가할 수 있다.

이 단계에서 기존 응답 DTO를 건드릴 필요가 없다는 것도 확인한다. 계획은 “무엇을 고칠지”뿐 아니라 무엇을 유지할지도 포함해야 한다.

4단계: 코드 변경과 테스트 실행

에이전트는 허용된 파일을 수정하고 관련 테스트를 실행한다. 테스트가 실패하면 실패 로그를 Observation으로 받아 원인을 다시 분석한다.

가령 Repository 테스트가 실패했다면 카테고리 조인 조건을 잘못 작성했는지, 테스트 데이터의 연관관계가 빠졌는지, 기존 검색 조건과 AND로 조합돼야 할 것이 OR로 연결됐는지 확인한다. 원인을 좁힌 후 코드를 수정하고 테스트를 다시 실행한다.

필요하다면 전체 빌드도 실행해 다른 기능에 회귀가 없는지 확인한다. 이 과정에서 에이전트는 한 번에 정답을 생성하는 것이 아니라 탐색, 실행, 관찰, 재수정을 반복한다.

5단계: 완료 조건 확인과 결과 보고

테스트가 통과했다는 사실만으로 요청이 모두 끝났다고 볼 수는 없다. 마지막에는 다음 질문을 확인해야 한다.

카테고리 필터가 실제 검색 쿼리에 적용됐는가
기존 검색 조건과 함께 사용할 수 있는가
기존 응답 형식이 유지됐는가
새 동작과 주요 예외를 테스트했는가
요청 범위 밖의 파일을 바꾸지 않았는가

이 검증이 끝난 뒤 변경 파일, 구현 내용, 실행한 테스트와 결과를 사용자에게 보고한다. AI가 코드를 만드는 시대, 개발자는 무엇을 검증해야 할까에서 정리했듯이, 코드 생성 속도보다 결과의 정확성과 책임 경계를 확인하는 일이 더 중요할 수 있다.

6. 정해진 워크플로우와 AI 에이전트의 차이

기존 자동화 워크플로우도 여러 시스템을 연결해 실제 작업을 수행한다. 그렇다면 워크플로우와 에이전트의 차이는 무엇일까?

예를 들어 데이터 조회 후 이메일을 보내는 자동화는 다음처럼 미리 정할 수 있다.

데이터 조회
→ 데이터 변환
→ 이메일 전송

실행 순서와 조건은 사람이 설계한다. 입력이 같고 외부 상태가 같다면 대체로 같은 경로를 따른다. 예외 처리도 “조회 실패 시 재시도”, “결과가 없으면 전송하지 않음”처럼 규칙으로 미리 정의한다.

AI 에이전트는 현재 상황과 실행 결과를 해석해 다음 행동을 동적으로 선택한다. 어떤 파일을 읽을지, 실패 원인을 더 조사할지, 다른 도구를 사용할지 실행 중에 결정할 수 있다.

워크플로우는 미리 설계된 경로를 안정적으로 반복한다. AI 에이전트는 관찰 결과에 따라 다음 행동을 선택하고, 필요하면 이전 판단 단계로 돌아간다.

구분	자동화 워크플로우	AI 에이전트
실행 경로	사람이 순서와 조건을 미리 정의	현재 상황과 결과에 따라 동적으로 선택
예측 가능성	비교적 높음	상대적으로 낮음
예외 대응	정의된 예외만 처리하기 쉬움	새로운 상황을 탐색하며 대응 가능
비용	반복 실행 비용을 계산하기 쉬움	모델·도구 호출 횟수에 따라 달라짐
적합한 작업	규칙이 명확하고 반복적인 작업	탐색과 판단이 필요한 작업

AI 에이전트가 항상 더 좋은 선택은 아니다. 정해진 시간마다 데이터를 조회하고 변환해 전송하는 작업이라면 기존 워크플로우가 더 단순하고 안정적이다. 결제나 정산처럼 실행 경로의 예측 가능성과 재현성이 중요한 경우에도 명시적인 규칙이 유리하다.

반대로 원인을 알 수 없는 빌드 실패 분석, 여러 문서에서 필요한 근거 찾기, 코드베이스의 기존 패턴을 조사한 뒤 수정 범위를 정하는 일처럼 예외가 많고 탐색이 필요한 작업에는 에이전트가 유연하게 대응할 수 있다.

결국 둘 중 하나를 선택하는 문제가 아니라, 결정적인 경로는 워크플로우로 고정하고 불확실한 탐색 구간만 에이전트에 맡기는 혼합 구조도 생각할 수 있다.

7. AI 에이전트는 왜 실패할 수 있을까

에이전트가 도구를 사용하고 스스로 다음 행동을 정한다고 해서 항상 목표에 올바르게 도달하는 것은 아니다. 오히려 판단과 실행이 연결되기 때문에 잘못된 결정이 실제 변경으로 이어질 수 있다.

잘못된 계획을 세울 수 있다

요구사항을 오해하거나 프로젝트 구조를 충분히 읽지 않은 상태에서 계획을 만들 수 있다. 이후 행동이 모두 그 잘못된 전제를 따르면, 여러 파일을 그럴듯하게 수정하고도 실제 문제를 해결하지 못할 수 있다.

적절하지 않은 도구를 선택할 수 있다

파일 검색으로 충분한 일을 웹 검색부터 시도하거나, 읽기만 필요한 상황에서 수정 도구를 선택할 수 있다. 같은 목적의 도구가 여러 개일 때는 잘못된 환경을 조회하는 문제도 생길 수 있다.

같은 행동을 반복할 수 있다

실패 원인을 정확히 파악하지 못하면 같은 테스트와 같은 수정을 반복할 수 있다. 관찰 결과를 이전 시도와 비교하지 못하거나, 중단 조건이 없을 때 이런 반복이 길어진다.

긴 작업에서 초기 요구사항을 놓칠 수 있다

로그와 파일 내용이 계속 문맥에 쌓이면 처음의 제약 조건이 상대적으로 약해질 수 있다. 기능은 동작하지만 “기존 응답 형식을 유지한다”는 조건을 놓치는 식이다.

실행 결과를 잘못 해석할 수 있다

명령이 종료됐다는 사실을 테스트 성공으로 오해하거나, 일부 테스트만 통과했는데 전체 검증이 끝났다고 판단할 수 있다. 경고를 무시해도 되는지 잘못 판단할 수도 있다.

과도한 권한은 실제 피해로 이어질 수 있다

잘못된 답변은 대화 안에서 끝나지만, 잘못된 도구 호출은 파일 삭제, 운영 배포, 데이터 변경, 결제, 외부 메시지 전송으로 이어질 수 있다. 에이전트의 유연성이 커질수록 영향 범위도 함께 커진다.

8. 자율성보다 통제 구조가 중요한 이유

이런 실패를 줄이려면 “더 좋은 모델을 사용한다”는 답만으로는 부족하다. 에이전트가 실수할 수 있다는 전제에서 실행 범위와 검증 지점을 설계해야 한다.

최대 반복 횟수: 같은 작업을 끝없이 반복하지 못하게 한다.
실행 시간 제한: 예상보다 오래 걸리는 작업을 중단하고 상태를 보고한다.
도구별 권한 분리: 조회, 수정, 삭제, 외부 전송 권한을 나눠 제공한다.
수정 가능한 디렉터리 제한: 요청과 무관한 파일이나 시스템 영역에 접근하지 못하게 한다.
고위험 작업 전 승인: 삭제, 배포, 결제, 이메일 전송은 실행 직전에 사람의 확인을 받는다.
실행 로그 기록: 어떤 판단 아래 어떤 도구와 입력을 사용했는지 추적할 수 있게 한다.
별도의 검증 단계: 테스트, 정적 분석, 코드 리뷰처럼 결과를 독립적으로 확인한다.
즉시 중단 조건: 권한 오류, 반복 실패, 요구사항 충돌이 발생하면 더 진행하지 않는다.
Human-in-the-loop: 중요한 결정과 되돌리기 어려운 행동에 사람을 포함한다.

이 장치들은 에이전트의 능력을 방해하기 위한 것이 아니다. 허용된 범위 안에서 자율적으로 움직이게 만들기 위한 안전 경계다.

특히 모든 작업을 같은 위험도로 다루면 안 된다고 느꼈다. 코드 작성과 로컬 테스트는 변경 내역을 비교하고 되돌리기 쉽다. 반면 운영 배포, 데이터 삭제, 결제, 외부 메시지 전송은 한 번 실행되면 사용자와 시스템에 직접 영향을 준다.

따라서 저위험 작업에는 비교적 넓은 자율성을 주고, 영향이 큰 작업에는 명시적인 승인 단계를 두는 편이 현실적이다. 자율성을 얼마나 많이 주느냐보다 어디까지 맡기고 어디에서 멈추게 할지를 설계하는 것이 더 중요하다.

9. 학습 후 생각: 에이전트는 자율적인 모델보다 통제된 실행 시스템에 가까웠다

처음에는 AI 에이전트를 스스로 모든 문제를 해결하는 자율적인 AI라고 생각했다. 질문을 받고, 계획을 세우고, 도구까지 사용하는 모습을 보면 하나의 완성된 지능처럼 느껴지기 때문이다.

하지만 구조를 살펴보니 AI 에이전트는 특별한 단일 모델이라기보다 LLM, 도구, 메모리, 실행 결과 관찰, 반복 구조를 조합한 실행 시스템에 가까웠다.

LLM의 성능은 분명 중요하다. 요청을 잘못 이해하거나 실행 결과를 엉뚱하게 해석하면 전체 작업이 흔들린다. 동시에 실제 에이전트의 품질은 다음 질문에 따라 크게 달라진다고 느꼈다.

어떤 도구를 제공하는가
도구에 어떤 권한을 허용하는가
실행 결과를 어떻게 검증하는가
실패했을 때 언제 중단하는가
어떤 작업에서 사람의 승인을 받는가

이 질문들은 백엔드 시스템을 설계할 때 권한, 트랜잭션 경계, 재시도, 감사 로그, 장애 대응을 고민하는 것과도 닮아 있다. 모델의 지능만 높이면 해결되는 문제가 아니라, 실패를 예상하고 경계를 만드는 시스템 설계의 문제다.

특히 코드 작성이나 테스트 실행처럼 되돌리기 쉬운 작업은 에이전트에게 비교적 적극적으로 맡길 수 있다고 생각했다. 반면 배포, 데이터 삭제, 결제, 외부 메시지 전송처럼 영향이 큰 작업은 사람이 마지막 의도를 확인하는 승인 단계가 필요하다.

결국 AI 에이전트는 모든 작업을 완전히 자동화하는 기술이라기보다, 반복적인 탐색과 판단은 AI에게 맡기고 위험한 행동에는 명확한 통제 지점을 두는 방식으로 활용하는 편이 현실적이다.

10. 핵심 정리

AI 에이전트는 더 성능이 좋은 LLM의 이름이 아니라, LLM과 도구, 메모리, 관찰, 반복 구조를 결합한 시스템이다.
LLM은 요청과 현재 상태를 해석해 다음 행동을 결정하고, 실행 시스템은 그 판단에 따라 허용된 도구를 호출한다.
Observation은 도구 결과를 다음 판단의 입력으로 바꾸며, Agent Loop는 목표가 완료될 때까지 판단과 행동을 이어준다.
ReAct는 판단, 행동, 관찰을 연결하는 대표적인 실행 패턴으로 이해할 수 있다.
규칙이 명확하고 반복적인 일은 기존 워크플로우가 더 단순하고 안정적일 수 있다.
에이전트의 품질은 모델 성능뿐 아니라 도구, 권한, 완료 조건, 중단 조건, 검증 방식에 의해 결정된다.
중요한 것은 자율성의 크기가 아니라 자율성의 범위와 통제 지점을 설계하는 일이다.

AI 에이전트가 브라우저라는 도구를 사용할 때 인증, 권한, 감사 로그가 어떻게 달라지는지 궁금하다면 AI 에이전트가 브라우저를 사용한다는 것의 의미도 함께 볼 수 있다. 에이전트의 추상적인 구조가 실제 도구 환경에서 어떤 운영 문제로 이어지는지 더 구체적으로 연결해볼 수 있다.

AI, Architecture