AI를 회사 업무에 붙이기 전에 확인할 것: 데모는 되는데 운영에서 깨지는 이유

AI 도입 전에 봐야 할 함정: 성능보다 먼저 확인할 5가지

AI 모델이 데모에서 잘 맞힌다고 해서 회사 업무나 제품에 바로 붙여도 되는 것은 아니다. 개인이 프롬프트로 실험할 때는 “오, 된다”로 끝나지만, 업무 시스템에 들어가는 순간 질문이 바뀐다. 이 답을 믿어도 되는가. 비용은 감당 가능한가. 고객 데이터는 어디까지 노출되는가. 여러 시스템이 동시에 움직일 때 상태가 꼬이지 않는가.

AI 역사를 만든 논문들은 단순한 교양 지식이 아니다. 튜링은 자동화의 경계를, 섀넌은 예측과 의미의 차이를, 램포트는 분산 시스템에서 순서가 깨지는 문제를 보여줬다. 이 관점으로 보면 AI 도입의 핵심은 “어떤 모델이 더 똑똑한가”가 아니라 “실패했을 때 잡아낼 구조가 있는가”다.

 

AI 기능을 고객에게 배포하기 전 비용, 보안, 검증, 시스템 상태 체크리스트를 확인하는 개발팀의 작업 장면

 

1. “모델이 답을 냈다”와 “문제가 풀렸다”는 다르다

AI 도입에서 가장 먼저 생기는 착각은 문제를 너무 깔끔하게 정의할 수 있다고 믿는 것이다. Alan Turing의 1936년 논문 On Computable Numbers는 계산 가능한 문제와 그렇지 않은 문제의 경계를 드러냈다. 특히 halting problem은 어떤 프로그램이 끝날지 영원히 돌지 일반적으로 판정하는 알고리즘은 없다는 점을 보여준다.

이 이야기는 추상적인 수학 문제가 아니다. AI에게 “이 계약서 위험한 부분 찾아줘”, “이 코드 배포해도 돼?”, “이 고객 문의 자동 처리해줘”라고 맡기는 순간, 우리는 애매한 판단을 자동화하려고 한다. 그런데 모든 판단을 완결된 입력과 출력으로 바꿀 수는 없다.

그래서 AI 도입 전에는 “AI가 할 일”보다 “AI가 판단하면 안 되는 경계”를 먼저 정해야 한다.

• 법적 책임이 생기는 판단인가?
• 고객에게 직접 노출되는 답변인가?
• 틀렸을 때 사람이 뒤늦게 발견할 수 있는가?
• 결과를 검증할 기준 데이터나 룰이 있는가?
• 실패했을 때 되돌릴 수 있는가?

 

이 질문에 답하지 못하면 모델 성능이 좋아도 위험하다. AI가 틀려서만 문제가 되는 것이 아니다. 애초에 자동화하면 안 되는 판단까지 자동화 대상으로 넣었기 때문에 문제가 된다.

 

 

 

2. 업무 시스템에서는 “그럴듯한 문장”이 가장 위험할 수 있다

Claude Shannon의 A Mathematical Theory of Communication은 메시지의 의미보다 전송, 불확실성, 정보량을 수학적으로 다뤘다. 다음 문자를 맞히는 방식으로 언어의 불확실성을 추정했다는 점은 오늘날 LLM의 next-token prediction을 떠올리게 한다. 물론 Shannon이 LLM을 만든 것은 아니다. 하지만 예측과 의미를 구분해야 한다는 경고는 지금도 유효하다.

업무에서 위험한 답은 노골적으로 이상한 답이 아니라, 자연스럽고 자신감 있어 보이는 답이다. 내부 정책 문서 요약이 매끄럽다고 해서 정책 해석이 맞는 것은 아니다. 고객지원 답변의 말투가 정중하다고 해서 환불 기준을 정확히 적용한 것도 아니다. 코드 리뷰 설명이 설득력 있다고 해서 실제 취약점이 사라진 것도 아니다.

AI를 업무에 붙일 때는 “잘 쓰는 모델”보다 “틀린 답을 걸러내는 구조”가 먼저 필요하다. 평가 기준을 별도로 잡아야 한다면 AI Evals란 무엇인가: LLM·RAG·코딩 에이전트를 위한 실전 평가 설계법을 함께 보는 편이 좋다.

 

확인할 것	어디서 확인할까	위험 신호	추천 판단
사실 검증 기준	원문 문서, DB, 테스트 케이스, 정책 파일	AI 답변만 보고 승인한다	내부 참고용까지만 사용
책임자	승인 플로우, 운영 매뉴얼	답변 오류 시 담당자가 없다	고객에게 보이는 기능은 보류
오류 추적	로그, 프롬프트 버전, 모델 버전	왜 그런 답이 나왔는지 재현할 수 없다	배포 전 로깅부터 구축
금지 주제	법무, 보안, 인사, 결제 정책	민감 판단을 AI가 단독 처리한다	사람 승인 필수

 

이 표에서 핵심은 “AI가 똑똑한가”가 아니다. 틀렸을 때 잡아낼 수 있는가다.

 

 

 

3. 한 번 잘 된 데모는 일반화의 증거가 아니다

Rosenblatt의 perceptron은 신경망의 출발점 중 하나로 자주 언급된다. 하지만 단일층 perceptron은 XOR 같은 단순 논리 문제도 풀 수 없다는 한계가 지적됐다. 이후 다층 구조와 역전파가 길을 열었지만, 이 흐름이 주는 실무 교훈은 더 단순하다.

한 조건에서 잘 맞힌 모델이 다른 조건에서도 잘 맞힌다고 보면 안 된다.

AI 기능을 붙일 때 팀에서 자주 하는 실수는 좋은 예시만 모아 데모를 만든 뒤 “이 정도면 됐다”고 판단하는 것이다. 하지만 실제 업무 데이터는 예쁘지 않다. 문서 형식이 다르고, 고객 표현이 흔들리고, 오래된 데이터가 섞이고, 예외 정책이 숨어 있고, 한국어와 영어가 섞이며, 사내 약어가 튀어나온다.

이때 문제는 모델이 “멍청하다”가 아니다. 검증에 들어가지 않은 패턴이 운영 중에 계속 들어온다는 점이다.

도입 전에 테스트 세트를 최소 세 갈래로 나눠야 한다.

1. 잘 될 것 같은 정상 케이스
2. 실제 업무에서 자주 나오는 지저분한 케이스
3. 틀리면 비용이나 보안 문제가 생기는 최악 케이스

세 번째 케이스를 통과하지 못하는 기능은 고객에게 보이는 화면으로 보내면 안 된다. 내부 보조 도구로 범위를 줄이거나, 사람 승인 단계를 붙인 뒤 다시 평가하는 편이 낫다.

 

 

 

4. 여러 시스템이 붙으면 정확도보다 순서가 먼저 깨진다

Leslie Lamport의 Time, Clocks, and the Ordering of Events in a Distributed System은 분산 시스템에서 사건의 순서를 어떻게 다룰지 설명한 고전이다. 여러 컴퓨터가 함께 움직일 때 벽시계 시간만 믿으면 안 되고, 무엇이 무엇보다 먼저 일어났는지 인과관계를 봐야 한다는 관점이 중요하다.

AI 기능도 혼자 떠 있는 챗봇일 때와 업무 시스템에 붙었을 때가 완전히 다르다. CRM, 결제, 고객지원, 사내 문서, 승인 시스템, 배치 작업이 연결되면 “AI 답변이 맞는가”보다 “어느 상태의 데이터를 보고 답했는가”가 더 중요해진다.

예를 들어 고객 등급이 바뀌었는데 AI가 이전 등급 기준으로 답변할 수 있다. 결제가 취소됐는데 상담 자동화가 취소 전 데이터를 보고 보상 안내를 할 수 있다. 개발 워크플로에서는 AI 에이전트가 오래된 브랜치를 기준으로 코드를 고치고, 다른 에이전트가 이미 바꾼 파일을 덮어쓸 수도 있다.

이 문제는 프롬프트만 다듬어서 해결되지 않는다. 상태 관리, 권한, 재시도, 잠금, 감사 로그가 필요하다. AI 도입을 “모델 연결”로만 보면 여기서 비용과 일정이 튄다.

 

 

 

5. 스케일은 성능을 올리지만 비용과 통제 문제도 같이 키운다

AlexNet 이후 딥러닝은 데이터, GPU, 모델 구조가 맞물릴 때 성능이 크게 달라질 수 있음을 보여줬다. 이후 Transformer 논문인 Attention Is All You Need와 OpenAI의 Language Models are Few-Shot Learners는 규모 확장이 언어 모델 성능에 어떤 영향을 줄 수 있는지 보여줬다.

하지만 실무에서 “크게 만들면 좋아진다”는 결론만 가져오면 위험하다. 스케일은 무료가 아니다. 모델 호출이 늘면 API 비용이 늘고, 문맥 길이가 길어지면 지연 시간이 늘고, 검색 증강을 붙이면 인덱싱과 권한 관리가 필요해진다. 자체 호스팅을 선택하면 GPU 비용과 운영 인력이 따라온다. 외부 API를 쓰면 데이터 반출, 계약, 감사, 장애 대응을 봐야 한다.

국내 팀에서도 “일단 써보고 좋으면 확장하자”는 접근이 자연스럽게 나온다. 개인 계정이나 작은 PoC에서는 괜찮을 수 있다. 하지만 고객 데이터, 사내 코드, 결제 정보, 인사 정보가 연결되면 PoC의 기준으로 운영 결정을 내리면 안 된다.

 

단계	해도 되는 것	하면 안 되는 것	판단 기준
개인 실험	공개 데이터로 프롬프트 테스트	회사 코드, 고객 정보 입력	민감 데이터가 없고 비용 상한이 낮다
팀 내부 도구	문서 검색, 초안 생성, 코드 보조	자동 승인, 자동 결제, 단독 배포	사람이 결과를 검토하고 로그가 남는다
부서 업무 적용	반복 문의 분류, 내부 리포트 보조	법무·보안·인사 판단 자동화	책임자, 예외 처리, 롤백이 있다
고객에게 보이는 제품	제한된 범위의 안내, 추천 보조	고위험 결정을 AI가 단독 수행	SLA, 감사 로그, 장애 대응, 금지 주제가 정리돼 있다

 

이 표에서 한 칸씩 올라갈수록 모델 성능보다 운영 기준의 비중이 커진다. AI 앱 개발 흐름 자체를 더 넓게 잡고 싶다면 2026년 AI 앱 개발 방법: 초보도 따라가는 9단계 실전 로드맵처럼 요구사항, 데이터, 평가, 배포 단계를 함께 보는 글이 이어서 읽기 좋다.

 

 

 

이런 조건이면 AI 도입을 보류하는 편이 낫다

AI 도입은 늦는 것보다 잘못 붙이는 것이 더 비쌀 때가 많다. 다음 조건이면 “도입”보다 “보류”가 더 합리적이다.

• 틀렸을 때 누가 책임지는지 정해져 있지 않다.
• 입력 데이터에 고객 정보나 사내 기밀이 섞이는데 반출 기준이 없다.
• AI 답변을 검증할 원문, 테스트, 로그가 없다.
• 비용 상한이 없고 사용량 증가를 추적하지 않는다.
• 모델 버전, 프롬프트 버전, 검색 인덱스 버전을 기록하지 않는다.
• 예외 상황을 사람이 넘겨받는 절차가 없다.

 

이 중 세 가지 이상이 해당하면 고객에게 보이는 기능으로 바로 내보내지 않는 편이 낫다. 내부 보조 도구로 범위를 줄이고, 로그와 검증 체계를 먼저 만든 뒤 다시 판단해야 한다.