AI로 회사를 처음부터 다시 짓는 법: ‘도구’가 아니라 ‘운영체제’로 쓰기

AI를 기존 업무에 "붙이는" 수준을 넘어서, 회사의 모든 의사결정과 실행이 AI의 지능 레이어를 통과하는 구조로 재설계해야 한다는 이야기를 다룹니다. 핵심은 회사를 닫힌 루프(피드백 기반) 시스템으로 바꾸고, 이를 위해 조직 전체를 AI가 질의(조회) 가능한 상태로 만드는 것입니다. 그렇게 되면 중간관리의 역할은 급격히 줄고, 작은 팀이 토큰(모델 사용량)을 극대화해 압도적인 속도로 제품을 만들 수 있다고 강조합니다.

1. AI는 생산성 도구가 아니라 회사의 운영체제다

YC 파트너 디아나 후는 최근 몇 달 동안 확신하게 된 변화로 이야기를 시작합니다. AI는 단지 "개발을 더 빨리 하게 해주는 것"이 아니라, 스타트업이 운영되는 방식 자체를 바꿔버릴 거라는 겁니다. 어떤 역할이 필요해지는지, 어떤 제품이 가능해지는지까지 달라진다고요.

"AI는 소프트웨어가 얼마나 빨리 만들어지는지를 바꾸는 것에 그치지 않아요. 스타트업이 어떻게 운영되어야 하는지를 근본적으로 바꿀 겁니다."

사람들이 흔히 AI를 생산성 프레임으로만 이야기하는 것도 짚습니다. 예를 들어 "엔지니어 생산성", "기존 워크플로에 코파일럿을 붙이자", "기능을 더 많이 출시하자" 같은 말들이요. 하지만 디아나는 이 관점이 지금 벌어지는 진짜 변화—완전히 새로운 능력의 등장—를 놓친다고 말합니다.

"이건 생산성 향상이라기보다, 완전히 새로운 역량(capabilities)이 생긴 거예요."

그리고 이 변화의 결론을 한 문장으로 정리합니다. AI는 회사가 '쓰는 도구'가 아니라, 회사가 '그 위에서 돌아가는 운영체제(OS)'가 되어야 한다는 거죠.

"AI는 회사가 그냥 사용하는 툴이 아니라, 회사가 그 위에서 돌아가는 운영체제가 되어야 해요."

즉 모든 워크플로, 모든 의사결정, 모든 프로세스가 지능 레이어를 통과하고, 그 지능 레이어는 계속 학습하며 개선되는 구조로 가야 한다는 제안입니다.

2. '열린 루프 회사'에서 '닫힌 루프 회사'로 바꾸기

그다음 디아나는 회사 운영을 제어 시스템(control systems)에 비유해 설명합니다. (어렵게 들리지만 핵심은 간단해요: 결과를 측정하고 다시 고치는 구조가 있느냐 없느냐입니다.)

열린 루프(Open loop): 실행은 하지만 피드백이 체계적으로 돌아오지 않음
닫힌 루프(Closed loop): 결과를 지속적으로 모니터링하고, 목표에 맞게 과정을 계속 조정함

예전의 많은 회사는 사실상 열린 루프처럼 운영됐다고 합니다. 결정을 내리고 실행한 다음, 그 결과를 체계적으로 재측정해 프로세스를 업데이트하는 일이 "항상" 일어나지는 않았다는 거죠.

"예전 세계에서 회사는 대체로 열린 루프로 돌아갔어요. 결정하고 실행하지만, 결과를 체계적으로 측정하고 조정하지는 않았죠."

반면 닫힌 루프는 자기조절(self-regulating)이 됩니다. 출력(결과)을 계속 보고, 목표에 맞게 입력(과정)을 고치니까요. 디아나는 자기개선 에이전트(self-improving agents)가 가능해진 지금은 회사가 닫힌 루프로 돌아가야 한다고 강조합니다.

"자기개선 에이전트가 있는 시대라면, 회사는 닫힌 루프로 운영되어야 합니다."

3. 닫힌 루프를 만들려면 '회사 전체를 질의 가능하게' 만들어라

닫힌 루프를 만들기 위한 실천 과제로 디아나는 한 가지를 강하게 말합니다. 바로 회사를 완전히 질의 가능(queryable)하게 만들라는 겁니다. 표현을 바꿔 말하면, 조직 전체가 AI에게 읽히는 상태(legible)여야 한다는 뜻이에요.

"닫힌 루프를 만들려면, 회사 전체를 질의 가능하게 만들어야 합니다. 조직 전체가 AI에게 '읽히는' 상태여야 해요."

이를 위해 중요한 원칙은 이겁니다.

회사에서 일어나는 중요한 행동은 반드시 '아티팩트(기록물/산출물)'를 남겨야 하고
그 기록물이 중앙의 지능 레이어가 학습하고 개선하는 재료가 되어야 한다

그래서 디아나는 아주 구체적인 운영 습관을 제안합니다.

"회의는 AI 노트테이커로 기록하고, DM과 이메일은 최소화하고, 모든 커뮤니케이션 채널에 에이전트를 심으세요."

또한 회사의 모든 핵심 지표와 활동이 한눈에 잡히도록 커스텀 대시보드를 구축하라고 말합니다. 매출, 세일즈, 엔지니어링, 채용, 운영 등 "전부"요.

"회사 안의 모든 걸 대시보드로 만드세요. 매출, 세일즈, 엔지니어링, 채용, 운영… 전부요."

4. 엔지니어링 예시: 스프린트 계획이 '관리 보고'가 아니라 '에이전트 분석'으로 바뀐다

디아나는 "이게 실제로 어떻게 돌아가느냐"를 엔지니어링 스프린트로 예시를 듭니다. 하나의 에이전트가 다음에 접근할 수 있다고 가정해보죠.

Linear 티켓
Slack 엔지니어링 채널
고객 피드백(이메일, Pylon 같은 도구)
GitHub
Notion/Google Docs에 있는 상위 계획
세일즈 콜 녹음
데일리 스탠드업 기록

이 정도 맥락이 모이면, 에이전트는 지난 스프린트에서 무엇이 실제로 배포되었는지, 그것이 고객 니즈를 얼마나 충족했는지를 분석할 수 있습니다. 그리고 한 단계 더 나아가 "다음 스프린트 계획"까지 더 정확하게 제안하게 됩니다.

"에이전트는 지난 스프린트에 실제로 무엇이 배포됐는지, 고객 니즈를 얼마나 충족했는지를 분석할 수 있어요. 그리고 더 정확하고 예측 가능한 스프린트 플랜을 제안할 수 있죠."

여기서 디아나는 기존 방식의 문제를 콕 집습니다. "상태 보고(status rollups)"는 본질적으로 정보가 많이 새고(손실되고), 담당자가 요약하면서 왜곡도 생기기 쉽다는 거예요.

"너무 손실이 큰 매니저식 상태 보고의 시대는 끝났어요."

본인도 엔지니어링 팀을 직접 매니징해봤고, YC 회사들에서 이런 변화를 목격하면서 확신했다고 말합니다.

"제가 직접 팀을 매니징해봤고, YC 여러 회사에서 이걸 보면서 말하는데… 이건 게임 체인저예요."

실제로 이렇게 운영하는 팀은 스프린트 시간을 절반으로 줄이고, 같은 시간에 10배 가까이 더 해내는 경우도 봤다고 합니다. 🚀

"이렇게 하는 팀은 스프린트 시간을 반으로 줄이고, 그 시간에 10배 가까이 더 해내기도 했어요."

핵심 원칙도 다시 한 번 반복합니다. 모델에게 맥락을 주려면, "대충 요약"이 아니라 직원에게 주는 수준의 컨텍스트를 제공해야 한다는 겁니다.

"모델에게는 직원에게 제공하는 것만큼의 맥락을 제공해야 진짜 역량이 나와요."

5. 'AI 소프트웨어 팩토리'와 1,000x(또는 10,000x) 엔지니어의 등장

다음으로 디아나는 제품 개발 방식 자체가 바뀌는 흐름을 설명합니다. AI 소프트웨어 팩토리(AI software factory)라는 패러다임인데, 테스트 주도 개발(TDD)을 아는 사람이라면 "그 다음 단계"로 이해할 수 있다고 합니다.

구조는 이렇습니다.

인간이 스펙(spec)과 성공을 정의하는 테스트를 작성한다
AI 에이전트가 구현 코드를 만들고
테스트를 통과할 때까지 반복(iterate)한다
인간은 "무엇을 만들지"를 정의하고, 결과를 평가한다

"인간은 스펙과 테스트로 '성공'을 정의하고, 에이전트가 구현을 만들고 테스트를 통과할 때까지 반복합니다."

심지어 어떤 회사는 저장소(repo)에 사람이 직접 쓴 코드가 거의 없고, 스펙과 테스트 하네스만 있는 수준까지 갔다고 말합니다. 😮

"어떤 회사는 저장소에 손으로 쓴 코드가 하나도 없고, 스펙과 테스트 하네스만 있어요."

예시로는 "StrongDM의 AI 팀"을 언급하면서, 목표가 "사람이 코드를 작성하거나 리뷰할 필요를 사실상 없애는 것"에 가까웠다고 설명합니다. 스펙과 시나리오 기반 검증이 에이전트를 움직이고, 테스트를 쓰고, 코드가 확률적 만족 임계치(probabilistic satisfaction threshold)에 도달할 때까지 반복하는 식입니다. (쉽게 말해, 정답이 하나로 고정되지 않는 문제에서도 "충분히 만족스러운 결과" 기준을 세워 계속 개선한다는 뜻이에요.)

이런 시스템이 만들어내는 효과를 디아나는 '1,000배 엔지니어'로 연결합니다. 한 명의 엔지니어를 에이전트 시스템으로 둘러싸면, 이전에는 절대 혼자 못 만들던 것들을 만들 수 있게 된다는 거죠.

"한 명의 엔지니어를 에이전트 시스템으로 둘러싸면, 예전에는 절대 만들 수 없던 것들을 만들게 됩니다."

그리고 한 발 더 나아가 이렇게까지 말합니다.

"1,000배, 심지어 10,000배 엔지니어의 시대가 왔어요."

6. 중간관리 계층이 사라지는 이유: '정보 라우팅'이 AI로 대체된다

AI 루프가 회사 곳곳에 깔리고, 조직이 질의 가능해지고, 소프트웨어 팩토리까지 갖추면—디아나는 전통적인 관리 계층 구조가 더 이상 말이 안 된다고 주장합니다.

과거에는 왜 중간관리자가 필요했냐면, 조직이 커질수록 정보가 여기저기 흩어지고, 이를 위아래로 전달하고 조율하는 "사람"이 필요했기 때문입니다. 디아나는 이를 "인간 미들웨어(human middleware)"라고 부릅니다.

"예전에는 중간관리자와 코디네이터가 비효율적으로 정보를 위아래로 라우팅해야 했어요."

그런데 이제는 그 역할을 지능 레이어가 맡게 된다는 겁니다. 회사가 아티팩트가 풍부하고(artifact-rich), AI가 읽을 수 있고(legible), 언제든 조회 가능(queryable)하면 굳이 사람을 '전달자'로 세울 이유가 약해지죠.

"회사가 질의 가능하고, 기록물이 풍부하고, AI가 읽을 수 있다면 인간 미들웨어는 거의 필요 없어요."

여기서 속도의 결정 요인도 명확히 합니다.

"회사 속도는 정보 흐름만큼만 빨라요. 사람 라우팅 계층을 하나 제거할 때마다 그게 곧 속도 이득입니다."

또한 잭 도시(Jack Dorsey)가 Block에서 내린 결론을 예로 들며, "그대로 조직도를 유지하면 변화의 핵심을 놓친 것"이라고 전합니다.

"조직도와 관리 구조를 그대로 유지하면, 변화를 완전히 놓친 겁니다."

7. 앞으로의 조직: IC, DRI, 그리고 'AI 파운더'가 핵심 역할이 된다

디아나는 잭 도시의 관점을 빌려, 앞으로 회사에는 세 가지 직원 아키타입이 중심이 될 거라고 설명합니다.

1) IC(Individual Contributor): 만드는 사람, 운영하는 사람

IC는 "빌더/오퍼레이터"로, AI 네이티브 회사에서 직접 만들고 돌리는 역할입니다. 중요한 건 이게 엔지니어만이 아니라는 점이에요.

"이건 엔지니어에만 해당되지 않아요. 모두가 만들고 운영합니다—지원, 세일즈, 모두요."

그리고 회의 문화도 바뀐다고 합니다. 슬라이드 덱이 아니라 작동하는 프로토타입을 들고 들어오는 문화요.

"모두가 피치덱이 아니라 작동하는 프로토타입을 들고 회의에 들어옵니다."

2) DRI(Directly Responsible Individual): 결과에 1인 책임지는 사람

DRI는 전통적 의미의 '매니저'가 아니라, 전략과 고객 성과(outcomes)에 대해 명확히 책임지는 사람입니다.

"이건 고전적인 매니저가 아니에요. 결과에 대한 명확한 책임자입니다. 한 사람, 한 결과—숨을 곳이 없죠."

3) AI 파운더 타입: 창업자가 최전선에서 직접 보여줘야 한다

세 번째는 특히 창업자에게 던지는 메시지입니다. 창업자는 여전히 만들고, 코칭하고, 몸소 보여주는 리더여야 하며, AI 전략을 남에게 위임하면 안 된다고 합니다.

"파운더라면 이게 당신이어야 해요. AI 전략을 다른 사람에게 위임하지 마세요."

8. '인원'이 아니라 '토큰'을 극대화하는 회사가 이긴다

이 구조가 가능해지면, 회사는 훨씬 더 작은 팀으로도 훨씬 큰 성과를 낼 수 있다고 말합니다. 여기서 디아나는 아주 인상적인 표현을 씁니다.

"헤드카운트가 아니라 토큰 사용량을 극대화하는 게 핵심 변화가 될 겁니다."

즉 최고의 회사는 token-maxing을 하는 회사라는 거죠. 예전에는 큰 엔지니어링 팀이 필요했던 일을, 이제는 AI 도구를 가진 1명이 상당 부분 대체할 수 있다는 주장입니다. 그래서 엔지니어링뿐 아니라 디자인, HR, 어드민까지 팀이 훨씬 더 슬림해질 거라고 봅니다.

또한 비용 감각도 뒤집으라고 말합니다. API 비용이 높게 나와도, 그게 예전 같으면 훨씬 비싼 인건비(그리고 비대해진 조직)를 대신하는 거라면 감수할 가치가 있다는 거죠.

"불편할 정도로 API 비용이 많이 나오는 걸 감수할 의지가 있어야 해요. 그건 더 비싼 헤드카운트를 대체하는 비용이니까요."

9. 확신은 '남에게서'가 아니라 '직접 써보면서' 만들어야 한다

마지막 파트에서 디아나는 청중(특히 창업자)에게 경고처럼 조언합니다. 이 변화에 대한 믿음은 남이 말해준다고 생기지 않으며, 직접 도구를 써서 자기 생각의 한계를 깨야 한다고요.

"이 도구들의 힘에 대한 확신을 아웃소싱할 수는 없어요."

방법도 구체적입니다. 코딩 에이전트와 함께 앉아서 계속 써보고, 그러다 보면 "이제 가능한 것"에 대한 기존 가정(priors)이 깨질 거라고 합니다.

"코딩 에이전트와 직접 앉아서 써보세요. 그러면 무엇이 가능한지에 대한 선입견이 깨질 겁니다."

그리고 초기 창업자(early-stage founder)가 특히 유리한 이유를 정리합니다. 레거시 시스템도 없고, 오래된 조직도도 없고, 수천 명을 재교육할 필요도 없으니 첫날부터 AI 네이티브로 설계할 수 있다는 겁니다.

"초기 창업자는 엄청난 이점이 있어요. 레거시 시스템도, 오래된 조직도도, 재교육할 수천 명도 없으니까요."

반대로 기존 대기업은 이미 돌아가는 제품을 유지하면서, 수년간의 SOP(표준 운영 절차)와 '소프트웨어는 이렇게 만든다'는 전제를 풀어헤쳐야 해서 훨씬 어렵다고 말합니다. 일부는 별도의 소규모 스컹크웍(skunkworks) 팀을 만들어 새로 구축할 수 있고, Mutiny가 그 사례라고도 덧붙입니다.

결론적으로 디아나는 스타트업이 이 제약이 없기 때문에, 처음부터 AI 중심으로 시스템/워크플로/문화를 설계하면 기존 강자를 압도적으로 앞지를 수 있다고 마무리합니다.

"처음부터 AI를 중심으로 설계하면, 기존 기업보다 1,000배 더 빠르게 운영할 수 있어요."

마무리

이 영상이 말하는 AI 네이티브 회사는 "AI를 쓰는 회사"가 아니라 AI가 흐르는 회사입니다. 핵심 실천은 회사 전체를 질의 가능하게 만들고, 모든 일을 닫힌 루프로 돌리며, 개발은 스펙·테스트 중심의 소프트웨어 팩토리로 전환하는 것입니다. 그렇게 되면 조직은 더 납작해지고, 경쟁력은 인원 수가 아니라 토큰 활용 능력에서 갈린다는 메시지가 또렷하게 남습니다.