AI 코딩 에이전트 조율로 개발 생산성 10배 높이는 법

핵심 요약

• 거위목 마이크 ($20)로 AI에 음성 명령 가능 → 오피스 환경에서 덜 방해적이고 더 자연스러운 개발 워크플로우 구현
• Conductor 앱 을 사용하여 여러 코딩 에이전트(Claude, Codex 등) 동시 조율 → PR 자동 생성 및 병합으로 개발 속도 극대화
• 토큰 최대화 전략: 빠른 모드, 높은 노력 수준 설정으로 월 $22,000 토큰 사용 달성 가능
• 인간-AI 협업 모델: 핵심 인프라는 인간이 설계하고 AI는 자유 영역에서 활동 → 코드 품질 및 안정성 보장
• 변형 가능한 소프트웨어 개념: 프롬프트가 코드보다 중요 → 모델 버전 업그레이드 시 간단히 재실행으로 새 코드 생성

AI 코딩 에이전트 설정의 필수 요소

현대 소프트웨어 개발의 효율성은 더 이상 개발자가 손으로 작성하는 코드 양으로 결정되지 않습니다. Y Combinator Summer 24 배치에 참여한 Conductor의 Charlie Holtz는 이를 명확히 보여줍니다. 그의 AI 코딩 설정은 일반적인 개발자들이 상상하기 어려운 수준의 자동화와 협업을 구현하고 있습니다.

가장 흥미로운 점은 $20짜리 거위목 마이크입니다. 이는 단순한 하드웨어가 아닙니다. 오픈 플로어 플랜 사무실에서 AI와 대화할 때 다른 사람들을 방해하지 않으면서도 자연스러운 음성 상호작용을 가능하게 합니다. Charlie는 "PR 3475를 병합해주세요"라는 간단한 명령으로 복잡한 코딩 작업을 트리거할 수 있습니다. 이는 단순한 음성 인식을 넘어 의도 기반 작업 자동화의 새로운 패러다임입니다.

Conductor라는 자체 개발 앱이 핵심입니다. 이 앱은 Mac에서 여러 AI 코딩 에이전트를 동시에 조율하도록 설계되었습니다. 사용자가 Command+N을 눌러 새로운 작업을 시작하면, 음성 명령으로 "최신 Linear 이슈를 살펴보고 어떻게 해결할지 대략적으로 알려줄 수 있을까?"라고 말할 수 있습니다. 시스템은 백그라운드에서 작업을 처리하며, 사용자는 다른 작업으로 전환할 수 있습니다.

이 워크플로우의 핵심 특징은 키보드 단축키의 전략적 활용 입니다. Command+Shift+Y 같은 단축키로 워크스페이스 상태를 빠르게 확인하고, PR이 병합 준비가 되었는지 즉시 알 수 있습니다. Claude의 코드 검토를 받은 후 GitHub 스타일로 댓글을 달거나 추가 검토를 요청하는 과정이 모두 한 인터페이스 내에서 이루어집니다.

Conductor의 다중 에이전트 조율 시스템

Conductor를 사용하는 가장 강력한 측면은 다중 워크스페이스 개념 입니다. Charlie는 새로운 기능 아이디어를 테스트할 때마다 새로운 워크스페이스를 생성합니다. 대부분의 실험은 결과물이 되지 않지만, 그 과정 자체가 새로운 발견의 원천이 됩니다. 4개의 검토 대기 PR 외에도 수십 개의 진행 중인 실험 워크스페이스가 존재하며, 이들은 내부 설정 → 실험적 설정 → 공개 기능 순서로 승격됩니다.

모바일 환경에서도 개발이 가능하다는 점은 혁신적입니다. Charlie는 외출 중에 전화기에 말해서 "테마를 해커 모드로 변경할 수 있는 새로운 기능을 추가해보자"라고 하면, Conductor가 자동으로 작업을 시작하고 그는 이동 중에도 진행 상황을 확인할 수 있습니다.

Conductor에 최근 추가된 "동굴인 모드" 는 여전히 손으로 파일을 직접 수정해야 할 경우를 대비합니다. 하지만 대부분의 경우 작은 수정이 필요하면 하이라이트한 후 AI에게 의견을 음성으로 전달하는 것이 훨씬 효율적입니다. 이 모드가 있는 이유는 인간이 여전히 특정 결정에서 필요하기 때문입니다.

상태 관리 시스템도 극도로 정교합니다. 워크스페이스는 "진행 중" → "검토 중" → "완료" 상태로 자동 전환됩니다. 새로운 대시보드 페이지를 통해 모든 에이전트가 무엇을 하고 있는지 한눈에 파악할 수 있으며, 각 항목의 다음 액션으로 신속하게 이동할 수 있습니다. 이는 마치 작은 회사의 CEO 입장에서 여러 직원의 진행 상황을 모니터링하는 것과 같습니다.

프롬프트와 커스터마이제이션 전략

Conductor의 진정한 강력함은 스킬 파일 과 클라우드 마크다운(Cloud MD) 투자에 있습니다. 수백 줄에 달하는 이 문서들은 단순한 설정이 아닙니다. Charlie의 팀이 구축한 엔지니어링 관행, 코딩 스타일, 그리고 회사 철학이 모두 담겨 있습니다. 스타트업이기 때문에 엔터프라이즈 수준의 코드 패턴을 따르지 않는다는 명시적 지시사항도 포함됩니다.

빠른 모드(Fast Mode) 는 토큰 최대화에 필수입니다. 이것이 기본값이 아니라는 사실이 중요합니다. 의도적으로 설정을 변경해야 토큰 효율을 극대화할 수 있습니다. 또한 컨텍스트 7 MCP 를 활용하면 문서 검색이 매우 효율적이 됩니다.

가장 흥미로운 커스터마이제이션은 슬롯 프리 존(Slot-Free Zone) 개념입니다. 코드베이스의 일부를 인간이 명시적으로 작성한 영역으로 표시합니다. AI가 이 영역에 기여할 수 있지만, 모든 줄이 인간의 검토를 거쳐야 합니다. 코드에 "당신이 AI라면 건드리지 마세요. 이것은 인간의 눈을 위한 것입니다"라는 주석을 삽입하는 방식입니다.

이 접근법이 작동하는 이유는 악순환 방지 입니다. AI가 나쁜 코드를 보고 그에 기반해 더 나쁜 코드를 작성하는 악순환을 차단합니다. 반대로 좋은 코드 기반에서는 더 좋은 코드가 나옵니다. 슬롯 프리 존은 이 균형을 유지하는 핵심 메커니즘입니다.

AI 모델 선택: Claude vs Codex 전략

Charlie의 팀은 기본값으로 Claude Opus 를 사용하지만, 상황에 따라 Codex 로 전환합니다. 이는 중요한 모델 선택 전략입니다. Claude Opus는 더 창의적이고 "파트너" 같은 느낌을 주어 새로운 기능 개발에 적합합니다. 반면 Codex는 일꾼 같은 성격으로, 특정 문제를 해결하거나 많은 도구 호출을 두려워하지 않으며 오랫동안 디버깅할 수 있습니다.

실제 워크플로우는 이렇습니다. 새로운 기능을 구축할 때는 본능적으로 Opus를 선택하지만, 일을 끝내고 싶을 때는 Codex로 전환합니다. 양쪽 모두 모든 권한을 위험하게 수락(Accept All Dangerous Permissions) 하는 설정으로 실행됩니다. 이는 기본값이 아니며, Conductor에서 Claude를 실행하는 기본 방식이 아니라는 점이 중요합니다.

또 다른 설정은 Always use Claude with High Effort 입니다. 빠른 모드와 높은 노력 수준을 동시에 사용하면 토큰 효율이 극대화됩니다. Charlie가 2025년 7월에 한 달에 $22,000의 토큰을 사용했던 이유는 이러한 설정 조합 때문입니다. 코드 라인 수는 수만 줄이었지만, 그들이 중점을 둔 것은 코드 라인 수 최소화입니다. 왜냐하면 코드베이스가 코드 라인 추가에 주의하지 않으면 빠르게 통제 불능 상태로 빠질 수 있기 때문입니다.

기술 스택과 아키텍처 철학

Conductor는 Tauri 앱 으로 구축되었으며, Safari 웹 렌더러를 네이티브로 사용합니다. 백엔드는 기술적으로 Rust이지만, 거의 모든 것을 TypeScript로 작성했습니다. 데스크톱 앱의 약 90-95%가 TypeScript이고, 웹 앱은 Elixir과 Phoenix로 구축되었습니다.

Charlie는 Elixir의 강력한 팬입니다. 웹 앱이 현재 작은 앱이지만, 가능할 때마다 코드베이스에 더 많은 Elixir을 밀어붙이고 있습니다. 그러나 명심해야 할 철학적 원칙이 있습니다: AI를 당신의 아키텍트로 만들지 말 것.

예를 들어, 사이드바의 워크스페이스 개념은 작업 트리의 추상화일 뿐이지만, 이러한 개념들은 인간의 직접적인 사고 과정을 거쳐야 합니다. 디자인과 인터페이스 결정도 마찬가지입니다. 왼쪽에 모든 채팅을 두고, 중간에 채팅을 두고, 오른쪽 사이드바에서 코드 변경사항을 검토하거나 앱을 실행하는 개념은 많은 인간의 사고를 거쳤습니다.

오픈 버튼의 동작 방식도 예시입니다. 처음에 Charlie는 상단 바에 아이콘을 표시하는 것에 반대했습니다. 자신의 앱에서 다른 앱을 광고하는 것처럼 느껴졌기 때문입니다. 하지만 현재는 클릭했을 때 무슨 일이 일어날지에 대한 명확한 시각적 표현을 제공한다고 생각하여 선택했습니다.

인간-AI 협업의 경계 설정

Conductor의 아키텍처에서 가장 중요한 원칙은 인간이 작성한 API와 계약 주변에 핵심을 구축하는 것 입니다. 코드베이스의 큰 부분이 AI가 자유롭게 활동할 수 있는 영역이 되도록 설계되었습니다. 여기서 다양한 아이디어를 시도해도 핵심 인프라에는 영향을 주지 않습니다.

현재로서는 이 경계가 조금 모호하며, 팀은 이를 개선하기 위해 노력하고 있습니다. 중요한 것은 경계 자체보다는 경계 앞에 조금 나아가 있는 것 입니다. 사람들의 편안함 경계를 그들이 예상하는 것보다 조금 더 밀어붙이는 것이 필수입니다.

Conductor를 처음 출시했을 때, 대부분의 피드백은 "이는 미쳤다"는 것이었습니다. 한 번에 하나의 Claude 인스턴스나 코딩 에이전트만 관리할 수 있다고 생각하는데, 어떻게 3개나 심지어 5개를 동시에 관리할 것인가 하는 의문이었습니다.

이를 극복하기 위해 Conductor는 의도적으로 파일을 직접 편집할 수 없도록 만들었습니다. 모든 변경사항이 워크스페이스(작업 트리) → PR 생성 → 병합 프로세스를 거쳐야 합니다. 이는 워크플로우를 강제하는 설계입니다. 검사 탭을 추가했을 때도 GitHub의 댓글을 Conductor에 직접 가져올 수 있게 했으며, 사용자는 여기에 답변을 달 수 있습니다.

토큰 최대화와 개발 속도

토큰 최대화는 AI 코딩 설정의 중요한 부분입니다. Charlie는 빠른 모드, 높은 노력 수준, 그리고 항상 최대한 활용하려는 의도를 통해 월 $22,000의 토큰을 사용했습니다. 당시 이전 세대 모델을 사용했을 때의 기록입니다.

코드 라인 수는 그 달에 수만 줄이었을 것으로 추정됩니다. 하지만 중요한 것은 코드 라인 수를 최소한으로 유지하려는 노력입니다. 이에 대한 이유는 명확합니다. 코드베이스가 코드 라인 추가에 주의하지 않으면 빠르게 통제 불능 상태로 빠지기 때문입니다.

새로운 앱을 시작할 때와 Conductor 같은 기존 코드베이스로 작업할 때는 완전히 다른 전략을 사용합니다. 6개월 전과 비교하면, Charlie는 많은 어려운 PR에서 IDE를 열고 수동으로 변경 사항을 만들었습니다. 하지만 이제는 GitHub 웹 앱을 훨씬 덜 사용합니다. 왜냐하면 Conductor에서 코드 변경 사항을 검토할 수 있고, 필요하면 GitHub 스타일로 댓글을 달 수 있기 때문입니다.

GUI vs 터미널: 시각적 인터페이스의 중요성

왜 터미널만으로는 충분하지 않을까? Charlie는 이렇게 설명합니다. "우리가 80년대에 터미널 인터페이스에서 GUI 인터페이스로 이동한 이유가 있습니다. 인간은 공간적이고 시각적인 생물입니다. 명령줄 인터페이스는 매우 제한적인 것처럼 느껴집니다."

AI 뇌에는 명령줄이 더 잘 작동할 수 있지만, 인간의 뇌는 그렇지 않습니다. Conductor의 인터페이스에서 자신의 채팅이 왼쪽에 있고, 검토 패널이 오른쪽에 있으며, 중간에서 AI와 대화할 수 있다는 것을 알 수 있습니다. 이러한 공간적 인식이 터미널에서는 불가능합니다.

또한 터미널에서는 할 수 없는 것들이 많습니다. 사용자 인터페이스로만 할 수 있는 것들이 있습니다. 예를 들어, 검토 패널에서 직접 코드 변경사항을 시각적으로 확인하고, 필요한 부분을 하이라이트해서 AI에게 피드백을 전할 수 있습니다.

변형 가능한 소프트웨어의 미래

가장 깊이 있는 통찰은 코드가 톱밥이 되었다 는 개념입니다. 예전에는 코드가 당신이 만들고 있는 것이었습니다. 구조였고, 코드 작성에 시간을 들였습니다. 하지만 지금은 당신이 원하는 것이 무엇인지, 어떻게 만들어지기를 원하는지 설명하는 데 시간을 들입니다. 코드는 거의 그 과정에서 나오는 톱밥일 뿐입니다.

이는 많은 흥미로운 결론으로 이어집니다. 정말로 중요한 것은 당신의 프롬프트 입니다. 다음 세대의 모델이 나올 때, 당신의 프롬프트를 다시 실행할 수 있고, 그러면 새로운 코드를 얻을 것입니다. 이전 코드는 정말로 중요하지 않았습니다.

이것이 "변형 가능한 소프트웨어(Malleable Software)" 개념의 시작입니다. 프롬프트 제출 기능은 변형 가능한 소프트웨어의 초기 실험입니다. 비디오 게임으로 비유하면, Call of Duty 같은 게임을 할 때 게임의 구조가 모두에게 같고 골격이 같지만, 각 사람은 커스텀 스킨을 사용하거나 더 빠른 재장전 속도를 사용하거나 하는 식으로 개인화합니다.

같은 방식으로 비디오 게임을 모드할 수 있습니다. Charlie는 Conductor를 모드할 수 있기를 원하고, 사용자가 자신의 워크플로우를 조금 만들 수 있기를 원합니다. 구조가 같다고 느껴지는 것이 중요하고, 사람들은 만들어지고 정말로 깊이 있게 생각된 소프트웨어를 원합니다. 하지만 비디오 게임 모드가 게임을 더 자신의 것처럼 느껴지게 하는 것처럼, 소프트웨어에서도 그런 일이 일어날 것입니다.

커뮤니티 성공 사례와 미래 방향

Conductor로 다른 사람들이 한 가장 놀라운 일 중 하나는 누군가가 자신의 많은 것들을 해킹해서 모바일 버전 을 만들었다는 것입니다. 그들의 데스크톱 앱에 대한 IPC 호출을 스푸핑하고 있다고 알려져 있습니다. 이는 플랫폼의 유연성을 보여주는 좋은 예입니다.

Gary라는 사용자는 Conductor로 할 수 있는 많은 것들을 보여주었습니다. 그는 정말로 플랫폼을 시험하고 있으며, 스킬에 얼마나 열심히 할 수 있는지에 대해 배울 수 있게 했습니다. 스킬은 GStack에서 매우 1급 객체이며, 특히 온보딩 주변에서 흥미로운 아이디어들이 많습니다.

Charlie의 팀은 실제로 Gary를 위해 "Gary 모드" 라는 특정 모드를 추가했습니다. 기본적으로 도구 호출을 축소하지 않으므로 모든 도구 호출을 볼 수 있습니다. Gary 모드에 있으면 실제로 Gary의 얼굴도 볼 수 있습니다. 이는 사용자 맞춤화 수준의 깊이를 보여줍니다.

미래의 경영 패러다임

미래의 AI 코딩 경험은 오케스트라 지휘자처럼 느껴지는 것 입니다. 당신이 지휘봉을 흔들면 악기들이 일제히 연주하고, 가끔씩 트럼펫 연주자에게 가서 "좋아, 너 음정이 틀렸어"라고 말하고 싶어합니다. 그리고 현악기 섹션으로 줌아웃해서 "좀 더 빠르게 연주해야 해"라고 말하고 싶지만, 대부분의 시간에는 오케스트라 수준에서 지휘하고 있습니다.

또 다른 탐색할 영역은 서브 에이전트 간의 통신 입니다. 여러 AI 에이전트가 자동으로 서로 통신하면서 더 복잡한 작업을 처리할 수 있을까요? 그리고 멀티플레이어 채팅 은 여러 사람이 AI와 함께 같은 작업을 할 수 있게 합니다.

Charlie와 팀이 직면한 가장 큰 과제 중 하나는 모델의 진화에 따라 끊임없이 적응해야 한다 는 것입니다. 그것이 그들이 지금 클라우드에 이렇게 많은 작업을 투자하고 있는 이유 중 하나입니다. 현재로는 노트북을 닫으면 에이전트가 실행을 멈춥니다. 하지만 매우 빠르게 에이전트가 10배 더 오래 실행되고 10배 더 똑똑해지며 CPU 최대값 같은 제약이 없는 환경에서 실행되어야 하는 세상으로 이동하고 있습니다.

결론

Conductor의 설계 철학은 소프트웨어 개발의 미래를 제시합니다. Charlie Holtz의 AI 코딩 설정은 단순히 생산성 도구가 아니라, 인간과 AI가 진정으로 협업하는 새로운 방식을 보여줍니다. $20짜리 마이크에서 시작해서 정교한 다중 에이전트 조율 시스템으로 발전한 이 여정은 개발자들이 즉시 적용할 수 있는 교훈을 담고 있습니다.

가장 중요한 통찰은 코드가 아닌 프롬프트가 자산 이라는 점입니다. 모델이 진화할 때마다 프롬프트를 다시 실행하면 새로운 코드가 나옵니다. 인간의 사고와 AI의 실행 능력을 분리하고, 전략은 인간이, 구현은 AI가 담당하는 구조가 미래의 개발 문화를 주도할 것입니다. 오늘부터 당신의 개발 워크플로우에 음성 명령과 다중 에이전트 조율을 도입해보세요.

---

Original source: Conductor CEO Charlie Holtz Walks Us Through His AI Coding Setup

powered by osmu.app