복합어에 대한 상념(想念)

복합어를 사용하는 이유는 크게 두 가지입니다.

 

첫째, 관용화된 용어를 사용하기 위해서입니다. 대상이 많지는 않지만 단어와 단어가 합쳐져서 뉘앙스가 달라지는 경우가 있습니다. 용어에 민감한 사람들은 이를 관리하고 싶어 합니다.

 

여기서, ‘용어’란 주로 영문 단어를 의미할 것입니다. 한글 단어 조합의 의미를 따지기도 하지만 주로 영문 조합의 의미를 따집니다. 예를 들어, 부가가치세는 ‘부가+가치+세’이지만 영문은 ‘VAT’로 쓰는 게 명확하다는 것이죠.

 

복합어를 사용하는 둘째 이유는 영문(컬럼 명)의 길이가 길어지는 것을 막기 위해서입니다. ‘부가가치세’를 복합어로 만들지 않으면 영문이 ‘VL_AD_TX’ 정도가 됩니다. 단어별로 두 자리의 약어를 사용해도 8자리가 되죠. 이를 복합어로 만들어 ‘VAT’로 정하면 3자리니 훨씬 짧죠.

 

부가가치세에 대한 영문이 꼭 ‘VAT’여야 한다는 것보다는 길어지기 때문에 ‘VAT’를 사용합니다. 이는 현실적인 이유죠. 다시 말해 전자의 이유보다는 후자 때문에 복합어가 많이 쓰입니다.

 

기업에서 주로 사용되는 복합명사는 복합어로 등록해서 영문명이 길어지는 것을 방지할 필요가 있습니다. 도메인 성격의 대표 속성이기도 한 고객번호, 계좌번호, 상품번호 등과 주민등록번호, 전화번호 등은 자주 사용되는 복합명사이기 때문에 복합어로 등록하는 것이 좋습니다. 단어 조합인 ‘CUST_NO’로 하기보다는 복합어인 ‘CUNO’로, ‘ACCT_NO’ 보다는 ‘ACNO’로 정하는 게 효과적이죠.

 

복합어를 사용하는 문제는 복합어를 나중에 만들 때 발생합니다. 예를 들어 모두 단어로 구성된 ‘랩+어카운트+계좌+개설+확인+사원+번호’는 영문으로 변환하면 매우 길어집니다. 만약 DBMS에서 30자라까지 허용한다면, 영문을 줄이기 위해 단어를 적절하게 합쳐서 복합어를 만들어야 합니다.

 

(오라클은 컬럼 명을 30글자까지 허용하는데, 30자면 매우 길어서 그렇게 긴 컬럼 명이 있을까 싶지만 비교적 빈번하게 발생한다. 이를 방지하는 두 가지 방법은 이 글의 주제인 복합어를 활용하는 것과 단어의 영문 약어를 짧게 정하는 것이다.

 

후자의 경우, 가독성 때문에 단어의 영문 약어를 자세히 정한다면 컬럼 명이 매우 길어질 수 있다. 단어에 대한 영문 약어를 일괄 4글자로 정하기도 하는데 바람직하지 않다. 2~3글자로 정하는 것이 좋다.)

 

컬럼 명을 줄이기 위해 복합어를 만들지 않으려면 속성 명을 수정해야 하는데, 이는 당연히 의미가 손상되지 않는 경우에만 허용됩니다. 하지만 속성 명에는 생략해도 의미가 통하는 단어만 사용하는 게 원칙이기 때문에, 이렇게 정해진 속성 명에서 특정 단어를 생략하면 의미가 통하지 않는 게 당연합니다. 속성 명을 임의로 줄여서 컬럼 명의 길이를 줄이는 방법은 사용하기 어렵습니다.

 

이렇게 뒤늦게 복합어(‘랩어카운트’)가 생기면 이전에 사용하던 것(‘랩+어카운트’)과의 혼선이 발생합니다. 위의 경우 ‘랩어카운트’라는 복합어를 만들어서 해결했다면, 이미 사용되던 ‘랩+어카운트’와 영문이 달라지게 됩니다. ‘WAC’와 ‘WR_AC’ 정도로 다르게 쓰이죠. 이는 큰 문제는 아니지만 어쨌든 표준을 해치는 일입니다.

 

이런 표준화 위배를 최소화하기 위해서는 복합어 ‘랩어카운트’는 ‘랩어카운트계좌개설확인사원번호’ 속성에만 사용해야 합니다. 그리고 추후에 ‘랩+어카운트’로 인해 길이 제약이 생기는 속성이 생긴다면 그 경우에 사용해야 합니다.

 

불가피한 경우만 나중에 생긴 복합어 ‘랩어카운트’를 허용하고 표준은 애초의 표준인 ‘랩+어카운트’가 돼야 하는 것이죠. 이를 피하기 위해서는 애초에 복합어를 제대로 등록하는 게 중요합니다.

 

모델 구조에 비하면 위와 같은 표준화 문제는 크지 않을 수 있습니다. 하지만 원칙을 정했다면 원칙에 맞도록 사용하는 것이 바람직합니다. 잘못된 원칙은 개선하는 게 맞고요.

 

제대로 된 원칙을 지킬 의지가 없거나, 제대로 되지 않은 원칙을 개선할 의지가 없다면 좋은 시스템이 되기 힘들 것입니다. 시스템뿐만 아니라 모든 분야가 마찬가지겠죠.