brunch

You can make anything
by writing

C.S.Lewis

by Shaun May 02. 2020

우리는 팀입니다.

"기획서에 잘 못된 사항 있으면 알려주세요."

"디자인 가이드는 어떻게 전달드리는 게 편하세요."

"그럼, 협의할 사항이 있으면 언제든지 편하게 요청 주세요!"





우리는 '협력'관계지 '경쟁'관계가 아니다.





기획자, 디자이너, 개발자.

기획자, 디자이너, 개발자 이 셋의 관계는 항상 바람 잘 날이 없다. 하지만 싸우면서 정든다고 하지 않았던가? 바람 잘 날 없는 관계에서 여러 프로젝트를 진행하다 보면 어느새 미운 정 고운 정든 사이가 되고 만다. 나는 일반화를 좋아하지 않는다. 예를 들어 사람은 모두 착하다와 모두 나쁘다는 너무 극단적이고 일반화하기 쉬운 오류다. 사람은 착한 사람도 있고 나쁜 사람도 있다. 기획자, 디자이너, 개발자 이 셋의 직군도 일을 잘하는 사람도 있고 못하는 사람도 있다. 그렇기 때문에 기획자는 '디자인과 개발을 고려한 기획을 원래 못한다.', '디자이너는 개발하기 수월하게 가이드 정리를 안 한다.', '개발자는 기획과 디자인 의도대로 개발을 잘 못한다.' 등과 같은 일반화의 오류를 담은 주장은 별로 좋아하지 않는다. 직군의 문제가 아닌 사람의 문제다. 바로 역량이 있는 사람과 없는 사람, 경험이 있는 사람과 없는 사람의 문제지 직군의 문제는 아니다. 기획자 중에 디자인과 개발을 고려하고 상세적인 기획을 잘하는 사람도 많다. 디자이너 중에도 개발 환경을 고려해 가이드 정리를 잘해서 넘겨주는 디자이너가 대부분이다. 개발자 중에도 기획의도와 디자인 콘셉트를 존중하고 구현하는 개발자들도 많다. 각각의 사람의 문제지 이것이 직군의 대립 문제처럼 얘기할 필요가 없다는 말이다.




협력과 경쟁을 혼동하는 조직.

소위 말해 상극이라는 관계가 있다. 이 관계의 사람들이 TF로 모이면 정말 바람 잘 날 없는 날이 매일 반복된다. 기획자, 디자이너, 개발자 이 셋의 직군은 서로 협력하는 관계다. 하지만 상극인 관계의 사람들과 TF가 되면 협력이 아닌 경쟁관계로 돌변한다. 바로 각 직군의 오류 찾기다. 디자이너는 기획자의 기획서를 보고 "기획이 잘못됐다." "왜 잘못했냐?" 개발자는 디자이너의 디자인을 보며 "이게 개발이 될 거 같냐?", "개발 가능성도 모르고 디자인하냐?", 또 기획자는 "이게 왜 개발이 안 되냐?", "이렇게 개발된 서비스가 있는데?", " 그럼 그건 뭐냐?", "그럼 그 서비스 개발한 개발자를 데려다가 개발해라." 등 프로젝트는 협력이란 기본적인 개념을 잊은 채 서로 주도권을 잡기 위해 경쟁에 돌입한다. 경쟁에서는 항상 승리자와 패배자가 있다. 기획이 승리하든, 디자인이 승리하든, 개발이 승리하든, 누가 승리하든 승리하게 되어 있다. 그렇게 승리한 직군은 자존심인지 자만심인지 모르는 것이 올라가지만 패배한 직군은 다시는 그 직군의 사람과 일하고 싶지 않다. 그렇게 승자와 패자가 존재하는 경쟁은 서로의 불신을 낳는다. 반면 협력은 서로의 경쟁이 아니기 때문에 그런 대참사가 결과로 나타나지 않는다.




신뢰가 없을 때 경쟁한다.

경쟁이라는 대참사가 생기는 이유는 신뢰가 없기 때문이다. 대부분 신뢰가 없는 이유는 서로 일해본 경험이 없기 때문이다. 서로 일하는 방식을 맞춰본 적이 없기 때문에 이 부분을 맞추는 데는 어느 정도 시간이 걸린다. 하지만 일하는 방식의 문제가 아닐 때도 있다. 바로 역량이 떨어지는 경우다. 그럴 경우는 시간이 지나도 신뢰가 생기지 않는다. 후자를 제외하고 전자의 경우를 예를 들면, 디자이너중에는 개발환경을 고려해 서로 협의하고 가이드를 작성하는 디자이너가 있다. 이런 디자이너는 개발 직군에서 신뢰가 생긴다. 그럼 기존에 말한 경쟁은 일어나지 않는다. 기획도 마찬가지다. 잘 기획된 기획서는 다른 조직의 경쟁을 불러오지 않는다. 결국 개인의 경험과 역량에 따른 것이지 직군의 고질적인 대립 관계가 아니라는 것이다. 기획자는 상세 기획이 끝나면 디자인과 개발 PM들을 불러 기획 리뷰를 한다. 보통 그렇게 한다. 그 자리에서는 디자인 PM은 기획 의도와 전략 등을 파악하고 디자인 후 개발에 가이드를 어떻게 전달할지 개발 PM과 협의한다. 그렇게 모든 것을 협의한다. 그런 협의 없이 개발에 넘어오는 디자인 가이드가 자신의 방식대로 넘어오지 않았다고 디자이너의 역량을 비하하고 험담하지 않는다. 이게 바로 또 다른 경쟁을 시작하는 바보짓이다. 내가 주니어 시절 가이드 작업을 할 때면 사수는 항상 나에게 당부했다. "네 맘대로 가이드 만들지 말고, 개발이랑 협의해서 가이드 만들어.", "개발자가 개발하기 편한 가이드가 좋은 가이드야." 그래서 항상 개발자와 협의 후 가이드를 만든다. 이런 협의가 없다면 '디자인 가이드가 개발하기 어렵다.'는 말이 나올만하다. 하지만 협의도 없이 당연히! 알아서! 본인이 편리한 개발 가이드를 요구한다면 또 다른 경쟁의 시작이다. 협의 없이 당신이 개발하기 편한걸 어떻게 안단 말인가. 또 디자인 콘셉트상 다수의 컬러, 폰트 및 효과 등이 적용될 수 있다. 이게 개발하기 편하지 않다고 말하기보다, 왜 그렇게 디자인이 되었는지 디자인 콘셉트 및 방향을 이해해 보는 것도 좋다. "개발하기 불편하면 그냥 빼세요."라고 했을 때, "그럼 디자인 콘셉트 무너지지 않으세요?"라며 구현해주는 개발자분들도 많이 봤다. 나는 그런 개발자를 신뢰한다. 기획, 디자인, 개발이 공장의 생산라인처럼 자신의 파트에 서서 단절된 채 찍어져 나온 것을 조립하는 방식이 아니지 않은가? 모든 문제는 협의하면 다 된다.




결국, 우리는 한배를 탔다.

기획자, 디자이너, 개발자 이 셋의 케미에 따라 서비스 및 제품의 완성도가 달라진다. 아무리 각 직군에 역량 좋은 사람들을 모아놔도 서로 협력하지 않으면 배는 산으로 간다. 한배를 탔을 때 배가 산으로 가지 않으려면 어떻게 해야 하는가? 바로 목표가 있어야 한다. 합의된 공동의 목표 말이다. 우리는 공동의 목표가 있을 때 서로 협력해서 항해하지만 목표가 없을 때 또는 각자의 목표가 다를 때는 경쟁하기 시작한다. 경쟁할 때 표류하기 마련이다. 어차피 우리는 한배를 탔다. 표류가 아닌 항해를 하기 위해서는 '협력하자.', '협의하자.', '존중하자.' 이 셋의 과정이 없이 서로를 탓하지 말자. 이 셋의 과정을 거치고도 경쟁을 한다면, 그건 조직 자체의 문제일 가능성이 크다. 그건 개인의 문제보다 조직의 문제다. 그런 조직이 있다. 기획이 왕인 조직, 디자인이 왕인 조직, 개발이 왕인 조직 그런 조직에서 왕족이 아니라면, 단호하게 떠나라! 같이 항해할 수 있는 곳으로!



매거진의 이전글 그날 기획자는 기획을 하지 않았다.

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari