ㅍㅍㅅㅅ

페이스북에서 개발자 A군이 “암 걸릴 것 같다…”며 한 동영상을 공유했습니다. ‘전문가(The Expert)’라는 제목의, 비유가 넘치는 짧은 코미디 필름이었죠. 내용은 프로그래머를 괴롭히는 제작 회의에 대한 것이었습니다.

개발에 대해 전혀 이해하지 못하고 있는 사람들이 프로그래머 입장에서는 말도 안 되는 불가능한 것들을 요구합니다. 그것이 왜 기술적으로 불가능한지 설명하려 들면, ‘가능하다고 말하셔야죠. 당신은 전문가잖아요.’라고 반복합니다. 거칠게 요약했는데도 벌써부터 혈압이 오르죠.

먼저 등장인물들을 보겠습니다.

이 영상에 나오는 캐릭터들은, 실제 직무에 따른 사람들의 스타일을 뭐랄까, 잘 유형화했다고나 할까요. 저 역시 여러 입장에서 이러한 회의를 해오면서 나름 깨닫는 게 있었습니다. 

그 경험을 바탕으로, 각 유형별 캐릭터들의 서브 텍스트를 구성해볼까 합니다. 이런 일은 배우들이 많이 하는 거죠. 이 사람이 이런 말을 왜 하는지, 시나리오엔 설명되지 않는 캐릭터들의 배경, 역사, 성격 등을 분석하고 스스로 이해하려는 작업입니다. 

1. 시나리오 분석

먼저 전체 영상의 스토리를 정리하면서 제가 꼽는 깨알 포인트도 뽑았습니다.

이제 본격적으로 각 캐릭터들의 서브 텍스트를 구성해보도록 합시다. 즉, 이 코미디 필름에 나온 캐릭터들을 예로 들어 직무별로 알기 쉽게 유형화하는 거죠. 이 작업은 영상의 본래 의도와는 상관없이 제가 재미로 2차 해석하는 것이니 단정하는 말투를 쓰더라도 이해해주세요.

2. 당신이 제일 싫어하는 상사는 어떤 유형?

이 기획자는 자신이 요구하는 최종적인 결과물이 어떻게 될 것인지를 전혀 추측하지 못합니다. 구현 방법을 아예 모르기 때문이겠지요.

또한 용어를 엄정하게 쓰지 않습니다. 빨간 선, 투명 잉크, 직교라는 단어를 사용하고 있지만, 그 정의를 확실히 알고 있지 않습니다. 이공계 쪽에서 사용하는 언어의 방식을 잘 모르다 보니, 불가능하다는 의미로 말한 것들도 ‘절대로 불가능하다고는 안 했으니까 가능하다고 말하는 거구나’라고 저 좋을 대로 이해하기도 해요.

만약 ‘가능성이 0.001%입니다’라고 한다면, 이쪽은 당연히 불가능하다는 의미로 받아들이는 데 반해, 저쪽은 약간의 가능성이 있다는 거라고 생각할 수도 있다는 겁니다. 과학 쪽에선 어떤 일이든 절대 0%나 절대 100%라고 말하는 법 자체가 거의 없다는 걸 모르는 거죠.

더 나쁜 건, 자신이 이미 다 알고 있다고 믿는 겁니다. 결과물의 형태라던가, 자신이 말하고 있는 용어들이 무엇을 의미하는지를 실제로는 모르면서 분명하게 이해하고 있다고 여기는 겁니다. 자기가 추측하지 못하고 있는 미씽 링크가 발견되어도, 그건 구현하는 사람들이 알아서 그려 넣으면서 완성되는 거라고 편리하게 생각하죠.

또한 이런 면이 머릿속으로 추상적으로 추측하는 일을 많이 해야 하는 기획자들이 갖기 쉬운 태도이기도 합니다. 이들은 여러 방면으로 잡학다식 하고, 눈치도 빨라요. 그래서 투명이 뭔지, 빨간 선이 뭔지는 이해하고 있죠. 그걸로 다 알았다고 믿습니다. 하지만 투명한 잉크로 빨간 선을 그리는 게 불가능하단 건 몰라요. 이런 건 말하자면 해 봐야만 아는 종류의 지식에 해당하는 거니까요.

이런 사람들은 자기가 모르고 있다는 것을 추호도 의심하지 않기 때문에, 오히려 상대방이 자신의 말을 이해하지 못하고 있다고 단정하곤 합니다. 그래서, 종종 답답하다는 듯이 ‘투명하다는 게 뭔지 알 테죠?’ 라던가, ‘직교의 의미는 아실 텐데요?’ 하고 되묻는 거죠.

이 경영자 역시 실무를 전혀 모릅니다. 실무를 모르는 상태에서, ‘파란 잉크로 그리면 어때?’라는 등의 뻘 대안을 내놓거나, 현 상황에서 중요하지도 않은 부분을 문제점이랍시고 ‘왜 선들이 파란색이지?’ 혼자 발견해서 지적하죠. 그걸 고치면 마치 모든 문제를 해결할 거라 생각하면서요. 본인이 유효한 대안을 내놓고 유효한 실수를 발견해낼 줄 아는 유능한 사람이라고 스스로 만족해하기도 합니다. 영상에서처럼 ‘빨간 걸로 그리면 7개의 선이 동시에 직교가 가능할 거야.’ 라고 하는 식인 겁니다.

회사를 다녀보신 분들은 이미 충분히 아시겠지만, 대부분의 시간과 에너지는 저런 식으로 회의 중간중간 뻘소리 하는 임원급들의 자존심을 건드리지 않고 ‘아주 좋은 아이디어이긴 하지만 아마도 이 상황에선 크게 도움이 안 될 겁니다’ 등으로 말을 최대한 돌려하는데 쓰이곤 하죠.

예컨대 ‘왜 마찰력을 영구히 없애 버릴 수 없다는 건가?’ 등의 예상치 못한 뻘 질문을 해대도 당황하거나 ‘신한테 물어봐라, 이 양반아!’ 라고 말하는 대신, 차근차근 물리 법칙을 설명할 정신적 여유를 배양해야 한다는 겁니다. 그리고 옆에 있던 상사가 ‘물리 법칙 따윈 잊어버리라고. 기존 방식을 고수하려고만 하는 답답한 공돌이야.’ 라고 말해도 참는 인내심도요.

역시 임원들이 갖는 나쁜 습관 중에 하나라고 생각합니다만, 가장 좋지 않은 건 일을 쓸데없이 단순하게 생각하는 겁니다. 이들이 단순화시키는 스케일은 정말이지 엄청나요. ‘겨우 빨간 선 7개일 뿐이잖아!’ ‘겨우 선 몇 개 찍찍 긋는 게 왜 이렇게 오래 걸려?’, ‘겨우 A4 반쪽짜리 시놉시스가 왜 이렇게 비싸?’, ‘이런 건 그냥 컴퓨터로 찍 하면 되는 거잖아?’, ‘애 젖 먹이면서 주방에 앉아서 진생 쿠키 좀 구워서 구글에 올리면 전 세계에서 주문 들어오는 거잖아?’ 뭐 이런 식인 거죠.

이 임원이 마지막에 회의를 끝내면서 한 말 역시 깨알 같아요. ‘자, 출장 가서 풍선을 만들도록 하게.’ 이들의 본 목적은 빨간 선이었어요. 풍선은 마지막에 추가된 부록 같은 거였지요. 하지만 이 사람은 전체적인 이해를 못 하고 막판에 등장한 풍선을 중심으로 요약해 버리는 겁니다.

이 사람은 기본적으로 경영자이고, 이 프로젝트를 반드시 수주해야 하기 때문에, 실무자들이 시시한 잔소리를 늘어놓지 않고 그저 ‘예, 다 가능합니다!’라고 시원하게 말해주기만을 바랍니다.

PM이란 프로젝트 전체를 진행 관리합니다. 스케줄을 관리하고, 컨택 포인트를 담당하며, 여러 비상 상황을 처리하고 많은 실무진들을 컨트롤해야 합니다. 온갖 종류의 잡무가 넘쳐나기 때문에 골치가 썩어나죠. 낯을 가리거나 시도 때도 없이 오는 전화를 받기 힘들어한다면, 아주 어려운 임무라고 할 수 있죠. 하지만 이 PM은 그럴 걱정은 없어 보입니다. 이 PM은 열정 중독자처럼 보이거든요. 모든 순간에 ‘전문가잖아!’를 마법의 주문처럼 쓰죠.

‘섣불리 불가능하다고 생각하지 마. 해보기도 전에 어떻게 안 된다는 걸 알아? 일단 해 봐야지. 되든 안 되는 해 보는 거야. 어떻게든 해내야 하는 거야. 자넨 전문가잖아. 의지만 있으면 다 돼. 파이팅! 이런 스타일이지요.

이런 타입의 사람들은 실무자들의 의견을 그냥 불평이라고 치부해버리기 일쑤입니다. ‘불평은 바보라도 할 수 있어. 불평만 하지 말고 해결책을 제시해 봐.’ 이렇게 말해서 의견을 말하는 실무자들의 복장을 푸콰칵 지릅니다. 더 열 받는 건 외부 사람들 앞에서 자기 부하 직원들을 마치 자기계발서에 나올 법한 오글거리는 문구로 충고하고 야단치는 것에도 거리낌이 없다는 거죠. 진지하게 문제점을 제시하는 부하 직원을 툭하면 웃음거리로 만들어서 사람들 앞에서 자신의 유능함과 열성과 여유로움을 뽐내기 일쑤고요.

‘불가능하다니 ㅋㅋㅋ’ 라는 농담 자체가 무척 비열하고 전략적이지 않나요? 기술적으로 불가능하다는 건데 멘탈 문제로 바꿔버렸잖아요. 비록 의식하고 있지는 않다 해도 결국 부하 직원을 이용해 자신의 호감도를 올리는 꼴이죠.

그 와중에 회의록은 또 꼬박꼬박 잘 기록해요. 이런 양반은 열심히 하는 타입이거든. 문맥도 모르고 무조건 열심히 기록하죠. 왜 문맥을 모르죠? 개발을 모르니까! 나중에 전혀 다른 상황에서 또 그걸 들이밀어 왜 니가 했던 말을 번복하냔 식이에요. 그리고 그게 또 상사의 눈에 든다? ㅋㅋㅋ 열성적이고 여유 넘치면서 유머 감각도 있고 일도 확실히 한다는 인상을 주거든. ㅋㅋㅋ

이런 사람들은 ‘전문가’가 뭐든지 다 해결해줄 수 있는 것이라고 생각합니다. 실은 전문가는, 뭐가 되고 뭐가 안 되는지 아는 사람에 가까운데 말이지요. 이런 타입이 PM이 됐을 때의 가장 문제는, 자기 실무자들을 보호해주지 않는다는 것에 있습니다. 실무를 잘 알고 있으면 어떤 요구는 불합리하고, 어떤 변경 요청은 생떼라는 걸 알고 있겠죠. 그래서 요청 사항을 자기가 다 들어보고, 개발자에게 전달되기 전에 적당히 자기 선에서 걸러줘야 하죠.

그런데 무조건 ‘자넨 전문가니까 모든 걸 다 할 줄 알아야 해’라는 식이네요. 이런 사람이 PM이면 애도를 표합니다. 공은 자기가 먹고 마음 고생은 일명 전문가인 님이 합니다. 그리고 격려랍시고 어깨 두들겨주고 술 사주고 하는 걸로 해결하려고 하는 것까지 민폐죠.

이런 사람의 특징은 파이프라인을 무시한다는 겁니다. 개인적인 일에서는 상관없지만, 팀 작업에서는 아주 환장하죠. 기획 단계에서는 몇 번이고 결정사항을 번복해도 됩니다. 뒷단계에서 번복하지 않도록 미리 온갖 지뢰를 다 밟아보는 거니까요. 물론 어떤 단계든, 이것저것 시도해보고 번복하고 할 수 있는 범위라는 것이 있지만 말이에요.

예를 들어 버튼의 위치를 수정한다고 칩시다. 기획 단계에서 수정해야 한다면 ‘버튼을 우측 상단으로 옮긴다’라고 텍스트 정도를 적어넣으면 됩니다. 디자인 단계에서는 버튼을 우측 상단에 옮겨보고, 그래서 어색해진 레이아웃들을 다시 잡아서 최적화하고, 옮겼더니 배경이랑 색이 안 맞아서 색감도 따로 수정하는 등의 수정 작업을 해야 할 수 있겠죠. 그런데 프로그래밍 단계라면? 그것도 제스처 인터페이스라도 다 구현해 놓은 상태라면? 오 마이 갓.

이런 타입의 디자이너는 결국 기획자가 되면 고쳐질 문제긴 합니다. 또는 이 디자이너가 갑이 아니라 프로그래머의 요구 사항을 받는 디자이너라면 또 얘기가 다르겠죠. 여튼 이 사람의 문제는 회의 중에 즉흥적으로 아이디어를 꺼낸다는 겁니다.

회의가 다 끝날 때쯤 중요하지 않다는 듯이 ‘아 참, 이것도 해 주세요’ ‘아 참 저건 가능한가요?’ 합니다. 마치 큰 작업의 부산물인 것처럼 말하지만 실제론 거의 새로운 프로젝트 하나를 더 하는 수준의 일인 경우도 많아요. 

그런 무시무시한 일을 마치 오늘 날씨 참 좋죠? 하듯이 ‘아참, 이것도 하나만 해 주세요’ 하는 겁니다. 해야 할 걸 처음부터 리스트로 정리해서 주란 말이야! 애초에 발주서에 그런 디테일한 사항까지 적혀 있다면 수주하지 않았을 텐데, 싶은 것들이 천지예요.

심지어 컨택포인트를 통하지 않고 직접 구현자에게 ‘그건 이렇게 수정해주시면 안 돼요?’ 하고 요청하기까지 해요. PM이 커트해줘야 하는데 직접 개발자한테 다이렉트로 요청하는 거예요. 큰 문제죠. 아참, 그런데 이 회사의 PM은 무조건 열정으로 다 할 수 있다고 믿는 사람이었죠? 어차피 망했네요.

다만 개발자의 말을 혼자서라도 알아들어 보려고 하는 태도(직교성!)는 좋았어요. 이해는 실무자들에서부터 이루어지곤 하죠.

3. 왜 이런 상황이 벌어지는가?

이 영상은 개발자의 입장에서 보고 들리는 말들이 얼마나 답답한지 알려주기 위해 지나치게 단순화한 비유를 사용한 겁니다. 실제로 일들은 더욱 복잡합니다. 그래서 저는 현실에 가까운 예로 재비유를 해보겠습니다.

A. 더 다양한 각도에서 이유를 물어봐야 한다.

빨간 선을 초록 잉크로 그려달라는 것을 예를 들자면, 어떤 콘텐츠를 특정 툴로 만들어 달라고 요구하는 상황이라고 볼 수도 있겠습니다. 그저 아주 비효율적인 수준일 때도 있고, 시장 판단을 못 한 수준일 때도 있고, 경우에 따라 완전 어이없는 수준일 때도 있죠.

게임을 엑셀로 만들어 달라고 한다거나(…) 그런데 그게 나름대로 자기들도 다 시장 조사해서 말하는 거다? 엑셀 사용자 관련 통계수치 잔뜩 내밀고 말이죠. 게다가 개발자들더러 ‘당신이 선호하는 툴만 써선 안 된다’고 훈계하는 경우도 있어요. ㅋㅋㅋㅋㅋ 어디서 또 개발자들끼리 서로 주고받는 얘기들, 들은 건 또 있으니까 자기도 안다 이거예요. 막 던지는 거죠.

여기서 무작정 수치 근거 없이 주장하는 것만큼이나 조심해야 한다고 생각하는 게, 맥락 없이 숫자만 잔뜩 내밀고선 득의만연하는 겁니다. 공정하고 바른 방법으로 바른 자료를 적당한 양만큼 분석했다는 근거가 없다면, 요즘의 복잡한 사안들에 대해선 그저 수치가 있다는 것만으로 이겼다고 하기도 힘들어요. 그냥 ‘코피 먼저 나면 짐’ 수준의 룰이랄까. 만약 상대방이 수치를 잔뜩 들고 와서 바르려고 하면, 그 수치부터 의심하세요. 수치 자체는 틀리지 않았다고 해도, 그 맥락을 제대로 이해하지 않는다면, 정 반대 주장의 근거로 이용될 수도 있어요.

여튼 이럴 땐 물어봐야 합니다. ‘그걸 꼭 써야 하는 이유라도 있으세요?’ 그래야 대안을 찾기도, 설득하기도 더 쉬워집니다. 영상에선 아쉽게도 왜 초록색 잉크를 써야 하는지, 왜 직교해야 하는지 아무도 물어보질 않네요.

B. 데모를 볼 줄 아는 것도 능력이다.

영상에서 개발자는 데모라도 보여줄 심산으로, 급하게 파란 펜으로 그려가며 선들이 직교하지 않는다는 걸 증명하려고 하죠. 하지만 사람들은 거기서도 보라는 건 안 보고, 색깔이나 보고 앉았습니다. ‘저건 왜 파란색이지?’ ‘방금 저도 그 말 하려고 했습니다.‘ 하고요.

저도 최종 결과물이 이런 느낌이다란 걸 보여주기 위해 데모를 보여주곤 했는데, 대체로 상황을 악화시켰습니다. 그들은 데모에 나온 온갖 쓸데없는 것들을 다 지적해요. 아직 개발 안 된 부분, 임시로 만들어 넣은 부분, 모든 것을 지적하죠. 보지 말란 건 다 보고 있어요.

정말 환장해요. 데모 단계에서 체크해야 할 것이 정확하게 뭔지 몰라요. 개발 파이프라인을 모르니까, 현재 어디까지 진행된 상황이구나, 보라는 건 이런 거구나, 이 부분은 그냥 임시 블랭크구나, 자체를 짐작하지 못하거든요. 와, 쓰면서도 열이 받아요.

그래서 쓸데없는 걸 보고 화가 난 갑이, 분노 및 초조함을 터뜨리면서 이따위 것이 출시될 작정이었냐며 닦달하기 때문에 회의가 길어지곤 하는 건 다반사죠. 덕분에 데모를 보여주고 결정해 달라고 할 심산이었던 모든 사항이 하나도 결정되지 않아요. 데모를 보여주는 바람에 기획이 엎어지기도 하거든요. ㅋㅋㅋㅋㅋ

저는 카메라 연출을 위해 그려진 콘티를 가지고, 콘티 속 건물들 그림이 역사적 고증에 맞지 않는다고 한 시간을 트집 잡는 갑 때문에 진짜로 넋이 나간 적도 있어요. 어떨 땐 너무 많은 정보가 이해를 방해합니다. 그들은 모든 것에서 혼란스러워하니까요. 그래서 영상에서도 데모를 본 경영자(을)가 말하죠. ‘자네가 모두를 헷갈리게 하고 있어!’ 라고요. 

데모를 볼 줄 아는 것도 능력이에요. 상대가 요구하지 않았으면 일부러 보여줄 필요 없어요. 데모는 볼 줄 아는 사람들에게만, 볼 준비가 된 사람들에게만 보여주도록 해야 합니다.

C. 일반인들은 개발 용어에 관심이 없다.

개발자는 개발 용어에 최적화되어 있는 사람입니다. 하지만 나머지 사람들은 개발 용어를 잘 모르고 개발 용어를 쓴다고 해도 자연어처럼 유추해서 비슷한 의미를 다 포함해서 광의하게 사용하기도 합니다. 완전히 오해해서 쓰기도 하고요. 자연어 중에서 개발 용어랑 똑같은데 뜻이 다른 게 있다면 그야말로 오해의 대재앙이 일어나기도 하죠.

영상에서 오래 논쟁을 하게 된 원인인 ‘직교성’을 예로 들어봅시다. 기획자는 직교라는 의미를, ‘선과 선끼리 만나는 상태’ 정도로 오해하고 있었을 가능성이 높습니다. 그러니까 삼각형을 그려놓고 세 선을 직교하게 했다고 말하는 거죠. 그걸 누군가가 빨리 캐치하고, 개발자에게 ‘자네가 생각하는 직교가 아니라, 선끼리 만나기만 하면 된다는 뜻이야’라고 말해줘야 했습니다. (실제론 7개의 선이 동시에 직교하려면 7차원이어야만 하죠.)

4. 개발자를 빼고 나머지 넷은 정말 다 멍청이인가?

사실 저는 그렇게 생각하지 않습니다.

기획자(갑)는, 구현하는 방법 자체는 잘 모르고 지시하고 있기는 하지만 그것 자체가 큰 문제는 아닙니다. 그 사람의 영역이 아닌 걸요. 게다가 사업 기획상, 여러 시장 조사, 여러 조건 분석들이 그런 결론을 내리도록 가리키고 있었다면? 좋은 점은 이 사람이 회의 자리에서 바로 제시한 해결책을 수락하거나 거절할 정도의 파워를 갖고 있다는 겁니다. 회의에 그 정도로 결정 권한이 있는 사람이 들어와 있는 것도 기회예요. 이때 최대한 여러 각도에서 많은 걸 물어서 해결책을 제시하고 결정을 얻어내야 합니다. 이 사람이 용어를 좀 틀리게 쓰고 있다는 것도 이쪽에서 빨리 캐치해서, 바른 용어로 번역해서 이해할 수 있었더라면 더 좋았겠죠.

경영자(을)의 경우, 경영일이 너무 바쁘기 때문에 실무를 모를 수 있다고 봅니다. 저렇게 뻘소리를 하는 것이 매번 복장을 북북 지르기는 하지만, 그래도 이 미팅 자체를 성사시킨 것만으로도 제 할 일을 다 한 겁니다.

디자이너(갑)는 앞으로 계속 같이 마주칠 실무자로 보여요. 이 사람이 파이프라인을 무시하는 것은 당장 교정하기 힘들겠지만, 거듭 이해시키고 쉬운 말로 지시하면 이해시킬 수 있다고 봅니다. 수정해야 할 모든 리스트는 수요일까지 문서로 정리해서 주세요. 등등으로요.

제가 생각하기에, 여기서 문제 있는 사람을 고르라면 PM을 고르겠습니다. 여러 각도로 질문하고, 일반인과 개발자의 언어를 서로가 알기 쉽게 번역해주고, 추가적으로 계속되는 요구들을 커트해야 하는 모든 일들은 실은 PM이 해야 했던 거예요. 실무자들이 자기 일에 온 시간과 정성을 쏟을 수 있도록, PM이 그 중간 다리 역할을 해줬어야 했던 거죠. 그런데 영상에서 보여준 모습은 그저 자기 실무진을 억압하는 모습밖에 없어요. 그런 주제에 마지막에 ‘수고해’란 듯이 어깨 툭툭 치는 것도 빡쳐요. 정말이지 이 회의에서 가장 쓸모가 없어 보이네요. 회의록 하나 열심히 작성한 것 빼고 말이죠.

5. 소름 끼치는 반전(?)

이 영상에서처럼, 홀로 명징 타당한 개발자를 분통 터지게 하는 일은 아주 흔합니다만, 그 반대의 경우도 물론 존재합니다. 이들의 말 중에 다음과 같은 키워드가 있어요.

이 영상에서처럼 개발자가 홀로 옳은 상황이라면, 이 말은 개발자를 빡치게 하는 가장 좋은 버튼이 되겠죠. 하지만 때로는 저 말을 정말 해주고 싶은 개발자가 있는 것도 사실입니다. 게다가 이들은 자기들이 쓰는 용어는 엄정하게 써야 한다고 하면서, 디자이너들이나 기획자가 쓰는 용어의 차이는 크게 신경 쓰지 않기도 해요. 그저 고양이와 야옹이의 차이로 치부해버리는 겁니다. (영상에서는 근본적인 문제를 이해하지 못했다는 사례로 사용된 거지만요.)

이런 식도 많다는 겁니다. 점선 실선, 중요하죠. 어마무지하게 중요합니다. 개발자들이 자신의 영역을 좀 이해하고 기획하라고 투덜거리는 것만큼이나 디자이너나 기획자들도 마찬가지란 걸 이해해야 합니다. 그들도 그렇게 결정해야만 할 외부적 내부적 필연적 사정이란 게 밤하늘의 별 만큼이나 있다는 걸요.

저는 디자이너 출신의 기획자였어요. 시나리오를 직접 개발하기도 하고 종종 PM을 겸하기도 했었죠. PM일 때는 실무자들을 쉴드치는 일이 제일 힘들었습니다. 이 영상에선 개발자 스스로 나서지만, 저희 프로젝트들은 개발자를 전면에 내세우지 않았기 때문에 외부 회의 같은 데선 제가 그들의 입장을 대변해야 했거든요. 그래서 저 영상이 말하고자 하는 답답함을 어느 정도 이해하고 있어요. 제가 외부에 나가서 갑들을 제대로 이해시키고 오지 못하면, 내부의 실무자들 모두에게서 엄청난 원망을 사게 되곤 했죠. 그것도 정말 죽어나는 일이었습니다.

그런데 PM일 때뿐 아니라, 디자인할 때는 디자이너로서, 시나리오 쓸 때는 작가로서, 기획일 할 때는 기획자로서의 고충이 다 있었습니다. 어떤 일 하나만이 유독 답답한 건 아니었어요. 어떤 일을 해도 남들이 이 분야를 정말 몰라도 너무 몰라서 속 터지기 이를 데가 없는 거예요. 안 된다는데 무조건 하라고 하거나, 결국 그게 그거 아니냐며 얕잡아 보거나, 전문가라면 모두를 만족시켜야 하는 거 아니냐고 하거나.

자기 세계에서 한 발자국만 나가면, 모든 연령이 좋아할 만한 글을 써야 실력 있는 작가 아니냐는 말 같은 걸 아무렇지도 않게 하는 멍청이들(이라 부르지만 실제론 다른 분야의 전문가들) 세상이 펼쳐진다고요. 저 역시 제가 전혀 모르는 분야, 예를 들어 교육이라던가 무용이라던가 어학이라던가 고대 아시아 역사라던가 하는 쪽과 함께 컨소를 한 적이 있었는데 그땐 제가 남부럽지 않게 말귀 못 알아듣는 멍청함 1위를 달렸죠.

결국 저 개발자가 홀로 명징 타당한 상태서 느끼는 답답함의 세계는 모든 직무에서 그들만의 버전으로 존재한다는 겁니다. 그럴 수밖에 없죠. 각자의 전공은 아주 깊고 광범위해요. 서로가 남의 분야를 자세히 알 수가 없어요. 결국 이들 사이의 번역자가 중요한 겁니다.

그런 의미에서, 저는 다시 PM을 지적하면서 이 글을 끝내겠습니다. 임마, 아래만 쪼지 말고 실무를 좀 배워.

원문: Media Fish