개발자에게 물어봤습니다: ③ 함께 일하고 싶은 기획자

우리가 알고 있는 대부분의 기업이나 서비스는 한 명의 힘으로 운영되지 않습니다. 스티브 잡스 하면 가장 먼저 떠오르는 애플의 아이폰조차 스티브 잡스 혼자만의 힘으로 만들어진 것이 아닙니다. 지금 이 시각에도 다양한 직무의 사람들이 서로 협력하며 서비스를 발전해 나가고 있으며, 특히 IT 기업의 경우 PM(혹은 기획자), 디자이너, 그리고 개발자가 함께 일하는 경우가 많습니다. 그렇다면 각 직무의 인재들이 원활하게 협력하기 위해서는 어떠한 역량이 필요할까요?

이번 시리즈를 통해 다양한 직무와 협업하는 IT 기업 직장인 중 개발자가 함께 일하고 싶어 하는 동료에 대해 다루고 있습니다. 오늘은 마지막으로 개발자가 생각하는 ‘함께 일하고 싶은 기획자'에 대해 살펴볼 예정입니다. 여러 의견을 듣기 위해 2년 차 개발자부터 10년 차 개발자까지 총 8명의 개발자와 인터뷰를 진행해 보았습니다. 과연 개발자는 어떤 기획자와 함께 일하고 싶어 할까요?

※ 기획자와 PM의 구분이 명확하지 않은 경우가 많아 해당 콘텐츠에서는 ‘기획자'라는 단어에 PM도 포함해 사용하고 있습니다.

개발자와 기획자의 협업

대부분의 개발자는 기획자와 함께 서비스를 만들어 나갑니다. 서비스의 큰 방향성은 함께 설정하더라도 구체적인 내용은 주로 기획자의 작업에 따라 결정되고, 개발자는 기획서를 토대로 개발을 진행하기 때문입니다. 그리고 기획자와 개발자 사이에 협업이 잦은 만큼 종종 소통에 어려움을 겪기도 하는데, 대표적인 상황은 다음과 같습니다.

1) 레거시를 고려하지 않고 속도만을 요구하는 경우

“PM의 기획 방향이나 속도가 기존 레거시를 고려하지 않을 때 어려움이 생기게 되는 것 같아요. PM 입장에서는 정말 별거 아닌 기능이라고 생각될 수도 있지만, 기존 레거시 체계에서는 굉장히 무리한 요구가 될 수도 있기 때문이에요. 하지만 하루라도 빨리 더 좋은 프로덕트를 고객에게 선보이고자 하는 PM의 입장도 어느 정도 이해는 하고 있어요. 그래서 이 부분은 모두가 조화롭게 해결해야 할 사항이라고 생각해요.”

많은 IT 서비스는 출시되고 난 이후에도 환경의 변화와 유저의 니즈에 따라 지속해서 발전합니다. 새로운 기능과 정책이 추가됨에 따라 서비스의 코드는 점차 복잡해지고, 코드가 복잡해질수록 새로운 기능을 추가하는데 필요한 시간도 증가하게 됩니다. 이렇게 복잡해진 상태를 IT 업계에서는 레거시, 혹은 기술 부채라고 말합니다.

같은 기능을 개발하더라도 기존에 레거시가 얼마나 쌓여있는지에 따라 개발에 소요되는 시간은 천차만별입니다. 그렇기에 많은 기획자는 개발자와 지속적으로 소통하면서 레거시를 파악하고, 기술 부채의 정도와 개발 속도를 이해해 나갑니다. 반면 몇몇 기획자는 단순한 예상이나 이전 회사의 경험으로 작업 기간을 산정하는데, 이런 경우 개발자와 소통에 어려움이 생기고 협업이 어렵게 됩니다.

2) 자신의 개발 경험만으로 판단하는 경우

“자신의 개발 경험으로만 판단하는 사람들과 함께 일하기 어려웠던 것 같아요. 간혹 자신이 개발자 출신이라거나 개발을 해본 적이 있다거나 해봐서 안다는 등의 말을 하며 의견을 밀어붙이고, 특정 기능에 대해 기술적으로 구현하기 어려운 이유를 설명해도 납득하지 못하던 기획자들이 있었어요.”

점차 프로그래밍 교육이 대중화되면서, 개발자가 아니더라도 프로그래밍을 접하는 사람들이 많아지고 있습니다. 이는 기획자도 마찬가지인데, 그러다 보니 ‘이 정도 기능이면 내가 직접 개발할 수 있겠다’는 생각을 하는 경우도 종종 생기는 것 같습니다.

그러나 앞서 말했다시피 같은 기능이더라도 회사의 상황이나 레거시 등에 따라서 작업의 난이도는 달라질 수 있습니다. 실제로 몇 년간 개발자로서 경력을 쌓아온 기획자도 이러한 사실을 잊고 개발자와의 소통에 어려움을 겪는 경우도 있는데, 어떤 직무든 자신의 경험을 지나치게 확신하지 않고 현재를 이해하려고 노력하는 자세가 필요한 것 같습니다.

3) 다른 팀과의 조율이 원활하지 못한 경우

“한참 기획을 쭉 따라가면서 개발하다가 갑자기 다른 프로젝트가 검증 중인 기능을 건드리게 되는 상황이 발생할 때가 있어요. 서로 간에 일정 조율이 안 되면 그쪽 프로젝트가 끝날 때까지 기다리거나 우리 기획을 우회해서 수정해야 하는데요. 그러면 일정 산정도 다시 해야 하고, 세부 정책도 바뀌어야 해서 그런 상황이 생길 때 조금 아쉬운 것 같아요.”

회사 내에 여러 팀이 존재하는 경우, 보통 팀마다 서로 다른 기능을 담당합니다. 그러나 간혹 작업 영역이 겹치는 상황이 생기는데, 이럴 때 팀 간 조율이 되지 않는다면 개발 단계에서 작업 시간이 늘어나거나 예상치 못한 오류가 발생할 수 있습니다. 물론 어쩔 수 없는 상황이 많겠지만, 개발자 입장에서는 프로세스의 첫 단계를 담당하고 매니징하는 기획자가 확인하지 못한 부분으로 인해 불필요하게 작업시간이 늘어났다고 생각하게 되어 소통에 어려움이 발생하기도 합니다.

함께 일하고 싶은 기획자

협업하는 과정에서 서로 다른 의견이 생기는 것은 자연스러운 현상입니다. 의견을 이야기하고 맞춰가는 과정에서 더 좋은 아이디어와 방식이 나오기도 하는데, 과연 개발자들은 어떤 기획자와 함께 의견을 나누며 협업하고 싶어 할까요?

1) 다른 직무와 프로세스 전반에 대한 이해도가 있는 사람

“개발적인 이해가 부족하면 성격의 차이보다도 소통에 어려움이 생기는 것 같아요. 가끔 보면 백엔드도 아예 모르고, 프런트엔드도 아예 모르고, ‘그래서 그럼 언제까지 되는 거예요?'라고만 말하는 PM들이 있어요. 이렇게 개발 전반의 프로세스와 소프트웨어 프로덕트가 어떻게 나오는지 알고 있는 사람들이 아니면 같이 일하기 힘들어요. 가령 문제가 있거나 수정이 필요할 때 프론트엔드 개발자에게 가서 말해야 할지 백엔드 개발자에게 말해야 할지 판단을 잘하지 못하는 거죠. 그럼 물어봐야 하는데 사실 어느 정도 백그라운드가 있어야 질문을 잘할 수 있다고 생각하고, 그렇지 않다면 이런 과정에서 리소스 소모가 많이 되는 것 같아요.”

기획자는 보통 전체적인 기획, 디자인, 개발의 과정을 조율하고 일정을 관리합니다. 그리고 일정을 관리하다 보면 다른 직무의 업무에 대해서도 알아야 하는 상황이 생기는데, 다른 분야를 이해하려고 하지 않는 경우에 주로 마찰이 발생합니다. 모든 분야에 대해 깊이 알고 있을 필요는 없지만, 기본적인 내용이라도 이해하기 위해 노력한다면 훨씬 소통하기 편해질 것입니다.

그렇다면 어떻게 다른 분야에 대한 이해도를 높일 수 있을까요? 많은 방법이 있겠지만 인터뷰 참가자 중 한 명은 직무와 프로세스에 대한 이해도를 높이는 방법 중 하나로 ‘이것저것 관심을 두고 물어보는 것’을 제안했습니다.

“이것저것 관심이 많은 사람이면 좋겠어요. 개발 코드까지 이 로직은 어떻게 되는 건지, 개발자들이 리팩터링 했다고 하는데 어떤 것을 리팩터링했는지 그냥 다 물을 수 있는 사람이면 좋을 것 같아요. 결국 그런 것을 다 이해해야 소통에 도움이 되기 때문이에요. ‘개발자가 알아서 다 잘하겠지’, ‘디자이너가 알아서 다 잘하겠지’라고 넘어가는 게 좋을 수 있어요. 하지만 개발하면서 꼭 개발자만이 좋은 코드 리뷰를 할 수 있는 것은 아니라고 느꼈어요. 개발자가 며칠 동안 고민하던 것을 PM이 별것 아닌 단서로도 도움을 줄 때가 많이 있는데, 그런 통찰력을 가진 PM이면 좋겠어요. 그리고 PM만큼 다른 직무를 둘러볼 수 있는 사람도 없는 것 같아요.”

다른 직무를 이해하기 위해서는 호기심을 갖고 틈틈이 물어보는 자세가 필요합니다. 그리고 기획자는 업무 과정에서 많은 직무의 사람들과 소통하기 때문에 질문할 수 있는 기회도 많습니다. 물론 아무 설명 없이 사소한 것까지 질문한다면 마이크로 매니징을 한다는 느낌을 받을 수 있겠지만, ‘왜 물어보는지’만 명확하다면 누구나 자신이 알고 있는 것을 기꺼이 설명해줄 것입니다. 이러한 노력이 쌓인다면 프로세스에 대한 전반적인 이해도가 높아질 것이고, 결국 이는 자신의 경쟁력이 될 것입니다.

2) 가설의 근거가 명확하고 자신이 있는 사람

“본인이 세운 가설에 근거가 명확하고 자신이 있는 기획자와 함께하고 싶어요. 저는 뭔가 확신이 있거나, 적극적으로 소통할 의지가 있는 사람들이랑 에너지 뿜어내면서 일하는 게 즐거운 것 같아요. 개발자 역할이 아무래도 기획된 내용을 구현해내는 것이니까 굉장히 생산적으로 보일 수 있어요. 하지만 반대로 기획자가 ‘우리가 다 기획했으니까 이대로 만들어 줘'라고 강요하면 개발자 자신이 수동적인 구성원처럼 느껴질 수도 있거든요. 자신이 있고 근거가 명확한 동료와 함께할 때 저는 뭔가 ‘다 같이 의미 있는 일을 한다.’라는 느낌을 받고 확실히 더 열심히 일하게 되는 것 같아요.”

업무에 있어서 명확한 근거와 설득은 매우 중요합니다. 같은 일을 하더라도 그냥 주어졌을 때와 업무의 논리를 이해하고 할 때의 마음가짐이 매우 다르기 때문입니다. 특히 개발자는 주어진 기능과 디자인을 그대로 구현하는 만큼 명확한 설명 없이 업무만 주어졌을 때, 스스로를 수동적인 구성원으로 느끼기 쉽습니다. 그렇기에 기획자는 더욱 기획에 대한 근거를 함께 설명할 필요가 있고, 그 근거가 명확할수록 개발자뿐만 아니라 여러 동료와 능동적으로 협업할 수 있을 것입니다.

3) 적절한 유저 니즈를 발굴할 수 있는 사람

“PM은 장기/단기적으로 본인이 매니징하는 조직의 목표를 세우고 그 목표를 실제 성과로 끌어올리는 직군인 것 같아요. 가장 앞에서 제품에 필요로 하는 니즈를 지각하고, 발굴한 니즈 중에서도 가장 중요하고 임팩트가 있을 만한 작업을 고르고, 이를 내부 조직에 설득하고, 실행해서 실질 결과물을 만드는 역할이라고 생각하거든요. 뛰어난 PM은 제품이 경시하고 있던 유저 니즈 중에서도 실행하기 값싸고 가져올 임팩트가 큰일들을 지속해서 찾아내고 성공시키는 사람이 아닐까 싶어요.”

개발자는 자신의 작업, 그리고 결과물로 인한 서비스가 더 많은 유저에게 큰 영향을 끼치기를 바랍니다. 그리고 유저에게 어떤 영향을 미칠지는 기획자의 기획에 따라 결정되는 경우가 많습니다. 결국 본인뿐만 아니라, 팀원들과 원활하게 협업하기 위해서도 기획자 본연의 역량을 기르는 것이 중요합니다.

4) 팀 전체의 상황을 읽을 수 있는 사람

“높은 커뮤니케이션 능력과 팀 전체의 진행 상황을 읽을 줄 아는 혜안이 있는 분이면 좋겠어요. 팀원 각각이 아무리 똑똑하고 열심히 하는 사람들이라고 해도 결국 프로덕트의 성공은 PM의 능력치와 열정에 의해 훨씬 더 많은 영향을 받는 것 같아요. 우리가 스타크래프트 같은 게임을 할 때도 자원은 잘 캐고 있는지, 우리 팀은 어떤 상태인지, 적은 어떤 전략을 쓸 것 같은지 등을 수없이 머릿속에서 병렬 처리하면서 게임을 하는데, 프로덕트 개발도 똑같다고 생각해요. 이러한 병렬 처리를 잘하시는 분이면 좋겠고, 그래야 목표한 대로 좋은 프로덕트가 나올 수 있는 것 같아요.”

디자이너나 개발자는 주로 특정 기능을 전담하여 작업합니다. 그러다 보면 조금 더 세부적인 부분에 집중하게 되고, 어쩔 수 없이 큰 방향성에 대해 고민할 수 있는 시간이 부족합니다. 반면 기획자는 내부적으로 프로세스의 진행 상황을 챙기고 외부적으로 유저의 니즈를 파악하는 직무이기 때문에 전체적인 상황을 파악하기 유리합니다. 결국 기획자가 큰 그림을 보고 방향성을 제시할 수 있어야 합니다. 물론 쉽지 않은 일이겠지만, 팀 전체의 상황을 챙길 수 있다면 팀원과 협력하고 프로덕트가 올바른 방향으로 나아가는 데 큰 도움이 될 것입니다.

프로세스를 이해하고 유저를 잘 아는 기획자를 원한다

인터뷰 내용을 종합해보면 개발자는 전반적인 프로세스와 팀을 잘 이해하고, 유저를 잘 파악할 수 있는 기획자와 함께하길 원하는 것을 알 수 있었습니다. 유저를 잘 파악할 수 있어야 임팩트 있는 기획안을 만들 수 있고, 프로세스를 이해하고 있어야 여러 사람과 소통하며 기획안을 원활하게 진행할 수 있기 때문입니다.

지금까지 시리즈 글을 통해 개발자가 함께 일하고 싶어 하는 세 가지 직무의 특성에 관해 모두 살펴봤습니다. 여러 특성 중 공통적으로 소통과 협업에 대한 내용이 있었습니다. 앞에서 설명했듯이 혼자만의 힘으로 원대한 서비스를 만들기는 불가능합니다. 직무에 상관없이 자신이 더 성장하고 좋은 영향을 주고 싶다면 업무적 역량을 기르는 것뿐만 아니라 주변의 동료들과 함께 소통하는 자세가 중요하다는 걸 새삼 느끼게 됐습니다. 여러분은 어떤 사람과 함께하고 싶으신가요?

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.