사람을 더 뽑았는데 스타트업이 오히려 느려지는 이유

“대표님, 그런데 이 기능은 왜 먼저 만드는 거였죠?”

저희 팀 또한 팀이 4명이었을 때는 이런 질문이 거의 필요하지 않았습니다. 고객과 통화하는 소리가 같은 공간에 들렸고, 기획자와 개발자가 그 자리에서 의견을 즉시 나눴습니다. 무엇을 왜 만드는지 따로 설명하지 않아도 모두가 대략 알고 있었습니다.

대표님이 아래처럼 한마디만 해도 충분했습니다.

“지난번 고객이 말한 그 문제부터 해결해 주세요.”

그런데 팀이 7명, 8명으로 늘어나면 같은 문장이 제대로 작동하지 않기 시작합니다.

새로 들어온 팀원은 지난번 고객이 누구인지 모릅니다. 개발자는 고객의 문제보다 기능 요구사항만 전달받습니다. 디자이너는 처음 논의한 배경을 모른 채 최신 버전의 화면만 봅니다.

모두 열심히 일하는데 결과는 점점 어긋납니다.

회의는 늘어나고 대표는 같은 설명을 반복합니다. 사람을 더 뽑았는데 의사결정은 느려지고 제품 배포 일정은 오히려 밀립니다.

문제는 여섯 번째 사람이 아닙니다.

5명일 때 통했던 방식으로 8명, 10명의 회사를 운영하고 있다는 것이 문제였습니다.

5명은 마법의 숫자가 아니라 전환을 감지하기 좋은 숫자입니다

모든 스타트업이 정확히 6명부터 흔들리는 것은 아닙니다. 팀 규모와 성과 사이에는 하나의 정답이 없습니다. 복잡한 과업에서는 사람이 늘어날수록 분업과 협업의 이점이 커지는 동시에, 소통과 조정에 필요한 비용도 함께 커집니다. 실제 연구에서도 큰 팀과 작은 팀 중 어느 쪽이 항상 우월하다고 단정하기 어렵다고 설명합니다. (PLOS ONE)

다만 구성원 사이에 생길 수 있는 관계의 수는 사람 수보다 훨씬 빠르게 늘어납니다.

• 3명  →  3개의 관계
• 5명  →  10개의 관계
• 8명  →  28개의 관계
• 10명 →  45개의 관계

모든 사람이 매일 모든 사람과 대화한다는 의미는 아닙니다. 하지만 누가 무엇을 알고 있는지, 어떤 결정에 누구의 의견이 필요한지, 변경된 내용을 누구에게 다시 전달해야 하는지를 조정할 가능성은 급격히 증가합니다.

5명까지는 서로의 일을 자연스럽게 볼 수 있습니다. 그 이후부터는 회사의 맥락이 사람마다 다른 조각으로 나뉘기 시작합니다.

5명까지는 같은 공간의 암묵적 맥락이 문서 역할을 합니다

초기 창업팀은 왜 이 사업을 시작했는지, 어떤 고객 문제가 중요한지, 무엇을 만들지 않기로 했는지를 함께 일하며 자연스럽게 배웁니다. 대표의 머리가 회사의 데이터베이스이고, 옆자리 대화가 알림 시스템입니다.

초기에는 이 방식이 빠릅니다. 의사결정자가 같은 공간에 있으니 모호한 부분도 몇 분이면 정리됩니다.

하지만 초기 멤버들이 암묵적으로 공유하던 판단 기준을 신규 구성원은 알 수 없습니다. Stripe의 전 COO도 작은 창업팀에서 자연스럽게 공유되던 믿음과 의사결정 원칙을 명문화하지 않으면, 조직이 확장될 때 새로 합류한 사람이 이를 그대로 이해하기 어렵다고 설명했습니다. (First Round Review)

회사 규모는 커졌는데 운영 방식은 제자리에 머뭅니다. 궁금한 것이 생기면 대표에게 묻고, 대표는 배경을 다시 설명합니다. 그 내용은 각자의 방식으로 정리되고 일부만 전달됩니다. 결과가 달라지면 다시 대표에게 확인합니다.

처음에는 빨랐던 방식이 어느 순간 가장 큰 병목이 됩니다.

스타트업이 5명을 넘어갈 때 흔들리는 세 가지 이유

1. 대표가 회사의 모든 요청을 처리하는 라우터가 됩니다

초기에는 대표가 모든 일에 관여하는 것이 오히려 장점입니다. 고객의 반응을 가장 잘 알고 있고, 사업의 방향과 자금 상황까지 함께 고려해 빠르게 결정할 수 있기 때문입니다.

사람이 늘어난 뒤에도 모든 결정이 대표를 거쳐야 한다면 팀 전체의 속도는 대표 한 사람의 처리 속도로 제한됩니다.

대표가 회의 중이면 결정이 멈추고, 영업하러 나가면 프로젝트가 기다립니다.

팀에서는 같은 질문이 반복됩니다.

“대표님, 이건 어떻게 할까요?”

“대표님, 어느 게 더 중요한가요?”

“전에 말씀하신 것과 지금 내용이 다른데 어떤 게 맞나요?”

대표는 하루 종일 바쁜데 구성원은 대표의 답을 기다립니다. 이 상태에서 사람을 더 뽑으면 실행력보다 대표에게 들어오는 질문의 수가 늘어납니다.

2. 일은 전달되지만 왜 하는지는 전달되지 않습니다

한 고객이 엑셀 내보내기 기능을 요청했다고 가정해봅시다.

고객이 실제로 겪는 문제는 단순히 엑셀 파일이 필요하다는 것이 아닐 수 있습니다. 매주 금요일 이사회 보고를 해야 하는데 데이터를 다시 정리하는 데 세 시간이 걸리고, 그 과정에서 숫자가 자주 틀리는 것이 진짜 문제일 수 있습니다.

이 내용이 여러 사람을 거치면 이렇게 축약됩니다.

고객의 문제
“이사회 보고 자료를 만드는 데 매주 3시간이 걸리고 숫자 오류가 발생한다.”

↓
영업팀의 전달
“엑셀 다운로드 기능이 필요합니다.”

↓

기획 문서
“데이터 내보내기 기능 추가”
↓

개발 태스크
“Export API 구현”

태스크는 살아남았지만 문제는 가려졌습니다.

개발자는 요청받은 기능을 정확하게 구현했지만 고객이 필요했던 보고서 형식과 맞지 않을 수 있습니다. 결국 다시 수정해야 합니다.

누군가 일을 잘못한 것이 아닙니다. 모두가 자신에게 전달된 정보 안에서는 합리적으로 일했습니다.

다만, 전달 과정에서 고객의 문제와 의사결정의 근거가 분리된 것이 원인일 수 있습니다.

3. 대화가 많아질수록 회사 안의 진실이 여러 개가 됩니다

팀이 작을 때는 대화와 결정이 거의 동시에 일어납니다. 사람이 늘어나면 대화가 여러 장소로 나뉩니다.

Slack에서는 A안으로 이야기했고, 회의에서는 B안으로 바뀌었습니다. 
Notion에는 아직 A안이 남아 있고, 개발자는 GitHub 이슈에 적힌 C안을 구현하고 있습니다.

각자 서로 다른 최신 정보를 가지고 일합니다.

정보는 충분하지만 다음 질문에 답하기 어렵습니다.

• 최종적으로 무엇이 결정됐는가?
• 누가 결정했는가?
• 왜 그렇게 결정했는가?
• 이전 내용에서 무엇이 바뀌었는가?

기존 문장이 덮어쓰기 되면 나중에는 결과만 있고 이유가 없습니다.

사람의 기억이 회사의 실행 기록을 대신하기 시작합니다.

가장 어려운 것은 체계와 속도 사이의 애매한 구간입니다

이런 문제가 반복해서 나타나는데도 쉽게 해결되지 않는 이유는, 팀이 놓인 단계가 애매하기 때문이라고 생각합니다.

고작 7명, 8명인데 체계를 갖춰 일하자니 조직이 갑자기 무거워지는 것 같습니다. 그렇다고 체계 없이 빠른 실행만 강조하면 중요한 맥락과 결정의 이유가 남지 않습니다.

많은 팀이 이 사이에서 어느 쪽도 빠르게 선택하지 못합니다. 기존 방식은 더 이상 제대로 작동하지 않지만, 새로운 운영 방식을 만들기에는 아직 이르다고 느끼기 때문입니다.

저희 팀도 초기에는 같은 딜레마를 겪었습니다.

그래서 해결책은 무엇일까요?

해결책은 회의와 문서를 무작정 늘리는 것이 아닙니다

이 문제를 발견한 스타트업은 대개 회의와 문서를 늘리고, 새로운 프로젝트 관리 도구나 보고 양식을 도입합니다.

일시적으로는 정리되는 것처럼 보이지만 운영 원리 없이 절차만 추가하면 고객 문제를 해결하는 시간보다 현재 상황을 설명하는 시간이 더 길어집니다.

Slack, Notion, Jira, Linear, GitHub와 같은 도구의 기능이 부족해서 생긴 문제도 아닙니다. 정보는 이미 여러 도구에 충분히 쌓여 있습니다. 문제는 그 정보들이 하나의 실행 흐름으로 연결되지 않는다는 것입니다.

스타트업에 필요한 것은 대기업 수준의 복잡한 결재 체계가 아닙니다.

사람이 늘어나도 왜 이 일을 시작했고, 무엇을 결정했으며, 어떤 결과가 나왔는지가 끊기지 않는 최소한의 실행 구조입니다.

그 구조는 최소한 다음 흐름을 유지합니다.

고객의 문제 또는 목표
→ 팀이 내린 결정
→ 수행한 작업
→ 만들어진 결과물
→ 고객과 데이터로 확인한 변화

중요한 작업마다 다음 질문에 답할 수 있어야 합니다.

• 왜 지금 이 일을 하는가?
• 어떤 결과를 만들기 위한 것인가?
• 누가 최종 결과를 책임지는가?
• 무엇을 확인하면 완료됐다고 판단하는가?

그리고 대화와 결정을 분리해야 합니다. 회의록을 길게 쓰기보다 결정한 내용과 이유, 선택하지 않은 대안, 최종 결정자, 변경이 일정과 범위에 미치는 영향을 남겨야 합니다.

이 기록이 반복되면 대표의 기억이 조직의 자산으로 바뀝니다.

그래서 뤼이도를 만들고 있습니다

기존 프로젝트 관리 도구는 주로 무엇을 해야 하는지, 누가 담당하는지, 언제까지 해야 하는지, 현재 상태가 무엇인지에 답합니다.

뤼이도는 여기에 몇 가지 질문을 더 연결합니다.

• 왜 이 일을 하는가?
• 어떤 문제에서 시작됐는가?
• 무엇을 근거로 결정했는가?
• 중간에 무엇이 바뀌었는가?
• 결과물이 실제로 어떤 변화를 만들었는가?

뤼이도는 조직의 목표, 결정, 작업, 결과물을 하나의 실행 맥락으로 연결하는 AI 네이티브 실행 레이어입니다.

쉽게 말하면 고객의 문제가 어떤 결정과 작업을 거쳐 어떤 결과로 이어졌는지 끊기지 않게 남기는 운영 구조입니다.

Slack의 대화를 없애거나 Notion의 문서, GitHub의 코드, Figma의 디자인을 모두 한곳으로 옮기자는 것도 아닙니다. 팀이 이미 사용하는 도구는 그대로 두고, 그 사이에서 사라지기 쉬운 인과관계를 연결하는 것이 뤼이도의 역할입니다.

앞에서 본 엑셀 내보내기 사례도 곧바로 ‘Export API 구현’만 태스크로 만들지 않습니다. 보고서 작성에 세 시간이 걸리고 숫자 오류가 난다는 문제를 먼저 남기고, 결정 이유와 대안, 기획 문서와 개발 작업, 배포 결과를 같은 흐름에 둡니다. 마지막에는 작성 시간과 오류가 실제로 줄었는지 확인합니다.

담당자가 바뀌어도 다음 사람은 태스크 제목만 보는 것이 아니라 고객 문제에서 결정, 작업, 결과까지 이어진 흐름을 따라갈 수 있습니다.

그래서 우리는 도구만 건네지 않습니다.

초기 도입 기간에는 뤼이도 팀의 PM이 실제 프로젝트 하나를 기준으로 목표와 완료 조건을 정리하고, 결정과 변경 이력이 작업·결과물까지 이어지도록 초기 구조를 만듭니다.

팀이 쓰던 자리도 옮기지 않습니다. 대화는 Slack에, 문서는 Notion에, 코드는 GitHub에 그대로 두고 그 사이에서 끊기던 연결만 잡습니다.

PM이 빠진 뒤에 남겨드리는 것은 도구 사용법이 아니라 실행 구조입니다.

모든 초기 스타트업에 운영 구조가 필요한 것은 아닙니다

공동창업자 2~3명이 하루 종일 같은 공간에서 일하고 있다면 대화로 맞추는 편이 더 빠를 수 있습니다.

다만 다음 현상이 반복되기 시작했다면 운영 방식의 전환을 검토할 수 있습니다.

• 대표가 같은 배경을 여러 사람에게 반복해서 설명합니다.
• 최종 결정이 Slack, 회의, Notion 중 어디에 있는지 알기 어렵습니다.
• 태스크는 완료됐지만 고객의 문제가 해결됐는지는 확인하지 않습니다.
• 새로운 팀원의 온보딩이 오래된 구성원의 구두 설명에 의존합니다.

이 중 두세 가지가 이미 나타나고 있다면 문제는 팀원의 역량이나 태도만이 아닐 가능성이 높습니다.

회사의 운영 방식이 현재 인원보다 작은 규모에 머물러 있는 것입니다.

뤼이도 역시 처음부터 회사 전체를 바꾸는 방식으로 도입할 필요는 없습니다. 진행 중인 프로젝트 하나를 정하고 2주 동안 세 가지만 확인하면 됩니다.

• 문제와 결정의 근거가 실제 작업까지 이어지는가?
• 변경된 내용과 이유를 나중에도 이해할 수 있는가?
• 완료된 결과가 실제 고객 문제의 해결과 연결되는가?

👉👉👉 우리 팀의 실행 구조 1분 진단하기

사람을 채용하는 것과 조직이 성장하는 것은 다릅니다

5명의 조직에서 사람을 다섯 명 더 채용해도 회사가 자동으로 두 배의 일을 할 수 있게 되는 것은 아닙니다. 
맥락을 전달하고 결정을 내리며 실행을 연결하는 방식도 함께 달라져야 합니다.

5명까지는 뛰어난 사람들이 회사를 움직입니다. 5명을 넘어가면 뛰어난 사람들의 판단과 실행이 서로 연결되도록 만드는 구조가 회사를 움직입니다.

필요한 것은 단순합니다.

왜 시작했는지, 무엇을 결정했는지, 누가 실행하는지, 어떤 결과가 나왔는지가 끊기지 않게 만드는 것.

저희 뤼이도 팀 또한 5명까지는 대표가 회사의 운영체제였습니다.

그 이후에는 대표의 머릿속에 있던 맥락이 조직의 운영체제로 탈바꿈 했습니다.

뤼이도 팀은 이미 그 전환을 겪었고, 이제 같은 문제를 마주할 다른 팀들을 위해 만들어가고 있습니다.

대표가 같은 설명을 반복하거나 최종 결정이 Slack·Notion·회의 사이에 흩어져 있다면, 프로젝트 하나를 기준으로 맥락이 끊기는 지점을 진단하고 필요한 경우 뤼이도를 활용한 2주 검증을 진행할 수 있습니다.

👉👉👉  우리 팀의 실행 구조 1분 진단하기
 

긴 글 읽어주셔서 감사합니다!

👉👉👉  뤼이도 데모 보러가기