남아프리카 공화국 정부 입찰(Government tender)에 참여해 본 적이 있다면 그 과정을 잘 아실 겁니다. CIDB 등급, B-BBEE 스코어카드, CSD 등록 번호, SBD/MBD 양식, 그리고 항상 "관보(Gazette) 발행일로부터 공휴일을 제외한 영업일 기준"으로 정해지는 마감일 같은 것들 말이죠. 이 중 개념적으로 어려운 것은 아무것도 없습니다. 그저 지루할 뿐이며, 지루함이야말로 개발자들이 자동화하여 해결하고 싶어 하는 바로 그 종류의 문제입니다.

저는 이와 관련된 도구를 찾다가 Tenders SA의 toolkit page에 도달하게 되었습니다. 이 도구들은 개발자가 아닌 공급업체를 대상으로 하지만, 몇몇 도구들은 제가 평소 스크립트로 해결하려 했던 문제들과 깔끔하게 매칭되었습니다. 따라서 개발자의 관점에서 정리해 보고, 제가 가장 유용하다고 느낀 도구를 빠르게 재구현해 보았습니다.

제가 분류한다면 다음과 같이 나눌 툴킷

Tenders SA는 14개의 도구를 계획 및 초안 작성 (Plan & Draft), 준수 및 자격 (Compliance & Eligibility), **시장 정보 (Market Intelligence)**라는 세 가지 범주로 그룹화합니다. 입찰 과정을 하나의 파이프라인(Pipeline)으로 생각한다면, 이는 각각 스케줄링 (scheduling), 검증 (validation), _분석 (analytics)_과 거의 1:1로 매칭됩니다. 소프트웨어를 만드는 것이 직업인 사람들에게는 매우 편안한 사고 모델입니다.

스케줄링: 입찰 준비 플래너 및 마감일 계산기 (무료)

두 도구 모두 남아프리카 공화국의 공휴일을 반영하여 영업일 계산을 수행합니다. 하나는 브리핑 세션 알림 기능이 포함된 단계별 계획 UI를 제공하고, 다른 하나는 순수한 마감일 계산기입니다. 만약 비즈니스 마감일이 "입찰 유효 기간 90일" 또는 "관보 발행 후 영업일 기준 20일 이내 마감"이라고 되어 있다면, 이는 단순히 공휴일 제외 목록을 포함한 날짜 산술(Date arithmetic) 문제이며, 손가락으로 세다가 실수하고 싶지 않은 바로 그런 종류의 작업입니다.

터미널을 떠나고 싶지 않은 분들을 위해 핵심 로직을 약 15줄 정도로 정리했습니다:

// 영업일 마감일 계산, 2026년 남아프리카 공화국 공휴일
const holidays = new Set([
  '2026-01-01','2026-03-21','2026-04-03','2026-04-06',
...

일회성 확인용으로는 괜찮습니다. 이 플랫폼의 버전은 여기에 브리핑 세션 (briefing-session) 추적 기능까지 추가되어 있는데, 이 부분은 제가 직접 다시 만들고 싶지 않은 부분입니다. 의무적인 브리핑 세션을 놓치는 것은 많은 지방 자치 단체의 입찰에서 즉각적인 실격 사유가 되며, 이는 확인하는 것을 잊어버릴 수 있는 크론 잡 (cron job)이 아니라, 사용자에게 알려주는 UI (User Interface)가 실제로 필요한 영역이기 때문입니다.

검증 (Validation): 준수 사항 계산기

이 부분은 제가 직접 구현하기보다 진심으로 API를 사용하고 싶은 영역입니다. 왜냐하면 입력값들 (CIDB 등급 산정 공식, B-BBEE 개정 일반 스코어카드 (Amended Generic Scorecard), JV 통합 규칙)이 단순한 비즈니스 로직이 아니라 법으로 규정된 (legislated) 사항이기 때문입니다. 즉, 규정이 바뀌면 함께 바뀌며, 이를 하드코딩하는 것은 유지보수의 함정이 됩니다.

• B-BBEE 점수 계산기 (B-BBEE Points Calculator) — 스스로 보고한 선서(affidavit) 수준을 신뢰하는 대신, 개정된 일반 스코어카드 (Amended Generic Scorecard)를 기준으로 점수를 산출합니다.
• CIDB 등급 계산기 (CIDB Grade Calculator) — 재무 능력과 완료된 작업 이력을 바탕으로 실제 계약자 등급을 도출합니다.
• JV 계산기 제품군 (JV Calculator Suite) — 기술적으로 가장 흥미로웠던 부분입니다. 서로 다른 스코어카드를 가진 JV (Joint Venture) 파트너가 두 곳 이상일 경우, 통합된 B-BBEE 수준을 해결해야 할 뿐만 아니라 여러 엔티티 (entities)에 걸친 프런팅 리스크 (fronting risk)를 식별해야 하므로, 이는 진정으로 까다로운 집계 문제이기 때문입니다.
• 준수 사항 체크리스트 생성기 (Compliance Checklist Generator) — 입찰 금액 및 산업군별로 제출해야 하는 특정 서류 목록을 출력합니다. 실제로는 예상보다 변동 폭이 큽니다 (어떤 지방 자치 단체는 이사의 개인 지방세 납부 증명서를 요구하고, 어떤 곳은 입찰 서류 대신 KYC 설문지를 요구하기도 합니다).

이 중 어느 것도 제 입찰에서 스스로 '신뢰할 수 있는 단일 원천 (source of truth)'으로 삼고 싶은 것은 아닙니다. 만약 잘못 계산한다면, 그것은 단순한 버그를 배포하는 문제가 아니라 계약에서 실격되는 문제가 됩니다.

분석 (Analytics): 프로급 기능

Tender Value Estimator (입찰 가치 추정기), Market Heatmap (시장 히트맵), Company Intelligence (기업 인텔리전스), 그리고 Tender Forensic Analysis (입찰 포렌식 분석) 기능은 유료 티어(월 R499부터 시작)에 포함되어 있습니다. 이 기능들은 공개용 도구라기보다는 내부 BI (Business Intelligence) 대시보드에 더 가깝습니다. 과거 낙찰 데이터, HHI 방식의 집중도 지표, 입찰 분할 및 이해상충 탐지 기능 등을 제공합니다. 만약 여러분이 평소에 직접 데이터를 수집하여 빠르게 대시보드를 구축하는 유형의 사람이라면, 이 기능이 스크래핑(Scraping) 수고를 덜어줄 것입니다.

**Restricted Suppliers Register (제한된 공급업체 명부)**는 입찰 계획이 전혀 없더라도 확인해 볼 가치가 있다고 말씀드리고 싶은 유일한 예외입니다. 이는 OCPO(Western Cape Government Office of the Chief Procurement Officer)의 제한된 공급업체 목록과 실시간으로 동기화되며, 계약에 서명하기 전에 잠재적인 하도급업체나 JV (Joint Venture, 합작 투자) 파트너의 이름을 통해 신속하게 상태를 확인(Sanity-check)할 수 있는 방법입니다.

이 스택을 실제로 활용할 지점

만약 제가 남아프리카 공화국(SA) 정부 입찰에 정기적으로 참여하는 기업을 위한 내부 도구를 구축한다면, 다음과 같은 직관적인 접근 방식을 취할 것입니다:

1. 날짜 계산 (Date math) (위에서 언급한 내용)은 직접 구현한다 — 의존성(Dependency)을 추가할 만큼 복잡하지 않고 충분히 간단하기 때문입니다.
2. 규정에서 파생된 모든 사항(CIDB, B-BBEE, JV 점수 산정 등)에 대해서는 **준수 사항 계산기 (Compliance calculators)를 신뢰할 수 있는 단일 출처 (Source of truth)**로 사용한다 — 법으로 정해진 점수 산정 로직을 사내에서 직접 재구현하지 마십시오.
3. 제한된 공급업체 (Restricted Suppliers) 조회를 모든 조달 워크플로우에서 사전 점검(Pre-flight check) 단계로 취급한다. 이는 벤더를 온보딩하기 전에 제재 목록(Sanctions-list)을 확인하는 것과 동일한 방식입니다.
4. 시장 인텔리전스 (Market intelligence) 티어는 가격 벤치마크가 실제 수치를 변화시킬 정도로 입찰을 자주 하게 되었을 때만 비용을 지불한다 — 그렇지 않다면 거의 활용하지 않을 데이터가 될 것입니다.

더 큰 패턴

더 큰 패턴

위와 같은 멘탈 모델 (mental model)을 구축하면서 제가 느낀 점은, 이것이 사실 조달 (procurement)의 탈을 쓰고 있는 컴플라이언스 자동화 (compliance-automation) 문제라는 사실입니다. "CIDB 등급 (CIDB grading)"을 "SOC 2 증거 (SOC 2 evidence)"로 바꾸고, "B-BBEE 스코어카드 (B-BBEE scorecard)"를 "공급업체 리스크 등급 (vendor risk tier)"으로 바꾼다면, 이는 기업 조달 및 공급업체 온보딩 (vendor-onboarding) 도구가 다른 모든 곳에서 해결하는 문제와 동일한 형태입니다. 즉, 마감 기한 추적, 규제된 루브릭 (regulated rubric)에 따른 자격 점수 산정, 그리고 제한 대상자 스크리닝 (restricted-party screen)의 문제입니다. 만약 이 중 하나라도 구축해 본 경험이 있다면, 이 모든 것이 낯설게 느껴지지 않을 것입니다. 이는 모든 규제 시장에 존재하는 도구 유형이 남아프리카 공화국이라는 특정 상황에 적용된 사례일 뿐입니다.

공개 사항: 저는 Tenders SA에서 근무하지 않습니다. 이 글은 남아프리카 공화국 정부 조달 도구를 조사하는 동안 유용하다고 느꼈던 툴킷을 정리한 것뿐입니다. 기능 가용성과 가격은 플랫폼에서 제어하며, 작성 시점 이후 변경되었을 수 있습니다.