인사이트 / 블로그

시리즈 안내 · 1/6

요즘은 어디를 가나 ‘AI 에이전트’ 이야기가 빠지지 않습니다. 웹사이트를 탐색하고, 필요한 정보를 모으고, 문서를 정리하고, 때로는 업무 시스템까지 조작하는 AI가 등장하고 있기 때문입니다.

그런데 막상 “에이전트가 무엇인가요?”라고 물어보면 답은 생각보다 흐려집니다. 챗봇이 길게 답하면 에이전트일까요? 검색 기능이 붙으면 에이전트일까요? 여러 API를 호출하면 모두 에이전트라고 불러도 될까요?

에이전트의 핵심은 단순히 더 똑똑하게 말하는 것이 아니라, 목표를 달성하기 위해 어떤 순서로 무엇을 실행할지 스스로 정하는 구조에 있습니다.

질의응답을 넘어 실행으로

일반적인 챗봇은 사용자의 질문을 받고 답변을 생성합니다. 사용자가 “이 자료를 요약해줘”라고 말하면, 주어진 텍스트를 읽고 요약문을 만들어주는 식입니다.

에이전트가 다루는 일은 여기서 한 단계 더 나아갑니다. 한 번 답하고 끝나는 일이 아니라, 중간에 판단하고 방향을 바꿔야 하는 일이 많습니다. 예를 들어 사용자가 이렇게 요청했다고 해보겠습니다.

“이번 주 AI 에이전트 관련 주요 이슈를 찾아서, 내부 공유용 요약문으로 정리해줘.”

이 요청은 단순한 문장 생성만으로는 처리하기 어렵습니다. 적어도 다음 과정을 거쳐야 합니다.

• 무엇을 검색할지 정하기
• 신뢰할 수 있는 출처 고르기
• 중복된 정보 걸러내기
• 핵심 흐름을 묶어 문서 형식으로 정리하기

검색 결과가 부족하면 다시 찾아봐야 하고, 출처가 불명확하면 제외해야 할 수도 있습니다.

정해진 순서대로만 움직이는 자동화라면 사람이 미리 실행 절차를 정해둘 수 있습니다. 매번 검색어, 도구, 순서, 판단 기준이 달라지는 일이라면 그때마다 누군가가 흐름을 결정해야 합니다.

에이전트는 이 결정을 언어모델에게 맡기는 구조입니다. 주어진 목표를 보고, 지금 상황에서 무엇을 해야 할지 생각하고, 필요한 도구를 선택해 실행하고, 결과를 확인한 뒤 다음 행동을 이어갑니다.

흐름은 단순합니다.

보고 -> 생각하고 -> 실행하고 -> 결과를 다시 본다.

이 반복 루프가 에이전트의 기본 구조입니다.

에이전트를 이해할 때 먼저 물어야 할 질문도 여기서 나옵니다.

다음 행동을 누가 결정해야 하는가?

에이전트가 “도구를 쓴다”는 말의 진짜 의미

에이전트가 검색하고, 캘린더를 확인하고, 파일을 읽고, Jira나 Notion 같은 업무 시스템을 호출할 때 우리는 흔히 “도구를 쓴다”고 말합니다.

언어모델이 직접 도구를 실행하는 것은 아닙니다.

모델은 “이 도구에 이런 값을 넣어 호출해야겠다”는 결정을 구조화된 응답으로 만듭니다. 실제 실행은 애플리케이션이나 서비스 계층이 맡습니다. 실행 결과가 다시 모델에게 전달되면, 모델은 그 결과를 바탕으로 최종 답변을 만들거나 다음 행동을 정합니다.

예를 들어 사용자가 “AI 팀 Jira 이슈 목록을 보여줘”라고 요청했다고 해보겠습니다.

1. 서비스는 모델에게 사용자 요청과 함께 사용할 수 있는 도구 목록을 알려줍니다.
2. 모델은 Jira에서 이슈 목록을 가져와야 한다고 판단하고, 검색에 필요한 데이터(인자)를 담아 도구 실행을 요청합니다.
3. 서비스는 그 응답을 읽고 실제 Jira API를 호출합니다.
4. Jira에서 받은 결과를 다시 모델에게 전달합니다
5. 모델은 그 결과를 사람이 읽기 쉬운 표나 문장으로 정리합니다.

Tool Calling에서 중요한 것은 호출 자체보다 그 뒤의 연결입니다. 모델, 서비스, 도구, 실행 결과가 이어지면서 작은 실행 루프가 만들어집니다.

그래서 에이전트 품질은 모델 성능만으로 정해지지 않습니다. 도구를 어떻게 제공할지, 설명을 얼마나 분명하게 쓸지, 결과와 실패를 어떤 방식으로 피드백할지까지 설계 범위에 들어갑니다.

에이전트는 어떻게 추론하고 행동할까?

계획형 에이전트에는 ReAct, ReWOO, Plan-and-Solve 계열이 들어갑니다.

ReAct는 한 단계씩 생각하고, 행동하고, 관찰하면서 다음 행동을 정하는 방식입니다. ReWOO는 먼저 전체 계획을 세운 뒤 실행을 분리하는 방식에 가깝습니다. Plan-and-Solve도 먼저 계획을 세우고 순차적으로 실행한다는 점에서 같은 계열로 볼 수 있습니다.

계획형 에이전트는 일을 한 번에 끝내려 하지 않습니다. 목표를 쪼개고, 한 단계씩 실행하며, 결과를 확인합니다. 업무 리서치, 보고서 초안 작성, 고객 문의 분류처럼 중간 판단이 필요한 작업에 잘 맞습니다.

절차 실행형 에이전트는 CodeAct 계열로 볼 수 있습니다.

CodeAct는 모델이 말로만 추론하지 않고, 필요한 절차를 실제로 돌릴 수 있는 형태로 만듭니다. 반복 작업이나 데이터 처리처럼 단계가 많은 일을 정리해 시스템이 처리하도록 넘기는 방식입니다.

여기서 말하는 절차는 꼭 사람이 직접 코드를 알아야 한다는 뜻이 아닙니다. Codex나 Claude Code 같은 CLI 어시스턴트를 활용하면, 업무 담당자도 자연어로 목표를 설명하고 필요한 실행 절차를 만들 수 있습니다. 결과를 확인하면서 그 흐름을 업무에 적용하는 것도 가능합니다.

계산, 반복 작업, 데이터 처리처럼 절차가 복잡한 문제에서는 이 방식이 더 효율적일 수 있습니다.

검증형 에이전트에는 Self-Refine, Reflexion, CRITIC 계열이 들어갑니다.

검증형 에이전트는 첫 결과에 바로 만족하지 않습니다. 결과가 맞는지 확인하고, 부족한 부분이 있으면 다시 고칩니다. Self-Refine은 스스로 피드백을 만들어 결과를 다듬고, Reflexion은 실패 경험을 다음 시도에 반영합니다. CRITIC은 외부 도구나 검증 절차로 오류를 점검하는 방식입니다.

출처가 필요한 문서, 정책 검토, 데이터 기반 보고서처럼 틀리면 안 되는 작업에서는 이런 검증과 개선 루프가 특히 중요합니다.

실제 에이전트 시스템에서는 계획을 세우다가 도구를 쓰고, 절차를 실행 후 결과를 검증하면서 다시 수정하는 일이 이어집니다.

모든 자동화를 에이전트로 만들 필요는 없습니다

에이전트가 유용하다고 해서 모든 업무를 에이전트로 만들 필요는 없습니다. 많은 경우에는 고정된 워크플로우가 더 안전하고 빠릅니다.

예를 들어 매일 오전 9시에 정해진 데이터베이스에서 매출 수치를 가져와 같은 형식의 리포트를 만드는 작업을 생각해볼 수 있습니다. 이런 일은 굳이 에이전트가 필요하지 않을 수 있습니다. 순서가 명확하고 예외가 적으며, 판단 기준이 고정되어 있기 때문입니다. 사전에 정한 실행 흐름이 더 예측 가능하고 운영하기 쉽습니다.

다음과 같은 일이라면 에이전트 구조를 검토할 만합니다.

• 입력이 매번 다르고 비정형적일 때
• 어떤 도구를 써야 할지 상황에 따라 달라질 때
• 중간 결과를 보고 다음 행동을 바꿔야 할 때
• 예외 상황이 많아 고정 파이프라인으로 처리하기 어려울 때
• 사용자의 목표는 분명하지만 실행 경로가 열려 있을 때

이 작업의 다음 단계를 언어모델이 판단해야 하는가, 아니면 사람이 미리 정해둘 수 있는가?

언어모델이 상황에 따라 제어 흐름을 바꿔야 한다면 에이전트에 가깝습니다. 사람이 정한 경로를 그대로 따라가면 워크플로우입니다.

실제 서비스에서는 두 방식을 섞는 경우가 많습니다. 전체 흐름은 워크플로우로 관리하고, 검색어 선택이나 예외 처리처럼 판단이 필요한 구간에만 에이전트를 넣는 식입니다.

좋은 에이전트 설계는 “얼마나 자율적인가”보다 “어디까지 자율적이어야 하는가”를 묻는 데서 시작합니다.

좋은 에이전트는 도구와 경계가 분명합니다

에이전트가 실패하는 이유가 늘 모델 성능에만 있는 것은 아닙니다. 역할이 모호하거나, 도구 설명이 부실하거나, 종료 조건이 없거나, 권한 경계가 흐릿해도 쉽게 실패합니다.

예를 들어 업무 지원 에이전트에게 “Jira 이슈를 정리해줘”라고만 말하면, 에이전트는 조회만 해야 하는지, 상태를 바꿔도 되는지, 이슈를 삭제해도 되는지 판단하기 어렵습니다. 반대로 “이슈 삭제는 지원하지 않으며, 사용자가 요청해도 거절한다”처럼 경계를 명확히 주면 위험한 행동을 줄일 수 있습니다.

설계 단계에서는 적어도 이런 질문을 확인해야 합니다.

• 이 문제는 정말 에이전트로 풀어야 하는가?
• 에이전트가 반드시 해야 할 일과 하지 말아야 할 일은 무엇인가?
• 최종 결과물은 어떤 형태여야 하는가?
• 언제 작업을 끝냈다고 판단할 것인가?
• 모를 때는 계속 추론할 것인가, 멈추고 물어볼 것인가?
• 어떤 도구를 어떤 상황에서 사용해야 하는가?
• 사용자 승인 없이 실행하면 안 되는 행동은 무엇인가?

도구를 어떻게 설계하느냐도 품질에 큰 영향을 줍니다. 이름만 봐도 언제 써야 하는지 알 수 있어야 하고, 도구 하나는 되도록 하나의 역할만 맡는 편이 좋습니다. 반환값도 모델이 다시 읽고 판단하기 쉬워야 합니다.

많은 도구를 한꺼번에 붙이는 것보다, 적은 수의 도구를 명확하게 설계하는 편이 더 낫습니다. 사람에게 좋은 도구가 필요하듯, 에이전트에게도 사용하기 좋은 도구가 필요합니다.

결국 에이전트는 “실행을 맡기는 방식”의 문제입니다

AI 에이전트를 이해하려면 기술 용어보다 관점을 먼저 잡아야 합니다. 에이전트는 챗봇의 고급 버전도 아니고, 단순 자동화의 멋진 이름도 아닙니다.

에이전트는 목표를 받은 뒤 실행 흐름을 정하고, 도구를 호출하고, 결과를 본 뒤 필요하면 계획을 고칩니다. 그래서 설계할 때도 모델만 고르면 끝나지 않습니다. 실행 구조, 도구, 권한, 검증, 종료 조건을 함께 정해야 합니다.

AI 에이전트를 기획할 때는 “얼마나 똑똑한가”보다 “무엇을 어디까지 맡길 수 있는가”를 먼저 물어야 합니다.

좋은 에이전트는 아무 일이나 대신하는 AI가 아닙니다. 필요한 곳에서만 자율성을 갖고, 주어진 도구를 정확히 사용하며, 위험한 경계에서는 멈출 줄 아는 시스템입니다.

에이전트 시대의 첫 번째 설계 기준은 여기서 시작합니다.

다음 행동을 누가 결정해야 하는가?

이 질문에 답할 수 있어야, 에이전트를 제대로 만들고 제대로 쓸 수 있습니다.

그 다음 질문은 실행 환경으로 이어집니다.

모델이 실제 업무 환경에서 안전하게 행동하려면, 모델 바깥에는 무엇이 필요할까?

에이전트형 기능을 기획하거나 구상하고 있다면, 이제 모델 자체만이 아니라 모델 바깥의 실행 계층도 함께 봐야 합니다. 도구 실행, 권한, 세션, 로그, 복구, 평가 같은 요소는 프롬프트만으로 해결되지 않습니다.

다음 편에서는 에이전트가 실제 업무 환경에서 안전하고 정확하게 행동하도록 돕는 하네스 엔지니어링을 다룹니다.

AI 에이전트 시리즈