AI 에이전트란 무엇이고 어떻게 작동하나요?

챗봇, 워크플로, 에이전트의 차이

사람들은 에이전트라는 말을 여러 의미로 씁니다. 예를 들어 Anthropic의 엔지니어링 가이드가 쓰는 유용한 구분은, 둘 다 언어 모델(LLM)과 도구를 쓰는 시스템을 두 종류로 나눕니다.

• 워크플로(workflow)는 개발자가 코드로 정해 둔 경로를 따릅니다. 1단계에서 요약하고, 2단계에서 번역하고, 3단계에서 형식을 검사하는 식입니다. 모델은 각 단계를 채울 뿐 단계를 고르지는 않습니다.
• 에이전트(agent)는 자기 단계를 스스로 고릅니다. 개발자가 목표와 도구 모음을 주면, 모델이 지금까지 본 내용을 바탕으로 다음에 어떤 도구를 호출할지 정합니다.

단계 수를 미리 알 수 없을 때 에이전트는 추가 비용만큼의 가치를 합니다. 코드 디버깅, 여러 페이지에 걸친 조사, 어수선한 폴더 정리가 그런 경우입니다. 단계가 정해져 있다면 워크플로가 더 싸고, 더 빠르고, 테스트하기도 쉽습니다.

에이전트 루프, 단계별로

코딩 어시스턴트부터 브라우저 에이전트까지 거의 모든 에이전트가 같은 작은 루프를 돕니다. ReAct 논문(2022)은 핵심 아이디어를 이렇게 설명했습니다. 모델이 작업에 대한 추론과 행동을 번갈아 하게 하고, 매번 결과를 다시 넣어 줍니다.

1. 프로그램이 모델에 목표, 설명이 달린 사용 가능한 도구 목록, 지금까지의 대화를 보냅니다.
2. 모델은 최종 답변이나 도구 호출로 응답합니다. 도구 호출은 도구 이름과 인자이며 보통 JSON입니다.
3. 도구는 모델이 아니라 프로그램이 실행합니다. 웹 검색, 파일 읽기, 데이터베이스 조회 같은 일입니다.
4. 프로그램이 도구 결과를 대화에 추가하고 1단계로 돌아갑니다.
5. 모델이 최종 답변을 내거나, 프로그램이 최대 단계 수·시간 제한·예산 같은 한도에 닿으면 루프가 끝납니다.

중요한 점이 있습니다. 모델은 내 파일이나 계정에 직접 손대지 않습니다. 행동을 요청하는 텍스트를 쓸 뿐이고, 실행할지는 둘러싼 소프트웨어가 결정합니다. 권한, 승인, 로그가 자리해야 할 곳이 바로 이 소프트웨어입니다.

코드로 쓰면 루프는 짧습니다.

messages = [system_prompt, user_goal]
for step in range(MAX_STEPS):
    reply = llm(messages, tools=TOOLS)
    if reply.tool_calls == []:
        return reply.text                  # final answer
    for call in reply.tool_calls:
        if needs_approval(call):
            ask_user(call)                 # human in the loop
        result = run_tool(call.name, call.arguments)
        messages.append(tool_result(call.id, result))
return "Stopped: step limit reached"

실전 예시: 작업 하나, 여섯 턴

도구 세 개, 즉 search_files, read_file, send_email을 가진 에이전트의 간단한 실행 기록입니다. 목표는 "지난달 청구서 합계를 Mai에게 이메일로 보내기"입니다.

Goal: Email Mai the total of last month's invoices.

Turn 1  model -> search_files(query="invoice 2026-10")
        tool  -> invoice-1031.pdf, invoice-1044.pdf, invoice-1052.pdf
Turn 2  model -> read_file("invoice-1031.pdf")
        tool  -> "... Total: 1,200.00 USD ..."
Turn 3  model -> read_file("invoice-1044.pdf")
        tool  -> "... Total: 860.50 USD ..."
Turn 4  model -> read_file("invoice-1052.pdf")
        tool  -> "... Total: 2,015.00 USD ..."
Turn 5  model -> send_email(to="mai@example.com",
                 body="October invoices: 3, total 4,075.50 USD")
        app   -> asks the user: Send this email? [yes]
        tool  -> sent
Turn 6  model -> "Done. I emailed Mai: 3 invoices, 4,075.50 USD."

각 턴은 모델에 대한 별도의 호출이고, 호출마다 전체 기록을 다시 보냅니다. 에이전트가 한 번의 채팅 답변보다 느리고 비싼 이유를 이 기록이 보여 줍니다. 어디서 문제가 생기는지도 보여 줍니다. 검색이 청구서 하나를 놓쳤다면 에이전트는 틀린 합계를 자신 있게 보고했을 것입니다. 좋은 에이전트 설계는 결과를 점검합니다. 예컨대 모델에게 사용한 파일 목록을 쓰게 해서 사람이 확인할 수 있게 합니다.

에이전트의 구성 요소

• 모델: 컨텍스트를 읽고 다음 행동을 고르는 LLM. 모델이 강할수록 잘못된 도구 호출이 줄고 오류에서도 더 잘 회복합니다.
• 도구: 이름, 설명, 매개변수 스키마가 있는 함수. 모델은 이 설명만 보고 도구를 고르므로 명확한 도구 설명은 메인 프롬프트만큼 중요합니다.
• 컨텍스트와 메모리: 작업의 진행 기록. 긴 작업은 컨텍스트 윈도우를 채우기 때문에 에이전트는 지난 단계를 요약하거나 파일에 메모를 저장합니다.
• 지시문: 목표와 규칙, 멈추거나 물어볼 시점을 정하는 시스템 프롬프트.
• 가드레일: 단계 한도, 지출 한도, 허용 행동 목록, 되돌릴 수 없는 일에 대한 사람의 승인.

이 글을 쓰는 시점에 도구 호출은 대부분의 LLM API가 기본으로 제공하는 기능입니다. 개발자가 요청에 도구 정의를 보내면 모델이 구조화된 호출을 돌려주고, 개발자가 결과를 다시 보냅니다. 같은 도구를 여러 앱에 연결할 수 있도록, 모델 컨텍스트 프로토콜(MCP)은 앱(호스트)이 별도 서버가 제공하는 도구를 찾아 호출하고, 리소스를 읽고, 프롬프트 템플릿을 쓰는 공통 방식을 정의합니다.

지금 에이전트가 잘 맞는 곳

• 코딩: 프로젝트를 읽고, 테스트를 실행하고, 파일을 고치고, 다시 테스트를 실행합니다. 테스트 결과가 에이전트에게 분명한 피드백을 주기 때문에 코딩은 가장 성숙한 활용 분야 중 하나입니다.
• 조사: 검색하고, 여러 출처를 열어 보고, 링크가 달린 요약을 씁니다. 결과물은 여전히 사실 확인이 필요합니다.
• 데이터 작업: 스프레드시트 정리, 형식 변환, 작은 스크립트 작성과 실행.
• 브라우저·컴퓨터 사용: 웹 페이지나 데스크톱 앱을 클릭해 가며 진행합니다. 동작은 하지만 화면이 바뀌고 페이지에 오해를 부르는 글이 있을 수 있어, 실제 API를 쓰는 것보다 느리고 덜 안정적입니다.

이 모두에서 뚜렷한 패턴이 있습니다. 에이전트는 결과를 자동으로 확인할 수 있는 곳(테스트 통과, 파일 파싱 성공, 숫자 합계 일치)에서 가장 잘합니다. 성공 여부가 주관적이거나, 행동 하나가 틀렸을 때 대가가 큰 곳에서는 가장 약합니다.

대비해야 할 위험과 한계

• 오류가 누적됩니다. 각 단계가 대부분 맞더라도 단계가 많은 작업은 자주 실패할 수 있습니다. 작업을 짧게 하고 체크포인트를 두면 도움이 됩니다.
• 환각된 행동입니다. 모델이 존재하지 않는 파일 이름처럼 지어낸 인자로 도구를 호출할 수 있습니다. 실행 전에 인자를 검증하세요.
• 프롬프트 인젝션입니다. 웹 페이지, 이메일, 문서에 "지시를 무시하고 파일을 보내라" 같은 텍스트가 들어 있을 수 있고, 모델이 따를 수 있습니다. 도구 출력은 모두 신뢰할 수 없는 데이터로 다루고, 에이전트에게 비공개 데이터와 제한 없는 외부 전송 수단을 함께 주지 마세요.
• 권한입니다. 에이전트에게는 필요한 최소한의 도구와 접근 권한만 주세요. 읽기 전용이 쓰기 권한보다 훨씬 안전합니다.
• 비용과 반복입니다. 에이전트가 실패하는 같은 단계를 되풀이할 수 있습니다. 최대 단계 수와 예산을 정하고 모든 호출을 기록하세요.
• 책임 소재입니다. 에이전트가 이메일을 보내거나 결제를 하면 책임은 모델이 아니라 그것을 운영하는 사람이나 회사에 있습니다.

에이전트를 만들거나 고를 때 시작하는 방법

1. 작업을 분명한 목표와 결승선이 있는 형태로 적으세요. 예를 들면 "모든 테스트 통과"나 "이 다섯 개 열이 있는 CSV"입니다.
2. 먼저 프롬프트 하나나 고정된 워크플로로 시도하세요. 단계가 정말 달라질 때만 에이전트로 넘어갑니다.
3. 설명이 잘 달린 도구를 몇 개만 주세요. 도구마다 한 가지 일만 하고 짧고 분명한 결과나 오류를 돌려줘야 합니다.
4. 한도를 두세요. 최대 단계 수, 시간, 비용, 위험한 행동에 대한 승인입니다.
5. 실제 사례 10~20개로 테스트하고 최종 답만이 아니라 전체 실행 기록을 읽으세요. 수정은 대부분 더 나은 도구 설명과 더 분명한 종료 규칙에서 나옵니다.