More AI Agents Won''t Fix This Solo Dev Workflow

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

More AI Agents Won't Fix This Solo Dev Workflow를 중심으로, 결과 화면만 보고 다시 프롬프트를 보내는 작업 방식에는 한계가 있다. 계획 작성 능력에 더해 명령줄 도구, 파일 구조, 데이터 모를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 결과 화면만 보고 다시 프롬프트를 보내는 작업 방식에는 한계가 있다. 계획 작성 능력에 더해 명령줄 도구, 파일 구조, 데이터 모델과 타입까지 살펴야 결과를 판단할 수 있다.
2. 직접 통제가 필요하면 데이터·타입·함수 수준으로 내려가고, 이해한 업무를 반복할 때는 시스템 수준으로 올라가 자동화한다. 모든 도메인에 동일한 자동화 수준을 적용할 수는 없다.
3. 코드가 최종적인 사실의 기준이지만 읽는 데 시간이 든다. 이미지, 다이어그램, 데이터 모델 SVG, 화면 녹화 등을 문서에 붙여 사람과 에이전트가 작업 내용을 빠르게 이해하도록 돕는다.
4. 자동화는 도메인 이해, 반복 경험, 에이전틱 엔지니어링 역량이 갖춰졌을 때 확대한다. 간단한 스킬에서 재사용 에이전트로, 이후 개발 워크플로로 확장하는 순서를 제안한다.
5. 목표는 작업마다 AI를 호출하는 데서 나아가 자신이 소유하는 개발 스튜디오를 만드는 것이다. 사람은 판단과 취향을 유지하고, 에이전트는 범위가 정해진 일을 맡으며, 코드는 검사를 담당한다.

🧩 배경과 문제 정의

영상은 앱이 기대와 다르게 나왔을 때 파일을 열어 원인을 확인하기보다 에이전트에게 다시 요청하는 습관에서 출발한다. 발표자는 에이전트·계획·결과 화면에 집중된 관심을 문서, 데이터 모델, 코드 구조와 실제 업무 이해로 넓혀야 한다고 주장한다.

발표자 Daniel은 10년 이상 iOS 개발을 했고 프리랜서와 Glassfy를 거쳐 솔로 개발에 집중하게 됐다고 소개한다. 현재는 디자인·코드·출시·마케팅에 에이전트를 활용하는 AI 네이티브 스튜디오를 만들고 있으며, 그 경험을 Crafters Lab에서 공유한다고 설명한다.

핵심 문제는 자동화를 어디까지 확대하고 언제 직접 통제할지 판단하는 것이다. 발표자는 도메인 이해, 반복 업무의 존재, 에이전틱 엔지니어링 역량을 확대 조건으로 제시한다. 후반부에는 이 관점을 구현하는 작업·지식·전문 에이전트 공간을 소개하며 초기 구축 비용도 인정한다.

🕒 시간순 섹션별 상세정리

1. 결과 화면과 재프롬프트에 갇힌 개발 방식

• 기대와 다른 앱을 보고 다시 요청하는 습관을 짚으며, 이해하는 시스템 영역에서만 자동화의 이점을 얻고 작업 경험이 쌓였을 때 수준을 높이라고 제안한다. [00:17]
• 바이브 코딩부터 에이전틱 엔지니어링까지를 하나의 범위로 설명하고, 프롬프트·컨텍스트·하네스 엔지니어링을 관련 역량으로 제시한다. 계획은 확장된 프롬프트이며 이를 작성하는 능력도 중요하다고 드러낸다. [01:11]
• 파일 하나 열지 않고 재프롬프트를 반복하는 상황을 지적한다. 명령줄에서 도구가 적절한지 확인하고 개별 파일을 조정하는 수준까지 관심을 넓혀야 한다고 보여준다. [01:46]

2. AI 네이티브 스튜디오와 이해를 돕는 문서

• Daniel은 자신의 개발 경력과 솔로 전환을 소개하고, 디자인부터 마케팅까지 에이전트를 활용하는 스튜디오가 매주 자신을 덜 필요로 하도록 만드는 것이 목표라고 드러낸다. 이어 Crafters Lab을 보여준다. [02:33]
• 직접 통제가 필요하면 아래로 내려가고 시스템의 이점이 필요하면 위로 올라가라고 권한다. 사람과 에이전트를 위한 문서에는 이미지, 다이어그램, 데이터 모델 SVG, 시뮬레이터 녹화를 포함하자고 제안한다. [03:10]
• 코드를 최종적인 사실의 기준으로 두되, 읽는 비용을 줄이기 위해 에이전트가 이미지·짧은 오디오·영상으로 요약하도록 하자고 보여준다. [03:33]

3. 데이터 모델과 타입까지 내려가야 하는 이유

• 짧은 프로토타입을 넘어 유지할 제품이라면 데이터 계층에 시간을 써야 한다고 강조한다. 특히 개인정보를 맡기면서 에이전트가 설계한 데이터 모델을 이해하지 않는 상황을 문제 삼는다. [03:55]
• 제품의 가치와 사용자 관계가 데이터에 담긴다고 보여준다. 더 많은 통제가 필요할수록 타입과 함수까지 살펴야 하며, 장기 수익을 목표로 하는 운영 소프트웨어에서는 바이브 코딩을 강하게 경계한다. [04:37]
• 폴더와 파일 구조는 전체 이해를 돕고 타입은 앱의 데이터 흐름을 보여 준다. 함수와 개별 코드 줄까지 내려가는 일에는 시간이 들기 때문에 필요한 깊이를 선택해야 한다고 드러낸다. [04:52]

4. 자동화를 확대할 조건과 필요한 역량

• 제과점 운영을 모르는 상태에서 제과점용 소프트웨어 공장부터 만들 수는 없다는 예를 든다. 도메인을 이해해야 결과의 옳고 그름을 판단할 수 있으며, 익숙한 반복 업무는 자동화 후보가 된다고 보여준다. [05:39]
• 간단한 스킬에서 재사용 에이전트로, 이후 비용 절감과 확장을 위한 개발 워크플로로 발전시키라고 권한다. 여러 산출물과 긴 단계가 있는 작업도 자동화 근거를 살펴야 하며, 반복한 출시 업무를 예로 든다. [06:16]
• 높은 자동화 수준에는 프롬프트·컨텍스트·하네스 설계, 다중 에이전트 조율, 상황과 가격에 맞는 모델 선택, 에이전트와 코드의 결합 역량이 필요하다고 강조한다. [06:53]

5. 소유하는 스튜디오와 연결된 작업·지식 공간

• 풍부한 문서, 데이터 모델, 폴더, 타입으로 관심을 넓히라는 주장을 정리한다. 도메인 이해와 반복 경험, 실제 역량이 있을 때 자동화하고, 사람은 판단을 맡으며 에이전트는 한정된 업무를 수행하고 코드는 검사를 담당한다고 드러낸다. [08:00]
• Crafters Lab이 코드뿐 아니라 제품 마케팅과 스튜디오 운영을 다룬다고 보여준다. 댓글과 Slack은 의견 교환 공간이며, Notion은 스튜디오의 공유 작업 공간이라고 보여준다. [09:08]
• Notion의 Foundry는 브리프부터 작업·피드백·출시까지 맥락을 유지하는 작업 계층이다. Swift Brain은 Swift·SwiftUI 지식과 스킬, 인터페이스 참고 자료를 축적해 세션 사이에 학습이 사라지지 않도록 하는 지식 계층이라고 보여준다. [09:59]

6. 필요한 지식과 도구만 연결하고 지속적으로 개선하기

• 에이전트가 존재하지 않는 SwiftUI를 만들어 내는 사례를 들며 공개 인터넷에만 의존하는 맥락을 비판한다. 필요한 데이터베이스만 복제하고 해당 자료를 검색하도록 연결하며, MCP를 지원하는 여러 도구를 언급한다. [10:30]
• Ops Lab은 지침·스킬·설계 청사진을 제공하는 전문 계층이다. 업무를 먼저 정한 뒤 지침을 만들고 필요한 스킬과 도구만 붙이며, 자기 도구에 맞게 적용해 가치가 있는 구성만 유지하라고 보여준다. [10:55]
• 첫 시스템은 단순 프롬프팅보다 느리고 계속 개선해야 한다고 인정한다. 이미 제품을 출시하는 솔로 개발자가 자신의 판단과 취향을 담은 스튜디오를 만드는 것이 목표이며, 마지막으로 데이터와 타입을 살피고 준비됐을 때만 자동화 수준을 높이라고 강조한다. [11:35]

🧾 결론

• 에이전트 수보다 업무 배치와 검토 방식이 중요하다. 무엇을 맡길지 정의하고 결과를 판단할 수 있어야 자동화가 의미를 갖는다.
• 장기 운영할 제품에서는 데이터 모델, 폴더 구조, 타입에 대한 이해가 필요하다. 발표자는 수익을 목표로 하는 실제 운영 소프트웨어에서 무비판적인 바이브 코딩을 강하게 경계한다.
• 문서와 지식은 작업이 바뀌거나 세션이 끝나도 맥락이 이어지도록 관리해야 한다. 브리프부터 피드백과 출시까지 연결되는 작업 기록이 그 기반이다.
• 이런 시스템의 첫 버전은 단순히 프롬프트를 보내는 것보다 느리며, 구축 이후에도 계속 다듬어야 한다.

📈 투자·시사 포인트

• 개발 도구와 운영 체계에 시간을 투자할 때는 에이전트 수보다 반복 업무의 범위, 검토 가능성, 도메인 이해 수준을 평가 기준으로 삼을 수 있다.
• 자동화의 비용 절감과 확장은 발표자가 제시한 목표다. 초기 구축이 더 느리다는 설명도 있으므로, 실제 도입 판단에서는 구축 시간과 반복 사용으로 얻는 절감 효과를 함께 따져야 한다.
• 모델과 도구가 바뀌어도 유지할 자산으로 자체 지침, 스킬, 지식 자료, 검토 절차를 강조한다. 도구 선택과 별개로 운영 체계를 축적한다는 관점이다.
• 솔로 개발자의 운영 범위는 코드 작성뿐 아니라 디자인, 출시, 제품 마케팅까지 이어진다. 기술적으로 완성된 앱을 만드는 일과 사용자에게 알리는 일을 함께 설계해야 한다.

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

• 자동화가 시간·비용·품질을 얼마나 개선했는지 보여 주는 정량 비교는 없다. 설명은 발표자의 경험과 권고를 중심으로 한다.
• 같은 일을 몇 번 반복하면 자동화해야 하는지, 어느 수준부터 충분한 도메인 이해와 에이전틱 역량을 갖췄다고 볼지 구체적인 기준은 제시하지 않는다.
• 개인정보를 다루는 데이터 모델에 주의를 기울이라고 강조하지만, 접근 권한·보관·보안 검증 등의 구체적인 운영 절차는 설명하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 최근 재프롬프트를 반복한 작업 하나를 골라 결과 화면뿐 아니라 관련 파일, 데이터 모델, 타입을 확인한다.
• 작업 문서에 의도와 구현 결과를 설명하는 다이어그램이나 화면 녹화를 붙이고, 실제 코드와 맞는지 검토한다.
• 익숙하고 반복되는 업무 하나를 선정해 간단한 스킬로 정리한 뒤, 재사용 에이전트나 개발 워크플로로 확장할 필요를 판단한다.
• 에이전트의 업무 범위와 검토 기준을 먼저 적고, 그 일에 필요한 지침·스킬·도구만 연결한다.

❓ 열린 질문

• 에이전트의 결과가 맞고 틀린지 판단할 수 있을 만큼 도메인을 이해했다는 것을 어떤 기준으로 확인할 것인가?
• 어떤 검사는 코드로 고정하고, 어떤 판단과 검토는 사람이 계속 맡아야 하는가?
• 복제한 지식 자료의 안정성을 유지하면서 원본의 유용한 변경을 언제 반영할 것인가?