플랫폼 프로덕트 매니저

로그인, 권한 확인, 알림 발송처럼 어느 팀에나 필요한 기능은 오랫동안 주인이 없었습니다. 제품 팀은 자기 화면을 만들다가 그 기능이 필요해지면 그 자리에서 직접 만들었습니다. 팀의 목표가 자기 화면을 내보내는 것이었으니 그게 빠른 길이었습니다.

페이지덱에서도 알림을 보내는 코드가 세 벌이 됐습니다. 문서 팀과 검색 팀과 모바일 팀이 각자 만들어 썼고, 문서 하나를 고치면 같은 알림이 세 번 갔습니다. 태오가 고치려고 열어 보니 손댈 곳이 세 군데였는데, 그 작업은 세 팀 어느 쪽 계획표에도 올라 있지 않았습니다. 누구의 일도 아닌 채로 반년이 지나갔습니다.

플랫폼 프로덕트 매니저는 이런 기반을 플랫폼, 곧 다른 것들이 그 위에 얹혀 돌아가는 바탕으로 보고 제품처럼 다루려고 둔 자리입니다. 쓰는 사람이 바깥 고객이 아니라 사내 동료라는 점만 다르고, 요구를 모으고 순서를 정하고 바뀐 내용을 알리는 일은 그대로입니다.

하루는 어젯밤 기반이 멈춘 데가 있었는지 확인하는 일로 시작해, 들어온 요청 가운데 무엇을 공통 기능으로 뺄지 정하는 일로 끝납니다. 만들 기능 목록이 아니라 다른 팀이 낸 요청 묶음이 출발점이라는 점이 프로덕트 매니저 일반과 갈리는 자리입니다.

반복되는 일은 다섯 단계로 돕니다.

1. 멈춘 기록을 봅니다. 로그인 처리가 5분 멈추면 그 위에 얹힌 열 개 팀의 화면이 같이 멈추기 때문에, 한 군데 장애가 회사 전체 장애로 번집니다.
2. 들어온 요청을 모아 같은 요구를 낸 팀이 몇 곳인지 셉니다. 세 팀이 같은 말을 하면 공통으로 뺄 근거가 되고, 한 팀만 필요하면 그 팀이 직접 만드는 쪽이 빠릅니다.
3. 말이 다른 요청을 한 덩어리로 묶습니다. 검색 팀의 "권한 확인이 느리다" 와 모바일 팀의 "권한을 한 번에 받고 싶다" 는 창구 하나로 함께 풀립니다.
4. 만들 것의 규격을 문서로 적습니다. 화면이 없는 제품이라 API, 곧 프로그램끼리 주고받기로 약속한 창구의 규격서가 화면을 대신합니다. 항목 이름 하나를 바꾸면 그걸 쓰는 팀이 전부 코드를 고쳐야 합니다.
5. 옮겨 타는 일정을 짭니다. 새 창구를 만드는 데 2주가 걸리면 기존 세 팀이 옛 코드를 버리고 넘어오는 데는 두 달이 걸립니다. 각 팀 계획표에 그 작업 자리를 얻어 내는 일까지가 몫입니다.

옛 경로를 끄는 것으로 한 건이 끝납니다. 호출이 0이 된 것을 확인하고 지웁니다. 여기서 멈추면 같은 일을 하는 창구가 둘로 남고, 이런 짝이 쌓인 상태가 기술 부채입니다.

상대가 곧 사용자라는 점이 이 자리의 특징입니다. 요구를 말하는 사람이 그것을 받아 쓰는 동료라서, 불만이 설문이 아니라 옆자리에서 바로 옵니다.

• 다른 제품 팀의 프로덕트 매니저 — 요청을 내는 쪽이면서 동시에 고객입니다. 분기 시작에 각 팀 계획표를 받아, 어느 기반이 언제까지 필요한지를 맞춰 둡니다.
• 기반을 만드는 개발자 — 규격을 함께 잡습니다. 볼 화면이 없으니 무엇이 완성인지도 함께 정해야 합니다.
• 인프라 담당 — 서비스를 돌리는 서버와 네트워크 기반을 맡는 쪽입니다. 얼마나 안 멈출지를 SLO, 곧 지키기로 정한 품질 목표치로 못 박아 두고 그 숫자를 같이 봅니다.
• 디자인 시스템 담당 — 버튼과 입력창처럼 화면을 이루는 공통 부품을 모아 둔 디자인 시스템도 안쪽을 향한 기반입니다. 화면 쪽 공통과 서버 쪽 공통이 어긋나지 않게 맞춥니다.
• 보안 담당 — 한 번 로그인으로 여러 서비스를 쓰게 하는 싱글 사인온처럼 편리함과 위험이 같이 늘어나는 기능은 열 범위를 함께 정합니다.
• 대표 — 사용자에게 보이지 않는 일에 개발자 여섯 명을 왜 쓰는지 설명하는 상대입니다. 규원에게는 알림 코드 세 벌이 한 벌로 줄어 다음 분기부터 그 작업이 3분의 1로 준다는 식으로, 아낀 양을 숫자로 말합니다.

"그건 플랫폼 로드맵에 올려 둘게요. 지금은 검색 팀만 쓰는 방식이라 공통으로 빼려면 두 팀이 더 필요합니다."

거절이 아니라 공통으로 만들 근거가 모자라다는 말입니다.

"이번 분기 제 일은 화면으로 안 보입니다. 대신 알림 코드가 세 군데에서 한 군데로 줄어요."

눈에 보이는 기능이 안 나온다는 사실을 미리 알리고, 대신 얻는 것을 숫자로 내놓는 말입니다.

"옛 권한 조회 경로 호출이 지난주에 0이 됐으니 다음 주에 지웁니다."

이관이 끝났다는 선언이면서, 그 경로에 매달린 코드가 있으면 지금 말하라는 예고입니다.

페이지덱에서 지현이 이 역할로 옮긴 첫 분기의 일은 권한 확인 창구를 하나로 모으는 것이었습니다. 같은 일을 하는 코드가 네 군데 있었고, 문서 한 건의 공유 범위를 세 화면에서 물으면 세 답이 나왔습니다. 지현은 만들기 전에 네 팀을 따로 만나 각자 무엇을 물어보는지부터 받아 적었습니다.

규격을 3주 만에 내놓고 나서 두 달을 이관에 썼습니다. 분기 끝에 남은 결과는 화면 하나가 아니라, 권한을 묻는 곳이 네 군데에서 한 군데로 줄고 같은 질문에 같은 답이 나오게 됐다는 기록이었습니다.

사내 도구를 맡으니 제품 감각은 덜 필요하다고 읽는 경우가 가장 많습니다. 사용자가 동료라 설득이 쉬워 보이는 탓입니다. 하지만 내부 사용자에게는 언제나 다른 선택지가 있습니다. 공통 창구가 자기 사정에 맞지 않으면 그냥 자기 팀에서 또 만들어 버립니다. 이 점을 놓치면 두 달을 들여 만든 창구를 아무도 쓰지 않고, 줄이려던 코드가 네 벌에서 다섯 벌로 늘어납니다.

들어온 요청을 다 받아 주는 자리라고 읽는 것도 흔합니다. 상대가 동료라 거절할 명분이 없어 보이기 때문입니다. 그런데 한 팀에만 필요한 요구를 공통에 넣으면 그 뒤로 모든 팀이 그 항목을 짊어지고 갑니다. 옵션이 스물쯤 붙은 창구는 새로 들어온 팀이 읽다가 포기하고, 결국 자기 코드를 다시 짜는 쪽으로 돌아갑니다.