기자 출신이 앱을 만든다고? Claude Code로 iOS 앱 출시까지
기자 출신이 앱을 만든다고? Claude Code로 iOS 앱 출시까지 코드 한 줄 못 짜던 기자가 주말마다 혼자 iOS 앱을 만들어 앱스토어에 올리고 있어요. 그것도 "Bob"과 "Ray"라는 이름의 AI 에이전트 두 명을 부하 직원처럼 부리면서요. 오늘 소개할 주인
기자 출신이 앱을 만든다고? Claude Code로 iOS 앱 출시까지
코드 한 줄 못 짜던 기자가 주말마다 혼자 iOS 앱을 만들어 앱스토어에 올리고 있어요. 그것도 "Bob"과 "Ray"라는 이름의 AI 에이전트 두 명을 부하 직원처럼 부리면서요.
오늘 소개할 주인공은 LinkedIn 편집장 Dan Roth이에요. Fortune, Wired, Forbes를 거친 30년 경력의 저널리스트인 그는, 어느 날 문득 "나도 뭔가 만들 수 있겠다"는 생각에 Claude Code를 집어 들었어요. 그리고 지금은 매주 주말마다 앱 업데이트를 배포하는 아마추어 개발자가 됐죠.
비기술직 직장인이, 400명 팀을 이끄는 임원이, 어떻게 혼자 프로덕션 수준의 앱을 만들고 있을까요? 그 비결은 생각보다 단순하면서도 정교해요. 오늘 이 인터뷰에서 그 모든 것을 공개합니다.
듀얼 에이전트 시스템: Bob과 Ray를 소개합니다
Q. 도대체 어떻게 혼자 프로덕션 앱을 만들 수 있는 건가요?
Dan의 핵심 비결은 Claude Code에 두 개의 전혀 다른 '페르소나'를 부여하는 것이에요. 단순히 챗봇에 말 거는 게 아니라, 마치 실제 팀처럼 구성하는 거죠.
- Bob (빌더 에이전트): "Bob the Builder"라는 이름답게 항상 먼저 계획하고, 모듈 단위로 코드를 짜요. 스파게티 코드를 절대 용납하지 않는 성격을 부여했어요.
- Ray (리뷰 에이전트): 보안에 집착하는 시니어 소프트웨어 엔지니어예요. Bob이 무언가를 만들면 반드시 Ray의 검토를 거쳐야 해요.
- Dan 본인: Bob과 Ray가 의견 충돌할 때 최종 결정을 내리는 타이브레이커(tiebreaker)예요.
Bob과 Ray의 역할 분담을 설명하는 Dan — Bob은 빌드, Ray는 보안 검토, Dan은 최종 결정권자
▶ 출처: How I AI — YouTube (0:35)
특히 Ray에 대해 Dan은 이렇게 설명해요:
"Ray의 역할은 보안을 지키고, 설계 방향을 수호하는 거예요. Claude는 항상 모든 걸 '천재적이야, 완벽해!'라고 칭찬하거든요. 그래서 Ray에게는 반드시 NO를 말하라고 지시했어요."
그리고 Bob의 핵심 규칙이 하나 있어요. Bob은 반드시 모든 작업을 Ray에게 먼저 보고해야 해요. 이 강제적 검토 루프가 품질을 지키는 핵심이에요.
주말 개발자의 실전 워크플로우
Q. 실제로 어떤 순서로 개발을 진행하나요?
Dan의 개발 루틴은 놀라울 정도로 체계적이에요. 주중에는 LinkedIn 편집장으로 일하고, 주말에만 이 모든 걸 해내요.
① 아이디어 관리 — Claude 웹앱 프로젝트 활용
Claude의 '프로젝트' 기능 안에 "기능 아이디어 & 트래커" 채팅창을 하나 항상 열어둬요. 사용자 피드백, 새로운 아이디어가 생기면 여기에 다 기록해요. 그리고 Claude에게 이렇게 평가하도록 프롬프트를 심어뒀어요:
- ⏱ 빌드 예상 시간 (1~3점)
- 고객 행복도 예상 임팩트 (1~3점)
- 성장 임팩트 예상 (1~3점)
주말이 되면 이 표를 열고 "오늘 몇 시간 있다 → 이 정도 규모의 기능을 고른다"는 식으로 작업을 선택해요.
② 개발 실행 — 터미널 2개 탭
터미널을 두 개 탭으로 열어요. 하나는 Bob 전용, 하나는 Ray 전용이에요. Bob이 계획을 짜면, Dan이 그걸 복사해서 Ray 탭에 붙여넣어요. 수동으로요.
왜 자동화하지 않냐고요? Dan의 대답이 인상적이에요:
"저는 배우기 위해 만드는 거예요. 복사-붙여넣기라는 작은 마찰이 Ray가 무슨 말을 하는지 실제로 읽게 만들어줘요. 너무 효율화하면 정작 프로세스를 이해하지 못하게 돼요."
Bob의 계획을 Ray에게 수동으로 전달하는 실제 장면 — 이 "의도적 마찰"이 학습의 핵심
▶ 출처: How I AI — YouTube (14:35)
Ray가 승인하면 Bob에게 다시 전달하고, Bob이 코드를 짜요. 완성되면 Xcode에서 컴파일하고 시뮬레이터로 테스트 후 앱스토어에 제출해요.
비기술직이 AI 개발에서 맡아야 할 진짜 역할
Q. 코딩을 모르는데, 개발 과정에서 내가 할 수 있는 게 뭔가요?
Dan은 자신의 역할을 정의하는 데 꽤 오랜 시간이 걸렸다고 해요.
- 처음엔 "나는 나쁜 PM인가?"라고 생각했어요.
- 그 다음엔 "아키텍트 같은 건가?"라고 생각했는데, "아키텍트는 실제로 세부 사항을 알잖아요."
- 결론은: "나는 그냥 엄청나게 까다로운 고객이에요."
"나는 샴페인을 마시기 전에 먼저 향을 맡는 사람" — 까다로운 고객으로서 AI 빌더의 역할을 설명하는 Dan
▶ 출처: How I AI — YouTube (24:35)
"저는 집을 둘러보며 아키텍트에게 '이 방은 파란색으로 해주세요. 당신이 좋은 생각이 아니라고 해도 저는 이걸 원해요'라고 말하는 사람이에요. 비브 코더(vibe coder)의 역할은 '내가 깊이 신경 쓰는 게 뭔가?'를 명확히 하는 거예요."
그리고 그는 이 역할을 단순한 QA(품질 검수)와 명확히 구분해요. 단순히 버그를 찾는 게 아니라, 제품의 목소리와 개성을 불어넣는 것이 역할이라고요. 예를 들어, 팟캐스트 클리핑 앱에서 "동영상 생성 중"이라는 건조한 메시지를 "와, 진짜 좋은 부분을 클립했네요!"라고 바꾼 것처럼요.
15년 테크 회사 경험이 AI 개발에 준 진짜 이점
Q. 비기술직인데 다른 비기술직보다 잘할 수 있었던 이유가 뭔가요?
15년간 테크 회사에서 일하며 익힌 팀 운영 방식을 AI 에이전트 구조에 그대로 적용한 Dan
▶ 출처: How I AI — YouTube (26:25)
Dan이 직접 설명한 핵심 포인트예요:
"저는 15년간 테크 회사 안에서 일했어요. 팀이 어떻게 돌아가는지 지켜봤죠. Ray는 실제로 제가 일했던 Principal Engineer(수석 엔지니어)를 모델로 만들었어요. PM 파트너들이 항상 '이거 Sanjay한테 한번 물어봐야 해'라고 하던 그 한 사람. 그 사람만이 yes/no를 말할 수 있고, 그 사람은 누구도 관리하지 않고, 누구에게도 관리받지 않아요."
조직 경험이 있는 사람이 AI 에이전트를 더 잘 설계할 수 있어요. 실제 팀 구조, 의사결정 프로세스, 견제와 균형 — 이걸 아는 사람이 AI에게도 그 구조를 그대로 적용할 수 있거든요.
그래서 Bob의 서브 에이전트 규칙도 명확해요:
- Bob은 서브 에이전트를 만들 수 있어요 (단, 책임은 Bob이 져요)
- 서브 에이전트는 또 다른 서브 에이전트를 만들 수 없어요
- Ray는 스폰(spawn)할 수 없어요 — 유일한 게이트키퍼로 고정이에요
주말 개발자 팁 총정리 + 직장인 AI 활용법
Q. 개발 외에 일상 업무에서 AI를 어떻게 활용하나요?
400명 팀을 이끄는 편집장의 퇴근 전 30분 루틴 — "오늘 내가 공을 놓친 게 뭔지 알려줘"
▶ 출처: How I AI — YouTube (32:35)
400명 팀을 운영하는 Dan은 Microsoft Copilot을 업무에 활용해요. 그의 핵심 프롬프트는 딱 하나예요:
"오늘 내가 공을 놓친 게 뭐야? (What did I drop the ball on?)"
Copilot이 Outlook, Teams, 업데이트된 파일을 모두 뒤져서 답장 안 한 이메일, 놓친 Teams 메시지, 팔로업 안 된 미팅 등을 정리해줘요. 단순히 멘션(@)된 것만이 아니라, Dan이 평소에 관심 가져온 프로젝트까지 맥락으로 파악해요.
대부분 사람들이 아침에 하루 계획을 세우는 용도로 AI를 써요. 하지만 Dan은 정반대예요. 퇴근 30분 전, "오늘 내가 뭘 빠뜨렸나"를 확인하는 것이 훨씬 실용적이라고 강조해요. 그래야 당일 바로 처리할 수 있으니까요.
이 인터뷰에서 뽑은 핵심 팁 5가지
- 모든 것을 MD 파일로 저장하세요 — Claude의 컨텍스트 창은 계속 리셋돼요. "모든 걸 로그 파일로 남겨"라는 지시를 습관화하세요.
- 반드시 브랜치를 만드세요 — main에 직접 배포했다가 2주 동안 고생한 실제 경험에서 나온 교훈이에요.
- 아이디어 트래킹 채팅창을 하나 고정으로 유지하세요 — 빌드 시간, 임팩트 점수로 우선순위를 자동으로 매기게 해두면 결정 피로가 줄어요.
- 계획이 완성되기 전에는 절대 빌드를 시작하지 마세요 — "plan first, then build"는 모든 게스트가 공통으로 강조하는 원칙이에요.
- AI를 관리하는 것은 팀 관리와 같아요 — "최선의 의도를 가정(assume best intentions)하되, 우리가 어떻게 일하는지 계속 상기시켜 줘야 해요."
🇰🇷 한국 중소기업/스타트업에 적용하는 법
Dan의 Bob-Ray 시스템은 사실 어떤 규모의 조직에서도 바로 적용 가능한 구조예요. 특히 개발자가 없거나 부족한 한국 스타트업과 중소기업에 딱 맞아요.
- 제조업 중소기업: 재고 관리 앱, 작업 지시서 자동화 앱을 Dan처럼 직접 만들 수 있어요. "Bob이 기능을 만들고 Ray가 데이터 보안을 검토"하는 구조 그대로요.
- 이커머스 스타트업: 상품 등록, 주문 처리 자동화 도구를 내부 툴로 직접 빌드하세요. 외주 개발 비용을 아낄 수 있어요.
- 마케터/기획자: 코딩 몰라도 괜찮아요. 당신이 "가장 까다로운 고객"이 되면 돼요. Claude Code에 Bob과 Ray를 만들고, 당신은 최종 결정만 하면 돼
가장 중요한 건 Dan이 처음 시작한 방식이에요. 자기 자신이 간절히 원하는 것을 먼저 만드세요. "내가 뉴욕 지하철을 자꾸 놓쳐서"라는 이유로 만든 Commutely처럼, 완벽한 제품-시장 적합성(product-market fit)은 내가 곧 시장일 때 찾기 가장 쉬워요.
AI 자동화, 어디서부터 시작해야 할지 모르겠다면?
자동화 교육부터 구축까지, 윤자동이 함께합니다.
윤자동 | 윤용승 대표 | ceo@yunjadong.com | 010-3944-5100