# 외부 루프를 소유하라 > Clean Markdown view of GeekNews topic #31372. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31372](https://news.hada.io/topic?id=31372) - GeekNews Markdown: [https://news.hada.io/topic/31372.md](https://news.hada.io/topic/31372.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-13T09:36:01+09:00 - Updated: 2026-07-13T09:36:01+09:00 - Original source: [substack.com/addyo](https://addyo.substack.com/p/own-the-outer-loop) - Points: 7 - Comments: 0 ## Topic Body - 에이전트가 조사·구현·검증을 반복하는 **내부 실행 루프**를 맡더라도, 엔지니어는 배포 여부를 결정하고 결과에 책임지는 **외부 루프**를 소유해야 함 - 에이전트 시스템은 사전 검사를 뜻하는 **품질(Quality)**, 프로덕션 투입 여부를 결정하는 **판정(Verdict)**, 결정 이유를 설명할 수 있게 하는 **설명 책임(Answerability)** 을 기반으로 운영됨 - Sonar의 2026년 조사에서 커밋된 코드의 **42%가 AI 생성 또는 상당한 AI 보조**를 받은 것으로 나타났으며, 생성 속도가 통제 속도를 앞지르면서 검토·검증·이해·유지보수가 희소 자원이 됨 - AI 활용에는 잘못된 답을 그대로 받아들이는 **인지적 항복**, 코드 이해를 약화하는 인지 부채, 여러 에이전트를 제한된 인간의 주의력으로 관리해야 하는 오케스트레이션 비용이 따름 - 확장 가능한 소프트웨어 팩토리는 에이전트에 최대 자율성이 아니라 **중단·조절·검증 가능한 자율성**을 부여하고, 인간이 제약·표본 검토·감사·소유권과 최종 결과를 책임질 때 가능함 --- ### 에이전틱 엔지니어링의 외부 루프 - 에이전틱 엔지니어링의 논의는 에이전트 **하네스**와 [루프](https://x.com/addyosmani/article/2064127981161959567?lang=en), 플릿, 소프트웨어 팩토리로 이동하고 있음 - Fable과 GPT-5.6 같은 강력한 모델이 등장할수록 엔지니어는 시스템에 대한 **책임**을 뜻하는 외부 루프를 직접 소유해야 함 - 에이전트의 높은 레버리지는 그에 상응하는 의무를 만듦 - 무엇이 바뀌었는지 정확히 설명할 수 있어야 함 - 해당 변경이 왜 안전했는지 설명해야 함 - 판단이 틀렸을 때 어떤 일이 일어날지 알아야 함 - 이 조건을 충족하지 못하면 에이전트의 행동을 정당화할 수 없고, 조직도 그런 시스템을 사용하기 어려움 ### 품질·판정·설명 책임 - **품질(Quality)** 은 시스템을 풀어놓기 전에 설치하는 모든 검사를 뜻하며, 여기서 얻은 증거가 판정의 기반이 됨 - **판정(Verdict)** 은 작업이 의존 시스템에 들어가기 전에 사람이 내리는 최종 프로덕션 결정임 - 모델이 코드를 작성해도 자신의 이름으로 작업을 배포하는 사람이 판정 책임을 짐 - 배포, 차단, 경로 변경, 응답 범위 축소, 가드레일 추가, 전면 거부 가운데 하나를 결정함 - **설명 책임(Answerability)** 은 누군가 이유를 물었을 때 해당 판단을 설명할 수 있다는 보장임 - 모델이 코드 한 줄을 작성할 수는 있지만, 의존 시스템으로 넘길지 결정하는 책임까지 대신하지는 않음 ### 모델·하네스·루프·팩토리 - 에이전트는 모델 하나가 아니라 **파일·도구·메모리·기술·샌드박스·권한·관측성·복구 기능**을 결합한 하네스까지 포함함 - 모델이 엔진이라면 하네스는 실제 작업을 안전하게 수행하도록 엔진 주위에 만든 자동차에 해당함 - 도구와 메모리는 작업 능력을 제공함 - 권한과 샌드박스는 실행 범위를 제한함 - 테스트와 관측성은 작업 결과를 확인하게 함 - 에이전트의 실행 루프는 **조사 → 구현 → 검증 → 반복**으로 구성됨 - 반복 가능한 주기가 한 번의 성공을 다시 신뢰할 수 있는 프로세스로 바꿈 - 작업 완료 여부는 모델 자신의 판단이 아니라 독립적인 검사로 결정해야 함 - 여러 루프를 동시에 운영하면 **소프트웨어 팩토리**가 됨 - 내부에서는 에이전트가 작업을 산출함 - 경계에서는 인간이 프로덕션 결정을 소유함 ### 시스템 안과 밖을 나누는 경계 - 소프트웨어 팩토리의 중심에는 시스템 **내부와 외부를 나누는 경계**가 있음 - 내부 시스템은 제품 팀의 의도, 과거 배포 작업에 관한 지식, 최근 장애, 구체적인 사용자 피드백을 입력으로 수집함 - 에이전트 루프는 작업을 조사하고 계획을 구현한 뒤 결과를 검증함 - 검증으로 생성된 **증거**가 시스템 경계를 넘어오면 의존 시스템을 소유한 인간이 진행 여부를 결정함 - 과거에는 에이전트가 실행 과정의 일부만 수행했지만, 이제는 내부 실행 루프 전체를 맡고 엔지니어가 외부 루프를 담당함 - 경계 안의 에이전트가 제공하는 것은 **역량(capability)** 임 - 작업 조사 - 계획 구현 - 결과 테스트 - 결과 보고 - 경계 밖의 인간이 행사하는 것은 **행위 주도권(agency)** 임 - 결정 - 검증 - 승인 - 소유 ### AI 코드가 만든 신뢰·검증 격차 - AI 코드의 비중은 더 이상 주변적인 수준에 머물지 않음 - [Sonar의 2026 State of Code 보고서](https://www.sonarsource.com/state-of-code-developer-survey-report.pdf)에 따르면 커밋된 코드의 **42%가 AI 생성 또는 상당한 AI 보조**를 받았으며, 응답자들은 그 비중이 정체되지 않고 계속 커질 것으로 예상함 - 코드 생성 비용이 낮아지면서 **검토·검증·이해·유지보수**가 더 희소한 자원이 됨 - 생성 속도가 통제 속도보다 빠르게 증가하면서 **신뢰·검증 격차**가 생김 - 많은 사람이 AI 코드에 불신을 나타냄 - 그 불신을 일관된 검증 절차로 구현하는 경우는 더 적음 - AI 코드의 신뢰성을 더 저렴하고 명확하게 확인할 방법이 필요함 ### 사후 거버넌스의 한계 - [GitLab의 2026년 6월 AI 책임 연구](https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx)에 따르면 AI 활용의 현재 병목은 **검토와 검증**임 - 거버넌스는 주로 코드가 만들어진 뒤에 적용됨 - 이 시점에는 조직이 이미 위험을 받아들인 상태임 - 작업 소유권에 대한 통제도 약해진 뒤임 - AI 거버넌스는 단순한 시스템 통제를 넘어 다음 사항을 정해야 함 - 시스템에 어떤 제약을 둘 것인지 - 어떤 증거로 작업을 검사할 것인지 - 팀에 어떻게 책임을 물을 것인지 - AI 수명주기의 각 부분을 누가 소유할 것인지 ### 품질을 만드는 역압 - 품질은 시스템에 작용하는 **역압(back pressure)** 으로 이해할 수 있음 - 목표는 에이전트가 행사할 수 있는 최대한의 자율성을 주는 것이 아님 - 에이전트를 중단하고 조절하며 작업을 검사하고 인간의 역할을 보존할 수 있을 정도로만 자율성을 부여해야 함 - 기존 엔지니어링에는 작업이 올바른 방향으로 진행되는지 보여주는 신호가 이미 존재함 - 타입 검사 - 테스트 - 훅 - 샌드박스 한도 - 감사 로그 - 모니터 - 에이전트도 같은 신호를 방출한다면 기존 엔지니어링 체계로 적절한 역압을 제공할 수 있음 ### 인간이 들어가야 할 네 가지 루프 - 시스템을 신뢰한다는 말은 인간을 루프에서 제외한다는 뜻이 아님 - 인간은 내부 실행 루프보다 다음 네 가지 **외부 통제 루프**에 있어야 함 - **제약 루프**: 어떤 입력, 아키텍처, 지침, 불변 조건을 설정할지 결정함 - **표본 검토 루프**: 출력 가운데 어느 정도를 추출해 검토할지 정함 - **감사 루프**: 어떤 증거를 보존하고 감사 로그의 유효성을 어떻게 보장할지 결정함 - **소유권 루프**: 프로덕션 경계의 어느 부분을 누가 소유할지 명확히 함 - 에이전트는 인간이 검토할 수 있는 양보다 더 많은 작업을 산출할 수 있음 - 따라서 희소 자원은 로그와 테스트 같은 품질 신호를 바탕으로 행사하는 **인간의 핵심 판단력**임 - [OpenAI의 에이전트와 일의 미래 연구](https://openai.com/index/how-agents-are-transforming-work/)가 다룬 실험 환경에서는 시간 단위 범위의 에이전틱 위임이 이미 가능한 단계에 도달함 - 시스템이 검토 가능량보다 많은 작업을 내놓기 전에 소유권 경계를 정립해야 함 ### 장기 실행 에이전트와 설명 책임 - 시간 단위로 실행되는 장기 에이전트가 내리는 선택은 모두 **결정**에 해당함 - 모든 결정이 기록되는 것은 아니며, 각각을 입력 토큰까지 역추적할 수도 없음 - 결과가 문제에 대한 올바른 선택이라고 믿기만 하면, 그 결과에 이른 결정 사슬을 재구성하는 데 수백 또는 수천 시간의 인간 노동이 필요할 수 있음 - 이런 결정 사슬은 사실상 재구성하기 어려우므로 **설명 책임**을 시스템 설계의 중심에 둬야 함 ### AI 위임의 세 가지 숨은 비용 - ## 인지적 항복 - **인지적 항복(cognitive surrender)** 은 AI가 내놓은 결과를 맹목적으로 받아들이는 현상임 - 작업을 에이전트에 맡겨도 결과물은 사용자의 작업과 평판, 책임에 연결됨 - 결함은 사용자의 소프트웨어에 남음 - 출력에 맞춰 변경해야 하는 대상도 사용자의 소프트웨어임 - 에이전트의 답은 결국 사용자의 답이 되고 책임도 함께 따라옴 - [Wharton 연구](https://executiveeducation.wharton.upenn.edu/thought-leadership/wharton-at-work/2026/05/thinking-fast-slow-and-artificially/)에서는 AI가 틀렸을 때도 참여자의 거의 **4분의 3**이 그 답을 받아들였고, AI 없이 판단했을 때보다 더 높은 자신감을 보였음 - ## 인지 부채 - **인지 부채(cognitive debt)** 는 문제 해결법에 대한 이해와 기억이 약해지는 현상임 - 에이전트에 작업을 위임하면 사고 과정도 함께 외부화됨 - 대규모 코드베이스를 스스로 이해하는 데 필요한 시간과 에너지는 학습 과정에서 확보하기 어려울 수 있음 - 그 결과 에이전트가 만든 산출물이 사용자의 현재 역량으로는 도달하기 어려운 수준이 되기도 함 - 에이전트의 계획 시간이 길어질수록 생성된 코드와 인간의 이해 사이의 격차가 커짐 - 이 격차는 누적되며, 학습 곡선을 다시 오르는 비용도 거의 기하급수적으로 증가함 - [Anthropic의 무작위 대조시험](https://www.anthropic.com/research/AI-assistance-coding-skills)에서는 AI로 코드를 작성한 엔지니어의 이해도 퀴즈 점수가 **50%** 로, 직접 작성한 집단의 **67%** 보다 17%포인트 낮았음 - ## 오케스트레이션 비용 - **오케스트레이션 비용(orchestration tax)** 은 많은 에이전트를 동시에 실행할 수 있어도 인간의 인지 대역폭은 같은 방식으로 병렬화되지 않는 데서 생김 - 인간은 다음 작업을 직접 수행해야 함 - 에이전트가 최악의 행동을 피하도록 조정함 - 산출물 가운데 주의가 필요한 작업을 골라냄 - 중요한 작업을 먼저 처리하도록 지시함 - 실행 전에 핵심 제약과 위험한 가정을 검증함 - 이 작업은 자동화할 수 없으며 **인간 판단**을 대체할 수 없음 ### 브라운필드에서 주의력을 보호하는 방법 - 브라운필드 시스템은 감사해야 할 동작이 코드에만 존재하지 않고 누적된 **상처와 역사**에도 남아 있어 특히 위험함 - 아키텍처 결정에서는 인간의 주의력을 우선순위로 둬야 함 - **worktree·범위·증거**를 사용하면 최초 계획과 실행 중 새로 드러난 작업 사이의 결합도를 낮출 수 있음 - 실행할 수 없는 단계의 해결 시도에는 시간 제한을 둬야 함 - 소프트웨어 변경 권한은 엄격한 **옵트인** 방식으로 부여해야 함 ### Alpha·decay·taste - 경력과 여러 분야의 성과를 형성하는 세 가지 핵심 패턴은 **alpha·decay·taste**임 - **Alpha**는 경쟁에서 가장 높은 성과를 내는 사람이 차지하는 선도 영역이자, 가장 가치가 높은 수를 두는 상태임 - **Decay**는 반복과 관찰을 통해 모두가 배우게 된 정착된 패턴이며, 일종의 정체 구간으로 볼 수 있음 - **Taste**는 alpha의 선도나 decay의 변화를 증거가 나타나기 전에 감지하는 판단력임 - [Paul Graham의 논의](https://paulgraham.com/taste.html)는 누구나 무엇이든 만들 수 있게 되면 무엇을 만들지 선택하는 일이 더 중요해진다는 것임 - Mitchell Hashimoto의 정의에서 taste는 아직 객관적인 측정 기준이 없을 때 내리는 **고품질의 정성적 판단**임 - alpha의 이동은 taste의 변화로 일어나고, decay는 사람들이 다른 것을 선호하기 시작할 때 사라짐 ### Taste를 운영 가능한 능력으로 만들기 - 직감에 머물던 taste를 의식적인 능력으로 옮기려면 먼저 **이름을 붙여야 함** - 비평과 구체적인 사례를 통해 해당 판단을 연습해야 함 - 판단의 근거도 명시적으로 표현해야 함 - 지속 가능한 경쟁 우위를 높이려면 역할의 경계를 계속 위로 이동해야 함 - 작업을 직접 수행함 - 다른 사람이나 시스템에 작업을 가르침 - 작업을 체계화함 - 언제 수행해야 하는지 결정함 - 결과를 소유함 ### 개발자와 엔지니어의 차이 - 누구나 개발자가 될 수 있지만 모두가 엔지니어인 것은 아님 - 개발자가 더 엄격한 **작업 규율**을 받아들일 때 엔지니어가 됨 - 철저하고 논리적으로 타당한 추론 - 제약과 절충안에 대한 고려 - 위험과 노출 범위의 인식 - 실질적인 책임 - 엔지니어링이 더 까다로워지면 사람들은 관리성 작업에서 벗어나, 장인정신에 묶여 있던 역할을 분리해 각자의 기능을 명확히 하게 됨 - 프로토타입을 만드는 사람 - 구축하는 사람 - 정리하는 사람 - 성장시키는 사람 - 유지보수하는 사람 ### 인간만이 지킬 수 있는 시스템 경계 - 인간은 시스템의 반대편 경계에서도 alpha를 높이는 역할을 맡음 - 무엇이 할 가치가 있는지 선택함 - 어떤 제약 안에서 수행할지 정함 - 진행하기에 증거가 충분한지 판단함 - 결과를 돌봄 - 팀 하나든 100개 팀이든 이 경계는 인간만이 소유할 수 있음 - **주의력·taste·책임**은 소프트웨어 팩토리가 작동하게 하는 핵심 요소임 - 책임이 없으면 규칙, 질문에 대한 대응, 절충안, 위험, 안전망도 성립하지 않음 - 결정의 결과를 소유하는 사람이 없다면 높은 행위 주도권은 혼란으로 이어짐 ### 기술보다 오래 남는 서명 - 기술적 우위의 반감기는 릴리스 하나일 수 있지만, 작업에 남긴 **서명(signature)** 의 반감기는 경력 전체에 걸침 - 서명은 배포한 결과에 자신의 이름을 걸고 지지할 수 있다는 뜻임 - 기술은 레버리지를 만들고 책임은 그 레버리지를 **신뢰**로 바꿈 - 선택하고 결과를 물려받는 주체는 사람뿐임 - 에이전트는 정책 안에서 선택, 경로 지정, 병합, 에스컬레이션을 수행할 수 있지만 그 결과를 물려받을 수는 없음 ### 코드베이스의 책임 계약 - 각 코드베이스에는 변경을 받아들일 때의 조건을 명시하는 **책임 계약**이 필요할 수 있음 - 승인할 때 이해한 내용을 확인하는 체크리스트 - 판단에 사용한 증거 - 변경을 책임지는 사람 - 변경을 차단한 뒤의 시스템 상태 - 계약은 주의력과 taste, 증거·판정·소유권, alpha·decay·taste 같은 연결 관계를 명시적으로 다뤄야 함 ### 높은 행위 주도권의 사다리 - 에이전틱 워크플로에서 **높은 행위 주도권**은 언제 위임하고 검사하며 중단하고 결과를 소유할지 아는 능력임 - 행위 주도권의 사다리는 낮은 단계에서 높은 단계로 이어짐 1. 잠재적 문제를 표시함 2. 문제를 조사함 3. 대응 작업을 실행함 4. 원인을 진단함 5. 해결책을 제안함 6. 수정안을 권고함 7. 문제를 해결함 - 더 높은 단계에는 문제를 발견했지만 고칠 가치가 없다고 판단하고 넘어가는 **분별력**도 포함됨 ### 브라운필드가 소프트웨어 팩토리의 최전선인 이유 - 브라운필드는 확장을 원하는 소프트웨어 팩토리가 맞닥뜨릴 **최전선**임 - 그린필드 시스템은 전체를 통제할 수 있어 충분한 역압 장치를 계획하고 구현하기 비교적 쉬움 - 레거시 시스템에 지능형 에이전트를 추가할 때는 코드 밖의 복잡성까지 다뤄야 함 - 전체 프로덕션 동작 - 고객의 미래 기대 - 마이그레이션 이력 - 릴리스 및 예산 주기 - 암묵적 가정 - 예외 상황 - 데이터의 특이성 - 런북 절차 - 관리되지 않은 채 누적된 상처 - 브라운필드를 돌보려면 **지속 가능한 엔지니어링**이 필요함 - 암묵지를 명시적 제약으로 바꿈 - 팀과 세대를 거쳐 지식을 일관되게 유지함 - 지식을 테스트 절차와 기능 명세로 공식화함 - 해당 지식을 객관적인 증거에 연결함 - 실패를 추가 학습으로 축적함 - 기존에 받던 수준의 관리가 끊기면 시스템 전체가 무너질 수 있음 ### 규모가 커질수록 생기는 새로운 작업 - 기존 구성 요소가 자동화되면 사람은 자신의 장인적 경험에서 얻은 alpha와 taste를 사용해 **새로운 작업**을 설계하게 됨 - 소프트웨어 팩토리에 접목할 새 루프를 설계함 - 팩토리에서 얻은 지식을 활용해 원칙적인 그린필드 시스템을 구축함 - 새로운 시스템을 검증할 수 있는 새로운 증거 형식을 만듦 - 전담 관리가 필요할 만큼 복잡해진 브라운필드 시스템을 돌봄 - 새로운 역압 장치를 설계하고 관리함 - 새로운 에이전트를 설계함 - 새로운 행위 주도권 체계를 구축함 - 이런 활동도 모두 실제 엔지니어링 작업이며, 규모가 커질수록 더 흥미로운 문제가 됨 ### 자동화가 이동시키는 병목 - 자동화는 산업적 규모에 대한 통제력을 주는 동시에 새로운 **병목**을 만듦 - 과거의 병목이 “이것을 만들 수 있는가?”였다면, 앞으로는 “이것이 존재해야 하는가, 그 결과를 설명하고 책임질 수 있는가?”로 이동함 - 프로덕션에서 새로 생긴 병목은 인간이 직접 소유할 가치가 있음 ### 에이전틱 엔지니어링의 운영 모델 - 내부 루프는 실제 작업이 이뤄지는 곳이며, 각 루프는 가능한 한 독립적으로 설계해야 함 - 모든 **품질 보증과 검증**을 내부 루프에 넣어야 함 - 루프 자체를 설계하고 검증한 뒤에는 실행 속도와 작업 범위를 통제하는 역압 장치를 설치해 자율성을 부여함 - 인간은 모든 내부 단계에 개입하는 대신 **올바른 결정 지점**에 배치해야 함 - 이해를 단순한 인수인계나 릴리스 게이트로 취급하지 말고, 인간이 통찰을 제공할 준비가 된 의사결정 지점으로 다뤄야 함 - 산출물이 프로덕션과 새 팀·엔지니어에게 다시 공급될 때마다 이전보다 나은 산출물과 증거를 남겨야 함 - 소프트웨어 팩토리를 구축하고 계속 운영하되, 작업을 **읽을 수 있고 검증할 수 있으며 소유자가 있는 상태**로 유지해야 함 - 에이전트가 코드를 작성하더라도 사용자에게 도달하기 전에는 사람이 다음 질문에 답해야 함 - 왜 이 코드가 존재해야 하는가 - 왜 프로덕션에 포함해도 충분히 안전한가 - 틀렸을 때 무엇을 할 것인가 - 이 판단과 책임을 수행하는 일이 에이전틱 엔지니어링의 **외부 루프**임 ## Comments _No public comments on this page._