Still Prompting Claude Code Back and Forth? Think Software Factory

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Code와 프롬프트를 주고받는 반복 작업을 줄이려면, 에이전트가 제안하고 코드가 검증하는 재사용 가능한 소프트웨어 팩토리를 구축해야 한다.

📌 핵심 요점

1. 자동화의 단위는 개별 프롬프트에서 개발 생애주기 전체로 넓어진다. 요청부터 계획·구현·테스트·수정·리뷰·문서화·커밋까지 연결하고, 각 단계의 진입·종료 조건과 사람·에이전트·코드의 책임을 구분한다.
2. 핵심 원칙은 ‘에이전트가 제안하고 코드가 판정한다’는 것이다. 에이전트는 판단이 필요한 작업을 맡고, 코드는 입력 검증과 결정적인 절차를 수행하며 워크플로를 통제한다.
3. 역할별 설정이 실행 품질을 좌우한다. 컨텍스트·모델·프롬프트·도구를 중심으로 플래너와 빌더 등의 목적과 실행 환경을 구성하고, 필요한 역할에 적절한 모델을 배치한다.
4. 팩토리의 가치는 한 번의 기능 구현보다 이후 실행의 반복 가능성에 있다. 단계별 비용과 설정을 확인하고, 중단된 실행을 세션 ID로 재개하며, 실행·설치 스킬로 다른 코드베이스에 작업 방식을 재사용한다.
5. 소유해야 할 자산은 특정 모델보다 자신의 스튜디오다. 도구를 교체하더라도 업무 흐름·지식·검증 기준·제품 판단을 유지하고, 에이전트에는 경계가 분명한 작업을 맡긴다는 구상이다.

🧩 배경과 문제 정의

영상은 에이전트가 수행할 수 있는 일에도 사람이 하루 종일 프롬프트를 주고받는 상황을 문제로 제기한다. 제안하는 해법은 개별 작업을 요청하는 방식을 넘어, 개발 생애주기를 실행하고 검증하는 ‘소프트웨어 팩토리’를 만드는 것이다.

발표자 Daniel은 iOS 개발 경험을 바탕으로 디자인·코드·출시·마케팅에 에이전트를 활용하는 AI 네이티브 스튜디오를 소개한다. 목표는 매주 자신의 개입을 조금씩 줄이는 것이다. 구체적인 시연 과제는 SwiftUI 글쓰기 앱에 마크다운 미리보기와 작성·미리보기 전환 기능을 테스트와 함께 추가하는 작업이다.

후반부는 이 운영 방식을 Crafter’s Lab의 프로젝트 자료, 지식 저장소, 스킬과 커뮤니티로 확장해 설명한다. 전체를 관통하는 질문은 ‘에이전트에게 가르칠 수 있는 일을 사람이 계속 직접 수행해야 하는가’이며, 해법의 전제는 시스템의 작동 원리를 충분히 이해하는 것이다.

🕒 시간순 섹션별 상세정리

1. 반복 프롬프팅에서 개발 생애주기 자동화로

• 사람이 직접 처리하는 반복 작업을 에이전트에게 가르칠 수 있다면, 이를 실행하는 팩토리를 만들자는 문제의식으로 시작한다. 목표는 시스템을 충분히 이해해 일일이 들여다볼 필요를 줄이는 것이다. [00:16]
• SwiftUI 글쓰기 앱에 마크다운 미리보기와 작성·미리보기 전환, 테스트를 요청한다. 이번 실행에는 frontier 구성을 지정하고, 에이전트가 시스템과 설정을 조사한 뒤 플래너를 시작한다. [01:13]
• 하나의 스킬을 중심으로 에이전트가 제안하고 코드가 검증·통제한다. 요청→계획→계획 커밋→구현→테스트·수정→리뷰·재수정→문서화·커밋의 단계마다 진입·종료 조건과 실행 주체를 구분한다. [02:23]

2. 역할별 설정과 단순한 실행 구조

• Daniel은 10년 넘는 iOS 개발 경험과 AI 네이티브 스튜디오 구상을 보여준다. 디자인·코드·출시·마케팅에 에이전트를 배치하고, 자신의 개입을 매주 줄여가는 과정을 Crafter’s Lab에서 공유한다고 보여준다. [03:10]
• 에이전트 설정의 핵심은 컨텍스트·모델·프롬프트·도구다. 플래너와 빌더에 서로 다른 목적과 실행 환경을 부여하고, 플래너와 스카우트는 필요할 때 하위 에이전트를 생성할 수 있다. [03:45]
• 워크플로는 입력을 검증하고 정확한 매개변수로 에이전트를 실행하도록 단순하게 구성한다. 별도 언어를 만들기보다 코드·설정 파일·에이전트·스킬을 사용해 모델이 익숙한 방식으로 시스템을 다룰 수 있게 한다. [04:16]

3. 실행 관찰과 검증, 시연의 한계

• 실행 결과에는 단계별 비용, 에이전트 설정, 계획·구현·리뷰 내역이 남고, 중단된 실행은 세션 ID로 재개할 수 있다고 보여준다. 시연은 메인 브랜치에서 동작하며, 실제 작업에는 샌드박스와 별도 브랜치, 격리된 실행, 최종 병합이 필요하다고 드러낸다. [04:45]
• 구현 직후 테스트를 실행해 실패를 에이전트에게 돌려보내고, 리뷰는 결과물이 요청한 기능인지 확인한다. 변경 사항은 커밋과 diff, 문서로 남겨 다음 개발자나 에이전트가 이어받도록 한다. [05:06]
• 모든 작업에 최상위 모델을 쓰기보다 반복 실행에서 필요한 구성을 찾는 것이 중요하다고 주장한다. 시뮬레이터에서는 굵은 글씨·글머리표·목록·헤더의 마크다운 렌더링을 확인한다. [05:42]

4. 복잡도에 따른 필요성과 재사용 설계

• 발표자는 시연 기능을 단일 에이전트가 처리할 수 있다는 반론을 인정한다. 다만 앱이 커지고 복잡해지면 검증이 중요해지고, 이를 에이전트에게 모두 맡기면 시간이나 비용을 지불하게 된다고 주장한다. [06:13]
• 팩토리는 작은 단위로 조합할 수 있게 설계하며, 실행용 스킬과 새 코드베이스에 설치하는 스킬을 통해 다른 앱에도 재사용한다. 스킬은 중심 개념과 필요할 때만 읽는 작업별 안내로 구성한다. [06:49]
• 에이전트가 요청에 필요한 내용만 읽고 작업하도록 접근 경로를 마련한다. 기본 템플릿의 테스트와 계획 수준은 자신의 앱에 맞춰 바꿔야 하며, 프롬프트의 효과는 개발 워크플로에 투입한 시간과 노력에 달려 있다고 보여준다. [07:24]

5. 사람이 소유하는 스튜디오와 적절한 업무 배치

• 반복적인 엔지니어링 작업을 안정적으로 넘기기 위해 팩토리 구축, 클라우드 실행, 샌드박스 구성을 촉구한다. 사람은 에이전트가 혼자 해결하기 어려운 새로운 문제에 집중해야 한다는 주장이다. [08:11]
• 전체 생애주기 실행, 코드에 의한 검증, 에이전트별 단일 목적을 다시 강조한다. 시스템을 모르면서 확인하지 않는 방식과, 시스템을 충분히 이해해 확인 부담을 줄이는 에이전틱 엔지니어링을 구분한다. [08:48]
• 모델과 도구는 교체할 수 있어도 자신의 스튜디오와 제품 판단은 유지한다는 관점을 제시한다. Claude Code·Codex·Cursor를 예로 들며, 에이전트에는 범위가 정해진 작업을 맡기고 코드가 검증을 수행하도록 적절히 배치해야 한다고 정리한다. [09:26]

6. 프로젝트·커뮤니티·지식이 연결되는 운영 구조

• Crafter’s Lab에서는 실제 운영에서 잘된 점과 실패한 점, 적용할 만한 스킬과 지침을 공유한다고 보여준다. 범위는 코드부터 제품 마케팅과 스튜디오 운영까지 이어지며, 실제 업무와 리뷰를 수행하는 개인 개발자를 대상으로 한다. [09:59]
• 영상 댓글의 논의는 Slack으로 이어지고, Notion에는 스튜디오의 공유 공간이 마련돼 있다고 보여준다. Foundry는 실제 프로젝트의 브리프·작업·피드백·출시 과정에서 컨텍스트가 이어지는 모습을 볼 수 있는 업무 계층이다. [10:53]
• 전체 공간을 막연히 탐색하기보다 프로젝트 하나를 끝까지 따라가라고 권한다. Swift Brain은 Swift·SwiftUI 지식을 세션 사이에 보존하는 계층이며, Apple 참고 자료·패턴·기술 스킬과 Apple UI Brain의 화면·인터페이스 자료를 포함한다. [11:27]

7. 필요한 지식과 도구만 연결하는 나만의 팩토리

• 존재하지 않는 SwiftUI 기능을 에이전트가 만들어내는 문제를 예로 들며 컨텍스트의 중요성을 강조한다. 필요한 데이터베이스만 복제해 자신의 사본으로 유지하고, 링크와 MCP를 통해 에이전트가 해당 자료를 검색하도록 하는 방식을 보여준다. [12:00]
• Ops Lab은 지침·스킬·설계 자료를 제공하는 전문 역할 계층이다. 먼저 할 일을 정하고 지침을 세운 뒤 필요한 스킬과 도구만 연결하며, 제공 자료를 자신의 환경에 맞게 조정해 유용한 구성만 남기라고 보여준다. [12:27]
• 대상은 이미 제품을 출시하며 더 체계적인 AI 개발 방식을 원하는 개발자라고 드러낸다. 각자가 자신의 판단이 담긴 스튜디오를 소유하고, 팩토리를 구축해 시스템을 충분히 이해하자는 메시지로 마무리한다. [12:52]

🧾 결론

• 시연에서는 SwiftUI 글쓰기 앱에 마크다운 미리보기를 추가하고 시뮬레이터에서 렌더링을 확인한다. 발표자도 이 기능 하나는 단일 에이전트로 처리할 수 있다고 인정한다.
• 복잡한 앱과 반복되는 실제 개발을 고려하면, 단계별 검증과 실패 피드백을 시스템으로 만드는 것이 중요하다는 주장이다. 다만 어느 규모부터 구축 비용을 회수하는지는 제시하지 않는다.
• 템플릿은 출발점이다. 앱에 맞는 테스트와 계획 품질, 역할별 설정을 직접 다듬어야 하며, 시스템을 이해할수록 반복적인 수동 개입을 줄일 수 있다는 것이 최종 메시지다.

📈 투자·시사 포인트

• 개발 도구를 평가할 때 모델 성능과 함께 검증 자동화, 실행 기록, 역할별 설정, 재사용성을 살펴볼 수 있다. 영상은 이런 운영 구조를 반복 실행의 기반으로 제시한다.
• 자동화에 투입할 시간과 비용은 단계별 비용, 실패 후 수정 부담, 사람의 개입량을 함께 확인하며 판단필요가 있다. 영상에는 비용 내역 기능이 등장하지만 실제 절감 수치는 없다.
• 도구 교체 가능성을 확보하고 자체 지식과 작업 기준을 축적하는 전략이 강조된다. ‘모델은 빌리지만 스튜디오는 소유한다’는 관점이 핵심이다.
• 이 영상은 개발 운영 방식과 Crafter’s Lab을 소개하는 콘텐츠다. 특정 기업이나 금융자산의 투자 수익을 판단할 근거는 제공하지 않는다.

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

• 생산성 향상, 토큰 절감, 오류 감소를 입증하는 비교 실험이나 수치는 제시되지 않는다. ‘팩토리를 운영하지 않으면 뒤처진다’는 표현은 발표자의 전망으로 구분해야 한다.
• 시연은 메인 브랜치에서 실행된다. 발표자는 실제 작업에 필요한 별도 브랜치·샌드박스·실행 격리·최종 병합 단계가 빠져 있다고 명시한다.
• 테스트와 리뷰 절차는 설명하지만 테스트 전체 내용, 커버리지, 장기 운영에서의 실패율은 확인할 수 없다. 미리보기 작동 확인만으로 전체 시스템의 신뢰성을 판단하기는 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복해서 프롬프트를 주고받는 개발 작업 하나를 골라 요청·계획·구현·테스트·리뷰·문서화 단계로 나누고, 각 단계의 책임과 완료 조건을 적는다.
• 플래너와 빌더 등 필요한 역할부터 정의하고, 역할별 컨텍스트·모델·프롬프트·도구 설정을 명시한다.
• 빌드 직후 테스트를 실행하고 실패 내용을 수정 작업으로 전달하며, 리뷰에서는 구현 결과가 원래 요청을 충족하는지 확인한다.
• 실제 프로젝트에 적용하기 전에 별도 브랜치와 샌드박스, 실행 격리, 최종 병합 절차를 마련한다.

❓ 열린 질문

• 단일 에이전트로 충분한 작업과 다단계 팩토리가 필요한 작업을 나누는 실용적인 기준은 무엇인가?
• 자동화 구축·유지 비용을 포함했을 때, 어느 정도의 반복 실행부터 시간과 비용의 이점이 나타나는가?
• 사람이 계속 확인해야 할 제품 판단과 에이전트·코드에 맡길 수 있는 검증의 경계를 어떻게 정할 것인가?