
마케팅팀은 ChatGPT를, 개발팀은 Copilot을, 영업팀은 또 다른 사설 챗봇을 씁니다. 부서마다 각개전투로 도구를 도입하다 보니 데이터가 어디로 흐르는지 IT 부서도 모르고, 비용만 새 나갑니다.
그래서 기업들은 뒤늦게 흩어진 AI를 하나로 묶기 위해 통제에 나서지만, 막상 무엇을 기준으로 플랫폼을 골라야 할지 막막합니다. 시중 자료는 대부분 추천이나 광고일 뿐, 무엇을 보고 판단해야 하는지는 알려주지 않습니다. 결국 데모에서 가장 화려해 보이는 제품을 덜컥 고르게 됩니다.
문제는 여기서부터 시작됩니다. 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 비용 급증, 불명확한 가치, 부족한 리스크 통제 때문에 취소될 것이라고 전망했습니다. BCG 역시 많은 기업이 AI 파일럿을 실제 비즈니스 가치로 확장하는데 어려움을 겪고 있다고 짚었습니다. 데모와 달리 실제 운영 환경은 문서가 낡거나 중복돼 있고, 권한 체계는 복잡하며, 사용자는 늘 예상 밖의 질문을 던지는 야생(!)이기 때문입니다.
2026년 6월 현재, 기업 AI 시장의 논의는 조금씩 이동하고 있습니다.
ChatGPT 같은 도구가 하나의 대화 창구라면, AI 플랫폼은그 위에서 여러 모델과 데이터, 여러 부서의 사용을 한꺼번에 묶어 관리하는 운영 계층입니다. 누가 어떤 모델을 얼마까지 사용할지 통제하고, 답변 출처를 추적하며, 운영 이후의 품질과 비용까지 한곳에서 들여다볼 수 있도록 합니다.
따라서 좋은 AI 플랫폼을 가리는 일은 곧 이 운영 계층이 제 역할을 하는지를 따지는 일입니다. 이번 글에서는 AI 플랫폼 추천 리스트 대신, 어떤 플랫폼이든 도입 전에 반드시 확인해야 할 7가지 판단 기준을 정리했습니다.

가장 먼저 확인해볼 것은 모델, 데이터, 권한, 비용을모두 하나의 콘솔에서 통제할 수 있느냐입니다. AI 플랫폼은 단순히 여러 모델을 연결해주는 도구가 아니라, 기업 안에서 누가 어떤 데이터에 접근하고, 어떤 모델을 사용하며, 얼마만큼의 비용을 쓰고 있는지 통제할 수 있어야 합니다.
예를 들어 마케팅팀은 외부 공개 자료 기반의 콘텐츠 생성만 허용하고, 법무팀은 계약서 원문에 접근할 수 있지만 외부 모델 호출은 제한해야 할 수 있습니다. 고객센터는 고객 응대 이력에 접근해야 하지만, 개인정보가 포함된 원문 데이터는 마스킹된 상태로만 활용해야 할 수도 있습니다. 업무마다 필요한 자율성과 데이터 접근 범위가 다르기 때문입니다.
보안이 걱정된다고 모든 기능을 막아버리면 현업은 다시 비공식 도구를 찾게 됩니다. 반대로 모든 권한을 열어두면 데이터 유출과 비용 폭증의 위험이 커집니다. 좋은 AI 플랫폼이라면 부서, 역할, 사용자별로 데이터 접근 범위, 모델 사용 권한, 비용 한도, 로그 정책을 다르게 설정할 수 있어야 합니다.

SaaS로 빠르게 시작하는 것은 대부분 가능합니다. 하지만 우리 회사가 금융, 공공처럼 규제 산업에 속해 있거나 민감 데이터를 다룬다면 폐쇄망, 즉 온프레미스 환경까지 지원할 수 있는지가 매우 중요합니다. 이때 반드시 확인해야 할 것은 SaaS에서 제공되던 기능을 폐쇄망에서도 동일하게 사용할 수 있는가입니다.
가령 엔터프라이즈 검색 플랫폼 글린(Glean)은 클라우드 기반의 단일 테넌트 SaaS까지 지원하며, 폐쇄망은 지원하지 않습니다. 검색 성능이 아무리 뛰어나더라도 데이터를 사외로 내보낼 수 없는 한국 금융, 공공 입찰에서는 후보에서 제외될 수밖에 없는 구조입니다.
이처럼 다수의 플랫폼이 SaaS 모드일 때는 화려한 기능을 모두 보여주다가, 온프레미스로 내려가는 순간 일부 기능이 빠지거나 업데이트 속도가 느려지고 운영 경험이 달라집니다. 처음에는 클라우드에서 원활하게 사용하다가 규제 대응 때문에 사내 서버로 옮기면서 성능이 크게 저하될 수도 있습니다. 온프레미스를 단순히 구색을 맞추기 위한 부가 기능으로 제공하는 것이 아니라, 처음부터 제대로 설계한 제품인지 반드시 꼼꼼하게 살펴보는 것을 권장합니다.

생성형 AI의가장 고질적인 리스크는 사실이 아닌 내용을 매우 그럴듯하게 생성한다는 점, 즉 Hallucination(환각 현상)입니다. 그렇기 때문에 플랫폼은 AI가 생성한 모든 답변이 원본 문서의 어느 페이지에서 비롯됐는지 정확하게 표시할 수 있어야 합니다. 인용구가 실제 출처 링크로 곧바로 연결되는지, 내부 문서가 업데이트되면 이전 버전으로 되돌릴 수 있는지, 누가 어떤 문서에 접근했는지 로그가 남는지를 확인할 수 있어야 합니다.
예를 들어 마이크로소프트의 에이전트형 검색(agentic retrieval)은 복잡한 질문을 여러 개의 하위 질문으로 나누어 병렬로 검색한 뒤, 출처가 포함된 답변으로 다시 합쳐주는 방식을 택했습니다. 그만큼 답변이 어디에서 비롯됐는지를 끝까지 추적할 수 있도록 만드는 것이 기본 요건이 됐다는 뜻입니다.
추적성이 없으면 답변이 틀렸을 때 왜 틀렸는지 아무도 설명하지 못합니다. 규제 산업에서는 이것이 단순한 불편을 넘어 감사(audit) 과정에서 문제가 될 수도 있습니다.

AI 플랫폼은 단순히 만드는 도구에서 끝나서는 안 됩니다. 운영 이후의 성능과 리스크도 지속적으로 확인할 수 있어야 합니다.
□ 응답 속도는 안정적인가요?
□ P50, P95, P99 지연 시간은 어느 정도인가요?
□ 토큰 비용은 어느 부서에서 많이 쓰고 있나요?
□ 답변 품질은 시간이 지나도 유지되나요?
□ 모델을 바꿨을 때 정확도와 비용은 어떻게 달라지나요?
□ 멀티턴 대화에서도 같은 품질이 유지되나요?
□ 평가 기능이 기본 내장인가요?
□ 골든셋(모델의 성능을 측정하는 시험지) 기반 정기 평가가 가능한가요?
□ 모델별 비용과 품질을 비교할 수 있나요?
□ 운영 로그를 감사와 품질 개선에 동시에 활용할 수 있나요?
이처럼 단순히 로그를 쌓는 수준이 아니라, 운영 중인 AI의 품질, 비용, 지연, 실패 패턴을 지속적으로 관찰할 수 있어야 합니다.
실제로 해외에서는 랭스미스(LangSmith), 랭퓨즈(Langfuse) 같은 옵저버빌리티 전문 도구가 사실상 별도의 시장을 이루고 있을 정도입니다. 문제는 플랫폼 따로, 옵저버빌리티 따로, 평가 따로 운영하면서 도구가 계속 쌓이면, 통합을 위해 도입한 제품이 오히려 또 다른 사일로가 된다는 점입니다. 측정 기능이 기본으로 내장되어 있는지, 아니면 매달 별도의 비용을 추가로 지불해야 하는지를 도입 전에 확인하는 것이 좋습니다.

보안은 단순히 ‘데이터를 암호화하는가?’를 확인하는 수준을 넘어야 합니다. 사용자가 입력하는 프롬프트에서도 개인정보(PII)가 유출되지 않는지, 금칙어와 민감 키워드 사전이 제대로 작동하는지, 폐쇄 클라우드까지 지원하는지를 확인해야 합니다.
잘 설계된 보안 구조는 일반적으로 여러 단계의 가드로 구성됩니다. 입력 단계에서 민감정보를 걸러내고, 모델 호출 과정에서는 데이터 보존 정책을 적용하며, 응답 단계에서는 유해성을 탐지하고, 전체 과정을 감사 추적으로 남기는 방식입니다.

현재 가장 좋은 모델이 1년 뒤에도 가장 좋다는 보장은 없습니다. 업무별로 적합한 모델 역시그때마다 달라질 수 있습니다. 어떤 업무는 GPT 계열이잘 맞고, 어떤 업무는 Claude가 더 적합할 수 있습니다. 국내 업무나 폐쇄망 환경에서는 자체 모델이나 국산 LLM이 필요할 수도 있습니다.
따라서 AI 플랫폼은 특정 모델 하나에 강하게 종속되지 않는 구조여야 합니다. 모델을 자유롭게 교체할 수 있는지, 업무별로 다른 모델을 라우팅할 수 있는지, 비용과 성능 기준에 따라 모델을 선택할 수 있는지를 살펴봐야 합니다.
예를 들어 해외 플랫폼인 라이터(Writer.com)와 같은 제품은 자체 모델(Palmyra)을 갖추고 있어 초기 도입이 편해 보일 수 있지만, 그 모델 하나에 전사가 묶이면 더 나은 선택지가 나와도 쉽게 전환하기 어렵습니다. 빅테크 클라우드 위에서만 동작하는 플랫폼들(AWS Bedrock, Azure AI Foundry 등) 역시 해당 클라우드의 인프라 정책과 가격에 영향을 받을 수밖에 없습니다. 인프라와 모델 모두로부터 중립적인 독립 콘솔인지 확인해야 장기적으로 비용을 절감할 수 있습니다.
자체 모델을 가진 플랫폼은 초기 도입이 편해 보일 수 있습니다. 하지만 전사가 하나의 모델에 묶이면 더 나은 선택지가 나왔을 때 전환 비용이 커집니다. 클라우드도 마찬가지입니다. 특정 인프라 위에서만 동작하는 플랫폼은 해당 클라우드의 가격 정책, 리전, 보안 요건에 그대로 영향을 받습니다. AI 플랫폼은 모델을 고정하는 도구가 아니라, 모델 선택권을 유지할 수 있도록 지원하는 운영 계층이어야 합니다.

마지막은 자주 빠뜨리는 기준이지만, 사실 도입 성패를 가장 크게 가르는 요소입니다. 아무리 강력한 플랫폼이라도 개발자만 사용할 수 있다면 전사 도입이 어렵습니다. 현업 담당자가 코드 없이 앱처럼 기능을 선택하고, 기획서나 문서를 입력하면 워크플로우가 자동으로 만들어지는 수준까지 쉽게 사용할 수 있는지를 확인해야 합니다.
마이크로소프트 사례를 살펴보겠습니다. 마이크로소프트는 빌더가 코파일럿 스튜디오(현업용 로우코드)와 파운드리(개발자용)로 나뉘어 있어 구매자 입장에서는 어떤 제품을 선택해야 할지 혼란스러울 수 있습니다. 이 때문에 회사가 직접 의사결정 가이드와 단일 구매 플랜까지 별도로 만들어야 했을 정도입니다.
또 다른 예시로 최근 오픈소스 시장에서 주목받고 있는 디파이(Dify)가 있습니다. 뛰어난 비주얼 워크플로우 빌더로 7만 개가 넘는 깃허브 스타를 받았습니다. 다만 Dify처럼 비주얼 워크플로우가 강한 도구도 실제 현업 사용자가 직접 운영하려면 노드 구조, 프롬프트 설계, API 연결 방식에 대한 기본적인 이해가 필요합니다. 즉, 노코드라고 해서 곧바로 비전문가도 쉽게 운영할 수 있다는 뜻은 아닙니다.
이처럼 빌더가 어려우면 결국 IT 부서에 요청이 몰리고, 처음에 해결하려 했던 ‘부서마다 따로 노는 문제’가 그대로 재현됩니다. 도구를 통합했는데 정작 사용하는 사람이 개발자뿐이라면 통합의 의미가 사라집니다.
시장의 내로라하는 플랫폼들을 이 7가지 잣대로 복기해보면 한 가지 사실이 보입니다. 대부분의 플랫폼은 모든 기준을 고르게 충족하기보다 특정 영역에 강점을 갖고 있습니다. 검색은 뛰어나지만 폐쇄망 배포가 어렵거나, 빌더는 잘 갖춰져 있지만 거버넌스가 약하거나, 거버넌스는 탄탄하지만 특정 클라우드 환경에서만 동작하는 식입니다.
따라서 기업이 진짜 물어야 할 질문은 ‘이 플랫폼이 단순히 좋은가?’가 아닙니다. ‘지금 우리 회사에 반드시 필요한 요건은 무엇이며, 그 요건을 하나의 운영 체계 안에서 충족할 수 있는 플랫폼은 무엇인가?’를 물어야 합니다.
만약 사내 문서 검색이 가장 시급하다면 검색에 강한 플랫폼을 선택하면 됩니다. 특정 CRM 안에서 AI를 긴밀하게 활용하는 것이 목적이라면 해당 벤더의 생태계에 최적화된 플랫폼이 더 적합할 수 있습니다. 고객 응대 자동화가 핵심이라면 CX 특화 에이전트 플랫폼이 더 빠른 선택지가 될 수도 있습니다.
하지만 우리 회사가 금융, 공공처럼 규제 요건이 강한 산업에 속해 있고, 폐쇄망 배포가 필요하며, 여러 부서가 하나의 도구를 함께 사용해야 하고, 답변 근거와 감사 추적이 중요하며, 운영 이후의 품질 평가까지 필요하다면 이야기는 조금 달라집니다. 이때는 개별 기능의 완성도보다 거버넌스, 배포 유연성, 답변 추적성, 평가, 보안, 모델 중립성, 편의성을 하나의 통합 운영 체계로 묶어 제공하는 플랫폼을 찾아봐야 합니다.
스켈터랩스도 이 7가지 관점을 하나의 콘솔로 묶어보자는 생각에서 MAIP aOS (agentOperating System)을 설계하고 있습니다. 거버넌스를 첫날부터 기본값으로 두고, SaaS에서 쓰던 기능이 폐쇄망에서도 이어지며, 답변을 원본 문서 단위로 추적하고, 운영 이후의 측정과 평가까지 하나의 흐름 안에 담는 방향입니다.
향후 어떤 플랫폼을 검토하든, 아래 7가지 체크리스트를 꼼꼼하게 따져보는 것부터 시작해보세요. 판단 기준이 선명해지면 복잡해 보이는 AI 플랫폼시장도 훨씬 단순하게 보입니다.
