테크니컬 프로덕트 매니저

제품을 쓰는 사람이 개발자인 경우가 늘면서 기존 방식이 맞지 않게 됐습니다. 프로그램끼리 주고받기로 약속한 창구를 API라고 하는데, 이것으로만 이루어진 제품에는 화면이 없습니다. 무엇을 만들지 적을 때 쓰던 화면과 버튼 이야기가 아예 성립하지 않습니다.

담당이 비어 있으면 규격은 만드는 쪽에서 정해집니다. 그러면 팀마다 다른 방식이 생깁니다. 한쪽은 오류를 숫자로 돌려주고 다른 쪽은 문장으로 돌려주며, 같은 회사의 제품인데 연동하는 개발자가 두 가지 방식을 배워야 합니다. 더 곤란한 것은 바뀔 때입니다. 연동해 둔 회사의 개발자가 응답 항목 하나가 사라진 이유를 물어도 답할 사람이 없고, 이미 그쪽 서비스는 멈춰 있습니다.

테크니컬 프로덕트 매니저는 그 자리를 채우려고 생긴 역할입니다. 제품 일을 누가 맡는지에 따라 갈리는 역할 갈래에서, 담당 영역이 기술 제품으로 좁혀진 변형입니다. 화면 대신 규격을 정하고, 사용자 대신 연동하는 개발자를 만나고, 기능을 늘리는 결정보다 이미 나간 약속을 깨지 않는 결정에 시간을 더 씁니다.

하루는 규격을 읽고 쓰는 일, 연동하는 쪽과 이야기하는 일, 바뀌는 것의 일정을 관리하는 일로 채워집니다.

1. 규격을 정하고 문서로 적습니다. 어떤 요청에 어떤 항목을 돌려줄지, 잘못된 요청에는 어떤 오류를 줄지를 문장 단위로 정합니다. 응답에 항목 하나를 더할지 말지가 하루의 주요 결정일 수 있습니다. 한 번 내보낸 항목은 쓰는 쪽이 생기면 없애기 어렵기 때문입니다.
2. 연동하는 개발자를 만납니다. 고객사의 개발자나 연동 파트너가 상대입니다. 이들은 무엇이 불편하다고 말하는 대신 우회해서 쓰는 방법을 만들어 두는 경우가 많아서, 어떻게 쓰고 있는지를 물어봐야 문제가 드러납니다.
3. 버전과 폐기 일정을 관리합니다. 규격이 바뀔 때 기존 사용자를 깨지 않게 판을 나누는 일이 API 버저닝이고, 곧 없앨 것을 미리 알려 사용을 말리는 상태가 디프리케이션입니다. 이번 분기에 무엇을 공지하고 언제 끊을지가 이 자리에서 정해집니다.
4. 사용 기록을 봅니다. 어느 요청이 하루에 몇 번 오는지, 특정 고객이 몰아서 부르고 있는지를 봅니다. 일정 시간에 받을 요청 수를 제한하는 요청 제한 정책의 숫자도 여기서 정합니다. 분당 60회를 100회로 올리는 판단에는 서버 비용과 고객의 실제 사용 패턴이 함께 들어갑니다.
5. 문서와 예제를 고칩니다. 개발자 제품에서는 문서가 판매 자료입니다. 연동에 걸리는 시간이 이틀에서 두 시간으로 줄면 그것이 전환에 직접 영향을 줍니다.

화면이 없으니 산출물이 문장과 규격입니다. 이번 분기에 만든 것을 보여 달라는 요청에 응답 항목 세 개와 오류 코드 체계를 내놓는 일이 흔합니다.

가장 가까이 있는 사람은 테크 리드입니다. 기술 방향과 구현 품질을 이끄는 역할인데, 경계는 대개 무엇과 어떻게로 갈립니다. 어떤 항목을 규격에 넣을지는 이쪽이 정하고, 그것을 어떤 구조로 구현할지는 그쪽이 정합니다. 이 경계가 흐려지면 규격이 구현 편의에 따라 정해지고, 쓰는 개발자에게 이상한 모양이 남습니다.

바깥쪽 상대는 연동하는 회사의 개발자와 그 계약을 맡는 세일즈입니다. 기업 고객은 계약 단계에서 기술 질문을 먼저 던집니다. 응답 속도를 어디까지 보장하는지, 고객과 계약으로 약속한 서비스 수준인 SLA에 무엇이 들어가는지가 그 자리에서 나오고, 답을 만드는 사람이 이쪽입니다.

화면이 있는 제품을 맡는 프로덕트 매니저와는 같은 기능을 양쪽에서 나눠 맡는 일이 많습니다. 화면에 새 기능이 붙으면 그 밑의 규격도 함께 바뀌기 때문입니다. 순서를 맞추지 않으면 화면은 나갔는데 외부에서는 같은 일을 할 방법이 없는 상태가 됩니다.

"이 항목 지우면 지금 깨지는 고객이 몇 곳이에요?"

이미 나간 약속을 바꿀 때 영향 범위를 먼저 세자는 요청입니다.

"v1은 여섯 달 뒤 종료로 공지하고 그동안 둘 다 유지합니다."

기존 사용자에게 옮길 시간을 주는 폐기 일정을 정한 것입니다.

"그 기능은 화면보다 규격을 먼저 내는 편이 맞습니다."

연동하는 쪽이 먼저 필요해 순서를 바꾸자는 제안입니다.

페이지덱이 문서 검색을 외부에서 부를 수 있게 열 때 이 역할의 판단이 드러났습니다. 태오는 검색 결과를 내부에서 쓰는 형태 그대로 내보내자고 했습니다. 만들기 쉽고 이미 돌아가는 형태였기 때문입니다.

담당자는 그 형태를 그대로 열지 않았습니다. 내부 형태에는 나중에 바뀔 항목이 섞여 있어서, 한 번 공개하면 그 항목이 바뀔 때마다 연동한 회사가 깨집니다. 대신 바뀌지 않을 항목만 골라 규격을 따로 짰고, 여섯 곳의 연동 파트너에게 미리 보여 준 뒤 확정했습니다. 수아는 그 규격 문서를 기업 계약 자료에 그대로 붙였습니다.

개발자 출신이어야 맡을 수 있다고 보는 경우가 가장 많습니다. 다루는 것이 기술이니 만들 줄 알아야 할 것처럼 보입니다. 하지만 이 자리가 하는 일은 코드를 쓰는 것이 아니라 규격을 읽고 결정을 설명하는 것입니다. 필요한 것은 응답 항목 하나를 없애면 무엇이 깨지는지 이해하고, 그 결정을 연동한 회사에 설명할 수 있는 정도입니다. 반대로 구현까지 직접 하려 들면 테크 리드의 자리와 겹쳐 결정이 두 곳에서 나오게 됩니다.

개발 일정을 관리하는 자리로 보는 것도 흔합니다. 이름에 기술이 들어가니 공정 관리처럼 읽힙니다. 그런데 이 역할이 지는 것은 일정이 아니라 규격의 값어치입니다. 제때 나왔지만 아무도 부르지 않는 창구를 만들었다면 그 책임은 이쪽에 남습니다. 일정만 보다가 규격을 개발 편의에 맞춰 내보내면, 두 분기 뒤에 같은 것을 다시 만들면서 그 사이에 연동한 회사를 모두 깨뜨려야 합니다.