디자이너는 코딩을 해야 할까? – 3 (번역)
No, Part Three: 역할과 책임.
이 글은 Alan Cooper의 "Should Designers Code?"라는 미디엄 글 시리즈를 번역한 것입니다.
이 업계에서는 디자이너가 코딩을 해야 하는가에 대한 토론이 줄곧 벌여진다. 이 질문에 대한 폭넓은 답은 전 글에서 다뤘지만 이 주제에 대해 할 말이 아직 많기에 보다 구체적인 생각을 이 글과 다른 글들을 통해 더 나누고 싶다.
몇 번이나 말했듯이, 이 질문에 대한 내 개인적인 답변은 "No, designers should not code."이다. 물론 이건 디자이너가 코딩을 해야만 하는 상황은 제외한 것이다. 이 난제는 대부분의 사람들보다 좀 더 깊게 바라봐야 해결할 수 있다.
이 혼란의 핵심은 세상을 단순하게 요약하고 싶어 하는 우리의 인간적인 본성이다. 사람들은 복잡한 걸 싫어하고, 우리는 너무나도 복잡한 세상을 간략하게 만들어줄 단순한 이야기들을 머릿속에 꾸며낸다. 단순화하려는 습성을 탓할 일은 아니다. 이건 진화해온 생존 메커니즘이다. 물론 이 메커니즘은 우리가 무서운 미지의 세계를 이해하려 했던 비포 디지털, 비포 산업화 시대 때 만들어온 것이다. 때문에 현대에서는 이 메커니즘이 많은 문제를 야기하는 것으로 보인다.
우리가 단순하게 생각하려고 하는 개념 중 하나는 기술적인 일(tech work)이다. 일하면서 주로 내놓는 산물이 "코드"인 사람들이 있는데, 우리는 그들의 정체성을 "코더"라고 요약한다. 일하면서 주로 내놓는 산물이 "코딩할 것들에 대한 설명"인 사람들이 있는데, 우리는 그들의 정체성을 "디자이너"라고 요약한다. 이것들은 진짜 직업이나 직함이 아니다. 이것들은 정신적 지름길(mental shortcut)이고, 지나치게 간소화된 어렴짐작이자, 혼란과 논쟁의 근원이 된다.
당신이 어떤 IT 회사의 창문 안을 들여다봤을 때, 누가 디자이너이고 누가 개발자인지를 구분하긴 굉장히 힘들 것이다. 두 직종 모두 직장 동료와 얘기하고, 복잡한 다이어그램을 화이트보드에 그리고 키보드를 두들기는데 많은 시간을 보낸다.
디자이너가 인터랙션을 만들 때는, 디자인을 하는 프로세스에 임한다. 디자이너는 관점을 디자인한다. 디자이너는 멘탈 모델을 디자인으로 구현한다. 디자이너는 논리와 의도를 가지고 경로와 여정을 디자인한다. 디자이너는 행동을 디자인한다. 디자이너는 사건과 행동과 반응의 결정적인 시퀀스를 디자인한다.
개발자가 코드를 쓸 때도 디자인을 하는 프로세스에 임한다. 개발자는 코드를 디자인한다. 개발자는 데이터의 구조를 디자인한다. 개발자는 절차를 디자인한다. 개발자는 알고리즘을 디자인한다. 개발자는 다양한 인터페이스가 가져오는 문제점의 해답을 디자인한다.
개발자의 세상에서는 큰 해답이 주로 화이트보드, 종이, 또는 머릿속에서 건설된다. 이걸 제대로 컴퓨터 코드로 줄이는 건 그냥 마무리 작업이다.
디자이너의 세상에서는 프로그램된 프로토타입을 코드로 만들고 고쳐가며 해답이 건설된다. 디자이너는 프로그램의 느낌과 사용자의 반응을 테스트하기 위해 인터랙션을 만든다.
내가 무슨 말을 하려는지 알겠는가? 디자인과 코딩의 차이는 넓고 애매하고 유동적이다. 이 차이는 우리가 "코딩"이라는 지나치게 단순한 용어를 사용할 때 혼란스러워진다. 코딩은 툴이고, 능력 있는 제작자는 무엇이든 일할 때 도움이 되는 툴을 쓴다. 코딩, 창의력, 디자인, 인터뷰 등 어떤 툴도 우리가 역할을 구분 지을 때는 관련이 없다.
실제로 관련이 있고, 이 역할들을 구분 짓는 것은 책임이다. 개발자는 디자이너와 매우 다른 책임을 가지고 있다. 개발자는 프로그램의 안전, 보안, 효율, 성공에 책임이 있다. 디자이너는 프로그램을 사용하는 사람의 경험, 행복, 만족, 성공에 책임이 있다. 두 책임 모두 중요하지만 완전히 다르다. 개발자는 그 기술에 책임이 있는 반면 디자이너는 사용자에 책임이 있다. 비즈니스가 성공하려면 둘 다 필요하다.
내가 최초로 고용한 프로그래머, Peter Breeze. 1979년경.우리가 누구를 "개발자" 또는 "디자이너"라고 부르는 것은 마치 누구를 "의사"라고 부르는 것과 같다. 질병을 연구하는 의사도 있고, 개코원숭이를 연구하는 의사도 있고, 뼈를 연구하는 의사도 있고, 종양 데이터를 체출하기 위해 쥐의 간을 다루는 의사, 안전에 대한 통찰력을 얻기 위해 사고 피해자를 인터뷰하는 의사, 사망원인을 알기 위해 시체를 부검하는 의사, 마취용 약물을 관리하는 의사, 심장 손상을 치료하기 위해 위해 심장을 절개하는 의사, 힘줄을 잇기 위해 로봇 팔을 이식하는 의사도 있다. 의사들이 가지고 있는 기술과 참여하는 활동의 범위는 어마어마하게 넓다. 어떤 의사들은 전문적인 범위 내에서 사람을 만질 일이 전혀 없기도 하다. 의사를 정의하는 것은 그 툴과 기술이 아니라 그 책임에 있다. 심지어 의사는 자신의 책무에 대해—그것도 매우 진중하게—외워야 하는 선서도 있다.
디자이너가 비전을 전달할 때 정지된 이미지보다 실제로 사용해볼 수 있게 뭔갈 코드로 쓰는 게 가장 효과적일 때도 있다. 이 코드의 목적은 개발자가 쓰는 코드의 목적과 다르다. 이 코드는 실질적인 개발보다 디자인을 위한 코드이다. 목적과 책임이 다르다. 물론 이것도 코드지만, 개발자가 쓰는 코드와는 다르다.
나는 이 목적을 위해 많은 코드를 썼다. 내가 1980년대에 쓰고 Visual Basic이 된 Ruby라는 시각 프로그래밍 언어는 두 가지 목적을 가지고 있었다: 창작을 위한 플랫폼이었고 나의 창작을 다른 사람에게 전달하기 위한 툴이었다. Ruby는 사용자가 접하게 될 실제 운용환경을 개발하기 위해 쓸 수 있는, 써야 하는, 쓰기 위한 코드가 아니었다.
이 질문의 거슬리는 재등장은 어떤 분야의 실무자가 다른 이들의 툴을 배워야 한다는 근거가 아니라, 다양한 실무자들이 함께하는 조직이 같은 목적의식을 가지고 있지 않고, 그들이 일하는 조직 구조가 망가져있다는 근거가 된다.
매니지먼트의 목적은 더 이상 결정을 내리는 것이 아니고, 같은 팀에 있는 모두가 같은 목적의식을 가지고 있고, 어떤 결정에 따라오는 비용, 이익, 희생에 대해 모두가 완전히 이해할 수 있도록 하는 것이다. 조직구조가 기술력 있는 다양한 사람들의 협력을 지지하면, 그 사람들은 함께 일하는 동료를 지지하게 된다. 개발자는 디자이너를 믿기 때문에 디자이너가 디자인을 하길 바란다. 디자이너도 같은 이유로 개발자가 코딩을 하길 바란다. 둘 다 원하지 않는 것은 서로의 세계에 침범하는 것이다.
사람들이 "분야 A"가 "분야 B"의 일을 해야 하는 거 아니냐고 묻는다는 것은, 그 조직에 결함이 있고, 더 나아가 매니지먼트가 실패했다는 확실한 증거이다.
최근에 Part Four도 올라왔지만, 이 시리즈는 여기서 마칠 예정입니다. 감사합니다 :)
