영상 정리 · 빌더 조쉬(Builder Josh)
39분 인터뷰를 처음부터 끝까지 따라 읽는 글
이 세 개만 알면 나머지는 다 따라온다. 이미 아는 것이면 1장으로 건너뛰어도 된다.
커서(Cursor) 같은 도구에서 "에이전트"는 내가 직접 부르는 일꾼이다. 내가 한 번 시키면 하나가 움직이고, 다음 일을 시키려면 내가 또 불러야 한다.
서브 에이전트(sub agent)는 다르다. 이건 에이전트가 부르는 에이전트다. 내가 클로드 코드(Claude Code, 터미널에서 쓰는 AI 코딩 도구)에게 명령을 한 번 내리면, 클로드 코드가 알아서 필요한 서브 에이전트를 필요한 만큼 불러 모은다. 열 개든 백 개든 말이다.
비유하면 이렇다. 커서는 내가 직원 한 명 한 명에게 직접 전화를 거는 구조다. 클로드 코드는 팀장 한 명에게 전화를 걸면, 팀장이 알아서 부서원을 다 불러 나눠 시키는 구조다.
이 "누가 누구를 부르는가"의 차이가 왜 중요한지는 9장에서 정확한 예시와 함께 다시 나온다. 기억해 두자.
AI는 한 번에 눈앞에 펼쳐 놓을 수 있는 양이 정해져 있다. 이걸 컨텍스트 윈도우(context window)라고 부르는데, 그냥 책상 크기라고 생각하면 된다.
책상이 작으면 자료 하나를 보려고 다른 걸 치워야 하고, 치운 건 잊는다. 그래서 한정된 책상 크기 안에서 어떻게 더 많은 일, 더 깊은 일을 시킬까를 다루는 분야가 있는데, 이게 컨텍스트 엔지니어링이다. 최수민이 영상 초반에 클로드 코드가 압도적인 이유로 가장 먼저 꼽는 게 바로 이거다.
MCP(Model Context Protocol)는 AI 에이전트가 이미지 생성, 배경 제거, 코드 조회 같은 바깥 기능을 직접 실행하게 해주는 규격화된 연결 부품이다.
비유하면, 리모컨에 새 버튼을 하나 다는 것과 같다. 원래는 사람이 손으로 하던 일을 에이전트가 그 버튼을 눌러 스스로 처리하게 만드는 것이다. 12장에서 자세히 나온다.
"어, 그래요? 이제 커서를 이제 안 쓰세요?" 조쉬가 묻는다.
"아, 네. 커서는 전혀 안 써요." 최수민이 답한다.
바이브 코딩(직접 코드를 치지 않고 AI에게 말로 시켜 프로그램을 만드는 방식)의 대표 도구로 꼽히는 커서를, 그는 안티그래비티(Antigravity, 구글의 코딩 도구)와 함께 완전히 접었다. 두 도구 다 "좋은 면도 충분히 있다"고 인정하면서도, 쓸 수 없는 이유를 하나로 요약한다.
에이전틱한 기능이 클로드 코드에 비해서 너무 떨어지거든요.
에이전틱(agentic)이란 AI가 답만 하는 게 아니라 스스로 여러 단계를 밟아 행동까지 하는 성질을 말한다. 이 차이가 인터뷰 전체를 관통하는 주제다. 그 근거로 그는 자기가 실제로 굴리고 있는 프로젝트를 화면에 띄운다.
최수민이 화면을 공유한다. 최근에 만든, "모빈과 비슷한 오픈소스 프로젝트"다.
차이가 하나 있다. 모빈이 디자인(스크린샷)만 모아 놓는다면, 최수민의 프로젝트는 코드까지 그대로 볼 수 있다. 사이트 이름은 모네(Monet). 페이지에 들어가면 랜딩페이지가 어떤 코드 조각들로 구성되어 있는지 낱낱이 뜯어볼 수 있다. 이 인터뷰 시점(2025년 12월) 기준 컴포넌트(부품 단위 코드 조각) 773개가 등록되어 있다.
그런데 이걸 그가 혼자서 다 만드는 게 말이 안 된다. 그래서 실제로 어떻게 명령하는지를 보여준다.
가져올 웹페이지 주소를 하나 정하고, 클로드 코드 창을 열어 그가 실제로 치는 명령은 이거다.
○○을 참고해서 처리하세요.
이게 끝이다. 이 한 줄이 실행되면 클로드 코드가 지정된 MD(마크다운) 파일을 읽는다. 그 파일에는 어떤 서브 에이전트를 어떤 순서로 써서 작업하라는 지침이 전부 적혀 있다. 지침대로 클로드 코드가 웹페이지 이미지를 가져오고, 섹션별로 전부 나눈 다음, 코드 스타일(컨벤션)까지 정리해서 컴포넌트로 만들어 낸다. 완성된 결과물이 화면에 그대로 뜬다.
이 지침 문서 — 최수민은 파이프라인이라 부른다 — 를 실제로 열어 보여준다. 오픈소스라 누구나 깃허브에서 볼 수 있다고 그는 강조한다.
구조는 이렇다.
이렇게 미리 짜 두면, 그는 인풋(작업할 웹페이지 주소) 하나만 준다. 나머지는 파이프라인이 알아서 판다. 이 지시 한 번으로 한 시간 정도 작업이 진행된다. 이렇게 반복되는 작업을 파이프라인화해서 계속 재사용하는 것이 그가 요즘 가장 자주 쓰는 패턴이다.
조쉬가 묻는다. 스크린샷이나 코드 같은 걸 대체 어떻게 다 정의해 뒀냐고. 최수민이 그 지침 파일을 연다.
"스크레이프 웹사이트"라는 항목이 있다. 가상 브라우저(화면 없이 뒤에서 돌아가는 브라우저 프로그램)를 켜서 해당 URL로 이동한 다음, 스크린샷이나 리소스(이미지·폰트 파일 등)를 추출하는 로직이 여기 다 적혀 있다.
여기서 그는 중요한 선택 하나를 설명한다. 이 작업을 플레이라이트(Playwright, 가상 브라우저를 조작하는 도구) MCP로 에이전트에게 직접 시킬 수도 있다. 그런데 그렇게 하면 컨텍스트 소모량이 훨씬 커진다.
이유는 이렇다. 스크린샷을 에이전트가 직접 만들게 하면, 그 이미지 데이터(페이로드)가 통째로 컨텍스트 윈도우(0-2에서 배운 그 "책상") 안에 들어온 다음에야 파일로 저장된다. 파일이 바로 생성되지 않고 이미지 데이터만큼 책상을 차지하는 경우도 있다.
반면 이 과정을 스크립트로 미리 짜 두고 코드로 실행하면, 필요 없는 찌꺼기(중간 데이터)가 책상에 남지 않고 결과물만 남는다.
모든 것을 LLM에게만 의존하는 게 아니라, 반복적으로 작업화할 수 있는 것들, 그냥 코드로만 처리할 수 있는 것들은 별도의 타입스크립트를 지정해서 그거를 언제나 서브 에이전트가 호출하게끔 만든다.
예로 든 게 "HTML 파일에서 어떤 폰트를 썼는지 추출하는 일" 같은 것이다. 이런 건 그냥 코드로 처리하면 속도도 빠르고 정확도도 높다. 서브 에이전트를 쓰더라도 프롬프트만 적는 게 아니라, 스크립트화할 건 스크립트화해서 분리해 두는 것 — 이게 3장의 핵심이다.
모네에 쌓인 컴포넌트를 누가 관리하냐는 물음에, 최수민은 "제가 관리자니까 관리자가 직접 업데이트하게끔 만든 것"이라 답하면서도 덧붙인다. 이 프로젝트는 오픈소스라서 누구나 기여할 수 있는 구조라고.
다만 기여하기가 쉽지 않다는 것도 그는 알고 있다. 그래서 기여 방법을 담은 유튜브 영상을 따로 찍을 생각이라고 밝힌다. 깃허브 저장소에 들어가 프로젝트를 내려받은 다음 똑같이 명령하면 똑같이 동작한다. 다른 사람들이 원하는 사이트를 계속 추가해 주면 좋겠다는 게 그의 바람이다.
조쉬가 묻는다. 이런 서브 에이전트를 만들게 된 배경이 뭐냐고, 그리고 왜 클로드 코드가 압도적인지.
최수민은 서브 에이전트라는 개념이 클로드 코드에 나온 지는 꽤 됐다고 말한다. 그는 앤트로픽(Anthropic, 클로드를 만든 회사)이 내놓은 자료들을 참고했다고 한다.
서브 에이전트를 쓸 수밖에 없는 이유는 단순하다. 바이브 코딩을 하다 보면, 컨텍스트 크기(0-2의 그 책상)가 조금만 큰 작업을 해도 모자란다. 그런데 작업을 서브 에이전트로 나누면, 하나하나가 각자의 책상을 따로 쓰기 때문에 모자라지 않고 전부 할 수 있다. 그래서 어쩔 수 없이, 컨텍스트를 극대화하기 위해 쓰게 됐다고 그는 말한다.
그리고 여기서 핵심 발언이 나온다.
다른 에이전트 코딩 툴들은 서브 에이전트 기능이 아무도 없어요.
코덱스(Codex, OpenAI의 코딩 도구)도, 제미나이 CLI(Gemini CLI, 구글의 코딩 도구)도 마찬가지라고 그는 말한다. "엄청 어려운 기능도 아닐 텐데 왜 안 넣어 주는지 답답하다"고 덧붙인다. (2025년 12월 녹화 시점의 비교이니, 지금은 달라졌을 수 있다는 점은 감안해서 읽어야 한다.)
조쉬가 구체적인 방법을 묻는다. 최수민은 "사실 되게 쉽다"고 답한다.
그의 프로젝트에는 .claude/agents라는 폴더가 있다. 이 폴더 안에 마크다운 파일을 하나 만들기만 하면 서브 에이전트가 만들어진다.
그가 실제로 만든 "브랜드 로고파인더"라는 서브 에이전트를 열어 보여준다. 파일 안에는 네 가지가 적혀 있다.
이렇게 정의만 하면 서브 에이전트가 생긴다. 그런데 그는 이걸 매번 손으로 쓰지 않는다. 서브 에이전트 크리에이터라는 걸 스킬(0-1에서 배운 그 절차서)로 만들어서 쓰고 있다.
이 서브 에이전트 크리에이터 스킬은 또 어떻게 만들었을까. 최수민은 서브 에이전트와 관련된 공식 문서를 마크다운 파일로 저장해 두고, 그걸 참고해서 "서브 에이전트 만드는 스킬을 만들어줘"라고 스킬 크리에이터에게 시켰다고 말한다.
이때 중요한 게, 검증도 할 수 있게 하고 잘 추가되는지 확인하는 장치를 걸어 둬야 하는데, "스킬 크리에이터를 쓰면 웬만하면 잘 잡아 준다"고 그는 말한다. 공식 문서를 참조해서 시키면 되는 것이다.
그가 쓰는 이런 시스템 파일들(스킬 크리에이터, 서브 에이전트 크리에이터 등)은 전부 자신의 깃허브 저장소 CC 시스템에 모아 뒀다고 한다. (부록 B에 저장소 정보가 있다.)
최수민이 추천하는 방법은 하나다. 작성하는 프롬프트를 에이전트 창에 바로 입력하지 말고, 파일에 모아 두는 것.
그래서 그의 프로젝트에는 항상 "프롬프트"라는 폴더가 있다. 프롬프트를 써 놓고 보면, 나중에 똑같은 프롬프트를 또 쓰게 될 일이 생긴다. 아니면 일부만 바뀌어서 재사용할 일이 생긴다.
예를 들어 "체크리스트 생성 에이전트"를 만들고 싶다면, 저장해 둔 프롬프트를 복사해서 새 서브 에이전트 파일(예: 체크리스트-크리에이터.md)에 그대로 붙여 넣는다. 이때 도구(tools) 항목은 안 써도 된다.
그다음 한 가지를 더 한다. 프롬프트 안에서 바뀌어야 할 값(예: 만들 대상의 이름)을 변수로 바꾼다. 이렇게 하면 특정 작업 하나가 아니라, 어떤 체크리스트든 범용적으로 만들 수 있는 서브 에이전트가 된다.
정리하면 이렇다. 평소에 쓰는 프롬프트를 아카이빙하는 습관만 들여도, 그걸 그대로 옮겨 어떤 작업에나 쓸 수 있게 만들면 그게 곧 서브 에이전트다. 설명(description)만 적당히 고치면 된다.
조쉬가 묻는다. 다른 서브 에이전트들은 "스크립트를 불러와라", "1단계는 이거, 2단계는 이거" 식으로 훨씬 체계적으로 적혀 있는데, 이런 세세한 지침은 어떻게 만드냐고.
최수민의 답은 단순하다. 일단 단순한 상태로 시작하고, 쓰다가 마음에 안 들거나 느리다고 느껴지면 조금씩 더한다.
실제로 서브 에이전트를 만들어 시키다 보면 반복적으로 부딪히는 문제가 생긴다. "폰트 웨이트를 자꾸 실수하네" 싶으면 그 부분을 지침에 추가한다. "태그를 잘못 잡아내네" 싶으면 태그에 대한 지침을 추가한다 — 이 지침 문장은 실제로 AI가 스스로 제안해서 추가한 내용이라고 그는 말한다.
이렇게 자기만의 서브 에이전트가 쓰면 쓸수록 지침이 늘어나면서, 자신에게 최적화된 형태로 진화한다. 최수민은 이걸 단정적으로 정리한다.
아무리 에이전트에 대한 고수더라도 한 번에 이 서브 에이전트를 딱 설정해서 이렇게 쓸 수 있게 되지 않아요.
처음 파이프라인을 만들고 실행하면 무조건 이상하게 나온다. 그러면 어느 부분이 약하게 지시되었는지 판단해서 조금씩 보강해 나가면 된다.
조쉬는 이걸 예전의 노드 기반 자동화(N8N 같은, 화면에서 상자와 화살표를 이어 붙이는 방식)와 비교한다. 노드형은 눈에 보이는 만큼 직관적이지만, 글로 채워 넣는 이 방식은 직관성은 다소 낮아도 본인만의 최적화된 에이전트를 훨씬 쉽게 만들 수 있다는 게 두 사람의 정리다.
최수민은 여기에 실용적인 조언을 하나 더 붙인다. "서브 에이전트나 스킬을 공부해서 프로젝트에 쫙 깔아 놔야겠다"고 생각하면 어렵다. 대신 평소에 하던 일의 프롬프트를 아카이빙해 두고, 그걸 조금씩 범용적으로 바꿔 나가면서 "이건 스킬로 해야겠다, 이건 에이전트로 해야겠다" 하는 식으로 활용해 나가는 편이 낫다. 그렇게 하면 별로 어렵지 않다고 그는 말한다.
조쉬가 정확히 이 질문을 던진다. 커서도 자기가 쓰는 걸 "에이전트"라고 부르는데, 대체 뭐가 다르냐고.
최수민의 답이 이 인터뷰에서 가장 중요한 한 문장이다.
이 서브 에이전트들은 에이전트가 호출하는 에이전트예요. 커서에서는 에이전트를 호출하는 게 나잖아요. 근데 그러니까 이제 내가 여러 개의 에이전트로 호출하고 싶으면 여러 번 명령을 해야 되거든요.
0-1에서 미리 풀어 둔 그 차이다. 커서에서는 내가 매번 "다음 일 해줘"를 불러야 한다. 클로드 코드에서는 여러 개의 에이전트를 한 번의 명령으로 호출할 수 있다. 내가 하나를 호출하면, 그 안에서 열 개든 백 개든 서브 에이전트가 한꺼번에 딸려 호출된다.
조쉬는 이걸 조직 비유로 풀어낸다. 내가 하나의 에이전트를 호출하면, 여러 서브 에이전트가 관계로 묶여 있어서 하나가 실행되면 연관된 다른 에이전트가 또 호출되고, 그게 계속 이어진다. 마치 조직장이 명령 하나를 내리면 여러 팀이 동시에 움직이는 것과 같은 느낌이다.
이 차이가 실제로 무엇을 가능하게 하는지, 최수민은 프롬프트 하나를 더 보여준다. 그는 "한 200개씩 호출할 때가 있다"고 운을 뗀다.
방식은 이렇다. 먼저 체크리스트 파일을 만들어 둔다. 그다음 프롬프트는 대략 이런 내용이다.
체크리스트에서 구현되지 않은 이미지들에 대해서 최대 20개씩만 구현하고, 그다음 배치를 반복해라.
구현하는 구체적인 방법은 이미 서브 에이전트 파일에 다 적혀 있다. 그가 보여준 리스트에는 125개 항목이 있었다. 이 상태에서 방금 본 그 프롬프트로 요청하면, 125개를 한 번에 다 구현한다. 물론 시간은 오래 걸리지만, 한 번의 요청으로 끝난다.
최수민은 못 박는다. 커서는 이 작업 자체를 못 한다. 한 번의 요청으로 이런 규모를 처리하는 게 원래 안 되는 일이다.
조쉬가 다른 예를 요청하자 최수민은 이렇게 답한다. 지금 존재하는 모든 기능에 대한 브라우저 테스트를 하고 싶다면, 그것도 병렬로 전부 할 수 있다. 커서에서 같은 걸 시키면 엄청 오래 걸리고, 한 번 요청해서 컨텍스트가 모자라 다 못 끝낼 가능성이 높다.
조쉬가 궁금해한다. 이 정도 규모를 처리하려면 클로드 코드 요금제가 어느 수준이어야 하냐고.
최수민은 월 200달러짜리 맥스(Max) 플랜을 쓴다고 밝힌다. 구현하는 양 자체가 많아서 딱 꽉 채워서 쓰고 있다고 한다. 이번 주 얼마나 썼는지 확인하면서, 한도가 남으면 몇백 개씩 시켜서 다 채운다고 말한다.
최근에 진행한 프로젝트를 소개해 달라는 요청에, 최수민은 모네를 다시 언급하면서 자기가 요즘 하고 있는 일을 설명한다. 바이브 코딩 능력을 극대화하는 연구를 위해 프로젝트를 최대한 많이, 빠르게 만들어 보고 있고, 그 과정에서 필요한 서비스와 도구를 스스로 만들고 있다는 것이다.
그중 하나가 오픈소스 코드를 조회해 주는 MCP다. 참고하고 싶은 오픈소스가 있을 때, 그 코드를 에이전트가 직접 찾아보게 해주는 도구다.
그리고 이미지 관련 작업을 할 일이 많다 보니, 나노바나나(Nano Banana, 구글의 이미지 생성 AI 모델)를 MCP로 호출할 수 있게 만들었다. 이미지 배경을 제거하는 MCP도 만들었다 — "직접 하면 번거로우니까" 만들었다고 그는 말한다.
왜 스크립트로 끝내지 않고 MCP까지 만드는지 그는 설명한다. 파일 생성 과정을 스크립트화하는 것 자체가 중요한데(3장에서 배운 그 이유), 그중에서도 엄청 범용적인 것은 MCP로 만든다. 더 널리 퍼뜨릴 수 있기 때문이다.
제가 MCP로 배포해 놓으면 제 MCP에 버그가 있으면 누가 고쳐 줄 테니까, 오픈소스니까. 아니면 제보라도 해주겠죠.
조쉬는 최근 최수민에게 새로운 계정이 생긴 걸 발견했다고 말한다. 처음엔 "이거 갑자기 부계정인가" 생각했는데, 알고 보니 본캐(본래 캐릭터, 실제 이름을 쓰는 계정)였다고 한다. 말투부터 다르다.
최수민이 이유를 설명한다. 커서마피아 계정은 정보성 계정이라서 깊은 얘기를 하기가 어렵다. 그래서 지금 당장 고민하고 있는 이야기를 할 수 있는 청중을 따로 모아 보려고, 다른 페르소나(가상의 인격)로 계정을 하나 더 만들었다.
같은 내용을 두 계정에 같이 올리기도 하지만, 하는 얘기는 다르다.
그는 이 프로젝트를 시작한 이유도 밝힌다. 바이브 코딩 교육을 하면서 "서비스 제작이 되게 쉬워진다, 딸깍하면 다 나온다"고 늘 말해 왔는데, 그렇게 좋은 거라면 본인이 직접 써먹어야지, 안 그러면 가르칠 이유가 없다는 생각이 들었다고 한다. 자신이 진짜 바이브 코딩 전문가가 맞는지 스스로 시험해 보고 싶어서 시작한 도전이라는 것이다. "해보니까 역시 어렵습니다. 어려운데 배우는 것도 많아요."라고 그는 인정한다.
새 계정에는 "3년 내 유니콘 만들기" 프로젝트, 그리고 "100개의 서비스를 런칭하겠다"는 목표가 적혀 있다. 조쉬가 이걸 어떻게 해낼 계획이냐고 묻는다.
최수민의 답은 예상 밖이다. 이 목표는 숫자를 채우는 게 목적이 아니라, 자기 생각의 회로를 바꾸고 싶어서 세운 목표라는 것이다.
100개의 서비스를 런칭한다고 생각했을 때랑 다섯 개를 런칭한다고 생각했을 때랑, 하게 되는 고민 자체가 달라져요.
구체적으로 이렇게 갈린다.
즉 생산량을 극대화했을 때 어떤 고민을 하게 되는지, 미래의 메이커(만드는 사람)들이 결국 마주하게 될 고민을 미리 겪어 보고 싶어서 이 무리한 목표를 세웠다고 그는 말한다. 그러면서도 퀄리티에서 타협할 생각은 없다고 못 박는다. 프롬프트 한 번으로 뚝딱 나오는 명함 제작 서비스 같은 걸로 채우면 100개는 쉽지만, 그렇게 하지는 않을 거라서 목표 달성이 어려울 수도 있다고 그는 인정한다.
조쉬는 최수민을 1년간 지켜본 결과 느낀 원칙 하나를 짚는다. 본인이 직접 쓰지 않으면 만들지 않는다는 것. 왜 그런 원칙을 갖게 됐는지 묻는다.
첫 번째 이유는 역할이 너무 많기 때문이다. 그는 기획자·개발자·디자이너 역할을 혼자 다 해야 한다. 그래서 자기가 안 쓰는 것에도 잘 만들려면 그만큼 몰입하고 기획에 시간을 써야 하는데, 그러기가 현실적으로 어렵다. 반면 자기가 쓸 제품이면, 쓰다가 불편함을 빠르게 캐치할 수 있다.
두 번째 이유는 과거의 실패에서 나온다. 최수민은 예전에 창업했다가 망한 적이 있는데, 패션 쇼핑몰이었다. 그런데 정작 본인은 자기가 창업한 사이트를 안 쓰고 무신사(경쟁 온라인 패션 쇼핑몰)를 썼다. 그는 이걸 "완전 배드 시그널(안 좋은 신호)"이었다고 회고한다.
이제 제가 타겟 서비스를 하면은 그 배드 시그널을 딱 알아차릴 수 있거든요. 어, 나 이거 안 쓰고 있네, 이걸로.
그래서 이 원칙은 일종의 안전 가드레일로도 작동한다. 모네를 만든 것도 같은 논리다. 앞으로 프로젝트를 100개 만들 텐데, 디자인 레퍼런스나 컴포넌트를 참고하고 싶을 때마다 모빈 같은 다른 사이트를 왔다 갔다 하지 않기 위해, 자기가 쓸 도구로 모네를 직접 만든 것이다.
모네에도 시작하고 나서 여러 기능을 추가했는데, 전부 그가 쓰다가 불편해서 넣은 것들이다. 그중 하나가 도컬렉션이다. 마음에 드는 컴포넌트를 모아 컬렉션으로 만들어 두면, "이 컬렉션에 있는 컴포넌트를 참고해서 랜딩페이지를 만들어 줘"라는 한마디에 MCP가 그 컴포넌트들을 읽어 와서 랜딩페이지를 한 번에 만들어 준다.
조쉬는 이걸 핀터레스트(이미지를 모아 두는 서비스)로 디자인 요소를 수집해 온 자기 경험에 빗대며, "컬렉션 자체가 하나의 에이전트가 되는 느낌"이라고 정리한다.
조쉬가 마지막으로 묻는다. 컨설팅도 하고, 강의도 하고, 자기 프로덕트도 만드는 최수민이 요즘은 어떻게 지내는지.
최수민은 이 프로젝트 외에는 완전히 최소화했다고 답한다. 크리에이터 활동도 잘 못 하고 있을 정도다. 강연이나 컨설팅도 한 달에 한두 번으로 줄였다. 지금은 내공을 쌓는 기간이라고 그는 표현한다. 이 프로덕트들이 전부 수익 창출이 가능하도록 만드는 것이기도 해서, 그 나름의 사업 방식이기도 하다고 덧붙인다.
조쉬는 많은 사람이 궁금해할 질문을 직접 던진다. 직장도 없이, 지금 같은 R&D(연구개발) 기간을 어떻게 버티고 있느냐고. 그는 이런 시도를 하는 것 자체가 용기라고 짚는다.
최수민의 답은 부스터라는 SaaS(구독형으로 운영하는 소프트웨어 서비스)다. 이미 만들어서 운영 중인 이 서비스에서 패시브 인컴(직접 일하지 않아도 반복적으로 들어오는 수입)이 꽤 괜찮게 나오고 있다고 한다. 그래서 별도의 경제 활동 없이도 생계 유지가 가능하고, "사실 좀 넉넉하다"고 말한다. 강연을 열심히 하면 수입을 더 넓힐 수 있겠지만, 그 부분은 미래를 위한 투자로 여기고 타협했다는 것이다.
마지막 질문이다. 지금 완전히 1인으로 활동하는 이유가 뭘까.
최수민은 자신이 팀으로 뭔가를 하는 데 그렇게 익숙하지 않다고 털어놓는다. 팀으로 활동하면 심심하지 않다는 등 좋은 점이 있지만, 그것 말고 팀원이 있어야만 하는 이유를 잘 못 느끼겠다고 한다. 개발은 자신이 하는 것이고, 팀원이 마케팅 콘텐츠를 대신 써 주는 것도 아니기 때문이다. 스스로 잘 위임하지 못하는 성격이라 단독으로 하는 편이 낫겠다고 판단했다는 것이다.
그런데 그는 유니콘이라는 목표를 허황되게 말하는 게 아니라고 강조한다. 진짜로 목표하고 있다는 것이다. 그래서 그는 전략을 이렇게 정리한다.
나는 이렇게 팀으로 움직이는 데 좀 최적화되지 못했지만, 주 무기인 AI를 최대한 활용해서 스케일업을 해 봐야겠다.
팀 없이 갈 수 있는 데까지, AI를 팀 대신 부려서 가 보겠다는 것이 이 인터뷰의 마지막 결론이다.
이제 다 읽었으니 한자리에 모아 둔다. 처음 볼 때는 낯설었던 것들이다.
| 말 | 뜻 | 어디서 |
|---|---|---|
| 서브 에이전트 | 에이전트가 부르는 특화된 작은 에이전트. 사람이 아니라 에이전트가 부른다 | 0-1, 9장 |
| 스킬 | "이 순서로 하라"고 적어 둔 절차서. 서브 에이전트를 만드는 데도 쓰인다 | 0-1, 6장 |
| 컨텍스트 윈도우 / 컨텍스트 엔지니어링 | AI가 한 번에 펼칠 수 있는 양 = 책상 크기. 그 안에서 더 많은 일을 시키는 기술 | 0-2, 5장 |
| MCP | AI가 이미지 생성·배경 제거 같은 바깥 기능을 직접 쓰게 해주는 연결 부품 | 0-3, 12장 |
| 에이전틱 | AI가 답만 하지 않고 스스로 여러 단계를 밟아 행동까지 하는 성질 | 1장 |
| 모빈 / 모네 | 모빈은 디자인만 모은 레퍼런스 사이트, 모네는 코드까지 볼 수 있는 최수민의 오픈소스 프로젝트 | 2장 |
| 파이프라인(지침 문서) | 어떤 서브 에이전트를 어떤 순서로 부를지 적어 둔 마크다운 문서 | 2장 |
| 플레이라이트 MCP | 가상 브라우저를 조작하는 도구. 직접 쓰면 컨텍스트를 많이 먹는다 | 3장 |
| 오퍼스 / 소네트 / 하이쿠 | 서브 에이전트에 지정하는 모델 등급. 순서대로 비싸고 똑똑함 → 저렴함 | 6장 |
| 노드형 자동화 | 상자와 화살표를 이어 붙이는 방식(N8N 등). 직관적이지만 서브 에이전트만큼 유연하진 않다 | 8장 |
| 맥스(Max) 플랜 | 클로드 코드의 월 구독 요금제 중 하나. 최수민은 200달러짜리를 쓴다 | 11장 |
| 나노바나나 | 구글의 이미지 생성 AI 모델. MCP로 호출해서 쓴다 | 12장 |
| 본캐 / 부캐 | 본캐는 실제 이름을 쓰는 원래 계정, 부캐는 다른 페르소나로 만든 별도 계정 | 13장 |
| 빌드인퍼블릭 | 제품 만드는 과정을 SNS에 실시간 공개하며 홍보하는 전략 | 14장 |
| 도컬렉션 | 마음에 드는 컴포넌트를 모아 두면 MCP가 그걸 참고해 랜딩페이지를 만들어 주는 모네의 기능 | 15장 |
| 부스터 | 최수민이 운영하는 SaaS. 여기서 나오는 수입으로 생계를 유지한다 | 16장 |
| 패시브 인컴 | 직접 일하지 않아도 반복적으로 들어오는 수입 | 16장 |
773개(모네 컴포넌트 수), 125개·200개(한 번에 처리한 작업 수), 월 200달러(요금제) — 전부 최수민이 인터뷰 중 직접 말한 값이다. 제3자가 검증한 수치가 아니다.
모네 컴포넌트 수는 원 출처(모네 사이트, 깃허브 저장소)를 직접 열어 대조했다. 이 정리를 쓴 시점(2026-08-11)에 모네 사이트는 1,007개 이상, 깃허브 저장소(monet-registry) 리드미는 "540개 이상"이라고 적혀 있어 서로도 다르고, 인터뷰 당시의 773개와도 다르다. 즉 이 숫자는 계속 바뀌고 있고, 지금 정확한 개수는 확인되지 않는다. 인터뷰 시점의 773개만 발표자 진술로 신뢰할 수 있다.
이 영상은 한국어 원어 자막이라 오역은 없지만, 자동 음성 인식이라 발음이 비슷한 다른 말로 잘못 옮겨진 곳이 있다.
| 자막에 찍힌 것 | 아마도 |
|---|---|
| 나노바나 | 나노바나나 (Nano Banana) — 웹검색으로 확인함 |
| 북캐 | 부캐 (한국어 신조어, "부캐릭터"의 줄임) |
| SU 해 가지고 | SEO 해 가지고 (검색엔진최적화) — 문맥상 추정, 확인 안 됨 |
| 줌 무기인 AI | 주 무기인 AI — 문맥상 추정 |
| 샤프 MCP | 이미지 배경 제거 MCP라는 것만 확실하고, 정확한 이름은 확인 안 됨. 웹검색으로 찾은 배경 제거 MCP들(Rembg, Remove.bg 등) 중 발음이 맞아떨어지는 것을 찾지 못했다 |
| 하우 아이 팟캐스트 | 진행자가 진행하는 팟캐스트 이름으로 보이나, 정확한 표기는 확인 안 됨 |
이 영상은 두 사람 다 한국어로 말한다. 그래서 번역을 거친 자막이 아니라 한국어 원어 자동 자막을 그대로 썼다. 오역 위험은 없지만, 자동 음성 인식이라 외래어·도구 이름이 소리 나는 대로 깨지는 문제는 그대로 있다. 그래서 위 표처럼 확인이 필요한 부분을 따로 표시해 뒀다.