미국 푸드뱅크, AI로 기능 개발 3개월을 하루로
미국 오하이오주 최대 푸드뱅크(기부 식품을 어려운 이웃에게 나누는 기관)가 소프트웨어 신규 기능 하나를 내놓는 데 2~3개월 걸리던 일을 AI 코딩 도구로 24~36시간으로 줄였다. 미드오하이오 푸드 콜렉티브의 이 숫자는 Anthropic이 공개한 자사 고객사례에 적힌 것으로, 30배가 넘는 개선이다. 제3자가 검증한 수치가 아니라는 점이 먼저 붙는다. 더 문제는, 이런 속도 숫자가 잰 뒤의 이야기를 말해주지 않는다는 것이다.
식품은 줄고 수요는 늘었는데, 손은 그대로였다
미드오하이오 푸드 콜렉티브는 오하이오 중동부 20개 카운티를 감싸는 최대 식품 은행이다. 이 단체는 눈에 안 보이는 다른 얼굴도 있다. 나눔터 창구용 소프트웨어 '프레시트랙(FreshTrak)'을 만드는 소프트웨어 회사이기도 하다. 프레시트랙은 전국 2,500여 개 나눔터·급식소에서 쓰이고, 누적 방문이 6,800만 번에 이른다. 유통업체들의 재고 예측이 정확해지면서 기부로 흘러들던 식품은 줄고, 도움을 청하는 가구는 팬데믹 전보다 거의 두 배로 늘었다. 물량과 인력 사이의 간극을 메운 도구가 AI 코딩 도구였다. 사례집 기준으로 신규 기능을 아이디어에서 서비스까지 24~36시간에 내놓게 됐고, 협력 푸드뱅크를 시스템에 들이는 데 걸리는 교육 시간은 절반으로 줄었다. 기술지원 담당자가 처음으로 올린 코드 수정이 반나절 만에 서비스에 반영되기도 했다.
보험 회사는 12~18개월 걸리던 규제 반영을 며칠로
같은 '속도' 이야기가 규제 산업에서도 나온다. 글로벌 보험회사 1,100곳의 핵심 시스템을 운영하는 미국 IT서비스업체 DXC 테크놀로지는 새 보험 규정을 시스템에 반영하는 데 12~18개월 걸리던 일을 며칠로 줄였다고 밝혔다. 청구 서류 분류는 1초 안에, 쌓인 서류 처리 백로그는 며칠에서 수 분으로 닿았다는 주장이다. 단 이 속도에는 조건이 붙어 있다. AI의 모든 행위를 기록하고 감독기관에 재현해 보일 수 있어야 한다는 것. 자동차 딜러용 소프트웨어업체 임펠은 또 다른 각도다. 영업사원이 신제품을 익히는 데 3~6개월 걸리던 것을 15만 통의 고객 통화 녹음으로 만든 역할극 연습 AI로 평균 1개월로 줄였고, 이 AI 자체를 3주 만에 구축했다.
숫자 네 개를 나란히 놓으면
| 회사 | 붙인 업무 | 지표 | 변화 | 출처 |
|---|---|---|---|---|
| 미드오하이오 푸드 콜렉티브(미국) | 나눔터 소프트웨어 기능 개발 | 아이디어→서비스 | 2~3개월 → 24~36시간 | Anthropic 고객사례(자체 발표) |
| DXC 테크놀로지(미국) | 보험 시스템 규제 반영 | 반영 기간 | 12~18개월 → 며칠 | Anthropic 고객사례(자체 발표) |
| 임펠(미국) | 영업사원 신제품 교육 | 숙련 기간 | 3~6개월 → 평균 1개월 | Anthropic 고객사례(자체 발표) |
| 프로액션(미국) | 영업용 맞춤 데모 제작 | 한 건 제작 시간 | 10시간(엔지니어) → 30~45분(창업자 직접) | OpenAI 고객사례(창업자 추정) |
프로액션은 차량 관리 소프트웨어를 만드는 스타트업이다. 공동창업자는 엔지니어에게 맡기면 10시간 걸리던 데모를 AI 코딩 도구로 직접 30~45분에 만들고, 이 덕에 엔지니어 일손이 매달 40~60시간 덜 든다고 추정했다. 네 건 모두 벤더와 고객사가 함께 낸 숫자라는 점은 표에 그대로 남아 있다.
반론: 만드는 속도와 버티는 속도는 다르다
해커 뉴스에서 'AI 사용이 부서지기 쉬운 코드베이스를 만든다'는 글이 638점을 받았다. 익명 댓글 작성자들은 속도 숫자의 뒷면을 찔렀다. 한 댓글은 "우리는 그저 더 부서지기 쉬운 코드베이스를 감수하며 살게 될 것"이라고 썼고, 다른 댓글은 토큰 사용량이나 스토리포인트 같은 속도 지표는 "의미는 별로 없으면서 부풀리기는 쉽다"고 지적했다. AI가 짠 코드를 사람이 검수해야 한다는 주장도 달렸다. 주니어 엔지니어에게 하듯 감독하고 표준을 가르치지 않으면 결과물을 못 쓴다는 것이다. 레딧 AI 에이전트 커뮤니티의 실패담도 방향은 같다. AI로 한 달 만에 서비스를 열었으나 오픈 뒤 밀려드는 버그와 기능 요청을 감당할 수 없다는 개발자 글이 달렸고, 다른 글은 에이전트 열풍을 "가끔 열쇠고리를 뽑아주는 3D 프린터"에 비유했다. 익명 커뮤니티의 주장을 사실로 확정할 수는 없지만, 출시 직전 속도만 재는 사례집 숫자와 정확히 반대 지점을 겨눈 목소리들이다.
한국 기업이 같은 걸 하려면
한국에서 이 표를 그대로 옮기기는 어렵다. 금융·공공 시스템은 DXC가 보여줬듯 감사 추적이 먼저다. 감독기관에 "AI가 어느 판단으로 이 결론에 닿았는지" 재현해 보일 장치가 없으면 속도는 아무 의미가 없다. 비개발자가 데모 코드를 직접 만드는 프로액션식 일감도 걸림돌이 다르다. 만든 사람이 책임지는 문화와 그 결과물을 협업으로 검수하는 절차가 함께 있어야지, 납품와 품질검토 문서가 병목인 환경에서는 24시간짜리 개발이 서류 심사에서 며칠을 더 기다리게 된다.
속도는 기술이 이미 풀었다. 남은 문제는 기술이 못 푸는 쪽이다. 누가 검수하고, 감독기관에 어떻게 설명하고, 오픈 뒤의 버그를 누가 감당하느냐. 이 질문에 답이 있는 회사만 표의 숫자를 따라 할 자격이 있다.
분석 근거: Anthropic 고객사례(미드오하이오 푸드 콜렉티브, DXC 테크놀로지, 임펠), OpenAI 고객사례(프로액션), Hacker News 토론(AI usage generates a fragile codebase), r/AI_Agents. 공개 자료에 근거한 분석입니다.
