디자이너는 코딩을 해야 할까? – 1 (번역)
No, Part One.
이 글은 Alan Cooper의 "Should Designers Code?"라는 미디엄 글 시리즈를 번역한 것입니다.
프로그래밍하고 있는 글쓴이, 1988년경.업계에서는 디자이너가 코딩을 해야 하는가에 대한 토론이 줄곧 벌어진다. 어떤 개발자가 이 질문을 트윗하면, 전문가들, 실무자들, 리더들이 뛰어들어 답변을 한다. 모두가 다른 의견을 가지고 있기에 논쟁은 뜨거워지고, 찬성과 반대로 나뉘었다가 차츰 가라앉는다. 하지만 몇 주 후 누군가가 같은 질문을 던지면 SNS는 다시 이 쓸모없고 끝없는 탁상공론으로 시끄러워진다.
이런 논쟁들이 따르는 특유의 패턴이 있다: 개인의 취향 문제를 마치 보편적인 진리인 것 마냥 이야기하는 사람들이다. 이건 마치 한 개인이 아보카도를 싫어하기 때문에 아보카도가 나쁜 음식이고 다른 사람도 피해야 한다는 것과 같다. 당연한 얘기지만 문제는 아보카도가 아니라 개인에게 있는데 말이다.
이 의미 없는 논쟁을 우리가 쉽게 무시할 수 없는 이유는 두 가지다. 첫째는, 이 논제를 제대로 파악할 능력이 부족한 어린 청년들이 많은 시간과 기회를 낭비할 위험이 있기 때문이다. 둘째는, 겉으론 중요한 주제인 것처럼 보이지만, 이 논쟁의 반복이 더 근본적인 문제와 원인을 숨기고 있기 때문이다.
나는 이 주제에 대해서 이야기할 수 있는 특별한 위치에 있다. 우선 나는 인터랙션 디자인을 시작하기 전, 1970년—80년대에 개인용 컴퓨터를 위한 혁신적인 소프트웨어들을 개발하며 경력을 쌓아왔다. 트위터는 이미 너무 많은 훈계로 가득하며 이 주제를 다루기엔 적합하지 않다. 따라서, 이 주제에 대한 나의 생각을 여기서 나누고자 한다.
디자이너가 코딩을 해야 한다는 전제를 반대하는 주장은 많지만, 이 전제를 찬성하는 나의 주장은 하나뿐이다. 많은 논의들이 제대로 다루지 않는 것은 이 질문 자체가 사실상 무의미하다는 것이다. 디자이너가 코딩을 해야 하는가라는 질문은 사실 다른 문제로부터 파생된 증상이다. 이는 다양한 직군의 사람들이 어떻게 협업하는가라는, 가장 의미 있고 중요한 주제를 함구해왔다. 이 부분은 나중에 더 다루도록 하겠다.
디자이너가 코딩을 해야 한다에 반대하는 주요 주장은 다음과 같다:
경험하지 않아도 알 수 있다. 코치, 안무가, 트레이너, 경영진처럼 본인이 직접 그 일을 하지 않고도 그 일을 하는 사람을 지휘하는 여러 예시만 봐도 알 수 있다.
업무를 수행하는 행위가 그 업무를 수행하는데 함축된 모든 것을 자동으로 깨닫게 하지 않는다. 코딩을 한다고 해서, 그 코드가 다른 이나 그 조직에게 끼치게 될 영향까지 바로 이해하는 것은 아니다.
소프트웨어 개발은 굉장히 넓은 폭의 기술, 업무, 직군으로 이루어져 있다. "디자이너"나 "개발자"라는 단순한 이분법에 대한 주장은 각 역할의 전문성을 고려하는데 실패한다.
우리는 애초에 왜 이 질문을 하고 있는가? 가만히 보면 이 의문을 제기하는 사람들은 항상 다른 사람의 입장은 이해하지 못하면서 훨씬 이해심이 넓은 사람으로부터 공감을 요구하는 사람들인 것 같다. 사용자를 이해하는 가장 중요한 과제는 회피하면서 말이다!
디자이너의 코딩을 호의적으로 볼 수 있는 주장은 그저 다른 사람의 일을 잠시 해보는 것이 그 사람이 직면하는 문제를 이해할 수 있는 좋은 방법이라는 일반화다. 때문에 보통의 디자이너가 코딩을 해보는데 어느 정도 시간을 쏟는 것은 좋은 일이다. 물론 같은 논리로 개발자도 디자인을 해보는 시간을 가져야 한다. 그리고 여기서 디자인이란 스크린을 디자인하는 것을 말하는 게 아니다. 사용자를 인터뷰하고 그로부터 배운 것을 숙지하는 것을 의미한다.
하지만 나는 실무 개발자들(production coders)이 실무 디자인(production design)을 해야 한다고 전혀 믿지 않는다. 그건 마치 개발자에게 장부관리를 하라는 것과 같다. 그렇다, 그들은 그 일을 수행할 능력은 있을 것이다. 하지만 왜 그래야 하는가? 능력 있는 개발자를 장부관리에 낭비하는 게 아닌가. 좋은 개발자와 좋은 디자이너는 흔치 않다. 그들의 전문적인 기량 외의 일을 시키는 것은 바보 같은 짓이다.
진짜 문제 (The real issue.)
이 모든 논쟁의 진정한 핵심은 우리가 가장 중요한 질문을 하지 못하는 데 있다: 소프트웨어는 어떻게 만들어야 하는가?
매일 세계 곳곳에서 많은 소프트웨어가 만들어지지만 그것이 우리가 무엇을 하는지 제대로 알고 있다는 뜻은 아니다. 인간의 본성은 무엇이 만들어지는 것을 정상적으로 여긴다. 하지만 산업 개발의 악명 높은 Waterfall(폭포수 진행법: 역자주 - 개발이 한 단계 한 단계 순차적으로 이루어지고 전 단계로 되돌아 갈 수 없기 때문에 폭포수로 비유되는 개발 방식)의 세계에서 80%의 소프트웨어는 실패를 맛본다. 우리는 수십 년간 형편없는 소프트웨어를 만들어왔고, 아직도 효율적인 개발 방법을 알아내지 못했다. 일반적인 프로젝트는 절대 세상 밖으로 나오지 못할뿐더러, 실제로 개발이 되는 것도 주로 힘과 유연성을 찾아볼 수 없는 끔찍한 버전이다.
Agile(애자일 방식: 역자주 - 일정한 주기를 가지고 빠르고 유연하게 협업하는 소프트웨어 개발 방식)을 하는 사람들은 과거의 보수적인 소프트웨어 개발 방식의 실패를 고소해하지만, 그들의 새로운 소프트웨어 개발법도 월등히 더 나은 것은 아니다. 개중 많은 실패는 더 작은 규모였고, 더 빨리, 더 쉽게 숨길 수 있었다. 다만 나는 Agile이 효율적인 소프트웨어 개발을 향한 아주 큰 발걸음이라고 생각하므로, 이 부분에서 갑론을박하고 싶은 마음은 없다. 하지만 Agile은 과대평가됐다. Agile은 조직관리를 혼란스럽게 한다. 대규모로 일하기도 굉장히 힘들며, 참된 사용자 중심 디자인을 종종 부수적으로 만든다. Agile은 주도적이기보다 반응적이다. 가장 심각한 건 많은 Agile 종사자들이 말 같지도 않은 헛소리로 그들의 무지와 자질 부족을 숨기고, 다른 분야 — 특히 인터랙션 다자인 — 와의 협업을 거부하는 수단으로 쓴다는 것이다. (그렇다, 이건 Agile을 향한 일침이다. 그럼에도 불구하고 난 Agile이 현재 다른 개발법중에서는 제일 낫다고 생각한다.)
더 심각한 것은, 많은 팀들이 데드라인을 지키지 못하는 데에 줄곳 다른 분야를 탓하고 있다. "소프트웨어 데드라인"이라는 말이 모순이라는 사람도 있고, 정해진 데드라인은 곧 소프트웨어 개발에 대한 이해가 부족하다는 걸 입증해준다. 솔직히 말하면 나도 그들 중 한 명이다. 코딩에 할애하는 대부분의 노력은 알 수 없는 것을 향한 반격이고, 그 세계를 이해하기 위해 수차례의 도전이 필요하다. 예측은 불가능하다. 나는 소프트웨어 개발을 지뢰밭 지나가기와 비교하길 좋아한다: 지뢰를 밟지만 않는다면, 빠르고 쉽다. 누군가 당신에게 소프트웨어 개발이 걸리는 시간을 예측한다면 그건 허세일 것이다. 그리고 만약 당신이 누군가에게 이걸 예측하라고 한다면, 당신은 변명을 부추기며, 소프트웨어 개발이 예측 가능하다는 이 업계의 미신에 일조하는 것이다.
주목받은 댓글
(...) 나는 코딩을 내 디자인 툴 중 하나라고 생각한다. 가끔 개발자에게 내 파일을 줄 때도 있지만, 그건 개발팀이 필요할 경우에 참고하라고 주는 것이다.
나는 스스로를 한 번도 코딩하는 디자이너™라고 생각해본 적도 없고 그건 내 코드가 실제로 개발에 쓰이기 위한 게 아니기 때문이다. 지금 내 일에서는 코딩이 가장 좋은 커뮤니케이션 툴이다. (...)
또 이 이야기인가? 이 얘기는 이제 다 지나갔다고 생각했다. 많은 논리적인 이유로 디자이너들은 코딩을 할 필요가 없다. 하지만 그들은 건축가가 건축 재료에 대해 알고 있는 것처럼, 그 가능성과 제약에 대해 코딩의 언어로 이야기할 줄 알아야 한다. 나는 우리 디자이너들이 디자인의 영역에서 활동하는 것만큼 개발자에게 그들의 언어로 말할 수 있길 원한다.
지금의 포지션에서 나는 코딩과 디자인을 둘 다 하고 있다. 동의한다. 결국 시간 관리(time management)의 문제다. 하루에 주어진 몇 시간 동안 누가 저 두 가지 일을 효율적으로 다 할 수 있겠는가.
더불어 이건 사고방식을 바꾸는 것이다. 프로그래밍과 UI 업무(픽셀 옮기기)는 엄청난 집중을 요구한다. 마치 몇 시간 동안 세상과 떨어져서 제품의 세세한 기초들을 하나하나 다져가는 것과 비슷하다. UX 디자인은 항상 사람들과 연결되어 관계를 쌓고, 큰 그림을 생각하면서 다른 이들이 그 관계를 볼 수 있도록 해야 한다. 더 외향적인 사고방식이다.
하지만 디자인 팀에서 프로그래밍 기술은 찾기 힘들다. 때문에 당신이 프로그래밍과 디자인을 둘 다 할 줄 안다는 걸 사람들이 알게 되면, 주로 디자인보다는 프로그래밍 업무를 맡길 가능성이 높다. 간단히 말해서 만약 당신이 저 두 스킬을 다 요구하는 포지션을 찾게 된다면 당신은 아마도 디자인보다 프로그래밍을 더 하게 될 것이다. 이것은 곧 회사가 리소스가 부족하다는 뜻이고, 당신은 이걸 위험 신호로 생각해야 한다.
