도어대시 AI 전사 도입 사례 — 클로드 코드 확산과 CI·리뷰 병목, 조직 변화

핵심 메시지

• 도입 초기에는 토큰 예산을 죄지 않고 도구부터 열어 자연스럽게 드러나는 얼리어답터를 찾는 전략을 썼다.
• 코딩 속도가 빨라지자 병목이 CI/CD와 코드 리뷰, 보안 검토로 옮겨 갔고 그 지점을 다시 AI로 메우고 있다.
• 가장 큰 걸림돌은 엔지니어링이 아니라 제품·디자인 리뷰 같은 전사 프로세스였다.
• 코드베이스를 에이전트가 읽을 수 있게 미리 정비하는 선투자가 성공 사례의 공통점이었다.
• 리더가 직접 프로덕션 코드를 배포해 봐야 팀이 겪는 마찰과 정체성의 혼란을 이해할 수 있다.

쉽게 이해하기

대담은 도어대시 공동창업자와 클로드 코드를 만든 앤트로픽 엔지니어가 마주 앉아, 회사 전체가 AI 코딩 도구를 쓰게 되기까지의 과정을 되짚는 자리다. 창업자는 2013년 기숙사에서 직접 코드를 쓰다가 회사가 커지며 손을 놓았는데, 클로드 코드를 쓰면서 다시 프로덕션 코드를 배포하게 됐다고 말한다. 수동으로는 코드를 쓰지 않겠다는 목표를 세우고, 저장소마다 워크트리를 만들어 여러 세션을 동시에 돌리는 식으로 작업한다.

모델의 변곡점에 대한 증언이 인상적이다. 2025년에 '아무에게도 묻지 않고 프로덕션까지 배포해 보기'를 시도했을 때는 로컬 환경 설정을 에이전트가 이해하지 못해 실패했는데, 2026년 초 같은 시도를 하자 그냥 됐다고 한다. 여기서 그는 조직에 '내 아이디어를 버릴 줄 알아야 한다'는 태도를 주문한다. 예전 모델로 안 되던 것을 몇 달 뒤 그대로 다시 시도하면 되는 일이 생기기 때문이다.

확산 전략은 통제보다 개방에 가까웠다. IT 보안팀과 별도의 조달·검토 프로세스를 합의해 새 도구에 빠르게 접근할 수 있게 하되, 가드레일은 보안팀이 함께 설계했다. 초기에는 예산을 조이지 않고 토큰과 도구를 충분히 주며 누가 자연스럽게 파고드는지 지켜봤고, 성공 사례가 나오면 그 사람을 팀 안의 전도사로 세웠다. 성공담뿐 아니라 토큰만 낭비한 실패담도 공유하도록 독려한 점이 특징이다.

속도가 붙자 병목이 이동했다. 머지되기까지 걸리는 시간에 대한 불만이 커지고 CI/CD를 다시 설계해야 했으며, 보안 관련 이슈도 업계 전반에서 늘었다. 도어대시는 AI 코드 리뷰 에이전트를 만들어 대응했고, 사내 클라우드에 보안 승인된 VM을 띄워 에이전트 세션을 돌리는 내부 플랫폼을 구축해 그 위에서 코드 리뷰 에이전트를 운영한다.

정작 가장 어려운 문제는 엔지니어링 밖에 있었다. 사용자 대면 기능은 디자인 합의와 제품 리뷰, 출시 리뷰를 거쳐야 하는데, 예전에는 합당했던 이 과정들이 이제는 큰 마찰이 됐다. 그래서 'AI 속도를 살리려면 엔지니어링만의 문제가 아니라 전사의 문제'라는 인식 아래 크로스펑셔널 리더들과 일하는 방식 자체를 다시 협의하고 있다. 엔지니어가 픽셀 단위까지 맞추는 대신 동작하는 상태까지 만들고 디자이너가 직접 마무리하는 식의 재배치도 시도한다.

조직 운영에서 얻은 교훈도 구체적이다. 3~5명 규모의 작은 팀이 가장 큰 가속 요인이었고, 한 성공 사례에서는 테크 리드가 아키텍처 원칙 수십 가지를 저장소 안 마크다운 파일로 정리해 둔 것이 결정적이었다. 모바일 팀은 시뮬레이터 실행과 테스트처럼 손이 많이 가던 작업을 스킬로 표준화했다. 실험을 맡은 팀에는 임원급 스폰서십을 붙여, 평소 업무의 제약 안에서 시도하다 금방 포기하는 일이 없도록 했다.

성과 측정에 대해서는 솔직하다. 엔지니어링은 코드 처리량과 납기로 방향성을 볼 수 있지만 게임하기 쉬운 지표임을 인정하고, 궁극적인 기준은 고객에게 가치가 더 빨리 닿았는가로 둔다. 지식 노동 쪽은 아직 탐색 단계로, 모두의 기본선을 올리는 접근과 부서별 특정 워크플로를 자동화하는 접근을 함께 보고 있다. 마지막 조언은 리더가 직접 써 보라는 것이다. 코드를 쓰는 일에 정체성을 걸어 온 엔지니어들이 겪는 불안을 이해하려면 그 방법밖에 없고, 배운 것을 글로 남겨 공유하는 것이 가장 확장성 있는 전파 방식이라고 말한다.

주요 인사이트

• 새 도구의 확산에서 예산 통제는 나중 문제라는 판단이 흥미롭다. 초기에는 오히려 예산을 느슨하게 풀어 누가 어떤 병목을 스스로 자동화하는지 관찰하는 편이 낫다는 것이다.
• 위에서 '이 워크플로를 자동화하라'고 지시하면 엉뚱한 워크플로나 엉뚱한 사람을 고를 수 있다. 각 부서에서 자발적으로 도구에 빠져든 사람을 찾아 챔피언으로 세우는 상향식이 더 잘 작동했다.
• 에이전트 친화적인 코드베이스는 저절로 생기지 않는다. 아키텍처 원칙을 미리 문서로 남겨 두는 선투자가 뒤이은 생산성 차이를 만들었다.
• 지식 공유를 문서로 하라는 권고에는 부수 효과가 있다. 사람에게 전파되는 동시에 에이전트가 읽을 수 있는 자산이 남는다는 것이다.
• 도메인 전문가를 모두에게 요구하는 대신 소수의 게이트키퍼로 두고 나머지를 제너럴리스트로 유연하게 움직이게 하는 인력 구성 변화가 이미 진행 중이다.

자주 묻는 질문

관련 AI 소식