AI 묘지가 증명한 것: 자율보다 협소하게

죽은 AI 프로젝트들의 공통점은 "자율성의 과잉 약속"이다. 스스로 판단하고, 연구하고, 다음 행동을 결정하는 AI일수록 실패율이 높다. 소수 개발팀이 AI 도구를 워크플로에 통합할 때, 이 한 줄이 평가 기준이 되어야 한다.

단, "그냥 단순한 AI만 써라"로 읽으면 반만 맞다. 경계선을 어디에 그을 것이냐가 진짜 문제다.

무엇이 죽었나 — 패턴 먼저

TechCrunch가 꾸준히 업데이트하는 "AI 묘지" 리스트를 보면, 실패한 프로젝트들 사이에 구조적 패턴이 있다. Apple의 Siri AI는 수차례 출시가 연기됐다. OpenAI의 "슈퍼앱" 계획은 혼란스러운 론칭으로 기대에 한참 못 미쳤다. 수십 개의 AI 스타트업이 런웨이가 바닥나거나 약속한 품질을 끌어올리지 못한 채 조용히 사라졌다.

이걸 "대기업 AI 투자 실패 스토리"로만 읽으면 절반밖에 못 읽는 거다. 묘지에 묻힌 프로젝트들의 공통 DNA를 들여다보면 한 가지가 반복된다. 자율 연구, 자율 판단, 자율 행동. 특히 AI 스스로 연구를 수행하는 autonomous research 영역에서 성능은 기대치 대비 실망스러울 정도였다는 평가가 지속적으로 나왔다. 이게 단순히 "AI가 아직 멀었다"는 얘기가 아니다. 협소하게 정의된 작업에서는 AI가 이미 충분히 쓸 만하다. 죽은 프로젝트들이 틀린 것은 AI의 능력이 아니라 적용 범위였다.

소수 개발팀이 특히 취약한 이유

대기업은 AI 도구에 잘못 베팅해도 흡수할 여력이 있다. 팀 하나가 6개월을 날려도 다른 팀이 커버하고, 손실이 분산된다. 소수 팀은 다르다.

4~5명이 15개 이상의 자동화 봇을 운영하고, 각 사이트의 콘텐츠 파이프라인을 돌리면서, 동시에 새 기능도 밀어야 하는 구조에서 AI 도구 선택을 잘못하면 그 비용이 팀 전체 워크플로에 직격으로 전파된다. 도구 교체 비용이 크고, 의존성이 한번 생기면 빼기가 어렵다.

직접 경험했다. 자율 코딩 에이전트를 붙여보고 싶어서 "알아서 리팩터링해줄 거다"라는 기대로 접근했다가, 결과물 검수에 직접 짰을 때보다 더 많은 시간이 들었다. 에이전트가 만든 코드를 신뢰하기 위해 전체를 다시 읽어야 하는 상황이 반복됐다. 생산성 도구가 오히려 생산성 드레인이 된 전형적인 케이스다. 이게 우연이 아닌 이유가 AI 묘지에 있다. 자율 에이전트 계열이 묘지에 많이 들어간 이유가 정확히 이 구조적 문제 때문이다.

살아남은 것들의 공통점 — 협소함

지금도 살아있고 실제 팀 생산성에 기여하는 AI 도구들을 보면 공통점이 있다. 범위가 좁다.

콘텐츠 봇에서 LLM을 활용할 때, "알아서 좋은 글 써줘"가 아니라 "이 구조대로, 이 소스 데이터 기반으로, 이 형식에 맞춰 써줘"처럼 입력-출력을 극도로 좁게 정의할수록 결과물이 안정적이었다. 시스템 프롬프트에 검수 기준을 명시하고, 본문이 특정 길이 미만이면 재생성 트리거를 코드로 강제하는 방식으로 AI의 자율도를 의도적으로 낮췄을 때 운영이 오히려 안정됐다.

반대로 "이 데이터를 분석해서 다음에 뭘 해야 할지 알려줘" 류의 오픈엔디드 프롬프트는 출력 품질 편차가 너무 커서 자동화 파이프라인에 넣을 수가 없었다. 자율 판단을 AI에게 맡기는 순간, 사람이 결과를 검수하는 비용이 기하급수적으로 올라간다. 죽은 AI 프로젝트들이 대부분 이 지점에서 실패했다.

수치로 본 트레이드오프

협소 AI의 효과를 수치로 감각화하면 이렇다. 블로그 봇 기준으로, 글 1건 생성에 드는 실질 인건비 환산 시간은 AI 도입 전 대비 약 70~80% 절감됐다. 단, 이건 "사람이 구조를 짜고 AI가 살을 붙이는" 역할 분담이 명확할 때의 수치다.

구조까지 AI에게 맡겼을 때는 수정 시간이 늘어서 결국 50% 절감 수준으로 떨어졌다. 비율로만 보면 작은 차이 같지만 소수 팀에게는 크다. 글 1건당 15분을 아끼는 것과 30분을 아끼는 것은, 하루 발행량이 1015건인 파이프라인에서 하루 23시간 차이가 난다. 월로 환산하면 60~90시간. 이게 다른 기능 개발이나 신규 봇 작업에 쓸 수 있는 시간이다.

자율 에이전트류 도구들이 내세우는 "80% 자동화"가 실제 운영에서는 "80% 자동화 + 검수 시간 2배"로 뒤집히는 이유가 여기에 있다. 유지보수 비용은 프로모션 자료에 없다. AI 묘지의 스타트업들도 같은 구조였다. 사용자에게 자율성을 팔면서, 그 자율성의 신뢰 비용을 실제로는 사용자가 감당하게 만들었다.

우리 팀이라면 — 실제 적용 시나리오

AI 묘지 리스트를 보면서 "써볼까" 했던 도구 몇 가지가 이미 묘지에 들어가 있었다. 이걸 역으로 활용하면 도구 평가 프레임이 된다.

자동화 파이프라인 구조를 예로 들면, 봇이 LLM을 호출하는 구간은 "템플릿 기반 생성"으로 좁게 유지하고, "다음에 어떤 주제를 써야 하나" 같은 전략적 판단은 사람이 한다. 코드 생성 지원도 마찬가지다. Cursor처럼 "내가 선택한 범위 내에서만 코드를 채워주는" 도구는 그 협소함 때문에 신뢰할 수 있다. 에이전트 방식은 범위 설정 자체를 AI가 하기 때문에 예측 불가능한 변경이 발생했을 때 디버깅 비용이 크다. 소수 팀에서 예측 불가능성은 곧 야간 긴급 대응이다.

그래서 새 AI 도구를 검토할 때 우리가 가장 먼저 묻는 건 기능이 아니라 이거다. "이 도구가 만들어내는 결과물을 내가 얼마나 빠르게 신뢰할 수 있는가." 신뢰 형성 비용이 높으면, 아무리 강력한 기능도 팀 규모 대비 통합 비용이 과하다.

당장 써먹을 수 있는 기준

AI 도구를 워크플로에 넣기 전, 세 가지를 먼저 확인하면 된다.

범위 테스트가 첫 번째다. 이 도구에게 오픈엔디드 질문을 던졌을 때 결과물의 편차가 얼마나 큰가. 편차가 크면 검수 비용이 자동화 이득을 잡아먹는다. "알아서 해줘" 유형의 도구는 묘지에 많다. 입력과 출력이 명확히 정의된 도구만 파이프라인에 넣는다.

생존 가능성 확인이 두 번째다. 이 도구를 운영하는 팀이 AI 묘지의 전형적인 패턴 — 유명 VC 투자, 과도한 기능 약속, 수익화 실패, 서비스 종료 — 을 따라가고 있지는 않은가. 스타트업 도구를 코어 파이프라인에 넣을 때는 런웨이를 직접 확인해보는 게 낫다. 판단이 안 서면 사이드 실험 수준에서만 쓴다.

대체 경로 설계가 세 번째다. 이 도구 없이 같은 결과를 낼 수 있는 경로를 미리 만들어두는 것. 도구가 갑자기 정책을 바꾸거나 가격을 올리면 파이프라인 전체가 멈춘다. 추상화 레이어 하나를 중간에 두면 교체 비용이 확 줄어든다. LLM 호출을 직접 박지 않고 헬퍼 래퍼를 통하는 것도 같은 이유다. 모델이 바뀌어도 봇 코드는 그대로 돌아가야 한다.

AI 묘지는 결국 "무엇을 하지 말아야 하는가"를 보여주는 실전 데이터다. 새 AI 도구를 검토할 때마다 한 번씩 훑어보는 것만으로도, 묻힌 것들이 왜 묻혔는지가 보이고, 자기 팀 워크플로의 취약점이 어디에 있는지가 보인다.

원문: AI News & Artificial Intelligence | TechCrunch