중소기업의 AI 자동화, 실제로는 어디서 시작해야 할까

“기업용 AI 자동화”는 상위 수준에서는 쓸모 있는 답이 거의 없는 검색어입니다. 정직한 답은 “누군가의 일주일 중 어느 세 시간을 되찾고 싶은가”이기 때문입니다. AI 자동화에서 실제로 성과를 얻는 기업들은 기술에서 시작하지 않았습니다. 구체적이고, 반복적이고, 지겨운 업무 하나에서 출발해 거꾸로 풀어나갔습니다.

기술이 아니라 업무에서 시작하십시오

가장 흔한 실패 패턴은 나쁜 모델이나 나쁜 프롬프트가 아닙니다 — “AI로 뭔가 해야 한다”에서 출발해서 나중에야 붙일 문제를 찾는 것입니다. 그 결과는 작동하는 시스템이 아니라 데모입니다. 그리고 데모는 실제 데이터와 부딪히면 버티지 못합니다.

더 나은 출발 질문은 이렇습니다. 팀의 누군가가 매주 하는 일 중, 반복적이고, 규칙으로 설명할 수 있을 만큼 정형화되어 있고, 자동화되면 오히려 환영받을 만큼 지겨운 업무는 무엇인가? 문의 티켓 분류, 자주 묻는 유형에 대한 초안 답변 작성, 이메일로 오는 PDF에서 구조화된 데이터 추출, “주문이 어디쯤 왔나요” 같은 질문을 사람 기억이 아니라 지식베이스로 답하기. 화려하지 않지만, 자동화가 실제로 효과를 발휘하는 지점이 바로 여기입니다.

파일럿이 실제로 증명해야 할 것

대부분의 AI 프로젝트는 고정된 몇 주짜리 파일럿으로 진행하고, 작동하는 프로토타입과 실제 숫자로 끝을 맺습니다. AI가 이론적으로 할 수 있는 것을 약속하는 슬라이드가 아니라, 실제 데이터로 테스트하고 “이걸 믿을 만큼 잘 작동하는가”에 숫자로 답하는 시스템입니다.

신뢰할 만한 파일럿은 세 가지 질문에 답합니다.

얼마나 자주 맞는가? 데모에서 되느냐가 아니라, 지저분한 사례를 포함한 실제 표본 전체에서 얼마나 자주 정확하거나 수용 가능한 결과를 내는가입니다.

틀렸을 때는 어떻게 되는가? 오류율이 0보다 큰 것은 모든 자동화의 숙명입니다. 문제는 잘못된 답이 고객에게 도달하기 전에 잡히는지, 재검토가 필요할 때 검토자가 무엇을 보게 되는지입니다.

실제로 시간을 절약하는가? 검토에 들이는 시간이 원래 사람이 하던 시간과 비슷하다면 아무것도 절약한 게 아닙니다. 작업이 옆으로 옮겨간 것뿐입니다.

데이터 처리는 파일럿의 일부이지, 나중에 덧붙이는 게 아닙니다

EU 개인정보보호규정(GDPR, 2018년 5월부터 시행)의 적용을 받는 기업에게 “어떤 모델을, 데이터가 어디로 가는 조건으로” 쓸 것인가는 부차적인 질문이 아니라 다른 모든 구축 작업과 마찬가지로 설계 단계의 제약 조건입니다. 저희는 학습에 사용하지 않는다는 조건의 API 제공사나 EU 내에서 호스팅되는 모델을 사용합니다. 고객 데이터가 누군가의 다음 학습 라운드에 들어가지 않도록 하기 위해서입니다. 이 결정은 파일럿이 끝난 뒤 감사하는 게 아니라 시작 전에 내려야 합니다.

질문	왜 중요한가
데이터가 물리적으로 어디로 가는가	GDPR / 데이터 거주지
모델 학습에 사용되는가	추측이 아니라 제공사 약관으로 확인
신뢰도가 낮을 때 대안은 무엇인가	검토 부담을 결정
플래그된 사례는 누가 검토하는가	인력 배치, 도구만의 문제가 아님
정확도는 어떻게 측정하는가	“작동한다”를 숫자로 바꿈

대부분의 경우 더 큰 모델보다 검색이 낫습니다

결과가 실망스러우면 더 강력한 모델을 찾는 게 본능적인 반응입니다. 하지만 실제 간극은 대개 검색(retrieval)에 있습니다 — 시스템이 답의 근거로 삼을 사내 문서, 티켓, 기록을 제대로 찾아내지 못하는 것이지, 모델 품질의 문제가 아닌 경우가 많습니다. RAG(검색 증강 생성)와 벡터 검색이 존재하는 이유는 모델의 일반 지식이 여러분 사업의 구체적인 지식과 다르기 때문이고, 빠져 있는 건 대개 후자입니다. 모델을 바꾸는 것보다 검색을 제대로 맞추는 일이 덜 화려하지만, 실제 정확도 대부분은 거기서 나옵니다.

워크플로 자동화에는 모델이 필요 없을 때도 많습니다

“AI가 필요하다”고 느껴지는 것 중 상당수는 실제로는 배관 문제입니다. 한 시스템에 있는 데이터가 일정이나 트리거에 따라 다른 시스템에서 어떤 동작을 일으켜야 하는 것뿐, 판단이 개입할 여지는 없습니다. 그건 평범한 워크플로 자동화이자 연동 작업이고, 브리프에 “AI”라는 단어가 들어갔다는 이유만으로 결정론적 작업을 언어 모델에 태우는 것보다 대개 더 빠르고, 더 저렴하게 돌아가고, 더 안정적입니다.

벤더를 고를 때 물어야 할 질문

내부 팀이든 외부 벤더든, 계약 전에 답을 들어야 하는 질문이 있습니다. 모델이 틀린 답을 냈을 때 책임은 누구에게 있는가? 파일럿이 끝난 뒤에도 같은 사람들이 유지보수를 맡는가, 아니면 다른 팀으로 조용히 인계되는가? 계약이 끝나거나 벤더가 서비스를 접으면, 그동안 다듬어온 프롬프트와 검색 인덱스, 분류 규칙은 누구 것이 되는가? 이런 질문에 선뜩 답하지 못하는 상대는 파일럿 단계에서는 문제가 없어 보여도 운영 단계에서 반드시 틀어집니다.

마찬가지로 중요한 질문은 “이 업무를 비슷하게 풀어본 적이 있는가”입니다. 문의 티켓 분류와 계약서 검색은 둘 다 편의상 “AI”라고 부르지만 요구하는 기술과 실패 방식이 다릅니다. 일반론으로 답하는 상대보다, 비슷한 업무에서 처음 시도가 왜 틀렸고 무엇을 바꿔 고쳤는지 구체적인 사례로 말하는 상대가 신뢰할 만합니다. 사례가 없다는 것 자체가 결격 사유는 아니지만, 그렇다면 파일럿 기간과 검증 기준을 더 넉넉하게 잡아야 한다는 뜻입니다.

마지막으로 확인할 것은 통제권입니다. 프롬프트, 분류 규칙, 검색 인덱스 설정을 여러분이 직접 열람하고 수정할 수 있는지, 아니면 전부 상대의 블랙박스 안에 있는지는 나중에 다른 팀으로 유지보수를 옮기거나 벤더를 바꿀 수 있는지를 결정합니다. 지금 당장 옮길 계획이 없더라도, 옮길 수 있는 구조와 옮길 수 없는 구조는 협상력 자체가 다릅니다.

파일럿 이후 확장하기

파일럿이 증명되면 확장은 모델보다 운영 체계에 달려 있습니다. 시간이 지나며 정확도가 흔들리지 않는지 모니터링하고, 플래그된 사례 큐가 조용히 쌓이지 않도록 명확한 담당자를 두고, 자동화가 추측 대신 사람에게 넘겨야 할 때를 문서화된 절차로 정해두는 것입니다. 이걸 건너뛰면 테스트에서는 잘 작동했던 파일럿이 아무도 모르는 사이에, 고객이 알아차릴 때까지 프로덕션에서 조용히 무너집니다.

파일럿 자체의 “끝”이 무엇인지도 미리 정해두는 게 좋습니다. 고정된 3~5주 일정이 효과적인 이유는 종료일과 산출물이 명확하기 때문이지, 행동 가능한 숫자를 결코 내놓지 않는 열린 탐색이 아니기 때문입니다.

저희라면 실제로 어디서 시작할지

구체적인 업무, (필요하면 익명화된) 실제 데이터 표본, 그리고 이미 추적하고 있는 숫자로 “충분히 좋다”가 무엇을 의미하는지를 먼저 여쭤봅니다. 응답 시간, 오류율, 소요 시간 같은 것들입니다. 거기서부터 짧은 파일럿이 실제 숫자로 사례를 증명하거나, 진짜 예산을 투입하기 전에 기각합니다. work 페이지에 소개된 저희 자체 제품들도 같은 원칙으로 만들어졌습니다 — 지겹고 반복적인 부분을 자동화하고, 판단이 필요한 일은 사람에게 맡깁니다.

파일럿의 역할은 여러분을 감동시키는 게 아닙니다. 확장할 가치가 있는지 숫자로 말해주는 것입니다.

구체적으로 염두에 둔 업무가 있다면, 문의 페이지에서 대화를 시작하는 것이 AI가 일반적으로 할 수 있는 일을 다시 읽는 것보다 아이디어를 빠르게 검증하는 방법입니다.