brunch

You can make anything
by writing

C.S.Lewis

by Dexter Park Apr 20. 2022

사이드 프로젝트로 앱 만들어서 수익 창출하기 - 5편

5. 개발자와의 커뮤니케이션

이 글은 다음과 같은 분들에게 추천합니다.

1. 사이드 프로젝트가 이뤄지는 전 과정을 알고 싶은 분
2. 한 서비스의 디자인 프로세스를 알고 싶은 분
3. 디자이너와 개발자와의 커뮤니케이션 방법을 알고 싶은 분
4. 실제로 앱 출시부터 홍보까지 수익 창출하는 방법을 알고 싶은 분

커뮤니케이션은 곧 서비스의 완성도이자 비용이다.

요즘 IT 업계에서는 사람을 뽑을 때 해당 업무의 전문성 다음으로 '커뮤니케이션 능력'을 가장 우선시하는 것 같습니다. 저도 7년 간 디자이너로 이쪽 업계에 몸을 담고 있지만 커뮤니케이션의 중요성을 몸소 깨닫고 있는 중입니다. 왜냐하면 커뮤니케이션이 곧 서비스의 완성도이자 비용이라 생각하기 때문입니다.

모든 서비스는 그 제품을 만들기 위한 긴 커뮤니케이션의 여정과도 같습니다. 기획자는 왜 이렇게 기획이 되어야 하는지 설명해야하고 또 디자이너는 왜 이렇게 디자인을 해야하는 지 또 개발자는 왜 이렇게 개발이 되야하는지를 설명해야합니다. 마치 어렸을 적 TV 예능 프로그램에서 사람들이 음악이 크게 나오는 헤드셋을 끼고 앞 사람에게 제시어를 말하면서 마지막 사람에게 온전히 전달되기만을 바라는 것과도 같습니다.

그 동안 제가 만나 본 개발자들만 수십명이 되지만, 커뮤니케이션을 잘하는 개발자의 특징은 사실 효율적인 의사소통에 있었습니다. 그러니까, 정말 간단한 예를 들어 '사과는 빨간색이 맞나요?'를 개발자에게 물어본다면 가장 효율적인 의사소통을 진행하는 개발자는 해당 질문에 대해 단순히 '맞는지' 아니면 '모르는지'만 대답합니다. 실제로 의사소통의 효율화는 업무적인 전문성과 상당히 밀접한 관계가 있습니다. 아는 것은 아는대로 모르는 것은 모르는대로 말할 수 있는 것이 결국 전문성이기 때문입니다.

하지만 실제로 위의 사진처럼 정말 간단한 질문임에도 개발자A는 답변을 바로 주지 않고 엉뚱한 이야기를 늘여놓아 괜한 시간을 소비하게 만들고 개발자B처럼 모든 질문에 무조건 자신의 책임을 회피하려는 태도를 보이기도 합니다. 이는 당연하지만 커뮤니케이션 능력이 현저히 낮은 경우에 해당하며 결국에는 서비스 제작 기간을 지체하게 만들어 비용을 증가시키는 원인이 됩니다.

따라서 '커뮤니케이션 능력'은 곧 '의사소통의 효율화'를 추구하는 과정이고 이는 '서비스 제작의 효율화'로 이어져 서비스의 완성도를 결정하는 가장 큰 요인이라 할 수 있습니다.

개발자와 커뮤니케이션하기

앞서 말씀드린 것처럼, 개발자와 좋은 커뮤니케이션을 한다는 것은 곧 서비스 제작에 불필요한 요소들을 제거하고 극한의 효율을 추구하는 과정이라고 볼 수 있습니다. 다시 말하자면 완성도 높은 서비스 제작을 위한 가장 쉽고 빠른 길을 찾는 것입니다.

그렇하기 위해서는 각 포지션에 대한 이해와 말하는 방식에 대한 차이를 아는 것도 중요합니다.

개발자들은 기본적으로 사고 자체가 논리적이고 효율을 추구하는 경향이 많습니다. 따라서 만약 어떤 기능을 넣고 싶어서 '네이버에 이런 기능 좋네요. 이 기능 넣어주세요.' 라고 말하면 개발자들 십중팔구는 '안되요.' 라고 대답하거나 난색을 표하는 표정을 지을 것입니다.

하지만 말하는 방식을 '이런 기능이 이런 이유로 꼭 필요한데 혹시 개발 공수가 최대한 적게 드는 방식에서 좋은 방법이 있을까요?'라고 물어본다면 어떨까요? 어떤 개발자든지 좋은 방법을 함께 찾아보기 위해 노력할 것입니다.

이번 자기 암시앱의 전체 디자인 페이지를 사내 개발자님과 함께 살펴보면서 당장은 필요하지 않는 기능이나 페이지들을 하나씩 소거해 나갔습니다. 녹음 페이지에서는 제목과 내용을 자유롭게 작성하는데 굳이 카테고리 레이블로 나눌 필요는 없기에 해당 사항을 제거하였고 PMF가 실질적으로 확인되지 않은 상태이기에 부가적인 백업 기능 또한 생략하기로 결정했습니다.

기능이 명확하고 단순한 사이드 프로젝트이기에 커뮤니케이션하는 과정은 그리 길지 않았습니다.

이제 해당 디자인 페이지들을 개발 가이드 프로그램인 Zeplin에 넘긴 후 주요 체크 사항만 메모하여 개발로 보내면 디자인 작업은 여기서 모두 끝이 납니다.

커뮤니케이션을 위해 디자이너가 할 수 있는 일

어떤 직종이든지 해당 포지션에 대한 서로의 이해가 있다면 커뮤니케이션은 원활할 것입니다. 예컨데 기획자가 디자이너가 작업하는 방식을 알면 '아 여기다 아이콘 표시를 해두고 제목과 본문을 따로 나누면 디자이너가 디자인하기 쉽겠네.' 라던가 혹은 디자이너가 개발자가 작업하는 방식을 알면 '개발하기 좋게 동일한 위치의 요소는 항상 우측 정렬해야지' 라는 생각을 할 수 있는 것입니다.

최근에는 프로덕트 디자이너들이 '디자인 시스템'을 만들어 개발의 효율을 높이고 토스(Toss)의 디자인팀은 Framer에 실제로 코드까지 구현해서 개발로 넘기는 등 디자인과 개발 사이의 갭이 점차 줄어들고 있습니다. 앞으로는 개발자에게 '1px만 옆으로 이동해주세요' 같은 불필요한 커뮤니케이션이 없어질지도 모르겠습니다.

다음 편에서는 '테스트 버전 제작 완료 후 디버깅' 편이 이어집니다.

keyword