한 가지만 한다

Part I — The Problem

동시에 고치면 동시에 무너진다

자원이 부족한 조직일수록 한 사람이 여러 역할을 겸한다. 기획, 개발, 영업, 관리가 한 사람의 머리 안에서 교차한다. 보통의 결론은 "더 열심히 해야 한다"다. 데이터는 다르게 말한다.

Gloria Mark(UC Irvine)의 연구다. 지식근로자가 하나의 화면에 집중하는 시간은 평균 47초. 한 번 끊긴 집중을 되찾는 데 23분 15초. 미국심리학회(APA)는 업무 전환 비용만으로 하루 생산성의 40%가 사라진다고 추산한다. 역할을 겸할수록 전환은 늘어나고, 실질 산출은 줄어든다.

McKinsey에 따르면, 기업 전환 시도의 70%가 실패한다. 실패 원인은 역량 부족이 아니다. 모든 것을 동시에 고치려 하기 때문이다. 비용 절감, 매출 성장, 조직 개편, 디지털 전환 — 한꺼번에 시작하고, 한꺼번에 무너진다.

70%가 실패하는 이유는 역량 부족이 아니다.
동시에 모든 것을 고치려 했기 때문이다.

McKINSEY TRANSFORMATION STUDY

Part II — The Framework

병목 하나

1984년, 물리학자 엘리야후 골드랫은 제약이론(Theory of Constraints)을 발표했다. 시스템 전체의 성과는 가장 약한 고리 하나에 의해 결정된다. 파이프라인에 병목이 하나 있으면, 나머지 99%를 아무리 개선해도 전체 처리량은 그 병목에 묶인다. Mabin과 Balderstone의 메타분석은 이 이론을 적용한 100개 이상의 기업을 추적했다.

처리량 증가

68%

병목 하나를 해소했을 때의 평균 산출량 증가. Lucent Technologies는 600%를 기록했다.

리드타임 단축

70%

주문에서 납품까지의 시간 단축. 리투아니아 정부 서비스는 388일을 63일로 줄였다.

실패 건수

100개 이상의 사례 중 실패가 단 한 건도 없었다. 병목에 집중하면 시스템은 반드시 개선된다.

방법론은 5단계다. 식별(가장 막히는 지점을 찾는다) → 활용(병목의 산출을 최대화한다) → 종속(나머지를 병목의 속도에 맞춘다) → 강화(병목에만 자원을 집중 투입한다) → 반복(해소되면 다음 병목을 찾는다). Apple은 1997년 파산 직전, 제품의 70%를 삭감하고 4개에 집중해 살아남았다. LEGO는 2003년 비핵심 사업을 전부 매각하고 브릭 하나에 집중해 세계 1위가 됐다.

문제는 "병목을 찾아라"가 조언에서 끝나기 쉽다는 것이다. 아래는 조언이 아니라 상황별 실행 매뉴얼이다.

Part III — The Playbook

상황별 실행

매출의 흐름을 따라가면 병목은 네 가지 중 하나다. 고객이 안 오거나, 납품이 느리거나, 제품이 안 팔리거나, 현금이 돌지 않거나. 자신의 상황을 진단하고, 해당하는 처방만 실행한다. 나머지는 멈춘다.

CASE A

고객이 안 온다

기술은 있다. 제품도 있다. 그런데 고객이 어디 있는지 모른다. 영업 인력이 없고, 마케팅 예산도 없다. 기존 고객의 소개에 의존하고 있다.

AI 기반 인바운드 파이프라인을 만든다. 업종 특화 블로그 5편 + SEO 랜딩 페이지 1개 + 자동 이메일 시퀀스를 구축한다. HubSpot 데이터에 따르면 블로그를 운영하는 B2B 기업은 그렇지 않은 기업보다 리드를 67% 더 확보한다. AI로 주 1편씩 발행하면 3개월이면 파이프라인이 작동하기 시작한다.

BUILD: SEO BLOG + LANDING PAGE + EMAIL SEQUENCE

CASE B

납품이 느리다

주문은 들어온다. 하지만 매번 비슷한 일을 처음부터 수작업으로 반복한다. 커스텀 개발, 수동 보고서, 반복 설정 작업이 시간을 잡아먹는다. 일감은 있는데 사람이 부족하다.

반복 업무를 제품으로 전환한다. 매번 반복하는 작업이 있다면, 그것이 제품이다. 내부 자동화 도구를 SaaS로 공개하거나, 수동 프로세스를 템플릿/API로 표준화한다. Basecamp(37signals)는 내부 프로젝트 관리 도구를 제품화해 수십억 달러 기업이 됐다. Copilot으로 개발 속도를 55.8% 올리면 한 사람이 제품을 만들 수 있다.

BUILD: INTERNAL TOOL → SAAS / TEMPLATE PRODUCT

CASE C

제품이 안 팔린다

개발은 했다. 기능도 추가했다. 그런데 매출이 없다. "기능을 더 넣으면 팔릴 것"이라는 가정 아래 계속 개발만 하고 있다.

개발을 멈추고 시장을 검증한다. 최소 기능 랜딩 페이지 1개를 만들고, 결제 버튼을 단다. 실제로 결제가 일어나는지 확인한다. Dropbox는 제품이 완성되기 전 설명 동영상 하나로 하룻밤에 대기 명단 75,000명을 모았다. 아무도 결제하지 않으면, 그 제품은 시장이 원하는 것이 아니다. 기능 추가가 아니라 고객 문제 재정의가 필요하다.

BUILD: VALIDATION LANDING PAGE + PAYMENT TEST

CASE D

현금이 돌지 않는다

일은 하고 있다. 매출도 발생한다. 하지만 수금이 느리거나, 선투자 비용이 크거나, 운영비가 매출보다 먼저 빠져나간다. 통장 잔고가 매달 줄어든다.

결제 구조를 바꾸거나, 외부 자금을 주입한다. 프로젝트 기반이라면 착수금 50% + 중간금 30% + 잔금 20% 구조로 전환한다. 반복 매출이 가능하면 월 구독형으로 바꾼다. 그래도 부족하면 이때 정부과제가 유효하다. 연간 1.5조 원 규모의 중소기업 R&D 예산이 있다. 단, KDI 분석에 따르면 정부 R&D 지원은 매출 개선에는 실패했다. 현금 주입 수단으로만 활용하고, 매출 병목은 별도로 해결해야 한다.

BUILD: PREPAYMENT MODEL / SUBSCRIPTION CONVERSION

핵심은 네 가지 중 하나만 고르는 것이다. A와 B가 동시에 문제처럼 보여도, 매출 흐름을 따라가면 먼저 막히는 지점은 반드시 하나다. 거기에 AI와 시간을 전부 쏟는다. BCG 조사에서 AI로 실질적 가치를 창출하는 기업은 전체의 5%에 불과하다. 나머지 95%는 AI를 여기저기 뿌렸기 때문이다.