뒤로 가기개발 이야기
2025-10-31
5분

여러 고객을 하나의 관리테이블로 변경한 이유

"세무보조 프로그램에서 기존에는 기장고객, 컨설팅 및 신고대리고객, 단순상담고객으로 구분했던 테이블을 하나의 통합 관리테이블로 변경한 이유와 과정을 설명합니다."

#SQL#데이터베이스
여러 고객을 하나의 관리테이블로 변경한 이유

직접 제작한 세무보조 프로그램을 운영하면서 가장 먼저 만들었던 것은 고객 관리 기능이었습니다. 처음에는 고객의 유형에 따라 테이블을 분리했습니다. 하지만 6개월 정도 운영 후, 하나의 통합 관리테이블로 변경하는 결정을 내렸습니다.


초기 구조: 유형별 분리된 테이블

처음 고객 관리 시스템을 설계할 때, 다음과 같이 고객 유형별로 테이블을 구분했습니다:

  • 기장고객 테이블: 장부 작성을 의뢰하시는 분들
  • 컨설팅 및 신고대리 고객 테이블: 세무 컨설팅과 일회성 신고대리(부가세, 종소세, 양도세 등)를 요청하시는 분들
  • 단순상담고객 테이블: 일회성 상담만 진행하시는 분들

이렇게 구분한 이유는 각 유형별로 빠르게 관리하고, 필요한 정보만 선택적으로 입력하기 위해서였습니다.

[기존 테이블 구조]
1. consultation_customer_table
2. business_customer_table
3. tax_proxy_customer_table

초기 구조

기장고객 테이블
  • 사업자정보
  • 장부내역
  • 신고이력
컨설팅 및 신고대리 고객 테이블
  • 사업자정보
  • 컨설팅내역
  • 신고대리내역
단순상담고객 테이블
  • 기본정보
  • 상담내역

운영 중 발견한 문제점

약 6개월간 운영하면서 다음과 같은 불편함을 경험했습니다:

1. 고객 유형의 변화

고객의 유형은 고정되어 있지 않습니다. 실제 사례:

  • 기장고객 → 컨설팅 고객: 처음엔 기장만 의뢰하시다가 사업 확장으로 컨설팅이 필요해지신 경우
  • 컨설팅 및 신고대리 고객 → 기장고객: 세무 전략 검토 후 장부 작성을 본격 시작하시는 경우
  • 모든 유형 → 상담: 간단한 질문이 생길 때마다 일회성 상담이 필요하신 경우

2. 중복 데이터 입력

현재 구조에서는 각 테이블마다 기본 정보(사업자명, 연락처, 사업자등록번호 등)를 별도로 입력해야 했습니다. 같은 고객이 여러 유형에 해당하면 정보가 분산되어 관리가 어려웠습니다.

3. 통합 조회의 어려움

한 고객의 모든 이력을 보려면 여러 테이블을 오가며 조회해야 했습니다:

  • 기장 고객 테이블에서 장부 이력 확인
  • 컨설팅 고객 테이블에서 컨설팅 내역 확인
  • 상담 고객 테이블에서 상담 기록 확인

이 과정이 번거롭고, 전체적인 고객 관계를 한눈에 파악하기 어려웠습니다.


해결책: 하나의 통합 관리테이블

이런 불편함을 해결하기 위해 하나의 고객 관리 테이블로 통합했습니다.

[새로운 테이블 구조]
1. clients_table 

이제 단일 테이블에서 고객의 모든 정보를 한 번에 관리할 수 있습니다.

고객 관리 테이블
  • 기본정보 (사업자명, 연락처 등)
  • 고객 유형 (필드로 관리)
  • 기장 내역
  • 컨설팅 내역
  • 상담 내역
  • 사업장 관리

주요 변경사항

1. 고객 유형을 필드로 관리

이제 고객의 유형을 하나의 필드로 관리합니다:

  • customerType: "기장" | "컨설팅" | "상담" | "기장+컨설팅" 등

이로써 고객의 유형 변화를 즉시 반영할 수 있게 되었습니다.

2. 통합 이력 관리

각 고객분의 모든 활동을 한 곳에서 확인할 수 있습니다:

  • 상담 내역과 컨설팅 기록
  • 기장 작업 이력과 신고 내역
  • 사업장별 관리 현황

3. 중복 제거

기본 정보는 한 번만 입력하고, 모든 유형의 작업에서 공유합니다. 데이터 일관성이 향상되었고, 유지보수 비용이 줄어들었습니다.


실제 운영에서의 개선 효과

변경 후 실제로 느낀 개선 사항:

  1. 고객 검색이 단순해짐: 한 곳에서만 검색하면 모든 정보를 확인 가능
  2. 유형 변경이 자유로움: 필드 값만 변경하면 즉시 반영
  3. 데이터 정합성 향상: 기본 정보 중복 입력으로 인한 불일치 제거
  4. 확장성 개선: 새로운 고객 유형 추가 시 테이블 구조 변경 불필요

마무리

이번 경험을 통해 배운 점은 "초기 설계가 완벽할 필요는 없다" 는 것입니다. 실제 운영을 통해 문제점을 발견하고, 그에 맞춰 개선하는 것이 더 중요합니다.

"모든 고객의 상태를 한 곳에서 관리할 수 있게 되었다" 는 것만으로도, 일상 업무의 효율성이 크게 향상되었습니다.

앞으로도 고객 중심의 관점에서 시스템을 지속적으로 개선해 나가겠습니다.

이재황

이재황

대표 세무사 | 개발자