AI가 비용을 늘릴 때 작은 팀이 갖춰야 할 역량
BCBS가 AI 도입으로 병원 의료비 9420억 원이 추가 발생했다고 밝혔다. AI가 비용을 줄인다는 전제가 흔들릴 때, 소규모 기술팀이 실제로 갖춰야 할 역량을 짚는다.
절감이 아니라 증가였다
Blue Cross Blue Shield가 2년치 데이터를 분석했더니 병원 AI 도입 이후 의료비가 9억 4,200만 달러(약 1조 2,700억 원) 더 나왔다. 어떻게? 진단 보조 AI가 더 많은 이상 징후를 감지했고, 그 결과 더 많은 검사와 시술이 뒤따랐다. 의료계에서 말하는 "유도 수요(induced demand)"의 AI 버전이다. 도구가 정밀해질수록 발견되는 항목이 많아지고, 발견된 것마다 처치 비용이 붙는다.
이 뉴스를 단순히 "의료 AI 부작용"으로 읽으면 절반만 본 거다. 핵심 패턴은 산업을 가리지 않는다. 그리고 그 패턴이 이미 작은 기술팀 안에서도 진행 중이다.
단, 이 문제를 "AI를 줄이자"로 해석하면 또 다른 함정이 기다린다. 진짜 과제는 AI의 양이 아니라 팀이 그것을 읽어내는 역량이다.
세계권이라던 한국 AI 현장
한국 정부가 수조 원 단위 AI 투자를 발표하고, 기업마다 AI 트랜스포메이션을 선언했다. 그런데 현장 엔지니어들 사이에선 "AI 도입 이후 실제로 얼마가 줄었는지 측정한 팀이 없다"는 얘기가 공공연히 나온다.
AI 코딩 어시스턴트를 도입한 뒤 코드 리뷰 부하가 오히려 늘었다는 사례가 심심찮다. AI가 생성하는 코드 양은 늘었는데, 그걸 검토하고 버그를 잡는 시간이 그 이상으로 증가한 것이다. BCBS가 목격한 구조와 똑같다. AI가 산출물을 늘리면, 그 산출물을 처리하는 비용도 함께 늘어난다.
우리 팀에서 직접 밟았던 함정
콘텐츠 발행 봇을 운영하면서 비슷한 사이클을 직접 겪었다. LLM이 짧은 글을 뽑아도 그냥 발행되던 시기, AdSense에서 "저가치 콘텐츠" 반려가 날아왔다. 결국 코드로 1,500자 미만 본문을 차단하는 게이트를 만들어야 했다.
비용을 따져보면 이렇게 된다. haiku 호출 1회로 글 생성, sonnet 호출 1회로 검수, 미달이면 haiku 재호출, 게이트 재검사까지 한 건당 최소 3번의 LLM 호출이 붙는다. 발행 성공률이 낮은 날엔 비용 대비 실제 발행 건수 효율이 처참해진다. AI가 일을 줄여줄 것 같았는데, 실제론 검증 레이어가 쌓이고 쌓였다.
kpopdex 사고도 같은 구조다. AI가 앨범 데이터를 시드할 때 가짜 컴백이 혼입됐고, 이를 막으려고 news_guard.py와 vtuber_guard.py라는 감시 봇을 추가로 만들었다. AI 자동화 위에 AI 감시를 얹고, 그 위에 또 예외처리를 쌓는 구조. BCBS가 본 "AI가 AI 비용을 만들어내는" 증식 사이클이다.
그래서 어떤 역량이 부족한가
이 시점에서 소규모 팀에 부족한 건 "AI를 쓸 줄 아는 사람"이 아니다. 이미 다들 쓰고 있다.
부족한 첫 번째는 측정 역량이다. AI 도입 전후 실제 공수를 수치로 비교해야 한다. "느낌상 빠른 것 같다"는 근거가 안 된다. LLM 호출 횟수, 검수 통과율, 재생성 비율, 엔지니어 수동 개입 건수 — 이걸 추적하는 팀이 얼마나 되는가. BCBS가 1조 원을 뽑을 수 있었던 건 데이터를 추적했기 때문이다.
두 번째는 AI 회의주의. "이 태스크에 AI가 진짜 필요한가"를 물을 수 있는 역량이다. 우리 팀 소셜 발행 봇이 좋은 반례다. 설계할 때 LLM 호출을 아예 0으로 만들었다. 실데이터와 고정 템플릿만 쓴다. 환각이 없고, 토큰 비용이 없고, 검수 루프가 없다. AI가 없어서 단순해진 게 아니라, AI를 쓰지 않기로 결정했기 때문에 단순해졌다. 그 판단 자체가 역량이다.
세 번째는 **비용 귀속(cost attribution)**이다. LLM 호출 비용은 청구서에 찍히지만, 리뷰 루프 증가로 인한 엔지니어 시간, 사고 후 가드 코드 개발 공수, 잘못된 콘텐츠 복구 비용은 어디에도 집계되지 않는다. 이 숨은 비용을 볼 수 없으면, 도입·미도입 결정이 언제나 감으로 끝난다.
채용보다 측정이 먼저다
작은 팀이 이 역량을 갖추는 방법으로 "사람을 뽑자"가 먼저 나오면 곤란하다. 측정 체계가 없는 상태에서 사람을 뽑아봐야, 그 사람이 뭘 개선했는지 알 수가 없다.
현실적인 순서는 이렇다. 먼저 지금 돌아가는 AI 파이프라인에서 "AI가 결정한 것"과 "사람이 결정한 것"을 분리해서 기록하기 시작한다. AI가 자동 통과시킨 것, AI가 생성하고 사람이 최종 승인한 것, AI가 틀려서 사람이 되돌린 것 — 이 세 버킷만 나눠도 3개월이면 패턴이 나온다. 그 데이터가 생기고 나서야 "어떤 역량이 부족한지"가 구체화된다.
당장 써먹을 수 있는 세 가지
지금 운영 중인 AI 파이프라인 하나를 골라 "AI 없이 하면 공수가 얼마인가"를 역산해봐라. AI 도입 이후 오히려 늘어난 공수가 있다면 그게 induced demand다. 없애거나 구조를 바꿔야 한다.
팀원이 "이거 AI로 자동화하자"고 제안할 때, 다음 질문 세 개를 표준화해라. 자동화 이후 검증 루프는 몇 단계인가? 검증 실패율은 얼마로 예상하는가? 실패 시 복구 비용은? 이 세 질문에 답 못 하면 착수 전에 설계로 돌려보내라.
LLM 호출 횟수와 실제 완료(발행·처리) 건수의 비율을 매주 추적해라. 이 비율이 악화되고 있다면, AI가 팀의 생산성을 잡아먹는 중이다. BCBS가 1조 원을 뒤늦게 발견했듯, 이 숫자를 안 보면 사고가 난 뒤에야 안다.
최근 본 글
* 위 링크는 인프런 affiliate 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
* 위 추천 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.