아우터 루프를 장악하라

지난 한 해 동안, 에이전틱 엔지니어링(agentic engineering)을 둘러싼 논의는 하네스(harness)와 루프(loop), 플릿(fleet)과 소프트웨어 팩토리(software factory)로 무게 중심을 옮겨 왔다. 내 생각을 한 마디로 정리하자면, 아우터 루프를 장악해야 하는 것은 결국 엔지니어다 — 이 시스템에 대한 책임의 주인이 되어야 한다는 뜻이다. Fable이나 GPT-5.6처럼 강력한 모델이 속속 등장하는 지금, 이 명제는 갈수록 더 절실해지고 있다.

AI Engineer World's Fair 2026 클로징 키노트를 글로 옮긴 것이다. 당일 발표 영상은 여기서 확인할 수 있다.

에이전트에게는 레버리지가 있고, 레버리지에는 의무가 따른다. 무엇이 바뀌었는지, 왜 안전했는지, 그리고 판단이 틀렸을 때 어떻게 할 것인지를 명확히 설명할 수 있는 사람이 반드시 있어야 한다. 그렇지 않으면 에이전트의 행동은 정당화될 수 없다. 그리고 정당화할 수 없는 시스템은, 애초에 도입을 요청받을 가능성도 낮다.

그래서 나는 세 가지 개념에 대해 이야기하려 한다. 첫 번째는 품질(Quality)이다. 시스템을 실제로 가동하기 전에 설치하는 모든 검증 장치를 가리킨다. 이 검증 장치들은 증거를 생성하고, 우리는 그 증거를 토대로 판정을 내린다.

두 번째는 판정(Verdict)이다. 작업 결과가 우리의 의존 시스템으로 넘어가기 직전에 내리는 최종 결정을 말한다. 나는 이 콘텐츠의 라인 프로듀서다. 내 이름으로 결과물이 출시되는 팀을 이끌고 있다. 코드 한 줄을 모델이 썼더라도, 판정은 내가 내린다. 내 팀의 작업물은 내 결정 없이는 의존 시스템에 진입하지 않는다. 판정이란 곧 프로덕션 결정이다: 출시할 것인가, 차단할 것인가, 방향을 바꿀 것인가, 응답 범위를 좁힐 것인가, 가드레일을 추가할 것인가, 아니면 아예 기각할 것인가.

세 번째는 답변 가능성(Answerability)이다. 누군가 이유를 물었을 때 내가 설명할 수 있다는 보장을 뜻한다.

달리 표현하면 이렇다. 우리의 에이전트(나는 이를 모델에 파일, 도구, 메모리, 스킬, 샌드박스, 권한, 관찰 가능성, 복구 기능으로 구성된 하네스를 더한 것으로 정의한다)는 루프를 구동하는 주체다(루프는 탐색, 구현, 검증, 반복으로 정의한다). 그리고 이것이 곧 소프트웨어 팩토리를 만들어낸다.

모델은 그저 엔진일 뿐이다. 하네스 — 도구, 메모리, 권한, 샌드박스, 테스트 — 는 엔진이 실제 작업을 안전하게 수행할 수 있도록 그 주위에 직접 설계하는 차체다.

이 하네스를 반복 가능한 사이클로 감싸라. 탐색, 구현, 검증, 반복. 루프란 한 번의 성공적인 실행을 다시 신뢰할 수 있는 프로세스로 전환하는 방법이다. 모델 스스로의 판단이 아니라 독립적인 검증이 작업 완료 여부를 결정하도록 — 탐색, 구현, 검증, 반복의 사이클로 하네스를 감싸라.

이제 루프를 동시에 여러 개 돌려라. 팩토리란 규모로 확장된 루프다 — 에이전트는 내부에서 작업을 처리하고, 경계에서의 결정은 사람이 소유한다.

그리고 팩토리의 핵심에는 시스템 내부와 외부 사이의 명확한 경계가 있다. 시스템 내부에서는 입력값을 수집한다(제품팀의 의도, 이전에 출시된 작업물에 대한 지식, 최근 인시던트 내역, 사용자의 구체적인 피드백 등에서). 에이전트 루프는 태스크를 탐색하고, 계획을 구현하며, 결과를 검증한다. 그런 다음 증거가 그 경계를 넘는다. 의존 시스템을 소유한 사람이 증거를 확인하고 진행 여부를 결정한다.

바로 이것이 우리가 이루려는 전환이다. 이전에는 에이전트가 실행 루프의 이너 루프를 담당했다면, 이제는 이너 실행 루프 전체를 에이전트가 구동한다. 아우터 루프는 엔지니어가 소유한다.

시스템 내부에서 에이전트가 하는 일은 본질적으로 한 가지다. 바로 역량(capability)이다. 태스크를 탐색하고, 계획을 구현하고, 결과를 테스트하고, 결과를 보고하는 역량. 그것이 모델의 역량이다. 그리고 이미 말했듯, 그 미래는 이미 도래해 있다.

시스템 외부에는 단 하나의 것이 있다. 바로 주체성(agency)이다. 결정하고, 검증하고, 승인하고, 소유하는 주체성.

결국 우리는 여전히 코드에 대해 이야기하고 있다. 다만 그 코드는 적절한 위치에 존재해야 하고, 무엇을 하는지 아는 사람들이 수행해야 한다.

AI 코드의 잠재력은 더 이상 주변적인 수준이 아니다. Sonar의 2026년 설문에서 우리는 팀들에게 전체 커밋 중 AI의 도움을 받은 비율을 물었다. 수치는 작지만 무시할 수 없는 수준이었다. 그리고 응답자 중 상당수는 AI 보조 커밋의 비율이 앞으로 크게 늘어날 것으로 기대했다. Sonar의 2026 State of Code 보고서에 따르면, 커밋된 코드의 42%가 AI가 생성했거나 AI의 상당한 도움을 받은 것이었으며, 이 비율은 정체되기보다 계속 증가할 것으로 전망됐다.

다시 말해, 생성 비용은 낮아지고 있다. 오히려 희소해지는 자원은 검토, 검증, 이해, 유지보수다.

우리는 생성 속도를 제어 속도보다 훨씬 빠르게 끌어올렸다. 그 결과, 신뢰-검증 간극이 생겼다. 우리가 대화를 나누는 많은 사람들이 여전히 AI 코드에 어느 정도 불신을 품고 있다. 그런데도 그 불신을 검증 프로세스에 일관되게 반영하는 사람은 많지 않다.

이것은 위험한 상태다. AI 코드의 신뢰성을 검증하는 더 저렴하고 명확한 방법이 필요하다.

GitLab의 2026년 6월 보고서를 보면 거버넌스 질문의 무게 중심이 달라졌음을 알 수 있다. GitLab의 2026년 6월 AI 책임성 연구는 AI 활용 시 검토와 검증이 현재 병목 지점임을 보여주며, 더 우려스럽게도 거버넌스가 대부분 코드 생성 이후 — 즉 이미 위험을 수용하고 소유권에 대한 통제를 잃은 뒤에야 — 이루어진다는 점을 드러낸다. 오늘날 문제는 단순히 통제에 그치지 않는다. 시스템에 어떤 제약을 설정하느냐, 증거를 갖추고 어떻게 작업을 검증하느냐, 팀에 어떻게 책임을 부여하느냐, 그리고 AI 라이프사이클의 어느 부분을 누가 소유하느냐의 문제다.

이 시리즈의 마지막 구분은 프로세스와 품질 사이에 있다. 품질은 백프레셔(back pressure)라는 개념이다. 말 그대로다. 에이전트에게 가능한 한 최대치의 자율성을 부여하고 싶은 게 아니다. 에이전트를 멈추고, 조절하고, 작업을 검토하고, 우리의 인간적 판단을 보장할 수 있을 만큼의 백프레셔가 확보되는 수준의 자율성만을 부여하려는 것이다.

일반적인 엔지니어링은 작업이 올바르게 이루어지고 있음을 나타내는 수많은 신호를 갖추고 있다. 타입 체크, 테스트, 훅, 샌드박스 제한, 감사 로그, 모니터. 우리의 엔지니어링 시스템은 이러한 신호로 가득 차 있으며, 시스템이 정직하게 작동하도록 충분한 백프레셔를 제공하도록 설계되어 있다.

따라서 에이전트가 동일한 신호를 발신하는 한, 우리는 기존 엔지니어링이 적절한 백프레셔를 제공한다고 신뢰할 수 있다.

시스템을 신뢰한다는 것이 루프 안에 사람이 필요 없다는 뜻은 아니다. 다만 사람이 이너 루프 안에 있을 필요가 없다는 뜻이다. 제약 루프(어떤 입력, 아키텍처, 지침, 불변 조건을 설정할 것인가), 샘플링 루프(얼마나 많은 출력을 샘플링하고 검토할 것인가), 감사 루프(어떤 증거를 보관해야 하며 감사 로그를 어떻게 실효성 있게 유지할 것인가), 소유권 루프(프로덕션 경계의 어느 부분을 소유할 것인가)에 사람이 있어야 한다.

하지만 이너 루프 안에 사람이 있어야 할 필요는 없다.

에이전트는 당신이 검토할 수 있는 것보다 더 많은 결과물을 출시할 수 있다.

희소한 자원은 바로 당신 자신의 핵심 인간 판단력이며, 이는 로그나 테스트와 같은 품질 신호를 통해 뒷받침된다.

AI 2026년 6월 보고서는 실험 환경에서 시간 단위의 시간 지평에 걸친 에이전틱 위임이 사실상 현실화됐음을 보여준다. 올해 에이전트와 미래의 일에 관한 OpenAI의 연구는 이 아이디어들의 훌륭한 출처가 되었다. 시스템이 우리가 검토할 수 있는 것보다 더 많은 결과물을 출시하기 시작하는 지금, 이 소유권 경계를 어떻게 확립할 것인지 진지하게 고민해야 할 때다.

바로 이 지점에서 답변 가능성이 등장한다.

장기 지평 에이전트의 경우, 시간 단위의 시간 지평에 걸쳐 내려지는 결정들은 말 그대로 '결정'이다. 그리고 그 결정 모두가 기록되지는 않는다. 입력 토큰까지 전부 역추적할 수는 없다. 만약 당신이 받은 출력이 당면한 문제에 대한 올바른 선택이라고 그저 믿는 것만으로 그친다면, 그 결정들의 연쇄를 재구성하는 데 수백, 수천 시간의 인간 작업이 필요해지고, 그것은 사실상 불가능해진다. 그러므로, 다시 한번, 답변 가능성은 시스템 설계의 핵심에 자리해야 한다.

세 가지 숨겨진 비용

여기에는 세 가지 숨겨진 비용이 있다.

인지적 항복(Cognitive surrender) ~ AI가 내놓는 결과를 무비판적으로 수용하는 것. 에이전트에게 작업을 위임하면, 그 결과물은 에이전트의 것처럼 보일 수 있다. 하지만 실제로는 당신의 작업이다. 당신의 평판이고, 당신의 책임이다. 출력물의 결함으로 피해를 입는 것도 당신의 소프트웨어이며, 그 출력을 반영해 수정해야 하는 것도 당신의 소프트웨어다. 에이전트의 출력이 곧 당신의 답이 되고, 그와 함께 모든 책임이 따라온다. Wharton 연구는 AI가 옳을 때는 안심이 된다는 사실을 보여준다. 하지만 틀렸을 때의 이야기는 그리 밝지 않다. AI가 틀렸을 때조차 거의 4분의 3에 달하는 사람들이 그것을 그대로 수용했으며, AI 없이 작업했을 때보다 더 높은 자신감을 느꼈다.

인지적 부채(Cognitive debt) ~ 문제 해결 방법에 대한 이해와 기억이 점차 침식되는 것. 에이전트에게 작업을 위임하면 모든 사고 작업을 에이전트에게 넘기게 된다. 물론 직접 생각해내는 과정은 시간과 에너지가 들지만, 방대한 코드베이스에서 그것을 해내려면 가파른 학습 곡선을 오르는 도중에는 확보하기 어려운 자원이 필요하다. 그래서 에이전트가 내놓는 결과물은 당신 스스로는 도달하기 어려운 수준인 경우가 많다. 에이전틱 계획의 시간 지평이 길수록, 에이전트가 생성한 코드와 그에 대한 당신의 이해 사이의 간극은 더 커진다. 간극은 복리로 쌓이고, 부채는 누적되며, 학습 곡선을 오르는 비용은 거의 기하급수적으로 증가한다. Anthropic의 무작위 대조 실험은 AI에 의존해 코드를 작성한 엔지니어가 직접 작성한 엔지니어만큼 코드를 이해하는지를 살펴봤다. 결론은 씁쓸했다. 이해도 퀴즈에서 AI를 활용한 엔지니어들은 그렇지 않은 엔지니어들보다 17퍼센트포인트 낮은 점수(50% 대 67%)를 기록했다.

그리고 오케스트레이션 세금(orchestration tax) ~ 지금은 에이전트를 여러 개 띄우기 쉽지만, 당신의 인지 대역폭은 그렇게 병렬화되지 않는다. 에이전트가 최악의 행동을 하지 않도록 방향을 잡아주는 것, 에이전트가 만들어낸 결과물 중 당신의 주의가 필요한 것을 가려내는 것, 가장 중요한 작업에 먼저 집중하도록 유도하는 것, 실제로 가동하기 전에 가장 중요한 제약 조건과 가장 위험한 가정을 검증하는 것…

이 모든 것이 작업이며, 자동화할 수 없다.

인간의 판단을 대체할 수 있는 것은 없다.

레거시 시스템, 즉 브라운필드(brownfield) 시스템은 여기서 특히 위험하다. 감사해야 할 시스템 동작이 코드 안에 있는 게 아니라, 쌓이고 쌓인 상흔(scars) 속에 있기 때문이다.

해결책은? 아키텍처 결정에서 주의(attention)를 최우선 순위로 삼아라. 워크트리(worktree), 스코프, 증거를 활용해 초기 계획과 실제로 도출된 결과물 사이의 결합도를 낮춰라. 실행 불가능한 단계를 해결하는 데 드는 노력은 시간 제한을 두어라. 그리고 소프트웨어 변경은 철저히 명시적 허가(opt-in permission)를 통해서만 이루어지게 하라.

알파, 감쇠, 취향 — 이 세 가지 핵심 패턴이 다양한 분야에서 커리어와 성과의 모양을 결정한다.

알파(alpha)는 경쟁에서 가장 높은 성취를 이루는 사람이 차지하는 선두 자리로, 자신이 가진 가장 가치 있는 한 수를 쓸 때 나타난다. 감쇠(decay)는 반복과 모방을 통해 누구나 익히게 되는 확립된 패턴이다(정체기라고 불러도 좋다). 취향(taste)은 알파의 선두나 감쇠의 변화를 가장 일찍 감지하는 능력이다. 아직 아무런 증거도 없는 상태에서 무언가 일어나고 있음을 직감하는 판단력이다. 폴 그레이엄의 주장처럼 누구나 무엇이든 만들 수 있게 된 세상에서는 무엇을 만들지 선택하는 것이 더 중요해지며, 미첼 해시모토의 정의는 그것을 실용적으로 풀어낸다. 아직 객관적인 척도가 없는 영역에서 고품질의 정성적 판단을 내리는 것. 앞으로는 취향이 모든 것을 이끈다. 알파의 전환은 취향의 변화이고, 감쇠는 우리가 다른 무언가를 감지하기 시작할 때 사라진다.

다음 단계는? 취향을 실용화하는 것이다. 어떻게? 감각에서 의식으로 끌어올리려는 것에 이름을 붙여라. 비평과 예시 속에서 연습하라. 그 근거를 명확히 드러내라.

그리고 당신이 속한 산업에서 가장 오래 지속되는 경쟁 우위를 가져다주는 행동을 계속하라. 그것이 무엇인가? 단순히 태스크를 수행하는 것에서 그것을 가르치고, 체계화하고, 언제 해야 할지를 결정하고, 결과를 소유하는 방향으로 경계를 계속 끌어올리는 것이다.

누구나 개발자가 될 수 있지만, 모두가 엔지니어는 아니다. 엔지니어링이란 개발자가 더 엄격한 작업 규율 — 철저하고 논리적으로 건전한 추론, 제약과 트레이드오프 고려, 위험과 노출 인식, 그리고 실질적인 책임 — 을 받아들일 때 도달하는 경지다.

미래에는 엔지니어링이 더 고도화되면서, 사람들은 엔지니어링의 행정적 업무에서 벗어나 새로운 역할을 맡게 될 것이다. 장인 정신의 본질에서 분리되어, 각자가 무엇을 하는지 명확히 드러내는 역할들이다. 프로토타입을 만드는 사람, 시스템을 구축하는 사람, 정리하는 사람, 성장시키는 사람, 유지보수하는 사람.

사람은 시스템의 반대쪽 경계도 붙잡고 있다. 반대 방향의 알파를 높이는 것: 무엇이 할 가치가 있는지 선택하고, 그것이 수행되어야 할 제약 조건을 정의하고, 증거가 충분한지 판단하고, 결과를 돌보는 것. 한 팀이든 백 개의 팀이든, 이것은 오직 사람만이 지킬 수 있는 경계다.

책임이 팩토리를 확장시킨다. 주의, 취향과 마찬가지로 책임 또한 모든 것을 작동시키는 세 가지 이중성 중 하나다. 책임이 없으면 규칙도 없다. 질문자와의 씨름도, 트레이드오프도, 위험도, 안전망도 없다. 결정의 결과를 아무도 소유하지 않는다면, 높은 주체성은 혼돈만을 낳을 뿐이다.

어떤 기술 우위의 반감기는 릴리즈 하나지만, 서명의 반감기는 커리어 전체다. 서명이란 출시된 결과물 뒤에 기꺼이 설 수 있을 만큼 그 작업에 자신의 이름을 새기는 것이다. 기술은 레버리지를 만들고, 책임은 그 레버리지를 신뢰로 바꾼다.

선택할 수 있는 것은 사람뿐이다. 결과를 물려받는 것도 사람뿐이다. 에이전트는 정책 안에서 안전하게 선택하고, 라우팅하고, 병합하고, 에스컬레이션하도록 요청받을 수 있지만, 결과를 물려받을 수는 없다.

모든 코드베이스에는 일종의 책임 계약서가 필요할지도 모른다. 변경이 수용될 때 이해된 체크리스트, 결정에 반영된 증거, 변경에 대한 책임자, 변경이 차단된 이후의 시스템 상태를 명시적으로 기록한 문서. 마치 다음과 같이:

• 당신의 주의와 취향
• 당신의 증거, 판정, 소유권
• 당신의 알파, 감쇠, 취향

높은 주체성

전형적인 에이전틱 워크플로에서 높은 주체성이란 언제 위임하고, 언제 점검하고, 언제 멈추고, 언제 프로세스의 결과를 소유할지 아는 기술이다. 주체성의 사다리는 낮은 것부터 높은 것까지 이어진다. 잠재적 문제를 표시하고, 조사하고, 실행하고, 진단하고, 해결책을 제안하고, 수정을 권고하고, 문제를 해결한다. 사다리의 높은 단계는 분별력이다. 발견했지만 수정할 가치가 없으니 넘어간다.

소프트웨어 팩토리를 떠받치는 열두 개의 기둥

규모를 키우려는 팩토리에게 브라운필드는 최전선이다. 그 영리한 혁신들이 아직 대단해 보이지 않을 수 있지만, 프로덕션 환경은 만만치 않다. 완전히 새로운 시스템을 구축할 때는 전면적인 통제권이 있으므로 충분한 백프레셔 메커니즘을 계획하고 구현하기가 훨씬 쉽다. 하지만 레거시 시스템에 지능형 에이전트를 추가하는 것은 전혀 다른 문제다.

레거시 시스템에는 모든 프로덕션 동작, 고객의 미래 기대치, 마이그레이션 이력, 릴리즈 및 예산 주기, 암묵적 가정, 엣지 케이스, 데이터의 기이함, 런북 절차, 그리고 시스템을 돌볼 의지 없이 쌓여온 모든 상흔이 담겨 있다.

브라운필드의 관리자가 되려면 지속 가능한 엔지니어링이 필요하다. 암묵적 지식을 명시적 제약으로 전환하고, 팀과 세대를 가로질러 일관성을 유지하고, 그 지식을 테스트 절차와 기능 명세로 공식화하고, 객관적 증거와 연결하는 작업이 필요하다. 그 모든 것을 해내면서도, 실패를 더 많은 학습으로 단단히 쌓아올려야 한다. 시스템이 늘 받아온 보살핌을 받지 못하면 모든 것이 무너지기 때문이다.

새로운 작업은 진짜 작업이다

규모가 커질수록 일은 더 흥미로워진다. 다른 모든 것이 구축되고 나면, 사람들은 새로운 것을 만들고 싶어하기 때문이다. 자신의 크래프트를 통해 발전시켜 온 알파와 취향을 발휘해 소프트웨어 팩토리에 접목할 수 있는 새로운 루프를 설계하고 싶어할 것이다. 아니면 소프트웨어 팩토리의 모든 지식을 한데 모아 우아하고, 목적 있고, 원칙적인 그린필드 시스템을 만들고 싶어할 것이다. 새로운 시스템의 검증 수준에 걸맞은 새로운 형태의 증거를 설계하고 구현하고 싶어할 것이다. 전담 관심이 필요할 만큼 복잡해진 브라운필드 시스템을 돌보고 싶어할 것이다. 새로운 백프레셔 메커니즘을 설계하고 관리하고 싶어할 것이다. 새로운 에이전트를 설계하고, 주체성을 구축하고 싶어할 것이다.

그리고 그러면서, 이 모든 것이 진짜 작업임을 깨닫게 될 것이다. 그것은 좋은 일이다.

자동화는 병목을 만든다. 소유할 가치가 있는 프로덕션 병목을. 왜냐하면 자동화는 산업적 규모에 대한 통제권을 우리에게 주기 때문이다. 하지만 산업적 규모에서 새로운 병목 또한 생겨난다. 병목은 "이것을 만들 수 있는가?"에서 "이것이 존재해야 하는가, 우리가 그에 대해 답할 수 있는가?"로 이동한다.

내가 제안하는 것은 에이전틱 엔지니어링을 확장하기 위한 실용적인 운영 모델이다. 이너 루프와 아우터 루프가 있다. 이너 루프는 작업이 이루어지는 곳이다. 루프는 최대한 독립적으로 설계된다. 모든 품질 보증과 검증을 루프 내부에 넣어라. 루프 자체를 설계하고 검증한 뒤에는, 루프가 실행되는 속도와 운영 범위를 제어하는 백프레셔 메커니즘을 통해 자율성을 부여하는 것만 남는다. 그리고 사람을 그들이 있어야 할 자리, 즉 올바른 결정의 지점에 두어라. 이해를 단순한 인수인계나 릴리즈 게이트로 취급하지 말고, 사람이 통찰을 발휘할 준비가 된 결정 지점으로 다루어라. 그리고 프로덕션과 새로운 팀, 엔지니어들에게 다시 공급되는 모든 산출물에 더 나은 산출물을 남겨라.

팩토리를 구축하라. 불을 켜두어라. 작업을 가시적이고, 검증 가능하고, 소유 가능하게 만들어라.

에이전트는 코드를 쓸 수 있다. 하지만 그것이 사용자에게 닿기 전에, 누군가는 왜 그것이 존재해야 하는지, 왜 프로덕션의 일부가 될 만큼 충분히 안전한지, 그리고 그것이 틀렸을 때 어떻게 할 것인지를 설명할 수 있어야 한다.

아우터 루프에서의 에이전틱 엔지니어링 — 그것이 지금 우리의 일이다.

Pangram은 이 아티클을 100% 인간이 작성한 것으로 평가했습니다: pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871