YouTubeIndyDevDan·2026년 11월 2일·0

Tiny Software Factories: Agentic Engineering DONE WRONG

Quick Summary

Tiny Software Factories의 ‘잘못된 에이전트 엔지니어링’은 장기 확장성을 희생해, 사람이 매번 지시하지 않아도 먼저 일하고 검토를 기다리는 작은 소프트웨어 공장을 빠르게 만드는 접근이다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Tiny Software Factories: Agentic Engineering DONE WRONG 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Tiny Software Factories: Agentic Engineering DONE WRONG의 핵심 내용을 4단계로 요약한 인포그래픽
Tiny Software Factories: Agentic Engineering DONE WRONG 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Tiny Software Factories의 ‘잘못된 에이전트 엔지니어링’은 장기 확장성을 희생해, 사람이 매번 지시하지 않아도 먼저 일하고 검토를 기다리는 작은 소프트웨어 공장을 빠르게 만드는 접근이다.

📌 핵심 요점

  1. 단기 효용을 위한 안티패턴을 의도적으로 사용한다. 발표자는 이 접근을 장기 해법으로 권하지 않으며, 완성도보다 빠른 실행·수정·출시를 우선한다고 설명한다.
  2. 하나의 문제와 니어 루프 운영에 집중한다. 지속적으로 실행되는 환경에서 능동형 에이전트가 일하고, 사람은 결과에 피드백을 주거나 의사결정과 승인을 맡는다. 사람 없이 운영되는 아웃 오브 루프와는 구분된다.
  3. 빈 공장을 특정 용도로 특화한다. 기본 템플릿은 에이전트, 작업 대상 목록, 중앙 콘텐츠 화면을 제공한다. 시연에서는 Python·TypeScript·Rust 학습 페이지를 생성하지만, 목록과 콘텐츠는 다른 문제에 맞게 바꾸도록 설계된다.
  4. 사람과 에이전트의 조작 능력을 맞춘다. UI 조작에 대응하는 도구를 제공하고, 컨텍스트·모델·프롬프트·도구를 설정할 수 있게 한다. 에이전트가 자신의 설정도 바꿀 수 있어 통제 범위가 중요하다.
  5. 예약 프롬프트로 반복 작업을 시작한다. 크론 작업은 이름·일정·프롬프트로 구성된다. 시연에서는 언어별 학습 내용을 반복 생성하며, 발표자는 브라우저를 닫아도 에이전트가 계속 일한다고 설명한다.

🧩 배경과 문제 정의

영상은 Tiny Software Factories 입문 과정의 첫 수업이다. 목표는 작은 소프트웨어 공장을 만들어, 사람이 에이전트에게 매번 지시하는 인 더 루프에서 결과를 검토하고 결정을 내리는 니어 루프로 이동하는 것이다.

발표자는 확장 가능한 범용 시스템을 만드는 데 시간이 오래 걸린다는 문제를 제기한다. 이에 대한 단기 해법으로 하나의 문제에 특화된 템플릿을 빠르게 배치하고 수정하는 방식을 제시한다. 제목의 ‘DONE WRONG’은 이러한 방식이 장기 확장성을 갖춘 정석이 아니라, 당장의 효용을 위해 의도적으로 채택하는 안티패턴이라는 뜻이다.

수업은 빈 공장의 구조와 기능을 차례로 소개한다. 실제 시연에서는 프로그래밍 언어 학습 페이지를 만들고 예약 작업으로 내용을 추가한다. 완전 자율 운영을 완성하는 과정이나 장기 운영 성과를 검증하는 내용까지는 제공되지 않는다.

🕒 시간순 섹션별 상세정리

1. 정석보다 빠른 가치 창출을 택하는 입문 과정

  • 작은 공장이 상시 일하도록 만들어 사람이 작업 과정에 계속 붙어 있는 상태에서 벗어나도록 한다. 각 수업에서는 빈 공장과 실행 중인 공장을 통해 기능을 먼저 이해하도록 구성한다. [00:29]
  • 확장되지 않는 패턴을 배우는 대신 빠르게 만들고, 고치고, 출시한다. 니어 루프에 집중하는 압축 과정이며, 사람 없이 운영되는 아웃 오브 루프 과정과 구분한다. [01:24]
  • 장기 해법으로 권하지 않는다는 전제를 밝히고, 당장의 결과를 얻는 유용한 국소 최적점으로 보여준다. 올바른 구조에 대한 집착보다 출시를 우선한다. [02:05]

2. 작은 소프트웨어 공장의 정의와 사람의 역할

  • 작은 공장은 하나의 특정 문제를 해결하도록 만들어지며, 능동형 에이전트가 지속 실행 환경에서 상시 작업하고 사람은 니어 루프에 위치한다. [02:44]
  • 사람은 이미 수행된 작업에 피드백을 주고, 결정을 내리고, 승인한다. 발표자는 이 피드백이 공장을 개선하는 데이터 플라이휠을 만든다고 보여준다. [03:19]
  • 사람을 병목으로 지목하며 상당수 작업을 적절한 시스템에서 사람 없이 실행할 수 있다고 주장한다. 역할 변화는 ‘직접 프롬프트하기’에서 ‘결과에 응답하기’로 요약된다. [03:40]

3. 빠른 배치와 특화, 선제적 실행의 가치

  • 메타 스킬과 명령으로 코드베이스 옆에 공장을 배치하고 샌드박스에서 실행하는 구상을 제시한다. 범용적인 확장 시스템보다 빠르게 작동 상태에 도달하는 것이 목표다. [04:28]
  • 프롬프트·도구·단축키·확장 기능·테마를 열어 두어, 사람과 에이전트가 공장 자체를 수정하고 특정 문제에 맞게 특화할 수 있다고 보여준다. [04:58]
  • 지속 실행 에이전트와 트리거를 샌드박스 안에 결합한다. 사람이 일을 시작할 때까지 기다리는 대신 먼저 작업하고 검토를 기다리는 시스템을 지향한다. [05:37]

4. 기능 지도와 빈 공장 템플릿

  • 전체 과정은 네 가지 공장 수준을 따라 기능을 단계적으로 공개한다. 기능마다 노력·가치·요구 숙련도가 있으며, 설명은 가치와 노력에 집중한다. [06:18]
  • 빈 공장은 특화에 필요한 기능을 갖췄지만 아직 목적이 없는 템플릿이다. 브라우저의 최소 UI와 두 개의 사이드바를 보여주며, 각 기능을 문제 해결에 맞게 바꾸도록 안내한다. [07:00]

5. 에이전트·목록·중앙 작업 화면

  • 오른쪽에는 지속 실행 에이전트가 배치되어 있으며, 메시지로 바로 작업을 요청할 수 있다. 이어 공장이 무엇을 대상으로 작동할지 질문한다. [07:34]
  • 왼쪽 목록에는 사람과 에이전트가 함께 다룰 페이지가 있다. Python·TypeScript·Rust 기초 설명을 폴더 안에 만들도록 요청하자 페이지가 생성되고 중앙 화면에 표시된다. [08:25]
  • 중앙은 핵심 작업 대상에 집중하는 공간이다. 예제에서는 페이지·아티팩트·마크다운 문서를 생성하고 수정하며, 사람이 내용을 확인하고 조정할 수 있다. [09:09]

6. UI 조작과 에이전트 도구의 대응 관계

  • 사람이 UI에서 할 수 있는 모든 작업에 대응하는 에이전트 도구를 제공하는 접근을 보여준다. 페이지 관련 도구 목록을 요청해 에이전트의 접근 능력을 보여준다. [09:51]
  • 진정한 공장은 에이전트를 충분히 제어할 수 있어야 한다고 강조한다. 설정 화면의 Core 4를 이해하고 구성하는 능력을 에이전트 특화의 핵심으로 제시한다. [10:31]

7. Core 4 설정과 에이전트의 자기 변경

  • 컨텍스트 표시와 압축 설정을 보여준다. 예제 설정은 200K에서 자동 압축, 500K에서 강제 압축이며, 모델과 추론 수준은 성능·비용·속도에 맞춰 선택하도록 보여준다. [10:56]
  • 시스템 프롬프트와 도구를 확인하고, 사용자 정의·확장 프롬프트 및 도구의 설명과 매개변수를 살펴본다. [11:38]
  • 코딩 도구 비활성화와 추론 수준 변경을 요청해 에이전트가 자기 설정을 수정하는 모습을 보여준다. 유용한 범위까지 자기 변경을 허용할 수 있지만 통제가 부족하면 위험하다고 경고한다. [12:44]

8. 기능을 조합하는 확장 가능한 하네스

  • 에이전트는 여러 기능 층을 합친 구조로 드러난다. 공장, 코딩 도구, 페이지, 이미지 생성, 공장 제어 등의 하네스를 설정에서 확인한다. [13:30]
  • 이후 수업에서는 새로운 기능을 하네스에 추가하는 방법을 다룰 예정이라고 드러낸다. 사용감이 좋은 도구가 도구를 만들고 활용하는 데 더 투자하게 한다는 관점을 덧붙인다. [13:48]

9. 작업 방식에 맞게 바꾸는 개발·사용 경험

  • 테마·탐색 막대·단축키·애니메이션을 조정해 자신의 작업 방식에 공장을 맞춘다. 에이전트에게 테마 변경과 컨텍스트·상태 표시 추가를 요청한다. [14:43]
  • 페이지 선택 해제와 컨텍스트 표시 영역 조정 같은 작은 UI 조작도 에이전트가 수행할 수 있음을 보여준다. 이후 테마와 표시 요소를 다시 바꾸며 수정 가능성을 강조한다. [15:33]
  • 상태 애니메이션과 단축키까지 구성할 수 있으며, 핵심 도구 역시 빠르게 바뀔 수 있어야 한다고 드러낸다. 이를 변경과 맞춤화를 전제로 한 소프트웨어로 보여준다. [16:03]

10. 크론 프롬프트로 반복 작업 구성

  • 니어 루프와 향후 아웃 오브 루프로 이동하기 위한 기능으로 예약 프롬프트를 보여준다. 각 작업은 이름·일정·프롬프트로 구성되며, 사람이 자리를 비운 동안 에이전트가 실행한다. [16:49]
  • 언어별 폴더에 새로운 개념을 추가하는 반복 작업을 요청한다. 파일 쓰기 권한과 실행 빈도에 관한 응답이 나오자 페이지 도구를 사용하도록 지시하고 실행을 진행한다. [17:23]
  • 결과로 Python 컨텍스트 매니저, TypeScript 유틸리티 타입, Rust 수명 관련 학습 페이지를 확인한다. 발표자는 특정 업무 해법이 아니라 동작 방식을 보여주는 예시라고 보여준다. [17:48]

11. 반복 실행의 지속성과 미완의 다음 기능 예고

  • 다음 예약 이벤트가 다시 실행되는 모습을 확인한다. 발표자는 새로고침하거나 브라우저를 닫더라도 지속 실행 애플리케이션의 에이전트는 계속 작업한다고 보여준다. [18:17]
  • 예약 프롬프트를 반복 작업을 빠르게 추가하는 방법으로 정리한다. 다음 기능을 통해 빈 공장을 다른 상태로 바꾼다고 예고하지만, 무엇으로 바꾸는지 설명하기 전에 대본이 끝난다. [18:24]

🧾 결론

  • 핵심 전환은 ‘사람이 프롬프트를 계속 입력하는 방식’에서 ‘에이전트가 먼저 수행한 작업에 사람이 응답하는 방식’으로 이동하는 것이다.
  • 작은 공장의 효용은 모든 상황을 처리하는 범용성보다, 하나의 문제에 빠르게 배치하고 수정할 수 있다는 데 있다.
  • 도구 접근권, 설정 제어, 확장 가능한 하네스, 예약 실행이 결합하면서 빈 템플릿이 반복 작업 시스템으로 발전한다.
  • 이번 영상은 기본 구조와 반복 실행을 소개하는 단계이며, 마지막에는 다음 기능을 설명하려다 대본이 끝난다.

📈 투자·시사 포인트

  • 에이전트 시스템의 가치를 평가할 때 모델 성능뿐 아니라, 사람이 매 단계 개입해야 하는지와 결과 검토만으로 운영할 수 있는지를 살펴볼 수 있다.
  • 영상이 강조하는 생산성 요소는 빠른 배치, 업무별 특화, UI와 도구의 대응 관계다. 같은 모델을 사용하더라도 주변 소프트웨어와 작업 환경의 설계가 중요하다는 시사점을 준다.
  • 모델 선택은 성능·비용·속도의 절충 문제로 제시된다. 반복 실행을 도입할 때도 실행 빈도와 필요한 도구를 함께 검토필요가 있다.
  • 장기 확장성을 희생한다는 전제가 있으므로, 짧은 시연의 편의성만으로 지속 가능한 운영 성과나 투자 수익성을 판단하기는 어렵다.

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

  • ‘현재 하는 일의 80% 이상을 사람 없이 실행할 수 있다’는 주장은 발표자의 설명이며, 업무 표본이나 측정 방법은 제시되지 않는다.
  • 상시 실행과 브라우저 종료 후 지속 동작을 설명하지만, 서버 장애·재시작·작업 실패 때 어떻게 복구하는지는 다루지 않는다.
  • 반복 작업을 ‘비용 없이’ 시작할 수 있다는 표현이 나오지만, 모델 호출과 실행 환경을 포함한 총운영비는 제시되지 않는다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 반복적으로 처리할 문제 하나를 고르고, 에이전트가 다룰 목록과 결과물의 형태를 정한다.
  • 사람이 직접 지시할 단계와 결과를 검토·승인할 단계를 나누어 니어 루프 운영 방식을 설계한다.
  • UI에서 가능한 작업이 에이전트 도구로도 제공되는지 확인하고, 자기 설정 변경의 허용 범위를 정한다.
  • 컨텍스트 압축, 모델, 프롬프트, 도구를 업무에 맞게 설정하고 성능·비용·속도의 절충을 확인한다.

❓ 열린 질문

  • 빠른 가치 창출을 위한 작은 공장이 어느 시점에 확장 가능한 구조로 전환되어야 하는가?
  • 사람의 피드백이 공장을 개선한다는 ‘데이터 플라이휠’은 구체적으로 무엇을 저장하고 어떻게 다음 실행에 반영하는가?
  • 에이전트가 자신의 도구와 설정을 변경할 때, 유용성과 통제를 함께 확보하는 경계는 어디인가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.