비즈니스 솔루션 연동 오류, 왜 자꾸 데이터가 어긋날까?

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

CRM의 고객 정보는 수정됐는데 청구 시스템에는 예전 주소가 남아 있고, 주문 상태는 배송 완료인데 상담 화면에는 결제 확인 중으로 표시됩니다. 담당자는 데이터를 다시 입력하고 개발자는 연동 로그를 확인하지만, 며칠 뒤 같은 문제가 되풀이됩니다. 이런 현상은 단순한 프로그램 고장보다 비즈니스 솔루션 사이의 데이터 전달 규칙이 불분명할 때 더 자주 발생합니다.

여러 서비스를 연결한 기업이라면 오류를 발견할 때마다 수동으로 데이터를 맞추는 방식에서 벗어나야 합니다. 아래 순서대로 원인을 분리하면 개발 지식이 많지 않아도 어디서 데이터가 막히고 변형됐는지 좁혀갈 수 있습니다.

연동 오류가 생기면 먼저 증상을 한 문장으로 고정합니다

‘안 된다’ 대신 데이터의 출발점과 도착점을 적습니다

“CRM 연동이 이상합니다”라는 신고만으로는 원인을 찾기 어렵습니다. 어떤 시스템에서 생성된 무슨 값이 어느 시스템에 언제까지 도착해야 했는지 적어야 조사 범위가 정해집니다. 예를 들어 “쇼핑몰에서 오전 10시 12분에 결제된 주문 10482번이 10분 후에도 ERP에 생성되지 않았다”처럼 기록하면 담당자가 같은 대상을 확인할 수 있습니다.

비즈니스는 거래뿐 아니라 업무와 사업 활동을 폭넓게 가리키므로, 연동의 목적도 단순한 데이터 복사가 아니라 실제 업무의 연결에 있습니다. 용어의 기본 범위는 지식백과의 비즈니스 설명에서도 확인할 수 있습니다. 따라서 기술 오류를 기록할 때는 데이터 차이와 함께 주문 지연, 중복 연락, 매출 누락처럼 업무에 미친 영향도 남겨야 우선순위를 제대로 판단할 수 있습니다.

최초 신고자는 다음 여섯 항목을 채우는 것이 좋습니다. 화면 전체를 무작정 캡처하기보다 주문번호나 고객번호를 가린 뒤 오류 메시지, 발생 시각, 기대 결과가 함께 보이게 남기면 개인정보 노출을 줄이면서 조사에 필요한 단서를 확보할 수 있습니다.

• 발생 시각: ‘오늘 오전’이 아니라 분 단위와 표준 시간대를 함께 기록합니다.
• 출발 시스템: 고객·주문·계약 정보가 처음 입력된 서비스를 적습니다.
• 도착 시스템: 값이 생성되거나 변경되어야 했던 서비스를 적습니다.
• 식별값: 주문번호, 고객 ID, 요청 ID처럼 양쪽 로그를 연결할 값을 확보합니다.
• 기대값과 실제값: 무엇이 어떻게 달랐는지 한 줄로 비교합니다.
• 업무 영향: 몇 건이 지연됐고 고객 응대나 정산이 중단됐는지 표시합니다.

현장 팁: 오류 화면만 저장하지 말고 정상 처리된 데이터 한 건도 함께 확보하세요. 실패 건과 정상 건의 입력값을 비교하면 원인 후보가 훨씬 빨리 줄어듭니다.

데이터가 사라진 지점을 네 구간으로 나눠 찾습니다

입력·전송·변환·저장 순서로 확인합니다

솔루션 연동은 대체로 원본 데이터 입력, API 또는 파일 전송, 필드 변환, 대상 시스템 저장의 네 구간을 지납니다. 모든 시스템을 동시에 살피면 로그가 많아져 오히려 혼란스럽습니다. 마지막으로 정상임이 확인된 지점부터 다음 구간을 하나씩 검사하는 방식이 가장 효율적입니다.

먼저 원본 시스템에서 해당 레코드가 실제로 저장됐는지 확인합니다. 저장 버튼을 눌렀더라도 필수값 검증에 실패했거나 임시 상태로 남아 있을 수 있습니다. 원본은 정상인데 발송 기록이 없다면 트리거 조건을, 발송 기록은 있는데 응답이 없다면 인증서·네트워크·API 제한을 살펴봅니다. 응답이 성공인데 대상 화면에 값이 없다면 변환 규칙이나 저장 후 처리 과정이 의심됩니다.

아래 표처럼 구간별 증상과 확인 항목을 맞추면 비개발 담당자도 조사 결과를 명확하게 전달할 수 있습니다. HTTP 200 같은 성공 응답이 있다고 안심해서는 안 됩니다. 요청 자체는 접수됐지만 내부 검증에서 제외되거나 비동기 처리 대기열에 남았을 가능성도 있기 때문입니다.

최근 변경 이력을 시간순으로 겹쳐 봅니다

어제까지 정상이었다면 장애 발생 직전의 변화를 찾는 것이 빠릅니다. API 버전 변경만 원인이 되는 것은 아닙니다. 관리자가 상태값 이름을 바꾸거나 사용자 권한을 조정하고, 필수 입력 필드를 하나 추가한 것만으로도 기존 연동이 실패할 수 있습니다.

1. 첫 오류 발생 시각을 정상 처리 마지막 시각과 나란히 놓습니다.
2. 그 사이에 배포, 설정 변경, 권한 수정, 비밀번호 교체가 있었는지 확인합니다.
3. 외부 솔루션의 점검 공지와 장애 이력을 조회합니다.
4. 변경 전후 요청 본문과 응답 코드의 차이를 비교합니다.
5. 원인이 의심돼도 운영 환경에서 즉시 되돌리지 말고 테스트 데이터로 재현합니다.

가장 흔한 다섯 가지 원인에는 확인 순서가 있습니다

인증 만료와 호출 한도부터 빠르게 배제합니다

갑자기 모든 연동이 멈췄다면 가장 먼저 인증 정보를 확인합니다. API 키가 만료됐거나 담당자 계정이 퇴사 처리되면서 토큰 권한이 사라지는 일이 흔합니다. 오류 코드가 401이면 인증 실패, 403이면 접근 권한 부족일 가능성이 크지만 솔루션마다 의미가 다를 수 있으므로 해당 서비스의 공식 문서를 기준으로 판단해야 합니다.

월말이나 행사 직후에만 문제가 생긴다면 호출 한도도 의심해야 합니다. API는 초당·분당·일일 요청 수를 제한할 수 있으며, 한도를 넘으면 429 응답이 발생하는 경우가 많습니다. 이때 요청을 즉시 반복하면 실패 요청이 더 쌓이므로 대기 시간을 점차 늘리는 재시도 방식과 처리 대기열을 함께 사용해야 합니다.

• 인증 정보: 만료일, 발급 계정, 허용 범위, 최근 교체 시점을 확인합니다.
• 호출 한도: 시간대별 요청량과 실패율을 나란히 비교합니다.
• 네트워크: 허용 IP, 방화벽 규칙, DNS 및 인증서 갱신 여부를 점검합니다.
• 서비스 상태: 공급사 상태 페이지와 공식 장애 공지를 확인합니다.
• 재시도 설정: 무한 반복 대신 최대 횟수와 재처리 보관함을 둡니다.

필드 형식과 중복 방지 규칙을 따로 검사합니다

일부 데이터만 실패한다면 값의 형식이 원인일 가능성이 큽니다. 전화번호에 하이픈이 포함됐거나 주소가 허용 글자 수를 넘고, 빈 문자열과 null을 서로 다르게 처리해 저장이 거부될 수 있습니다. 날짜도 ‘08/18/26’처럼 해석이 모호한 형식보다 ISO 형식을 사용하고, 한국 시간과 UTC가 뒤섞이지 않도록 기준을 명시해야 합니다.

중복 데이터는 더 까다롭습니다. 같은 이메일 주소를 기준으로 고객을 합치는 CRM과 휴대전화 번호를 기준으로 구분하는 상담 솔루션을 연결하면 한쪽의 두 고객이 다른 쪽에서는 한 명으로 합쳐질 수 있습니다. 반대로 재시도 요청에 고유 키가 없으면 주문 한 건이 두 번 생성됩니다. 어떤 필드가 동일할 때 같은 데이터로 볼 것인지를 기술팀이 아니라 업무 책임자까지 참여해 결정해야 합니다.

문제 유형별로 아래 조치를 적용하되, 원본 데이터를 바로 수정하기 전 실패 사본을 보관하세요. 원인을 확인하지 않고 특수문자를 지우거나 고객 정보를 합치면 당장은 성공해 보여도 감사 기록과 거래 이력이 훼손될 수 있습니다.

• 빈 값 오류는 필수 필드에 기본값을 무조건 넣기보다 업무상 허용 여부부터 결정합니다.
• 상태 코드가 다르면 ‘결제완료→PAID’처럼 양방향 매핑표와 책임자를 지정합니다.
• 중복 생성은 주문번호와 같은 고유 키로 멱등성을 적용해 같은 요청의 재저장을 막습니다.
• 문자 깨짐은 UTF-8 등 인코딩 기준과 파일의 구분자·따옴표 규칙을 맞춥니다.
• 시간 차이는 저장 기준 시간대와 화면 표시 시간대를 분리하고 변환 로그를 남깁니다.

오류율이 낮다는 이유로 방치하지 마세요. 하루 주문 5만 건 중 0.2%만 실패해도 100명의 고객에게 배송·환불 문제가 생길 수 있습니다.

복구할 때는 재전송보다 중복과 순서를 먼저 통제합니다

백업한 뒤 작은 묶음으로 재처리합니다

원인을 고쳤다고 실패 데이터를 한꺼번에 다시 보내면 새로운 문제가 생길 수 있습니다. 이미 일부 요청은 대상 시스템에 저장됐는데 응답만 유실됐을 수 있고, 주문 생성보다 배송 상태 변경 이벤트가 먼저 도착하면 데이터 순서가 뒤집힐 수도 있습니다. 따라서 복구 전에는 실패·성공·처리 중 상태를 식별값 기준으로 대조해야 합니다.

안전한 복구는 샘플 1건, 소량 묶음, 전체 대상의 세 단계로 진행합니다. 샘플에는 정상적인 데이터뿐 아니라 빈 선택 항목, 긴 주소, 할인 금액, 해외 전화번호처럼 경계 조건을 포함합니다. 소량 묶음에서 저장 결과와 후속 자동화까지 확인한 뒤 전체 재처리를 시작하면 대규모 중복 생성 위험을 줄일 수 있습니다.

재처리 대상을 CSV로 내보내 수동 수정할 때도 원본과 수정본을 분리해야 합니다. 누가 어떤 값을 바꿨는지, 재전송 전에 승인을 받았는지 기록해 두면 정산 차이나 개인정보 문의가 생겼을 때 근거를 찾을 수 있습니다.

1. 운영 영향 제한: 오류가 계속 유입되면 해당 연동만 일시 중지하고 수동 업무 절차를 공지합니다.
2. 원본 보존: 실패 요청 본문, 응답, 발생 시각을 변경 불가능한 형태로 보관합니다.
3. 대상 대조: 고유 키로 이미 저장된 건과 미저장 건을 구분합니다.
4. 샘플 검증: 테스트 고객 또는 승인된 실데이터 1건으로 생성·수정·취소 흐름을 확인합니다.
5. 소량 재처리: 10~50건을 보내 성공률, 중복, 처리 시간을 관찰합니다.
6. 전체 복구: 속도 제한을 지키며 실행하고 실패 건은 별도 대기열로 분리합니다.
7. 업무 검산: 시스템 건수뿐 아니라 매출 합계, 주문 상태, 고객 알림 발송 여부도 맞춥니다.

정상화 기준을 숫자로 합의합니다

기술팀이 “API가 정상입니다”라고 말해도 현장에는 누락 주문이 남아 있을 수 있습니다. 정상화 기준은 응답 성공률만으로 정하지 말고 미처리 건수 0건, 중복 주문 0건, 양쪽 금액 합계 일치, 지연 시간 목표 이내처럼 업무 지표를 포함해야 합니다. ‘business’라는 표현의 사전적 의미가 궁금하다면 관련 용어 설명을 참고할 수 있지만, 실제 운영에서는 조직마다 업무 범위와 책임 경계를 문서로 구체화해야 합니다.

• 성공률은 전체 요청 수와 고유 업무 건수를 각각 기준으로 계산합니다.
• 평균 지연뿐 아니라 가장 느린 상위 5%의 처리 시간도 확인합니다.
• 재처리 완료 후 원본과 대상의 건수·금액·상태별 합계를 대조합니다.
• 고객 알림이 중복 발송되지 않았는지 이메일과 문자 이력을 검사합니다.
• 복구 선언 시각, 확인자, 남은 예외 건과 후속 조치를 기록합니다.

온라인 주문 327건 누락을 복구한 흐름을 따라가 봅니다

오전 신고부터 오후 정상화까지의 실제형 시나리오

생활용품을 판매하는 A사는 쇼핑몰, 주문관리 솔루션, 택배 서비스를 연결해 사용하고 있었습니다. 오전 9시 20분, 물류 담당자가 주문관리 화면의 신규 주문이 평소보다 적다는 사실을 발견했습니다. 담당자는 단순한 매출 감소로 넘기지 않고 쇼핑몰 주문번호 3건을 골라 확인했고, 결제는 완료됐지만 주문관리 솔루션에는 생성되지 않았다는 공통점을 찾았습니다.

오전 9시 35분에는 최초 장애 기록을 작성했습니다. 정상 처리 마지막 시각은 전날 오후 11시 58분, 첫 실패 시각은 자정 2분이었으며 대상 솔루션의 응답은 401이었습니다. 변경 이력을 대조하자 자정에 연동 전용 계정의 보안 정책이 갱신됐고, 기존 접근 토큰이 폐기된 사실이 드러났습니다. 운영팀은 주문 접수 자체는 계속되므로 쇼핑몰을 닫지 않고, 출고 지연 안내가 필요한 주문만 별도 목록으로 관리했습니다.

오전 10시 10분에 새 토큰을 발급했지만 327건을 곧바로 재전송하지는 않았습니다. 개발 담당자는 주문번호를 고유 키로 양쪽 시스템을 대조해 11건이 이미 생성됐으나 응답만 실패했다는 사실을 확인했습니다. 이 11건을 제외하지 않았다면 중복 주문과 이중 출고가 발생할 수 있는 상황이었습니다.

1. 10시 25분: 미저장 316건의 원본 요청과 결제 금액 합계를 별도 보관했습니다.
2. 10시 40분: 일반 주문, 쿠폰 주문, 부분 취소 주문을 각각 1건씩 시험 전송했습니다.
3. 11시 05분: 20건을 소량 재처리해 주문 생성과 재고 차감, 고객 알림을 확인했습니다.
4. 11시 30분: 고객 알림은 원래 쇼핑몰에서 이미 발송됐으므로 재처리 과정에서 알림 기능을 비활성화했습니다.
5. 오후 12시 20분: 나머지 296건을 호출 한도 안에서 나눠 전송했습니다.
6. 오후 1시 10분: 주문 건수와 결제 합계, 상품 수량, 출고 대기 상태를 양쪽에서 대조했습니다.

같은 장애가 반복되지 않도록 운영 규칙을 바꿉니다

A사는 복구 뒤 ‘토큰을 새로 발급했다’는 기록만 남기지 않았습니다. 만료 30일·7일·1일 전에 담당자와 대체 담당자에게 알림이 가도록 설정하고, 개인 계정이 아닌 권한을 제한한 연동 전용 계정을 사용했습니다. 인증 오류가 5분 동안 세 번 이상 발생하면 운영 채널에 알림을 보내고 실패 요청은 14일간 재처리 대기열에 보관하도록 바꿨습니다.

또한 주문 수가 0건일 때만 경고하던 기존 감시 기준을 수정했습니다. 최근 4주 같은 요일·시간대 평균보다 주문 유입이 40% 이상 줄거나, 연동 지연이 10분을 넘으면 확인하도록 만든 것입니다. 완전 중단뿐 아니라 조용히 일부 데이터만 누락되는 장애까지 찾기 위한 조치였습니다.

오후 2시, 운영 책임자는 327건의 상태를 마지막으로 확인했습니다. 이미 생성된 11건은 그대로 유지됐고 미저장 316건은 한 번씩만 복구됐으며, 결제 합계와 재고 수량도 일치했습니다. 물류팀은 지연된 주문을 우선 피킹 목록으로 넘겼고 고객에게 중복 메시지는 발송되지 않았습니다. 한 달 뒤 같은 인증 갱신 시점에는 사전 알림으로 토큰을 교체했고, 시험 주문 한 건이 정상 처리된 것을 확인한 뒤 평소와 같은 출고 업무를 시작할 수 있었습니다.

• 연동 계정과 일반 사용자 계정을 분리하고 최소 권한만 부여합니다.
• 인증 만료일, API 버전 종료일, 공급사 점검 일정을 공동 캘린더에 등록합니다.
• 오류율뿐 아니라 처리량 급감, 지연 증가, 금액 불일치를 함께 감시합니다.
• 장애 시 중지할 자동화와 계속 유지할 고객 서비스를 미리 구분합니다.
• 분기마다 샘플 주문으로 생성·수정·취소·환불 흐름을 실제로 점검합니다.