Convention over Configuration(CoC)에 관하여

Ruby on Rails의 확산과 Aspect-Oriented Programming(AOP)의 확산으로 인하여 많은 분들이 Convention over Configuration(CoC)에 관하여 많은 관심을 가지거나 한번정도씩은 들어보신 경험이 있을 것입니다.

하지만 Convention over Configuration(CoC)만을 설명하는 자료가 부족한듯합니다. 최근 하는 일중에 독자들에게 명확하게 Convention over Configuration(CoC)에 관하여 설명할 필요가 있는 일이 있는 관계로 Wikipedia의 자료를 바탕으로 Convention over Configuration(CoC)에 대한 개념을 정리하였습니다. 이런 개념이 나올때마다 얼마나 Wikipedia가 고마운지~ ;-)

보시면서 부족한 점이 있다면 적극적인 피드백이나 참고자료에 관한 조언부탁드립니다.
최근 개념이 부족해서 그런지 이런 개념을 정리하는 작업이 재미있네요~ :-)

---

Convention over Configuration(CoC)

우리나라에서는 일부 "설정 이상의 관례", "설정보다 관례", "설정을 넘은 관례" 혹은 "설정보다 규범" 등으로 번역하고 있는 Convention over Configuration는 최근 국내에서 CoC로 번역이 통일되어 가고 있는 것 같습니다.

저 역시 CoC를 어떻게 번역할까 많은 고민을 하였으며, 지인들에게도 물어보기도 하였는데, 우리나라에서 사실상의 표준(De-facto)로 CoC로 자리잡혀 가고 있는것 같으며, 저 역시 애매한 번역보다는 CoC가 표기 및 의미 면에서 독자들에게 더 쉽게 이해될 것으로 생각되어 CoC로 번역하기로 결정하였습니다. CoC의 모습이 마치 이모티콘 같아서 쉽게 기억될 것 같습니다. :-)

Convention over Configuration(이하 CoC)는  Coding by Configuration이라고도 알려져 있습니다. 항상 개념이란것이 그러하듯이 CoC 개념 자체는 매우 단순합니다.


CoC는 개발자가 내려야할 수 많은 결정들(decisions)을 줄여주어, 단순성(simplicity)을 확보하면서, 유연성(flexibility)을 잃어버리지 않도록 하기 위한 소프트웨어 디자인 패러다임 입니다.


CoC의 단어상의 근본적인 의미는 개발자는 단지 어플리케이션에서 관습적이지않은 면(unconventional aspects of the application)만 정의할 필요가 있다는 것입니다. 예를들어 Model에 Sale이란 클래스가 있다면, 데이터베이스 내에 대응하는 테이블은 기본적으로 sales라고 불리운다라는 관례(convention)가 있다면, 모든 데이터베이스에 테이블을 생성할때 테이블 명을 관례에 따라 작성한다면 자연스럽게 모델에 대응될 것입니다. 만약 이 관례에 벗어나는 테이블인 products_sold와 같은 테이블이 있는 경우에만, 개발자들은 이러한 테이블 명에 대응하는 코드를 작성할 필요가 있다는 것입니다.

여러분이 원하는 기능들에 일치하는 관례에 따라 툴에 의하여 개발한다면, 여러분들은 설정 파일을 작성할 필요없이 이러한 장점들을 누릴 수 있는 것입니다.

만약 여러분들이 Spring Framework 1.x를 사용해본 경험이 있다면, 수 없이 많은 XML 들을 xdoclet을 통하여 작성하여야만 했을 때의 고통을 잘 알것입니다. 하지만 여러분들이 개발하시려는 어플리케이션의 공통적인 관례(Common Conventions)들만 통일시켜 놓는다면 AOP와 같은 툴을 통하여 이런한 설정의 고통에서 벗어날 수 있다는 의미입니다.

현재 Spring 2.x대에서는 이러한 설정의 고통들이 많이 해결되었으며, Spring 2.5에서는 별다른 설정없이 어노테이션(Annotation)을 통하여 특별한 설정외에는 별다르게 설정할 필요가 없어 개발자들에게 고통을 가져다주면 의미없는 설정들을 하기 위한 결정을 할 필요가 없어졌습니다. 즉 일관된 관례를 통하여 공통적인 관례에 따르는 개발을 진행할 경우에는 개발자의 수고가 많이 줄어드는 장점이 있습니다.

하지만, 이러한 공통의 관례는 모두가 알고 있어야 한다는 점을 주의하여야 합니다.
즉 공통 부분을 책임지시는 분들의 경우 CoC 기반의 개발을 지원하고 계신다면, 공통 프레임웍이나 유틸리티 뿐만 아니라 개발자들에게 공통의 개발 관례까지 지원하여야 합니다. 만약 관례를 벗어나는 개발을 하는 경우에 공통된 관례를 따르지 않으므로, 공통의 관례를 따를 때 자동으로 지원하였던 트랜잭션 처리, 로깅 등의 처리를 개별적으로 처리할 수 있는 방안까지 마련해주어야 하며, 이를 최소화 할 수 있도록 개발자들에게 공통의 관례에 대한 이해를 높일 수 있도록 지속적으로 교육을 할 필요가 있습니다.


CoC는 실질적으로 추상화 레이어를 생성하지 않고도 높은 수준의 추상화 작업을 프로그래머들이 할 수 있도록 지원하는 프로그래밍적인 접근 방식이며, 수 많은 설정들에서 프로그래머들을 해방시켜줍니다.


CoC의 동기
전통적으로, 프레임웍은 여러 다중 설정 파일들을 필요로하며, 각 설정 파일은 많은 설정들을 포함하고 있습니다. 이러한 설정 파일들은 각 프로젝트에 맞는 특정한 정보를 제공하며, 이러한 설정의 범위는 URL에서부터 클래스들과 데이터베이스 테이블 사이의 매핑까지입니다. 즉 엄청나게 다양할 수 있다는 의미입니다. 어플리케이션의 복잡도에 따라 이러한 설정 파일들의 수와 크기는 매우 쉽게 늘어납니다. 이에따라 설정의 방법도 복잡해지며, 이러한 설정을 개발자가 일일이 하여야 하기 때문에 개발의 속도는 감소되며, 개발의 복잡도는 증가하게 됩니다.

예를들어, 잘 알려진 자바 영속성 매퍼(Java persistence mapper)인 Hibernate의 이전 버전의 경우, 엔티티들을 엔티티에 대응하는 데이터베이스의 필드를 연결시키기 위하여 XML 파일 안에 각 관계를 기술하여야 하였습니다. 클래스(class) 명은 데이터베이스의 테이블(table) 명 같으며, 필드(field) 명은 컬럼(column)과 각각 같도록 관례적으로 표현하였기 때문에 대부분의 정보는 이러한 정보들을 가지고 있었습니다. CoC를 채용한 이후의 버전에서 이러한 XML 설정 파일들 대신 많은 관례(convention)들을 채용하였으며, 자바의 어노테이션을 사용하여 이러한 변화를 수용하였습니다.


활용
대부분의 현대적인 프레임웍에서는 CoC적인 접근방법을 사용하고 있습니다.
CoC는 현재 Ruby on Rails, Zend Framework, Grails, Spring, Castle MonoRail, JUnit, JBoss Seam, CakePHP, symfony 와 Kohana에 포함되어 있습니다.


참고자료

• http://en.wikipedia.org/wiki/Convention_over_Configuration
• http://softwareengineering.vazexqi.com/files/pattern.html

---

Wikipedia 덕분에 정리가 점 되었습니다.

http://softwareengineering.vazexqi.com/files/pattern.html를 보면 CoC는 패턴으로도 나와 있는데, 추후 CoC에 패턴적인 의미를 고찰해 보겠습니다.
감사합니다. :-)