이성관님의 아티클

PM이 원하는 개발자는 말야

한 번은 주니어 개발자에게 질문한 적이 있다. PM이 원하는 개발자는 어떤 개발자 일까? 여러가지 대답이 나왔지만 내가 생각하는 PM이 원하는 개발자는 기능을 시간내에 개발하는 개발자이다. 정확히는 지속적으로 일정을 맞추는 개발자이다. 사실 일정을 맞춘다는 것보다 “지속적” 이라는 말이 더 중요한데, 한 두번은 몰라도 지속적으로 일정을 맞추기 위해서는 내가 생각하기엔 두가지 능력이 필요하다.

첫번째는 구조화 능력이다. 기능이 계속 늘어나면 복잡해지기 마련이고, 같은 기능을 추가해도 시간이 더 걸리기 마련이다. 이런 상황에서도 지속적으로 일정을 맞추기 위해서는 코드에 구조라는게 필요하고, 이 구조를 잘 만드는게 시니어리티의 핵심이 된다고 생각한다.

두번째는 빠른 학습 능력인데, 이미 몇번 개발을 해본 기능이라면 대충 얼마나 걸릴지 알지만, 자기도 모르는 영역이라면 이 일정에 개발이 가능한지 알 수 없다. 이럴때 1-2일 정도 리서치를 위한 시간을 달라고 PM을 설득하고 빠르게 해결책을 찾아가야 되는데 이 때 빠른 학습능력이 필요하다.

지속적으로 일정을 맞추는 개발자를 나는 신뢰한다. 그 사람이 일주일 걸린다고 하면 일주일이 걸리고, 그 사람이 하루가 걸린다고 하면 하루가 걸린다고 생각한다. “저 사람이 다 못 끝내면 안되니깐 버퍼로 3일만 더 가져가자” 이런 생각 안하게 하는 사람을 신뢰한다.

PM이 리더십을 갖는 유일한 방법

조직마다 다르겠지만, 내가 PM으로 일했을 때는 Business roadmap을 유지하는 선에서 product roadmap을 PM이 가져갈 수 있는 구조였다. 무엇을 만들것인가에 대한 선택의 자유가 PM에게 어느정도 있었다.

제품이 만들어지는데 PM은 아교같은 역할을 한다. 디자인, 개발 두 큰 덩어리가 못채우는 빈 공간을 PM이 다채워넣는다. 그래서 잡다한 일이 많아 보이고, 이런일을 즐겁게 해내는 이유는 결국 내가 만들자고 한 제품을 만들고 있기 때문이다. 내가 기획한 기능이 실제 제품화 되고 사용자가 사용할 때의 그 벅차오르는 뽕이란, 안해본 사람은 모르겠지.

PM이 리더십을 가지는 유일한 방법은 자기가 기획 목적에 맞게 결과가 나올 때 이다. 사용자를 늘리기 위한 기획이었더면 사용자가 늘어나야 되고, 매출을 올리기 위한 기획이었다면 매출이 늘어나야 된다. 좀 더 자세히 내려가 사용시간, 사용자가 컨텐츠를 만들거나, 소비하거나 등등의 특정 행동 무엇이 되었던 원했던 결과가 나왔을 때 이다. 그래서 PM의 일은 기능이 릴리즈된 이후가 더 중요하다. 목적에 맞는 결과가 나오는지 확인해야 하고, 이미 기획단계에서 이 결과를 확인하기 위해 어떤 데이터가 필요한지가 명확해야 된다. PM에게 데이터분석 능력이 요구되는건 결국 결과를 확인하기 위해서다.

매번 결과가 안좋은 기획을 가져오는 PM이 팀원들에게 신뢰를 줄수가 있나. 작은 기능이라도 목적에 맞는 결과를 내고 이런 신뢰가 쌓여갈 때, 결국 PM이 리더십을 가지게 된다.

엑셀 업로드 기능 잘 못 개발하면 나중에 피본다.

서비스를 사용하는 사용자가 있으면, 서비스를 관리하는 관리자가 있다. 관리자가 사용하는 기능은 사용자가 원하는 기능보다 우선순위가 낮게 되는 경우가 많다. 그래도 매번 개발자를 통해서 진행되는 업무가 잦아지면 효율화를 위해 관리자 기능을 개발하게 된다.

엑셀 업로드는 대량으로 컨텐츠를 추가하거나, 사용자를 추가할때 자주 사용된다. 하지만 꽤나 무서운 기능이고, 제대로 QA를 하지 않으면 서비스 자체를 망쳐버린다.

PM이라면 프론트엔드 / 백엔드 / 데이터베이스 정도의 용어엔 익숙할 것이고, 데이터베이스의 데이터를 백엔드에서 적절히 가져와서 프론트엔드에 넘겨주는 API에 대해서도 익숙할거다. 원칙적으로는 프론트엔드는 백엔드가 주는 데이터를 믿어선 안되고, 백엔드도 프론트엔드가 넘겨주는 데이터를 믿어서는 안된다. 그렇기에 양쪽에 모두 검증하는 로직을 추가하고, 약속과 다른 데이터가 왔을때에 에러를 내며, 약속하지 않은 데이터가 데이터베이스에 들어가는 것은 무조건 막는다.

하지만 좋은게 좋은거라고 마치 편의점에서 담배를 살 때 모든 사람에게 신분증검사를 하지 않듯이, 편의상, 일정상 이런 검증로직은 빠질때가 많고, 그중에서 제일 빠지기 쉬운게 엑셀로 업로드된 대량의 데이터에 대한 검증이다. 프론트엔드는 백엔드를 믿고 엑셀파일을 보내고, 백엔드도 프론트엔드도 믿고 엑셀에 있는 내용을 그대로 데이터베이스에 올린다. 모두가 약속만 잘 지킨다면 아무일이 없겠지만, 악의가 없어도 실수가 생기고 작은 실수, 예를 들면 빈 셀이 하나 들어간다거나, 문장부호가 잘못되었다거나 하나씩 밀려쓴다거나 하는 크고 작은 실수가 분명히 생긴다.

이런 데이터가 데이터베이스에 들어가면, QA하기도 어렵고 버그를 인식해도 재현하기도 어렵다. 아마 특정한 데이터를 사용하는 사용자에게서만 발생하기에, 간헐적이고 개발팀에 리포트를 해도 재현이 안된다는 소리가 나온다.

엑셀 업로드 기능은 편리하긴 한데, 그만큼 검증로직도 빡세게 걸어야 되고 최소한 잘못된 데이터가 올라가지 않게 해야되며, 제대로 하려면 어떤 row가 문제가 되는지 정도도 알 수 있게 개발을 해야한다.

QA를 잘해야 서비스 퀄리티가 높아진다

QA에 목숨을 걸자. 이때는 지독하고 집요하게 파고 들어야 한다. 내가 버그를 최대한 많이 찾을 수록 사용자가 겪는 버그가 줄어든다고 생각하자. 술자리에 남은 술을 다 마신다는 생각으로 임하자.

위에서 공을 떨어뜨려 아래에 어떤 바구니에 담기느냐에 따라 경품을 주는 추첨판을 생각하자. 사용자가 어디로 가던지 떨어질 바구니가 있어야 된다. 빠지는 케이스가 있어선 안된다는 말이다. QA에서 PM이 주로 봐야할 것은 정상적인 사용경로가 아니라 분기점이 되는 부분이다.

작게는 콘텐츠를 읽거나, 크게는 결제를 하거나 이런 주요한 행동은 분기점이 된다. 사용자의 행동에 따라 보상을 주는 로직이 있거나, 레벨과 같이 유저별로 차등적인 요소가 있다면 그 요소가 바뀌는 점도 분기점이다. 10레벨이 되었을 때만 이용가능한 컨텐츠가 있다면, 10레벨을 되는 모든 경우의 수를 살펴봐야 한다.

B2B의 경우엔 사용자가 소속된 회사마다 기능이 상이한 경우가 정말 많다. 이것만 있으면 거래가 성사된다고 해서 추가했던 기능은 시작부터 수많은 분기점을 만들어 낸다. 결국 이 분기점을 다 체크하는 것이 서비스 퀄리티에 직결된다.

만약 외주를 통해서 개발을 진행한다면, 정말 사력을 다해야 된다. 검수에서 문제가 없으면 문제가 아닌게 된다. 하자보수기간을 갖더라도 이미 버그투성이인 서비스는 제대로된 런칭에 실패하게 된다. 기능리스트만으로 구현여부를 체크하지 말자. 분기점이 될 부분을 미리 다 파악해서, 해당 조건에서 문제가 없는지 확인해야 한다.

설익은 음식을 서빙하는 쉐프가 제대로 된 쉐프일리 없듯이 버그가 만연한 서비스를 출시하는 PM도 제대로된 PM이라 볼 수 없다. 이런 서비스에 대한 책임감이 PM의 리더십의 기본이 된다.

MVP만들면서 제일 기분좋은 순간은 아마도 domain구입?

fastsalesmail.com