최근 읽고 있는 ‘소프트웨어 컨플릭트 2.0′에 표준과 관련된 컬럼이 있어서 소개한다. (사실 15년 전에 처음 작성된 컬럼이지만 세상의 본질은 그렇게 쉽게 변하는 것은 아닌가 보다.)

표준과 표준 준수: 정말 소프트웨어 품질을 높이는 데 도움이 되나?

표준을 정립하는 목적은 제품 품질과 프로그래머 생산성을 높이기 위해서이다.

1. 표준은 간결하고 핵심적이어야 한다. ‘필수’ 규칙은 신속하게 습득하고 쉽게 적용하고 편리하게 준수하도록 도와주는 간략한 메뉴얼로 다듬어야 한다. 필수는 아니지만 선호하는 정교한 방식이 있다면, 표준이 아니라 지침으로 명시하고 별도로 문서를 만든다. 지침서는 아주 길어도 괜찮다. 프로그래머가 읽어서 도움이 될 정보를 담고 있으며 규칙을 강제할 필요나 의도가 없으므로 분량은 그다지 문제가 되지 않는다.
2. 표준은 회사에서 프로그래밍 기량이 가장 뛰어난 사람이 작성하고 검토해야 하며, 시간이 남는다고 아무에게나 맡겨서는 안된다. 모두에게 강조하고 준수시킬 규칙이므로 마땅히 최고 두뇌에게 맡겨야 한다.
3. 표준 준수는 의무적이어야 하며, 시간이 남으면 따르는 선택이 되어서는 안된다. 표준 문서를 줄이겠다고 결단을 내린 후 진짜 핵심만 남기면, 표준 준수에 따르는 비용은 급격하게 줄어든다. 표준 준수 절차는 자동화된 검사 기능과, 검토 활동을 포함해야 한다. 동료간 코드 검토는 표준을 준수하는 중요한 방법 중 하나인데, 단순히 표준 준수 여부보다는 전반적인 품질 향상에 초점을 맞춰야 한다.

표준이 ‘must’라면 가이드(지침)은 ‘had better’일 것이다. 즉, 표준은 가능한 간결하게 작성해서 쉽게 습득하고 적용할 수 있어야 하며, 그 외의 권고 사항은 가이드로 따로 제공해 주는 것이 효과적이다.

그리고 표준 작성은 표준을 가장 잘 만들 수 있는 사람이 담당해야 한다. 표준 작성자는 현업의 이해도가 높아야 하며 최고 수준의 코드를 만들 수 있는 사람으로 지정되야 한다.

그리고 마지막으로 표준이 준수되는지 지속적으로 확인해야 한다. 표준 검사 툴을 만들 수도 있겠지만 모듈 개발자들이 서로의 코드를 검토하는 과정을 통해 코드 품질을 향상시키는 방식이 가장 효과적일 것이라 생각된다.

서비스 개발자와 플랫폼 개발자 간의 견해 차이 때문인지 개발자에게 자유도를 주는 것 보다는 쉽게 기능을 제공해 주는 쪽에 무게중심이 실린 것 같다. 결국 얼마나 서비스 기능을 모듈화할 수 있을지가 관건이 되었는데, 게시판, 테스터 모집, 이벤트, 웹 상점 등의 웹 서비스 기능들이 글로벌 환경에서 재사용 가능한 형태로 만들어져야 한다.

(사실 개인적으로는 DB 쿼리를 포함한 100% 구현된 기능이 글로벌 환경에서 재사용될 수 있을 것이라고 생각하지는 않지만 가능한 방법을 찾는 것이 나의 미션이니 고민해 볼 수 밖에….)

현재 개발하는 웹 플랫폼은 Webwork, Spring, iBatis를 중심으로 구성되어 있다. Webwork나 Spring은 충분히 모듈화에 대한 고민이 담겨져 있는 프레임워크이기 때문에 이를 잘 활용한다면 유연한 모듈간의 결합도 가능할 것이라 생각한다. 물론 프레임워크를 100% 활용할 수 있는 실력이 필요한데 매번 공부해야 할 꺼리들만 늘어나고 있다.

또 다른 고민거리는 모듈에 다양한 옵션을 제공해 주는 기능을 어떻게 구현할 수 있는가 하는 것이다. 일반적으로 CMS(Content Management System) 같은 경우는 DB에 옵션을 저장해 놓고 캐시를 사용해서 이 옵션을 매번 읽어 오는 방식을 취하고 있다. 하지만 이렇게 구성하는 경우 모듈 어드민(모듈 옵션 설정)과 서비스 어드민(서비스 운영)이 별도로 필요하며 이 기능들이 상호 의존적으로 연결되게 된다. (이는 결과적으로 글로벌 재사용성을 저하시킨다.)

다른 대안으로 AOP를 활용하는 방법이 있을 것 같다. Spring의 동적 AOP와 AspectJ의 정적 AOP를 적절히 조합해서 모듈의 기능을 효과적으로 통제할 수 있지 않을까. 서비스 모듈을 모듈 Pool에서 서비스로 이식할 때 옵션에 따라 AspectJ로 Weaving 해서 jar 파일을 만들 수 있고, 동적인 기능은 Spring AOP 설정 기능을 통해 변경이 가능할 것이라 판단된다.

AOP가 기능별 흐름을 분기해주거나 조건에 따라 레이어를 묶기 위한 기능이기 보다는 코드에 중복된 Aspect를 분리한 후 다시 조건에 맞춰 연결해주는 기능이지만 모듈 생성 시에 기능을 엮어주는 역할로도 사용될 수 있을 것 같다.

마지막으로 Script 언어를 활용해서 Domain Specific 기능을 변경 가능하도록 해주는 방법도 있을 것 같다. 이 방법은 글을 쓰다 생각이 났는데, 더 고민해봐야 구체적인 구현 방법이 정리될 것 같다.

※ 자신이 작성한 프로젝트에서 AOP 사용의 필요성을 판단해 볼 수 있는 Eclipse Plugin을 소개한다. 작년 OOPSLA 2006 ETX workshop에서 발표된 두 편의 논문을 참고하면 된다. HAM, CloneDR AJDT Visualiser