🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Conductor CEO Charlie Holtz의 AI Coding Setup은 “코드를 직접 쓰는 개발자”보다 “여러 AI 에이전트를 지휘하고 검토·병합하는 운영자”에 가까운 개발 방식으로 이동하고 있음을 보여준다.

📌 핵심 요점

1. Conductor의 핵심 사용 방식은 여러 AI 작업 공간을 동시에 띄우고, 각 에이전트가 만든 결과를 사람이 검토·수정·병합하는 병렬 오케스트레이션이다.
2. 창업자는 음성 입력, 모바일 지시, 사이드바 상태 관리, PR 리뷰 흐름을 결합해 직접 코딩 시간을 줄이고, 작업 지시와 검토에 더 많은 시간을 쓰는 방식을 실험하고 있다.
3. AI가 코드베이스를 빠르게 확장할수록 “AI가 자유롭게 실험해도 되는 구역”과 “인간이 직접 읽고 지켜야 하는 핵심 구역”을 나누는 경계 설정이 중요해진다.
4. Conductor는 파일을 직접 편집하는 방식보다 workspace, worktree, PR, 리뷰 패널을 거치는 구조를 강하게 유도하며, 터미널보다 GUI가 다중 에이전트 관리에 더 적합하다는 관점을 제시한다.
5. 장기적으로는 코드 자체보다 프롬프트, 작업 지시, 에이전트 조율 방식이 더 중요한 자산이 될 수 있으며, 소프트웨어는 고정된 제품이 아니라 사용자별 워크플로로 확장되는 개인화된 작업 환경에 가까워질 수 있다.

🧩 배경과 문제 정의

• Conductor는 Mac에서 여러 코딩 에이전트를 동시에 띄우고 조율하는 앱이며, 창업자 Charlie Holtz는 Conductor 자체를 Conductor로 만들고 있다고 설명한다.
• 이 영상의 핵심 문제의식은 개발자가 직접 모든 코드를 쓰는 방식에서 벗어나, 여러 AI 작업 공간을 만들고 그 결과를 검토·수정·병합하는 방식으로 개발 흐름이 바뀌고 있다는 점이다.
• AI가 코드베이스를 빠르게 확장할수록 “어디까지 AI에게 맡길 것인가”, “어떤 구역은 인간이 반드시 읽고 판단해야 하는가”, “아키텍처와 UI의 최종 판단 주체는 누구인가”가 더 중요해진다.
• 터미널 중심의 에이전트 사용 방식은 여러 작업의 상태를 시각적으로 파악하고 병렬로 관리하기 어렵다는 한계가 있으며, Conductor는 이를 GUI 기반의 작업 공간·리뷰·병합 흐름으로 풀려는 제품으로 소개된다.
• 영상 후반부에서는 AI 코딩의 본질이 단순히 코드를 많이 생성하는 것이 아니라, 토큰을 적극적으로 쓰되 코드베이스를 작게 유지하고, 사람과 AI가 함께 조율하는 협업 구조를 만드는 쪽으로 이동하고 있다는 논지가 제시된다.

🕒 시간순 섹션별 상세정리

1. 음성 입력과 병렬 작업 공간 중심의 Conductor 사용 방식

• Charlie Holtz는 오픈 플랜 사무실에서 컴퓨터에 더 자주 말하기 위해 약 20달러짜리 구스넥 마이크를 사용한다고 보여준다. 이 마이크는 주변에 큰 방해를 주지 않으면서 PR 병합 같은 짧은 지시를 작은 목소리로 전달하는 장치로 쓰인다 [00:22]
• Conductor 사용 흐름은 새 작업을 계속 만들고, Linear 이슈를 보고 해결 방향의 초안을 내라고 지시한 뒤, 사이드바에서 현재 실행 중인 작업들을 확인하는 방식으로 묶인다 [00:50]
• 이 방식에서 개발자는 하나의 터미널이나 하나의 대화창에 머무르기보다, 여러 AI 작업 공간을 병렬로 띄우고 각 작업의 진행 상태를 관리하는 역할에 가까워진다 [01:05]

2. 모바일 지시, 수동 코딩 축소, 작업 상태 관리

• Holtz는 휴대폰으로 “hacker mode” 테마 기능을 추가하라고 말하고 conduct를 누르면, 컴퓨터가 해당 작업을 시작한다고 보여준다. 이동 중에도 에이전트 작업을 생성하고 실행할 수 있다는 점이 중요하다 [02:20]
• 직접 코딩은 Tailwind 클래스 수정이나 ENV 파일 변경처럼 제한적인 경우에만 남아 있으며, 파일을 키보드로 직접 바꾸는 기능은 일부러 “caveman mode”라고 불린다 [02:40]
• 이 표현은 Conductor가 지향하는 개발 흐름이 “사람이 직접 파일을 열고 계속 수정하는 방식”이 아니라, AI에게 작업을 맡기고 결과를 검토하는 방식임을 보여준다 [02:55]

3. 보조 도구와 AI 작업 환경 커스터마이징

• Telegram은 OpenClaw와 대화하는 용도로 사용되고, Spokenly는 control space로 호출하는 로컬 음성 인식 도구로 묶인다. Spokenly에서는 Parakeet 모델이 로컬에서 실행된다고 드러난다 [04:17]
• Holtz는 128GB RAM을 갖춘 고사양 컴퓨터가 Parakeet 같은 로컬 모델 실행에 도움이 된다고 드러낸다 [04:32]
• 동시에 그는 일부러 최저 사양 MacBook Neo를 주문해 낮은 스펙 환경을 강제로 경험하려 한다고 보여준다. 이는 좋은 개발자 경험이 고사양 장비에만 의존해서는 안 된다는 문제의식으로 읽힌다 [04:47]

4. 인간 검토 구역과 기술 스택의 경계

• 코드베이스와 문서에는 “slot free zones”처럼 인간이 작성했거나 인간이 모든 줄을 읽어야 하는 구역이 있다고 드러난다. AI가 기여하더라도 이 경계 안에서는 인간 검토가 필수다 [05:49]
• Holtz는 나쁜 코드가 AI에게 다시 입력되면 AI가 더 많은 나쁜 코드를 생성하는 악순환이 생길 수 있다고 드러낸다 [06:11]
• 반대로 좋은 코드가 기준으로 남아 있으면 AI도 그 기준을 따라 더 나은 방향으로 반복할 수 있다는 점이 드러난다. 따라서 AI 코딩 환경에서는 초기 품질과 검토 경계가 장기적인 코드베이스 품질에 직접 영향을 준다 [06:26]

5. AI에게 맡기지 않는 아키텍처와 UI 판단

• Holtz는 AI를 아키텍트로 두면 안 된다고 드러낸다. Conductor의 workspace 개념도 worktree 추상화에 가까운 핵심 설계 판단이며, 이는 인간이 먼저 사고해 만든 구조로 드러난다 [07:06]
• Conductor의 인터페이스는 왼쪽 채팅 목록, 가운데 대화, 오른쪽 코드 리뷰·앱 실행 패널이라는 구조를 갖고 있으며, 이 배치는 많은 고민을 거친 결과로 묶인다 [07:27]
• 그는 AI가 UI 선택을 대신하면 손으로 다듬은 느낌이 약해질 수 있다고 본다. 즉 AI는 구현과 반복에는 유용하지만, 제품의 핵심 구조와 사용감에 대한 최종 판단은 인간이 가져가야 한다는 입장이다 [07:42]

6. 의견 강한 제품 방향, 모델 선택, GUI가 필요한 이유

• Conductor는 사용자의 comfort zone을 일부러 밀어붙이는 방향을 택했다고 드러난다. 출시 초기에는 여러 Claude Code나 Codex를 동시에 관리한다는 발상이 과격하게 받아들여졌다고 드러낸다 [08:49]
• 제품은 파일을 직접 편집하지 못하게 하고, 모든 workspace가 worktree와 PR을 거쳐 병합되도록 강제한다. 이는 Conductor가 특정 개발 워크플로를 강하게 유도하는 제품이라는 점을 보여준다 [09:11]
• 이 흐름에서 GUI는 단순한 장식이 아니라 여러 에이전트의 상태, 작업 결과, 리뷰 흐름, 병합 과정을 한눈에 관리하기 위한 핵심 인터페이스로 기능한다 [09:26]

7. 토큰을 많이 쓰되 코드베이스는 작게 유지하는 운영 방식

• Holtz는 Conductor 초기인 2025년 7월에 한 달 토큰 비용이 2만2천 달러까지 올라갔다고 언급한다. 또한 이전 세대 모델 기준으로 수만 줄 규모의 코드가 생성된 적이 있다고 보여준다 [12:07]
• 그는 토큰 사용 자체를 아끼기보다 fast mode, think extra hard, high effort 같은 고강도 설정을 적극적으로 쓰는 방향을 드러낸다 [12:26]
• 다만 중요한 것은 코드 라인 수를 늘리는 것이 아니라 오히려 최소화하는 방향이라고 중요하다. AI가 많은 토큰을 쓰더라도 최종 코드베이스는 작고 명확하게 유지되어야 한다는 운영 원칙이다 [12:41]

8. 코드보다 프롬프트와 조율이 중요해지는 협업형 소프트웨어

• 사람과 AI의 협업에서는 서브에이전트와 직접 소통할 수 있는지, 여러 사람이 같은 작업에서 AI와 함께 멀티플레이어 채팅을 할 수 있는지가 핵심 질문으로 드러난다 [14:22]
• Conductor의 비유는 오케스트라 지휘에 가깝다. 대부분의 시간에는 전체 오케스트라를 조율하지만, 필요할 때는 특정 악기나 특정 섹션까지 내려가 세부 조정을 하게 된다는 설명이다 [14:35]
• 영상의 마무리 논지는 AI 코딩의 중심이 “사람이 코드를 한 줄씩 쓰는 능력”에서 “여러 AI 작업을 만들고, 검토하고, 경계를 정하고, 최종 방향을 조율하는 능력”으로 이동하고 있다는 점으로 압축된다 [14:50]

9. 코드가 부산물이 되고 프롬프트가 핵심 자산이 되는 변화

• Holtz는 대부분의 시간에는 오케스트라 전체를 지휘하듯 AI 작업을 조율하고, 필요할 때만 특정 악기나 섹션으로 내려가 세부 조정을 한다고 보여준다 [14:57]
• 그는 이제 코드가 더 이상 직접 짓는 구조물이라기보다, 원하는 것과 만드는 방식을 설명하는 과정에서 나오는 톱밥 같은 부산물에 가까워졌다고 비유한다 [15:18]
• 이 관점에서는 다음 세대 모델이 나오면 기존 코드를 붙잡기보다 프롬프트를 다시 실행해 새 코드를 얻을 수 있고, 그래서 진짜 중요한 것은 프롬프트라고 드러낸다 [15:32]

10. 각자에게 맞게 변형되는 말랑한 소프트웨어의 결론

• prompt request 기능은 사용자가 소프트웨어를 더 쉽게 바꾸는 말랑한 소프트웨어를 향한 초기 실험으로 드러난다 [15:42]
• Holtz는 비디오게임처럼 기본 구조와 뼈대는 모두에게 같지만, 각자가 스킨이나 속도 같은 요소를 바꾸며 자기 경험으로 만드는 방식을 비유로 든다 [16:02]
• 그는 Conductor도 게임을 모드하듯 각자의 워크플로를 조금씩 넣어 바꿀 수 있기를 원한다고 드러낸다 [16:08]
• 마지막 결론은 잘 설계된 공통 구조는 유지하되, 사용자가 자기만의 방식으로 소프트웨어를 변형하면서 더 자기 것처럼 느끼는 흐름이 앞으로 소프트웨어에도 일어난다는 것이다 [16:23]

🧾 결론

• 이 영상에서 Conductor는 단순한 AI 코딩 도구가 아니라, 여러 코딩 에이전트를 동시에 운영하는 “개발 지휘 인터페이스”로 제시된다.
• Charlie Holtz의 작업 방식은 개발자가 모든 코드를 직접 작성하는 모델에서 벗어나, 아이디어를 던지고 결과물을 검토하며 좋은 결과만 병합하는 모델로 이동하고 있음을 보여준다.
• 다만 그는 AI에게 모든 판단을 넘기지는 않는다. 아키텍처, UI 구조, 핵심 API 계약, 인간 검토 구역은 사람이 주도해야 한다는 선을 분명히 둔다.
• 중요한 변화는 “AI가 코드를 얼마나 많이 쓰는가”보다 “사람이 어떤 경계와 기준을 세우고, 여러 에이전트의 결과를 어떻게 조율하는가”로 옮겨가고 있다는 점이다.
• 검증이 필요한 부분: 영상에서 언급된 Conductor의 실제 제품 성능, 팀 외부 사용자에게서의 재현성, 클라우드 작업 환경 전환 계획의 구체적 일정은 이 입력만으로 단정하기 어렵다.

📈 투자·시사 포인트

• AI 개발 도구 시장은 단일 채팅형 코딩 보조에서 다중 에이전트 오케스트레이션, 리뷰, 병합, 상태 관리까지 포함하는 워크플로 플랫폼으로 확장될 가능성이 있다.
• 향후 경쟁력은 모델 자체보다 인간 검토 구역, 권한 관리, PR 흐름, 코드 품질 피드백 루프를 얼마나 제품 안에 자연스럽게 녹이느냐에서 갈릴 수 있다.
• Conductor 사례는 개발자 도구가 점점 “IDE”보다 “AI 작업 운영 대시보드”에 가까워질 수 있음을 시사한다.
• 토큰 사용량은 늘어나더라도 코드베이스를 작게 유지해야 한다는 관점은 AI 코딩 시대의 비용 관리와 유지보수 리스크 관리 모두에서 중요한 기준이 될 수 있다.
• GUI 기반 에이전트 관리, 모바일 지시, 음성 입력, 개인화된 workflow mod는 AI 개발 도구의 다음 차별화 축이 될 수 있다.
• 검증이 필요한 투자 포인트: Conductor가 실제로 넓은 개발자층에 채택될지, 터미널 중심 도구 대비 GUI 오케스트레이션이 더 큰 시장을 만들지는 추가 사용자 데이터가 필요하다.

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

• “Conductor 자체를 Conductor로 만든다”는 설명은 영상 내 창업자의 사용 사례로 제시되지만, 실제 코드베이스 전체에서 어느 정도 비중을 AI 에이전트가 작성했는지는 별도 확인이 필요하다.
• Conductor가 Claude를 dangerously accept all permissions로 실행하는 방식이 내부 워크플로의 핵심 전제라고 언급되지만, 이것이 모든 사용자에게 권장되는 설정인지, 특정 팀 내부 환경에 한정된 방식인지는 구분해 확인해야 한다.
• “2025년 7월 한 달 토큰 비용이 2만2천 달러”였다는 수치는 영상 발언 기준으로 정리된 것이며, 비용 산정 범위나 포함된 모델·실험 규모는 추가 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Conductor식 워크플로를 실험할 때는 “AI에게 자유롭게 맡길 영역”과 “인간이 모든 줄을 검토해야 하는 영역”을 먼저 문서화한다.
• 여러 코딩 에이전트를 병렬로 사용할 경우, 각 작업을 in progress, review, done처럼 상태별로 추적하는 대시보드나 보드를 만든다.
• AI가 생성한 코드가 다시 AI의 기준 데이터로 들어가는 악순환을 막기 위해, 병합 전 리뷰 기준과 코드 품질 경계를 명확히 둔다.
• 새 기능 구현은 AI에게 맡기더라도, 핵심 아키텍처·UI 구조·도메인 계약은 사람이 먼저 설계하고 판단한다.

❓ 열린 질문

• 여러 AI 에이전트를 동시에 운용할 때, 인간 개발자는 어느 시점까지 직접 코드를 읽고 어느 시점부터 결과 중심으로 검토해도 되는가?
• AI가 빠르게 코드를 늘리는 환경에서 “좋은 코드베이스”를 유지하기 위한 최소한의 인간 리뷰 경계는 어디에 두어야 하는가?
• Conductor처럼 파일 직접 편집을 제한하고 worktree와 PR 병합 흐름을 강제하는 방식은 모든 개발팀에 적합한가, 아니면 특정 성향의 팀에만 맞는가?