같은 말이 세 시스템에서 다른 뜻이다

한 줄 요약

"활성 고객이 몇 명이죠" 라는 질문에 세 사람이 세 숫자를 답하고 셋 다 맞을 수 있다. 용어를 식별자에 묶어 두지 않으면 그 뒤의 모든 숫자가 조용히 어긋난다.

왜 이게 필요했나

현장 둘째 날쯤이면 회의에 불려 간다. 누군가 "지난달 활성 고객이 몇 명이었죠" 라고 묻고, 영업 담당이 3만 4천이라 하고, 청구 담당이 3만 1천이라 하고, 운영 담당이 2만 6천이라 한다. 세 사람이 서로를 이상하다는 듯 본다.

아무도 틀리지 않았다. 영업 시스템은 고객 표의 상태 글자가 A 인 행을 세었고, 청구 시스템은 청구가 가능한 계정을 세었고, 운영 시스템은 최근 30일 안에 로그인한 사람을 세었다. 세 정의는 각자의 업무에서 전부 옳다. 틀린 것은 하나의 낱말이 세 정의를 다 담고 있다고 믿은 것이다.

이 어긋남이 무서운 이유는 오류로 드러나지 않기 때문이다. 쿼리는 성공하고, 대시보드는 숫자를 그리고, 보고서는 인쇄된다. 드러나는 순간은 대개 그 숫자로 무언가를 결정한 뒤다.

어떻게 동작하나

고치는 방법은 낱말을 금지하는 것이 아니다. 사람들은 계속 "고객" 이라고 말할 것이고, 그래야 한다. 대신 낱말과 식별자를 잇는 표를 만든다. 용어 하나가 시스템마다 어느 표의 어느 칼럼을 어떤 조건으로 고른 것인지 한 줄씩 적으면, 그때부터 숫자는 어긋나도 설명이 된다.

대조표 한 줄에 들어갈 것은 넷이다 — 시스템, 표, 식별자 칼럼, 그리고 조건. 조건이 빠지면 표는 절반만 쓸모가 있다. "활성" 의 차이는 표가 아니라 조건에 있기 때문이다.

표를 만든 다음에는 숫자로 확인한다. 같은 이름의 집합이 시스템마다 얼마나 큰지, 두 집합이 얼마나 겹치는지를 재는 것이다. 겹침은 교집합과 차집합으로 보고, 한 숫자로 줄이고 싶으면 자카드 계수를 쓴다.

자카드 계수 = |A 교집합 B| / |A 합집합 B|1.0  두 집합이 완전히 같다        — 이름이 같아도 괜찮다0.8  대체로 같고 한쪽이 조금 넓다  — 경계 조건을 확인한다0.0  겹치는 것이 없다             — 같은 이름을 쓰면 안 되는 관계다

여기서 대부분이 넘어지는 자리가 하나 더 있다. 두 집합을 견주려면 "같은 것" 이 무엇인지부터 정해야 한다. 사람을 이메일로 잇는다고 하자. 영업 시스템에는 User07@Example.com 이, 청구 시스템에는 user07@EXAMPLE.COM 이, 운영 시스템에는 꼬리 공백이 붙은 user07@example.com 이 들어 있다. 이 셋을 같다고 볼 것인가.

[RFC 5321 의 2.4 절](https://www.rfc-editor.org/rfc/rfc5321.html)은 이 질문에 정확한 답을 준다. 메일 주소의 로컬 파트(@ 앞)는 대소문자를 가린다(MUST BE treated as case sensitive). 반면 도메인은 DNS 규칙을 따르므로 가리지 않는다. 규격대로라면 User07@Example.com 과 user07@example.com 은 다른 주소다. 같은 절은 이어서, 로컬 파트의 대소문자를 실제로 구별해 쓰는 것은 상호운용을 해치므로 권하지 않는다고도 적는다.

그래서 현장에서 쓰는 정규화는 둘 중 하나다.

• 규격을 따르는 정규화 — 공백을 떼고 도메인만 소문자로 눕힌다. 로컬 파트는 건드리지 않는다.
• 시스템의 실제 동작을 따르는 정규화 — 전부 소문자로 눕힌다. 대부분의 사내 시스템이 이렇게 동작한다.

어느 쪽이 맞는지는 문서가 아니라 그 고객의 시스템이 정해 준다. 중요한 것은 고르는 일 자체가 아니라, 고른 규칙을 적어 두고 모든 집계에 같은 규칙을 쓰는 것이다. 규칙을 바꾸면 겹침이 통째로 달라진다 — 위의 세 시스템은 규격대로 보면 겹치는 사람이 한 명도 없고, 전부 소문자로 눕히면 거의 다 겹친다.

현장에서 만나는 모습

첫째, 같은 이름 다른 것보다 다른 이름 같은 것이 더 흔하다. 영업은 email, 청구는 billing_email, 운영은 login_email 이라 부르지만 셋 다 같은 사람을 가리킨다. 이름이 다르니 아무도 대조하지 않고, 그래서 세 시스템에 같은 사람이 세 번 들어 있다는 것을 아무도 모른다.

둘째, 완전히 다른 것에 같은 이름이 붙기도 한다. 창고 운영팀은 "주문" 이라는 말을 창고 작업 지시라는 뜻으로 쓴다. 영업의 주문 300건과 운영의 주문 180건은 겹치는 것이 하나도 없다. 이런 관계는 자카드가 0 으로 곧바로 드러난다 — 표만 있으면 5분이면 알아낼 수 있는 것을 몰라서 2주를 헤맨다.

셋째, 대조표를 회의록에 적으면 사라진다. 파일로 두고 집계 도구가 그 파일을 읽게 해야 한다. 그러면 용어 정의가 바뀔 때 숫자도 함께 바뀌고, 바뀌지 않으면 누군가 대조표를 고치지 않았다는 뜻이다.

넷째, 충돌을 찾았다고 곧바로 고치려 들면 안 된다. 세 시스템의 "활성" 정의를 하나로 통일하자는 제안은 세 팀의 업무를 동시에 바꾸자는 말이다. 첫 주에 할 일은 통일이 아니라 보고서마다 어느 정의를 썼는지 적는 것이다.

실무에서 진짜 중요한 것

• 낱말을 금지하지 말고 식별자에 묶는다. 사람들은 계속 자기 말을 쓸 것이다.
• 조건까지 적는다. 활성의 차이는 표가 아니라 조건에 있다.
• 정규화 규칙을 먼저 정하고 모든 집계에 같은 것을 쓴다. 규칙이 바뀌면 답이 바뀐다.
• 숫자로 확인한다. 용어 충돌은 의견이 아니라 집합의 크기와 겹침으로 증명한다.

다음 실습에서 할 것

(가상) 하나유통의 시스템 세 대를 한 파일에 담은 스냅샷을 손에 쥔다. 세 시스템이 "고객"·"활성"·"주문" 을 각각 어느 표의 어느 칼럼을 어떤 조건으로 부르는지 대조표로 적고, 집합의 크기를 재고, 두 시스템씩 견주어 겹침을 낸다. 그다음 식별자 정규화를 규격대로 한 번, 시스템의 실제 동작대로 한 번 적용해 답이 통째로 달라지는 것을 본다. 채점기는 매번 다른 표와 값으로 만든 데이터베이스에 여러분의 집계기를 실제로 돌려 숫자를 대조한다. 마지막에는 같은 이름 다른 집합과 다른 이름 같은 집합을 갈라내 보고서로 낸다.