지금 동시에 하는 프로젝트는 5개정도 되지만 이중에 실질적으로 가장 많은 시간을 쏟는 것은 평균 2~3개 정도 된다. 그리고 시작하는 시기가 비슷하여 비슷한 작업을 되풀이하는 것도 있다. 예를들어 시스템을 설계하는 부분이 그런데, 어느 시스템에나 필수적으로 들어가는 기능을 고려하는 단계이자 아직은 서비스별 차별화된 작업을 하지 않는 단계이기도 하다.
한편으로 이 단계야말로 머리를 가장 많이 쓰는 단계기도 하다. 기초작업이라 불리기도 하는데, 이 작업을 얼마나 튼튼하게 하느냐에 따라 이후 작업의 질과 양이 달라지기 때문이다. 건물 짓는걸 비유해보면 공사중이라고 한참 오래 걸려있다가 어느날 뚝딱 세워지는걸 볼 수 있는데, 지반공사에 많은 시간을 할애하다 튼튼하게 마무리되면 위로 올리는건 순식간에 해낸다. 그만큼 기초공사가 중요하단 뜻이다.
이번에 하면서 반성하게 된 점은 반복적인 알고리즘을 매번 새롭게 생각했다는 점이다. 처음부터 추상화, 도식화 해두었다면 다음 만들때도 참고하며 만들면 좋았을텐데 당장 코드를 열어 수정하는 것에 몰두했다. 그러다보니 전반적인 것을 보지 못하고 몇차례 수정을 하다가 겨우나 완성하면 그 노하우를 막연히 아는 것으로 치부하여 다른 프로젝트에서 반복하고 있었다.
이것을 깨달은 것은 모처럼 시간이 남아 프로그래밍 책을 보다 발견한 것이다. 거기서는 이런 설명이 있었는데, 해결이라고 하는 것에는 2가지 유형이 있다. 첫번째는 직접적인 해결이고 두번째는 구조적으로 해결한다는 점이다. 책에선 길을 묻는 것에 대한 해결책을 예로 들었는데, 길을 묻는 사람에게 직접적인 해결방법은 ‘직선으로 500m가서 사거리에서 우회전한다음 한블럭가서 좌회전 하세요’라고 직접 알려주는 것이다. 그에 반해 구조적인 방법은 지도를 제시하는 것이다. 전자는 확실한 방법이지만 길을 물어보는 위치가 어디냐에 따라서, 가려는 곳이 어디냐에 따라 매번 다르게 대답해야 하기 때문에 유연성이 떨어지고 매번 시간을 잡아먹는데 반면, 후자는 한번 익혀두기만 하면 언제든 재활용할 수 있다는 점이 달랐다.
내게 필요한 것은 지도를 만드는 것과 같은 작업이다. 그리고 그 방법을 해야만 반복활동을 줄이고 문제해결에 유연성을 갖게 된다. 이번 프로젝트를 하면서 내가 반드시 극복해내야 하는 과정임을 깨달았고 제 1순위로 두기로 했다. 구조를 보는 것과 아울러 구조를 설계하고 활용하는 방법을 익히는 것, 이번 회고에는 이 깨달음을 얻은 것만으로도 큰 수확이다.
함께 보면 좋은 글:
https://brunch.co.kr/@lemontia/427
https://brunch.co.kr/@lemontia/342