기업 솔루션은 많이 연결할수록 업무가 더 느려진다

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

영업팀은 고객관리 시스템을, 재무팀은 전사자원관리 시스템을, 인사팀은 협업 도구를 사용합니다. 각각의 제품은 정상인데 월말만 되면 숫자가 맞지 않고, 승인 결과가 늦게 반영되며, 담당자는 결국 엑셀 파일을 대조합니다. 기업이 흔히 말하는 ‘통합’이 실제 현장에서는 왜 더 많은 확인 업무를 만드는 것일까요?

SSMO는 기업 시스템 연결과 운영 구조를 설계해 온 시스템 통합 아키텍트 정유찬 씨를 만나 질문을 던졌습니다. 이번 인터뷰에서는 기능 수보다 중요한 연결 품질, API 연동 비용, 장애 책임, 데이터 동기화 방식까지 기업 담당자가 놓치기 쉬운 기준을 구체적으로 짚습니다.

연동 개수가 늘었는데 왜 직원의 복사·붙여넣기도 늘어날까

Q. 솔루션을 연결하면 업무가 자동화된다는 믿음부터 틀린 건가요?

A. 연결 자체가 자동화를 보장하지는 않습니다. 두 시스템 사이에 데이터가 이동하더라도 전송 시점, 필드 정의, 수정 권한이 다르면 사람이 결과를 다시 검증해야 합니다. 예를 들어 고객관리 솔루션의 ‘계약 완료’가 전자계약 서명 시점을 뜻하고, 회계 솔루션에서는 첫 입금 확인을 뜻한다면 동일한 이름의 상태값도 전혀 다른 사건을 가리킵니다.

이런 차이를 정리하지 않은 채 API만 붙이면 시스템은 빠르게 데이터를 보내지만 조직은 더 자주 충돌합니다. 자동화 속도가 오류 발견 속도보다 빨라지는 상황도 생깁니다. 비즈니스의 일반적인 개념 범위는 비즈니스 용어 정의에서 확인할 수 있지만, 기업 내부에서는 계약·고객·매출처럼 자주 쓰는 단어부터 조직 고유의 정의를 다시 세워야 합니다.

실무자가 먼저 확인할 것은 ‘무엇을 연결할 것인가’보다 ‘어떤 사건을 어느 시스템이 확정할 것인가’입니다. 견적 승인, 계약 체결, 매출 인식, 환불 완료처럼 업무상 의미가 달라지는 순간을 정하고 각각의 원본 시스템을 하나만 지정해야 합니다. 원본이 두 개라면 동기화 문제가 아니라 업무 책임 설계의 문제입니다.

• 고객 정보: 최초 생성 시스템과 최종 수정 권한자를 정합니다. 영업 담당자가 주소를 고쳤을 때 청구 시스템에도 반영되는지 확인합니다.
• 상품 및 가격: 할인율, 세금, 통화, 유효기간을 어느 시스템이 계산하는지 구분합니다. 화면에 보이는 최종 금액만 전달하면 사후 감사가 어렵습니다.
• 계약 상태: 작성, 검토, 서명, 발효, 해지 상태를 별도 값으로 관리합니다. ‘완료’ 하나로 묶으면 후속 자동화가 잘못 실행될 수 있습니다.
• 매출 데이터: 수주액과 회계상 인식 매출을 동일하게 취급하지 않습니다. 영업 보고와 재무 보고의 기준일도 따로 기록해야 합니다.

Q. 연동이 많을수록 오히려 느려지는 전형적인 사례가 있습니까?

A. 대표적인 사례는 다단계 실시간 연동입니다. 고객이 주문하면 쇼핑몰이 고객관리 시스템을 호출하고, 고객관리 시스템이 재고 시스템을 부른 뒤, 재고 시스템이 회계 시스템의 응답을 기다리는 구조입니다. 네 서비스 중 하나만 늦어도 고객 화면 전체가 멈춥니다. 각 솔루션의 평균 응답 시간이 짧더라도 의존 관계가 직렬로 이어지면 체감 속도와 장애 확률은 함께 나빠집니다.

두 번째는 양방향 동기화입니다. A에서 수정한 고객명을 B로 보내고 B의 수정값을 다시 A로 보내면 어느 변경이 최신인지 판별해야 합니다. 시간대 설정이나 재시도 순서가 어긋나면 과거 데이터가 최신 값을 덮기도 합니다. 그래서 모든 정보를 양방향으로 연결하기보다, 필드별로 흐름의 방향을 고정하는 편이 안전합니다.

1. 업무 화면에서 즉시 필요한 값과 몇 분 늦어도 되는 값을 나눕니다.
2. 즉시 처리가 필요한 연동만 동기 방식으로 남기고 보고·집계 데이터는 비동기로 전환합니다.
3. 실패한 요청을 자동 재시도하되 동일 거래가 중복 생성되지 않도록 고유 식별자를 사용합니다.
4. 사람이 개입할 조건을 정합니다. 예를 들어 3회 실패, 금액 불일치, 필수 필드 누락 시 담당자에게 작업을 배정합니다.
5. 월말이나 행사 기간처럼 트래픽이 몰리는 시나리오를 기준으로 처리량을 시험합니다.

“좋은 통합은 모든 시스템을 실시간으로 묶는 구조가 아닙니다. 업무가 허용하는 지연 시간을 이용해 장애가 퍼질 범위를 줄이는 구조입니다.”

API 기능표보다 먼저 물어야 할 운영 질문은 무엇인가

Q. 기업 솔루션 상담에서 어떤 질문을 던져야 숨은 비용이 보이나요?

A. ‘API를 지원합니까?’라는 질문만으로는 부족합니다. API가 있어도 호출 횟수 제한이 낮거나 필요한 필드를 읽기만 할 수 있고 수정할 수 없다면 원하는 프로세스를 만들지 못합니다. 상위 요금제에서만 연동 기능을 제공하거나 별도의 개발자 계정, 중계 서비스, 전용 IP 비용을 요구하는 제품도 있습니다.

비용은 라이선스와 최초 개발비만 합산해서는 안 됩니다. 일반적인 중소·중견기업 프로젝트에서는 단순한 단방향 연결이 수백만 원 수준에서 시작할 수 있지만, 데이터 정제와 예외 처리, 보안 심사, 과거 자료 이관까지 포함하면 수천만 원 이상으로 커질 수 있습니다. 정확한 금액은 거래량과 시스템 수에 따라 달라지므로 견적서에는 초기 구축비·월 운영비·변경비·장애 대응비를 분리해 받는 것이 좋습니다.

특히 SaaS 제품은 공급사가 API 버전을 변경하거나 특정 기능을 종료할 수 있습니다. 계약 당시 잘 작동했다는 사실보다 변경 공지 기간, 구버전 지원 기간, 테스트 환경 제공 여부가 장기 비용을 좌우합니다. 온라인 환경에서 거래와 업무가 이루어지는 범위를 이해하려면 이비즈니스 개념 설명도 참고할 수 있습니다. 다만 실제 도입 계약에서는 서비스별 데이터 처리 범위와 책임을 훨씬 세밀하게 명시해야 합니다.

• 호출 제한: 분당·일일 한도와 초과 요금, 한도 상향 절차를 묻습니다. 조회 한도와 수정 한도가 다른지도 확인합니다.
• 기능 범위: 조회, 생성, 수정, 삭제 중 무엇이 가능한지 필드 단위로 확인합니다. 첨부파일과 사용자 정의 항목은 별도 제약이 자주 생깁니다.
• 이벤트 알림: 변경을 즉시 알려주는 웹훅이 있는지, 알림 실패 시 재전송하는지 확인합니다.
• 시험 환경: 실제 고객정보 없이 연동을 검증할 샌드박스와 테스트 계정이 제공되는지 묻습니다.
• 버전 정책: API 종료 통보 시점, 이전 기간, 변경 이력과 기술 문서의 공개 범위를 확인합니다.
• 지원 체계: 장애 접수 채널, 응답 목표 시간, 야간·주말 지원 범위와 유료 기술지원 단가를 기록합니다.

Q. 자체 개발, 연동 플랫폼, 공급사 구축 중 어느 방식이 유리합니까?

A. 정답은 기업의 변경 빈도와 내부 역량에 달려 있습니다. 자체 개발은 복잡한 규칙을 정교하게 구현하고 특정 공급사에 대한 의존을 줄일 수 있지만, 담당 개발자가 떠난 뒤 유지보수가 멈추는 위험이 있습니다. 소스코드뿐 아니라 배포 절차, 인증서 갱신, 장애 복구 문서까지 내부 자산으로 남겨야 장점이 유지됩니다.

연동 플랫폼은 화면에서 흐름을 조립할 수 있어 초기 속도가 빠릅니다. 표준적인 알림, 고객 등록, 문서 생성 업무에는 효율적이지만 실행 건수에 따라 요금이 증가하고 복잡한 분기에서 관리 화면이 지나치게 얽힐 수 있습니다. 공급사 구축은 제품 이해도가 높다는 장점이 있으나 다른 솔루션에서 발생한 문제까지 한 업체가 책임지지는 않는다는 점을 기억해야 합니다.

예를 들어 하루 50건의 문의를 CRM에 등록하는 업무는 연동 플랫폼으로 시작해도 충분합니다. 반면 결제 승인과 재고 차감처럼 중복 실행이 직접 손실로 이어지는 흐름은 내부 통제 수준에 맞춘 개발과 검증이 필요합니다. 질문은 “어떤 기술이 더 좋은가?”가 아니라 “실패했을 때 누가 몇 분 안에 복구할 수 있는가?”여야 합니다.

“연동 견적이 유난히 저렴하다면 정상 흐름만 구현한 것은 아닌지 확인하십시오. 실제 운영비는 취소, 중복, 지연, 부분 실패를 처리하는 데서 발생합니다.”

연결을 줄이는 결정부터 우선순위를 다시 세워야 한다

Q. 이미 복잡해진 기업은 어디서부터 손봐야 합니까?

A. 새로운 통합 도구를 구매하기 전에 현재 연결 지도를 만들어야 합니다. 시스템 이름만 나열하지 말고 데이터가 출발하는 곳, 도착하는 곳, 전송 주기, 인증 방식, 담당자, 실패 알림 수신자를 한 줄씩 적습니다. 직원 개인 계정으로 만든 자동화나 퇴사자의 이메일로 오류 알림이 가는 이른바 ‘그림자 연동’도 반드시 포함해야 합니다.

그다음 30일 동안 실제 사용량과 실패 기록을 봅니다. 매일 실행된다고 믿었던 연결이 수개월째 멈춰 있거나, 이미 폐기된 보고서 때문에 고객 데이터 전체를 복제하는 경우가 적지 않습니다. 사용되지 않는 연결은 즉시 삭제하기보다 잠시 중지한 뒤 영향이 없는지 관찰하고, 관련 부서의 확인을 받아 폐기하는 방식이 안전합니다.

아래 순서는 시스템 수가 열 개든 백 개든 적용할 수 있습니다. 핵심은 눈에 잘 띄는 화면 개선보다 돈·고객·법적 의무에 영향을 주는 데이터 흐름을 먼저 다루는 것입니다.

1. 1순위, 손실과 규제 위험: 결제, 세금계산서, 개인정보, 접근권한 연동부터 확인합니다. 중복 청구나 퇴사자 권한 유지처럼 즉시 피해가 생기는 오류를 우선 차단합니다.
2. 2순위, 고객 경험: 주문 상태, 배송 안내, 상담 이력처럼 고객에게 바로 노출되는 흐름을 점검합니다. 내부 처리 완료와 고객 알림 발송의 시간 차이도 측정합니다.
3. 3순위, 업무 중단 범위: 하나의 장애가 여러 부서로 전파되는 직렬 연결을 분리합니다. 임시 수동 절차와 재처리 방법을 함께 마련합니다.
4. 4순위, 반복 노동: 직원이 매주 같은 파일을 내려받아 업로드하거나 두 화면을 대조하는 업무를 자동화 후보로 올립니다.
5. 5순위, 편의 기능: 알림 문구, 보고서 꾸미기, 부가 대시보드처럼 중단되어도 핵심 거래에 영향이 적은 항목은 뒤로 미룹니다.

Q. 새 기업 비즈니스 서비스를 최종 승인할 때 판단 기준은 무엇입니까?

A. 최종 시연에서 화면이 매끄럽다는 이유로 승인하지 마십시오. 정상 주문 한 건이 아니라 고객명 수정, 승인 취소, 네트워크 지연, 중복 클릭, 담당자 퇴사 같은 예외 시나리오를 직접 실행해야 합니다. 오류가 발생했을 때 어느 시스템에서 멈췄는지 담당자가 스스로 찾을 수 없다면 운영 가능한 솔루션이라고 보기 어렵습니다.

시험 운영은 전체 조직보다 하나의 팀과 제한된 데이터로 시작하는 편이 좋습니다. 성공률만 보지 말고 처리 시간, 수동 개입 건수, 중복 생성 건수, 누락 발견 시간, 복구 소요 시간을 도입 전후로 비교하십시오. 자동화율이 높아졌어도 복구 시간이 길어졌다면 기업 전체 확산을 서두를 이유가 없습니다.

마지막 승인 문서에서는 판단 기준을 다음 순서로 세우는 것이 현실적입니다. 첫째는 데이터 원본과 책임자가 명확한가, 둘째는 실패를 발견하고 되돌릴 수 있는가, 셋째는 보안·계약·API 변경 위험을 감당할 수 있는가입니다. 그다음에야 처리 속도와 직원 편의, 추가 기능, 화면 디자인을 평가합니다. 연결 수를 성과로 삼지 않고 수동 확인과 장애 영향을 얼마나 줄였는지를 성과로 삼을 때, 기업 솔루션은 비로소 업무를 빠르게 만드는 서비스가 됩니다.

• 가장 먼저: 데이터의 최종 원본, 승인 권한, 장애 책임자를 문서에서 한 명 또는 한 조직으로 특정합니다.
• 그다음: 재시도, 중복 방지, 오류 알림, 수동 복구 절차를 실제 실패 상황에서 검증합니다.
• 세 번째: 개인정보 전송 범위, 보관 기간, 접근 기록, 공급사 변경 정책을 계약 조건과 대조합니다.
• 네 번째: 3년 총비용에 라이선스뿐 아니라 호출량, 유지보수, 변경 개발, 교육 비용을 포함합니다.
• 마지막: 사용 편의와 부가 기능을 평가하되 앞선 네 기준을 통과하지 못한 제품의 화려한 시연에는 점수를 주지 않습니다.