AI 도입 업체 제안서, 어디를 보고 비교해야 하나

AI 에이전트 제안서 검토는 금액을 나란히 놓기 전에, 세 문서가 같은 일을 제안하고 있는지부터 확인하는 작업입니다. 범위와 전제 조건, 책임 소재를 같은 질문으로 훑어야 가격 비교가 성립하죠.

제안서 세 부가 책상에 올라와 있고 임원 보고는 다음 주입니다. 표지도 목차도 제각각인데, 마지막 장의 금액만은 서로 다른 숫자로 정확하게 비교되죠.

그 숫자를 그대로 옮겨 적은 비교표가 회의에서 가장 자주 흔들립니다. “이 금액에 운영도 들어가 있나요”라는 질문 하나에 표 전체가 무너지거든요.

저는 하마다랩스에서 윈디플로 제품을 맡아, 자사 솔루션과 다른 솔루션을 같은 선택 기준에 올려 견주는 일을 반복합니다. 그 자리에서 걸리는 것은 기능의 우열이 아니라 문서의 층위입니다. 같은 항목을 한쪽은 수량으로, 다른 쪽은 방향으로 적어 두면 뒤따르는 비교가 통째로 어긋나거든요. 그래서 문서를 펴기 전에 읽을 순서부터 정합니다.

제안서를 받으면 무엇부터 확인해야 하나요?

세 문서를 같은 자에 올리는 정규화가 먼저입니다. 각 제안서가 무엇을 팔고 있는지 문장 단위로 확인한 뒤에야 금액이 같은 의미를 갖거든요.

정규화의 축은 세 가지로 좁혀집니다. 무엇을 하겠다는 범위, 그 일이 성립하려면 우리 쪽이 미리 갖춰야 할 전제 조건, 그리고 어긋났을 때 누가 감당하는지의 책임 소재입니다.

축	문서에 던질 질문	비어 있을 때 생기는 일
범위	무엇을 어디까지 만들고 어디부터는 빼는가	착수 후 “그건 별도입니다”
전제 조건	우리가 무엇을 언제까지 제공해야 하는가	우리 쪽 인력·기간이 예산 밖에서 늘어남
책임 소재	결과가 틀리거나 멈추면 누가 고치는가	장애·재작업 때 협의부터 다시 시작

세 축은 우열을 가리는 채점표가 아니라 문서 간 차이를 드러내는 자입니다. 어느 제안서가 좋은지는 그다음 판단이고, 먼저 할 일은 세 문서가 서로 다른 물건을 팔고 있다는 사실을 표로 보이게 만드는 것이죠.

세 축만 훑을 때는 기능 설명 장표를 건너뛰고 범위·전제·책임에 해당하는 절만 찾아 읽으면 됩니다. 검토가 길어지는 이유는 대개 분량이 아니라 어디를 봐야 할지 정하지 않은 채 처음부터 읽기 때문이죠. 축이 정해져 있으면 두꺼운 제안서에서도 실제로 읽을 자리는 몇 쪽으로 줄어듭니다.

제안서마다 목차가 다른데 같은 항목을 어떻게 찾나요?

목차를 기준으로 삼지 않고 표현을 검색하는 편이 빠릅니다. 업체마다 절 이름은 다르지만, 같은 성격의 문장에는 비슷한 단어가 쓰이거든요.

문서를 열면 목차보다 아래 표현부터 찾습니다.

찾을 표현	그 문장이 알려 주는 것
별도, 추가, 협의	이 금액 밖에 있는 일
전제, 가정, 고객사 제공	우리 쪽에 넘어온 일
제외, 포함되지 않음	범위의 바깥 경계
검수, 승인, 확인	완료 판정의 주체와 기준
변경, 재산정	조건이 바뀔 때의 금액 처리

이 방식은 제안서 분량이 크게 다를 때도 통합니다. 두꺼운 문서와 얇은 문서를 목차로 견주면 두꺼운 쪽이 성실해 보이지만, 위 표현으로 훑으면 얇은 쪽이 경계를 더 또렷하게 적어 둔 경우가 드물지 않죠. 디자인과 물량은 판단 재료가 아닙니다.

가격 비교표가 가장 먼저 무너지는 이유는 무엇인가요?

금액은 독립 변수가 아니라 범위의 함수이기 때문입니다. 범위가 다른 세 숫자를 한 줄에 놓으면, 비교하는 순간 이미 잘못된 전제가 표에 들어가죠.

같은 요구서를 받고도 견적 금액이 갈리는 구조 자체는 견적 편차와 범위 정의에서 따로 다뤘습니다. 손에 제안서가 들어온 지금 남는 물음은 그 편차가 문서의 어느 문장에서 만들어졌고, 그 문장을 어떻게 찾아내느냐죠.

외부 데이터도 이 단계의 무게를 가리킵니다. 가트너는 인프라·운영 책임자 782명을 2025년 11~12월에 조사해 그 결과를 2026년 4월 발표했습니다. AI 활용 사례 가운데 ROI 기대를 온전히 충족한 비율은 28%였고, 20%는 완전한 실패로 분류됐죠.

같은 조사에서 실패를 한 번 이상 경험한 응답자는 57%였고, 그 흔한 원인으로 너무 이른 과도한 기대가 꼽혔습니다. 제안서 단계에서 전제와 책임을 문장으로 확인하는 일은 그 기대를 계약 가능한 조건으로 되돌리는 장치입니다.

범위 — 제안서는 어디까지를 ‘포함’으로 적고 있나요?

범위를 읽는 가장 빠른 신호는 불포함 목록의 존재 여부입니다. 무엇을 하는지만 적힌 문서와, 무엇을 하지 않는지까지 적은 문서는 착수 후의 대화가 완전히 달라지거든요.

다음은 수량 한정어를 찾는 일입니다. “ERP 연동”은 범위가 아니라 방향이고, “판매 조회 API 3종 연동, 시나리오 5개, 수정 2회”가 범위죠.

범위 확인 항목	문서에서 찾을 표현
산출물 단위	연동 대상 시스템·API 목록, 에이전트 시나리오 수
수량 한정	사용자 수, 문서 건수, 수정 라운드 횟수
불포함 명시	“본 제안에 포함되지 않는 사항” 절의 유무
운영 경계	구축 종료 시점, 안정화 기간, 이후 운영의 소관
인수인계	관리자 교육, 운영 매뉴얼, 소스·설정 이관

운영 경계는 특히 자주 흐려집니다. 구축 금액에 3개월 안정화가 포함된 제안서와, 검수 완료로 끝나고 운영은 별도 계약인 제안서가 같은 금액으로 나란히 놓이는 일이 흔하거든요. 교육과 인수인계도 같은 자리에 둡니다. 도입의 목적이 내부에서 굴러가는 것이라면, 관리자 교육과 매뉴얼이 범위에 없는 제안은 완료 시점에 우리 쪽 숙제를 남기죠.

범위 서술이 흐린 제안서를 곧바로 탈락시킬 이유는 없습니다. 요구서가 성글면 제안서도 성글게 나오고, 그 경우 흐린 쪽은 업체가 아니라 우리가 준 정보이거든요. 되물어 개정본을 받아 보면 그 업체가 범위를 다루는 방식이 드러납니다. 질문에 숫자로 답해 오는지, 다시 “협의”로 답해 오는지가 실제 판단 재료죠.

전제 조건 — 우리가 할 일이 몇 개나 적혀 있나요?

전제 조건은 제안서에서 가장 조용한 자리에 있습니다. “고객사 제공 사항” 같은 절에 서너 줄로 적히지만, 그 줄들이 우리 쪽 인력과 기간을 실제로 결정하죠.

읽는 요령은 개수를 세는 것입니다. 전제가 열 줄이면 그 제안의 실행 가능성은 우리 조직의 준비도에 열 번 의존한다는 뜻이거든요.

전제 유형	문서에 적히는 모습	깨졌을 때
데이터	“정제된 데이터 제공 전제”	정비 공수가 우리 쪽 일로
환경·계정	테스트 서버·API 키·권한 제공	착수 지연, 일정 재조정
인력·시간	담당자 주 N시간 참여	실무자 본업과 충돌
승인 속도	“산출물 회신 3영업일 이내”	지연 책임이 우리 쪽으로
사용료	모델 사용료·라이선스 부담 주체	운영 단계 비용이 뒤늦게 등장

모델 호출량에 따라 매달 나가는 사용료를 누가 부담하는지는 AI 도입에서 새로 생긴 항목이라, 제안서에 없으면 운영이 시작된 뒤에 그 대화를 처음 하게 됩니다.

전제는 일정과도 붙어 있습니다. 담당자 참여 시간과 승인 회신 기한이 전제로 적혀 있다면 그 일정은 우리 조직의 속도를 계산에 넣은 것이고, 전제가 없는데 기간만 짧은 제안은 어디선가 시간을 당겨 쓰고 있다는 뜻이거든요. 그 시간이 어디서 나오는지 물어보면 대개 우리 쪽 검토 기간이 답으로 돌아옵니다.

전제가 많다는 것 자체는 흠이 아닙니다. 오히려 전제를 숨긴 제안서보다 정직하죠. 확인할 것은 그 전제를 우리가 실제로 충족할 수 있는가, 그리고 못 지켰을 때 무슨 일이 생긴다고 적혀 있는가입니다.

책임 소재 — 결과가 틀리거나 멈추면 누가 고치나요?

책임 소재는 세 축 중에서 문서마다 편차가 가장 큽니다. 한 줄도 없는 제안서가 있고, 산출물별 승인 주체와 재작업 범위를 표로 적어 온 제안서가 있죠.

AI 에이전트에서는 확인할 국면이 하나 더 있습니다. 시스템이 멈추는 장애만이 아니라, 멀쩡히 돌면서 틀린 판단을 내놓는 경우를 어떻게 다루는지입니다.

국면	제안서에서 확인할 것
산출물 승인	누가 무엇을 기준으로 승인하는가
재작업	검수 후 수정 범위와 무상 기간
오답·오작동	판단 오류의 처리 절차와 개선 책임
3자 시스템	ERP·그룹웨어 쪽 장애 시 대응 경계
데이터 처리	위탁 관계와 보관·파기의 주체

오답 처리를 문서로 약속하기 어렵다는 답을 받을 수도 있습니다. 그 답 자체는 정직한 것이고, 대신 오류를 어떻게 감지하고 며칠 안에 재학습이나 규칙 보정으로 대응하는지 절차를 받아 두면 되죠. 3자 시스템의 경계도 같은 자리에서 긋습니다.

ERP 쪽에서 인터페이스가 바뀌어 에이전트가 멈췄을 때, 그것이 유지보수 범위인지 별도 과업인지가 정해져 있지 않으면 장애 한복판에서 견적부터 논의하게 됩니다. 멈춘 채로 협의를 시작하는 것과 조항을 펴 보는 것은 복구까지 걸리는 시간이 다르죠.

AI 에이전트 제안서 검토에만 따로 있는 항목은 무엇인가요?

기존 시스템 구축 제안서를 읽던 눈으로는 놓치는 자리가 넷 있습니다. 데이터, 모델, 정확도, 그리고 사용량입니다.

데이터는 범위이자 전제입니다. 어느 시스템의 어떤 데이터를 어느 주기로 읽는지, 그 데이터의 정비를 누가 하는지가 갈리면 같은 시나리오라도 공수가 배로 벌어지죠.

모델 항목에서는 선택권과 교체 절차를 봅니다. 특정 모델에 묶이는 구조인지, 성능이나 요금이 바뀌었을 때 다른 모델로 옮기는 경로가 있는지, 그 교체를 누가 수행하는지가 운영 2년 차의 자유도를 정합니다.

이름표 자체를 확인해야 하는 경우도 있습니다. 가트너는 2025년 6월 25일 발표에서 기존 어시스턴트나 RPA를 실질적인 역량 없이 에이전트로 바꿔 부르는 관행을 ‘에이전트 워싱’이라 불렀고, 실제 에이전트 공급업체를 약 130곳으로 추정했습니다.

같은 발표는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망하며 그 사유로 비용 상승과 불명확한 사업 가치, 미흡한 위험 통제를 들었습니다. 제안서에 ‘에이전트’라고 적혀 있다면 무엇을 스스로 판단하고 어디까지 실행하는지를 산출물 단위로 되물어야 그 낱말이 검증되죠.

정확도는 숫자보다 정의가 관건입니다. 제품 쪽에서 지표를 정의해 본 자리에서 보면 “정확도 95%”는 분모와 표본이 적히기 전까지 아직 값이 아닙니다. 무엇을 분모로 삼았는지, 어떤 표본으로 측정했는지, 미달 시 무엇을 하는지가 없으면 검수 자리에서 해석이 갈리거든요.

검수 기준으로 쓸 지표를 언제부터 무엇으로 재는지는 도입 성과 KPI 정리에서 따로 다뤘습니다. 제안서 단계에서 할 일은 그 지표의 측정 방법과 표본이 문서에 정의로 적혀 있는지까지입니다.

사용량은 비용의 변동 축입니다. 문서 건수나 호출량이 늘 때 요금이 어떻게 움직이는지 구간으로 적혀 있어야, 파일럿 금액만 보고 전사 확대를 결정하는 일을 피할 수 있습니다. 구간이 없는 제안서에는 확대 시점의 예상 호출량을 우리 쪽에서 적어 보내고 그 조건의 금액을 받아 둡니다.

데이터 처리 경로도 이 자리에서 함께 봅니다. 사내 문서가 외부 모델로 나가는지, 나간다면 어느 구간에서 어떤 형태로 나가는지가 제안서에 그려져 있어야 보안 검토가 착수 전에 끝나거든요. 하마다랩스가 온프레미스 배포를 두는 이유도 이 경로를 조직 안쪽으로 되돌려야 하는 고객이 실제로 있기 때문입니다.

네 항목은 도입 이후에야 존재감을 드러내는데, 제안서에서는 대개 한 줄로 지나갑니다.

세 제안서를 같은 자에 올리는 대조표는 어떻게 만드나요?

대조표는 항목을 왼쪽에, 업체를 위쪽에 놓은 단순한 격자면 충분합니다. 요령은 표를 채우는 규칙에 있죠.

항목을 세 축(범위·전제·책임)으로 묶어 20줄 안팎으로 고정합니다.
제안서의 표현을 요약하지 말고 원문 문구를 그대로 옮깁니다.
적혀 있지 않으면 빈칸이 아니라 “미기재”로 적습니다.
수량은 같은 단위로 환산합니다. 시나리오 수, 연동 수, 운영 개월 수처럼요.
세 문서가 모두 미기재인 줄에 표시를 남깁니다.

세 번째 규칙이 이 표의 핵심입니다. 빈칸은 눈에 띄지 않지만 “미기재”는 읽는 사람이 반드시 걸리거든요.

표는 제안서를 받은 날 만들어 두는 편이 낫습니다. 발표를 듣고 나면 인상이 문서 위에 얹혀 원문 문구를 옮길 때도 해석이 섞이거든요. 문서만 놓고 채운 표가 있으면 발표에서 들은 말과 문서의 차이도 그 자리에서 드러납니다.

세 곳이 똑같이 비워 둔 항목은 그 업체들의 결함이라기보다 시장의 관행입니다. 그런 줄에 남긴 표시가 뒤에서 질의서의 뼈대가 되죠.

같은 요구서에 세 제안서가 다르게 답한 가상 사례

감을 잡기 위해 가상 상황을 하나 세워 보겠습니다. 아래는 설명을 위해 구성한 예시이며, 실제 고객사 사례나 특정 업체의 제안서가 아닙니다.

한 회사가 “ERP 데이터를 읽어 주간 리포트를 만드는 에이전트”를 요구서로 돌렸다고 하죠. A사는 시나리오 3개·연동 2종·안정화 3개월을 포함해 적었고, B사는 시나리오 5개를 제시했지만 연동 API는 고객 제공을 전제로 두었으며 운영은 별도 계약으로 뺐습니다.

C사는 총액 한 줄과 “요구사항 일체 구현”만 적어 왔습니다. 세 금액만 나란히 놓으면 C사가 가장 저렴해 보입니다. 그런데 대조표를 채우면 C사 칸의 절반이 미기재로 남죠.

A사도 그냥 통과시킬 대상은 아닙니다. 시나리오 3개가 우리가 요구한 업무를 실제로 덮는지, 안정화 3개월 동안 무엇을 해 주는지가 문서에 적혀 있어야 그 포함이 값을 갖거든요. 포함 항목이 많은 제안서일수록 각 항목의 내용을 되묻는 편이 안전합니다.

이때 유용한 것은 순위가 아니라 질문 목록입니다. B사에는 API 제공 범위와 운영 계약의 조건을, C사에는 시나리오 수와 수정 라운드를 되물으면 세 문서가 비로소 같은 자 위에 올라오거든요.

일정과 투입 계획에서는 무엇이 드러나나요?

일정표는 실행 가능성의 밑그림입니다. 마일스톤이 몇 개인지보다, 각 마일스톤에 우리 쪽 승인 게이트가 붙어 있는지가 판단 재료입니다.

승인 게이트가 없는 일정은 착수부터 검수까지가 한 덩어리라, 중간에 방향을 바로잡을 지점이 없습니다. 요건 확정, 프로토타입 확인, 연동 완료처럼 되돌릴 수 있는 지점이 표시된 일정이 관리 가능한 일정이죠.

투입 계획도 같은 눈으로 봅니다. 역할과 기간이 적힌 제안서는 그 금액이 어떻게 산출됐는지 되짚을 수 있지만, 총액만 있는 제안서는 범위가 줄어도 금액이 왜 그만큼 줄어야 하는지 설명할 근거가 없거든요. 확인할 문장이 하나 더 있는데, 담당자가 바뀔 때 동등 이상 경력으로 대체한다는 조항입니다.

산정 방식을 되물을 때 기댈 공적 기준도 있습니다. 한국소프트웨어산업협회의 「SW사업 대가산정 가이드」는 기획·구현·운영 단계마다 대가를 산정하는 방법을 따로 두고 있어, 총액을 어느 단계에서 어떤 방식으로 뽑았는지 물으면 한 줄짜리 금액이 세 덩어리로 갈라집니다.

제안서에 적힌 담당자가 착수 후 다른 프로젝트로 옮겨 가는 일은 드물지 않습니다. 핵심 역할이 한 사람에게 몰려 있는지도 같은 표에서 확인합니다. 총 기간이 짧다는 점은 장점으로도 위험으로도 읽히는데, 우리 쪽 전제 조건 항목과 겹쳐 보면 판단이 서죠. 담당자 주 8시간 참여를 전제로 6주를 제시한 일정은, 그 8시간을 실제로 낼 수 있는지에 달린 계획입니다.

제안서에 적히지 않은 것은 어떻게 찾아내나요?

빠진 항목은 읽어서 찾기 어렵습니다. 없는 것은 눈에 띄지 않으니까요.

그래서 대조표의 “미기재” 표시가 도구가 됩니다. 세 문서가 공통으로 비운 자리에 아래 질문들을 얹으면 공백 목록이 그대로 질의서가 되죠.

검수 기준은 무엇이며 누가 판정하나요.
무상 수정은 어느 범위까지, 언제까지인가요.
모델·라이선스 사용료는 누가 부담하며 사용량이 늘면 어떻게 되나요.
운영 이관 시 넘겨받는 것은 무엇인가요. 설정·프롬프트·문서가 포함되나요.
중간에 중단하기로 하면 정산과 산출물 인계는 어떻게 되나요.
우리와 비슷한 규모·업종의 도입 사례를 확인할 수 있나요.

질의는 세 곳에 같은 문장으로 보냅니다. 업체마다 다르게 물으면 돌아온 답도 다시 비교 불가능해지고, 같은 질문에 대한 답변의 구체성 차이가 그 자체로 판단 재료가 되거든요. 회신 기한도 함께 적어 두면 응대 속도까지 관찰할 수 있습니다.

하마다랩스가 제안서를 쓸 때 이런 항목을 앞쪽에 배치하는 이유도 여기에 있습니다. 협의로 풀자고 미뤄 둔 항목이 착수 후 가장 비싼 대화가 되는 것을 여러 번 봐 왔거든요.

되물은 답변은 어디에 남겨야 하나요?

구두로 들은 답은 대조표에 옮겨 적더라도 근거가 되지 못합니다. 메일 회신이나 제안서 개정본처럼 날짜와 발신자가 남는 형태로 받아 두시길 권합니다.

답변을 받으면 대조표의 미기재 칸을 지우지 말고 그 옆에 답을 붙여 둡니다. 처음에 무엇이 비어 있었는지가 남아 있어야, 그 업체가 무엇을 먼저 적고 무엇을 물어야 적었는지가 보이거든요. 이 기록은 나중에 계약 문구를 다듬을 때도 그대로 쓰입니다.

가장 깔끔한 방법은 개정본 요청입니다. 질의응답 내용을 반영한 제안서 v2를 받으면 대조표의 미기재 칸이 문서로 채워지고, 나중에 어느 버전이 정본인지도 흐려지지 않죠.

이렇게 정리된 문서는 업체를 정한 다음 단계로 그대로 넘어갑니다. 제안서에서 확인한 범위·전제·책임이 계약서와 SLA의 어느 조항으로 옮겨지는지는 계약 단계에서 따로 다룰 몫이죠.

검토 결과를 임원 보고로는 어떻게 옮기나요?

보고에는 대조표 전체가 아니라 판단이 갈린 줄만 올립니다. 스무 줄 중 세 곳이 결정을 갈랐다면, 그 세 줄과 각각의 근거 문구가 보고의 본문이 되죠.

금액 차이도 그 세 줄로 설명됩니다. “B사가 가장 낮지만 안정화 3개월과 관리자 교육이 범위 밖이다”처럼 적으면, 승인권자는 가격이 아니라 무엇을 사는지를 놓고 결정할 수 있거든요. 보고 문서의 전체 구조는 임원 보고용 사업성 분석서 구조에 정리해 두었습니다.

탈락시킨 제안서의 사유도 한 줄씩 남깁니다. 다음 해에 같은 업체가 다시 들어오거나 선정된 업체와 재계약을 논의할 때, 그때의 판단 근거가 협상 자료가 되거든요. 보고 문서 말미의 짧은 표 하나면 됩니다.

받은 제안서를 어떤 항목으로 갈라 보아야 할지 함께 정리하고 싶으시면 도입 상담 문의로 검토 중인 과업 범위와 우리 조직의 제약을 보내 주세요. 하마다랩스는 500개 이상 외부 시스템 연동과 온프레미스 배포를 다뤄 왔고, 견적은 범위가 확정된 뒤에 산정합니다.

자주 묻는 질문

제안서는 몇 곳에서 받는 것이 적당한가요?

세 곳 안팎이 다루기 좋습니다. 두 곳이면 서술의 차이가 업체 특성인지 시장 관행인지 가려지지 않고, 다섯 곳이 넘으면 대조표를 채우는 일 자체가 담당자의 본업을 밀어내거든요. 규모가 크지 않은 과업이라면 두 곳으로 좁히되 질의 라운드를 한 번 더 도는 편이 낫습니다.

요구서를 문서로 만들지 않고 구두로 설명해도 되나요?

같은 문서를 돌리지 않으면 받은 답도 비교 대상이 되지 않습니다. 한 장짜리라도 목적·대상 업무·연동 시스템·기대 산출물·제약을 적어 동일하게 보내면, 업체별 해석 차이가 문서에 드러나 그 자체로 판단 재료가 되죠.

제안서에 적힌 레퍼런스는 어떻게 확인하나요?

로고 나열보다 유사도를 보시길 권합니다. 우리와 비슷한 규모·업종·연동 환경의 사례가 있는지 묻고, 가능하면 그 고객과 짧게라도 통화해 보면 제안서에 없던 운영의 실제가 드러납니다. 사례 공개가 계약상 어려운 경우에는 익명 조건으로 과업 구조만 설명해 달라고 요청할 수 있습니다.

가장 낮은 금액을 고르면 안 되나요?

금액이 같은 범위 위에서 나온 것이라면 낮은 쪽이 합리적입니다. 문제는 대조표를 채우기 전에는 그 조건이 성립하는지 알 수 없다는 것이죠. 정규화를 마친 뒤에도 여전히 낮다면 그 제안은 근거 있는 선택이 됩니다.

제안 발표 자리에서는 무엇을 물어보면 좋을까요?

미기재 항목과 전제 조건에 집중합니다. 기능 시연은 자료로도 확인되지만, “이 전제가 깨지면 어떻게 되나요”나 “이 산출물은 누가 승인하나요” 같은 질문에 대한 답은 그 자리에서만 나오거든요. 답변은 회의록으로 남기고 개정본 반영을 요청하시면 됩니다.

검토는 실무 담당자 혼자 해도 되나요?

세 축을 나눠 보는 편이 안전합니다. 범위는 현업, 전제와 일정은 실무 담당, 책임과 데이터 처리는 정보보안·법무가 각각 읽으면 혼자서는 그냥 지나칠 문장이 걸리거든요. 나눠 읽은 결과를 하나의 대조표에 모으면 보고 자료가 그대로 완성됩니다.

참고 자료

가트너(Gartner), “Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns”, 2026년 4월 7일 보도자료 — 인프라·운영 리더 782명 조사(조사 시점 2025년 11~12월), AI 활용 사례 중 ROI 온전 충족 28%·완전 실패 20%, 실패 1회 이상 경험 57%(원인으로 과도한 기대 다수 지목)(2026-08-25 확인): https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns
위 가트너 발표의 보도 확인 — The Register, “Only 28% of AI infrastructure projects fully pay off”(2026-08-27 확인): https://www.theregister.com/2026/04/07/ai_returns_gartner/
가트너(Gartner), “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”, 2025년 6월 25일 보도자료 — 취소 전망 40% 이상과 사유 세 가지(비용 상승·불명확한 사업 가치·미흡한 위험 통제), ‘에이전트 워싱’ 정의, 실제 공급업체 약 130곳 추정(2026-08-25 확인): https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
위 가트너 발표의 보도 확인 — SDxCentral, “According to Gartner, the future isn’t actually agentic”(2026-08-27 확인): https://www.sdxcentral.com/news/according-to-gartner-the-future-isnt-actually-agentic/
한국소프트웨어산업협회(KOSA), 「SW사업 대가산정 가이드」 2025년 개정판 — 기획 단계 컨설팅 업무량·투입공수, 구현 단계 기능점수, 운영 단계 요율·투입공수 등 단계별 대가산정 방법(2026-08-25 확인): https://www.sw.or.kr/site/sw/ex/board/List.do?cbIdx=276
하마다랩스 제안·구축 과정 관찰(2026년, 익명 집계): 같은 요구서에도 범위 서술·전제 조건 기재 수준이 업체마다 갈리며, 착수 후 분쟁이 잦은 항목은 운영 경계·모델 사용료 부담·검수 기준에 집중된다. 문서를 읽는 데 걸리는 시간과 실제로 읽을 분량은 검토 축을 먼저 정했는지에 따라 갈린다 — 특정 고객사·특정 경쟁사 사례가 아님
하마다랩스 플랫폼·회사 소개(500개 이상 외부 시스템 연동·온프레미스 배포 지원): https://www.hamadalabs.com/platform · https://www.hamadalabs.com/about

작성자

안효준 — 하마다랩스 윈디플로 프로덕트 매니저. 자사 솔루션과 다른 솔루션을 같은 선택 기준에 올려 견주는 일을 맡고 있으며, 중소기업이 후회 없는 도입 파트너를 고르는 검증 절차와 소규모 POC·파일럿으로 본도입을 판단하는 방법, 도입 성과 KPI를 다룹니다. 회사 소개: https://www.hamadalabs.com/