AI는 단순히 소프트웨어 개발 속도를 높이거나 업무를 자동화하는 도구가 아니다. 스타트업의 운영 방식 자체를 근본적으로 바꾸는 혁신이다. 팀 구성, 만들 수 있는 제품, 회사 운영 방식까지 달라진다. 창업자가 AI 네이티브 회사를 구축할 때 필요한 팀 구성과 지금 실행할 수 있는 구체적인 내부 관행을 살펴본다.
핵심 요약
- AI는 생산성 도구가 아닌 핵심 운영 체계: 기존 프레임워크에서 벗어나 AI를 회사의 운영 체계로 삼아야 한다
- 폐쇄형 루프 시스템 구축: 모든 중요한 프로세스에서 정보를 수집하고 피드백을 받아 지속적으로 개선해야 한다
- 회사 전체를 AI에 쿼리 가능하게 만들기: 조직의 모든 행동은 인공지능이 학습할 수 있는 결과물을 남겨야 한다
- AI 소프트웨어 팩토리: 테스트 주도 개발의 진화 형태로, AI가 코드를 자동으로 생성하고 반복 개선한다
- 새로운 조직 구조: 중간 관리자 계층을 없애고 개별 기여자, 책임자, AI 창업자 3가지 역할로 재편성한다
AI는 생산성 도구가 아닌 운영 체계다
현재 대부분의 사람들은 AI를 생산성 향상 도구로만 이해한다. 엔지니어가 더 빠르게 코드를 작성하거나 기존 워크플로우에 코파일럿을 추가해 더 많은 기능을 배포하는 수준으로 본다. 하지만 이런 관점으로는 지금 우리가 경험하는 변화의 본질을 놓친다.
현재의 AI 혁신으로 생산성이 높아지고 완전히 새로운 역량도 생겨난다. 적절한 AI 도구를 사용하는 한 명이 예전에는 팀 전체가 필요했던 기능을 만들 수 있게 됐다. 심지어 불가능하다고 여겨지던 것도 가능해졌다.
이런 새로운 역량을 고려하면 창업자는 회사 운영 방식도 다시 생각해야 한다. 가장 중요한 원칙은 AI를 단순한 도구로 취급하면 안 된다는 것이다. AI는 회사 운영의 기본 운영 체계가 되어야 한다.
회사 전체로 보면 AI는 모든 워크플로우, 의사결정, 프로세스를 아우르며 지속적으로 학습하고 개선되는 지능형 계층이 되어야 한다. 구체적으로는 회사의 모든 중요한 프로세스를 지능형 폐쇄형 루프로 관리해야 한다.
폐쇄형 루프로 자동으로 개선되는 조직 만들기
폐쇄형 루프가 무엇인지 정확히 이해해야 한다. 폐쇄형 루프는 정보를 수집하고 그 정보를 지능형 시스템에 되돌려 보내 프로세스를 시간이 지날수록 개선하는 체계다. 제어 시스템 이론에 친숙한 사람이라면 개방형 루프와 폐쇄형 루프의 차이를 알 것이다.
개방형 루프는 피드백 루프가 없는 제어 시스템이다. 과거의 회사들은 본질적으로 개방형 루프로 운영됐다. 의사결정을 내리고 실행하지만 결과를 체계적으로 측정하거나 프로세스를 조정하지 않는 방식이다. 개방형 루프에서는 정보 손실이 많다. 정보가 여기저기 흩어지고 결정을 제대로 평가하지 못하며 같은 실수를 반복하곤 한다.
반대로 폐쇄형 루프는 스스로 조절하며 지속적으로 출력을 모니터링하고 설정된 목표를 더 잘 달성하도록 프로세스를 조정한다. 폐쇄형 루프는 정확성과 안정성을 확보하는 데 강력하다. 자기 개선 에이전트를 사용하는 회사라면 폐쇄형 루프로 운영되어야 한다.
이런 폐쇄형 루프를 구축하려면 회사 전체를 AI에 쿼리 가능하게 만들어야 한다. 조직 전체를 AI가 명확하게 파악할 수 있어야 한다. 모든 중요한 행동은 회사 중심의 지능형 시스템이 학습하고 자체 개선에 사용할 수 있는 결과물을 남겨야 한다.
구체적으로 필요한 조치는 다음과 같다.
- AI 노트 필기 도구로 회의 기록
- DM과 이메일을 최소화하고 에이전트를 모든 커뮤니케이션 채널에 배치
- 맞춤형 대시보드 구축 (매출, 영업, 엔지니어링, 채용, 운영 등 회사의 모든 것)
- 조직의 모든 중요한 활동을 추적 가능한 형태로 기록
핵심은 직원에게 제공하는 것과 같은 수준의 맥락을 지능형 시스템에도 제공하는 것이다. 이렇게 구현하면 회사는 정보가 분산되고 사람이 수동으로 해석하는 개방형 루프에서 벗어나 폐쇄형 루프 시스템으로 운영된다. 상태, 의사결정, 결과를 지속적으로 수집해 지능형 계층에 되돌려 보내므로 실제로 일어나는 일을 항상 최신 상태로 파악할 수 있다.
엔지니어링 관리에 적용한 AI 폐쇄형 루프
엔지니어링 관리와 스프린트 계획을 구체적인 예로 들 수 있다. AI 에이전트가 다음 정보에 접근할 수 있다고 가정해보자.
- Linear 티켓
- Slack 엔지니어링 채널
- 이메일이나 Pylon, GitHub 같은 도구의 고객 피드백
- Notion이나 Google Docs의 상위 수준 계획
- 영업 통화 기록
- 일일 스탠드업 기록
이런 정보에 접근할 수 있다면 에이전트는 이전 스프린트에서 실제로 배포한 것이 고객 요구를 얼마나 잘 충족했는지 분석할 수 있다. 이를 바탕으로 다음 스프린트도 내다볼 수 있다.
무엇을 배포했고 무엇이 효과가 있었으며 무엇이 효과가 없었는지 완벽하게 파악하면 에이전트는 앞을 내다보기 시작할 수 있다. 엔지니어에게 훨씬 더 예측 가능하고 정확하며 일정에 맞는 스프린트 계획을 제안할 수 있다. 정보 손실이 많은 엔지니어링 매니저 상태 보고의 시대는 끝났다.
직접 엔지니어링 팀을 관리했고 현재 여러 YC 회사에서 이를 지켜보는 입장에서 이는 큰 변화다. 예전에는 끊임없이 조정해야 했던 일을 이제 명확하게 파악하고 쿼리할 수 있다. 정보를 사람이 수동으로 해석하고 여러 단계를 거쳐 전달하던 시대는 끝났다.
이 변화가 중요한 이유는 정보 흐름이 빠를수록 회사의 속도가 빨라지기 때문이다. 사람이 수동으로 정보를 라우팅하는 계층을 하나씩 제거할 때마다 속도가 직접적으로 빨라진다. AI 에이전트가 실시간으로 상황을 파악하고 예측하고 제안할 수 있으므로 엔지니어링 관리도 완전히 새로워진다.
AI 소프트웨어 팩토리와 1000배 엔지니어
가장 빠르게 움직이는 회사들 사이에서 새로운 제품 구축 방식이 나타나고 있다. **AI 소프트웨어 팩토리(AI Software Factories)**다.
테스트 주도 개발(TDD)의 다음 진화 형태로 이해할 수 있다. 소프트웨어 팩토리에서는 인간이 스펙(명세)과 성공을 정의하는 테스트 세트를 작성하고 AI 에이전트가 구현을 맡아 코드를 생성한 뒤 테스트를 통과할 때까지 반복 개선한다. 인간은 무엇을 만들지 정의하고 출력을 판단한다. 실제 코드 생성은 에이전트의 일이다.
일부 회사는 이 방식을 극단까지 밀어붙여 저장소에 손으로 작성한 코드 없이 명세와 테스트 하네스만 두는 단계에 도달했다. StrongDM의 AI 팀이 좋은 예다. 이 팀의 최종 목표는 인간이 코드를 작성하거나 검토할 필요가 없는 시스템이다.
이 팀은 자체 소프트웨어 팩토리를 구축했다. 여기서는 명세와 시나리오 기반 검증에 따라 에이전트가 테스트를 작성하고 확률적 만족 임계값에 도달할 때까지 코드를 반복 개선한다. 이 방식은 작동한다. 이것이 Steve Yegge가 말한 "1000배 엔지니어"를 달성하는 방법이다. 한 명의 엔지니어가 에이전트 시스템과 함께 일하며 이전에는 절대 만들 수 없었을 것들을 만들도록 한다.
"1000배는 물론 10,000배 엔지니어"의 시대가 왔다. 더 이상 과장이 아니다. 올바른 시스템과 AI 도구를 갖춘 한 명의 엔지니어가 50명의 엔지니어 팀보다 더 많은 일을 할 수 있다.
AI는 다음과 같은 일을 할 수 있기 때문이다.
- 무한한 컨텍스트에서 작업
- 모든 기술 스택과 라이브러리를 완벽하게 알고 있음
- 피로를 모름
- 지루한 작업을 반복 없이 수행
- 각 테스트 실패를 분석하고 개선
이런 이점이 합쳐지면 개발 속도는 기존의 몇 배가 된다.
중간 관리자가 필요 없는 새로운 조직 구조
곳곳에서 AI 루프가 작동하고 조직에 쿼리할 수 있으며 소프트웨어 팩토리를 갖춘 회사에서는 고전적인 관리 계층이 더 이상 의미가 없다.
과거에는 중간 관리자와 조정자들이 조직 위아래로 정보를 비효율적으로 라우팅했다. 새로운 조직에서는 지능형 계층이 그 역할을 수행한다. 회사에 쿼리할 수 있고 결과물이 풍부하며 AI가 이를 명확하게 파악할 수 있다면 인간 미들웨어는 거의 필요 없어야 한다.
회사의 속도는 정보 흐름의 속도에 달려 있다. 사람이 정보를 라우팅하는 계층을 제거할 때마다 속도가 직접적으로 빨라진다. Jack Dorsey가 Block에서 하는 일이 좋은 예다.
AI 도구를 깊이 사용한 후 Jack은 많은 사람들이 공유하는 결론에 도달했다. 이는 단순한 점진적 생산성 향상에 그치지 않는다. 그는 같은 조직 차트와 관리 구조를 유지하면 전체 패러다임 전환을 놓친다고 봤다.
회사 자체를 지능형 계층으로 재구축해야 하며 인간은 그 안에서 정보를 라우팅하는 대신 가장자리에서 이를 안내해야 한다. Jack은 앞으로 모든 회사에 세 가지 직원 유형이 있어야 한다고 제안한다.
첫 번째는 개별 기여자(IC)—본질적으로 빌더-오퍼레이터다. 직접 만들고 운영하는 사람이다. AI 네이티브 회사에서 이 역할은 엔지니어로 제한되지 않는다. 엔지니어링, 운영, 지원, 영업 모두가 만들며 피치 덱 대신 작동하는 프로토타입을 들고 회의에 온다.
두 번째는 직접 책임이 있는 개인(DRI)—전략과 고객 결과에 집중하는 역할이다. 고전적인 관리자가 아니라 명확한 결과 책임을 지는 사람이다. 한 사람이 한 결과를 책임지므로 숨을 곳이 없다. DRI는 실패에 대한 책임이 명확하기 때문에 매우 효율적이다.
세 번째는 AI 창업자 타입이다. 이 사람은 계속 직접 만들고 코칭하며 모범을 보인다. 창업자는 AI 전략을 위임하는 대신 앞장서서 크게 높아진 역량을 보여주는 이 역할을 맡아야 한다.
이 구조에서 회사들은 훨씬 더 작은 팀으로 과감한 결과를 달성할 것이다. 핵심 변화는 헤드카운트 대신 토큰 사용을 최대화하는 것이다. 최고의 회사들은 토큰 사용을 최대화하는 회사들이다.
이런 트레이드오프에서 AI 도구를 가진 한 명은 AI가 없던 회사의 큰 엔지니어링 팀과 동등할 수 있다. 그만큼 엔지니어링, 디자인, HR, 행정 팀이 극도로 작아진다.
불편할 정도로 높은 API 청구서도 기꺼이 감수해야 한다. 그렇지 않으면 훨씬 더 비싸고 부풀려진 헤드카운트가 필요하기 때문이다. 이 말만 믿고 판단할 일은 아니다.
직접 경험해야 이해할 수 있는 AI의 능력
이런 도구의 힘에 대한 확신은 외부에서 얻을 수 없다. 코딩 에이전트와 적극적으로 일하며 자신의 선입견에 도전하는 과정에서 확신을 쌓아야 한다. 이것이 가장 중요한 부분이다.
현재 많은 리더들이 AI 도구를 시도해보지 않고 있다. 이들은 "이건 아직 프로덕션용이 아니야" 또는 "우리 코드베이스는 너무 복잡해"라고 말한다. 하지만 이는 실수다. 직접 사용해보지 않고서는 가능성의 진정한 범위를 알 수 없다.
ChatGPT, GitHub Copilot, Claude와 같은 도구로 직접 실험하면 놀라게 될 것이다. 리더가 놀라면 팀도 놀랄 것이다.
초기 단계 창업자에게는 엄청난 이점이 있다. 레거시 시스템이나 굳어진 조직 차트, 재교육이 필요한 수천 명의 사람들이 없다. 첫 날부터 회사를 올바르게 구축할 수 있을 만큼 규모가 작다.
기존 회사들은 사정이 반대다. 운영 중인 제품을 유지하고 성장시키면서 수년간의 표준 운영 절차와 소프트웨어 개발에 대한 핵심 가정을 해체해야 한다. 일부 회사는 작은 내부 "스캥크웍스" 팀을 꾸려 핵심 비즈니스와 분리된 AI 네이티브 시스템을 처음부터 구축하는 방식으로 이를 달성할 수 있다. Mutiny가 좋은 예다. 하지만 대부분의 경우 핵심 프로세스를 바꾸면 이미 작동하는 것을 깨뜨릴 위험이 있다.
이런 특성 때문에 큰 회사들은 적응하기가 훨씬 더 어려울 것이다. 결국 따라오겠지만 지금 시작하는 창업자는 1-2년 앞서갈 수 있다. 스타트업 환경에서는 거대한 이점이다.
결론
AI 네이티브 회사 구축은 이미 현재의 일이다. 초기 단계 창업자는 처음부터 AI를 중심으로 회사를 설계할 수 있는 특별한 위치에 있다.
폐쇄형 루프 시스템을 구축하고 조직을 쿼리 가능하게 만들며 소프트웨어 팩토리와 새로운 조직 구조를 도입하면 기존 회사보다 천 배 빠르게 운영할 수 있다. 더 작은 팀으로 더 큰 결과를 달성할 수 있다.
지금 AI 도구를 직접 실험하고 팀의 워크플로우에 통합할 방법을 검토해야 한다. 레거시를 가진 기존 회사들은 변화의 속도가 느릴 수밖에 없다. 초기 단계 창업자에게는 그런 제약이 없다. 시스템, 워크플로우, 문화를 처음부터 AI 중심으로 설계해 경쟁자보다 천 배 빠르게 운영해야 한다.
댓글 0
첫 댓글을 남겨 주세요.