조사위원회의 조력자, 인공지능: 클라우드 에이전트에서 오프라인 사고 조사까지

첫 클라우드 실험에서 출발해 “마스킹 도구 → 인공지능 에이전트 → 마스킹 해제”라는 실무 체계를 갖추고, 이어 테스트용 오프라인 조사 시스템을 만들어 다음 단계인 보안 사내 인공지능 환경 Fire를 준비하기까지 우리가 걸어온 길.

핵심 아이디어: 인공지능은 “과실 책임자를 지목”해서는 안 되며, 조사위원회를 대신하지도 않는다. 인공지능의 진짜 쓸모는 위원회가 흩어진 자료를 하나의 그림으로 더 빨리 엮고, 빈틈을 찾고, 인과 논리를 점검하고, 조사의 첫 실무 초안을 준비하도록 돕는 데 있다.

모든 것의 시작

사고 조사에 인공지능을 활용하려는 첫 시도는 이미 2023년에 시작되었다. 당시 아이디어 자체는 꽤 단순해 보였다. 자체 에이전트를 만들어 조사 방법론과 해당 사고의 자료를 올린 다음, 타임라인을 구성하고, 경위서 사이의 모순을 찾고, 원인과 조치를 제안해 달라고 요청하는 것이었다.

2024년에는 모델의 역량이 눈에 띄게 넓어졌다. 텍스트뿐 아니라 이미지도 능숙하게 다루기 시작한 것이다. 초기 실험 가운데 하나는 사실 제대로 된 조사라고 할 수도 없었다. 원격지 사업장에서 한 여성 근로자가 넘어져 발을 다쳤다. 현장에서 엑스레이 촬영은 했지만, 곧바로 판독해 줄 전문의가 없었다. 영상을 인공지능에 올리자, 모델은 제5중족골 골절로 보이는 부위를 짚어 냈다.

분명히 강조해 둔다. 이것은 의학적 소견이 아니었고, 그래서도 안 된다. 의료 영상의 최종 판단은 의사의 몫이다. 하지만 그 일은 우리에게 중요한 기술적 신호가 되었다. 모델이 비전문가라면 놓칠 수 있는 이미지 속 세부 사항을 알아챌 수 있다는 것이다. 그렇다면 조사에서도 텍스트뿐 아니라 도식, 사진 같은 다른 자료까지 다룰 잠재력이 있다는 뜻이었다.

첫 실무 버전: 클라우드 에이전트

더 안정적인 사용자 맞춤형 에이전트가 등장하자, 우리는 이를 사내 방법론에 맞춰 직접 설정하기 시작했다. GPT, Gemini, Perplexity로 여러 버전을 만들었고, 초기에는 Grok도 시험해 봤다. 에이전트에는 먼저 방법론을 올리고, 이어 경위서, 최초 상황 기술서, 개별 문서와 기타 자료를 넣었다.

실질적인 효과는 곧바로 나타났다. 인공지능은 진술을 빠르게 대조하고, 사건의 순서를 제안하고, 시각과 표현의 불일치를 찾아내고, 추가 질문 목록을 만들었다. 위원회에게는 수십 쪽을 지치지 않고 거듭 읽어 주는 “두 번째 분석가”로서 쓸모가 있었다.

그러나 첫 버전에는 뚜렷한 결함이 있었다. 사실상 실제 조사 자료를 외부 서비스에 넘기고 있었던 것이다. 사고 조사에서는 이 점이 특히 민감하다. 자료에는 성명, 직위, 의료 정보, 경위서, 사진, 기업 내부 정보가 담길 수 있기 때문이다.

도구를 쓰면 쓸수록 분명해졌다. 편리함이 불필요한 데이터를 외부로 넘기는 핑계가 될 수는 없다.

부록의 프롬프트 참조: Prompt 1 — 사전에 비식별화한 자료만 다루는 안전한 클라우드 에이전트 버전.

방법론이 엄격해지자 인공지능에 대한 요구도 달라졌다

그와 나란히 사내 조사 방법론 자체도 발전했다. 내게는 이것이 중요한 지점이다. 인공지능에게 “조사 방법을 스스로 정할” 권한을 주어서는 안 된다. 먼저 방법론이 있어야 하고, 디지털 도구는 그 방법론에 맞춰 만들어진다.

현행 방법론에서 위원회의 주된 목표는 과실 책임자를 찾는 것이 아니라, 유사한 사건의 재발을 막거나 그 가능성을 낮출 가장 효과적인 대책을 마련하는 것이다. 사건의 연쇄에 사람의 행동이 끼어 있다면 한 걸음 더 들어가, 왜 그런 행동이 가능했는지 또는 허용되었는지를 규명해야 한다.

조사는 방호 방벽의 논리에 따라 진행된다. 위험원 → 원치 않는 사건 → 결과라는 흐름을 세우고, 예방 방벽과 완화 방벽을 따로 검토한다. 정보 분석 단계에서는 타임라인을 작성하고 결정적 요인을 가려낸다. 이어서 원인 트리를 구성하는데, 이 트리는 직접 원인과 중간 원인에서 출발해 시스템적 근본 원인에 이르러야 한다.

비교적 단순한 사안에서는 “왜?”를 묻는 질문의 사슬이 짧을 수 있다. 복잡한 사건에서는 가지를 치며 온전한 원인 트리로 자라난다. “보타이”의 방벽 논리는 사건이 애초에 왜 일어났는지, 그리고 결과가 왜 하필 그렇게 나타났는지를 따로 점검하도록 돕는다.

바로 이 순서가 훗날 우리 로컬 애플리케이션의 뼈대가 되었다.

Prompt 2–6 참조: 타임라인과 결정적 요인 → 질문과 모순 → 방벽 → 원인 트리 → 조치.

두 번째 버전: 수작업 마스킹

다음 단계는 훨씬 안전했지만 꽤 번거로웠다. 클라우드 에이전트에 자료를 올리기 전에 성씨와 기타 민감한 값을 손으로 바꿔 넣었다. “근로자 1”, “근로자 2”, “관리자 1”, “부서 1” 하는 식이다.

기밀성 측면에서는 이미 한 걸음 나아간 셈이었다. 에이전트는 사고의 논리는 보았지만 실제 성명은 보지 못했다. 분석이 끝나면 이 표기를 손으로 다시 원래대로 되돌려야 했는데, 대개는 Ctrl+F 검색에 기댔다.

관계자가 두세 명일 때는 그럭저럭 견딜 만하다. 그러나 조사에 경위서, 목격자, 문서, 반복되는 성씨가 많아지면 수작업 마스킹과 원상 복원 자체가 별도의 업무가 되고, 오류 위험까지 생긴다.

세 번째 버전: 로컬 마스킹 도구, 그리고 오디오라는 별개의 문제

바이브 코딩 역량을 갖추게 되자, 우리는 이 수작업을 로컬 마스킹 도구로 대체했다. 이 도구는 시리즈 첫 번째 글에서 소개한 바 있다. Word 문서를 컴퓨터에서 처리해 가명 표기를 입히고, 마스킹 해제 키는 따로 저장한다. 키는 비밀번호로 보호되며 에이전트에게 넘어가지 않는다.

이렇게 하면 클라우드 인공지능에는 마스킹된 경위서와 기타 자료만 보낼 수 있다. 받은 결과는 다시 컴퓨터로 가져와 로컬에서 복원한다. 오늘날 우리가 실무에 쓰는 체계가 바로 이것이다. 로컬 마스킹 도구 → 설정된 조사 에이전트 → 로컬 마스킹 해제. 이 방식으로 원래 성명과 복원 키를 넘기지 않고도 클라우드 모델의 강점을 활용할 수 있다.

하지만 취약한 부분이 하나 더 남아 있었다. 바로 녹음 파일이다. 경위 진술과 면담은 음성으로 녹음하는 편이 편리하지만, 분석하려면 먼저 텍스트로 바꿔야 한다. 예전에는 이를 위해 별도의 온라인 서비스와 모바일 앱을 썼다. 나중에는 대형 인공지능 서비스 안에 전사 기능이 직접 들어왔다. 편리하긴 하지만, 사람의 목소리가 담긴 원본 녹음은 여전히 외부로 나간다.

그래서 우리는 도구를 하나 더 만들었다. 로컬 음성 전사 도구다. 이 도구는 Whisper를 컴퓨터에서 직접 구동한다. 우리 시험에서 전사 품질은 익숙한 클라우드 서비스와 충분히 견줄 만했고, 원본 녹음은 컴퓨터 밖으로 나가지 않는다. 로컬에서 전사한 텍스트는 마스킹을 거친 뒤, 필요하면 실무용 조사 에이전트에 넘길 수 있다.

이 단계의 연결 고리: 로컬 음성 전사 → 로컬 마스킹 도구 → 클라우드 에이전트. 자료 분석은 Prompt 1–6 참조.

네 번째 버전: 오프라인 시스템은 이미 만들었고, 이제 시험 중이다

여기서 또 다른 질문이 생겼다. 전사, 문서 판독, 모델이 이미 로컬에서 돌아간다면, 이 모두를 하나의 보안 환경에 모으면 어떨까? 그렇게 실험적인 오프라인 조사 시스템이 탄생했다. 시스템은 이미 개발되어 작동하지만, 지금은 의도적으로 테스트 단계로 보고 있다. 교육용 사례와 비식별 사례로 검증하고, 결과를 위원회의 작업과 비교하며, 프로세스를 더 빠르고 편리하고 안정적으로 만들어 줄 다음 반복 개선을 찾고 있다.

과제는 이랬다. 방법론 지침서, 최초 정보, 경위서, Word와 PDF 문서, 녹음 파일, 사진과 도식을 올릴 수 있는 위원회의 통합 작업 공간을 만든다. 음성과 문서를 로컬에서 판독한다. 방법론의 단계를 차례로 밟아 편집 가능한 Word 보고서 초안을 얻는다.

한 문장으로 말하니 간단해 보일 뿐이다. 실제로는 수없이 많은 반복이 필요했다. 로컬 음성 인식부터가 단번에 작동하지 않았고, 이어 PDF 스캔본, 이미지, 대용량 자료, 로컬 모델, 타임라인, 원인, 최종 문서 문제를 하나하나 풀어야 했다. 개발 방식은 우리의 다른 프로젝트와 같았다. 변경 한 가지 → 실행 → 결과 또는 오류 스크린샷 → ChatGPT와 함께 다음 반복.

그 결과 브라우저 인터페이스와 자체 로컬 인공지능 환경을 갖춘 로컬 시스템이 나왔다. 이미 녹음을 잘 전사하고, 준비된 자료를 읽고, 구조화된 조사 초안을 만들어 낸다. 지금 우리의 과제는 이를 “완성된 제품”으로 선언하는 것이 아니라, 차분히 시험하고 결과를 비교하며 작업 논리를 개선하는 것이다. 본격적인 로컬 모델을 돌리고 대량의 자료를 빠르게 처리하려면 성능이 넉넉한 컴퓨터가 있는 편이 좋다.

Prompt 8 참조 — 위원회의 로컬 작업 공간을 바이브 코딩으로 만들기 위한 마스터 프롬프트.

테스트용 오프라인 버전이 이미 할 수 있는 일

테스트용 오프라인 버전에서는 전체 주기가 평범한 인공지능 채팅이 아니라 방법론을 중심으로 짜여 있다.

먼저 위원회가 최초 정보를 기록한다. 무슨 일이 있었는지, 위험원, 원치 않는 사건, 결과, 관련자, 현장 확인 결과. 이어서 계획을 세운다. 어떤 질문을 해소해야 하는지, 누구를 면담할지, 어떤 문서와 감정 결과를 확보할지.

자료 섹션에는 DOCX와 텍스트 기반 PDF를 올릴 수 있다. 스캔본과 사진은 로컬에서 문자 인식을 할 수 있고, 도식과 이미지는 사건 파일에 보관되며, 모델이 눈에 보이는 세부 사항에 대한 설명을 제안할 수 있다. 오디오와 비디오는 로컬에서 전사된다. 마이크로 면담을 직접 녹음한 뒤 녹취록을 받을 수도 있다.

자료 검토가 끝나면 애플리케이션이 타임라인 작성을 돕는다. 인공지능은 사건과 인용문을 제안하지만, 항목을 넣을지는 위원회가 결정한다. 결정적 요인은 따로 표시한다.

다음 블록은 방호 방벽과 원인이다. 위원회는 예방 방벽과 완화 방벽을 점검하고, 출발점이 되는 두 가지를 세운다. 원치 않는 사건은 왜 일어났는가, 그리고 왜 그러한 결과가 초래되었는가. 인공지능이 제안한 원인은 위원회가 확인하기 전까지 가설로 남는다.

원인이 정리되면 조치를 수립한다. 조치가 어떤 원인에 대응하는지, 담당자는 누구인지, 기한은 언제인지, 어떤 결과로 검증할 수 있는지, 임시 방벽이 필요한지, 해당 조치를 한 구역을 넘어 더 넓게 적용해야 하는지.

그런 다음에야 보고서 초안이 만들어진다. 애플리케이션은 방법론 지침서의 구조에 따라 Word 첫 초안을 엮어 내고, 타임라인, 원인 트리, 방벽, 자료 대장과 부록을 담을 수 있다.

참조: Prompt 2 — 타임라인; Prompt 3 — 모순과 누락 데이터; Prompt 4 — 방벽; Prompt 5 — 원인 트리; Prompt 6 — 조치; Prompt 7 — 최종 보고서 초안.

로컬 인공지능이 하는 일, 그리고 해서는 안 되는 일

여기서 자동화를 과대평가하지 않는 것이 중요하다. 인공지능은 검증된 텍스트를 조각 단위로 읽고, 타임라인, 질문, 방벽, 원인 가설, 조치안을 제안한다. 두 경위서 사이의 모순을 찾아내거나, 타임라인에서 중요한 시간대가 빠졌다는 것을 알아챌 수도 있다.

하지만 문서에서 뽑은 인용문은 그런 말이 자료에 실제로 적혀 있다는 사실만 확인해 줄 뿐이다. 진술이 참이라는 것을 증명하지는 않는다. 인식된 텍스트에는 오류가 섞일 수 있다. 도식은 잘못 해석될 수 있다. 인과관계는 가설에 그칠 수도 있다.

그래서 애플리케이션에는 하나의 원칙이 녹아 있다. 인공지능은 제안하고, 위원회는 채택하거나 기각하거나 수정한다. 원인은 자동으로 확정되지 않는다. 담당자와 기한은 모델이 지정하지 않는다. Word 초안은 말 그대로 첫 실무 초안일 뿐, “받아서 서명만 하면 되는” 문서가 아니다.

이 점이 특히 중요한 이유는 내부 보고서가 법령과 정해진 절차에 따라 작성해야 하는 문서를 대신하지 않기 때문이다. 조사에 대한 책임은 여전히 위원회에 있다.

Prompt 9 참조 — 결과를 사용하기 전 품질, 기밀성, 자동화의 한계 점검.

기밀성은 별도의 지침이 아니라 아키텍처의 일부가 되었다

조사에서 기밀성 문제는 “나중으로” 미룰 수 없다. 방법론 자체가 내부 조사 자료를 대외비 문서로 분류하고, 파일을 만들고 전달할 때 개인정보를 보호하도록 따로 요구한다.

테스트용 오프라인 버전에서는 사건 자료, 전사본, 분석 결과, Word 문서가 모두 컴퓨터에 남는다. 로컬 모델은 루프백 주소를 통해 동작하며, 필요한 모델을 준비해 두면 이후 사건 작업 세션은 외부 인터넷에 접속하지 않고도 진행할 수 있다.

하지만 여기에도 마법은 없다. 로컬에서 작업한다고 해서 자동으로 비식별화되는 것은 아니다. 성명과 의료 정보를 사건 파일에 올리면, 그 정보는 해당 컴퓨터와 사건 첨부 자료에 그대로 남는다. 따라서 일반적인 정보보안 조치가 필요하다. 보호된 사용자 계정, 접근 권한, 보관 규칙, 백업, 그리고 필요하면 추가 마스킹.

즉, 우리의 진화는 “모두 오프라인이니 모두 안전하다”는 구호로 끝나지 않았다. 더 정확히 말하면 이렇다. 자료를 외부로 불필요하게 보내는 일을 없애고, 데이터에 대한 통제권을 있어야 할 곳, 곧 기업 내부에 두었다.

지금 무엇을 쓰고 있는가

현재 우리에게는 사실상 두 개의 체계가 있다. 첫째는 실무 체계다. 자료를 로컬에서 마스킹하고, 비식별 사본을 설정된 조사 에이전트에 넘긴 뒤, 받은 결과를 로컬에서 마스킹 해제한다. 실제 업무에 이미 쓸 수 있는 것은 바로 이 방식이다.

둘째는 테스트 체계다. 완전한 오프라인 시스템으로, 스스로 로컬에서 오디오를 전사하고, 자료를 읽고, 타임라인과 방벽과 원인을 구성하도록 돕고, 첫 보고서 초안을 만든다. 이미 작동하지만 우리는 계속 검증하고 개선하는 중이다. 우리에게 이것은 원칙의 문제다. 보기 좋다는 이유만으로 파일럿을 성숙한 실운영 시스템인 양 내세워서는 안 된다.

실무 체계: 마스킹 도구 → 설정된 인공지능 조사 에이전트 → 마스킹 해제.

테스트 체계: 완전히 로컬에서 돌아가는 위원회 작업 공간 → 검증과 이후의 반복 개선.

다음 단계 — 보안이 확보된 사내 Fire

한편 그룹 정보기술 부서는 사내 환경 Collab 안에서 내부 인공지능 Fire를 개발하고 있다. 우리에게는 자연스러운 다음 단계다. 위원회 조력자의 방법론 논리를 보안이 확보된 사내 서버 환경으로 옮기면, 대형 모델의 성능과 기밀성 요건 사이에서 하나를 고를 필요가 없어진다.

우리는 Fire를 “자동 조사관”이 아니라 같은 원칙을 구현할 또 하나의 환경으로 본다. 자료는 보호된 인프라 안에 머물고, 인공지능은 위원회가 타임라인, 방벽, 모순, 원인을 분석하도록 도우며, 결정은 여전히 사람이 내린다.

옮기기 전에 먼저 Fire의 기술적 역량을 점검해야 한다. 문서와 오디오 처리, 컨텍스트 용량, 접근 권한 분리, 로그, 데이터 보관, 결과 내보내기. 다시 말해 여기서도 우리는 어떻게든 새로 나온 모델을 써 보겠다는 욕심이 아니라, 방법론과 정보 보호에서 출발한다.

영상으로 보기: 로컬 조사의 전체 주기

이 글에서는 비슷비슷한 스크린샷 수십 장으로 본문을 채우지 않기로 했다. 3분짜리 화면 녹화가 각 요소가 서로 어떻게 맞물리는지, 사람이 실제로 하는 일과 프로그램이 하는 일이 무엇인지를 더 잘 보여 준다.

스크린샷은 아키텍처를 짚고 넘어가야 할 곳에만 필요하다. 자료 유형, 타임라인, 원인, 조치, 최종 Word 문서. 나머지 작동 방식은 영상으로 보는 편이 낫다. 영상은 글 끝에 있다.

시간은 어디서 절약되는가

사고 조사에는 여전히 사람이 필요하다. 현장을 살피고, 관계자를 면담하고, 문서를 확보하고, 사실을 논의하고, 결정을 내려야 한다. 위원회가 존재하는 의미 자체를 자동화할 수는 없다.

그러나 서류 작업의 상당 부분은 덜어 낼 수 있다. 녹음 받아 적기, 경위서 대조, 시간 불일치를 손으로 찾는 일, 인용문을 타임라인으로 옮기는 일, 방벽의 1차 배치, 원인 트리 작성, 조치 목록 초안 준비, 첫 보고서 초안 취합.

그리고 내가 보는 핵심 효과는 전문 인력을 줄이는 데 있지 않다. 오히려 그 반대다. 전문가가 문서를 기계적으로 다루는 데 쓰는 시간이 줄면, 애초에 조사를 하는 이유에 쓸 시간이 늘어난다. 사람들과 대화하고, 현장에서 일하고, 방벽을 점검하고, 관리자들이 같은 사건의 재발을 막도록 돕는 일 말이다.

결국 무엇을 얻었나

몇 년에 걸친 여정은 그 자체로 시사하는 바가 크다. 공개 클라우드 에이전트 → 수작업 마스킹 → 로컬 마스킹 도구와 마스킹 해제 → 로컬 음성 전사 → 테스트용 오프라인 시스템 → 다음 단계, 보안이 확보된 사내 Fire.

다만 오늘의 실무 도구는 실험적인 오프라인 버전이 아니라, 마스킹을 거치는 검증된 체계다. 원본 자료는 우리 손에 남고, 에이전트에는 비식별 버전만 가며, 복원은 로컬에서 이루어진다. 오프라인 시스템은 지금 시험하면서 단계적으로 다듬고 있다.

가장 중요한 변화는 기술적인 것조차 아니다. 우리는 인공지능에게 “누구의 잘못인가?”를 묻지 않게 되었고, 대신 다른 질문을 던지기 시작했다. “어떤 데이터가 부족한가, 어떤 방벽이 작동하지 않았는가, 왜 작동하지 않았는가, 그리고 어떤 대책이 재발 위험을 실제로 낮출 것인가?”

조사에서 인공지능이 쓸모 있는 자리는 바로 여기다. 판사도, 위원장도 아닌, 사람들이 사실을 더 깊이 파고들도록 돕는 빠른 두 번째 분석가.

그리고 하나 더: 자연 지능을 잊어서는 안 된다

모델이 강력해질수록 자신의 사고를 모델에 내주지 않는 것이 더 중요해진다. 인공지능은 자연 지능을 강화할 때 쓸모가 있다. 연결 고리를 더 빨리 보게 하고, 가설을 검증하게 하고, 초안을 엮어 주고, 사람들과 대화하고 현장에서 일할 시간을 벌어 줄 때 말이다.

그래서 내가 생각하는 올바른 길은 완성된 버튼을 누르기만 하는 사용자에 머물지 않고, 새로운 해법을 만드는 사람이 되는 것이다. 방법론을 이해하고, 아키텍처를 정하고, 결과를 검증하고, 오류를 바로잡으며, 도구와 함께 스스로도 더 강해지는 것.

인공지능은 써야 한다. 그러나 자신의 자연 지능도 그에 못지않게 활용하고 키워야 한다. 이 조합이 사건을 더 깊이 조사하고, 거기서 더 잘 배우고, 재발을 막는 데 도움이 된다면, 기술은 정말로 안전을 위해 제 몫을 하고 있는 것이다.

이 글의 프롬프트

마스킹을 거치는 실무 체계 → 테스트용 오프라인 시스템 → 다음 단계, 보안이 확보된 사내 Fire

현재 상태: 실제 업무에는 “로컬 마스킹 도구 → 설정된 클라우드 에이전트 → 로컬 마스킹 해제” 체계를 쓴다. 완전 오프라인 시스템은 이미 개발되었지만 시험과 개선 단계에 있다. Fire는 다음 단계의 보안 사내 환경으로 검토하고 있다.

Prompt 1. 현재 실무용 에이전트: 비식별 자료 전용

본문과의 연결: “세 번째 버전”과 “지금 무엇을 쓰고 있는가” 섹션. 로컬 마스킹을 거친 뒤 현재 가동 중인 실무 체계다.

당신은 산업안전보건 분야 사고를 내부 조사하는 조사위원회의 분석 보조자입니다.

작업 체계:
원본 문서는 먼저 로컬에서 마스킹됩니다. 당신은 비식별 사본만 받습니다. 당신의 작업이 끝나면 결과는 당신에게 없는 별도의 키와 비밀번호로 로컬에서 마스킹 해제됩니다.

중요:
- 사전에 비식별화된 자료만 다루세요;
- 성명, 부서, 주소 등 가려진 값을 복원하려 하지 마세요;
- 별도로 제공되지 않는 한 인터넷과 외부 사실을 사용하지 마세요;
- 과실 책임자를 판정하지 마세요;
- 가설을 확인된 사실이라고 부르지 마세요;
- 위원회의 결정을 대신하지 마세요.

목표: 위원회가 자료를 구조화하고 조사의 완결성을 점검하도록 돕는 것.

모든 결론마다 다음을 구분하세요:
FACT — 자료로 직접 확인됨;
ASSUMPTION — 근거 있는 추정;
CONFLICT — 자료 간 모순;
GAP — 누락된 정보;
QUESTION — 해소해야 할 질문;
HYPOTHESIS — 확인이 필요한 가능한 원인.

순서:
1. 받은 자료의 대장을 작성하세요.
2. 확인 가능한 사실만 출처와 함께 추출하세요.
3. 예비 타임라인을 작성하세요.
4. 모순과 빈틈을 제시하세요.
5. 위원회를 위한 추가 질문을 작성하세요.
6. 타임라인이 확정된 뒤 방벽 분석을 제안하세요.
7. 원인은 위원회가 결정하기 전까지 가설로만 제시하세요.
8. 조치는 확인된 원인과만 연결하세요.

모든 표에 출처를 표시하세요: 자료 번호, 문서/파일, 그리고 결론의 근거가 된 짧은 인용문이나 정확한 위치.

Prompt 2. 사건 타임라인과 결정적 요인

본문과의 연결: 실무 에이전트와 테스트용 오프라인 시스템의 타임라인 관련 섹션.

사고 자료 가운데 검증을 마친 텍스트를 전달합니다.

타임라인 초안을 작성하세요.

규칙:
1. 자료에 없는 사건을 추가하지 마세요.
2. 시각이 정확하면 정확한 시각으로 표시하세요.
3. 시각이 대략적이면 “추정”이라고 표시하세요.
4. 두 출처의 시각이나 순서가 다르면 말없이 한쪽을 고르지 말고 CONFLICT로 표시하세요.
5. 각 행마다 날짜/시각, 사건 또는 조건, 출처, 상태 FACT / ASSUMPTION / CONFLICT, 중요한 이유를 기재하세요.
6. 결정적 요인 목록을 따로 제안하세요. 결정적 요인이란 그것이 없었다면 원치 않는 사건이나 결과의 심각도가 달라졌을 가능성이 큰 사건/조건을 말합니다.
7. 결정적 요인은 위원회가 결정하기 전까지 확정된 것으로 보지 마세요.

마지막에 다음을 제시하세요:
A. 타임라인 초안;
B. 모순 목록;
C. 누락 데이터 목록;
D. 위원회 논의용 결정적 요인 초안.

Prompt 3. 모순, 빈틈, 추가 면담 계획

본문과의 연결: 계획 수립, 자료 수집, 두 번째 분석가로서 인공지능의 역할에 관한 섹션.

자료와 타임라인 초안을 바탕으로 위원회 작업 시트를 준비하세요.

해야 할 일:
1. 경위서, 문서, 시각, 기술 데이터 사이의 모순을 찾으세요.
2. 표현의 차이를 증거 없이 거짓으로 해석하지 마세요.
3. 각 모순마다 출처 A, 출처 B, 정확히 무엇이 다른지, 무엇을 확인해야 하는지를 표시하세요.
4. 추가 면담을 위한 질문을 작성하세요.
5. 질문은 답을 유도하지 않는 개방형·중립형이어야 합니다.
6. 빈틈을 메울 수 있는 문서, 측정, 감정, 사진, 도식 목록을 따로 작성하세요.
7. 경위, 방호 방벽, 원인, 결과의 심각도를 규명하는 데 핵심적인 질문이 무엇인지 표시하세요.

모순이 있다는 사실만으로 진술의 신빙성이 없다고 결론짓지 마세요.

Prompt 4. 방벽 논리와 “보타이”

본문과의 연결: 방벽 논리와 원인 분석으로 넘어가는 과정에 관한 섹션.

위원회가 확정한 타임라인과 결정적 요인을 사용하세요.

방벽 분석 초안을 작성하세요.

1. 위험원(들).
2. 원치 않는 사건.
3. 결과.
4. 예방 방벽: 어떤 방벽이 사건/접촉을 막았어야 했는가; 그 방벽이 존재했는가; 사용할 수 있었는가; 적용되었는가; 작동했는가; 확인 출처.
5. 완화 방벽: 어떤 방벽이 결과를 막거나 심각도를 낮췄어야 했는가; 존재했는가; 작동했는가; 확인 출처.
6. 없었거나 효과가 없었던 방벽마다 “왜?”라는 질문을 세우세요.

방벽이 없었다는 사실을 자동으로 근본 원인이라고 부르지 마세요.
방법론, 문서, 공정 논리에 없는 방벽을 HYPOTHESIS 표시 없이 지어내지 마세요.

결과물은 확정된 결론이 아니라 위원회 논의용 표입니다.

Prompt 5. 원인 트리와 근본 원인

본문과의 연결: “방법론이 엄격해지자” 섹션과 원인 블록.

입력 자료:
- 확정된 타임라인;
- 결정적 요인;
- 방벽 분석;
- 확인된 사실에 대한 위원회의 결정.

원인 트리 초안을 작성하세요.

출발점: “원치 않는 사건 + 결과”.
첫 두 가지:
A. 원치 않는 사건은 왜 일어났는가?
B. 왜 그러한 결과가 초래되었는가 / 왜 심각도가 그 정도였는가?

이어서:
1. 각 노드마다 시스템적 원인에 이를 때까지 필요한 만큼 “왜?”를 물으세요.
2. 각 원인을 상위 질문과 연결하세요.
3. 모든 결정적 요인은 트리에 반영되거나, 제외된 이유가 따로 설명되어야 합니다.
4. 사람의 행동/실수를 근본 원인으로 받아들이지 마세요. 분석을 이어 가세요. 그 행동이 왜 가능했는지, 또는 왜 허용되는 것으로 여겨졌는지.
5. 근본 원인은 다음을 충족할 때만 제안하세요: 프로세스/시스템의 구체적 결함을 기술한다; 제거할 수 있다; 기업/그룹의 관리 범위 안에 있다; 구체적 대책을 제안할 수 있게 한다.
6. 구체적 설명 없는 일반적 표현은 금지합니다: “낮은 안전 문화”, “개인 부주의”, “허술한 관리”, “교육 미흡”.

각 노드마다:
- 기술 내용;
- 유형: 직접 / 중간 / 근본 원인 후보;
- 뒷받침하는 출처;
- 관련된 결정적 요인;
- 상태 FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

위원회를 대신해 근본 원인을 확정하지 마세요.

Prompt 6. 시정 및 예방 조치

본문과의 연결: 조치, 그리고 첫 초안 준비에서 아끼는 시간에 관한 섹션.

위원회가 대책 수립 대상 목록에 넣기로 결정한 원인만 사용하세요.

각 원인마다 조치안을 2–4개 제안하세요.

각 조치안마다 다음을 기재하세요:
- 어떤 구체적 원인을 제거하는지 또는 어떤 방벽을 강화하는지;
- 유형: 기술적 / 조직적 / 교육 / 점검·감독 / 기타;
- 기대되는 검증 가능한 결과;
- 효과성을 확인하는 방법;
- 적용 범위: 사건 발생 장소 / 유사 시설 / 기업 / 그룹;
- 영구 조치를 이행하기 전까지 임시 보호 조치가 필요한지;
- 발생할 수 있는 부수적 위험;
- 기한과 담당자를 정하는 데 필요한 데이터.

위원회 결정 없이 담당자 성명과 구체적 기한을 채우지 마세요.
확인된 원인을 제거하지 못한다면 “수시 안전교육 실시” 같은 조치를 만능 해법으로 제안하지 마세요.
감독만 강화할 뿐 근본 원인을 제거하지 못하는 조치는 따로 표시하세요.

Prompt 7. 방법론에 따른 최종 보고서 초안

본문과의 연결: Word 문서 작성, 그리고 “서명용 문서가 아닌 첫 초안” 원칙에 관한 섹션.

위원회가 승인한 요소만을 바탕으로 내부 보고서 본문 초안을 준비하세요.

사용할 자료:
- 사고 개요 카드;
- 확정된 타임라인;
- 결정적 요인 목록;
- 승인된 방벽 분석;
- 최종 원인 트리;
- 승인된 원인 목록;
- 합의된 조치;
- 자료 대장.

확인되지 않은 가설, 표시 없는 논쟁적 견해, 출처 없는 결론을 사실처럼 최종본에 넣지 마세요.

구성:
1. 개요 및 경위.
2. 자료 및 정보 수집 방법.
3. 타임라인.
4. 결정적 요인.
5. 방호 방벽.
6. 원인 분석.
7. 근본 원인.
8. 시정 및 예방 조치.
9. 부록 / 자료 대장.

가능한 경우 중요한 결론 옆에 근거 자료에 대한 참조를 남기세요.
문서 상단에 “초안. 위원회의 검토와 승인이 필요함”이라고 표시하세요.
과실 책임에 관한 결론을 내리지 마세요.

Prompt 8. 테스트용 오프라인 시스템을 위한 마스터 프롬프트

본문과의 연결: “오프라인 시스템은 이미 만들었고, 이제 시험 중이다” 섹션.

저는 프로그래머가 아닙니다. 사내 방법론에 따라 사고를 내부 조사하기 위한 테스트용 로컬 애플리케이션을 만들 수 있도록 도와주세요. 이번 단계의 목표는 파일럿과 품질 검증이지, 실운영에 자동으로 투입하는 것이 아닙니다.

단계별로 진행하세요. 각 단계마다:
1. 무엇을 왜 하는지 설명하세요;
2. 한 가지 작업 또는 완성된 파일/패치 하나를 제시하세요;
3. 제 결과나 스크린샷을 기다리세요;
4. 그것을 확인하세요;
5. 그런 다음에만 다음 단계로 넘어가세요.

목표 아키텍처
- Windows 10/11;
- 127.0.0.1의 로컬 backend와 브라우저 인터페이스;
- 모델을 한 번 준비한 뒤에는 외부 인터넷 없이 사건 자료 작업;
- 고성능 업무용 컴퓨터에서의 작업을 전제로 하되, 저사양 컴퓨터에는 경량 모델을 제안하고 품질/속도 저하를 숨기지 말 것;
- 사건 파일의 로컬 저장;
- 체크섬이 포함된 사건 파일 아카이브;
- 버전 이력;
- 외부 API로 자료를 반드시 보내야 하는 구조는 두지 말 것.

자료
- DOCX: 단락, 표, 머리글과 바닥글;
- 텍스트가 있는 PDF;
- PDF 스캔본 / 이미지 — 로컬 문자 인식;
- 도식 / 사진 — 원본을 보관하고 설명은 초안으로만 제안;
- 오디오 / 비디오 — 로컬 음성 전사;
- 마이크 녹음;
- 수동 입력과 편집;
- 텍스트를 인공지능 분석에 쓰기 전 “원본과 대조함” 표시 필수.

로컬 모델
- 로컬 엔진을 통한 LLM(예: Ollama);
- 다국어 음성 모델 Whisper;
- 필요 시 로컬 vision-모델;
- 조사 도중 애플리케이션이 몰래 모델을 내려받아서는 안 됨.

방법론 / 단계
1. 최초 정보.
2. 위원회 계획.
3. 자료 수집.
4. 타임라인과 결정적 요인.
5. 방벽과 원인.
6. 조치.
7. 보고서.

인공지능 규칙
- 인공지능은 제안만 한다.
- 모든 결론은 출처와 인용문을 함께 저장한다.
- FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS를 구분한다.
- 원인은 위원회가 확인하기 전까지 가설이다.
- 담당자와 기한은 모델이 스스로 지정하지 않는다.
- 위원회는 모든 제안을 채택, 기각, 수정할 수 있어야 한다.
- 최종 Word는 편집 가능한 초안이다.
- 보고서에는 원인 트리, 방벽, 대장, 부록을 포함한다.

보안
- CDN과 외부 원격 측정 없음;
- 조사 관련 네트워크 요청은 loopback으로만;
- 로컬 작업이 곧 자동 비식별화는 아니라는 점을 사용자에게 알릴 것;
- 공개된 클라이언트 코드에 비밀 정보를 저장하지 말 것;
- 사건 파일 삭제, 백업, 이전 기능을 마련할 것.

디렉터리 구조, 사건 파일 데이터 형식, 위협 모델부터 시작하세요. 제가 승인하기 전에는 코드를 작성하지 마세요.

파일럿 상태
- 버전에 “테스트 / 파일럿”이라고 명확히 표시할 것;
- 기준이 되는 교육용 사례 세트를 추가할 것;
- 각 사례마다 인공지능의 결과를 사람/위원회의 결론과 비교할 것;
- 발견된 결함과 반복 개선 기록을 관리할 것;
- 시험이 끝나기 전에는 시스템이 실운영 준비를 마쳤다고 하지 말 것.

Prompt 9. 파일럿 오프라인 시스템 감사

본문과의 연결: 자동화의 한계, 기밀성, 현재의 테스트 상태에 관한 섹션.

위원회에 넘기기 전에 완성된 애플리케이션과 조사 초안을 감사하세요.

기술 점검
1. 사건 파일 작업 중에 외부 네트워크 요청이 발생하는가.
2. CDN, 외부 글꼴, 클라우드 speech-to-text, 외부 API를 사용하는가.
3. 원본, 전사본, 로컬 모델, 백업은 어디에 저장되는가.
4. 사건 파일을 삭제하면 어떻게 되는가.
5. 원본 문서가 진단 로그에 남지 않는가.
6. 오류가 날 때 사건 파일 내용이 외부로 내보내지지 않는가.

방법론 점검
7. 모든 중요한 결론에 출처가 있는가.
8. 사실과 가설이 구분되어 있는가.
9. 모든 결정적 요인이 원인 분석에 반영되었는가.
10. 시스템적 조건을 분석하지 않은 채 사람의 행동을 근본 원인으로 지목하지 않았는가.
11. 조치가 구체적인 원인/방벽과 연결되어 있는가.
12. 위원회 결정 없이 모델이 담당자와 기한을 지정하지 않았는가.
13. 보고서 초안을 승인된 문서처럼 내세우지 않았는가.

기밀성 점검
14. 로컬 사건 파일에 어떤 개인정보/의료 정보가 들어 있는가.
15. 시연, 공개, 전달을 위해 추가 마스킹이 필요한가.
16. 파일 이름과 스크린샷에 불필요한 성명이 들어 있지 않은가.

결과는 표로 제시하세요:
점검 항목 | 상태 | 발견된 위험 | 수정할 사항 | 확인해야 할 사람.

조사의 실질적 결론을 자동으로 수정하지 마세요.

성숙도 점검
17. 기준 사례 세트와 비교 결과가 있는가.
18. 어떤 기능이 이미 안정적이고, 어떤 기능이 아직 실험 단계인가.
19. 실운영 전에 어떤 오류/제약을 해결해야 하는가.
20. 인터페이스가 인공지능의 결론을 위원회의 결정인 것처럼 오해하게 만들지 않는가.

프롬프트 활용법

• Prompt 1 — 현재 실무에서 쓰는 체계: 사전에 비식별화한 자료만 다루며, 마스킹 해제 키는 에이전트에 넘기지 않는다.
• Prompt 2–7 — 현재 에이전트는 물론 앞으로의 로컬/서버 환경에서도 쓸 수 있는 방법론 실무 블록.
• Prompt 8 — 테스트용 완전 오프라인 시스템의 구축과 추가 개선.
• Prompt 9 — 적용 범위를 넓히기 전 파일럿 감사.

시리즈의 기본 원칙은 그대로다. 먼저 데이터를 보호하고 방법론을 정한 다음 자동화한다. 인공지능은 위원회의 작업을 강화하지만, 전문가다운 사고, 사실 검증, 사람의 책임을 대신하지는 않는다.