Samsung SDS

Executive Summary

• AI 경쟁력의 패러다임 전환: 기업 AX의 핵심이 '최고 성능 모델의 확보'에서 '업무 목적에 따른 유연한 모델 교체 및 통제 능력'으로 이동하고 있습니다.
• 데이터 기반의 실무적 선택 기준: 일반 벤치마크가 아닌 자사 업무 맞춤형 기반의 품질 평가, 인프라, 인적 비용을 포함한 운영 기준 정립이 필수적입니다.
• 지속 가능한 AI 거버넌스 구축: AI 게이트웨이와 컨트롤 플레인을 통해 모델 종속성을 탈피하고, AI 기본법 등 법적 규제와 보안 가이드라인을 반영한 통합 관리 체계를 구축해야 합니다.

기업이 AI를 도입할 때 가장 먼저 결정해야 하는 것은 무슨 모델을 선택할 것인지이다. 모델에 따라 성능이나 비용이 달라지기 때문에 모델 선택이 첫 번째 결정해야 할 사항이다. 그런데, 막상 실제 운영을 하다보면 모델 자체가 중요한 것이 아니라 모델이 업그레이드되었을 때, 더 나은 모델을 찾았을 때 이를 어떻게 전환할 것인지가 더 중요해진다. 즉, 새 모델이 나올 때마다 바꿔야 하는가? 바꾼 뒤 품질이 떨어지면 어떻게 알아낼 것인가? 비용과 지연이 급증하면 어디까지 자동으로 되돌릴 것인가? 고객 데이터와 규제 요건을 만족하는 대체 모델은 준비돼 있는가? 라는 질문을 하게 된다. 이제 AI 모델은 한 번 선택해 계속 쓰는 것이 아니라 필요에 따라 수시로 교체하는 핵심 부품에 가깝다. 기업 경쟁력도 최고 성능의 모델을 먼저 확보하는 데서 나오지 않는다. 바뀌는 모델을 안전하게 시험하고 승인하고 배포하고 되돌리는 능력에서 나온다. 모델은 갈아 끼울 수 있어야 한다. 업무 품질과 책임은 흔들리지 않아야 한다. 이것이 AI 모델 변경 관리와 통제가 필요한 이유다.

최신 AI 모델 어디까지 어떻게 경쟁 중인가?

생성형 AI의 첫 경쟁은 파라미터의 크기였다. GPT-3 이후 시장은 파라미터 수와 학습에 투입된 GPU 수를 모델의 잠재력으로 받아들였다. 큰 모델이 더 많은 지식과 더 복잡한 패턴을 담을 수 있다는 스케일링 법칙도 이를 뒷받침했다. 이 경쟁이 끝난 것은 아니다. 프런티어 모델의 학습 연산량과 데이터 규모는 여전히 커지고 있다. 다만 파라미터 수만으로 실제 경쟁력을 설명하기 어려워졌다. 파라미터는 엔진 배기량과 같다. 잠재 성능은 말해주지만, 도로에서 얼마나 빠르고 안전하며 경제적으로 달리는지는 알려주지 못한다.

그렇게 모델의 평가 기준으로 더 이상 파라미터 수가 아니게 된 이유는 성능 격차가 좁아진 덕분이다. Stanford AI Index 2026에 따르면 2026년 3월 기준 주요 4개 기업의 모델은 Arena 평가에서 대동소이했다. 미국과 중국의 최고 모델 격차도 2.7%였다. 최고 폐쇄형 모델과 최고 오픈웨이트 모델의 격차는 3.3%였다. 어느 한 기업이 모든 과제에서 압도적 우위를 유지하기 어려워졌다는 것이다. 그렇다 보니 기업 입장에서는 모델 자체보다 어떤 업무에서 얼마나 안정적으로 성과를 내는지가 더 중요해졌다. 또한, 작은 모델의 효율이 급격히 좋아진 것도 변화의 원인이다. Stanford AI Index 2025는 MMLU 60%를 넘긴 최소 모델이 2022년 5,400억 파라미터의 PaLM에서 2024년 38억 파라미터의 Phi-3-mini로 줄었다고 분석했다. 같은 수준에 필요한 크기가 2년 만에 142분의 1이 된 셈이다. GPT-3.5 수준의 MMLU 성능을 얻는 추론 비용도 2022년 11월 100만 토큰당 20달러에서 2024년 10월 0.07달러로 280배 이상 낮아졌다. 이제 단순한 크기보다 지능 대비 비용이 시장을 움직인다.

최근에는 기술적으로 MoE(Mixture of Experts)가 모델의 성능을 높이는 대안으로 주목받고 있다. MoE는 거대한 모델 안에 여러 전문가 모듈을 두고 입력마다 일부만 활성화한다. 그로 인해 총 파라미터는 크지만 실제 추론에 쓰는 활성 파라미터는 작다. Qwen과 DeepSeek 계열이 이 방식을 적극 활용했다. 그렇다 보니 모델의 성능이 파라미터가 크다고 무조건 품질이 좋은 것만은 아니다. 이제는 총 파라미터에서 활성 파라미터와 메모리 사용량을 보면서 모델의 성능과 운용 비용을 균형 있게 살펴봐야 한다. 여기에 양자화와 증류를 적용하면 특정 업무는 더 작은 모델로 처리할 수 있다. 소형 모델이라고 평가 절하할 것이 아니라 되려 분류와 정보 추출처럼 범위가 좁고 반복량이 많은 업무에서는 더 나은 대안이 될 수 있다.

최근 중국 오픈웨이트 모델의 확산도 모델의 경쟁 구도를 바꾸고 있다. Qwen3와 DeepSeek 계열은 모델 가중치를 공개해 다양한 파생 모델들이 만들어질 수 있는 계기를 만들고 있다. OpenAI도 gpt-oss를 Apache 2.0 라이선스로 공개했다. 오픈웨이트는 모델을 자체 인프라에서 운영하고 세부 조정할 수 있다는 장점이 있다. 데이터 주권이 중요한 기업에는 FM에 의존하지 않고 자체적인 모델을 만들어 독립할 수 있는 기회가 생긴 셈이다. 또한, 모델의 성능을 높이는 데 있어 후행학습도 중요해지고 있다. 지시 튜닝, 선호 최적화와 강화학습을 거치며 같은 기반 모델이라도 성능이 크게 달라진다. 코드와 수학처럼 검증 가능한 분야에서는 합성 문제와 자동 채점이 성능 향상에 도움을 준다. 반면 검증되지 않은 합성 데이터만 되풀이하면 오류와 편향도 복제된다. 기업 데이터의 가치도 단순한 문서량에서 업무의 성공과 실패까지도 기록한 피드백으로 이동한다. AI가 준 답이 실제 업무 성과로 이어졌는지, Agent가 호출한 도구가 실효성이 없었는지 등을 기록으로 남겨야 더 가치가 있는 것이다. 기반 모델은 살 수 있지만, 이 운영 피드백은 기업이 직접 축적해야 한다.

또 다른 모델 운용의 경쟁 축은 추론 예산이다. 최신 추론 모델은 모든 요청에 같은 양의 연산을 쓰지 않는다. 업무 난이도와 설정에 따라 생각하는 깊이를 달리한다. 단순한 업무는 추론 강도를 낮춰 응답 시간과 비용을 줄이고 복잡한 코딩과 연구에는 더 많은 연산을 투입한다. GPT-6 Astra는 추론 강도를 low부터 max까지 다섯 단계로 조절한다. Claude Fable 5.1도 다섯 단계의 effort 설정으로 성능과 비용을 조율한다. 대화 도중에도 추론 강도를 바꿀 수 있다. Gemini 3.8 Flash 역시 사고 수준을 설정해 추론 깊이를 조절한다. 모델 하나를 고르는 시대에서 업무별로 모델과 사고 시간을 함께 배분하는 시대로 넘어간 것이다. 기업의 운영 역량도 어떤 AI를 도입했느냐에서 어떤 업무에 얼마만큼 생각하게 하느냐로 확장된다.

특히 최근의 AI는 Agent 기반으로 실행하는 AI로 바뀌면서 이미지와 음성과 비디오를 함께 이해하고 검색과 코드 실행 그리고 사내 API도 호출한다. 브라우저와 업무 도구를 다루며 여러 단계를 이어가며 완결적인 작업을 수행한다. 모델의 경쟁 단위가 한 번의 정답을 생성해 주는 것에서 작업 완료율로 확장된 셈이다. 좋은 모델은 문장을 잘 만드는 모델에 머물지 않고 상황을 파악해 필요한 도구를 골라 실제 실행해 내야 한다. 이 때문에 컴퓨터 사용과 도구 호출 그리고 장기 에이전트 과제가 새로운 평가 항목이 됐다.

이렇게 AI의 경쟁이 모델에서 Agent의 작업 성공률로 옮겨지면서 AI에 대한 성능 평가의 변수도 Agent의 성공률을 중요한 잣대로 삼고 있다. AI Index 2026은 구조화된 에이전트 평가에서 최신 시스템도 대략 세 번 중 한 번은 실패한다고 지적한다. 단계가 길어질수록 오류가 누적되는 문제도 있다. 각 단계의 성공률이 95%이고 오류가 서로 독립이라고 단순 가정해도 20단계를 모두 통과할 확률은 약 36%다. 실제 에이전트 오류는 서로 영향을 주기 때문에 더 복잡하다. 한 단계의 잘못된 검색이 다음 추론과 도구 호출까지 오염시킬 수 있다. 기업이 봐야 할 것은 반복 실행에서의 완주율과 복구율이다.

결국 최신 모델 경쟁은 파라미터 수를 넘어 도구를 호출하고 컴퓨터를 조작해 작업을 완결적으로 처리하는 Agent와 같은 작업을 처리하더라도 더 싸고 빠르게 실행하는 효율성으로 바뀌고 있다. 그만큼 AI를 도입해 사용하는 기업은 목적과 용도에 따라 적정 모델을 바꿔가며 보다 효율적으로 그리고 완성도 높게 사용할 수 있는 운영 역량을 갖춰야 한다.

기업 AX를 위한 모델 선택과 운영의 기준

기업의 모델 선택은 무슨 기술이 더 나은지가 아니라 업무 설계에서 시작해야 한다. 즉, “가장 좋은 모델이 무엇인가”보다 “어떤 업무를 어느 수준의 품질과 비용과 시간 안에 끝낼 것인가”를 먼저 정의해야 한다. 고객 문의에 답하는 업무와 대출 심사를 보조하는 업무는 같은 기준으로 모델을 선택할 수 없다. 사내 문서를 요약하는 업무와 생산설비를 멈추는 명령을 내리는 업무도 모델 선택의 기준이 다르다. 모델보다 먼저 업무의 중요성과 실패 시 손실 비용을 비교해 모델을 선택해야 한다.

그렇다면 어떤 기준으로 업무 설계를 하고 AI 모델을 선택해야 할까?

첫 번째 기준은 실제 업무에서의 품질이다.

공개된 벤치마크에서 높은 점수를 받았다고 우리 회사의 업무도 잘 처리하는 것은 아니다. 예를 들어 고객의 반품 문의에 답하는 AI라면 반품 규정을 아는 것만으로는 부족하다. 구매 시점과 상품 상태를 확인하고 예외 조건까지 반영해 고객에게 필요한 안내를 해줘야 한다. 이를 평가하려면 실제 업무에서 자주 접하는 질문과 적절한 처리 결과를 모은 골든셋이 필요하다. 여기에 평범한 문의뿐 아니라 담당자도 판단하기 어려웠던 사례와 과거 사고 사례를 포함해야 한다. 한국어와 사내 용어를 제대로 이해하는지도 중요하다. 기업의 지시를 무시하도록 유도하거나 민감정보를 요구하는 입력도 시험해 봐야 한다. 그렇게 자사 업무를 담은 문제로 평가해야 모델이 답을 얼마나 잘하는지와 실제 일을 얼마나 잘하는지를 구분할 수 있다.

그런데 이런 평가는 한 번 실행해 보는 것으로 끝나지 않는다. 생성형 AI는 같은 질문에도 다른 답을 할 수 있기 때문에 중요한 사례는 반복해서 실행하며 결과가 얼마나 일관적인지 살펴야 한다. 평균 점수가 높더라도 특정 고객의 문의에서 오류가 반복되거나 복잡한 조건이 붙을 때 품질이 급격히 떨어진다면 실제 서비스에 쓰기 어렵다. 평가할 때도 정답 여부와 함께 근거를 제대로 제시하는지와 정해진 출력 형식을 지키는지를 봐야 한다. Agent라면 필요한 도구를 정확히 사용해 업무를 끝냈는지까지 확인해야 한다. 다른 LLM을 심사위원으로 활용할 수도 있지만 그 판단이 현업 전문가의 평가와 얼마나 일치하는지 먼저 검증할 필요가 있다. Microsoft도 Model Router의 평가에서 실제 업무를 대표하는 요청으로 품질과 비용을 비교하고 운영 조건에서 다시 확인하도록 안내한다. 결국 기업에 필요한 것은 자사 업무에 맞는 시험 문제와 합격 기준이다.

두 번째 기준은 업무 한 건을 성공적으로 처리하는 데 들어가는 총비용이다.

모델 가격표에 적힌 100만 토큰당 요금은 이 비용의 일부에 불과하다. 저렴한 모델이 질문을 잘못 이해해 여러 번 다시 답하거나 불필요한 검색과 도구 호출을 반복하면 전체 비용은 늘어난다. 여기에 직원이 결과를 검토하고 수정하는 시간까지 더하면 처음부터 성능이 좋은 모델을 쓰는 편이 더 경제적일 수 있다. 따라서 모델 호출료와 검색 및 도구 사용료에 인프라 비용과 사람의 검토 비용까지 합산해야 한다. 이를 품질 기준을 통과한 업무 건수로 나누면 성공한 업무 한 건의 비용을 알 수 있다. 이 기준으로 보면 개발팀의 비용 절감과 사업팀의 생산성 개선을 같은 관점에서 평가할 수 있다. 모델 이용료는 줄었는데 고객의 재문의와 직원의 재작업이 늘었다면 기업 전체로는 비용을 줄인 것이 아닌 셈이다.

세 번째는 사용자가 체감하는 속도와 서비스의 안정성이다.

고객 상담에서는 질문을 한 뒤 첫 반응이 얼마나 빨리 오는지가 중요하지만, 보고서 작성은 다소 시간이 걸리더라도 완성도가 더 중요할 수 있다. 따라서 첫 토큰이 나올 때까지의 시간인 TTFT(Time to First Token)와 전체 작업이 끝나는 시간을 구분해서 봐야 한다. 평균 응답시간이 짧아도 일부 고객이 유난히 오래 기다린다면 서비스에 대한 평가는 달라진다. 요청의 95%나 99%가 완료되는 데 걸리는 시간인 p95와 p99를 함께 살펴야 하는 이유다. 특히 Agent는 모델의 답변 이후에도 검색과 외부 시스템 호출을 이어가므로 이 과정 전체를 측정해야 한다. 클라우드 공급사가 약속한 가용성 SLA(Service Level Agreement)만으로 이런 업무 품질까지 보장받을 수는 없다. 기업은 고객에게 어느 정도의 응답시간과 완료율을 제공할 것인지 자사의 서비스 목표인 SLO(Service Level Objective)를 별도로 정해야 한다.

네 번째는 기업 데이터가 어디까지 이동하고 누가 통제하는가이다.

공급사가 고객 데이터를 모델 학습에 사용하지 않는다고 해도 그것만으로 데이터 관리에 대한 검토가 끝나는 것은 아니다. 실제 추론이 어느 지역에서 처리되는지와 입력 및 출력이 어디에 얼마나 오래 저장되는지를 확인해야 한다. 오남용 탐지를 위해 데이터를 검토하는 과정에서 누가 접근할 수 있는지도 살펴볼 필요가 있다. 여러 지역의 인프라를 활용하면 장애에 대응하기 쉽고 처리량도 늘릴 수 있지만 데이터 처리 지역이 달라질 수 있다. 금융과 의료처럼 민감한 정보를 다루는 기업은 이런 차이가 모델의 성능 점수보다 중요할 수 있다. 결국 모델 선택에는 기술적인 성능과 함께 기업이 허용할 수 있는 데이터의 이동 범위까지 포함돼야 한다.

다섯 번째는 도구를 사용하는 능력과 그에 따른 보안이다.

고객에게 환불 규정을 잘못 설명하는 것과 실제로 잘못된 금액을 환불하는 것은 기업에 미치는 영향이 다르다. Agent를 평가할 때는 적절한 도구를 선택했는지에 더해 대상 고객과 금액 같은 실행 조건을 정확히 전달했는지까지 확인해야 한다. 통신 오류로 결과를 받지 못했을 때 같은 환불을 다시 실행하지 않는지도 중요하다. 이를 위해 같은 요청을 반복해도 거래가 중복 처리되지 않도록 하는 멱등성을 업무 시스템에서 보장할 필요가 있다. 또한 삭제와 결제 등 되돌리기 어려운 행동에는 위험 수준에 맞는 사람의 승인 절차를 둬야 한다. 모든 도구를 한꺼번에 AI에게 보여주기보다 현재 업무에 필요한 도구를 제공하는 것도 도움이 된다. 도구 설명을 읽는 비용을 줄이고 엉뚱한 기능을 선택할 가능성도 낮출 수 있기 때문이다.

여섯 번째는 모델을 얼마나 수월하게 교체할 수 있는가이다.

API 형식이 비슷하다고 모델의 행동까지 같지는 않다. 같은 프롬프트를 입력해도 답변이 지나치게 길어지거나 이전에는 처리하던 요청을 거부할 수 있다. 도구를 호출하는 방식과 처리할 수 있는 문서의 길이도 다르다. 그렇다 보니 여러 서비스가 특정 모델을 직접 호출하도록 개발하면 모델을 바꿀 때마다 수정해야 할 곳이 늘어난다. 기업 내부에 AI 게이트웨이라는 공통 접점을 두고 모델별 차이를 어댑터에서 처리하면 이런 부담을 줄일 수 있다. 서비스가 주고받는 메시지와 도구의 형식은 공통으로 관리하되 모델마다 다른 기능은 별도로 연결하는 방식이다. 이때 모든 모델에 공통으로 있는 기능만 쓰겠다고 하면 각 모델의 장점을 활용하기 어렵다. 공통 구조를 갖추면서도 필요한 곳에서는 특정 모델의 강점을 사용할 수 있도록 설계하는 것이 현실적이다.

이 기준을 적용하면 기업의 AI 운영도 자연스럽게 여러 모델이 역할을 나누는 구조로 바뀐다. 정해진 규칙으로 처리할 수 있는 요청은 기존 프로그램이 맡고 반복적인 분류와 정보 추출은 해당 업무에서 검증된 소형 모델로 처리할 수 있다. 복잡한 분석과 추론이 필요한 업무에는 더 높은 성능의 모델을 배치하는 식이다. 기밀정보를 다루는 업무는 승인된 전용 환경에서 처리하고 외부 연결 없이 즉시 반응해야 하는 기능은 온디바이스 모델을 검토할 수 있다. 다만 큰 모델에 중요한 일을 맡긴다고 해서 안전성까지 확보되는 것은 아니다. 업무의 난이도와 데이터 민감도에 맞춰 모델을 선택하고 실행 권한은 별도로 통제해야 한다. 모델의 크기에 따라 서열을 정하기보다 각 업무를 가장 적절하게 처리할 수 있는 조합을 찾는 것이다.

이렇게 여러 모델을 운영할 때 요청을 어디로 보낼지 결정하는 것이 라우팅이다. 먼저 데이터 처리 지역과 보안 정책을 기준으로 사용할 수 있는 모델을 정한 뒤 그 안에서 업무의 품질과 비용을 비교해 선택해야 한다. 단순히 요청을 여러 서버에 나누는 로드밸런싱이나 장애가 발생했을 때 대체 모델을 호출하는 폴백과는 목적이 다르다. 이런 기능은 이미 상용 서비스에도 들어와 있다. Amazon Bedrock의 Intelligent Prompt Routing은 같은 모델 계열 안에서 예상 응답 품질과 비용을 고려해 요청을 분배한다. Microsoft Foundry의 Model Router도 대화 이력과 도구 정의를 포함한 요청을 분석해 모델을 선택하고 비용이나 품질을 우선하는 설정을 제공한다. 다만 기업은 실제로 어떤 모델이 선택됐고 그 결과 업무 품질이 어떻게 달라졌는지를 계속 확인해야 한다. 라우터를 도입한 뒤에도 자사 업무에 맞는 평가와 조정은 필요한 것이다.

그렇다 보니 기업의 AX 플랫폼도 모델을 여러 개 연결하는 수준에서 한 단계 더 나아가야 한다. AI 게이트웨이가 요청을 받아 적절한 모델로 보내면 컨텍스트 관리 기능은 사내 문서를 검색하는 RAG(Retrieval-Augmented Generation)와 이전 업무에서 축적한 기억을 연결해 준다. 평가 체계는 모델을 교체해도 기존 업무가 제대로 처리되는지 검증하고 모니터링 체계는 품질과 비용 및 지연을 함께 살핀다. 여기에 접근 권한과 안전장치를 집행하는 정책 관리가 필요하다. 어떤 모델과 프롬프트에 어떤 데이터와 도구를 연결했는지 기록하는 버전 관리도 갖춰야 한다. 이 기능들이 함께 작동해야 문제가 생겼을 때 원인을 찾고 영향을 받은 서비스만 조정할 수 있다. 기업의 운영 부담을 줄이는 것은 연결한 모델의 개수보다 이런 공통 관리 기능의 완성도인 셈이다.

다행히 연결 표준의 확산도 이런 운영 구조를 만드는 데 도움이 된다. 모델을 활용하는 애플리케이션과 외부 데이터 및 도구를 연결하는 MCP(Model Context Protocol)는 2025년 12월 Linux Foundation 산하 Agentic AI Foundation의 출범과 함께 기증됐다. Google이 시작한 에이전트 간 통신 규격인 A2A 역시 Linux Foundation 프로젝트로 출범했다. 공통 규격이 자리 잡으면 모델이나 도구를 바꿀 때마다 연결 방식을 새로 개발하는 부담을 줄일 수 있다. 그렇다고 규격이 같다는 이유만으로 모든 서버와 Agent를 신뢰할 수는 없다. 상대의 신원을 확인하고 어떤 데이터와 기능에 접근할 수 있는지 정하는 일은 여전히 기업의 몫이다. 앞으로 플랫폼을 선택할 때도 연결의 편리함과 함께 사내 문맥과 정책 및 운영 기록을 얼마나 쉽게 옮길 수 있는지 살펴야 한다. 모델을 바꾸기 쉬워져도 이 자산이 특정 플랫폼에 묶이면 전환의 부담은 여전히 남기 때문이다.

사용자 경험 역시 모델 선택 과정에서 빠져서는 안 된다. 고객은 서비스 내부에서 어떤 모델을 사용하는지보다 질문에 일관되게 답하고 필요한 일을 제대로 처리해 주는지를 중요하게 여긴다. 새 모델의 성능이 좋아졌더라도 익숙한 답변 형식이 갑자기 달라지거나 근거 링크가 사라지면 오히려 불편함을 느낄 수 있다. 안전 정책의 변화로 평소에 하던 문의가 거절되는 것도 마찬가지다. 따라서 답변의 말투와 인용 방식부터 AI가 해결하지 못했을 때 상담사에게 연결하는 과정까지 서비스 기준으로 정해둘 필요가 있다. 모델을 교체할 때는 이런 경험이 유지되는지도 함께 시험해야 한다. 기업 입장에서는 기술 업그레이드이지만 사용자에게는 매일 쓰던 서비스의 변화이기 때문이다.

이를 운영하는 조직의 역할도 분명해야 한다. 중앙 AI 플랫폼 팀이 모델 연결과 평가 도구 및 공통 정책을 제공한다면 현업은 어떤 결과를 업무의 성공으로 볼 것인지 정해야 한다. 법무 업무를 지원하는 AI의 답이 적절한지는 법무 담당자가 판단해야 하고 보안과 개인정보 담당자는 허용할 데이터와 실행 범위를 설계해야 한다. 이 역할이 맞물려야 개별 부서의 실험이 기업 전체의 운영 체계로 이어진다. 모델은 외부에서 조달하고 필요에 따라 바꿀 수 있지만 자사 업무의 합격 기준과 실패 경험은 기업이 직접 쌓아야 한다. 그렇게 축적한 데이터와 평가 기준이 있어야 새로운 모델이 나왔을 때도 자사에 도움이 되는지를 빠르게 판단할 수 있다.

모델 성능 경쟁에서 운영 관리로의 전환

기업이 이런 운영 구조를 갖춰야 하는 이유는 모델의 변경이 서비스의 행동까지 바꿀 수 있기 때문이다. 일반 소프트웨어도 업데이트 이후 문제가 생기지만 AI는 API가 정상적으로 작동하는데도 업무 결과가 달라질 수 있다. 고객에게 보여주는 문체와 인용 방식이 바뀌거나 도구에 전달하는 조건이 미묘하게 달라지는 식이다. 안전 필터가 강화되면서 정상적인 요청까지 거부할 수도 있고 반대로 이전에는 막았던 위험한 요청을 허용할 수도 있다. 개발팀이 오류 없이 배포를 마쳤다고 해도 현업에서는 전혀 다른 서비스를 쓰게 될 수 있는 것이다. 따라서 모델 변경은 기능의 작동 여부와 함께 결과의 의미와 실행 범위까지 확인하는 과정이어야 한다.

게다가 모델의 교체는 기업이 원할 때만 하는 일이 아니다. 공급사가 기존 모델의 제공을 종료하면 기업도 정해진 시점 안에 대안을 찾아야 한다. Anthropic은 공개 모델의 서비스 종료 전에 최소 60일의 사전 통지를 제공한다고 안내한다. 실제로 Claude Opus 4.1은 2026년 6월 5일 종료가 예고됐고 8월 5일 Claude API에서 제공이 끝났다. 다만 같은 모델이라도 이용하는 클라우드에 따라 종료 일정은 다를 수 있다. 최신 모델로 자동 연결되는 별칭을 사용하면 관리가 편리하지만 실제 연결되는 모델이 바뀔 수 있고 특정 버전을 고정해도 언젠가는 지원 종료에 대응해야 한다. 어느 방식을 선택하든 변경을 미리 파악하고 시험할 수 있는 준비가 필요한 셈이다.

그 준비의 출발점은 사내에서 어떤 AI를 어디에 사용하는지 파악하는 것이다. 기업의 여러 부서가 각자 AI 서비스를 개발하다 보면 같은 공급사의 모델도 서로 다른 버전과 계약으로 사용하는 경우가 생긴다. 이런 상태에서는 종료 공지를 받아도 어떤 업무가 영향을 받는지 바로 알기 어렵다. 따라서 모델의 공급사와 정확한 버전 및 배포 지역을 서비스별로 기록해야 한다. 어떤 데이터를 다루고 외부 시스템에서 무엇을 실행할 수 있는지도 연결해 관리할 필요가 있다. 여기에 업무 담당자와 변경 승인자 및 장애 발생 시 연락할 사람까지 정해두면 모델 변경의 영향 범위와 대응 책임을 빠르게 확인할 수 있다. 기존 IT 자산 관리에 AI의 사용 목적과 권한을 함께 담는 것이다.

관리할 대상의 범위도 모델 자체보다 넓어져야 한다. 같은 모델을 사용해도 시스템 프롬프트나 추론 강도를 바꾸면 결과가 달라진다. RAG가 검색하는 문서와 문서를 나누는 방식이 바뀌어도 답변에 사용되는 근거가 달라질 수 있다. 도구의 입력 형식과 접근 권한은 물론 Agent의 실행 순서를 관리하는 프로그램의 버전도 영향을 준다. 따라서 배포할 때는 이런 구성을 하나의 묶음으로 기록해야 한다. 그래야 문제가 생겼을 때 무엇이 달라졌는지 비교하고 이전 구성을 다시 적용할 수 있다. 생성형 AI의 특성상 같은 답을 매번 똑같이 재현할 수는 없더라도 어떤 조건에서 그 답이 나왔는지는 추적할 수 있어야 한다.

새 모델을 검토할 때는 이렇게 정리한 기존 운영 환경을 비교 기준으로 삼으면 된다. 현재 모델과 후보 모델에 같은 업무 사례를 입력하고 품질과 안전성에 더해 비용과 처리시간을 함께 살펴보는 것이다. 출력 형식처럼 명확한 기준이 있는 항목은 프로그램으로 검사하고 자연어 답변의 적절성은 현업 전문가와 검증된 LLM 평가를 조합할 수 있다. 이때 실제 배포할 양자화 모델과 검색 문서 및 도구 설정을 사용해야 한다. 원본 모델을 평가한 결과만으로는 기업의 운영 환경에서도 같은 성능이 나온다고 보기 어렵기 때문이다. 평균 점수가 올랐더라도 중요한 업무에서 오류가 늘었거나 답변이 길어져 비용이 급증했다면 그 차이까지 드러내야 한다. 변경 승인도 이런 개선과 손실을 함께 검토하고 남은 위험을 누가 책임질 것인지 정하는 과정이 돼야 한다.

평가를 통과한 모델은 실제 서비스에서도 적용 범위를 조금씩 넓혀가는 것이 좋다. 먼저 운영 요청을 새 모델에도 보내되 고객에게는 기존 모델의 결과만 제공하는 섀도 방식으로 비교할 수 있다. 이때 새 모델이 실제 결제나 데이터 변경을 실행하지 못하도록 막아야 한다. 이후 품질과 비용이 확인되면 일부 사용자에게만 새 모델을 적용하는 카나리 배포로 넘어가는 식이다. 다만 어디까지 좋아야 적용 범위를 넓힐지와 어떤 문제가 생기면 중단할지는 배포 전에 정해둬야 한다. 고객의 재문의나 잘못된 도구 실행이 늘고 응답시간이 기준을 벗어나면 이전 구성으로 돌아갈 수 있어야 한다. 작은 범위에서 변화를 확인하는 절차가 있어야 모델을 더 자주 바꾸면서도 서비스의 혼란을 줄일 수 있다.

운영 중에는 서버의 상태와 함께 AI가 업무를 처리한 과정까지 살펴야 한다. 어떤 모델과 프롬프트를 사용했고 어떤 문서를 검색했는지 알아야 잘못된 답의 원인을 찾을 수 있다. Agent라면 선택한 도구와 전달한 조건 및 실행 결과도 연결해서 봐야 한다. 여기에 토큰 사용량과 처리시간 및 비용을 함께 기록하면 품질 저하와 비용 증가가 어디서 시작됐는지 파악하기 쉬워진다. 직원이 AI의 답을 수정하거나 상담사에게 업무를 넘긴 기록도 중요한 신호다. 다만 모든 대화 원문을 무조건 저장하면 개인정보 관리의 부담이 커진다. 필요한 정보를 선별하고 민감한 부분은 가린 뒤 접근 권한과 보존기간을 정하는 것까지 운영 설계에 포함해야 한다.

문제가 생겼을 때 사용할 대체 경로도 미리 준비해야 한다. 주 모델에 장애가 났다고 접속 가능한 다른 모델로 요청을 보내면 데이터 처리 지역이나 보안 조건을 위반할 수 있다. 대체 모델 역시 해당 업무에 필요한 출력 형식과 도구 사용 능력을 갖추고 같은 데이터 보호 기준을 충족해야 한다. 이런 대안이 없다면 일정 시간 동안 답변만 제공하고 실행은 사람에게 넘기는 식으로 기능을 줄일 수 있다. 특히 결제나 외부 발송은 응답을 받지 못했다고 즉시 재시도하면 이미 완료된 작업을 중복 실행할 수 있다. 실행 상태를 먼저 확인하고 필요하면 담당자가 개입하도록 해야 한다. 모델을 이전 버전으로 되돌리는 것과 이미 일어난 거래를 복구하는 것은 별개의 일이므로 실행 중단과 후속 복구 절차도 함께 준비할 필요가 있다.

운영에서 발견한 문제는 다음 평가를 위해 로그를 남겨야 한다. 고객이 잘못된 안내를 신고했거나 직원이 같은 유형의 답변을 반복해서 수정했다면 모델의 문제인지와 검색 문서 또는 업무 규칙의 문제인지를 구분해야 한다. 오래된 규정을 검색해 틀린 답을 했다면 모델을 바꾸는 것보다 문서 관리 방식을 고치는 것이 먼저일 수 있다. 원인을 해결한 뒤에는 그 사례를 평가세트에 추가해 다음 변경 때 다시 확인해야 한다. 그렇게 해야 한 번 해결한 문제가 새로운 모델에서 되풀이되는 것을 줄일 수 있다. 이처럼 실제 업무의 성공과 실패를 반영해 두어야 AI를 계속 발전시킬 수 있다.

이 과정에서 보안은 모델 외부의 시스템에서도 집행돼야 한다. OWASP가 2026년 8월 공개한 GenAI LLM Top 10은 프롬프트 인젝션과 민감정보 노출에 더해 과도한 Agent 권한과 공급망 위험을 주요 문제로 다룬다. 외부 문서에 숨겨진 지시를 AI가 따르더라도 중요한 데이터와 시스템까지 피해가 번지지 않도록 설계할 필요가 있다는 뜻이다. 예를 들어 모델이 생성한 도구 호출은 실제 실행 전에 애플리케이션에서 권한과 입력 조건을 검증하고 자격 증명은 모델이 읽는 문맥과 분리해 관리해야 한다. 실행 환경을 격리하고 외부 전송과 사용량에 한도를 두는 것도 같은 이유다. 프롬프트에 보안 규칙을 적는 것은 도움이 되지만 실제 접근과 실행을 막는 장치는 시스템에 있어야 한다.

법적 요구사항도 기업의 운영 체계에 반영해야 한다. 한국에서는 2026년 1월 22일 AI 기본법이 시행됐다. 제34조는 고영향 AI 또는 이를 이용한 제품과 서비스를 제공하는 사업자에게 위험관리와 이용자 보호 및 사람의 관리·감독 등을 위한 조치를 요구한다. 기술적으로 가능한 범위에서 결과를 설명할 방안을 마련하고 관련 조치를 확인할 수 있는 문서도 작성해 보관해야 한다. 제31조에는 해당 AI를 이용한다는 사실의 사전 고지와 생성형 AI 결과물의 표시 의무가 규정돼 있다. 기업은 자사 서비스에 적용되는 의무를 확인하고 모델을 바꿨을 때도 필요한 고지와 보호 장치가 유지되는지 살펴야 한다. 이런 변화가 기업 운영에 미치는 시사점은 분명하다. AI가 어떤 역할을 수행하고 누가 감독하며 문제가 생겼을 때 어떻게 대응하는지를 설명할 수 있어야 한다는 것이다. 모델의 변경 이력과 평가 결과를 기록하는 일도 이런 설명을 뒷받침하는 자료가 된다. 특히 여러 국가에 서비스를 제공하는 기업이라면 모델을 교체하거나 요청을 다른 지역으로 보낼 때 해당 서비스의 적용 조건까지 함께 검토해야 한다.

그렇다고 모든 모델 변경을 복잡한 심의 절차에 묶을 필요는 없다. 기존 IT 변경 관리와 보안 및 품질 검토 과정에 AI의 특성을 반영하는 것부터 시작할 수 있다. 저위험 문서 요약 기능이라면 자동 평가와 제한된 배포를 통해 신속하게 개선하고 고객의 권리나 중요한 의사결정에 영향을 주는 기능은 현업 책임자와 보안 및 준법 담당자가 함께 검토하는 식이다. 이를 공통으로 지원하는 관리 계층이 AI 컨트롤 플레인이다. 사내 모델의 사용 현황과 데이터 및 도구의 접근 범위를 파악하고 변경 전후의 품질과 비용을 비교하며 문제가 생겼을 때 실행을 중단하거나 이전 구성을 적용할 수 있도록 하는 것이다. 이런 기반이 갖춰지면 부서마다 같은 관리 기능을 반복해서 개발할 필요도 줄어든다.

앞으로 AI 모델의 성능은 더 좋아지고 기업이 선택할 수 있는 대안도 계속 늘어날 것이다. 그만큼 기업의 과제는 새로운 모델이 자사 업무에 어떤 이익을 주는지 판단하고 실제 서비스에 안정적으로 반영하는 일로 확장된다. 더 저렴한 모델이 나왔을 때 업무 품질을 지키며 비용을 줄이고 더 뛰어난 모델이 등장했을 때 고객에게 필요한 기능으로 연결할 수 있어야 한다. 이를 가능하게 하는 것은 자사 데이터와 평가 기준에 더해 변경의 영향을 확인하고 대응하는 운영 경험이다. 모델이 바뀌는 속도에 맞춰 이 역량을 갖춘 기업은 기술의 발전을 꾸준히 사업 성과로 가져올 수 있다. 그렇게 모델을 유연하게 교체하면서도 고객에게 약속한 서비스의 품질과 책임을 지키는 것이 기업 AX의 중요한 경쟁력이 될 것이다.

FAQ

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.