1) 출발점은 “사고조사 보고서가 매번 처음부터 시작된다”는 불편함이었습니다

사고조사 보고서는 형식이 있는 문서입니다. 사고 개요, 재해자 정보, 발생 장소, 작업 내용, 사고 발생 과정, 원인, 대책, 향후 조치가 들어가야 합니다. 그런데 실제 작성 과정은 매번 새 문서를 여는 것처럼 느껴집니다. 현장 사진과 진술은 따로 있고, 위험성평가 자료는 다른 폴더에 있고, 작업허가서나 TBM 기록은 담당자에게 물어봐야 합니다. 자료가 모이기 전까지 보고서는 빈칸이 많고, 자료가 모인 뒤에는 문장으로 정리하는 시간이 오래 걸립니다.

특히 사고 직후 초동 보고를 할 때는 완벽한 원인분석보다 “무엇을 더 확인해야 하는가”가 중요합니다. 그러나 사람은 급할수록 눈앞의 사고 장면에만 집중합니다. 재해자 행동, 작업 절차, 설비 방호상태, 감독체계, 교육 이력, 위험성평가 반영 여부처럼 뒤쪽에 있는 질문은 늦게 떠오릅니다. 그래서 첫 번째 목표는 보고서를 바로 완성하는 것이 아니라, 사고 개요를 보고 추가 확인 질문을 뽑아주는 기능이었습니다.

바이브코딩으로 접근하기 좋았던 이유도 여기에 있습니다. 이 업무는 정답 하나를 맞히는 문제가 아니라, 안전담당자가 이미 알고 있는 사고조사 순서를 화면과 프롬프트로 옮기는 문제였습니다. 사고 개요 입력, 보강 질문, 분석 실행, 결과 검토, 인쇄와 엑셀 다운로드라는 흐름을 먼저 잡고, 그 흐름에 맞춰 백엔드와 프론트엔드를 나누면 작은 웹 도구로 만들 수 있었습니다.

2) 화면은 세 단계로 단순하게 잡았습니다

프론트엔드 화면은 1단계 사고 개요 입력, 2단계 보강 질문 답변, 3단계 사고조사 보고서 결과로 구성했습니다. 사고 개요 입력에는 회사명, 현장명, 업종, 발생일시, 발생장소, 사고형태, 공정명, 작업명, 재해자 정보, 상해 정보, 사고 구분, 사고 경위가 들어갑니다. 모든 항목을 강제로 채우게 하면 사용자가 시작하기 어렵기 때문에, 아는 항목만 입력하되 사고 경위는 가능한 구체적으로 쓰도록 안내했습니다.

두 번째 단계는 보강 질문입니다. 사용자가 사고 개요를 입력하면 API의 questions 모드가 실행되고, AI는 보고서 작성을 위해 더 확인해야 할 질문을 6개에서 10개 정도 만듭니다. 예를 들어 작업 전 안전조치가 있었는지, 방호장치가 정상 상태였는지, 재해자가 어떤 절차를 따랐는지, 감독자는 어디에 있었는지, 비상 대응은 어떻게 진행되었는지를 묻는 식입니다. 이 단계는 사고조사의 빈칸을 드러내기 위한 장치입니다.

세 번째 단계에서는 분석 결과를 보여줍니다. 결과는 하나의 긴 글이 아니라 섹션으로 나뉩니다. 사고 시나리오, 원인분석, 재발방지대책, 수시 위험성평가, 산업재해조사표가 각각 따로 보이도록 했습니다. 사용자는 화면에서 바로 읽을 수도 있고, 인쇄 또는 PDF로 저장할 수도 있고, 엑셀 다운로드로 내부 검토 자료를 만들 수도 있습니다. 사고조사 도구에서 결과 화면은 단순한 출력 페이지가 아니라 검토 작업대입니다.

3) 사고 개요 입력은 “아는 만큼 시작”할 수 있어야 했습니다

사고 직후에는 모든 정보가 완성되어 있지 않습니다. 사업장명과 발생장소는 알지만 재해자 나이나 근속기간은 모를 수 있고, 사고형태는 짐작되지만 정확한 상해 정도는 병원 확인 후에야 알 수 있습니다. 그래서 입력 폼은 비어 있는 값을 허용하되, 사고 경위나 사고형태가 전혀 없으면 분석을 막도록 했습니다. 최소한 어떤 일이 일어났는지는 있어야 AI가 질문을 만들 수 있기 때문입니다.

입력 항목은 보고서 작성에 필요한 필드를 기준으로 잡았습니다. 공정명과 작업명은 위험성평가 항목으로 이어지고, 사고형태와 발생장소는 시나리오와 위험유형 분류에 영향을 줍니다. 재해자 정보와 상해 정보는 산업재해조사표 초안에 들어가며, 사고 구분은 실제 재해인지 아차사고인지에 따라 분석의 초점이 달라집니다. 단순한 폼처럼 보이지만, 뒤쪽 결과 구조와 연결된 입력입니다.

이 구조에서 중요한 점은 빈칸을 부끄럽게 만들지 않는 것입니다. 안전담당자는 처음부터 모든 답을 갖고 있지 않아도 됩니다. 오히려 “확인 필요”가 보이는 편이 낫습니다. AI가 모르는 내용을 그럴듯하게 채워 넣는 것보다, 비어 있는 정보를 명확히 드러내는 것이 사고조사에는 더 안전합니다. 그래서 백엔드 프롬프트에도 부족한 정보는 확인 필요로 표기하라는 문장을 넣었습니다.

4) 보강 질문 생성은 보고서 품질을 올리는 가장 현실적인 단계였습니다

처음에는 사고 개요를 바로 분석하게 만들 수도 있었습니다. 하지만 사고조사는 입력 품질에 크게 좌우됩니다. “지게차와 보행자가 부딪힘”이라는 한 줄만으로는 좋은 원인분석이 나오기 어렵습니다. 보행자 동선이 있었는지, 후진 경보음은 작동했는지, 작업구역 분리가 되어 있었는지, 유도자는 있었는지, 운전자의 시야를 가린 적재물이 있었는지, 작업 전 위험성평가에서 충돌 위험이 다뤄졌는지 확인해야 합니다.

그래서 질문 생성 모드는 별도로 만들었습니다. API 요청의 mode가 questions이면 사고 개요만 받아서 질문 배열을 반환합니다. 질문은 id, question, hint를 갖고, 화면은 이 질문들을 textarea로 렌더링합니다. 사용자는 아는 만큼 답하고, 모르면 비워둘 수 있습니다. 중요한 것은 AI가 한 번에 보고서를 쓰기 전에 “이 사고를 제대로 보려면 무엇을 더 알아야 하는가”를 먼저 묻게 만든 점입니다.

이 단계는 실무적으로도 쓸모가 큽니다. 보강 질문 목록은 현장 확인 체크리스트처럼 사용할 수 있습니다. 사고 현장에 다시 가거나, 관리감독자와 면담하거나, 작업자 진술을 받을 때 질문 목록을 들고 가면 빠뜨리는 항목이 줄어듭니다. 즉 이 도구는 보고서 작성 도구이면서 동시에 사고조사 질문 생성 도구입니다.

5) 백엔드는 questions와 analyze 두 모드로 나눴습니다

PHP 백엔드는 같은 엔드포인트에서 두 가지 모드를 처리합니다. questions 모드는 보강 질문만 만들고, analyze 모드는 전체 사고조사 보고서 초안을 만듭니다. 요청은 JSON으로 받고, 응답도 JSON으로 돌려줍니다. 프론트엔드는 mode와 overview, answers를 보내고, 백엔드는 필요한 프롬프트를 만든 뒤 Gemini API를 호출합니다. 이 구조는 단순하지만 업무 흐름과 잘 맞습니다.

API에는 CORS 허용 도메인, POST 요청 제한, JSON 파싱 오류 처리, 로그 기록, fatal error shutdown 로그 같은 기본 장치가 들어 있습니다. 또한 여러 API 키를 순서대로 시도하는 키 로테이션 흐름도 있습니다. 중요한 점은 이 글에서 실제 키 값을 다룰 필요가 없다는 것입니다. 운영 코드에서는 키가 노출되지 않도록 관리해야 하고, 글에서는 “키 로테이션과 오류 처리 구조가 있다”는 수준만 설명하면 충분합니다.

응답 파싱도 신경 써야 했습니다. AI 응답은 원칙적으로 JSON만 오도록 지시했지만, 실제 서비스에서는 모델 응답이 항상 이상적이라고 가정하면 안 됩니다. 그래서 응답 텍스트에서 배열 또는 객체 형태의 JSON을 추출하고, 해석하지 못하면 오류를 반환합니다. 사고조사 보고서는 문장만 예쁘게 나오면 되는 것이 아니라, 화면이 렌더링할 수 있는 안정적인 구조로 와야 합니다.

6) 원인분석 분류체계를 프롬프트에 넣은 이유

사고 원인을 AI에게 자유롭게 쓰게 하면 그럴듯하지만 제각각인 문장이 나올 수 있습니다. 어떤 답변은 “안전의식 부족”이라고 쓰고, 어떤 답변은 “작업자 부주의”라고 쓰고, 어떤 답변은 “관리 미흡”이라고만 쓸 수 있습니다. 이런 표현은 보고서 문장으로는 익숙하지만, 대책과 연결하기에는 너무 넓습니다. 그래서 직접원인과 근본원인 분류체계를 프롬프트에 펼쳐 넣었습니다.

코드는 lov_causes.json 파일이 있으면 그 안의 directCausesGrouped와 rootCausesGrouped를 읽어 분류표를 만들고, 없으면 축약된 폴백 분류를 사용합니다. 직접원인은 불안전한 행동과 불안전한 상태로 나누고, 근본원인은 인적 요인과 업무/시스템적 요인으로 나눕니다. 각 항목에는 영문 코드와 한글 라벨이 붙습니다. AI는 보고서에서 이 코드와 라벨을 사용해야 합니다.

이 방식의 장점은 결과를 비교하고 추적하기 쉽다는 점입니다. 원인분석이 단순 문장으로 끝나면 나중에 사고 유형별로 어떤 원인이 반복되는지 보기 어렵습니다. 하지만 코드와 라벨을 함께 남기면 반복 사고의 패턴을 볼 수 있습니다. 예를 들어 작업절차 미준수, 부적절한 작업계획, 교육·훈련 미흡, 위험성평가 미흡 같은 원인이 여러 사고에서 반복되는지 확인할 수 있습니다. 작은 도구라도 데이터를 쌓을 생각을 하면 분류체계가 필요합니다.

7) 사고 시나리오는 시간 순서로 쪼개야 했습니다

사고조사에서 “사고 발생 과정”을 한 문단으로 쓰면 읽기에는 편하지만, 원인을 찾기에는 부족할 수 있습니다. 사고는 보통 한 순간만의 문제가 아닙니다. 사건 전의 작업 준비, 작업 절차, 설비 상태, 작업자 행동, 감독 상태가 있고, 사건 발생 순간의 직접 접촉이나 추락이나 끼임이 있으며, 사건 후 대응과 구조 과정이 있습니다. 피해 크기는 사건 전 요인뿐 아니라 사건 후 대응에 의해서도 달라질 수 있습니다.

그래서 시나리오 결과는 timeline 배열로 받도록 했습니다. 각 노드는 phase, actor, action, is_cause, cause_note를 갖습니다. phase는 before, event, after로 나뉘고, actor는 행위자, action은 구체적 행동이나 상태, is_cause는 그 노드가 원인인지 여부, cause_note는 왜 원인인지 설명합니다. 화면은 이 값을 세로 타임라인으로 렌더링하고, 원인 노드는 강조 표시합니다.

이 구조는 검토에 도움이 됩니다. 예를 들어 사고 전 단계의 “작업구역 분리 미흡”은 발생확률을 높인 원인이 될 수 있고, 사고 후 단계의 “응급조치 지연”은 피해크기를 키운 원인이 될 수 있습니다. 두 원인은 같은 “원인”이라는 단어로 묶이지만 성격이 다릅니다. 그래서 프롬프트에서는 발생확률은 사건 전 요인 중심으로, 피해 크기는 사건 후 대응 요인 중심으로 별도 평가하라고 지시했습니다.

8) 5Why는 모든 직접원인에 붙어야 했습니다

5Why 분석은 말로는 쉽지만 실제 보고서에서는 자주 얕아집니다. “작업자가 절차를 지키지 않았다. 왜? 교육이 부족했다. 왜? 관리가 미흡했다.” 정도에서 멈추면 근본원인처럼 보이지만, 실행 가능한 대책으로 이어지기 어렵습니다. 그래서 프롬프트에는 각 직접원인이 반드시 branches를 갖고, 각 branch의 whys 배열은 왜1부터 왜5까지 모두 채우라고 넣었습니다.

또한 가능하면 서로 다른 관점의 why 분기를 만들도록 했습니다. 같은 직접원인도 인적 요인과 시스템 요인으로 나눠볼 수 있기 때문입니다. 예를 들어 보호구 미착용이라는 직접원인은 작업자의 착용 습관 문제일 수도 있지만, 보호구 지급 기준, 작업 전 점검, 관리감독자 확인, 교육 체계, 작업 압박과 연결될 수도 있습니다. 하나의 답만 고정하면 사고조사가 좁아집니다.

물론 AI가 만든 5Why가 항상 맞는 것은 아닙니다. 하지만 5단계로 강제로 펼쳐진 초안은 검토자가 “여기서부터는 사실이 아니다”, “이 단계는 근거가 부족하다”, “실제 원인은 다른 쪽이다”라고 고치기 좋습니다. 빈 보고서보다 잘못된 초안이 항상 낫다는 뜻은 아닙니다. 다만 명확히 초안이라는 전제와 확인 필요 표시가 있다면, 구조화된 초안은 사고조사의 토론을 빠르게 시작하게 해줍니다.

9) 재발방지대책은 근본원인과 연결되어야 했습니다

사고조사 보고서에서 가장 아쉬운 부분은 원인과 대책이 따로 노는 경우입니다. 원인에는 작업계획 미흡이 적혀 있는데 대책에는 “근로자 교육 강화”만 들어가거나, 방호장치 결함이 원인인데 대책에는 “주의 환기”만 들어가는 식입니다. 이런 보고서는 문서는 완성되어도 사고를 줄이는 힘은 약합니다. 그래서 countermeasures에는 target_root_cause를 넣고, cause_analysis에서 도출된 근본원인 라벨과 일치하도록 요구했습니다.

대책의 type은 기술적, 관리적, 교육적으로 나눴습니다. action에는 무엇을, 누가, 어떻게, 어떤 기준이나 주기로 실행할지를 쓰도록 했습니다. “안전교육 실시” 같은 문장보다 “관리감독자가 작업 전 10분 TBM에서 추락위험 작업절차와 추락방지설비 확인 항목을 체크리스트로 확인하고, 미흡 시 작업을 보류한다”처럼 실행 단위가 보여야 합니다. AI에게도 이 정도 수준의 구체성을 요구해야 쓸 만한 초안이 나옵니다.

이 구조는 나중에 대책 이행관리로 확장하기 좋습니다. responsible과 due가 있으므로 담당부서와 기한을 연결할 수 있고, target_root_cause가 있으므로 어떤 근본원인을 줄이기 위한 조치인지 추적할 수 있습니다. 지금 도구는 보고서 초안 생성에 집중하지만, 구조를 잘 잡아두면 향후에는 조치 이행현황, 완료 증빙, 효과성 검토까지 이어질 수 있습니다.

10) 수시 위험성평가는 사고조사의 후속 업무와 연결됩니다

사고가 발생하면 같은 작업이나 유사 작업에 대한 위험성평가를 다시 봐야 합니다. 기존 위험성평가가 사고의 전조를 제대로 다뤘는지, 현재 안전조치가 충분했는지, 추가 개선대책이 필요한지 확인해야 합니다. 그래서 analyze 결과에는 risk_assessment 배열을 넣었습니다. 공정명, 작업명, 설비, 위험유형, 위험근원, 잠재결과, 위험 상황 설명, 현재 안전조치, 현재 심각도와 가능성, 개선대책, 개선 후 심각도와 가능성이 들어갑니다.

프롬프트에서는 최소 5개 이상, 가능하면 6개에서 10개 정도의 위험성평가 항목을 작성하도록 했습니다. 사고에서 나온 직접원인, 근본원인, 시나리오의 전조와 피해확대 요인이 각각 위험요인으로 반영되어야 합니다. 예를 들어 끼임 사고라면 기계적 위험만 볼 것이 아니라 작업절차, 비정상작업, 정비 중 에너지 차단, 작업자 접근, 비상정지, 구조 지연까지 볼 수 있습니다.

개선대책은 제거, 대체, 공학적, 관리적, PPE 단계로 나눠 쓰도록 했습니다. 모든 사고에 제거나 대체가 쉽게 적용되는 것은 아니지만, 이 계층을 한 번씩 생각하게 만드는 것 자체가 의미가 있습니다. 안전관리에서 대책이 교육과 주의로만 모이면 효과가 약해집니다. 공학적 조치와 관리적 조치, 개인보호구가 어떤 순서와 관계로 들어가는지 보고서 초안에서부터 보여주는 것이 중요합니다.

11) 산업재해조사표 초안은 빈칸을 줄이기 위한 기능입니다

도구의 결과에는 accident_report 객체도 포함됩니다. 사업장명, 사업자등록번호, 업종, 상시근로자 수, 소재지, 도급 여부, 재해자 성명, 성별, 나이, 국적, 고용형태, 근속기간, 직종, 발생일시, 발생장소, 작업유형, 재해 발생과정 및 원인, 상해종류, 상해부위, 휴업예상일수, 사망여부, 재발방지계획 요약을 받습니다. 이 값들은 화면에서 산업재해조사표처럼 보이는 테이블로 렌더링됩니다.

여기서도 핵심은 초안입니다. AI가 사업자등록번호나 정확한 근로자 수를 모를 수 있고, 재해자 개인정보는 별도 확인이 필요할 수 있습니다. 그러므로 모르는 값은 확인 필요로 남기는 것이 맞습니다. 담당자는 초안을 보며 실제 자료와 대조하고, 제출 양식과 최신 법령 요구사항에 맞게 수정해야 합니다. 도구는 빈 문서에서 시작하는 부담을 줄이는 역할을 합니다.

사고조사표 형태로 한 번 보여주는 이유는 보고서의 문장과 행정 양식 사이를 연결하기 위해서입니다. 사고 원인분석은 잘 되어 있는데 조사표에는 짧고 모호한 문장이 들어가면 안 됩니다. 반대로 조사표 작성에만 집중하면 5Why와 위험성평가가 얕아질 수 있습니다. 두 결과를 한 화면에서 같이 보게 하면 서로의 누락을 확인할 수 있습니다.

12) 엑셀 다운로드는 내부 검토 회의에 바로 쓰기 위한 기능입니다

프론트엔드에는 xlsx-js-style 라이브러리를 사용한 엑셀 다운로드 기능이 들어 있습니다. 결과 데이터가 있으면 사고조사 보고서, 위험성평가, 산업재해조사표 시트로 나눠 엑셀 파일을 만듭니다. 사고조사 보고서 시트에는 요약, 시나리오 타임라인, 직접원인, 5Why, 근본원인, 재발방지대책이 들어가고, 위험성평가 시트에는 각 위험요인과 위험도, 개선대책이 들어갑니다.

이 기능은 작지만 실무에서는 중요합니다. 사고조사 결과는 혼자 보는 문서가 아니라 현장소장, 관리감독자, 공무, 설비, 협력업체, 안전보건관리책임자와 함께 검토해야 하는 자료입니다. 웹 화면을 그대로 보여줄 수도 있지만, 회의에서는 엑셀이 여전히 편한 경우가 많습니다. 필터를 걸고, 담당자와 기한을 수정하고, 개선대책을 추가하기 쉽기 때문입니다.

파일명에는 사업장명 또는 사고조사라는 기본명과 날짜가 들어가도록 했습니다. 작은 배려지만, 다운로드 파일이 쌓이면 이름이 중요해집니다. 안전관리 업무에서는 자료를 만든 뒤 찾는 시간도 업무입니다. 도구가 만든 결과물은 나중에 다시 열어볼 수 있어야 하고, 내부 문서관리 체계에 넣기 쉬워야 합니다.

13) 인쇄와 PDF는 보고서 공유의 가장 단순한 출구입니다

결과 화면에는 인쇄/PDF 버튼도 있습니다. 브라우저 인쇄 기능을 이용하면 보고서 화면을 PDF로 저장하거나 종이로 출력할 수 있습니다. CSS에는 print media 설정을 넣어 입력 패널과 안내 콘텐츠를 숨기고, 결과 섹션이 끊기지 않도록 처리했습니다. 웹 도구라고 해서 모든 산출물이 웹 안에만 머물 필요는 없습니다. 사고조사 자료는 회의실에서 종이로 검토되기도 하고, PDF로 결재 라인에 공유되기도 합니다.

이 기능을 만들면서 다시 느낀 점은 안전관리 도구는 끝단 출력까지 봐야 한다는 것입니다. 화면에서만 멋진 도구는 실제 업무 흐름에 들어가기 어렵습니다. 입력, 분석, 검토, 수정, 공유, 보관 중 어느 단계에서 막히면 사용자는 다시 엑셀과 한글 파일로 돌아갑니다. 그래서 작은 도구라도 인쇄와 다운로드는 초기에 붙이는 편이 좋습니다.

물론 인쇄본이나 PDF도 최종 제출본은 아닙니다. 현장 확인, 담당자 검토, 법정 양식 확인, 개인정보 처리, 내부 승인 절차를 거쳐야 합니다. 도구의 역할은 그 전 단계에서 구조화된 초안을 빠르게 만드는 것입니다. 초안의 속도와 최종 문서의 정확성은 서로 다른 목표이고, 둘 다 필요합니다.

14) 사용 흐름 예시

이 흐름에서 가장 중요한 것은 사고 개요, 보강 질문, AI 초안, 담당자 검토, 공유 산출물이 분리되어 있다는 점입니다. 단계가 분리되어 있으면 사용자는 어느 단계에서 사실 확인을 해야 하는지 알고, AI 결과를 최종 결론으로 착각할 가능성이 줄어듭니다.

15) 바이브코딩으로 빨라진 부분

가장 빨라진 부분은 화면과 프롬프트를 동시에 다듬는 일이었습니다. 사고조사 업무를 설명하면 입력 필드가 만들어지고, 출력 구조를 말하면 JSON 스키마가 잡히고, 결과 화면을 보면서 “여기는 타임라인이 더 낫다”, “원인 노드는 강조되어야 한다”, “대책은 담당과 기한이 있어야 한다”는 식으로 바로 수정할 수 있었습니다. 전통적인 개발 방식이었다면 요구사항 문서를 길게 쓰고 기다렸을 부분을 훨씬 짧은 주기로 확인했습니다.

또 하나는 안전담당자의 언어를 코드 구조로 옮기는 속도였습니다. 직접원인, 근본원인, 5Why, 수시 위험성평가, 산업재해조사표는 개발자에게는 낯선 단어일 수 있습니다. 하지만 안전담당자가 그 의미와 업무 흐름을 정확히 알고 있다면, AI와 코드는 그 구조를 빠르게 화면과 데이터로 바꿔 줍니다. 바이브코딩의 장점은 기술을 몰라도 된다는 뜻이 아니라, 업무 구조를 아는 사람이 프로토타입을 훨씬 빨리 만들 수 있다는 뜻에 가깝습니다.

물론 빠르게 만든 만큼 검증도 필요합니다. 프롬프트가 너무 강하면 AI가 억지로 원인을 채울 수 있고, 너무 약하면 결과가 흐릿해집니다. 화면 구조가 편해 보여도 실제 사고 자료를 넣어보면 빠지는 항목이 보입니다. 그래서 이 도구는 한 번 만들고 끝나는 제품이 아니라, 실제 사고·아차사고 사례를 넣어보며 계속 다듬어야 하는 작업대입니다.

16) 사람이 끝까지 봐야 하는 부분

첫째, 사실관계입니다. AI는 입력된 사고 개요와 답변을 바탕으로 구조화된 추론을 할 뿐, 현장을 직접 보지 않습니다. 작업자가 실제로 어떤 동선을 이동했는지, 설비가 어떤 상태였는지, 방호장치가 정상 작동했는지, 교육이 실제로 이루어졌는지는 사람이 확인해야 합니다. 보고서 초안의 문장이 자연스럽다고 해서 사실이라고 볼 수 없습니다.

둘째, 법령과 사내 기준입니다. 산업재해조사표 제출 여부, 제출 기한, 중대재해 해당 여부, 재발방지대책의 적정성, 위험성평가의 절차적 요건은 최신 법령과 사내 기준을 확인해야 합니다. 도구 안의 안내 문구와 초안은 작성 보조일 뿐입니다. 실제 제출과 보고는 담당자의 검토와 승인 절차를 거쳐야 합니다.

셋째, 대책의 실행 가능성입니다. AI가 제안한 대책이 좋아 보여도 현장 여건, 예산, 설비 구조, 협력업체 계약, 작업 일정과 맞지 않을 수 있습니다. 반대로 실행하기 쉬운 대책만 고르면 사고 원인을 충분히 줄이지 못할 수 있습니다. 안전담당자는 기술적 조치, 관리적 조치, 교육적 조치를 균형 있게 보고, 실제 이행 가능한 수준으로 바꿔야 합니다.

17) 앞으로 개선하고 싶은 부분

첫째, 사고 사진과 도면을 분석 흐름에 연결하고 싶습니다. 현재 도구는 텍스트 기반 사고 개요와 답변을 중심으로 작동합니다. 하지만 사고 현장 사진, 작업구역 도면, 설비 배치도, 동선 그림이 있으면 시나리오 검토가 더 좋아질 수 있습니다. 다만 사진에는 개인정보와 민감정보가 포함될 수 있으므로 업로드, 저장, 삭제, 접근권한 정책을 먼저 설계해야 합니다.

둘째, 원인분석 결과를 누적해 반복 원인 대시보드로 보고 싶습니다. 여러 사고와 아차사고에서 어떤 직접원인과 근본원인이 반복되는지 볼 수 있다면, 교육 주제와 점검 계획을 더 잘 세울 수 있습니다. 예를 들어 “부적절한 작업계획”이 반복된다면 단순 교육보다 작업계획 검토 프로세스를 고쳐야 합니다. 개별 보고서를 넘어서 조직 학습으로 이어지는 기능입니다.

셋째, 재발방지대책 이행관리와 연결하고 싶습니다. 보고서 초안에 responsible과 due가 이미 들어가 있으므로, 이를 조치관리 목록으로 넘기고 완료 증빙과 효과성 확인까지 추적할 수 있습니다. 사고조사의 목표는 문서 작성이 아니라 재발 방지입니다. 보고서 도구가 조치 이행관리까지 이어지면 실무 효과가 더 커질 것입니다.

18) 안전담당자가 직접 만들어서 좋았던 점

직접 만들면서 가장 좋았던 점은 사고조사 업무가 어디에서 막히는지 더 선명해졌다는 것입니다. “사고조사 보고서 작성이 어렵다”는 말은 너무 넓습니다. 실제로는 사고 개요를 구조화하는 문제, 추가 질문을 뽑는 문제, 시간 순서로 재구성하는 문제, 직접원인과 근본원인을 분리하는 문제, 5Why를 충분히 깊게 전개하는 문제, 대책을 원인과 연결하는 문제, 위험성평가로 확장하는 문제, 조사표 양식으로 옮기는 문제가 각각 따로 있습니다.

문제를 이렇게 나누면 개선도 쉬워집니다. 보강 질문이 약하면 질문 프롬프트를 고치고, 원인분석이 얕으면 5Why 규칙을 강화하고, 대책이 모호하면 action 작성 지침을 더 구체화하면 됩니다. 화면에서 보기 어렵다면 렌더링 구조를 바꾸면 됩니다. 안전담당자가 직접 도구를 만들면 업무 감각이 바로 수정 요구사항이 됩니다.

또 하나는 “AI 안전관리”라는 말을 현실적으로 보게 된 점입니다. AI는 사고조사를 대신 해주는 조사관이 아닙니다. 하지만 사고조사자가 놓칠 수 있는 질문을 던지고, 흩어진 정보를 구조화하고, 원인과 대책의 연결을 보여주고, 초안을 빨리 만들어 검토 시간을 확보하게 할 수 있습니다. 이 정도만 되어도 실무에서는 충분히 의미가 있습니다.

19) 이 도구를 사용할 때 지켜야 할 기준

첫째, AI 결과는 반드시 현장 조사 자료와 대조해야 합니다. 목격자 진술, CCTV, 작업허가서, TBM 기록, 위험성평가표, 설비 점검 기록, 교육 기록, 보호구 지급 기록 등 실제 근거와 맞지 않는 문장은 삭제하거나 수정해야 합니다. AI가 만든 보고서 문장은 근거자료를 대신하지 못합니다.

둘째, “확인 필요”를 지우기 전에 실제 확인을 해야 합니다. 초안에서 확인 필요가 많이 보이면 보고서 품질이 낮은 것이 아니라 아직 조사할 일이 남아 있다는 뜻입니다. 빈칸을 그럴듯한 문장으로 채우는 것보다, 확인 필요를 남겨두고 담당자를 지정해 확인하는 편이 안전합니다.

셋째, 재발방지대책은 이행관리까지 이어져야 합니다. 보고서에 좋은 대책이 적혀 있어도 담당자, 기한, 예산, 완료 기준, 효과성 확인이 없으면 현장에서 사라질 수 있습니다. 도구가 만든 대책 초안을 실제 조치계획으로 바꾸는 일은 안전담당자와 관리감독자의 몫입니다.

20) 결론: 사고조사 자동화의 목표는 결론 자동 생성이 아니라 검토 가능한 구조화입니다

AI 사고조사 보고서 도우미를 만들면서 얻은 결론은 분명합니다. 사고조사 자동화의 목표는 AI가 사고 원인을 대신 확정하는 것이 아닙니다. 사고 개요와 답변을 바탕으로 확인해야 할 질문을 만들고, 사고 진행을 시간 순서로 쪼개고, 직접원인과 근본원인을 분리하고, 5Why를 끝까지 펼치고, 대책과 위험성평가와 조사표 초안을 같은 구조 안에서 보여주는 것입니다. 즉 자동화의 핵심은 결론이 아니라 구조입니다.

구조가 생기면 검토가 쉬워집니다. 사고 전 요인과 사고 후 대응이 나뉘고, 원인 노드가 표시되고, 직접원인마다 5Why가 붙고, 근본원인마다 대책이 연결되면 담당자는 더 빠르게 틀린 부분을 찾을 수 있습니다. 보고서 초안이 완벽해서가 아니라, 검토할 지도가 생기기 때문입니다.

바이브코딩은 안전담당자에게 이 지도를 직접 만들 수 있는 방법을 줍니다. 업무의 언어를 알고, 반복되는 문서의 구조를 알고, 현장에서 어떤 빈칸이 위험한지 아는 사람이 AI와 코드를 이용해 작은 도구를 만들 수 있습니다. AI 사고조사 보고서 도우미는 아직 계속 다듬어야 할 도구입니다. 하지만 지금 단계에서도 한 가지는 분명합니다. 사고조사 보고서는 빈 문서에서 시작할 필요가 없습니다. 사고 개요에서 질문으로, 질문에서 원인분석으로, 원인분석에서 대책과 위험성평가로 이어지는 구조를 먼저 만들고, 사람은 그 구조 위에서 사실을 확인하고 판단하면 됩니다.