코딩 에이전트를 잘 쓰는 팀은 판단을 자산으로 남깁니다

밤새 에이전트가 일했다는 사실만으로는 생산성을 알 수 없습니다. 아침에 무엇이 완성되었는지, 그것을 믿고 쓰기 위해 사람이 얼마나 더 일해야 하는지가 남아 있기 때문입니다.

Andrew Ng는 코딩 에이전트 활용 역량에 관한 글에서 이 차이를 지적합니다. 수시간 동안 수백만·수천만 토큰을 쓰게 하는 방식도 유용할 수 있지만, 아주 긴 작업을 자율적으로 맡기는 방식의 실용성은 비용 대비 과장되어 있다는 것입니다. 실제로 효과적인 사용은 계획, 구현, 검증을 오가며 숙련된 판단으로 개입하는 과정에 가깝다고 설명합니다.

그의 주장은 “AI를 덜 쓰자”는 권고가 아닙니다. 무엇을 맡길지, 언제 개입할지, 어떤 증거가 있어야 완료로 인정할지를 더 잘 결정하자는 제안입니다. Ng가 이 설명을 만들 때 사용한 근거는 수십 명의 AI 엔지니어 인터뷰와 자기 팀의 경험입니다. 특정 방식의 생산성 우위를 대조실험으로 입증한 연구와는 구분해야 합니다.

이 구분을 기업의 경쟁력으로 옮기면 한 가지 질문이 생깁니다. 숙련자가 한 번 내린 판단이 다음 작업에서도 쓰이는가, 아니면 매번 대화창에서 다시 소비되는가. 같은 모델을 쓰더라도 이 질문에 대한 답이 다르면 팀의 생산성은 달라질 수 있습니다. 이 글의 사업적 해석은 이 지점에서 출발합니다.

코드를 덜 쓰더라도, 개발 전체를 이해해야 합니다

Ng가 제시한 작업 흐름은 낯설지 않습니다. 먼저 조사하고 요구사항과 설계를 정합니다. 다음으로 구현하고 검사합니다. 실제 환경에 배포한 뒤에는 오류와 사용자 반응을 관찰해 다시 고칩니다. 에이전트가 들어왔다고 소프트웨어 개발의 기본 문제가 사라지는 것은 아닙니다.

달라지는 것은 사람의 주의를 배분하는 위치입니다. 직접 코드를 입력하는 시간의 일부를 줄이는 대신, 무엇을 만들 것인지, 기존 시스템 어디를 바꿀 것인지, 어떤 결과를 허용할 것인지에 더 많은 판단을 투입할 수 있습니다. 구현이 틀렸으면 구현으로 돌아가지만, 요구사항 자체가 틀렸으면 기획으로 돌아가야 합니다. 잘못된 목표를 정교하게 구현하는 것은 성공이 아닙니다.

앞서 다룬 AI 애플리케이션을 구축하고 배포하는 역량은 AI를 제품의 구성요소로 쓰는 능력에 관한 글이었습니다. 이번 주제는 에이전트를 제품을 만드는 작업자로 쓰는 능력입니다. 만드는 제품이 반드시 AI 제품일 필요도 없습니다. Ng는 데이터 분석과 시스템 운영 같은 비코딩 업무까지 이 범위에 포함합니다.

Ng의 역량 구분을 실무에서 확인할 수 있는 결과물에 연결하면 다음과 같습니다. 오른쪽 열은 원문의 번역이 아니라 필자의 실무적 해석입니다.

Ng가 제시한 역량	실제로 결정해야 하는 것	팀에 남아야 하는 결과물
작업 흐름 지휘	조사·설계·구현에 각각 얼마나 투자하고, 언제 앞 단계로 돌아갈지	요구사항, 설계 결정, 검증 가능한 작업 단위
자율성 부여	어떤 범위를 혼자 처리하게 하고, 어디서 멈추거나 승인받게 할지	권한 범위, 실행 예산, 중단·승인 조건
결과 검토	무엇을 성공으로 볼지, 자동 검사와 사람 판단을 어떻게 나눌지	테스트, 평가 사례, 사용자 확인, 배포 증거
에이전트와 환경 관리	필요한 정보와 도구를 어떻게 제공하고 오래된 규칙을 어떻게 없앨지	공통 지침, 현재 상태, 도구 설정, 변경 이력
작동 원리 이해	정보 누락·과도한 설계·성급한 완료를 어떻게 구별할지	실패 원인에 맞는 수정과 재현 가능한 검증

이 역량들은 별개 자격증처럼 쌓이지 않습니다. 작업을 어떻게 나누느냐에 따라 필요한 정보와 권한이 달라지고, 검증이 얼마나 명확하냐에 따라 허용할 수 있는 자율성이 달라집니다.

좋은 명세는 긴 문서가 아니라, 오해할 여지가 적은 약속입니다

가상의 구독 서비스를 생각해보겠습니다. 고객지원 담당자가 사용할 환불 기능을 에이전트에게 만들어 달라고 지시합니다.

시연용 화면이라면 “주문을 선택하면 환불 결과가 보인다”는 짧은 설명으로 시작할 수 있습니다. 가짜 데이터로 동작을 확인하고, 담당자가 원하는 화면인지 물어보면 됩니다. 이 단계에서 장기 확장성과 모든 예외를 설계하는 것은 낭비일 수 있습니다.

실제 고객과 결제 시스템이 붙어 있는 서비스라면 질문이 달라집니다. 이미 일부 환불한 주문은 어떻게 처리합니까. 버튼을 두 번 눌러도 같은 금액이 두 번 지급되지 않습니까. 누가 실행할 수 있고, 결과가 확정되기 전에 통신이 끊기면 무엇을 표시합니까. 기존 주문 내역과 회계 기록은 어떤 상태로 남아야 합니까.

“환불 기능”이라는 이름은 같지만, 필요한 명세와 검증은 크게 다릅니다. Ng가 새로 만드는 시제품과 많은 사용자가 있는 기존 프로젝트를 구분한 이유도 여기에 있습니다. 문서의 길이는 작업의 크기보다 오해했을 때의 비용에 맞춰야 합니다.

이 사례에서 구현 전에 합의할 것은 구체적입니다. 이번에는 전액 환불만 지원하며 부분 환불은 제외한다는 범위, 승인된 담당자만 실행한다는 권한, 같은 요청이 반복되어도 결과는 한 번만 반영된다는 조건, 결과가 불명확하면 임의로 완료 처리하지 않는다는 중단 규칙입니다. 이들은 문장을 꾸미기 위한 설명이 아니라, 구현과 테스트를 함께 결정하는 약속입니다.

명세 작성도 에이전트에게 맡길 수 있습니다. 다만 에이전트가 낸 초안을 승인하는 것과 사업상 요구를 결정하는 것은 다른 일입니다. 환불 정책을 정할 권한이 없는 에이전트가 기술적으로 편한 정책을 선택하게 해서는 안 됩니다. 반대로 사람이 모든 구현 세부를 먼저 결정하면 에이전트가 탐색할 여지를 없애고 불필요한 설계를 고정할 수 있습니다.

좋은 분업은 목적과 제약은 명확하게, 구현 방법은 필요한 만큼 열어두는 것에 가깝습니다. 중간에 정책이 바뀌었다면 채팅에서 한 번 알리는 것으로 끝내지 않고, 현재 명세와 검사 기준도 함께 바꿔야 합니다. 다음 작업자가 옛 가정으로 돌아가면 앞선 수정은 유지되지 않습니다.

자율성은 프로젝트 전체가 아니라, 작업마다 다르게 줍니다

에이전트를 적극적으로 쓰는 것과 모든 권한을 한꺼번에 주는 것은 별개입니다. 같은 환불 기능을 개발하더라도, 가짜 주문으로 테스트를 반복하는 일과 실제 고객에게 환불을 실행하는 일은 다른 권한으로 다뤄야 합니다.

필자는 자율성의 범위를 정할 때 우선 결과를 얼마나 분명하게 검증할 수 있는지, 잘못되었을 때 얼마나 되돌리기 쉬운지를 봅니다. 여기에 외부 고객과 데이터에 미치는 범위, 작업 예산, 사람이 개입할 수 있는 시점을 더합니다. 아래 도식은 Ng의 자율성 배분 원칙을 구체화한 판단 예시입니다.

격리된 개발 환경에서 정해진 검사를 통과할 때까지 수정하게 하는 작업은 비교적 넓게 맡길 수 있습니다. 반면 확인하기 어려운 사업 정책을 바꾸거나 많은 고객에게 영향을 미치는 조치라면, 중간 판단을 사람이 소유하고 실행 범위를 더 작게 나누는 편이 합리적입니다.

여기서 격리는 단지 “조심하라”는 지시가 아닙니다. 개발용 데이터만 읽게 하거나, 수정 가능한 파일과 외부 연결을 제한하거나, 실제 환경에 반영하는 권한을 따로 두는 식의 실행 조건입니다. 안전에 관한 문장과 실제 권한은 일치해야 합니다.

병렬 실행도 같은 원리로 다뤄야 합니다. 환불 정책을 정하는 에이전트, 화면을 만드는 에이전트, 검사를 만드는 에이전트가 서로 다른 정책을 전제하면 각자의 작업은 성공해도 합친 제품은 틀릴 수 있습니다. 작업을 동시에 시작하기 전에 공유해야 할 인터페이스와 현재 가정을 정하고, 서로의 결과에 의존하는 부분은 순서를 지켜야 합니다.

사람의 주의도 제한된 자원입니다. 병렬 작업 수를 늘렸는데 승인 대기와 결과 통합이 더 오래 걸린다면 전체 처리량이 늘었다고 보기 어렵습니다. 평가해야 할 것은 실행 중인 에이전트 수보다 같은 품질 기준 아래 사람이 끝까지 받아들인 결과와 그에 들인 시간입니다.

테스트를 통과했다는 말보다, 무엇을 검사했는지가 중요합니다

환불 기능을 작성한 에이전트가 테스트까지 만든다고 하겠습니다. 에이전트가 처음부터 “통신 성공 응답이 오면 환불 완료”라고 잘못 이해했다면, 코드와 테스트가 같은 오해를 공유할 수 있습니다. 테스트가 모두 통과해도 원래 요구사항을 충족했다는 보장은 없습니다.

따라서 구현을 검토하는 일에는 검사가 올바른 목표를 측정하는지 확인하는 일이 포함되어야 합니다. 같은 주문에 두 번 요청을 보내도 중복 지급이 없는지, 권한이 없는 사용자는 실행하지 못하는지, 처리 결과가 불확실할 때 기존 기록을 손상하지 않는지처럼 구현 바깥에서 정한 조건을 대조해야 합니다. 기존의 정상 동작과 실제 장애에서 얻은 재현 사례도 기준이 될 수 있습니다.

Anthropic은 장기 실행 에이전트에 관한 개발 사례에서 부분 검사만 마치고 기능을 완성했다고 판단하는 문제를 설명합니다. 이를 줄이기 위해 기능별 성공 조건을 미리 만들고, 한 번에 한 기능씩 진행하며, 실제 브라우저에서 사용자 흐름을 확인하도록 했습니다. 검사를 지우거나 고쳐서 성공한 것처럼 처리하지 않도록 하는 지침도 포함했습니다. 이는 공급자의 개발 경험이며, 모든 업무에서 동일한 효과를 보장하는 실험은 아닙니다.

화면 캡처는 버튼이 보이거나 특정 화면으로 이동했다는 증거가 될 수 있습니다. 그러나 장부 기록이 맞는지까지 증명하지는 않습니다. 사용자의 흐름은 화면에서, 데이터의 일관성은 데이터에서 확인해야 합니다. 증거의 종류가 검사하려는 주장과 맞아야 합니다.

정답이 하나가 아닌 결과에는 다른 검토가 필요합니다. 고객 안내 문구가 이해하기 쉬운지, 지원 담당자가 불확실한 상태를 알아볼 수 있는지는 대표 사례와 사람의 판단을 함께 써야 합니다. Ng가 언급한 모델 기반 평가도 사용할 수 있지만, 평가 모델이 같은 오해를 반복하지 않는지 확인해야 합니다. 다른 에이전트에게 한 번 더 물었다는 사실만으로 독립 검증이 되지는 않습니다.

배포도 완료 선언만으로 끝나지 않습니다. 의도한 버전이 실제 환경에서 실행되는지, 핵심 동작이 유지되는지, 문제가 생겼을 때 어디까지 되돌릴 수 있는지 확인해야 합니다. 감시 에이전트가 로그를 보고 문제를 찾게 할 수는 있어도, 모든 오류를 스스로 수정하고 재배포할 권한까지 자동으로 따라오는 것은 아닙니다.

환경을 잘 관리한다는 것은, 무엇을 지울지도 안다는 뜻입니다

Ng는 코딩 에이전트의 작동 원리도 별도 역량으로 다룹니다. 모델 주변에는 자료 검색, 도구 실행, 권한, 작업 상태, 재시도와 검사 기능을 묶은 실행 장치가 있습니다. 흔히 하네스라고 부르는 부분입니다. 결과가 잘못되었을 때 모델의 추론이 부족한 것인지, 필요한 정보를 못 찾은 것인지, 도구나 검사가 없었던 것인지 구분하려면 이 구조를 알아야 합니다.

문제가 정보 누락인데 더 비싼 모델로 바꾸는 것은 해결책이 아닐 수 있습니다. 반대로 이미 해결 능력이 높아진 모델에 옛 약점을 보완하던 복잡한 지침을 계속 덧씌우면 불필요한 작업을 늘릴 수 있습니다. Ng가 스킬과 플러그인을 추가하는 능력뿐 아니라, 필요 없어진 것을 정리하는 능력까지 언급한 대목이 중요합니다.

Anthropic의 맥락 관리 설명도 모든 자료를 한꺼번에 넣는 접근을 권하지 않습니다. 필요한 정보가 어디에 있는지 식별할 수 있게 하고, 작업 시점에 맞춰 불러오도록 설계합니다. 역할이 중복되거나 선택 기준이 불분명한 도구를 지나치게 많이 제공하는 것도 실패 원인으로 지적합니다.

이 원칙을 팀 운영에 적용한다면 저장할 정보의 성격을 구분하는 편이 좋습니다. 현재 유효한 요구사항과 설계 결정은 작업 기준으로 둡니다. 무엇을 시도했고 어떤 검사가 통과했는지는 실행 기록으로 둡니다. 반복되는 실패에서 확인한 원칙은 공통 지침이나 자동 검사로 승격합니다. 아직 검증하지 않은 추측을 공통 규칙에 바로 넣지 않는 것이 중요합니다.

AGENTS.md나 CLAUDE.md 같은 공통 지침 파일에는 모든 대화를 복사할 필요가 없습니다. 어디서 현재 명세를 찾는지, 무엇을 수정하면 안 되는지, 어떤 검사를 실행해야 하는지가 분명해야 합니다. 작업 중에 바뀐 가정은 변경 이유와 적용 범위를 남기고, 폐기한 가정은 현재 지침에서 제외해야 합니다.

도구 연결도 설치 개수보다 기능 분담이 중요합니다. MCP는 외부 자료와 도구를 연결하는 표준 인터페이스로 이해하면 됩니다. 연결했다고 자료의 최신성이나 실행 권한이 자동으로 검증되지는 않습니다. 반복 실행이 필요한 검사는 사람이 매번 부탁하기보다, 특정 변경 뒤에 정해진 검사를 실행하는 연결 장치인 훅으로 묶는 편이 나을 수 있습니다. 다만 연결 장치 자체가 제대로 동작하는지도 검사해야 합니다.

실행이 끝난 뒤의 회고 역시 긴 감상문일 필요가 없습니다. 어떤 오류가 났고, 왜 기존 검사로 못 잡았으며, 다음부터 어느 기준이 달라지는지만 남겨도 됩니다. 대화 기록의 양보다, 검증을 거쳐 다시 사용할 수 있게 된 판단의 양이 중요합니다.

오래 맡기는 능력과 잘 맡기는 능력은 함께 발전할 수 있습니다

Ng의 경고를 장기 자율 실행에 대한 부정으로 읽으면 중요한 반대 사례를 놓칩니다.

OpenAI는 2026년 2월의 내부 제품 개발 사례에서 Codex가 한 작업을 여섯 시간 넘게 수행하는 경우를 소개했습니다. 그 배경에는 작업별로 분리된 실행 환경, 에이전트가 직접 볼 수 있는 화면과 로그, 자동 검사와 복구 절차가 있었습니다. 사람이 반복해서 지적하던 규칙을 저장소의 검사로 옮기는 작업도 설명합니다.

다만 OpenAI는 이 결과가 해당 저장소의 구조와 도구에 크게 의존하며, 비슷한 투자 없이 일반화해서는 안 된다고 명시합니다. 회사가 소개한 내부 성공 사례이지, 임의의 개발팀이 같은 성과를 낸다는 증거는 아닙니다.

두 설명은 모순되지 않습니다. 사람이 판단해야 할 일이 충분히 정리되고, 에이전트가 자신의 결과를 검사하고 실패에서 복구할 수 있다면 더 긴 실행이 유용할 수 있습니다. 목표가 모호하고 오류를 확인하기 어려운 상태에서 실행 시간부터 늘리는 것은 다른 문제입니다.

자율 실행 시간은 능력의 한 측면이며, 사업적 성과는 그 능력을 어떤 일에 적용했는지까지 포함합니다. 같은 결과를 같은 신뢰도로 만들었다면 짧고 저렴한 실행이 낫습니다. 반대로 더 많은 계산을 써서 비싼 사람의 검토를 크게 줄였거나, 전에는 불가능했던 가치 있는 작업을 해냈다면 높은 토큰 사용량이 합리적일 수 있습니다. 토큰 절감과 토큰 확대 중 어느 쪽도 그 자체로 목표가 될 수는 없습니다.

생산성 연구는 낙관과 비관 어느 쪽에도 단일 숫자를 주지 않습니다

METR의 2025년 실험에서는 익숙한 오픈소스 저장소에서 일하는 숙련 개발자 16명이 246개 작업을 수행했습니다. 당시 AI 도구를 허용한 작업의 완료 시간이 평균적으로 19% 더 길었습니다. 실제 작업을 무작위로 나눠 비교했다는 점은 중요하지만, 2025년 초의 도구와 특정 개발 환경을 대상으로 한 결과입니다. 이를 2026년의 모든 코딩 에이전트에 적용하는 것은 잘못입니다.

METR는 2026년 2월 후속 설명에서 최신 효과를 정확히 측정하기 어려워졌다고 밝혔습니다. AI 없이 일하는 조건을 원하지 않는 개발자와 AI에 특히 잘 맞는 작업이 실험에서 빠지는 선택 편향이 생겼고, 여러 에이전트를 동시에 쓰면 작업별 사람 시간을 측정하는 일도 어려워졌습니다. 연구진은 이전보다 생산성 향상이 커졌을 가능성을 보면서도, 그 크기에 대한 증거는 약하다고 설명했습니다. 이를 곧바로 특정 비율의 생산성 개선이 입증되었다고 바꿔 읽어서는 안 됩니다.

다른 방향의 근거도 있습니다. 2026년 5월 공개된 메타분석 사전공개 논문은 2025년까지 발표된 관련 연구 23편을 종합해 평균적으로 긍정적인 프로그래밍 생산성 효과를 보고했습니다. 동시에 실험 환경과 실제 조직·오픈소스 환경 사이의 효과 차이를 확인했습니다. 이 역시 최신 에이전트만을 대상으로 한 직접 비교는 아닙니다.

따라서 투자 검토에서 “AI를 쓰면 몇 배 빨라지는가”에 보편적인 계수를 넣기는 어렵습니다. 같은 난도의 작업, 같은 품질 기준, 같은 완료 정의 아래 해당 팀의 변화를 확인해야 합니다. 새로 시작한 개발과 기존 시스템 수정, 화면 작성과 정책 판단을 섞은 평균은 실제 병목을 가릴 수 있습니다.

측정할 때는 실패한 시도와 사람의 재작업도 포함해야 합니다. 산출물이 많아졌는지 외에, 요청부터 검증·배포까지 걸린 시간, 사람이 실제로 투입한 시간, 배포 뒤 문제와 재작업을 함께 봐야 합니다. 이전에는 시도하지 못했던 제품 실험이 가능해진 가치도 별도로 인정해야 합니다. 작업 속도와 탐색 범위는 서로 다른 성과이기 때문입니다.

개인의 요령이 팀의 자산이 되는 순간

한 개발자가 에이전트를 잘 다룬다고 해서 회사 전체가 그 능력을 갖게 되는 것은 아닙니다. 그 사람이 매번 필요한 자료를 찾아 붙이고 잘못된 결과를 직접 고친다면, 생산성은 여전히 개인에게 붙어 있습니다.

팀의 자산이 되는 순간은 그 판단이 다른 사람과 다음 에이전트의 작업에도 적용될 때입니다. 환불의 중복 실행을 발견한 뒤 채팅에서 한 번 고치게 하는 데 그치지 않고, 관련 요구사항과 재현 검사, 실행 권한을 갱신하는 경우입니다. 다음에 모델이 바뀌거나 담당자가 교체되어도 같은 조건을 확인할 수 있어야 합니다.

물론 이 자산을 만드는 데도 비용이 듭니다. 설명을 위한 가정으로, 공통 기준과 검사 환경에 처음 20시간을 쓰고 같은 유형의 작업당 사람의 시간이 1.5시간에서 1.0시간으로 줄었다고 하겠습니다. 사람 시간만 놓고 본 회수 지점은 다음과 같습니다.

초기 투입 20시간 ÷ 건당 절약 (1.5시간 − 1.0시간) = 40건

40건을 처리하면 종전 방식은 60시간, 새로운 방식은 초기 20시간과 작업 40시간을 합쳐 60시간이 됩니다. 실제 측정값이 아닌 계산 예시입니다. 추가 토큰 비용과 유지보수까지 넣으면 경제적 회수 시점은 더 늦어질 수 있습니다. 반대로 결함 감소로 절약하는 비용은 별도로 더해질 수 있습니다.

일회성 시제품에는 이런 초기 투자가 과할 수 있습니다. 반복되는 업무와 오래 유지할 서비스에서는 가치가 커집니다. 중요한 것은 문서를 얼마나 많이 만들었느냐가 아니라, 다음 유사 작업에서 같은 품질을 얻는 데 필요한 사람의 판단과 시간이 실제로 줄었느냐입니다.

이때 숙련자가 필요 없어지는 것은 아닙니다. 반복되는 판단을 검사로 옮겼다면 사람은 새 예외와 잘못된 기준을 발견하는 데 집중해야 합니다. 기존 글 AI 에이전트를 감독하는 사람의 실력은 공짜가 아닙니다에서 다룬 숙련 유지 문제도 남습니다. 규칙을 이해하지 못한 채 승인만 반복하는 조직은 규칙이 틀어졌을 때 이를 고치기 어렵습니다.

개발 도구 기업의 기회는 고객의 반복 비용을 없애는 데 있습니다

벤처투자 관점에서는 이런 변화가 새로운 제품 수요를 만들 수 있습니다. 요구사항과 실제 변경을 연결하고, 중요한 예외만 사람에게 올리고, 여러 도구에서 일한 결과를 검증 가능한 기록으로 모으는 기능입니다. 다만 고객에게 필요한 기능이라는 사실과 독립 기업이 오래 돈을 벌 수 있다는 사실은 구분해야 합니다.

범용 계획 작성, 코드 검토, 에이전트 선택 화면은 기존 개발 도구가 흡수할 수 있는 영역입니다. 실제로 GitHub는 2026년 2월 Agent HQ에 Claude와 Codex를 연결하는 공개 프리뷰를 발표하며, 기존 작업 환경 안에서 여러 공급자의 에이전트를 사용하고 작업 맥락과 검토 기록을 유지하는 방향을 제시했습니다. 여러 에이전트를 한 화면에서 실행한다는 것만으로는 지속적인 차별성을 설명하기 어렵습니다.

독립 제품이 더 강한 경쟁우위를 가지려면 고객의 중요한 업무 기준을 실제 실행과 연결해야 합니다. 기존 데이터와 권한 체계를 연동하고, 고객이 받아들인 결과와 반려한 이유를 검사 가능한 사례로 축적하고, 새로운 모델로 바뀌어도 같은 품질 기준을 유지할 수 있어야 합니다. 특히 모델이 흔히 놓치는 현업의 예외를 재현하고 줄일 수 있다면, 범용 도구 위에 남는 가치가 있을 수 있습니다.

그러나 “고객의 예외 사례가 쌓인다”는 설명에도 확인할 것이 있습니다. 그 자료를 누가 소유하고 다른 고객에게 활용할 권리가 있는지, 특정 고객에만 맞춘 작업인지, 다른 고객에게 적용할 때 구축 시간이 실제로 줄어드는지입니다. 고객마다 숙련 인력이 처음부터 규칙을 만들고 수작업으로 수정해야 한다면, 반복 판매되는 소프트웨어처럼 보이는 매출 안에 인력 중심 구축 비용이 숨어 있을 수 있습니다.

좋은 확인 방법은 모델 교체와 고객 확대를 함께 보는 것입니다. 기반 모델이 좋아져도 이 제품을 통해 얻는 추가 가치가 남는지, 다른 공급자의 모델을 붙여도 고객 기준과 실행 기록이 유지되는지, 비슷한 고객을 추가할수록 초기 설정과 반복 지원 비용이 감소하는지입니다. 반대로 모델의 기본 기능만으로 차이가 사라지거나 사람이 고치는 시간이 사용량에 비례해 늘어난다면, 경쟁우위에 관한 설명을 낮춰 잡아야 합니다.

모든 판단을 영구히 고정하는 조직이 유리하다는 뜻도 아닙니다. 사업 요구는 바뀌고, 모델이 잘하는 일도 바뀝니다. 오래된 규칙을 안전하게 버리면서 필요한 기준은 유지하는 능력까지 포함해야 재사용이 경쟁력이 됩니다.

새로운 코딩 에이전트 팀을 만난다면 멋진 시연 뒤에 실제 작업 하나를 따라가 볼 만합니다. 처음 요구는 무엇이었고, 어떤 가정이 바뀌었으며, 무엇으로 결과를 받아들였고, 그 실패와 수정이 다음 작업에 어떻게 남았는지입니다. 다음 작업에서 같은 설명과 같은 실수가 줄었다면, 그 팀은 코드를 넘어 생산 방식을 개선하고 있는 것입니다.

---

출처와 해석 범위

Andrew Ng의 공개 게시글을 출발점으로 삼았습니다. 본문은 제공된 전체 원문을 기준으로 읽었으며, 동일 주제의 글이 공식 글 목록에서 2026년 9월 4일자로 소개된 사실을 확인했습니다. Facebook 자체의 게시 시각을 별도로 확정한 것은 아닙니다. 역량 분류와 장기 실행에 관한 경고는 Ng의 주장이고, 환불 기능 예시·자율성 도식·시간 회수 계산·기업 경쟁력에 관한 판단은 필자의 해석입니다.

기술 사례는 Anthropic의 장기 실행 환경 및 맥락 관리, OpenAI의 하네스 설계, GitHub의 Agent HQ 발표를 참조했습니다. 모두 해당 제품 공급자의 공개 자료이며, 일반적인 생산성 효과를 독립적으로 입증한 자료로 취급하지 않았습니다.

실증 근거는 METR의 2025년 무작위 대조실험과 2026년 2월 후속 실험 설명, 생성형 AI의 프로그래밍 생산성·학습 효과에 관한 메타분석을 구분해 사용했습니다. 과거 도구의 결과를 현재 모든 에이전트의 성과로 일반화하지 않았습니다.