Become a product maker beyond a product manager (1)

Become a product maker beyond a product manager (1)

[서론]

IT 회사에서 PM으로 근무한지 3년, 이제는 내 스스로 내가 해결하고 싶은 문제를 해결하는 제품을 만들고 싶어졌다. 그렇게 2023년 9월 사이드 프로젝트 팀을 결성하게 되고, 지난 반년 간 TODA라는 다이어리 서비스를 출시하기 위해 노력해왔다. 하지만, 내가 해결하고 싶은 문제를 해결하는 제품을 만드는 팀이기에, 내가 설정한 목표에 대해 팀원들이 공감하는 깊이는 매우 얕거나, 매우 깊었다.

자동차가 만들어져, 정상적으로 전후좌우로 움직이기 위해 수만개의 부품이 결합되어야 하듯이, 하나의 제품을 만들기 위해선 각 직군에서 수많은 작업을 진행해야 한다. 이것은 어느 한 직군이라도 완료해야할 작업을 완료하지 않는한, 다른 직군이 얼마나 빠른 속도를 내어 얼마나 빠르게 작업을 마무리하던지 그것은 의미가 없다. 이것은 생산관리에서 누누이 강조하게 되는 제약조건으로, 하나의 제품이 만들어지는 기한을 줄이기 위해선, 작업별 능률의 최대치를 높여야 하는 것이 아니라, 작업별 능률의 최소치를 향상시켜야 한다.

다만 아쉬운 점은, 내가 팀원들에게 해줄 수 있는것은 무엇도 없다는 것이다. 정당한 대가를 지불하여 외주 계약을 한 것도 아니며, 그렇다고 정부지원 사업이나 VC로부터 투자금을 받아온 것도 아니었다. 또한 내가 의도한 바를 업무화하여 팀원들에게 정확하게 분담하는것 역시 매우 어려웠다. 이러한 상황속에서 나는 항상 내가 배워서 만들어볼까? 내가 모든것을 할 수 있다면 적어도 커뮤니케이션 비용과 노력으로 발생하는 제약조건 딜레이를 최소화 할 수 있을것이라는 생각이 들었다.

결과적으로 프론트앤드, 백앤드에 대한 지식을 쌓기 위해 정보처리기사, SQLD와 같은 기본적인 개발 지식을 배울 수 있는 자격증을 공부하였고, 직접 마크업 언어를 익혀 나의 포트폴리오 사이트를 제작해보기도 하였다. 주변에서는 기획자가 개발공부를 할 필요가 없다는 얘기를 종종하였지만, 지금에와서 생각해보면 업무적으로도, 내가 앞으로 진행할 사업적으로도 꽤나 만족할 만한 선택이었다는 생각이 든다. 어떠한 점에서 나에게 도움이 되는지 아래 상세 설명을 추가하도록 하겠다.

[개발 공부의 이점]

PM으로서 상황 파악 후 문제 대응하는 시간이 단축된다.

하나의 프로젝트에 앱과 웹과 서버개발자가 모두 관여되어있다고 해보자. 실제 운영되고 있는 서비스의 경우, 가장 중요한 것은 앱 배포 주기이며, 해당 주기에 맞추어 어떻게 일정을 관리할 것인가가 PM의 주요 업무이다. 이 경우, 현재 우리가 진행하는 프로젝트의 목표 달성을 위해 앱 배포가 필요한 작업, 웹 배포가 필요한 작업, 서버 배포가 필요한 작업이 있으며, 서로 어떻게 연관이 되어있느냐에 따라 배포의 순서가 달라지기도 한다. 예를 들면, 앱에서 서버로부터 받아와야 하는 정보가 바뀌는 경우 두 가지 케이스가 있는데, 하나의 케이스는 앱에서 이미 서버로 요청하고 있는 데이터를 받아오는 API가 수정되는 경우이며, 다른 케이스는 앱에서 서버로 요청하는 데이터를 받아오는 API를 새로 생성해야하는 경우이다. API를 수정하는 경우에는, 서버 작업만이 필요하고, 앱 개발자는 이미 해당 API를 연동해두었기 때문에 별도의 작업 및 배포가 필요가 없다. 결국 서버 배포만 필요하니, 앱 배포를 위한 심사 및 배포 주기가 필요 없는것이다. 반면에 새롭게 API를 생성하는 경우에는, 서버에서 작업하여 개발한 API를 앱에서 용도에 맞는 위치에 연동해주어야 하는데, 이러한 작업이 실제 상용 서버의 유저들에게 도달하기 위해서는 API를 연동한 앱 개발자의 코드가 상용 서버에 적용될 수 있도록 앱 심사 및 배포가 필요하다.

이 과정에서 의사결정은 복잡한 편인데, 기존 API 수정하여 활용하는 것이 앱 배포가 없어 일정관리에 수월한 방안이지만, 해당 방안을 활용할 경우 우리의 사용성 측면 혹은 사업성 측면에서의 목적 달성에 완전히 부합하는가, 제약은 없는가, 사이드 이펙트가 발생하지는 않는가 굉장히 많은 정보들을 파악하고 정리할 수 있어야 한다.

결론적으로, 개발자 및 디자이너와 직업 소통하고 일정 관리 측면에서 의사결정을 내리고, 회사의 대표나 이해관계자들에게 보고 및 컨펌을 받아내야하기 때문에 PM으로서 개발 및 디자인 지식을 알면 알수록 좋고, 해당 지식을 쌓기 위해 노력해야하는 것은 필수적이라는 생각이다.

2. 기획자로서 앱/웹을 설계할 때 정해주어야 할 정책의 범위를 파악할 수 있다.

IT 업계에서 처음 일을 시작할 때에 개발자 혹은 디자이너의 질문에 내가 이런거까지 결정을 해주어야 하는가? 에 대한 의문이 종종 들었던 적이 있다. 결론부터 말하면, 디자이너와 개발자가 기획자에게 질문하는것의 대다수는 기획자가 답변을 정확히 해주어야 한다. 왜냐하면 그들이 물어보는 질문이 사소한 것이든 중요한 것이든, 모두 우리의 서비스와 관련이 되어있으며,서비스에 대한 사용성&사업성 측면에서 가장 이해도가 높아야만 하는것은 기획자이기 때문에 그들에게 정해주어야할 정책에 대한 정확한 가이드라인을 제공해주어야 한다.

그들의 가장 사소한 질문은 무엇인가? 설계도에 나타나지 않은 동적인 측면의 정책과 화면 뒤에서 일어나고 있는 백앤드 측면의 질문들이 대다수이다. 동적인 질문은 이러한 것들이다 "화면이 전환될 때, 다음 페이지가 아래에서 위로 오나요, 오른쪽에서 왼쪽으로 오나요, 위쪽에서 아래쪽으로 오나요?". 당황스럽다. 사실 어떻게 해도 상관 없을 것 같은데? 왜 나한테 물어보는 것일까? 왜냐하면, 그들은 모든것을 구현해줄 수 있기 때문에 선택지 중 어떠한 선택지가 우리의 서비스에 최적화된 경험인지, 어떠한 선택지로 구현해야만 하는 것인지 확인하는 것이다. 아이러니하게 모든것을 해줄 수 있기때문에 선택지 중 어떠한 것을 선택해야 최적인지 결정이 필요하다.

백앤드 측면의 질문은 무엇일까? 일기를 작성할 수 있는 화면이 있다. 이곳에는 이미지, 키워드, 텍스트, 이모티콘 총 4가지의 인풋을 작성할 수 있다. 백앤드 개발자는 질문한다. 모든 정보는 비어있을 수 있습니까? (Null이 허용이 됩니까?). 백앤드 개발자가 물어보는 것은 어떠한 정보가 필수로 입력되어야 하는 정보이고, 어떠한 정보가 선택으로 작성될 수 있는 정보인가가 궁굼한 것이다. 만약 유저가 텍스트를 입력하지 않을 경우에는, 일기가 발행될 수 없도록 만드록 싶다면, 백앤드 개발자에게는 텍스트는 필수 값이며, 나머지는 선택적으로 입력 가능하다는 정보만 전달해주면 백앤드 개발자가 알아서 설계해줄 것이다 (단, 보다 정확하게, 입력값별로 이미지는 URL로 받아올 것이고, 텍스트는 1,000자 이하로 작성될 것이고, 이모티콘은 1개만 입력할 수 있으며, 사진은 최대 5장 까지 저장이 가능하다라는 가이드라인을 미리 전달해준다면 개발자와 커뮤니케이션하는 횟수와 시간이 단축될 수 있을 것이다). 디자이너와 개발자가 질문하는것에 대해 다시 한번 생각해보면, 그들은 무엇이든 만들어줄 수 있기에, 무엇을 만들지 정확한 가이드라인을 세울 수 있는 정책에 대한 질문을 하는 것이다. 그들의 질문에 정확히 답변하기 위해 디자인과 개발에 대한 지식이 필요한 것이다.

3. 내 서비스를 만드는데에, 병목을 줄인다.

위에 서술한 1,2번과 같이 개발자 디자이너와 협업을 하기 위해서는 상당한 시간을 커뮤니케이션에 쏟아야 한다. 커뮤니케이션이 완료된다고 끝인것도 아니다. 그 후엔 실제 작업하는 시간이 필요하다. 모두의 동기부여가 동일하다면, 최대한의 효율로 작업이 마무리되겠지만, 작업자 한 명이 인생에서 보다 중요한 우선순위가 발생하여 작업이 지체되거나 중간에 이탈하게 된다면, 나머지 모두가 작업을 완료하였음에도, 우리 제품은 나머지 한 명의 작업자가 작업을 완료할때까지 기다려야만 한다.

나는 종종 위와 같은 상황에 두려움을 느끼곤 하였는데, 작업이 느린것까지는 괜찮지만, 중간에 이탈하는 경우 그가 작업해두었던 작업물을 인수인계 받아 이어서 작업하기가 굉장히 어려웠다. (돈받고 일하는 회사가 아니기에, 책임질 이유가 없다) 그렇기 때문에 나는 어떠한 작업이든 0으로 돌아가는 순간에 극심한 스트레스를 느꼇으며, 결과적으로 내가 하나하나 차근히 배워서 내가 직접만드는 것은 적어도 0으로 돌아갈 일은 없기 때문에 내 손으로 모든것을 직접 해보자는 생각이 들게 되었다.

지금은 다행히 마음이 맞는 동업자가 생겨 내가 기획 - 디자인 - 프론트앤드 개발까지의 과정을, 동업자가 백앤드 설계의 모든것을 담당하는 역할로 역할을 조금 쪼갤 수 있었다. 앞으로 좋은 동료들을 영입하여 서로 맡고있는 작업에 대한 책임을 조금씩 덜고, 보다 생산성이 높은 팀이 될 수 있도록 노력하겠지만, 나는 그 과정에서 무엇이든 0으로 돌아가는 순간만큼은 막기 위해 내가 직접 내 제품을 디자인하고 개발하기로 마음 먹었다.

결과적으로 이러한 선택은 내가 제품 출시를 포기하지 않고, 꾸준히 이어나갈 수 있는 원동력이 되었으며 앱/웹 서비스가 만들어지는 전 과정을 보다 깊게 이해할 수 있는 초석이 되어가고 있다.

[앞으로 할 것]