Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
에이전트 시스템에서 내부 실행 루프는 AI가 맡지만, 엔지니어는 배포 결정과 책임이 따르는 외부 루프를 소유해야 합니다. 에이전틱 엔지니어링은 '품질(Quality)', '판정(Verdict)', '설명 책임(Answerability)'을 기반으로 운영되며, 인간의 최종 검증과 통제가 필수적입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기에이전틱 엔지니어링의 논의는 에이전트
하네스와 루프, 플릿, 소프트웨어 팩토리로 이동하고 있음
Fable과 GPT-5.6 같은 강력한 모델이 등장할수록 엔지니어는 시스템에 대한
책임을 뜻하는 외부 루프를 직접 소유해야 함
에이전트의 높은 레버리지는 그에 상응하는 의무를 만듦
무엇이 바뀌었는지 정확히 설명할 수 있어야 함
해당 변경이 왜 안전했는지 설명해야 함
판단이 틀렸을 때 어떤 일이 일어날지 알아야 함
이 조건을 충족하지 못하면 에이전트의 행동을 정당화할 수 없고, 조직도 그런 시스템을 사용하기 어려움
품질(Quality) 은 시스템을 풀어놓기 전에 설치하는 모든 검사를 뜻하며, 여기서 얻은 증거가 판정의 기반이 됨
판정(Verdict) 은 작업이 의존 시스템에 들어가기 전에 사람이 내리는 최종 프로덕션 결정임
설명 책임(Answerability) 은 누군가 이유를 물었을 때 해당 판단을 설명할 수 있다는 보장임
에이전트는 모델 하나가 아니라
파일·도구·메모리·기술·샌드박스·권한·관측성·복구 기능을 결합한 하네스까지 포함함
모델이 엔진이라면 하네스는 실제 작업을 안전하게 수행하도록 엔진 주위에 만든 자동차에 해당함
도구와 메모리는 작업 능력을 제공함
권한과 샌드박스는 실행 범위를 제한함
테스트와 관측성은 작업 결과를 확인하게 함
에이전트의 실행 루프는
조사 → 구현 → 검증 → 반복으로 구성됨
반복 가능한 주기가 한 번의 성공을 다시 신뢰할 수 있는 프로세스로 바꿈
작업 완료 여부는 모델 자신의 판단이 아니라 독립적인 검사로 결정해야 함
여러 루프를 동시에 운영하면
소프트웨어 팩토리가 됨
내부에서는 에이전트가 작업을 산출함
경계에서는 인간이 프로덕션 결정을 소유함
AI 코드의 비중은 더 이상 주변적인 수준에 머물지 않음
Sonar의 2026 State of Code 보고서에 따르면 커밋된 코드의
42%가 AI 생성 또는 상당한 AI 보조를 받았으며, 응답자들은 그 비중이 정체되지 않고 계속 커질 것으로 예상함
코드 생성 비용이 낮아지면서
검토·검증·이해·유지보수가 더 희소한 자원이 됨
생성 속도가 통제 속도보다 빠르게 증가하면서
신뢰·검증 격차가 생김
많은 사람이 AI 코드에 불신을 나타냄
그 불신을 일관된 검증 절차로 구현하는 경우는 더 적음
AI 코드의 신뢰성을 더 저렴하고 명확하게 확인할 방법이 필요함
GitLab의 2026년 6월 AI 책임 연구에 따르면 AI 활용의 현재 병목은
검토와 검증임
거버넌스는 주로 코드가 만들어진 뒤에 적용됨
이 시점에는 조직이 이미 위험을 받아들인 상태임
작업 소유권에 대한 통제도 약해진 뒤임
AI 거버넌스는 단순한 시스템 통제를 넘어 다음 사항을 정해야 함
시스템에 어떤 제약을 둘 것인지
어떤 증거로 작업을 검사할 것인지
팀에 어떻게 책임을 물을 것인지
AI 수명주기의 각 부분을 누가 소유할 것인지
품질은 시스템에 작용하는
역압(back pressure) 으로 이해할 수 있음
목표는 에이전트가 행사할 수 있는 최대한의 자율성을 주는 것이 아님
에이전트를 중단하고 조절하며 작업을 검사하고 인간의 역할을 보존할 수 있을 정도로만 자율성을 부여해야 함
기존 엔지니어링에는 작업이 올바른 방향으로 진행되는지 보여주는 신호가 이미 존재함
타입 검사
테스트
훅
샌드박스 한도
감사 로그
모니터
에이전트도 같은 신호를 방출한다면 기존 엔지니어링 체계로 적절한 역압을 제공할 수 있음
시스템을 신뢰한다는 말은 인간을 루프에서 제외한다는 뜻이 아님
인간은 내부 실행 루프보다 다음 네 가지
외부 통제 루프에 있어야 함
제약 루프: 어떤 입력, 아키텍처, 지침, 불변 조건을 설정할지 결정함
표본 검토 루프: 출력 가운데 어느 정도를 추출해 검토할지 정함
감사 루프: 어떤 증거를 보존하고 감사 로그의 유효성을 어떻게 보장할지 결정함
소유권 루프: 프로덕션 경계의 어느 부분을 누가 소유할지 명확히 함
에이전트는 인간이 검토할 수 있는 양보다 더 많은 작업을 산출할 수 있음
따라서 희소 자원은 로그와 테스트 같은 품질 신호를 바탕으로 행사하는
인간의 핵심 판단력임
OpenAI의 에이전트와 일의 미래 연구가 다룬 실험 환경에서는 시간 단위 범위의 에이전틱 위임이 이미 가능한 단계에 도달함
시스템이 검토 가능량보다 많은 작업을 내놓기 전에 소유권 경계를 정립해야 함
인지적 항복(cognitive surrender) 은 AI가 내놓은 결과를 맹목적으로 받아들이는 현상임
작업을 에이전트에 맡겨도 결과물은 사용자의 작업과 평판, 책임에 연결됨
결함은 사용자의 소프트웨어에 남음
출력에 맞춰 변경해야 하는 대상도 사용자의 소프트웨어임
에이전트의 답은 결국 사용자의 답이 되고 책임도 함께 따라옴
Wharton 연구에서는 AI가 틀렸을 때도 참여자의 거의
4분의 3이 그 답을 받아들였고, AI 없이 판단했을 때보다 더 높은 자신감을 보였음
인지 부채(cognitive debt) 는 문제 해결법에 대한 이해와 기억이 약해지는 현상임
에이전트에 작업을 위임하면 사고 과정도 함께 외부화됨
대규모 코드베이스를 스스로 이해하는 데 필요한 시간과 에너지는 학습 과정에서 확보하기 어려울 수 있음
그 결과 에이전트가 만든 산출물이 사용자의 현재 역량으로는 도달하기 어려운 수준이 되기도 함
에이전트의 계획 시간이 길어질수록 생성된 코드와 인간의 이해 사이의 격차가 커짐
이 격차는 누적되며, 학습 곡선을 다시 오르는 비용도 거의 기하급수적으로 증가함
Anthropic의 무작위 대조시험에서는 AI로 코드를 작성한 엔지니어의 이해도 퀴즈 점수가
50% 로, 직접 작성한 집단의 67% 보다 17%포인트 낮았음
오케스트레이션 비용(orchestration tax) 은 많은 에이전트를 동시에 실행할 수 있어도 인간의 인지 대역폭은 같은 방식으로 병렬화되지 않는 데서 생김
인간은 다음 작업을 직접 수행해야 함
에이전트가 최악의 행동을 피하도록 조정함
산출물 가운데 주의가 필요한 작업을 골라냄
중요한 작업을 먼저 처리하도록 지시함
실행 전에 핵심 제약과 위험한 가정을 검증함
이 작업은 자동화할 수 없으며
인간 판단을 대체할 수 없음
누구나 개발자가 될 수 있지만 모두가 엔지니어인 것은 아님
개발자가 더 엄격한
작업 규율을 받아들일 때 엔지니어가 됨
철저하고 논리적으로 타당한 추론
제약과 절충안에 대한 고려
위험과 노출 범위의 인식
실질적인 책임
엔지니어링이 더 까다로워지면 사람들은 관리성 작업에서 벗어나, 장인정신에 묶여 있던 역할을 분리해 각자의 기능을 명확히 하게 됨
프로토타입을 만드는 사람
구축하는 사람
정리하는 사람
성장시키는 사람
유지보수하는 사람
인간은 시스템의 반대편 경계에서도 alpha를 높이는 역할을 맡음
무엇이 할 가치가 있는지 선택함
어떤 제약 안에서 수행할지 정함
진행하기에 증거가 충분한지 판단함
결과를 돌봄
팀 하나든 100개 팀이든 이 경계는 인간만이 소유할 수 있음
주의력·taste·책임은 소프트웨어 팩토리가 작동하게 하는 핵심 요소임
책임이 없으면 규칙, 질문에 대한 대응, 절충안, 위험, 안전망도 성립하지 않음
결정의 결과를 소유하는 사람이 없다면 높은 행위 주도권은 혼란으로 이어짐
각 코드베이스에는 변경을 받아들일 때의 조건을 명시하는
책임 계약이 필요할 수 있음
승인할 때 이해한 내용을 확인하는 체크리스트
판단에 사용한 증거
변경을 책임지는 사람
변경을 차단한 뒤의 시스템 상태
계약은 주의력과 taste, 증거·판정·소유권, alpha·decay·taste 같은 연결 관계를 명시적으로 다뤄야 함
에이전틱 워크플로에서
높은 행위 주도권은 언제 위임하고 검사하며 중단하고 결과를 소유할지 아는 능력임
행위 주도권의 사다리는 낮은 단계에서 높은 단계로 이어짐
잠재적 문제를 표시함
문제를 조사함
대응 작업을 실행함
원인을 진단함
해결책을 제안함
수정안을 권고함
문제를 해결함
더 높은 단계에는 문제를 발견했지만 고칠 가치가 없다고 판단하고 넘어가는
분별력도 포함됨
브라운필드는 확장을 원하는 소프트웨어 팩토리가 맞닥뜨릴
최전선임
그린필드 시스템은 전체를 통제할 수 있어 충분한 역압 장치를 계획하고 구현하기 비교적 쉬움
레거시 시스템에 지능형 에이전트를 추가할 때는 코드 밖의 복잡성까지 다뤄야 함
전체 프로덕션 동작
고객의 미래 기대
마이그레이션 이력
릴리스 및 예산 주기
암묵적 가정
예외 상황
데이터의 특이성
런북 절차
관리되지 않은 채 누적된 상처
브라운필드를 돌보려면
지속 가능한 엔지니어링이 필요함
암묵지를 명시적 제약으로 바꿈
팀과 세대를 거쳐 지식을 일관되게 유지함
지식을 테스트 절차와 기능 명세로 공식화함
해당 지식을 객관적인 증거에 연결함
실패를 추가 학습으로 축적함
기존에 받던 수준의 관리가 끊기면 시스템 전체가 무너질 수 있음
기존 구성 요소가 자동화되면 사람은 자신의 장인적 경험에서 얻은 alpha와 taste를 사용해
새로운 작업을 설계하게 됨
소프트웨어 팩토리에 접목할 새 루프를 설계함
팩토리에서 얻은 지식을 활용해 원칙적인 그린필드 시스템을 구축함
새로운 시스템을 검증할 수 있는 새로운 증거 형식을 만듦
전담 관리가 필요할 만큼 복잡해진 브라운필드 시스템을 돌봄
새로운 역압 장치를 설계하고 관리함
새로운 에이전트를 설계함
새로운 행위 주도권 체계를 구축함
이런 활동도 모두 실제 엔지니어링 작업이며, 규모가 커질수록 더 흥미로운 문제가 됨
내부 루프는 실제 작업이 이뤄지는 곳이며, 각 루프는 가능한 한 독립적으로 설계해야 함
모든
품질 보증과 검증을 내부 루프에 넣어야 함
루프 자체를 설계하고 검증한 뒤에는 실행 속도와 작업 범위를 통제하는 역압 장치를 설치해 자율성을 부여함
인간은 모든 내부 단계에 개입하는 대신
올바른 결정 지점에 배치해야 함
이해를 단순한 인수인계나 릴리스 게이트로 취급하지 말고, 인간이 통찰을 제공할 준비가 된 의사결정 지점으로 다뤄야 함
산출물이 프로덕션과 새 팀·엔지니어에게 다시 공급될 때마다 이전보다 나은 산출물과 증거를 남겨야 함
소프트웨어 팩토리를 구축하고 계속 운영하되, 작업을
읽을 수 있고 검증할 수 있으며 소유자가 있는 상태로 유지해야 함
에이전트가 코드를 작성하더라도 사용자에게 도달하기 전에는 사람이 다음 질문에 답해야 함
왜 이 코드가 존재해야 하는가
왜 프로덕션에 포함해도 충분히 안전한가
틀렸을 때 무엇을 할 것인가
이 판단과 책임을 수행하는 일이 에이전틱 엔지니어링의
외부 루프임