한 에이전트가 52개의 티켓 중 51개를 해결한 뒤, 해당 업무를 종료해 버렸다

Nate B Jones는 팀의 가장 고질적인 지원 문제 하나를 단일 AI 에이전트에게 맡겼습니다. 단 일주일 만에, 이 에이전트는 52개의 열린 이슈 중 51개를 해결했습니다. 그러고 나서 아무도 예상치 못한 일을 저질렀습니다. 해당 티켓들을 생성하는 근본적인 프로세스를 식별하고 이를 재구축하여, 해당 카테고리 전체를 영구적으로 제거해 버린 것입니다.

차트와 임베디드 소스가 포함된 전체 버전은 AgentConn에서 확인하세요.

그다음 비교 가능한 주에는 케이스가 52건에서 19건으로 급감했습니다.

이것은 데모가 아닙니다. 이는 실제 배포 결과(deployment receipt)입니다. 그리고 이는 에이전트로 서비스를 구축하는 대부분의 팀이 아직 흡수하지 못한 변화를 시사합니다. 즉, AI 작업의 단위가 "기능 (a function)"에서 "프로젝트 (a project)"로 이동하고 있다는 것입니다.

Nate B Jones AI News and Strategy Daily podcast episode — Find a Real Job for Your First AI Agent

Acast에서 전체 에피소드 듣기 →

배포 결과 (The deployment receipt): Jones의 에이전트는 단순히 티켓에 더 빠르게 답변한 것이 아닙니다. 에이전트는 지원 로그(support logs) 전반에 걸쳐 교차 시스템 조사(cross-system research)를 수행했고, 반복되는 카테고리를 생성하는 숨겨진 프로세스를 식별했으며, 더 적은 수의 고객이 도움을 요청할 필요가 있도록 워크플로(workflow)를 재구조화했습니다. 에이전트는 처음에는 초안 모드(draft mode)로 작동한 후 권한을 확장받았으며, 특정 파괴적인 작업은 인간의 승인 게이트(human approval gate) 뒤에 유지되었습니다.

약속이 아닌 결과

지난 2년 동안 AI 에이전트에 대한 대화는 약속들로 지배되어 왔습니다. 컨퍼런스의 데모들, 벤치마크 점수들, 그리고 에이전트가 몇 분 이상 감독 없이 작동하는 모습을 전혀 보여주지 않는 "이것 좀 보세요" 식의 영상들 말입니다.

Jones의 사례 연구는 검증 가능한 전후 수치를 제시한다는 점에서 이러한 패턴을 깨뜨립니다. 즉, 52개의 티켓이 들어왔고, 51개가 해결되었으며, 그 후 해당 티켓들을 생성했던 카테고리가 대기열(queue)에서 완전히 사라졌습니다. 그 접근 방식은 구체적이고 재현 가능했습니다.

1. 에이전트가 팀의 지원 백로그(support backlog)를 입력값으로 받았습니다.
2. 에이전트는 인간의 검토를 거치는 초안 모드(draft mode)로 작동하며 개별 티켓을 해결했습니다.
3. 티켓을 처리하면서, 에이전트는 공통된 근본 원인(root cause)을 공유하는 티켓들과 같은 패턴을 식별했습니다.
4. 에이전트는 해당 패턴을 특정 상류 프로세스(upstream process)로 추적했습니다.
5. 에이전트는 해당 프로세스에 대한 해결책을 제안했고 (승인 후 실행했습니다).
6. 반복되던 카테고리는 더 이상 새로운 티켓을 생성하지 않게 되었습니다.

Jones가 언급했듯이, 핵심적인 통찰은 다음과 같습니다: "가장 큰 이득은 애초에 티켓을 만들어냈던 숨겨진 프로세스를 찾아내어 제거하는 데서 옵니다."

이것은 단순히 질문에 답하는 에이전트가 아닙니다. 이것은 근본 원인 분석 (root-cause analysis), 프로세스 재설계 (process redesign), 그리고 구현 (implementation)을 수행하는 에이전트입니다. 과거에는 프로젝트 매니저, 시스템 분석가, 그리고 개발자가 필요했던 종류의 업무입니다. 이 모든 것이 단 하나의 루프(loop) 안에서 이루어집니다.

기능에서 프로젝트로: 업무 단위의 변화

Jones의 지원 티켓 사례는 이제 무시하기 어려운 하나의 패턴을 보여주는 데이터 포인트 중 하나입니다. AI 업무의 단위 — 즉, 에이전트에게 맡겨 자율적으로 결과물을 기대할 수 있는 단위 — 가 "기능 (a function)"에서 "프로젝트 (a project)"로 확장되었습니다.

이번 달에 세 가지 독립적인 신호가 수렴했습니다:

신호 1: MirrorCode는 에이전트가 몇 주에 걸친 코딩 작업을 수행할 수 있음을 증명합니다. Epoch AI와 METR가 공동 개발한 MirrorCode 벤치마크 (MirrorCode benchmark)는 AI가 버그를 수정하거나 함수를 작성하는 수준을 넘어, 오직 동작 방식만으로 전체 프로그램을 처음부터 다시 구현할 수 있는지 테스트합니다. 2026년 6월 정식 출시에서 Claude Opus 4.7은 25개의 대상 프로그램 중 56%를 해결했으며, 여기에는 4명의 독립적인 엔지니어가 인간이 수행할 경우 2주에서 17주가 소요될 것으로 예상한 16,000라인 규모의 생물정보학 (bioinformatics) 툴킷이 포함되었습니다. 에이전트는 이를 14시간 만에 251달러로 완료했습니다.

25개의 대상은 Unix 유틸리티, 데이터 직렬화 (data serialization), 생물정보학 (bioinformatics), 인터프리터 (interpreters), 정적 분석 (static analysis), 암호학 (cryptography), 압축 (compression)을 아우릅니다. 이것들은 장난감 수준의 문제가 아닙니다. 소스 코드에 대한 접근 없이 재구현된, 실제 사용자가 존재하는 실제 프로그램들입니다.

수치로 보는 MirrorCode: 6개 언어 (Python, C, Rust, Go, OCaml, Ada)에 걸친 25개의 대상 프로그램. Opus 4.6은 생물정보학 툴킷인 gotree에서 2,001개의 테스트 중 2,000개를 통과했습니다. 가장 비용이 많이 든 단일 작업은 2,600달러의 비용으로 19일 동안 연속 계산을 수행했습니다. 인간 기준선 (Human baseline): 한 명의 엔지니어가 더 단순한 2,000라인 작업에서 20시간 후 42%를 달성했습니다.

신호 2: "에이전트 기반 엔지니어링 (Agentic engineering)"에 이름과 워크숍, 그리고 ACM 논문집이 생겼습니다. Andrej Karpathy가 2025년 초 "바이브 코딩 (vibe coding)"이라는 용어를 만들었을 때, 그것은 바닥(floor)을 설명했습니다. 즉, 누구나 LLM에 프롬프트를 입력해 코드를 작성할 수 있다는 것입니다. 그가 Sequoia Ascent 2026에서 발표한 후속 용어인 "에이전트 기반 엔지니어링 (agentic engineering)"은 천장(ceiling)을 설명합니다. 이는 AI 에이전트가 구조화된 인간의 감독 하에 계획을 세우고, 코드를 작성하고, 테스트하고, 배포(ship)하는 시스템을 설계하는 규율을 의미합니다.

Andrej Karpathy on X — Fireside chat at Sequoia Ascent 2026 discussing agentic engineering as the next evolution beyond vibe coding

X에서 원문 보기 →

해당 용어는 이미 공식화되었습니다. 최고의 소프트웨어 공학 컨퍼런스인 ICSE와 공동 개최되는 제1회 에이전트 공학 국제 워크숍 (1st International Workshop on Agentic Engineering, AGENT 2026)은 ACM을 통해 논문집 (proceedings)을 출판했습니다. 논문들은 에이전트 아키텍처 지식 관리 (agentic architecture knowledge management), 에이전트 소프트웨어 프로젝트 관리 (agentic software project management), 그리고 멀티 에이전트 시스템 (multi-agent systems)을 위한 평가 프레임워크 (evaluation frameworks)를 다룹니다.

Mustafa Ergisi on X — Karpathy framing agentic engineering as the next step past vibe coding is a clearer mental model than most

X에서 원문 보기 →

시그널 3: 이제 프로덕션 배포 데이터가 존재합니다. LangChain의 AI 에이전트 현황 조사 (State of AI Agents survey)에 따르면, 전문가의 57.3%가 현재 에이전트를 프로덕션 (production) 환경에서 사용 중이라고 보고했습니다. 이 수치는 18개월 전에는 10% 미만이었습니다. 병목 현상은

• Wendy's FreshAI는 160개 이상의 매장에서 매일 수만 건의 드라이브스루 주문을 86%의 정확도로 처리하고 있으며, 500개 이상의 매장으로 확장 중입니다.
• Salesforce는 지원 인력을 9,000명에서 약 5,000명으로 줄였으며, 이에 대한 공개적인 번복은 없었습니다.
• Klarna는 700명의 고객 서비스 상담원을 감축했으나, 만족도가 하락한 후 하이브리드 모델로 조용히 재고용했습니다.
• Duolingo는 번역가들을 없애고 1년 만에 148개의 코스를 구축했으나, 이후 품질 불만으로 인해 재고용을 진행했습니다.

패턴을 살펴보면: AI 기반의 역할 대체 중 약 절반만이 지속적인 이득을 달성했습니다. 나머지 절반은 방향을 되돌리거나 하이브리드화되었습니다. 차이점은 무엇일까요? 성공적인 배포는 단순히 작업자(worker)가 아닌 워크플로(workflow)를 타겟팅했다는 점입니다.

Business Insider on X — OpenAI cofounder Andrej Karpathy says agentic engineering is the next evolution in AI coding

X에서 원문 보기 →

도구(tooling) 측면도 이러한 어휘를 따라잡고 있습니다. 한 실무자가 언급했듯이, "Karpathy는 에이전트 공학(agentic engineering)을 프로덕션 에이전트 작업과 바이브 코딩(vibe coding)을 구분하는 학문으로 정의했습니다. 그가 나열한 핵심 기술은 사양 설계(spec design), 평가 루프(eval loops), 그리고 보안 감독(security oversight)이었습니다." Google은 이미 이 워크플로를 위한 전용 도구를 출시했습니다.

Akshay Pachaar on X — Karpathy's Agentic Engineering finally has proper tooling, built by Google

X에서 원문 보기 →

반대 의견의 관점: 한 에이전트가 51개의 티켓을 해결한 것은 인상적입니다. 하지만 배포 사례에는 생존 편향(survivorship bias)이 짙게 깔려 있습니다. 데이터베이스를 손상시키거나, 회귀(regression)를 유발하거나, 그럴듯하게 들리지만 틀린 답변을 생성한 에이전트에 대해서는 아무도 트윗하지 않습니다. WithoutHuman의 데이터는 50%의 번복률을 보여줍니다. 만약 프로덕션 지원 업무에 에이전트를 배포하고 있다면, Jones가 했던 것처럼 인간의 검토가 포함된 초안 모드(draft mode)부터 시작하십시오. 에이전트는 확장된 권한을 획득하며 얻는 것이지, 처음부터 가지고 시작하는 것이 아닙니다.

루프 엔지니어링(Loop Engineering)과의 연결

업무의 단위가 이제 프로젝트라면, 엔지니어링 과제는 프로젝트가 실행되는 루프(loop)를 설계하는 것입니다. 이것이 바로 루프 엔지니어링 (loop engineering)이 다루는 핵심입니다. 즉, 에이전트가 경로를 이탈하지 않고 몇 시간 또는 며칠 동안 자율적으로 작동할 수 있도록 관찰-방향 설정-결정-실행 (observe-orient-decide-act) 사이클을 구조화하는 것입니다.

Jones의 지원 에이전트는 훌륭한 루프 설계의 전형을 보여줍니다:

• 관찰 (Observation): 지원 백로그 (support backlog)를 수집
• 방향 설정 (Orientation): 단순히 증상이 아닌 근본 원인 (root cause)에 따라 티켓을 클러스터링 (cluster)
• 결정 (Decision): 프로세스 변경 제안 (인간의 승인 단계 포함)
• 실행 (Action): 변경 사항을 실행하고 티켓 볼륨을 모니터링

이 에이전트는 단순히 개별 티켓을 루프 돌며 처리한 것이 아닙니다. '왜 이 티켓들이 존재하는가?'라는 메타 문제 (meta-problem)를 루프 돌며 파고들어 그 문제를 공격했습니다. 이것이 질문에 더 빠르게 답변하는 (answers questions faster) 에이전트와, 질문 자체가 발생하지 않도록 워크플로 (workflow)를 재구조화하는 에이전트 사이의 차이점입니다.

MirrorCode의 설계도 동일한 원리를 반영합니다. 벤치마크는 에이전트에게 컴파일된 바이너리 (compiled binary), 문서, 그리고 예시 입출력 (I/O) 쌍을 제공합니다. 에이전트는 소스 코드를 볼 수 없습니다. 에이전트는 임의의 입력값으로 바이너리를 실행하고, 동작을 관찰하며, 그와 일치하는 완전한 재구현 (reimplementation)을 반복적으로 구축해야 합니다. 이것은 하나의 프로젝트이지, 단순한 함수 호출 (function call)이 아닙니다.

이것이 당신에게 의미하는 바

만약 당신이 2026년에 에이전트를 구축하거나 배포하고 있다면, 다음과 같은 세 가지 구체적인 시사점이 있습니다:

1. 티켓이 아닌 카테고리를 목표로 하세요. Jones의 가장 큰 승리는 51개의 티켓을 해결한 것이 아닙니다. 그 티켓들을 생성해낸 카테고리 자체를 제거한 것입니다. 에이전트의 권한 (charter)을 설정할 때 다음과 같이 질문하십시오: "어떤 상류 프로세스 (upstream process)가 이 반복적인 업무를 만들어내는가?" 바로 그곳에 10배의 ROI (투자 대비 수익)가 있습니다. 하루에 100개의 티켓에 답변하는 에이전트는 유용합니다. 하지만 그중 80개의 티켓이 더 이상 존재하지 않게 만드는 에이전트는 혁신적입니다.