“고객 문의에 답하는 AI 챗봇을 만들고 싶습니다.”
“계약서와 신청서를 자동으로 읽어서 시스템에 입력하고 싶습니다.”
“사내 문서를 검색해 답변해 주는 AI가 필요합니다.”
AI개발을 검토하는 기업에서 자주 나오는 요청입니다. 문제는 이 정도의 설명만으로는 개발 범위를 구체적으로 정하기 어렵다는 점입니다.
같은 AI 챗봇이라도 공개된 상품 정보를 안내하는 기능과 사내 규정을 검색하는 기능은 필요한 데이터와 권한 구조가 다릅니다. 문서 OCR도 글자를 추출하는 데서 끝나는지, 추출한 정보를 기존 시스템에 등록하고 담당자가 검수·확정하는 단계까지 포함하는지에 따라 프로젝트 범위가 달라집니다.
어떤 AI 모델을 사용할지 결정하는 것도 필요하지만, 그보다 먼저 정해야 하는 것은 AI가 처리할 업무, 입력받을 데이터, 만들어야 할 결과, 결과를 검수할 사람과 시스템입니다.
AI를 별도의 기술 기능으로만 보면 “질문을 입력하면 답변이 나오는 화면”에 집중하기 쉽습니다. 하지만 실제 서비스에서는 AI 앞뒤로 사용자 화면, 관리자 기능, 데이터베이스, 문서 저장소, 외부 API, 권한 관리, 오류 대응이 연결됩니다.
이번 글에서는 챗봇, 문서 검색, OCR, 분류, 추천, 업무 자동화 중 우리 업무에 어떤 기능이 필요한지 판단하고, AI개발 외주 문의 시 어디까지 범위에 포함해야 하는지를 실무 관점에서 정리합니다.
AI를 넣을 곳보다 해결할 업무를 먼저 정해야 합니다
AI개발을 검토할 때 가장 먼저 나오는 질문은 대개 다음과 같습니다.
- 어떤 AI 모델이 좋을까요?
- 자체 모델을 만들어야 할까요?
- 챗봇으로 구현할 수 있을까요?
- 학습 데이터는 얼마나 필요한가요?
- 기존 서비스에 AI API만 연결하면 될까요?
그러나 모델과 구현 방법을 먼저 결정하면 실제 업무에는 필요하지 않은 기능이 포함되거나, 반대로 운영에 필요한 관리자 기능이 빠질 수 있습니다.
먼저 현재 업무를 다음과 같이 한 줄로 적어보는 편이 좋습니다.
담당자가 이메일로 접수된 신청서를 확인하고, 고객 정보를 내부 시스템에 입력한 다음, 신청 유형에 따라 담당 부서를 배정한다.
이 업무에는 여러 단계가 섞여 있습니다.
- 이메일과 첨부파일을 확인합니다.
- 문서에서 고객 정보를 찾습니다.
- 필요한 항목을 시스템에 입력합니다.
- 신청 내용을 기준으로 유형을 분류합니다.
- 담당 부서나 담당자를 배정합니다.
- 처리 결과를 고객에게 안내합니다.
이 중 모든 단계를 AI로 처리할 필요는 없습니다.
문서에서 이름, 연락처, 신청번호를 읽는 과정에는 OCR이나 문서 분석 기능을 적용할 수 있습니다. 신청 내용을 유형별로 나누는 업무에는 분류 기능을 사용할 수 있습니다. 담당 부서 배정은 명확한 조건이 있다면 AI보다 규칙 기반 로직이 더 적합할 수도 있습니다.
예를 들어 “신청 지역이 경기도이면 경기 담당팀에 배정한다”와 같이 조건이 명확한 업무는 일반적인 프로그램 로직으로 처리할 수 있습니다. 반면 자유롭게 작성된 문의 내용을 읽고 상담, 환불, 기술 지원, 제휴 문의로 구분해야 한다면 AI 분류를 검토할 수 있습니다.
따라서 AI개발 범위를 정할 때는 업무를 다음 세 종류로 나누는 것이 좋습니다.
| 구분 | 특징 | 적용 방식 |<br>|---|---|---|<br>| 규칙이 명확한 업무 | 조건과 결과를 미리 정할 수 있음 | 일반 개발 로직, 자동화 규칙 |<br>| 내용 해석이 필요한 업무 | 문장, 이미지, 문서의 의미를 판단해야 함 | AI 분류, OCR, 생성형 AI |<br>| 사람이 책임져야 하는 업무 | 승인, 계약, 정산, 민감한 의사결정 | AI 보조 후 담당자 검수 |
AI는 모든 업무를 대신하는 시스템이라기보다, 사람이 반복적으로 확인하고 정리하던 일부 단계를 보조하는 기능으로 시작하는 편이 현실적입니다.
NIST의 AI 위험관리 프레임워크도 AI가 지원할 구체적인 업무와 적용 범위를 정의하고, 사람의 감독 절차와 역할을 문서화하도록 안내합니다. 기술을 먼저 고르는 것이 아니라 사용 맥락과 책임 구조를 함께 정해야 한다는 의미입니다. (airc.nist.gov)
반복 문의가 많다면 AI 챗봇을 검토할 수 있습니다
고객센터나 내부 지원 부서에 비슷한 질문이 반복된다면 AI 챗봇이 도움이 될 수 있습니다.
예를 들면 다음과 같습니다.
- 서비스 이용 방법 안내
- 상품과 요금제 정보 안내
- 신청 절차와 준비 서류 안내
- 예약 변경 및 취소 규정 안내
- 사내 복지와 인사 규정 안내
- 업무 매뉴얼 검색
- 시스템 사용 방법 안내
다만 “모든 질문에 답하는 챗봇”을 목표로 잡으면 답변 범위와 책임이 불명확해질 수 있습니다.
먼저 챗봇이 답변해야 하는 질문과 답변하지 않아야 하는 질문을 구분해야 합니다.
답변 범위에 넣기 쉬운 질문
- 승인된 매뉴얼과 자주 묻는 질문에 답이 있는 내용
- 상품명, 이용 조건, 제출 서류처럼 근거가 분명한 정보
- 서비스 화면의 사용 방법
- 담당 부서와 상담 채널 안내
별도의 대응 기준이 필요한 질문
- 계약이나 법률적 판단이 필요한 질문
- 고객 개인의 결제·주문·예약 정보를 조회해야 하는 질문
- 환불 가능 여부처럼 운영자의 확인과 승인이 필요한 질문
- 의료·금융 등 잘못된 답변의 영향이 큰 질문
- 문서에 근거가 없거나 최신 여부를 확인하기 어려운 질문
AI가 답변할 수 없는 질문은 억지로 추정하게 만들기보다 상담 접수, 담당자 연결, 문의 등록으로 전환하는 흐름이 필요합니다.
따라서 AI 챗봇 개발 범위에는 채팅 화면만이 아니라 다음 기능이 함께 포함될 수 있습니다.
- 사용자 로그인 상태 확인
- 고객 유형별 답변 범위 구분
- 답변에 사용된 문서와 근거 표시
- 답변하지 못한 질문의 상담 전환
- 사용자 피드백 수집
- 대화 이력 조회
- 관리자용 답변 검토 기능
- 금지어와 민감 질문 처리
- 질문 유형과 실패 사례 통계
- 문서 및 FAQ 등록·수정 기능
챗봇 화면만 개발하고 운영 기능을 제외하면 잘못된 답변이 발생해도 어떤 자료를 참고했는지 확인하기 어렵습니다. 반복적으로 답변하지 못한 질문도 파악할 수 없어 개선이 늦어질 수 있습니다.
사내 자료가 흩어져 있다면 문서 검색형 AI가 적합할 수 있습니다
사내 규정, 제품 설명서, 업무 매뉴얼, 계약 기준, 프로젝트 문서가 여러 폴더와 시스템에 흩어져 있다면 문서 검색형 AI를 검토할 수 있습니다.
사용자가 질문을 입력하면 관련 문서를 찾고, 검색된 내용을 바탕으로 답변을 구성하는 방식입니다. 일반적인 AI 지식이 아니라 기업이 보유한 자료를 기반으로 답변하도록 설계하는 것이 핵심입니다.
문서 검색형 AI를 개발할 때는 문서를 업로드하는 기능만 생각해서는 부족합니다. 다음 항목을 함께 정해야 합니다.
- 어떤 종류의 문서를 등록할 것인가?
- PDF, 워드, 엑셀, 이미지 문서를 모두 처리해야 하는가?
- 누가 문서를 등록하고 삭제할 수 있는가?
- 부서별로 볼 수 있는 문서가 다른가?
- 시행일과 만료일이 있는 문서를 어떻게 구분할 것인가?
- 같은 규정의 이전 버전과 최신 버전을 어떻게 관리할 것인가?
- 답변에 문서명과 참고 위치를 표시할 것인가?
- 근거 문서를 찾지 못하면 어떻게 응답할 것인가?
- 문서가 수정되면 검색 데이터도 자동으로 갱신할 것인가?
문서 검색 기능은 파일을 저장하는 것과 검색 가능한 지식으로 가공하는 과정이 구분될 수 있습니다. 실제 AI API에서도 파일을 검색 데이터로 활용하려면 문서를 분할하고 검색용 데이터로 구성하는 과정이 사용되며, 저장량과 검색 도구 호출이 별도 과금 항목이 될 수 있습니다. 사용하는 AI 제공사와 구현 방식에 따라 과금 구조가 다르므로 상담 단계에서 확인해야 합니다. (developers.openai.com)
특히 사내 문서 검색에서는 권한이 중요합니다.
영업팀 직원이 인사 평가 문서나 경영진 전용 자료를 검색할 수 있어서는 안 됩니다. 단순히 검색 화면의 메뉴를 숨기는 것이 아니라, AI가 참고할 문서를 조회하는 단계에서도 사용자의 소속과 권한이 적용되어야 합니다.
권한 검사가 검색 이후에만 이루어지면 AI가 답변을 생성하는 과정에서 접근하면 안 되는 문서가 사용될 수 있습니다. 따라서 문서를 찾는 시점부터 사용자별 접근 범위를 제한하는 구조가 필요합니다.
문서를 읽고 입력하는 업무라면 OCR과 검수 화면이 함께 필요합니다
OCR은 이미지나 스캔 문서에서 글자를 인식하는 기능입니다.
다음과 같은 업무에서 검토할 수 있습니다.
- 신청서의 이름, 연락처, 주소 추출
- 사업자등록증 정보 입력 보조
- 계약서의 계약번호와 날짜 추출
- 견적서와 거래명세서의 품목·금액 확인
- 영수증과 세금계산서 정보 정리
- 이미지로 접수된 서류의 문서 유형 구분
하지만 OCR 결과를 바로 확정 데이터로 저장하는 구조는 주의해야 합니다.
문서가 흐리거나 기울어져 있을 수 있고, 도장이나 표가 글자를 가릴 수도 있습니다. 같은 의미의 값이 문서마다 다른 위치와 형식으로 표시되기도 합니다.
OCR 제품은 일반적으로 추출 항목별 신뢰도 값을 제공할 수 있으며, 임계값을 높이면 정확하다고 판단되는 결과는 늘어날 수 있지만 인식 대상으로 채택되는 결과는 줄어드는 상충 관계가 생길 수 있습니다. 따라서 모든 항목을 동일한 기준으로 자동 확정하기보다 업무 중요도에 따라 검수 기준을 나누는 것이 좋습니다. (docs.cloud.google.com)
예를 들어 다음과 같이 구분할 수 있습니다.
| 항목 | 처리 기준 예시 |<br>|---|---|<br>| 문서 제목 | 자동 분류 후 운영자가 필요할 때 수정 |<br>| 고객 이름 | 원문과 비교해 검수 |<br>| 연락처 | 형식 검사 후 검수 |<br>| 계약 금액 | 반드시 담당자가 확인 후 확정 |<br>| 참고 문구 | 검색용 데이터로 저장하되 확정값으로 사용하지 않음 |
OCR 개발 범위에는 다음과 같은 운영 화면이 필요할 수 있습니다.
- 원본 문서를 업로드합니다.
- AI가 문서 유형과 주요 항목을 추출합니다.
- 원본 이미지와 추출 결과를 한 화면에서 보여줍니다.
- 신뢰도가 낮거나 형식이 맞지 않는 항목을 표시합니다.
- 담당자가 결과를 수정합니다.
- 검수 완료 후 시스템 데이터로 확정합니다.
- 처리 실패 문서는 재업로드하거나 재처리합니다.
- 수정 전·후 값과 처리 담당자를 기록합니다.
원본과 결과를 비교할 수 없다면 담당자는 OCR 결과를 확인하기 위해 파일을 별도로 열어야 합니다. 이 경우 자동화를 도입하고도 운영자는 다시 수작업에 의존하게 됩니다.
문의와 문서를 자동으로 나누려면 분류 기준부터 정의해야 합니다
AI 분류는 자유롭게 작성된 글이나 문서를 정해진 유형으로 나누는 기능입니다.
예를 들면 다음과 같습니다.
- 고객 문의를 결제, 환불, 배송, 기술 지원으로 분류
- 접수 문서를 신청서, 계약서, 증빙 자료로 분류
- 게시물을 정상, 광고, 신고 검토 대상으로 구분
- 지원 요청을 담당 부서별로 배정
- 상품 정보를 카테고리별로 분류
- 상담 내용을 긴급도나 처리 우선순위에 따라 구분
분류 기능을 개발하기 전에 실제 운영자가 사용하는 기준을 확인해야 합니다.
현재 담당자마다 서로 다른 기준으로 분류하고 있다면 AI도 일관된 결과를 내기 어렵습니다. 먼저 분류 항목과 항목별 조건을 정리해야 합니다.
- 하나의 문의가 여러 유형에 포함될 수 있는가?
- 분류할 수 없는 내용은 어디에 넣을 것인가?
- 새로운 유형은 누가 추가하는가?
- AI 결과를 운영자가 변경할 수 있는가?
- 변경된 결과를 향후 개선 자료로 사용할 것인가?
- 분류 결과에 따라 자동으로 실행되는 업무가 있는가?
- 어느 정도 확실한 결과만 자동 처리할 것인가?
특히 분류 이후 환불, 계약 승인, 계정 정지와 같은 중요한 처리가 자동 실행된다면 더 신중한 기준이 필요합니다.
초기에는 AI가 분류 결과를 제안하고 운영자가 확정하도록 구성한 뒤, 실제 처리 데이터를 바탕으로 자동화 범위를 넓히는 방법을 검토할 수 있습니다.
추천 기능은 무엇을 추천할지보다 추천 이후 행동을 봐야 합니다
추천 기능은 상품이나 콘텐츠를 보여주는 기능으로만 생각하기 쉽습니다. 그러나 업무 시스템에서도 활용할 수 있습니다.
- 고객 조건에 맞는 상품 추천
- 문의 내용에 맞는 담당자 추천
- 프로젝트 조건에 맞는 전문가 추천
- 이전 구매 이력에 따른 재주문 품목 추천
- 처리 중인 업무의 다음 단계 추천
- 검색 내용과 관련된 문서 추천
추천 기능을 검토할 때는 다음 질문이 필요합니다.
- 누구에게 무엇을 추천할 것인가?
- 추천에 사용할 수 있는 데이터는 무엇인가?
- 추천 결과를 사용자가 직접 선택하는가?
- 운영자가 승인한 뒤 적용하는가?
- 추천 이유를 보여줘야 하는가?
- 추천할 결과가 없을 때는 어떻게 처리하는가?
- 특정 상품이나 담당자가 과도하게 노출되지는 않는가?
- 사용자의 선택과 거절 결과를 기록할 것인가?
추천 결과가 참고 정보라면 상대적으로 단순하게 시작할 수 있습니다. 반면 담당자 배정이나 가격 결정처럼 실제 업무 결과에 직접 영향을 준다면 운영자의 확인, 수정, 예외 처리와 이력 관리가 필요합니다.
추천 기능의 품질도 단순히 “정답을 맞혔는가”만으로 평가하기 어렵습니다. 사용자가 추천 결과를 선택했는지, 운영자가 얼마나 자주 변경했는지, 특정 항목으로 결과가 치우치지 않는지 등 서비스 목적에 맞는 평가 기준을 별도로 정해야 합니다.
업무 자동화는 AI 한 번 호출하는 기능이 아닙니다
AI 업무 자동화는 다음과 같은 흐름으로 구성될 수 있습니다.
``text<br>문의 접수<br>→ 내용 분석<br>→ 문의 유형 분류<br>→ 필요한 고객 정보 추출<br>→ 담당 부서 추천<br>→ 답변 초안 생성<br>→ 담당자 검수<br>→ 고객에게 발송<br>→ 처리 이력 저장<br>``
이 흐름에서 AI가 담당하는 부분은 내용 분석, 분류, 정보 추출, 답변 초안 작성일 수 있습니다. 고객 정보 조회, 담당 부서 배정, 발송 승인, 처리 이력 저장은 일반적인 백엔드와 관리자 시스템이 담당합니다.
따라서 AI 업무 자동화 외주 범위에는 다음 개발이 함께 포함될 수 있습니다.
- 이메일·웹·앱의 접수 화면
- AI API 호출과 결과 처리
- 기존 고객·주문·예약 데이터 조회
- 운영자용 검수 및 승인 화면
- 상태값과 담당자 배정
- 알림과 결과 발송
- 실패 건 재처리
- 처리 이력과 변경 이력
- 사용량과 비용 통계
- AI 결과에 대한 운영자 피드백
AI개발은 AI 모델을 연결하는 작업과 업무 시스템을 구축하는 작업으로 나누어 봐야 합니다. 이미 웹사이트와 관리자 시스템이 있다면 기존 구조에 연동할 수 있는지 확인해야 하고, 없다면 AI 결과를 사용할 사용자 화면과 운영 화면도 새로 개발해야 할 수 있습니다.
AI에 전달할 입력과 받아야 할 결과를 구체적으로 적어보세요
AI 기능의 범위를 명확하게 만드는 방법은 입력과 출력을 예시로 작성하는 것입니다.
“문서를 분석해 주세요”보다 다음과 같이 작성하는 편이 개발 범위를 정하기 쉽습니다.
입력
- PDF 또는 이미지 형식의 신청서
- 문서당 최대 페이지 수
- 문서에 포함될 수 있는 항목
- 손글씨 포함 여부
- 표와 도장 포함 여부
- 지원해야 하는 언어
- 한 번에 처리할 문서 수
출력
- 신청자 이름
- 연락처
- 신청번호
- 신청 유형
- 접수일
- 누락 항목
- 항목별 확인 필요 여부
- 원문에서 해당 값이 위치한 페이지
챗봇도 동일합니다.
입력
- 사용자의 질문
- 사용자 유형과 로그인 여부
- 현재 보고 있는 상품이나 화면
- 대화 이력
- 검색할 수 있는 문서 범위
출력
- 사용자에게 보여줄 답변
- 참고한 문서와 근거
- 답변 가능 여부
- 상담 연결 필요 여부
- 문의 유형
- 관리자 확인이 필요한 이유
결과 형식을 구조화하면 AI의 출력을 기존 시스템과 연결하기 쉬워집니다.
예를 들어 답변 문장만 받는 것이 아니라 문의 유형, 담당 부서, 처리 우선순위, 검수 필요 여부를 각각 별도의 값으로 받으면 관리자 업무에 활용할 수 있습니다.
다만 AI 결과는 형식이 맞는지 확인하는 검증 과정이 필요합니다. 날짜, 전화번호, 금액처럼 규칙을 적용할 수 있는 값은 일반 프로그램에서 형식을 다시 검사할 수 있습니다.
AI 결과는 초안·검수·확정 상태로 나누는 것이 좋습니다
AI가 결과를 만들었다고 해서 업무가 완료된 것은 아닙니다.
운영 시스템에서는 다음과 같이 상태를 구분할 수 있습니다.
``text<br>처리 대기<br>→ AI 처리 중<br>→ 검수 필요<br>→ 담당자 수정<br>→ 확정<br>→ 후속 시스템 반영<br>``
처리에 실패한 경우에는 별도의 흐름이 필요합니다.
``text<br>AI 처리 실패<br>→ 실패 원인 확인<br>→ 재처리 또는 수동 입력<br>→ 담당자 확정<br>``
검수 기능을 설계할 때는 단순히 승인 버튼만 만들기보다 다음 항목을 확인해야 합니다.
- 원본 입력과 AI 결과를 함께 볼 수 있는가?
- AI가 참고한 근거를 확인할 수 있는가?
- 결과를 항목별로 수정할 수 있는가?
- 수정 전 값과 수정 후 값을 기록하는가?
- 누가 검수하고 확정했는가?
- 같은 데이터를 다시 처리할 수 있는가?
- 재처리 결과가 기존 확정값을 덮어쓰는가?
- 오류 사례를 별도로 모아볼 수 있는가?
AI가 작성한 답변 초안을 직원이 수정한 경우에도 수정된 최종 답변만 저장하면 개선 지점을 찾기 어렵습니다. 초안과 최종 결과의 차이를 기록하면 어떤 표현이나 정보가 반복적으로 수정되는지 확인할 수 있습니다.
사람의 검수는 모든 결과를 같은 방식으로 확인한다는 의미가 아닙니다. 영향도가 낮은 결과는 자동으로 처리하고, 특정 조건이나 낮은 신뢰도의 결과만 검수 대상으로 보낼 수도 있습니다.
중요한 것은 어떤 결과를 자동 확정하고 어떤 결과를 사람이 확인할지 업무 기준을 정하는 것입니다.
기존 웹·앱·관리자 시스템과의 연동 범위도 확인해야 합니다
AI 기능이 독립된 페이지에서 끝나는 경우는 많지 않습니다.
고객 문의 AI라면 회원 정보와 주문 내역을 조회해야 할 수 있고, OCR이라면 추출한 값을 기존 업무 시스템에 등록해야 할 수 있습니다. 추천 기능은 상품 데이터, 재고, 가격, 사용자 이력과 연결될 수 있습니다.
외주 문의 전에는 연동 대상을 다음과 같이 정리해보는 것이 좋습니다.
| 연동 대상 | 확인할 내용 |<br>|---|---|<br>| 기존 홈페이지·앱 | AI 기능을 어느 화면에 추가할지 |<br>| 회원 시스템 | 로그인 여부와 사용자 권한 |<br>| 관리자 시스템 | 검수, 수정, 승인, 재처리 기능 |<br>| 문서 저장소 | 문서 위치, 형식, 최신 버전 관리 |<br>| ERP·CRM | 조회·등록할 데이터와 기준 시스템 |<br>| 이메일·메신저 | 문의 수집과 결과 알림 방식 |<br>| 외부 AI API | 이용 계정, 데이터 처리 조건, 호출 제한 |<br>| 데이터베이스 | 원본, AI 결과, 확정 결과의 저장 범위 |
연동할 API가 있는지도 확인해야 합니다.
기존 시스템에 API가 없다면 데이터베이스를 직접 연결하거나 별도의 연동 기능을 추가해야 할 수 있습니다. 외부 솔루션에서 필요한 API를 제공하지 않는다면 원하는 자동화를 그대로 구현하기 어려울 수도 있습니다.
또한 AI 처리가 늦어지거나 외부 API가 일시적으로 응답하지 않을 때 기존 서비스까지 멈추지 않도록 설계해야 합니다.
문서 분석처럼 즉시 결과가 필요하지 않은 업무라면 다음과 같은 비동기 처리 방식을 검토할 수 있습니다.
- 사용자가 문서를 등록합니다.
- 시스템은 접수를 완료하고 처리 대기 상태로 저장합니다.
- 백그라운드에서 AI 분석을 실행합니다.
- 처리가 끝나면 사용자나 운영자에게 알립니다.
- 실패하면 재처리 대상으로 표시합니다.
이렇게 하면 AI 응답이 늦어지더라도 사용자가 화면에서 계속 기다려야 하는 문제를 줄일 수 있습니다.
권한·개인정보·문서 최신성을 운영 기준에 포함해야 합니다
AI에 전달되는 데이터에 개인정보나 기업 내부 정보가 포함된다면 어떤 정보가 외부 AI 서비스로 전달되는지 확인해야 합니다.
개인정보보호위원회가 공개한 생성형 AI 개인정보 처리 안내서도 개발 목적을 먼저 구체화하고, 어떤 개인정보를 어떤 목적으로 처리할지를 설정하는 것을 출발점으로 제시합니다. AI개발을 시작할 때 데이터의 종류와 이용 목적을 함께 검토해야 하는 이유입니다. (pipc.go.kr)
다음과 같은 항목을 상담 단계에서 정리해보는 것이 좋습니다.
- AI에 전달되는 개인정보는 무엇인가?
- 꼭 필요하지 않은 정보는 제거하거나 마스킹할 수 있는가?
- 원본 문서와 AI 결과를 얼마 동안 보관할 것인가?
- 외부 AI 서비스에 데이터가 저장되는가?
- 로그에는 질문과 답변이 어느 범위까지 남는가?
- 데이터 삭제 요청을 어떻게 처리할 것인가?
- 부서와 역할별 접근 권한을 어떻게 나눌 것인가?
- 다운로드와 외부 반출을 제한해야 하는가?
- 관리자가 AI 처리 이력을 조회할 수 있는가?
외부 AI API의 데이터 저장 및 보존 정책은 서비스와 기능별로 다를 수 있습니다. 예를 들어 같은 제공사의 API라도 사용하는 엔드포인트와 저장 설정에 따라 애플리케이션 상태의 보관 여부가 달라질 수 있으므로, 계약과 기술 문서를 실제 구현 시점에 확인해야 합니다. (platform.openai.com)
문서 최신성도 중요합니다.
사내 규정이 개정됐는데 AI가 이전 버전을 계속 참고하면 자연스러운 문장으로 오래된 답변을 제공할 수 있습니다.
따라서 문서에는 다음과 같은 정보를 함께 관리하는 것이 좋습니다.
- 문서명과 문서 유형
- 작성 부서와 관리 담당자
- 버전
- 시행일과 만료일
- 공개 범위
- 사용 여부
- 대체된 이전 문서
- 마지막 검토일
- 검색 데이터 반영 상태
문서를 삭제하는 것만이 답은 아닐 수 있습니다. 과거 시점의 업무를 확인해야 한다면 이전 문서를 보관하되, 현재 답변에는 최신 문서를 우선 사용하도록 구분할 수 있습니다.
모델 이용료만이 AI 운영비의 전부는 아닙니다
AI개발 견적을 검토할 때 초기 개발비와 운영비를 나누어 확인해야 합니다.
AI 운영 과정에서는 다음과 같은 비용이 발생할 수 있습니다.
1. AI 모델 API 이용료
생성형 AI는 입력 데이터와 출력 결과의 양, 선택한 모델, 호출 횟수에 따라 비용이 달라질 수 있습니다.
긴 문서 전체를 매번 전달하거나 대화 이력을 계속 누적하면 입력량이 늘어납니다. 답변이 길거나 여러 결과를 동시에 생성해도 사용량이 증가할 수 있습니다.
2. 문서 검색용 데이터 저장 비용
사내 문서 검색 기능은 원본 파일 외에도 검색을 위한 가공 데이터와 색인 정보를 저장할 수 있습니다. 사용 서비스에 따라 저장 용량이나 검색 도구 호출이 별도 과금될 수 있습니다. (developers.openai.com)
3. 서버와 데이터베이스
회원 정보, 대화 이력, 문서 처리 상태, 검수 결과, 관리자 기록을 저장할 서버와 데이터베이스가 필요합니다.
문서와 이미지가 많다면 파일 저장공간과 백업 비용도 함께 고려해야 합니다.
4. OCR과 외부 API 이용료
OCR, 번역, 음성 인식, 문자 발송, 이메일, 푸시 알림 등 외부 서비스를 함께 사용한다면 각 서비스의 이용료가 추가될 수 있습니다.
5. 모니터링과 유지보수
AI 모델이나 외부 API가 변경될 수 있고, 실제 운영 중 새로운 질문과 문서 유형이 추가될 수 있습니다.
따라서 다음 업무의 담당 범위를 정해야 합니다.
- 실패 로그 확인
- 사용량과 비용 모니터링
- 문서 갱신
- 답변 정책 변경
- AI 프롬프트와 처리 규칙 수정
- 모델 변경 전 테스트
- 오류 사례 분석
- 개인정보 삭제 처리
- 관리자와 운영자 교육
현재 가격표만 보고 장기 운영비를 단정하기보다는 예상 사용자 수, 하루 처리 건수, 평균 입력 길이, 문서 저장량을 기준으로 사용량을 추정하는 편이 좋습니다. AI API의 과금 단위와 가격은 변경될 수 있으므로 계약 및 개발 시점의 공식 정책을 다시 확인해야 합니다.
1차 MVP에는 하나의 완결된 업무 흐름을 넣어보세요
AI개발 MVP는 여러 AI 기능을 조금씩 넣는 방식보다, 하나의 업무를 처음부터 끝까지 처리할 수 있도록 구성하는 편이 검증하기 쉽습니다.
예를 들어 문서 자동화 MVP라면 다음 범위를 생각할 수 있습니다.
1차 MVP
- 한 종류의 문서 업로드
- 주요 항목 5~10개 추출
- 원본과 결과 비교 화면
- 운영자 수정 및 확정
- 처리 상태 관리
- 실패 건 재처리
- 확정 데이터 다운로드 또는 기존 시스템 전달
- 처리량과 오류 건수 확인
이후 확장 기능
- 여러 종류의 문서 자동 분류
- 대량 일괄 업로드
- 이메일 첨부파일 자동 수집
- ERP·CRM 자동 등록
- 항목별 자동 확정 기준
- 운영자 수정 결과를 활용한 품질 개선
- 부서별 권한과 승인 절차
- 고급 통계와 비용 대시보드
문서 검색형 AI도 처음부터 모든 사내 문서를 넣을 필요는 없습니다.
특정 부서의 승인된 매뉴얼이나 FAQ부터 시작해 실제 질문, 답변 실패 유형, 문서 관리 부담을 확인한 뒤 범위를 넓힐 수 있습니다.
MVP에서 확인해야 할 것은 “AI가 답변을 생성할 수 있는가”만이 아닙니다.
- 필요한 답변을 찾는 비율은 어느 정도인가?
- 운영자는 결과를 얼마나 자주 수정하는가?
- 처리 시간이 실제 업무에 적합한가?
- 직원이 기존 방식보다 편하게 사용하는가?
- 답변할 수 없는 질문을 적절히 구분하는가?
- 한 건 처리에 드는 운영비는 어느 정도인가?
- 문서와 정책을 지속적으로 관리할 수 있는가?
대표적인 실제 업무 사례를 테스트 데이터로 준비하고, 같은 기준으로 결과를 반복 평가해야 모델이나 프롬프트를 변경했을 때 품질이 나아졌는지 확인할 수 있습니다. AI 서비스도 일반 프로그램처럼 테스트 기준과 검수 데이터가 필요합니다.
AI개발 외주 문의 전 체크리스트
개발사에 문의하기 전 아래 내용을 준비하면 기능 범위와 견적을 구체적으로 논의하기 쉽습니다.
해결할 업무
- [ ] 현재 사람이 반복해서 처리하는 업무는 무엇인가?
- [ ] 한 건을 처리하는 순서는 어떻게 되는가?
- [ ] 가장 시간이 오래 걸리는 단계는 어디인가?
- [ ] AI가 보조할 단계와 일반 로직으로 처리할 단계를 구분했는가?
- [ ] AI 결과를 누가 사용하고 최종 확정하는가?
입력 데이터
- [ ] 질문, 문서, 이미지, 고객 정보 중 무엇을 입력하는가?
- [ ] 실제 샘플 데이터를 제공할 수 있는가?
- [ ] 개인정보나 민감한 내부 정보가 포함되는가?
- [ ] 데이터의 형식과 품질이 일정한가?
- [ ] 문서의 최신 버전을 구분할 수 있는가?
출력 결과
- [ ] AI가 만들어야 하는 결과를 항목별로 적었는가?
- [ ] 결과가 문장인지 구조화된 데이터인지 정했는가?
- [ ] 근거와 참고 문서를 표시해야 하는가?
- [ ] 자동 확정할 결과와 검수할 결과를 구분했는가?
- [ ] 답변하거나 처리할 수 없는 경우의 기준이 있는가?
사용자와 관리자
- [ ] AI 기능을 사용하는 사용자 유형은 누구인가?
- [ ] 사용자별 데이터 접근 범위가 다른가?
- [ ] 운영자가 결과를 수정하고 승인할 수 있어야 하는가?
- [ ] 실패 건과 미처리 건을 모아볼 화면이 필요한가?
- [ ] 변경 이력과 처리 담당자를 기록해야 하는가?
기존 시스템 연동
- [ ] 기존 웹사이트나 앱에 추가하는 기능인가?
- [ ] 관리자 시스템이 이미 있는가?
- [ ] ERP, CRM, 그룹웨어와 연동해야 하는가?
- [ ] 기존 시스템에서 사용할 수 있는 API가 있는가?
- [ ] AI 처리 결과를 어느 시스템에 저장할 것인가?
운영과 비용
- [ ] 예상 사용자 수와 하루 처리 건수는 어느 정도인가?
- [ ] 원본 문서와 결과의 보관 기간은 얼마인가?
- [ ] 모델 API, OCR, 저장공간 비용을 누가 부담하는가?
- [ ] 사용량과 비용을 확인할 관리자 기능이 필요한가?
- [ ] 모델이나 외부 API 변경 시 유지보수 범위는 어디까지인가?
실제 개발에서는 AI와 운영 시스템을 함께 설계해야 합니다
원소프트는 웹·앱·AI 기능과 관리자 시스템을 함께 개발하며, AI 결과가 실제 서비스 업무로 이어지는 구조를 중요하게 봅니다.
관련 경험으로 부동산 경매 업무 통합 플랫폼인 바토너 프로젝트에서 문서 정보를 인식하는 OCR 연동과 입력 보조 흐름을 구현했습니다.
이 프로젝트에서는 OCR 기능만 독립적으로 추가한 것이 아니라, 경매 물건 확인부터 입찰 신청, 계약 문서 처리, 결제, 포인트, 정산, 알림, 고객 문의, 관리자 운영으로 이어지는 전체 업무 흐름 안에서 문서 데이터를 활용하도록 구성했습니다.
문서에서 추출한 값은 실제 업무 데이터와 연결되어야 했기 때문에 회원·전문가·운영자별 권한, 입찰과 계약의 상태, 결제·정산 데이터, 관리자 기능도 함께 고려했습니다.
이처럼 AI 또는 OCR 기능은 결과를 생성하는 단계만으로 완성되지 않습니다.
누가 데이터를 입력하고, 누가 검수하며, 확정 결과가 어느 업무에 반영되고, 잘못된 결과를 어떻게 수정할지를 함께 설계해야 실제 운영에서 사용할 수 있습니다.
원소프트는 프로젝트 상황에 따라 AI API, 외부 OCR, 웹·앱 화면, 백엔드, 데이터베이스, 관리자 시스템을 조합합니다. 특정 기술을 먼저 정하기보다 현재 업무와 데이터, 기존 시스템, 예상 사용량을 확인한 뒤 필요한 구조를 검토합니다.
AI개발을 준비하고 있다면 완성된 기획서가 없어도 괜찮습니다. 현재 반복하고 있는 업무, 사용 중인 문서나 시스템, 원하는 결과의 예시를 바탕으로 AI가 맡을 부분과 일반 개발로 처리할 부분을 나누어 볼 수 있습니다.
원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·AI 개발사입니다. 동탄·화성을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부 지역에서 AI 기능이나 업무 시스템 개발을 검토하고 계신다면 현재 업무 흐름을 기준으로 1차 구축 범위와 이후 확장 범위를 함께 정리해드릴 수 있습니다.
제목 후보
- AI개발, 우리 업무에 필요한 기능과 외주 범위를 정하는 방법
- AI개발 외주 문의 전, 챗봇·OCR·문서 검색 범위를 정리하는 기준
- AI 업무 자동화 개발, 모델보다 먼저 정해야 할 입력·검수·운영 구조
- 기업 AI개발, 반복 업무에서 필요한 기능을 찾는 실무 체크리스트
- AI개발 범위 정하기, 사용자 화면부터 관리자·기존 시스템 연동까지
추천 제목
AI개발, 우리 업무에 필요한 기능과 외주 범위를 정하는 방법
메인 키워드
AI개발
서브 키워드
- AI개발외주
- AI업무자동화
- AI챗봇개발
- OCR개발
- 문서검색AI
추천 해시태그
#AI개발 <br>#AI개발외주 <br>#AI업무자동화 <br>#AI챗봇개발 <br>#OCR개발 <br>#문서자동화 <br>#관리자시스템개발 <br>#외부API연동 <br>#동탄개발업체 <br>#화성웹개발
썸네일 문구
- 우리 업무에 필요한 AI 기능은?
- AI개발 범위 정하는 방법
- 챗봇·OCR·자동화 선택 기준
글 요약
AI개발은 최신 모델을 먼저 선택하기보다 반복되는 업무를 단계별로 나누고, AI가 받을 입력과 만들어야 할 결과를 구체화하는 것에서 시작해야 합니다. 챗봇·문서 검색·OCR·분류·추천·업무 자동화별 적용 상황과 검수 구조, 기존 시스템 연동, 개인정보·권한, 운영비 및 MVP 범위를 정하는 기준을 설명했습니다.
CTA 후보
- AI 적용을 검토하고 있지만 기능 범위를 정하기 어렵다면, 현재 반복하고 있는 업무와 사용 중인 문서·시스템을 바탕으로 1차 개발 범위를 함께 정리해볼 수 있습니다.
- 챗봇, OCR, 문서 검색 중 어떤 방식이 적합한지 확실하지 않다면 실제 입력 데이터와 원하는 결과를 기준으로 AI 기능, 관리자 시스템, 기존 서비스 연동 범위를 나누어 검토해드릴 수 있습니다.
관련 포트폴리오
바토너(Batoner) - 부동산 경매 업무 통합 플랫폼
참고한 부분:
- OCR을 활용한 문서 정보 인식 및 입력 보조 기능 연동
- 입찰·계약 과정에서 필요한 문서 데이터 관리
- 사용자 유형별 인증과 권한 처리
- 입찰 신청부터 계약·결제·정산까지의 상태 기반 업무 흐름
- 고객용 기능과 관리자용 운영 기능의 데이터 연결
- 공지, 푸시 알림, 문의 답변 등 운영 기능
다음에 작성하면 좋은 연관 글
- 문서 검색 AI 개발, 오래된 자료와 부서별 권한을 관리하는 방법
- AI개발 비용, 모델 API·문서 저장·관리자 시스템 범위를 구분하는 기준
- AI 챗봇 관리자 페이지, 답변 검수와 상담 전환에 필요한 기능 8가지
