#3 개발하기 전에 치밀한 설계

2006년 대규모 개편이었던 것으로 기억된다.

제로보드4 기반의 인디스쿨은 PHP프로그래밍을 통해 기능을 개선하고 새로운 서비스를 구현하고 있었다.

닉네임 ‘어리버리’ 김광수 선생님이 개발자였고, ‘요술콩’ 최선주 선생님이 웹디자인/마스터링을… 난 서버관리와 함께 대규모 개편을 맡게 되었다.

안양역 앞 대동문고 2층의 북카페에서 여러 사이트들을 벤치마킹하고 개편작업의 전반에 대해 이야기를 나눴고, 작업이 시작되었다.

그 전까지는 시도하지 않았던 것이 하나 있었는데, 스팩문서(라고하면 거창하려나?)를 만들었다는 점이었다. 디자인에 대한 스케치와 구성, 컬러셋, 프로그래밍을 위한 모듈 구성, 프로시저와 함수의 사전설계와 동작 등…

이 문서를 기반으로 디자이너는 자신의 영역을, 프로그래머(코더)는 또 자신의 영역을… 생성된 결과는 서로 공유하면서 적용하고 수정하는 단계가 반복되었다.

요술콩은 역할이 웹다자이너였지만 코드에 대한 이해가 있었기에 어리버리의 코드를 디자인에 반영했고, 미리 제작된 설계에 의해 정확히 구현된 코드는 내부를 알지 못한다 하더라도 바로 사용할 수 있었다. 코드의 길이가 짧다보니 개발문서를 별도로 작성하는 대신에 주석을 상세하게 충분히 달아 소스코드의 이해도를 높이는 방향으로 진행했다.

디버깅과 유지보수의 입장에서도 스팩문서가 바탕이었기 때문에, 셋 중 누구라도 어느 부분을 손대야 할지 알고 있었고, 2006-2009년까지 사용한 인디스쿨의 웹페이지가 완성되었다.

때로는 오랜 시간을 들여 설계를 한다는 것은 시간 낭비처럼 생각된다. 설계와 문서 없이 당장 작업이 시작되면 가시적으로 진행되어 마치 무언가 멋지게 움직이는 것처럼 보일 수 있다.

하지만, 그렇게 만들어진 스파게티 디자인과 코드들이 과연 유지보수 단계에서 살아남을 수 있을까? 부정적이라고 본다.

NEIS시스템이 엄청난 비용을 들여 만들어졌다고는 하지만, 사용자의 입장에서나 유지보수의 입장에서 형편없는 결과를 초래하는 것이 바로 이런 까닭이다. 초기 설계에서 전문가가 아닌 업무전문가가 참여하여 마치 업무를 효율화할 것처럼 거창하게 시작했지만, 전체적인 인터페이스부터 실패하고 개발 단계에서도 삐걱였으며, 오픈 이후 디버깅 단계에서도 일 년 가까이 방향을 잡지 못했다. 설계를 한 사람의 구성과 자질에 문제가 있었다는 것이고, 스팩/개발문서가 완벽하지 않았다는 것이다. 그 당시의 분위기가 그렇기도 했고…

자랑하려는 것은 아니지만, 인디스쿨 역사를 보았을 때, 전문가들도 어려워하는 전문적인 프로세스를 통해 성공한 사례가 있었다는 점은 드러내도 좋은 것 아닌가 싶어 상기해 보았다.

지금 요술콩과 어리버리는 육아에 전념하고 있다. 나 또한…

 

맥노턴.