토큰을 물처럼 쓰는 빅테크의 신화, 그 이면에 가려진 세 가지 구조적 한계

최근 소프트웨어 개발 업계에서 '루프 엔지니어링(Loop Engineering)'이 큰 주목을 받고 있다. AI가 코드를 생성하고(generate), 테스트하고(test), 배포(deploy)까지 자동화한 뒤 다시 그 결과를 입력으로 되먹이는 폐쇄 순환(closed-loop) 개발 방식을 뜻한다. 무한한 토큰을 가진 초거대 AI 조직처럼, 사람의 개입을 최소화한 채 제품을 끝없이 진화시키겠다는 비전이다.

하지만 현실은 다르다. 지금까지 루프 엔지니어링으로 유의미한 성과를 냈다고 알려진 사례는 대부분 토큰을 '물 쓰듯' 사용할 수 있는 LLM 기업이거나, 구글·메타·마이크로소프트 같은 빅테크 조직에 국한된다. 정작 산업 현장에서 제로 베이스(zero-base)로 시작해 실제 라이브 서비스로 연결된 사례는 찾아보기 어렵다. 본 칼럼은 루프 엔지니어링이 범용 해법으로 자리 잡지 못하는 결정적 병목 세 가지를, 구체적인 사례·레퍼런스와 함께 분석한다.

1. 토큰 부자들의 전유물 — 잘 정비된 문서·테스트·시나리오의 부재

루프 엔지니어링이 효과를 발휘하려면 LLM이 이해할 수 있는 풍부한 문서, 유저 시나리오, DB 관련 테스트 코드가 뒷받침되어야 한다. 이는 데이터 인프라가 막대한 조직만의 특권이다.

성공 사례 — 정비된 데이터 위에서만 작동하는 루프

빅테크의 성과는 예외 없이 '잘 정비된 사내 데이터'라는 토대 위에 서 있다.

  • 구글(Google): 사내 10,000명 이상의 개발자를 대상으로 8개 언어, 3개월에 걸쳐 ML 기반 코드 완성(ML-Enhanced Code Completion)을 적용했다. 그 결과 빌드-테스트 반복 시간(coding iteration time)이 6% 줄고, 컨텍스트 스위칭(context switch)은 7% 감소했으며, 제안 수용률(acceptance rate)은 25~34%에 달했다. 다만 ML이 실제로 작성한 코드는 전체의 약 3%에 그쳤다[1]. 즉, 막대한 자원을 투입해도 자동화의 실효 비중은 제한적이라는 점을 빅테크 스스로 보여준 셈이다.
  • 메타(Meta): 자사 코드베이스로 학습한 'CodeCompose'를 16,000명 엔지니어에게 배포해, 15일 동안 450만 건의 제안을 제공했다. 제안 수용률 22%, 개발자가 입력한 코드의 8%가 CodeCompose에서 나왔고, 정성 피드백의 91.5%가 긍정적이었다[2]. 주목할 점은 따로 있다. 메타는 학습 전 단계에서 'PHP-ism' 같은 구식 패턴과 프로덕션에 올라가지 않은 실험 코드를 의도적으로 걸러냈다. 양질의 데이터를 사람이 먼저 큐레이션했기에 루프가 작동한 것이다.
  • 마이크로소프트(Microsoft)/GitHub: 흔히 인용되는 "코파일럿으로 개발 속도 55% 향상"이라는 수치의 정확한 출처는, 마이크로소프트의 사내 일괄 적용 결과가 아니라 GitHub의 통제 실험(controlled experiment)이다. 전문 개발자 약 95명을 두 그룹으로 나눠 JavaScript HTTP 서버를 구현하게 했더니, 코파일럿을 쓴 그룹이 평균 71분 만에 완료해 대조군(161분)보다 55% 빨랐다(p=0.0017)[3]. 다만 이는 '명세가 명확하고 보편적인 단일 과제'라는 이상적 조건에서의 결과임을 분명히 해야 한다.

현실의 벽 — 정비되지 않은 환경에서는 버그가 양산된다

중소 규모 조직이나 스타트업의 사정은 전혀 다르다. 테스트 커버리지가 낮고 문서화가 미흡한 환경에 AI 코딩 도우미를 투입하면, 오히려 결함이 양산되는 역효과가 나타난다. 검토 없이 채택된 AI 생성 코드의 상당 부분(일부 분석에서는 약 48%)이 보안 취약점을 포함할 수 있다는 보고가 대표적이다[4]. 루프를 돌리려면 그 루프의 출력을 검증할 '벤치마크 데이터'가 먼저 필요한데, 대부분의 기업은 이를 갖추지 못한 채 유행만 좇다 실패한다.

요컨대 루프 엔지니어링의 1차 진입 장벽은 모델의 성능이 아니라 입력 데이터의 품질이며, 이는 본질적으로 '토큰 부자'들의 전유물이다.

2. 산업 도메인 지식의 사각지대 — LLM도 베스트 프랙티스를 찾지 못한다

LLM이 최적의 구현 패턴을 찾으려면, 해당 도메인의 코드와 아키텍처가 사전 학습(pre-training) 데이터에 충분히 반영되어 있어야 한다. 웹·모바일 앱처럼 보편적인 영역은 GitHub에 풍부하지만, 제조·금융·의료처럼 특수 산업의 핵심 로직은 공개 데이터에 거의 존재하지 않는다.

구체적 한계 사례 — 비즈니스 로직 앞에서 무너지는 변환

레거시 코드 현대화는 이 한계를 가장 선명하게 드러내는 분야다. COBOL은 지금도 전 세계 은행 거래의 약 70%를 처리하는 미션 크리티컬(mission-critical) 자산이다[5].

  • 범용 LLM의 한계: 한 실무 비교 분석에서, 범용 도구인 GitHub Copilot에 COBOL 프로그램의 Java 변환을 맡기자 비즈니스 로직과 시스템 컨텍스트에 대한 이해가 결여된 '피상적 변환'을 내놓았다. DB2 연동을 누락했고, 신규 고객번호 생성을 제어하는 NCS(Named Counter Server)의 역할도 인식하지 못했다[6]. 공개 데이터에 없는 도메인 규칙은 모델이 만들어낼 수 없다는 점을 보여준다.
  • 전용 도구조차 인간 검증이 필수: IBM은 1.6조 토큰으로 학습하고 수천 쌍의 COBOL-Java 프로그램으로 파인튜닝한 전용 모델(Granite 20B 기반 watsonx Code Assistant for Z)을 내놓았다[5]. 그러나 2026년 실무 리뷰는 여전히 "정제(refinement) 없이 프로덕션에 바로 쓸 수 있는 결과를 기대해서는 안 된다"고 명시한다. 즉, 전용 도구로도 시니어 개발자의 수작업 검증과 의미 동등성(semantic equivalence) 테스트가 빠질 수 없다[6].
  • 도메인 로직에서의 일관된 실패: 개발자 400여 명을 대상으로 한 ZoomInfo 사례에서도, 코파일럿은 보일러플레이트(boilerplate) 생성에는 유용했으나 도메인 특화 로직(domain-specific logic)에서는 고전했다[3].

정확한 산업 지식을 지시할 수 있는 인간 전문가의 개입 없이는, 루프는 그럴듯하지만 엉뚱한 방향으로 수렴할 뿐이다. 규제가 엄격한 금융·의료 환경일수록 이 사각지대의 위험은 더 커진다.

3. 경제성의 신기루 — 토큰 비용과 검증 인력이라는 이중 청구서

설령 1번(데이터)과 2번(도메인 지식)을 부분적으로 해결했다 해도, 마지막 관문이 남는다. 루프를 '계속 돌리는' 비용 자체다. 빅테크가 토큰을 물처럼 쓸 수 있는 이유는 단순하다. 자체 인프라를 보유했거나 모델 제조사 본인이기 때문이다. 일반 조직에는 매달 청구서가 날아온다.

첫 번째 청구서 — 폭주하는 토큰 비용

에이전트형(agentic) 코딩은 단순 채팅·추론 대비 압도적으로 비싸다.

  • 한 연구에 따르면 에이전트형 코딩 task는 채팅·코드 추론보다 약 1,000배 많은 토큰을 소비하며, 재시도와 자기교정(self-correction) 루프를 포함하면 task 하나당 100만~350만 토큰에 이른다[7][8].
  • 더 큰 문제는 예측 불가능성이다. 동일한 task를 반복 실행해도 토큰 사용량이 최대 30배까지 출렁이고, 토큰을 더 쓴다고 정확도가 올라가지도 않는다. 오히려 정확도는 중간 비용 구간에서 정점을 찍고 그 이상에서는 포화된다. 게다가 프런티어 모델은 자신의 토큰 비용을 제대로 예측하지 못하고 체계적으로 과소평가한다[8]. 예산을 세우는 행위 자체가 성립하지 않는 셈이다.
  • 비용은 곧장 현금 흐름으로 나타난다. Claude Code는 개발자 1인당 활성 사용일 기준 약 13달러, 자동화를 강하게 돌리면 엔지니어 1인당 월 500 ~ 2,000달러까지 치솟는다[9]. GitHub Copilot이 토큰 종량 과금으로 전환하자 개발자들은 10 ~ 50배의 비용 증가를 호소했고, 에이전트 세션을 돌리는 사용자는 월 750~3,000달러를 전망했다. 특히 '바이브 코딩(vibe coding)'에 의존하던 비개발자 그룹이 가장 큰 타격을 입었다[10].

나 역시 효율적으로 토큰을 사용하기 위해 다양한 LLM을 목적에 맞춰 사용하고 있지만, 토큰을 태우는 비용을 인공지능 타이쿤에 투자하는 것이 더 투자 대비 ROI가 좋을 것이라는 결론에 도달했다. 결국 보안이나 주의할 부분은 인간이 보고 확인해야하며, 확실히 더 LLM이 이해할 문서를 만들어야 효율적이었다.

두 번째 청구서 — 숨겨진 검증 인력 비용

루프의 출력은 공짜로 신뢰할 수 없다. 누군가는 읽고, 검증하고, 고쳐야 한다. 그리고 그 비용은 종종 절감 효과를 상쇄한다.

  • 비영리 연구기관 METR이 2025년 수행한 무작위 대조 시험(RCT)은 통념을 정면으로 뒤집었다. 평균 100만 줄 규모의 성숙한 오픈소스 저장소에서 246개의 실제 task를 수행한 숙련 개발자 16명은, AI 도구를 사용했을 때 오히려 작업이 19% 느려졌다. 그런데도 본인들은 20% 빨라졌다고 믿었다[11].
  • 다만 이 결과는 신중히 해석해야 한다(불확실성 라벨: 중간). METR 자신이 2026년 후속 검토에서 선택 편향(selection effect) 가능성을 인정하고 실험 설계를 수정 중이며, 일부 후속 추정에서는 기존 참가자 -18%, 신규 참가자 -4%로 효과 크기가 달라졌다[12]. 즉, "AI는 항상 느리게 만든다"는 법칙이 아니라, 성숙한 코드베이스에서는 검증 부담이 생산성 이득을 잠식할 수 있다는 강한 신호로 읽어야 한다.

종합 — 빅테크의 회계로만 닫히는 ROI

결국 루프 엔지니어링의 투자수익률(ROI)은 토큰을 한계비용 0에 가깝게 조달할 수 있는 빅테크의 회계 장부에서만 일정 부분 가능하다. 일반 조직에서는 (1) 변동성이 큰 토큰 비용과 (2) 줄지 않는 검증 인력 비용이 합쳐진 '이중 청구서'가, 보장되지도 않는 속도 향상과 맞교환된다. 코딩에 대한 이해, 산업 도메인 이해가 되지 않는다면 그저 헛도는 무한 루프만 될 수 밖에 없다.

세 가지 병목 요약

구조적 병목 왜 빅테크는 통과하는가 왜 일반 조직은 실패하는가
1. 입력 데이터 (문서·테스트·시나리오) 사내에 정비·큐레이션된 코드, 테스트, 시나리오가 방대하게 축적 (예: 메타의 학습 데이터 사전 필터링) 테스트 커버리지·문서화 부족 → 검증 기준 부재, 버그 양산
2. 도메인 지식 (산업 특화 로직) 자사 도메인 데이터로 직접 파인튜닝 가능 제조·금융·의료 핵심 로직이 공개 데이터에 부재 → 피상적·오류 변환
3. 경제성 (토큰·검증 비용) 자체 인프라/모델 보유 → 토큰 한계비용 ≈ 0 task당 100만~350만 토큰, 최대 30배 변동 + 검증 인력 비용 → ROI 미달

결론 — 루프는 전동공구이지, 자율 오라클이 아니다

루프 엔지니어링의 빅테크 성공담을 그대로 이식하려는 시도는 대개 실패한다. 성공의 본질이 '뛰어난 AI 모델'이 아니라, 그 모델을 둘러싼 정비된 데이터·축적된 도메인 지식·한계비용 0의 토큰 조달이라는 세 가지 인프라적 전제에 있었기 때문이다. 이 전제가 없는 조직에서 사람의 개입을 걷어낸 완전 자동 루프를 기대하는 것은, 도구의 성능을 인프라의 부재로 메우려는 착시에 가깝다.

"LLM은 엑셀이지 오라클이 아니다." 엑셀이 계산을 가속하지만 회계 판단까지 대신하지 않듯, 루프는 개발을 가속하는 전동공구일 뿐 자율적으로 옳은 제품을 빚어내는 신탁(oracle)이 아니다. 현실적인 전략은 폐쇄 루프 신화를 좇는 대신, 사람이 검증 고리(human-in-the-loop)에 남아 있는 점진적·부분적 자동화를 먼저 정착시키고, 그 위에서 데이터와 도메인 지식을 축적해 루프의 반경을 천천히 넓혀 가는 것이다.

참고문헌 (References)

  1. Google Research, "ML-Enhanced Code Completion Improves Developer Productivity," 2022. (사내 1만 명+ / 8개 언어 / 반복시간 6% 감소 / ML 코드 비중 약 3% / 수용률 25–34%)
  2. Murali, A. et al., "AI-assisted Code Authoring at Scale: Fine-tuning, deploying, and mixed methods evaluation (CodeCompose)," Proc. ACM Softw. Eng. (FSE), 2024. (수용률 22% / 입력 코드의 8% / 긍정 91.5%)
  3. Peng, S. et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv:2302.06590, 2023; GitHub Research Blog, 2022. (통제 실험 약 95명, 55% 단축); ZoomInfo 도메인 로직 한계 관련: Bakal et al. (arXiv:2502.13199 인용).
  4. AI 생성 코드 보안 취약점 관련 보고(미검토 코드 일부에서 약 48% 취약점 포함 가능) 및 Stanford 연구(AI 코딩 도구 사용 시 보안 결함 증가 경향). 공개 2차 보도 기반, 정밀 수치는 환경 의존적임(불확실성: 중).
  5. IBM Research, "Application modernization with IBM generative AI (watsonx Code Assistant for Z)," 2023–2025. (Granite 20B / 1.6조 토큰 학습 / COBOL이 전 세계 은행 거래 약 70% 처리)
  6. CROZ, "An Honest Take on watsonx Code Assistant for Z," 2026 (실무 리뷰); Vicky's Notes(Medium), "Comparing AI Tools for COBOL2Java," 2024 (Copilot의 비즈니스 로직 누락·NCS 미인식 사례).
  7. iternal.ai, "Tokenization in NLP: Tokens, Usage & Cost Guide," 2026. (에이전트형 코딩 task당 100만~350만 토큰)
  8. Stanford Digital Economy Lab, "How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks," arXiv:2604.22750, 2026. (채팅 대비 약 1,000배 / 동일 task 최대 30배 변동 / 비용↑이 정확도↑로 직결되지 않음 / 자기 비용 예측 실패)
  9. Atlas Cloud, "How to Reduce AI Coding Token Cost," 2026 (CloudZero 2026 인용). (Claude Code 1인 활성일 약 $13 / 자동화 시 월 $500–$2,000)
  10. TechJournal, "GitHub Copilot Token Billing Backlash," 2026. (종량 과금 전환 후 10–50배 비용 증가 호소 / 에이전트 세션 월 $750–$3,000 전망 / 바이브 코더 최대 타격)
  11. Becker, J., Rush, N., Barnes, E., Rein, D., "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR / arXiv:2507.09089, 2025. (숙련 개발자 16명·246 task, AI 사용 시 19% 지연, 본인 인식은 20% 단축)
  12. METR, "We are Changing our Developer Productivity Experiment Design," 2026. (선택 편향 인정 및 설계 수정 / 후속 추정: 기존 -18%, 신규 -4%)

본 칼럼의 모든 정량 수치는 공개된 1차·2차 출처에 근거하며, 출처별 측정 조건이 상이하므로 직접 비교 시 주의가 필요하다. 확정된 결과와 해석상의 추정은 본문에서 구분해 표기했다.