• 에이전트가 조사·구현·검증을 반복하는
  내부 실행 루프를 맡더라도, 엔지니어는 배포 여부를 결정하고 결과에 책임지는 외부 루프를 소유해야 함
• 에이전트 시스템은 사전 검사를 뜻하는
  품질(Quality), 프로덕션 투입 여부를 결정하는 판정(Verdict), 결정 이유를 설명할 수 있게 하는 설명 책임(Answerability) 을 기반으로 운영됨
• Sonar의 2026년 조사에서 커밋된 코드의
  42%가 AI 생성 또는 상당한 AI 보조를 받은 것으로 나타났으며, 생성 속도가 통제 속도를 앞지르면서 검토·검증·이해·유지보수가 희소 자원이 됨
• AI 활용에는 잘못된 답을 그대로 받아들이는
  인지적 항복, 코드 이해를 약화하는 인지 부채, 여러 에이전트를 제한된 인간의 주의력으로 관리해야 하는 오케스트레이션 비용이 따름
• 확장 가능한 소프트웨어 팩토리는 에이전트에 최대 자율성이 아니라
  중단·조절·검증 가능한 자율성을 부여하고, 인간이 제약·표본 검토·감사·소유권과 최종 결과를 책임질 때 가능함

에이전틱 엔지니어링의 외부 루프

• 에이전틱 엔지니어링의 논의는 에이전트
  하네스와 루프, 플릿, 소프트웨어 팩토리로 이동하고 있음

• Fable과 GPT-5.6 같은 강력한 모델이 등장할수록 엔지니어는 시스템에 대한
  책임을 뜻하는 외부 루프를 직접 소유해야 함

• 에이전트의 높은 레버리지는 그에 상응하는 의무를 만듦

• 무엇이 바뀌었는지 정확히 설명할 수 있어야 함

• 해당 변경이 왜 안전했는지 설명해야 함

• 판단이 틀렸을 때 어떤 일이 일어날지 알아야 함

• 이 조건을 충족하지 못하면 에이전트의 행동을 정당화할 수 없고, 조직도 그런 시스템을 사용하기 어려움

품질·판정·설명 책임

품질(Quality) 은 시스템을 풀어놓기 전에 설치하는 모든 검사를 뜻하며, 여기서 얻은 증거가 판정의 기반이 됨
판정(Verdict) 은 작업이 의존 시스템에 들어가기 전에 사람이 내리는 최종 프로덕션 결정임

• 모델이 코드를 작성해도 자신의 이름으로 작업을 배포하는 사람이 판정 책임을 짐
• 배포, 차단, 경로 변경, 응답 범위 축소, 가드레일 추가, 전면 거부 가운데 하나를 결정함

설명 책임(Answerability) 은 누군가 이유를 물었을 때 해당 판단을 설명할 수 있다는 보장임

• 모델이 코드 한 줄을 작성할 수는 있지만, 의존 시스템으로 넘길지 결정하는 책임까지 대신하지는 않음

모델·하네스·루프·팩토리

• 에이전트는 모델 하나가 아니라
  파일·도구·메모리·기술·샌드박스·권한·관측성·복구 기능을 결합한 하네스까지 포함함

• 모델이 엔진이라면 하네스는 실제 작업을 안전하게 수행하도록 엔진 주위에 만든 자동차에 해당함

• 도구와 메모리는 작업 능력을 제공함

• 권한과 샌드박스는 실행 범위를 제한함

• 테스트와 관측성은 작업 결과를 확인하게 함

• 에이전트의 실행 루프는
  조사 → 구현 → 검증 → 반복으로 구성됨

• 반복 가능한 주기가 한 번의 성공을 다시 신뢰할 수 있는 프로세스로 바꿈

• 작업 완료 여부는 모델 자신의 판단이 아니라 독립적인 검사로 결정해야 함

• 여러 루프를 동시에 운영하면
  소프트웨어 팩토리가 됨

• 내부에서는 에이전트가 작업을 산출함

• 경계에서는 인간이 프로덕션 결정을 소유함

시스템 안과 밖을 나누는 경계

• 소프트웨어 팩토리의 중심에는 시스템
  내부와 외부를 나누는 경계가 있음
• 내부 시스템은 제품 팀의 의도, 과거 배포 작업에 관한 지식, 최근 장애, 구체적인 사용자 피드백을 입력으로 수집함
• 에이전트 루프는 작업을 조사하고 계획을 구현한 뒤 결과를 검증함
• 검증으로 생성된
  증거가 시스템 경계를 넘어오면 의존 시스템을 소유한 인간이 진행 여부를 결정함
• 과거에는 에이전트가 실행 과정의 일부만 수행했지만, 이제는 내부 실행 루프 전체를 맡고 엔지니어가 외부 루프를 담당함
• 경계 안의 에이전트가 제공하는 것은
  역량(capability) 임
• 경계 밖의 인간이 행사하는 것은
  행위 주도권(agency) 임

AI 코드가 만든 신뢰·검증 격차

• AI 코드의 비중은 더 이상 주변적인 수준에 머물지 않음

• Sonar의 2026 State of Code 보고서에 따르면 커밋된 코드의
  42%가 AI 생성 또는 상당한 AI 보조를 받았으며, 응답자들은 그 비중이 정체되지 않고 계속 커질 것으로 예상함

• 코드 생성 비용이 낮아지면서
  검토·검증·이해·유지보수가 더 희소한 자원이 됨

• 생성 속도가 통제 속도보다 빠르게 증가하면서
  신뢰·검증 격차가 생김

• 많은 사람이 AI 코드에 불신을 나타냄

• 그 불신을 일관된 검증 절차로 구현하는 경우는 더 적음

• AI 코드의 신뢰성을 더 저렴하고 명확하게 확인할 방법이 필요함

사후 거버넌스의 한계

• GitLab의 2026년 6월 AI 책임 연구에 따르면 AI 활용의 현재 병목은
  검토와 검증임

• 거버넌스는 주로 코드가 만들어진 뒤에 적용됨

• 이 시점에는 조직이 이미 위험을 받아들인 상태임

• 작업 소유권에 대한 통제도 약해진 뒤임

• AI 거버넌스는 단순한 시스템 통제를 넘어 다음 사항을 정해야 함

• 시스템에 어떤 제약을 둘 것인지

• 어떤 증거로 작업을 검사할 것인지

• 팀에 어떻게 책임을 물을 것인지

• AI 수명주기의 각 부분을 누가 소유할 것인지

품질을 만드는 역압

• 품질은 시스템에 작용하는
  역압(back pressure) 으로 이해할 수 있음

• 목표는 에이전트가 행사할 수 있는 최대한의 자율성을 주는 것이 아님

• 에이전트를 중단하고 조절하며 작업을 검사하고 인간의 역할을 보존할 수 있을 정도로만 자율성을 부여해야 함

• 기존 엔지니어링에는 작업이 올바른 방향으로 진행되는지 보여주는 신호가 이미 존재함

• 타입 검사

• 테스트

• 훅

• 샌드박스 한도

• 감사 로그

• 모니터

• 에이전트도 같은 신호를 방출한다면 기존 엔지니어링 체계로 적절한 역압을 제공할 수 있음

인간이 들어가야 할 네 가지 루프

• 시스템을 신뢰한다는 말은 인간을 루프에서 제외한다는 뜻이 아님

• 인간은 내부 실행 루프보다 다음 네 가지
  외부 통제 루프에 있어야 함
  제약 루프: 어떤 입력, 아키텍처, 지침, 불변 조건을 설정할지 결정함
  표본 검토 루프: 출력 가운데 어느 정도를 추출해 검토할지 정함
  감사 루프: 어떤 증거를 보존하고 감사 로그의 유효성을 어떻게 보장할지 결정함
  소유권 루프: 프로덕션 경계의 어느 부분을 누가 소유할지 명확히 함

• 에이전트는 인간이 검토할 수 있는 양보다 더 많은 작업을 산출할 수 있음

• 따라서 희소 자원은 로그와 테스트 같은 품질 신호를 바탕으로 행사하는
  인간의 핵심 판단력임

• OpenAI의 에이전트와 일의 미래 연구가 다룬 실험 환경에서는 시간 단위 범위의 에이전틱 위임이 이미 가능한 단계에 도달함

• 시스템이 검토 가능량보다 많은 작업을 내놓기 전에 소유권 경계를 정립해야 함

장기 실행 에이전트와 설명 책임

• 시간 단위로 실행되는 장기 에이전트가 내리는 선택은 모두
  결정에 해당함
• 모든 결정이 기록되는 것은 아니며, 각각을 입력 토큰까지 역추적할 수도 없음
• 결과가 문제에 대한 올바른 선택이라고 믿기만 하면, 그 결과에 이른 결정 사슬을 재구성하는 데 수백 또는 수천 시간의 인간 노동이 필요할 수 있음
• 이런 결정 사슬은 사실상 재구성하기 어려우므로
  설명 책임을 시스템 설계의 중심에 둬야 함

AI 위임의 세 가지 숨은 비용

인지적 항복

인지적 항복(cognitive surrender) 은 AI가 내놓은 결과를 맹목적으로 받아들이는 현상임

• 작업을 에이전트에 맡겨도 결과물은 사용자의 작업과 평판, 책임에 연결됨

• 결함은 사용자의 소프트웨어에 남음

• 출력에 맞춰 변경해야 하는 대상도 사용자의 소프트웨어임

• 에이전트의 답은 결국 사용자의 답이 되고 책임도 함께 따라옴

• Wharton 연구에서는 AI가 틀렸을 때도 참여자의 거의
  4분의 3이 그 답을 받아들였고, AI 없이 판단했을 때보다 더 높은 자신감을 보였음

인지 부채

인지 부채(cognitive debt) 는 문제 해결법에 대한 이해와 기억이 약해지는 현상임

• 에이전트에 작업을 위임하면 사고 과정도 함께 외부화됨

• 대규모 코드베이스를 스스로 이해하는 데 필요한 시간과 에너지는 학습 과정에서 확보하기 어려울 수 있음

• 그 결과 에이전트가 만든 산출물이 사용자의 현재 역량으로는 도달하기 어려운 수준이 되기도 함

• 에이전트의 계획 시간이 길어질수록 생성된 코드와 인간의 이해 사이의 격차가 커짐

• 이 격차는 누적되며, 학습 곡선을 다시 오르는 비용도 거의 기하급수적으로 증가함

• Anthropic의 무작위 대조시험에서는 AI로 코드를 작성한 엔지니어의 이해도 퀴즈 점수가
  50% 로, 직접 작성한 집단의 67% 보다 17%포인트 낮았음

오케스트레이션 비용

오케스트레이션 비용(orchestration tax) 은 많은 에이전트를 동시에 실행할 수 있어도 인간의 인지 대역폭은 같은 방식으로 병렬화되지 않는 데서 생김

• 인간은 다음 작업을 직접 수행해야 함

• 에이전트가 최악의 행동을 피하도록 조정함

• 산출물 가운데 주의가 필요한 작업을 골라냄

• 중요한 작업을 먼저 처리하도록 지시함

• 실행 전에 핵심 제약과 위험한 가정을 검증함

• 이 작업은 자동화할 수 없으며
  인간 판단을 대체할 수 없음

브라운필드에서 주의력을 보호하는 방법

• 브라운필드 시스템은 감사해야 할 동작이 코드에만 존재하지 않고 누적된
  상처와 역사에도 남아 있어 특히 위험함
• 아키텍처 결정에서는 인간의 주의력을 우선순위로 둬야 함
  worktree·범위·증거를 사용하면 최초 계획과 실행 중 새로 드러난 작업 사이의 결합도를 낮출 수 있음
• 실행할 수 없는 단계의 해결 시도에는 시간 제한을 둬야 함
• 소프트웨어 변경 권한은 엄격한
  옵트인 방식으로 부여해야 함

Alpha·decay·taste

• 경력과 여러 분야의 성과를 형성하는 세 가지 핵심 패턴은
  alpha·decay·taste임
  Alpha는 경쟁에서 가장 높은 성과를 내는 사람이 차지하는 선도 영역이자, 가장 가치가 높은 수를 두는 상태임
  Decay는 반복과 관찰을 통해 모두가 배우게 된 정착된 패턴이며, 일종의 정체 구간으로 볼 수 있음
  Taste는 alpha의 선도나 decay의 변화를 증거가 나타나기 전에 감지하는 판단력임
• Paul Graham의 논의는 누구나 무엇이든 만들 수 있게 되면 무엇을 만들지 선택하는 일이 더 중요해진다는 것임
• Mitchell Hashimoto의 정의에서 taste는 아직 객관적인 측정 기준이 없을 때 내리는
  고품질의 정성적 판단임
• alpha의 이동은 taste의 변화로 일어나고, decay는 사람들이 다른 것을 선호하기 시작할 때 사라짐

Taste를 운영 가능한 능력으로 만들기

• 직감에 머물던 taste를 의식적인 능력으로 옮기려면 먼저
  이름을 붙여야 함
• 비평과 구체적인 사례를 통해 해당 판단을 연습해야 함
• 판단의 근거도 명시적으로 표현해야 함
• 지속 가능한 경쟁 우위를 높이려면 역할의 경계를 계속 위로 이동해야 함
• 작업을 직접 수행함
• 다른 사람이나 시스템에 작업을 가르침
• 작업을 체계화함
• 언제 수행해야 하는지 결정함
• 결과를 소유함

개발자와 엔지니어의 차이

• 누구나 개발자가 될 수 있지만 모두가 엔지니어인 것은 아님

• 개발자가 더 엄격한
  작업 규율을 받아들일 때 엔지니어가 됨

• 철저하고 논리적으로 타당한 추론

• 제약과 절충안에 대한 고려

• 위험과 노출 범위의 인식

• 실질적인 책임

• 엔지니어링이 더 까다로워지면 사람들은 관리성 작업에서 벗어나, 장인정신에 묶여 있던 역할을 분리해 각자의 기능을 명확히 하게 됨

• 프로토타입을 만드는 사람

• 구축하는 사람

• 정리하는 사람

• 성장시키는 사람

• 유지보수하는 사람

인간만이 지킬 수 있는 시스템 경계

• 인간은 시스템의 반대편 경계에서도 alpha를 높이는 역할을 맡음

• 무엇이 할 가치가 있는지 선택함

• 어떤 제약 안에서 수행할지 정함

• 진행하기에 증거가 충분한지 판단함

• 결과를 돌봄

• 팀 하나든 100개 팀이든 이 경계는 인간만이 소유할 수 있음
  주의력·taste·책임은 소프트웨어 팩토리가 작동하게 하는 핵심 요소임

• 책임이 없으면 규칙, 질문에 대한 대응, 절충안, 위험, 안전망도 성립하지 않음

• 결정의 결과를 소유하는 사람이 없다면 높은 행위 주도권은 혼란으로 이어짐

기술보다 오래 남는 서명

• 기술적 우위의 반감기는 릴리스 하나일 수 있지만, 작업에 남긴
  서명(signature) 의 반감기는 경력 전체에 걸침
• 서명은 배포한 결과에 자신의 이름을 걸고 지지할 수 있다는 뜻임
• 기술은 레버리지를 만들고 책임은 그 레버리지를
  신뢰로 바꿈
• 선택하고 결과를 물려받는 주체는 사람뿐임
• 에이전트는 정책 안에서 선택, 경로 지정, 병합, 에스컬레이션을 수행할 수 있지만 그 결과를 물려받을 수는 없음

코드베이스의 책임 계약

• 각 코드베이스에는 변경을 받아들일 때의 조건을 명시하는
  책임 계약이 필요할 수 있음

• 승인할 때 이해한 내용을 확인하는 체크리스트

• 판단에 사용한 증거

• 변경을 책임지는 사람

• 변경을 차단한 뒤의 시스템 상태

• 계약은 주의력과 taste, 증거·판정·소유권, alpha·decay·taste 같은 연결 관계를 명시적으로 다뤄야 함

높은 행위 주도권의 사다리

• 에이전틱 워크플로에서
  높은 행위 주도권은 언제 위임하고 검사하며 중단하고 결과를 소유할지 아는 능력임

• 행위 주도권의 사다리는 낮은 단계에서 높은 단계로 이어짐

• 잠재적 문제를 표시함

• 문제를 조사함

• 대응 작업을 실행함

• 원인을 진단함

• 해결책을 제안함

• 수정안을 권고함

• 문제를 해결함

• 더 높은 단계에는 문제를 발견했지만 고칠 가치가 없다고 판단하고 넘어가는
  분별력도 포함됨

브라운필드가 소프트웨어 팩토리의 최전선인 이유

• 브라운필드는 확장을 원하는 소프트웨어 팩토리가 맞닥뜨릴
  최전선임

• 그린필드 시스템은 전체를 통제할 수 있어 충분한 역압 장치를 계획하고 구현하기 비교적 쉬움

• 레거시 시스템에 지능형 에이전트를 추가할 때는 코드 밖의 복잡성까지 다뤄야 함

• 전체 프로덕션 동작

• 고객의 미래 기대

• 마이그레이션 이력

• 릴리스 및 예산 주기

• 암묵적 가정

• 예외 상황

• 데이터의 특이성

• 런북 절차

• 관리되지 않은 채 누적된 상처

• 브라운필드를 돌보려면
  지속 가능한 엔지니어링이 필요함

• 암묵지를 명시적 제약으로 바꿈

• 팀과 세대를 거쳐 지식을 일관되게 유지함

• 지식을 테스트 절차와 기능 명세로 공식화함

• 해당 지식을 객관적인 증거에 연결함

• 실패를 추가 학습으로 축적함

• 기존에 받던 수준의 관리가 끊기면 시스템 전체가 무너질 수 있음

규모가 커질수록 생기는 새로운 작업

• 기존 구성 요소가 자동화되면 사람은 자신의 장인적 경험에서 얻은 alpha와 taste를 사용해
  새로운 작업을 설계하게 됨

• 소프트웨어 팩토리에 접목할 새 루프를 설계함

• 팩토리에서 얻은 지식을 활용해 원칙적인 그린필드 시스템을 구축함

• 새로운 시스템을 검증할 수 있는 새로운 증거 형식을 만듦

• 전담 관리가 필요할 만큼 복잡해진 브라운필드 시스템을 돌봄

• 새로운 역압 장치를 설계하고 관리함

• 새로운 에이전트를 설계함

• 새로운 행위 주도권 체계를 구축함

• 이런 활동도 모두 실제 엔지니어링 작업이며, 규모가 커질수록 더 흥미로운 문제가 됨

자동화가 이동시키는 병목

• 자동화는 산업적 규모에 대한 통제력을 주는 동시에 새로운
  병목을 만듦
• 과거의 병목이 “이것을 만들 수 있는가?”였다면, 앞으로는 “이것이 존재해야 하는가, 그 결과를 설명하고 책임질 수 있는가?”로 이동함
• 프로덕션에서 새로 생긴 병목은 인간이 직접 소유할 가치가 있음

에이전틱 엔지니어링의 운영 모델

• 내부 루프는 실제 작업이 이뤄지는 곳이며, 각 루프는 가능한 한 독립적으로 설계해야 함

• 모든
  품질 보증과 검증을 내부 루프에 넣어야 함

• 루프 자체를 설계하고 검증한 뒤에는 실행 속도와 작업 범위를 통제하는 역압 장치를 설치해 자율성을 부여함

• 인간은 모든 내부 단계에 개입하는 대신
  올바른 결정 지점에 배치해야 함

• 이해를 단순한 인수인계나 릴리스 게이트로 취급하지 말고, 인간이 통찰을 제공할 준비가 된 의사결정 지점으로 다뤄야 함

• 산출물이 프로덕션과 새 팀·엔지니어에게 다시 공급될 때마다 이전보다 나은 산출물과 증거를 남겨야 함

• 소프트웨어 팩토리를 구축하고 계속 운영하되, 작업을
  읽을 수 있고 검증할 수 있으며 소유자가 있는 상태로 유지해야 함

• 에이전트가 코드를 작성하더라도 사용자에게 도달하기 전에는 사람이 다음 질문에 답해야 함

• 왜 이 코드가 존재해야 하는가

• 왜 프로덕션에 포함해도 충분히 안전한가

• 틀렸을 때 무엇을 할 것인가

• 이 판단과 책임을 수행하는 일이 에이전틱 엔지니어링의
  외부 루프임

댓글과 토론