AI 도입을 결정할 때 진짜 질문은 "이 AI가 답을 잘 만드는가"가 아니라, "그 답을 어떻게 검증하고, 개인정보를 어떻게 빼고, 운영 중 무엇이 잘못됐는지 어떻게 추적하는가"입니다. 공공기관 AI에서는 생성보다 검증이 핵심입니다. 이 안내서는 그 도구들을 목적별로 묶은 지도이며, 각 도구를 이 사이트의 기존 가이드와 연결합니다.
- AI 업무 흐름에서 입력 전·배포 전·운영 중 통제 지점을 구분할 수 있습니다.
- 비식별·회귀 평가·추적·라벨 검수 도구의 역할을 비교할 수 있습니다.
- 도구 이름보다 실패 가능성과 남겨야 할 증거를 기준으로 선택할 수 있습니다.
- 자동 검사 결과와 사람 승인 사이의 경계를 설계할 수 있습니다.
왜 생성보다 검증인가
식당에 요리사를 뽑는 상황을 떠올려 보세요. 맛있게 만드는 솜씨(생성)는 물론 중요합니다. 하지만 그 식당이 급식소라면, 채용 기준이 달라집니다 — 위생 점검을 통과하는가(비식별), 어제와 오늘 같은 맛을 재현하는가(회귀 테스트), 문제가 생겼을 때 어느 조리 단계였는지 되짚을 수 있는가(추적). 손맛이 좋아도 이 셋이 없으면 급식소에는 들일 수 없습니다.
소방 업무 AI가 바로 급식소 쪽입니다. 틀린 답 하나가 민원인에게 나가거나 내부 판단을 흐릴 수 있어, "가끔 놀랍게 잘하는" 것보다 "언제나 검증 가능한" 편이 낫습니다. 그래서 도구를 고르는 축은 AI의 수명 주기 세 길목에 걸립니다.
- 입력 전 — 개인정보를 빼고 넣는가 (비식별)
- 배포 전 — 프롬프트를 고친 뒤에도 답이 흔들리지 않는가 (회귀 테스트)
- 운영 중 — 무엇이 오갔고 어디서 틀렸는지 남는가 (추적·관측)
아래 도구들은 전부 이 세 길목 중 하나에 놓입니다. 이름을 외우기보다, 지금 우리 업무의 어느 길목이 비어 있는지를 먼저 보세요.
동작 원리
운영 도구는 AI 앞뒤에 검사 지점과 증거 기록을 추가합니다. 입력 전 비식별은 원문을 탐지 결과와 마스킹 결과로 나누고, 남은 민감정보를 사람이 확인할 목록을 만듭니다. 배포 전 회귀 평가는 고정 질문과 기대 조건을 새 프롬프트·모델 결과에 반복 적용해 이전 합격 조건이 깨졌는지 비교합니다. 운영 중 추적은 입력, 사용한 버전, 검색 결과, 출력, 피드백을 같은 실행 흐름으로 연결합니다.
이 세 지점은 서로 대신할 수 없습니다. 추적 로그가 잘 남아도 민감정보가 입력되면 이미 늦고, 회귀 평가가 통과해도 운영 중 처음 만난 입력에서 실패할 수 있습니다. 반대로 비식별만 해서는 답의 근거 누락이나 버전 변경 영향을 알 수 없습니다. 그래서 각 도구의 출력이 다음 관문으로 넘어갈 조건과, 실패했을 때 멈추거나 사람에게 올릴 경로가 함께 있어야 합니다.
도구가 내놓는 점수나 통과 표시는 증거의 일부입니다. 어떤 입력·규칙·버전으로 얻었는지가 없으면 재현할 수 없습니다. 사람은 자동 결과를 승인 근거 중 하나로 보고, 실제 업무 기준·공개 범위·오류 영향에 따라 최종 사용 여부를 결정합니다.
선택지와 트레이드오프
도구군을 많이 도입하는 것보다 비어 있는 통제 지점 하나를 정확히 채우는 편이 낫습니다.
| 선택지 | 먼저 필요한 상황 | 얻는 증거 | 남는 부담 |
|---|---|---|---|
| 입력 비식별 검사 | 원문에 이름·주소·연락처 등 민감정보가 섞일 수 있을 때 | 탐지·마스킹·사람 확인 목록 | 문맥형 정보와 미탐을 계속 검토해야 함 |
| 배포 전 회귀 평가 | 프롬프트·검색·모델 변경이 반복될 때 | 고정 질문별 이전·현재 결과와 조건 통과 여부 | 대표 질문과 합격 기준을 사람이 유지해야 함 |
| 운영 추적·관측 | 실패를 재현하고 버전별 원인을 찾아야 할 때 | 실행 흐름·입출력·검색·피드백 연결 기록 | 로그 자체의 개인정보·권한·보존 범위를 관리해야 함 |
| 라벨 검수·탐색 | 학습 데이터의 누락·중복·기준 흔들림이 의심될 때 | 의심 샘플과 검수 이력 | 최종 라벨 판단과 기준 합의는 사람이 해야 함 |
가상 상황: 규정 챗봇이 조용히 틀리기 시작할 때
가상의 상황을 하나 들어 보겠습니다. 어느 소방서가 내부 규정을 답해 주는 챗봇을 만들었습니다. 처음엔 잘 도는 듯했습니다. 그런데 두 가지 일이 벌어집니다.
프롬프트를 한 줄 고쳐 답변 말투를 다듬었더니, 전에는 잘 나오던 "소화기 점검 주기" 답이 근거 규정을 빼먹기 시작합니다. 눈으로는 눈치채기 어렵습니다 — 다른 질문은 멀쩡하니까요. 이것이 회귀입니다. 한쪽을 고치다 다른 쪽이 조용히 깨지는 것이죠. 며칠 뒤 민원인이 "이상한 답을 받았다"고 알려 오지만, 무엇을 물었고 어떤 답이 나갔는지 로그가 없어 재현조차 못 합니다. 이것이 추적의 부재입니다.
이 두 통증이 아래 표의 "회귀 테스트"와 "추적·관측" 도구가 존재하는 이유입니다. 도구가 화려해서가 아니라, 이 통증을 겪어 봤기 때문에 그 자리에 놓는 것입니다.
가상 사례: 영상 데이터 담당자의 라벨 기준 변경
다음은 규정 챗봇과 다른 가상 사례입니다. 영상 데이터 담당자가 화염 상자의 경계를 더 일관되게 그리도록 라벨 기준을 고친 뒤, 기존 모델과 새 데이터의 차이를 확인하려 합니다. 입력은 승인된 합성·교육용 영상 샘플, 이전 라벨 버전, 새 기준으로 검수한 후보입니다. 실제 CCTV 원문은 이 교육 사례에 사용하지 않습니다.
담당자는 라벨링 도구만 도입하고 끝내지 않습니다. 변경된 샘플 목록과 기준 버전을 남기고, 학습 전에 의심 라벨을 다시 검수합니다. 같은 고정 평가 샘플에서 이전 모델과 새 모델의 미탐·오탐 목록을 비교하고, 결과가 달라진 장면을 사람이 확인합니다. 운영에 넘길 때는 어떤 라벨 버전과 평가 결과를 썼는지 추적 기록에 연결합니다.
실패 가능성은 새 기준으로 고친 데이터만 보고 성능이 좋아졌다고 판단하는 것입니다. 학습에 가까운 샘플에서는 변화가 좋아 보일 수 있습니다. 담당자는 분리된 평가 샘플과 실제 오류 목록을 확인하고, 기준 변경 이유와 남은 오류를 검토자가 승인한 뒤에만 다음 단계 후보로 보냅니다.
개인정보 비식별 — AI에 넣기 전
| 도구 | 무엇인지 | 소방 활용 |
|---|---|---|
| Presidio | 텍스트 속 개인정보를 탐지·마스킹하는 라이브러리 | 신고자 이름·전화·주소·차량번호를 LLM에 넣기 전 비식별화 |
→ 개인정보, AI에 넣기 전에 점검하기 가이드가 패턴·문맥·사람 3단 점검을 설명한다면, Presidio는 그중 정규식 단계를 더 넓은 패턴으로 자동화하는 도구입니다. 다만 Presidio도 만능이 아닙니다 — 한국어 이름·상세 주소·의료 정보는 놓칠 수 있으니, 자동 비식별 뒤에도 사람의 최종 확인을 생략하지 마세요.
문서를 AI 입력으로 바꾸기
| 도구 | 무엇인지 | 소방 활용 |
|---|---|---|
| MarkItDown | PDF·DOCX·PPTX 등을 Markdown으로 변환 | 법령·매뉴얼·지침 문서를 RAG·요약 입력 형태로 정리 |
| Unstructured | 표·혼합 포맷이 섞인 복잡한 문서를 구조화 파싱 | 스캔된 매뉴얼, 표 포함 보고서, 혼합 자료 정리 |
→ 소방 공공데이터·API 지도와 법령 근거 확인 브리프에서 모은 문서를 RAG 입력으로 바꿀 때 씁니다.
답변 품질을 회귀 테스트
| 도구 | 무엇인지 | 소방 활용 |
|---|---|---|
| promptfoo | 프롬프트·RAG·에이전트를 테스트·레드팀하는 CLI | 보고서·민원·SOP 답변의 환각·금칙어·권한 우회 회귀 테스트 |
| DeepEval | LLM을 pytest처럼 테스트하는 평가 프레임워크 | "근거 있는 답변인지"를 테스트 세트로 반복 검증 |
| Ragas | RAG 답변의 충실도·맥락 정밀도를 평가 | 법령·SOP 검색 답변의 faithfulness·context precision 점검 |
| Guardrails | LLM 입출력에 검증 가드·구조화 출력을 적용 | 법령 브리프·민원 답변의 필수 필드·금칙 조건 검증 |
"회귀 테스트"가 막연하다면, 이렇게 생각하면 쉽습니다. 사람이 매번 눈으로 확인하던 합격 기준을 표로 적어 두고, 프롬프트를 고칠 때마다 기계가 대신 채점하게 하는 것입니다. 앞의 규정 챗봇이라면 이런 표가 됩니다(가상 예시).
| 고정 질문 | 반드시 포함 | 절대 포함 안 됨 |
|---|---|---|
| 소화기 점검은 누가 하나요? | 근거 규정 인용, 불확실 시 [확인 필요] 표기 | 지어낸 조문 번호 |
| 우리 아파트 방화문 기준은? | "규정 원문 확인 안내" 문구 | 특정 단정("무조건 …입니다") |
위 도구들은 이 표를 실행 가능한 테스트로 바꿔, 프롬프트를 손볼 때마다 자동으로 돌립니다. 통과 기준을 사람이 정하고, 반복 채점을 기계가 맡는 구조입니다.
→ AI 결과, 제출 전 1분 점검의 pass·needs·block을, 프롬프트를 고칠 때마다 자동 회귀로 돌리는 단계입니다. RAG 답변을 골든셋 회귀로 굳히는 운영 방법은 RAG 운영, 골든셋 회귀 평가와 가드레일에서 이어집니다.
운영 중 추적·관측
| 도구 | 무엇인지 | 소방 활용 |
|---|---|---|
| Opik | LLM 호출·RAG·에이전트 실행을 추적·평가·모니터링 | 내부 챗봇 답변 로그, 검색 결과, 실행 흐름 점검 |
| Phoenix | AI 관측성·평가 도구 | 답변 품질·관련성·검색 실패를 추적하는 실습 |
| Langfuse | LLM 호출·프롬프트·피드백을 추적·관리하는 관측 플랫폼 | 공공 챗봇 응답 품질·프롬프트 버전·사용자 피드백 추적 |
추적이 남기는 것은 결국 "재현할 수 있는 기록"입니다 — 어떤 질문에, 어떤 프롬프트 버전으로, 무엇을 검색해, 어떤 답이 나갔는지. 앞 상황의 민원 재현 실패는 이 기록이 없어서 생긴 일입니다. 실데이터·내부망에 붙일 때는 이 로그에도 개인정보가 섞이므로, 추적 로그 역시 비식별과 접근 권한 설계 대상입니다. 예측 모델의 품질이 시간이 지나며 미끄러지는 것을 잡는 이야기는 예측 모델 운영, 드리프트 감지와 재학습 시점으로 이어집니다.
영상·텍스트 데이터 라벨링 — CV 학습 전
| 도구 | 무엇인지 | 소방 활용 |
|---|---|---|
| Label Studio | 텍스트·이미지·영상 라벨링 플랫폼 | 화재·연기 영상, 신고 텍스트, 위험물 표지 데이터셋 구축 |
| CVAT | 컴퓨터비전 어노테이션 도구 | CCTV·드론 영상 객체 탐지 학습용 바운딩박스 작업 |
| FiftyOne | 비전 데이터셋 검수·탐색 | 탐지 실패 사례·중복 이미지·라벨 품질 확인 |
→ 화재 영상에서 화염·연기 탐지하기의 학습 데이터 품질을 올리는 앞단계입니다. 라벨 자체가 흔들리면 모델도 흔들리므로, 라벨 품질을 학습 전에 재는 방법은 훈련 데이터 라벨 품질, 학습 전에 잡기에서 다룹니다.
어디서부터 — 작은 팀의 도입 순서
가장 흔한 실수는 도구를 먼저 고르고 문제를 끼워 맞추는 것입니다. 순서는 반대여야 합니다 — 우리 업무의 위험부터 짚고, 그 자리에 도구를 놓습니다. 작은 팀이라면 대체로 이 순서가 안전합니다.
- 비식별이 먼저. 실데이터를 AI에 붙이기 전, 개인정보부터 뺍니다. 이름·주소까지 파이프라인으로 굳히는 법은 개인정보 비식별 파이프라인, 이름·주소까지 자동으로.
- 다음이 회귀. 프롬프트를 고칠 때마다 이전 합격 답이 깨지지 않는지 자동으로 봅니다. 위의 회귀 테스트 도구가 여기 놓입니다.
- 그다음이 추적. 운영에 올린 뒤에는 무엇이 오갔는지 로그로 남깁니다.
세 길목을 한꺼번에 갖추려 하기보다, 지금 가장 위험한 하나부터 채우는 편이 현실적입니다. 자체 호스팅 도구는 편리하지만 인증·업데이트를 방치하면 그 자체가 구멍이 되고, 망 안에서 모델을 직접 돌리는 선택은 온프레미스 LLM, 망분리 환경에서 안전하게 운영하기에서 이어집니다. 여기 실린 도구들의 저장소는 레포 레이더에서, 에이전트·LLM 운영의 기초는 에이전트 AI 코스에서 더 볼 수 있습니다.
문제 해결
| 증상 | 가능한 원인 | 처방 | 확인 |
|---|---|---|---|
| 검사 도구는 통과했는데 민감정보가 남음 | 규칙이 문맥형 이름·주소를 잡지 못함 | 미탐 사례를 비식별된 형태로 분류하고 사람 검토 관문 강화 | 자동 결과와 별개로 승인 샘플을 사람이 다시 확인 |
| 프롬프트 수정 뒤 일부 질문만 근거가 사라짐 | 회귀 질문이나 필수 조건이 부족함 | 실패 질문을 골든셋에 추가하고 근거 필드를 명시 | 변경 전후 같은 질문의 출력과 조건 결과 비교 |
| 이상 답변을 재현할 수 없음 | 입력·프롬프트·검색 결과·버전 연결 기록이 없음 | 최소 추적 필드를 정하고 한 실행 ID로 묶음 | 해당 기록만으로 같은 흐름을 설명할 수 있는지 확인 |
| 도구가 많지만 누가 실패를 처리할지 모름 | 경고 이후 중단·검토·승인 경로가 없음 | 각 관문에 책임 역할과 실패 시 다음 상태를 정의 | 모의 실패 한 건이 사람 확인까지 전달되는지 점검 |
자주 묻는 질문
Q. 비식별 도구를 쓰면 원문을 외부 AI에 보내도 되나요?
자동 도구가 모든 문맥형 정보를 잡는다는 보장은 없습니다. 소속 기관 기준, 처리 목적, 사람 확인과 승인된 환경을 함께 검토해야 하며 도구 통과만으로 전송을 결정하지 않습니다.
Q. 회귀 테스트 점수가 좋아지면 배포해도 되나요?
점수는 정한 질문과 기준 안의 변화만 보여 줍니다. 중요한 실패가 질문에 빠졌는지, 실제 업무 영향과 사람 검토 경로가 준비됐는지 별도로 확인합니다.
Q. 추적 로그는 자세할수록 좋은가요?
재현에 필요한 기록은 중요하지만 원문·민감정보를 과도하게 남기면 새 위험이 됩니다. 목적에 필요한 최소 필드, 접근 권한, 보존 범위를 함께 정합니다.
Q. 여러 도구를 한꺼번에 도입해야 하나요?
먼저 가장 큰 실패 지점과 현재 없는 증거를 정합니다. 작은 합성 사례에서 한 관문을 검증한 뒤 다음 관문으로 넓히는 편이 책임과 효과를 확인하기 쉽습니다.
핵심 정리
- 입력 전 비식별, 배포 전 회귀, 운영 중 추적은 서로 다른 실패를 막는 관문입니다.
- 도구 선택은 제품 이름보다 실패 영향·필요 증거·사람 처리 경로에서 시작합니다.
- 자동 점수와 통과 표시는 입력·규칙·버전과 함께 남아야 재현할 수 있습니다.
- 로그와 평가 데이터도 개인정보·권한·보존 범위의 검토 대상입니다.
다음 단계
- 개인정보 비식별 파이프라인, 이름·주소까지 자동으로 — 입력 전 비식별을 탐지·가명화·재현율 검증 흐름으로 구체화합니다.
- RAG 운영, 골든셋 회귀 평가와 가드레일 — 배포 전 고정 질문과 운영 가드레일을 실제 평가 루틴으로 확장합니다.
- 예측 모델 운영, 드리프트 감지와 재학습 시점 — 운영 중 입력 변화와 품질 저하를 관측·재학습 결정으로 연결합니다.