화성에서 온 기획자, 금성에서 온 개발자. 또는, 화성에서 온 개발자, 금성에서 온 기획자라는 제목으로는 이전에도 많은 수의 글들이 존재해 왔습니다. 왜 이들이 남자와 여자처럼 서로 사고하는 방식과 특성이 다른지 많은 수의 사람들이 글을 써 왔고, 또 많은 사람들이 그 글을 읽고 공감해 왔습니다. 그렇지만, 남자와 여자들이 그러하듯 기확자들과 개발자들의 괴리가 글 하나로 쉽게 해결되지는 않습니다.
저 역시, 몇 해간 서비스를 개발하면서 기획자들과 개발자들이 함께 일하는 방식을 지켜봐 왔었고, 그 사이에서 개발자로서 일을 하여왔습니다. 한 두해 만으로 서로가 서로를 이해할 수는 없으며 어쩌면 영원히 이 둘은 서로를 완벽히 이해할 수 없을지도 모릅니다. 하지만, 남자와 여자가 그러하듯 서로의 다름을 인정하고 이해해 나가다 보면 정말 사용자들에게 좋은 서비스를 제공할 수 있을 것이라고 생각합니다.
이 글에서는 그럴싸한 근거를 들어 이들이 왜 다른지에 대해 설명한다기 보다, 저의 경험을 토대로 서로가 서로에게 절대로 해서는 안 되는 말들, 즉 커뮤니케이션에서 반드시 피해야 하는 언행에 대해서 몇 가지 적어보도록 하겠습니다.
이 순위들은 지극히 개인적인 판단으로 결정한 것이며 그 어떤 객관적인 근거가 없음을 밝혀두도록 하겠습니다.
기획자들에게 절대 해서는 안 되는 말들
Top 2. 그거 해봤는데, 안 되요.
개발자들은 자신의 경험을 바탕으로 어떤 것이 안된다고 너무 쉽게 말해버리는 경향이 있습니다. 그리고, 실제로 그것이 쉽지 않은 일인 경우도 많습니다. 어렵지만 그것이 왜 기술적으로 어려운지 설명하기 힘들어서 거두절미하고 “그거 안 돼요”라고 말하게 되곤 합니다.
하지만, 저를 포함한 모든 개발자들은 “그거 안 돼요”라는 말이 일종의 우대권이라고 생각해야 합니다. 즉, 몇 번 사용하고 나면 그 다음에는 전혀 효용가치가 없는 말이 된다는 것입니다. 몇 번 이러한 말을 하고나면 그 다음에는 당신이 어떠한 근거를 들어 설명하더라도 당신은 그저 ‘무조건 안된다고 말하는 사람‘이 되어 있을 것입니다.
실제로 불가능해 보이더라도 한번 쯤 말을 아끼고, 한 템포 쉰 후에 ‘시도해 봤으나, (충분히 납득할 만한 근거를 들어) 이러 이러한 이유로 현재 상황에서는 구현하는 것이 쉽지 않아 보입니다. 이러한 내용을 구현하기 위해서는 이러이러한 기간 또는 이러이러한 조건이 만족되어야 할 것 같습니다.‘ 라는 식으로 설명하는 것이 좋습니다.
커뮤니케이션이라는 것은 그 목적이 내 기분 푼다거나, 상대방과 싸우는 데에 있지 않고 궁극적으로 모두가 원하는 바를 얻고 상대방을 설득시키며 좋은 결론을 얻기 위함이라는 것을 항상 기억해야 합니다.
Top 1. 그럼 당신이 만들어 보든가요.
이러한 대화가 오고 가는 상황이라면, 이미 서로간의 신뢰가 많이 무너져 있다고 볼 수 있습니다. 이러한 대화는 보통 요구하는 기능에 대하여 “이건 그냥 ‘이렇게 이렇게’ 하면 되는 거 아니에요? 되게 간단해 보이는데?” 라는 식의 이야기를 들었을 때 화가 난 개발자들이 가끔 내뱉어 버리는 말들 입니다.
이건 정말 말도 안 되는 이야기입니다. 남편이 집에서 힘들게 애들하고 씨름하는 아내에게 “그럼 당신이 나가서 돈 벌어 오든가?” 라고 말하는 것과 다를 바 없습니다. 서로의 역할이 무엇인지 까맣게 잃어버리고 정말 해서는 안 되는 말을 뱉어 버리는 것이고, 더 이상의 커뮤니케이션이 불가능한 지경에까지 이르게 됩니다.
이건 머라고 깊게 설명할 필요가 없습니다. 그냥 이런 언행은 절대로 생각하지도 말고, 입에 담지도 말하야 합니다. 그냥 어디 아무도 안보는 개인 일기장에 혼자 끄적이고 말아야 합니다.
개발자들에게 절대 해서는 안 되는 말들
Top 3. 다른 곳은 되던데…
이 세상에 기술로 불가능 한 것은 없습니다. 우주로 여행을 가는 세상에 화면에서 이렇게 이렇게 동작하는 게 왜 불가능 하겠습니까? 다른 곳에서 이런 기능들이 동작한 다는 것은 기획자보다 개발자들이 이미 더 잘 알고 있습니다. 그러나, 개발자들이 ‘안 돼요’ 라고 말하는 것은 사실 ‘(이 기간과 이 일정에는) 안 돼요’ 라는 의미이거나, ‘(되게 할 수는 있으나, 그렇게 했을 때 이러이러한 문제가 발생할 소지가 있으니) 안 돼요‘ 라는 의미라고 받아들이는 것이 맞습니다.
기획자들이 개발자들과 일할 때 반드시 알아야 하는 개념이 있습니다. PMP(Project Management Professional) 에서 가장 핵심이라고 일컬어지는 내용으로 Time, Cost 그리고 Scope 의 상관관계입니다.
(개발을 포함한)모든 프로젝트는 시간(Time)과 비용(Cost), 범위(Scope) 그리고 품질(Quality) 네 가지 요소의 싸움이라고 볼 수 있습니다. 그런데 품질은 왜 제외했을까요? 품질은 기본적으로 최소한의 요건이 명확하기 때문에 쉽게 조절할 수 있는 영역이 아니기 때문에 현실 세계에서도 조절대상에서 많이 제외하기 때문입니다. 최종 아웃풋의 품질이 낮을 경우에는 그 이유가 무엇이 되었건 고객 또는 사용자들에게 외면을 받기 때문입니다.
그렇다면 나머지 세 가지 조건들에 대해서 이야기 해보도록 하겠습니다. 프로젝트는 주어진 시간에 주어진 비용으로 주어진 범위의 과제를 완수하는 것 입니다. 이는 다시 말해, 범위가 늘어났다면 시간이 함께 들어나거나 비용이 증가해 주어야 한다는 이야기 입니다. 만약 원가 절감의 이유로 개발자가 줄었거나, 사정상 오픈일정을 앞당겨야 하는 상황이 발생했다면 당연히 범위를 줄여야만 합니다. 그러나 현실세계에서 이러한 일들은 거의 불가능하며 대부분 모든 책임을 개발자들에게 맡기는 경향이 있습니다.
정리하자면, BMW 5시리즈에서 제공하는 앞유리에 속도 표시하는 기능을 갖고 싶다면, 개발자에게 ‘저번에 보니 BMW 5시리즈에는 되던데?’라고 말하지 말고, 현재 우리가 가지고 있는 비용과 기간이 아반떼 정도의 수준인지 BMW 수준인지를 먼저 판단해봐야 합니다.
Top 2. 시도 때도 없이 말이나 메신저로 하는 커뮤니케이션
제가 개발자이기 때문에 개발이라는 행위 자체를 감싸거나, 무슨 고귀한 작업인냥 포장하려는 것은 아닙니다. 이 세상의 모든 일들이 똑같이 어렵고 많은 노력을 요구한다고 생각합니다. 하지만, 많은 종류의 일이 그러하 듯 개발이라는 업무 역시 그 특성상 집중력과 아웃풋이 매우 밀접하게 관련되어 있습니다.
많은 개발자들이 개발하다가 전화받고, 이메일 보내다가 메신저 하다가 다시 개발하는 것에 익숙해져 있지만, 사실 이러한 방식으로는 절대 개발자가 발휘할 수 있는 최고의 품질이나 퍼포먼스를 만들어 낼 수 없습니다. 이 것은 제가 최근 1년간 매주 하루씩 재택근무라는 것을 하면서 절실히 깨달은 바입니다.
처음 재택근무를 하였을 때는 저 역시 쉽게 적응이 되지 않아 집에서 이래저래 왔다리 갔다리 하고 했는데, 집 앞에 있는 도서관 또는 커피숍에서 혼자 앉아 개발을 해보니 사무실에서 일할 때보다 훨씬 높은 집중력과 퍼포먼스를 발휘할 수 있었습니다. 아마도 평소 사무실에서 4~5일 정도 할일을 하루만에 해결하는 듯한 느낌이었습니다. 물론 개발한 내용에 대한 품질 또한 훨씬 더 좋았습니다.
그렇다고 ‘개발자가 개발할 때는 건들지 마라’라는 의미는 아닙니다. 다만, 가급적 이메일이나 JIRA, Track 과 같은 이슈트래킹 시스템이 있다면 그런 툴의 도움을 받는 것이 서로에게 좋을 것이라는 이야기 입니다. 특히, 이슈 트랙킹시스템을 이용하는 경우에는 자신이 언제 했는지 기억도 안나는 이야기들까지 정확히 현재 상태가 어떻게 진행되고 있는지 확인할 수 있는 장점이 많습니다.
물론, 원하는 결과를 가장 빨리 얻는 방법은 직접 이야기하는 것 입니다. 그러나, 스스로 생각했을 때 이 내용이 정말 촌각을 다투는 사안이 아니라면 개발자가 원할 때 확인할 수 있는 커뮤니케이션 방법을 이용해 보는 것이 좋습니다.
Top 1. 이건 그냥 ‘이렇게 이렇게’ 하면 되는 거 아니에요? 되게 간단해 보이는데?
제가 이 말을 가장 1순위로 정한 것은 아마도 개발자들이 가장 듣기 싫어하는 말들 중에서도, 가장 흔히 듣게되는 말이기 때문입니다. 개발자들에게 요구하는 기능의 난이도나 공수는 기획자가 생각하는 것보다 더 쉬울 수도 있고, 더 어려울 수도 있습니다. 아니면 기획자가 생각하는 정도와 비슷한 난이도일 수 있습니다. 하지만 중요한 건 그 일이 얼마나 어려운 일인지, 얼마나 오래 걸릴지는 단순히 그 일만을 바라봐서는 안 되고 기존의 시스템과의 관계와 다른 부분에 미칠 영향을 총체적으로 고려해야 하기 때문에 현재 시스템을 정확하게 파악하고 있는 사람이 아니고서는 그 누구도 섯불리 판단할 수 없다는 것 입니다. 즉, 주어진 일에 대한 난이도나 공수를 판단하는 것은 기획자의 몫이 아니라는 것 입니다. 심지어 같은 개발자라 하더라도 다른 사람이 맡은 영역에 대해서는 판단이 틀리는 경우가 허다합니다.
중요한건 누구의 판단이 옳고 그른지가 아닙니다. 개발자들은 실제로 그 일이 아주 쉬운 일이라고 하더라도, 누군가 그 일을 아주 쉽다고 이야기 하면 반사적으로 그 일이 왜 쉽지 않은지에 대한 근거를 찾게 됩니다. 오히려, “이거 너무 어려운 거 아닌가요?” 라고 말한다면 개발자들은 대부분 자신이 그 일을 반드시 해내기 위해서 노력할 것 입니다. 저도 개발자이지만, 개발자를 대할 때는 어린 아이들을 대하듯이 잘한다 잘한다 해주는 것이 가장 효율적입니다. 왜냐하면 개발자들은 대부분 자신의 아웃풋을 자기 자식처럼 생각하며, 자존심을 매우 중시하는 사람들이 많기 때문입니다.
다시말하자면, 개발자들에게는 원하는 바, 그 자체에 대해서만 이야기하고 그 일의 난이도나 공수에 대한 판단은 개발자에게 맡기도록 하는 편이 좋습니다.
맺음말
기획자와 개발자는 삼국지의 제갈량과 관우, 장비 처럼 서로가 잘하는 분야(지략, 전투)가 다를 뿐 한실 부흥이라는 대업을 이루기 위해서는 그 누구도 없어서는 안 되는 필수불가결한 존재입니다.
원문: 전호상 블로그
※ 이 글에 사용된 이미지들의 출처: whicdn.com / thefabulabs.com / cisco.com / sbccollege.ca / learnandteachstatistics.files.wordpress.com
chanel espadrillesWhat to Wear for a Smart Casual Dinner Out
