<스타트업은 ‘문제 해결’을 너무 빨리 시작합니다>
“Don’t fix the problem. Fix the system that created it.”
(문제를 해결하지 마세요. 문제를 일으킨 시스템을 고치세요.)
- Donella Meadows, Thinking in Systems (2008)
많은 스타트업이 이렇게 말합니다. “우리는 문제 해결 집단이다.” 하지만 진짜 중요한 건 문제를 해결하는 능력보다, 문제가 다시 생기지 않게 만드는 구조를 설계하는 능력입니다.
해결은 단기적이고, 구조는 장기적입니다. 해결은 ‘소방관’의 일이라면, 구조는 ‘도시 설계자’의 일입니다. 이 장에서는 바로 그 ‘도시 설계자들’을 이야기하려 합니다.
<Stripe - 문제보다 구조를 고친 형제들>
온라인 결제 시스템이 복잡하던 시절, Stripe의 공동창업자 Patrick & John Collison 형제는 “문제를 해결하겠다”가 아니라 “결제의 구조를 단순화하겠다”고 말했습니다.
“We didn’t want to fix payments. We wanted to fix how software handles money.”
(“우리는 결제를 고치고 싶었던 게 아니라, 소프트웨어가 돈을 다루는 방식을 고치고 싶었습니다.”)
- Patrick Collison, Y Combinator Talk, 2016
Stripe는 이후 “7줄의 코드로 결제 기능을 붙이는 구조”를 만들었고, 그 구조는 수천 개 스타트업의 문제 해결 방식을 완전히 바꿨습니다. 2023년 현재, Stripe API를 사용하는 기업 수는 300만 개가 넘습니다. 그들은 문제를 해결한 게 아니라, 문제 해결의 프레임 자체를 다시 쓴 셈이었습니다.
<Atlassian - ‘문제 회의’를 없앤 회사>
Atlassian은 Jira·Confluence로 유명한 협업 도구 기업입니다. 초기 시절, 이 회사의 공동창업자 Scott Farquhar는 ‘문제 해결 미팅’이 팀을 오히려 지치게 만든다는 걸 깨달았습니다. 그래서 그는 과감히 미팅 문화를 바꿨습니다.
“Don’t meet to fix problems. Meet to improve systems.”
(“문제를 고치기 위해 모이지 말고, 시스템을 개선하기 위해 모이세요.”)
- Scott Farquhar, Atlassian Blog, 2019
이후 Atlassian은 전사적 ‘Incident Playbook’을 만들었고, 문제가 생기면 ‘누가 잘못했는가’가 아니라 ‘어떤 구조가 실패했는가’**를 기록했습니다. 그 덕분에 2018~2023년 사이, Atlassian의 평균 장애 대응 시간이 62% 단축되었습니다. 그들의 해결 방식은 ‘인간 중심’이 아니라 ‘구조 중심’이었습니다.
<Shopify - 문제보다 리듬을 설계한 사람들>
Shopify의 창업자 Tobias Lütke는 성장기에 “문제가 터지는 속도보다 해결 속도가 느리다”는 말을 자주 들었습니다. 그는 이를 이렇게 바꿔 말했습니다.
“We don’t move fast and break things. We move intentionally and build rhythms.”
(“우리는 빠르게 움직이며 부수지 않습니다. 의도적으로 움직이며 리듬을 만듭니다.”)
- Tobias Lütke, Bloomberg Interview, 2022
Shopify는 이후 ‘리듬 단위 운영 시스템(Rhythm-based Ops)’을 도입했습니다. 모든 팀이 6주 단위로 목표를 설정하고, 2주마다 “System Health Check”를 하도록 바꿨죠.
결과적으로 Shopify는 2023년 매출이 21% 성장했지만, 개발자 이직률은 오히려 줄었습니다. 문제를 빨리 푸는 대신, 문제가 덜 생기도록 리듬을 설계한 것입니다.
<Notion - “혼돈을 정리하는 언어”>
Notion의 공동창업자 Ivan Zhao는 이런 말을 자주 했다고 합니다.
“Notion is not a tool to fix chaos. It’s a tool to organize it.”
(“노션은 혼돈을 없애는 도구가 아니라, 혼돈을 정리하는 도구입니다.”)
- Ivan Zhao, First Round Review, 2020
그는 “모든 회사는 결국 정리 정돈으로 무너진다”고 했습니다. 그래서 Notion은 기능보다 정보 구조(Information Architecture) 에 집중했습니다. 즉, 문제를 ‘제거’하려 하지 않고, ‘정리 가능한 형태’로 바꾼 것이죠.
그 결과, Notion은 2020년 이후 조직 규모가 10배 늘었음에도 문서 관리 프로세스는 동일한 형태로 유지되고 있습니다. 이건 단순한 효율이 아니라, 지속 가능한 질서의 설계였습니다.
<Slack - 문제를 대화로 바꾼 구조>
Slack의 창립자 Stewart Butterfield는 문제를 ‘프로세스의 오류’로 보지 않았습니다. 그는 이렇게 말했습니다.
“Every problem is a communication problem in disguise.”
- Stewart Butterfield, MIT Sloan Talk, 2018
(“모든 문제는 사실, 소통의 문제로 위장되어 있습니다.”)
Slack은 문제를 ‘보고서’로 처리하지 않고 ‘대화 구조’로 전환했습니다. 즉, 문제를 문서로 고정시키지 않고 실시간 토론이 가능한 공간에서 해결하도록 만들었죠. 이 접근법은 Slack 내부뿐 아니라, 수많은 스타트업의 협업 문화까지 바꿨습니다. Slack은 ‘문제 해결’의 상징이 아니라, ‘문제 소통 구조’의 대표 사례가 되었습니다.
<마치며 - 해결보다 구조를 만들어라>
Stripe는 결제의 구조를 바꿨고, Atlassian은 회의의 구조를 고쳤고, Shopify는 리듬의 구조를 설계했고, Notion은 혼돈의 구조를 정리했고, Slack은 대화의 구조를 만들었습니다.
이들의 공통점은 단 하나입니다. 문제를 직접 해결하지 않고, 문제를 만드는 구조를 고쳤다는 것
“Don’t fix the problem. Fix the system that created it.”
(“문제를 고치려 하지 말고, 그 문제를 만든 구조를 고치세요.”)
Donella Meadows
스타트업의 진짜 실행가는 문제의 주인공이 아니라, 구조의 설계자입니다.