3명이서 회사 하나를 굴리는 법 (AI 네이티브 조직 3개월 기록)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

세 명이서 회사 하나를 굴리는 핵심은 모두가 AI로 실행하되 제품 책임자·디자이너·개발자의 판단 경계를 지키고, 모든 결정을 하나의 문서에 모으는 것입니다.

📌 핵심 요점

1. AI 네이티브 조직은 개발자만 AI를 쓰는 팀이 아니라, 모든 직군이 AI를 통해 직접 결과물을 만들고 반영하는 팀입니다.
2. 디자이너는 화면 영역을 직접 수정하고, 개발자는 코딩보다 아키텍처 설계와 위험 검토에 집중하며, 제품 책임자는 작은 변경을 직접 처리하되 큰 기능은 스펙 문서로 위임한다.
3. 빠르게 움직이는 세 사람의 방향을 맞추는 핵심 장치는 회의가 아니라 결정·이유·포기한 대안을 기록한 ADR입니다.
4. 코드와 HTML 문서를 같은 저장소에 두면 변경 이력과 팀의 규칙을 사람과 AI가 함께 읽을 수 있으며, 중복 문서를 제거해 단일 진실 공급원을 유지할 수 있다.
5. 이 방식은 실행 속도를 높이지만 문서화 비용, AI 활용 역량의 개인차, 인력 여유 부족과 조직 확장성 미검증이라는 대가를 요구한다.

🧩 배경과 문제 정의

바이브 코딩은 본래 개인이 AI에 지시해 앱이나 기능을 만드는 도구로 인식됐지만, 이 팀은 이를 모든 직군이 따르는 조직 운영 규칙으로 확장했습니다. 문제는 세 사람이 기획·디자인·개발·마케팅을 빠르게 수행할수록 서로 다른 방향으로 움직일 위험도 커진다는 점입니다. 따라서 역할별 판단 경계를 유지하면서 기다림을 줄이고, 회의 없이도 같은 결정을 공유할 수 있는 단일 문서 체계가 필요했습니다.

🕒 시간순 섹션별 상세정리

1. 세 명의 AI 네이티브 조직

• 세 명이 3개월 동안 제품의 기획·디자인·개발·마케팅을 운영했으며, 인력을 늘리는 대신 모든 팀원이 AI에 지시해 결과를 만드는 바이브 코더로 일했다고 보여준다. [00:34]
• 개인이 사용하던 AI 코딩 도구를 팀의 규칙으로 확장하면 직군 사이의 전달과 대기가 줄고, 디자이너가 버튼을 직접 수정하는 식으로 며칠 걸리던 일이 수분 단위로 단축됩니다. [01:47]

2. 디자이너·개발자·제품 책임자의 역할 재편

• 디자이너는 눈에 보이는 화면을 AI로 직접 수정하고 서비스에 반영하되, 데이터와 내부 구조는 개발자의 영역으로 남겨 의도 손실과 무분별한 변경을 함께 줄입니다. [02:40]
• 개발자는 직접 코드를 쓰는 시간보다 아키텍처와 위험 검토에 집중하고, 제품 책임자는 시스템 전체를 이해한 상태에서 작은 변경은 직접 처리하고 큰 기능은 스펙 문서로 넘깁니다. [04:35]

3. 회의를 대신하는 ADR

• 세 사람이 빠르게 움직일수록 방향이 어긋날 수 있으므로, 무엇을 정했는지·왜 정했는지·무엇을 버렸는지를 기록한 ADR을 공통 기준으로 사용합니다. [05:25]
• ADR을 노션이나 구글 문서가 아닌 HTML 파일로 만들어 코드와 같은 저장소에 두면 변경 이력이 남고, 비개발자는 브라우저로 열 수 있으며, AI도 사람이 보는 것과 같은 규칙을 읽을 수 있습니다. [06:24]

4. 단일 진실 공급원과 일상 운영

• 같은 규칙을 여러 곳에 적으면 내용이 달라져 재작업이 발생하므로, 팀은 노션의 중복 규칙을 삭제하고 합의 중인 초안까지 하나의 문서에서 커밋으로 논의합니다. [07:15]
• 아침에는 회의 대신 변경 문서를 읽고, 낮에는 각자 작업하며, 문서에 없는 문제가 생길 때만 대화한 뒤 그 결론을 다시 문서에 넣습니다. 리뷰도 취향이 아니라 문서와의 일치 여부를 기준으로 진행합니다. [08:13]

5. 작은 실험으로 시작하는 도입법

• 중요한 결정 하나를 세 줄로 기록하고, 비개발자 한 명이 오타처럼 작은 변경을 직접 처리하게 한 뒤, 중복 문서 하나를 삭제하는 세 단계가 제안됩니다. [08:56]
• 처음부터 조직 전체를 바꾸거나 도구부터 구매하지 말고, 한 달 동안 운영 방식을 먼저 실험한 다음 필요한 도구를 선택해야 한다고 강조한다. [09:08]

6. 운영 비용과 최소 조직 구성

• 문서 작성에 업무 시간의 약 3분의 1이 들고, AI 지시 역량의 개인차가 크며, 세 명 중 한 명만 빠져도 일정이 밀리는 등 소수 조직의 여유 부족과 확장성 문제가 남아 있습니다. [10:06]
• 최소 구성은 무엇을 만들지 판단하는 제품 책임자, 어떻게 보일지 판단하는 UI/UX 디자이너, 무너지지 않게 만드는 개발자이며, 다음 채용은 생산 이후의 병목을 풀 마케팅과 사업 개발 순으로 제안합니다. 마지막 원칙은 진실을 한 군데에만 두라는 것입니다. [11:11]

🧾 결론

• AI는 반복적인 실행을 대신할 수 있지만 무엇을 만들지, 어떻게 보여줄지, 어떤 구조로 안전하게 운영할지에 대한 판단까지 대신하지는 못한다.
• 세 명의 조직이 작동하려면 제품 책임자·UI/UX 디자이너·개발자가 서로 대체할 수 없는 판단을 맡고, 직접 수정할 영역과 문서로 합의할 영역을 구분해야 한다.
• 조직 전환은 도구 구매보다 결정 하나의 문서화, 비개발자의 작은 수정, 중복 문서 하나의 삭제처럼 제한된 실험에서 시작하는 편이 적합한다.
• 최종적으로 조직의 속도를 결정하는 것은 AI 도구의 수가 아니라 같은 기준을 보고 판단하게 만드는 운영 방식입니다.

📈 투자·시사 포인트

• AI 코딩 도구의 확산은 개발 인력을 단순히 대체하기보다 디자인·기획·제품 운영 직군의 실행 범위를 넓히고, 개발자의 가치를 아키텍처와 검토 역량 쪽으로 이동시킬 가능성을 보여준다.
• 제품 생산 속도가 빨라지면 병목은 개발에서 마케팅과 사업 개발로 이동할 수 있으므로, AI 네이티브 기업을 평가할 때 배포량뿐 아니라 유통과 시장 확장 역량도 함께 살펴야 한다.
• 문서와 코드를 같은 저장소에서 관리하고 사람과 AI가 동일한 규칙을 읽게 하는 지식 관리 방식은 AI 에이전트 기반 업무 자동화의 기반이 될 수 있다.
• 소수 인원 운영은 고정비를 낮출 수 있지만 한 명의 부재에도 일정이 밀리는 구조이므로, 높은 생산성과 조직 회복력을 동일한 것으로 해석해서는 안 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제시된 결과는 한 팀이 세 명으로 3개월 동안 운영한 경험에 기반하며, 매출·사용자 증가·배포 빈도·결함률 같은 정량 성과는 공개되지 않았습니다.
• 세 명에게 적용된 역할 구조와 문서 중심 운영 방식이 30명 규모에서도 유지되는지는 발표자도 검증하지 못했다고 명시한다.
• AI 활용 능력의 개인차가 크고 경력이 짧은 구성원일수록 무엇을 지시해야 하는지 판단하기 어렵지만, 이를 보완할 채용·교육·검수 방법은 제시되지 않았습니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 최근 팀에서 내린 중요한 결정 하나를 골라 무엇을 정했는지, 왜 정했는지, 어떤 대안을 버렸는지 기록한다.
• 결정 문서를 코드와 가까운 위치에 두고, 사람과 AI가 같은 문서를 기준으로 작업하도록 설정한다.
• 비개발자 한 명이 오타나 문구처럼 영향 범위가 작은 변경을 AI로 직접 수정하고 반영해 보게 한다.
• 같은 규칙이 적힌 중복 문서를 찾아 하나를 삭제하고 단일 진실 공급원을 지정한다.

❓ 열린 질문

• 세 명에서 30명으로 조직이 커질 때 ADR의 수와 리뷰 비용을 어떻게 통제해야 할까요?
• AI 활용 능력이 부족한 신입 구성원이 안전하게 직접 수정할 수 있도록 어떤 교육과 검수 장치가 필요할까요?
• 핵심 인력 한 명의 부재에도 운영이 멈추지 않도록 최소한의 역할 중복과 인수인계를 어디까지 마련해야 할까요?