프로덕트에 대한 내 사고를 만들어 준 책이 두 권 있다. 마티 케이건의 Inspired와 조카 토레스의 Gestão de Produtos다. 조카 본인에게 직접 멘토링을 받는 행운까지 누렸다. 몇 년 동안 이 두 권이 내 지도였다. PM이 무엇인지, 프로덕트 디자이너가 무엇인지, 엔지니어가 무엇인지, 누가 무엇을 하는지. 각 역할이 뚜렷한 윤곽을 가지고 있었다.
지난 1년, 프로로그에서 우리 팀이 AI로 일하는 걸 보면서 그 윤곽들이 미끄러지는 걸 느끼기 시작했다. 책이 틀린 게 아니다. 각 역할이 벌어지는 계층이 한 단계 올라간 것이다.
시리즈 첫 번째 글에서 나는 프로로그에서 테크를 다시 짓게 만든 그 불편함을 이야기했고, 두 번째 글에서는 harness가 무엇인지, AI가 실제로 성과를 내게 만드는 인프라를 다뤘다. 첫 번째 글 끝에서 나는 구체적인 한 부분을 열겠다고 약속했다. AI가 짓는 주체가 될 때 각 직무의 일이 어떻게 바뀌는가. 이번 글의 주제가 그것이다.
일은 사라지지 않는다, 한 계층 위로 올라간다
AI는 각 직무의 역할을 지우는 게 아니다. 그 역할이 벌어지는 계층을 바꾸고 있다.
쉬운 해석, 공포를 파는 해석은 “AI가 직무 X를 대체할 것이다”인데, 그건 내가 본 게 아니다. 내가 본 것은 일의 내용이 자리를 옮기는 것이었다. 예전에 하는 것이었던 게 하는 사람을 지휘하고 비평하는 것으로 바뀌었다.
코드를 짜던 엔지니어는 이제 에이전트가 쓴 걸 리뷰한다. 스펙을 쓰던 PM은 이제 그 스펙에서 몇 시간 만에 나온 프로토타입을 판단한다. 사람은 같고, 손에 든 도구가 바뀐 것이다.
이걸 머릿속에 두고 케이건과 조카로 다시 돌아갔을 때, 다른 방식으로 실감이 왔다. 두 사람 모두 각 역할의 실행을 조심스럽게 묘사한다. 구체적인 과업, 산출물, 하루가 끝날 때 내 손에서 나가는 것. 그리고 바로 그것이 AI가 넘겨받고 있는 부분이다. 사람에게 남는 것은 나머지 절반이다. 무엇을 지을 가치가 있는지 결정하고, 지어진 것에서 구멍을 찾아내고, 무엇이 좋은지 알아보는 취향을 갖는 것. 실행이 아니라 판단이다.
그래서 나 자신에게 했던 걸 그대로 하려 한다. 책에서 각 역할의 정의를 꺼내, AI가 그중 무엇을 먹어치우고 무엇이 남는지(그리고 더 비싸지는지) 묻는 것.
셋으로 된 팀, 책에 따르면
역할별로 나누기 전에, 책들이 팀을 어떻게 구성하는지 짚어 볼 만하다. 조카는 직설적이다. 성공하는 프로덕트는 바람직해야 하고, 실현 가능해야 하고, 만들 수 있어야 하며, 이것이 “성공하는 프로덕트를 만들기 위한 세 가지 핵심 기능”(2장)을 정의한다. UX 디자이너, 프로덕트 매니지먼트, 개발자. 그가 core team이라 부르는 트리오다. 케이건은 Inspired의 첫 장 “Key Roles and Responsibilities”에서 같은 역할들을 묘사한다.
두 사람 모두 마지막에 다시 다룰 한 가지를 강조한다. 이건 상사와 부하의 관계가 아니라는 것. 조카의 말로는 “프로덕트 엔지니어링, 프로덕트 매니지먼트, UX는 하나의 팀이고, 이 그룹들 사이에 종속 관계는 없다”(31장)이고, 케이건에서는 같은 생각이 PM과 엔지니어링이 “동료이며, 어느 쪽도 다른 쪽에 종속되지 않는다”(5장, 내 번역)로 나온다. 그리고 AI가 이 트리오의 한가운데로 들어올 때, 형태가 가장 많이 바뀌는 것이 바로 이 파트너십이다.
표: 테크의 각 직무가 한 계층 위로 올라간다. 엔지니어링은 코드 생산자에서 에이전트 비평가로, 프로덕트는 스펙 작성자에서 반복의 설계자로, 디자인은 화면 생산자에서 실험의 지휘자로, 품질은 테스터에서 검증의 구축자로.
테크에서 각 직무의 역할
같은 역할, 한 계층 위로
실행은 에이전트에게 · 판단은 당신에게 남는다: 결정하고, 비평하고, 취향을 갖는 것
엔지니어: 코드 생산자에서 에이전트 비평가로
엔지니어링에서 중요한 것은 이제 당신이 코드를 얼마나 생산하느냐가 아니다. 에이전트가 생산한 것을 당신이 얼마나 잘 비평하느냐가 됐다.
조카의 정의는 지금 다시 보면 아플 만큼 명확하다. “프로덕트 엔지니어링은 프로덕트를 개발하고 그것이 계속 돌아가게 유지하는 책임을 진다”, 그리고 조금 뒤에 엔지니어링은 프로덕트를 “짓는다”(31장). 짓는 것이 동사였다. 케이건은 프로덕트와의 관계를 이야기하며 반대편에서 이를 완성한다. “프로덕트 매니저는 솔루션을 정의하는 책임을 지지만, 무엇이 가능한지는 엔지니어링 팀이 가장 잘 알고, 결국 그 솔루션을 전달하는 것도 그들이다”(5장, 내 번역). 한쪽은 정의하고, 다른 쪽은 전달한다.
이제 첫 버전의 전달은 에이전트의 몫이다. 바뀌지 않았고 오히려 더 비싸진 것은, 케이건이 혁신의 원천으로 엔지니어에게 붙여 둔 모든 것이다. “엔지니어는 무엇이 가능한지 누구보다 잘 안다”(5장). 무엇이 가능한지 아는 것, 에이전트가 제안한 계획에서 구멍을 찾는 것, 그것이 못 보는 성능이나 보안의 트레이드오프를 보는 것, 언제 개입하고 언제 흘려보낼지 결정하는 것. 이건 매달 더 무거워진다. 문법을 외우는 것, 손으로 보일러플레이트를 치는 것, Stack Overflow를 뒤지는 것, 코드 양을 개인의 트로피로 삼는 것. 이건 더 가벼워진다.
프로로그에서 나는 팀에게 이걸 대놓고 말했다. 누구도 코드 줄 수로 평가받지 않을 것이다. 늘 “구멍 찾기”에 뛰어났던 사람은 더 가치 있어지고, “빠르게 많은 코드를 생산하는” 것에 자신을 동일시하던 사람은 어디에 투자할지 다시 조율해야 할 것이다. 그리고 이건 엔지니어링의 가치를 깎지 않는다. 엔지니어링의 가치는 늘 빠르게 생산하는 것보다 무엇이 제대로 된 것인지 아는 데 더 있었고, 이제 그게 겉으로 드러날 뿐이다.
PM: 스펙 작성자에서 반복의 설계자로
PM은 프로토타입이 싸질 때 이걸 느낀다. 그의 일은 문서를 쓰는 것에서 어느 아이디어가 팀의 시간을 쓸 가치가 있는지 고르는 것으로 바뀐다.
케이건은 일의 핵심에 대해 단호하다. “누군가는 솔루션, 즉 프로덕트가 무엇인지 알아내야 한다. 기능, 사용자 경험, 출시 기준까지 포함해서. 그 누군가가 프로덕트 매니저이고, 그 과업이 그의 일의 핵심이다”(1장, 내 번역). 조카는 넓은 윤곽을 준다. 프로덕트 매니지먼트는 “소프트웨어 프로덕트의 모든 측면을, 그 프로덕트의 생애 전체에 걸쳐, 착상부터 생의 끝까지 책임지는 기능”이다(2장).
두 사람 모두 핵심 단어가 명세가 아니라 발견이라는 점을 보라. 케이건은 이 일이 “요구사항”이 아니라 discovery라고 방어하는 데 한 장 전체를 쓴다. 소프트웨어에는 두 단계가 있다. “무엇을 지을지 알아내는 것(올바른 프로덕트)과 짓는 것(올바른 방식의 프로덕트). 첫 번째는 discovery가 지배하고, 두 번째는 실행이다”(12장, 내 번역). 이건 늘 그의 메시지였고, AI는 그걸 문자 그대로 만들었을 뿐이다.
빌드가 몇 주에서 몇 시간으로 무너지면, 병목은 짓는 것이 아니라 무엇을 지을 가치가 있는지 결정하는 것으로 옮겨 가기 때문이다. 위원회에서 검토하는 긴 스펙, 확정된 분기 플래닝, 산출물로서의 상태 보고서, 엔지니어링과 디자인 사이의 교통정리. 이 모든 게 더 가벼워진다. 더 무거워지는 것은 빠른 discovery(짓기 위해 스펙을 쓰는 게 아니라 이해하기 위해 프로토타이핑하는 것), 가설의 큐레이션(어느 아이디어가 팀의 시간을 쓸 가치가 있는지), 그리고 무엇을 하지 않을지를 더 자주 결정하는 것이다. 어떤 회사들은 이미 이런 PM을 “Editor”나 “Architect”라고 부른다. PM이 덜 된 게 아니다. 다른 PM이다. 큐레이션하는 사람, 취향으로 결정하는 사람, 방향을 주는 사람. 옛날 방식에서 중심이었던 것, 스펙을 쓰는 일이 가벼워진 것이다.
프로덕트 디자이너: 화면 생산자에서 실험의 지휘자로
디자인에서는 일의 단위가 화면에서 벗어나 화면을 생산하는 시스템으로 옮겨 가고, 프로덕트 디자이너는 어느 변형이 살아남는지 고르는 사람이 된다.
조카에게 UX의 정의는 그리기 위해 이해하는 것이다. “UX는 사용자와, 그 사용자를 위해 풀고자 하는 문제를 깊이 이해하는 책임을 진다”(32장). 그가 묘사하는 흐름은 모두가 아는 의식이다. 종이 프로토타입, 그다음 와이어프레임, 그다음 “UX 비주얼 디자이너가 그 화면들에 색과 형태를 입히기 시작한다”. 케이건은 같은 논리로 역할을 둘로 쪼갠다. interaction designer는 “사용자에 대한 깊은 이해를 발전시키고 과업, 내비게이션, 흐름을 만들어” 이를 와이어프레임으로 옮겨 visual designer에게 넘기고, 그는 “와이어프레임에 살을 붙인다”(4장, 내 번역).
이 연쇄, 이해하고, 스케치하고, 화면 하나하나를 다듬는 것이 바로 AI가 줄이는 부분이다. 일의 단위는 “화면”에서 “화면을 생성하는 시스템”으로 바뀐다. 같은 변형을 Figma에서 다섯 번 다시 만드는 것, 컴포넌트를 하나하나 명세하는 것, 의식으로서의 픽셀 퍼펙트 핸드오프. 이건 더 가벼워진다. 반복 속도로 프로토타이핑하는 것(여러 옵션을 병렬로 만들고 나쁜 건 버리는 것), 화면 하나하나가 아니라 비주얼 시스템을 정의하는 것, 그리고 빠른 비주얼 비평(AI가 뭔가를 제안하는 걸 보고 사용자가 눈치채기 전에 그게 틀렸다는 걸 알아채는 것). 이건 더 무거워진다.
그리고 여기서 케이건은 저 멀리 2008년에, 프로덕트 디자이너가 자신이 버튼 누르는 사람이 됐다고 여기지 않도록 지켜 주는 말을 한다. 그의 일은 결코 예쁘게 그리는 것만이 아니었다. “좋은 프로덕트는 좋은 사용자 경험을 요구한다. 그리고 좋은 경험은 프로덕트와 디자인의 긴밀한 협업을 요구한다”(4장, 내 번역). AI가 변형을 생성하고, 그중 어느 것이 사용자에게 도달할 자격이 있는지 결정하는 것은 여전히 취향을 가진 사람이다.
QA: 테스터에서 검증의 구축자로
QA는 가장 흥미로운 경우다. 책들이 거의 따로 떼어 두지 않은 역할이면서, AI가 가장 많이 흔드는 역할이기 때문이다.
보라. 조카의 트리오(디자이너, PM, 개발자)와 케이건의 역할들에서 품질은 팀의 책임으로 희석되어 나타날 뿐, 고유한 방법을 가진 고유한 자리로는 나타나지 않는다. 오랫동안 이건 말이 됐지만, 이제는 아니다. 이유는 간단하다. 에이전트가 빠르게 짓는데 검증이 여전히 수작업이면, 당신은 그저 고속으로 기술 부채를 생산한 것뿐이다.
그래서 QA는 테스트 케이스를 손으로 돌리는 사람에서 testing harness, 곧 시스템을 테스트하는 시스템을 설계하는 사람이 된다. 다른 AI가 쓴 코드에 테스트를 쓰도록 AI를 세팅하고, 사용자가 겪기 전에 회귀(regression)를 잡아내고, 결함이 어디서 나타나는 경향이 있는지 생각하는 것. 실제로 이건 우리가 채택한 운영상의 질문이 됐다. 빠져나간 버그 하나하나가 “다음번엔 이걸 어떻게 자동으로 잡아내지?“로 바뀐다. 알려진 흐름에 대한 소진적 수작업 테스트, 릴리스마다 손으로 돌리는 회귀, 배포 전 유일한 관문으로서의 QA. 이건 더 가벼워진다. 검증은 컨베이어 끝의 패스가 아니라 시스템이 된다.
가장 계층이 많이 올라가는 역할인데, 그건 바로 가장 덜 정의되어 있었기 때문이다. 책이 윤곽을 새기지 않은 곳에, AI가 새로운 윤곽을 그리고 있다.
상수: 책들이 이미 가장 중요하다고 말한 것
바뀌지 않는 게 하나 있고, 그건 두 책 안에 훤히 드러난 채 숨어 있었다. 그들이 가장 중요하다고 이름 붙이는 것이 정확히 AI가 하지 못하는 것이다.
조카는 좋은 PM의 특성을 다루는 장을 돌려 말하지 않고 연다. “그 모든 것 중 가장 중요한 것은, 의심할 여지 없이, 공감이다”(4장). 기능표도 산출물도 아니다. 쓰는 사람의 자리에 자신을 놓을 줄 아는 능력이다. 케이건은 그 나름대로 책 전체를 discovery, 취향, 판단력을 프로세스보다 위에 두는 데 쓰고, 두 사람은 각자의 방식으로 같은 말을 하고 있었다. 좋은 것과 평범한 것을 가르는 것은 결코 일의 기계적인 부분이 아니었다.
그리고 그 기계적인 부분이 바로 에이전트에게 간 것이다. 스펙을 쓰고, 화면을 그리고, 코드를 짜고, 테스트를 돌리는 것. 남은 것, 그리고 더 비싸진 것은 비판적 사고, 취향(무엇이 좋은지 아는 것), 모호함 속의 판단력, 호기심, 당신이 만든 걸 쓰는 사람에 대한 배려다. 팀에게 쓴 문장으로 요약하면, 일의 내용은 바뀌지만, 그 일을 하는 사람은 바뀌지 않는다.
두 계층 다이어그램. 위쪽은 우리에게 남아 더 비싸진 것: taste(무엇이 좋은지 아는 것), 모호함 속의 판단, 쓰는 사람에 대한 공감, 무엇을 하지 않을지 결정하기, 책들이 이미 가장 중요하다고 말한 것. 일이 한 계층 올라갔다. 아래쪽은 에이전트에게 간 것: 스펙 쓰기, 화면 그리기, 코드 짜기, 수동 테스트 돌리기.
우리에게 남았다 · 그리고 더 비싸졌다
책들이 이미 가장 중요하다고 말한 것
일이 한 계층 올라갔다
에이전트에게 갔다
이게 치르게 할 대가 (클리셰 없이)
이걸 너무 예쁘게 마무리하고 싶지 않다. 예쁘지 않기 때문이다. 이 변화는 구체적인 것을 대가로 요구하고, 그중 편한 건 하나도 없다.
첫째는 10년짜리 습관을 뒤에 두는 것이다. 옛 방식으로 5년, 10년을 해 온 사람은 여기까지 오게 해 준 패턴들을 짊어지고 있고, 바로 그 패턴들이 바뀌는 걸 무겁게 만든다. 지름길은 없고, 그 불편함은 예상된 것이다.
다음은 AI로 만드는 만큼 AI를 비평하는 것이다. 떠오른 제안을 받아들이는 건 일이 아니다. 그것이 제안한 계획에서 구멍을 찾는 것이 일이다. 늘 비쌌던 것(비판적 사고, 취향, 판단력)이 더 비싸진다.
팀으로 실수하는 것이지 개인으로 실수하는 게 아니라는 점도 있다. 우리는 프로덕션 버그로 엔지니어를 해고하지 않는다. 리뷰를 개선한다. 그리고 AI가 틀리면 우리가 강화하는 건 harness다. 에이전트의 버그는 프로세스이지 사람이 아니다. 슬로건이 아니라 약속이다.
그리고 가장 불편한 것. 어떤 직무는 다른 직무보다 더 많이 바뀐다는 걸 받아들이는 것이다. 지금까지 별로 바뀌지 않은 사람에게 이건 불편함을 낳고, 다 똑같은 척할 수는 없다. 할 수 있는 건 그걸 열린 대화로 가져오는 것이다.
그리고 도착한 사람처럼 들리지 않도록 말하면, 프로로그는 아직 이 일의 초기에 있다. 우리는 여전히 AI-assisted로 10~20%의 이득을 얻고 있지, 5배나 10배의 AI-first가 아니다. 나는 우리가 만들어 가고 있는 방향을, 맞힘과 틀림을 섞어 이야기하는 것이지, 승리를 이야기하는 게 아니다.
여기서 내가 가져가는 것
책들은 틀린 게 되지 않았다. 그것들은 각 역할의 실행을, 이제야 진짜로 이해하게 된 정밀함으로 묘사했다(스펙을 쓰고, 화면을 그리고, 프로덕트를 짓고, 테스트를 돌리는 것). 그리고 그 실행은 이제 에이전트의 몫이다. 사람에게 남은 것은 나머지 부분이다. 판단하고, 비평하고, 취향을 가지고, 쓰는 사람을 배려하는 것. 그리고 이건, 케이건과 조카로 돌아가 보면, 그들이 첫 페이지부터 가장 중요하다고 말한 것이다.
어쩌면 그게 좋은 부분이다. AI가 우리 손에서 가져간 일은 가장 반복적인 것이었고, 남겨 둔 일은 늘 가장 어렵고, 가장 흥미로웠던 것이다. 어떻게 되어 가는지 계속 이야기하겠다.
출처
- Marty Cagan, Inspired: How to Create Products Customers Love (1판, 2008). 역할 정의는 1장(Key Roles and Responsibilities), 4장(Product Management vs. Design), 5장(Product Management vs. Engineering), 12장(Product Discovery)에서 왔다. 발췌 번역은 내 것이다.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). 정의는 2장(소프트웨어 프로덕트 매니지먼트란 무엇인가?), 4장(프로덕트 매니저의 핵심 특성), 31장(프로덕트 엔지니어링과 프로덕트 매니지먼트), 32장(UX와 프로덕트 매니지먼트)에서 왔다.
- 역할이 한 계층 올라간다는 이 읽기는 시리즈를 뒷받침한다: OpenAI, Harness Engineering, 그리고 Peter Pang, CREAO의 CTO.