Sketch and Draft

Wed 31 August 2016

소셜 미디어에 사진을 올리며 스케치와 시안 사이라고 적었다. sketch-and-draft.jpg

모 대학교 취업 박람회에서 사용할 홍보물을 제작하기 위해 간단히 스케치한 것과 그 스케치를 바탕으로 만든 시안이었다.

디지털로 바로 작업하는 것보다 종이에 펜으로 일단 빠르게 그려보는 것이 아이디어 구체화가 더 빠르게 진행되고 시간을 절약할 수 있어 선호한다. 이는 프로그래밍에서도 바로 제품 코드를 작성하는 것보다, 비교적 단순한 코드로 Proof-of-Concept(PoC)를 달성하고 발전시키거나 교체해가면서 작업하는 것과 같다고 생각한다.

최근에는 제품 디자인이나 제작과 관련된 업무를 더 수행하면서, 이와 같이 서로 다른 업무 영역에서 비슷한 일들이 있음을 경험하고 있다. (다른 영역에 대해서 비슷한 논리를 잘못 대입하는 경우가 워낙 많아 조심스럽지만.)

프로그래밍은 대부분 연속적인 논리적 사고의 결과물이라고 여기는 경우가 많은데, 제품을 만들어가는 과정에서는 논리 뿐 아니라 상상력도 필요하다고 생각한다. 쓰임새를 예상하지 못하고 낮은 수준으로 만드는 것도 문제지만, 더 큰 문제는 과한 설계가 아닐까. 미래를 걱정하는 설계만 계속하다 제대로 동작하는 서비스를 하나도 만들지 못하는 경우도 경험했었다. 이런 일들을 줄이기 위해서는 내가 지금 스케치하고 있는 내용이 어떤 모습으로 완성되고 사용될 지 상상해보는 일이 필요하지 않을까.

헛된 상상이 아닌, 가치 있는 상상이 되려면 우선 이 결과물이 어떻게 사용될 지 예상하는 것과, 결과물을 만드는데 동원되는 도구들에 대해 많은 경험이 요구된다. 저장하는 데이터의 크기는 얼마나 큰지, 얼마나 자주 많은 데이터가 들어오는지, 어떤 하드웨어 수준에서 동작될 것인지 - 이런 것과 마찬가지로 내가 만드는 포스터는 어디에 부착되고 얼마나 먼 거리에서 몇 명이 볼 것이며, 대상 청중은 어떤 교육을 받고 어떤 기대를 가지고 오는 사람들인지 알고 예측할 수 있어야 하며, 사용하는 도구는 어떻게 동작하고 어떤 한계를 가지고 있는지 알고 있어야 빠른 예상이 가능할 것이다.

좋은 코드를 작성하기 위해서 다른 좋은 코드를 많이 보는 것 / 좋은 디자인을 위해서 다른 좋은 디자인을 많이 보는 것이 기본이지만, 자신이 사용하는 도구에 익숙해지는 것도 생산성을 높이는 것 뿐 아니라 기능과 한계를 명확히 앎으로써 더 나은 작업을 가능하게 할 수 있다고 생각한다.

처음으로 돌아가보면, 이 홍보물이 사용될 곳과 취업 박람회에 참가할 대학생들은 어떤 부분을 유심하게 볼 지 고민했었고, 우리 회사가 할당받은 부스의 크기를 감안해 부스 디자인, 포스터 디자인 그리고 홍보물 디자인을 조화롭게 하기 위해 노력했었다. 스케치와 시안은 서로 다른 사람이 한 것이 아니라, 내가 직접 한 것이었고, 대충 그린 그림을 주고 “이렇게 해보세요” 했던 것이 아니라, 어떤 도구로 이 제품을 제작해야할 지, 어떤 부분을 강조해서 넣으면 좋을 지 감안해서 종이에 그림을 그렸다.

저 사진을 페이스북에 올렸던 이유를 생각해봤는데, 도구를 다루는 능력이 부족해도 수록될 콘텐츠에 대한 이해가 있다면, 시간을 절약해서 적당한 품질로 작업하는 것이 가능하다는 얘기를 하고 싶었던 것 같다.