핵심 주제 1: "Loop Engineering"은 틀린 프레임이다
왜 Loop Engineering이 잘못된 용어인가?
Loop Engineering은 기존 소프트웨어 개발 라이프사이클(SDLC)의 형편없는 리브랜딩이다. 불명확하고 과대포장되어 있으며, 전체 그림을 담지 못한다.
구체적 비판
- 루프(loop)는 전체 워크플로우의 단 한 가지 측면에 불과하다
- "loop engineering"이 맞다면 "condition engineering", "function engineering"도 만들어야 한다 — 제어 흐름마다 새 용어를 붙여야 하는 무한 증식이 발생한다
- 실제로 중요한 것은 정보가 시스템 내에서 어떻게 흐르는가이다
올바른 프레임: AI Developer Workflows (ADW)
"소프트웨어 팩토리" 비유가 핵심이다:
- 입력(props)이 소프트웨어 팩토리로 들어온다
- 특정 워크플로우가 실행된다
- 결과물이 출력된다
핵심 주제 2: 가치 창출의 세 주체 (Three Actors of Value Creation)
세 주체: Engineers + Agents + Code
Agentic Engineering의 게임은 "언제, 어디서 각 주체를 배치하느냐"다.
Code의 숨겨진 가치 (가장 과소평가된 주체)
코드가 가장 신뢰할 수 있는 이유
- 속도: 빛의 속도로 실행됨
- 비용: 토큰 비용 제로
- 일관성: 지시하지 않는 한 항상 동일하게 실행됨
- 환각(hallucination) 없음: 항상 결정론적(deterministic)
신뢰성 순위
- Code (가장 신뢰)
- Engineers
- Agents (가장 변동성 큼)
"Speed costs zero tokens. There's no hallucination. It does the exact same thing every time. And it literally runs at the speed of light." — Dan
핵심 주제 3: AI Developer Workflow의 진화 단계
단계 1: 기본 (Basic Foundation)
엔지니어가 LLM에 프롬프트 → 엔지니어가 결과 리뷰
- 모든 루프, 모든 워크플로우, 모든 작업의 기반
단계 2: 코드 추가 = 첫 번째 루프 생성
구체적 사례
- Linter 추가: 실패 시 결과가 Build Agent로 돌아감
- 이 조건(condition)과 라우팅(routing)이 첫 번째 루프를 만든다
- 여기서 "Loop Engineering"이라는 용어가 나왔지만, 이것은 전체의 작은 일부
단계 3: 더 많은 결정론적 코드 추가
추가 가능한 코드
- Code Formatter 추가
- Type Checker 추가
- 검증 루프 계속 확장 → Build Agent로 피드백
단계 4: Test Agent 통합
- 모든 테스트, 검증, 린팅, 타입 체킹을 단일 Test Agent에 집약
- 컴퓨트를 확장해 임팩트를 확장 (Scale compute to scale impact)
- 실패 시 → Build Agent로, 성공 시 → 엔지니어 리뷰 → 배포
단계 5: Planning 추가
워크플로우에 계획 단계 통합:
- Plan → Build → Test → Engineer Review → Ship
- 엔지니어가 직접 하던 모든 단계를 AI로 강화한 것
단계 6: Work Trees (병렬화)
Work Tree의 장점
- 각 에이전트가 독립적 Work Tree에서 실행
- 에이전트들이 서로 충돌하지 않음 (isolation)
- 병렬 작업 가능 → 처리량 대폭 증가
- 결정론적 코드로 Work Tree를 빌드하고 여러 에이전트를 병렬 실행
단계 7: Agent Sandbox (완전한 격리)
Work Tree vs Agent Sandbox
- Work Tree: 좋은 시작점, 좋은 종착점이 아님
- Agent Sandbox: 각 에이전트가 자신만의 컴퓨터 환경을 가짐
- 장점: 완전한 격리, 엔지니어가 직접 sandbox에 들어가 작업 결과 검토 가능
단계 8: Kanban Board + Ticket System 통합
티켓 처리 파이프라인
[Support/Product/Engineers]
→ Kanban Ticket
→ 엔지니어가 Mid-to-Low Level 프롬프트로 번역
→ Scout Agent (코드/문서/스펙 검색)
→ Plan Agent (계획 수립)
→ 코드로 티켓 상태 업데이트
→ Build Agent → Test Agent → CI/CD
→ 엔지니어 리뷰 → Fail/Pass/Ship
핵심 개념: Agentic Layer vs App Layer
- App Layer: 실제 애플리케이션 코드
- Agentic Layer: 에이전트, 프롬프트, 스킬, 시스템 프롬프트
- 지금 당장 집중해야 할 것은 Agentic Layer
"Agentic engineering is not just about the agents. It's about your team and most importantly your users."
단계 9: 고급 팀은 엔지니어 입력 프롬프트 단계 건너뜀
- 조직이 프롬프트 작성을 잘하게 되면, 엔지니어 번역 단계 생략 가능
- 엔지니어의 역할: Meta Layer에서 시스템을 빌드하는 것
핵심 주제 4: Production Crisis 대응 워크플로우
프로덕션 다운 시나리오
플로우
[Production Down]
→ Support files ticket → Slack/Teams 알림
→ 핵심 엔지니어가 즉시 Scout Agent 프롬프트
→ Hot Fix Agent (특화된 에이전트)
→ Human in the Loop (승인/거절)
→ 승인 시: 여러 Agent Sandbox에서 병렬로 솔루션 실행 (Racing)
→ 가장 빠른 에이전트가 이김
→ 실패 시 Hot Fix Agent + 엔지니어로 되돌아감
→ 성공 시 엔지니어 검증 → 핫픽스 배포
Hot Fix Agent의 특성
- 특화된 에이전트: 빠른 수정에만 집중
- 올바른 방식을 고집하지 않음, 최적화하지 않음
- 오직 ASAP 수정에만 집중
레이싱 전략
- 3, 5, 10개의 에이전트가 각자의 sandbox에서 경쟁
- 첫 번째로 솔루션을 찾은 에이전트가 이김
- 컴퓨트 예산에 따라 스케일 조정
핵심 질문 (조직에 던지는 질문)
"당신의 조직에는 프로덕션 다운 시 AI 개발자 워크플로우가 있는가?"
핵심 주제 5: Full Software Factory
소프트웨어 팩토리의 구조
다양한 유형의 특화된 Agent Sandbox Workflow:
- Chore Workflow: 반복 작업용
- Bug Fix Workflow: 버그 수정용
- Feature Workflow: 기능 개발용
- Hot Fix Workflow: 긴급 수정용
- Routing System이 올바른 워크플로우로 라우팅
"This is the art and science of agentic engineering."
핵심 주제 6: 엔지니어의 두 가지 역할 (Two Constraints)
Agentic Engineering에서 엔지니어가 나타나는 시점
- 시작: Prompting (= Planning)
- 끝: Reviewing (= Validation)
"You and I always show up at the ends. These are the two constraints of agentic engineering."
중간은 시스템이 처리
- 시스템이 스스로 동작 (Autonomous operation)
- 엔지니어는 시스템을 구축하는 데 집중
핵심 주제 7: 실전 조언 세 가지
조언 1: 먼저 직접 해봐라 (Design ADWs by doing the work yourself first)
방법
- 워크플로우를 직접 단계별로 실행해보기
- 각 노드를 직접 밟아보기
- 조건 실행, 함수 실행, 리뷰, 배포까지 직접 경험
- Mermaid diagram으로 워크플로우를 먼저 그려보기
조언 2: 에이전트와 코드를 분리하라 (Separate Code from Skills)
이유
- 프로덕션 단계에서 스킬 안에 코드를 넣으면 안 됨
- 그 코드도 여전히 에이전트가 실행하는 것이 됨
- 코드를 독립적으로 분리해야 올바른 가드레일과 정보 흐름 설정 가능
KISS 원칙 적용
- 시작: 모든 것을 하나의 스킬에 (단순하게 유지)
- 프로덕션화: 코드를 스킬에서 분리
조언 3: 에이전트 + 코드를 함께 사용하라 (Agents + Code beats either alone)
왜 함께?
- 코드가 필요한 이유: 성능, 신뢰성, 속도
- 에이전트가 필요한 이유: 인텔리전스, 유연성
- 각 노드를 독립적으로 테스트해야 함 → 분리 필수
클래식 엔지니어링 원칙 유지
- Isolatable (격리 가능)
- Decoupled (디커플드)
- Single interface
"Once you do it right and you set up your AI developer workflow, it gets multiplied hundreds and thousands of times."
핵심 주제 8: Dan의 배경 및 채널 철학
IndyDevDan (Dan Eisler) 배경
- 15년+ 소프트웨어 엔지니어링 경험
- Blizzard 인턴 → 금융/회계 분야 (C, TypeScript, Python, Vue)
- AI 코딩 초기부터 시작: Aider, GPT-3.5 Turbo, GPT-4, Sonnet 3 사용
- agenticengineer.com 소유 — 수천 명의 엔지니어 교육
채널 철학
- 뉴스 팜 채널이 아님 — "Think, Plan, Build"
- 매주 월요일 업로드
- 모든 콘텐츠는 무료 (강의도 있지만)
권장 리소스
- Tactical Agentic Coding 코스: agenticengineer.com (30일 환불 보장, 4강 시작 전)
- Agentic Horizon (업그레이드): Multi-agent orchestration, Agent Experts
- 블로그: "Thinking in Threads" (링크 설명란)
메타 인사이트: "시스템을 만드는 시스템을 구축하라"
"You want to be building the system that builds the system."
- App Layer를 더 이상 직접 건드리지 않는다
- Agentic Layer가 App Layer를 대신 구축한다
- 엔지니어는 Meta Layer에서 활동 → 조직 전체에 복리로 확산된다
Agent Expert 개념 (Agentic Horizon)
- 특화된 전문가 에이전트 구축
- Out-of-the-box 에이전트보다 성능 뛰어남
- 중요한 미래 패턴
노트 작성: 2026-07-14 | 영상 길이 추정: ~25분 | 자막 기반 완전 재구성