한 줄 생각
AI 자동화가 가능한 업무와 안 되는 업무를 가르는 건 뭘까? 결과물에 대한 퀄리티? 자동화된 결과 검증 가능 여부? 인간의 판단이 필요한가 등이 아닐까 싶다.
결과가 맞는지 기계가 자동으로 확인해 주는 일에서는 AI가 시간을 크게 줄이지만, “이게 좋은 결과인가”를 사람이 판단해야 하는 일에서는, AI에게 초안까지만 맡기고 마지막 판단에 사람이 붙어야 하지 않을까 하는 것이 요즘의 생각이다.
Claude Code로 날씨 대시보드를 하루 만에 만들었을 때는 진짜 놀랐다. 그런데 같은 AI한테 업무 문서 정리를 맡겼더니, 결과물 검수하느라 그냥 내가 쓰는 게 빨랐다. 이 격차가 뭘까 계속 궁금했는데, 최근 연구 데이터를 뒤져보니 답이 꽤 명확했다.
“AI 생산성 대폭발”과 “코딩 말고는 체감 안 됨”은 둘 다 맞는 말이다. 그리고 이 둘을 하나로 꿰는 열쇠가 있다.
검증 비용이란 무엇일까?
검증 비용(verification cost)이란, AI가 내놓은 결과물이 맞는지 확인하는 데 드는 시간과 노력을 말한다.
이 비용이 낮을수록 AI 자동화의 효과가 커진다.
코드에는 컴파일러와 테스트가 있다. AI가 짜준 코드가 틀리면 즉시 빨간 줄이 뜬다. 확인이 사실상 공짜다. 반면 마케팅 카피나 전략 보고서에는 정답표가 없다. “이게 좋은가”를 사람이 읽고 판단해야 한다. 바이브코딩이 먼저 터진 건 우연이 아니라, 그 업무에 공짜 정답표가 붙어 있었기 때문이다.
그런데 코딩에도 함정이 있다. Stack Overflow 개발자 설문 2025(166개국 49,009명)에서 개발자들이 꼽은 최대 좌절 요인은 “거의 맞는데 완전히는 아닌” AI 결과물로, 66%가 대답했다. 그다음이 “AI 코드 디버깅에 시간이 더 든다, 45%”다. 완전히 틀린 경우 버리면 그만인데, 90% 맞으면 나머지 10%를 찾느라 더 고생한다는 것이다.
숫자로 보면 정말 그런가?
태스크 단위 연구는 일관된 패턴을 보여준다.
Stanford AI Index 2026은 “생산성 향상은 구조화되고 측정 가능한 업무에서 가장 크다”고 정리했다.
반대로 깊은 추론이 필요한 업무일수록 이득은 줄거나 사라진다.
| 연구 | 결과 | 시사점 |
|---|---|---|
| AI Index 2026 | 고객지원 14~15% 개발 26% 마케팅 산출물 최대 50% |
구조화될수록 이득 ↑ |
| GitHub Copilot RCT (2023) | 55.8% 빠름 (71분 vs 161분) |
검증 자동화된 업무의 위력 |
| BCG 실험 (758명) | 잘하는 영역 25.1% 빠름 못하는 영역 19%p 저조 |
‘jagged frontier’ |
| METR (2025.7) | 숙련 개발자 19% 느려짐 | 코딩도 만능은 아님 |
BCG 실험에서 나온 ‘jagged frontier’가 특히 중요하다. AI 성능의 경계선은 매끄럽지 않고 들쭉날쭉하다. 겉보기엔 비슷한 난이도인데 어떤 건 척척하고 어떤 건 완전히 틀린다. 진짜 문제는 사용자가 그 경계를 넘은 걸 모른다는 점이다.
METR 실험은 더 뼈아프다. 숙련 개발자 16명이 실제 태스크 246개를 처리했는데, AI를 쓴 쪽이 19% 더 느렸다. 참가자들은 사전에 “24% 빨라질 것”이라 예측했고, 실험이 끝난 뒤에도 “20% 빨라졌다”고 믿었다. 체감과 실측이 반대로 간 것이다.
다만 자기 코드베이스를 훤히 아는 고수 16명이라는 특수 조건이니, 모든 개발자로 일반화하면 안 된다.
바이브코딩은 되는데 업무 자동화는 왜 안 될까?
내 경험을 이 기준으로 다시 분류해 보니 깔끔하게 세 덩어리로 나뉘었다.
1) 완전히 되는 쪽 — 검증이 자동인 일. 날씨 대시보드는 Claude Code로 하루 만에 붙였다. 기상청 API 응답이 틀리면 바로 에러가 나고, 화면이 안 뜨면 그게 곧 실패 신호다. 내가 판단할 게 거의 없었다.
2) 절반만 되는 쪽 — 형식은 검증되는데 의미는 어렵다. 워드프레스 포스트 81개에 내부 링크와 메타 디스크립션을 n8n으로 일괄 생성했을 때가 딱 그랬다. 링크가 실제로 존재하는지, 슬러그가 맞는지는 스크립트로 걸러진다. 그런데 “이 문맥에 이 링크가 어울리나”는 결국 내가 다 봐야 했다. 여기가 HITL(Human-in-the-Loop) 체크포인트가 필요한 지점이다.
3) 오히려 손해인 쪽 — 정답표가 아예 없는 일. n8n AI Agent 노드가 tools[0].strict = null을 보내서 vLLM에서 400 에러가 나던 문제는, AI한테 아무리 물어도 못 잡았다. 남들이 겪지 않은 문제에는 참조할 정답이 없다.
결국 요청 페이로드를 직접 까보고 찾았다.
정리하면 이렇다. 바이브코딩이 잘 되는 건 내가 코딩을 잘해서가 아니다. 그 영역에 검증 장치가 이미 깔려 있어서다. 업무 자동화가 안 되는 것도 AI가 멍청해서가 아니라, 그 업무에 검증 장치를 안 만들어놨기 때문이다.
완전자동은 왜 항상 사람에게 돌아올까?
이 규칙을 가장 비싸게 증명한 게 핀테크 기업 클라르나(Klarna)다.
- 2024년 2월 — OpenAI 기반 챗봇이 한 달 만에 230만 건을 처리하고 전체 상담의 3분의 2를 담당, 직원 700명분 업무를 대체했다고 발표.
- 2025년 5월 — CEO가 블룸버그 인터뷰에서 “우리가 너무 멀리 갔다”고 인정. 비용에만 집중해 품질이 떨어졌다며 사람 상담원을 다시 뽑기 시작.
- 2026년 — “AI가 단순 상담을 처리하는 세상에서 사람 상담은 거의 VIP 서비스처럼 될 것.” 결국 하이브리드로 착지.
듀오링고도 비슷하다. 2025년 4월 ‘AI-first’를 선언했다가 이용자 반발에 1주 만에 물러섰고, 2026년엔 AI 사용량을 인사평가에 반영하던 규칙까지 없앴다.
기업 전체 통계도 같은 방향이다. MIT NANDA 보고서(2025)는 생성형 AI 파일럿의 95%가 측정 가능한 손익 성과를 못 냈다고 봤고, S&P Global은 AI 프로젝트를 대부분 접은 기업 비율이 2024년 17%에서 2025년 42%로 뛰었다고 집계했다. 실패 원인은 하나같이 모델 성능이 아니라 워크플로 통합과 데이터 준비였다.
그럼 워크플로우에 HITL(Human-in-the-Loop)을 어디에 넣어야 할까?
n8n으로 자동화를 짜는 입장에서 뽑아낸 실무 규칙 다섯 가지다.
- 검증 노드부터 만들고 자동화해라. 스키마 체크, 링크 유효성, 수치 검산, 정규식 필터 — 자동 판정 장치가 있는 구간부터 AI를 투입한다. 검증기가 없으면 그 구간은 아직 자동화 대상이 아니다.
- HITL 체크포인트는 되돌릴 수 없는 지점 바로 앞에 둬라. 발행, 발송, 결제, 삭제 직전이다. 중간 산출물 단계에 승인을 넣으면 병목만 생긴다.
- ‘90% 맞음’ 구간을 따로 관리해라. 가장 위험한 건 완전히 틀린 결과가 아니라 거의 맞는 결과다. diff 리뷰나 샘플링 검수를 워크플로우 안에 미리 설계해 둔다.
- 완전자동을 KPI로 삼지 마라. ‘AI 초안 → 사람 검수’를 기본값으로 놓는다. 클라르나가 대신 수업료를 냈다.
- 도구보다 무형투자에 시간을 써라. 새 모델을 갈아 끼우는 것보다 업무 흐름 재설계, 데이터 정비, 프롬프트 자산화가 성패를 가른다.
사람 손을 남겨두는 게 왜 자산이 될까?
시장도 같은 신호를 보내고 있다. 유튜브는 2025년 7월 ‘비진정성 콘텐츠’ 정책을 도입했고, 2026년엔 템플릿 양산 콘텐츠와 금융·건강을 다루는 AI 페르소나를 수익화 제외 대상으로 못박았다.
소비자 조사도 뚜렷하다. Harris Poll·4As·Infillion 조사에서 78%가 “AI가 광고를 덜 진정성 있게 만든다”, 63%가 “AI 생성 광고를 쓰는 브랜드에서 구매할 가능성이 낮다”고 답했다.
한국도 마찬가지다. 메조미디어 조사(2025년 8월)에서 AI 광고는 “주목도가 높다” 59%였지만, “브랜드를 신뢰한다”는 34%, “구매하고 싶다”는 28%에 그쳤다. 눈길은 끌지만 지갑은 안 열린다는 뜻이다.
자주 묻는 질문
Q. HITL이 정확히 뭔가?
A. Human-in-the-Loop, 자동화 파이프라인 중간에 사람의 판단·승인 단계를 의도적으로 넣는 설계다. 전체를 수동으로 돌리는 것과는 다르다. 되돌릴 수 없는 지점 앞에만 사람을 배치한다.
Q. 그럼 AI 자동화는 하지 말라는 건가?
A. 반대다. 검증 장치가 있는 구간에서는 데이터상 20~50%대 시간 단축이 확인된다. 다만 검증 장치 없이 끝단까지 자동화하면 오히려 손해라는 얘기다.
Q. 내 업무가 자동화 가능한지 어떻게 판단하나?
A. 질문 하나면 된다. “결과물이 맞는지 사람 없이 확인할 방법이 있나?” 있으면 자동화, 없으면 초안 생성까지만.
Q. 코딩은 무조건 AI가 빠른가?
A. 아니다. METR 실험에서 자기 코드베이스에 익숙한 숙련 개발자는 오히려 19% 느려졌다. 익숙한 영역일수록 AI 제안 검토가 부담이 된다.
마무리
AI 회의론도 낙관론도 답이 아니다. 답은 “AI가 잘하는 곳에 AI를 두고, 사람이 필요한 곳에 사람을 두는 설계”다. 바이브코딩이 먼저 터진 건 그 업무가 이 조건을 가장 잘 만족했기 때문이지, 코딩이 특별해서가 아니다.
지금 돌리고 있는 워크플로우를 열어서, 노드 하나하나에 이 질문을 던져보자. “이 노드의 출력이 맞는지, 사람 없이 확인할 방법이 있나?” 없다면 거기가 바로 HITL 체크포인트를 넣을 자리다. 그 자리를 찾는 것만으로도 자동화 성공률이 달라진다.
다음 글에서는 n8n에서 실제로 HITL 승인 단계를 구현하는 방법을 다룰 예정이다. Wait for Approval 노드와 텔레그램 승인 버튼을 엮는 구성이다.
출처: Stanford AI Index 2026 / Peng et al.(2023, arXiv:2302.06590) / Dell’Acqua et al.(2023, Organization Science) / METR(2025, arXiv:2507.09089) / Stack Overflow Developer Survey 2025 / MIT NANDA(2025) / S&P Global Market Intelligence(2025) / Harris Poll·4As·Infillion / 메조미디어(2025.8)