My Super Simple Software Factory (For Agentic Engineers)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

My Super Simple Software Factory (For Agentic Engineers)를 중심으로, 소프트웨어 팩토리의 가치는 에이전트 수가 아니라 프롬프트 레버리지에서 나온다. 에이전트와 코드를 함께 설계해 사람 없이도 동등하거를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 소프트웨어 팩토리의 가치는 에이전트 수가 아니라 프롬프트 레버리지에서 나온다. 에이전트와 코드를 함께 설계해 사람 없이도 동등하거나 더 나은 결과를 반복할 수 있을 때 레버리지가 커진다.
2. 관측 가능성·맞춤 가능성·재사용 가능성이 운영의 세 축이다. 입력, 보강된 프롬프트, 모델별 이벤트, 도구 호출, 비용과 오류를 단계별로 추적해야 성능과 신뢰성을 개선할 수 있다.
3. 스카우트·계획·구현·검사·문서화 같은 원자적 작업을 조합하면 전체 개발 수명주기로 확장할 수 있다. 각 단계에는 목적에 맞는 모델·프롬프트·도구·하네스를 배치하고, 오케스트레이터가 필요한 스킬을 지연 로딩한다.
4. 에이전트가 작업을 제안하더라도 진행 여부는 결정론적 코드가 판정해야 한다. JSON 형식의 구조화된 핸드오프, 코드 기반 게이트, 테스트 실패의 재전달을 통해 수백·수천 회 실행에서도 형식과 품질을 일관되게 유지한다.
5. 프로덕션 팩토리는 첫 성공이 아니라 천 번째 실행을 기준으로 설계해야 한다. 브랜치·샌드박스·격리 실행·병합·세션 재시작을 갖추고, 템플릿과 기본 테스트를 실제 코드베이스에 맞게 바꿔야 반복 업무를 안정적으로 이전할 수 있다.

🧩 배경과 문제 정의

• 소프트웨어 팩토리의 가치는 에이전트 수를 늘리는 데 있지 않고, 한 번의 프롬프트가 더 큰 작업을 안정적으로 수행하게 만드는 레버리지에 있다.
• 단일 에이전트나 멀티에이전트 구성만으로는 부족하며, 엔지니어·코드·에이전트를 전체 소프트웨어 개발 수명주기에 맞춰 배치해야 한다.
• 실행 규모가 커질수록 관측 가능성, 결정론적 검증, 맞춤 가능성, 재사용 가능성이 비용과 신뢰성을 좌우한다.

🕒 시간순 섹션별 상세정리

1. 프롬프트 레버리지로 보는 소프트웨어 팩토리

• 소프트웨어 팩토리의 핵심 효용은 프롬프트 하나가 수행할 수 있는 일을 늘리는 레버리지이며, 설계와 구성에 투자한 품질이 그 크기를 결정한다. [00:13]
• 낮은 단계는 몇 개의 에이전트를 연결하는 수준이지만, 높은 단계는 에이전트와 코드를 결합해 사람 없이도 동등하거나 더 나은 결과를 내는 시스템으로 확장된다. [00:32]

2. 관측·맞춤·재사용의 세 가지 원칙

• 관측 가능성, 맞춤 가능성, 재사용 가능성이 세 가지 설계 원칙이며, 실행을 측정할 수 있어야 에이전트의 성능도 개선할 수 있다. [01:23]
• 스윔레인 화면에서 모델별 실행 이벤트와 작업 흐름을 확인하므로, 어느 단계에서 어떤 결과와 오류가 발생했는지 추적할 수 있다. [01:35]

3. 엔지니어·코드·에이전트의 역할 결합

• 가치 창출의 세 주체는 엔지니어, 실제로 실행되는 코드, 에이전트이며, 컴퓨트와 영향력을 확장하려면 세 주체를 적절한 시점에 결합해야 한다. [02:09]
• 이벤트와 컴파일된 프롬프트, 도구, 코딩 에이전트, 하네스를 함께 추적하면 프롬프트·컨텍스트·하네스·개발 수명주기를 세부적으로 조정할 수 있다. [02:35]

4. 단일 스카우트로 시작하는 원자적 워크플로

• 앱의 구조와 기능을 분석하고 개선 기능 세 가지를 제안하라는 요청을 받은 오케스트레이터는 필요한 스킬을 지연 로딩한 뒤 스카우트 작업을 시작한다. [04:10]
• 관측 화면은 엔지니어의 입력, 오케스트레이터가 명확하게 보강한 프롬프트, 스카우트 실행을 실시간으로 분리해 추적한다. [04:31]

5. 원자 단위에서 복합 개발 흐름으로

• 오케스트레이터는 스카우트·계획·구현·품질 검사·문서화뿐 아니라 계획-구현-테스트와 전체 개발 수명주기 같은 복합 워크플로도 선택할 수 있다. [06:40]
• 라이트 모드와 향후 테마 확장을 위한 디자인 시스템을 요청하자 계획·구현·테스트를 잇는 3단계 워크플로가 실행된다. [07:23]

6. 라이트 모드 검증과 코드의 소유 가치

• 완성 화면에서 라이트 버튼을 누르면 색상이 반전돼 기능 구현을 즉시 확인할 수 있고, 단순한 UI 변경에도 실행 결과를 직접 검증한다. [08:54]
• Kimi K3가 계획하고 Gemini 3 Flash가 구현한 뒤 두 개의 코드 검사가 결과를 확인하며, 검사 실패 시 작업을 빌드 에이전트로 되돌려 수정한다. [09:01]

7. 전체 개발 흐름과 구조화된 핸드오프

• 개발 작업의 출발 단위가 프롬프트나 에이전트 팀에서 재현 가능한 엔드투엔드 개발 워크플로로 바뀌면, 애플리케이션에서 원하는 성공을 반복할 수 있다. [10:28]
• 계획 단계 끝에는 코드 기반 게이트가 결과를 검사하고, 비용·출력·세션 디렉터리를 함께 남겨 다음 단계가 필요한 컨텍스트를 이어받게 한다. [11:22]

8. 결정론적 경로로 비용과 오류 줄이기

• 빌드 단계는 계획 단계가 남긴 작업 지시와 컨텍스트 묶음, 응답 보고서 형식을 받아 실행하고, 자신의 출력도 다음 에이전트가 사용할 수 있도록 연결한다. [12:39]
• 변경 파일과 도구 호출을 기록하면 각 단계의 동작을 진단하고 개선할 수 있으며, 엔지니어의 요청·코드 실행·에이전트 판단을 명확히 분리할 수 있다. [13:01]

9. 전체 SDLC로 마크다운 미리보기 구축

• Inkwell에 편집·분할·미리보기를 전환할 수 있는 마크다운 뷰어를 추가하고 테스트까지 포함하는 작업에 전체 소프트웨어 개발 수명주기를 적용한다. [14:20]
• 최상위권 구성을 요청하면 단계마다 모델·역할·에이전트 하네스·도구를 바꿀 수 있으며, 중요한 계획 단계에는 강력한 모델을 배치한다. [14:41]

10. 코드가 통제하는 단계별 아키텍처

• SSSF 단일 스킬을 중심으로 에이전트가 작업을 제안하고 코드가 결과를 판정하며, 결정론적 검증 코드가 전체 워크플로의 진행 여부를 통제한다. [16:28]
• 가장 큰 단순 SDLC도 약 180줄이며, 반복 운영의 핵심 경로는 사람이 직접 읽고 이해해야 규모 확장과 에이전트 운용 오류를 관리할 수 있다. [17:02]

11. 코어 포와 특화 에이전트 하네스

• 에이전트 구성의 코어 포는 컨텍스트·모델·프롬프트·도구이며, 계획자 설정에서 제공자와 모델, 추론 수준, 시스템·사용자 프롬프트, 하네스를 함께 지정한다. [18:18]
• 계획자·빌더·스카우터마다 도구와 프롬프트, 하네스를 특화하고 필요한 역할에는 하위 에이전트 생성 기능까지 부여해 단계별 능력을 다르게 만든다. [18:59]

12. 일회성 성공을 넘어선 운영 규모

• 완료된 흐름은 단계별 모델과 비용, 에이전트 구성을 한 화면에서 보여주고, 각 단계를 하나의 에이전트·프롬프트·목적으로 좁히며 세션 ID로 재시작할 수 있다. [20:44]
• 프로덕션에서는 브랜치·샌드박스·격리 실행·병합 단계를 추가해야 하며, 테스트 실패는 에이전트에 되돌리고 리뷰와 변경 내역은 다음 엔지니어나 에이전트를 위해 남겨야 한다. [21:23]

13. 설치 가능한 스킬과 에이전틱 접근

• 팩토리의 모든 요소는 원자적이고 조합 가능하며, SSSF 스킬과 설치 명령은 에이전트가 구성요소를 다른 코드베이스에 복사해 동일한 시스템을 배치하도록 만든다. [24:42]
• 쿠크북은 새 저장소 설정, ADW 생성·수정, 구성 파일 작성, 에이전트 로스터 설정을 지연 로딩 액션으로 라우팅해 반복적인 수작업을 에이전트에 넘긴다. [25:55]

14. 반복 업무를 에이전트 스택으로 이전하는 소프트웨어 팩토리

• 소프트웨어 팩토리는 프롬프트의 활용도를 높이며, 결과 품질은 팩토리를 구성하는 AI 개발자 워크플로에 얼마나 많은 노력·시간·투자를 했는지에 따라 달라진다. [26:57]
• 팩토리를 클라우드에 배포하고 샌드박스를 마련하면 엔지니어링의 반복적인 80% 업무를 에이전트 스택에 안정적으로 넘기고, 사람은 에이전트만으로 해결할 수 없는 새롭고 어려운 문제에 집중할 수 있다. [27:22]

15. 바이브 코딩을 넘어 에이전틱 엔지니어링으로

• 바이브 코딩은 시스템의 작동 원리를 모른 채 결과를 확인하지 않는 방식인 반면, 에이전틱 엔지니어링은 시스템을 충분히 이해해 매번 내부를 들여다보지 않아도 되는 수준을 지향한다. [28:32]
• 고급 AI 개발자 워크플로는 단순한 AI 코딩을 넘어 코드베이스가 스스로 운영되는 수준을 목표로 하며, 무료 Super Simple Software Factory와 별도의 Tactical Agentic Coding 과정이 학습 경로로 제공된다. [28:45]

🧾 결론

• 개발의 기본 단위를 단일 프롬프트나 에이전트 팀이 아니라 재현 가능한 엔드투엔드 워크플로로 바꿔야 한다.
• 가장 실용적인 역할 분담은 에이전트가 제안하고, 코드가 검증하며, 엔지니어가 전체 구조와 예외를 설계하는 방식이다.
• 빠르고 저렴하게 실행·수정할 수 있으며 직접 소유할 수 있는 결정론적 코드는 임대형 AI 모델과 구별되는 핵심 자산이다.
• 에이전틱 엔지니어링은 결과를 확인하지 않는 바이브 코딩이 아니라, 시스템을 이해하고 검증 가능한 경로를 설계한 뒤 반복 실행을 맡기는 접근이다.

📈 투자·시사 포인트

• 경쟁력의 중심은 최고 모델 하나에 대한 접근권보다 모델·코드·도구를 작업별로 조율하는 워크플로 설계 역량으로 이동할 수 있다.
• 모델별 품질·속도·비용을 함께 비교해 단계별로 배치하는 구조는 단일 모델 중심의 선택보다 운영 효율을 높일 가능성을 시사한다.
• 조직이 직접 소유하는 검증 코드, 프롬프트, 하네스와 재사용 가능한 워크플로는 모델이 교체되더라도 남는 누적 자산이 될 수 있다.
• 도입 가능성을 평가할 때는 데모의 첫 성공보다 관측성, 실패 복구, 격리 실행, 반복 비용과 천 번째 실행의 일관성을 핵심 지표로 봐야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 반복적인 엔지니어링 업무의 80%를 에이전트 스택에 넘길 수 있다는 주장은 목표에 가깝고, 프로젝트 유형·팀 규모·실패율별 실측 자료는 제시되지 않았다.
• Opus 5가 Fable 5보다 절반 수준의 가격이라는 비교와 각 모델의 순위는 측정 시점, 요금 조건, 평가 과제와 토큰 사용량을 별도로 확인해야 한다.
• 라이트 모드와 마크다운 미리보기 데모는 워크플로의 작동 방식을 보여주지만, 프로덕션 천 번째 실행의 안정성을 입증할 성공률·복구 시간·비용 분포는 제공하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 개발 수명주기에서 반복 빈도가 높고 결과를 명확히 검사할 수 있는 작업 하나를 첫 원자적 워크플로로 선정한다.
• 입력·계획·구현·테스트·리뷰 사이의 JSON 핸드오프 스키마와 각 단계의 코드 기반 통과 조건을 정의한다.
• 모델별 실행 품질·속도·비용·실패 유형을 기록하고, 계획자·빌더·스카우터에 서로 다른 모델과 하네스를 배치해 비교한다.
• 브랜치·샌드박스·격리 실행·병합·세션 재시작과 테스트 실패 반환 경로를 포함한 프로덕션 운영 장치를 마련한다.

❓ 열린 질문

• 어떤 작업까지 결정론적 코드로 처리하고, 어떤 판단부터 에이전트에 맡기는 것이 비용과 품질의 최적점을 만드는가?
• 천 번째 실행의 신뢰성을 입증하려면 성공률·비용·지연 시간·재시도 횟수 가운데 어떤 지표와 임계값을 사용해야 하는가?
• 반복 업무를 에이전트에 이전하면서도 보안·병합·최종 승인에 필요한 인간 개입 지점을 어떻게 최소한으로 유지할 것인가?