한 달 토큰값 2.2만 달러, 코드는 손도 안 대는 창업자의 책상

코드를 손으로 안 치는데 한 달 토큰값으로 2만 2천 달러, 우리 돈 3,400만 원을 쓴 달이 있어요. 찰리 홀츠 얘기예요. 그가 만든 'Conductor'는 맥에서 여러 AI 코딩 에이전트를 동시에 띄워놓고 지휘하게 해주는 앱인데, 정작 본인은 하루 대부분을 키보드 단축키랑 음성으로만 일합니다. 손가락으로 코드를 두드리는 일? 거의 없어요.

요즘 1인 개발자나 작은 팀에서 "Claude Code 하나도 벅찬데 여러 개를 어떻게 동시에 굴리냐"는 말이 자주 나오잖아요. 홀츠는 그걸 매일 몇 개씩 돌리는 사람입니다. 한두 개가 아니라 셋, 다섯 개를 동시에. 토큰은 거침없이 태우는 쪽이고요. Y Combinator 2024년 여름 기수 출신인 그가 자기 작업 셋업을 처음부터 끝까지 펼쳐 보였어요. AI한테 뭘 맡기고, 뭘 끝까지 사람이 쥐고 있어야 하는지에 대한 얘기까지요.

읽다 보면 묘한 지점이 하나 있어요. 토큰엔 돈을 쏟아붓는데 코드 줄 수는 한 줄이라도 아끼려 든다는 거. 모순 같죠? 근데 그 안에 이 사람의 셈법이 다 들어 있더라고요. 비싼 건 마음껏 쓰고, 싼 것처럼 보이는 건 악착같이 줄이고. 왜 그러는지는 뒤에서 풀려요.

20달러 마이크에 속삭여서 앱을 만든다

홀츠가 "없으면 못 산다"며 가장 먼저 꺼낸 물건이 구즈넥 마이크예요. 목이 자유롭게 휘어지는 그 마이크. 아마존에서 20달러 주고 샀대요. 이유가 좀 웃긴데, 지금 다들 컴퓨터한테 말을 거는 일이 늘고 있잖아요. 근데 사무실이 칸막이 없는 오픈 구조면 그게 은근 민폐거든요.

그래서 몸을 살짝 기울여 Claude한테 속삭이듯 말한다는 거예요. "PR 3475번 머지해줘" 이렇게요. 주변에 덜 거슬리게. 옆자리 동료한테 키보드 소리 대신 혼잣말이 들리는 환경이라고 생각하면 좀 웃기긴 한데, 그게 이들이 가려는 방향이에요. 팀원들이랑 다 같이 이 마이크를 산 것도, 컴퓨터한테 말로 일 시키는 습관을 더 들이려는 시도였대요. 도구를 먼저 갖춰서 행동을 바꾸는 쪽이죠.

마이크 하나에 이렇게까지 의미를 부여하나 싶지만, 이게 그의 작업 방식 전체를 압축한 물건이에요. 키보드보다 입이 먼저 움직이는 셈. 도구를 바꿔서 사람 자신을 바꾸겠다는, 이 책상의 모든 선택을 관통하는 첫 단추이기도 하고요.

Conductor로 Conductor를 만든다는 것

그는 Conductor를 Conductor로 만들어요. 늘 하는 일은 새 작업을 계속 띄우는 거고요. Command+N으로 새 작업을 연 다음, 컴퓨터에 대고 말합니다. "가장 최근 Linear 이슈를 보고, 어떻게 풀면 좋을지 대략 잡아줘" 이런 식으로. 엔터를 누르면 사이드바에서 작업이 돌아가는 게 보여요. (인터뷰 중에 준비 중인 '클라우드 워크스페이스' 기능도 슬쩍 흘리더라고요.)

Claude가 일하는 동안 그는 다른 대화창으로 넘어갑니다. 단축키에 진심인 사람이라, 가능한 모든 동작에 단축키를 박아둬요. 이 경우엔 Command+Shift+Y. 누르면 워크스페이스가 머지할 준비가 됐는지 보입니다. 열어서 Claude가 한 작업을 빠르게 리뷰하죠. 근데 Claude가 항상 정답을 들고 오는 건 아니거든요. 그럴 땐 GitHub에 코멘트 달듯이 한마디 남겨요. "이 부분 좀 이상한데, 이거 왜 필요해?" 엔터. 다시 Claude가 돌아가고, 그는 또 다른 워크스페이스로 이동. 한 작업이 끝나길 기다리며 멍 때리는 시간이 없어요. 기다리는 동안 다른 일을 보고, 그 일이 도는 동안 또 다른 일을 보고. 사람이 병목이 안 되게 흐름을 짜둔 거죠.

이게 한두 개가 아니에요. 그가 Conductor를 쓰는 방식의 큰 부분이 '실험'이거든요. 항상 워크스페이스를 띄워서 여러 아이디어를 시험하는데, 대부분은 본 코드에 못 들어가요. 인터뷰 시점에 리뷰 단계 PR이 네 개, 그 말고도 그냥 한번 던져본 잡다한 아이디어들이 진행 중인 채로 잔뜩 깔려 있었대요. 영영 빛 못 볼 것들. 그러다 마음에 드는 게 나오면 내부용 설정으로 한 칸, 다시 실험용 설정으로 또 한 칸 올라가요. 아이디어를 아끼지 않고 마구 던질 수 있는 건, 던진 게 본 코드를 망치지 않는다는 안전망이 있어서거든요. 토큰을 펑펑 쓴다는 게 이런 의미예요. 한 번 해보고 버리는 비용이 거의 0에 가까운 거죠.

자리에 없을 때도 시킵니다. 휴대폰에 대고 "테마를 해커 모드로 바꿀 수 있는 새 기능을 추가해줘" 말한 다음 'conduct' 버튼을 누르면 그의 컴퓨터가 작업을 시작해요. 이동 중에도 지휘하는 거죠. 책상 앞에 앉아 있어야만 일이 굴러가던 시절이랑은 완전히 다른 리듬이에요.

'원시인 모드'라는 이름의 자조

그럼 코드는 진짜 안 쓰냐. 거의 안 써요. 아주 가끔 Tailwind 클래스 손보거나 env 파일 하나 바꾸려고 IDE를 열 때 정도. 그래서 만든 게 '케이브맨 모드(caveman mode)'예요. 켜면 진짜로 키보드로 직접 타이핑해서 파일을 고칠 수 있어요. 어쩌다 손으로 만져야 할 때가 있으니까요. 근데 이름이 괜히 '원시인 모드'가 아니에요. 그만큼 원시적인 짓이라는 거죠. (자기 제품의 직접 편집 기능을 이렇게까지 깎아내리는 작명이라니.)

평소엔 작은 수정 하나도 그 부분을 마우스로 선택한 다음 AI한테 코멘트로 알리거나, 그냥 컴퓨터에 대고 말해요. "저 버튼이 좀 넓어 보이는데, 더 작게 해줄래?" 이렇게요. CSS 한 줄 고치는 것보다 말 한마디가 빠르다고 판단하면, 정말 말로 해버리는 거죠. 손가락이 키보드로 가는 순간을 최대한 미루는 게 이 사람의 기본 자세예요.

작업이 동시에 여러 개 돌면 헷갈리지 않냐고요? 그래서 왼쪽에 상태 표시를 붙였어요. 작업이 시작되면 '진행 중', PR이 만들어지면 '리뷰 중', 머지가 끝나면 '완료' 폴더로. 거기에 대시보드 페이지라는 개념도 새로 넣었습니다. 한곳에서 내 에이전트들이 전부 뭘 하는지 보고 다음 행동으로 넘겨줄 수 있게요. 인터페이스가 어떤 느낌이어야 하는지는 아직 만지작거리는 중이고요.

그가 그리는 이상은 작은 회사의 CEO가 된 기분이래요. 내 에이전트들이 전부 나를 위해 일하는 게 보이고, 걔네가 소화하기 좋은 보고서를 가져다주고, 방향이 틀어지면 바로잡고, 괜찮으면 그냥 머지해 넣는 거죠. 코드를 짜는 사람이 아니라, 코드를 짜는 것들을 부리는 사람. 그 전환이 이 대시보드 하나에 다 담겨 있어요.

책상 위 도구들, 그리고 일부러 산 최저 사양 맥북

Conductor 밖에서 그가 자주 쓰는 도구도 흥미로워요. Telegram을 꽤 씁니다. 자기 OpenClaw랑 대화하려고요. 받아쓰기는 Spokenly라는 맥용 앱. Control+Space를 누르면 떠요. 말하면 텍스트로 바꿔주는데, 클라우드 서버가 아니라 본인 컴퓨터 안에서 직접 모델을 돌립니다. 엔비디아가 만든 오픈소스 음성 인식 모델 Parakeet를 로컬로요.

컴퓨터 사양이 빵빵하거든요. RAM이 128기가바이트. Parakeet 같은 로컬 모델 돌리려는 이유도 커요. 음성 인식을 클라우드에 안 보내고 내 기계 안에서 돌리니, 받아쓰기가 빠르고 데이터도 밖으로 안 나가죠. 근데 사족 하나. 최근에 MacBook Neo를 주문했는데, 그것도 가장 낮은 사양, RAM도 메모리도 제일 적은 밑단 모델로 샀대요. 일부러. 자기 자신을 가장 낮은 사양으로 일하게 강제하려고요. (좋은 컴퓨터를 두고 굳이 약한 걸 사는 사람이라니.) 솔직히 이 대목에선 좀 웃었어요. 근데 곱씹어 보면 결이 같더라고요. 내 CPU에 발목 잡히는 작업 방식 자체를 버리겠다는 거. 약한 기계로도 굴러가게 만들면, 그건 클라우드에서 돌아가야 한다는 뜻이니까요.

권한은 다 주되, '슬롭 프리 존'은 사람이 지킨다

여기서 그의 셋업이 좀 세집니다. 스킬 파일과 CLAUDE.md에 시간을 엄청 쏟았대요. 열어보면 수백 줄. 안에 이런 문장이 있다는 거예요. "엔지니어링 관행: 우리는 스타트업이다. 당신(AI)은 대기업식 코드를 쓰는 데 익숙하겠지만, 여기서는 그렇게 일하지 않는다." 이런 항목들을 시간 들여 차곡차곡 쌓아온 거죠.

거기에 항상 fast mode를 켜요. 기본값이 아닙니다. 토큰 맥싱을 하려면 켜야 하거든요. 속도와 토큰 소모를 맞바꾸는 옵션인데, 그는 망설임 없이 속도를 택해요. 문서 가져오는 데는 Context7 MCP도 씁니다. 꽤 도움이 된다고요. 나머지는 대부분 기본 상태 그대로 쓰고요. 그리고 핵심 하나. Claude를 항상 '모든 권한 자동 허용(dangerously accept all permissions)' 상태로 돌립니다. 이것도 기본값이 아닌데, Conductor에서는 이게 기본 실행 방식이에요.

권한을 다 주면 코드가 엉망 되지 않냐. 그래서 명확한 경계가 중요하다는 거예요. 그게 '슬롭 프리 존(slop-free zone)'입니다. 슬롭은 AI가 막 찍어낸 저품질 코드를 뜻하는 말인데, 그런 게 못 들어오게 막아둔 구역. 코드베이스나 문서에서 "여긴 사람이 직접 쓴 곳"이라고 분명히 아는 영역을 둬요. AI가 이 구역에 기여할 순 있는데, 단 모든 줄을 사람이 직접 읽어야 합니다. 코드베이스 안엔 이런 줄이 박혀 있대요. "당신이 AI라면 이 부분은 건드리지 마라. 여기는 사람 눈으로만 볼 곳이다."

왜 이렇게까지 하냐면, 조심하지 않으면 AI가 악순환에 빠지거든요. 나쁜 코드를 보면 그걸 따라 더 나쁜 코드를 써버리는 식으로. 좋은 쪽으로도 똑같이 일어나고요. 그러니 사람이 직접 쓴 좋은 영역을 박아두는 게 닻 역할을 하는 셈이죠. 권한을 다 주는 것과 경계를 또렷이 긋는 것이 한 세트라는 게 핵심이에요. 둘 중 하나만 하면 무너지거든요. 권한만 주면 슬롭이 쌓이고, 경계만 그으면 속도가 안 나니까. 이게 도움이 됐다고 그는 봅니다.

"AI를 너의 설계자로 두지 마라"

그가 자주 한다는 말. "AI를 너의 설계자로 두지 마라." 사이드바의 '워크스페이스'라는 개념만 해도 지금은 워크트리를 감싼 껍데기에 가깝긴 해요. 곧 바뀔 거지만요. 그래도 이 개념 자체는 사람인 본인들이 직접 고민해서 짜낸 거래요.

디자인과 인터페이스 결정도 마찬가지. 왼쪽에 대화 목록, 가운데에 대화창, 오른쪽 사이드바에서 코드 변경분을 리뷰하거나 앱을 실행하는 이 3분할 구조에 정말 많은 고민을 쏟았다고 합니다. AI한테 UI 선택을 맡겨버리면, 뭔가 정성껏 빚은 느낌이 안 나는 결과물이 나오거든요. 그 '공들여 만든 느낌'이 이들한테는 진짜 중요해요. 작동만 하는 것과 잘 만든 것 사이의 그 미묘한 차이를, AI는 아직 못 메운다는 거죠.

'open in' 버튼이 어떻게 동작해야 하는지를 오래 붙들었대요. 지금은 비슷한 패턴 앱이 많아져서 좀 우습긴 한데, 그때 진짜 고민은 상단 바에 다른 앱 아이콘을 보여줄지 말지였어요. 처음엔 반대가 심했죠. 우리 앱 상단에서 남의 앱을 광고하는 것처럼 느껴졌으니까요. 근데 지금은 마음에 든대요. 클릭하면 무슨 일이 일어날지 한눈에 보여주는 시각적 신호가 되니까요. 버튼 하나에 이 정도 시간을 쏟는 게 비효율 같지만, 그게 바로 AI한테 못 맡기는 영역이라는 거. AI는 "동작하는 버튼"은 금방 만들지만, "왜 이 자리에 이 아이콘이어야 하는가"는 못 정하니까요.

지금이라면 다르게 했을 부분도 있어요. 앱의 핵심을 사람이 직접 쓴 API와 계약(contract) 중심으로 짰을 거래요. 그 핵심엔 AI가 덜 손대게 하고요. 대신 코드베이스의 큰 덩어리는 AI가 자유롭게 휘젓도록 열어두는 게 중요하다고 봅니다. 온갖 아이디어를 던져봐도 핵심 인프라엔 영향이 없다는 걸 알 수 있게요. 지금은 그 경계가 좀 모호해서, 더 또렷하게 다듬는 중이고요.

사용자를 일부러 불편하게 만든 이유

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

그리고 일부러 파일을 직접 수정하지 못하게 막았어요. 어떤 작업이든 반드시 워크트리가 되어야 하고, 그게 PR을 만들어야 하고, 사람이 그걸 머지해야 하도록. 워크플로우를 강하게 강제한 거죠. 불편하지만, 그 불편함이 곧 안전장치예요. 아무 파일이나 막 고치는 길을 아예 닫아버리면, 모든 변경이 리뷰와 머지를 거치게 되니까. 슬롭 프리 존이 '내용'의 경계라면, 이건 '절차'의 경계인 셈이고요.

지금 신나면서도 어려운 점은, 모델이 어디로 가는지에 계속 맞춰 적응해야 한다는 거. 그래서 클라우드 쪽에 공을 많이 들이고 있어요. 지금은 노트북을 닫으면 에이전트가 멈추거든요. 근데 곧 에이전트가 10배 더 오래 돌고, 10배 더 똑똑해지고, 내 CPU에 발목 잡히지 않는 환경으로 빠르게 가는 느낌이래요. 최저 사양 맥북을 산 게 괜한 짓이 아니었던 거죠.

확신은 어디서 나오냐고요? 그냥 매일 직접 쓰는 거예요. 사용자들은 이것저것 직접 설정해서 쓰고 싶어 하고, 본인도 도구가 유연해야 하고 쓰다 보면 '내 것 같다'는 느낌이 들어야 한다고 봐요. 근데 확신을 만드는 방법은 단순합니다. 억지로가 아니라 그냥 매일 쓰다 보니, 뭔가 안 맞으면 금방 알아챈다는 거. 분석 지표나 A/B 테스트는 별로 안 봐요. 거의 직감. "이게 맞는 느낌이다." 클릭했을 때 가운데에서 열리는 게 맞는 느낌이다, 하는 식이죠. 그렇게 하면 별도 입력창이 필요 없고, 여기서 바로 메시지를 칠 수 있어서 모든 게 하나로 통합된 느낌이 든다고요. 데이터로 의사결정하는 시대에 "직감"이라니 좀 의외인데, 매일 자기 제품의 첫 번째 사용자로 사는 사람만 할 수 있는 말이긴 해요.

Codex는 일꾼, Opus는 파트너

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

반면 Claude는 좀 더 주거니 받거니 하고 싶을 때 손이 가요. Opus는 더 창의적이고 파트너 같은 느낌이거든요. 그래서 새 기능을 만들어나갈 땐 본능적으로 Opus, "이제 그냥 일을 끝내자" 싶을 땐 Codex. 같은 일을 시키는 게 아니라, 일의 성격에 따라 도구를 갈라 쓰는 거예요. 발산이 필요한 단계엔 파트너를, 수렴이 필요한 단계엔 일꾼을. Conductor가 Claude Code와 Codex를 둘 다 품는 이유도 여기 있고요.

그럼 터미널만으로는 왜 부족할까요? 그의 답이 좋아요. 우리가 1980년대에 터미널 화면에서 GUI로 옮겨간 데는 이유가 있다는 거예요. 사람은 공간적이고 시각적인 존재거든요. CLI 화면은 답답하게 느껴지고, 그건 사람 뇌보다 AI 뇌한테 더 잘 맞는 방식 같다고요. "내 대화는 여기 있고, 리뷰 패널은 여기 있다"는 걸 눈으로 알고 싶다는 거죠. 결국 핵심은 사람이 시각적인 존재라는 거. 터미널에선 못 하지만 화면 인터페이스에선 할 수 있는 일도 많고요. AI 시대에 오히려 GUI가 더 중요해진다는 역설이, 곱씹을수록 묘해요.

토큰은 펑펑, 코드 줄 수는 짠돌이

이제 그 모순 같던 셈법. 가장 많이 쓴 건 Conductor를 막 시작하던 2025년 7월이에요. 그달 토큰값으로 2만 2천 달러. 물론 그땐 이전 세대 모델이었고요. 코드 줄 수는 그달에 수만 줄은 됐을 거래요. 그는 토큰 쓰는 데 진짜 거침이 없어요. fast mode 켜고, '아주 깊이 생각하기', '최고 강도' 항상 켜두는 식.

근데 코드 줄 수엔 정반대예요. 오히려 최소로 유지하려 합니다. 줄 수를 신경 안 쓰면 코드베이스가 순식간에 통제 불능으로 불어나거든요. AI한테 마음껏 짜라고 해두면 코드는 금방 늘어나는데, 그 늘어난 코드를 결국 사람이 떠안아야 하니까요. 다만 이것도 새 앱을 막 시작할 때냐, Conductor처럼 이미 자리 잡은 코드베이스에서 일할 때냐에 따라 완전히 다르게 생각한대요. 막 시작하는 앱이면 줄 수는 별로 안 따지고, 이미 굴러가는 제품이면 한 줄 한 줄을 깐깐하게 본다는 거죠. 토큰엔 후하고 줄 수엔 박한 이유가 여기 있어요. 토큰은 한번 쓰고 마는 비용이지만, 코드는 두고두고 짊어지는 부채라는 거.

6개월 전이랑 비교하면요? 예전엔 어려운 PR이 많아서 그때마다 IDE 열고 손으로 고쳤어요. GitHub 웹사이트도 훨씬 많이 썼고요. 지금은 그걸 확 줄였습니다. 코드 변경분을 Conductor 안에서 바로 리뷰하고, 필요하면 거기서 코멘트도 다니까요. 외부 도구를 오가던 일이 한 화면 안으로 빨려 들어온 거죠. PR마다 돌아가는 검사가 많은 편이라, 최근엔 검사 탭도 추가했어요. GitHub 코멘트를 Conductor 안으로 바로 끌어올 수 있게. 점점 더 많은 작업이 이 앱 한 군데로 모이는 방향이에요.

코드는 톱밥이다

남들이 Conductor로 한 일 중 가장 놀라웠던 건, 누가 모바일 버전을 만든 거래요. 기능 여러 개를 짜깁기해서요. 본인도 어떻게 동작하는지 잘 모르는데, IPC 호출을 데스크톱 앱에 흉내 내서 보내는 식이라고 알고 있대요. 만든 사람도 모르는 방식으로 쓰이는 제품. 그게 좀 흥미롭죠. 그리고 솔직히 Garry Tan(YC 대표)이 Conductor로 뭘 할 수 있는지를 정말 많이 보여줬다고 합니다. 그가 Conductor를 한계까지 시험하고 있거든요. 그를 보면서 스킬을 얼마나 세게 밀어붙일 수 있는지를 배웠대요. 그가 공개한 gstack(Garry Tan이 공개한 Claude Code 설정 모음)에선 스킬이 아주 일급 시민 같은 존재예요. 특히 온보딩 쪽으로 흥미로운 아이디어가 있고요. 그래서 아예 그를 위한 전용 모드도 만들었어요. '개리 모드'라고 부르는데, 켜면 도구 호출을 하나도 접어두지 않고 다 펼쳐서 보여줍니다. (평소엔 도구 호출이 기본적으로 접혀 있거든요.) 그리고 개리 모드에선 개리의 얼굴도 볼 수 있어요. 사용자 한 명을 위해 모드를 따로 파는 회사라니, 좀 귀엽기도 하고요.

세상이 아직 잘 모르는 게 뭐냐는 질문엔, 사람과 AI 사이 협업에 탐구할 영역이 많다고 했어요. 서브 에이전트와 직접 대화할 수 있어야 할까? 여러 사람이 AI와 함께 같은 작업을 하는 멀티플레이어 대화가 가능해야 할까? 같은 질문들. 아직 정답이 없는 질문들이라는 게 핵심이에요. 다들 에이전트 하나 잘 굴리는 데까지는 와 있는데, 여러 사람과 여러 에이전트가 한 작업 위에서 부대끼는 그림은 아무도 제대로 안 그려봤거든요.

그가 자주 쓰는 비유가 오케스트라 지휘자예요. 지휘봉을 흔들면 악기들이 모여 연주하고, 가끔 트럼펫 주자한테 가서 "음정 안 맞아" 짚어주고, 현악 파트로 시선 돌려 "조금 더 빠르게" 하지만, 대부분의 시간은 오케스트라 전체 수준에서 지휘하는 거죠. 제품 이름이 왜 Conductor인지 여기서 딱 떨어지죠. 한 악기를 직접 연주하는 사람이 아니라, 전체를 듣고 방향을 잡는 사람.

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

결국 톱밥. 여기서 흥미로운 결론이 따라옵니다. 중요한 건 당신의 프롬프트라는 거. 다음 세대 모델이 나오면 프롬프트를 다시 돌리기만 하면 됩니다. 그러면 새 코드가 나오고, 옛날 코드는 별로 중요하지 않았던 거죠. 세상이 이 사실에 서서히 눈뜨고 있다고 봐요. 아까 코드 줄 수를 왜 그렇게 아끼는지 의문이었잖아요. 답이 여기 있어요. 코드가 톱밥이면, 톱밥은 적을수록 좋은 거니까. 진짜 자산은 무엇을 어떻게 만들지 적어둔 프롬프트지, 그 결과물로 떨어진 코드 더미가 아니라는 거예요.

게임에 모드 입히듯, 소프트웨어도

그게 사용자한테는 어떤 모습일까요. 그는 Conductor의 '프롬프트 요청(prompt request)' 기능이 이른바 '말랑한 소프트웨어(malleable software)'를 향한 초기 실험이라고 봐요. 정해진 그대로만 쓰는 게 아니라, 사용자가 자기 입맛대로 주물러 바꿀 수 있는 소프트웨어라는 뜻이에요.

이걸 떠올릴 때 늘 비디오 게임을 생각한대요. Call of Duty 같은 게임은 구조가 모두에게 똑같잖아요. 뼈대는 같아요. 근데 각자 자기만의 스킨을 쓰거나 재장전 속도를 빠르게 바꾸거나 할 수 있죠. 게임에 모드를 입히듯이. 앞서 사용자들이 이것저것 직접 설정해서 쓰고 싶어 한다고 했잖아요. 그 욕구에 대한 답이 바로 이 '모드' 개념이에요. 그는 사람들이 Conductor도 그렇게 모드로 손볼 수 있기를 바라요. 자기만의 워크플로우를 어느 정도 직접 짜 넣을 수 있게요.

단, 구조는 똑같게 느껴지는 게 중요합니다. 사람들은 잘 다듬어지고 충분히 고민된 소프트웨어를 원하니까요. 그래서 뼈대는 만든 사람이 책임지고, 그 위에서 각자 입맛대로 모드를 얹는 그림이에요. 게임 모드가 그 게임을 더 '내 것'처럼 느끼게 해주듯, 소프트웨어에서도 똑같은 일이 일어날 거라고 그는 생각해요.

20달러 마이크에 속삭여 앱을 만드는 사람이 그리는 다음 그림이, 결국 "내가 손댈 수 있는 소프트웨어"라는 게 좀 의외였어요. 코드는 톱밥처럼 흘려보내고 프롬프트만 쥐겠다던 사람이, 정작 사용자한테는 끝까지 손댈 자리를 남겨주겠다는 거잖아요. AI한테 다 맡기는 듯 보이지만, 설계도 디자인도 절차도 결국 사람 손에 남겨두는 그 일관됨. 그게 이 책상의 진짜 메시지예요.