brunch

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 라프 Aug 27. 2023

사회초년생은 좌절할 시간이 없어요 EP5

'ETA와 작업 범위의 무한 줄다리기에서 현답을 찾느라'편

지난 편에서는 프로덕트의 차별화 포인트를 고민하고 기획에 녹여내는 이야기를 했었다.

그렇게 기획에서의 큰 틀이 잡힌 후 세부적인 기획을 하기 전 해당 프로덕트가 출시되었을 때를 상상하며 PR을 작성하였다. 그리고 내외부 이해관계자들이 물을 수 있는 질문을 미리 예상하고 해당 질문에 대한 답을 정리한 FAQ도 작성하였다. (PR&FAQ는 다음에 한 번 따로 자세하게 작성할 예정이다.) 이는 간단하게 설명하면 고객의 가치와 경험을 먼저 정의하고 이를 달성하기 위해 역으로 세부 기획을 짜는 것이다. 즉 고객을 가장 중요시하게 생각하는 아마존의 가치관을 담은 프로젝트 방법론이다.

내부 공유 용 프로덕트 PR&FAQ

이제 큰 그림이 그려졌으니 기획자들에게 공유를 하고, 작업 범위와 예상 작업 완료 날짜를 확정 지을 논의를 진행하였다.

해당 논의에는 PO, PM(나), 디자이너, 서버 개발자, 클라이언트 개발자 총 5명이 참석하게 되었다. 기획자로서 첫 프로덕트 개발을 진행했기 때문에 해당 논의가 매우 떨렸던 것으로 기억에 남는다.

우선 PR&FAQ를 공유하는 것에 대해서는 큰 무리가 없었다. 화면 기획서를 기반으로 디자이너분께서 1차 시안을 제작해 주신 상태였고 내가 상상하는 결과물을 전달하는 데에는 전혀 어려움이 없었다. 하나 꽤 이야기를 주고받았던 부분이 있었다면 무한으로 '좋아요'를 누르는 것에 대한 내용이었다. 그때 당시 다른 기능에서 '좋아요'를 누르면 화면 절반정도 엄지 애니메이션이 나오고 있었다. 물론 횟수는 1회로 제한이 있었다.

해당 프로덕트에는 게이미피케이션 요소를 위해 횟수 제한을 없애고 누를 때마다 애니메이션이 계속 노출되는 형태로 작업을 우선 요구했다. 클라 개발자분께서는 3가지 우려사항을 말씀해 주셨다.

첫 번째는 이전에 시도해보지 않은 것이라 작업 시간이 꽤 오래 걸릴 수 있다는 점

두 번째는 제한 없이 제공되었을 때 API가 과도하게 많이 호출될 수 있는 점

세 번째는 제한 없이 좋아요가 주어졌을 때 남용될 수 있는 가능성

첫 번째 점에 대해서는 우선 해당 작업 자체에 대한 우선순위를 조정하여 일정 상 작업이 불가능하다면 횟수에 대한 조절을 하는 것으로 합의를 했다.

두 번째 점에 대해서는 해당 문제가 서비스 사용에 치명적인 에러를 주지 않는 이상 좋아요를 무한으로 누르는 액션이 기록될 수 있도록 해결방법을 찾아달라 요청했다. 결론적으로는 마지막으로 눌린 횟수를 count 하여 마지막으로 좋아요를 누른 후 n초가 지났을 때 1회 API를 호출하여 숫자를 반영하는 것으로 좋은 방법을 찾아주셨던 것으로 기억한다.

세 번째 점에 대해서는 '좋아요'를 많이 누른다고 해서 일기의 순위가 바뀌는 것으로 인한 남용은 거의 없다고 말씀드렸다. 일기 순위에 따라 보상이 지급되는 것 또한 아니었으며 만약 자극적인 내용이 기재된 일기가 1위가 된다고 했을 때에는 이를 방지하기 위한 블라인드 기능이 있다는 점을 언급하였다. 다만 순위 자체로 전달할 수 있는 남들이 많이 공감하는 내용에 대한 가치를 폄훼할 수 있는 '내 일기 무한 좋아요'를 막기 위해서 본인의 일기에는 좋아요를 할 수 없도록 설정했다.

작업적인 내용을 논의한 후 이제 최종적으로 작업 범위에 따른 ETA를 설정하기로 했다.

해당 프로덕트 작업은 일기 작성, 일기 수정, 일기 삭제, 일기 확인, 담벼락으로 크게 5가지로 구성되었다.

학생들을 타깃 한 만큼 나는 2학기 개학에 맞춰 오픈 일정을 이야기했다. 일자로 산정하면 약 3주 정도였던 것 같다. 다만 개발자 2분의 의견이 크게 갈렸다.

한 분은 '가능하다' 한 분은 '매우 높은 확률로 불가능하다'였다. 불가능을 이야기하던 개발자께선 앞서서 말한 안 해본 작업으로 인해 확답을 주기 어렵다는 말을 해주셨고, QA나 심사제출등을 포함하면 1주의 시간이 더 필요하다고 말씀해 주셨다. 하지만 그 누구도 확답을 내릴 순 없었다. 그때 당시 스쿼드는 모두 주니어로 구성되어 있었기 때문에 이렇다 할 프로젝트 경험도, 개발 경험도 많지 않아서 그저 추정일 뿐이었다.

나는 패닉에 빠졌었다. ETA를 늘릴 것이냐, 작업 범위를 줄일 것이냐, 그냥 밀고 나갈 것이냐 이렇게 3가지의 옵션이 주어졌다. 하지만 그냥 밀고 나간다는 제외 시켰다. 첫 프로젝트였으며 우선은 이 프로젝트를 해당 팀원들과 잘 마무리하는 것 또한 내 이후 프로젝트들에도 굉장히 중요하게 작용할 것이라 생각했다. 경험도 타당한 이유도 없이 무작정 밀어붙였다가 만약 프로덕트가 잘못된다면 더 좋지 못한 결과를 얻을 것이라 생각했다.

그때 당시에는 나는 ETA가 더 중요하다고 판단을 했던 기억이 있다. 이유는 잘 모르겠다. 아마 개학 시점에 받을 수 있는 영향과 버프가 굉장히 중요했다고 생각했었을 것이다. 그렇게 나는 스콥을 줄여야 한다는 결론을 내렸고, 그렇다면 필수 기능이 아닌 차별화 포인트였던 일기를 공유하고 소통할 수 있는 영역을 빼는 것으로 혼자서 생각 정리를 했다. 그리고 이걸 말해야겠다 결심한 순간 옆에 앉아있던 PO께서 말을 꺼내셨다.

"그럼 우선 ETA를 1주 뒤로 정하죠. 왜냐하면 차별화 포인트가 없으면 다른 일기와 다를 게 없고 우리 프로덕트에서 가치를 느끼기 아주 힘들어요. 이 차별화 포인트가 없다면 마케팅도 소구점이 없기 때문에 원활하게 진행되지 않을 겁니다. 개발이 1주 미뤄지는 것보다는 차별화 포인트를 포함하는 것으로 결정합시다."라고.

그렇게 논의가 끝난 후 PO께서는 나에게 '작업자들께 계속해서 진행상황을 체크하고 최대한 푸시를 해보는 방향'으로 진행해 보자고 말씀해 주셨다.

이해관계가 충돌할 때 프로덕트를 최우선으로 생각하는 것을 처음으로 경험하고 보았던 순간이었다.

다행히도 결론적으로는 유능한 개발자분들이어서 기간보다 매우 빨리 (거의 처음 설정한 ETA 정도) 완성되어 무리 없이 출시되었다. 나 또한 프로젝트를 관리하며 개발자분들께 나만의 방식으로 개발자분들의 작업을 촉진시키는 경험을 해보기도 하였다.

그때에는 정말 큰 고민이고 그 결정이 일생일대의 중요한 것으로 생각되어 매우 혼란스러웠는데 지금 이 글을 쓰면서 느끼는 것은 그런 순간들이 쌓였기에 지금은 조금 더 침착하고 차분하게, 그리고 이성적으로 매 순간 좋은 결정을 할 수 있는 원천이라고 느껴진다.

내 첫 프로덕트 '일기'는 성공적으로 출시되어 초기 KPI를 성공적으로 달성했다. 그럼에도 아쉬운 부분은 남아있다. 해당 프로덕트의 정말 장기적인 그림을 그렸지만 그 후 개선 작업만을 진행하고 스쿼드를 변경해야 했고, 다른 기획자분이 한 번 더 일기 프로덕트에 추가 기능을 만들어주셨지만 그 이후에 팀 자체로 집중하는 사업이 바뀌며 일기는 그렇게 더 이상의 개발은 없었다.

개인적으로 기회가 된다면 한 번 더 일기 기능을 만들어 보고 싶다. 내 첫 프로덕트였던 만큼 아쉬움도 크고 펼치지 못한 아이디어도 무궁무진하다. 사이드 프로젝트를 해보아도 괜찮을지도?

기획자로서 처음으로 내 손으로 탄생시킨 프로덕트가 출시되기까지의 이야기가 끝이 났다. 사실 지금까지 가장 기억에 남는 프로덕트가 여전히 이 '일기'이다. 정말 해당 프로덕트를 만드는 동안은 '재미'를 느꼈고, 사용자들에게 출시되고 반응을 살피며 매일 아침 설레며 출근했던 기억이 있다. 기획자로서 좋은 날들이었다. 앞으로 이런 프로덕트 개발 경험이 있으면 좋겠지만 없더라도 이 기억을 가지고 몇 년간은 더 나아갈 수 있지 않을까?

사회초년생은 좌절할 시간이 없어요 일기 EP 끝

keyword