디자이너는 코딩을 해야 할까? – 2 (번역)
No, Part Two: 아는 것 vs. 하는 것
이 글은 Alan Cooper의 "Should Designers Code?"라는 미디엄 글 시리즈를 번역한 것입니다.
이 업계에서는 디자이너가 코딩을 해야 하는가에 대한 토론이 줄곧 벌여진다. 이 질문에 대한 폭넓은 답은 전 글에서 다뤘지만 아직 할 말이 많기에 보다 구체적인 생각을 이 글을 시작으로 더 나누고 싶다.
전에 말했듯이, 이 질문에 대한 내 개인적인 답변은 "No, designers should not code."이다. 하지만 이 질문을 더 적절하고 유용한 "개발자가 씨름해야 하는 강력한 세력들을 디자이너가 이해해야 하는가?"로 다르게 묻는다면 나의 답변은 분명한 "Yes!"이다.
개발자 외의 사람이 프로그래밍의 미주알고주알에 대해 알아야 할 필요는 전혀 없다. 그런 디테일은 개발자한테만 유용하다. 반대로 개발자들을 주도하고, 조언하고, 영향을 끼치고, 또는 영향을 받는 사람이 개발자가 일하는 곳에 존재하는 강력한 세력과 그들의 세상에 대해 아는 것은 필수적이다. 이 세력들은 주로 잘 보이지 않고, 눈치채기 어렵고, 개발자의 세상을 지배하는데도 주목받지 않는다. 많은 개발자는 이 세력과 매일 싸우고 있는데, 아무도 입 밖으로 꺼내지 않아서 존재한다는 것도 전혀 자각하지 못한다.
디자이너가 코딩을 할 줄 알아야 한다는 개발자의 변명은 개발자 스스로 느끼는데도 이해할 수 없는 거대한 세력을 알아내려는 욕망에서 온다고 생각한다. 개발자는 자신의 세계를 코딩으로 이해하기 때문에, 자연스럽게 다른 사람도 똑같이 해주길 바라는 것이다.
몇 년 동안 프로그래밍을 하는 것도 이 무언의 세력을 인지하기에 좋은 방법이지만, 유일한 방법은 아니다. 디자이너가 코딩을 배우길 개발자가 바라는 것은 코딩에 도움이 필요해서가 아니라, 대부분의 개발자가 프로그래밍의 본질을 배울 수 있게 된 유일한 방법 중 하나가 코딩이기 때문이다.
이 글은 숨겨진 많은 "세력들"에 대해서 하나하나 이야기할 곳은 아니지만, 한 가지 예를 들자면 이렇다:
모든 소프트웨어는 만들기 매우 어렵다. 에러 투성이에 시간이 오래 걸리는 작업이다. 반대로 제공된 라이브러리에서 이미 써져있는 코드를 불러오는 건 훨씬 싸고, 빠르고, 쉽다. 그러므로 (이건 매우 중요한 사실인데) 많은 프로그래밍이 애초에 시도되지 않는다. 대신에 대부분의 개발자는 이미 존재하는 코딩 라이브러리를 사용한다. 이게 바로 우리가 만드는 많은 소프트웨어가 비슷하게 생기고, 비슷하게 행동하고, 그 행동과 범위가 뻔한 운명을 따르는 것처럼 보이는 이유 중 하나다. 이 난제를 또 다른 시각에서 바라본다면, 혁신이 단순하게 의자의 배열을 바꾸는 것보다 훨씬 비싼 비용이 든다는 것이다. 매니지먼트의 스케줄 총대 밑에서 개발자는 디자이너에게 "그건 못 만든다. 기술적으로 불가능하다"라고 말한다. 이 말이 실제로 의미하는 바는 "그러려면 쓰인 코드를 쓰는 게 아니라 처음부터 오리지널 코드를 다 써야 하고 거기에 드는 모든 리스크, 위험, 시간, 비용을 내가 다 감수해야 한다. 난 절대 증명되지 않은 "사용자의 니즈"를 위해 그 방아쇠를 당길 생각이 없다"이다.
디자이너, 매니저, 개발자와 일하는 사람들은 코딩에 대해 하나도 알 필요가 없다. 하지만 위와 같은 영향력과 프로그래밍의 특성을 이해해야 한다.
디자이너가 개발자에게 복잡하고 어려운 코드를 처음부터 쓰라고 주장하는 것은 괜찮지만, 그러려면 개발자의 노력에 대한 타당한 이유가 있어야 한다. 그리고 개발자는 디자이너가 이 희생을 이해한다고 믿어줘야 한다.
보병 이야기 (The Infantry Man)
나는 평생 전쟁과 군대에 대해 관심이 많았다. 청소년기 전부터 나는 전쟁소설과 관련 비소설의 애독자였고 지금도 그렇다. 내 안의 엔지니어는 멋진 하드웨어에 매혹됐다: 무기고의 탱크, 총, 배, 전투기 말이다. 하지만 내가 더욱 매료된 것은 군인의 정신이었다. 도대체 어떻게, 솜므와 테르모 펠레의 병사들은 안전한 대피호에서 나와 확고한 죽음을 택할 수 있었는지 나는 끝없이 궁금해했다. 어떻게 병사들은 아내나 어머니를 위해 마지막으로 사랑의 쪽지를 쓰고, 칼로 쪽지를 벽에 꼽은 다음, 머신건의 총알이 빗발치는 곳을 향해 달려갈 수 있었을까?
이런 나의 궁금증은 뭇 어린 남성이 흔하게 묻는 질문들로부터 영향받은 게 분명하다. 나는 강한가? 나는 용감한가? 개인적인 위험을 무릅쓰고 의무를 다할 수 있는 정신을 가지고 있는가? 나는 죽음을 맞설 수 있을까? 나는 사나이인가?
나의 시아버지, Ed Carlick과 참전용사의 파란 소총을 포함한 그가 받은 세계 2차대전 메달들.내가 일하는 곳의 벽에는 세계 2차 대전에 참전하신 시아버님의 기념물들이 액자 안에 걸려있다. 그는 얼음장 같은 1944년의 겨울에 제1보병사단의 소위로 벌지 전투에 참여했다. 그는 영리하고 멋진 남자였고 전투에서 살아남아 돌아왔다. 결코 작은 전투가 아니었는데, 당시 참전했던 병사들의 기대수명이 주 단위나 하루 단위가 아니라 시간 단위로 측정됐을 정도였다. 그가 받은 표창들 몇 개는 그 얼어붙은 은닉처에서 온 것이다.
어떤 병사 든 가장 가치 있는 메달은 Combat Infantry Badge(참여 보병 훈장)의 심플한 파란 소총이라고 당신에게 말할 것이다. 전투에 참여하면 수여받는 표창이다. 30년 동안 충실하게 복무하거나 평화로운 시기에 큰 성과를 이룬다고 받을 수 있는 것은 아니다. 이것이 참전용사와 병사의 차이다. 참전용사는 당신이 잊을 수 없는 경험을 했고, 벼랑 끝까지 가봤으며, 낭떠러지를 보았다는 뜻이다.
페인트볼광이였던 나, 1986년경.1980년대 초반에 나는 어떤 신종 —너무 새로워서 이름 조차 없었던— 스포츠에 빠져들었다. 나는 몇 년을 빠져서 거의 매주말 실패 없는 플레이를 하고, (이 스포츠의) 광신도로 자리매김했다. 나는 압축된 공기총을 들고 어둡고 깊숙한 숲으로 들어가 비슷한 장비로 무장한 사람들을 찾아내서 쏴야 했다. 이 게임은 간단히 말해서 무장한 숨바꼭질과 같다. 공기총은 한 번에 한 발밖에 쏠 수 없었고, 우리는 위장 군복을 입고 몇 시간 동안 숲 속을 미친 듯이 기어 다녔다. 몇 년이 지나고 이 스포츠는 페인트볼(Paintball)이라고 알려지게 됐다. 이 게임은 전과 좀 달라져서 오늘날은 배구와 비슷해졌지만 전에는 나폴레옹 시대의 전쟁과 비슷했다.
페인트볼은 내가 가지고 있던 큰 질문의 답을 제시해줬고, 내가 이토록 빠져들게된 이유 중 하나였다. 싸움은 밀접했고, 위험하고, 고통스럽고, 사적이고, 삶이냐 죽음이냐 라는 공황상태가 길고 팽팽한 고요를 방해했다. 나는 분명 공기총에 맞는 게 총알에 맞는 것과는 다르다는 걸 머리로는 인지했지만, 게임을 시작하는 휘슬이 불린 후 팀원들이 조용히 숲 속으로 사라지고 나 혼자 남았다는 걸 느꼈을 때는 이제 실전이라고, 내가 타깃이고, 사람들이 지금 이 순간 날 추적하고 있다고, 알 수 있었다.
이 경험은 순수하고 완전했다. 아드레날린은 내 감각을 최고조로 만들었다. 나는 전사가 되었고 내 안전은 우선순위가 아니었다. 놀랍게도 나는 종종 튀어나와 "공격!"이라고 온 목소리로 소리치며 내 병사들을 페인트볼 총알들이 빗발치는 곳으로 돌진시켰다. 그렇다, 나는 피가 들끓는 나머지 전투중에 정신을 놓기도 했다. 그렇다, 나는 고민할 찰나도 없이 팀을 위해 총알에 맞기도 했다. 그렇다, 나는 진정한 사나이였다.
나는 참전용사였나? 절대 아니다! 나는 병사였나? 절대 아니다! 나는 진짜 군인으로부터 존경을 받았을까? 절대 아니다! 나는 군인의 일을 이해할 수 있었을까? 그렇다. 나는 참전용사를 이해할 수 있었을까? 그렇다. 나는 전보다 전략을 더 잘 짤 수 있게 되었을까? 그렇다. 나는 알 수 있었다. 하지 않고도 말이다.
최고의 가르침 (The Best Lesson)
나는 오랜 시간을 소프트웨어를 개발하는데 써왔고, 코딩의 세계에서 진정한 참전용사다. 나는 프로그래머를 위한 참전용사 배지를 받은 자격이 있다. 나는 컴파일러, 게임, 비즈니스 소프트웨어, 엑셀 시트, 워드 프로세서, 지형 정보 시스템, 시각 프로그래밍 언어, critical path 시각화 소프트웨어 등등을 개발했다. 이런 경험이 나를 더 나은 디자이너로 만들어 주었는가? 그럴 것이다. 하지만 나를 더 나은 디자이너로 만들어 준 한 가지 선택이 있다면 그건 내가 프로그래밍을 그만둔 것이다. 내가 개발자로서의 툴과 방식을 버렸을 때, 내가 코딩을 그만두고 프로그래머의 커리어를 돌아보며 어떤 의미가 있었는지 스스로에게 되물었을 때, 난 가장 많이 배울 수 있었다.
나는 프로그래머로 일하는 것이 소프트웨어 개발의 모든 과정을 이해하고 전반적인 개념을 구축하게 해주었다는 걸 바로 알 수 있었다. 또한 이 시스템이 사용자의 니즈와 충돌한다는 것도 분명히 알 수 있었다. 프로그래머는 두 마스터를 섬겨야 한다: 컴퓨터와 사용자이다. 근데 프로그래머는 컴퓨터와 함께 살아가지만, 사용자는 거의 보기 힘들다.
나를 좋은 디자이너로 만들어 준 것은 내가 코딩을 한 세월들이 아니라, 개발자가 항상 씨름해야 하는 보이지 않는 악마를 제대로 이해한 것이다. 만약 어떤 디자이너가 매우 뛰어난 기술을 가지고 있다면, 이 개발 악마를 인지하는 것이 그를 더욱 성공하게 만들어 준 것이다.
안타깝게도 재주가 없는 디자이너는 충분히 많고, 그만큼 코딩을 못하는 개발자도 충분히 많다. 열려있는 채용공고의 수가 유능한 기술자에 비해 많다는 슬픈 현실이 디자이너가 무엇을 알아야 하는지를 혼란스럽게 만드는 큰 주범이다.
인터랙션 디자이너의 주된 책임은 사용자의 관심사와 공감대를 제품을 창조하는 과정에서 보여주는 것이다. 개발자가 버그 없는 코딩을 하는 것만큼 인터랙션 디자이너는 사용자과 공감하고 그들의 동기를 이해하는데 능숙해야 한다. 하지만 디자이너는 개발자가 자신의 디자인을 개발한다는 것에는 목을 매는데, 개발자는 아무도 자신이 하는 일을 이해하지 못하고 혼자만 제품의 상태와 성공에 대한 책임을 진다고 느낀다. 협력적인 환경에서 배운 더 젊은 개발자들은 디자이너가 지시하는 방향으로 일하는 것에 훨씬 열려있지만, 그들도 스스로와 디자이너의 역량 간극 때문에 힘들어한다.
당신은 다른 사람과 일을 더 잘하기 위해 그 사람의 일을 해볼 필요가 없다. 하지만 당신의 직장동료가 마주하는 큰 문제들을 이해해야 한다. 어떤 직장동료가 스스로의 문제에 대해 무지할 때는, 별의별 이상한 생각들이 들기 시작한다 —디자이너가 코딩을 해야 한다는 것 같은.
주목받은 댓글
디자이너가 코딩을 해야 하나? 는 토론하기에 너무 막연한 주제다.
여기서 코딩은 무엇을 의미하는가? HTML? Javascript? Python? 데이터베이스 디자인?
여기서 코딩은 무엇을 의미하는가? 코딩 배우기? front-end 코딩? 모든 코딩? (이 단계라면 당신은 디자이너가 아니라 스타트업의 절반이다.)
건축가는 콘크리트를 붓는 법을 배우지만 그걸 실제로 다시 하게 되지는 않는다. 화가는 캔버스를 짜는 법을 배우지만, 결국 피하게 된다. 내가 코딩에 투자한 일분일초는 나를 디자이너와 팀메이트로서 더 똑똑하게 해주었다. 하지만 내가 코딩에 투자한 일분일초는 내가 디자인에 깊게 들어가지 않았을 때이고 힘든 업무 변경이었다. (...)
css가 됐던 알고리즘이 됐던 디자이너는 자신의 재료에 대해 배워야 한다. 디자이너는 팀의 규모에 따라 필요한 만큼 코딩을 하면 된다.
가장 중요한 건 디자인과 코딩을 둘 다 하는 사람을 뽑으면서 절감하는 비용과 무관하게 작업의 속도와 퀄리티를 잃게 됨을 지도자가 염두해야 한다는 것이다.
나는 옳고 그름이 있다고 생각하지 않는다. 다만 이런 거래에 따라오는 많은 희생이 있을 뿐이다.
Part Three로 이어집니다.
