AI를 업무에 넣고 싶은데 무엇부터 해야 할지 모를 때의 진행 방법

경영진이 "AI로 뭔가 할 수 있는 게 없는지 검토해 봐"라고 한다. 찾아볼수록 사례는 쏟아지는데, 우리 회사 어느 업무에 해당하는지는 모르겠다. 몇 군데 상담도 받아봤지만 이야기가 겉돌다 멈춰 있다.

이 상태에서 빠져나오려면 순서를 바꿔야 한다. AI에서 출발하면 들어맞는 업무를 찾아 헤매게 되고, 업무에서 출발하면 쓸 기술이 정해진다.

'AI 도입'을 목적으로 삼으면 실패한다

사내 품의서에는 'AI 도입'이라고 적힌다. 그건 수단이지 달성하려는 목표가 아니다.

실제로 원하는 건 처리 시간을 줄이는 것, 일손 부족을 메우는 것, 판단 품질을 고르게 하는 것 같은 업무 쪽 결과다. 이걸 먼저 정해두지 않으면 "정확도 85%가 나왔습니다"라는 보고를 받아도 그게 좋은 건지 나쁜 건지 아무도 판단하지 못한다.

순서를 뒤집는다. 시간이 많이 드는 업무를 먼저 나열하고, 그중 어떤 게 AI로 다룰 수 있는지를 본다. 나열해 보면 AI까지 쓸 필요가 없는 업무가 섞여 있는 경우가 많다. 입력 포맷을 통일하거나, SQL로 집계하거나, 규칙 기반 조건 분기를 짜면 되는 일들이다. 이걸로 끝날 일에 LLM을 쓰면 비용도 늘고 결과도 불안정해진다.

맞는 업무를 가려내는 법

AI에 맞는 업무에는 공통점이 세 가지 있다.

반복적으로 일어난다. 한 달에 몇 번 안 생기는 업무를 자동화해도 구축과 운영에 든 수고를 회수하지 못한다. 대략 한 달에 수십 번 이상, 또는 한 번에 수십 분 이상 걸리는 업무가 대상이다.

판단 기준을 말로 설명할 수 있다. 베테랑이 머릿속으로 하는 판단을 글로 설명할 수 있는가. "이런 조건이면 이렇게 분류한다"를 적어낼 수 있다면, 그 설명이 그대로 프롬프트나 평가 기준이 된다. 적어낼 수 없는 업무는 AI에 넘기기 전에 업무 쪽 정리가 먼저다.

틀려도 치명적이지 않거나, 사람이 확인하는 단계를 끼울 수 있다. AI는 확률적으로 움직이기 때문에 반드시 일정 비율로 틀린다. 틀리는 순간 바로 손해가 나는 업무에는 사람이 확인하는 단계를 꼭 넣는다. 넣을 수 없다면 대상에서 뺀다.

반대로 맞지 않는 건 법적 책임이 직접 생기는 판단, 발생 빈도가 낮은 업무, 정답이 하나로 정해지지 않는데 하나의 답을 요구받는 업무다.

처음에 어디서부터 손댈까

업무를 쭉 뽑아서 '발생 빈도 × 1회당 소요 시간'으로 줄 세운다. 위에서부터 앞의 세 가지 조건에 맞는지 본다.

여기서 가장 큰 걸 고르지 않는다. 시간을 제일 많이 잡아먹는 업무는 대개 핵심 업무라서, 멈추면 사업이 멈춘다. 첫 대상은 두 번째나 세 번째, 잘 안 돼도 업무가 돌아가는 걸 고른다.

문의 메일 1차 분류, 사내 문서에서 정보 추출, 정형 리포트 초안 작성, 회의록 요약과 항목 추출. 이런 것들은 조건을 채우기 쉽고, 실패해도 사람이 다시 하면 된다.

PoC로 끝나는 이유

PoC를 했는데 남은 게 없다는 얘기가 많다. 원인은 대체로 세 가지로 좁혀진다.

평가 기준 없이 시작했다. 데모를 보고 "생각보다 똑똑하네"로 판단하면, 실제 데이터를 넣었을 때 무너진다. 데모는 잘 통하는 예시로 만들어져 있다.

비교 대상이 없다. "정확도 80%"만으로는 판단할 수 없다. 지금 그 업무를 사람이 할 때 정확도가 어느 정도인지 모르면, 80%가 도입할 만한 수준인지 알 수 없다.

업무 흐름에 얹는 얘기를 뒤로 미뤘다. 돌아가는 게 나와도, 누가 언제 쓰는지, 결과를 누가 확인하는지, 틀리면 어떻게 고치는지가 정해져 있지 않으면 그대로 멈춘다.

피하는 방법은 평가 데이터를 먼저 만드는 것

기술 검증보다 먼저 판단 재료를 준비한다.

1. 과거 실제 데이터를 50~100건 모은다. 깔끔한 샘플이 아니라 실제로 처리했던 것 중에서 무작위로 고른다. 예외적인 케이스도 넣는다
2. 사람이 정답을 단다. 그 업무 담당자가 원래 이래야 한다는 결과를 적는다. 여기서 담당자마다 답이 갈리면 업무 판단 기준이 아직 모호하다는 걸 알 수 있다. 이 시점에 발견하는 게 싸게 먹힌다
3. 합격선을 먼저 정한다. "이 업무에서는 100건 중 몇 건이 맞아야 사람의 확인 공수가 맞아떨어지는가"를 업무 쪽 언어로 정한다
4. 현재 수치를 잰다. 지금 사람이 할 때의 소요 시간과 오류율

여기까지 준비한 다음 가장 간단한 방법으로 시험한다. 프롬프트만 써도 합격선을 넘는 경우가 있다. 넘지 못하면 사내 문서를 검색해서 넘겨주는 구성(RAG)을 붙인다. 그래도 부족할 때 파인튜닝을 검토한다. 이 순서를 건너뛰면 필요 없는 구축 비용이 든다.

정확도는 보장할 수 없다

"정확도 99%를 보장합니다"라고 하는 상대는 의심하는 게 낫다. LLM은 같은 입력에 같은 출력을 낸다는 보장이 없고, 입력 데이터의 경향이 바뀌면 결과도 바뀐다. 100%는 안 된다.

현실적인 설계는 틀리는 걸 전제로 업무를 짜는 것이다.

• 결과에 신뢰도를 붙이고, 낮은 건 사람에게 넘긴다

• 전수가 아니라 일정 비율을 뽑아서 사람이 확인한다

• 입력과 출력 로그를 남겨서 나중에 오류 경향을 추적할 수 있게 한다

• 틀렸을 때 누가 어떻게 고칠지를 운영 시작 전에 정해둔다

도입 후에 정확도가 떨어지기도 한다. 다루는 문서 서식이 바뀌었거나 새 상품 카테고리가 늘었거나 하는 업무 쪽 변화가 원인이다. 계속 재는 구조가 없으면 떨어진 줄도 모른다.

비용을 보는 법

비용은 네 가지로 나뉜다. 초기 구축, API 사용료, 평가와 개선 운영, 사람의 확인 공수.

놓치기 쉬운 건 뒤의 두 가지다. 만들고 끝이 아니라, 매달 결과를 보고 프롬프트나 검색 대상을 계속 고치는 작업이 생긴다. 그 담당자를 정해두지 않은 프로젝트는 반년 뒤 아무도 안 보는 상태가 된다.

API 사용료는 입력 길이로 거의 정해진다. 사내 문서를 통째로 넘기는 구성이면 건당 단가가 확 뛰기 때문에, 필요한 부분만 넘기는 설계가 곧 비용 절감이다. 여기는 초기에 어떻게 만드느냐에 따라 몇 배 차이가 난다.

이 밖에 데이터 정비, 접근 권한 설계, 로그 보관이 필요하다. 기밀 문서를 다룬다면 어떤 데이터가 어디로 전송되는지도 정리해야 한다.

견적을 받기 전에 업무 쪽에서 하나를 정해두면 이야기가 빨라진다. "이 업무 1건을 처리할 때 얼마까지면 수지가 맞는가". 지금의 인건비에서 역산할 수 있다. 이 숫자가 있으면 구현 방법의 선택지를 금액으로 좁힐 수 있다.

진행 순서

1. 업무를 하나로 좁힌다 (빈도 × 시간으로 줄 세우고 2~3번째를 고른다)
2. 평가 데이터를 만든다 (실제 데이터 50~100건 + 정답 + 합격선)
3. 가장 간단한 방법으로 시험한다 (프롬프트 → RAG → 파인튜닝)
4. 합격선과 현재 수치로 비교한다
5. 업무 흐름에 얹는다 (사람의 확인 단계까지 포함해서 설계한다)
6. 로그를 쌓고 매달 다시 본다

2를 건너뛰고 3부터 시작하면 PoC에서 멈춘다. 순서 중에서는 여기가 가장 효과가 크다.

상담 안내

어떤 업무부터 시작할지 판단하는 것만으로도 사내에서 결론을 못 내는 경우가 있습니다. 저희는 평가 데이터를 만드는 법과 합격선을 정하는 법부터 시작하는 상담을 받고 있습니다. 기술 선정은 그다음 이야기입니다.

아직 사내 방침이 정해지지 않은 단계라도 괜찮습니다.

→ 상담하기