이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

찰리 홀츠는 자기가 만든 앱으로 그 앱을 다시 만듭니다. 그가 운영하는 'Conductor'는 맥에서 여러 AI 코딩 에이전트를 동시에 돌리고 지휘하게 해주는 앱인데, 정작 본인은 하루의 대부분을 키보드 단축키와 음성으로만 일합니다. 손으로 코드를 치는 일은 거의 없어요.

요즘 1인 개발자나 작은 팀 사이에서 "Claude Code 하나도 벅찬데 여러 개를 어떻게 동시에 돌리냐"는 말이 자주 나오는데, 홀츠는 그걸 매일 여러 개씩 동시에 돌리는 사람입니다. 토큰값으로 한 달에 2만 2천 달러(약 3,400만 원)를 쓴 달도 있었을 만큼, 토큰은 거침없이 태우는 쪽이죠.

Y Combinator 2024년 여름 기수 출신인 그가 자신의 작업 셋업을 직접 보여주면서, AI에게 무엇을 맡기고 무엇을 끝까지 사람이 쥐고 있어야 하는지 이야기했습니다.

음성과 단축키로 굴러가는 하루

Q. 본인 작업 셋업을 보여주신다고 했어요. 가장 먼저 소개하고 싶은 게 뭔가요?

요즘 없으면 못 사는 물건이 하나 있는데, 구즈넥 마이크(목이 자유롭게 휘어지는 마이크)예요. 아마존에서 20달러 주고 샀습니다. 지금 우리 모두 컴퓨터한테 말을 거는 일이 점점 늘고 있잖아요. 그런데 사무실이 칸막이 없는 오픈된 구조면 그게 꽤 방해가 되거든요. 

이 마이크의 장점은 몸을 살짝 기울여서 Claude한테 속삭이듯 말할 수 있다는 거예요. "PR 3475번 머지해줘" 이렇게요. 그러면 주변에 덜 방해가 되죠. 팀원들이랑 다 같이 이 마이크를 산 게, 컴퓨터한테 말로 일을 시키는 습관을 더 들이려는 시도였어요.

Q. 하루 대부분을 Conductor 안에서 보내신다고요. 실제로 어떻게 쓰시나요?

저는 Conductor로 Conductor를 만들고 있어요. 제가 늘 하는 일은 새 작업을 계속 새로 띄우는 겁니다. Command+N을 눌러서 새 작업을 열어요. 방금 이건 저희가 준비 중인 클라우드 워크스페이스라는 기능을 살짝 미리 보여드린 거고요. 어쨌든 Command+N을 누른 다음 컴퓨터에 대고 말을 합니다. "가장 최근 Linear 이슈를 한번 보고, 어떻게 풀면 좋을지 대략 잡아줘" 이런 식으로요. 그리고 엔터를 누르면 사이드바에서 작업이 돌아가는 게 보입니다.

Claude가 일하는 동안 저는 다른 대화창으로 넘어가요. 제가 키보드 단축키에 굉장히 진심이라서, 가능한 모든 동작에 단축키를 만들어두려고 합니다. 이 경우엔 Command+Shift+Y를 눌러요. 그러면 이 워크스페이스가 머지할 준비가 됐다는 게 보입니다. 그걸 열어서 Claude가 한 작업을 빠르게 리뷰하죠. 그런데 Claude가 항상 정확히 맞게 해오는 건 아니거든요. 그럴 때는 GitHub에 코멘트 달듯이 한마디 남깁니다. "이 부분이 좀 이상한데, 이게 왜 필요해?" 이렇게요. 엔터를 누르면 다시 Claude가 작업을 시작하고, 저는 또 다른 워크스페이스로 넘어갑니다.

Q. 그 많은 워크스페이스를 동시에 굴리는 게 가능한가요?

제가 Conductor를 쓰는 방식의 큰 부분이 바로 실험이에요. 저는 항상 워크스페이스를 띄워서 여러 아이디어를 시험해봅니다. 그중 대부분은 본 코드에 들어가지 못해요. 지금 보시면 리뷰 단계에 있는 PR이 네 개 있는데, 그것 말고도 제가 그냥 한번 시도해본 잡다한 아이디어들이 진행 중인 상태로 잔뜩 있어요. 영영 빛을 못 볼 것들이죠. 그러다 마음에 드는 게 있으면 내부용 설정으로 한 단계 올라가고, 그다음엔 실험용 설정으로 또 한 단계 올라갑니다.

Q. 자리에 없을 때도 작업을 시킬 수 있나요?

네, 제가 요즘 흥미롭게 보는 게 바로 외출 중에 시키는 거예요. 휴대폰에 대고 그냥 말합니다. "테마를 해커 모드로 바꿀 수 있는 새 기능을 추가해줘." 그리고 'conduct' 버튼을 누르면 제 컴퓨터가 그 작업을 시작합니다. 이동 중에도 지휘할 수 있는 거죠.

코드를 손으로 쓰지 않는 개발

Q. 그럼 요즘도 코드를 직접 쓰시나요?

거의 안 씁니다. 아주 가끔 Tailwind 클래스를 손보거나, env 파일 하나 바꾸려고 IDE를 열 때 정도예요. 저희가 '케이브맨 모드(caveman mode)'라고 부르는 기능을 만들어뒀는데, 이걸 켜면 진짜로 키보드로 직접 타이핑해서 파일을 수정할 수 있어요. 어쩌다 한 번씩은 손으로 파일을 고쳐야 할 때가 있긴 하거든요. 그런데 이름이 괜히 '원시인 모드'가 아니에요. 그만큼 원시적인 방식이라는 거죠.

대부분의 경우 작은 수정을 하고 싶으면 그 부분을 마우스로 선택한 다음 AI한테 코멘트로 알려주거나, 아니면 그냥 컴퓨터에 대고 말합니다. "저 버튼이 좀 넓어 보이는데, 더 작게 만들어줄 수 있어?" 이런 식으로요.

Q. 작업들이 동시에 여러 개 돌아가면 상태 관리가 헷갈리지 않나요?

그래서 최근에 왼쪽에 상태 표시를 추가했어요. 작업이 시작되면 '진행 중'이 되고, PR이 만들어지면 '리뷰 중'으로 넘어가고, 머지가 끝나면 '완료' 폴더로 들어갑니다. 그리고 대시보드 페이지라는 새 개념을 도입했는데, 한곳에서 내 에이전트들이 전부 뭘 하고 있는지 보고 다음 행동으로 넘겨줄 수 있어요. 인터페이스가 어떻게 보이고 어떤 느낌이어야 하는지는 아직 이리저리 만져보는 중입니다.

저희가 그리는 이상적인 모습은, 작은 회사의 CEO가 된 것 같은 느낌이에요. 내 에이전트들이 전부 나를 위해 일하는 게 보이고, 걔네가 소화하기 좋은 보고서를 가져다주고, 방향이 틀어졌으면 제가 바로잡아 주거나, 괜찮아 보이면 그냥 머지해 넣는 거죠.

그가 매일 쓰는 도구들

Q. Conductor 말고 주로 쓰는 소프트웨어는 뭔가요?

Telegram을 꽤 많이 씁니다. 제 OpenClaw랑 대화하려고요. 이건 최근에 새로 들인 거예요. 그리고 받아쓰기는 Spokenly(맥용 받아쓰기 앱)를 씁니다. Control+Space를 누르면 뜨는 게 이거예요. 말하면 텍스트로 바꿔주는 도구인데, 클라우드 서버가 아니라 제 컴퓨터 안에서 직접 모델을 돌리고 있어요. Parakeet(엔비디아가 만든 오픈소스 음성 인식 모델)를 로컬로 돌리고 있습니다.

제 컴퓨터가 사양이 아주 좋거든요. RAM이 128기가바이트예요. Parakeet 같은 로컬 모델을 돌리려는 이유도 큽니다. 그런데 사족을 붙이자면, 최근에 MacBook Neo를 주문했어요. 그것도 가장 낮은 사양, RAM도 메모리도 제일 적은 제일 밑단 모델로요. 일부러 그렇게 샀습니다. 제 자신을 가장 낮은 사양으로 일하게 강제하려고요.

진짜 효과를 본 커스터마이징

Q. 지금도 유지하고 있는, 실제로 효과를 본 설정이 있나요?

몇 가지 있어요. 일단 저희는 스킬 파일과 CLAUDE.md에 시간을 많이 쏟았습니다. 열어보면 아마 수백 줄은 될 거예요. 안에 재미있는 내용들이 있는데, 예를 들면 이렇게 적혀 있어요. "엔지니어링 관행: 우리는 스타트업이다. 당신(AI)은 대기업식 코드를 쓰는 데 익숙하겠지만, 여기서는 그렇게 일하지 않는다." 이런 항목들을 시간을 들여 CLAUDE.md와 스킬 파일에 쌓아왔습니다.

또 뭐가 있냐면, 저는 항상 fast mode를 씁니다. 이건 기본값이 아니에요. 토큰 맥싱을 하려면 fast mode를 켜야 하거든요. 그리고 Context7 MCP도 씁니다. 문서를 가져오는 데 꽤 도움이 돼요. 그 외에는 대부분 기본 상태 그대로 씁니다.

한 가지 핵심은, 저희는 Claude를 항상 '모든 권한 자동 허용(dangerously accept all permissions)' 상태로 돌린다는 거예요. 이건 기본값이 아닌데, Conductor에서는 이게 기본 실행 방식입니다.

Q. 그렇게 AI에게 권한을 다 주면 코드가 엉망이 되지 않나요?

그래서 저희한테 정말 중요한 게, 명확한 경계를 두는 거예요. 저희는 이걸 '슬롭 프리 존(slop-free zone)'이라고 부릅니다. 슬롭은 AI가 막 찍어낸 저품질 코드를 뜻하는 말인데, 그런 코드가 들어오지 못하게 막아둔 구역이라는 거죠. 코드베이스나 문서에서 "이 부분은 사람이 직접 쓴 곳"이라고 우리가 분명히 아는 영역을 둡니다. AI가 이 슬롭 프리 존에 기여할 수는 있는데, 단 모든 줄을 사람이 직접 읽어야 해요.

이게 저희한테 꽤 도움이 됐다고 봅니다. 조심하지 않으면 AI가 악순환에 빠질 수 있거든요. 나쁜 코드를 보면 그걸 따라서 더 나쁜 코드를 써버리는 식으로요. 반대 방향, 그러니까 좋은 쪽으로도 똑같은 일이 일어날 수 있고요. 그래서 저희 코드베이스 안에는 이런 줄들이 있어요. "당신이 AI라면 이 부분은 건드리지 마라. 여기는 사람 눈으로만 볼 곳이다."

AI에게 설계를 맡기지 않는다

Q. 어디까지 사람이 직접 정하고, 어디부터 AI에게 맡기는지 궁금합니다.

저희가 자주 하는 말이 "AI를 너의 설계자로 두지 마라"예요. 예를 들어 여기 사이드바에 있는 '워크스페이스'라는 개념만 해도, 지금은 어떤 면에서는 워크트리를 감싼 껍데기에 불과하긴 해요. 물론 곧 바뀔 예정이지만요. 그래도 이 워크스페이스라는 개념 자체는 사람인 저희가 직접 고민해서 짜낸 겁니다.

또 하나는 디자인과 인터페이스 결정이에요. 왼쪽에 대화 목록을 두고, 가운데에 대화창을 두고, 오른쪽 사이드바에서 코드 변경분을 리뷰하거나 앱을 실행하는 이 구조에 저희가 정말 많은 고민을 쏟았어요. AI한테 UI 선택을 맡겨버리면, 뭔가 정성껏 빚은 느낌이 안 나는 결과물이 나옵니다. 저희한테는 그 '공들여 만든 느낌'이 정말 중요하거든요.

예를 들어 'open in' 버튼이 어떻게 동작해야 하는지를 오래 고민했어요. 지금은 비슷한 패턴을 가진 앱이 워낙 많아져서 좀 우습긴 한데요. 그때 정말 고민했던 건 상단 바에 다른  앱의 아이콘을 보여줄지 말지였어요. 처음엔 보여주는 데 꽤 반대했어요. 우리 앱 상단에서 다른 앱을 광고하는 것처럼 느껴졌거든요. 그런데 지금은 정말 마음에 들어요. 클릭하면 무슨 일이 일어날지 한눈에 보여주는 시각적 신호가 되니까요.

Q. 지금이라면 다르게 만들었을 부분도 있나요?

앱의 핵심을 사람이 직접 쓴 API와 계약(contract) 중심으로 짰을 것 같아요. AI가 그 핵심 부분에는 덜 손대게 했을 겁니다. 그러면서도 코드베이스의 큰 덩어리는 AI가 자유롭게 휘젓도록 열어두는 게 중요하다고 봐요. 온갖 아이디어를 막 던져봐도 핵심 인프라에는 영향을 주지 않는다는 걸 알 수 있게요. 지금은 그 경계가 좀 모호한 편이라, 이걸 더 명확하게 다듬는 작업을 하고 있습니다.

Q. 사용자를 일부러 불편하게 만든 부분도 있다고 들었어요.

저희한테 정말 중요한 건 프론티어(기술의 최전선)보다 살짝 앞서 있는 거예요. 사람들이 예상하는 것보다 편안함의 경계를 조금 더 밀어붙이는 거죠. Conductor를 처음 내놨을 때 받은 피드백 대부분이 이거였어요. "이건 미친 짓이다. 나는 Claude Code 하나, Codex 하나도 겨우 관리하는데 이걸 셋, 다섯 개를 어떻게 관리하냐."

그리고 저희는 일부러 파일을 직접 수정하지 못하게 만들었어요. 어떤 작업이든 반드시 워크트리가 되어야 하고, 그게 PR을 만들어야 하고, 그걸 사람이 머지해야 하도록요. 저희 워크플로우를 강하게 강제한 거죠. 지금 위치에서 신나면서도 동시에 어려운 점은, 모델이 어디로 가고 있는지에 맞춰 계속 적응해야 한다는 거예요. 그래서 지금 클라우드 쪽에 공을 많이 들이고 있습니다. 지금은 노트북을 닫으면 에이전트들이 멈추거든요. 그런데 곧 에이전트가 지금보다 10배 더 오래 돌고, 10배 더 똑똑해지고, 내 CPU 성능에 발목 잡히지 않는 환경에서 돌아가는 세상으로 빠르게 가고 있는 느낌이에요.

확신은 매일 직접 써보며 만든다

Q. Conductor는 사용자 설정이 자유롭다기보다 '이건 이렇게 써라'를 강하게 정해둔 제품 같아요. 그런 확신은 어디서 나오나요?

좋은 질문이에요. 저희 사용자들은 이것저것 직접 설정해서 쓰고 싶어 하거든요. 저도 도구가 유연해야 하고, 쓰다 보면 '내 것 같다'는 느낌이 들어야 한다고 봐요. 저희가 확신을 갖는 방법은 그냥 매일 직접 쓰는 거예요. 억지로 쓴다기보다 그냥 매일 쓰다 보니, 뭔가 안 맞으면 금방 알아챕니다.

저희는 분석 지표나 A/B 테스트 같은 걸 별로 안 봐요. 거의 직감이에요. "이게 맞는 느낌이다." 이걸 클릭했을 때 가운데에서 열리는 게 맞는 느낌이다, 하는 식이죠. 그렇게 하면 별도의 입력창이 필요 없고, 여기서 바로 메시지를 칠 수 있어서 모든 게 하나로 통합된 느낌이 듭니다.

Q. 보통 Claude Code를 기본으로 쓰시는 것 같은데, Conductor는 Codex도 지원하잖아요. Codex는 언제 쓰나요?

요즘은 오히려 Codex를 더 많이 쓰고 있어요. Codex는 일꾼 같은 존재예요. 특정 문제 하나를 끝까지 밀어붙이거든요. 도구 호출을 잔뜩 하는 걸 두려워하지 않고, 저랑 오랫동안 같이 버그를 잡아줍니다.

반면 Claude는 좀 더 주거니 받거니 하고 싶을 때 손이 갑니다. Opus는 좀 더 창의적이고, 좀 더 파트너 같은 느낌이거든요. 그래서 새 기능을 만들어나갈 때는 본능적으로 Opus에 손이 가고, "이제 그냥 일을 끝내자" 싶을 때는 Codex로 갑니다.

Q. 그냥 터미널만으로는 왜 부족한가요?

우리가 1980년대에 터미널 화면에서 그래픽 화면(GUI)으로 옮겨간 데는 이유가 있어요. 사람은 공간적이고 시각적인 존재거든요. CLI 화면은 뭔가 답답하게 느껴집니다. 그건 사람 뇌보다 AI 뇌한테 더 잘 맞는 방식인 것 같아요.

저는 그냥 "내 대화는 여기에 있고, 리뷰 패널은 여기에 있다"는 걸 알고 싶어요. 가운데에서 AI랑 대화하고요. 결국 핵심은 사람이 시각적인 존재라는 거예요. 그리고 조금 더 들여다보면, 터미널에서는 할 수 없지만 화면 인터페이스에서는 할 수 있는 일이 많기도 하고요.

토큰은 아끼지 않지만 코드 줄 수는 아낀다

Q. 토큰 맥싱 얘기를 해보죠. 하루 코드 줄 수나 한 달 지출에서 최고 기록이 얼마였나요?

가장 많이 쓴 건 Conductor를 막 시작하던 2025년 7월이었어요. 그달에 토큰 값으로 2만 2천 달러를 썼습니다. 물론 그땐 이전 세대 모델이었고요. 코드 줄 수는 그달에 수만 줄은 됐을 거예요.

저는 토큰을 쓰는 데는 정말 거침이 없어요. fast mode를 켜고, '아주 깊이 생각하기', '최고 강도'를 항상 켜두는 식으로요. 그런데 코드 줄 수에는 그렇지 않아요. 오히려 줄 수를 최소로 유지하려고 합니다. 이유는 여러 가지인데, 줄 수를 신경 쓰지 않으면 코드베이스가 순식간에 통제 불능으로 불어날 수 있거든요. 다만 이건 새 앱을 막 시작할 때냐, Conductor처럼 이미 자리 잡은 코드베이스에서 일할 때냐에 따라 완전히 다르게 생각합니다.

Q. 6개월 전과 비교하면 지금 워크플로우는 뭐가 달라졌나요?

예전엔 어려운 PR이 많았어요. 그럴 때마다 IDE를 열어서 손으로 직접 고쳤죠. 그리고 GitHub 웹사이트도 훨씬 많이 썼습니다. 지금은 그걸 훨씬 덜 써요. 코드 변경분을 Conductor 안에서 바로 리뷰할 수 있고, 필요하면 여기서 코멘트도 달 수 있으니까요. 저희는 PR마다 돌아가는 검사(check)가 많은 편인데, 그래서 최근에 검사 탭을 추가했어요. GitHub의 코멘트를 Conductor 안으로 바로 가져올 수 있게요.

남들이 아직 모르는 것

Q. 다른 사람이 Conductor로 한 일 중 가장 놀라웠던 건 뭔가요?

한 명은 Conductor의 모바일 버전을 만들었어요. 저희 기능 여러 개를 짜깁기해서요. 사실 어떻게 동작하는지 저도 잘 모르는데, IPC 호출을 우리 데스크톱 앱에 흉내 내서 보내는 식이라고 알고 있어요. 꽤 흥미롭죠.

그리고 솔직히 Garry Tan(YC 대표)이 Conductor로 뭘 할 수 있는지를 정말 많이 보여줬어요. 그가 Conductor를 한계까지 시험하고 있거든요. 그를 보면서 스킬을 얼마나 세게 밀어붙일 수 있는지를 좀 배웠습니다. 그가 만든 gstack(Garry Tan이 공개한 Claude Code 설정 모음)에서는 스킬이 아주 일급 시민 같은 존재예요. 거기엔 특히 온보딩 쪽으로 흥미로운 아이디어가 있어요. 그래서 저희는 그를 위한 전용 모드도 만들었어요. '개리 모드'라고 부르는데, 이걸 켜면 도구 호출을 하나도 접어두지 않고 다 펼쳐서 보여줍니다. 평소엔 도구 호출이 기본적으로 접혀 있거든요. 그리고 개리 모드에서는 개리의 얼굴도 볼 수 있어요.

Q. 당신과 팀에는 당연한데, 세상은 아직 잘 이해하지 못한 게 있다면요?

사람과 AI 사이의 협업에 탐구할 만한 멋진 영역이 많다고 생각해요.

서브 에이전트와 직접 대화할 수 있어야 할까?

여러 사람이 AI와 함께 같은 작업을 하는 멀티플레이어 대화가 가능해야 할까? 같은 질문들이요.

그리고 저희가 자주 쓰는 비유가 오케스트라 지휘자가 된 기분이라는 거예요. 지휘봉을 흔들면 악기들이 한데 모여 연주하고, 가끔 트럼펫 주자한테 가서 "음정이 안 맞아"라고 짚어주고, 또 현악 파트로 시선을 돌려서 "조금 더 빠르게" 하고 말하지만, 대부분의 시간은 오케스트라 전체 수준에서 지휘를 하는 거죠.

Q. 코드 자체에 대한 생각도 예전과 달라졌나요?

이제 코드는 거의 톱밥 같은 거예요. 예전엔 코드가 만들어내는 대상 그 자체였어요. 그게 구조였고, 우리는 코드를 정성껏 깎는 데 시간을 쏟았죠. 그런데 지금은 무엇을 원하는지, 그리고 그걸 어떻게 만들고 싶은지를 설명하는 데 시간을 씁니다. 그러면 코드는 그 과정에서 나오는 톱밥처럼 나와요.

여기서 흥미로운 결론들이 따라옵니다. 그중 하나는, 결국 중요한 건 당신의 프롬프트라는 거예요. 다음 세대 모델이 나오면 프롬프트를 다시 돌리기만 하면 됩니다. 그러면 새 코드가 나오고, 옛날 코드는 별로 중요하지 않았던 거죠. 세상이 이 사실에 서서히 눈뜨고 있다고 봐요.

Q. 그게 사용자에게는 어떤 모습으로 다가올까요?

저희가 가진 '프롬프트 요청(prompt request)' 기능이 이른바 '말랑한 소프트웨어(malleable software)'를 향한 초기 실험이라고 봅니다. 정해진 그대로만 쓰는 게 아니라, 사용자가 자기 입맛대로 주물러 바꿀 수 있는 소프트웨어라는 뜻이에요. 제가 이걸 떠올릴 때 늘 생각하는 비유가 비디오 게임이에요. Call of Duty 같은 게임을 하면 게임의 구조는 모두에게 똑같잖아요. 뼈대는 같아요. 그런데 각자 자기만의 스킨을 쓰거나, 재장전 속도를 빠르게 바꾸거나 할 수 있죠. 게임에 모드(mod)를 입히듯이요.

저는 사람들이 Conductor도 그렇게 모드로 손볼 수 있기를 바라요. 자기만의 워크플로우를 어느 정도 직접 짜 넣을 수 있게요. 구조는 똑같게 느껴지는 게 중요합니다. 사람들은 잘 다듬어지고 충분히 고민된 소프트웨어를 원하니까요. 하지만 게임 모드가 그 게임을 더 '내 것'처럼 느끼게 해주듯이, 소프트웨어에서도 똑같은 일이 일어날 거라고 생각합니다.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]