1) 출발점은 “검색 시간이 너무 길다”였습니다

안전관리 업무에서 검색은 부수 업무처럼 보이지만 실제로는 핵심 업무입니다. 신규 작업이 들어오면 관련 법령을 찾아야 하고, 사고 사례를 분석하면 유사한 KOSHA GUIDE를 확인해야 하며, 작업자가 질문하면 현장에서 바로 설명할 수 있는 문장으로 바꿔야 합니다. 문제는 검색 결과가 바로 실무 문장이 되지 않는다는 점입니다. 검색어 하나를 입력해도 조문, 해설, 카드뉴스, 고시, 안내자료, KOSHA GUIDE가 섞여 나오고, 어떤 자료가 법적 의무인지 어떤 자료가 실행 참고자료인지 다시 분류해야 합니다.

특히 현장 질문은 법령 문장처럼 들어오지 않습니다. “사다리 타도 되나요”, “환기구 청소할 때 안전대 꼭 해야 하나요”, “굴착기 집게 아래 잠깐 들어가도 되나요”처럼 생활 언어에 가깝습니다. 담당자는 이 질문을 법령 검색어로 바꿔야 합니다. 사다리는 이동식 사다리인지, 작업발판인지, 고소작업대인지 구분해야 하고, 환기구 청소는 추락 위험인지 밀폐공간인지 도급 작업인지 분리해야 합니다. 이 변환 과정이 매번 사람 머릿속에서만 일어나면 결과가 흔들립니다.

그래서 첫 목표는 거창한 AI 비서가 아니었습니다. 검색어를 조금 더 잘 만들고, 검색 결과를 한 화면에 모으고, 법령과 KOSHA 자료를 같은 흐름에서 볼 수 있게 하는 것이었습니다. 안전담당자의 판단을 대신하는 시스템이 아니라, 판단에 필요한 근거를 빨리 펼쳐 주는 시스템이 필요했습니다. 이 기준이 없었다면 개발은 쉽게 기능 욕심으로 흘렀을 것입니다.

2) 바이브코딩은 감으로 만드는 것이 아니라 업무 언어를 코드로 옮기는 과정이었습니다

바이브코딩이라는 말을 들으면 즉흥적으로 화면을 만들고, AI에게 코드를 던지고, 돌아가는지만 보는 방식처럼 오해할 수 있습니다. 실제로 해보니 핵심은 오히려 반대였습니다. 안전담당자가 이미 알고 있는 업무 언어를 최대한 구체적으로 설명해야 코드가 쓸 만해졌습니다. “법령 검색 만들어줘”라고 하면 흔한 검색창이 나오지만, “산업안전보건법 계열 자료와 KOSHA GUIDE를 검색하고, 법령은 의무로, KOSHA GUIDE는 실행 방법으로 구분해서 보여줘”라고 말하면 설계가 달라집니다.

이번 작업에서 가장 중요했던 프롬프트는 디자인 지시보다 업무 구분이었습니다. 카테고리 1, 2, 3, 4, 8, 9, 11은 법령 자료로 우선 검토하고, 카테고리 5와 7은 고시·예규 또는 KOSHA GUIDE 같은 참고·실행 자료로 다루게 했습니다. 법령 자료에 없는 의무를 KOSHA GUIDE만 보고 새로 만들어내지 않게 했고, 반대로 KOSHA GUIDE의 장점인 구체적인 실행 방법은 법령 기준과 연결해서 쓰게 했습니다. 이 구분이 없으면 AI 분석은 그럴듯하지만 위험한 답변이 됩니다.

바이브코딩에서 안전담당자의 역할은 코드를 전부 손으로 쓰는 것이 아니었습니다. 무엇이 안전관리상 틀린 답인지, 어떤 표현이 현장을 오해하게 만드는지, 어떤 흐름이 담당자의 시간을 줄이는지 계속 판단하는 일이었습니다. 개발자는 아닐 수 있어도 문제의 소유자는 안전담당자입니다. 그래서 이번 시스템은 기술 실험이라기보다 안전관리 업무의 구조를 코드로 번역한 결과에 가깝습니다.

3) 시작 조건은 공공데이터포털 API였습니다

이 도구는 빈 검색창 위에 AI를 얹은 것이 아닙니다. 출발점은 공공데이터포털에서 제공되는 한국산업안전보건공단_안전보건법령 스마트검색 OpenAPI였습니다. 공공데이터포털의 해당 API는 산업안전보건법·령·규칙, 산업안전보건기준에 관한 규칙, 고시·훈령·예규, 중대재해처벌법령, KOSHA GUIDE, 안전보건 미디어 자료, 유해·위험작업의 취업 제한에 관한 규칙 등을 검색할 수 있는 JSON 기반 데이터를 제공합니다. 독자에게 이 전제를 먼저 알려야 합니다. 이 API가 없으면 검색 결과도 없고, 검색 결과가 없으면 AI 분석도 시작할 수 없습니다.

실무적으로는 활용신청, 서비스키 발급, 호출 URL 구성, 응답 필드 확인이 먼저였습니다. 공공데이터 API는 단순한 참고 링크가 아니라 시스템의 원천 데이터입니다. smart-search.html은 사용자의 질문과 필터를 화면에서 받는 역할을 하고, search.php는 서비스키를 서버 안쪽에 숨긴 채 공공데이터 API를 호출합니다. 그리고 응답으로 받은 제목, 카테고리, 문서 ID, 본문 일부, 점수 같은 값을 다시 화면과 AI 분석이 쓰기 좋은 형태로 정리합니다.

이 구조를 글에 넣어야 하는 이유는 분명합니다. 독자는 “AI가 알아서 법령을 찾아주는 도구”라고 오해하면 안 됩니다. 스마트검색은 승인된 공공데이터 API에서 받은 검색 결과를 먼저 보여주고, 그 결과 안에서 AI가 요약과 연결을 돕는 구조입니다. 그래서 신뢰의 출발점은 AI 답변이 아니라 한국산업안전보건공단이 제공하는 공공데이터와 그 데이터를 안정적으로 호출하는 백엔드 흐름입니다.

4) 첫 화면은 화려한 설명보다 바로 검색할 수 있어야 했습니다

스마트검색 화면은 처음부터 블로그 랜딩페이지처럼 만들지 않았습니다. 사용자는 이 페이지에 도착했을 때 서비스 소개문을 읽으러 오는 것이 아니라, 지금 필요한 기준을 찾으러 옵니다. 그래서 상단에는 “안전보건법령 스마트검색”이라는 기능명이 바로 보이게 하고, 바로 아래에 검색어, 카테고리, 표시 개수, 검색 버튼을 배치했습니다. 설명은 짧게 두고, 실제 행동을 먼저 할 수 있게 했습니다.

카테고리는 전체 검색을 기본으로 두되, 미디어 성격의 6번 카테고리는 전체 검색에서 제외했습니다. 안전담당자가 실무 근거를 찾을 때 이미지나 홍보성 자료가 먼저 섞이면 판단 속도가 떨어지기 때문입니다. 물론 특정 자료가 필요할 때는 카테고리를 따로 선택할 수 있지만, 기본값은 법령과 실무 기준 중심이어야 했습니다. 검색 결과 수는 100개, 300개, 500개, 1000개로 조절할 수 있게 했습니다. 현장에서는 빠른 확인이 필요할 때도 있고, 기준을 넓게 훑어야 할 때도 있기 때문입니다.

PC 화면에서는 결과를 표로 보여줍니다. 번호, 카테고리, 제목, 문서 ID, 점수, 본문 미리보기를 한 줄 흐름으로 비교할 수 있어야 하기 때문입니다. 반면 모바일에서는 같은 표가 오히려 방해가 됩니다. 그래서 모바일에서는 카드형 결과로 전환되게 했습니다. 안전담당자는 사무실 모니터에서만 일하지 않습니다. 현장 이동 중에도 검색하고, 회의실에서도 검색하고, 작업 전 TBM 자리에서도 휴대폰으로 확인합니다. 화면 구조는 이 사용 환경을 따라가야 했습니다.

5) 질문형 문장을 검색어 후보로 바꾸는 기능이 생각보다 중요했습니다

검색창에 “사다리 기준”처럼 짧은 단어만 넣는 사용자는 많지 않습니다. 실제 사용자는 “사다리에서 작업해도 되나요”, “지게차 후진할 때 신호수 기준 알려줘”, “밀폐공간 산소농도 측정은 어떻게 하나요”처럼 질문형 문장을 넣습니다. 검색 API가 이런 문장을 그대로 잘 처리하면 좋겠지만, 법령 검색에서는 핵심 명사와 행위 단어가 더 중요합니다. 그래서 프론트엔드에서 질문을 정리해 검색 후보를 만들어 주도록 했습니다.

구현 방식은 복잡한 자연어 처리 모델이 아니라 실무적으로 충분한 전처리였습니다. 물음표와 따옴표 같은 문장부호를 제거하고, “무엇”, “알려줘”, “인가요”, “해야”, “관련” 같은 검색 효율이 낮은 표현을 제외했습니다. 그리고 조사와 어미를 가볍게 제거해 핵심 단어를 남겼습니다. 예를 들어 “사다리에서 작업해도 되나요”는 “사다리 작업” 또는 “사다리” 같은 후보로 바뀔 수 있습니다. 이 후보는 화면에 칩 형태로 보여 주고, 사용자가 직접 눌러 검색할 수 있게 했습니다.

이 기능은 작아 보이지만 현장 사용성에는 큰 차이를 만듭니다. 안전담당자는 법령 검색 전문가일 수 있지만, 모든 사용자가 그렇지는 않습니다. 협력업체 담당자나 현장관리자는 질문을 자연어로 입력할 가능성이 큽니다. 시스템이 질문을 검색 가능한 단위로 정리해 주면, 사용자는 검색어를 고치느라 시간을 쓰지 않고 바로 결과를 비교할 수 있습니다. 바이브코딩의 장점은 이런 작은 불편을 빠르게 기능으로 바꿔 볼 수 있다는 데 있었습니다.

6) 백엔드 프록시는 선택이 아니라 운영상 필수였습니다

처음에는 프론트엔드에서 공공데이터포털 API를 바로 호출하는 방식도 생각할 수 있습니다. 하지만 실제 운영을 생각하면 브라우저에서 직접 외부 API를 때리는 구조는 불안합니다. 서비스키가 노출될 수 있고, CORS, 오류 메시지, 타임아웃, 검색어 검증, 호출 제한, 응답 정규화 같은 문제가 생깁니다. 그래서 search.php를 두고 서버가 검색 요청을 대신 처리하게 했습니다. 이 파일은 단순 중계가 아니라 공공데이터 API를 실무 도구로 바꾸는 관문 역할을 합니다.

search.php는 GET 요청만 받게 하고, 검색어는 2자 이상 80자 이하로 제한했습니다. 카테고리는 허용된 값만 통과시키고, 표시 개수는 최대 1000개로 묶었습니다. 한국산업안전보건공단 안전보건법령 스마트검색 API 호출은 일정 시간 안에 끝나도록 타임아웃을 두었고, 응답이 JSON이 아니거나 HTTP 오류가 발생하면 사용자에게 이해 가능한 메시지를 돌려주도록 했습니다. 전체 검색에서는 기본적으로 6번 카테고리를 제외하고, 결과는 점수 순으로 정렬한 뒤 필요한 필드만 정리했습니다.

이런 제한은 사용자를 괴롭히기 위한 것이 아닙니다. 안전관리 도구는 안정적으로 동작해야 합니다. 검색어 하나가 너무 길거나, 잘못된 카테고리 값이 들어오거나, 공공데이터 API가 느려졌다고 전체 화면이 망가지면 실무 도구로 신뢰를 얻기 어렵습니다. 백엔드 프록시는 서비스키를 보호하고, API 응답을 화면과 AI가 다루기 좋은 데이터로 바꾸며, 실패했을 때도 사용자가 다음 행동을 판단할 수 있게 만드는 운영 장치였습니다.

7) AI 분석은 검색 뒤에 붙인 장식이 아니라 근거 정리 엔진입니다

검색 결과가 많아지면 또 다른 문제가 생깁니다. 500개 결과가 보인다고 해서 담당자의 일이 바로 줄어드는 것은 아닙니다. 오히려 중요한 자료를 골라야 하는 부담이 생깁니다. 그래서 AI 분석 기능을 붙였습니다. 다만 여기서 중요한 원칙을 세웠습니다. AI가 인터넷에서 새 지식을 가져와 답하는 것이 아니라, 검색 결과 원문 JSON 안에 들어 있는 내용만 근거로 삼게 했습니다. 안전보건 법령과 기준을 다루는 도구에서 출처 없는 상상은 기능이 아니라 위험입니다.

smart_search_analyze.php는 검색 결과 중 법령 카테고리와 일정 점수 이상의 참고자료를 추려 AI 입력으로 보냅니다. 항목 수와 항목당 텍스트 길이를 제한해 응답 속도와 비용을 관리하고, 프롬프트에는 분석 원칙을 명확히 넣었습니다. 법령 자료는 누락하지 말고 우선 검토하도록 했고, KOSHA GUIDE나 고시·예규는 법령 의무를 새로 만들지 않는 실행 방법으로 연결하도록 했습니다. 출력도 자유 문장이 아니라 JSON 객체로 강제했습니다.

AI 출력 구조는 answer, legal_points, law_kosha_links, solution_plan, practical_checklist, references, cautions로 나누었습니다. 이 구조는 안전담당자의 업무 흐름과 맞춰져 있습니다. 먼저 요약을 읽고, 핵심 법령 근거를 보고, KOSHA 실행 기준과 연결한 다음, 현장 문제해결 방안과 체크리스트로 옮깁니다. 마지막으로 주의사항을 확인합니다. 즉 AI 분석은 “멋진 설명”이 아니라 회의자료, TBM, 위험성평가, 작업허가 검토로 가져갈 수 있는 중간 산출물입니다.

8) 법령과 KOSHA GUIDE를 섞지 않는 것이 가장 중요한 품질 기준이었습니다

안전보건 자료를 다룰 때 가장 흔한 오류는 법적 의무와 권고 기준을 한 문장으로 섞는 것입니다. KOSHA GUIDE는 매우 유용한 실행 자료이지만 모든 문장이 곧바로 법적 의무가 되는 것은 아닙니다. 반대로 법령은 의무의 뼈대를 제시하지만, 현장에서 어떤 순서와 표로 관리할지는 별도 실행 기준이 필요합니다. 이 둘을 구분하지 않으면 답변은 강해 보이지만 실제 검토에서는 취약해집니다.

그래서 AI 프롬프트에는 상위 법령 우선 원칙과 참고자료 표시 원칙을 넣었습니다. 법령 자료와 KOSHA GUIDE가 같은 주제를 다루면 “법령상 요구 기준 → KOSHA GUIDE상 구체 실행 방법 → 현장 조치”의 순서로 연결하게 했습니다. 법령 근거가 없고 참고자료만 있는 내용은 “참고자료 기준” 또는 “실무상 권고”로 구분하게 했습니다. 수치, 거리, 높이, 시간, 점검 주기, 금지행위가 원문에 있으면 빠뜨리지 말고 그대로 반영하게 한 것도 같은 이유입니다.

이 기준은 기술보다 안전관리의 태도에 가깝습니다. 현장에서 담당자는 “이거 법에 있어요?”라는 질문을 자주 받습니다. 그때 법령 기준과 실무 권고를 구분해 말할 수 있어야 합니다. 스마트검색의 AI 분석이 담당자를 대신해 최종 판단을 내리는 것은 아니지만, 적어도 처음부터 구분된 재료를 제공하면 담당자의 검토 품질은 훨씬 좋아집니다.

9) AI 분석 대기 토큰은 응답 크기와 운영 안정성 때문에 넣었습니다

처음에는 검색 요청과 AI 분석을 한 번에 처리하는 구조를 생각했습니다. 그러나 검색 결과가 많고 AI 분석까지 붙으면 응답이 오래 걸릴 수 있습니다. 사용자는 검색 결과라도 먼저 보고 싶을 때가 있고, 서버는 분석용 데이터를 안전하게 전달해야 합니다. 그래서 search.php에는 prepareAnalysis 옵션을 두었습니다. 검색 결과를 만든 뒤 AI 분석에 쓸 원문을 임시 캐시에 저장하고, 짧은 토큰을 발급합니다. 프론트엔드는 이 토큰을 가지고 다시 analyze 모드로 요청합니다.

이 방식은 사용자 경험과 서버 운영을 동시에 고려한 절충이었습니다. 검색 결과는 먼저 렌더링하고, AI 분석은 이어서 로딩 모달로 상태를 보여주며 처리합니다. 분석용 캐시는 일정 시간이 지나면 만료되게 했고, 토큰 형식도 제한했습니다. 만료된 토큰이나 잘못된 토큰은 명확한 오류로 처리합니다. 이런 장치는 눈에 띄는 기능은 아니지만, 실제 서비스에서는 중요합니다. 도구가 오래 쓰이려면 성공 흐름보다 실패 흐름이 더 단단해야 합니다.

안전관리 시스템도 마찬가지입니다. 평소에는 체크리스트 하나가 간단해 보여도, 예외 상황에서 어떻게 멈추고, 누구에게 알리고, 어떤 기준으로 재개할지가 품질을 결정합니다. 스마트검색의 백엔드도 같은 관점으로 만들었습니다. 검색 성공만 바라보지 않고, 실패했을 때 사용자가 무엇을 알 수 있는지, 서버가 얼마나 버틸 수 있는지, 다음 요청이 어떻게 이어지는지를 함께 봤습니다.

10) 화면 디자인은 안전관리 문서를 읽는 방식에 맞췄습니다

스마트검색 원본 페이지의 디자인은 진한 남색 상단바, 흰색 검색 패널, 정돈된 표와 카드, 상태 메시지, 로딩 모달로 구성했습니다. 색상은 과하게 튀지 않게 잡았습니다. 안전관리 도구는 화려한 마케팅 페이지보다 반복 사용에 견디는 화면이어야 합니다. 사용자는 매일 검색하고, 비교하고, 복사하고, 회의자료로 옮깁니다. 그래서 버튼과 입력창은 작동이 분명해야 하고, 결과 표는 오래 봐도 피로하지 않아야 합니다.

상단에는 블로그와 AI 위험성평가로 이동하는 링크를 두었지만, 검색 흐름을 방해하지 않게 했습니다. 검색 패널 아래에는 후보 검색어와 자동 재검색 옵션을 배치했습니다. 결과가 없을 때 다음 후보를 자동으로 시도할 수 있게 한 이유는 질문형 검색어가 한 번에 맞지 않을 수 있기 때문입니다. 다만 호출이 추가된다는 점을 사용자가 선택하도록 했습니다. 자동화는 편리하지만, API 호출이 늘어나는 기능은 사용자가 알 수 있어야 합니다.

결과 화면에는 카테고리별 건수 버튼을 두었습니다. 전체 결과를 본 뒤 “KOSHA GUIDE만 보자”, “안전보건기준규칙만 보자”처럼 좁혀 볼 수 있어야 하기 때문입니다. 모바일에서는 같은 기능을 드롭다운으로 바꿨습니다. 현장에서는 작은 화면에서 긴 버튼 묶음이 불편합니다. 디자인은 예쁜 화면을 만드는 일이 아니라, 사용자의 실제 손동작을 덜 피곤하게 만드는 일이라는 것을 이번 작업에서 다시 느꼈습니다.

11) 개발 과정에서 가장 조심한 것은 “그럴듯한 답변”이었습니다

AI 기능을 붙이면 시연은 쉬워집니다. 검색어를 넣고 멋진 문장으로 요약되면 시스템이 똑똑해 보입니다. 하지만 안전보건 분야에서는 그럴듯함이 가장 위험할 수 있습니다. 현장 담당자가 AI 문장을 그대로 믿고 조치 기준을 만들었는데, 원문에는 없는 의무나 수치가 들어가 있다면 문제가 됩니다. 그래서 프롬프트의 첫 원칙은 “검색 원문 JSON에 포함된 내용만 근거로 사용하라”였습니다.

또한 출력에는 cautions를 반드시 두었습니다. 해석상 한계, 적용 범위, 추가 확인이 필요한 사항을 별도로 쓰게 했습니다. 법령 검색은 늘 맥락이 필요합니다. 같은 “사다리”라도 작업 높이, 작업 지속 시간, 바닥 상태, 사다리 종류, 보호구, 대체 작업발판 가능성에 따라 판단이 달라질 수 있습니다. AI가 모든 상황을 알 수 없기 때문에 주의사항 영역은 단순한 부록이 아니라 안전장치입니다.

스마트검색은 최종 법률 자문 도구가 아닙니다. 담당자가 근거를 찾고, 원문을 확인하고, 현장 조건에 맞게 판단하도록 돕는 도구입니다. 그래서 글이나 화면에서 이 한계를 숨기지 않는 편이 좋습니다. 도구의 한계를 명확히 말해야 사용자가 올바르게 씁니다. 안전관리에서 가장 위험한 도구는 부족한 도구가 아니라, 부족함을 숨기는 도구입니다.

12) 구현 구조를 안전관리 언어로 다시 보면 이렇습니다

개발을 하다 보면 파일명과 함수명에 시야가 갇히기 쉽습니다. 하지만 안전담당자 입장에서는 각 파일이 업무에서 어떤 역할을 하는지 계속 번역해야 합니다. 공공데이터포털 API는 원천 데이터이고, smart-search.html은 화면이며, search.php는 검색 관문이고, smart_search_analyze.php는 해석 보조자입니다. 이렇게 역할을 분리하니 수정할 때도 판단이 쉬웠습니다. 화면 문제가 생기면 프론트엔드를 보고, 검색 응답 문제가 생기면 프록시와 API 응답을 보고, AI 답변 품질 문제는 프롬프트와 입력 선별을 봅니다.

13) 보안과 운영은 작은 프로젝트에서도 건너뛸 수 없었습니다

개인이나 소규모 팀이 만든 도구라고 해서 보안과 운영을 대충 볼 수는 없습니다. search.php에는 공공데이터포털 API 서비스키를 둘 수 있는 구조가 있지만, 운영에서는 환경변수 사용을 우선하도록 했습니다. AI 분석도 Gemini API 키를 환경변수에서 읽고, 여러 키가 있을 때 순차적으로 시도할 수 있게 했습니다. 공개 저장소나 글에는 실제 키를 노출하지 않아야 하며, 화면에서도 키나 내부 설정을 보여주지 않아야 합니다.

CORS도 필요한 출처만 허용하는 방향으로 구성했습니다. 검색 프록시는 hseteam.kr 계열과 운영에 필요한 출처를 중심으로 허용하고, AI 분석 쪽은 개발 중 로컬 테스트 출처도 고려했습니다. 요청 방식도 GET, POST, OPTIONS, HEAD를 용도에 맞게 제한했습니다. 입력 본문 크기 제한, 검색어 길이 제한, AI 분석 항목 수 제한도 같은 맥락입니다. 작은 제한들이 모여 서비스의 남용 가능성을 줄입니다.

로그도 중요했습니다. AI 분석이 실패했을 때 단순히 “안 됩니다”로 끝나면 원인을 알 수 없습니다. 그래서 분석 모듈에는 요청 방식, URI, Origin, 원격 주소, 오류 수준과 메시지를 기록하는 로깅 흐름을 넣었습니다. 다만 로그에는 민감한 내용을 과도하게 남기지 않는 것이 좋습니다. 안전관리 도구도 결국 사용자 입력과 API 응답을 다루기 때문에, 운영 편의와 개인정보·보안 사이의 균형을 잡아야 합니다.

14) 이 도구가 현장에서 특히 유용한 순간

첫 번째는 TBM 전 질문 정리입니다. 작업 전 회의에서 “오늘 작업과 관련된 기준이 뭐냐”는 질문이 나오면 담당자는 스마트검색에 핵심 작업어를 넣어 관련 법령과 KOSHA GUIDE를 빠르게 훑을 수 있습니다. 예를 들어 “사다리 기준”, “밀폐공간 환기”, “굴착기 작업반경”, “지게차 후진”, “추락방지망 해체” 같은 검색어로 법령과 실행 가이드를 함께 확인할 수 있습니다. 외부 법령 사이트를 여러 개 열 필요 없이 스마트검색에서 먼저 방향을 잡을 수 있습니다.

두 번째는 사고 사례 글을 작성할 때입니다. 사망사고 분석 글을 쓰려면 사고 경로, 법령 기준, KOSHA GUIDE, 현장 체크리스트가 필요합니다. 기존에는 자료를 찾는 데 시간이 오래 걸렸고, 한 조문에서 찾은 가이드를 다른 조문에 관성적으로 재사용하는 위험도 있었습니다. 스마트검색은 매번 검색어를 기준으로 다시 후보를 확인하게 하므로, 사고 유형별로 더 적합한 기준을 찾는 데 도움이 됩니다.

세 번째는 협력업체와의 소통입니다. 협력업체 담당자가 “왜 이것까지 해야 하냐”고 물을 때, 담당자는 막연히 “법에 있습니다”라고 말하기보다 검색 결과를 바탕으로 법령 기준과 실행 방법을 나눠 설명할 수 있습니다. 법령은 의무의 근거로, KOSHA GUIDE는 방법의 근거로 보여 주면 설득이 쉬워집니다. 안전관리의 많은 갈등은 기준이 없어서가 아니라 기준이 제대로 전달되지 않아서 생깁니다.

15) 바이브코딩으로 가능했던 속도와, 반드시 사람이 봐야 했던 품질

이번 작업에서 바이브코딩의 장점은 속도였습니다. 검색창, 카테고리 선택, 후보 칩, 표 렌더링, 모바일 카드, 로딩 모달, PHP 프록시, AI 분석 프롬프트를 짧은 주기로 만들고 고칠 수 있었습니다. 예전 같으면 개발자에게 요구사항을 정리해 전달하고, 결과를 기다리고, 다시 설명하고, 다시 수정하는 사이에 의욕이 떨어졌을 것입니다. 지금은 안전담당자가 직접 흐름을 보고 바로 수정 방향을 잡을 수 있었습니다.

하지만 속도가 품질을 대신하지는 않았습니다. 특히 법령과 안전 기준을 다루는 부분은 사람이 끝까지 확인해야 했습니다. AI가 만든 코드가 돌아간다고 해서 업무적으로 맞는 것은 아닙니다. 예를 들어 카테고리 6번 미디어를 전체 검색에서 제외하는 판단, 법령 카테고리를 우선 분석하는 판단, KOSHA GUIDE를 법적 의무처럼 쓰지 못하게 하는 판단은 안전관리자의 검토가 있어야 나옵니다. 코드가 맞는지와 업무가 맞는지는 다른 문제입니다.

그래서 이 프로젝트의 교훈은 “안전담당자도 개발자가 될 수 있다”가 아니라 “안전담당자는 개발 과정에서 더 적극적인 제품 책임자가 될 수 있다”에 가깝습니다. 어떤 결과가 현장에 도움이 되는지 가장 잘 아는 사람은 현장 업무를 하는 사람입니다. AI와 코드는 그 사람의 판단을 빠르게 구현하는 도구입니다. 방향을 잡는 사람은 여전히 업무 담당자입니다.

16) 검색 결과를 그대로 믿지 않고 다시 검토하는 절차

스마트검색을 만들었다고 해서 원문 검토가 사라지는 것은 아닙니다. 오히려 원문 검토가 더 쉬워져야 합니다. 검색 결과의 제목, 문서 ID, 본문 미리보기, 점수를 보고 관련 자료를 좁힌 뒤, 최종적으로는 원문을 확인해야 합니다. 스마트검색은 “어디를 볼지”를 빠르게 알려주는 도구이지, 모든 법적 판단을 자동 확정하는 장치가 아닙니다.

특히 AI 분석 결과는 초안으로 봐야 합니다. answer는 방향을 잡는 요약이고, legal_points는 검토할 법령 포인트이며, law_kosha_links는 연결 후보입니다. 담당자는 이 내용을 그대로 복사하기보다 현장 조건에 맞게 다듬어야 합니다. 작업 높이, 장비 종류, 도급 구조, 작업자 숙련도, 작업 장소, 유해위험요인, 기존 안전조치 여부에 따라 최종 문장은 달라질 수 있습니다.

이 절차는 글 작성에도 그대로 적용됩니다. 블로그 글에서 특정 법령이나 KOSHA GUIDE를 언급할 때는 검색 결과와 AI 분석을 출발점으로 삼되, 최종 문장에서는 원문 근거와 적용 범위를 다시 확인해야 합니다. 안전 글은 검색 노하우를 보여주는 콘텐츠가 아니라, 독자가 현장에서 오해 없이 쓸 수 있는 기준을 제공해야 합니다.

17) 사용 흐름 예시

이 흐름에서 중요한 것은 검색과 분석과 판단을 분리하는 것입니다. 검색은 공공데이터 API에서 자료를 찾는 단계이고, AI 분석은 그 자료를 정리하는 단계이며, 최종 판단은 담당자의 업무입니다. 세 단계를 섞으면 편해 보이지만 위험합니다. 세 단계를 분리하면 조금 더 느려 보일 수 있지만, 실제로는 재검토와 설명 시간이 줄어 전체 업무가 빨라집니다.

18) 개발하면서 느낀 안전관리 디지털 전환의 현실

안전관리 디지털 전환은 거창한 플랫폼 도입만을 의미하지 않습니다. 매일 반복하는 검색, 복사, 정리, 요약, 체크리스트 작성 시간을 줄이는 것도 충분히 중요한 전환입니다. 현장 담당자가 가장 자주 하는 일을 조금 더 정확하고 빠르게 만들면 그 효과는 바로 나타납니다. 스마트검색은 대형 시스템은 아니지만, 담당자의 하루에서 반복되는 작은 마찰을 줄이는 도구입니다.

또 하나 느낀 점은 안전관리 도구는 업무 맥락 없이는 만들기 어렵다는 것입니다. 일반 검색창은 누구나 만들 수 있지만, 법령 자료와 KOSHA GUIDE를 어떻게 구분할지, 전체 검색에서 어떤 카테고리를 제외할지, AI가 어떤 말투와 구조로 답해야 현장에서 쓸 수 있을지는 안전 업무를 알아야 정할 수 있습니다. 그래서 안전담당자가 바이브코딩에 참여하는 것은 단순 취미가 아니라 업무 품질을 높이는 방법이 될 수 있습니다.

물론 모든 안전담당자가 코드를 직접 운영해야 한다는 뜻은 아닙니다. 중요한 것은 문제를 정확히 설명하고, 결과물을 검토하고, 업무에 맞게 반복 개선하는 역량입니다. AI 도구가 좋아질수록 “개발을 맡기는 사람”과 “개발을 이해하며 지휘하는 사람”의 차이는 커질 것입니다. 안전담당자도 이제 자신이 쓰는 도구의 구조를 어느 정도 이해해야 합니다.

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

첫째, 검색 결과의 원문 연결성을 더 강화하고 싶습니다. 지금은 검색 결과를 정리해 보여주고 AI 분석까지 연결하지만, 각 결과가 실제 원문 확인으로 더 부드럽게 이어지면 좋습니다. 다만 직접 외부 링크를 무분별하게 늘리기보다, 사용자가 스마트검색 안에서 다시 검색하고 검토할 수 있는 흐름을 우선 유지하려 합니다. 외부 자료는 계속 바뀌고, 링크 구조도 달라질 수 있기 때문입니다.

둘째, 검색어 후보 생성 로직을 더 똑똑하게 만들 수 있습니다. 지금은 조사 제거와 불용어 제거 중심이지만, 안전보건 분야의 동의어 사전을 붙이면 훨씬 좋아집니다. 예를 들어 “집게”, “그래플”, “압쇄기”, “어태치먼트”처럼 현장에서 섞어 쓰는 말을 묶거나, “사다리”와 “이동식 사다리”, “작업발판”을 상황에 따라 구분하는 방식입니다. 이 작업은 단순 기술보다 안전 용어 정리가 필요합니다.

셋째, AI 분석 결과를 위험성평가 문장, TBM 질문, 작업허가 체크리스트 형식으로 바로 변환하는 기능도 생각해볼 수 있습니다. 이미 출력 구조에 solution_plan과 practical_checklist가 있으므로 확장 가능성은 있습니다. 다만 이 기능을 붙일 때도 원칙은 같아야 합니다. 원문 근거 없는 기준을 만들지 않고, 법령 의무와 실행 권고를 구분하며, 최종 검토는 담당자에게 남겨야 합니다.

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

직접 만들면서 가장 좋았던 점은 업무의 불편을 더 이상 추상적으로 말하지 않아도 된다는 것이었습니다. “검색이 불편하다”는 말은 너무 넓습니다. 하지만 코드를 만들다 보면 불편이 쪼개집니다. 질문형 문장이 검색어로 잘 안 바뀐다, 카테고리 구분이 어렵다, 결과가 PC와 모바일에서 다르게 보여야 한다, AI가 법령과 KOSHA를 섞는다, 응답이 느릴 때 사용자가 기다리는 상태를 알아야 한다. 이렇게 쪼갠 문제는 해결할 수 있습니다.

또한 개발을 하면서 안전관리 문서 작성 방식도 선명해졌습니다. 좋은 안전 문서는 검색 결과를 많이 모은 문서가 아니라, 근거의 성격을 구분하고 현장 행동으로 바꾼 문서입니다. 스마트검색을 만들면서 이 구조를 코드에도 넣고, 글에도 넣고, 사고 분석에도 넣게 되었습니다. 도구를 만드는 과정이 업무 기준을 다시 정리하는 과정이 된 셈입니다.

마지막으로, 작은 성공이 다음 개선을 부릅니다. 처음에는 검색창 하나가 목표였지만, 만들고 보니 AI 분석이 필요했고, AI 분석을 붙이니 프롬프트 원칙이 필요했고, 프롬프트를 만들다 보니 법령과 KOSHA 구분 기준이 더 중요해졌습니다. 바이브코딩은 완성품을 한 번에 만드는 방식이라기보다, 업무 감각을 바탕으로 계속 다듬는 방식에 가까웠습니다.

21) 이 도구를 쓰는 안전담당자에게 남기고 싶은 기준

스마트검색을 사용할 때는 세 가지 기준을 기억하면 좋겠습니다. 첫째, 검색어는 짧고 구체적으로 시작하는 것이 좋습니다. “추락방지망 해체”, “밀폐공간 환기”, “지게차 후진”, “굴착기 작업반경”처럼 기인물과 행위를 같이 넣으면 결과가 더 실무적으로 나옵니다. 질문형 문장을 넣어도 후보가 만들어지지만, 핵심 단어를 직접 고르는 습관은 여전히 중요합니다.

둘째, 카테고리를 바꿔 가며 보아야 합니다. 전체 검색에서 방향을 잡고, 안전보건기준규칙이나 KOSHA GUIDE처럼 필요한 자료군으로 좁혀 보십시오. 법령 기준을 먼저 확인하고, 그다음 실행 가이드를 보는 순서가 좋습니다. 이 순서가 바뀌면 권고 기준을 법적 의무로 오해할 수 있습니다.

셋째, AI 분석은 초안으로 쓰되 원문 확인을 생략하지 마십시오. AI가 정리한 체크리스트가 좋아 보여도, 실제 현장 조건과 법령 원문이 맞는지 확인해야 합니다. 안전관리에서 자동화는 판단을 없애는 것이 아니라 판단 전에 자료를 정돈하는 일입니다. 이 차이를 지키면 스마트검색은 위험한 자동 답변기가 아니라 유용한 실무 보조자가 됩니다.

22) 결론: 안전담당자의 바이브코딩은 현장 문제를 제품으로 바꾸는 방법입니다

안전보건법령 스마트검색을 만들면서 느낀 가장 큰 변화는 “이런 기능이 있으면 좋겠다”에서 멈추지 않게 되었다는 점입니다. 예전에는 불편한 점을 발견해도 언젠가 누군가 만들어주기를 기다렸습니다. 이제는 문제를 문장으로 정리하고, AI와 함께 초안을 만들고, 직접 검토하고, 업무 기준에 맞게 고칠 수 있습니다. 이것이 안전담당자에게 바이브코딩이 주는 실질적인 힘입니다.

물론 코드가 모든 것을 해결하지는 않습니다. 법령 해석은 여전히 신중해야 하고, 현장 판단은 담당자가 책임져야 하며, AI 답변은 검토되어야 합니다. 그러나 반복 검색과 자료 정리의 부담을 줄이면 담당자는 더 중요한 일에 시간을 쓸 수 있습니다. 위험요인을 더 깊게 보고, 작업자에게 더 잘 설명하고, 사고 예방 문장을 더 구체적으로 만들 수 있습니다.

스마트검색은 완성된 끝점이 아니라 계속 다듬어야 할 도구입니다. 하지만 지금 단계에서도 한 가지는 분명합니다. 안전담당자가 자신의 업무 언어를 정확히 알고 있다면, 바이브코딩은 그 언어를 실제 작동하는 시스템으로 바꾸는 강력한 방법이 될 수 있습니다. 안전관리의 디지털 전환은 먼 곳에 있는 대형 프로젝트만이 아닙니다. 오늘 반복해서 찾던 법령 기준을 더 빨리, 더 정확하게, 더 현장답게 찾는 것에서 시작할 수 있습니다.