거래처 코드 한 줄을 어떻게 둘까 — 모던 트렌드와 한국 운영 현실 사이

데이터 모델링 결정 한 줄에 며칠이 걸렸습니다

운영 중인 B2B SaaS에서 거래처(파트너 회사) 식별자를 어떻게 둘지 다시 결정해야 했습니다.

현재 구조는 이렇습니다. 거래처 테이블에 짧은 비즈니스 코드 컬럼이 있고, 이 컬럼이 9개 다른 테이블의 FK로 사용되고 있습니다. 처음 설계할 때 의도는 명확했습니다. 사람이 부여하는 짧은 코드를 만들어서 운영자가 거래처를 부를 때 사용한다는 것이었습니다.

시간이 지나면서 이 컬럼이 흐트러졌습니다.

외부 시스템과 동기화하면서 들어온 8자리 영숫자 코드가 섞여 있음

처음 의도였던 짧은 코드와 형식이 일치하지 않음

관리자 웹의 등록 폼이 disabled 처리되어 운영자가 직접 입력 못 함 (스펙 위반/버그)

회원이 거래처를 등록할 때 입력하는 코드는 별도 6자리 인증 코드로 분리되어 있어, 본래 컬럼은 회원 채널에서 쓸모가 없어진 상태

요약하면 컬럼의 의미와 실제 데이터, 사용 방식이 다 어긋난 상태였습니다. 이걸 어떻게 정리할지가 결정 사항이었습니다.

두 가지 옵션을 검토했습니다

옵션은 두 가지였습니다.

옵션 A — 현 상태 유지, 등록 폼 fix만

비즈니스 코드 컬럼을 그대로 두고, 관리자 웹에서 운영자가 입력할 수 있도록 disabled 처리만 풉니다. 9개 테이블의 FK 구조는 변경 없음. 빠른 길입니다.

옵션 B — ID 기반 전환

PK를 BIGSERIAL 또는 UUID로 두고, 외부 시스템 매칭이 필요한 코드는 별도 컬럼으로 분리합니다. 9개 테이블 마이그레이션, 코드 약 60군데 변경, API 경로 변경까지 따라옵니다. 작업 기간은 수일에서 수주.

기술적으로 더 깔끔한 건 명백히 B입니다.

마지막 두 줄이 결정의 핵심이었습니다.

글로벌 트렌드는 ID 중심입니다

모던 SaaS 사례를 보면 거의 다 ID 중심 구조입니다.

국내 핀테크·플랫폼 신규 서비스: 내부 PK는 BIGSERIAL 또는 UUID, 외부 매칭은 사업자등록번호 같은 표준 식별자를 별도 컬럼으로

글로벌 SaaS: 비즈니스 코드를 사용자에게 노출하지 않음. 사용자는 회사명·로고로 식별, 시스템 내부는 ID로 통일

이 구조의 장점이 명확합니다.

코드 중복 걱정 없음

외부 시스템과 매핑 시 유연함

사용자가 코드를 외울 필요 없음

마이그레이션 부담이 미래에 발생하지 않음

데이터 모델링 책이나 모범 사례 자료를 보면 거의 다 B 방향을 권합니다. 그래서 처음에는 B로 가는 게 자연스러워 보였습니다.

그런데 운영 현실은 달랐습니다

옵션 B로 결정하기 전에 한 가지를 점검했습니다. 사용자(운영자, 거래처 담당자)가 실제로 어떻게 부르는가.

확인해보니 운영 현장에서는 거래처 코드를 호명하는 습관이 매우 강했습니다.

운영팀 간 소통: "O001 거래처에서 문의 왔어요"

거래처와 통화: "저희 코드 O001번입니다"

내부 회의: "O001, O042 두 거래처가 같은 이슈예요"

엑셀 작업: 거래처를 코드로 정렬·필터

이 습관이 단순히 "익숙해서"가 아니었습니다. B2B 환경에서 거래처 호칭이 회사명보다 코드가 더 효율적이었습니다. 회사명은 길고 헷갈리고 동음이의 가능성도 있는데, 코드는 짧고 명확합니다.

만약 옵션 B로 가면 어떻게 될까요? 운영자가 사용하던 코드가 갑자기 사라지거나, 새 코드 체계로 바뀝니다. 거래처와 소통하던 모든 채널이 함께 흔들립니다. 운영 마찰이 발생합니다.

측정 가능한 비용 vs 측정 어려운 마찰

결정의 결정적 순간이 여기서 왔습니다.

옵션 B의 비용은 측정 가능합니다.

9개 테이블 마이그레이션

코드 60여 군데 변경

API 경로 변경

수일~수주 작업

이건 견적 산정이 가능한 수치입니다. 개발자가 며칠 시간 빼서 정리하면 끝납니다.

옵션 B로 갔을 때 발생하는 운영 마찰은 측정이 어렵습니다.

운영자가 새 코드 체계에 적응하는 데 걸리는 시간

거래처와 소통할 때 발생하는 혼란

기존 엑셀·매뉴얼·교육 자료 전부 갱신

"예전 코드로 찾아주세요"라는 요청이 계속 들어옴

적응 기간 동안 누적되는 작은 불만들

이 비용은 견적에 안 잡힙니다. 그래서 보통 무시당합니다. 그런데 운영 환경에서 실제로 가장 큰 부담입니다.

마이그레이션 비용은 한 번 지나가지만, 운영 마찰은 매일 누적됩니다. 사용자가 "예전이 더 편했는데"라고 느끼는 순간 그 시스템에 대한 신뢰가 깎입니다.

결정은 옵션 A였습니다

종합한 결과 옵션 A — 비즈니스 코드 유지 + 등록 폼 fix로 결정했습니다.

근거를 정리하면 이렇습니다.

운영자와 거래처가 실제로 코드를 부르며 소통하는 습관이 강함

내부적으로 코드를 따는 프로세스가 익숙해 보임

마이그레이션 비용보다 운영 마찰 비용이 더 클 것으로 예상

글로벌 트렌드보다 현장의 호명 행동을 우선

기술적으로는 분명 옵션 B가 깔끔합니다. 하지만 데이터 모델은 깔끔함이 아니라 사용자의 사용 방식과 일치해야 한다는 원칙이 더 우선이었습니다.

다만 옵션 A로 가더라도 손볼 곳은 있었습니다.

등록 폼 disabled 해제

외부 시스템에서 들어온 8자리 코드와 자체 의도 코드가 섞인 부분 정리

신규 등록 시 형식 검증 추가

회원 채널의 6자리 코드와 비즈니스 코드의 역할 분리 명시

이런 정리 작업은 옵션 A 범위 안에 들어갑니다. 큰 마이그레이션 없이 진행 가능합니다.

"이 코드를 전화로 불러본 적 있는가"

이번 결정에서 가장 강력한 의사결정 신호 하나를 발견했습니다.

"이 코드를 전화로 불러본 적 있는가."

이 질문이 데이터 모델링 결정에 놀랍게 좋은 신호였습니다.

전화로 부른다 → 사용자에게 노출되는 식별자다 → 비즈니스 코드로 두는 게 자연스러움

전화로 부르지 않는다 → 시스템 내부에서만 쓰는 식별자다 → ID로 두는 게 자연스러움

거래처 코드는 전화로 부릅니다. "O001번 거래처"라고 말이죠. 그래서 비즈니스 코드 형태가 맞습니다.

반면 회원의 내부 ID는 전화로 부르지 않습니다. 회원에게 "당신의 ID는 12345번입니다"라고 말할 일이 없죠. 그래서 BIGSERIAL로 두면 됩니다.

이 단순한 질문이 글로벌 트렌드와 운영 현실 사이의 어느 쪽으로 가야 하는지 알려줍니다.

의사결정자가 점검할 4가지

이 사건에서 나온 일반 원칙을 의사결정 관점에서 정리하면 네 가지가 됩니다. SaaS 데이터 모델링·솔루션 도입·시스템 리팩토링 결정 시 활용하시면 됩니다.

1. 사용자가 그 식별자를 어떻게 부르는지 확인합니다

운영팀, 고객사, 거래처가 그 코드를 전화로·메일로·회의에서 부르고 있다면 그건 비즈니스 코드입니다. 부르지 않는다면 ID로 충분합니다. 이 확인은 30분이면 끝납니다.

2. 마이그레이션 비용보다 운영 마찰 비용을 더 크게 봅니다

마이그레이션은 한 번 지나가지만 운영 마찰은 매일 누적됩니다. 견적에 잡히지 않는 비용이 더 무서운 경우가 많습니다.

3. 글로벌 트렌드와 한국 운영 환경의 차이를 인정합니다

모던 SaaS 사례가 ID 중심이라고 해서 모든 환경에 맞는 건 아닙니다. 한국 B2B 환경은 코드 호명 문화가 강합니다. 일본도 마찬가지입니다. 이건 "구식"이 아니라 "이 환경의 특수성"입니다.

4. 데이터의 일관성보다 사용 방식의 일치를 우선합니다

깔끔한 데이터 모델보다 사용자의 사용 방식과 일치하는 모델이 더 좋은 모델입니다. 깔끔함은 개발자가 좋아하는 것이고, 일치는 운영자가 좋아하는 것입니다.

비슷한 발상이 다른 운영 결정에서도 흐릅니다. 사용자의 실제 행동을 관찰하고, 그 행동에 맞춰 시스템을 설계한다는 원칙. 트렌드를 따르는 것보다 사용자를 따르는 것이 운영 시스템의 핵심 기준입니다.

마무리

거래처 식별자를 어떻게 둘지 결정하는 데 며칠이 걸렸습니다. 기술적으로 더 깔끔한 옵션 B(ID 기반 전환) 대신 옵션 A(비즈니스 코드 유지)를 선택했습니다. 운영자와 거래처가 실제로 코드를 호명하고 있었고, 마이그레이션 비용보다 운영 마찰 비용이 더 클 것으로 판단했기 때문입니다.

핵심 교훈은 세 가지입니다.

데이터 모델링은 트렌드가 아니라 호명 행동을 따른다 — 사용자가 그 식별자를 어떻게 부르는지가 결정 기준

측정 어려운 운영 마찰이 측정 가능한 마이그레이션 비용보다 클 수 있다 — 견적에 안 잡히는 비용을 보는 시야가 중요

"전화로 불러본 적 있는가"가 좋은 의사결정 신호 — 노출되는 식별자는 비즈니스 코드, 내부 식별자는 ID

SaaS 데이터 모델링이나 솔루션 도입을 검토 중이라면, 이번 글의 4가지 체크리스트(사용자의 호명 방식 확인 / 운영 마찰 비용 측정 / 환경 특수성 인정 / 사용 방식 일치 우선)를 한 번 점검해보시길 추천합니다. 트렌드를 따르기 전에 사용자를 따르는 것이 더 안전한 결정이었습니다.