공급업체 가격표 및 계약을 관리하는 웹앱 구축하기

앱이 해결해야 할 문제(대상 사용자 포함)

대부분의 공급업체 가격 및 계약 혼란은 비슷합니다: 가격표는 이메일로 온 스프레드시트에 잠들어 있고, "final_FINAL" PDF는 공유 드라이브에 놓여 있으며, 어떤 조건이 최신인지 아무도 확신하지 못합니다. 결과는 예측 가능합니다—오래된 가격으로 주문이 생성되고, 공급업체와 불필요한 분쟁이 발생하며, 갱신이 놓쳐집니다.

해결할 비즈니스 문제

좋은 웹앱은 공급업체 가격표와 계약의 진실 소스를 중앙화하고 변경사항을 끝까지 추적 가능하게 만들어야 합니다. 이를 통해 다음을 줄여야 합니다:

• 스프레드시트, ERP, 이메일 간 수작업 복사
• 오래된 버전으로 인한 가격 오류
• 놓친 갱신 및 통지 기간
• 최신 서명 문서나 수정사항을 찾느라 소모되는 시간

앱의 대상 사용자

가격과 조건을 매주 다루는 사람들을 중심으로 시스템을 설계하세요:

• 조달(Procurement): 가격표를 임포트하고, 업데이트를 협상하며, 유효일을 추적함
• 재무/지급(AP): 청구된 가격 검증, 통화 및 단위, 세금/수수료 확인
• 법무/준법(Compliance): 서명된 계약, 수정서, 필수 조항 보관
• 승인자(경영진): 가격/조건 변경 검토 및 승인
• 관리자(Admins): 사용자, 역할, 공급업체 마스터 데이터, 템플릿 관리

성공 지표(성과를 보여주는 지표)

초기에는 몇 가지 측정 가능한 목표를 선택하세요:

• 가격 업데이트 게시 시간(예: 2일 → 2시간)
• 임포트 오류율 및 업로드당 수동 수정 건수
• 갱신 알림 적중률(예: 통지 기한 전에 알림이 발송된 계약 비율)
• 가격 불일치율(송장/PO 불일치 비율—가격 유효성과 연계)

“완료”의 정의: 첫 릴리즈 vs 이후

첫 릴리즈는 중앙화된 공급업체 레코드, 검증을 포함한 가격표 임포트, 주요 날짜가 있는 계약 저장, 기본 승인, 검색 및 감사 추적을 목표로 하세요.

이후에는 더 깊은 ERP 통합, 조항 라이브러리, 자동 송장 매칭, 다중 엔터티 지원, 고급 리포팅 대시보드를 추가할 수 있습니다.

요구사항 및 워크플로 매핑

화면이나 테이블을 스케치하기 전에, 공급업체가 가격표를 보내는 순간부터 누군가 그에 따라 주문을 하기까지 실제로 무슨 일이 일어나는지 매핑하세요. 이렇게 하면 단순한 "문서 보관소"를 만드는 실수를 피하고 통제된 가격 시스템을 구축할 수 있습니다.

현재 워크플로(As-is) 매핑

조달, 재무, 법무와 함께 실제 사례를 단계별로 살펴보고 핸드오프와 아티팩트를 캡처하세요:

• 가격표 수령(이메일, 포털, 스프레드시트, EDI) → 수령일과 출처 기록
• 검토 및 협상 → 질문, 반제안, 합의된 변경 사항 기록
• 가격 및 조건 승인 → 의사결정 포인트 및 필요한 승인 식별
• 계약서 서명 및 저장 → 조건을 유효 가격표에 연결
• 운영 및 갱신 → 만료, 가격 변경, 예외 모니터링

간단한 스윔레인 다이어그램(공급업체 → 구매/조달 → 법무 → 재무 → 운영)로도 충분한 경우가 많습니다.

주요 의사결정과 역할 식별(누가 무엇을 할 수 있는지)

비즈니스 결과를 바꾸는 의사결정을 나열하고 명확한 소유자를 지정하세요:

• 누가 새로운 가격표를 승인할 수 있고, 누가 계약 수정만 승인할 수 있는가?
• 누가 가격 필드(통화, 단위, MOQ, 리드타임)를 편집할 수 있고, 누가 변경만 요청할 수 있는가?
• 누가 민감한 계약 조항(결제 조건, 책임 조항)을 볼 수 있고, 누가 제한되어야 하는가?

또한 승인 기준이 임계값에 따라 달라지는 곳(예: \u003e5% 인상 시 재무 승인 필요)을 기록해 두어 나중에 규칙으로 인코딩할 수 있게 하세요.

필요한 출력 정의(사용자가 해야 할 작업)

앱이 첫날 답해야 할 정확한 질문을 적으세요:

• “오늘 기준으로 공급업체 Y의 품목 X 현재 가격은 무엇인가?”
• “다음 60/90일 내 만료되는 계약과 갱신 담당자는 누구인가?”
• “예외는 어디에 있는가: 만료된 가격이 사용 중인 경우, MOQ 누락, 통화 불일치?”

이 출력들이 데이터 필드, 검색, 리포트를 구동하게 하세요—그 반대가 되지 않도록.

초기 문제점 및 엣지 케이스 캡처

조달 데이터는 지저분합니다. 일반적인 예외를 명시적으로 문서화하세요:

• 부분 업데이트(공급업체가 전체 카탈로그가 아닌 20개 SKU만 업데이트함)
• 다중 통화 및 환율 가정
• MOQ, 포장 단위, 단위(각품 vs 케이스) 및 반올림 이슈
• 중첩된 유효일이나 소급 수정

이 목록을 임포트 및 승인에 대한 수용 기준으로 삼아 시스템이 현실을 지원하도록 하세요.

상위 수준 아키텍처 및 모듈 분해

공급업체 가격표와 계약을 위한 좋은 아키텍처는 유행을 쫓는 것이 아니라 조정 오버헤드를 줄이면서 성장 여지를 남기는 것입니다.

빌드 접근법: 단순하게 시작하고 의도적으로 진화시키기

대부분의 팀(1–6명의 엔지니어)에겐 모듈형 모놀리스가 출발점으로 적절합니다: 명확히 분리된 모듈과 경계를 가진 하나의 배포 가능한 앱. 빠른 개발, 단순한 디버깅, 적은 운영 복잡성을 가져옵니다.

명확한 이유(예: 독립적 확장이 필요한 대량 임포트 워크로드, 여러 팀의 병행 작업, 엄격한 분리 요구)가 있을 때만 서비스로 분리하세요. 일반적 경로는: 모듈형 모놀리스 → 임포트/처리와 문서 워크로드를 백그라운드 워커로 추출 → 필요 시 고트래픽 도메인을 서비스로 분할하는 것입니다.

첫 프로토타입(화면, 워크플로, 역할 기반 접근)을 빨리 가속하려면 Koder.ai 같은 바이브-코딩 플랫폼을 이용해 구조화된 스펙으로 React + Go + PostgreSQL 기본을 생성한 뒤 임포트, 승인, 감사 추적에 빠르게 반복해 볼 수 있습니다. 조달팀의 경우, 과도하게 구축하기 전에 실제 사용자로 워크플로를 검증하는 것이 중요합니다.

핵심 모듈(이해하기 쉬운 최소 집합)

앱을 몇 가지 안정된 도메인 중심으로 설계하세요:

• Suppliers(공급업체): 공급업체 프로필, 연락처, 식별자, 상태
• Catalog(품목/자재): 내부 품목 마스터와 공급업체 품목 코드 매핑
• Price Lists(가격표): 헤더(공급업체, 유효 기간) 및 라인 항목(가격, 단위, 통화), 임포트 히스토리 포함
• Contracts(계약): 계약 레코드, 연관 공급업체, 적용 품목/카테고리, 주요 날짜, 관련 문서
• Approvals & Governance(승인 및 거버넌스): 검토 단계, 서명, 코멘트, 결정 히스토리
• Reporting(리포팅): 검색, 내보내기, 지출/가격 뷰, 운영 스냅샷

각 모듈은 자체 규칙과 데이터 접근을 책임지게 하세요. 모놀리스라 하더라도 코드의 경계를 강제하세요(패키지, 명명, 모듈 간 명확한 API).

통합을 초기에 계획(즉시 구축하지 않더라도)

통합은 데이터 흐름을 바꾸므로 명확한 확장 포인트를 예약해 두세요:

• SSO(SAML/OIDC) 인증 및 사용자 프로비저닝
• ERP/재무 시스템: 공급업체 ID, 품목 마스터, 승인된 가격 푸시
• 이메일/캘린더: 갱신 알림 및 승인 알림
• 문서 서명(선택적): 수정 및 신규 계약을 최종화

비기능 요구사항(출시 전에 목표 설정)

측정 가능한 기대치를 미리 정의하세요:

• 성능: 일반 검색 2초 미만; 임포트는 비동기로 처리하고 진행 상태 제공
• 가용성: 명확한 가동률 목표 및 계획된 유지보수 시간
• 백업 & 복구: 자동 백업, 복구 훈련, 보존 정책에 맞춘 보존 기간
• 감사성: 임포트, 승인, 계약 변경에 대한 불변 이벤트 히스토리, 사용자 및 타임스탬프 추적

데이터 모델: 엔티티, 관계, 버전 관리

깨끗한 데이터 모델은 조달 앱 신뢰성의 핵심입니다. 사용자가 “3월 3일에 유효했던 가격은 무엇인가?” 또는 “어떤 계약이 그 구매를 규정했는가?”라고 물으면 데이터베이스가 명확히 대답해야 합니다.

핵심 엔티티(최소한으로 의존할 항목)

작은 집합의 명확한 레코드로 시작하세요:

• Supplier(공급업체): 벤더 계정(이름, 공급업체 코드, 상태, 기본 통화, 결제 조건)
• Contact(연락처): 공급업체 내 인물(공급업체당 다수)
• Item/SKU(품목/SKU): 구매 대상(품목 코드, 설명, 카테고리, 단위)
• PriceList(가격표): 공급업체가 제공한 리스트 또는 협상된 스케줄(이름, 유효일, 통화, 파일 원본, 상태)
• PriceLine(가격라인): 리스트 내 가격 항목(품목, 단가, 계단가격/MOQ, 세금 플래그)
• Contract(계약): 상업적 합의(계약 번호, 공급업체, 시작/종료일, 갱신 설정, 상태)
• Term(조항): 검색/리포트에 활용할 구조화된 조항(리드타임, 보증, 납품, 서비스 수준)

모든 것을 연결하는 관계

구매자가 실제로 작업하는 방식을 반영하도록 관계를 모델링하세요:

• Supplier → Contracts: 하나의 공급업체는 여러 계약을 가질 수 있음
• Supplier → PriceLists: 공급업체는 시간 경과에 따라 여러 가격표를 제공할 수 있음
• Contract → PriceLists(선택적이지만 유용): 계약이 적용하는 가격표를 연결
• Item/SKU → PriceLines: 하나의 품목은 여러 가격라인에 등장할 수 있음(공급업체, 통화, 유효일에 따라)

다중 배송지나 사업부를 지원하면 Scope 개념(회사, 사이트, 지역 등)을 추가해 계약과 가격표에 첨부할 수 있게 고려하세요.

버전 관리: 히스토리를 지우지 마세요

라이브 레코드를 제자리에서 수정하지 마세요. 대신:

• 가격표 버전 관리: 각 임포트는 새 PriceList 버전을 생성(또는 동일 가족 ID의 새 PriceList 레코드). 이전 버전은 읽기 전용으로 유지
• 계약 수정: 각 수정은 자체 유효일을 가진 새 버전으로 저장. "현재" 계약 뷰는 단순히 최신 승인된 버전임

이렇게 하면 언제 무엇이 승인되었고 무엇이 변경되었는지 재구성하기 쉬워집니다.

참조 데이터 및 고유성 규칙

참조 데이터는 전용 테이블에 보관해 자유 텍스트 난맥을 피하세요:

• 통화, 단위(단위 측정), 세금 코드, 국제 운송이 있다면 인코텀즈(Incoterms)

중복을 방지하기 위해 식별자를 강제하세요:

• 공급업체 코드: 시스템 전역에서 고유
• 품목 코드: 고유(또는 카탈로그/출처별 고유)
• 계약 번호: 공급업체별 또는 전역 고유(정책을 선택하고 일관되게 강제)

가격표 임포트: 템플릿, 검증, 오류 처리

가격표는 기계 처리를 염두에 두고 만들어지지 않은 스프레드시트로 도착하는 경우가 많습니다. 매끄러운 임포트 흐름은 “앱을 쓰겠다”와 “계속 엑셀을 이메일로 주겠다”의 차이를 만듭니다. 목표: 업로드는 관대하게, 저장되는 데이터는 엄격하게.

지원 형식과 다운로드 가능한 템플릿

첫날부터 CSV와 XLSX를 지원하세요. CSV는 ERP와 BI 도구에서의 내보내기에 좋고, XLSX는 실제 공급업체가 보내는 형식입니다.

데이터 모델을 반영한 다운로드 가능한 템플릿을 제공하세요(오해를 줄이기 위해). 포함 항목:

• 정확한 열 이름을 담은 첫 행
• 유효한 값(통화, 단위, 날짜)을 보여주는 예시 행
• 각 열을 설명하는 선택적 "노트" 시트(XLSX의 경우)

템플릿은 버전 관리(예: Template v1, v2)를 해서 기존 프로세스를 깨뜨리지 않고 진화시킬 수 있게 하세요.

매핑 규칙: 필수 vs 선택 열

매핑 규칙을 명시적으로 정의하고 업로드 UI에서 보여주세요.

일반적인 접근법:

• 필수 열: 공급업체 식별자, 품목/SKU, 가격, 통화, 단위, 유효 시작일
• 선택 열: 유효 종료일, 최소 주문 수량, 리드타임, 포장, 인코텀즈, 코멘트
• 기본값(공급업체별 또는 업로드별): 통화, 단위, 시작일 기본값 "오늘", 종료일 비워둠

커스텀 열을 허용하면 그것들은 메타데이터로 취급해 핵심 가격 스키마를 어지럽히지 않도록 별도 저장하세요.

나쁜 데이터를 막는 검증 규칙

모든 것이 커밋되기 전에 검증을 실행하세요:

• 숫자 형식: 숫자가 아닌 가격 셀 거부; 천 단위 구분자 정규화; 음수 가격 금지
• 통화 코드: ISO 4217 대조(예: USD, EUR)
• 날짜 범위: 시작일 필수; 종료일은 시작일 이후여야 함; 같은 품목에 대해 중복 유효 범위를 금지(정책에 따라)
• 중복 행: 동일 키(예: 공급업체 + SKU + 시작일 + 통화 + 단위) 탐지. 오류로 처리할지, '마지막 값 우선'으로 할지 결정(오류가 안전함)

행 수준 검증(이 행이 잘못되었음)과 파일 수준 검증(이 업로드가 기존 레코드와 충돌함)을 모두 수행하세요.

오류 처리: 미리보기, 행별 피드백, 재업로드

좋은 임포트 경험은 업로드 → 미리보기 → 수정 → 확인의 흐름을 가집니다.

미리보기 화면에서:

• 셀을 하이라이트하고 명확한 메시지(예: "잘못된 통화 코드: US$")를 표시하는 표 제공
• "오류 리포트"(CSV) 다운로드 기능 제공(오류 열 포함)
• 마지막 시도의 매핑 선택을 유지하는 수정 후 재업로드 흐름 제공

"한 행의 오류로 전체 파일을 실패시키지 마세요." 대신 사용자가 선택하도록 하세요: 유효한 행만 임포트 또는 모든 오류가 수정될 때까지 차단.

추적성을 위한 원본 업로드 저장

감사성과 재처리를 위해 다음을 저장하세요:

• 원본 원파일(정확한 바이트), 체크섬 및 업로더 정보
• 파싱된 행과 검증 결과(오류 포함)
• 임포트 설정(템플릿 버전, 열 매핑, 기본값)

이렇게 하면 분쟁 시 "우리가 언제 무엇을 임포트했는가"를 방어할 수 있고, 검증 규칙이 바뀔 때 재처리가 가능합니다.

계약 레코드: 조건, 문서, 수정

계약 레코드는 단순한 파일 캐비닛 이상이어야 합니다. 갱신, 승인, 리포팅을 구동할 만큼 구조화된 데이터가 필요하면서도 서명된 문서를 쉽게 찾을 수 있어야 합니다.

핵심 계약 조건(구조화된 필드)

매주 조달팀이 묻는 질문에 답할 수 있는 필드를 우선하세요:

• 계약 시작일 및 종료일
• 갱신 유형(자동 갱신, 고정 기간, 상시) 및 갱신 기간
• 통지 기간(예: "종료 60일 전") 및 누가 통지받아야 하는지
• 결제 조건(Net 30/45/60, 조기 결제 할인) 및 청구 규칙
• 계약 담당자, 공급업체 연락처, 내부 이해관계자

엣지 케이스를 위한 자유 텍스트 노트는 두되, 필터/그룹/알림에 쓸 항목은 정규화하세요.

문서, 첨부파일, 보존

문서를 계약에 연결된 1급 엔티티로 취급하세요:

• 서명된 계약서(PDF)
• 수정서/추가 합의서
• 업무 명세서(SOW), 요율표, 보험 증명서, 준수 문서

각 파일에 대해 문서 유형, 유효일, 버전, 업로더, 기밀 등급 같은 메타데이터를 저장하세요. 보존 요구사항이 있으면 "보존 기간" 및 "법적 보류(legal hold)" 필드를 추가해 삭제를 방지하고 감사에 대응하세요.

수정 및 조항 추적

수정은 히스토리를 덮어써서는 안 됩니다. 날짜가 있는 변경으로 모델링하세요(종료일 연장, 상업적 조건 조정, 범위 추가/제거 등).

가능하면 주요 조항을 구조화된 데이터로 캡처해 알림과 리포팅에 활용하세요—예: 계약해지 허용 여부(Y/N), 물가연동 공식, 서비스 크레딧, 책임한도, 독점성 등.

하나의 계약, 다수의 공급업체 또는 사이트

중앙에서 구매하지만 여러 사이트에서 운영한다면 하나의 계약을 다수의 사이트/사업부에 연결하고(사이트별 오버라이드 허용) 계약 당사자를 명확히 보존하세요. 또한 하나의 계약이 모회사와 자회사를 포괄할 수 있게 하되, 준법을 위해 “계약 당사자”를 명확히 하세요.

승인 워크플로 및 거버넌스

승인은 가격표와 계약을 방어 가능한 상태로 만드는 곳입니다. 명확한 워크플로는 "누가 이것을 승인했는가?"라는 논쟁을 줄이고 공급업체 제출에서 사용 가능한, 컴플라이언트한 데이터로 가는 반복 가능한 경로를 만듭니다.

상태 흐름(명시적으로 유지)

가격표와 계약 레코드 모두에 대해 간단하고 눈에 보이는 수명주기를 사용하세요:

Draft → Review → Approved → Active → Expired/Terminated

• Draft: 제출자가 편집 가능; 구매에 사용되지 않음
• Review: 변경은 요청을 통해서만 가능; 검토자는 완전성과 정책 적합성 검증
• Approved: 결정 기록; 날짜 규칙으로 활성화 준비
• Active: 주문에 적용; 변경은 새 개정과 승인이 필요
• Expired/Terminated: 읽기 전용; 보고 및 감사용으로 보존

역할과 책임

앱 내에서 책임을 정의하세요(구전 지식에 맡기지 마세요):

• Submitter(조달/공급업체 매니저): 가격표 업로드, 계약 초안 작성, 검토 코멘트에 응답
• Reviewer(카테고리/재무): 가격, 단위, 통화, 상업적 정합성 확인
• Approver(예산 소유자): 상업적 영향에 대한 최종 결정
• Legal(법무): 계약 언어, 문서, 수정에 대해 필수 검토/승인자
• Admin(관리자): 임계값, 라우팅 규칙, 권한 구성(기본적으로 비즈니스 콘텐츠 승인 권한은 없음)

가격 변경 규칙(무단 비용 상승 방지)

자동으로 추가 승인 단계를 트리거하는 정책 기반 체크를 추가하세요:

• 임계값 승인: 예: 어떤 라인 항목이라도 \u003e5% 인상 또는 총 카테고리 지출 영향이 $10,000 초과 시 상위 승인자에게 라우팅
• 카테고리 기반 라우팅: IT, 물류 등 전략적 카테고리는 항상 법무 + 예산 소유자 필요
• 예외 처리: 오버라이드는 필수 사유 및 첨부파일 요구

감사 가능한 결정: 코멘트, 사유, 증거

모든 승인 또는 거부는 다음을 캡처해야 합니다:

• 결정(승인/거부/수정 요청)
• 사유 코드 + 자유 텍스트 설명
• 타임스탬프, 행위자, 영향받은 개정 버전
• 연결된 증거(이메일 PDF, 공급업체 서신, 회의 노트)

에스컬레이션, 타임아웃, 책임성

승인이 지연되지 않도록 서비스 수준 기대치를 설정하세요:

• 24/48시간 자동 리마인더
• 설정된 타임아웃 후 백업 승인자로 에스컬레이션
• “내가 승인 대기 중인 항목” 큐와 연체 리포트로 가시성 제공

거버넌스는 사후 강제가 아니라 워크플로에 내장될 때 가장 잘 작동합니다.

사용자 경험: 화면, 검색, 리포팅

조달 앱은 사람들이 "현재 가격은 무엇인가?", "이 품목을 규정하는 계약은 무엇인가?", "지난 분기 이후 무엇이 변경되었나?" 같은 단순한 질문에 얼마나 빨리 답하느냐에 따라 성공 여부가 갈립니다. UI를 데이터베이스 테이블이 아니라 이러한 워크플로 중심으로 설계하세요.

빠른 정보 찾기: 검색과 필터

상단 내비게이션에 두 가지 주요 진입점을 제공하세요:

• 공급업체 검색(이름, 세금 ID/벤더 코드, 상태, 카테고리)
• 품목 검색(SKU/파트 번호, 설명, 제조사, 단위)

결과 페이지에서는 실제 작업과 맞는 계약 필터를 제공하세요: 유효일, 계약 상태(초안/활성/만료), 사업부, 통화, "승인 대기 중" 등. 필터는 칩 형태로 보여 쉽게 제거할 수 있게 하세요.

먼저 설계할 주요 화면

공급업체 프로필은 허브가 되어야 합니다: 활성 계약, 최신 가격표, 진행 중인 분쟁/노트, "최근 활동" 패널 포함.

계약 뷰는 “우리는 무엇을 어떤 조건으로 언제까지 구매할 수 있는가?”에 답해야 합니다. 주요 조건(인코텀즈, 결제 조건), 첨부 문서, 수정 타임라인을 포함하세요.

가격표 비교는 사용자가 많은 시간을 소비하는 곳입니다. 현재 vs 이전을 나란히 보여주고:

• 유효일(및 "미래" 가격)
• 품목별 변동(절대값 및 %)
• 신규/삭제된 품목 하이라이트

리포팅 및 내보내기

리포트는 장식적이기보다 실행 가능해야 합니다: “60일 내 만료”, “가장 큰 가격 인상”, “여러 활성 가격을 가진 품목” 등. 재무용 CSV와 공유/승인용 PDF를 원클릭으로 제공하되, UI의 필터가 그대로 적용되게 하세요.

단순하고 설명적이게 유지

명확한 레이블("유효 시작일" 대신 "Effective date" 같은 내부 용어를 피해 한국어로 명확히), 까다로운 필드에 대한 인라인 도움말(단위, 통화), 빈 상태 메시지("가격표를 임포트하여 변경 추적을 시작하세요")를 사용하세요. /help의 짧은 온보딩 체크리스트는 교육 시간을 줄여줍니다.

보안, 권한, 감사 추적

보안은 나중에 덧붙이는 것보다 워크플로에 설계하는 것이 더 쉽습니다. 조달 앱의 목표는 간단합니다: 사용자들은 자신이 책임진 것만 보고 변경하며, 모든 중요한 변경은 추적 가능해야 합니다.

역할 및 권한(최소 권한 원칙)

작고 명확한 역할 모델을 시작하고 이를 액션 단위로 매핑하세요:

• Viewer: 승인된 가격표와 활성 계약 읽기 전용
• Editor: 드래프트 생성, 문서 업로드, 임포트 오류 수정
• Approver: 드래프트 승인/거부, 유효일 잠금, 수정 승인
• Admin: 사용자, 역할, 참조 데이터, 시스템 설정 관리

권한은 모든 엔드포인트에서 서버 측으로 강제 적용되어야 합니다(UI 권한만으론 부족).

민감 데이터 처리

초기에 무엇이 추가 보호가 필요한지 결정하세요:

• 계약 파일(PDF, 스캔): 저장 시 암호화, 다운로드 제한, 선택적 워터마크
• 은행 정보: 별도, 더 제한된 영역에 저장; 소수의 재무 역할만 가시성 허용
• 가격 가시성: 마진이나 특별 가격을 광범위하게 노출하지 않도록 고려; 필요 시 "내부용 vs 공급업체용" 뷰 지원

감사 추적: 누가 무엇을 어떻게 변경했는가

핵심 엔티티(계약, 조항, 가격 항목, 승인)에 대해 불변 감사 로그를 캡처하세요: 누가, 무엇을 변경했는지(이전/이후), 언제, 출처(UI/임포트/API). 임포트 파일명과 행 번호도 기록해 문제 추적과 수정이 가능하게 하세요.

인증 및 세션 기본

주요 로그인 방법 하나를 선택하세요:

• SSO(SAML/OIDC): 엔터프라이즈 사용자용, 또는 비밀번호 + MFA: 소규모 팀용

민감한 작업(예: 가격 내보내기)에는 짧은 토큰 수명, 보안 쿠키, 비활성 타임아웃, 재인증 요구를 적용하세요.

준수(과대 약속 없이) 기본

실용적 통제를 목표로 하세요: 최소 권한, 중앙 로깅, 정기 백업, 복구 훈련. 감사 로그는 비즈니스 기록으로 취급해 삭제를 제한하고 보존 정책을 정의하세요.

가격 규칙: 유효일, 통화, 단위

가격은 거의 절대 "하나의 숫자"가 아닙니다. 구매자, AP, 공급업체 모두 "오늘 이 품목의 가격은 무엇인가?"에 대해 같은 답을 얻어야 합니다.

유효일 지정(시작/종료, 미래 가격, 중첩)

가격을 시작일과 선택적 종료일을 가진 시간 경계 레코드로 저장하세요. 미래 일자를 허용하고(예: 다음 분기 인상), "오픈엔디드"는 보통 "대체될 때까지 유효"로 정의하세요.

중첩은 의도적으로 처리하세요:

• 기본적으로 임포트 시 중첩을 거부(거버넌스에 유리)
• 프로모션 가격처럼 필요하면 우선순위 규칙을 허용하되 사유 및 승인을 요구

실용적 규칙: 특정 시점에서 공급업체-품목-통화-단위 당 하나의 기본 가격만 허용; 나머지는 명시적 오버라이드로 표시.

“현재 가격” 정의

여러 후보가 존재할 때 순서를 정의하세요(예 예시):

1. 계약으로 커버되는 가격(계약이 활성이고 품목이 범위에 있을 때)
2. 승인된 오버라이드(프로모션/예외, 유효 기간 내)
3. 표준 공급업체 가격표(유효 기간 내)
4. 대체값 또는 "가격 없음" 상태(사용자 조치 필요)

공급업체 선호도가 있으면 동일 품목에 여러 공급업체가 있을 때 쓰이는 공급업체 우선순위 필드를 명시적으로 추가하세요.

다중 통화 전략

어떤 방식을 저장할지 선택하세요:

• 가격 레코드별 저장된 환율(감사성에 유리; 과거 결정을 재현 가능)
• 실시간 환율 변환(대시보드에 유용; 원래 통화는 항상 저장)

많은 팀은 둘 다 사용합니다: 공급업체 가격은 원화(원래 통화)로 저장하고 보고용으로 "기준 시점 변환값"을 함께 저장합니다.

반올림 및 단위 변환

단위 정규화(각품, 케이스, kg 등)를 정의하고 변환 계수를 버전 관리하세요. 반올림 규칙(통화 소수점, 최소 가격 증분)을 일관되게 적용하고, 반올림이 언제 일어나는지(단위 변환 후, 환율 변환 후, 최종 행 합계 후)를 명확히 하세요.

갱신, 알림, 운영 대시보드

갱신은 계약 가치를 지키는 곳입니다: 통지 기간 누락, 무심코 발생하는 자동 갱신, 막판 협상은 불리한 조건으로 이어질 수 있습니다. 앱은 갱신을 관리되는 프로세스로 처리해야 합니다: 명확한 날짜, 책임자, 작업 큐.

갱신 타임라인 및 리마인더

갱신을 계약(또는 선택적으로 특정 수정)에 연결된 마일스톤 집합으로 모델링하세요:

• 종료일(만료)
• 통지 마감일(취소/재협상의 최종일)
• 갱신 창 시작(소싱을 시작해야 하는 시점)

이 마일스톤을 중심으로 리마인더를 만들고, 실용적 기본값은 통지 기한을 기준으로 90/60/30일 전의 캔디드와 당일 알림입니다.

알림 채널 및 전달

초기에는 두 채널로 시작하세요:

• 앱 내 알림: 일상 작업 큐용
• 이메일: 시간 민감 알림용

선택적으로 계약별 또는 사용자별로 ICS 캘린더 파일 내보내기(Outlook/Google Calendar 구독 가능)를 지원하세요.

알림은 실행 가능해야 합니다: 계약명, 공급업체, 정확한 데드라인, 레코드로의 딥링크를 포함하세요.

소유권 및 에스컬레이션

알림 대상:

• 계약 담당자(기본)
• 카테고리 담당자(다르다면 보조)
• 백업 담당자(대체 커버리지)

에스컬레이션 규칙 추가: 기본 담당자가 X일 내 확인하지 않으면 백업 또는 관리자에게 알림. "확인(acknowledged)" 타임스탬프를 추적해 알림이 단순 배경 소음이 되지 않게 하세요.

작업을 이끄는 운영 대시보드

대시보드는 단순하고 필터 가능하며 역할 인지형이어야 합니다:

• 곧 만료되는 계약(30/60/90일, 통지 기한 포함)
• 갱신 작업이 지연된 계약(미확인 또는 마일스톤 지남)
• 승인 대기 중인 가격표(연령, 소유자)

각 위젯은 필터된 목록 보기와 내보내기로 연결되어 대시보드가 단순한 리포트가 아니라 실행의 출발점이 되게 하세요.

MVP 계획, 테스트, 배포 체크리스트

공급업체 가격표와 계약을 위한 MVP는 한 가지를 증명해야 합니다: 팀이 안전하게 가격을 올리고, 올바른 계약을 빠르게 찾고, 승인과 감사 기록을 신뢰할 수 있어야 합니다.

MVP 범위(필수 항목)

많은 기능을 부분적으로 구현하기보다 얇고 엔드투엔드 워크플로 하나를 증명하세요:

• 공급업체 + 품목 마스터 기본: 공급업체, 제품/서비스, 단위, 통화
• 가격표 임포트: 하나 또는 두 가지 템플릿(CSV/XLSX), 미리보기, 필드 매핑(필요 시), 검증, 명확한 오류 리포트
• 계약 레코드: 핵심 날짜(시작/종료, 통지 기간, 갱신 유형), 첨부파일, 공급업체 및 관련 가격표 버전 연결
• 승인: 하나의 간단한 워크플로(Draft → Review → Approved)와 역할 기반 권한, 감사 로그
• 검색 + 보고: 글로벌 검색(공급업체, SKU, 계약 ID) 및 "현재 승인된 가격" 단일 내보내기

작게 빠르게 움직이는 팀이라면 Koder.ai로 초기 제품 골격(React 프론트엔드, Go 백엔드, PostgreSQL)을 빠르게 띄우고 조달/법무 이해관계자와 워크플로를 검증한 뒤 소스코드를 익스포트해 확장하는 전략도 고려하세요.

테스트 계획(실무에서 무엇이 깨지나)

실수가 비용이 큰 부분에 테스트를 집중하세요:

• 임포트 검증 테스트: 필수 열 누락, 잘못된 통화/단위, 중복 행, 날짜 중첩, 음수 가격, 혼합 소수 구분자
• 권한 테스트: 누가 임포트할 수 있는지, 승인할 수 있는지, 승인 후 편집 권한, 민감 첨부파일 보기 권한 등
• 워크플로 테스트: 편집 시 재승인, 거부 시 코멘트 필수, 상태 변경마다 감사 항목 생성

배포 및 롤아웃

생산 유사 데이터를 갖춘 스테이징을 사용하세요(데이터 마스킹/익명화). 체크리스트: 백업 활성화, 마이그레이션 스크립트 리허설, 롤백 계획(버전 관리된 DB 마이그레이션 + 배포 되돌리기).

임포트 실패, 느린 검색 쿼리, 승인 병목 현상에 대한 모니터링을 추가하세요.

출시 후 반복

조달 및 재무와 2–4주 피드백 루프를 운영하세요: 임포트에서 발생한 상위 오류, 계약에 누락된 필드, 느린 화면. 다음 우선순위는 ERP 통합, 공급업체 포털 업로드, 절감액 및 컴플라이언스에 대한 분석 등이 될 수 있습니다.

권장 내부 참고: /pricing 및 /blog.