AI agent는 사람이 매번 질문을 던지지 않아도 스스로 다음 행동을 정하며 일을 끝까지 밀고 가는 프로그램입니다. 구조만 보면 생각보다 단순합니다. 언어 모델을 반복문 안에 넣고 외부 도구를 쥐여 주면 됩니다. 그래서 그럴듯한 시연은 금방 만들 수 있습니다. 어려운 일은 그다음입니다. 클라우드에서 쉬지 않고 돌리고, 무엇을 했는지 기록하고, 점수로 평가하고, 실패를 하나씩 고쳐 믿고 맡길 수준까지 끌어올리는 일이 실제 엔지니어링의 대부분을 차지합니다.
사람이 돌리던 반복을 agent가 맡는다
기존의 언어 모델 활용 방식을 떠올려 보면 차이가 분명합니다. 예를 들어 React 컴포넌트를 만들고 싶은 사람은 prompt(모델에 주는 지시문)를 입력하고, 모델의 답을 읽고, 부족하면 다시 질문합니다. 결과가 만족스러울 때까지 질문과 답을 오가는 반복을 사람이 직접 운전합니다.
AI agent는 이 반복을 자동으로 돌립니다. 사람은 처음 목표만 줍니다. 그다음부터는 agent가 매 단계에서 최종 답을 낼지, 도구를 호출할지 스스로 정합니다. 도구를 호출했거나 중간 결과가 나오면 그 결과가 다시 맥락으로 들어가 다음 판단의 재료가 됩니다. 이 순환을 agentic loop라고 부르며, 한 번에 끝날 수도 있고 여러 번 돌 수도 있습니다. agent가 일을 마쳤다고 판단하면 반복이 멈춥니다.
| 구분 | 기존 언어 모델 활용 | AI agent |
|---|---|---|
| 반복을 이끄는 쪽 | 사람 | agent |
| 다음 행동 결정 | 사람이 다음 질문을 입력 | 답을 낼지 도구를 쓸지 agent가 판단 |
| 중간 결과 처리 | 사람이 읽고 판단 | 다음 반복의 맥락으로 자동 투입 |
| 끝나는 시점 | 사람이 만족할 때 | agent가 완료라고 판단할 때 |
핵심은 두 가지, 반복 구조와 도구
agent의 뼈대는 두 가지 생각으로 정리됩니다.
첫째는 agentic loop입니다. 프로그램 안의 while 반복문 같은 제어 구조로 언어 모델을 감싸고, 종료 조건이 올 때까지 계속 돌립니다. 모델이 ’완료’를 뜻하는 정해진 표시를 내면, 바깥 코드가 이를 규칙대로 읽어 반복을 끊습니다.
둘째는 도구입니다. 언어 모델은 원래 글자만 내놓습니다. 그런데 structured output(정해진 형식에 맞춘 출력)을 쓰면 바깥 코드가 모델의 출력을 함수의 인자로 해석할 수 있습니다. 이 출력이 실제 소프트웨어 함수를 실행시키면서 agent는 API를 호출하고, 웹을 검색하고, 데이터베이스를 조회하고, 셸 명령을 실행합니다. 글을 예측하던 모델이 바깥세상에 실제 변화를 만드는 행위자가 되는 지점이 여기입니다.
직무에 맞춘 agent, ‘AI 직원’
범용 agent를 만들 수 있게 되면 다음 단계는 특정 직무에 맞춘 agent입니다. 이를 AI 직원으로 볼 수 있습니다. AI 직원은 맡은 일의 범위, 쓸 수 있는 도구, 일하는 환경이 그 직무에 맞게 좁혀져 있다는 점에서 일반 agent와 다릅니다.
- 소프트웨어 엔지니어: 파일 시스템, 코드 편집 도구, 코드를 올리고 검토할 GitHub 접근 권한을 주고, 저장소를 스스로 탐색하고 수정하고 시험할 수 있는 격리된 환경을 마련합니다.
- 영업 담당자: CRM(고객 관리 시스템), Gmail 같은 이메일 도구, 웹 검색을 주어 잠재 고객을 조사하고 연락하게 합니다.
- 고객 지원: 같은 방식으로 역할에 맞는 도구와 환경을 설계할 수 있는 직무입니다.
결국 AI 직원을 만드는 일은 조직의 구조를 분석해 역할마다 알맞은 도구를 갖춘 agent 환경을 따로 설계하는 일에 가깝습니다.
▲ 직무별로 도구를 갖춘 AI 직원
시연은 쉽고 운영은 어렵다
언어 모델을 단순한 반복문에 연결하고 간단한 도구 몇 개를 붙이는 일은 agent 개발용 framework(미리 만들어 둔 소프트웨어 틀)로 금방 끝납니다. 그러나 특정 작업을 위해 처음 만든 agent는 품질이 낮을 수밖에 없습니다. 일 못하는 직원 수준의 agent를 시니어 엔지니어처럼 믿고 맡길 수준으로 끌어올리려면 그 주변에 여러 체계를 갖춰야 합니다. 엔지니어링, 영업, 고객 지원 등 어떤 직무의 agent든 같은 과제입니다.
| 항목 | 해결해야 할 문제 |
|---|---|
| 배포 | 오래 돌아가는 agent일수록 클라우드에서 안정적으로 유지하기가 훨씬 어렵습니다 |
| 관측 가능성 | agent가 맡은 일을 제대로 하는지, 엉뚱한 답을 지어내거나 궤도를 벗어나지 않는지 확인해야 합니다 |
| telemetry(운영 중 자동으로 모으는 실행 데이터) | 하루 24시간 도는 agent는 실행 기록을 엄청나게 쏟아내므로 잡음 속에서 의미 있는 신호를 골라내야 합니다 |
| 평가 | 수치로 매기는 평가(eval)와 사람의 감독을 함께 두어 현재 실력을 정확히 점검합니다 |
| 버전 관리 | 두 버전을 실제 운영 환경에서 동시에 돌리는 A/B 테스트로 개선 효과를 확인한 뒤 전면 적용합니다 |
| 개선 반복 | 실행 경로를 trace(작업 한 번의 전체 실행 기록)와 span(그 안의 단계별 기록) 단위로 남기고 평가 묶음으로 채점해 실패 유형을 하나씩 넘어섭니다 |
telemetry는 많이 모은다고 좋은 것이 아닙니다. 걸러 내는 장치 없이 쌓기만 하면 오히려 개선에 쓸 신호를 찾기 어려워질 수 있습니다. 또 개선 반복에는 끝이 없습니다. 운영 중인 agent는 평가와 추적, 수정을 계속 되풀이해야 합니다.
로컬 시제품에서 믿을 만한 agent까지 여섯 단계
직접 만들어 보며 배우는 방식을 권할 만합니다. 순서는 다음과 같습니다.
- 로컬에서 하나 만들기: 내 컴퓨터에서 도구를 호출할 수 있는 agentic loop를 짜고 간단한 일을 맡깁니다.
- 배포하기: 클라우드로 옮겨 컴퓨터를 꺼도 하루 24시간 돌게 합니다. 팀원과 권한을 받은 사람이 언제든 agent와 소통하고 지켜볼 수 있습니다.
- 관찰하기: agent가 무엇을 했고 어떤 이력을 거쳤으며 맡은 일을 충실히 했는지 답할 수 있는 관측 체계를 만듭니다.
- 평가하기: 예를 들어 시나리오 100개짜리 시험을 돌려 신뢰도를 숫자로 매깁니다. 100개 중 90개를 통과했다면 나머지 10개가 살펴볼 실패 사례입니다.
- 개선하기: 찾아낸 실패 유형을 하나씩 고칩니다.
- 믿을 만하게 만들기: 관찰, 평가, 개선을 되풀이해 실제 운영에 쓸 수 있는 신뢰도에 이를 때까지 반복합니다.
agent 하나를 이 수준까지 끌어올렸다면 첫 번째 제대로 된 AI 직원을 만들 기초를 갖춘 셈입니다.
AI 직원 여럿이 모이면 ‘AI 회사’
믿을 만한 AI 직원을 하나 만들 수 있게 되면 여러 agent가 함께 일하는 조직으로 넓힐 수 있습니다. 이때 병목은 개별 agent의 논리에서 agent 사이의 조율과 구조의 확장성으로 옮겨 갑니다.
여기서 주의할 점은 AI 직원을 하나씩 따로 만들지 않는 것입니다. 모든 agent가 공통 기반과 통합된 인프라 계층을 함께 쓰게 하면 같은 작업을 되풀이하지 않고도 여러 agent를 일관되게 만들고 설정하고 운영할 수 있습니다. 많은 기술 기업이 AI agent 플랫폼에 크게 투자하는 것도 이런 조율 수요 때문으로 볼 수 있습니다.
이런 조직에서는 사람과 AI 직원이 각자 잘하는 일을 나눠 맡게 될 것으로 보입니다. AI 직원은 대량의 데이터를 읽고 요약하고 종합하는 반복적인 후방 업무에 강합니다. 사람은 창의적이고 전략적인 일, 사람만 할 수 있는 일에 집중하면서 agent들의 협업이 회사 목표를 향하도록 감독합니다.
▲ 공통 기반 위의 AI 회사
실제로 여러 agent를 묶은 서비스의 예로 취업 준비를 돕는 플랫폼을 들 수 있습니다. 이력서 코칭 agent는 올린 이력서에서 졸업 시기나 학교 정보 같은 빠진 내용을 찾아 지적하고 문장을 고쳐 줍니다. 면접 준비 agent들은 코딩, 시스템 설계, 인성 면접을 나눠 맡고, 코딩 시험은 문제 2개, 60분, 프로그래밍 언어 3종으로 구성됩니다. 사용자가 초보 학생 역할의 agent에게 이진 탐색 같은 개념을 가르치게 하고, 코드 숙련도와 설명의 정확성을 점수로 매기는 agent도 있습니다. 이 agent들을 이어 지원부터 취업까지 한 흐름으로 안내하는 것이 이 플랫폼의 목표입니다.
정리: 시연보다 운영 체계에 시간을 쓰자
AI agent는 언어 모델을 반복 구조에 넣고 도구를 쥐여 준 프로그램이며, 구조 자체는 단순합니다. 차이는 그 주변에서 납니다. 지금 agent를 만들고 있다면 다음 순서를 권합니다.
- 도구 호출이 되는 작은 agentic loop를 로컬에서 직접 짜 봅니다.
- 이른 시점에 클라우드로 옮겨 하루 24시간 돌게 하고, 실행 경로를 trace와 span으로 남깁니다.
- 반복해서 돌릴 수 있는 평가 묶음을 만들어 점수로 비교하고, 실패 사례부터 고칩니다.
- 새 버전은 A/B 테스트로 이전 버전과 비교한 뒤 바꿉니다.
- agent를 여럿 둘 계획이라면 처음부터 공통 기반을 함께 쓰게 설계합니다.
시연이 잘 돌아간다는 것은 출발점일 뿐입니다. 관찰하고 평가하고 고치는 체계를 먼저 갖추는 쪽이 믿고 맡길 agent에 더 빨리 닿는 길로 보입니다.