제품 팀의 네 가지 리스크: 능력 목록이 아니라 자리 배치도

회사 소개나 채용 공고에서 이런 네 줄을 자주 봅니다.

제품 목표를 잘 세우는 능력
사용자가 진짜 무엇을 원하는지 이해하는 능력
우리가 만드는 경험과 가치를 명확히 정의하는 능력
견고한 소프트웨어 아키텍처를 설계하고 유지하는 능력

네 줄 다 맞는 말이고, 반박할 구석도 없습니다. 그런데 이 목록을 한 사람의 이력서 옆에 놓아 보면 이상해집니다. 넷을 모두 갖춘 사람을 뽑겠다는 뜻인지, 넷 중 하나만 잘하면 되는지, 아니면 회사 전체가 넷을 갖추겠다는 선언인지 읽어낼 수 없습니다. 목록이 잘못된 것이 아니라, 목록이라는 형식이 이 네 가지에 안 맞습니다.

능력 목록으로 읽으면 사라지는 정보

능력 목록은 한 주체가 시간을 들여 갖춰 나가는 것을 전제합니다. 자격증 목록이 그렇고 기술 스택 목록이 그렇습니다. 순서가 있고, 지금 몇 개를 갖췄는지 셀 수 있고, 없는 것은 나중에 채우면 됩니다.

위 네 줄은 그런 성질이 아닙니다. 넷은 동시에, 서로 다른 사람이 책임져야 성립합니다. 하나를 나중에 채우겠다는 말은 그 판단을 그때까지 아무도 하지 않겠다는 뜻이 됩니다. 목록 형식은 이 정보를 통째로 지웁니다. 누가 무엇의 주인인지가 안 적히기 때문입니다.

같은 네 가지를 주인과 함께 적어 놓은 정본이 이미 있습니다.

네 가지 리스크와 그 주인

Marty Cagan은 제품 팀이 무언가를 만들기 전에 매번 답해야 하는 질문을 네 가지 리스크로 정리하고, 각 리스크의 주인을 명시합니다. 가치 리스크는 고객이 이것을 살 것인가 사용자가 이것을 쓰기로 선택할 것인가이고, 사용성 리스크는 사용자가 쓰는 법을 알아낼 수 있는가이며, 실현 가능성 리스크는 우리 엔지니어가 지금 가진 시간과 기술로 만들 수 있는가입니다. 여기에 이 해법이 우리 사업의 여러 측면에서도 작동하는가를 묻는 사업성 리스크가 붙습니다.

위 목록의 능력	Cagan의 리스크	주인	책임지는 결과
제품 목표 수립	사업성 + 가치	프로덕트 매니저	사업 성과 (outcomes)
사용자가 원하는 것 파악	가치	프로덕트 매니저	사업 성과 (outcomes)
경험과 가치 정의	사용성	프로덕트 디자이너	제품 경험 (experience)
아키텍처 설계와 유지	실현 가능성	테크리드	납품 (delivery)

오른쪽 두 열이 목록에는 없던 정보입니다. 세 사람이고, 각자가 책임지는 결과의 종류가 다릅니다. 디자이너는 사업 성과로 평가받지 않고 테크리드는 사용자가 그것을 원하는지로 평가받지 않습니다. 그래서 이건 능력 목록이 아니라 자리 배치도입니다.

순서대로 넘길 때 생기는 릴레이

배치도를 알고도 자주 하는 실수가 있습니다. 넷을 공정 순서로 읽는 것입니다. 목표를 세우고, 사용자를 조사하고, 경험을 정의하고, 그것을 개발합니다. 산출물이 순서대로 넘어가니 관리하기도 좋습니다.

이렇게 하면 실현 가능성 판단이 마지막에 옵니다. 이미 승인된 화면 설계를 받아 든 개발자가 「이건 이 구조로는 어렵습니다」라고 말하는 시점이 그때입니다. 그 말은 늦어서 무시되거나, 받아들여지면 앞의 세 단계를 되돌립니다. 사용성 판단도 마찬가지입니다. 목표가 확정된 뒤에 「사용자가 원하는 건 이게 아닐 수 있습니다」라고 말하는 사람은 진행을 막는 사람이 됩니다.

넷이 동시에 있어야 한다는 말의 실질적인 뜻은 이것입니다. 각 판단이 다른 판단을 되돌릴 수 있는 시점에 나와야 합니다. 늦게 나온 옳은 판단은 옳지만 쓸모가 없습니다.

한 사람이 넷을 다 맡을 때 빠지는 순서

작은 팀에서는 세 자리를 세 사람으로 채울 수 없습니다. 흔한 일이고 잘못도 아닙니다. 다만 한 사람이 넷을 다 쥐면 빠지는 순서가 거의 정해져 있습니다.

가장 먼저 빠지는 것은 사용성 판단입니다. 안 해도 화면은 나오기 때문입니다. 그다음이 가치 판단인데, 이것도 안 해도 기능은 나옵니다. 실현 가능성은 마지막까지 남습니다. 안 하면 코드가 돌아가지 않아서 그날 바로 드러나기 때문입니다. 사업성은 돈을 내는 사람이 있으니 어떻게든 누군가 묻습니다.

즉 빠지는 것은 그 사람이 못하는 항목이 아니라 빠져도 당장 아무 일도 일어나지 않는 항목입니다. 저는 이것이 능력 문제로 오해되는 경우를 자주 본다고 생각합니다. 디자이너를 뽑으면 해결된다고 말하지만, 실제로 없었던 것은 사람이 아니라 그 판단을 요구하는 시점이었습니다.

회사 밖으로 나가는 첫 줄

외주 구조에서는 배치도가 한 번 더 틀어집니다. 제품 목표와 사업성 판단은 대금을 지급하고 검수에 서명하는 쪽에 있습니다. 계약이 그렇게 만든다는 이야기는 앞 글에서 다뤘습니다.

그래서 수행사가 「우리는 이 네 가지를 잘합니다」라고 말하면 첫 줄은 사실과 다른 주장이 됩니다. 잘하고 못하고의 문제가 아니라 그 자리에 앉을 수 없습니다. 정직한 문장은 「넷 중 셋을 맡고, 첫 줄은 발주사와 함께 정한다」에 가깝습니다.

네 번째 줄도 계약 때문에 반쯤 잘립니다. Cagan의 실현 가능성 리스크는 착수 시점의 판단인데, 위 목록의 네 번째 줄은 설계뿐 아니라 유지를 함께 말합니다. 외주는 검수와 함께 계약이 끝나므로 그 뒤 몇 년의 유지는 배치도에 자리가 없습니다. 유지보수 계약을 따로 맺지 않으면 이 자리는 납품 다음 날부터 비어 있습니다.

문제를 받는가, 기능 목록을 받는가

Cagan이 강한 제품 팀을 구분할 때 쓰는 질문은 두 문장입니다. 해결할 문제를 배정받는가 아니면 만들 기능 목록을 받는가. 그리고 기능을 출시하는 것(output)이 아니라 사업 결과(outcomes)에 대해 책임지는가.

이 기준으로 보면 외주 프로젝트는 구조적으로 기능 목록을 받는 쪽입니다. 계약서에 범위가 적혀 있고 그 범위대로 만드는 것이 의무이기 때문입니다. 저는 이걸 결함으로 부르는 것이 별로 쓸모없다고 봅니다. 계약 없이 일할 수는 없습니다.

쓸모 있는 것은 어디까지가 그 구조 때문이고 어디부터가 그냥 안 한 것인지 가르는 일입니다. 목표를 우리가 정할 수 없는 것은 구조 때문입니다. 사용자를 한 번도 만나지 않은 것은 구조 때문이 아닙니다. 화면 설계 전에 아키텍처 제약을 말하지 않은 것도 구조 때문이 아닙니다.

배치도로 읽으면 달라지는 것

같은 네 줄을 자리 배치도로 읽으면 물어볼 것이 생깁니다. 이 프로젝트에서 각 줄의 이름이 누구인지, 그 사람이 다른 줄의 결정을 되돌릴 수 있는 시점에 참여하는지, 계약 종료 후 네 번째 줄을 누가 이어받는지.

셋 다 답이 없으면 그 프로젝트는 네 가지 능력이 부족한 것이 아니라 세 자리 중 두 자리가 비어 있는 것입니다. 능력은 채용으로 채우지만 빈 자리는 문서와 계약으로 채웁니다. 고치는 방법이 서로 다르기 때문에, 어느 쪽인지 먼저 가르는 것이 실제로 이득입니다.

자리가 정해진 다음, 그 판단을 기르는 법

배치도를 그리고 나면 다음 질문이 남습니다. 그 자리에 앉은 사람은 그 판단을 어떻게 기르는가. 능력 목록으로 읽는 것이 왜 틀렸는지와 별개로, 자리마다 늘려야 할 판단력은 실재합니다. 다만 기르는 방법이 자리마다 다르고, 넷을 같은 방식으로 훈련하려다 셋을 놓칩니다.

제품 목표: 기능을 결과로 바꿔 적는 연습

왼쪽에 만들려는 기능을 적고, 오른쪽에 「이것이 성공하면 무엇이 어떻게 달라지는가」를 적습니다. 오른쪽 칸이 안 채워지면 그것은 목표가 아니라 요청입니다. 앞서 인용한 outcomes와 output의 구분이 훈련으로 바뀌는 지점이 여기입니다. 개념으로 알고 있는 것과 오른쪽 칸을 채워 본 것은 다릅니다.

한 가지를 더 붙이면 훨씬 빨리 늡니다. 목표를 적을 때 하지 않을 것을 함께 적는 것입니다. 무엇을 하겠다는 문장은 대개 흐릿한 채로도 써지지만, 무엇을 포기하겠다는 문장은 흐릿하면 써지지 않습니다.

사용자 이해: 의향이 아니라 과거 행동을 묻기

이 자리에서 가장 흔한 훈련 실패는 사용자에게 무엇을 원하는지 묻는 것입니다. 사람은 자기 미래 행동을 잘 예측하지 못하고, 특히 아직 없는 물건에 대해서는 예의로 답합니다. 「이런 기능이 있으면 쓰시겠어요」라는 질문은 거의 항상 긍정을 받아 오고, 그 긍정으로는 아무것도 판단할 수 없습니다.

대신 마지막으로 그 일을 실제로 했을 때 어떻게 했는지를 묻습니다. 그때 무엇이 막혔고 어떻게 우회했는지까지 따라갑니다. 우회 방법이 나오면 그것이 진짜 문제의 위치입니다. 질문지 한 줄을 바꾸는 일이라 오늘 당장 바뀌고, 이 자리의 판단력은 사실 접촉 빈도에 거의 비례합니다. 분기에 한 번 만나서는 늘지 않습니다.

경험 정의: 취향 논쟁을 테스트로 옮기기

경험 정의는 회의에서 취향 논쟁이 되기 쉽습니다. 근거가 없으면 목소리가 큰 쪽이 이기고, 그 방식으로는 아무도 배우지 못합니다.

두 단계로 막을 수 있습니다. 화면을 그리기 전에 문장으로 먼저 적습니다. 누가, 어떤 상황에서, 무엇을 하려고 하고, 지금은 그 일을 어떻게 하고 있는가. 그다음에도 의견이 갈리면 테스트로 넘깁니다. Jakob Nielsen은 사용자 다섯 명이면 대부분의 사용성 문제가 드러난다고 말합니다. 다섯 번째 사용자 이후로는 같은 발견을 반복해서 보게 된다는 것입니다. 저는 네 자리 중 이 자리가 가장 싸게 늘 수 있는 곳이라고 봅니다. 다섯 명은 하루면 되고, 다음 주에 또 할 수 있습니다.

아키텍처: 결정을 적어 두고 2년 뒤에 다시 여는 것

여기서는 설계 능력과 유지 능력을 갈라야 합니다. 설계는 남이 만든 시스템을 읽으면서도 늘지만, 유지 판단력은 자기가 내린 결정의 결과를 자기가 겪어야 늡니다. 그래서 훨씬 느리게 늘고, 대부분의 사람이 그 기회를 못 갖습니다.

그 기회를 인위적으로 만드는 방법이 결정을 적어 두는 것입니다. Architecture Decision Record는 Michael Nygard가 2011년에 제안한 형식으로, 결정 하나와 그때의 맥락, 검토한 대안, 예상한 결과를 짧게 남깁니다. 핵심은 문서 자체가 아니라 2년 뒤에 그 파일을 다시 여는 행위입니다. 적어 두지 않으면 2년 뒤에 남는 것은 「왜 이렇게 짰지」뿐이고, 거기서는 아무것도 배울 수 없습니다. 예상한 결과를 적어 두었을 때만 예상이 틀렸다는 사실을 알게 됩니다.

되돌릴 수 있는 결정과 되돌릴 수 없는 결정을 가르는 습관도 같이 붙습니다. 라이브러리 교체는 되돌릴 수 있고 데이터 모델과 URL 구조는 사실상 되돌릴 수 없습니다. 이 구분이 서면 어디에 시간을 더 쓸지가 자동으로 정해집니다.

네 가지에 공통된 조건 하나

넷을 다시 보면 훈련 방법은 다른데 조건은 같습니다. 판단력은 자기 판단의 결과를 자기가 다시 볼 때만 늡니다. 목표가 맞았는지는 출시 후 지표에서, 사용자 이해가 맞았는지는 사람들이 실제로 쓰는가에서, 경험 정의는 테스트에서, 아키텍처는 2년 뒤 그것을 고칠 때 드러납니다.

외주 구조가 어려운 진짜 이유가 여기라고 봅니다. 검수와 함께 계약이 끝나면 네 개의 피드백 루프가 한꺼번에 끊깁니다. 그래서 같은 유형의 프로젝트를 열 번 해도 열 번의 경험이 쌓이지 않고, 한 번의 경험이 열 번 반복됩니다. 유지보수 계약이 단순한 추가 매출이 아닌 이유이기도 합니다. 그것이 유일하게 루프를 다시 잇는 장치입니다.

여기서부터는 조직마다 다릅니다

Cagan의 모델은 자체 제품을 가진 회사를 전제합니다. 팀에 문제 해결 권한이 있고, 사용자에게 직접 접근할 수 있고, 실패를 학습으로 처리할 여지가 있다는 조건이 깔려 있습니다. 그 조건이 없는 조직에 이 모델을 그대로 얹으면 용어만 남고 실질은 안 바뀝니다. 그가 최근 몇 년 동안 조직 전환을 따로 다루는 이유도 여기 있다고 봅니다.

위에 적은 훈련 방법도 법칙이 아니라 관행입니다. 다섯 명 테스트는 널리 검증됐지만 대상이 전문가 집단이거나 사용 맥락이 여럿으로 갈리면 그 숫자로는 부족합니다. 세 자리를 몇 명으로 채우는 것이 맞는지도 조직마다 다릅니다. 두 사람이 네 판단을 나눠 갖고 잘 굴러가는 팀이 있고, 세 사람을 다 두고도 셋이 순서대로만 만나면 앞서 말한 릴레이가 됩니다. 인원수가 아니라 판단이 되돌릴 수 있는 시점에 나오느냐가 기준인데, 이건 밖에서 보고 판정하기 어렵습니다.

확실한 것은 하나입니다. 저 네 줄을 능력 목록으로 적어 두는 한, 빠진 자리는 능력 부족으로 보고되고 채용으로 해결하려다 다시 빕니다.