시소당

프로그래밍 과정에서 작명에 관하여

대형 SI 프로젝트의 경우 경험있는 개발자들에게 찾아볼 수 있는 공통점은 개발에 들어가기 전에 작명 지침을 받고자 한다는 점이다. 작명은 생각보다 간단한 문제는 아니다. 개인적으로는 가장 중요한 설계 결정 중에 하나라고 생각한다.

종 종 그다지 바람직하지 않은 방향으로 작명의 기준이 정해지는 것을 볼 때 화가 나기도 한다. 지금보다 널 노련했을때는 대놓고 화를 냈으니까. 얼마 전에도 가능하면 업무 용어를 번역한 단어를 가능하면 그대로 쓰자는 지침에 대해 약어를 기준으로 해야 한다는 개발자를 만났다. 경험이 많은 개발자였는데 권위에 의존해서 다음과 같이 발언해서 감정을 통제하지 못하고 직격탄을 날리기도 했다:

'S모 전자에서도 약자를 기준으로 한다'
'10년 동안 개발하면서 그런 경우는 본 적이 없다'

나 를 포함해 대부분은 변하기 싫어한다. 그리고, 미래를 위해 더 나은 준비를 하려다 보면 현재에 희생을 요구하는 법이다. 종종 약어를 쓰면 생산성이 떨어진다고 말하는 이들도 있는데 이클립스와 같은 IDE를 쓰지 않는 경우나 통용되는 말이다. (2006/12/20 - [자바 프로그래밍/이클립스 노하우] - 적절한 작명을 손쉽게 할 수 있는 바람직한 습관
참조)

사람의 습성에 관계된 문제 외에도 작명의 어려움은 근본적인 원인이 하나 더 있다. 월간마소에 기고할 DDD 관련 기사를 영문으로 작성해야 하는 프로그램과 우리말 사이의 변환 문제가 얼마나 부담스러운 일인지를 돌아보게 되었다. 실제로 프로젝트를 할 때 분석 모델을 구성하는 클래스의 이름을 설계 클래스로 바꾸는 일은 상당한 공수를 요한다. 게다가 상당한 공수를 요할만큼 중요한 일이기도 하다. 하지만, 노력에 비해 좋은 결과가 나오지는 못한다. 무엇보다 마치 DSL처럼 업무를 잘 드러내는 단어가 쓰여야 한다.

그러나, 대부분의 업체가 업무 용어에 대한 영어대역어를 구비하고 있지는 않다. 고객이 모든 용어를 정해주지도 않는다. 그러다 보니 개발자들이 네OO를 뒤져서 작명을 한다. 그러다 보면 자연스럽게 오역이 일어나기 마련이고, 가독성을 높이려는 시도는 퇴색된다.
자바가 요구하는 일종의 관습을 알아야 하기 때문이다.

개발자와 고객이 같은 언어(Ubiquitous Language)를 쓰도록 유도하거나 같은 공간에 머물게 하는 것(XP에서 개발자를 팀원으로 하라는 지침) 모두는 결국 고객과 개발자 사이의 의사소통이 제대로 되게 함이다. 작명의 어려움은 물론 영문화의 문제도 있지만, 궁극은 고객과 개발자의 소통이 어렵다는 것을 보여주는 반증이기도 하다.

관련 글:
월간마소에 기고할 DDD 관련 기사의 모티브가 담긴 글: 2007/06/27 - [소프트웨어 설계/소프트웨어 모델링] - 산만한 글로 주장하는 단일 모델이 요체다~
DSL과 작명이 무슨 관계냐?:  2006/10/01 - [소프트웨어 설계/인터페이스 설계] - 좋은 작명은 internal DSL의 시작