업무 자동화 도구에 AI 검색을 붙일 때 피해야 할 설계
내가 만든 HTML 업무도구에 AI 검색을 붙이는 현실적인 방법
AI에게 업무용 프로그램을 만들어 달라고 하면 생각보다 빠르게 결과물이 나옵니다. 엑셀이나 CSV 파일을 불러오고, 조건에 맞는 항목을 찾고, 결과를 표로 보여주는 HTML 도구 정도는 코딩을 깊게 알지 않아도 만들 수 있습니다. 파일 하나를 더블클릭하면 브라우저에서 바로 실행되기 때문에 별도 설치 없이 쓸 수 있다는 장점도 있습니다.
그런데 이런 도구를 실제 업무에 쓰다 보면 자연스럽게 다음 단계가 떠오릅니다. 원장이나 거래내역을 검토한 결과 옆에서 회사 규정, 매뉴얼, PDF 근거까지 찾아주는 AI를 붙일 수는 없을까 하는 생각입니다. 결론부터 말하면 가능합니다. 다만 HTML 파일 안에 채팅창 하나를 추가한다고 끝나는 일은 아닙니다.
핵심은 역할 분리입니다. 기존 HTML 도구는 숫자와 조건을 빠르게 검사하고, AI 검색 서버는 관련 문서와 근거를 찾아 설명합니다. 두 기능을 억지로 하나의 HTML 파일에 모두 넣기보다, 각각 잘하는 일을 나누는 구조가 훨씬 안정적입니다.
기존 HTML 도구가 잘하는 일부터 구분해야 합니다
HTML로 만든 업무도구는 정해진 규칙을 빠르게 적용하는 데 강합니다. 특정 계정이나 코드를 필터링하고, 금액 기준 이상 항목을 추출하고, 중복이나 누락을 찾고, 결과를 표로 정리하는 작업은 규칙 기반 로직이 더 안정적입니다.
📋 HTML 도구가 맡기 좋은 업무
- 특정 계정과목, 거래처, 코드 필터링
- 금액 기준 이상 거래 추출
- 중복, 누락, 비정상 조합 탐지
- 결과 집계와 표 출력
- 사람이 검토할 항목의 우선순위 지정
이런 작업까지 LLM에게 맡길 필요는 없습니다. 조건이 명확한 검토를 AI에게 넘기면 결과가 매번 조금씩 달라질 수 있고, 처리 시간과 비용도 늘어납니다. 이미 잘 작동하는 원장검토 로직이 있다면 그대로 유지하는 편이 좋습니다.
AI가 맡아야 할 일은 해석과 근거 검색입니다
AI가 유용한 지점은 정답이 하나로 고정되지 않은 업무입니다. 예를 들어 적요와 거래내용을 읽고 의미를 설명하거나, 이상 항목이 발생한 원인 가설을 제시하거나, 관련 규정과 매뉴얼을 찾아 요약하는 일입니다.
💡 Tip: 숫자와 조건을 검사하는 일은 기존 HTML 도구가 맡고, 그 결과를 해석하거나 관련 문서 근거를 찾는 일은 AI가 맡는 구조가 가장 자연스럽습니다.
예를 들어 HTML 도구가 “복리후생비 중 일정 금액 이상인 거래”를 찾아냈다면, AI는 해당 거래의 적요를 읽고 관련 내부 규정이나 증빙 기준을 검색해줄 수 있습니다. 이때 AI가 원장을 직접 최종 판단하는 것이 아니라, 사람이 판단할 수 있도록 근거를 찾아주는 보조 역할을 하는 것이 중요합니다.
가장 현실적인 구조는 HTML과 AI 검색 서버를 분리하는 것입니다
기존 HTML 안에 PDF 업로드, 벡터 검색, AI 답변 기능을 모두 넣고 싶어질 수 있습니다. 하지만 브라우저에서 실행되는 파일 하나에 모든 기능을 담으면 여러 문제가 생깁니다. 대용량 PDF 처리 속도가 느려지고, API 키나 내부 설정이 화면 코드에 노출될 수 있으며, 여러 사용자가 같은 지식베이스를 공유하기도 어렵습니다.
이 구조를 쓰면 사용자는 화면을 옮겨 다니지 않고도 검토 결과 옆에서 관련 근거를 확인할 수 있습니다. 동시에 PDF 처리, 검색 규칙, 프롬프트, 접근권한 같은 민감한 로직은 서버 쪽에서 관리할 수 있습니다.
실제 동작 흐름은 이렇게 설계할 수 있습니다
사용자가 HTML 화면에서 특정 거래를 선택하고 “이 항목과 관련된 내부 규정을 찾아줘” 버튼을 누른다고 가정해보겠습니다. 이때 HTML은 거래의 계정명, 적요, 금액, 사용자가 입력한 질문을 문서검색 서버로 보냅니다.
✅ 예시 흐름
서버는 질문을 임베딩으로 변환하고, 벡터DB에서 의미가 가까운 규정 문단을 찾습니다. 필요한 경우 계정명이나 문서 유효기간 같은 키워드 조건을 추가로 확인합니다. 이후 검색된 원문과 질문을 Ollama 같은 로컬 LLM에 전달하고, 답변·문서명·페이지·원문을 HTML 화면에 돌려줍니다.
여기서 중요한 점은 AI가 원장을 직접 판정하지 않는다는 것입니다. AI는 원장검토 결과를 바탕으로 필요한 근거를 검색하고 설명합니다. 최종 판단은 사용자가 원문과 회사 기준을 확인한 뒤 내리는 구조가 안전합니다.
HTML에서 Ollama를 직접 호출하는 방식은 신중해야 합니다
개인 PC에서 시험하는 수준이라면 HTML의 자바스크립트가 localhost의 Ollama API를 직접 호출하도록 만들 수도 있습니다. 로컬 실험에서는 빠르게 구조를 확인할 수 있다는 장점이 있습니다. 그러나 실제 업무용이라면 중간 서버를 두는 편이 훨씬 낫습니다.
⚠️ 중요: 브라우저에서 실행되는 HTML은 사용자가 소스를 확인할 수 있습니다. API 키, 시스템 프롬프트, 내부 검색 규칙, 민감한 설정값을 HTML 안에 직접 넣어서는 안 됩니다.
중간 서버를 두면 프롬프트와 검색 규칙을 숨길 수 있고, 사용자별 접근권한을 검사할 수 있으며, 질문과 답변 기록도 관리할 수 있습니다. 또한 모델이나 검색 방식을 바꾸더라도 HTML 파일을 크게 수정하지 않아도 됩니다. 처음에는 Python FastAPI처럼 가벼운 서버로 질문을 받고 JSON으로 답을 돌려주는 정도면 충분합니다.
화면에는 답변보다 근거를 함께 보여줘야 합니다
업무도구에서 AI 답변만 크게 보여주면 사용자는 그 문장을 사실로 받아들이기 쉽습니다. 그러나 AI가 작성한 설명과 실제 문서 원문은 다릅니다. 따라서 답변과 근거를 분리해서 보여주는 화면 구성이 필요합니다.
📋 AI 검색 결과 화면에 필요한 정보
- AI가 작성한 요약 답변
- 근거 문서명과 페이지
- 실제로 검색된 원문
- 문서의 기준일 또는 버전
- 검색 관련도와 원문 열기 버튼
- 근거가 약할 때 표시되는 ‘근거 부족’ 안내
답변과 원문을 나란히 보여주면 사용자가 AI의 해석이 적절한지 바로 검토할 수 있습니다. 특히 회계, 세무, 내부통제, 계약 검토처럼 근거가 중요한 업무에서는 답변 문장보다 원문 확인 기능이 더 중요할 수 있습니다.
구축은 네 단계로 나누면 됩니다
처음부터 완성형 시스템을 만들려고 하면 범위가 커집니다. 가장 좋은 접근은 작은 문서 묶음으로 검색 정확도를 먼저 검증하고, 그다음 기존 HTML 도구와 연결하는 방식입니다.
처음부터 피해야 할 설계도 있습니다
초기에 편해 보이는 방식이 나중에는 큰 문제가 될 수 있습니다. 예를 들어 API 키를 HTML 소스 안에 저장하거나, 모든 PDF를 질문할 때마다 통째로 모델에 넣거나, 문서명과 페이지 없이 답변만 보여주는 방식은 피해야 합니다.
최신 규정과 폐기된 규정을 같은 DB에서 함께 검색하거나, 엑셀 원본 전체를 무조건 LLM에 전달하거나, AI 답변을 자동으로 최종 검토결론에 반영하는 것도 위험합니다. 업무용 AI는 자동 판단기보다 근거 확인 도구로 시작하는 것이 안전합니다.
결론: 기존 도구를 버리지 말고 AI 검색을 옆에 붙이면 됩니다
AI 기능을 추가한다고 해서 기존 규칙 기반 HTML 도구를 전부 새로 만들 필요는 없습니다. 명확한 조건 검사는 기존 HTML이 처리하고, 문서의 의미를 찾고 설명하는 일은 AI 검색 서버가 처리하면 됩니다.
한 문장으로 정리하면, 원장검토 HTML은 숫자와 예외를 찾고, 별도의 AI 검색 서버는 그 옆에서 근거와 설명을 찾아줍니다. 이 구조라면 현재 사용 중인 검토도구를 유지하면서도 PDF 검색과 AI 설명 기능을 단계적으로 붙일 수 있습니다.
시작은 거창할 필요가 없습니다. 먼저 작은 문서 묶음에서 검색 정확도와 출처 표시가 제대로 되는지 확인해보는 것이 좋습니다. 화면을 크게 바꾸기보다, 올바른 근거가 검색되는 구조를 먼저 만드는 것이 업무용 AI 도구의 출발점입니다.