무언가 만들 때는 그 분야에 깊이 참여해야 한다

인테리어 디자인 솔루션을 개발하고 있는데

최근에 개발 전략을 바꿨다.

그동안은 '디자이너가 더 빠르게 작업할 수 있도록' 솔루션을 개발했다. 그래서 디자이너가 원하는 기능을 전달받아서 기능을 개발하고 디자이너에게 써보라고 하면서 피드백을 받는 과정을 반복했다.

하지만 이제 솔루션을 개발하는 목적은 '내가 디자인을 더 빨리 만들어내기 위해서'다.

엥? 무슨 뚱딴지 같은 소리지? 어떻게 개발자가 인테리어 디자인을 만들어낸다는 거지? 가능하다고 하더라도 굳이 왜 개발자가 그런 일까지 손을 댄다는 걸까? 개발자가 할 일이 있고 디자이너가 할 일이 따로 있는 거 아냐? 싶을 거다.

그도 그럴 것이 개발 전략을 바꾸면서 나는 인테리어 지식은 거의 없는데도 실제로 인테리어 디자인을 만들어야 하는 상황에 처했기 때문이다.

그러는 바람에 인테리어 디자인을 스스로 만들어내기 위해서 고객과 미팅한 내용을 나에게도 전달해 달라고 요청했다. 회의에 직접 참여하기도 했다.

그러면서 나는 예전에는 하지 않던 생각을 하게 되었다.

예를 들어서 '고객이 준 이 손도면을 어떻게 프로그래머인 나조차 쉽게 3D로 옮길 수 있을까?' 라는 질문이었고

또 '이번에 고객이 원하는 신발장과 붙박이 소파 그리규 유리 파티션을 구현하려면 이러한 것들을 import할 수 있는 에셋으로 만들어야겠군' 같은 생각이었다.

그리고 디자이너가 150평짜리 디자인 요청을 받았을 때 겉보기에 아무리 단순한 내용이더라도 실제로 CAD 작업과 Sketchup 작업 그리고 자질구레한 반복작업들을 거칠 생각에 얼마나 스트레스를 받을지 이해할 수도 있었다. 스트레스는 평수에 비례하는 셈이다.

이러한 질문에 대한 해답을 찾고 생각을 하나하나 실천으로 옮기면서 비로소 강력한 인테리어 디자인 솔루션이 탄생했다.

지난번 의뢰받은 고객 요청은 CAD와 Sketchup을 사용하지 않고 나 스스로 10분만에 3D 디자인을 만들어낼 수 있었다.

아마 내가 스스로 결과물을 만들어내야 한다고 생각하지 않았다면 여전히 나는 '너무 예민한 선택 도구'와 같은 문제를 두고 씨름하고 있을 것이다.

아니면 '디자이너의 수준 높은 요구를 모두 만족하는 확장성 있는 2D 지오메트리 에디터 아키텍처' 같은 문제를 고심하고 있을 수도 있다.

제일 나쁜 종류로는 내 업무 목표와 성과 측정을 디자이너 평가에 의존하고 있었을 것이다. '디자이너님이 이런 기능이 좋을 거라고 하셔서 개발했는데요?'처럼 핑계를 대면서 말이다.

하지만 나는 고객이 점점 더 많이 요청하는 3D 디자인을 만들어내는 일만을 목표로 삼고자 했다. 솔루션도 결국 그런 목적을 위해서 개발하고 있는 것이기도 하다.

결국 '만약 인테리어 디자인 프로그램을 만들고자 한다면, 실제로 인테리어 디자인을 만들어라'처럼 말할 수 있겠다. 즉 무언가를 만들 때는 그 분야에 깊이 참여해야 한다.