기획자, 개발자 그리고 디자이너
내가 재직한 에이전시는 기획조직과 디자인조직이 각각 독립적으로 운영되었다. 그때 기획자와 디자이너는 애증의 관계였다. 제안 작업은 기획수장의 진두지휘로 선행단에서 제안목표와 전략을 기획하며 시작이다. 그리고 제안 전략을 반영해 상세화면 기획안을 설계한다. 화면 기획안 설계를 완료하면 디자인, 기획, 개발 조직 수장과 제안 프로젝트 TF(task force) 인원이 모두 모여 기획 리뷰를 진행한다. 제안 내용은 실제로 구축 가능해야 하기 때문에 개발 스펙 확인을 위해 개발 조직도 이 자리에 참여한다. 리뷰를 하고 개발 스펙에 이견이 없으면 개발 조직은 먼저 자리에서 일어나곤 했다. 그러면 이제 기획과 디자인 담당자가 세부 논의를 할 시간이다.
기획자, 개발자
그리고 디자이너의 조직문화
프로젝트 제안에서 기획자와 디자이너
디자이너가 기획자의 기획의도를 이해하지 못하거나 기획이 탄탄하지 못할 때 해법을 논의하기 시작한다. 논의는 간혹 논쟁으로 번지기도 한다. 이때 기획 내용이 모호하고 핵심이 없다면 직설적으로 얘기한다. 기획자에게는 상처가 될 수 있지만 그래야 잘못된 기획에서 일찌감치 미련을 버리고 새로운 아이디어를 고민해 제안 전략의 완성도가 올라간다. 반대로 기획자도 디자인 시안이 임팩트가 없고 기획 전략을 제대로 담지 못하면 “디자인 시안 퀄리티가 떨어진다”라고 얘기했다. 그래야 수정을 거치며 완성도를 높일 수 있다. 그렇게 서로 거리낌 없이 의사소통하며 제안시안을 발전시켰다. 직설적인 의사소통의 장점은 기획 전략이든 디자인 시안이든 상대가 괜찮다고 하면 정말 괜찮은 거였다. 서로 악의를 가지고 유치한 비난은 하지 않았다. 작업 퀄리티에 대해서는 서로 솔직했다.
상대에 대한 배려가 부족한 의사소통이 아니냐고 생각할 수도 있겠지만, 배려한다며 에둘러 애매한 표현을 주고받다가는 오히려 완성도를 깎아 먹는다. 예전에 라디오에서 이런 이야기를 들은 적이 있다. “좋아하는 연예인이나 취미 등을 비난하면 기분 나쁜 이유가 무엇일까요?”라는 질문에 전문가 한 명이 이런 답을 내놨다. “자아가 확장되었기 때문입니다.” 내가 좋아하는 영역까지 자아가 확장됐는데 이를 비난하면 나에 대한 비난으로 느낀다는 뜻이다. 이 말을 듣고 바로 공감했다.
내가 작업한 디자인 시안이 완성도가 낮다고 하면 꼭 나를 비난하는 기분이었다. 또 아이데이션을 진행할 때 내 아이디어가 별로라고 하면 기분이 그다지 좋지 않았다. 누구나 그런 경험이 있으리라 생각한다. 하지만 이는 작업한 시안과 제안한 아이디어로 내 자아가 확장되어 마치 그것을 비판하면 나를 비판한다는 착각에 빠지기 때문이다. 완성도가 떨어지는 존재는 디자인 시안이지 나 자신이 아니다. 아이디어가 별로이지 내가 별로인 것이 아니다. 디자인 완성도는 고민과 수정을 통해 끌어올리면 된다. 아이디어도 다시 고민하면 된다. 조 직에 우리가 모인 이유는 완성도 있는 결과물을 만들기 위해서라는 사실을 이해하고 이를 위해 각자의 위치에서 노력하고 있음을 인정한다면 앞에서 말한 상처에서 조금은 자유로워질 수 있으리라 생각한다.
자아를 분리하자. 내가 작업한 디자인과 내가 제안한 아이디어는 내가 아니다. 우리에게는 항상 제안 프레젠테이션을 준비할 시간이 부족했고 제안 전략, 디자인 시안의 퀄리티가 훌륭해야 디자인을 팔 수 있었다. 그렇기 위해 그 시절 우리는 서로의 작업에 솔직했다. 아니, 솔직해야만 했다.
프로젝트 구축에서 개발자와 디자이너
제안이 선택되어 프로젝트를 수주하면 실제 구축 작업을 진행하는데 이때 다시 상세 기획에 들어간다. 수주 전에는 내용이 매우 제한적인 제안 요청서를 기반으로 기획과 디자인을 진행한다. 상세 비즈니스 내용까지 모두 오픈하는 시점은 수주 이후라 실제 정보에 맞춰 다시 상세 기획을 한다. 제안 내용으로 구축을 진행하는 때도 있지만 매우 드물었다. 기획자는 클라이언트와 상세한 요건 정의부터 시작해 새로이 기획을 진행한다. 기획을 완료하면 디자인 시안도 다시 잡는데 이때부터는 기획자와 디자이너가 한 팀이 되어 클라이언트에게 기획 전략과 디자인 시안을 설득한다. 시안 컨펌 완료 이후에는 수월하다. 디자인 가이드대로 하나씩 디자인을 진행하면 된다. 기획자와 디자이너 사이에도 긴장감이 줄어든다.
디자인이 어느 정도 마무리되면 드디어 개발자가 등판한다. 제안작업에서는 개발자들이 할 일이 별로 없다. 제안은 프로토타입 단계라 개발까지 적용해 클라이언트에게 보여주지는 않는다. 하지만 제안을 수주하고 실제 구축 단계에 접어들면 개발자가 역량을 발휘해야 한다. 기획전략과 디자인시안이 원활히 작동하도록 프로그램으로 구현하는 작업이 필요하다. 이 시기에 기획자와 디자이너는 더 긴밀하게 소통한다. 클라이언트가 원하는 방향, 기획의도, 디자인의도에 맞춰 개발이 진행되고 있는지 계속 확인해야 한다.
디자인처럼 개발 영역도 세분화되어 있다. 먼저 실제 사용 자가 보는 화면을 개발하는 분야가 있다. 사용자 화면의 움직임을 UI 시나리오에 따라 제대로 작동하도록 개발한다. 시각적인 디자인을 소스코드를 이용해 데이터로 만들어 어떤 환경에서든 사용자 화면이 디자인 화면과 동일하도록 개발한다고 생각하면 된다. 그리고 데이터 입출력을 통해 비즈니스 로직을 개발하는 개발자도 있다. 사용자가 요청하는 정보를 서버를 통해 사용자 화면에 전달해 주고 사용자가 입력한 정보를 다시 서버로 전달하도록 로직을 설계하고 개발한다. 주로 디자이너가 소통하는 개발자는 사용자 화면을 개발하는 UI 개발자다. 그리고 기획자가 소통하는 개발자는 비즈니스 로직 개발자다. 디자이너는 개발 후 화면에 문제가 없는지 확인하고 개발자에게 피드백을 준다. 디자이너 의도대로 개발이 되어 있지 않으면 기획자와 상의해서 수정해 달라고 개발자에게 얘기한다. 앞에서 말했지만 그래야 완성도가 올라간다. 그리고 기획자는 클라이언트가 원하는 비즈니스 방향대로 프로그램 로직이 오류 없이 개발됐는지를 확인한다.
디자이너가 선호하는 개발자는 디자인대로 오차 없이 개발해 주는 개발자다. 어떤 개발자는 UI 화면개발이 끝나면 디자인 시안을 캡처해 자신이 개발한 화면에 오버랩해서 오차를 확인하는 개발자도 있었다. 디자이너들 사이에서는 최고의 UI 개발자였다. 한편 디자이너가 사용하고 싶은 기능을 설명하기 위해 다른 서비스를 찾아 그것과 같은 기능을 구현해 달라고 요청했을 때 “그럼 그 서비스를 만든 개발자를 데려다 해라!”라고 말하는 개발자도 있었다. 나중에 그분에게 그렇게 말 한 이유를 들었다. 디자이너들이 프로그램상 최고 잘된 다른 서비스를 보고 그대로 해달라고 너무 쉽게 말하는 태도가 얄미워서 그랬다고 했다. 기획자가 해외 어워드에서 수상한 디자인을 보여주며 이렇게 수상할 정도의 디자인을 해달라고 하면 같은 기분이기에 그의 마음이 충분히 이해가 갔다.
좋은 기능과 디자인을 논하기 전에 서로 목표가 일치하는지 점검하는 일이 중요하다는 사실을 깨달았다. 좋은 기능을 구현하려면 공동의 목표를 위해 그 기능이 왜 필요한지 먼저 공유하고 공감해야 한다. 그렇게 기획자와 디자이너 그리고 개 발자는 대립하기도 하고 어떨 때는 또 한 팀이 되기도 한다. 당시 기획, 디자인, 개발로 조직을 구분 짓는 것이 전문성을 위한 구별이라 생각했지만 프로젝트를 위해, 공동의 목표를 위해 좀 더 효율적인 조직 구조와 문화를 만들려고 고민하기 시작했다.
조직 구조가 팀워크에 영향을 미칠까?
당시 조직을 직군으로 분류하는 방법은 전문성을 고려한 결정이었다. 한편으로는 기획자, 디자이너, 개발자가 프로젝트 중심으로 더 긴밀하게 소통하기를 회사는 원했다. 그래서 대규모 조직 개편을 단행했다. 직군 중심이 아닌 프로젝트 중심으로 조직을 구성하기로 했다. 즉 기획자, 디자이너, 개발자를 섞어서 팀으로 묶었다. 초반에는 한 팀이 된 세 직군 간 어색함이 감돌았지만 기획 단계부터 세 직군이 같이 고민하며 변화가 시작됐다.
직군별로 조직을 구성했을 때는 하나의 프로젝트를 진행하더라도 기획은 기획자의 일, 디자인은 디자이너의 일, 개발은 개발자의 일이라 구분해 서로의 일에 신경 쓰지 않았다. 예를 들어 프로젝트 초반에 기획이 잘 풀리지 않아도 그건 기획자의 일이니 기획자가 알아서 해야 한다고 다른 직군은 한발 빠지는 분위기였다. 조직을 개편하고는 같은 상황에서 디자이너, 개발자도 초반 기획에 참여해 같이 고민하게 됐다. 한마디로 기획은 기획자의 일에서 우리의 일로 관점을 바꾸는 시도였다. 디자이너나 개발자가 난관에 부딪치면 마찬가지로 함께 모여 상의하는 분위기가 생겨났다.
지금은 이런 구조를 가진 조직을 흔히 볼 수 있지만 당시 대형 에이전시로는 꽤 과감한 시도였다. 조직 개편을 거치면서 또 여러 회사와 조직을 경험하면서 내가 느낀 점은 팀워크란 게 어느 정도는 조직구조의 영향을 받을 수밖에 없다는 사실이다. 하지만 조직 구조를 바꾼다고 모든 것이 해결되지는 않았다. 중요한 부분은 프로젝트를 바라보는 공동의 목표가 같아야 한다는 사실이다. 기획자, 디자이너, 개발자가 한 팀에 있다 한들 기획은 여전히 기획자만의 일이라고 생각한다면 조직을 개편한 이유가 없어진다. 오히려 갈등이 더 심해진다.
한동안 구글의 OKR 문화를 모방한 조직이 유행처럼 퍼 졌다. OKR(Objectives and key results)은 조직의 목표와 결과를 정의하고 추적하기 위한 목표설정 프레임워크이다. 구글은 OKR이란 문화를 통해 많은 성과와 성장을 이루었다고 말한다. 하지만 나는 다른 곳의 조직문화를 모방하는 일에 회의적이다. iF 디자인 어워드 시상식 참석을 위해 독일에 갔을 때 자전거 도로로 보행하는 사람을 본 적이 없다. 내가 실수로 자전거 도로에서 걸어가면 현지 사람이 거긴 자전거 도로니 걸으면 안 된다고 알려주었다. 한국에도 자전거 도로가 있지만 사람들이 자전거 도로로 걷는 모습을 많이 본다. 그것을 제지하는 사람은 거의 없다. 그때 경험을 통해 느낀 점은 동일한 시스템이 갖춰졌다고 해서 꼭 그 시스템이 의도대로 운영이 되지는 않는다는 사실이다. 시스템도 중요하지만 더 중요한 건 시스템을 받아들이는 사람의 의식 수준이다.
이는 조직문화와 조직 구조, 팀워크에도 적용된다. 앞에서 말한 ‘퀄리티에 솔직해지자’는 문화는 개인적으로 좋은 문화라 생각한다. 하지만 구성원이 그 문화를 이해하지 못한다면 조직 내 갈등이 더 심해진다. 팀워크는 구조와 문화보다 공동의 목표를 위해 의식 수준이 서로 공유되는 사람들로 조직을 구성하는 일이 첫 번째다. 그런 사람들이 모여 일을 하다 보면 다른 곳을 따라 하지 않아도 고유한 팀워크와 문화가 탄생한다. 그래서 나는 성장을 위해 이직을 고민하는 주니어들에게 자신의 성장목표와 의식 수준을 생각하고 같은 성향의 사람들이 모여 있는 곳에서 일하길 조언한다.
[늘지 않는 디자인 중에서...]
[참고 도서]
