요즘 마이크로소프트조차 클로드(Claude) 비용을 감당하기 어렵다고 한다. 이 말이 심상치 않게 들리지 않나. 사실 토큰 단가는 GPT-3.5급 기준으로 보면 몇 년 새 280배나 저렴해졌다는 분석도 있다. 그런데 왜 다들 AI 비용 압박을 느낀다고 할까.

원문을 보니 답은 명확하다. 문제는 단가가 아니라 '사용량'에 있다. AI가 비싸졌다기보다, AI를 너무 빨리, 너무 많이 쓰기 시작한 것이다. 단가는 내려가도 총 사용량이 폭증하면 예산은 당연히 터지는 법이다.

에이전트 시대, AI 호출 공장이 돌아간다

이 변화의 중심에는 '에이전트'가 있다. 과거의 AI 사용은 채팅에 가까웠다. 질문 하나 던지고 답변 하나 받는 식이었다. 하지만 에이전트는 다르다. 계획을 세우고, 파일을 읽고, 검색하고, 코드를 고치고, 테스트하고, 실패하면 다시 읽고, 다시 쓰고, 다시 검증한다.

사용자 입장에서는 "클로드 코드 한 번 돌렸다"처럼 느껴질지 모른다. 하지만 그 뒤에서는 작은 LLM 호출 공장이 수십 번, 때로는 수백 번의 추론을 쏟아낸다. 깃허브(GitHub)가 코파일럿(Copilot)을 사용량 기반(usage-based) 과금으로 전환한 이유도 여기에 있다. 빠른 채팅 질문과 몇 시간짜리 자율 코딩 세션을 같은 가격으로 취급하는 모델은 지속 가능하지 않다고 본 것이다. AI가 에이전트가 되는 순간, 비용은 질문 수가 아니라 '추론량'의 문제가 된다.

그럼 우리는 AI를 덜 써야 할까? 원문 필자는 오히려 AI를 더 깊게 쓰기 위한 구조가 필요하다고 말한다. 더 긴 메모리, 더 많은 작업 맥락, 과거 의사결정 기록 등을 주입해 효과적으로 일하게 만들려면, 당연히 토큰은 더 많이 든다. 오픈라우터(OpenRouter)의 분석에서도 평균 프롬프트 길이는 2024년 초 이후 거의 4배 늘었고, 완성 토큰도 거의 3배 늘었다고 한다. 특히 프로그래밍 작업이 이 증가를 크게 밀고 있다.

모든 작업에 가장 비싼 모델을 쓸 필요는 없다: LLM 라우터

해결책은 '무작정 싼 모델로 바꾸자'가 아니다. 어떤 요청에 어떤 모델을 쓸지, 어떤 맥락을 넣을지, 어디까지 캐시할지, 언제 강한 모델을 호출할지를 판단하는 '라우팅 구조'가 필요하다. 즉, 똑똑한 LLM 라우터가 답이라는 얘기다.

좋은 LLM 라우터는 모든 요청을 가장 비싼 모델로 보내지 않는다. 어떤 일은 작은 모델로 처리하고, 어떤 일은 규칙 기반 로직이나 캐시로 끝낸다. 이미 주입된 메모리를 다시 쓰는 경우도 있다. 정말 긴 맥락과 어려운 판단이 필요한 순간에만 가장 강한 모델을 쓰는 것이다.

핵심은 단순히 비용 절감이 아니다. 같은 예산 안에서 더 많은 메모리를 넣고, 더 많은 맥락을 유지하며, 가장 중요한 판단에 고급 모델을 쓰기 위한 구조를 만드는 것이다. 앞으로 AI를 잘 쓰는 조직은 '가장 좋은 모델을 쓰는 조직'이 아니라, '어떤 문제에 어느 정도의 지능을 써야 하는지 아는 조직'이 될 것이다.

AI 도입, 현장에서 답을 찾다: FDE와 신중한 자동화

LLM 라우터가 기술적인 측면에서 지능 배분을 고민하게 한다면, AI를 현장에 도입하는 과정에서도 '어떤 지능이 필요한가'에 대한 깊은 고민이 필요하다. 최근 수요가 폭증하는 직무 중 하나가 FDE(Forward Deployed Engineer)라고 한다. 이들은 고객사 현장에 직접 들어가 AI를 구현하는 사람들이다.

FDE는 단순히 기술만 아는 엔지니어가 아니다. 고객 문제를 깊이 이해하고 처음 보는 코드베이스에 바로 코드를 쓸 수 있어야 한다. 동시에 비기술 의사결정자에게 비즈니스 임팩트를 설명해서 계약까지 끌어내는 역할을 한다. 기술과 비즈니스 커뮤니케이션 능력을 모두 요구하는 자리다.

특히 FDE는 진단(Audit), 검증(Evals), 배포(Deployment)의 세 단계를 거치며, 자동화 대상을 매우 신중하게 고른다. 예를 들어, 규칙은 정해져 있는데 이메일, PDF, 스캔 이미지 등 입력이 다양한 지점에 에이전트를 도입한다. 하지만 규칙과 입력이 모두 예측 가능하다면 에이전트보다 코드가 더 빠르고 저렴하다. 패턴 인식과 도메인 전문성이 필요한 일은 사람에게 맡겨야 한다.

중요한 점은 'AI를 과도하게 쓰는 것도 경계해야 할 대상'이라는 것이다. 대부분의 자동화는 툴 콜 몇 번과 LLM 호출 한 번이면 충분하다고 한다. 작업 내용 대비 AI를 많이 쓸수록 토큰 비용 지출만 커지고, 오히려 출력 품질은 떨어진다. FDE의 역할은 최소 범위의 자율성부터 시작하며, AI가 정답이 아닌 상황을 솔직하게 말할 줄 아는 비즈니스 커뮤니케이터 역할도 포함한다. 결국 AI를 '얼마나' 쓸지, '어디에' 쓸지 판단하는 지혜가 필요한 것이다.

마크다운 대신 HTML, AI와 더 똑똑하게 소통하기

마지막으로, 앤스로픽(Anthropic) 엔지니어 타리크 쉬히파르(Thariq Shihipar)의 흥미로운 시도가 있다. 그는 AI 에이전트와 소통하고 계획을 세울 때 마크다운 대신 HTML을 활용한다고 한다. "AI 생성 토큰의 99%는 프로덕션 코드가 아니라 계획, 인터페이스, 커뮤니케이션에 사용되어야 한다"는 그의 주장은 우리가 AI를 바라보는 관점을 바꾼다.

HTML을 사용하면 인터랙티브한 계획, 임시 UI, 살아있는 디자인 시스템을 만들 수 있다. 이는 시각적이고 풍부한 형식으로 인간의 참여를 높이고, 궁극적으로 제품 품질까지 끌어올리는 데 기여한다. 단순히 텍스트 기반의 지시를 내리는 것을 넘어, AI와 시각적인 맥락을 주고받으며 훨씬 더 효율적이고 정교한 협업이 가능해지는 것이다.

이는 AI가 단순한 '노가다 도구'가 아니라, '계획하고 소통하는 협업 파트너'로 진화하고 있음을 보여준다. HTML을 통해 복잡한 계획을 시각화하고, 불필요한 AI 호출을 줄이며, 인간의 피드백을 더 효과적으로 반영할 수 있다면, 이것 역시 AI 지능을 똑똑하게 배분하는 중요한 전략이 된다.

결국, AI 지능을 아는 지혜

세 기사를 관통하는 핵심은 명확하다. AI 시대에는 '가장 강한 모델'을 무조건 쓰는 것이 능사가 아니다. 오히려 어떤 상황에 어떤 지능이 필요한지 정확히 파악하고, 그 지능을 효율적으로 배분하고 활용하는 전략이 훨씬 중요하다. 비용 측면에서는 LLM 라우터로 똑똑하게 모델을 선택하고, 현장 적용에서는 FDE처럼 비즈니스 맥락을 이해하며 자동화 대상을 신중하게 선별해야 한다. AI와의 소통 방식 또한 HTML처럼 더 풍부하고 효율적인 방식으로 진화해야 한다.

AI의 시대는 '지능의 풍요'를 가져왔지만, 동시에 그 지능을 현명하게 다룰 줄 아는 '지혜'를 요구한다. 우리 조직은 지금 AI 지능을 얼마나 똑똑하게 배분하고 있을까?

참고

  1. 정구봉 (Goobong Jeong). "AI 비용: 단가 아닌 사용량, 답은 LLM 라우터". LinkedIn. 2026-05-23.
  2. 이정민 (Jeongmin Lee). "수요 폭증 FDE: AI 현장 구현 실무 가이드". LinkedIn. 2026-05-22.
  3. Claire Vo. "HTML is the new Markdown: How Anthropic engineers are building with Claude Code | Thariq Shihipar". Lenny's Newsletter. 2026-05-18.