에이전트 엔지니어링 운영 수준: 에이전트의 집중 지점 정하기 (Agentic Engineering Operating Level)

메타데이터

• 채널: IndyDevDan
• 원문 제목: Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS?
• 발행일/다이제스트 날짜: 2026-09-01
• 영상 길이: 2,192초(약 36분 32초)
• URL: https://www.youtube.com/watch?v=rPWCYB62wvI
• Video ID: rPWCYB62wvI

---

📌 핵심 질문 / 핵심 논점

에이전트와 함께 가치 있는 소프트웨어 산출물을 만들 때 나와 에이전트의 시간·집중·주의를 어느 운영 수준(operating level)에 배치해야 하는가? 위로 이동하면 시스템 레버리지(leverage)와 속도를 얻고, 아래로 이동하면 직접 통제(control)와 이해(understanding)를 얻으므로, 높은 수준이 무조건 우월한 것이 아니라 문제에 맞춰 양방향으로 이동할 수 있어야 한다.

• 가장 아래에는 코드 한 줄과 블록, 함수, 타입, 클래스가 있고 가장 위에는 에이전트 시스템과 소프트웨어 팩토리(software factory)가 있다.
• 낮은 수준을 충분히 이해하지 않은 채 높은 수준의 자동화만 쌓으면 에이전트가 무엇을 하는지 검증하거나 고칠 수 없어 성공의 상한이 낮아진다.
• 익숙하고 반복적이며 결과물이 많은 작업은 위로 올려 자동화하고, 낯설거나 위험하거나 세부사항·성능이 중요한 작업은 아래로 내려 통제해야 한다.
• 전문성은 모델이 모르는 영역(out of distribution)을 메우는 능력이며, 실제로 만들어 보고 원자적 수준부터 쌓은 경험을 대체할 방법은 없다.

에이전트 운영 수준은 특정 도구나 프롬프트 기법의 이름이 아니라, 엔지니어와 에이전트가 시스템의 어느 추상화 계층에 주의를 투입하는지 나타내는 지도다. 목표는 계속 위로 올라가는 것이 아니라 현재 문제를 판별할 수 있을 만큼 아래를 이해한 뒤, 필요한 순간에는 속도와 레버리지를 위해 위로 올라가고 필요한 순간에는 통제와 증거를 위해 아래로 내려가는 것이다.

1. 에이전트 운영 수준의 지도

에이전트 운영 수준은 주의가 적용되는 위치와 그에 따른 레버리지·통제의 교환 관계를 한눈에 보여준다.

1.1. 질문과 정의

1. 주의가 어디에 적용되는가

   1. 주체: 운영 수준은 사람과 에이전트를 함께 가리킨다. 사람이 에이전트를 조종하고, 에이전트는 시스템의 특정 수준을 바라보며 작업한다.
   2. 핵심 질문: 지금 시간과 집중과 주의를 어디에 쓰고 있는지, 어떤 산출물을 검사할 수 있는지 먼저 물어야 한다.

2. 운영 수준의 양끝

   1. 최상단: 소프트웨어 팩토리(software factory)는 시스템 레버리지가 최대인 지점이다.
   2. 최하단: 코드의 세부를 직접 다루는 지점은 시스템을 가장 강하게 통제할 수 있는 곳이다.
   3. 방향의 오해: 높은 수준으로 가는 것 자체가 목표가 아니며, 사용 사례와 해결할 문제에 따라 내려가는 편이 더 가치 있을 수 있다.

1.2. 지도를 읽는 법과 범위

1. 일상적인 집중 위치 확인

   1. 많은 엔지니어는 계획(planning), 에이전트(agent), 애플리케이션(application) 수준에 가장 오래 머물고 필요할 때 파일(file) 수준으로 내려간다.
   2. 현재 어떤 아티팩트(artifact)를 주로 만들고 검사하는지 기록하면 자신의 운영 범위를 파악할 수 있다.

2. 다섯 가지 큰 구간

   1. 기초(foundation): 라인·블록·함수·타입·클래스와 같은 코드 원자 단위다.
   2. 구조·데이터·실행(structure, data, execution): 파일·모듈·디렉터리, 데이터베이스·테이블, 스크립트·CLI다.
   3. 전달·의도(delivery and intent): 애플리케이션, 저장소(repository), 계획, 문서화다.
   4. 에이전트 시스템(agentic system): 에이전트와 AI 개발 워크플로(AI developer workflow, ADW)다.
   5. 소프트웨어 팩토리: 여러 워크플로를 조합해 시스템이 지속적으로 일을 수행하는 지점이다.

3. 논의의 순서

   1. 각 수준의 장단점을 살펴보고 레버리지와 통제 중 무엇을 선택할지 판단한다.
   2. 일반적인 엔지니어의 운영 위치와 도메인 전문성(domain expertise)의 역할을 확인한다.
   3. 전문성을 쌓는 방법과 자신의 운영 수준을 옮길 조건을 연결한다.

2. 아래에서 위로 올라가는 운영 수준

각 단계는 아래에 있는 세부 정보를 일부 포기하는 대신 더 넓은 범위의 작업을 빠르게 움직일 수 있게 한다.

2.1. 코드 기초: 라인에서 클래스까지

1. 직접 통제의 층위

   1. 라인(line): 소프트웨어의 가장 작은 실질 단위이며 특정 연산이 무엇을 하는지 직접 볼 수 있다.
   2. 블록(block): 조건문·반복문 등 코드 흐름의 묶음으로, 여러 라인의 동작을 함께 파악할 수 있다.
   3. 함수(function): 함수 정의, 인자(arguments), 반환 타입(return type)을 통해 하나의 동작 계약을 확인할 수 있다.
   4. 타입(type): 데이터가 어떤 형태로 흐르는지와 코드의 의미를 드러낸다.
   5. 클래스(class): 관련 상태와 동작을 묶어 더 큰 코드 구조를 이해하게 한다.

2. 사람과 에이전트의 역할

   1. 사람이 직접 모든 라인을 손으로 작성해야 한다는 뜻이 아니다. 이 수준에서도 사람과 에이전트가 함께 코드를 보고 수정한다.
   2. 이 구간에 시간·집중·주의를 배치하면 시스템에 대한 정보량과 통제력이 가장 커진다.

3. 비용

   1. 세부사항을 많이 얻는 만큼 범위가 좁고 느리다.
   2. 에이전트가 처리할 수 있는 하위 수준의 일을 계속 사람이 붙잡으면 속도와 레버리지를 잃는다.

2.2. 코드 구조와 데이터 계약

1. 파일·모듈·디렉터리 구조

   1. 구조 지정: 새 기능의 파일 배치, 파일 이름, 모듈과 디렉터리 구성을 에이전트에게 명시한다.
   2. 통제와 레버리지의 변화: 파일 수준으로 올라가면 여러 라인을 한 번에 다루는 레버리지는 늘지만, 에이전트가 처리하는 하위 세부의 과립도(granularity)와 직접 통제는 줄어든다.

2. 데이터베이스와 테이블

   1. 데이터베이스 범위: 운영(production)·스테이징(staging)·개발(dev) 데이터베이스와 제품이 사용하는 여러 데이터베이스를 함께 본다.
   2. 테이블의 계약: 데이터베이스 테이블은 모든 모듈과 코드, 개별 라인이 공유하는 계약(contract)이다.
   3. 추상화의 의미: 테이블을 바라보는 순간 많은 구현 세부를 추상화하지만, 제품의 핵심 자산인 데이터의 모양과 흐름은 더 넓게 이해하게 된다.

3. 제품 가치와 개인 정보

   1. 단기 프로토타입이 아니라 중·장기 제품을 만든다면 에이전트가 설계한 테이블 구조를 검토해야 한다.
   2. 사용자의 개인 식별 정보(PII)와 자원을 다루면서 데이터베이스 수준에 주의를 기울이지 않는 것은 장기적으로 수익을 낼 제품을 신뢰할 수 없는 상태로 배포하는 일이다.
   3. 많은 제품에서 실제로 축적되는 가장 값진 자산은 사용자와의 관계이며, 그 관계는 데이터의 형태로 제품 안에 남는다.

2.3. 실행·전달·의도

1. 스크립트와 CLI

   1. 엔지니어링 제어판: CLI(command-line interface)는 시스템을 엔지니어링 수준에서 빠르게 조작하고 특정 코드를 실행하는 방식이다.
   2. 재사용 경로: 스크립트(script)와 CLI 명령은 사람과 에이전트가 반복해서 사용할 수 있는 경로(pathway)를 만든다.
   3. 교환 관계: 커스텀한 작업을 대량으로 지정할 수 있고 구조의 수명주기를 관리하는 레버리지가 생기지만, 라인·파일·디렉터리를 직접 보지는 않게 된다.

2. 애플리케이션과 바이브 코딩

   1. 애플리케이션(application) 수준은 결과 화면이나 기능을 보고 에이전트에게 다시 프롬프트하는 방식과 가깝다.
   2. 비엔지니어를 포함한 많은 바이브 코더(vibe coder)는 이 수준만 바라본다. 원하는 결과가 아니면 다시 프롬프트하고, 내부 구조나 위·아래 수준을 검사하지 않는다.
   3. 애플리케이션만 볼 수 있고 그 위와 아래를 볼 수 없다면 만들 수 있는 결과의 종류, 영향의 규모, 고장 났을 때 해결할 능력이 모두 제한된다.

3. 저장소와 제품

   1. 저장소(repository) 수준에서는 apps 디렉터리 하나에 여러 애플리케이션을 담는 구조를 다룰 수 있다.
   2. 하나의 제품은 하나의 앱도, 하나의 저장소도 아닐 수 있으며 여러 애플리케이션과 저장소로 구성된다.
   3. 이 수준은 높은 추상화로 제품 전체를 움직이는 힘을 주지만, 개별 코드에 대한 직접 정보는 더 잃는다.

4. 계획과 문서화

   1. 계획(plan): 시스템 아래쪽 전체와 일부 위쪽을 바라보면서 다음에 일어날 일, 과거에 일어난 일, 원하는 변경을 자연어로 정리한다.
   2. 계획의 한계: 자연어 계획만 작성하고 애플리케이션을 열어 실제로 변경하지 않는다면, 그 계획은 실행 가능한 시스템 이해를 대신하지 못한다. 그런 행동은 어리석지만 실제로 벌어진다.
   3. 문서(documentation): 무엇이 일어났는지 구체적으로 기록해 사람·에이전트·팀이 같은 상태를 빠르게 파악하게 한다.
   4. 코드와 문서의 관계: 코드가 최종적인 진실의 원천(source of truth)이라는 점은 변하지 않지만, 코드만 문서라고 보는 것은 낮은 운영 수준이다. 정확성은 얻어도 읽고 공유하는 속도는 떨어진다.
   5. 미디어가 풍부한 문서: 계획과 문서에 이미지, SVG, 오디오 파일, 짧은 비디오를 활용하면 정보의 압축·전달 속도가 올라간다. 에이전트가 코드와 작업을 요약해 이런 형태로 제공하도록 만들 수 있다.

2.4. 에이전트 시스템과 소프트웨어 팩토리

1. 에이전트 수준

   1. 에이전트(agent)는 AI 개발자 워크플로와 결합할 때 단독 모델이나 단독 코드보다 큰 능력을 낸다.
   2. 현재 산업 표준은 에이전트 하나를 사용하는 것이며, 에이전트 하나만 쓰면 평균적인 결과를 얻는 상태가 일반적이다.

2. AI 개발 워크플로(ADW)

   1. ADW(AI developer workflow)는 개발자가 손으로 밟던 소프트웨어 개발 생명주기(SDLC)의 어떤 워크플로든 에이전트로 곱하는 반복 가능한 절차다.
   2. 핵심은 단순한 루프(loop)가 아니다. 상황에 맞는 코드와 에이전트를 적절한 시점에 배치해 빛의 속도로 작업을 통과하는 재사용 가능한 워크플로다.
   3. plan → build → test → deliver 한 개를 실행하는 것만으로는 소프트웨어 팩토리가 아니라 AI 개발 워크플로 하나에 해당한다.

3. 소프트웨어 팩토리

   1. 여러 ADW를 조합하면 소프트웨어 팩토리(software factory)가 된다.
   2. 소프트웨어 팩토리는 SDLC만 자동화하지 않는다. 핫픽스(hot fix), 기능 프로토타이핑, 아이디어 구상, 스테이징 환경 배포와 테스트, 여러 변형(permutation) 시도, 새 지원 티켓 처리까지 포함한다.
   3. 시스템은 사람의 명시적인 지시가 없어도 작업을 시작하고, 사람이 곁에 있을 때와 없을 때 모두 제품을 움직이게 된다.

4. 최상단의 통제 비용

   1. 최종 제품이나 에이전트 자체를 바라보는 것만으로는 내부 동작을 세밀하게 통제할 정보가 거의 없다.
   2. 따라서 위로 갈수록 시스템 레버리지는 커지지만, 아래 수준의 이해·검증·직접 통제는 거의 사라진다.
   3. 이해하지 못하는 시스템을 확장할 수 없으므로, 높은 수준으로 가려면 먼저 낮은 수준으로 내려가 기반을 익혀야 한다.

3. 높은 수준이 무조건 좋은 것은 아니다

운영 수준은 한 방향의 계단이 아니라 문제에 따라 오르내리는 능력의 범위(range)다.

3.1. 역할과 능력 범위

1. 바이브 코더(vibe coder)

   1. 애플리케이션만 결과 아티팩트로 검사하고, 그 아래의 코드와 그 위의 제품 의도를 이해하지 못한다.
   2. 결과가 틀리면 내부 원인을 증명하기보다 에이전트에 다시 프롬프트하는 방식에 머문다.

2. 지식 노동자(knowledge worker)

   1. 문서와 계획, 어쩌면 제품 의도까지 이해해 애플리케이션만 보는 사람보다 넓은 범위를 갖는다.
   2. 다만 코드 원자와 구조를 직접 판별하는 능력은 제한적일 수 있다.

3. 데이터 분석가(data analyst)

   1. 테이블을 이해하고 몇 가지 스크립트를 실행해 소프트웨어 수준을 더 넓게 볼 수 있다.
   2. 데이터 계약과 실행 경로를 함께 볼 수 있어 애플리케이션 결과만 보는 것보다 더 많은 선택지를 갖는다.

4. 소프트웨어 엔지니어(software engineer)

   1. 코드 원시 요소(code primitives), 코드 구조, 데이터베이스, 실행과 전달의 여러 수준을 이해한다.
   2. 아래를 이해한 상태에서 계획·제품·에이전트 시스템까지 이동할 수 있어 가장 넓은 능력 범위를 확보한다.

5. 시니어·프린시펄 엔지니어(mid-senior, principal plus)

   1. 2018~2019년 무렵부터 계획과 문서화를 습관화하고 팀이나 상사보다 제품 자체와 실제 사용자 관점으로 사고하는 것이 큰 도약을 만든다.
   2. 애플리케이션이나 저장소의 내부 구현만 보지 않고 제품 전체와 사용자 가치를 생각하는 능력이 시니어·프린시펄 수준으로 가는 핵심이다.
   3. 계층의 위치는 필요에 따라 재배치하거나 항목을 추가할 수 있다. 제품을 더 아래에 둘지와 같은 세부 배열보다 레버리지와 통제의 개념이 중요하다.

3.2. 기술이 주는 교환

1. 위로 이동할 때

   1. 레버리지와 속도가 증가해 혼자서는 불가능한 규모의 일을 처리한다.
   2. 대신 직접 이해와 통제가 감소한다. 이는 기술이 능력을 주는 동시에 다른 능력을 빼앗는 일반적인 교환이다.

2. 조직의 리더십과 같은 패턴

   1. 리드·매니저·CTO·스태프 엔지니어가 될수록 실제로 무슨 일이 일어나는지 직접 통제하고 이해하는 정도는 줄어든다.
   2. 그 대신 팀과 협업자를 통해 혼자서는 불가능한 임팩트와 속도를 얻는다. 에이전트 스택에서 위로 올라가는 현상도 같은 구조다.

3. 아래로 이동할 때

   1. 통제와 이해가 증가하고 문제의 세부를 증명할 수 있다.
   2. 더 많은 시간과 주의가 들고 속도가 감소한다. 제한된 시간·집중·자원 때문에 모든 계층을 동시에 최대로 볼 수는 없다.

4. 손코딩에 대한 구분

   1. 에이전트와 함께 아래로 내려가는 것과 모든 코드를 손으로 작성하는 것은 다르다.
   2. 일반적인 손코딩만으로 경쟁하려는 엔지니어는 경쟁력이 없다. 예외는 0.1%보다도 훨씬 작은 범위의 극도로 정밀한 작업이다.
   3. 예를 들어 고빈도 알고리즘 트레이딩(high-frequency algorithmic trading) 시스템에서 C나 어셈블리 문장을 직접 조정해 마이크로 최적화를 하는 경우가 있다.
   4. 그런 예외적인 작업조차 에이전트가 능력을 배가할 가능성이 있으므로, 손코딩을 기본 운영 모델로 삼을 이유는 더욱 약하다.

3.3. 현재 엔지니어가 머무는 곳과 권장 위치

1. 일반적인 바닥과 천장

   1. 게으름은 낮은 애플리케이션 수준에 머무르게 하며, 결과가 마음에 들지 않을 때 재프롬프트만 반복하게 만든다.
   2. 반대쪽 천장은 새로운 기술이자 공예(craft)인 에이전트 엔지니어링(agentic engineering)이다.
   3. 에이전트·ADW·소프트웨어 팩토리 안에는 더 많은 하위 기술이 있으며, 프롬프트·컨텍스트·하네스 엔지니어링(prompt, context, harness engineering)은 그중 눈에 잘 띄는 일부다.

2. 계획의 레버리지

   1. 계획은 규모가 커진 프롬프트처럼 작동한다. 강력한 모델과 에이전트에게 넘길 수 있는 큰 의도 명세이므로 중요한 능력이다.
   2. 다만 계획만 잘 쓰고 실제 애플리케이션·데이터·코드 구조를 검증하지 않으면 레버리지가 아니라 통제 상실이 된다.

3. 권장 집중 이동

   1. 이해하는 시스템에서 레버리지를 얻어야 한다.
   2. 직접 통제가 필요하면 아래로 내려가고, 시스템 레버리지가 필요하면 위로 올라간다.
   3. 문서화, 데이터베이스 테이블, 디렉터리 구조, 타입, 함수 수준을 의식적으로 확인하면 빠른 자동화와 장기적 신뢰성을 함께 확보할 수 있다.

4. 레버리지를 선택하는 조건

도메인과 작업의 증거가 자동화를 지지할 때 위로 이동한다.

4.1. 전문성을 가진 상태

1. 도메인을 이해할 때

   1. 소프트웨어 기술만으로는 충분하지 않다. 제품이 베이킹 자동화라면 빵을 굽는 도메인 지식이 있어야 로봇과 소프트웨어의 결과가 맞는지 판단할 수 있다.
   2. 도메인을 알면 에이전트의 출력이 옳은지 그른지 구분할 수 있으므로 높은 수준에서 레버리지를 안전하게 적용한다.

2. 작업이 익숙하고 반복될 때

   1. 같은 작업을 세 번 했다면 자동화를 검토해야 하는 빨간 경고등이 켜진다.
   2. 에이전트와 코드를 투입해 AI 개발 워크플로를 만들고, 매우 단순한 재사용 에이전트에서 시작한 뒤 비용 절감과 규모 확장이 필요할 때 ADW로 옮긴다.

3. 산출물과 단계가 많을 때

   1. 결과 아티팩트가 많고 여러 단계가 연속되는 작업은 자동화의 증거가 강하다.
   2. 한 사람이 모든 순서를 기억하고 실행하는 대신 적절한 에이전트·코드·모델을 조합하면 더 큰 시스템 레버리지를 얻는다.

4.2. 에이전트 엔지니어링 기술이 있을 때

1. 필수 기반

   1. 프롬프트·컨텍스트·하네스 엔지니어링을 이해해야 한다.
   2. 여러 에이전트를 오케스트레이션하고, 상황에 맞는 모델을 적절한 가격과 시점에 고르고, 자신의 하네스를 만들 수 있어야 한다.
   3. 에이전트와 코드를 결합해 어느 한쪽만 사용할 때보다 좋은 결과를 내고, 여러 모델의 의견과 계획을 조합할 수 있어야 한다.

2. 고급 조합

   1. 여러 에이전트를 융합 하네스(fusion harness)로 묶으면 서로의 빈틈을 채우고 상충하는 판단을 비교할 수 있다.
   2. 모델 하나에서 여러 모델로, 에이전트 하나에서 여러 에이전트로, 에이전트만 쓰는 방식에서 에이전트와 코드를 함께 쓰는 방식으로 올라갈 때 능력의 차이는 단순한 덧셈 이상으로 커진다.

5. 통제가 필요한 조건

이해·증거·위험·세부 성능이 부족하면 사람과 에이전트가 함께 아래로 내려가야 한다.

5.1. 지식과 시스템이 부족할 때

1. 도메인 지식이 적을 때

   1. 무엇을 하는지 모르면 에이전트의 결과가 맞는지 증명할 수 없다.
   2. 작은 물리 로봇을 처음 만든다면 불을 켜는 한 줄의 코드처럼 하드웨어의 가장 작은 Hello World부터 확인해야 한다.

2. 시스템이 낯설 때

   1. 새 회사·새 코드베이스·새 프로젝트를 시작할 때는 아래에 무엇이 있는지 모른 채 운영 수준을 위로 올려서는 안 된다.
   2. 디렉터리·파일·타입·함수·테이블을 확인하면서 시스템의 지도를 만든 뒤에야 계획과 자동화를 넓힌다.

3. 전문성을 쌓는 과정일 때

   1. 전문성은 추상적인 자신감이 아니라 특정 입력에 어떤 출력이 나오는지 구분하는 능력이다.
   2. 좋은 결과와 나쁜 결과를 가르는 기준이 없으면 아래로 내려 원인과 동작을 직접 이해해야 한다.

5.2. 위험과 영향이 클 때

1. 고위험·고영향 도메인

   1. 우주로 로켓을 발사하는 시스템에서 바이브 코딩에만 의존해서는 안 된다.
   2. 사람이 거주할 주택 구조를 설계하거나 바이오메디컬(biomedical) 시스템을 만드는 일도 심각한 통제 근거가 된다.
   3. 실패 비용이 크면 클래스·타입·테이블·필요한 경우 코드 라인까지 내려가 검증한다.

2. 검증 증거가 약할 때

   1. 에이전트의 트레이스(trace)가 성공이나 실패를 제대로 증명하지 못하고 검증 내용이 말이 되지 않으면 더 낮은 수준으로 이동한다.
   2. 성공·실패를 판별하는 피트니스 함수(fitness function)나 측정 가능한 신호를 먼저 마련해야 한다.

5.3. 품질·취향·성능이 중요할 때

1. 사용자 인터페이스의 동일화

   1. 모든 UI가 비슷해지는 이유는 사람들이 중요하지 않다고 여기며 UI를 바이브 슬로핑(vibe slopping)하기 때문이다.
   2. 제품에 강한 의견과 취향(taste)이 없다면 결과에는 어디에나 대시가 들어가는 듯한 자동 생성의 흔적이 남는다.
   3. 엔지니어뿐 아니라 일반 사용자도 이런 흔적을 알아차린다. 똑똑한 사람만 품질 차이를 식별하는 것이 아니다.

2. 성능이 핵심일 때

   1. 고빈도 거래 알고리즘에서 5밀리초 지연을 일으키는 코드 라인을 모르면 경쟁자가 앞서가므로 직접 통제해야 한다.
   2. 성능과 세부사항이 중요한 순간에는 사람, 에이전트 하네스, 에이전트 팀, 멀티에이전트 오케스트레이션, 융합 하네스가 함께 아래로 내려간다.

6. 모델의 분포와 전문성

에이전트의 지식 분포를 파악하면 어디까지 맡기고 어디서부터 가르칠지 결정할 수 있다.

6.1. 인분포와 분포 밖

1. 인분포(in distribution)

   1. 일반적인 대규모 언어 모델(LLM), 실무형 워크호스(workhorse) 모델, 경량(lightweight) 모델, 최신(state-of-the-art) 모델이 공통으로 잘 아는 영역이다.
   2. 대부분의 모델은 API를 만들고, PostgreSQL 데이터베이스를 설계하고, 평범한 UI를 만들 수 있으며 일부 모델은 꽤 좋은 UI도 만든다.

2. 분포 밖(out of distribution)

   1. 모델이 전혀 모르거나 훈련 데이터에 없거나, 특정 행동을 하지 말라고 학습되어 적극적으로 회피하는 영역이다.
   2. 단순히 지식이 없는 문제만이 아니다. 모델이 원치 않는 행동을 반복해 사용자가 적극적으로 싸워야 하는 경우도 분포 밖에 해당한다.
   3. 이런 영역에서 모델에게 일반적인 협업자처럼 일을 맡기면 안 된다. 다른 주변 분야에는 도움이 되더라도 목표 분야의 규칙을 먼저 가르쳐야 한다.

6.2. 분포를 넓히는 방법

1. 사람의 개입

   1. 모델에 정보가 없거나 틀린 행동을 하면 엔지니어링 전문성과 도메인 전문성을 적용해 모델이 다룰 수 있는 분포를 넓힌다.
   2. 새로운 기술을 알려주는 일은 곧 에이전트를 훈련해 새로운 작업 범위를 갖게 하는 일이다.

2. 기술적 방법

   1. 컨텍스트 엔지니어링(context engineering)과 인컨텍스트 러닝(in-context learning)으로 필요한 지식과 예시를 제공한다.
   2. 고급 상황에서는 파인튜닝(fine-tuning)을 사용한다.
   3. 융합 하네스로 여러 모델에 여러 의견과 계획을 요청하고 에이전트가 협력하게 해 각 모델의 공백을 메운다.

7. 전문성을 만드는 방법과 다음 단계

높은 레버리지는 실제로 아래를 경험한 사람만 안전하게 사용할 수 있다.

7.1. 원자에서 시스템까지 만들기

1. 직접 구축의 불가피성

   1. 잘하고 싶은 영역을 실제로 만들어 경험해야 한다. 지름길이나 추상적인 동기만으로 전문성을 얻을 수 없다.
   2. 소프트웨어의 원자는 라인과 블록이고, 그 위로 함수·타입·클래스·파일·모듈이 쌓인다.
   3. 데이터베이스·스크립트·애플리케이션·저장소·제품까지 차례로 거치며 시스템이 어떻게 결과를 만드는지 배워야 한다.

2. 시간이라는 대체 불가능한 요소

   1. 중급·시니어·프린시펄·신입을 막론하고 좋은 엔지니어가 된 방식에는 컴퓨터 앞에서 반복해서 부딪힌 시간이 포함된다.
   2. 한두 번의 프롬프트나 도구 선택은 원시 전문성(raw expertise)을 대체하지 못한다.
   3. 위험도, 전문성, 모델의 지식량에 따라 필요한 깊이는 달라지지만, 기본 원칙은 무엇을 확장하기 전에 그것을 이해하는 것이다.

7.2. 레버리지의 급격한 확장

1. 조합의 효과

   1. 에이전트 하나에서 여러 에이전트로 가는 간극이 크다.
   2. 모델 하나에서 프롬프트 안의 여러 모델로 가는 간극도 크다.
   3. 에이전트만 바라보는 방식에서 에이전트와 코드를 함께 쓰는 방식으로 가면 제품·엔지니어링 작업의 능력이 기하급수적으로 확장된다.

2. 소프트웨어 팩토리 이후

   1. 소프트웨어 팩토리는 이미 한 단계 다른 행성이지만, 그 위에 다크 팩토리(dark factory)와 RSI(recursive self-improvement) 같은 단계가 있다.
   2. RSI는 아직 사실상 최첨단의 실험 상태로, OpenAI와 Anthropic 같은 대형 AI 연구소의 선도 그룹이 시도하는 정도다.
   3. 다크 팩토리와 RSI, 소프트웨어 팩토리 어느 것도 바로 뛰어넘어 갈 수 없다. 낮은 수준에서 이해하고 점진적으로 조합·확장해야 한다.

7.3. 시스템이 시스템을 만들게 하기

1. 핵심 사고 전환

   1. 애플리케이션 자체를 계속 만드는 데서 멈추고, 애플리케이션을 대신 만드는 에이전트 계층에 시간을 투입한다.
   2. 계획을 매번 새로 작성하는 단계에서 템플릿(template)을 만드는 단계로 옮겨 반복되는 의도를 재사용한다.
   3. 에이전트의 기반인 컨텍스트·모델·프롬프트·도구(context, model, prompt, tools)를 표준화하고 조합한다.

2. 자기 확장형 제품 비전

   1. 목표는 사람이 깨어 있을 때만 작동하는 코드가 아니라 잠든 동안에도 실행되는 살아 있는 소프트웨어(living software)를 만드는 것이다.
   2. 에이전트·ADW·소프트웨어 팩토리를 쌓은 뒤 더 높은 자동 개선 단계로 이동하되, 각 단계의 동작과 한계를 검증할 수 있는 전문성을 유지해야 한다.

3. 학습 자료와 대상

   1. Tactical Agent Coding은 바이브 코딩을 넘어 에이전트 엔지니어링으로 확장하고, 코드베이스가 스스로 실행되도록 만드는 방향을 제시한다.
   2. 이 접근은 프로덕션에 배포하는 상위 20% 엔지니어를 대상으로 하며, 병목이 더 이상 모델·도구·에이전트가 아니라 자기 자신인 엔지니어에게 맞는다.
   3. 모델·도구·프레임워크의 유행보다 에이전트 코딩의 단단한 아이디어와 전술에 초점을 두므로 시간이 지나도 원리가 남는다.
   4. 다음 단계인 Phase 3가 개발 중이며, 기존 Tactical Agent Coding 멤버에게는 후속 제품 할인 혜택이 예고되었다.

주요 발언 모음

“최고의 엔지니어는 당신이나 나보다 더 오래, 더 열심히 일해서 최고가 되는 것이 아니다. 영향력을 확장할 때 레버리지가 큰 활동에 집중하고, 세부사항이 가장 중요할 때 속도를 늦추기 때문에 최고가 된다.”

“에이전트 운영 수준은 당신과 에이전트가 가치 있는 소프트웨어 산출물을 만들기 위해 시간과 주의를 집중하는 위치다.”

“더 높은 것이 더 좋은 것은 아니다. 이해하지 못하는 상태에서 레버리지만 얻는 것은 작동하지 않는다.”

“이해하는 시스템에서 레버리지를 얻어라.”

“세 번 했다면 패턴이다. 자동화해야 한다는 빨간 경고등이다.”

“무엇을 하는지 이해하지 못하면 그것을 확장할 수 없다.”

“레버리지와 이해 없는 통제는 무의미하다. 레버리지와 속도가 필요할 때는 올라가고, 통제와 이해가 필요할 때는 내려가라.”

핵심 데이터 & 수치

• 15년 이상: 에이전트 운영 수준 프레임워크가 15년 이상의 엔지니어링 경력에서 발전했다.
• 2,192초: 영상 길이로 약 36분 32초다.
• 2018~2019년: 계획·문서화와 제품·사용자 관점으로 사고하기 시작하며 커리어가 크게 도약한 시기로 제시된다.
• 세 번: 동일 작업을 세 번 반복하면 자동화를 검토할 패턴으로 본다.
• 0.1% 미만: 손으로 코드를 써도 경쟁이 가능한 극도로 정밀한 예외 작업의 범위조차 0.1%보다 훨씬 작다고 본다.
• 5밀리초: 고빈도 거래 시스템에서 경쟁력을 좌우할 수 있는 성능 지연의 예시다.
• 상위 20%: Tactical Agent Coding의 대상은 프로덕션에 배포하며 다음 단계로 도약할 준비가 된 상위 20% 엔지니어다.
• 운영 계층: 라인·블록·함수·타입·클래스·파일·모듈·디렉터리·데이터베이스·테이블·스크립트·CLI·애플리케이션·저장소·계획·문서·에이전트·ADW·소프트웨어 팩토리가 대표적인 이동 경로다.
• 세 가지 조합 도약: 에이전트 하나→여러 에이전트, 모델 하나→여러 모델, 에이전트만→에이전트+코드의 전환은 각각 큰 능력 격차를 만든다.
• 최첨단 상태: RSI는 아직 사실상 존재하지 않는 수준이며, OpenAI와 Anthropic 같은 대형 연구소의 선도 그룹이 시도하는 단계다.

결론 및 시사점

1. 현재 위치를 측정한다: 사람과 에이전트가 실제로 가장 오래 머무는 수준과 생성하는 아티팩트를 적어 운영 범위를 확인한다.
2. 위로 갈 자격을 만든다: 코드·데이터·제품·도메인에서 좋은 결과와 나쁜 결과를 구분할 수 있을 만큼 낮은 수준을 먼저 경험한다.
3. 반복을 자동화한다: 세 번 반복한 작업, 단계와 산출물이 많은 작업, 익숙하고 검증 가능한 작업부터 재사용 에이전트와 ADW로 옮긴다.
4. 위험하면 내려간다: 새 코드베이스, 낯선 도메인, 약한 디버깅 증거, 고위험·고영향 시스템에서는 타입·테이블·함수·라인까지 내려가 원인을 확인한다.
5. 품질의 세부를 포기하지 않는다: UI의 취향과 성능은 자동 생성 결과에 맡기기 쉬워도 제품 신뢰를 결정하므로 직접 관찰하고 조정한다.
6. 모델의 분포를 보정한다: 인분포 작업은 위로 올리되, 분포 밖 작업은 컨텍스트·예시·파인튜닝·다중 모델 협업으로 가르치고 사람의 전문성으로 검증한다.
7. 운영 수준을 양방향으로 이동한다: 위로 고정된 엔지니어도 아니고 아래에 갇힌 엔지니어도 아닌, 문제에 따라 속도와 레버리지 또는 통제와 이해를 선택하는 엔지니어가 되어야 한다.
8. 최종 기준을 결과에 둔다: 남에게 어떻게 보이는지나 순위를 높이는 데 집착하지 말고, 실제로 완성하고 배우고 진화하는 데 집중한다.
9. 장기 목표를 확장한다: 에이전트에서 ADW, 소프트웨어 팩토리, 다크 팩토리와 RSI로 나아가되 각 단계의 기반을 이해한 뒤 조합한다.
10. 핵심 공식: 레버리지와 속도가 필요하면 위로 이동하고, 통제와 이해가 필요하면 아래로 이동하며, 두 방향 모두로 움직일 수 있는 범위를 유지한다.

핵심 요약 (20줄)

1. 에이전트 운영 수준은 사람과 에이전트가 가치 있는 소프트웨어를 만들기 위해 주의와 시간을 배치하는 추상화 계층이다.

2. 코드 라인·블록·함수·타입·클래스는 가장 큰 직접 통제와 가장 작은 작업 범위를 제공한다.

3. 파일·모듈·디렉터리·데이터베이스·테이블·스크립트·CLI로 올라가면 더 넓은 구조와 데이터 계약을 다룬다.

4. 애플리케이션만 보는 바이브 코딩은 내부 원인과 상위 제품 의도를 검증하지 못해 결과의 종류와 영향이 제한된다.

5. 계획과 문서화는 시스템의 과거와 다음 의도를 압축하고 이미지·오디오·비디오로 전달 속도를 높인다.

6. 에이전트 하나를 넘어 ADW를 만들면 개발 생명주기의 반복 작업을 코드와 모델로 재사용할 수 있다.

7. 여러 ADW를 조합한 소프트웨어 팩토리는 핫픽스·프로토타입·스테이징·지원 티켓까지 사람이 없을 때도 처리한다.

8. 높은 운영 수준은 레버리지와 속도를 주지만 낮은 계층의 이해와 직접 통제를 잃게 만든다.

9. 낮은 계층을 이해하지 않은 채 소프트웨어 팩토리를 만들면 확장할수록 검증 불능과 실패가 커진다.

10. 도메인을 이해하고 작업이 익숙하며 세 번 이상 반복되고 산출물과 단계가 많다면 운영 수준을 위로 옮긴다.

11. 새 도메인과 코드베이스를 만나거나 검증 증거가 약하면 아래로 내려가 입력·출력과 시스템 구조를 확인한다.

12. 로켓·주택 구조·바이오메디컬처럼 위험과 영향이 큰 영역은 타입·테이블·함수·라인까지 직접 통제해야 한다.

13. UI의 취향과 제품의 세부 품질, 고빈도 거래의 5밀리초 성능 차이도 아래 계층으로 내려갈 이유가 된다.

14. 인분포 작업은 대부분의 LLM이 API·PostgreSQL·일반 UI를 만들 수 있지만 분포 밖 작업은 사람의 지도가 필요하다.

15. 컨텍스트 엔지니어링·인컨텍스트 러닝·파인튜닝·융합 하네스로 모델의 지식 분포를 넓힐 수 있다.

16. 전문성은 라인과 블록에서 시작해 함수·타입·클래스·파일·모듈과 제품을 실제로 구축한 시간에서 생긴다.

17. 에이전트 여러 개, 모델 여러 개, 에이전트와 코드를 함께 쓰는 조합은 단일 도구보다 기하급수적으로 큰 능력을 만든다.

18. 다크 팩토리와 RSI는 소프트웨어 팩토리 이후의 방향이지만 아직 선도 AI 연구소가 시도하는 최첨단 영역이다.

19. 애플리케이션을 직접 만드는 데서 에이전트 계층과 템플릿을 만드는 일로 이동하면 시스템이 시스템을 만들게 된다.

20. 레버리지와 속도가 필요하면 위로, 통제와 이해가 필요하면 아래로 움직이며 두 방향을 모두 유지하는 것이 에이전트 엔지니어링의 운영 원칙이다.