실제 앱을 출시하는 4단계 에이전틱 엔지니어링 워크플로

URL: https://www.youtube.com/watch?v=8rEAkEvhhcQ
날짜: 2026-10-11
채널: Peter Yang

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트에게 일을 통째로 맡기는 소프트웨어 팩토리 대신, 격리·구축·검증·반복 리뷰를 명시한 워크플로로 사람이 신뢰할 수 있는 실제 앱을 어떻게 출시할 것인가?==

• 잘못된 초기 가정 하나가 장시간의 에이전트 작업과 토큰을 모두 낭비할 수 있으므로 작업을 처음부터 격리해야 한다.
• 에이전트가 코드와 버그 수정 결과를 주장하는 데 그치지 않고, 실행 영상·전후 스크린샷·성능 수치·테스트 코드로 결과를 증명하게 해야 한다.
• PR 리뷰 점수와 미해결 댓글을 기준으로 자동 반복시키되, 실제 사용자가 쓰는 앱의 최종 판단은 사람이 직접 맡아야 한다.

마이클이 말하는 소프트웨어 팩토리는 특정 모델이나 하네스에 종속된 자동화 공장이 아니다. agent.md에 개인의 엔지니어링 원칙과 작업 순서를 기록하고, 코드 구조·새 기능·증거 기반 테스트·PR 리뷰 루프 같은 스킬을 조합해 반복 가능한 개발 시스템으로 만드는 방식이다. 모델이 좋아져도 개인의 취향, 도메인 지식, 검증 기준, 자원 제약은 남기 때문에 워크플로의 뼈대는 계속 유효하다.

1. 소프트웨어 팩토리의 정의와 설계 원칙

소프트웨어 팩토리는 에이전트에게 요청 한 번을 던지고 끝까지 방치하는 시스템이 아니라, 사람이 정한 엔지니어링 절차를 에이전트가 매번 따르게 하는 패키지다.

1.1. 모델보다 오래가는 패키지

1. 구성 요소의 결합

   1. 도메인 지식과 워크플로: 기술 지식, 제품 맥락, 개발 순서, 검증 기준을 agent.md, cloud.md, 스킬 파일에 함께 적는다.
   2. 모델·하네스 독립성: Astra, Fable, Codex, Cursor Cloud 등 어떤 모델이나 하네스를 쓰더라도 동일한 작업 원칙을 적용할 수 있게 만든다. 가장 좋은 모델을 쓰는 것은 유리하지만, 팩토리 자체가 특정 모델에만 의존해서는 안 된다.
   3. 코드베이스 설명의 최소화: 최신 모델은 도구로 저장소를 탐색할 수 있으므로 파일 구조를 장황하게 설명하기보다, 에이전트가 어떻게 일해야 하는지를 agent.md에 집중한다.

2. 초기 가정의 위험 관리

   1. 긴 자율 실행의 취약성: 게임을 밤새 만들도록 에이전트를 돌려도 시작 가정 하나가 틀리면 모든 결과가 무너지고 토큰만 소모된다.
   2. 사람의 개입: 마이클은 에이전트를 아직 완전히 신뢰하지 않는다. 소프트웨어 팩토리라는 이름과 달리 기능을 직접 실행하고 사용해 보며, 각 단계에서 증거를 확인한다.

1.2. agent.md에 기록한 네 단계

1. 격리(Isolate): 새 기능, 버그 수정, 탐색 작업을 시작하기 전에 메인 브랜치에서 독립 Git worktree를 만든다.
2. 구축(Build): 정해진 코드 구조 스킬을 호출해 서비스 계층 아키텍처에 맞춰 구현한다.
3. 검증(Validate/Prove): 버그가 실제로 재현되고 해결됐는지, 또는 새 기능이 기대대로 작동하는지 영상·스크린샷·수치로 증명한다.
4. 리뷰 루프(Review loop): PR에 남은 리뷰 피드백을 반영하고 다시 점검해 Griptile의 신뢰도 점수가 5점 만점에 도달할 때까지 반복한다.

2. 1단계 — 격리: 모든 작업을 독립 worktree에서 시작하기

새 작업은 메인 브랜치에 바로 쓰지 않고 독립된 Git worktree에서 시작해야 병렬 에이전트의 실험이 서로를 망가뜨리지 않는다.

2.1. 새 기능 스킬의 작동 방식

1. 작업 시작점 고정

   1. 요청 범위: “분석 기능을 만들어 달라”, “이메일 추적을 개선해 달라”, “맥에서 네트워크에 연결된 iMessage 서비스를 실행하게 해 달라”처럼 새 기능이나 버그 수정 요청이 들어오면 new feature 스킬을 호출한다.
   2. 저장소 동기화: 원본 저장소를 가져오고 최신 상태인지 확인한 다음 저장소 루트에서 새 worktree를 생성하고 생성 결과를 검증한다.
   3. 공유 자원 고지: worktree는 파일 작업을 분리하지만 개발 서버 포트와 데이터베이스 같은 공유 자원까지 격리하지는 않는다는 점을 에이전트에게 알려 준다.

2. 병렬 개발의 안전장치

   1. 메인 브랜치에서 분기: 모든 기능은 동일한 메인 브랜치에서 각각 갈라진다. 한 작업이 실패하거나 방향을 바꿔도 다른 작업의 파일을 덮어쓰지 않는다.
   2. 동시 탐색: Herder 터미널의 다섯 탭에서 Codex 에이전트를 동시에 실행했고, 네 개가 완료된 동안 한 개가 계속 진행 중인 상태를 보여 줬다.
   3. 기존 방식과의 차이: Ralph loop나 slash goal처럼 에이전트가 빈틈을 스스로 추측해 채우는 방식보다, 각 단계에서 호출해야 할 스킬을 미리 지정한다. 최신 모델은 좋은 추측을 하기도 하지만 완전히 틀린 추측도 할 수 있기 때문이다.

2.2. 격리 단계의 실무 한계

1. Git 사용 경험을 스킬로 보완

   1. 마이클은 AI를 쓰기 전 Git이 강점이 아니어서 Stack Overflow와 Google에서 rebase 방법을 찾아 해결하곤 했다.
   2. 이제 worktree 생성, 저장소 동기화, 위치 검증, 공유 자원 경고를 스킬에 적어 에이전트가 절차를 수행하게 한다.

2. 격리는 구현과 별개의 단계

   1. worktree를 만드는 일은 작업 공간을 분리하는 단계이며, 실제 코드 작성은 다음 Build 단계에서 시작한다.
   2. 개인 앱에서 빠르게 재미를 느끼는 것이 목적이라면 이 절차를 생략할 수 있지만, 타인이 사용할 제품과 여러 에이전트가 동시에 만지는 저장소에서는 격리가 신뢰의 출발점이다.

3. 2단계 — 구축: 서비스 계층 아키텍처로 코드를 작성하기

구축 단계는 에이전트가 그럴듯한 코드를 아무 곳에나 추가하는 단계가 아니라, 사람이 읽고 재사용할 수 있는 서비스 계층 패턴을 지키게 하는 단계다.

3.1. 오케스트레이션 계층과 서비스 계층

1. 오케스트레이션 계층

   1. 역할: “왜”, “언제”, “어떻게”를 조율하고 비즈니스 규칙, 상태 전환, 상태 머신, 점검과 서비스 호출을 담당한다.
   2. 액션과 경계: 샌드박스 생성 및 관리, 저장소 준비, 패키지 관리자 감지, 종속성 설치, 빌드 명령 실행, 샌드박스 런타임 시작처럼 작업의 흐름과 실행 조건을 표현한다.

2. 서비스 계층

   1. 재사용 함수: 명시적인 입력과 구조화된 반환값을 가진 재사용 가능한 함수를 관리한다. SDK도 이 계층에 둔다.
   2. 중복 방지: 에이전트가 동일한 함수를 여러 곳에 반복해서 만드는 습관을 줄인다.
   3. 가독성: 함수 이름만 읽어도 책임을 파악할 수 있다. 다른 개발자와 에이전트 모두 “샌드박스 관리 함수”가 무엇을 하는지 빠르게 이해할 수 있다.

3.2. 코드 구조 스킬을 만든 이유

1. 개인의 읽기 방식 보존

   1. 마이클이 2024년식으로 코드를 직접 읽고 수정해야 할 때에도 자신이 익숙한 방식으로 작성된 코드는 이해하기 쉽다.
   2. “서비스 계층 아키텍처에 따라 작성하라. 액션과 경계는 실행 시점과 이유를 오케스트레이션하고, 서비스 계층은 명시적 입력과 구조화된 반환으로 재사용 방법을 관리하라”는 지시를 Build 단계에 넣었다.

2. 에이전트에게도 일관된 지도 제공

   1. 구조가 고정되면 에이전트가 기존 코드를 탐색할 때 책임과 호출 관계를 빠르게 찾는다.
   2. 아키텍처 취향에 대한 개발자 간 논쟁은 있을 수 있지만, 중복을 막고 장기 유지보수를 돕는다는 점이 마이클에게는 핵심 가치다.

4. 3단계 — 검증: 결과를 증거로 남기기

에이전트가 “수정했다”고 말하는 것만으로는 충분하지 않다. 버그가 실제 버그였는지, 수정 뒤 동작이 개선됐는지를 사람이 확인할 수 있는 자료로 남겨야 한다.

4.1. 증거 기반 테스트

1. 버그의 존재 증명

   1. 제품 담당자가 “버그를 발견했다”는 일반 티켓을 등록하면, 에이전트는 먼저 사용자 오류인지 시스템 오류인지 구분하기 위해 버그를 재현한다.
   2. 실제 버그라면 수정 전 상태를 기록한다. 예를 들어 메시지를 보낸 뒤 앱을 새로 고칠 때 스트리밍이 깨지는 문제를 재현하고 동작을 녹화한다.

2. 수정 결과의 증명

   1. Cursor Cloud 또는 Devin Cloud 에이전트가 Linux 머신에서 버그가 발생하지 않는 상태를 다시 실행하고, 수정 전후의 증거를 만든다.
   2. FFmpeg가 설치된 Linux 머신에서 동작하는 스크립트들이 실행 전후 화면을 캡처한다. FFmpeg는 비디오 녹화 프로그램처럼 동작하며, macOS와 Linux에서 테스트했고 Windows는 별도 검증하지 않았다.
   3. 버그가 재현되지 않으면 기록할 “이전” 상태가 없으므로 수정 후 상태만 남긴다. 따라서 증거 기반 테스트는 운영 중인 앱에 실제 버그 신고가 들어왔을 때 특히 유용하다.

4.2. 전후 비교 스킬

1. UI 변화의 시각화

   1. Vercel 팀에서 가져온 전후 비교 스킬은 기능을 만들기 전과 만든 후의 스크린샷을 찍는다.
   2. 이메일 전송 추적 기능처럼 UI 변화가 있는 경우 기존 메일함과 변경 후 화면을 나란히 보며 무엇이 달라졌는지 확인한다.

2. UI가 아닌 개선의 수치화

   1. 스크린샷으로 표현할 화면이 없으면 성능 수치를 전후로 기록한다.
   2. GPT-5.6으로 만든 대시보드의 탐색 속도를 Astra에게 개선시키자 한 측정값은 850ms에서 60ms로, 다른 측정값은 817ms에서 61ms로 줄었다.
   3. 이런 자료는 에이전트가 만든 해결책이 실제로 나아졌는지 판단하게 한다. 전후 비교 뒤 “변경이 별로 좋지 않다”고 스스로 판정하고 계속 고치는 에이전트도 있어, 검증 자료가 추가 작업을 유도하는 안전장치가 된다.

4.3. 사람의 수동 검토를 마지막에 배치하기

1. 검토 전 증거 수집

   1. 증거 기반 테스트, 전후 비교, Grep Loop의 목적은 신뢰를 만들고 수동 검토 시간을 줄이는 것이다.
   2. 에이전트가 완료 주장과 함께 실행 영상, 전후 스크린샷, 통계, 테스트 코드, 재현 가능한 결과를 제출하면 개발자는 전체 구현을 처음부터 다시 검증하는 부담을 덜 수 있다.

2. 사람이 직접 기능을 사용하기

   1. 마이클은 기능을 하나씩 추가해 나중에 깨진 기능 열 개를 발견하는 방식으로 일하지 않는다.
   2. 본인이 직접 앱을 사용해 보고, 실제 사용자의 입장에서 품질을 판단한다. 소프트웨어 팩토리라는 이름이 사람을 제거한다는 뜻은 아니다.

5. 4단계 — Grep Loop: PR 리뷰 점수로 반복 개선하기

Grep Loop는 Griptile이 남긴 리뷰를 읽고 코드와 PR을 반복 수정해 5점짜리 PR을 만드는 자동 루프다.

5.1. Griptile 리뷰의 입력과 출력

1. 점수와 댓글

   1. PR을 제출하면 Griptile은 요약, 신뢰도 점수, 실행 가능한 피드백을 돌려준다.
   2. 최첨단 모델이 만든 첫 PR도 보통 5점 만점에 4점을 받고, 가끔 3점을 받는다. “현금 지원을 가정하지 마라”처럼 P1 수준의 중요한 댓글과 근거 자료가 함께 나올 수 있다.

2. 자동 개선 순환

   1. 5점 미만이면 리뷰를 다시 트리거하고, 조치 가능한 댓글을 수정하고, 변경 사항을 push한 뒤 재검토를 기다린다.
   2. 5점 만점에 5점이고 미해결 댓글이 없을 때 루프가 멈춘다. 기본 버전은 다섯 번 반복하고, 마이클의 버전은 열 번 반복하도록 설정했다.
   3. 리뷰 결과가 3점이면 에이전트는 Build 단계로 돌아가 피드백을 반영하고 코드를 수정한 뒤 다시 push한다. 최종 응답에는 “PR 155 업데이트됨”, 문서 검사 통과, Griptile이 10분을 기다린 뒤에도 보류 중이라는 상태 같은 정보가 포함될 수 있다.

5.2. 함께 쓰는 스킬과 적용 범위

1. 공개 스킬 조합

   1. Grep Loop와 Griptile 관련 스킬은 오픈 소스이며 무료이고, 마이클의 저장소에 공개되어 있다.
   2. 마이클이 직접 만든 핵심 스킬은 새 기능, 코드 구조, 증거 기반 테스트다.
   3. Unslop은 PR의 문제를 정리하는 스킬이다. 모든 작업에서 반드시 실행하지 않고 건너뛸 때도 있지만, 핵심 격리·구축·검증·리뷰 순서는 유지한다.

2. 루프를 써야 하는 경우

   1. 수천 줄짜리 PR이나 다른 사람이 실제로 사용할 제품은 리뷰 기준을 반복 통과시키는 것이 중요하다.
   2. 이미지 공유 서비스나 Still처럼 본인만 쓰는 작은 앱은 코드 품질이나 Griptile 점수보다 “스크린샷을 복사해 올렸을 때 제대로 작동하는가”가 중요하므로 전체 루프가 과하다.

6. 사람이 통제하는 운영 방식

자동화의 중심에는 빠른 에이전트가 있지만, 어떤 기능을 만들지 결정하고 실제 동작을 확인하는 책임은 사람에게 남는다.

6.1. 혼자 만드는 앱과 고객 프로젝트의 차이

1. 개인·출시 앱

   1. 개인 프로젝트와 자신이 출시하는 앱은 마이클이 설계·구현·테스트 전 과정을 혼자 맡는다.
   2. 이미지 공유 서비스와 Still은 코드 구조를 세세히 읽지 않아도 원하는 동작을 하면 충분한 사례다. 반대로 타인이 쓰는 도구는 실패 비용이 커서 검증 워크플로가 필수다.

2. 컨설팅 프로젝트

   1. 마이클은 온라인에서 자주 말하지 않지만 컨설팅 회사를 운영하며 다양한 규모의 회사를 위해 앱과 에이전트를 만든다.
   2. 고객 프로젝트에는 책임과 코드 구조의 일관성이 필요하다. 마이클이 모든 코드를 직접 리뷰하지는 않고 팀의 개발자들이 코드 리뷰를 담당한다.

6.2. 터미널, GUI, 원격 인프라의 분업

1. 작업 성격별 인터페이스

   1. Bezel처럼 백엔드 비중이 높은 앱은 강력한 Linux 서버에 연결된 터미널에서 작업한다.
   2. 시각적 UI 작업은 Mac과 동기화된 Codex 앱과 GUI를 사용한다. 브라우저 기반 컴퓨터 사용과 녹화 기능이 있는 환경에서는 증거 기반 테스트가 더 강력해진다.

2. 일하는 장소의 변화

   1. 에이전트 시스템 덕분에 사무실에 가지 않고 휴대폰으로 작업을 처리할 수 있게 됐다.
   2. Codex의 원격 제어 기능을 알고 있지만, 새 모델이 나올 때마다 Fable 등 여러 모델을 직접 써 보고 현재 최선의 조합을 확인한다.

6.3. 수동 실행과 자동 실행의 경계

1. Astra의 불규칙한 자율성

   1. Astra 5.1과 5.6은 명시적으로 시키지 않아도 다음 단계를 자동으로 실행할 때가 있지만, 가끔 “PR에 Griptile 피드백이 있는데 Grep Loop를 실행하지 않았다”고 상기시켜야 한다.
   2. 에이전트가 “깜빡했다”고 인정하고 루프를 실행하기도 하며, 5.1과 GPT-5.6 이후에는 기능 설명을 마치자마자 테스트할 PR을 받는 흐름이 더 자주 나타났다.

2. Astra와 Codex의 한계

   1. Astra는 컴퓨터 사용과 성능·보안 점검에서 인상적이지만, 지시를 따르지 않거나 수동으로 계속하라고 재촉해야 할 때가 있다.
   2. Codex는 똑똑하지만 작업을 시작했다고 말한 뒤 완전히 끝내지 않을 때가 있어 “계속해”라는 확신을 줘야 한다. 따라서 모델이 스킬을 제대로 따르는지 별도로 확인해야 한다.

7. 대화 자체를 계획 문서로 사용하는 방식

명시적인 PRD를 먼저 작성하는 대신, 마이클은 음성 대화로 생각을 풀어내고 중요한 결론만 저장소 안의 문서로 굳힌다.

7.1. WhisperFlow와 장시간 음성 브레인스토밍

1. 말해야 직관이 생기는 사고 방식

   1. 마이클은 개인 메모, 훈련, 공부, 독서도 소리 내어 해야 직감이 나온다.
   2. Mac에서 WhisperFlow를 켜고 FN 키를 누른 채 에이전트와 5~10분 동안 생각을 쏟아낸다. WhisperFlow는 불필요한 말을 지우고 문장을 정리해 Slack 답장, 뉴스레터, 제품 사양서에도 쓸 수 있다.

2. 대화가 사양이 되는 과정

   1. Bezel의 이메일 서비스 무료 티어를 다 써서 비용이 부담스러워진 상황에서 에이전트와 27~30분 동안 대화했다.
   2. Cloudflare 이메일 문서를 함께 찾아 읽은 끝에 필요한 기능이 사용자 지정 도메인과 추적 기능이라는 결론에 도달했다.
   3. Codex의 툴 호출과 질의응답을 이용해 작은 아이디어를 계속 주고받으면서 요구사항을 좁힌다. 사전에 완성된 사양서를 제출하고 “그대로 구축하라”고 하는 방식과 다르다.

7.2. 대화를 저장소의 장기 기억으로 바꾸기

1. setup.md의 역할

   1. Mac에서 iMessage에 연결하는 유료 서비스가 비싸서 직접 만들자는 대화를 나눈 뒤, 당장 설치하지 않고 iMessage/setup.md 파일에 설치와 설정 계획을 저장했다.
   2. 나중에 “이것을 어떻게 설정하지?”라고 물으면 에이전트가 저장된 계획을 읽고 정확한 절차를 복원할 수 있다.

2. 휘발성 대화와 지속성 문서의 분리

   1. 바로 구현할 내용은 대화 맥락에서 처리한다.
   2. 나중에 다시 참고하거나 에이전트가 반드시 기억해야 할 정보는 코드베이스 안에 파일로 만든다. 기억력이 약한 사람에게도, 다음 에이전트에게도 저장소 문서가 외부 기억 장치가 된다.

8. 모델 선택: 모든 작업에 최첨단 모델을 쓰지 않기

모델은 작업 성격에 따라 배치해야 하며, 가장 비싼 모델을 모든 요청에 투입하면 오히려 복잡성·시간·토큰 낭비가 커진다.

8.1. Astra와 Fable의 역할 분담

1. Astra의 강점

   1. Next.js, SvelteKit, React 같은 최신 프레임워크에서 내비게이션, 로딩, 캐싱, 프리페칭 개선점을 거의 10번 중 9번 찾아낸다.
   2. 성능 업데이트와 보안 감사, 브라우저·컴퓨터 사용 능력이 뛰어나다. 기존 앱도 성능 감사를 돌리고 클릭 때마다 로딩되는 부분, 캐싱과 사전 로딩의 기회를 점검할 만하다.
   3. Astra는 컴퓨터 사용을 넘어 하드웨어 운용 측면에서도 강력하며, 마이클은 Astra와 Blender를 활용하려고 장비를 추가로 마련했다.

2. Fable의 강점

   1. UI를 참고 자료 없이도 더 자연스럽게 만들고, 코드 작성에서는 Astra보다 PR이 병합될 가능성이 높다고 평가한다.
   2. 참고 이미지가 있으면 Astra의 UI도 좋아진다. Bezel UI에 Windows 95/XP 네트워크 로고를 참고 자료로 주자 그 분위기를 잘 살렸다.
   3. 참고 자료가 없으면 Astra 결과물에서 작은 대문자 헤더, 과장된 버튼, 무작위 복사처럼 OpenAI 특유의 스타일이 드러날 수 있어 UI는 Fable을 선호한다.

3. 보안 감사의 실제 가치

   1. 마이클은 캐나다의 높은 결제 서비스 수수료를 줄이려고 교회용 결제 시스템을 직접 만들었고, 다른 교회에도 무료로 제공할 계획이다.
   2. Astra의 보안 감사는 영수증 처리 방식의 문제를 찾아냈다. 네트워크 탭을 읽을 줄 아는 사용자가 악용했다면 돈이 오가는 시스템에 심각한 보안 사고가 될 수 있는 취약점이었다.
   3. 실제 사용자가 있고 금전이 흐르는 앱은 반드시 보안 감사를 받아야 한다.

8.2. 작고 싼 모델과 모델 라우터

1. 작업별 모델 배치

   1. GPT 5.6 Sol은 컴퓨터 사용과 일상적인 중간 난이도 업무에 충분히 신뢰할 만하다.
   2. Luna는 저렴하면서 지식 노동에 강하다. 공동 세금 신고를 위해 결혼 후 1년 반 동안의 수많은 숫자와 비용을 정리할 때 빠르게 계산했고, Sol을 서브에이전트로 두어 진행 상황을 추적했다.
   3. 단순 PR 배포에 Astra Ultra를 쓰면 문제를 과도하게 복잡하게 보고 시간이 오래 걸리며 토큰을 낭비할 수 있다.

2. 앞으로의 라우팅

   1. 모든 일에 최첨단 모델을 쓸 필요가 없으며, 작은 모델도 빠르게 좋아지고 있다. Grok 4.6도 좋은 사례다.
   2. 비싼 모델은 오케스트레이션과 리뷰처럼 판단 비용이 높은 곳에 배치하고, 단순 작업은 저렴한 모델로 라우팅하는 구조가 앞으로 몇 주 안에 더 중요해질 것으로 본다.
   3. 예산이 충분하면 Fable 5.1도 여전히 가치가 있다. Astra가 전반적으로 더 뛰어나도 프로그래밍 결과와 코드 품질에서는 Fable을 유지할 이유가 있다.

9. 홈랩, 보안 크론, 자원 관리

에이전트 워크플로를 개인 컴퓨터 한 대에 가두지 않고 Linux와 Mac을 연결한 홈랩으로 확장하되, 자동화가 만든 자원 문제도 정기적으로 관리해야 한다.

9.1. 정기 보안 점검

1. 에이전트 워크스페이스

   1. 마이클은 Linux 컴퓨터와 Mac 컴퓨터를 보유하고 있으며 앞으로 더 구입할 계획이다.
   2. Cursor Cloud 에이전트를 클라이언트 앱, 특히 특정 정부 기관과 협력하는 높은 보안 기준의 프로젝트에 사용한다.

2. 크론 실행

   1. 매일 정해진 시간에 Cursor Cloud 에이전트가 보안 문제를 점검하도록 예약 작업을 설정했다.
   2. 프로덕션 앱이라면 최소한 간단한 보안 감사라도 정기적으로 실행해야 한다. 오래된 컴퓨터가 있다면 연결해 Codex를 돌리는 것도 권장한다.

9.2. 자동화가 만든 운영 부채

1. 분산된 크론과 대시보드

   1. 피터는 메인 노트북, Mac mini, 클라우드 저장소를 쓰면서 크론 작업이 세 군데에 흩어져 무엇이 실행되는지 파악하기 어려운 상황을 설명했다.
   2. 모든 작업을 통합하고 추적할 수 있는 대시보드를 만드는 방향이 필요하다.

2. worktree 폭증

   1. 고사양 Linux 서버에서 “메모리가 거의 부족하다”는 메시지가 발생했다.
   2. Codex가 조사하자 worktree가 3,000개 이상 쌓였고 여러 프로그램과 종속성이 함께 실행 중이었다.
   3. 에이전트에게 정리 작업을 맡길 수 있지만, worktree·프로세스·종속성을 주기적으로 청소하는 크론과 가시화 대시보드가 소프트웨어 팩토리의 필수 운영 요소가 된다.

10. 모델이 진화해도 남는 것과 사라질 것

모델이 좋아지면 도구 사용법을 설명하는 스킬은 줄어들 수 있지만, 개인의 작업 방식과 품질 기준을 보존하는 스킬은 오래 남는다.

10.1. 새 모델을 검증하는 순서

1. 깨끗한 상태에서 테스트

   1. 새 모델이 출시될 때마다 기존 에이전트와 스킬을 바로 붙이지 않고, 아무것도 없는 상태에서 모델 자체가 어떻게 작동하는지 확인한다.
   2. 코드 구조를 더 우아하게 만들 수 있는 모델이라도 프로젝트의 기존 구조를 깨뜨릴 수 있으므로, 새 모델의 장점과 팩토리의 규칙이 충돌하는지 본다.

2. 검증 뒤 통합

   1. 모델이 충분히 안정되면 워크플로와 하네스에 통합한다.
   2. 미래에는 하네스가 더 나은 엔지니어링 관행을 자동으로 포함하고 불필요한 스킬을 제거할 수 있지만, 현재는 명시적인 네 단계가 잘 작동한다.

10.2. 개인화와 현실적인 자원 제약

1. 개인 선호의 내구성

   1. 모든 사람에게 동일하게 최적인 모델이 존재하지 않는 한, 각자의 전문 지식과 선호도에 맞춘 스킬은 사라지지 않는다.
   2. 모델이 이미 아는 API 설명은 줄어들 수 있지만, 개인이 어떤 구조를 좋아하고 어떤 방식으로 검증하며 어떤 결과를 배포하는지는 여전히 개인화된 지식이다.

2. 연구실의 모범 사례를 그대로 복사하지 않기

   1. 연구실 엔지니어는 토큰과 컴퓨팅 자원이 사실상 무제한인 환경에서 반복 루프를 돌릴 수 있지만, 일반 사용자는 하루 종일 루프를 실행할 수 없다.
   2. 과거 회사에서는 고성능 MacBook에서만 테스트하면 모든 것이 빠르게 보이는 문제를 피하려고 사무실에 구형 노트북을 두고 기능을 테스트했다. 대부분의 사용자는 최신 장비를 갖고 있지 않기 때문이다.
   3. 오픈 소스 창업자와 AI 연구소의 조언은 유용하지만, 기업은 고객이 더 많은 비용을 쓰길 원한다는 이해관계도 있다. 따라서 오픈 소스·오픈 웨이트 모델, 특히 로컬 컴퓨터에서 실행 가능한 모델을 함께 확보해야 한다.

주요 발언 모음

“처음에 잘못된 가정 하나만 해도 모든 게 망가진다.”

“에이전트에게 각 단계에서 어떤 스킬을 사용해야 하는지 알려주는 워크플로를 사용한다.”

“새로운 작업 트리를 분리하고, 특정 기준에 맞춰 코드를 작성하고, 버그가 존재한다는 것을 증명한다.”

“에이전트가 자신이 만든 해결책이 제대로 작동한다는 것을 증명하도록 강제하는 효과가 있다.”

“대화 기록 자체가 사양이다.”

“모든 것에 최첨단 기술을 사용할 필요는 없다.”

“프로덕션 앱이라면 간단한 보안 감사라도 꼭 해야 한다.”

“모델은 좋아져도 제가 일하는 방식에 가까운 소프트웨어 팩토리는 계속 존재할 것이다.”

핵심 데이터 & 수치

• 영상 길이: 약 47분.
• 채널 규모: Peter Yang은 AI 코딩을 가르치는 10만 명 규모의 유튜브 채널로 마이클을 소개했다.
• 첫 PR 점수: Astra·Fable 같은 최첨단 모델도 첫 PR에서 대체로 5점 만점에 4점, 가끔 3점을 받는다.
• Grep Loop 반복 횟수: 기본 버전은 최대 5회, 마이클의 버전은 최대 10회 반복한다. 5점 만점에 5점을 받으면 더 일찍 멈춘다.
• 성능 개선 사례 1: 대시보드 탐색 속도가 850ms에서 60ms로 줄었다.
• 성능 개선 사례 2: 다른 측정값이 817ms에서 61ms로 줄었다.
• 계획 대화 시간: 일반적인 계획은 음성으로 5~10분 동안 풀어내며, Cloudflare 이메일·사용자 지정 도메인·추적 기능 사례는 약 27~30분 대화했다.
• worktree 운영 부채: Linux 서버에서 worktree가 3,000개 이상 누적되어 메모리 부족 문제가 발생했다.
• 보안 점검 빈도: 정부 기관 관련 클라이언트 앱은 Cursor Cloud 에이전트가 매일 특정 시간에 점검한다.
• WhisperFlow 절약 효과: Peter는 WhisperFlow가 매주 최소 3시간을 절약해 준다고 설명했다.
• 결혼 후 기간: 공동 세금 신고를 위해 결혼 후 약 1년 반 동안의 비용과 숫자를 정리했다.

결론 및 시사점

1. 에이전트 개발의 핵심은 자율성을 최대화하는 것이 아니라, 잘못된 가정이 넓게 퍼지기 전에 격리하는 것이다.
2. 새 기능과 버그 수정은 독립 worktree에서 시작해 병렬 실행의 충돌을 줄인다.
3. 코드 구조 스킬은 오케스트레이션 계층과 서비스 계층을 분리해 에이전트의 중복 구현과 사람의 이해 비용을 낮춘다.
4. 버그는 존재 자체를 재현하고 수정 결과까지 증명해야 하며, 실행 영상·스크린샷·성능 수치·테스트 코드를 증거로 남긴다.
5. Griptile 기반 Grep Loop는 5점 만점의 리뷰 결과를 얻을 때까지 댓글 수정과 재검토를 반복한다.
6. 증거 수집은 수동 검토를 없애는 장치가 아니라, 사람이 최종 판단에 쓸 시간을 줄이는 장치다.
7. 개인용 장난감 앱은 속도와 재미를 위해 엄격한 PR 절차를 생략할 수 있지만, 타인이 쓰거나 돈이 오가는 앱은 동일한 기준으로 다루면 안 된다.
8. 음성 대화는 생각을 탐색하는 사양 작성법이 될 수 있고, 장기 기억이 필요한 결론은 setup.md 같은 저장소 문서로 굳혀야 한다.
9. Astra·Fable·Sol·Luna처럼 모델을 작업별로 라우팅하면 비용과 속도를 함께 관리할 수 있다.
10. 프로덕션 앱에는 정기 보안 감사와 자원 정리 크론이 필요하며, 3,000개 worktree 같은 운영 부채를 대시보드로 드러내야 한다.
11. 새 모델은 기존 스킬을 붙이기 전에 깨끗한 상태에서 평가한 뒤 소프트웨어 팩토리에 통합해야 한다.
12. 연구실의 무제한 토큰 환경을 일반 개발자의 기준으로 삼지 말고, 구형 장비와 실제 예산을 반영해 검증해야 한다.
13. 궁극적으로 내구성이 높은 자동화는 모델 이름이 아니라 개인의 엔지니어링 선호, 도메인 지식, 검증 습관을 보존하는 시스템이다.