기업 AI 도입 전 무엇부터 정해야 할까?

Step 1. 어떤 업무 문제를 풀 것인지 정한다

"우리도 AI를 도입하자"는 목표로는 무엇을 만들지 정할 수 없습니다. 대신 "직원이 규정 검색에 쓰는 시간을 줄이자", "고객 문의 답변 초안 작성을 지원하자"처럼 업무 하나를 지목합니다. 그다음 그 업무에서 실제로 오가는 질문을 표현 그대로 20개 모읍니다. 담당자에게 반복해서 들어오는 문의, 신입이 첫 달에 하는 질문, 메신저에서 자주 오가는 확인 요청이면 충분합니다. 이 목록이 이후 모든 판단의 기준이 됩니다.

Step 2. 어떤 데이터가 실제로 있는지 확인한다

답이 어디에 있는지 모르면 만들 수 없습니다. 아래 분류로 나눠 목록을 만들어 보면 대상 범위가 눈에 보입니다. 이 단계에서 "생각보다 정리가 안 돼 있다"는 사실이 드러나는 경우가 많은데, 그것을 미리 아는 것이 도입 성공에 더 유리합니다.

• 문서 — 규정·매뉴얼·제품 자료(PDF·DOCX·XLSX·PPTX)
• DB — 시스템에 쌓여 있는 업무 데이터
• API — 실시간 조회가 가능한 내부 서비스
• CRM·ERP — 고객·주문·재고 정보
• FAQ — 이미 정리된 질문·답변
• 웹 콘텐츠 — 사내 포털·위키·공지

Step 3. 데이터 민감도를 나눈다

검색 대상에 넣을 자료와 넣지 않을 자료를 미리 나눠야 합니다. 여기서 정한 범위가 곧 시스템이 알 수 있는 한계이며, 나중에 넓히는 것보다 처음에 좁게 시작하는 편이 안전합니다. 아래 분류는 일반적인 구분이며, 회사 내부 기준과 관련 규정에 따른 최종 판단은 법무·보안 담당의 검토가 필요합니다.

• 공개 — 외부에 이미 공개된 자료
• 사내 공용 — 전 직원이 볼 수 있는 규정·매뉴얼
• 부서 제한 — 해당 부서만 봐야 하는 자료
• 개인정보 포함 — 이름·연락처 등이 들어 있는 문서
• 민감정보 — 인사 평가·계약·재무처럼 별도 판단이 필요한 자료

Step 4. 누가 쓸 것인지 정한다

사용자가 정해져야 화면·권한·답변 방식이 정해집니다. 전 직원이 쓰는 시스템과 상담 직원만 쓰는 시스템은 만드는 것이 다릅니다. 예를 들어 상담 직원용이라면 답변 초안을 복사하기 쉬운 화면이 중요하고, 전 직원용이라면 사내 포털 안에서 바로 열리는 것이 중요합니다. 첫 대상은 자료가 어느 정도 정리돼 있고 같은 질문이 반복되는 부서를 고르면 효과가 빨리 확인됩니다.

• 전 직원 — 규정·복리후생·업무 절차 안내
• 특정 부서 — 그 부서 업무 자료 중심
• 상담 직원 — 고객 문의 대응 시 답변 초안 지원
• 관리자 — 자료 등록·회수, 이용 현황 확인
• 영업팀 — 제품·계약 조건 조회

Step 5. 문제에 맞는 AI 유형을 고른다

모든 문제를 한 가지 기술로 풀려고 하면 어느 쪽도 잘 안 됩니다. 1단계에서 모은 질문을 보면 대개 유형이 나뉩니다.

• 사내 자료에서 찾아 답해야 한다 → RAG(지식검색) 구조
• 반복 업무를 대신 실행해야 한다 → AI 업무 자동화
• 문서·콘텐츠 초안을 만들어야 한다 → 생성형 AI 워크플로
• 여러 도구를 순서대로 판단해 실행해야 한다 → Agent 구조 검토(범위가 크게 늘어나므로 뒤로 미루는 편이 안전합니다)

Step 6. PoC로 실제 업무 기준에서 검증한다

PoC는 "AI가 그럴듯한 말을 하는지" 보는 데모가 아니라 "우리 업무에 쓸 수 있는지" 확인하는 절차입니다. 1단계에서 모은 실제 질문으로 아래를 확인합니다. 여기서 안 되는 것이 보이면 그때 범위를 조정하면 되고, 그것이 PoC의 목적입니다.

• 실제 질문에 답하는가 — 다듬은 질문이 아니라 현장 표현 그대로
• 필요한 문서를 찾아오는가 — 답변 이전에 검색이 맞는지
• 출처가 적절한가 — 근거로 제시한 문서가 실제 근거인가
• 사용자에게 유용한가 — 담당자에게 묻는 것보다 빠른가
• 기존 업무 흐름에 들어갈 수 있는가 — 새 창을 따로 열어야 한다면 잘 안 쓰입니다

Step 7. 기업 AI는 '잘 되는 것 같다'로 검수하면 안 됩니다

느낌으로 판정하면 개선했는지 나빠졌는지 알 수 없습니다. 대표 질문 세트를 만들어 두고, 바뀔 때마다 같은 질문으로 확인하는 절차가 필요합니다. 어떤 지표를 쓸지는 프로젝트 요구에 따라 달라지므로, 처음부터 복잡한 정량 지표를 만들기보다 아래 네 가지를 사람이 확인하는 것에서 시작해도 충분합니다.

• 대표 질문 세트 — 업무에서 실제로 나오는 질문 20~50개
• 기대 답변 — 정답이 명확한 질문은 기대값을 함께 적어 둡니다
• 검색 문서 — 답변 이전에 원하는 문서가 후보에 들어왔는지 확인
• 답변 품질 — 근거가 맞는지, 모를 때 모른다고 하는지

Step 8. 운영을 누가 맡을지 정한다

기업 AI는 한 번 만들고 끝나는 정적 페이지가 아닙니다. 규정이 바뀌었는데 예전 문서가 검색 대상에 남아 있으면 AI는 옛 내용을 근거로 자신 있게 답합니다. 문서를 올리고 내리는 작업을 담당자가 직접 할 수 있도록 관리자 화면을 함께 만드는 것을 권합니다 — 개발자를 거쳐야 자료를 바꿀 수 있는 구조면 결국 갱신이 멈춥니다.

• 문서 업데이트 — 갱신 담당자와 주기
• 새 데이터 반영 — 신규 자료를 검색 대상에 넣는 절차
• 권한 변경 — 조직 개편 시 반영 방법
• 사용자 피드백 — 답이 이상할 때 알릴 수 있는 창구
• 오류 질문 분석 — 검색이 놓친 질문을 모아 개선
• 모델·API 변경 — 요금·성능이 바뀔 때의 교체 절차

도입 전에 확인할 보안 질문

보안은 기능으로 해결되는 것이 아니라 무엇을 어디까지 열어 둘지 정하는 일입니다. 아래 질문에 답을 정해 두면 이후 설계가 훨씬 빨라집니다. 특정 인증이나 법적 적합성을 보장하는 내용은 아니며, 회사 기준에 따른 최종 판단은 보안·법무 담당의 검토가 필요합니다.

• 어떤 데이터가 외부 API로 전달되는가
• 질문·답변 로그를 저장하는가, 얼마나 보관하는가
• 사용자 권한은 어떻게 나뉘는가
• 사용하는 모델 제공자의 데이터 취급 정책은 무엇인가
• 사내 시스템과 어떤 방식으로 연결되는가

기성 서비스와 맞춤 구축 중 무엇이 맞을까

맞춤 구축이 항상 나은 것은 아닙니다. 표준 기능으로 충분하고 빨리 시작하는 것이 중요하다면 기성 서비스가 합리적입니다. 반대로 사내 업무 흐름에 맞춰야 하거나 기존 시스템과 연결해야 하면 구축형이 맞습니다. 두 방식을 함께 쓰는 경우도 있습니다 — 기성 서비스로 먼저 써 보고 한계가 분명해진 뒤 구축으로 넘어가는 순서입니다. 아래 표로 판단 기준을 정리했습니다.

외부 API와 자체 환경 중 어디에 둘 것인가

상용 API 모델을 쓰면 도입이 빠르고 성능이 좋지만, 질문과 검색된 문서 일부가 해당 서비스로 전송됩니다. 반대로 자체 환경에 모델을 두면 데이터가 밖으로 나가지 않지만 필요한 장비와 운영 부담이 커집니다. 어느 쪽이 맞는지는 회사가 다룰 자료의 민감도와 기존 인프라에 달려 있어 일반론으로 정하기 어렵습니다. 름랩은 상용 API 연동 구성을 기본으로 제안하며, 외부 전송이 어려운 자료가 있다면 그 부분을 검색 대상에서 어떻게 분리할지부터 함께 설계합니다. 보안 요구사항과 기존 인프라 환경을 확인한 뒤 적합한 구성을 정합니다.

도입 체크리스트

상담 전에 아래를 스스로 점검해 보시면 좋습니다. 전부 채워야 시작할 수 있는 것은 아니고, 비어 있는 항목이 무엇인지 아는 것만으로도 첫 상담이 훨씬 구체적이 됩니다.

• 해결할 업무 문제가 명확한가?
• 사용할 데이터가 실제로 있는가?
• 데이터 접근 권한을 정했는가?
• 실제 사용자가 누구인지 정했는가?
• RAG가 필요한지 검토했는가?
• 기존 시스템 연동이 필요한가?
• PoC 성공 기준이 있는가?
• 운영 담당자가 있는가?

자주 어긋나는 지점

검토 과정에서 반복해서 나오는 문제들입니다. 대부분 기술이 아니라 준비 단계에서 갈립니다.

• 목적이 모호함 — 무엇이 개선인지 판단할 기준이 없습니다.
• 데이터 품질 문제 — 옛 문서가 섞이면 답이 오히려 나빠집니다.
• 실제 사용자가 없음 — 만들어 놓고 쓸 사람을 나중에 찾습니다.
• 검색 정확도 테스트 부족 — 답변만 보고 검색 단계를 확인하지 않습니다.
• 권한 설계 미흡 — 화면에서만 가리면 답변 문장으로 내용이 새어 나갈 수 있습니다.
• 갱신 담당 미지정 — 몇 달 뒤 자료가 낡아 신뢰를 잃습니다.