여러 회사가 함께 쓰는 거래 플랫폼을 설계하는 방법

한 번의 거래에 여러 회사가 걸쳐 있을 때

입찰이나 계약, 정산을 하나의 시스템에서 처리하려고 하면 가장 먼저 부딪히는 문제는 권한입니다. 발주사 담당자와 참여 회사, 그 사이에서 서류를 확인하는 중간 담당자가 같은 화면을 봐야 하지만, 각자 볼 수 있는 범위와 수정할 수 있는 범위는 전혀 다릅니다.

참여 회사는 자신이 제출한 제안서만 볼 수 있어야 하고, 평가자는 평가가 끝나기 전까지 다른 평가자의 점수를 볼 수 없어야 합니다. 이런 조건을 화면을 다 만든 뒤에 끼워 넣으려 하면 구조를 다시 짜야 하는 경우가 많아, 설계 단계에서 누가 무엇을 볼 수 있는지부터 정리해야 나중에 손댈 일이 적습니다.

거래는 단계마다 다음으로 넘어가는 조건도 다릅니다. 입찰은 마감 시각이 지나면 접수를 막아야 하고, 계약은 내부 결재가 끝나야 상대방에게 서명을 요청할 수 있고, 정산은 거래가 확정돼야 계산을 시작할 수 있습니다. 이 조건들을 하나의 흐름 위에 미리 그려두지 않으면 단계마다 예외 처리가 하나씩 늘어납니다.

단계별로 나눠서 설계하기

참여 신청과 자격 확인

참여 신청을 받을 때는 사업자등록증 같은 자격 서류를 먼저 확인하는 절차가 들어갑니다. 등록번호 유효성은 외부 조회로 자동 확인하고, 서류 내용이 조건에 맞는지는 담당자가 직접 검토하도록 나눠 설계해두면, 신청이 몰리는 시점에도 처리가 밀리지 않습니다.

제안·견적 접수와 비교

입찰 시스템에서는 제안서나 견적서를 마감 시각을 기준으로 자동 차단하고, 회사마다 다른 형식으로 들어온 내용을 같은 평가 항목과 가중치 위에 올려 점수를 매기고 합산할 수 있어야 합니다. 그래야 나중에 평가 공정성을 묻는 질문에 답할 수 있습니다.

계약 체결

전자계약은 템플릿을 고르고 내부 결재를 거친 뒤 상대방에게 서명을 요청하는 순서로 진행되고, 체결 후에는 만료 알림과 갱신 처리까지 이어집니다. 전자서명법상 전자서명은 자필서명이나 날인과 동일한 효력을 가지지만, 부동산 등기처럼 전자 방식으로 처리할 수 없는 문서도 있어 어떤 계약 종류를 다루는지 먼저 확인해야 합니다.

진행 중 정산과 증빙 관리

정산 시스템은 거래 유형별로 수수료율이나 공제 항목이 다르고, 환불이나 부분취소가 겹치면 계산을 다시 해야 합니다. 이의 제기 창구와 세금계산서 발행 연동까지가 증빙 관리의 핵심입니다. 정산 대금을 플랫폼이 직접 수수하는 구조라면 전자금융거래법상 전자지급결제대행업 등록 대상이 될 수 있어, 거래 대금이 실제로 어떤 경로로 흐르는지 미리 확인해야 합니다.

상태가 꼬이지 않게 만드는 법

거래 하나가 지금 어느 단계에 있는지를 발주사, 참여 회사, 중간 담당자가 각자 다른 화면에서 확인하면 어느 시점에는 서로 다른 말을 하게 됩니다. 모두가 같은 화면에서 같은 상태를 확인할 수 있어야, 진행 상황을 다시 확인하는 연락이 줄어듭니다.

발주사와 참여 회사가 서로 다른 화면에서 같은 거래를 보고 있다면, 이미 같은 시스템이라고 부르기 어렵습니다.

서류가 반려되거나 다시 제출해야 하는 상황도 처음부터 설계에 넣어두어야 하는 흐름입니다. 반려 사유를 남기고 재제출을 받고 다시 검토하는 흐름이 따로 없으면, 담당자가 매번 이 과정을 수동으로 처리하게 되어 거래가 많아질수록 부담이 커집니다.

보안과 기록이 같이 가야 하는 이유

계약과 정산 데이터는 나중에 분쟁이 생기면 근거가 되는 자료입니다. 누가 언제 무엇을 수정했는지가 남아 있지 않으면, 문제가 생겼을 때 어느 쪽 말이 맞는지 가릴 방법이 없습니다. 접근하고 변경한 기록을 남기고, 그 기록 자체가 바뀌지 않도록 지키는 처리가 함께 필요합니다.

기록을 남기는 일보다 중요한 것은, 그 기록 자체를 아무도 고칠 수 없게 지키는 일입니다.

접근 권한은 회사 단위로 한 번, 그 회사 안에서 담당자 단위로 한 번 더 나눠야 합니다. 협력사 계정을 다른 시스템과 묶어 썼다면 권한도 함께 회수해야 합니다. 협력사 직원이 바뀌거나 담당자가 퇴사했을 때 권한이 제때 회수되지 않으면, 이미 끝난 거래의 서류를 더 이상 관련 없는 사람이 열어볼 수 있는 상태로 남습니다.

개인정보보호법에 따라 계약 상대방이나 협력사 담당자의 연락처, 서명 정보 같은 항목은 꼭 필요한 범위로만 수집하고, 목적을 고지하고 동의를 받아야 합니다. 개인정보 보유 규모나 매출 규모 등 법정 기준에 따라 ISMS-P 인증이 의무화되는 경우가 있고, 공공기관 대상 사업이거나 거래 규모가 크면 거래처 요청으로 인증을 준비하는 경우도 있어 사업 성격을 먼저 확인해야 합니다.

연락하기 전에 정리해두면 좋은 것들

지금 입찰이나 계약, 정산을 어떤 방식으로 처리하고 있는지부터 적어보는 것이 출발점입니다. 엑셀과 이메일로 돌고 있는 흐름이라면 어느 지점에서 가장 많은 시간이 들고 어느 지점에서 오류나 지연이 반복되는지를 함께 적어두면, 범위를 정하는 데 걸리는 시간이 줄어듭니다.

거래에 참여하는 당사자가 누구인지, 그리고 각자 어느 화면까지 볼 수 있어야 하는지도 미리 정리해두는 편이 낫습니다. 발주사 한 곳과 참여 회사 여러 곳이 기본 구조인지, 중간에 승인하거나 검토하는 담당자가 따로 있는지에 따라 권한 설계가 달라집니다.

정산 대금이 실제로 어떤 경로로 오가는지, 즉 플랫폼이 직접 돈을 받아 나눠주는 구조인지 아니면 거래 당사자끼리 직접 주고받고 플랫폼은 계산만 맡는 구조인지도 짚어두면 법적 검토가 필요한 부분을 미리 가늠할 수 있습니다. 기존에 쓰던 시스템이 있다면 그 안에 쌓인 계약과 정산 이력이 어떤 형태로 보관돼 있는지 확인해두는 것도 이관 범위를 가늠하는 데 도움이 됩니다.

정리

여러 회사가 걸쳐 있는 거래를 하나의 흐름으로 설계하는 일은, 누가 무엇을 언제 볼 수 있고 어떤 조건에서 다음 단계로 넘어가는지를 먼저 정하는 일입니다. 화면을 보기 좋게 만드는 일은 그 다음입니다. 이 기준을 먼저 세워두면 참여 회사가 늘어나거나 거래 유형이 추가돼도 같은 구조를 그대로 넓혀 쓸 수 있습니다.

지금 운영 중인 입찰, 계약, 정산 방식과 참여 당사자 구조를 정리해두면 상담 단계에서 바로 설계를 살펴볼 수 있습니다. B2B 플랫폼 서비스 페이지에서는 단계별 설계와 권한, 보안, 운영까지 이어지는 과정을 더 자세히 안내합니다.