고객 포털 홈페이지 개발: 거래처별 문서·견적 조회 설계 기준

고객 포털 홈페이지 개발은 거래처가 자기 회사의 문서·견적·진행 상태를 확인하도록 만드는 작업입니다. 로그인 화면보다 중요한 것은 사용자와 거래처의 관계, 문서 공개 승인, 파일 접근 권한과 원천 데이터의 최신성입니다. 공개 홈페이지의 검색 노출과 비공개 업무 자료의 보호를 분리해 설계해야 합니다.

같은 견적서를 이메일로 다시 보내거나 인증서 최신본을 찾는 요청이 반복될 때 포털을 검토할 수 있습니다. 다만 모든 업무를 한 번에 옮기려 하면 홈페이지 제작이 주문·정산 시스템 구축으로 커질 수 있습니다. 먼저 고객이 직접 확인하면 되는 정보와 담당자의 승인이 필요한 행동을 구분하세요.

이 글은 결제 중심의 쇼핑몰이 아니라 거래처별 자료 조회를 중심으로 하는 B2B 포털을 다룹니다. 아래 표와 시험은 발주·검수용 설계 예시입니다. 자사나 특정 고객이 해당 기능을 모두 운영한다는 실적 설명은 아닙니다.

공개 홈페이지와 비공개 포털은 무엇을 나눠야 할까요?#

제품 소개, 공개 인증과 서비스 안내는 검색으로 찾을 수 있게 제공하고, 거래처별 가격·견적·계약 문서는 승인된 사용자만 볼 수 있게 구분하세요. 같은 화면 디자인을 쓰더라도 데이터와 파일의 접근 정책은 같지 않습니다. 공개와 비공개를 문서 업로드 시점부터 선택하도록 만드는 편이 운영하기 쉽습니다.

검색 제외와 정보 보호는 별개입니다.Google의 robots.txt 안내는 robots.txt가 페이지를 비공개로 만드는 수단이 아니며 차단된 URL도 검색에 나타날 수 있다고 설명합니다. 포털의 기밀 자료는 로그인과 서버 권한 검사로 보호하고, 검색 정책은 그 위에서 별도로 정해야 합니다.

공개용 소개서와 고객 맞춤 제안서가 같은 폴더에 있다면 파일 위치부터 분리하는 것을 검토하세요. 공개 폴더에 올린 파일을 화면에서만 감추는 방식은 고객 포털의 보호 경계가 아닙니다. 실수로 공개한 자료의 회수·삭제와 고객 안내 절차까지 운영 범위에 포함하는 것이 좋습니다.

기업 회원 승인은 개인 회원가입과 다릅니다#

이메일 인증은 그 주소를 사용할 수 있다는 확인입니다. 특정 거래처의 견적을 볼 수 있다는 승인과는 다릅니다. 사용자, 거래처, 소속 관계와 역할을 따로 두고 누가 어떤 근거로 소속을 승인하는지 정하세요.

예를 들어 본사 구매 담당자가 자회사 두 곳의 문서를 볼 수 있고, 협력사 기술자는 한 프로젝트의 기술 자료만 볼 수 있습니다. 회사 하나에 사용자 하나라는 구조나 이메일 도메인만으로 회사를 확정하는 규칙은 이런 관계를 표현하기 어렵습니다. 복수 소속과 한시적 외부 접근이 실제로 필요한지부터 표본으로 확인하세요.

초대 링크에는 유효기간과 승인 대상이 있어야 하며, 누가 초대할 수 있는지도 정해야 합니다. 거래처 관리자가 동료를 추가할 수 있도록 하더라도 최초 회사 관리자 지정, 권한 확대와 관리자 교체는 별도의 절차가 필요할 수 있습니다. 공유 계정 대신 개인별 접근과 이력을 남길 수 있는 구조를 검토하세요.

퇴사나 거래 종료 때는 계정 차단, 소속 해제와 문서 보존을 구분합니다. 사용자를 삭제하면서 과거 견적 확인 이력까지 사라지게 하지 말고, 보존할 기록과 삭제할 정보를 계약·개인정보 처리 정책에 맞춰 정해야 합니다. 보존 기간의 법적 판단은 별도 검토가 필요합니다.

문서 목록과 파일 다운로드를 따로 검수하세요#

목록에서 다른 거래처의 문서를 감추는 것만으로는 부족합니다. 문서 상세, 첨부, 다운로드, 검색과 내보내기에서도 같은 회사·프로젝트 관계를 확인해야 합니다. 고객 계정으로 다른 거래처의 문서 주소를 요청했을 때 자료가 반환되지 않는지를 허용된 시험 환경에서 검수하세요.

Microsoft Power Pages의 테이블 권한 안내는 전역, 연락처와 계정 관계 등 접근 범위를 구분하고 웹 역할과 연결합니다. 이처럼 로그인 여부뿐 아니라 데이터와 사용자의 관계를 설계해야 합니다. 특정 제품의 권한 기능이 있다는 사실과 자사 포털 설정이 안전하다는 검증은 같은 의미가 아닙니다.

파일을 내려받는 방식도 제안서에 적게 하세요. 서버가 권한을 확인한 뒤 파일을 전달하는지, 제한된 시간 동안 유효한 링크를 발급하는지에 따라 접근 회수 방식이 달라질 수 있습니다. 이미 발급된 링크가 남는 시간, 파일 교체 뒤 과거 링크의 동작과 캐시 범위를 확인해야 합니다.

어떤 방식이든 고객이 이미 내려받은 파일까지 원격으로 사라지게 만들 수 있다고 약속해서는 안 됩니다. 화면 열람 제한, 다운로드 허용, 워터마크와 이용 조건은 서로 다른 통제입니다. 필요한 보호 수준과 사용 편의의 균형을 고객 업무에 맞춰 결정하세요.

견적과 문서는 버전·승인·만료를 보여줘야 합니다#

최신 파일이라는 문구보다 어떤 문서의 어느 버전인지가 명확해야 합니다. 작성 중, 검토 중, 공개와 폐기를 구분하고 고객에게 공개되는 버전을 승인자가 선택하게 하세요. 내부 파일을 저장하는 행위가 즉시 고객 공개로 이어지는 구조는 신중하게 검토해야 합니다.

견적의 유효기간이 끝났을 때 조회를 막을지, 과거 자료로 표시할지 정하세요. 새 견적을 올렸다고 과거 계약에 사용한 문서가 조용히 바뀌면 안 됩니다. 원문 버전, 공개 시각과 관련 거래를 연결하면 고객이 보고 있는 자료와 담당자가 설명하는 자료를 일치시키기 쉽습니다.

열람 기록도 해석 범위가 있습니다. 파일이 내려갔다는 기록은 사용자가 내용을 이해하거나 계약 조건을 승인했다는 증거와 다릅니다. 견적 수락이나 계약 체결을 포털에서 받으려면 별도 업무 상태, 확인 방식과 법적 요건을 검토해야 합니다. 조회 기능의 완료와 거래 확정의 완료를 섞지 마세요.

ERP·CRM 연결은 조회 범위부터 정하세요#

처음에는 고객에게 필요한 정보만 읽기 전용으로 연결할 수 있습니다. 견적 원본은 CRM, 납품 진행은 ERP처럼 항목별 기준 시스템을 정하고, 포털에서 수정 가능한 값과 수정 요청만 받는 값을 구분하세요. 같은 값을 여러 곳에서 확정하면 충돌 해결과 변경 이력의 비용이 커집니다.

실시간이라는 표현도 구체화해야 합니다. 고객이 확인하는 정보의 최종 갱신 시각, 동기화 지연과 실패 상태를 보여줄지 정하세요. 연동이 멈췄는데 오래된 납품 상태를 현재 정보처럼 보여주는 경우를 검수 표본에 넣으면 업체가 정상 화면 외 운영을 어떻게 설계하는지 알 수 있습니다.

포털에서 변경 신청을 받는다면 접수, 내부 승인과 원천 반영을 나눕니다. 고객이 버튼을 눌렀다고 ERP 주문이 즉시 확정됐다는 뜻이 되지 않도록 상태와 안내 문구를 맞추세요. 중복 제출과 재시도를 구분할 식별자, 처리 책임자와 고객에게 알려줄 실패 상태도 함께 요구합니다.

홈페이지 개발업체에는 어떤 검수표를 줄까요?#

가상 거래처 A·B, 각 회사의 담당자와 내부 운영자를 준비해 허용·거부 결과를 먼저 정하세요. 업체가 시연용 관리자 계정 하나로 모든 기능을 보여주는 것보다, 실제 역할 계정으로 같은 문서를 어떻게 다르게 다루는지 보는 것이 포털 검수에 적합합니다.

견적서는 회원·회사 승인, 권한, 문서 관리, 조회 연동과 운영 인수를 별도 항목으로 받으세요. 기존 CMS나 포털 제품의 설정으로 충족되는 기능과 추가 개발을 나누고, 외부 사용자·저장 공간·연동에 따른 이용 비용도 확인해야 합니다. 특정 플랫폼이 무조건 저렴하거나 맞춤 개발이 항상 유리하다고 단정할 수는 없습니다.

첫 운영 범위는 적은 거래처와 제한된 문서 유형으로 정할 수 있습니다. 다만 타 회사 자료 차단, 퇴사자 회수와 비공개 파일 보호는 나중 기능으로 미루지 마세요. 운영이 시작된 뒤에는 초대 실패, 권한 오류와 오래된 문서 문의를 확인하고 실제 고객의 작업을 기준으로 다음 범위를 결정하면 됩니다.

운영 기능의 범위는 홈페이지 관리자 개발 가이드, 연동 책임은 API 연동 개발 체크리스트, 주문·결제까지 필요한 경우는 B2B 폐쇄몰 구축 기준과 구분해 확인하세요. 개발사 비교에는 홈페이지 개발업체 선정 기준을 함께 활용할 수 있습니다.