안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
요즘 기업 IT 담당자의 책상에는 AI 제안서가 쌓입니다.
SAP 쪽에서도, 클라우드 쪽에서도 들어옵니다. 다들 비슷하게 화려하고, 다들 비슷하게 자신 있습니다.
그런데 읽고 나서도 판단이 서지 않습니다.
멋진 말은 많은데 정작 우리 회사에서 되는지를 알 수 없기 때문입니다.
오늘은 AI 제안서에 자주 등장하는 문장들과, 그럴 때 무엇을 되물어야 하는지 정리해보겠습니다.
저희도 제안서를 쓰는 입장이라 조심스럽지만, 그래서 더 솔직하게 말씀드릴 수 있는 이야기이기도 합니다.
가장 흔하고, 데모에서 가장 잘 먹히는 기능입니다.
문제는 무엇을 근거로 답하느냐입니다.
우리 회사 데이터에서 찾아 답하는지, 일반 지식으로 그럴듯하게 만들어내는지에 따라 완전히 다른 물건이죠.
더 중요한 건 같은 질문에 답이 여러 개일 수 있다는 점입니다.
"재고가 몇 개냐"는 단순한 질문도 창고 실물 기준이냐 가용 재고 기준이냐에 따라 달라집니다.
기준이 정의돼 있지 않으면 AI는 틀린 답을 자신 있게 내놓습니다.
되물어야 할 것 — "이 답변은 어느 데이터를, 어떤 기준으로 계산한 건가요?" "우리 회사의 용어 정의를 어떻게 반영하나요?"
'손쉽게'라는 단어가 들어가면 일단 의심해보시는 게 좋습니다.
SAP를 예로 들면, 읽기만 하는 연동과 실제로 문서를 생성하는 연동은 난이도가 다릅니다.
권한 처리, 표준 API 사용 여부, 커스텀 코드와의 충돌 가능성이 전부 다르죠.
여기에 라이선스 문제도 있습니다.
외부 시스템이나 AI가 SAP에 문서를 만들면 간접 사용에 해당할 수 있는데, 제안서에 이 내용이 언급되는 경우는 드뭅니다.
되물어야 할 것 — "표준 API를 쓰나요, 직접 접근하나요?" "라이선스 영향은 검토하셨나요?" "우리 커스텀 개발 부분은 어떻게 처리하나요?"
솔깃하지만 따져볼 게 많은 문장입니다.
우선 방식이 다릅니다.
모델 자체를 조정하는 것과, 질문이 들어올 때마다 회사 문서에서 근거를 찾아 답하는 것은 비용도 결과도 전혀 다릅니다.
대부분의 기업에는 후자가 더 현실적이고 안전합니다.
그리고 데이터가 어디로 가는지가 핵심입니다.
인사 정보나 원가 자료가 포함된다면 이건 기술 문제가 아니라 보안 문제입니다.
되물어야 할 것 — "학습인가요, 검색 기반인가요?" "우리 데이터는 어디에 저장되고 누가 접근할 수 있나요?" "모델 제공사가 이 데이터를 학습에 쓰나요?"
요즘 가장 자주 보이는 문장이고, 가장 조심해야 할 부분입니다.
에이전트가 실제로 일을 하려면 시스템 권한이 필요합니다.
그런데 에이전트에게 준 권한 전체가 곧 위험 범위가 됩니다.
사람의 실수는 한 건으로 끝나지만, 에이전트의 잘못된 판단은 후속 작업으로 자동 연쇄되니까요.
특히 발송, 승인, 삭제처럼 되돌릴 수 없는 작업이 포함된다면 반드시 확인해야 합니다.
되물어야 할 것 — "권한 범위를 어떻게 제한하나요?" "되돌릴 수 없는 작업에는 사람 승인이 들어가나요?" "에이전트가 한 일을 나중에 추적할 수 있나요?"
인프라 쪽 제안서에 흔한 표현입니다.
AI 워크로드는 기존 시스템과 비용 구조가 다릅니다.
서버처럼 예측 가능한 고정비가 아니라, 누가 얼마나 쓰느냐에 따라 요동치는 비용이거든요.
게다가 AI 사용량은 도입 초기보다 나중에 늘어납니다.
처음엔 몇 명이 써보다가, 전사로 퍼지면 청구서가 달라지죠.
초기 견적만 보고 판단하면 나중에 곤란해집니다.
되물어야 할 것 — "사용량이 열 배로 늘면 비용은 어떻게 되나요?" "어느 부서가 얼마나 썼는지 구분해서 볼 수 있나요?" "비용 상한을 설정할 수 있나요?"
레퍼런스는 중요합니다.
하지만 어디까지 갔는지를 확인해야 합니다.
시범 운영과 실제 운영은 전혀 다릅니다.
업계 조사에 따르면 AI 파일럿의 상당수가 실서비스 전환에 실패합니다.
"도입했다"는 표현 안에는 아직 검증 중인 경우도 섞여 있습니다.
되물어야 할 것 — "파일럿인가요, 실제 운영 중인가요?" "몇 명이 얼마나 자주 쓰고 있나요?" "도입 후 어려웠던 점은 무엇이었나요?"
마지막 질문에 대한 답이 특히 중요합니다.
어려움을 구체적으로 말하지 못하는 회사는, 실제로 끝까지 해보지 않았을 가능성이 높습니다.
반대로 믿을 만한 제안서의 특징도 있습니다.
안 되는 것을 말합니다.
모든 게 다 된다는 제안서보다, "이건 되고 저건 어렵습니다"라고 선을 긋는 쪽이 훨씬 신뢰할 만합니다.
준비 작업을 먼저 말합니다.
데이터 정비, 권한 설계, 사용자 교육 같은 지루한 작업이 일정에 들어 있는지 보세요. 이게 빠진 제안서는 현실을 모르거나 감추고 있는 것입니다.
작게 시작하자고 제안합니다.
전사 도입을 한 번에 밀어붙이는 대신, 검증할 범위부터 제시하는 쪽이 경험이 있는 회사입니다.
운영 이후를 말합니다.
구축이 끝난 뒤 누가 관리하고, 모델이 바뀌면 어떻게 대응하고, 비용은 누가 모니터링하는지. 여기까지 담겨 있어야 완성된 제안서입니다.
AI 제안서를 판단하는 가장 좋은 질문은 사실 단순합니다.
"이걸 직접 해보셨나요? 그때 어디서 막히셨나요?"
해본 사람은 구체적으로 답합니다.
데이터의 어느 부분이 문제였고, 사용자가 왜 안 썼고, 비용이 어디서 튀었는지요.
안 해본 사람은 기능 설명으로 돌아갑니다.
BSG는 SAP 파트너이자 AWS MSP 파트너로서 데이터 기반 구축부터 운영까지 함께해왔습니다.
그 과정에서 매끄러운 데모와 실제 운영 사이의 간격도 여러 번 경험했고요.
받으신 제안서를 어떻게 판단해야 할지 고민이시라면, 함께 짚어보셔도 좋겠습니다.
무엇이 되는지보다 어디서 막히는지를 먼저 말씀드리겠습니다.
출처 : BSG Partners SAP·AWS 기반 AI 구축 경험, 업계 도입 동향 종합
기획 : 도예원