AI 에이전트
에이전트는 질문과 응답을 주고받는 단순한 반복에서, 밤사이 스스로 과제를 밀고 나가는 장기 실행 주체로 옮겨가고 있다. 그 전환이 무엇을 바꾸는지 정리한다.
2026년 7월 2일
불과 얼마 전까지 'AI 에이전트'라는 말은 소박한 뜻이었다. 사람이 질문을 던지면 모델이 답하고, 그 답을 받아 다시 다음 질문을 넣는 반복 고리(prompting loop) 정도였다. 지금의 에이전트는 그보다 훨씬 무겁다. 외부 시스템과 내부 도구, 민감한 데이터에 직접 접근하고, 사람의 개입 없이 몇 분에서 몇 시간씩 스스로 작업을 이어간다. 접근 권한이 커진 만큼 권한 관리와 관찰(observability), 중간 조종(steering)이 함께 필요해졌다.
이 변화의 상징적인 장면이 하나 있다. 잠자기 전에 밀린 일감과 버그 목록을 에이전트에 맡겨 두면, 아침에 일어났을 때 백로그가 정리되고 버그가 잡혀 있다는 것이다. 아직은 과장 섞인 이상에 가깝지만, 장기 실행 에이전트가 어디로 향하는지는 분명히 보여준다. 일하는 시간의 한계가 '개인의 처리 용량'이 아니라 '한 번에 얼마나 위임할 수 있는가'로 옮겨간다는 발상이다.
에이전트를 뜯어보면 밑바탕 부품은 예나 지금이나 크게 셋이다. 지능을 담당하는 모델, 행동과 안전 규칙을 정의하는 시스템 프롬프트, 그리고 그 둘을 감싸 실제 작동을 이끄는 하네스(harness)다. 달라진 것은 우리가 에이전트에 시키는 일의 난도이며, 그만큼 하네스의 정교함도 올라갔다.
하네스는 모델 주위를 감싸는 뼈대다. 모델이 도구를 실행하고, 기억(메모리)을 불러오고, 언제 사람에게 판단을 물어야 하고 언제 그냥 계속 실행해도 되는지를 결정하게 해 준다. 토큰을 넣으면 토큰이 나오는 무작위 샘플링을, 실제로 쓸 수 있는 제품 수준의 행동으로 끌어올리는 것이 바로 이 하네스의 역할이다.
모델이 '숙련된 일꾼'이라면, 하네스는 그 일꾼이 일하는 작업대와 안전장비다. 연장을 어디서 집고, 위험한 작업 전에는 관리자에게 확인을 받고, 실수하면 되돌리는 절차가 작업대에 배어 있다. 같은 일꾼이라도 작업대가 잘 짜여 있으면 훨씬 복잡한 일을 안전하게 해낸다.
모델과 하네스를 따로 개발할 수 있느냐는 물음에는, 만드는 쪽의 답이 대체로 일관된다. 최대 성능은 둘을 함께 묶어야만 나온다는 것이다. 모델의 성능을 평가하려면 반드시 어떤 하네스 위에서 돌려 봐야 하고, 세상의 모든 하네스를 시험할 수는 없으니 결국 자신이 만든 하네스로 측정하게 된다. 이 필연성이 모델과 하네스를 붙여 놓는다.
다만 하네스의 두께는 고정된 것이 아니라 모델이 똑똑해질수록 얇아진다. 실제로 Anthropic은 자사 엔지니어링 기록에서, Claude Sonnet 4.5가 컨텍스트 한계가 다가오는 것을 감지하면 작업을 서둘러 마무리해 버리는 이른바 '컨텍스트 불안(context anxiety)' 현상을 하네스에 컨텍스트 리셋을 추가해 해결했다고 밝혔다. 그런데 같은 하네스를 더 강한 Claude Opus 4.5에 얹었더니 그 행동 자체가 사라져 있었다. 모델이 나아지면 하네스가 떠안고 있던 가정 중 일부는 낡아 버린다는 뜻이다.
이 흐름 위에서 Anthropic은 2026년 4월 8일 Claude Managed Agents를 공개 베타로 내놓았다. Claude Platform에서 장기 실행 에이전트를 대신 돌려 주는 호스팅 서비스로, 에이전트를 직접 만들 때 늘 발목을 잡던 요소들을 플랫폼이 떠맡는 것이 핵심이다. 격리된 샌드박스에서의 코드 실행, 중간 저장(checkpointing), 자격 증명 관리, 범위가 제한된 권한, 그리고 실행 전 과정의 추적(tracing)이 그것이다. 사용자는 에이전트가 할 일과 쓸 도구, 지켜야 할 가드레일만 정의하면 된다.
직접 에이전트를 운영하는 것은 식당을 열기 위해 주방 배관과 전기, 소방 설비부터 손수 까는 것과 같다. 정작 손님이 먹는 요리(에이전트가 실제로 하는 일)와는 무관한 공사에 몇 달이 든다. Managed Agents는 그 설비가 이미 깔린 주방을 빌려 주는 셈이라, 요리 자체에 집중할 수 있다.
가격은 표준 토큰 요금에 더해 활성 실행 시간당 0.08달러(session-hour)가 붙는 소비 기반이다. 흔히 인용되는 '10배 빠르게'라는 표현은 모델 성능이 아니라 개발 속도를 가리킨다. Anthropic 자체 시험에서는 구조화된 파일 생성 과제에서 단순 프롬프트 루프 대비 작업 성공률이 최대 10%포인트가량 올랐고, 어렵고 복잡한 과제일수록 이득이 컸다고 한다. Notion, Rakuten, Asana, Sentry 같은 팀이 코딩·업무 자동화·문서 처리에 이미 쓰고 있다.
이 서비스의 설계 사상은 '두뇌와 손의 분리'로 요약된다. 세션(일어난 모든 일의 기록), 하네스(모델을 호출하고 도구 호출을 라우팅하는 고리), 샌드박스(연산이 이뤄지는 공간)를 각각 추상화해, 그 위에 얹히는 구현이 바뀌어도 인터페이스는 그대로 유지되게 했다. 운영체제가 하드웨어를 프로세스·파일 같은 추상으로 감싸 오래 살아남게 했던 방식과 같다. 여러 개의 두뇌(brains)와 여러 개의 손(hands)으로 확장하는 것도 전제로 삼는다. 여러 에이전트가 다른 에이전트를 띄워 작업을 병렬화하는 다중 에이전트 조율과, 성공 기준을 주면 스스로 채점하며 반복하는 자기 평가는 아직 별도 신청이 필요한 리서치 프리뷰 단계다.
에이전트가 실제 세계에 손을 뻗는 방법은 크게 세 가지다. 첫째는 웹 검색·코드 실행·파일 조작 같은 내장 도구다. 둘째는 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)로, 외부 서비스와 통신하는 표준화된 방식이면서 앞단에 인증 계층을 둔다. 아무나 접근하면 곤란한 사내 데이터베이스에 에이전트를 안전하게 연결할 때 쓰인다. 셋째는 스킬(Skills)이다.
MCP가 여러 기기를 꽂아 쓰는 표준 콘센트라면(어떤 서비스든 규격만 맞으면 안전하게 연결), 스킬은 신입에게 건네는 업무 매뉴얼이다. 매뉴얼에는 절차와 예시, 참고 자료가 담겨 있고, 필요한 대목만 펼쳐 보면 된다.
스킬의 작동 원리가 '점진적 공개(progressive disclosure)'다. 매뉴얼을 통째로 외우는 대신 목차부터 보고, 관련 장을 펼치고, 세부는 필요할 때 부록에서 찾는 방식이다. 에이전트가 시작할 때 컨텍스트에는 각 스킬의 이름과 한 줄 설명(메타데이터)만 올라간다. 그 작업에 맞는 스킬이라고 판단되면 그제야 전체 지침(SKILL.md)을 읽고, 실제 실행 단계에서만 참조 파일과 스크립트, 데이터를 불러온다. 덕분에 방대한 지식을 담아도 컨텍스트 창이 과부하되지 않는다. 스킬은 2025년 12월 18일 개방형 표준으로 공개되어 여러 플랫폼으로 퍼졌다.
에이전트를 만들 때 오늘날 가장 어려운 부분은 평가다. 과제가 복잡해지면서 전통적 평가 방식도 진화하고 있다. 여전히 통하는 기본형은 초기 프롬프트 묶음과 기대 결과를 정해 두고 비교하는 것이다. 여기에 여러 단계로 이어지는 상호작용을 재생(replay)하거나, 같은 사용자 조작 흐름을 서로 다른 버전에 넣어 반응 차이를 보는 A/B 시험 같은 정교한 기법이 더해진다.
평가의 종류도 갈린다. 통과·실패를 가리는 이진 평가, LLM(Large Language Model, 대규모 언어모델)이 채점관 역할을 맡아 등급을 매기는 점수형 평가, 그리고 특정 행동이 제때 촉발됐는지 확인하는 트리거 평가가 함께 쓰인다. 예컨대 스킬이 적절한 순간에 제대로 발동하는지는 초기부터 공들여 점검한 부분이다. 더 나아가 에이전트가 자기 결과물을 스스로 채점하게 만들면, 평가를 세션 바깥이 아니라 작업 흐름 안으로 끌어들일 수 있다. 편향을 줄이려면 채점을 별도의 맥락(컨텍스트 창)에서 돌리는 편이 낫다.
다만 처음부터 정교한 평가에 매달릴 필요는 없다. 실제로 써 보며 느낌을 확인하는 '바이브 테스트'가 가장 중요한 첫 단계이고, 규모가 커져 느낌을 수치로 모으기 어려워지는 지점에서 비로소 정식 평가로 넘어가는 순서가 자연스럽다.
프롬프트 설계의 무게중심도 옮겨갔다. 한때는 출력이 정해진 형식(예: 특정 JSON 구조)을 엄격히 따르도록 지시하고, 그 조각들을 사람이 접착제 코드로 이어 붙여 화면에 그럴듯하게 렌더링했다. 모델이 유능해지고 하네스가 진화하면서, 이제는 '결과물 그 자체'가 사실상의 출력 규격이 된다.
세세한 구조를 일러 주는 대신, "이런 풍부하고 상호작용적인 결과물을 만들라"고 목표와 성공 기준을 던지고 나머지는 에이전트가 스스로 교정하며 도달하게 하는 것이다. 슬라이드나 콘텐츠 생성처럼 '무엇이 좋은 결과인가'를 안목으로 정의하는 작업, 또는 예측 모델이 특정 정확도(가령 90%)에 이를 때까지 반복하게 하는 작업에서 특히 유용하다. 자율적으로 도는 인프라가 갖춰졌기에, 중간 산출물을 사람이 일일이 엮지 않아도 에이전트가 경로를 스스로 바로잡는다.
지시의 언어가 "이 형식을 지켜라"에서 "이 결과에 도달하라"로 바뀐다. 형식은 수단으로 내려가고, 목표와 판단 기준이 앞으로 나온다.
에이전트를 개발하는 조직 내부의 활용은 '깊이'라는 말로 설명된다. 코드베이스에 대한 접근이 가장 큰 해방이었다는 것이다. 엔지니어들을 일일이 찔러보지 않고도 PR(Pull Request, 코드 병합 요청)이 병합됐는지 배포됐는지 직접 추적하고, 제품이 정확히 어떻게 동작하는지 코드베이스에 직접 물어 이해한다. 고객 제안요청서(RFP, Request for Proposal)의 보안 점검 항목을 채우거나, 현장 문제를 진단하고, 막힌 사용자를 풀어 주는 일까지 훨씬 수월해진다.
운영 방식에서는 '항상 켜져 있음'과 '능동성'이 강조된다. 정해진 시각에 도는 예약 실행으로 지난주 활동을 요약하게 하거나, 여러 Slack 채널을 지켜보며 고객 반응을 정리하게 한다. 필요할 때 부르면 답하는 것을 넘어, 좋은 동료라면 그러하듯 먼저 필요한 것을 끌어와 보여 주는 방향이다. 이런 능동성은 예약 실행과 트리거 이벤트, 그리고 데이터를 끊임없이 갱신해 늘 최신 맥락을 쥐고 있게 하는 것으로 구현된다.
흥미로운 고백도 있다. 동료보다 오히려 Claude와 더 많이 대화한다는 것이다. 낯선 영역을 붙들 때 먼저 모델과 개념을 정리해 보고, 그렇게 기초 조사와 나름의 관점을 갖춘 뒤 동료와의 대화에 들어가면 논의의 수준 자체가 올라간다는 이야기다. 팀이 특정 설계 결정에서 교착에 빠지면, 우리의 편향이 판단을 흐릴 때 그것을 짚어 줄 중립적 심판으로 모델을 불러들이기도 한다.
많은 기업이 에이전트를 들일 때 곧장 스무 개 팀이 얽힌 몇 달짜리 대형 프로세스를 자동화하려 든다. 야심 차고 흥미롭지만, 더 값진 출발점은 그 반대편에 있다는 조언이 나온다. 먼저 개인을 해방하는 것이다. 한 사람 한 사람이 다른 팀에 의존 요청을 넣지 않고도, 예전이라면 사람에게 부탁했을 디자인 작업까지 스스로 확장해 낼 수 있게 만드는 것. 그러면 조직 안에 사실상 '1인 스타트업'들이 생겨난다.
실무 요령도 단순하다. 백지의 막막함을 없애도록 템플릿을 주고, 그 위에서 자유롭게 변형하게 한다. 정교한 평가에 오래 매달리기 전에, 완성도를 과하게 높이지 않은 에이전트라도 일부 베타 사용자의 손에 빨리 쥐여 주는 편이 낫다. 실제 사용이 부딪히는 지점에서 배움이 나온다. 개인 단위의 창의성이 자리 잡은 다음에야, 여러 팀이 얽힌 복잡한 프로세스로 천장을 높여 가는 순서가 무리가 없다.
가까운 미래의 그림은 두 갈래다. 하나는 앞서 본 '밤사이 위임'이다. 장기 실행 에이전트가 이미 어느 정도 그렇게 작동하고 있고, 앞으로 일하는 시간의 한계는 개인의 처리 용량보다 한 번에 얼마나 많이 위임할 수 있는가에 좌우된다. 에이전트를 동료(partner)처럼 곁에 두게 된다는 뜻이다.
다른 하나는 산업 차원의 수직화다. 모델의 일반적 도메인 지식이 충분히 좋아지면서, 소프트웨어의 가치는 점점 더 좁고 구체적인 쓰임새로 옮겨간다. 두루뭉술한 회계 에이전트보다 '특정 업종을 위한 회계 에이전트'처럼 극단적으로 특화된 제품이 부상한다. 정작 공유되는 자산은 '금융 에이전트를 만드는 정석' 같은 것이 아니라, 맥락을 다루고 과제를 조율하는 패턴 쪽으로 이동한다.
이 전환에서 살아남는 제품은 사용자의 작업 흐름이 있는 바로 그 자리에 존재한다. 웹사이트로 옮겨 가 양식을 채우게 하는 대신, 대화(chat)와 코딩 환경처럼 일이 실제로 벌어지는 곳으로 파고든다.
그래서 '항상 켜져 있고, 필요한 순간에 알아서 떠오르며, 사용자가 기대하는 자리에 놓인' 에이전트 패턴이 중요해진다. Vercel의 챗 SDK가 "이제 모든 것이 대화"라고 본 것과 같은 맥락이다. 더 멀리 보면, 내 맥락을 통째로 짊어진 개인 에이전트가 상대편의 회계 에이전트에게 직접 말을 걸어 일을 처리하는 에이전트 간 협업으로도 이어진다. 결국 에이전트는 별개의 창이 아니라, 내 모든 맥락과 연결된 채 일이 사는 자리에 함께 있어야 한다는 것이다.