INSIGHT
Tech Blog
LabQ의 엔지니어들이 현장의 문제를 해결하며 얻은 기술적 경험과 R&D 인사이트를 공유합니다.
[R&D] 제조화학 SHE 합성 데이터 설계기
-
김
김수빈
선임연구원
- 26.06.26
TL;DR
제조화학·유해물질 도메인의 SHE(안전·보건·환경) 데이터, 특히 SHE 팀이 관리하는 비상대응 훈련에 쓰이는 사고·위험 데이터는 기밀이고, 희소하고, 유출되면 위험한 삼중 제약을 갖는다. 우리는 이 문제를 “데이터가 부족하니 더 모으자”가 아니라 “위험한 진짜를 굳이 보유하지 않기 위해 합성하자”로 다시 정의했다. 핵심은 생성 기술이 아니라 하나의 설계 경계다. 구조·인과적으로는 현실적이되, 실제 현장에서는 결코 실행할 수 없게. 이 글은 실제 위험 정보를 일절 노출하지 않는 선에서, 그 경계를 슬로건이 아니라 검증 가능한 수용 기준으로 만든 과정을 엔지니어 관점으로 정리한다.
공개 범위
이 글은 사내 R&D에서 출발해 실제 제조화학 AI 딜리버리로 이어진 작업을 다룬다. 구체적으로는 SHE 팀이 관리하는 비상대응 훈련 영역에서, 훈련 시나리오를 만들고 그 생성 AI를 평가하기 위한 합성 데이터다. 이 합성 프레임워크는 한 곳에 머물지 않았다. 사내 R&D에서 출발해, 그 데이터로 학습한 검색 모델을 거쳐, 데이터 분석 플랫폼에 배포되는 검색 기반 에이전트로 이어졌다(research-to-practice). 다만 고객·사업장 식별 정보, 실제 유해화학물질, 실제 사고 기록, 공정명, 설비명, 모델/파이프라인의 정량 성능 수치는 의도적으로 가렸다. 특히 실제 중대 사고 발생 사례는 어떤 형태로도, 추상적으로도 예시하지 않는다. 그 예시를 드는 순간이 곧 누설이기 때문이다. 이 글이 다루지 않는 것: 생성 모델 벤치마크, 실제 배포 아키텍처, 정량 성능 비교. 이 글은 데이터 설계와 거버넌스에 관한 글이다.
1. 문제: 가장 필요하지만, 가장 갖기 싫은 데이터
1.1 안전 AI의 데이터 역설
제조 현장의 비상대응 훈련을 돕는 안전 AI를 만들다 보면 역설과 마주한다. 모델에 가장 필요한 데이터인 실제 중대 사고 기록 데이터가 동시에 회사가 가장 보유하고 싶지 않은 데이터라는 점이다. 그것은 고객의 공정 기밀이자, 법적 책임이자, 유출되면 오남용될 수 있는 위험 정보다. 게다가 다행히도 중대 사고는 드물어서, 모델이 배우기엔 사례가 턱없이 부족하다.
문제는 한 겹 더 있다. 안전 AI를 만드는 데만 이 데이터가 필요한 게 아니라, 그 AI가 쓸 만한지 평가할 기준에도 같은 데이터가 필요하다. 채점 기준(골든셋)조차 위험한 진짜에 의존하는 것이다. 모델도, 모델을 평가할 잣대도 같은 금고 안에 있다.
그래서 우리는 목표를 다시 적었다. “데이터를 더 모으는 문제”가 아니라 “위험한 진짜를 굳이 들고 있지 않는 문제”로, 답은 합성이었다. 비행 시뮬레이터가 일어난 적 없는 추락으로 조종사를 훈련시키듯, 일어난 적 없는 사고로 모델을 학습·평가하는 것이다. 단, 한 가지 분명한 경계 위에서: 진짜처럼 유용하되, 실제로는 결코 만들 수 없게.
1.2 왜 익숙한 방법들은 부족한가
화학물질관리법에 의거하여, 유해화학물질 유출·누출 등이 발생했을 때 신고해야 하는 기준이 있는데, 공공데이터포털의 화학 사고 정보는 사고 재발 방지와 신속한 대응 체계 구축에 기여하기 위해 이용허락범위 제한 없음으로 공개되어 있다.
어차피 공개되어 있다면 “그냥 실제 데이터를 익명화하면 되지 않나?” 하는 질문이 이 도메인에서는 통하지 않는다. 익명화는 이름과 식별자를 지우지만, 위험을 만드는 것은 이름이 아니라 화학물질과 공정 구조다. 공개데이터의 사고 내용은 약식으로만 기술된다. 반대로 보안등급이 높은 실제 기록에는 도메인 전문가가 아니면 알아보지도 못할 핵심 정보가 담겨 있고, 위험은 바로 거기에 있다. 배합비·공정 조건·실패 인과는 익명화해도 그대로 남고, 그 자체가 기밀이자 위험이다. 게다가 중대 사고는 희소해서, 익명화로 가릴 모수 자체가 부족하다. 즉, k-익명성을 논할 표본이 없는 것이다.
수집을 늘리는 길도, 순수 규칙 템플릿으로 찍어내는 길도 각자의 벽에 부딪힌다. 우리가 검토하고 택하지 않은 대안과 그 이유는 다음과 같다.
| 대안 | 왜 매력적인가 | 왜 택하지 않았나 |
|---|---|---|
| 원시 실제 데이터 익명화 | 현실성 최상(원본 그대로) | 레시피·인과가 남아 기밀·위험 미해소, 희소 사건은 익명화 모수 부족 |
| 실제 데이터 + 접근통제 | 진짜를 그대로 활용 | “위험한 진짜를 안 들기”라는 목표 자체와 충돌, 유출 표면 상존 |
| 순수 규칙 템플릿 | 안전·완전 통제 | 현장 서술 특유의 지저분한 변이를 못 담아 비현실적, 판별력 없음 |
| 제약 없는 자유 생성 | 다양성·풍부함 | 드리프트하며 유효하지 않은 위험 조합 또는 민감 구체성 생성 |
결국 남는 것은 공개 지식 위에서, 제약된 생성으로, 거버넌스 게이트를 통과시킨 하이브리드다.
2. 접근: 안전 데이터의 크래시 테스트 더미
2.1 설계 규칙: “그럴듯하되 진짜 레시피는 아니게”
자동차 충돌 안전을 연구하려고 실제 사람을 차에 태워 벽에 부딪게 하지는 않는다. 대신 크래시 테스트 더미를 쓴다. 더미는 실제 신체처럼 변형되고 충격을 전달하지만(높은 현실성), 그 자체로는 누구도 해칠 수 없다(0에 가까운 실행가능성). 우리가 만들려는 합성 SHE 데이터가 정확히 이 자리에 있어야 했다.
그래서 프로젝트 첫날부터 설계 규칙을 하나 못 박았다. “그럴듯하되 실제 사례는 아니게.” 이것은 마지막에 덧붙이는 안전 점검이 아니라, 무엇을 생성할지/하지 않을지를 정하는 1차 설계 제약이다. 데이터의 골격은 전부 공개 표준(GHS 위험성 분류, MSDS 구조, 규제 항목 스키마, 공개 물성)에서 가져오고, 고객의 실제 사건으로는 시드조차 하지 않는다. 들일 경로 자체를 만들지 않는 것이다.
2.2 합성 파이프라인 구조
우리가 만든 것은 데이터 생성기라기보다 위험한 진짜를 들이지 않고도 신뢰할 수 있는 채점 기준을 찍어내는 설비에 가깝다. 비행 시뮬레이터가 실제 추락 영상이 아니라 공개된 항공역학과 표준 계기 배치 위에서 만들어지듯, 이 파이프라인도 고객의 실제 사고 기록이 아니라 공개 위험성 체계 위에서 출발한다. 전체 흐름은 다섯 단계의 게이트형 파이프라인이다.
① 공개 위험성 분류 체계
합성의 골격은 전부 공개 표준에서 가져온다. GHS 위험성 분류, MSDS의 섹션 구조, 규제 항목 스키마(화관법·화평법·산안법·PSM의 공개 카테고리), 공개 물성 정보가 그것이다. 이 단계가 정하는 것은 “어떤 필드가 존재하고, 어떤 위험 범주가 유효하며, 사건 리포트가 구조적으로 무엇을 담는가”다. 골격을 공개 스키마에서 가져오면 구조적 충실도는 확보하면서 어떤 독점 콘텐츠도 복제하지 않는다.
② 데이터 사양 정의
다음으로 목표 데이터셋을 명세(spec)로 적는다. 도메인 모델을 먼저 세우는 방식이다. “SHE 비상대응 시나리오(사건·위험성)”를 엔티티·속성·관계로 모델링하고, 그 위에 어떤 필드를, 어떤 분포로, 어떤 사고 유형 카테고리로, 어떤 인과 패턴(어떤 행위의 실패가 어떤 규모의 결과로 이어지는가)으로, 어떤 난이도·엣지케이스 커버리지로 채울지 규정한다. 이 명세가 생성기가 만족해야 할 계약이 된다. 트레이드오프는 분명하다. 명세가 너무 느슨하면 비현실적이고 정보량이 없으며, 너무 빡빡하면 커버리지가 좁아지고 (시드 데이터를 쓸 경우) 위협·노출 위험이 커진다.
③ 생성 엔진
두 가지 결합 모달리티를 생성한다.
- 정형 레코드(위험성 분류, 위험성 평가 필드, 실제 값이 아닌 파라미터 범위)
- 텍스트(사건 서술, 관찰 리포트, 완화 조치 노트)
생성은 명세와 공개 골격에 의해 제약되며, 고객의 실제 사건으로 시드하지 않는다. 위협·노출을 원천 차단하기 위해서다. 순수 규칙 템플릿은 너무 경직되어 현장 서술 특유의 지저분한 변이를 못 담고, 순수 자유 생성은 드리프트하며 유효하지 않은 위험성 조합을 만들거나 민감한 구체성으로 흘러간다. 그래서 둘을 결합한 하이브리드를 쓴다.
④ 안전 경계 필터
거버넌스 게이트가 세 가지를 한다.
- (a) 현장 실행가능성 제거: 고의로 해를 끼칠 수 있는 재현가능한 절차·레시피·실제 수치값을 담지 않음.
- (b) 실제 설비/공정이나 알려진 취약점을 닮을 수 있는 민감한 구체성 차단.
- (c) 내부 정합성 검증: 물질 범주에 위험 분류가 맞물리는지, 인과 사슬이 타당한지.
통과하지 못한 항목은 ②의 명세로 되돌아간다. 이 단계가 3장에서 다룰 핵심 경계의 집행 지점이다.
⑤ 검증 게이트
마지막으로 4장의 검증 루프(통계·분포 점검 → 도메인 전문가 검토 → 다운스트림/평가 성능)로 넘긴다. 수용되면 안전 AI 에이전트를 평가할 합성 골든셋이 되고, 거부되면 명세 보정으로 환류한다.
의도적으로 넣지 않은 것도 설계의 일부다. 이 파이프라인은 라이브 고객 데이터 소스에 연결되지 않고, 실제 텔레메트리를 수집하지 않는다. 위험한 진짜를 안 들이는 것이 목표이므로, 들일 경로 자체를 만들지 않았다.
한 가지 덧붙이면, 이 합성 데이터는 두 곳에서 쓰인다.
- 에이전트를 평가하는 골든셋
- 검색 품질을 좌우하는 임베딩·리랭킹 모델을 학습시키는 데이터
학습에 쓰인다는 사실이 3장의 경계를 더 무겁게 만든다. 실행가능한 구체성이 평가셋에 섞이면 채점이 오염되는 데 그치지만, 학습셋에 섞이면 그 능력이 모델 가중치에 새겨질 수 있기 때문이다. 그래서 ‘비실행적’ 경계는 평가보다 학습에서 더 절실하다.
3. 핵심 설계 경계: 진짜처럼 보이되 진짜가 아니게
3.1 현실성과 실행가능성은 두 개의 축
초기에 우리는 양극단에서 실패했다. 한쪽 끝에서는 데이터를 과하게 정제한 나머지 인과 구조가 사라졌고, 그러자 골든셋이 좋은 안전 에이전트와 나쁜 에이전트를 구분하지 못했다. 모두를 “통과”시키는 채점표는 채점표가 아니다.
반대쪽 끝에서는 생성이 진짜로 민감하거나 실행가능한 구체성 쪽으로 드리프트했는데, 이건 두 가지 의미에서 실패다.
- 첫째, 들이지 않으려던 위험한 진짜를 다시 만들어버린 셈이라 목적 자체가 붕괴한다.
- 둘째, 넘어선 안 되는 안전선을 넘는다.
여기서 얻은 핵심 통찰은 이것이다. “현실성”과 “실행가능성”은 하나의 손잡이 양 끝이 아니라, 분리 가능한 두 개의 축이다. 데이터는 구조·인과적으로는 매우 현실적이면서 동시에 현장 실행가능성은 거의 0일 수 있다. 우리 설계의 전부는 이 둘을 분리(decouple)하는 데 있다.
3.2 경계를 테스트로 만들기
중요한 건 이 경계를 감(感)이 아니라 테스트로 만드는 것이다. 두 방향에서 점검한다.
실행가능성 테스트(부재 확인). 도메인·안전 전문가가 묻는다. “악의적 사용자가 이 데이터에서 사용가능한 절차나 실제 파라미터를 추출할 수 있는가?” 그렇다면 거부하고 명세로 환류한다. 해로운 유용성의 부재를 확인하는 음성 테스트다.
현실성 테스트(판별력 확인). 후보 항목을 알려진-좋은 에이전트와 알려진-나쁜 에이전트 모두에게 통과시킨다. 둘의 점수가 같다면 그 항목은 판별력이 없는 것이고, 현실성이 부족하다는 뜻이므로 거부한다.
이 경계는 2.2의 안전 경계 필터와 4장의 전문가 검토에서 집행되지, 사후에 덧붙이는 점검이 아니다.
3.3 추상화 수준
실무에서 추상화 수준은 중요하다. 범주적·인과적 구조(위험 분류, 실패모드→결과 관계)는 보존하고, 절차적·정량적 구체성(정확한 경로, 정확한 파라미터)은 끊는다. 가령 “반응성 비양립이 열폭주와 누출로 이어졌다”는 인과 패턴 범주는 어떤 물질도, 비율도, 조건도 명시하지 않은 채 보존할 수 있다(이건 공정안전 교과서 수준의 공개 개념이다). 트레이드오프는 직접적이다. 추상화가 과하면 현실성 테스트에서 떨어지고, 부족하면 실행가능성 테스트에서 떨어진다. 기술은 필드·시나리오마다 그 추상화 수준을 맞추는 데 있다.
마지막으로, 이 경계는 단순한 기밀 전술이 아니라 윤리적 약속이다. 더 많은 구체성을 넣으면 “더 인상적으로 보일” 수 있음에도 해를 끼칠 수 있는 능력을 의도적으로 만들지 않기로 택하는 것, 즉 “절제”가 곧 엔지니어링 성숙도다. 이 절제는 우리 작업 환경과도 맞물린다. 폐쇄망에서 일하다 보니 문서 관리 시스템(DMS)이나 정보 인가 시스템(IMS)을 거쳐 자료를 반입하는 것조차 쉽지 않다. “내부 정보를 활용한 서비스를 원한다”는 요구와 “학습용 합성 데이터의 레퍼런스로 쓴다”는 목적이 부딪힐 때, 정답은 일반론 수준만 추상화해 드러내고 구체 정보는 서비스 단에서 재구성하여 요구사항을 채우는 것이다.
4. 검증: 합성물을 믿어도 되는가
합성 데이터 생성은 파이프라인 중 절반이다. 나머지 절반은 “이 합성물을 채점 기준으로 써도 되는가”를 묻는 검증 루프다. 합성 후보는 다층 게이트를 통과해야만 수용되고, 떨어지면 사양으로 되돌아간다.
4.1 통계·분포 점검
가장 먼저 수행 가능한 값싸고 자동화 가능한 게이트다. 위험 범주 분포가 의도한 명세와 맞는지, 필드 간 조합이 유효 범위 안인지, 텍스트 길이·어휘 분포가 비정상적으로 쏠리지 않았는지. 표면적 정합성을 통과하지 못하는 후보는 사람을 부르기 전에 걸러낸다.
4.2 도메인 전문가 검토
통계가 잡지 못하는 것은 화학적·인과적 타당성이다. 전문가는 “이 위험 분류가 이 물질 범주에 실제로 맞물리는가”, “이 실패→결과 사슬이 현장에서 말이 되는가”, 그리고 3.2의 실행가능성 부재를 함께 본다. HITL(Human-in-the-Loop)는 이 도메인에서 선택이 아니라 거버넌스 게이트다.
4.3 다운스트림 평가
마지막으로, 표면이 아니라 용도로 검증한다. 합성 데이터가 실제로 다운스트림 태스크(비상대응 훈련 시나리오 생성, 유해화학물질 위험성 분류, 화학사고 리포트 이해)에서 모델을 가르고 채점할 수 있는가? 3.2의 판별력 테스트가 여기서 작동한다. 알려진-좋은/나쁜 동작을 실제로 구분해내야 통과다.
세 게이트의 순서는 의도적이다. 싼 것(통계) → 비싼 것(전문가) → 목적-정합(다운스트림) 순으로, 사람의 시간을 가장 늦게 그리고 가장 값지게 쓴다.
5. 결과·한계·교훈
5.1 결과와 해석
무엇을 얻었나. 위험한 진짜를 보유하지 않고도, 비상대응 훈련 시나리오를 생성하는 안전 AI 에이전트를 평가할 수 있는 반복 가능한 합성 골든셋 파이프라인을 얻었다. 모델/파이프라인의 정량 수치는 이 글의 범위 밖이지만, 숫자 없이도 말할 수 있는 정성적 증거가 있다.
골든셋이 실제로 한 일은 에이전트를 가른 것이다. 표면적으로 그럴듯한 답을 내지만 인과를 못 짚는 에이전트와, 위험 범주와 실패-결과 사슬을 제대로 연결하는 에이전트를 구분해냈다. 즉 3.2의 판별력 테스트를 현장에서 통과했다. 또한 전문가 검토에서 반려된 패턴의 종류도 신호였다. 반려는 대부분 두 범주였다. 인과적으로 말이 안 되는 조합(현실성 부족), 그리고 너무 구체적으로 흘러간 서술(실행가능성 초과). 이 두 반려 유형이 꾸준히 줄어든 것이 파이프라인이 수렴하고 있다는 증거였다.
한계도 분명했다. 잘 경계 지어진 합성 골든셋조차 드문 파국적 사건의 진짜 꼬리를 다 담지는 못한다. 실행가능성으로부터 보호하는 바로 그 경계가, 가장 극단적인 실제 시나리오에 얼마나 가까이 갈 수 있는지도 동시에 제한하기 때문이다. 그래서 골든셋은 전문가 판단과 배포 전 현장의 검증을 대체하지 않고 보완한다. 합성은 현업 검증의 필요를 줄일 뿐, 없애지 않는다.
이번 연구의 결과물은 과제 이행 과정의 검증 흐름에 투입되었고 검색 기능의 개선을 이끌어냈다. 검증에서 확인된 한계는 참조 데이터 구조 개선과 서비스 단 로직 개선으로 나누어 대응했고, 이후 초기 목표보다 넓은 훈련 유형까지 적용 범위를 확장할 수 있었다.
5.2 시행착오와 교훈
앞서 말한 양극단 실패(0단계)는 한 번에 깨달은 건 아니고 순서대로 겪은 상황이었다. 처음엔 생성 자유도를 주어서 민감 구체성으로 목적이 붕괴되었다가, 그걸 해결하기 위해 “안전하게”에 과몰입해 과도 정제로 실효성이 떨어졌었다. 이후에 “현실성과 실행가능성은 별개 축”이라는 결론에 도달했고, 과제 정의 및 목표를 달성하기 위해 현업의 소리를 듣는 것과는 별개로 일반 지식의 영역을 유형·역할·구조 등에 맞게 참조·검색할 필요가 있다고 판단했다.
다시 한다면 두 가지를 먼저 하겠다.
- 첫째, 경계를 코드보다 먼저 테스트로 적겠다. 실행가능성 부재 테스트와 판별력 테스트를 생성기보다 앞서 정의했다면 양극단을 훨씬 일찍 잡았을 것이다.
- 둘째, 전문가 검토를 더 앞단으로 당기겠다. 우리는 전문가를 후반 게이트로 뒀다가 병목을 만들었다. 검토 기준을 명세 단계에서 합의했다면 재작업이 줄었을 것이다.
전문가 병목은 지금도 발생 가능한 이 접근의 실질적 한계다. 전문가 검토에 전용 UI가 필요하거나 문서 기반 소통을 고수해야 하는 상황이면, 검토 기준을 설계 단계에서 합의하기 쉽지 않기 때문이다. 그럴 때는 산업 분야, 과제 유형·범위, 작업 흐름의 명확성과 난이도, 평가 기준의 공개 여부에 따라, AITL(AI-in-the-Loop)을 적용할지 판단할 것이다.
5.3 일반화된 패턴
이 사례는 제조화학 산업에 관한 것이지만, 시사하는 점은 화학 도메인에 갇히지 않는다. 기밀이면서 안전에 민감한 어떤 도메인이든 의료, 금융 사기, 보안 사건, 중요 인프라 같은 산업은 더욱 삼중 제약(기밀·희소·위험)에 부딪힌다. 그런 도메인에서 합성 데이터는 생성의 문제가 아니라 거버넌스·설계의 문제다.
재사용 가능한 원칙은 넷이다.
- ⑴ 공개 분류체계에 접지하라. 골격을 공개 표준에서 가져오면 구조적 충실도와 비복제를 동시에 얻는다.
- ⑵ “현실적이되 비실행적”을 명시적·검증 가능한 경계로 만들라. 현실성과 실행가능성을 별개 축으로 분리하고 양방향 테스트로 운용하라.
- ⑶ 표면 현실성이 아니라 다운스트림 용도로 검증하라. 채점표는 좋은 것과 나쁜 것을 갈라야 채점표다.
- ⑷ 도메인 전문가를 루프에 유지하라. 통계가 못 잡는 인과·안전 타당성은 사람이 본다.
5.4 실무 체크리스트
기밀·안전 도메인의 합성 데이터를 설계할 때, 시작 전에 답해두면 좋은 항목들:
- □목표를 재정의했는가. “더 모으기”가 아니라 “위험한 진짜를 안 들기”로?
- □골격이 공개 표준에 접지되는가. 독점 콘텐츠를 복제하지 않는가?
- □실제 데이터로 시드하는가. 한다면 위협·노출 위험을 어떻게 막는가?
- □경계를 테스트로 적었는가. 실행가능성 부재 테스트와 판별력 테스트를 코드보다 먼저?
- □검증이 용도 기반인가. 표면 정합성을 넘어 다운스트림에서 판별력을 보는가?
- □전문가가 후반 병목이 아니라 앞단 게이트인가?
- □한계를 명시했는가. 합성이 대체하지 못하는 현업 검증의 자리를 남겨뒀는가?
- □“더 구체적이면 더 인상적”의 유혹을 거절했는가. 절제가 설계에 박혀 있는가?
이 도메인에서 가장 어려운 엔지니어링 결정은 무엇을 만들까가 아니라, 무엇을 의도적으로 만들지 않을까였다. 현실적이되 악용할 수 없는 데이터는, 기술이 아니라 그 절제의 산물이다.
- 이전글expand_less
- 다음글expand_more
