같이 일하고 싶은 소프트웨어 엔지니어의 특징
초보 PM의 입장에서 바라본
들어가며
첫 회사는 디자인 컨설팅 회사였고 저는 주로 UX 리서치/전략을 담당했기 때문에, 소프트웨어 엔지니어 분들과 함께 일할 기회가 많이 없었습니다. 두번째 회사는 50여명 규모의 코딩교육 스타트업이었고, 거기서 PM으로 일하며 여러 소프트웨어 엔지니어 분들과 협업하게 되었습니다. 다양한 개성을 가진 소프트웨어 엔지니어 분들과 매일 소통하며 일할 수 있었습니다. 그 과정에서 같이 일하기 편했던, 다음에도 같이 일하고 싶은 소프트웨어 엔지니어의 특징을 생각하게 되었습니다.
1. 기술 개념을 비전공자도 이해하기 쉽게 설명한다
PM의 핵심 업무는 우선순위 판단과 리소스 분배입니다. 핵심 업무를 잘 하려면, 기술적 개념에 대한 이해를 게을리할 수 없습니다. 처음 PM을 하며, 처음 접하는 기술 용어들이 많아 어려웠습니다. 검색을 통해서 스스로 학습하려 해도, 전공자가 아니라면 설명도 이해하기 상당히 어려웠습니다.
예를 들어 검색을 구현할때 현재 쓰고 있는 A라는 기술 방식과 B라는 새로운 기술 방식이 있습니다. 검색 정책을 개편하면서, 개발 팀에서 B라는 기술을 도입하면 초기 개발 리소스는 많이 들지만, 장기적 이점이 많을 것이라 이야기합니다. 여기서 A와 B는 각각 어떤 방식이며, 어떤 장단점이 있는지, 왜 리소스가 많이 드는 것인지를 제대로 이해하지 않으면 좋은 의사결정을 내리기 어려울 것입니다.
이때 한 소프트웨어 엔지니어께서 비전공자도 이해하기 쉬울 정도로, 개념을 풀어 설명해주었습니다. 그 분은 기술적 개념을 일상생활 또는 비즈니스에 빗대어 잘 설명했습니다. 위의 검색 기술을 예로 들자면, A라는 방식은 1이라는 검색 요청이 왔을 때 100명의 내부 직원이 1을 찾기 위해 각자 DB를 찾는다고 하면, B라는 방식은 검색에 능통한 외주업체에게 이 일을 맡긴다고 설명하는 식이죠. 그렇게 되자, 다른 사람과 하는 프로젝트에서 나오는 개념도 해당 소프트웨어 엔지니어에게 어떤 의미인지 물어보게 되었습니다.
더욱 고마운 사람들은, 제가 먼저 요청하기도 전에 먼저 나서서 따로 시간을 내어 생소한 개념을 설명해주는 분들입니다. 비전공자에게 생소하게 느껴지는 맥락이 무엇인지 정확하게 파악하고, 최적에 타이밍에 소통을 요청할 능력이 있는 분이라고 생각했습니다.
2. 기획 의도를 비판적으로 이해하고 나은 방향을 제시한다
기획은 '왜?'라는 질문에서 출발합니다. 이걸 왜 해야하는가? 반드시 필요한가? 누구를 위해서 해야 하는가를 하나 하나 정의해 나갑니다. 해결방안도 중요하지만, ‘왜?’라는 질문에 제대로 답하지 않는다면, 수많은 비용을 들여 아무도 쓰지 않고, 왜 쓰는지도 모르는 무언가를 만들겠죠. 엔지니어는 '어떻게?'를 다룹니다. 기획에서 정의한 'A 유형의 사용자를 위해, B라는 목적을 달성하게 돕기 위한 기능'을 어떻게 구현할지 풀어내야 합니다.
PM의 의도를 여과없이 받아들이는 엔지니어와 비판적으로 받아들이는 엔지니어는 output이 완전히 다릅니다. 여기서 제가 말하는 '비판적으로 받아들인다'는 말은 기획자 말에 무조건 반대한다는 의미가 아닙니다. 누구를 위해 어떤 문제를, 어떤 방향으로 해결하려는지 정확히 이해하고 여기에 본인의 독립된 논리적 사고를 곁들인다는 의미입니다.
'어떤 문제를 해결하기 위해 A를 B 방식으로 만들자(고치자)'는 PM의 생각에서, A와 B에는 엔지니어가 개입할 여지가 충분히 있습니다. 문제를 해결하기 위해 A를 건드리는게 아니라 C를 건드리는게 더욱 효율적일 수도 있고, PM이 알지 못했던 다른 D 방식이 효율적일 수도 있습니다. 다만, PM이 A와 B를 제안하는 것은 생각의 틀이 거기 머무른 것입니다. 다른 관점에서 새로운 더 좋은 방안을 제시하는 걸 싫어하는 PM을 좋은 PM으로 보기는 어려울것 같습니다.
PM 입장에서는 엔지니어가 요구사항을 충족하는 더욱 간단한 구현방안을 제시한다면 더욱 좋습니다. 리소스를 절약하면서 원하는 목표를 달성할수 있기 때문입니다. 다만, 이런 제안이 가능하려면 문제정의와 기획 단계에서 엔지니어와 소통이 원활하게 이루어지는 회사여야겠지요.
3. 유저의 입장에서도 제품을 보려고 노력한다
프로덕트 팀의 목표는 프로덕트가 성공하는 것입니다. 프로덕트가 성공하기 위해서는 많은 유저가 프로덕트에서 가치를 느끼고, 잘 사용해야겠죠. 멋진 신기술을 사용했는지, 디자인이 매력적인지는 부차적입니다. 신규 유저가 지속적으로 유입되고 기존 유저가 지속적으로 제품을 사용한다면, 소프트웨어 엔지니어, 디자이너, PM이 만든 프로덕트는 성공궤도에 오른 것입니다.
회의를 할때 기술적인 부분에 대해서만 흥미를 가지는 엔지니어가 있고, 유저 입장에서 보려는 엔지니어가 있습니다. 유저가 어떤 생각을 하는지, 유저가 어떻게 행동하는지 관심을 가지는 분들입니다. 자신이 구현한 제품이 의도대로 사용되고 있는지, 유저가 어떤 어려움을 겪는지 관심을 가지는 분들은 유저에게 발생하는 문제 해결에도 적극적입니다.
제품을 만드는 입장에서 바라보는 관점과, 유저의 관점은 다를 수 밖에 없습니다. 만드는 입장에서는 서비스를 바라보면 복잡한 기능, 기능 안의 운영 정책, 화면 구성, 컴포넌트, 데이터 구조가 눈에 들어옵니다. 유저 입장에서는 정책이나 컴포넌트보다는, 자신의 목적을 달성하도록 돕는 무언가가 눈에 들어오겠죠. 이렇게 메이커에서 유저 관점으로 모드를 전환하려면 의식적인 노력이 필요합니다.
아무래도 PM 입장에서, 유저의 문제를 해결하려는 엔지니어가 더 함께 일하고 싶겠죠. 유저의 문제가 곧 PM이 해결해야 하는 문제이자, 프로덕트가 성공하기 위해 팀에서 해결할 문제이기 때문입니다.
마치며
제가 위에서 작성한 내용들은 사실 코딩 실력과는 별개의 이야기겠죠. 함께 일했던 분들이 실력이 좋았던 분들이기 때문에, 기본적인 코딩 능력에 더해, 같이 일하기 편하다 느꼈던 분들의 특성을 정리해 보았습니다. 읽어주셔서 감사합니다.
