아우터 루프를 책임져라
TMT지난 한 해 동안 **에이전틱 엔지니어링(agentic engineering)**을 둘러싼 논의는 하네스와 루프, 에이전트 함대와 소프트웨어 공장으로 옮겨왔습니다. 제 생각을 짧게 보태자면, 엔지니어는 아우터 루프(outer loop)를 직접 책임져야 합니다. 이 시스템들에 대한 책임 말입니다. Fable이나 GPT-5.6 같은 강력한 모델이 나올수록 이 말은 더욱 맞는 말이 됩니다.
에이전트는 지렛대 같은 힘을 갖고 있고, 그 힘에는 의무가 따릅니다. 무엇이 바뀌었는지, 그것이 왜 안전했는지, 만약 틀렸다면 어떤 일이 벌어질지를 누군가는 정확히 설명할 수 있어야 합니다. 그러지 못하면 에이전트의 행동은 정당화될 수 없습니다. 그리고 그런 상태라면 애초에 조직이 에이전트를 찾을 일도 없을 것입니다.
그래서 세 가지 용어를 이야기하려 합니다. 첫 번째 **품질(Quality)**은 시스템을 풀어놓기 전에 심어두는 모든 점검 장치를 가리킵니다. 이 점검들이 증거를 만들어내고, 그 증거에서 판정이 나옵니다.
두 번째 **판정(Verdict)**은 작업물이 그것에 의존하는 시스템으로 들어가기 전에 내리는 최종 결정을 가리킵니다. 저는 이 콘텐츠의 제작 책임자(line-producer)입니다. 제 이름을 걸고 결과물을 내보내는 팀을 이끌고 있습니다. 한 줄 한 줄은 모델이 쓸지 몰라도, 판정은 제 몫입니다. 제 결정 없이는 우리 팀의 작업물이 의존 시스템에 들어가지 않습니다. 판정은 곧 프로덕션 결정입니다. 내보낼 것인가, 막을 것인가, 방향을 틀 것인가, 응답 범위를 좁힐 것인가, 가드레일을 추가할 것인가, 아니면 아예 반려할 것인가?
세 번째 **설명 책임(Answerability)**은 누군가 물었을 때 왜 그랬는지 설명할 수 있다는 보장을 가리킵니다.
달리 말하면 이렇습니다. 에이전트(제 정의로는 모델에 파일, 도구, 메모리, 스킬, 샌드박스, 권한, 관측성, 복구 장치로 이루어진 하네스를 더한 것)가 루프(제 정의로는 조사, 구현, 검증, 그리고 반복)를 돌리는 주체이고, 그것이 우리의 소프트웨어 공장을 만들어냅니다.
모델은 엔진일 뿐입니다. 하네스, 즉 도구, 메모리, 권한, 샌드박스, 테스트는 그 엔진이 안전하게 실제 일을 할 수 있도록 주위에 조립해 올리는 자동차입니다.
그 하네스를 반복 가능한 사이클로 감싸세요. 조사하고, 구현하고, 검증하고, 반복하는 것입니다. 루프는 한 번의 좋은 실행을 다시 돌려도 믿을 수 있는 프로세스로 바꿔주는 방법입니다. 하네스를 조사, 구현, 검증, 반복의 사이클로 감싸되, 작업이 끝났는지는 모델 자신의 주장이 아니라 독립적인 검사가 판단하게 하세요.
이제 여러 루프를 동시에 돌려봅시다. 공장이란 루프를 대규모로 돌리는 것입니다. 안에서는 에이전트가 작업물을 만들어 내보내고, 경계에서는 사람이 결정을 책임집니다.
그리고 그 공장의 심장부에는 시스템의 안과 밖을 가르는 신중한 경계가 있습니다. 시스템 안에서는 입력을 모읍니다(제품팀의 의도에서, 이전에 출시한 작업에 대한 지식에서, 최근의 장애에서, 혹은 사용자의 구체적인 피드백에서). 에이전트 루프가 과제를 조사하고, 계획을 구현하고, 결과를 검증합니다. 그런 다음 증거가 그 경계를 넘어갑니다. 의존 시스템을 책임지는 사람이 그 증거를 보고 진행 여부를 결정합니다.
그리고 여러분, 바로 이것이 우리가 만들려는 전환입니다. 예전에는 에이전트가 실행 루프 안쪽의 이너 루프(inner loop)를 거드는 존재였다면, 이제는 이너 실행 루프를 통째로 돌립니다. 엔지니어는 아우터 루프를 책임집니다.
시스템 안에서 에이전트가 하는 일은 사실 한 종류뿐입니다. 바로 능력(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) 개념입니다. 말 그대로의 의미입니다. 에이전트가 발휘할 수 있는 최대치의 자율성을 그대로 내주고 싶지는 않습니다. 에이전트를 멈추고, 조절하고, 작업을 점검하고, 우리의 인간다움을 지킬 수 있을 만큼의 백프레셔가 확보되는 선까지만 자율성을 주려는 것입니다.
평범한 엔지니어링에는 지금 하는 작업이 옳은 방향으로 가고 있음을 알려주는 신호가 많습니다. 타입 체크, 테스트, 훅, 샌드박스 제한, 감사 로그, 모니터 같은 것들입니다. 우리의 엔지니어링 시스템은 이런 신호로 가득하고, 이 신호들은 시스템이 정직함을 유지하도록 충분한 백프레셔를 걸어주게끔 설계되어 있습니다.
따라서 에이전트가 이와 똑같은 신호를 계속 내보내는 한, 평범한 엔지니어링이 적절한 백프레셔를 걸어주리라 믿을 수 있습니다.
시스템을 믿는다는 것이 루프에서 사람을 빼겠다는 뜻은 아닙니다. 사람이 이너 루프에 있을 필요가 없다는 뜻일 뿐입니다. 사람은 제약 루프(어떤 입력, 아키텍처, 지시, 불변 조건을 정할 것인가?), 샘플링 루프(산출물을 얼마나 뽑아서 검토할 것인가?), 감사 루프(어떤 증거를 남길 것이며, 감사 로그가 실효성을 갖게 하려면 어떻게 해야 하는가?), 그리고 소유 루프(프로덕션 경계의 어느 부분을 우리가 책임질 것인가)에 있어야 합니다.
하지만 사람이 이너 루프에 있을 필요는 없습니다.
에이전트는 여러분이 검토할 수 있는 양보다 더 많이 내놓을 수 있습니다.
그리고 희소 자원은 로그나 테스트 같은 품질 신호로 뒷받침되는, 여러분 자신의 핵심적인 인간 판단력입니다.
2026년 6월의 AI 보고서는 실험 환경에서는 시간 단위 지평의 에이전트 위임이 사실상 이미 실현됐음을 보여줍니다. 올해 OpenAI가 발표한 에이전트와 일의 미래에 관한 연구에서 이 아이디어의 많은 부분을 얻었습니다. 그러니 시스템이 우리가 검토할 수 있는 양보다 많이 내놓기 시작하는 지금, 이 소유권의 경계를 어떻게 세울지 고민을 시작해야 합니다.
바로 여기서 설명 책임이 등장합니다.
긴 지평의 에이전트에서는 시간 단위에 걸쳐 내려지는 결정들이 말 그대로 '결정'이기 때문입니다. 그리고 그 결정이 전부 기록되지는 않을 것입니다. 모든 결정을 입력 토큰까지 거슬러 추적할 수도 없습니다. 손에 들어온 산출물이 당면 문제에 맞는 선택이겠거니 그저 믿기만 한다면, 그 결과에 이른 결정의 사슬을 재구성하는 데 필요한 수백, 수천 시간의 사람 손 작업은 불가능한 일이 됩니다. 그래서 다시 한번, 설명 책임은 시스템 설계의 핵심에 놓여야 하는 것이 됩니다.
세 가지 숨은 비용
그리고 여기에는 세 가지 숨은 비용이 있습니다.
판단을 통째로 맡겨버리기(cognitive surrender) ~ AI가 주는 것을 맹목적으로 받아들이는 것. 에이전트에게 일을 맡기면 그 작업이 에이전트의 것처럼 보일 수 있습니다. 하지만 실제로는 여러분의 작업입니다. 여러분의 평판이고, 여러분의 책임입니다. 산출물의 결함으로 상하는 것도 여러분의 소프트웨어이고, 그 산출물을 반영해 고쳐야 하는 것도 여러분의 소프트웨어입니다. 결국 에이전트의 산출물은 여러분의 답이 되고, 그에 따르는 책임도 전부 함께 따라옵니다. 이를 정리한 와튼 연구는 AI가 맞았을 때는 안심되는 결과를 보여줍니다. 하지만 AI가 틀렸을 때의 소식은 좋지 않습니다. AI가 틀렸을 때도 거의 4분의 3에 이르는 사람들이 그 답을 그대로 받아들였고, 심지어 AI 없이 판단할 때보다 더 확신했습니다.
인지 부채(cognitive debt) ~ 문제 푸는 법에 대한 이해와 기억이 침식되는 것. 에이전트에게 일을 맡긴다는 것은 생각하는 일 전부를 에이전트에게 떠넘긴다는 뜻입니다. 모든 것을 스스로 생각해내는 데는 시간과 에너지가 들지만, 거대한 코드베이스 위에서 그것을 해내는 데는 학습 곡선을 오르는 중에는 확보할 수 없는 수준의 자원이 듭니다. 그래서 손에 들어온 산출물은 여러분 스스로는 만들어낼 수 없는 것일 때가 많습니다. 그리고 에이전트가 계획하는 시간 지평이 길어질수록, 에이전트가 만든 코드와 그에 대한 여러분의 이해 사이의 간극은 더 벌어집니다. 간극은 복리로 불어나고, 부채는 쌓이고, 학습 곡선을 오르는 비용은 거의 기하급수적으로 커집니다. AI에 기대어 코드를 쓰는 엔지니어가 직접 쓰는 엔지니어만큼 코드를 이해하는지 살펴본 Anthropic의 무작위 대조 실험이 있습니다. 결론은 우울했습니다. 이해도 퀴즈에서 AI를 거쳐 작업한 엔지니어는 그렇지 않은 엔지니어보다 17퍼센트포인트 낮은 점수를 받았습니다. 50% 대 67%였습니다.
그리고 오케스트레이션 세금(orchestration tax)이 있습니다 ~ 이제 에이전트를 잔뜩 띄우기는 쉽지만, 여러분의 인지 대역폭은 그런 식으로 병렬화되지 않습니다. 에이전트가 최악의 행동으로 빠지지 않게 방향을 잡아주는 일, 에이전트가 쏟아낸 작업물을 분류해 여러분의 주의가 필요한 것을 골라내는 일, 여러분이 중요하게 여기는 일부터 하도록 이끄는 일, 실행을 허락하기 전에 가장 중요한 제약과 가장 위험한 가정을 검증하는 일…
이 모든 것이 품이 드는 일이고, 자동화할 수 없습니다.
인간의 판단을 대신할 것은 없습니다.
여기서 특히 위험한 것이 브라운필드(brownfield) 시스템입니다. 감사해야 할 시스템의 동작이 코드가 아니라 흉터 속에 살아 있기 때문입니다.
해법은요? 아키텍처 결정에서 주의력(attention)을 최우선에 두세요. 워크트리, 스코프, 증거를 활용해 처음 세운 계획과 거기서 파생되어 나오는 작업 사이의 결합도를 낮추세요. 실행할 수 없는 단계를 붙들고 해결하려는 노력에는 시간 상한을 두세요. 그리고 소프트웨어에 대한 변경은 철저히 옵트인 방식의 권한으로 만드세요.
알파(alpha), 디케이(decay), 안목(taste). 이 셋은 분야를 가리지 않고 커리어와 성과를 좌우하는 세 가지 핵심 패턴입니다.
알파는 가장 가치 높은 수를 둘 때 경쟁의 최고 성취자가 차지하는 앞선 몫입니다. 디케이는 반복과 어깨너머 배움을 통해 누구나 익히게 되는 정형화된 패턴입니다(정체 구간이라고 불러도 좋습니다). 안목은 알파의 앞서감이나 디케이의 변화를 가장 이르게 감지해내는 능력입니다. 무언가 벌어지고 있다는 증거가 하나도 없을 때 다가올 것을 미리 판단하는 것이죠. 폴 그레이엄의 요지는 누구나 무엇이든 만들 수 있게 되면 무엇을 만들지 고르는 일이 더 중요해진다는 것이고, 미첼 하시모토의 정의는 실무적입니다. 아직 객관적 지표가 없는 곳에서 수준 높은 정성적 판단을 내리는 것. 이제부터는 안목이 모든 것을 이끕니다. 알파의 이동은 곧 안목의 변화입니다. 그리고 디케이가 사그라드는 것도 우리가 뭔가 다른 것에 끌리기 시작하기 때문입니다.
다음 할 일은요? 안목을 운영 가능한 체계로 만드세요. 어떻게요? 감으로만 알던 것을 의식의 영역으로 끌어올릴 수 있도록, 그것을 반영하는 이름을 붙이세요. 비평과 예시 속에서 연습하세요. 그 근거를 명시적으로 밝혀두세요.
그리고 여러분의 업계에서 가장 오래가는 경쟁 우위를 만들어주는 수를 계속 두세요. 그게 뭐냐고요? 우위의 지점을 계속 위로 올리는 것입니다. 그저 과제를 수행하는 데서, 그것을 가르치고, 체계화하고, 언제 해야 할지 결정하고, 결과를 책임지는 데까지 말입니다.
누구나 개발자이지만, 누구나 엔지니어인 것은 아닙니다. 엔지니어링이란 개발자가 더 엄격한 작업 규율을 받아들일 때 도달하는 상태입니다. 철저하고 논리적으로 탄탄한 추론, 제약과 트레이드오프에 대한 고려, 리스크와 노출에 대한 인식, 그리고 실질적인 책임 말입니다.
앞으로 사람들은 엔지니어링의 행정적인 일에서 벗어나, 엔지니어링의 요구 수준이 높아지면서 새로 생겨나는 역할들을 받아들이게 될 것입니다. 장인 정신이라는 한 덩어리에서는 떨어져 나왔지만 각자 무엇을 하는지는 분명한 역할들입니다. 프로토타입을 만드는 사람, 구축하는 사람, 청소하는 사람, 키우는 사람, 유지보수하는 사람이 있을 것입니다.
사람은 반대 방향에서도 시스템의 가장자리를 지킵니다. 반대 방향으로 알파를 키우는 것이죠. 무엇이 할 가치가 있는지 고르고, 어떤 제약 안에서 해야 하는지 정의하고, 진행하기에 증거가 충분한지 판단하고, 결과를 돌보는 일입니다. 팀이 하나든 백 개든, 이것은 오직 사람만이 지킬 수 있는 가장자리입니다.
공장을 확장시키는 것은 책임입니다. 주의력, 안목과 마찬가지로 책임 역시 모든 것을 굴러가게 하는 세 가지 이중성 중 하나입니다. 책임이 없으면 규칙도 없습니다. 따져 묻는 사람과 씨름할 일도, 트레이드오프도, 리스크도, 안전망도 없습니다. 결정의 결과를 아무도 책임지지 않는다면, 높은 주체성은 혼돈만 불러올 뿐입니다.
우위의 반감기는 릴리스 한 번이지만, 서명의 반감기는 커리어 전체입니다. 서명이란 작업물에 새긴 여러분의 이름이며, 내보낸 결과물을 떳떳하게 책임질 수 있다는 표시입니다. 스킬은 지렛대를 쥐여주고, 책임은 그 지렛대를 신뢰로 바꿉니다.
선택은 오직 사람만 할 수 있습니다. 결과를 떠안는 것도 오직 사람뿐입니다. 에이전트에게 정책 안에서 안전하게 선택하고, 분배하고, 병합하고, 에스컬레이션하라고 시킬 수는 있지만, 에이전트가 그 결과까지 떠안을 수는 없습니다.
어쩌면 모든 코드베이스에는 일종의 책임 계약서가 딸려 있어야 하는지도 모릅니다. 변경을 수용할 때 서로 이해하고 있던 체크리스트, 그 결정에 들어간 증거, 변경의 책임자가 누구였는지, 그리고 변경이 차단된 뒤의 시스템 상태를 명시적으로 적어두는 것입니다. 다음과 같이 말이죠.
- 여러분의 주의력과 안목
- 여러분의 증거, 판정, 그리고 소유권
- 여러분의 알파, 디케이, 그리고 안목
높은 주체성
전형적인 에이전트 워크플로에서 높은 주체성(high agency)이란 언제 위임하고, 언제 들여다보고, 언제 멈추고, 언제 프로세스의 결과를 책임질지 아는 기술입니다. 주체성의 사다리는 낮은 데서 높은 데로 이어집니다. 잠재적 문제를 발견해 알리고, 조사하고, 대응을 실행하고, 진단하고, 해법을 제안하고, 수정안을 권고하고, 문제를 끝내 해결하는 것. 이 사다리의 높은 칸에 있는 것이 분별력입니다. 찾았다, 고칠 가치가 없다, 넘어간다.
소프트웨어 공장을 떠받치는 열두 기둥
규모를 키우려는 공장에게 브라운필드는 넘어야 할 개척지입니다. 그 영리한 작은 혁신들이 아직은 별것 아니게 느껴질지 몰라도, 프로덕션 환경은 만만치 않습니다. 완전히 새로운 시스템을 지을 때는 모든 것을 통제할 수 있으니 충분한 백프레셔 장치를 계획하고 구현하기가 훨씬 쉽습니다. 하지만 레거시 시스템에 지능형 에이전트를 붙이는 일은 전혀 다른 문제입니다.
레거시 시스템에는 프로덕션 동작 전체, 고객이 앞으로 기대할 것들, 마이그레이션의 역사, 릴리스와 예산 주기의 길이, 입 밖에 내지 않는 가정들, 엣지 케이스, 이상한 데이터, 런북 절차, 그리고 시스템을 돌볼 의지가 없던 시절에 쌓인 온갖 흉터가 전부 포함됩니다.
브라운필드의 관리인이 되려면 오래가는 형태의 엔지니어링이 필요합니다. 암묵지를 명시적인 제약으로 바꾸고, 팀을 넘고 세대를 거쳐도 일관되게 유지하고, 그 지식을 테스트 절차와 기능 명세로 정형화하고, 객관적인 증거에 연결하는 작업을 해내야 합니다. 그러면서도 실패를 차곡차곡 더 많은 배움으로 바꿔가야 합니다. 시스템이 늘 받아오던 보살핌을 받지 못하는 순간, 모든 것이 와르르 무너질 테니까요.
새로운 일도 진짜 일이다
규모가 커질수록 일은 더 재미있어질 것입니다. 다른 모든 것이 다 지어지고 나면, 사람들은 새로운 것을 짓고 싶어 하기 때문입니다. 자신의 일에서 갈고닦은 알파와 안목을 살려 소프트웨어 공장에 접붙일 새로운 루프를 설계하고 싶어 할 것입니다. 혹은 소프트웨어 공장의 모든 지식을 우아하고 선의에 찬, 원칙 있는 하나의 시도에 쏟아부은 그린필드(greenfield) 시스템을 짓고 싶어 할 것입니다. 새로운 시스템에서 검증의 수준까지 올라설 새로운 형태의 증거를 설계하고 구현하고 싶어 할 것입니다. 이제는 너무 복잡해져 전담 관리가 필요해진 브라운필드 시스템을 돌보고 싶어 할 것입니다. 새로운 백프레셔 장치를 설계하고 운영하고 싶어 할 것입니다. 새로운 에이전트를 설계하고 싶어 할 것입니다. 그리고 주체성을 세우고 싶어 할 것입니다.
그리고 그렇게 하다 보면, 이 모든 것이 진짜 일이라는 사실을 알게 될 것입니다. 좋은 일입니다.
자동화는 병목을 만듭니다. 맡아둘 가치가 있는 프로덕션의 병목입니다. 자동화는 산업적 규모를 통제할 힘을 주니까요. 하지만 산업적 규모에서 새로 생겨나는 병목도 있습니다. 병목은 "우리가 이걸 만들 수 있나?"에서 "이게 존재해야 하나, 우리가 이것을 책임지고 답할 수 있나?"로 옮겨갑니다.
제가 제안하는 것은 에이전틱 엔지니어링을 확장하기 위한 실용적인 운영 모델입니다. 이너 루프와 아우터 루프가 있습니다. 이너 루프는 일이 이뤄지는 곳입니다. 루프는 최대한 서로 독립적이도록 설계합니다. 모든 품질 보증과 검증은 루프 안에 넣으세요. 루프 자체를 설계하고 검증하고 나면, 남은 일은 하나뿐입니다. 루프의 실행 속도와 작동 범위를 통제하는 백프레셔 장치를 마련해 자율성을 부여하는 것입니다. 그리고 사람은 마땅히 있어야 할 자리, 즉 올바른 결정 위에 두세요. 이해를 인수인계나 릴리스 관문으로 취급하지 말고, 사람이 통찰을 보탤 준비가 된 결정의 지점으로 취급하세요. 그리고 프로덕션으로, 새로운 팀과 엔지니어에게로 되먹임되는 모든 산출물마다 더 나은 산출물을 남기세요.
공장을 지으세요. 시스템이 멈추지 않게 지키세요. 일을 읽을 수 있게, 검증할 수 있게, 책임자가 있게 만드세요.
코드는 에이전트가 쓸 수 있습니다. 하지만 그것이 사용자에게 닿기 전에, 누군가는 그것이 왜 존재해야 하는지, 왜 프로덕션의 일부가 될 만큼 안전한지, 그리고 잘못됐을 때 자신이 무엇을 할 것인지 설명할 수 있어야 합니다.
그것이 아우터 루프에서의 에이전틱 엔지니어링이며, 그것이 지금 우리가 할 일입니다.
Pangram은 이 글을 100% 사람이 쓴 글로 판정했습니다: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
