시간은 한정적이며, 한정적 시간을 이용해서 결과를 만들어내야 한다.
단순 개발 업무에서는 이 부분이 명확했다.
내가 제대로 해석했는지를 먼저 확인하고, 필요하면 Cross-check를 했다. 이를 통해서 만들어야 될 목적을 명확하게 했다. 그리고 그 목표를 수행하기 위한 각종 Try를 시도했다. 이 때 새로운 기술을 도입할지, 아니면 기존에 구현한 것을 재활용할지, 아니면 내가 아이디어를 즉각적으로 제시해서 새로 만들기를 했다. 이 과정이 생각보다 길기도 하고 맨땅의 헤당의 느낌을 갖기도 한다. 이 작업에 많은 시간을 투자했다. 개인시간은 항상 2순위였고, 이 작업에 심혈을 기울였다. 이렇게 해서 나온 결과물을 이용하여 프로젝트 개발에 투입한다. 개발 과정은 생각보다 짧다. 큰 부분의 개발 보다는 대부분 앞서 제시한 준비 단계에서 제시되었기 때문으로 생각된다. 이렇게 마친 뒤, 실제 다양한 케이스의 테스트를 직접한다. 클릭이나, 순서를 정해 프로세스를 적용해본 결과를 이용하여 문제점을 도출하고, 도출된 문제점을 수정하거나 변경하는 작업을 했다.
운이 좋은 것인지, 지금까지의 모든 프로젝트를 위의 과정을 통해서 해결해왔고, 큰 문제없이 진행되었다. 일단 제일 중요한 것은 목표물이기 때문에, 이 목표 설정에서 중요하게 짚어왔다. 이 목표가 잘 잡혔다고 판단할때가 내가 그 목표를 설명할 수 있다라는 자신감이 들 때이다. 설명 자료를 준비하거나, 직접 Live로 설명할 수 있다면 목표가 제대로 잡혔다고 생각한다. 이렇게 잡힌 목표에 대한 준비 작업이 내가 개발하는데 가장 많은 시간을 소모하는 단계이다. 이 과정에서 생각보다 많은 시간을 보내고 즐거움도 많이 찾는 단계다. 다양한 형태의 테스트와 실험을 해서 적용을 해보는 것이다. 그리고 개발. 물론 개발로 바로 뛰어들 때도 있긴하지만...
다만, 이 과정은 코딩/개발에서 많이 사용한 방식이지, 지금 계속 지적 받는 설계라든가, 각종 문서 작업에서는 큰 도움이 안된다. 일단, 설계를 한다고 할 때, 전체적인 Layout Achitechure 수립이라든가, 각 단위 단위에 대한 도형 그리기 등이 잘 안된다. 일단, 재미가 없다. 작성하고 난 뒤에도 도리어 내가 이해가 안된다. 무엇을 하려는 것인지도 잘 모르겠다. 계속 그려보고 나타내면 나올 것 같기도 하지만, 그 연습을 쉽게 하지를 못하겠다. 작성하면서도 제대로 하고 있는지도 모르겠고, 최종 결과물을 보고 있자면, 대체 왜 이런 낭비적인 작업을 했는지 갸웃 거릴 때도 있다. 정말 설계 잘하는 사람의 설계서를 구경못해봐서 일지도 모르겠다.