요즘 AI 전환 이야기를 들으면 대부분 도구 목록에서 시작합니다. 어떤 모델을 쓸지, 어떤 에이전트를 붙일지, 사내 데이터는 어디에 연결할지부터 묻습니다. 그런데 OpenAI 스타트업팀 인터뷰를 끝까지 보면 답은 조금 다른 쪽에 있습니다.

AI 네이티브 기업은 AI 도구 사용량으로 정해지지 않습니다. 새 기능이 나오면 일단 만져봅니다. 안 맞으면 버리고 맞으면 바로 업무 흐름에 넣습니다. 영상에서 반복해서 나온 표현도 이쪽이었습니다. “만지작거리는 사람”이 많아야 한다는 얘기입니다.

Codex는 코딩 도구에서 업무 도구로 넘어갔습니다

OpenAI 내부에서는 Codex를 단순 코딩 보조로만 쓰지 않습니다. 스타트업 사용량 분석, 알파 테스트 피드백 요약, 슬랙 의견 정리까지 맡깁니다. 코드를 짜는 일은 그중 한 부분입니다.

사용 방식도 달라졌습니다. 정해진 프롬프트를 입력한 뒤 기다리는 수준이 아닙니다. 매일 아침 같은 분석을 돌리도록 자동화를 걸어둡니다. 컴퓨터 사용 기능으로 웹이나 로컬 앱도 조작합니다. Codex Mobile로 노트북 자료를 찾고 Slack, Gmail, Calendar와 연결해 회의와 메일을 정리하는 흐름도 나옵니다.

코딩에서도 변화가 보입니다. 예전에는 큰 리팩토링 스프린트를 따로 잡아야 했습니다. 지금은 최근 PR을 훑고 공통 패턴을 찾아 함수나 컴포넌트로 묶을 부분을 계속 정리합니다. 유지보수가 이벤트가 아니라 일상 작업이 되는 셈입니다.

작은 팀이 커지는 방식이 달라집니다

영상에서 가장 강하게 남은 대목은 팀 규모 이야기였습니다. OpenAI 팀이 본 사례 중에는 두 명의 창업자가 Codex 기반 에이전트를 사업 운영의 중심에 놓은 회사도 있었습니다. 이 팀은 당장 직원을 많이 뽑지 않겠다고 했습니다. 매출이나 사용량이 작다는 뜻은 아닙니다. 조직을 키우는 방식이 달라졌다는 얘기입니다.

또 다른 사례는 네 명짜리 팀이었습니다. 이 팀은 영업 리드 발굴, 인바운드 라우팅, 고객 응대, 제품 개발 일부를 AI 자동화로 묶었습니다. 그래서 “팀에 여섯 자리 정도만 더 있습니다”고 말했습니다. 예전 같으면 영업, 지원, 제품, 운영을 역할별로 나눠 사람을 늘렸을 텐데 이제는 작은 팀이 먼저 시스템을 만듭니다.

이 흐름은 1인 유니콘 같은 구호보다 현실적입니다. 한 사람이 모든 일을 완전히 혼자 한다기보다, 소수 인원이 AI 에이전트를 업무 파이프라인에 넣고 조직의 빈칸을 메웁니다. 고객과 대화할 시간과 제품을 만들 시간을 서로 빼앗기지 않게 만드는 쪽에 가깝습니다.

AI 네이티브 조직은 부서별로 작은 루프부터 만듭니다

전통 기업이 바로 AGI 조직으로 바뀌기는 어렵습니다. 영상에서도 전사 업무를 한 번에 AI로 끝까지 처리하려는 접근은 위험하다고 봅니다. 사람이 들어가야 하는 구간이 많기 때문입니다.

출발점은 더 작습니다. 재무팀, 법무팀, 미수금 관리팀, 고객지원팀, 엔지니어링팀처럼 업무 단위를 나눠 봅니다. 그중 모델이 이미 잘하는 일, 제대로 만들면 팀 전체에 바로 도움이 되는 일을 먼저 고릅니다. 버그 리포트가 들어왔을 때 긴급도를 분류하거나, 반복 문의를 묶거나, 내부 문서를 찾아 초안을 만드는 식입니다.

좋은 회사는 이 실험을 개인 취미로 방치하지 않습니다. 사내에서 AI를 가장 잘 만지는 사람을 찾아 챔피언으로 세웁니다. 해커톤과 데모 세션도 맡깁니다. 특정 부서의 작은 성공을 다른 팀으로 옮깁니다. OpenAI도 Codex 해커톤에서 팀원들이 서로의 사용법을 배웠다고 합니다.

제품 개발 프로세스 자체가 AI 중심으로 바뀝니다

영상에서 언급된 한국 회사 사례가 특히 인상적이었습니다. 이 회사는 제품 개발 흐름 전체를 AI 중심으로 다시 짰습니다. 연구에서 시작해 제품 요구사항으로 바꾸고 디자인 후보를 만듭니다. 그다음 코드로 옮기고 배포 후 피드백을 받아 다시 처음으로 돌아갑니다.

여기서 AI는 사람을 빼는 역할이 아니었습니다. 사람이 직접 판단해야 하는 지점은 남겨둡니다. 대신 AI가 연구, 초안, 설계 후보, 반복 작업을 빠르게 밀어줍니다. 팀원 모두가 적은 노력으로 같은 흐름을 쓰도록 맞춤 워크플로우를 만든 것도 포인트였습니다. 인터뷰에서는 이 워크플로우 자체를 상품으로 팔아도 될 정도였다고 평가했습니다.

이 사례는 AI 네이티브가 “AI를 써야 합니다”는 선언만으로 만들어지지 않는다는 걸 보여줍니다. 회사가 원래 어떤 제품을 좋아하는지, 어떤 방식으로 만드는지, 어떤 피드백을 중시하는지부터 알아야 합니다. 그 기준에 맞게 에이전트와 사람의 루프를 설계해야 실제로 돌아갑니다.

역할 경계는 흐려지고 조직은 더 납작해집니다

AI 도구가 강해질수록 제품 관리자, 디자이너, 엔지니어의 경계는 흐려집니다. PM이 직접 프로토타입을 만듭니다. 엔지니어는 제품 판단과 디자인에 더 깊게 들어갑니다. 고객과 이야기하면서 기술도 다루는 하이브리드형 인재가 더 중요해집니다.

조직 구조도 비슷합니다. 영상에서는 AI를 잘 쓰는 스타트업일수록 팀이 작고 수평적이라고 봅니다. 중간 관리자가 하던 리포팅, 정보 취합, 상태 정리 업무 일부를 도구가 흡수하기 때문입니다. 관리자 한 명 아래 여덟 명이 붙는 고전적 구조보다 더 넓은 범위의 팀이 자율적으로 움직이는 모습에 가깝습니다.

그렇다고 기본기가 사라지는 건 아닙니다. 오히려 문제를 정확히 설명하는 능력이 더 중요해집니다. 에이전트가 기대한 대로 동작하지 않을 때 프롬프트를 보면 사람이 머릿속으로 알고 있던 도메인 조건을 빼먹은 경우가 많습니다. 사람에게 일을 맡길 때 필요한 명확한 커뮤니케이션이 에이전트에게도 그대로 필요합니다.

창업 아이디어는 문제 집착과 미래 가설에서 나옵니다

마지막 조언은 단순했습니다. 지금 20살이고 AI로 창업한다면, 먼저 자신이 정말 해결하고 싶은 문제를 찾으라는 것입니다. 법무 절차가 반복적으로 고통스러웠거나, 제조 현장의 안전 문제가 눈에 밟혔거나, 교육 접근성 같은 주제에 오래 끌렸다면 그 문제가 출발점이 됩니다.

두 번째는 1년 뒤 모델이 무엇을 잘하게 될지 가설을 세우는 일입니다. 지금은 아직 약하지만 빠르게 좋아질 영역에 미리 들어가 문제와 시장을 파악해 두면 모델 성능이 충분해졌을 때 바로 움직입니다. 영상에서는 교육과 헬스케어를 기대 영역으로 꼽았습니다.

AI 네이티브 기업을 만드는 방법은 거창한 선언보다 훨씬 손에 잡힙니다. 새 도구를 계속 만져보는 사람을 키웁니다. 작은 업무 루프를 바꾸고 사람의 판단이 들어가는 지점을 정확히 남깁니다. 그 과정을 반복하는 회사가 빠르게 달라집니다.

짧게 보면

  • AI 네이티브 기업은 AI 도입률보다 실험 속도와 업무 루프 재설계 능력으로 갈립니다.
  • Codex는 코딩 보조를 넘어 분석, 피드백 정리, 자동화, 유지보수, 사내 검색까지 들어가고 있습니다.
  • 작은 팀은 AI 에이전트로 영업, 고객지원, 제품 개발의 빈칸을 메우며 더 적은 인원으로 큰 일을 합니다.
  • 전통 기업은 전사 자동화보다 부서별 작은 루프와 사내 AI 챔피언 육성부터 시작하는 편이 현실적입니다.