공장이 아니라 오케스트라다: 최고 속도로 개발하는 사람들의 일하는 방식

원제: [한영자막] 공장이 아니라 오케스트라입니다: 최고 속도로 개발하는 사람들의 일하는 방식
URL: https://www.youtube.com/watch?v=WWUxQgAZTu4
날짜: 2026-10-01
채널: Tech Bridge
발표자: Charlie Holtz (Conductor 공동창업자)
영상 길이: 16분 53초

---

메타데이터

• 콘텐츠 유형: YouTube 기술 컨퍼런스 발표 번역·심층 다이제스트
• 주제: AI 코딩 에이전트(AI coding agents), 개발 워크플로, 인간과 에이전트의 협업
• 원문 자막: 영어 자동 생성 자막을 시간순으로 정리해 한국어로 번역함
• 핵심 제품: 여러 코딩 에이전트를 동시에 관리하는 데스크톱 앱 Conductor
• 핵심 기억법: 발표자가 마지막에 Stickfo라는 기억용 약어를 제시함

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트 시대의 최고 속도 개발은 에이전트를 공장 라인처럼 끊임없이 찍어내는 일이 아니라, 사람을 중심에 둔 오케스트라를 지휘하는 일이다.==

• 최신 도구를 남들보다 늦지 않게 시험하되, 도구 자체를 만지는 일이 실제 일을 대체하지 않도록 frontier와 default 사이의 거리를 지켜야 한다.
• 에이전트에게 모든 코드를 맡기는 것이 아니라, 마이그레이션·문서·조직 지식처럼 사람이 반드시 검토할 slot-free zone을 명시하고 나머지 영역에는 넓은 자율성을 줘야 한다.
• Slack, Discord, 회의 기록, 버그 요청을 하나의 데이터베이스에 축적해 에이전트가 회사 고유의 맥락을 SQL로 조회하게 해야 한다.
• 에이전트가 노트북에 묶이지 않고 클라우드 샌드박스에서 계속 실행되며 사람·다른 에이전트와 실시간으로 협력하고 스스로 새 작업공간을 만들도록 해야 한다.

발표자는 Conductor를 만들며 가까이서 관찰한 최고의 빌더들이 공통으로 쓰는 일하는 방식을 여섯 가지 원칙으로 정리한다. 결론은 자동화율이나 토큰 사용량의 극대화가 아니라, 사람이 흐름(flow)을 느끼고 소프트웨어가 인간적으로 만들어졌다고 느끼게 하는 개발 환경을 만드는 데 있다.

0. 도입: AI 엔지니어링을 설명하자 대화가 끝난 이유

0.1. 결혼식에서 만난 사람과 AI 엔지니어링

1. 기술 바깥의 현실과 컨퍼런스의 대비

   1. 발표자는 주말에 뉴욕에서 열린 결혼식에 갔고, 그곳에는 유행을 따르는(trendy) 사람들이 많았다고 말한다.
   2. 처음 만난 사람에게 발표를 준비하고 있다고 말하자 상대는 어느 컨퍼런스인지 물었다.
   3. 발표자가 주제가 AI engineering이라고 답하자 상대의 눈빛이 흐려지고, 뒤를 돌아 다음에 대화할 사람을 찾기 시작했다.
   4. 발표자는 그 장면을 농담처럼 전하면서도, 지금 자신이 AI 엔지니어링 이야기를 듣고 싶어 하는 사람들로 가득한 방에 있다는 사실이 매우 기쁘다고 말한다.

2. Conductor 소개

   1. 발표자는 Conductor의 공동창업자다.
   2. 청중에게 Conductor를 써본 사람이 있는지 묻고, 몇 명의 반응에 “Nice”라고 답한 뒤 제품을 설명한다.
   3. Conductor는 여러 코딩 에이전트(coding agents) 팀을 동시에 관리하는 데스크톱 앱이다.
   4. Claude Code, Codex 등 코딩 에이전트마다 터미널 창을 여러 개 띄우는 대신, 하나의 인터페이스에서 모두 관리한다.

0.2. 발표의 출발점

1. 최고의 빌더를 관찰한 결과

   1. Conductor를 만들면서 발표자는 최고의 빌더들을 가까이서 보고 그들의 워크플로를 관찰했다.
   2. 무엇을 하는지뿐 아니라 무엇을 피하는지도 살펴봤다.
   3. 그 관찰을 바탕으로 조직에서 가장 빠른 빌더가 되기 위한 원칙들을 정리해 청중에게 전달하겠다고 한다.

2. 시연 화면과 원칙의 전환

   1. 발표자는 화면에 Conductor를 띄우고 청중이 보이는지 확인한다.
   2. 이어 “조직에서 가장 빠른 빌더가 되는 원칙”의 첫 번째 항목으로 넘어간다.

1. 원칙 1 — Stay Near the Frontier: 최전선 가까이에 머물기

1.1. 출시 당일 최신 도구를 시험하는 이유

1. Near the frontier의 의미

   1. 최전선 가까이에 머문다는 것은 새로운 도구와 워크플로가 나오면 거의 출시 당일에 직접 시험한다는 뜻이다.
   2. 발표자는 Ultra Code가 나오면 써보고, Slashgo가 나오면 시도해보는 식의 태도를 예로 든다.
   3. 단순히 유행을 좇는 것이 아니라, 최신 도구가 개발자가 무엇을 만들 수 있는지에 대한 상상력을 넓혀주기 때문에 중요하다.

2. 스타트업에서 생기는 제품 아이디어

   1. 스타트업을 운영한다면 최전선에 가까이 있을수록 실제로 무엇을 만들어야 하는지에 대한 새로운 아이디어를 더 많이 얻는다.
   2. Conductor 팀은 원래 Chorus라는 완전히 다른 앱을 만들고 있었다.
   3. 지난해 2월 무렵 Claude Code의 파워 유저가 된 팀은 개발 워크플로 전체를 Claude Code 중심으로 다시 만들기 시작했다.
   4. 처음에는 저장소(repo)를 다섯 번 복제해 동시에 작업했고, 이후 Git worktree를 발견했다.
   5. 이 과정이 조금씩 내부 도구로 발전했고, 결국 그 내부 도구가 Conductor가 됐다.
   6. 최신 워크플로를 실제로 사용하지 않았다면 이런 제품을 발견하고 만들 수 없었을 것이라고 강조한다.

3. 스타트업이 아닌 조직에서의 역할

   1. 스타트업을 하지 않는 사람이라면 회사 안에서 최신 개발 워크플로를 가장 잘 아는 사람이 되어야 한다.
   2. 예전에는 사회적 관계망(social graph)을 통해 좋은 워크플로에 대한 정보가 자연스럽게 전달되기를 기다려도 됐다.
   3. 하지만 변화 속도가 너무 빨라져 그런 방식으로 기다리면 늘 3~6개월 뒤처지게 된다.

1.2. 최전선에 붙어 살지 말고, 가까이에서 관찰하기

1. At the frontier의 위험

   1. 발표자는 near라는 단어가 중요하다고 반복한다.
   2. 최전선에 너무 깊이 들어가면 midw meing이라고 부르는 상태가 된다. 자막상 표기는 다소 불명확하지만, 의미는 워크플로를 만지는 데 모든 시간을 쓰고 실제 업무는 하지 않는 상태다.
   3. 최신 도구와 설정을 실험하는 일이 목적 자체가 되면, 개발 속도를 높이기는커녕 실제 결과물을 늦춘다.

2. Don't beat the market이라는 내부 휴리스틱(heuristic)

   1. Conductor 팀은 최전선을 지나치게 추격하지 말라는 원칙을 Don't beat the market이라고 부른다.
   2. 자신이 최전선 가까이에 있는지, 아니면 최신 유행에 너무 깊이 빠졌는지 판단하려면 “왜 이 워크플로가 아직 기본값(default)이 아닌가?”라고 자문해야 한다.
   3. Ralph loops가 큰 화제가 됐을 때, Ralph loops에 맞춰 워크플로를 직접 대대적으로 최적화할지 먼저 물어야 한다.
   4. Ralph loops가 모든 사람에게 통하는 방식이라면, Anthropic이나 OpenAI 같은 모델 제공자가 곧 기본 하네스(harness)에 기능으로 넣을 가능성이 높다.
   5. 모두에게 유용한 기본 기능을 직접 재구축하는 것은 시장을 이기려는 불필요한 노력에 가깝다.

3. 효율적 시장 가설과 real alpha

   1. 이 원칙은 효율적 시장 가설(efficient market hypothesis)에 비유할 수 있다.
   2. 자신만 가진 진짜 알파(real alpha)가 없다면 워크플로를 지나치게 최적화할 이유가 없다.
   3. 여기서 진짜 알파는 모델이 알기 어려운 사용자 정보나 코드베이스 고유의 정보다.
   4. Conductor는 긴 채팅을 매우 빠르게 렌더링해야 하는 채팅 앱이므로 성능이 특히 중요하다.
   5. 그래서 React Query를 최적화해 긴 채팅을 빠르게 렌더링하고, 그 목표를 위해 코드베이스의 다른 부분에서는 일정한 희생을 감수한다.
   6. 이런 제품 고유의 정보가 있다면 워크플로에 시간을 투자할 가치가 있다. 반대로 그런 알파가 없다면 최신 유행을 위해 워크플로를 개조하지 말아야 한다.

4. 도구 설정이 성과를 대체하지 않게 하기

   1. 발표자는 “멋진 Emacs 설정을 갖고 있지만 실제로는 일을 끝내지 못하는 사람”이 되지 말라고 농담한다.
   2. 좋은 워크플로의 기준은 설정의 화려함이나 토큰 사용량이 아니라, 실제 결과물을 만들어내는가다.

2. 원칙 2 — Create Slot-Free Zones: 사람이 엄격하게 지키는 구역 만들기

2.1. 모든 코드를 같은 방식으로 검토하지 않기

1. Slot-free zone의 정의

   1. Conductor에서 slot-free zone은 코드베이스나 앱 중 사람의 매우 엄격한 검토가 필요한 부분을 뜻한다.
   2. AI 에이전트가 많은 토큰을 소모하며 3만 줄짜리 PR을 쏟아내는 token maxer 조직일 것이라는 외부의 예상과 달리, Conductor는 특정 영역을 매우 조심스럽게 다룬다.
   3. 반대로 위험이 낮은 다른 영역에는 훨씬 느슨한 규칙을 적용한다.

2. 구역을 만들지 않았을 때의 비용

   1. 사람이 반드시 검토할 구역을 정하지 않으면 코드베이스가 매우 다루기 어려운 상태로 흘러갈 수 있다.
   2. Conductor 팀도 이 원칙을 지키지 않았을 때 앱 전체를 몇 차례 다시 작성해야 했다.
   3. 빠르게 많이 생성하는 것만으로는 장기적인 개발 속도를 보장할 수 없고, 핵심 경계면의 품질이 무너지면 전체 시스템을 다시 만드는 시간이 더 커진다.

2.2. 사람의 검토가 필요한 구체적인 경계

1. 데이터베이스 마이그레이션

   1. Conductor에는 마이그레이션 파일이 있다.
   2. CI에서는 마이그레이션 파일에 어떤 변경이 생겨도 반드시 사람의 리뷰를 요구한다.
   3. 데이터 구조를 바꾸는 변경은 한 번 잘못 적용되면 되돌리기 어렵기 때문에, 에이전트의 자율성보다 인간의 판단을 우선한다.

2. 사람이 쓴 조직 지식

   1. Slack에 쓰인 내용은 AI가 만든 slop이 아니라 사람이 쓴 slop-free 정보라고 간주한다.
   2. 문서, CLAUDE.md로 들리는 에이전트 지침 파일, 각종 스킬 파일에도 많은 시간을 투자한다.
   3. 자막에는 cloud MD로 표기된 부분이 있지만 문맥상 코딩 에이전트의 프로젝트 지침 문서(MD 파일)를 가리킨다.

3. 신입 인턴에게 매일 속삭이는 말의 비유

   1. 새 인턴이 회사에 들어왔다고 가정한다.
   2. 인턴이 일을 시작할 때마다 귓속말로 한마디를 해줄 수 있다면, 매일 어떤 말을 해줄지 매우 신중하게 고를 것이다.
   3. CLAUDE.md나 AGENTS.md 같은 파일은 에이전트가 일을 시작할 때마다 컨텍스트에 로드되는 정보다.
   4. 따라서 그 파일에 적는 규칙은 매번 에이전트의 판단에 영향을 주는 “반복되는 귓속말”이며, 대충 작성해서는 안 된다.

3. 원칙 3 — Feed the Beast: 에이전트에게 조직의 맥락을 먹이기

3.1. CIA라는 중앙 지식 저장소

1. Conductor Internal Agent

   1. Conductor에는 Conductor Internal Agent라는 내부 도구가 있다.
   2. 팀은 이를 줄여 CIA라고 부른다.
   3. CIA는 조직에서 일어나는 모든 일을 모으는 중앙 데이터베이스이자 내부 에이전트다.

2. 데이터가 모이는 경로

   1. Slack에 새 메시지가 올라오면 CIA가 이를 감지하고 Postgres 테이블에 저장한다.
   2. Discord에서 사용자가 버그를 요청해도 같은 방식으로 수집한다.
   3. 팀 회의는 녹화하며, 회의 기록도 CIA로 들어간다.
   4. 결과적으로 대화, 사용자 피드백, 버그, 회의 맥락이 흩어진 채 사라지지 않고 검색 가능한 조직 기억이 된다.

3.2. 정보량이 에이전트의 조직 적합성을 결정한다

1. 회사마다 다른 맥락의 축적

   1. 에이전트가 특정 회사에서 유능하게 일하려면 그 회사가 실제로 일하는 방식에 대한 정보와 맥락을 최대한 많이 가져야 한다.
   2. 일반적인 모델 지식만으로는 회사의 내부 용어, 과거 결정, 고객 불만, 팀 간 약속, 코드베이스의 예외 규칙을 알 수 없다.
   3. 따라서 정보가 들어갈 중앙 장소를 먼저 만들고, 모든 업무 흐름을 그곳으로 연결해야 한다.

2. SQL을 가진 에이전트

   1. 발표자는 이를 요약하는 트윗을 인용하며, 모든 것을 데이터베이스에 넣고 에이전트에게 SQL 도구를 주면 나머지는 에이전트가 처리하게 할 수 있다고 말한다.
   2. 핵심은 AI에게 막연히 “우리 회사 맥락을 기억해”라고 요청하는 것이 아니라, 실제 원천 데이터를 구조화하고 필요할 때 조회할 수 있게 하는 것이다.

4. 원칙 4 — Free-Range Agents: 노트북 밖에서 자유롭게 움직이는 에이전트

4.1. 죽지 않는 샌드박스와 장시간 실행

1. 에이전트에게 놀 공간 주기

   1. 에이전트가 코드를 탐색하고 어려운 작업을 시도할 수 있는 샌드박스를 제공해야 한다.
   2. 노트북을 닫는 순간 종료되지 않고 계속 살아 있는 환경이어야 한다.
   3. 에이전트가 자기 자신을 더 만들고, 다른 에이전트와 사람과 협업할 수 있는 방법도 제공해야 한다.

2. 왜 로컬 노트북이 한계가 되는가

   1. 모델은 점점 더 좋아지고 있으며, 한 번 실행된 에이전트가 더 오래 작업할 수 있게 되고 있다.
   2. 앞으로 동시에 실행되는 에이전트의 수도 늘어난다.
   3. 이들을 노트북 하나에 가두면 클라우드에서 자유롭게 움직일 때보다 훨씬 덜 효과적이다.
   4. 노트북에 종속되지 않는 샌드박스가 생기면, 그 위에 장시간 작업·협업·자동 위임 같은 새로운 기능을 만들 수 있다.

4.2. Conductor의 클라우드 샌드박스와 실시간 협업 시연

1. 새 버전의 방향

   1. 발표자는 출시를 앞둔 새 Conductor 버전을 시연한다.
   2. 새 버전은 클라우드 협업(cloud collaboration)을 중심에 둔다.
   3. 각 워크스페이스 상단에는 작은 클라우드 아이콘이 있으며, 클릭하면 에이전트가 실행 중인 샌드박스 정보를 확인할 수 있다.
   4. 발표자는 노트북을 닫아도 에이전트가 계속 실행될 수 있다고 강조한다.
   5. 그 주까지 Conductor의 모든 작업은 Git worktree 위에서 실행됐지만, 새 버전부터는 클라우드 샌드박스에서 실행되는 free-range agent가 된다.

2. 팀원의 작업을 한눈에 보는 인터페이스

   1. 발표자 자신의 작업 목록과 현재 Conductor에서 무엇을 하는지가 화면에 표시된다.
   2. 스크롤하면 Caden, Lewis, Tywin이 무엇을 작업 중인지 볼 수 있다.
   3. Jackson의 얼굴이 나타나는 UI도 보이며, 클릭하면 그가 실시간으로 무엇을 하는지 확인할 수 있다.
   4. 즉 각 작업공간은 에이전트의 실행 화면이면서 팀 전체의 진행 상황을 공유하는 협업 공간이다.

3. 협업이 중요한 이유

   1. 발표자는 이런 도구에서 협업이 가장 중요한 새 개념 중 하나지만 아직 사람들이 충분히 이야기하지 않는다고 말한다.
   2. 위대한 결과물은 개인 혼자 만들기보다 사람으로 구성된 팀이 만든다는 사실이 변하지 않는다.
   3. 모델이 좋아질수록 더 야심찬 것을 만들 수 있고, 더 야심찬 프로젝트일수록 더 많은 사람과 에이전트가 필요하다.
   4. 발표자는 Fable에서 보낸 이틀을 예로 들며, 모델의 발전으로 만들 수 있는 것의 범위가 커지고 있다고 말한다.

4. 실시간 리뷰와 메시지 교환

   1. 발표자는 Caden이 작업 중인 워크스페이스에 들어가 변경 사항을 리뷰한다.
   2. 변경 자체는 괜찮아 보이지만, “공백(spaces)이 아니라 탭(tabs)을 사용할 수 있나?”라고 메시지를 남긴다.
   3. Caden은 그 메시지를 실시간으로 볼 수 있고, 같은 워크스페이스 안에서 답장할 수도 있다.
   4. 발표자는 상대가 입력 중인 표시를 확인하며 잠시 기다린다.
   5. 입력이 길어지자 “에이전트들이 탈출했다(The agents have escaped)”라고 농담한다.
   6. 시연의 결론은 팀원과 에이전트가 같은 작업공간에서 실시간으로 작업·리뷰·대화하는 협업 워크스페이스다.

4.3. 에이전트가 스스로 작업을 생성하는 API

1. Conductor API와 OpenClaw

   1. 클라우드 샌드박스의 또 다른 장점은 에이전트에게 새 에이전트를 생성할 수 있는 API를 줄 수 있다는 점이다.
   2. 발표자는 자신의 OpenClaw를 화면에 띄우고 Lord Crandon이라는 이름을 보여준다.
   3. Lord Crandon은 Conductor API에 접근할 수 있다.

2. 전화기에서 업무를 시작하는 예시

   1. 발표자는 전화기, Telegram, Slack 등 자신이 어디에 있든 Lord Crandon에게 명령할 수 있다고 말한다.
   2. 실제 예시로 “버튼을 전부 파란색으로 만드는 새 워크스페이스를 만들어줄래?”라고 요청한다.
   3. Lord Crandon은 Conductor API를 호출해 새 워크스페이스를 만들고 그 안에서 에이전트를 작업시킨다.
   4. 발표자는 이동 중이거나 자리를 비운 동안에도 Conductor에서 워크스페이스의 설정과 진행 상황을 확인할 수 있다.
   5. 즉 사람은 작업을 직접 시작하기 위해 노트북 앞에 앉을 필요가 없고, 대화형 인터페이스에서 의도를 말하면 에이전트가 실행 환경을 만들고 업무를 시작한다.

5. 원칙 5 — Orchestras, Not Factories: 공장이 아니라 오케스트라

5.1. Software factory라는 비유에 대한 거부

1. 공장 비유가 놓치는 것

   1. 발표의 제목이자 마지막 원칙은 Orchestras, not factories다.
   2. 발표자는 software factories라는 표현을 솔직히 싫어한다고 말한다.
   3. 공장을 떠올리면 자동화, 효율성, 더 많은 물건을 만들어내는 생산라인이 연상된다.
   4. 자동화가 삶을 효율적으로 만들고 더 많은 것을 만들게 한다는 장점은 인정하지만, 앞으로의 소프트웨어가 공장이라는 이미지 위에 세워지기를 바라지는 않는다.

2. 사람이 느끼는 개발 경험

   1. 발표자는 미래에도 인간처럼 느끼고 싶고, 흐름(flow) 속에 있고 싶다고 말한다.
   2. 지휘봉을 든 오케스트라 지휘자처럼 한쪽으로 지휘하면 한 에이전트 팀이 움직이고, 다른 쪽으로 가면 인간과 에이전트가 섞인 다른 팀이 움직이는 모습을 원한다.
   3. 필요할 때는 세부 사항으로 확대해 들어가고, 대부분의 시간에는 화면에서 한 발 물러나 전체 흐름을 보고 싶다고 말한다.

5.2. 기능 공장과 라인 매니저를 거부하기

1. 에이전트 군단의 버튼 관리자라는 미래상

   1. 미래의 개발자가 에이전트 떼(swarms)를 관리하는 공장 라인 매니저가 되어 버튼을 누르고 다음 기능을 찍어내는 모습은 원하지 않는다.
   2. 발표자는 약 10년 전에도 feature factory라는 말을 사용했지만, 그런 방식은 작동하지 않았다고 지적한다.
   3. 기능의 개수와 생산 속도만 밀어붙이면 소프트웨어의 의미, 품질, 인간적 감각이 사라진다.

2. 인간 중심 도구를 만들 책임

   1. 소프트웨어는 인간적이고 정성 들여 만들어진(crafted) 느낌이어야 한다.
   2. 도구를 만드는 사람들에게는 인간을 중심에 두고 도구를 훌륭하게 만들 책임이 있다.
   3. 사용하는 언어와 비유도 중요하다. 사람을 흥분시키고, 능력을 느끼게 하고, 흐름 속에서 재미있게 일하게 하는 단어를 선택해야 한다.
   4. 어두운 공장이나 라인 매니저가 아니라, 사람과 AI 에이전트가 한 공간에서 함께 설계하는 창조적 환경을 상상해야 한다.

3. Steve Jobs와 Mac의 비유

   1. 발표자는 Steve Jobs가 뛰어난 사람들로 구성된 팀과 함께 Mac을 디자인하는 장면 같은 미래를 원한다고 말한다.
   2. 그 팀에는 인간과 AI 에이전트가 함께 있고, 사람은 방향을 정하고 세부를 판단하며 전체를 지휘한다.
   3. 이 감각이 바로 발표자가 말하는 오케스트라다.

6. 전체 원칙 정리와 마무리

6.1. 가장 빠른 빌더를 위한 원칙

1. 여섯 가지 원칙

   1. Stay near the frontier: 최신 도구를 실제로 시험하되 최전선에 매몰되지 않는다.
   2. Don't try to beat the market: 모두에게 통하는 기본 기능을 직접 재발명하지 말고, 사용자·코드베이스 고유의 real alpha에 집중한다.
   3. Create slot-free zones: 마이그레이션, 조직 문서, 핵심 지식 등은 사람이 엄격하게 검토한다.
   4. Feed the beast: Slack·Discord·회의·버그를 중앙 데이터베이스에 축적하고 에이전트에게 충분한 맥락을 제공한다.
   5. Free-range agents: 에이전트를 노트북에 가두지 않고 지속 실행 가능한 샌드박스와 협업 환경을 제공한다.
   6. Think about orchestras, not factories: 자동화 생산라인이 아니라 인간과 에이전트가 함께 창조하는 오케스트라를 설계한다.

2. 기억법과 마무리

   1. 발표자는 여섯 원칙을 기억하기 위한 약어로 Stickfo를 제시한다.
   2. 발표가 끝난 뒤 질문을 받겠다고 말하고, 행사장에 계속 머물겠으며 인터넷에서 다시 만나자고 인사한다.
   3. 실제 자막에는 별도의 청중 Q&A가 이어지지 않고, 발표자의 마무리 인사에서 영상이 끝난다.

주요 발언 모음

“Stay near the frontier.”

“Don't try and beat the market.”

“Why isn't this workflow the default?”

“Don't be the person who has an amazing Emacs setup but doesn't actually get stuff done.”

“You want your agents to have as much information and as much context as they can have about the way you specifically work.”

“Give your agents a lot of space to play.”

“The agents have escaped.”

“All great things are built with teams of people. They're not built by individuals.”

“I don't want the future to be built around factories. I want to feel like a human. I want to be in the flow.”

“I want to feel like I'm Steve Jobs designing the Mac with a team of amazing humans and AI agents all in the same place.”

핵심 데이터 & 수치

• 3~6개월: 기존 사회적 관계망을 통해 최신 워크플로 정보가 전달되기를 기다리면 뒤처질 수 있는 시간이다.
• 5개 복제본: Conductor 팀이 Claude Code 중심의 초기 워크플로에서 저장소를 다섯 번 복제해 동시에 작업했던 방식이다.
• 약 3만 줄 PR: Conductor가 실제로는 이런 대규모 PR을 무검토로 쏟아내는 조직이 아니라는 점을 설명하기 위해 든 수치다.
• 몇 차례 전체 재작성: slot-free zone을 명확히 하지 않아 앱 전체를 다시 작성해야 했던 경험이다.
• 16분 53초: 영상 전체 길이다.
• 출시 주간: 발표 시점의 새 Conductor 버전은 클라우드 샌드박스와 실시간 협업 기능을 모든 사용자에게 그 주에 배포할 예정이었다.

결론 및 시사점

1. 최신 AI 개발 도구는 출시일에 시험하되, 도구 탐색이 실제 제품 개발을 삼키지 않도록 “왜 기본값이 아닌가?”를 묻는 습관이 필요하다.
2. 모델이 모르는 사용자·코드베이스 고유의 정보가 있을 때만 워크플로 최적화에 깊이 투자해야 한다.
3. 모든 코드에 동일한 자동화·리뷰 정책을 적용하지 말고, 데이터 구조·조직 지식·핵심 규칙처럼 사람이 보호할 구역을 먼저 정의해야 한다.
4. CLAUDE.md, AGENTS.md, 스킬 파일은 에이전트가 매 작업 시작 때 듣는 지침이므로 신입에게 반복해 알려줄 규칙처럼 정성 들여 작성해야 한다.
5. Slack, Discord, 회의 녹화, 버그 요청을 중앙 저장소에 넣고 SQL로 조회하게 하면 에이전트가 일반적인 답변을 넘어 회사의 실제 맥락에 맞게 행동할 수 있다.
6. 장시간 실행 가능한 클라우드 샌드박스는 노트북을 닫아도 작업을 지속하게 하며, 다른 사람·에이전트와의 협업 및 에이전트의 자기 확장을 가능하게 한다.
7. 개발자의 미래 역할은 기능 생산라인의 감독자가 아니라, 사람과 AI 에이전트로 구성된 팀의 방향과 리듬을 조율하는 오케스트라 지휘자에 가깝다.
8. 생산량만 높이는 software factory보다 인간이 흐름을 느끼고 재미와 장인정신을 유지하는 orchestra를 목표로 삼아야 한다.