How를 아는 사람이 Why를 말할 때
How를 아는 사람이 Why를 말할 때
PM이 Why-What을 담당하고 엔지니어가 How를 담당하는 분업 모델은 낡아가고 있다. AI 시대에 필요한 건, Why-What-How를 모두 오갈 수 있으면서 상황에 따라 의식적으로 레이어를 선택하는 사람이다. 나는 이런 사람을 제품 빌더라고 부른다.
이 생각은 PM들과 회의를 하면서 구체화됐다.
“사용자가 이탈하는 이유는 온보딩이 복잡해서예요.” 왜 이탈하는지, 무엇을 바꿔야 하는지에 대한 이야기는 풍성하다. 그런데 논의가 일정 수준 이상으로 깊어지지 않는다. 표면에서 맴돈다.
이유는 단순하다. How를 모르기 때문이다.
Why-What의 천장
PM의 전통적 역할은 Why와 What이다. 왜 만드는가, 무엇을 만드는가. 이건 여전히 중요하다. 하지만 How에 대한 감각이 없으면, Why와 What의 탐색 범위 자체가 좁아진다.
“실시간으로 사용자 행동을 분석해서 온보딩 플로우를 동적으로 바꿀 수 있다”는 가능성을 모르면, “온보딩 스텝을 3개에서 2개로 줄이자”가 논의의 끝이다. 기술적 가능성의 지도가 없으면, 제품의 상상력도 그 지도 안에 갇힌다.
리서치도 마찬가지다. 경쟁사의 기능 목록을 비교하는 건 할 수 있다. 하지만 “저 기능이 기술적으로 어떤 트레이드오프 위에 서 있는가”, “우리가 같은 걸 만든다면 어떤 제약이 생기는가”를 파악하려면 How에 대한 이해가 필요하다.
AI 시대가 바꾸는 것
AI가 구현을 가속화하면서, 역설적으로 How를 아는 것의 가치가 더 커졌다.
예전에는 How를 안다는 건 곧 “직접 만들 수 있다”는 뜻이었다. 지금은 다르다. How를 안다는 건 가능성의 공간을 넓게 볼 수 있다는 뜻이다. AI가 구현을 도와주니까, “이게 가능한가?”라는 질문의 답이 대부분 “가능하다”로 바뀌었다. 그러면 진짜 질문은 “가능한 것들 중에 뭘 할 것인가”가 된다.
이 질문에 답하려면 How의 지형을 읽을 수 있어야 한다.
제품 빌더라는 역할
나는 이런 사람을 “소프트웨어 엔지니어”보다 제품 빌더라고 부르고 싶다.
제품 빌더의 특징은 두 가지다:
첫째, How까지 보면서 리서치한다. 경쟁사 앱을 쓸 때 UX만 보는 게 아니라 네트워크 탭을 열어본다. 새로운 서비스를 만나면 “이걸 어떻게 만들었을까”를 생각한다. 일상의 모든 채널이 아이디어 소스다. 카페에서 주문 시스템을 보면서 상태 머신을 떠올리고, 게임을 하면서 온보딩 플로우를 분석한다. 기술과 제품의 경계를 넘나들며 흡수한다.
둘째, 제품을 논할 때는 의도적으로 How를 생략한다. 이게 핵심이다. How를 모르는 것과 How를 알면서 꺼내지 않는 것은 완전히 다르다. How를 아는 사람이 의식적으로 Why와 What에 집중하면, 논의의 깊이가 달라진다. “이건 기술적으로 어렵다”는 말 대신 “이 문제를 풀면 사용자에게 어떤 가치가 있는가”를 먼저 탐색할 수 있다. 가능성을 알기 때문에 두려움 없이 Why에 몰입할 수 있다.
How를 모르는 사람의 Why는 천장이 있다. How를 아는 사람의 Why는 천장을 뚫는다.
일상이 리서치가 되는 사람
이건 회의실에서만 일어나는 일이 아니다.
좋은 제품 빌더는 생활 자체가 리서치다. 배달 앱의 주문 추적 UX에서 실시간 시스템 설계를 읽고, 유튜브 추천 알고리즘의 변화에서 개인화 전략을 읽는다. 기술 블로그만 읽는 게 아니라, 비기술 분야의 문제 해결 방식에서 패턴을 발견한다.
이 감각은 Why-What-How를 모두 볼 수 있는 사람만이 가질 수 있다. 왜냐하면 “이게 왜 이렇게 동작하지?”라는 호기심은 How에 대한 기본적인 이해가 있어야 작동하기 때문이다.
엔지니어라는 이름을 넘어서
AI가 타이핑을 대신하면서, 엔지니어의 본질적 가치는 코드 작성에서 기술적 가능성의 공간을 탐색하고, 그 위에서 제품적 판단을 내리는 것으로 이동하고 있다.
분업의 벽이 낮아진 시대에, How를 아는 사람이 Why를 말할 때 — 그 Why는 다르다.