이 글의 목적은 K-REACH 대응을 위해 기업 내부에 구축해야 하는 IT 시스템 요구사항을 기능·데이터·보안·운영 관점으로 정리하여 실무에서 바로 적용할 수 있게 하는 것이다.
1. K-REACH 대응 IT 시스템이 필요한 이유
K-REACH 업무는 물질 단위 데이터와 사업장 단위 실적 데이터가 동시에 필요하다.
등록·신고·보고는 제출 시점뿐 아니라 준비 과정에서 반복적인 자료 보완과 내부 검토가 발생하다.
따라서 규제 준수 품질을 사람의 기억과 파일 폴더 구조에 의존하면 오류가 구조적으로 누적되다.
IT 시스템은 물질 데이터의 단일 원장과 문서 증적을 기반으로 업무 흐름을 표준화하는 장치이다.
2. 구축 범위 정의와 목표 아키텍처
2.1 구축 범위 3단계 모델
범위 정의는 과투자와 과소구축을 동시에 막는 출발점이다.
1단계는 물질 마스터와 문서관리 중심의 레지스트리이다.
2단계는 워크플로우와 승인, 제출 산출물 자동생성까지 포함한 준수 운영 시스템이다.
3단계는 ERP·PLM·구매·물류·SDS 시스템과 연동하는 전사 통합 규제 플랫폼이다.
2.2 권장 아키텍처 원칙
데이터는 단일 원장으로 통합하고 화면은 역할 기반으로 분리하는 구조가 바람직하다.
문서 파일은 버전 관리 가능한 저장소에 두고 메타데이터는 DB로 관리하는 구성이 적합하다.
외부 제출용 산출물은 템플릿 기반으로 생성하고 생성 이력을 변경불가 로그로 남기다.
주의 : 시스템 목표를 “제출 화면 자동화”로만 정의하면 내부 데이터 품질과 증적 관리가 붕괴하다.
3. 핵심 기능 요구사항
3.1 물질 마스터 데이터 관리
물질 마스터는 K-REACH 대응의 기준 데이터이다.
물질 식별은 CAS, EC, 국문명, 영문명, 동의어, UVCB 여부, 조성정보를 함께 관리해야 하다.
동일 물질의 표기 변형을 하나로 묶는 정규화 규칙이 필수이다.
혼합물은 구성성분, 함량 범위, 분류 근거, 공급처별 차이를 버전으로 분리해 관리해야 하다.
3.2 톤수 산정과 의무 판단 엔진
의무 판단은 연간 제조·수입·사용 실적 데이터에 의해 결정되다.
거래 단위가 kg, L, drum, lot 등으로 혼재하므로 단위 변환과 밀도 적용 로직이 필요하다.
법적 예외와 특례는 규칙 엔진으로 관리하고 규칙 변경 이력을 남겨야 하다.
의무 판단 결과는 “근거 데이터 스냅샷”과 함께 보관해야 하다.
3.3 등록·신고·보고 업무 워크플로우
업무 단계는 접수, 범위확정, 데이터수집, 시험자료 확보, 위해성 문서 작성, 내부검토, 제출, 사후관리로 구성되다.
각 단계는 담당자, 기한, 산출물, 검토 체크리스트가 연결되어야 하다.
반려와 보완은 동일 케이스의 버전으로 기록되어야 하다.
3.4 시험자료·문헌·위해성 문서 관리
시험자료는 원문 파일, 요약본, 데이터 포인트, 신뢰성 평가를 함께 저장해야 하다.
자료의 출처, 사용 범위, 재사용 가능 조건을 필드로 관리해야 하다.
문서 템플릿은 회사 표준과 제출 요구 형식을 동시에 만족해야 하다.
3.5 CBI와 비공개 자료 관리
비공개 항목은 접근권한과 열람 이력 통제가 필수이다.
비공개 사유와 공개 시 리스크 평가 기록을 함께 저장해야 하다.
내부 공유용 버전과 제출용 버전을 분리해 자동 마스킹하는 기능이 유효하다.
3.6 공급망 커뮤니케이션과 하류 사용자 대응
등록자와 하류 사용자 간 정보 제공 의무는 SDS 전달과 별개로 관리되어야 하다.
물질의 용도, 노출 시나리오, 위험관리조치 같은 커뮤니케이션 항목을 구조화해야 하다.
하류 사용자 용도 변경 요청, 사용조건 변경, 정보 제공 기한을 티켓 형태로 운영해야 하다.
3.7 외부 시스템 제출 지원
환경부 화학물질정보처리시스템을 통한 등록·신고·보고 제출 흐름을 사내 프로세스에 맞춰 표준화해야 하다.
제출 직전 데이터 묶음을 “제출 패키지”로 고정하고 해시값을 남기는 기능이 필요하다.
제출 후 접수증, 보완요청, 처리결과를 케이스에 자동 귀속시키는 기능이 필요하다.
4. 데이터 요구사항과 데이터 모델
4.1 필수 데이터 도메인
| 도메인 | 핵심 데이터 | 품질 규칙 | 주요 연계 |
|---|---|---|---|
| 물질 마스터 | CAS, 명칭, 동의어, 조성, 분류, UVCB | 중복 식별 금지, 정규화, 버전관리 | R&D, 구매, SDS |
| 제품·혼합물 | 구성성분, 함량범위, 배합 버전, 공급처 | 배합 변경 시 신규버전 생성 | PLM, 품질, SDS |
| 실적·톤수 | 제조·수입·사용·판매, 단위, 밀도, 환산 | 원천 데이터 스냅샷 보관 | ERP, 물류 |
| 규제 의무 | 등록/신고/보고 판단 결과, 근거 규칙 | 규칙 변경 이력 필수 | 컴플라이언스 |
| 자료·문서 | 시험자료, 문헌, 평가서, 제출 패키지 | 원문 불변, 열람 이력 | DMS, 전자결재 |
| 대외 커뮤니케이션 | 공급망 정보 제공, 문의, 답변, 기한 | SLA와 증적 보관 | CRM, 메일 |
4.2 권장 식별자 체계
물질은 내부 물질ID를 기본키로 두고 외부 식별자는 속성으로 관리하는 방식이 안정적이다.
케이스는 “연도-유형-일련번호” 형태로 사람이 읽을 수 있게 설계하는 편이 운영에 유리하다.
문서는 “문서종-물질ID-버전-일자” 규칙으로 자동 명명하는 정책이 효과적이다.
4.3 데이터 예시 스키마
{ "substance_id": "SUB-000123", "identifiers": { "cas": "000-00-0", "ec": "000-000-0", "name_ko": "물질명", "name_en": "Substance name", "synonyms": ["동의어1", "동의어2"], "uvcb": false }, "composition": [ {"component_cas": "111-11-1", "name": "Component A", "w_w_percent_min": 10.0, "w_w_percent_max": 20.0} ], "classification": { "ghs_revision": "UN GHS Rev.4", "hazard_classes": ["Acute Tox. 4"], "evidence": [{"type": "study", "doc_id": "DOC-TOX-0009"}] }, "tonnage": { "year": 2026, "manufacture_kg": 0, "import_kg": 1200, "calculation_snapshot_id": "SNAP-2026-0011" } }5. 보안·권한·감사 요구사항
5.1 역할 기반 접근제어
권한은 최소권한 원칙으로 설계해야 하다.
물질 담당, 제품 담당, 자료 담당, 검토자, 승인자, 관리자 권한을 분리해야 하다.
비공개 자료는 별도 보안 등급을 두고 다운로드 제한을 적용해야 하다.
5.2 감사 로그와 변경 이력
누가 언제 어떤 필드를 어떻게 변경했는지 추적 가능해야 하다.
제출 패키지는 생성 후 변경 불가 상태로 잠그는 기능이 필요하다.
전자서명 또는 승인 이력은 법적 분쟁 대응의 핵심 증적이 되다.
주의 : 감사 로그가 화면 이벤트 수준으로만 남으면 실제 데이터 변경의 원인과 책임 추적이 불가능하다.
6. 연동 요구사항
6.1 ERP·구매·물류 연동
톤수 산정의 신뢰성은 원천 실적 데이터 품질에 의해 결정되다.
주문·통관·입고·출고·생산 실적을 기준으로 자동 집계하는 연동이 필요하다.
6.2 SDS 시스템과의 연동
K-REACH 데이터와 산업안전보건 체계의 SDS 데이터는 겹치는 영역이 크다.
분류, 구성성분, 노출·관리조치 정보는 단일 소스로 유지하는 방향이 효율적이다.
6.3 문서관리와 전자결재 연동
시험자료와 보고서 파일은 문서관리시스템에 저장하고 링크로 참조하는 방식이 안정적이다.
승인 프로세스는 전자결재와 연결해 조직 표준 통제를 적용해야 하다.
6.4 API 연동 예시
# pseudo code GET /erp/transactions?year=2026&material_code=MAT-001 -> normalize_units() -> map_to_substance_id() -> calculate_tonnage_snapshot() -> update_obligation_rules() -> create_tasks_if_deadline_risk()7. 운영 요구사항
7.1 일정·마감 관리
마감 관리는 규제 일정과 내부 리드타임을 동시에 고려해야 하다.
업무 케이스별 표준 리드타임을 정의하고 위험 임계치를 기준으로 알림을 발행해야 하다.
7.2 품질지표와 대시보드
데이터 완성도, 필수 문서 누락, 검토 반려율, 보완 회수 같은 지표가 필요하다.
경영 보고용 지표와 실무 개선용 지표를 분리해 운영해야 하다.
7.3 변경관리
법령·고시·가이드 변경은 규칙 엔진과 템플릿의 변경으로 연결되다.
변경 사항은 테스트 환경에서 검증한 뒤 운영 반영해야 하다.
8. 구축 단계별 산출물 체크리스트
| 단계 | 필수 산출물 | 합격 기준 |
|---|---|---|
| 요구사항 정의 | 업무 흐름도, 데이터 사전, 권한 설계, 연동 목록 | 케이스 유형별 예외처리 정의 완료 |
| 설계 | ERD, 화면 목록, 로그 정책, 템플릿 설계 | 감사로그 요구 충족 |
| 구현 | 마이그레이션, API 연동, 템플릿 생성, 알림 | 원천 데이터 대비 집계 오차 0 |
| 검증 | 샘플 케이스 리허설, 제출 패키지 재현 테스트 | 동일 입력 시 동일 출력 보장 |
| 운영 | 표준작업서, 교육, 권한 부여 프로세스, 백업 | 월간 품질점검 루틴 정착 |
9. 실패 패턴과 예방 포인트
9.1 엑셀 기반 분산 운영
엑셀은 빠른 시작에는 유리하지만 통제와 증적에 취약하다.
파일 복제와 버전 충돌이 반복되면 동일 물질이 여러 정의로 존재하다.
9.2 문서만 모으고 데이터는 남기지 않는 방식
문서 저장만 하고 핵심 데이터 포인트를 구조화하지 않으면 검색과 재사용이 불가하다.
후속 등록, 변경등록, 공급망 문의 대응에서 재작업 비용이 폭증하다.
9.3 권한 통제 부재
비공개 자료가 일반 공유 폴더에 저장되면 유출 리스크가 상시화되다.
열람 로그가 없으면 사고 시 원인 규명이 불가능하다.
주의 : 비공개 자료는 “보관”이 아니라 “통제”가 핵심이다.
10. FAQ
사내 시스템을 구축하면 외부 제출 시스템 사용이 불필요하다?
외부 제출은 공적 시스템을 통해 이행하는 구조가 일반적이다.
사내 시스템은 제출 준비와 품질 통제, 증적 보관을 담당하는 역할이다.
가장 먼저 구축해야 하는 기능은 무엇이다?
물질 마스터 단일 원장과 문서 버전관리 기능이 우선이다.
이 기반이 없으면 워크플로우 자동화의 효과가 급감하다.
ERP 연동이 어려우면 대안은 무엇이다?
초기에는 표준 업로드 양식을 강제하고 업로드 스냅샷을 남기는 방식이 대안이다.
단위 변환과 환산 로직은 시스템 내부에서 일관되게 수행해야 하다.
비공개 항목 관리는 어떻게 설계해야 하다?
보안 등급, 접근권한, 열람 이력, 자동 마스킹, 제출용 분리본 생성이 핵심이다.
사유와 검토 기록을 함께 남겨야 감사 대응이 가능하다.