제품을 대하는 개발자의 자세

7 min readJul 2, 2020

개발자에게 프로덕트 관점은 왜 중요할까요

버즈빌 테크 블로그 — 제품을 대하는 개발자의 자세에 기고한 내용입니다.

최근 인터뷰에서 개발자로서 성장하기 위해서 어떻게 하면 좋겠느냐는 질문을 받았습니다. 프로그래밍 언어를 더 깊게 파는 것이 좋을까요? 알고리즘을 잘 풀어야 할까요? CS 지식? 클라우드 환경 운영? 머신러닝 엔지니어링? 무엇 하나 명확한 답이 되기에는 어려움이 있습니다. ‘개발자’라는 한 단어로 분류하기에 개발 분야는 너무 넓고 많으니까요.

이 질문은 서비스를 만들고 운영하는 입장에서 개발자가 무엇을 통해 성장해야 하는지에 대한 고민으로 이어졌습니다. 여전히 하나의 궁극적인 답은 없겠지만, 제품에 대한 고민이 개발자의 성장에 어떤 의미를 가지는지에 대해 생각을 정리해보려고 합니다.

PM/PO의 덕목

PM/PO가 되어서는 안되는 사람

얼마전 “PM/PO가 되어서는 안되는 사람”이라는 글이 커뮤니티에서 활발하게 돌아다녔습니다. PM/PO로서 필요한 시각과 능력을 정의하기 위해 반례를 나열한 글인데요, 제목만 참고하면 아래와 같습니다.

이 일을 왜 하는가를 이해하지 못하는 사람
납기와 최소 스펙 개념이 없는 사람
전체 판을 보지 못하는 사람
우선 순위를 설정하지 못하는 사람
수면 위에 드러난 것만 보는 사람
질문을 하지 못하는 사람
문제를 인식하지 못하는 사람
압박을 견디지 못하는 사람
끝을 보지 않는 사람
실패했다는 것을 알지 못하는 사람

이를 요약해보면 “해야 하는 일을 목적과 이유를 전체적인 관점에서 파악하되 커뮤니케이션을 통해 우선 순위를 정하고, 이를 바탕으로 단계별 상세 스펙과 스케쥴을 산정한 뒤 끝을 볼 때까지 최선을 다하는 사람” 입니다. 이 항목들이 PM/PO에게만 필요한 덕목일까요?

개발자의 덕목

“Software Engineering Economics”의 저자 Barry Boehm은 개발자를 평가할 때 다음 항목이 순서대로 높은 중요도를 가진다고 합니다.

문제를 분석하고 어떻게 해결할지 결정할 능력
날 것(Raw)의 개발 능력
문제를 분석하고 해결한 경험
OS 혹은 어플리케이션 도메인을 포함한 소프트웨어 구동 환경에 대한 경험과 지식
특정 언어의 경험과 지식

순서에서 알 수 있듯이 언어에 대한 경험과 지식은 가장 덜 중요한 항목입니다. 훌륭한 개발자라면 새로운 언어는 금세 배울 수 있지만 어플리케이션 도메인에 대한 능력과 경험은 그렇지 않기 때문이라고 합니다. 반면에 특정 도메인에서 문제를 분석하고 해결해 온 경험을 바탕으로 문제를 정의/분석하고 해결해 나갈 수 있는 능력이 중요하다고 이해할 수 있습니다.

(제가 좋아하는 문구를 인용해 보자면) 역사적으로 장인 정신은 경제학의 논리를 이긴 적이 없다고 합니다. 그런 의미에서 경제학의 관점으로 개발자가 프로덕트 이해도를 높이는 것이 왜 중요한지 나열해 보죠.

프로덕트 이해도가 높을 수록 문제 분석 및 해결 능력이 증가한다.
해당 능력이 좋아질 수록 평가가 좋아진다.
평가가 좋아지면 몸 값(?)이 높아진다.

참 쉽죠?

프로덕트의 이해도

그래서 무엇을 어떻게 하라는 것 일까요? 우리는 이미 개발하고 있는 프로덕트를 잘 이해하고 있는 것 같은데 말이죠. 앞서 나온 PM/PO의 덕목 중에 ‘질문을 잘 하는 사람’을 참고해서 질문을 한번 던져 볼까요?

프로덕트 관점

이 제품/기능의 목적은 무엇인가?
얼마나 많은 사람들이 얼마나 자주 사용하게 되는가?
문제가 발생했을 때 어떤 일이 생기는가?

사용자 관점

누가 언제 왜 사용하게 되는가?
해당 기능의 이전 행동과 이후 행동은 무엇인가?
사용 도중 예외 사항은 없는가? 있다면 어떻게 동작해야 하는가?

비지니스 관점

이 제품은 우리의 비지니스에서 어떤 의미를 가지는가?
사용자/매출/수익 관점에서 어떤 영향을 어떻게 미치는가?
기능의 성공 혹은 실패 시 어떤 리스크가 있는가?

어떤가요? 위 질문에 쉽게 대답할 수 있나요? 어쩌면 많은 좋은 개발자 분들의 경우 이미 이런 질문이 체득 되어서 보는 즉시 대답을 하실 수도 있을 것입니다. 한편 ‘대답을 할 수 있다’와 ‘대답을 해봤다’ 사이의 간극도 고려해야 합니다. 즉흥적으로 답을 내릴 수 있는 능력의 중요함 뿐만 아니라, 개발 전에 스스로 질문하고 대답해 보았는가 역시 중요하다는 의미 입니다.

위 질문을 듣고 다음과 같은 의문이 생길 수도 있습니다:

Q. 이미 위에서 고려되어 내려온 것인데 왜 개발자가 또 생각해야 하나요?

A. 문제를 분석하는 시각이 달라질 수 있습니다. 주어진 요구 사항 또한 잘 구성된 것인지 스스로 검증해야 합니다. 다시 한 번 언급하자면, 문제를 잘 분석하고 해결책을 만들 수 있어야 여러분의 몸 값이 올라갑니다(?). 그리고 일단 위라는 개념을 버리세요.

Q. 사용자 관점에서의 고민은 PM의 역할 아닌가요?

A. 개발자는 제품의 첫 번째 사용자입니다. 사용자의 관점에서 제품을 바라보면 미처 생각하지 못한 부분들이 발견되기 마련입니다. 로그인 화면 구현 요청이 왔는데 비밀번호 가리기 요구 사항이 전달되지 않았다고 비밀번호를 노출하는 일을 하지 마세요.

Q. 사용자를 위해 기능을 개발하는데 매출을 왜 생각하나요! (버럭)

A. 모든 것은 연결되어 있습니다. 회사에게 돈은 공기와 같고, 비지니스 목적에서 수익 추구는 빠질 수 없습니다. 비영리 단체도 운영 유지를 위해선 수익이 필요하죠. 돈, 수익 만을 목적으로 만들라는 의미가 아닙니다. 내가 지금 하는 일이 비지니스에 어떤 의미를 가지는지 이해해야 제대로 우선 순위를 정하고, 문제를 더 잘 분석하고 해결해 나갈 수 있다는 의미입니다.

버즈빌의 각 프로덕트는 어떤 의미를 가질까요

수영을 잘 하기 위해서 어떤 것들이 필요할까요? 수영 선수들은 어깨가 엄청 넓고 어깨 근육이 매우 잘 발달해 있죠. 팔 동작이 수영 속도에 큰 영향을 미치는 것은 자명합니다. 하지만 팔 동작만 잘 한다고 속도가 나지 않겠죠. 주기 함수에서 팔 동작이 진폭을 의미한다면, 발 동작은 y축 평행 이동을 책임집니다. 발차기를 통해서 꾸준한 속도를 만들어 낼 수 있죠. 이런 모든 동작은 기초 체력과 코어 근육으로 부터 나옵니다. 기본기가 되어 있어야 성장할 수 있죠. (제가 수영 전문가는 아니니 메타포로서 대충 이해 부탁 드립니다.)

우리 회사 내의 제품군과 내가 개발하고 있는 기능들이 어떤 역할을 하는지 생각해 보면 비지니스에 대한 이해도와 제품 및 기능의 의미를 좀 더 명확하게 느낄 수 있습니다. (각 버즈빌 프로덕트의 의미는 좋은 내부 토론 주제 입니다. 이 글에서는 설명 없이 넘어가도록 하겠습니다.)

우리의 프로덕트가 버즈빌 성장에 어떻게 영향을 미칠까요

서비스의 확장성(Scalability)과 관련해서 스케일 큐브(Scale Cube)라는 개념이 있습니다. 수평적으로 값을 복제하여 사용하는 X축, 기능 별로 묶어서 제공하는 Y축, 그리고 비슷한 것들을 묶어서 파티셔닝하는 Z축 확장을 모두 활용하면 이론적으로 무한한 확장이 가능하다고 합니다.

이 개념은 기술적인 확장성 외에도 생각보다 많은 경우에 적용이 가능합니다. 서비스 관점에 이를 적용해 볼까요? 우리는 현재 이뤄낸 성공을 복제하면서 X축 성장을 도모하고, 우리가 가진 기능과 효율을 늘려감으로써 Z축 성장을 도모할 수 있으며, 우리 시스템이 가진 독립적인 기능을 따로 제공함으로써 Y축으로도 성장할 수 있습니다.

마무리

대학교 재학 중 사진 동아리 활동 시절, 생각보다 많은 동아리 친구들이 사진이 아닌 카메라에 빠지곤 했습니다. 카메라의 성능에 관심이 많았고 카메라 조작 기술에 심취했죠. 좋은 사진을 찍는데 있어서 좋은 카메라와 좋은 기술은 매우 중요한 재료지만, 사진 자체에 대한 고민과 깊은 이해가 없다면 어느 순간 길을 잃게 되지 않을까요?

이 글이 우리가 개발자로서 무엇을, 왜, 어떻게 하고 있는지 고민하는데 조금이나마 도움이 되기를 바랍니다. 모든 개발자 여러분 화이팅 👍