bj.choi - notes

[AI Agent] AI Agent Preview (6주차)

Updated:

LLM이 런타임에 다음 행동을 스스로 결정하는 AI Agent의 개념부터 설계까지 알아봅시다. AI Agent를 설계하는 것과 Workflow와의 차이, 4대 구성요소를 통해 Agent 구축의 기초를 다집니다.

현재의 AI Agent 개요

많은 개발자가 Cursor와 Claude Code 같은 코딩 에이전트를 매일 쓰고 있습니다.

ChatGPT와 Claude 내부에도 Agent 모드가 들어왔고 사내 업무 자동화에는 LangGraph, CrewAI 같은 오픈소스 프레임워크로 만든 멀티 에이전트가 점점 들어오고 있습니다.

표준화 흐름도 빠릅니다. Anthropic이 2024년 말에 공개한 MCP(Model Context Protocol)는 LLM과 외부 tool·데이터 소스를 잇는 오픈 표준입니다. 1년 반 만에 9천만 건이 넘는 설치를 기록. 2025년 말에는 Linux Foundation 산하 AAIF로 이관되며 사실상 “Agent ↔ Tool” 연결의 기본이 됐습니다.

앤트로픽의 MCP는 2026년 3월 25일 9,700만 설치를 돌파했습니다. 이는 AI 인프라 표준 중 가장 빠른 채택 곡선입니다.

Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 태스크 전용 AI Agent를 포함하게 될 것으로 예측합니다. 현재는 5% 미만입니다.

요약하면 이렇습니다.

“AI Agent는 이미 많은 곳에서 쓰이기 시작했고, 점점 더 많이 들어오고 있습니다.”

그런데 이름만 자주 들을 뿐 Agent가 정확히 뭔지 설명해보라고 하면 막히는 경우가 많습니다. LLM을 한 번 호출하는 것과 뭐가 다른지, RAG와 뭐가 다른지, 만들려면 뭘 설계해야 하는지 간단하게 개요를 알아보겠습니다.

AI Agent란 무엇인가

“AI Agent는 LLM이 사용자의 요청(목적)을 수행하기 위해 스스로 다음 행동(tool 호출 또는 최종 응답)을 결정하며 작업을 진행하는 시스템입니다.”

기존 소프트웨어는 개발자가 실행 경로를 미리 다 정해둡니다. 사용자가 버튼을 누르면 어떤 함수가 호출되고, 그 함수가 어떤 DB를 조회하는지 코드로 고정돼 있습니다.

하지만 Agent는 그 경로를 “런타임에 LLM이 직접 선택”합니다.

AI Agent 예시

말로만 설명하면 감이 잘 안 옵니다. 가장 단순한 Agent 패턴인 ReAct의 trace를 한 번 확인해보겠습니다.

User: "서울의 오늘 날씨를 알려주고, 우산 필요한지 알려줘"

Thought: 날씨 정보가 필요하다. weather tool을 호출하자.
Action: weather(city="서울")
Observation: {"temp": 12, "rain_prob": 80, "condition": "비"}

Thought: 강수확률 80%이면 우산 필요. 답변을 만들자.
Final Answer: 서울은 현재 12도, 비 소식 있고 강수확률 80%입니다. 우산을 챙기세요.

세 가지가 존재합니다.. Thought / Action / Observation.

한 번의 LLM 호출로 끝나지 않습니다. 여러 번의 호출에 나뉘고, 매 번 LLM은 스스로 “지금 tool을 쓸지, 아니면 답할지”를 결정합니다.

Observation은 RAG의 retrieved context와 다릅니다. RAG에서 context는 항상 “검색 결과”로 고정돼 있지만, Agent의 Observation은 이번엔 weather API, 다음엔 DB 조회, 그 다음엔 파일 읽기처럼 그 때 그 때 판단한 tool의 출력을 가져오는 것 입니다.

종료 조건도 LLM이 스스로 판단합니다. 답변 가능한 정보가 충분하다고 판단되면 Tool을 종료하고 답변을 출력합니다.

AI Agent를 어떻게 구분할 수 있는가?

하지만 주의할 게 있습니다. 위 예시가 AI Agent로 적합하다고 생각하시나요?

조금 반전일 수 있는데 해석에 따라, 목적에 따라 Agent가 아닐 수도 있습니다.

날씨 앱에서 사용한다고 가정하면 “사용자 지역 날씨를 확인해서 우산 필요 여부를 알려준다”는 작업은 경로가 처음부터 정해져 있습니다.

언제나 날씨 정보를 가져와야겠다 생각하는게 아닌 앞선 로직에서 사용자 위치에 따라 weather 함수를 실행하고 결과를 읽은 뒤 우산 필요 여부만 LLM이 응답해도 되고 아니면 weather 자체에서 비/눈 → 우산 값을 던져주면 됩니다.

def handle(user_query: str) -> str:
    city = extract_city(user_query)
    weather = call_weather_api(city)
    return llm.summarize(user_query, weather)

흐름이 질문에 따라 바뀔 일이 없습니다. 이런 작업은 고정된 코드로 푸는 쪽이 더 빠르고, 싸고, 안정적이며 AI 조차 사용할 필요가 없죠.

하지만 다른 관점으로 보겠습니다.

“비가 오면 사용자의 하루 계획을 어떻게 바꿔야 하는가?”처럼 목표가 열려 있고, 여러 도구를 호출하며, 선택지가 달라지고, 실행까지 이어지면 Agent에 가까워집니다.

도메인 Agent가 되는 이유
여행 / 일정 관리 비, 폭염, 눈 예보에 따라 야외 일정을 실내 일정으로 바꾸고 예약/이동 경로까지 조정
농업 기상, 토양, 작물 상태를 보고 관수, 방제, 수확 시점을 판단
물류 / 배송 폭우, 폭설, 강풍에 따라 배송 경로, 출발 시간, 지연 안내를 조정
건설 / 현장 작업 강풍, 낙뢰, 폭염 기준에 따라 작업 중단, 인력 재배치, 안전 공지 수행
야외 행사 / 스포츠 우천 가능성에 따라 장소 변경, 취소 판단, 참가자 안내, 장비 준비
스마트홈 / 빌딩 관리 날씨와 실내 상태를 보고 냉난방, 창문, 제습, 에너지 사용을 최적화
보험 / 재난 대응 태풍, 홍수, 우박 위험 지역을 감지하고 고객 알림, 피해 접수, 대응 우선순위 결정
항공 / 해운 / 드론 기상 조건에 따라 운항 가능 여부, 경로, 대체 계획 판단. 단, 고위험 영역이라 human-in-the-loop 필요
커머스 / 수요 예측 날씨 변화에 따라 우산, 음료, 방한용품, 배달 수요 등을 예측하고 재고/프로모션 조정

즉 날씨를 의사결정의 수단으로 사용하는 도메인이죠.

이 구분을 Anthropic이 “Building Effective Agents”에서 명확히 합니다.

Notion Image

Anthropic — Building Effective Agents

Workflow는 LLM과 tool이 미리 정해진 코드 경로로 orchestrate되는 시스템입니다.
Agent는 LLM이 자신의 프로세스와 tool 사용을 동적으로 지시하며, 태스크를 어떻게 수행할지에 대한 통제권을 유지하는 시스템입니다.

가장 단순한 솔루션부터 시작하세요. 필요할 때만 복잡도를 올리세요.
많은 경우 Agent는 좋지 않은 선택입니다.

Workflow의 예측 가능성과 통제 가능함 vs Agent의 유연성과 확장성의 대비라고 생각합니다.

그러니까 “AI Agent로 적합한가?“라는 질문은 예시의 구조만 보고는 답할 수 없습니다.

목적과 범위를 함께 봐야 답이 나옵니다.

같은 weather tool을 쓰더라도, 요청이 다음처럼 범위가 열려 있으면 Agent가 될 수 있다는 얘기죠.

시스템 유형을 스펙트럼으로 정리하면 다음과 같습니다.

시스템 유형 의사결정 주체 실행 경로 종료 조건 대표 예시
Chatbot 사람 매 턴 사람이 결정 사람이 종료 단순 Q&A 봇
RAG 개발자 검색 → 생성 고정 답변 1회 생성 사내 문서 검색 봇
Workflow 개발자 미리 정한 그래프 경로 그래프 끝 Prompt chaining, Routing
Agent LLM 런타임에 LLM이 선택 LLM이 “done” 선언 ReAct 루프

그렇다면 Agent는 어떻게 설계하는가

“이 문제는 Agent로 풀어야 한다”는 판단이 섰다는 전제 아래 Agent 설계는 무엇을 생각하게 하고. 무엇을 실행하게 하는지 원칙을 정의할 수 있습니다.

Anthropic이 제시한 원칙 세 가지으로 정리해보겠습니다.

이 세 원칙을 체화한 뒤에 비로소 아래 구성을 하나씩 결정하는 일이 시작됩니다.

이후 섹션에서는 Agent의 구성요소와 대표 패턴을 먼저 짚고, 그 다음 각 설계 축을 하나씩 풀어쓰겠습니다.

AI Agent의 4대 구성요소

Notion Image

Agent의 구성은 네 가지로 정리됩니다.

각 축이 빠지면 실패 모양이 다르게 드러납니다.

빠지는 축 드러나는 증상
LLM 판단 흐림 엉뚱한 tool 선택, 같은 질문에 다른 경로
Tool 스키마 불명확 hallucinated tool call, 없는 파라미터 호출
Memory 없음 대화 맥락 유실, 이전 결과 반복, 상태 유실
Planning 없음 무한 루프, 중도 방향 상실

RAG 용어와 매핑해두면 이해가 쉽습니다. Retriever는 Agent 관점에서 “검색 tool 하나”입니다. Agent는 그 검색 tool 외에도 여러 tool을 함께 쓸 수 있고, tool을 쓸지 말지를 매 턴 LLM이 결정합니다.

RAG는 무조건 검색이 먼저지만, Agent는 “검색이 필요 없는 질문”이면 검색을 건너뜁니다.

구성 4가지를 AI 구성 요소로

4가지 구성 요소를 실제 AI 개발과 매칭해보겠습니다.

System prompt

Agent의 목표·제약·행동 가이드로 LLM, Planning 구성을 포함합니다.

Context, Database

Agent가 장기, 반복 실행 가능하게 결과를 저장하고 상태를 기록하는 구성입니다.

차주 Multi Agent 패턴에서 자세히 확인해보겠습니다.

Tool

코드, 함수 그 자체를 의미 → 이름, 설명, 파라미터(입력), 반환 스키마(출력)

프레임워크에서 Thought / Action / Observation을 단순 state로 구현한 것 뿐

state = initial_state

  while not framework.should_stop(state):
      state = agent.invoke(state)

  return stat

MCP & Tool 참고

AI Agent 패턴

Agent의 종류는 다양하고 툴의 종류도 다양합니다.

대표적인 것을 정리했습니다.

AI Agent의 한계

Agent는 아직 완성된 기술이 아니며 설계자, 구현하는 사람에 따라 품질이 크게 차이날 수 있습니다.

앞으로 남은 5주간 AI Agent를 직접 설계하고 구현하면서 본격적으로 진행해보겠습니다.

Reference