멀게 느껴지지만 가깝게 지내야 하는 개발자
‘개발자’라는 세 글자, 벌써부터 어렵습니다. 지금은 개발자와 소통하는데 어느 정도는 편해져서 함께 일을 그럭저럭 해 나갈 수 있지만, 처음 기획을 시작하던 무렵에 개발자와 소통하는 것은 저에게 크나큰 숙제였습니다.
때는 2015년 1월, 한주의 일정을 마무리하는 금요일 주간 회의 시간. 개발자들이 각자 이번 주에 본인이 맡은 일에 대해서 설명합니다. JSON이 어쩌고 저쩌고, PARSING이 어쩌고 저쩌고, XML이 어쩌고 저쩌고... 자신이 한 일에 대해서 쭉 이야기를 하는데 도무지 무슨 말인지 알아들을 수가 없었습니다. 한편으로는 앞으로 내가 이 사람들과 어떻게 일을 해야 되나 정말로 막막했습니다.
다행스럽게도 개발에 대해 거의 모르는 저에게 차근차근 서비스가 어떻게 만들어지는지에 대해 설명해주는 개발자도 있었습니다만, 개발을 거의 모르는 저를 완전히 무시하는 개발자도 있었습니다. 이를테면 이런 식이었죠. ‘ㅇㅇ씨 그것도 몰라요? 하 진짜 답답하네’. 뭐 정확히 이런 워딩은 아니었지만 대체로 이런 식의 반응을 보였고, 잔뜩 움츠러든 저는 그 사람과 서비스에 대해 이야기하러 갈 때마다 속으로 한숨을 몇 번은 쉬고 말을 걸었던 것 같습니다. 한편 지금 생각해보면 그 사람이 그렇게 한숨을 쉬었던 데는 다 이유가 있었습니다. 아래에 서술한 내용은 제가 생각하는 이유입니다.
1. 정확하지 않은 설명
프로그램은 0과 1로 이루어져 있기 때문에 ‘그런 것도 같고 아닌 것도 같다’는 모호함은 절대 통하지 않습니다. ‘정확’ 해야 합니다. 이 버튼을 누르면 이것이 출력된다. 예외 상황은 이런 것들이 있으며 이런 상황들에서는 각각 이런 액션들이 나타난다. 서비스의 flow는 이렇게 되며 여기서는 그 외 다른 방법의 접근은 허용하지 않는다 등, 어떤 상황의 밴 다이어그램을 상상했을 때 100% 빠짐없이 모든 상황에 대해서 명확하게 설명을 해주어야 합니다. 물론, 우리는 완벽하지 않기 때문에 때론 실수를 할 수도 있겠죠. 하지만 시작부터 많은 고민이 묻어나는 기획과, 이상적인 케이스만 고려한 기획은 개발자가 받아들이는 데 있어 많은 차이를 보일 것입니다. 개발자가 ‘그럼 이럴 때는 어떻게 하나요?’, ‘저런 케이스에는 어떻게 해야 하나요?’ 등의 이야기를 시작한다면 아마 상당히 곤혹스러울 것입니다.
개발자도 처음에는 그러려니 하겠죠, 하지만 결국 그도 사람입니다. 자꾸 무언가를 빼먹는 기획자에게 무한한 자비를 베풀만한 개발자는 별로 없을 것입니다.
2. 해도 해도 너무 모른다. 개발.
개발은 결국 데이터를 어떻게 저장하고 교환할 것인지를 프로그래밍 언어를 통해 구축해내는 것입니다. DB에 어떻게 저장하고, 클라이언트에 어떻게 표현해내야 되는지에 대한 지식이 전혀 없다면 아예 개발자와 소통할 수 없겠죠. 저도 처음에 기본적인 개발 용어도 모르는 상태로 기획을 시작했었기 때문에 개발자들이 답답해할 때가 한두 번이 아니었을 겁니다. 하다못해 클라이언트가 요청을 하고 서버가 응답을 하는 것조차도 몰랐으니 개발자 입장에선 그런 사람이 서비스 기획을 할만한 자격이 되는지도 많이 의심했을 겁니다. 한편 많은 기획자들이 개발을 잘 몰라도 기획을 잘하는데 큰 지장은 없다고들 말합니다. 저도 일정 부분 공감합니다만 그래도 개발에 대한 관심을 절대 놓아서는 안된다고 생각합니다. 결국 우리는 개발자와 가장 많이 ‘소통’해야 되니까요. 개발을 직접 하지는 못해도, 조금씩 보는 눈을 키워서 소통하는데 활용할 수 있어야 합니다.
심각한 ‘개알못’이었기 때문에 초반에 많은 무시를 당했습니다. 어쩌면 당연한 일이었겠죠. 아마 제가 개발자라도 무턱대고 아무것도 모른 채 서비스 개발에 참여한 기획자를 그런 시선으로 바라봤을지도 모르겠습니다. 우리는 개발자에게 진정 어린 협조를 이끌어 내야 합니다. 사업부서가 어떤 요청사항을 정리해서 가져다주면 기획자는 그것을 개발의 형식에 맞게 잘 가공을 해서 개발자와 소통해야 합니다. 그런 과정을 잘 해내는 기획자가 개발자들로부터 진짜 동료로서 인정받을 수 있습니다.
일을 잘하기 위해 꼭 사적으로 친하게 지낼 필요는 없습니다. 그런 인간적인 영역은 사람에 따라 잘 해내는 사람도 그렇지 못한 사람도 있으니까요. 다만 아래와 같은 사항들을 지키신다면 아마 무리 없이 개발자와 일 할 수 있지 않을까 생각합니다.
1. 개발자를 존중, 또 존중
개발자 출신의 기획자가 아닌 이상 개발자는 개발에 있어서 기획자보다 훨씬 더 잘 압니다. 기획자가 생각한 개발 접근이 개발자에게 있어서는 말도 안 되거나 매우 어려운 방법일 수 있습니다. 만약 개발자가 기획자가 제안한 방법으로 개발하는데 난색을 표한다면 반드시 그 이유를 상세히 들어보고 공감해주세요. 저는 가급적이면 사업을 요청한 누군가보다는 개발자의 의견을 적극 공감해주고 지지해주는 것이 중요하다고 생각합니다. 만약 사업 요청 부서와 개발자와의 의견이 서로 충돌 나는 경우라면 - 상황에 따라 물론 다르겠지만 - 개발자의 생각을 일반인의 언어로 충분히 전달하는 역할을 기획자가 맡아서 해야 한다고 생각합니다. 이런 행동이 개발자에게는 큰 도움이 되며, 더 나아가 개발자가 기획자를 자신의 ‘동료’로서 생각할 수 있게끔 만들어줍니다.
물론, 그저 일이 귀찮아서 복잡하고 어려운 일은 회피하는 개발자도 있을 수 있겠죠. 아마 그런 개발자라면 기획자 스스로 어떤 사람인지 감이 올 겁니다. 그런 경우까지 편을 들어줄 필요는 없겠죠.
2. 우리는 문학작품을 쓰는 것이 아닙니다.
서두에 했던 이야기와 일맥상통하는 내용입니다. 우리는 기획서를 쓸 때 문학작품을 쓰는 것이 아닙니다. 최대한 기승전결에 맞게, 또한 역, 이, 대우 등 논리 구조에 맞게 기획서를 작성해야 합니다. 개발에 있어 ‘없다’와 ‘있을 수도 있다’는 매우 큰 차이를 보일 수 있습니다. 확률 0%와 0.01%는 현실에서는 거의 비슷하지만, 개발에서는 매우 다른 차이를 보일 수 있기 때문에 0%와 0.01%를 구분하지 못하는 우를 범해서는 결코 안됩니다. 기면 기고 아니면 아니게 최대한 정확하게 표현해주세요.
3. 개발자의 언어로 이야기해보려고 해 보세요.
최대한 개발자들이 이야기하는 방식으로 대화를 시도해보는 것이 일을 효율적으로 진행하는데 도움이 됩니다. DB를 어떻게 join 하고 query를 어떻게 뽑아내고, 어떤 API를 어디에 활용하고 등 개발자들끼리 서로 소통하는 방식을 한번 관찰해보고 실제 업무에 활용해보세요. 물론 이 부분은 개발에 대한 지식이 없으면 그저 흉내내기에 지나지 않을 것입니다. 하지만 핵심은 그들의 의사소통 방식을 관찰해서 그들이 이해하기 쉬운 형태로 접근해야 한다는 것입니다. 기획자 입장에서 개발자는 ‘고객’입니다. 저희는 기획을 개발자에게 sales 하는 것입니다. 그들이 이해할 수 있는 형태로 이야기하는 것을 통해 보다 효율적인 협조를 이끌어 낼 수 있을 것입니다.
4. 최대한 솔직하게.
개발자들이 때론 이렇게 묻습니다. ‘이거 진짜 왜 하는 거예요?’ 이럴 때 억지로 누군가의 의견을 대변할 필요는 없습니다. 기획자 본인조차도 상부의 지시(chain of command)에 의해 어쩔 수 없이 기획을 해야 되는 경우라면 차라리 허심탄회하게 터놓고 이야기를 하는 것이 좋습니다. 혹은 본인이 원해서 하는 기획인데 본인이 생각해도 문제가 있는 부분이 있다면 해당 부분에 대해서 억지로 설명하려 들지 말고 속 시원하게 해당 이슈를 인정해버리는 것이 좋습니다. ‘저도 그렇게 생각은 하는데 도저히 답을 모르겠어요, 혹시 이 문제를 해결할만한 좋은 방안이 없을까요?’ 같이 열린 자세로 접근하는 것이 생각보다 매우 중요합니다.
개발자의 책상에 방문하면 어두컴컴한 배경의 프로그램과 깨알 같은 언어로 둘러싸인 모니터가 두 세대 있는 모습을 흔히 보실 수 있을 것입니다. 그런 모습에 처음에는 뭔가 다가가기 어려움이 느껴집니다. 하지만 배우려는 태도, 존중하는 태도, 진정성 있는 태도를 갖고 개발자에게 다가가는 기획자에게 대놓고 면박을 줄 개발자는 아마 거의 없을 것입니다. 모두 함께 일을 만들어가는 ‘동료’로서 상대방의 입장을 한번 더 생각해보고 진정성 있는 업무 요청을 할 때 보다 성공적인 기획의 첫발을 디딜 수 있을 것입니다.
다음 시간에는 기획자의 개발 공부에 대해서 알아보도록 하겠습니다.
읽어주셔서 감사합니다.
