What과 How 사이에서
스프린트가 끝났다. 개발자들에게 할 일이 없다.
기획은 아직 나오지 않았고, 디자인은 리뷰 중이다. 백로그에는 "추후 논의"라는 딱지가 붙은 티켓들만 쌓여 있다. 이상한 일이었다. 팀의 실행 속도는 분명히 빨라졌다. 예전에 2주가 걸리던 기능을 며칠 만에 끝낸다. 그런데 팀 전체의 체감 속도는 오히려 느려졌다. 엔지니어들은 손이 비고, PM과 디자이너는 숨이 가쁘다. 실행이 빨라졌는데 팀이 느려지는 이 역설은 대체 어디에서 오는 걸까.
앞선 챕터들에서 사람을 다루는 기술 — 공정함, 피드백, 장면을 보여주는 매니지먼트 — 을 이야기했다. 사람 사이의 신뢰가 확보되었다면, 이제 질문은 자연스럽게 "일"로 옮겨간다. 이 팀이 무엇을, 어떤 구조로 할 것인가. 이 챕터는 그 질문에 대한 탐색이다.
How가 공짜가 되어가는 세상
지난 몇 년간 "만드는 비용"은 극적으로 줄었다. AI 코딩 도구, 자동화 파이프라인, 코드 생성기. 과거에 시니어 개발자 두 명이 2주를 매달려야 했던 기능을, 이제는 주니어 한 명이 3일이면 구현한다. 과장이 아니다. 실제로 수많은 팀에서 벌어지고 있는 현실이다.
How — 어떻게 만들 것인가 — 의 비용이 빠르게 0에 수렴하고 있다. 구현은 점점 쉬워지고, 같은 결과물을 내는 데 필요한 사람과 시간은 줄어든다. 기술의 진보다. 분명히 축하할 일이다.
그런데 한 가지 비용은 전혀 줄지 않았다. What — 무엇을 만들 것인가 — 를 결정하는 비용이다. 어떤 문제를 풀어야 하는지 파악하고, 아이디어를 구체화하고, 방향을 설정하는 데 걸리는 시간과 에너지는 여전히 그대로다. 오히려 선택지가 늘어나면서 의사결정의 무게는 더 커졌다.
How는 점점 싸지는데, What은 여전히 비싸다. 이 비대칭에서 역설이 시작된다.
개발자의 생산성이 높아지면 팀이 더 많은 것을 만들어야 정상이다. 하지만 현실은 그렇지 않다. 엔지니어들의 손이 빈다. 게으른 것이 아니다. 실행할 거리가 없는 것이다. What이 공급되는 속도보다 How가 소화하는 속도가 압도적으로 빨라졌기 때문이다. PM과 디자이너가 기획하고 검증하는 속도 자체가 병목이 되어버렸다.
이때 기업에게는 두 가지 선택지가 놓인다.
첫째, 병목 포지션을 충원한다. PM이나 디자이너를 더 뽑아서 What의 처리량을 늘린다.
둘째, 개발자를 줄인다. How의 처리량을 What의 공급 속도에 맞춘다.
논리적으로는 첫 번째가 맞다. 그러나 현실에서 두 번째가 압도적으로 쉽다. 적합한 PM이나 디자이너를 찾는 것은 정말 어려운 일이다. 비용의 문제가 아니라, 우리 제품과 시장을 깊이 이해하면서 동시에 문제 정의 능력을 갖춘 사람을 찾는 것 자체가 난제다. 반면 개발자를 줄이는 것은 숫자 계산만으로 결정할 수 있다.
그래서 많은 기업이 구조조정을 택한다. 실행력이 높아질수록, 실행하는 사람의 자리가 위태로워지는 역설. 빨라진 실행이 느려진 팀을 만들고, 느려진 팀이 더 적은 사람을 요구한다. 지난 몇 년간 테크 업계를 뒤흔든 대규모 구조조정의 이면에는 이 구조적 원인이 자리하고 있다.
How만 잘하는 사람은 대체 가능해진다. 이 문장이 불편할 수 있다. 하지만 외면해서는 안 되는 현실이다.
What에 참여하는 엔지니어
그렇다면 이 역설을 어떻게 깨뜨릴 수 있을까. 핵심은 What을 PM과 디자이너만의 영역으로 두지 않는 데 있다. 문제 파악, 아이디에이션, 방향 설정 — 이 과정에 엔지니어를 포함한 팀 전체가 참여해야 한다.
볼타에서는 세 가지 방식으로 이를 실천했다.
첫째, 고객 문의를 함께 본다. 고객이 어떤 문제로 문의를 넣는지, 어떤 기능을 예상과 다르게 사용하는지를 엔지니어가 직접 확인한다. 예컨대 단순 알림용으로 설계한 웹훅을 고객이 자체 자동화 파이프라인의 핵심 트리거로 활용하고 있다면 — 그것은 엔지니어가 가장 먼저, 가장 정확하게 포착할 수 있는 종류의 신호다. 코드를 만든 사람이 코드의 예상 밖 쓰임새를 가장 잘 읽는다.
둘째, 벤치마크 세션을 함께 한다. 경쟁사 분석, 시장 리서치를 PM만의 업무로 두지 않는다. 팀 전체가 주기적으로 시장을 함께 들여다본다. 엔지니어의 관점에서 보이는 기술적 가능성이 전혀 다른 아이디어를 촉발하기도 한다.
셋째, 프로토타이핑으로 아이디에이션에 기여한다. 피그마 목업을 기다리는 대신, 실제로 동작하는 프로토타입을 빠르게 만들어서 팀의 논의를 앞당긴다. How가 저렴해진 세상에서 프로토타입의 비용은 거의 0이다. 이미 구현 능력을 가진 사람이 아이디어 단계에서부터 손을 움직이면, 논의의 속도와 깊이가 완전히 달라진다.
이것은 엔지니어에게 위협이 아니라 기회다. 과거에는 구현에 모든 시간을 쏟느라 기획에 참여할 여유가 없었다. 지금은 실행 시간이 줄어든 만큼 What에 참여할 시간이 생겼다. 줄어든 시간을 어떻게 쓸 것인가가 개인의 가치를 결정한다.
1/3 법칙: What과 How를 교차하는 운영 구조
What에 참여하는 것만으로는 부족하다. 운영 구조 자체가 바뀌어야 한다.
가장 흔한 실수는 같은 문제에 대한 What과 How를 하나의 스프린트 안에서 동시에 진행하는 것이다. 이번 스프린트에 문제를 파악하면서, 동시에 그 해결책을 구현하려 한다. 이러면 반드시 블로킹이 생긴다. What이 늦어지면 How가 멈추고, How가 멈추면 엔지니어가 다시 손이 빈다. 앞에서 이야기한 역설이 스프린트 단위로 반복되는 것이다.
더 큰 문제는 리스크다. What 단계에서 방향이 틀어지면, 같은 스프린트에서 이미 진행 중이던 How 작업이 통째로 소실된다. 스프린트의 상당 부분을 한순간에 잃는 셈이다.
해법은 교차 운영이다. 이를 "1/3 법칙"이라 부른다.
스프린트의 1/3은 미래의 What에 투자한다. 아직 정의되지 않은 문제를 파악하고, 싱크하고, 아이디에이션한다. 나머지 2/3는 이미 정의된 What의 How를 실행한다. 지난 스프린트에서 충분히 검증해둔 것들을 만드는 데 집중한다.
흐름은 이렇다.
- S1: 문제 A 파악 + 아이디에이션
- S2: 문제 A 실행 + 문제 B 파악
- S3: 문제 B 실행 + 문제 C 파악
이 구조의 핵심은 손실의 격리에 있다. S1에서 문제 A의 방향이 잡히지 않더라도, S1에서 실행하고 있는 것은 이전 스프린트에서 이미 검증된 다른 문제의 How다. What이 실패해도 How의 리소스가 날아가지 않는다. 반대로 How가 예상보다 빨리 끝나면, 미리 진행 중이던 What 작업 덕분에 다음 실행으로 곧바로 넘어갈 수 있다.
교차 운영에는 약간의 리드 타임이 필요하다. 다음 달 초에 실행할 것의 What을 이번 달부터 시작해야 한다. 하지만 이 선행 투자가 팀 전체의 블로킹을 제거한다. 엔지니어가 손이 비는 순간이 사라지고, PM과 디자이너에게 집중되던 병목이 완화된다.
직관을 훈련하는 팀
What을 잘하려면 직관이 필요하다. 고객의 문의 한 줄을 읽었을 때 "같은 문제를 겪고 있을 다른 고객사가 어디인지" 바로 떠올릴 수 있는 수준. 별도의 리서치 없이도 "이건 진짜 문제일 수 있겠다"라는 판단이 서는 수준.
이것은 타고나는 능력이 아니다. 훈련으로 만들어진다.
볼타에서는 네 가지 방식으로 직관을 훈련한다.
외부 고객에 대한 이해. 우리 고객이 어떤 비즈니스를 하고, 어떻게 수익을 만들고, 어떤 고민을 안고 있는지를 아는 것이다. 경조사, 신규 사업, 채용, 구조조정까지. 고객의 맥락을 깊이 알수록 문의 한 줄에서 읽어내는 것의 깊이가 달라진다.
내부 고객 — 팀원 — 에 대한 이해. 같은 팀의 구성원이 어떤 강점을 가지고 있고, 어떤 영역에 도전하고 싶어하는지를 아는 것이다. 새로운 문제가 포착되었을 때 누구에게 맡길지, 어떻게 나눌지 판단하는 것도 직관이다. 사람에 대한 이해 없이는 문제를 정의해도 실행으로 연결되지 않는다.
시장에 대한 이해. 경쟁사, 법령, 글로벌 트렌드. 이 맥락이 없으면 어떤 문제가 풀 만한 가치가 있는 문제인지 판단할 수 없다. 경쟁사의 과거 시행착오도 귀중한 학습 자료다. 현재의 UX나 기능을 참고하는 것이 아니라, 그들이 왜 그 선택을 했고 어디에서 어려움을 겪었는지를 읽는 것이다.
예상치 못한 사용의 관찰. 우리가 A를 위해 만든 기능을 고객이 B에 쓰고 있다면, 거기에 의외의 기회가 숨어 있다. 이런 신호는 제품을 만든 사람이 가장 먼저 감지할 수 있다. 코드를 작성한 사람만이 설계 의도와 실제 사용 사이의 간극을 정확히 이해하기 때문이다.
데이터를 경시하자는 이야기가 아니다. 데이터 분석은 어느 정도 규모의 팀이라면 누구나 할 수 있다. 좋은 도구가 많아졌고 방법론도 표준화되었다. 하지만 실무에서 마주하는 대부분의 상황에는 참고할 만한 정량적 데이터가 없다. 새로운 시장에 진출할 때, 경쟁사가 예상 밖의 움직임을 보일 때, 과거 데이터는 별로 도움이 되지 않는다. 데이터 없는 상황에서 판단할 수 있는 것은 오직 훈련된 직관뿐이다. 직관으로 빠르게 가설을 세우고, 데이터로 검증하며, 그 경험이 다시 직관을 더 예리하게 만드는 선순환. 그것이 What을 잘하는 팀의 기반이다.
"신입 PM은 없다"는 표현이 있다. 직관이 쌓이는 데 시간이 걸리기 때문이다. PM이라는 직군이 아무나 할 수 없다는 뜻이 아니다. 고객과 시장과 제품에 대한 깊은 이해를 기반으로 한 직관은 하루아침에 생기지 않는다는 뜻이다. 그리고 이 말은 PM에게만 해당되지 않는다. What에 참여하려는 모든 사람 — 엔지니어든 디자이너든 — 에게 똑같이 적용된다.
직관이 충분히 훈련된 팀은 탑다운으로 사고한다. "이 기능을 만들면 나아지겠지?"라는 바텀업이 아니라, "목표를 달성하려면 어떤 문제를 풀어야 하는가?"에서 출발한다. 목표에서 역산하되, How가 아닌 What과 Why에 먼저 집중한다. 실행 방법은 그다음이다. 올바른 문제를 정의하는 것이 올바른 해결책을 구현하는 것보다 언제나 앞선다.
더 잘 정의하는 팀
How가 공짜가 되어가는 흐름은 되돌릴 수 없다. 실행 비용은 앞으로도 계속 줄어들 것이고, 같은 일을 하는 데 필요한 사람은 점점 적어질 것이다.
이때 살아남는 팀은 "더 빨리 만드는 팀"이 아니라 "더 잘 정의하는 팀"이다. 잘 정의하는 것은 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다. 그리고 그 역량은 개인의 직관 훈련과 팀의 운영 구조가 함께 뒷받침할 때 비로소 작동한다.
줄어든 실행 시간을 위협으로 볼 수도 있고, 기회로 볼 수도 있다. 그 시간을 What에 참여하는 데 쓴다면, 이것은 모든 구성원에게 더 넓은 영역에서 기여할 수 있는 기회가 된다. 1/3 법칙으로 구조를 잡고, 직관을 훈련하여 문제 정의의 깊이를 높이고, 팀 전체가 What에 참여하는 문화를 만든다. 그것이 빨라진 실행 시대에 작은 팀이 택할 수 있는 가장 현명한 전략이다.
일의 구조를 세웠다면, 그 안에서 뛰는 사람은 괜찮은 걸까. 빠르게 돌아가는 스프린트, 촘촘한 실행 주기, 끊임없는 문제 정의. 이 리듬 속에서 개인이 지치지 않으려면 무엇이 필요한가. 구조가 아무리 좋아도, 그 안의 사람이 무너지면 아무 소용이 없다.