본문 바로가기

Papyrus/Dizzy Report

코드 바깥의 일에 관심을 가져라

일반적으로, 유능한 프로그래머라고 하면 어떤 이미지를 떠올리는가? 눈 부신 설계를 할 수 있고, 빠르고 간결한 코드를 작성하는 해커를 떠올릴 것이다. 이것은 대부분의 프로그래머가 지향하는 목표이기도 하다. 그러나, 이런 이미지는 상이한 성격의 협업을 할 필요가 없는 일부의 분야 이야기일 뿐, 그외의 다른 곳에서는 오히려 프로그래머들에게 잘못된 오만을 심어주는 원인 중 하나라고 말하고 싶다. 좋은 소프트웨어를 만들고 싶다면, 코드 그 자체에만 관심 있는 고고한 모습에서 벗어나, 그 소프트웨어가 사용되는 비지니스나 일상 생활에 대해서도 잘 알아야 한다. 엉터리 기획 때문에 고통 받고 있다고 생각한다면, 왜 프로그래머가 그 기획의 개선을 제시하지 않았는지 반성해야 한다. 쓸데없이 구현하기 어려운 UX가 문제라고 생각했다면, 프로그래머가 더 나은 UX 시나리오를 제시해야 한다.


혹시라도 위의 말을 메시보다 더 많이 골을 넣어야만 메시를 비난할 수 있다는 뜻으로 이해할 수 있을지도 모르겠다. 그러나, 이것은 그런 뜻이 아니다. 기획자가 프로그래밍의 세부 구현 사항을 고려하며 기획을 하는 것보다, 프로그래머가 기획에 대한 이해를 갖추고 기획에 참여하는 것이 현실적이란 뜻이다.


예를 들어, 새로운 SDK 에 대한 큰 관심이 없는 UX 디자이너보다, 이런 업데이트를 빠르게 접하고 시험 구현을 할 수 있는 프로그래머가 UX에 대한 이해를 높이고 UX 시나리오 개선을 제시하는 것이 더 쉽다. 모든 것을 사용자 구현에 맡겼던 과거와 달리, 플랫폼 홀더들이 일관적인 디자인 가이드 라인을 따라줄 것을 요구하는 요즘 시대는 더욱 그렇다. 물론, 기획자나 UX 디자이너와 같은 전문가를 필요성을 무시하는 것은 아니다. 다만, 코드 바깥의 전문가들이 취약할 수 밖에 없는 부분이 있고, 이 부분을 이해하는 프로그래머가 직접 개선책을 찾는 것이 낫다는 이야기다.


전통적인 데이터만 다루어왔던 기획자라면, 데이터를 다루는 새로운 기술이 나왔을 때, 이것이 어떤 방식으로 제품에 적용될 수 있을지 판단하기 쉽지 않다. 이런 기술을 실제로 다루어 보지 않는다면, 해당 기술이 널리 알려지기 전까지는 그야말로 탁상공론 수준의 이해를 벗어나지 못할 가능성이 크다. 이 기획자의 선택은 두 가지다. 하나는 이전까지 해왔던 전통적인 방식을 다시 적용하는 것이고, 다른 하나는 프로그래머의 원성을 각오하면서 시행착오를 겪는 것이다. 어느 것이든 기획자에게는 그리 유쾌하지 않다. 만약, 프로그래머가 수동적인 자세에서 벗어나, 기획을 이해하고 기획 초기 단계에서부터 참여했다면 모두에게 불유쾌한 일을 상당히 줄일 수 있었을 것이다. 기획자는 기술적인 문제라며 무시하기 쉬운 세부 구현 문제를 초기 단계에서 면밀하게 검토할 수 있으며, 프로그래머는 비지니스 전체를 관찰 할 수 있기 때문에 제품을 보는 시야를 넓힐 수 있다.


UX 부분도 크게 다르지 않다. 만약, UX 디자인이 단순히 직관적이고 쉬운 사용자 경험, 그리고 아름다운 일러스트와 예쁜 위젯 정도를 의미하는 정도였다면 프로그래머가 관여할 부분은 없었을 것이다. 그러나, 현실은 다르다. 어느 정도 코드에 대한 이해를 갖춘 UX 디자이너라고 하더라도, 정도의 차이만 있을 뿐이지 최선의 UX 시나리오를 그려내는 능력은 부족할 수 밖에 없다. SDK의 New features 항목을 읽으며 시나리오를 개선할 수 있는 UX 디자이너는 매우 부족하기 때문에, 이런 일에 익숙한 프로그래머가 능동적으로 UX 개선 방안을 제시하는 것이 훨씬 낫다. UX 디자인을 완전히 새롭게 창조하는 것이 아니라면, 프로그래머가 새로운 기능을 검토하고 최적의 사용 시나리오를 검토한 다음, UX 디자이너에게 세부 사항을 맡기는 것이 서로에게 좋다. 특히, 현대적인 플랫폼은 비지니스 코드와 UI를 분리하는 구조적인 부분부터 픽셀 단위의 디자인 가이드라인까지, 프로그래머와 UX 디자이너 모두의 작업 부담을 줄여주는 기능을 제공한다. 플랫폼은 플랫폼 자체의 일관적인 UX를 위해 이 가이드라인을 지킬 것을 권하며, 이 부분에 편집증적인 집착을 보이는 애플 같은 기업도 있다.


이쯤되면 프로그래머가 코드를 작성하기도 바쁜데 언제 이런 일까지 신경 써야 하냐며 불평 할지도 모르겠다. 그러나, 이런 부분에 신경 쓰지 않는다면 프로그래머는 결국 더 바빠질 것이 확실하다. 코드 이외의 부분은 신경 쓸 것이 아니라며 고고한 생활을 하고 있다면, 지금부터 주변의 일을 둘러보기 바란다. 기획자의 업무를 대신 떠맡으라는 의미가 아니다. UX 연구를 한다고 해서 프로그래머가 키보드를 치우고 펜을 움직이며 그림도 그려야 한다는 뜻도 아니다. 당신이 프로그래머라면 스스로 생각해보라. 프로그래머 스스로 코드를 작성하는 것은 아무나 쉽게 할 수 없는 일이라고 자부해오지 않았던가? 그 논리를 받아들인다면, 기획자, UX 디자이너가 프로그래머의 코드를 이해하며 프로그래머의 입맛에 맞춰 일을 하지 않는 것은 당연한 것이다. 이것이 불만족스럽다면, 먼저 프로그래머가 그들의 일을 이해하고 초기 단계에서부터 적극적으로 세부 사항을 결정하는 것이 합리적이다.


코드로만 시작해서 코드로만 끝나는 프로젝트가 아니라면, 프로그래머는 코드 바깥에서 벌어지는 일에 관심을 가져야 한다. 그것이 결국 견고한 소프트웨어를 작성하는 지름길이다.