(2편) 스타트업처럼 일해야해 vs. manners maketh product
페친분들중에 참 대단한 분들이 많으셔서, 멋진 책을 쓰시는 분들이 계십니다. 마침 부산에 계시는 곽한영 님께서 쓰신 책을 사서 읽다가 (보통 저희들은 구독료를 낸다고 표현합니다만) 이 글에 어울리는 문구를 발견해서 원래 쓰던 글의 제목을 변경해서 들였습니다.
Manners maketh man, manner의 의미, 그리고 Mannerism.
“사전적으로 보면 매너는 '일이 되어가는 방식'이고 '타인을 대하는 외면적인 태도'입니다. 즉 사회적으로 통용되고 고정된 어떤 코드에 따라 타인을 대하는 것이 매너의 기본적인 의미입니다. 따라서 매너는 좋은 의미인 반면 매너에 얽매이는 매너리즘(mannerism)은 틀 에 박힌 일정한 방식이나 태도를 취함으로써 신선미와 독창성을 잃어버리는 일로 부정적인 의미를 띠는 아이러니가 발생합니다.”
이 글의 전편에서 언급했던 시스템에 대한 부정적 경험이 mannerism 이라고 얘기할 수 있겠습니다. 시스템이라는 것은 분명 매너리즘을 야기하는 측면도 있기는 합니다. 전편에서 언급했던 물샐틈없는 시스템의 경우에도 그러하겠고, 목표의식을 상실하고 눈앞의 턴을 돌리기만 하는 경우에도 그렇게 표현할 수 있습니다. 이런 경험을 하신 분들은 아마도 인간의 자율의지를 더 신봉하고 시스템을 배격하고자 하는 필요를 역설하시기도 할 것입니다.
하지만 mannerism이 있으니까 manners가 필요없는 것이 아니라는 말씀을 꼭 드리고 싶습니다. 그래서 오늘의 주제입니다.
일이 되어가는 방식, manners가 프로덕트를 만드는 제품개발프로세스 vs. ‘우리는 스타트업처럼 일해야해’
턴돌리기는 시스템 하에서만 발생하는 것이 아니라는 것도 꼭 알아두어야 합니다. 자율의지의 시스템리스 상태에서도 턴돌리기는 얼마든지 발생할 수 있습니다. 그리고 그런 상황이 일단 벌어지고 나면 그때에는 인간의 자율의지만으로는 극복할 수 없습니다.
우리는 스타트업처럼 일해야해, 그러니까 개발자를 괴롭히는 시스템이나 프로세스를 만들지 말아야 해
이런 얘기를 들어보신 분이 많으실 것입니다. 혹시 이런 얘기를 직접 해보신 분도 계시지 않을까요? 그분들께 꼭 여쭤보고 싶습니다. 스타트업처럼 일한다는 것은 무엇인가. 지금의 상태를 부정적으로 인식하고, 그러니까 긍정적인 반대의 의미로 스타트업처럼 일한다 를 꼽으셨을 것입니다.
제가 이런 얘기를 들었던 것은 두번입니다. 그중 첫번째 상황을 들어보겠습니다.
우리는 원팀으로 일할거야. 스타트업처럼.
(One team spirit, Startup spirit)
그때의 부정적인 상태를 회상해보자면, 제품개발의 일정은 여러개월 예상으로 잡아야 하는데, 개발에 투입되는 것은 리소스가 부족해서 수개월 뒤에야 착수할 수 있고, 하지만 정작 그 시점에는 제품에 대한 MRD/PRD가 작성된 것도 아니어서, 그 제품이 어떤 형상인지, 실제로 얼마나 기간이 들어갈지 아무도 예상하려 시도해보지도 않았습니다.
오랜시간 진행되어왔던 어떤 과제는 시연회도 하고 개발완료를 선언하고 나서야 영업팀으로부터 ‘개발팀이 어떤 기능을 구현하지 않아서’ ‘고객에게 제공할 수 없는’ 상태라고 회신을 받고 경영진에게 보고되었습니다. 개발팀의 누락인가, 요구명세의 잘못인가를 따져야 하는 상황입니다. 여러개월을 끌어왔던 TF에게 다시 추가 몇개월의 ‘추가개발’이 부여되었습니다.
급기야 경영진에서는 Project Leader 제도를 따로 도입해서, 모든 개발팀은 원팀으로 스타트업처럼 일해야 한다는 선언을 하게 되었습니다.
저는 그때의 상황이 제품개발 프로세스가 전무하여 시스템이 존재하지 않는 아노미 상태처럼 보여집니다. 참여자 또는 이해관계자 개개인의 역량과 자율의지에 기대었고 최악의 상황을 방어해야할 시스템이 전무하기 때문에 발생했다고 봅니다. 그러니까 당연히 해결책도 시스템을 설계하고 시스템 안에서 구성원이 작동하도록 제어하는 것이라고 생각했지만, 경영진의 생각은 달랐습니다. Project Leadership 를 부여하고 더 탁월한 개인기로 이 상황을 구성하여 극복하려고 합니다.
사람은 누구나 자신의 경험을 기반으로 판단합니다. 과거에 뛰어난 개인, 탁월한 개인기 즉 수퍼맨이 문제를 해결하는 것을 보고 경험했으며, 본인이 수퍼맨이었던 시절을 회상하시는 분들은 모든 문제를 수퍼맨으로 해결하려고 합니다. 어쩌면 그 경영진 분들은 한때 또는 현재에도 수퍼맨이기 때문에 그렇게 해결하고 싶은 것일까요?
최근 들었던 그 조직의 상황입니다.
UIUX: PRD가 나와야만 개발/디자인 리소스를 검토할 수 있을것 같습니다.
BE: PRD가 개발에 방해됩니다 DB아키텍쳐 설계는 PRD에 있는 스토리 레벨이 아닌 디자인이 나와야만 가능합니다.
UIUX: PRD가 디자인을 방해합니다. (유즈케이스 작성해도 이해하기 어렵다고함)
수퍼맨이 없어서 해결하지 못한 것일까요, 아니면 수퍼맨도 극복하지 못한 문제인 것일까요.
“도심 어항에는 민물고기가 사는거 아니야? 바다로 가면 어떻게해”
“그러게요 그래도 목표는 일단 바다로간다는 거니까”
또다른 조직으로부터 경험한 두번째 사례를 들어보겠습니다.
PRD를 작성해야 한다는 PM의 요구에 대해서, 경영진은 이렇게 대답했다고 합니다.
우리는 스타트업처럼 일해야해, 그러니까 개발자를 괴롭히는 시스템이나 프로세스를 만들지 말아야 해.
저는 이 말의 의미를 “코드가 아닌 전단계에서 너무 많은 시간을 소모하는 것”이라고 이해했습니다. 스타트업은 일단 닥치고 개발하는 거야라는 뿌리깊은 믿음, 개발자 중심의 회사에서 자주 보여지는 것 같습니다. 이 회사는 닥치고 개발한 제품이 큰 성공을 거두었습니다. 그리고 닥치고 개발한 그다음 제품들은 실패했습니다.
스타트업이란 닥치는대로 하다가 뭐 하나 성공하면 되는 그런 조직이라고 한다면 (어느 경우에 그러하였듯) 그것은 맞을 수도 있고 또 그렇지 않을 수도 있습니다. 닥치는대로 하다가 얻어걸리지 않는 훨씬 더 많은 경우에 그러하였듯이요.
Done is better than perfect.
많은 분들이 동의하시는 문구입니다. 그리고 스타트업 정신을 표현하는 문구로 받아들여지기도 합니다. 하지만 저는 이 말이 왜 ‘일단 닥치고 하는 것’으로 받아들여지는지 잘 모르겠습니다. 그리고 “방향”을 잡기 위한 형상화 작업들이 왜 이 문구에 대척점에 서있다고 간주되는지도 이해할 수 없습니다. 목표가 뭔지 잘 몰라도 무조건 한다는 것이 스타트업 정신일까요?
누군가 저에게 스타트업에게 가장 중요한 격언을 꼽으라고 한다면 저는 단연코 이것을 꼽을 것입니다.
“속도보다 방향이다”
스타트업의 부족한 여러가지 환경들은 오랜동안 기다려주지 못합니다. 그래서 절벽에서 뛰어내리면서 비행기를 조립하듯이 빠르게 해야할 필요가 있습니다. 하지만 비행기를 만들겠다는 목표, 그 비행기의 형상에 대해서는 생각을 하고 뛰어내려야죠. 우리가 MVP를 언급하면서 빠른 실행과 빠른 실패를 추구한다고 해서 실패가 미화되는 것은 아닙니다. 그저 우리가 시장을 충분히 잘 모르기 때문에 가장 싸게 실패해야만 다음 기회가 주어질 뿐이죠. 하지만 아무리 싸게 실패한다고 해도 그 기회가 무한정 주어지는 것은 아닙니다.
개인적으로는 별로 동의하거나 좋아하지 않는 비유입니다만 일단 드라이버 하나 들고 뛰어내리면서 뭘 만들어야 하는지 생각하는건 스타트업 정신이 아니라고 생각합니다.
어떠한 격언도, 금과옥조처럼 항상 옳을 수는 없습니다. 그저 그것들의 지향점을 공유하고 있을 뿐이지요. 저는 시스템을 신뢰하는 사람이지만 시스템이 만능이라고 생각하지는 않습니다. 시스템의 실패도 많은 지점에서 관찰되고 목격되고 있을 것입니다. 다만 저는 시스템은 상당히 가치중립적이라고 생각합니다. 그래서 시스템의 목적을 어디로 잡느냐에 따라서 많은 것들이 달라질 것이라고 생각합니다.
시스템을 최악을 예방하기 위한 방안으로 수립해보시기를 권해드립니다. 특히 제품개발에서 혼란에 빠져있는 조직이라면 수퍼맨의 개인기에 의존하시는 것보다 훨씬 더 안정적이고 기대할만할 것입니다. 수퍼맨은 컨디션이 들쭉날쭉하기도 하고 위기에 빠지기도 하고, 언젠가 어디로 가버릴지도 모르니까요.
** 이글에서 시스템과 제품개발프로세스가 혼용되었습니다. 같은 의미로 이해해주시기 바랍니다.
** 이 글에 영감을 주신 책입니다. 많이 구매해서 읽어주시기를^^ 아주 쉽게 슥슥 편안하게 잘 읽힙니다. 비행기를 타거나 휴가를 간다면 이 책을 꼭 가져가시기를 추천합니다.
