AI 코딩 비서의 보이지 않는 야근 수당: 클로드 코드의 3만 3천 토큰 미스터리

시작은 2만 5천 달러짜리 '카피바라 게임'이었습니다

며칠 전 흥미로운 소식을 들었습니다. 한 개발자가 AI 코딩 도우미인 '클로드 코드(Claude Code)'만 써서 2주 만에 '카피바라 게임'이라는 웹 게임을 만들었고, 이걸로 2만 5천 달러(약 3천 5백만 원)를 벌었다는 이야기였습니다. 코딩의 'ㅋ'자도 모르는 기획자나 디자이너가 혼자서 앱을 뚝딱 만들어내는 시대가 정말 오는 건가, 솔깃했습니다.

저도 엔지니어로서 이런 도구를 그냥 지나칠 수 없습니다. 당장 클로드 코드를 붙잡고 며칠간 이런저런 프로젝트를 시켜봤습니다. 간단한 데이터 분석 스크립트부터 만들어 둔 웹사이트에 자잘한 기능을 덧붙이는 일까지. 처음 몇 시간은 감탄의 연속이었습니다. 막히는 부분을 한국말로 물어보면 제법 그럴듯한 코드를 내놓았고, 귀찮은 반복 작업은 순식간에 끝내줬습니다. 생산성이 서너 배는 오르는 기분이었습니다. '이러다 정말 내 일자리가 없어지는 거 아닌가' 하는 시큰둥한 농담을 스스로에게 던지면서 말입니다.

그런데 며칠 뒤 API 사용 내역을 보고는 눈을 비볐습니다. 제가 생각했던 것보다 훨씬 많은 비용이 청구되어 있었습니다. 분명 복잡한 질문은 몇 번 하지도 않았는데, 마치 택시 기본요금이 몇 만 원부터 시작하는 것처럼 이상하게 비용이 쌓여 있었습니다. 처음에는 제가 뭔가를 잘못 설정했거나, 밤새 오류가 나서 무한 루프라도 돈 줄 알았습니다.

알고 보니 저만 겪은 일이 아니었습니다. 개발자 커뮤니티인 '해커 뉴스'에서 비슷한 경험을 한 개발자들이 원인을 파헤친 보고서가 올라왔고, 문제는 순식간에 뜨거운 감자가 됐습니다. 원인은 충격적이었습니다. 클로드 코드는 제가 키보드에 손을 얹어 첫 질문을 입력하기도 전에, 혼자서 무려 3만 3천 '토큰'이라는 걸 쓰고 있었다는 겁니다. 제가 시키지도 않은 일을 먼저 하면서 돈을 쓰고 있었던 셈입니다.

'토큰'이 뭔데 자꾸 돈 이야기를 합니까?

여기서 '토큰(Token)'이란 개념을 먼저 짚고 넘어가야 합니다. 어렵게 생각할 것 없습니다. AI 언어 모델을 쓸 때 내는 일종의 '글자당 통화료'라고 보시면 됩니다. 우리가 카카오톡 메시지를 보낼 때 데이터가 소모되듯, AI에게 말을 걸 때마다 글자 단위로 비용이 나갑니다. 다만 데이터처럼 용량 단위가 아니라, AI가 이해하는 의미 단위인 '토큰'으로 계산될 뿐입니다.

보통 영어는 한 단어가 1토큰, 한국어는 한 글자가 2~3토큰 정도를 차지합니다. 예를 들어 'Apple'은 1토큰이지만, '사과'는 2토큰(사, 과)으로 쪼개지는 식입니다. 앤트로픽(Anthropic)사의 클로드 3 오푸스(Claude 3 Opus) 모델 기준으로, 1백만 토큰을 처리하는 데 약 15달러(입력 기준) 정도가 듭니다. 3만 3천 토큰이면 대략 0.5달러, 우리 돈으로 700원 정도입니다. 한번 질문할 때마다 700원이 추가로 붙는 셈이죠. 이게 별거 아닌 것 같아도, 개발 과정에서 수백, 수천 번 질문을 던진다고 생각하면 이야기가 달라집니다. 티끌 모아 태산이 아니라, 티끌이 어느새 태산이 되어 있는 겁니다.

이런 AI 모델을 LLM(Large Language Model)이라고 부릅니다. 쉽게 말해, 사람 말을 흉내 내 문장을 만들어내는 거대 글짓기 AI입니다. 인터넷의 수많은 글과 책을 읽고 단어와 단어 사이의 관계를 확률적으로 학습해서, '하늘은' 다음에는 '푸르다'가 올 확률이 높다고 예측하는 원리입니다.

개발자들은 이 LLM을 직접 쓸 때 보통 API(Application Programming Interface)라는 창구를 이용합니다. 식당에 비유하면 API는 '점원'입니다. 제가 점원에게 "파이썬 코드로 웹사이트 방문자 수를 세는 함수를 만들어줘"라고 주문(API 요청)하면, 점원은 주방(LLM)에 주문을 전달합니다. 그러면 주방장이 뚝딱 요리해서(AI가 코드 생성) 점원을 통해 저에게 코드를 가져다주는(API 응답) 식이죠. 이 과정에서 제가 점원에게 말한 내용(입력 토큰)과, 점원이 저에게 가져다준 요리(출력 토큰) 모두에 대해 돈을 냅니다. 왕복 통행료를 내는 셈입니다.

문제는 제가 주문하기도 전에, 주방장이 혼자 '오늘의 추천 메뉴'를 준비하느라 비싼 재료를 왕창 쓰고 있었다는 사실입니다. 그 비용이 고스란히 제 식사비에 포함되고 있었던 겁니다.

3만 3천 토큰, 보이지 않는 '시스템 프롬프트'의 정체

그렇다면 클로드 코드는 대체 왜, 무슨 목적으로 사용자 몰래 3만 3천 토큰이나 쓰고 있었을까요? 이건 버그나 실수가 아닙니다. 오히려 더 좋은 결과물을 내기 위한 의도된 설계에 가깝습니다. 바로 '시스템 프롬프트(System Prompt)' 때문입니다.

시스템 프롬프트란, AI에게 본격적인 작업을 시키기 전에 미리 역할을 부여하고 상세한 규칙을 알려주는 '사전 업무 지시서' 같은 겁니다. 마치 새로 온 알바생에게 일을 시키기 전에 "너는 이제부터 우리 가게 최고의 바리스타야. 손님에겐 항상 웃으며 인사하고, 라떼를 만들 땐 우유 거품을 1.5cm 두께로 만들어야 해. 질문에 답할 땐 항상 '네, 고객님'으로 시작해." 와 같이 빼곡하게 적힌 매뉴얼을 쥐여주는 것과 같습니다.

클로드 코드는 이 '업무 지시서'가 유난히 길고 꼼꼼했던 겁니다. 약 3만 3천 토큰에 달하는 이 시스템 프롬프트 안에는 아마 이런 내용이 들어있을 겁니다.

• '너는 세계 최고의 소프트웨어 엔지니어다. 명확하고, 효율적이며, 유지보수하기 쉬운 코드를 작성해야 한다.'
• '사용자의 요구사항을 정확히 파악하고, 애매한 부분이 있으면 질문을 통해 명확히 해야 한다.'
• '보안 취약점이 없는 코드를 작성하는 것을 최우선으로 생각해야 한다.'
• '코드를 제공할 때는 반드시 특정 형식(예: 마크다운 코드 블록)을 사용하고, 어떤 언어인지 명시해야 한다.'

이런 수백 개의 규칙과 가이드라인을 매번 대화를 시작할 때마다 AI에게 먼저 읽게 시키는 겁니다. 그러니 사용자가 "안녕?" 한마디만 입력해도, 내부적으로는 3만 3천 토큰짜리 지시사항과 "안녕?"이라는 사용자 질문이 합쳐져서 AI에게 전달됩니다. 비용은 당연히 3만 3천 토큰 + α부터 시작하는 거죠.

비교 대상으로 거론된 '오픈코드(OpenCode)'라는 다른 도구는 이 시스템 프롬프트가 약 7,000 토큰 수준이었다고 합니다. 클로드 코드가 약 4~5배 더 많은 '사전 준비'를 하는 셈입니다. 그렇다고 클로드 코드가 나쁘고 오픈코드가 좋다는 이분법적인 이야기는 아닙니다. 이건 전략의 차이입니다.

결국 클로드 코드는 '비용이 좀 들더라도, 어떤 상황에서든 최고의 결과물을 내겠다'는 길을 택한 것이고, 오픈코드는 '간단한 일은 가볍고 싸게 처리하자'는 길을 택한 겁니다. 문제는, 사용자가 이 사실을 모른 채 '간단한 계란 프라이'를 주문하면서 '풀코스 요리' 비용을 내고 있었다는 점입니다.

새롭지 않은 문제입니다: CASE 도구와 4세대 언어의 추억

사실 이런 '자동화의 배신'은 IT 역사에서 낯선 풍경이 아닙니다. 엔지니어들은 수십 년째 비슷한 꿈을 꾸고, 비슷한 현실에 부딪혀 왔습니다.

1980년대 후반과 90년대 초반, 'CASE(Computer-Aided Software Engineering) 도구'라는 것이 있었습니다. '코딩 없는 개발'이라는, 지금과 똑같은 구호를 내걸었죠. 개발자가 다이어그램을 그리고 마우스로 버튼을 누르면, 컴퓨터가 알아서 코드를 생성해 프로그램을 완성해준다는 환상이었습니다. 저도 학생 때 잠시 써 본 기억이 납니다. 결과는 어땠을까요? 대부분 실패했습니다. 간단한 화면이나 정해진 로직은 만들 수 있었지만, 조금만 복잡한 비즈니스 규칙이 들어가면 결국 개발자가 직접 코드를 수정해야 했습니다. 심지어 CASE 도구가 자동으로 생성한 코드는 너무 복잡하고 비효율적이어서 '손대지 말아야 할 영역'으로 취급받기까지 했습니다. 편리함을 얻는 대가로 유연성과 성능, 그리고 비싼 라이선스 비용을 치러야 했던 겁니다. AI 코딩 에이전트의 '숨겨진 토큰 비용'과 정확히 같은 구조입니다.

'4세대 언어(4GL)'도 마찬가지입니다. SQL처럼 인간의 언어와 가깝게 만들어 생산성을 극적으로 높이겠다는 목표를 가졌습니다. "Select all users from Seoul"이라고 쓰면 알아서 데이터를 가져오는 식이죠. 일부는 데이터베이스 조회 등 특정 영역에서 큰 성공을 거뒀습니다. 하지만 복잡한 알고리즘을 구현하거나, 시스템의 성능을 1%라도 더 끌어올려야 하는 세밀한 작업은 여전히 C언어나 자바 같은 3세대 언어의 몫으로 남았습니다. '편리함'이 언제나 '효율'과 '비용'을 이길 수는 없다는 교훈을 남겼습니다.

가장 가까운 예시는 최근 몇 년간 유행한 '노코드(No-Code) / 로우코드(Low-Code)' 플랫폼입니다. 코딩 없이 블록을 조립하듯 앱을 만들게 해주는 서비스들이죠. 분명 간단한 사내 관리 도구나 개인용 웹사이트를 만드는 데는 혁신적인 생산성을 보여줍니다. 하지만 사용자가 늘어나고 기능이 조금만 복잡해지면 플랫폼의 한계에 부딪히거나, 감당하기 힘든 수준의 비싼 요금제를 써야 하는 '벽'을 만나게 됩니다.

이 모든 역사가 말해주는 것은 하나입니다. 개발의 본질적인 복잡성은 사라지지 않는다는 것. 그저 한 곳에서 다른 곳으로 옮겨갈 뿐입니다. 코드를 짜는 수고를 덜어주는 대신, 어떤 도구를 쓸지, 어떻게 써야 비용을 아낄 수 있을지, 도구의 한계는 무엇인지 고민하는 새로운 종류의 수고가 생겨나는 겁니다.

그래서, 우리는 무엇을 놓치고 있었나: '판단의 값'

이번 '숨겨진 토큰' 사건은 단순히 '클로드 코드가 비싸다'는 차원의 문제가 아닙니다. AI 시대에 개발자의 역할과 가치가 어떻게 변하고 있는지를 보여주는 중요한 변곡점입니다. 많은 사람들이 흔히 하는 오해 두 가지를 짚어보겠습니다.

• 흔한 오해 1: "AI가 코딩을 다 해주니 이제 개발자는 필요 없어진다."
• 올바른 해석: "아닙니다. 어떤 AI 도구를, 어떤 작업에, 어떤 방식으로 써야 가장 효율적인지 '판단'하는 개발자의 역할이 훨씬 더 중요해집니다." 단순히 벽돌을 나르던 역할에서, 어떤 벽돌을 어떤 크레인으로 나를지 결정하는 '현장 감독'의 역할로 바뀌는 것에 가깝습니다.

• 흔한 오해 2: "토큰을 많이 쓰는 비싼 AI가 더 좋은 AI다."
• 올바른 해석: "아닙니다. '소 잡는 칼로 닭 잡는다'는 말이 있듯, 작업의 성격에 따라 다릅니다." 간단한 텍스트 변환 스크립트를 짜는 데 3만 3천 토큰을 쓰는 건 명백한 낭비입니다. 반면 수백만 사용자를 감당해야 하는 시스템의 전체 아키텍처를 설계하는 일이라면, 3만 3천 토큰의 상세한 가이드라인이 오히려 큰 도움이 될 수 있습니다. 중요한 건 '절대 성능'이 아니라 '비용 대비 효과'입니다.

결국 AI 시대의 새로운 병목 지점은 '코드 작성 능력'이 아니라 '판단 능력'입니다. 개발자는 이제 다음과 같은 질문에 답해야 합니다.

1. 도구 선택의 판단: 이 일은 클로드 코드에게 맡기는 게 나을까? 아니면 더 가벼운 모델이나 오픈코드 같은 도구가 적합할까? 혹은 그냥 내가 30분 만에 직접 짜는 게 가장 싼 방법은 아닐까?
2. 비용-효과 판단: 이 기능을 구현하기 위해 AI에게 10달러어치 토큰을 쓰는 것이 과연 사업적으로 가치가 있는 일인가? 사용 빈도가 낮은 기능이라면, 조금 덜 완벽하더라도 더 저렴한 방식으로 구현할 방법은 없을까?
3. 결과물 검증의 판단: AI가 내놓은 코드가 겉보기엔 그럴듯하지만, 정말 최적의 코드일까? 눈에 보이지 않는 보안 구멍이나 성능 저하 문제는 없을까? 이 코드를 나중에 다른 사람이 유지보수할 수 있을까?

이런 판단 하나하나가 곧 돈과 직결됩니다. 잘못된 판단 한 번에 수백, 수천 달러의 API 비용이 순식간에 증발할 수 있습니다. 키보드를 두드리는 시간은 줄었지만, 결정의 무게는 훨씬 무거워졌습니다. 개발자의 가치는 이제 '판단의 값'으로 매겨지기 시작했습니다.

앞으로 우리가 추적해야 할 신호들

그렇다면 앞으로 우리는 이 변화의 흐름 속에서 무엇을 눈여겨봐야 할까요? 몇 가지 중요한 신호들이 있습니다.

- 신호 1: '토큰 계기판'의 보편화 마치 자동차의 연비 표시 기능처럼, 앞으로 AI 개발 도구나 코드 에디터에는 실시간 토큰 사용량과 예상 비용을 보여주는 '계기판'이 기본으로 탑재될 겁니다. 내가 입력하는 프롬프트의 토큰 수는 얼마인지, 시스템 프롬프트는 몇 토큰을 차지하는지, AI의 답변 길이에 따라 예상 비용이 어떻게 달라지는지 투명하게 보여주는 거죠. 이런 '비용 투명성'을 먼저 제공하는 도구가 개발자들의 신뢰를 얻고 시장을 주도할 가능성이 높습니다.

- 신호 2: '경량 모델 오케스트레이션'의 부상 모든 일을 최고급 모델 하나에게만 맡기는 건 비효율적입니다. 앞으로는 작업의 난이도에 따라 여러 AI 모델을 지휘하듯 조합해서 쓰는 '오케스트레이션(Orchestration)' 패턴이 대세가 될 겁니다. 예를 들어, 사용자의 의도를 파악하고 전체적인 계획을 세우는 복잡한 일은 GPT-4o나 클로드 오푸스 같은 비싸고 똑똑한 '마스터 셰프'에게 맡기고, 계획에 따라 단순 코드를 생성하거나 데이터를 변환하는 자잘한 일은 클로드 하이쿠 같은 저렴하고 빠른 '보조 요리사'에게 나눠주는 식입니다. 앤트로픽 스스로도 최근 이런 방식으로 비싼 모델의 성능을 96% 유지하면서 비용은 46%까지 절감했다는 연구 결과를 발표하기도 했습니다.

- 신호 3: 프롬프트 엔지니어링의 진화 단순히 AI에게 '좋은 질문'을 던지는 수준을 넘어, 비용 효율까지 고려하는 방향으로 진화할 겁니다. 특히 '숨겨진 비용'의 주범인 시스템 프롬프트를 어떻게 하면 더 적은 토큰으로, 더 명확하게 작성할 수 있을지에 대한 연구가 활발해질 겁니다. 불필요한 수식어를 덜어내고 핵심 지시사항만 남겨 시스템 프롬프트의 '토큰 다이어트'를 하는 전문가가 높은 가치를 인정받게 될 수도 있습니다.

결국 기술은 다시 '효율'의 문제로 돌아오고 있습니다. 누가 더 화려한 기술을 가졌는지가 아니라, 누가 같은 결과물을 더 싸고 현명하게 만들어내는지가 새로운 경쟁의 축이 될 것입니다.

Q&A: 독자들이 던질 법한 질문들

Q. 그래서 결론적으로 클로드 코드는 쓰지 말라는 건가요? A. 아닙니다. 무조건 나쁘다는 뜻이 아닙니다. 마치 최고급 전문가용 카메라와 같습니다. 작품 사진을 찍는 전문가에게는 그만한 값어치를 하지만, 가족 여행 기념사진을 찍는 데는 너무 무겁고 비쌀 수 있습니다. 아주 복잡하고 중요한 소프트웨어 아키텍처를 설계할 때는 클로드 코드의 꼼꼼한 가이드라인이 오히려 빛을 발할 수 있습니다. 다만 동네 슈퍼 가는데 F1 경주용 차를 몰 필요는 없다는 이야기입니다. 내 작업의 규모와 복잡도를 먼저 따져보고, 그에 맞는 도구를 '알고' 선택하는 지혜가 필요합니다.

Q. 코딩을 모르는 일반인도 이런 AI 코딩 도구를 써서 돈을 벌 수 있나요? 비용은 얼마나 드나요? A. 네, '카피바라 게임' 사례처럼 불가능한 일은 아닙니다. 최근에는 월 20~30달러 정도의 구독료만 내면 꽤 많은 양을 쓸 수 있는 ChatGPT 유료 버전이나 클로드 프로 같은 서비스가 많아져 진입 장벽이 낮아졌습니다. 하지만 API를 직접 연결해 프로그램을 만드는 건 완전히 다른 문제입니다. 앞서 말씀드린 '보이지 않는 비용' 때문에 자칫 잘못하면 하룻밤 사이에 수십, 수백 달러가 청구될 수 있습니다. 취미로라도 API를 사용해볼 생각이라면, 반드시 카드사에 사용량 알림을 설정하거나 API 제공 사이트에서 비용 한도를 낮게 설정해두는 습관을 들여야 합니다. 월세방 보증금 빼서 AI 이용료 내는 일은 없어야 합니다.

Q. 이 '숨겨진 토큰' 문제를 근본적으로 해결할 기술은 없나요? A. 여러 시도가 있습니다. 모델 자체를 더 작고 효율적으로 만드는 연구가 계속되고 있고, 앞서 말씀드린 여러 모델을 조합해 쓰는 '오케스트레이션' 방법도 좋은 대안입니다. 또 다른 접근법은 AI가 매번 처음부터 배우는 게 아니라, 중요한 정보를 미리 압축해서 '기억'하게 만드는 기술(RAG, 파인튜닝 등)을 쓰는 겁니다. 하지만 어떤 기술도 '공짜 점심'은 아닙니다. 각 기술은 또 다른 종류의 복잡성과 관리 비용을 수반합니다. 결국 어떤 기술을, 어떤 상황에 적용할지 '판단'하는 것은 여전히 사람의 몫으로 남습니다.