AI 에이전트의 진화: 루프는 출발점이자 종착점이다

AI 에이전트를 둘러싼 용어가 빠르게 늘어나고 있다. 루프, 하네스, 스웜, 오케스트레이터, 워커, MCP, A2A 같은 말이 한꺼번에 등장한다. 처음 보면 전부 새로운 유행어처럼 보이지만, 흐름을 따라가면 꽤 일관된 방향이 보인다. 다만 여기서 가장 조심해야 할 점이 있다. 루프는 단순히 첫 번째 단계가 아니다. 루프는 에이전트의 가장 작은 실행 단위이면서, 하네스와 스웜을 거친 뒤에도 최종적으로 남는 운영 원리다.

그러므로 AI 에이전트의 진화를 “루프 다음 하네스, 그다음 스웜”이라는 직선형 단계로만 이해하면 절반만 맞다. 더 정확히는 계층 구조에 가깝다. 작은 내부 루프가 생기고, 그 루프를 안전하게 감싸는 하네스가 필요해지고, 여러 개의 루프가 역할별로 나뉘어 스웜을 이루며, 마지막에는 전체 시스템이 관측, 평가, 개선을 반복하는 더 큰 운영 루프로 돌아온다.

이 변화의 핵심은 “모델이 더 똑똑해졌다”가 아니다. 모델은 중요하지만, 실제 업무에서 중요한 것은 모델을 둘러싼 시스템이다. 어떤 도구를 쓸 수 있는지, 어디까지 실행할 수 있는지, 실패하면 어떻게 멈추는지, 누가 검토하는지, 상태를 어떻게 저장하는지, 여러 에이전트가 어떻게 역할을 나누는지가 생산성을 결정한다. 개발자가 적응해야 할 지점도 여기에 있다. 앞으로 살아남는 개발자는 프롬프트를 잘 쓰는 사람을 넘어, 에이전트가 일할 수 있는 환경과 검증 루프를 설계하는 사람이 될 가능성이 크다.

루프는 시작점이다: 에이전트의 가장 작은 실행 단위

AI 에이전트의 출발점은 루프다. 루프는 간단히 말해 “생각하고, 도구를 실행하고, 결과를 관찰하고, 다시 판단하는 반복 구조”다. 사용자가 요청을 주면 모델이 다음 행동을 고른다. 파일을 읽거나, 검색하거나, 명령을 실행하거나, API를 호출한다. 그 결과가 다시 모델에게 들어가고, 모델은 다음 행동을 결정한다. 이 과정이 완료 조건에 도달할 때까지 반복된다.

OpenAI의 Swarm README도 핵심 실행 과정을 이런 식으로 설명한다. 현재 에이전트로부터 응답을 받고, 도구 호출을 실행하고, 필요하면 다른 에이전트로 전환하고, 컨텍스트 변수를 갱신하고, 더 이상 함수 호출이 없으면 반환한다. Anthropic 역시 에이전트를 “환경 피드백을 바탕으로 도구를 사용하는 LLM의 루프”로 설명한다. 표현은 다르지만 본질은 같다. 에이전트는 한 번의 답변이 아니라 반복되는 실행 구조다.

루프가 등장한 이유는 명확하다. 한 번의 프롬프트로는 복잡한 일을 끝내기 어렵기 때문이다. 소프트웨어 개발만 봐도 그렇다. 버그를 고치려면 코드를 읽고, 원인을 추론하고, 수정하고, 테스트하고, 실패 로그를 다시 읽어야 한다. 이 과정은 애초에 반복적이다. 사람 개발자도 한 번에 정답을 쓰는 것이 아니라 관찰과 수정을 반복한다. 에이전트 루프는 이 인간의 작업 리듬을 기계가 수행할 수 있게 만든 구조다.

하지만 루프만으로는 부족하다. 루프는 강력하지만 위험하다. 잘못된 목표를 받으면 잘못된 방향으로 계속 달릴 수 있다. 도구 권한이 과하면 파일을 망가뜨리거나 비용이 큰 API를 반복 호출할 수 있다. 종료 조건이 약하면 무한에 가까운 반복에 빠질 수 있다. 로그와 추적이 없으면 왜 그런 결정을 했는지 알기 어렵다. 그래서 다음 층이 필요해졌다. 루프를 감싸는 하네스다.

하네스는 루프를 제품으로 만들기 위한 실행 장치다

하네스는 표준화된 단일 제품명이라기보다, 에이전트 루프를 실제 서비스와 개발 업무에 넣기 위해 필요한 실행 장치 전체를 뜻하는 말로 이해하는 편이 좋다. 모델이 엔진이라면 하네스는 차체, 안전벨트, 계기판, 브레이크, 운전 기록 장치에 가깝다. 모델이 무엇을 할 수 있는지보다, 어떤 조건에서 어떻게 실행되고 어떻게 멈추는지가 중요해지는 단계다.

OpenAI Agents SDK의 핵심 개념을 보면 하네스가 무엇을 포함하는지 잘 드러난다. 에이전트는 지시문, 도구, 가드레일, 핸드오프를 갖는다. 실행에는 세션, 트레이싱, 인간 개입, 샌드박스 에이전트 같은 요소가 붙는다. LangGraph도 장기 실행, 상태 유지, 실패 후 재개, human-in-the-loop, 메모리, 디버깅과 배포를 주요 가치로 내세운다. MCP는 AI 애플리케이션이 외부 데이터, 도구, 워크플로에 표준 방식으로 연결되게 만든다. 이 모든 흐름은 같은 문제를 다룬다. “모델이 도구를 쓸 수 있다”에서 “모델이 통제 가능한 환경에서 일을 할 수 있다”로 이동하는 것이다.

하네스가 필요한 이유는 세 가지다.

권한 통제: 에이전트가 읽을 수 있는 데이터, 실행할 수 있는 명령, 호출할 수 있는 API를 제한해야 한다.
상태 관리: 긴 작업에서는 대화 기록, 파일 상태, 중간 산출물, 실패 지점을 보존해야 한다.
관측 가능성: 어떤 프롬프트, 어떤 도구 호출, 어떤 결과 때문에 최종 출력이 나왔는지 추적해야 한다.

개발자 관점에서 하네스는 “AI를 믿을 수 있게 만드는 코드”다. 테스트 없는 자동 코딩 에이전트는 빠른 사고를 낼 수 있다. 반대로 샌드박스, 테스트, 권한, 로그, 재시도 정책, 검토 지점을 갖춘 에이전트는 반복 업무를 안정적으로 줄여준다. 중요한 것은 하네스가 화려한 프레임워크라는 뜻이 아니라는 점이다. Anthropic은 오히려 성공적인 에이전트 구현이 복잡한 프레임워크보다 단순하고 조합 가능한 패턴에서 나온다고 말한다. 하네스의 목적은 복잡하게 만드는 것이 아니라, 실패를 다룰 수 있게 만드는 것이다.

워크플로는 루프를 어디까지 고정할지 정하는 설계다

에이전트가 유행하면서 모든 문제를 자율 에이전트로 풀어야 할 것처럼 보일 때가 있다. 하지만 실제로는 그 반대가 더 안전하다. Anthropic은 agentic system을 크게 워크플로와 에이전트로 나눈다. 워크플로는 LLM과 도구가 미리 정의된 코드 경로를 따라 움직이는 구조다. 에이전트는 LLM이 스스로 과정과 도구 사용을 동적으로 결정하는 구조다.

이 구분은 개발자에게 매우 중요하다. 많은 업무는 완전한 자율성이 필요 없다. 문서 초안 생성 후 검수, 고객 문의 분류 후 담당 프로세스로 전달, 코드 리뷰 체크리스트 실행, 보안 항목별 점검 같은 작업은 정해진 경로가 있다. 이런 경우에는 자율 에이전트보다 워크플로가 낫다. 예측 가능하고, 테스트하기 쉽고, 비용과 지연 시간도 관리하기 쉽다.

Anthropic이 제시한 대표 패턴도 실무적이다. 프롬프트 체이닝은 큰 작업을 순차 단계로 나눈다. 라우팅은 입력을 분류해 다른 경로로 보낸다. 병렬화는 여러 LLM 호출을 동시에 실행해 결과를 합친다. 오케스트레이터-워커는 중앙 LLM이 하위 작업을 동적으로 나누고 결과를 종합한다. 평가자-최적화자는 한 모델이 결과를 만들고 다른 모델이 평가와 피드백을 반복한다. 이 패턴들은 모두 루프를 어디까지 사람이 고정하고, 어디부터 모델에게 맡길지 결정하는 설계 언어다.

개발자가 적응하려면 “에이전트를 쓸 것인가”보다 “어디까지를 코드 경로로 고정하고, 어디부터를 모델 판단에 맡길 것인가”를 물어야 한다. 예를 들어 배포 파이프라인은 고정된 워크플로가 더 낫다. 반면 낯선 코드베이스에서 버그 원인을 탐색하는 일은 에이전트가 더 적합할 수 있다. 좋은 개발자는 모델의 자율성을 무조건 키우지 않는다. 필요한 만큼만 연다.

스웜은 여러 루프를 조율하는 구조다

스웜은 여러 에이전트가 협업하는 구조를 가리킨다. 단일 에이전트가 모든 일을 하도록 만드는 대신, 역할을 나눈다. 하나는 요구사항을 정리하고, 하나는 코드를 수정하고, 하나는 테스트를 만들고, 하나는 보안 위험을 검토하고, 하나는 문서를 정리할 수 있다. 또는 고객 지원에서 접수 에이전트가 환불, 기술 지원, 계정 문제 담당 에이전트로 넘길 수도 있다.

이때 스웜은 루프의 다음 단계라기보다 여러 루프를 묶는 조율 방식에 가깝다. 각 전문 에이전트는 자기 내부 루프를 가진다. 오케스트레이터는 전체 목표를 보고 어느 에이전트에게 넘길지 결정한다. 리뷰 에이전트는 구현 에이전트의 결과를 다시 평가 루프로 돌려보낸다. 따라서 스웜이 커질수록 루프가 사라지는 것이 아니라, 루프의 수와 층위가 늘어난다.

OpenAI Swarm은 이 흐름을 잘 보여준 실험적 프레임워크였다. Swarm은 에이전트와 핸드오프라는 두 가지 원시 개념을 중심으로, 가볍고 통제 가능한 다중 에이전트 조정을 탐색했다. 다만 현재 Swarm README는 Swarm이 교육용 실험 프레임워크이며, 프로덕션 용도에는 OpenAI Agents SDK로 이전하라고 안내한다. 이 사실 자체가 시장의 변화를 잘 보여준다. 다중 에이전트 아이디어는 남았지만, 이제는 교육용 실험에서 가드레일, 추적, 세션, 샌드박스가 포함된 운영 프레임워크로 이동하고 있다.

Microsoft AutoGen도 비슷한 흐름을 보여준다. AutoGen은 다중 에이전트 애플리케이션을 만드는 대표적 프레임워크였지만, 현재 README는 유지보수 모드로 전환되었고 신규 사용자는 Microsoft Agent Framework를 권장한다고 말한다. 이 역시 단순한 프레임워크 교체가 아니다. 초기의 다중 에이전트 실험이 엔터프라이즈급 오케스트레이션, 멀티 프로바이더 모델 지원, MCP와 A2A 같은 상호운용성으로 이동하고 있다는 신호다.

스웜이 필요한 이유는 단일 프롬프트가 과부하되기 때문이다. 하나의 에이전트에게 제품 기획자, 백엔드 개발자, 프론트엔드 개발자, QA, 보안 리뷰어, 문서 작성자 역할을 모두 맡기면 지시문이 길어지고 책임이 흐려진다. 반면 역할을 나누면 각 에이전트의 도구, 권한, 평가 기준을 좁힐 수 있다. 테스트 에이전트는 테스트와 로그에 집중하고, 보안 에이전트는 권한과 입력 검증에 집중하며, 오케스트레이터는 전체 작업을 나누고 합친다.

하지만 스웜은 공짜가 아니다. 에이전트가 많아질수록 조정 비용이 커진다. 서로 다른 에이전트가 같은 파일을 다르게 해석할 수 있고, 책임이 분산되어 오류 원인을 찾기 어려워질 수 있다. 병렬 실행은 빠르지만 합치는 단계에서 충돌이 생긴다. 여러 모델 호출은 비용과 지연 시간을 늘린다. 따라서 스웜은 “멋져 보여서” 쓰는 구조가 아니라, 단일 에이전트나 단순 워크플로로는 분명히 부족할 때 선택해야 한다.

MCP와 A2A는 루프들이 연결되는 방식을 표준화한다

에이전트가 도구를 쓰고 서로 협업하기 시작하면, 다음 문제는 연결 방식이다. 모든 앱이 각자 다른 방식으로 도구를 붙이면 개발 비용이 폭증한다. 모든 에이전트가 서로 다른 메시지 형식으로 대화하면 협업도 어렵다. 그래서 표준화가 중요해졌다.

MCP(Model Context Protocol)는 AI 애플리케이션과 외부 시스템을 연결하는 오픈소스 표준이다. 공식 문서는 MCP를 AI 애플리케이션을 데이터 소스, 도구, 워크플로에 연결하는 표준 방식으로 설명한다. 개발자 입장에서는 같은 도구 서버를 여러 AI 클라이언트에서 재사용할 수 있다는 점이 중요하다. 파일, 데이터베이스, 검색, 브라우저, 디자인 도구, 사내 API를 모두 모델별 커스텀 통합으로 만들 필요가 줄어든다.

A2A(Agent2Agent)는 다른 방향의 표준화다. Google은 A2A를 서로 다른 벤더와 프레임워크로 만든 에이전트들이 협업하고 정보를 교환할 수 있게 하는 오픈 프로토콜로 소개했다. MCP가 에이전트와 도구 사이의 연결을 표준화한다면, A2A는 에이전트와 에이전트 사이의 협업을 표준화하려는 시도다. Google은 A2A가 MCP를 보완한다고 설명한다. 하나는 도구와 컨텍스트, 다른 하나는 에이전트 간 작업 위임과 상호운용성에 초점이 있다.

이 흐름은 개발자에게 중요한 메시지를 준다. AI 에이전트 개발은 더 이상 “LLM API를 한 번 호출하는 코드”가 아니다. 도구 서버, 권한 모델, 상태 저장, 이벤트 스트리밍, 장기 실행 작업, 인간 검토, 에이전트 간 계약을 다루는 분산 시스템 개발에 가까워지고 있다. AI를 잘 쓰는 개발자보다, AI가 일할 수 있는 운영 환경을 잘 만드는 개발자가 더 중요해진다.

결국 루프가 마지막이기도 하다

단계별로 보면 루프가 마지막 아니냐는 질문은 정확한 지적이다. 내부 실행 원리로서 루프는 처음에 등장하지만, 성숙한 운영 모델로서 루프는 마지막에 다시 등장한다. 차이는 루프의 크기다.

초기 루프는 한 에이전트가 도구를 쓰며 문제를 푸는 실행 루프다. 성숙한 루프는 시스템 전체가 관측, 평가, 개선을 반복하는 운영 루프다. 에이전트가 작업을 수행하고, 하네스가 로그와 결과를 남기고, 평가자가 품질을 측정하고, 개발자가 실패 패턴을 반영해 도구와 지시문과 테스트를 개선한다. 이 전체가 다시 다음 실행 품질을 높인다.

따라서 더 정확한 진화 표현은 이렇게 정리할 수 있다.

단일 호출: 모델이 한 번 답한다.
도구 사용 루프: 모델이 관찰, 행동, 피드백을 반복한다.
하네스: 루프에 권한, 상태, 샌드박스, 로그, 가드레일을 붙인다.
워크플로: 반복 구조 중 예측 가능한 부분을 코드 경로로 고정한다.
스웜: 여러 전문 루프를 역할별로 나누고 조율한다.
운영 루프: 실행 결과를 평가하고 시스템 자체를 계속 개선한다.

이 관점에서 루프는 첫 단계이자 마지막 단계다. 처음에는 에이전트 한 개의 작동 방식으로 나타나고, 마지막에는 조직과 시스템 전체의 학습 방식으로 확장된다.

왜 이런 방향으로 진화하는가

첫째, 실제 업무는 열린 문제다. 사용자의 요청은 대개 모호하고, 필요한 단계 수를 미리 알기 어렵다. 소프트웨어 개발에서는 수정해야 할 파일 수, 영향 범위, 테스트 전략을 처음부터 정확히 알 수 없다. 그래서 루프와 동적 계획이 필요하다.

둘째, 모델의 자율성은 위험을 함께 키운다. 도구를 쓰는 모델은 단순 텍스트 생성 모델보다 훨씬 강력하지만, 그만큼 사고 범위도 커진다. 파일 삭제, 잘못된 배포, 민감 정보 노출, 비용 폭증, 잘못된 외부 호출을 막으려면 하네스가 필요하다.

셋째, 전문화가 필요하다. 하나의 모델 호출에 모든 역할을 넣으면 지시문이 복잡해지고 성능이 불안정해진다. Anthropic이 말하는 라우팅, 병렬화, 오케스트레이터-워커, 평가자-최적화자 패턴은 이 문제를 줄이는 방식이다. 스웜은 그 연장선에 있다.

넷째, 기업 환경에서는 상호운용성이 중요하다. 사내 시스템은 여러 클라우드, SaaS, 데이터베이스, 권한 체계로 나뉘어 있다. 에이전트가 실제 업무를 하려면 이 환경을 건너다닐 수 있어야 한다. MCP와 A2A 같은 표준은 이 비용을 낮추려는 시도다.

개발자는 어떻게 적응해야 하는가

첫째, 코딩 능력만이 아니라 작업 설계 능력을 키워야 한다. 에이전트에게 좋은 일을 맡기려면 문제를 실행 가능한 단위로 쪼개야 한다. “이 기능 만들어줘”가 아니라, 목표, 제약, 수정 범위, 테스트 방법, 완료 기준을 명시해야 한다. 개발자는 이제 작업 티켓을 사람이 읽는 문서이자 에이전트가 실행할 사양으로 작성해야 한다.

둘째, 테스트와 관측성을 기본값으로 삼아야 한다. 에이전트가 만든 코드는 빠르게 늘어난다. 이 속도를 품질로 바꾸는 유일한 방법은 검증 루프다. 단위 테스트, 타입 검사, 린트, 통합 테스트, 보안 스캔, 로그, 트레이스, 롤백 절차가 없는 팀은 AI로 더 빨라지는 것이 아니라 더 빨리 불안정해질 수 있다.

셋째, 도구를 API가 아니라 계약으로 설계해야 한다. 에이전트가 사용할 도구는 사람용 CLI보다 더 명확해야 한다. 입력 스키마, 권한, 실패 메시지, 부작용, 재시도 가능 여부가 분명해야 한다. 좋은 MCP 서버나 내부 도구는 에이전트에게 “할 수 있는 일”뿐 아니라 “하면 안 되는 일”도 알려준다.

넷째, 하네스를 직접 이해해야 한다. 어떤 프레임워크를 쓰든 세션, 메모리, 샌드박스, 가드레일, human-in-the-loop, 트레이싱, 비용 제한, 실행 시간 제한, 비밀 관리가 어떻게 동작하는지 알아야 한다. 이것을 모르면 에이전트를 운영할 수 없다. 앞으로 개발자는 프롬프트 작성자라기보다 에이전트 런타임 엔지니어에 가까워진다.

다섯째, 스웜을 성급히 도입하지 말아야 한다. 스웜은 강력하지만 복잡하다. 먼저 단일 루프를 안정화하고, 그 다음 워크플로를 만들고, 그 다음 하네스를 강화한 뒤, 정말 필요한 역할만 분리해야 한다. 좋은 순서는 “단일 호출 → 도구 사용 루프 → 하네스 → 워크플로 → 제한된 멀티 에이전트 → 운영 개선 루프”다. 처음부터 스웜으로 가면 디버깅할 수 없는 시스템이 되기 쉽다.

실무 적용 로드맵

1주차에는 개인 업무에서 작은 루프를 익힌다. 작은 버그 수정, 문서 정리, 테스트 초안 작성처럼 실패 비용이 낮은 일을 에이전트에게 맡긴다. 단, 항상 결과를 읽고 diff를 검토한다. 목표는 자동화가 아니라 실패 패턴을 파악하는 것이다.

2주차에는 하네스를 만든다. 로컬 샌드박스, 테스트 명령, 금지 파일, 코드 스타일, 보안 체크리스트를 정리한다. 에이전트가 작업을 시작하기 전에 읽어야 할 문서와 실행해야 할 검증 명령을 고정한다. 가능하면 작업별 템플릿을 만든다.

3주차에는 워크플로를 설계한다. 예를 들어 “이슈 분석 → 계획 → 테스트 추가 → 구현 → 검증 → 변경 요약”을 단계로 나누고, 각 단계에서 사람이 승인할지 자동으로 넘어갈지 정한다. 모든 단계를 자율 에이전트에게 맡기지 말고, 위험한 단계에는 중단 지점을 둔다.

4주차에는 제한된 멀티 에이전트를 시도한다. 코드 작성 에이전트와 리뷰 에이전트를 분리하거나, 구현 에이전트와 테스트 에이전트를 나눈다. 이때 중요한 것은 역할 이름이 아니라 평가 기준이다. 리뷰 에이전트가 무엇을 통과시켜야 하는지, 테스트 에이전트가 어떤 실패를 잡아야 하는지 명확히 해야 한다.

5주차 이후에는 운영 개선 루프를 만든다. 어떤 작업에서 에이전트가 자주 실패했는지, 어떤 테스트가 부족했는지, 어떤 도구 설명이 모호했는지, 어떤 권한이 과했는지를 기록한다. 그리고 그 결과를 다시 프롬프트, 도구, 테스트, 런북에 반영한다. 이 단계에서 루프는 더 이상 에이전트 내부의 반복만이 아니다. 개발 조직의 학습 시스템이 된다.

개발자의 역할은 사라지는 것이 아니라 위로 이동한다

AI 에이전트의 진화는 개발자를 불필요하게 만드는 흐름이 아니다. 단, 개발자가 하던 일의 일부를 기계가 맡게 만드는 흐름은 맞다. 반복적인 코드 작성, 검색, 초안 작성, 테스트 보강, 변경 요약은 점점 에이전트에게 넘어간다. 남는 일은 더 어렵다. 문제를 정의하고, 시스템을 설계하고, 권한을 제한하고, 실패를 검증하고, 최종 책임을 지는 일이다.

루프는 에이전트가 일하는 기본 리듬이다. 하네스는 그 리듬을 안전하게 만든다. 스웜은 여러 리듬을 조율해 더 큰 일을 처리하게 한다. MCP와 A2A는 그 조율이 특정 도구나 벤더에 갇히지 않도록 만드는 표준화의 방향이다. 그리고 마지막에는 다시 루프가 남는다. 관측하고, 평가하고, 고치고, 다시 실행하는 운영 루프다.

앞으로 좋은 개발자는 AI를 많이 쓰는 사람이 아니라, AI가 잘못 일할 수 있는 조건을 먼저 발견하는 사람이다. 그리고 그 조건을 테스트, 권한, 로그, 프로토콜, 작업 설계로 줄이는 사람이다. 에이전트 시대의 생존 전략은 AI에게 일을 던지는 것이 아니다. AI가 책임 있게 일할 수 있는 구조를 만들고, 그 구조를 계속 개선하는 루프를 운영하는 것이다.