눈에 보이도록 하는 작업과 뒷받침하는 기술의 이해

요즘 주위에 있는 분들이 출판쪽 일러스트레이터들이 많다보니, 그들의 작업방식과 산출물들과 비교해서 그간의 내가 일한 방식에 대해 생각할 기회가 많다. 내가 해 온 일들이 대부분 디지털 상에서 일어나는 일이다보니, 작업 도중에 보이는 것들은 개념적이고 추상적인일이 많고, 산출물을 보고 나서야 비로소 눈에 보이거나 심지어 서버의 경우 로그가 올라가는 것이나 시스템의 전반적인 건강상태(CPU, Memory, Kernel Context Switching, Network Bandwidth 등)를 보는 정도이다. 반면 아티스트들은 작업자체가 대상 자체가 완성되는 모습에 대한 것이며, 중간단계 하나하나가 작업의 품질을 바로 알 수 있는 일들이다.

인류가 해 온 일들 중에 이렇게 작업자체의 중간 과정이 보이지 않는 경우가 얼마나 있었던가, 심지어 IT 프로젝트의 모델을 건축 프로젝트의 공정 방식에서 가져왔다고도 하는데, 건축만 해도 중간 과정은 이러하지 않다. 출판쪽 일러스트레이터들은 의뢰인에게 스케치만 가지고 피드백받고, 작업을 마치고서 1차로 편집자에게 넘긴 다음 지적 사항을 받아서 수정한다. 이 경우에도 보면, 맘에 드는 정도가 사람마다 달라서, 의뢰인이 기대하는 수준에 맞는 정도로 보내기도하고, 자기 기준에 안맞으면 시간을 들여 훨씬 고퀄리티로 만들어 보내기도 한다. (하지만, 볼 눈이 없는 나에겐 크게 달라 보이지 않는다.) 또한, 편집자들은 아티스트들의 기존 포트 폴리오를 보고 이 사람을 쓰면 자기가 하려는 일에 맞을지 여부를 판단하고 의뢰를하며, 비슷한 분위기를 할 수 있는 여러 사람들에게 작업을 나눠주기도 한다.

그래서 그간 내가 해 온 방식과 일을 비교하면서 생각이 드는 것은 이렇다. 협업이나 피드백은 이 분야처럼 눈에 보이는 것을 바탕으로 이루어지기 마련인데, 결국 IT 업계의 의뢰인처럼 기술을 잘 모르는 입장에서 최종 산출물이 기대하는 기능을 하기만 하면 모든게 다 되는 것이고, 그러다 보면 정작 프로그래머들도 기술을 잘 모르는 사람의 입장에서 맞춰주는 정도로만 익숙해진다. 내가 다시 한 번 많이 느끼는 것은 중간 과정을 눈으로 보는 것이다. 동료에게 물어보고, 의뢰인에게 피드백을 받는 것들 모두가 과정의 품질에 대한 합의가 이루어지기 때문에 최종 산출물에 대한 책임 또한 공유하게 된다.

IT 업계에서 일을 같이 할 사람을 판단하는 것은 보이지 않는 부분에 대한 일처리에 있다. 이력서를 보지만 이력서를 통해서 의뢰인이 기대하는 최종 산출물이 내포하고 있는 기능 집합 그 이상에 대한 해석과 구현한 기능이 작동하는 환경에 대한 이해를 바탕으로 얼마나 견고한 설계 및 구현을 했느냐를 평가하는 것이다. 의뢰인의 시각에서 사람을 평가하는 것은 제품을 보고 평가하는 것이지만, 동일한 개발자의 시각에서 사람을 평가할 때는 그 제품이 만들어지는 상황을 시뮬레이션하면서 평가를 하게 된다. 혼자 일 할 것이 아니면, 시간과의 싸움에서 기능 구현과 뒷받침하는 기술에 대한 이해의 두 마리의 토끼를 다 잡을 기세로 훈련되지 않으면 안된다. 늘 없는 것은 시간이므로, 적당한 수준에서 기술을 모르는 사람의 입장만 맞춰주다가 그것에 익숙한 일만 하게 되지 말아야한다.

내가 하는 일을 중간 중간 볼 수 있게 만들어야하며, 그 기능을 뒷받침하는 기술에 대해 완벽한 이해를 하는 것. 전자는 인류가 일해 온 방식에 편승하기 위하여, 후자는 이 바닥에서 평가되어지는 기준을 맞추기 위해서. 이 두가지를 염두에 두지 않으면, 우수한데 어딘가 부족한 사람이 되고 만다.