메타데이터
- 채널: IndyDevDan
- 제목: My Super Simple Software Factory (For Agentic Engineers)
- URL: https://www.youtube.com/watch?v=haUfb1ievTE
- Video ID: haUfb1ievTE
- 처리일: 2026-08-05
- 카테고리: AI 에이전트 오케스트레이션 / 에이전틱 엔지니어링 / 소프트웨어 팩토리
1계층 — 한 줄 요약
"소프트웨어 팩토리"는 프롬프트 하나로 얻는 것보다 훨씬 큰 레버리지를 만들어주는 시스템이며, 그 핵심은 "에이전트 단독"이 아니라 "에이전트 + 결정론적 코드"의 조합에 있다. IndyDevDan은 자신의 오픈소스 도구인 Super Simple Software Factory(SSSF)를 실제로 시연하며, 관측 가능성(observable), 커스터마이징 가능성(customizable), 재사용성(reusable)이라는 세 가지 설계 원칙을 어떻게 코드로 구현했는지 보여준다.
2계층 — 핵심 주장과 구조
소프트웨어 팩토리란 무엇이고 왜 필요한가
- 소프트웨어 팩토리는 근본적으로 "프롬프트에 대한 레버리지"를 얻기 위한 것이다. 그 이상도 이하도 아니다.
- 레버리지의 크기는 당신이 그 팩토리에 투자한 노력의 질에 비례한다.
- 낮은 수준: 에이전트 몇 개를 체이닝해서 약간의 추가 작업을 자동화
- 높은 수준: 에이전트 + 코드로 구성된 시스템이 사람 없이도, 때로는 사람보다 더 잘 작동
- 이 팩토리는 채널과 TAC(Tactical Agentic Coding)에서 다뤄온 아이디어들을 에이전틱 엔지니어링의 다음 단계에 맞게 처음부터 다시 만든 것이다.
세 가지 설계 원칙
- Observable (관측 가능성): 에이전트를 측정할 수 없으면 개선할 수 없다. 모든 AI 개발자 워크플로우(ADW)를 스윔레인 뷰로 클릭해 들어가 정확히 무슨 일이 일어났는지 볼 수 있다. 사용된 모델(Kimi K3, Gemini 3.6 Flash, GPT-5.6 Terra, GPT-5.6 Luna 등), 컴파일된 프롬프트(시스템+유저), 에이전트 설정, 툴, 코딩 에이전트 종류, 특정 에이전트 하네스까지 전부 확인 가능.
- Customizable (커스터마이징 가능성): 모델, 역할, 에이전트 하네스, 툴 등 모든 것을 개별적으로 설정할 수 있다. "Core Four"라는 개념 — Context, Model, Prompt, Tools — 이 네 가지를 마스터하면 에이전트를 마스터하는 것.
- Reusable (재사용성): 이 시스템은 스킬(skill) 형태로 어떤 코드베이스에든
/install명령 한 번으로 이식 가능. 팩토리 자체를 새 저장소에 배포하는 시스템.
세 명의 가치 창출 주체
저자는 가치를 만드는 세 주체를 명시적으로 구분한다:
- 엔지니어(me) — 사람
- 코드(code) — 실제로 실행되는 결정론적 로직
- 에이전트(agent) — AI가 수행하는 작업
핵심 메시지: "Agents plus code beats agents alone" (에이전트+코드가 에이전트 단독보다 낫다). 단순히 여러 에이전트를 병렬로 돌리거나 팀 구성을 바꾸는 것이 아니라, 엔지니어+코드+에이전트를 적절한 시점에 결합하는 것이 핵심.
서브 엔지니어링 영역
소프트웨어 팩토리는 다음 네 가지 하위 엔지니어링을 통합적으로 다룬다:
- Prompt engineering (프롬프트 엔지니어링)
- Context engineering (컨텍스트 엔지니어링)
- Harness engineering (하네스 엔지니어링)
- "Loop engineering"이라 잘못 불리는 것 — 실제로는 소프트웨어 개발 생명주기(SDLC) 관리. 저자는 이 용어가 SDLC를 형편없이 리브랜딩한 것이라 비판하며, 관련 이전 영상을 참고하라고 안내(설명란 링크).
3계층 — 실제 데모 3단계 (난이도 순)
데모 1: 단순 스카우트(Scout) 워크플로우
- 터미널 멀티플렉서로 tmux 대신 Herder를 사용 중 (더 커스터마이징 가능, 더 간단, 더 빠름).
- Pi 코딩 에이전트 + Opus 5 모델로 실행.
- 프롬프트: "이 앱이 무엇인지, 어떤 기능이 있는지 분석하고 새 기능 3개를 제안하라."
- 에이전트가 스킬을 lazy-load하며 워크플로우(ADW scout)를 자동 오케스트레이션 — 사람이 명령어를 직접 치지 않고 에이전트가 대신 조율("agentic speed로 움직인다").
- 실행 모델은 Gemini 3.6 Flash (가성비 최고의 A급 워크호스 모델, 입력 $1.50 수준으로 Luna를 제외한 거의 모든 상위 모델을 가격 대비 성능에서 앞선다). 자신만의 "모델 스택"(state-of-the-art / workhorse / lightweight 온디바이스 계층)을 관리 중이라고 언급.
- 테스트 앱은 Inkwell이라는 글쓰기용 미니 애플리케이션 (포커스 모드, 확대/축소 등 지원).
- 결과: 에이전트가 앱 구조를 스캔하고 새 기능 3가지를 제안 — 단순한 "요청 → 스카우트 에이전트"의 2단계 워크플로우.
데모 2: 중급 — Plan → Build → Test (라이트 모드 추가)
- 프롬프트: "다크 기본 테마와 대비되는 라이트 모드를 추가하라. 향후 다른 테마도 추가할 수 있는 디자인 시스템을 구축하라."
- 3단계 에이전틱 워크플로우: Plan → Build → Test.
- 플래너는 Kimi K3(Fireworks 경유) 사용 — Opus/Fable 급은 아니지만 최초의 오픈웨이트 SOTA급 모델로 평가. 다만 "생각을 많이 해서" Opus/Fable보다 느림.
- Fireworks에 대한 언급: 데이터 소유권 문제(전주 영상에서 다룬 "Anthropic이 사용료를 받으면서 데이터도 가져가는가?" 주제와 연결)에 대응해, 빠른 티어와 우선 서버리스 티어를 제공하며 데이터를 가져가지 않는 저렴한 서버리스 추론을 제공한다고 평가(스폰서 아님을 명시).
- 빌드는 Gemini 3 Flash로 실제 구현.
- 완료 후 라이트 모드 버튼 클릭 → 색상 반전 확인, 실제 동작.
- 빌드 이후 결정론적 코드 체크 2개가 자동 실행되어 검증하며, 실패 시 빌드 에이전트에게 되돌려 수정하게 함.
- 핵심 통찰: "이 모든 게 에이전틱일 필요는 없다"— 사람들이 놓치는 큰 아이디어. 모두가 "에이전트에 심취"해 있지만, 코드는 비용이 거의 없고 빛의 속도로 실행되며 즉시 변경 가능하다는 사실을 재발견하는 중. 우리는 코드는 "소유"하지만 AI 모델은 "임대"하는 것일 뿐 — 그래서 코드를 워크플로우의 1급 시민으로 취급해야 한다.
데모 3: 고급 — 풀 SDLC (마크다운 사이드바이사이드 뷰어)
- 프롬프트: "Inkwell 에디터에 사이드바이사이드 마크다운 뷰어를 추가하라. 전환 가능(togglable)하게 만들고 테스트로 커버하라. 이 작업에는 state-of-the-art 설정을 사용하라."
- 플래너: Claude Opus 5 — "게임 체인징 모델"이라 극찬. 단, 저자는 Opus 5가 벤치마크상 Fable 5를 앞선다고 알려져 있지만, 본인 체감으로는 여전히 Fable 5가 한 수 위라고 느낀다고 밝힘(가격은 Opus 5가 절반이라 기본 선택은 Opus 5, 정말 중요한 상황에서는 Fable 5 사용). 시청자에게 "Opus 5가 Fable 5를 이기는지" 댓글로 의견을 묻는다.
- 코드베이스 구조 설명(VS Code로 코드 열람):
- 전체가 SSSF(Super Simple Software Factory) 스킬 하나로 감싸져 있음.
ADWS디렉토리에 end-to-end AI 개발자 워크플로우들이 들어있음.- 예시로 본
simple SDLC워크플로우는 약 180줄의 Python. - Python의
with문으로 각 단계(phase)의 진입/종료를 명시적으로 구분: planning → commit plan → build → test → (실패 시) fix → review → revise → (실패 시) → document → commit docs. kind=값으로 각 단계가 "search / engineer(사람) / agents / code" 중 무엇인지 명확히 구분해 표기 — 에이전트와 코드를 명확히 분리하는 패턴.- 모든 단계는 저자가 선호하는 코딩 툴인 Pi 코딩 에이전트 호출로 귀결됨(
ADW modules에서 설정 확인 가능).
- 설정 파일(config)과 Core Four:
- 각 에이전트(플래너, 빌더 등)는 YAML 기반 config 파일로 정의되며 Context / Model / Prompt / Tools의 "Core Four"를 명시.
- 예: 플래너는 Kimi K3(Fireworks 경유, thinking high)를 사용하고 고유한 시스템/유저 프롬프트, 고유한 하네스 설정을 가짐.
- 각 에이전트는 고유한 커스텀 에이전트 하네스를 가질 수 있음 — 예를 들어 플래너와 스카우터에는 서브 에이전트를 부를 수 있는 능력이 추가되어 있음.
- ADW 실행 코드: 가장 단순한 ADW인 "prompt" 예시를 통해, 입력을 받아 실제로 에이전트를 실행하는 흐름을 설명.
agent.py의run_workflow로 귀결되며, Pi 코딩 에이전트를 params, mode(JSON), provider 등으로 세팅해서 실행. - "Stay in distribution" 철학: 커스텀 DSL을 만들지 않는다. 커스터마이징 지점은 YAML config뿐이며, 나머지는 순수 Python + YAML + 에이전트 + 스킬. 즉 모델이 이미 잘 아는 것들(Python, YAML)의 분포 안에 머무른다.
- 완료 후 결과 확인: 전체 모델 커스터마이징, 비용 분석, 전체 에이전트 설정, phase별 작업(plan → build → review, 각 단계는 "1 agent, 1 prompt, 1 purpose")이 가능함을 보여줌. 세션 ID/ADW ID로 워크플로우 재시작도 가능.
- 한계점 인정: 현재는 메인 브랜치에 바로 작업 중 — 실제로는 브랜치를 따고, 에이전트를 샌드박스에 격리하고, 이후 머지 단계를 둬야 한다고 명시.
- 빌드 직후 테스트 스위트를 바로 실행해 실패 시 에이전트에게 피드백을 되돌리는 구조, 리뷰 단계("우리가 요청한 걸 만들었는가?"를 Opus급 모델이 검증), 이후 커밋과 diff(다음 엔지니어/에이전트를 위한 문서화 목적)로 마무리.
- 마크다운 뷰어 기능 실제 검증: 밑줄, 불릿, 리스트, 헤더(H2) 등 마크다운 요소들이 사이드바이사이드 프리뷰에서 정상 렌더링됨을 실시간으로 확인.
4계층 — 시스템 철학, 스킬 재사용 구조, 결론
이 시스템이 필요한 스케일에 대한 자기비판적 인정
- 저자 스스로 "이 정도 기능(마크다운 뷰어)은 굳이 이런 시스템 없이 에이전트 하나로도 만들 수 있었을 것"이라 인정.
- 하지만 시스템이 점점 커지고 복잡해지면 검증(validation)이 유일한 전진 방법이 되는 시점이 온다고 주장. 그 비용을 에이전트에게 넘기면 시간이든 비용이든 어떤 차원에서는 반드시 대가를 치르게 됨.
- "1번째, 10번째 실행이 아니라 1000번째 실행을 생각하라"— 반복 가능성과 스케일을 염두에 둔 엔지니어링 철학.
재사용 가능한 스킬 시스템
docs/skills/SSF라는 스킬을 통해 에이전트가 이 소프트웨어 팩토리 자체를 조작하는 법을 학습함.- 다른 코드베이스에 이 팩토리를 심는 것도
/install명령 한 번으로 가능 — 완전히 재사용 가능한 시스템으로 설계. - 스킬 설계 철학: 중심 아이디어(예: "재사용 가능한 agents+code 시스템을 어떤 코드베이스에도 배포·운영") + "쿡북(cookbook)" — lazy-load되는 액션들의 모음(예: 새 저장소에 팩토리 셋업, 새 ADW 생성/수정, 새 에이전트 로스터 구성 등 요청 라우팅 테이블).
- **에이전틱 접근(agentic access)**은 에이전틱 엔지니어링의 5대 핵심 축 중 하나로 언급됨. "손으로 뭔가를 계속 하고 있다면 너무 느리게 움직이는 것 — 시스템을 만드는 시스템을 만들어야 한다."
- 이 팩토리에 포함된 템플릿/테스트/플랜 품질은 "기본값"일 뿐이며, 사용자가 자신의 상황에 맞게 반드시 커스터마이징해야 한다고 강조.
핵심 메시지 정리 (저자의 결론)
- 소프트웨어 팩토리가 주는 레버리지는 투자한 노력·시간·정성에 비례한다.
- "이제 더 이상 하지 않아도 되는 엔지니어링 작업이 정말 많다 — 그런데 왜 아직도 하고 있는가?"
- Vibe coding의 정의(저자 관점): 시스템이 어떻게 동작하는지 모르고, 들여다보지도 않는 것.
- Agentic engineering의 정의: 시스템이 어떻게 동작하는지 너무 잘 알아서 굳이 들여다볼 필요가 없는 것.
- "Vibe coding의 바닥이 아니라 Agentic engineering의 천장을 향해 올라가라."
- 자신의 유료 강의 **Tactical Agentic Coding(TAC)**을 홍보하며, "이건 상위 20% 엔지니어를 위한 것"이라 언급. 반면 SSSF 자체는 완전 무료 오픈소스로 배포한다고 명시(설명란 링크).
- 다음 세션(매주 월요일) 예고로 마무리.
핵심 인용 (저자 원문 뉘앙스)
- "Software factories give you more leverage on your prompt. That's it."
- "Agents plus code beats agents alone."
- "If you can't measure your agents, you can't improve them."
- "Code costs nothing, runs at the speed of light, and can be changed in an instant. You own your code. You're renting your AI models."
- "Vibe coding is not knowing how your system works and not looking. Agentic engineering is knowing how your system works so well you don't have to look."
- "If you're doing something you can teach your agents to do, why aren't you?"
시청 포인트 / 활용 메모
- Core Four(Context, Model, Prompt, Tools) 프레임은 어떤 에이전트 설계에도 그대로 적용 가능한 체크리스트로 쓸 만함.
- "결정론적 코드 게이트(deterministic gate checks)"를 plan/build 단계 사이사이에 끼워 넣는 패턴은 실무 에이전틱 파이프라인 설계 시 바로 참고할 수 있음.
- 모델을 하나로 고정하지 않고 역할별(플래너=고성능/느림, 빌더=저비용/빠름)로 분산 배치하는 "모델 스택" 개념은 비용-성능 트레이드오프 관리에 실질적으로 적용 가능.