월 1억 토큰을 쓰고 나서야 보인 AI 활용법

들어가기

AI를 쓰면 생산성이 올라간다는 말은 이제 낯설지 않다. 너무 많이 들어서 오히려 조금 납작하게 느껴질 때도 있다. 생산성이 얼마나 올라가는지보다 더 궁금한 것은 따로 있었다.

정말로 결과물을 끝까지 만들 수 있을까?

카카오톡 선물하기 이벤트로 ChatGPT Pro 월 구독권 5장을 저렴하게 구매했다. 덕분에 최근 3개월 동안 월평균 1억 토큰 이상을 써볼 수 있었다. 그 기간에 일주일에 하나씩 제품을 만들며 총 3개의 결과물을 끝까지 구현했다.

사용량을 보고 나도 조금 놀랐다. 그런데 토큰을 많이 썼다는 사실보다 더 흥미로웠던 것은, AI를 대하는 내 태도가 꽤 많이 바뀌었다는 점이다.

처음에는 AI를 잘 쓰는 일이 좋은 질문을 던지는 일에 가깝다고 생각했다. 지금은 조금 다르게 본다. AI는 검색창보다 작업 시스템에 가깝다. 컨텍스트를 읽고, 도구를 실행하고, 실패한 결과를 다시 보고, 다음 행동을 바꿀 때 비로소 제대로 힘을 낸다.

문서, 코드, 로그, 검증 루프를 거쳐 AI 결과물이 만들어지는 작업 흐름 삽화

이 글은 AI 내부 수학을 설명하는 글이 아니다. 월 1억 토큰 이상을 쓰며 내가 실제로 체감한 변화에 가깝다. 토큰, 프롬프트, 컨텍스트, RAG, 에이전트, 하네스라는 말이 실제 작업 품질과 어떻게 이어지는지 정리한다.

작성 시점은 2026년 5월 12일이다. 모델 이름, 가격, 사용 한도는 자주 바뀐다. 그래서 이 글은 특정 수치보다 계산 구조와 판단 기준을 중심으로 읽는 편이 안전하다.

처음에는 그냥 많이 시켜보면 된다고 생각했다

처음 AI를 업무에 붙일 때는 다들 비슷하게 시작하지 않을까 싶다.

모르는 것을 묻는다. 답이 나오면 복사한다. 뭔가 어긋나면 질문을 조금 바꾼다. 그래도 안 되면 다시 검색하듯 다른 말로 물어본다.

이 방식도 충분히 도움이 된다. 나도 처음에는 이렇게 썼다. 작은 코드 조각을 물어보고, 에러 메시지를 붙여 넣고, 글 초안을 만들어 달라고 했다. 그 자체로도 예전보다 빠르다.

그런데 제품 하나를 끝까지 만들려고 하면 이 방식은 금방 한계가 온다. AI가 방금 한 말을 잊지는 않더라도, 내가 진짜 중요하게 생각하는 기준을 항상 붙잡고 있지는 못한다. 테스트가 실패했는데도 그럴듯하게 설명을 이어가고, 이미 결정한 구조를 슬쩍 바꾸고, 모르는 내용을 아는 것처럼 말하기도 한다.

그때부터 질문이 바뀌었다.

어떻게 더 좋은 답을 받을까?

에서

어떻게 하면 AI가 내 작업 환경 안에서 덜 위험하게 일하게 만들까?

로 바뀌었다.

이 차이를 느끼고 나서야 토큰, 프롬프트, 컨텍스트 같은 단어가 단순한 사용법이 아니라 작업 설계의 언어로 보이기 시작했다.

토큰을 많이 쓰면 비용보다 먼저 습관이 보인다

토큰은 모델이 텍스트를 처리하는 기본 단위다. 단어와 정확히 같지 않다. 문자 하나일 수도 있고, 단어 일부일 수도 있고, 공백이나 문장부호도 토큰 수에 영향을 준다.

개발자가 토큰을 알아야 하는 이유는 명확하다.

토큰 수가 비용에 영향을 준다.
토큰 수가 응답 속도에 영향을 준다.
토큰 수가 컨텍스트 한도 초과 여부를 결정한다.

API 응답의 사용량 필드에는 보통 입력 토큰, 출력 토큰, 전체 토큰이 나온다. 최근 API는 여기에 캐시된 입력 토큰이나 reasoning 토큰처럼 더 세분화된 사용량을 함께 보여주기도 한다.

총 사용량 = 입력 토큰 + 출력 토큰 + 모델별 추가 토큰
실제 비용 = 토큰 종류별 사용량 * 모델별 단가 + 도구 사용 비용

하지만 직접 많이 써보니, 토큰은 비용 계산표이기 전에 습관을 비추는 거울에 가까웠다.

내가 자주 낭비한 토큰은 긴 답변이 아니었다. 이미 말한 배경을 다시 설명하고, 필요 없는 파일을 통째로 붙이고, 실패한 시도를 정리하지 않은 채 같은 요청을 반복하는 데 쓴 토큰이 더 아까웠다.

ChatGPT, Claude 같은 구독형 제품에서 보이는 "크레딧"이나 "사용량 한도"는 API 토큰 과금과 완전히 같지 않을 수 있다. 제품 UI에서는 메시지 수, 모델, 대화 길이, 파일, 도구 사용량, 서버 부하 같은 요소가 함께 반영될 수 있다. 정확한 비용을 보려면 해당 제품의 usage 화면이나 API usage 필드를 기준으로 확인해야 한다.

내가 얻은 기준은 단순하다.

비용을 줄이고 싶다면 답변을 짧게 만들기 전에, 반복해서 넣는 컨텍스트부터 줄여야 한다.

토큰은 글자 수가 아니라 작업량이다. 많이 쓸 수 있다는 것보다, 무엇에 쓰고 있는지 아는 것이 더 중요했다.

프롬프트보다 먼저 작업 계약이 필요했다

한동안은 프롬프트를 잘 쓰면 대부분 해결될 줄 알았다. "전문가처럼 답해줘", "단계별로 생각해줘", "친절하게 설명해줘" 같은 문장을 바꿔가며 시도했다.

효과가 없지는 않았다. 하지만 오래가지는 않았다. 작업이 조금만 길어지면 프롬프트 문장보다 더 중요한 것들이 드러난다.

항목	약한 요청	더 나은 요청
목표	"이 코드 봐줘"	"동시성 버그 가능성만 리뷰해줘"
기준	"좋게 고쳐줘"	"동작 변경 없이 중복만 줄여줘"
입력	"우리 시스템 기준으로"	"아래 ADR과 테스트 규칙을 기준으로"
출력	"설명해줘"	"위험도 순으로 5개 이하로 정리해줘"

좋은 프롬프트는 멋진 문장이 아니라 작업 계약에 가깝다. AI에게 모든 판단을 맡기는 대신, 무엇을 보고 무엇을 하지 말아야 하는지 정해준다.

이번 작업의 목표는 무엇인가.
성공과 실패를 무엇으로 판단할 것인가.
어떤 문서와 테스트를 근거로 삼을 것인가.
바꾸면 안 되는 경계는 어디인가.
모르면 추측하지 말고 어디서 멈춰야 하는가.

OpenAI와 Anthropic 문서 모두 프롬프트 개선 전에 성공 기준과 평가 방법을 먼저 세우는 접근을 강조한다. 나도 이 순서가 맞다고 느꼈다. 성공 기준이 없으면 AI가 더 그럴듯해졌는지, 실제로 더 나아졌는지 구분하기 어렵다.

컨텍스트는 많이 넣을수록 좋은 것이 아니었다

프롬프트가 지시라면 컨텍스트는 작업 기억이다. 현재 질문, 이전 대화, 시스템 지시, 파일 내용, 검색 결과, 도구 설명, 테스트 출력이 모두 컨텍스트가 된다.

처음에는 많이 보여줄수록 좋다고 생각했다. 저장소 전체를 읽히고, 긴 로그를 붙이고, 관련 있어 보이는 문서를 다 넣으면 더 똑똑하게 판단할 것 같았다.

그런데 꼭 그렇지는 않았다.

오래된 대화가 남아 있으면 현재 목표와 충돌한다.
관련 없는 파일이 많으면 중요한 신호가 묻힌다.
긴 로그를 통째로 넣으면 원인보다 표면 패턴에 끌린다.
같은 지시를 매번 바꾸면 캐시 효율도 떨어진다.

컨텍스트 엔지니어링은 결국 무엇을 보여줄지보다 무엇을 빼야 할지에 가까웠다.

나는 지금 아래 순서로 생각하려고 한다.

지금 작업의 성공 기준을 먼저 정한다.
그 기준에 직접 필요한 자료만 고른다.
안정적인 지시와 매번 바뀌는 입력을 분리한다.
긴 자료는 요약하되 원문 위치를 남긴다.
모델 답변을 테스트, 로그, 문서로 다시 확인한다.

프롬프트 캐싱도 같은 맥락에서 이해할 수 있다. 제공자별 구현은 다르지만, 공통 아이디어는 반복되는 긴 입력을 매번 새로 처리하지 않도록 재사용하는 것이다. 안정적인 지시, 도구 정의, 예시, 긴 배경 자료를 앞쪽에 두고 변하는 사용자 입력을 뒤쪽에 두는 구성이 유리하다.

정리하면, 컨텍스트는 많이 붙이는 기술이 아니다. 지금 판단에 필요한 근거만 남기는 기술이다.

RAG와 에이전트는 이름보다 운영 방식이 중요했다

AI를 쓰다 보면 멋진 이름을 자주 만난다. RAG, agent, workflow, tool use 같은 단어가 그렇다. 처음에는 이 단어들이 어떤 특별한 마법처럼 느껴졌다.

하지만 직접 써보면 조금 담백해진다.

RAG(Retrieval Augmented Generation)는 모델이 우리 문서를 학습하는 기술이 아니다. 외부 문서나 데이터에서 관련 정보를 찾아 현재 프롬프트에 넣는 방식에 가깝다.

질문 -> 관련 문서 검색 -> 검색 결과를 컨텍스트에 추가 -> 모델 응답 생성

그래서 RAG의 품질은 모델만으로 결정되지 않는다. 문서 분할 방식, 검색 쿼리, 랭킹, 중복 제거, 오래된 문서 정리, 출처 표시가 모두 영향을 준다. 검색 결과가 별로면 좋은 모델도 그럴듯한 오답을 만든다.

에이전트도 비슷했다. 핵심은 "알아서 다 한다"가 아니었다. 매 단계마다 환경에서 ground truth를 얻고, 그 결과로 다음 행동을 바꾸는 피드백 루프가 핵심이었다.

계획 -> 도구 실행 -> 결과 관찰 -> 계획 수정 -> 다시 실행 -> 검증

Anthropic은 agentic system을 workflow와 agent로 나눈다. 절차가 명확하면 workflow가 낫고, 필요한 단계 수를 미리 알기 어려우면 agent가 유리하다. 개발 업무도 마찬가지다. 브랜치 생성, 린트 실행, 릴리즈 체크리스트처럼 경로가 정해진 일은 workflow가 더 안정적이다. 반대로 원인 모를 테스트 실패를 조사하거나, 큰 코드베이스에서 수정 범위를 탐색하는 일은 agent 방식이 잘 맞는다.

여기서 중요한 것은 이름이 아니다. AI가 어떤 근거를 보고, 어떤 도구를 쓰고, 실패했을 때 어디까지 다시 시도할지 정하는 운영 방식이다.

하네스를 만들고 나서야 일이 끝나기 시작했다

하네스 엔지니어링은 OpenAI의 Codex 활용 글에서 접한 표현이다. 나는 이 말을 AI가 일할 작업장을 만드는 일로 이해했다.

코딩 에이전트를 예로 들면 하네스는 아래 요소를 포함한다.

저장소 구조와 작업 디렉터리
읽을 수 있는 문서와 규칙
실행 가능한 테스트 명령
사용할 수 있는 도구와 권한
멈춰야 하는 조건
결과 보고 형식
실패 로그와 재시도 방식

프롬프트가 작업 지시서라면, 하네스는 작업장이다. 지시서가 좋아도 작업장이 불안정하면 결과가 흔들린다. 테스트가 느리거나, 의존성이 깨져 있거나, 문서가 오래됐거나, 권한 경계가 불명확하면 모델은 그 틈에서 불필요한 추측을 한다.

이 관점에서 AGENTS.md, ADR, 테스트 스크립트, CI, 린트 규칙은 모두 AI 활용 품질에 영향을 준다. AI를 잘 쓰는 팀은 프롬프트만 잘 쓰는 팀이 아니라 AI가 읽고 실행하고 검증할 수 있는 환경을 잘 정리한 팀이다.

이걸 체감한 뒤로는 AI에게 일을 맡길 때 먼저 작업장을 확인하게 됐다.

이 저장소에서 따라야 할 규칙이 문서화되어 있는가.
바꿔도 되는 파일과 바꾸면 안 되는 파일이 분명한가.
검증 명령이 한 번에 실행되는가.
실패했을 때 원인을 좁힐 로그가 남는가.
사람이 마지막에 볼 수 있는 diff와 요약이 남는가.

하네스는 AI에게 일을 더 많이 맡기는 기술이 아니다. 맡긴 일을 검증 가능한 형태로 제한하는 기술이다.

그래서 지금은 이렇게 맡긴다

3개월 동안 AI를 많이 쓰면서 가장 크게 바뀐 것은 요청 방식이다. 예전에는 "이거 해줘"에 가까웠다면, 지금은 작은 작업 주문서처럼 쓴다.

요청 전에 먼저 적는 것은 대략 이렇다.

목표: 무엇을 끝내야 하는가
맥락: 어떤 문서와 코드를 기준으로 삼아야 하는가
경계: 무엇은 바꾸면 안 되는가
검증: 어떤 명령이나 근거로 맞았다고 볼 것인가
보고: 결과를 어떤 형태로 받을 것인가

이 다섯 가지를 적으면 프롬프트가 길어지긴 한다. 하지만 전체 토큰은 오히려 줄어드는 경우가 많았다. 중간에 방향을 잃고 되묻는 일이 줄고, 엉뚱한 파일을 고치는 일이 줄고, 검증 결과를 기준으로 다음 행동을 정하기 쉬워졌기 때문이다.

AI를 쓸 때마다 거창한 시스템을 만들 필요는 없다. 다만 최소한 아래 세 가지는 먼저 정해두는 편이 좋았다.

1. 성공 기준은 관찰 가능해야 한다

"좋은 답변"은 기준이 아니다. 테스트가 통과한다, 공식 문서 링크가 붙어 있다, 기존 API 동작을 바꾸지 않는다처럼 실행 결과로 확인할 수 있어야 한다.

2. 모델이 볼 정보와 보지 말아야 할 정보를 나눈다

필요한 정보를 숨기면 모델은 추측한다. 반대로 모든 것을 보여주면 중요한 신호가 묻힌다. 지금 판단에 필요한 문서, 코드, 로그만 고르는 일이 중요하다.

3. 결과를 검증 가능한 형태로 회수한다

AI가 낸 결과는 최종 결과물이 아니라 검증 대상이다. 코드는 테스트와 타입 검사, 문서는 공식 문서와 원문 링크, 설계는 대안 비교와 실패 조건으로 다시 확인해야 한다.

이 세 가지를 지키면 AI는 더 이상 신기한 대화 상대에만 머물지 않는다. 꽤 쓸만한 작업 파트너가 된다.

개발자의 일은 사라지기보다 이동한다

AI가 코드를 만들고 문서를 정리하고 테스트까지 제안할 수 있다면 개발자의 일이 사라질 것처럼 보일 수 있다. 하지만 실제로 결과물을 만들어보면 반대에 가깝다. 생산 속도가 빨라질수록 검증해야 할 결과물도 함께 늘어난다.

AI가 만든 결과물에는 책임 주체가 없다. 코드가 장애를 만들거나, 문서가 잘못된 사실을 전파하거나, 설계가 장기 변경 비용을 키웠을 때 "AI가 그렇게 했다"는 말은 책임을 대신하지 못한다. 최종적으로 승인하고 배포하고 설명해야 하는 주체는 사람과 조직이다.

그래서 개발자의 역할은 사라진다기보다 이동한다. 직접 타이핑하는 비중은 줄어도 문제를 정의하고, 맥락을 제공하고, 결과를 읽고, 구조적 결함을 발견하고, 장기 변경 비용을 판단하는 일은 더 중요해진다.

이 지점에서 필요한 역량은 도구 사용법만이 아니다.

요구사항의 본질을 좁히는 능력
모델이 놓친 전제를 발견하는 능력
작동하는 코드와 유지 가능한 코드를 구분하는 능력
할루시네이션을 공식 문서와 실행 결과로 검증하는 능력
"뭔가 이상하다"는 감각을 구체적인 언어로 바꾸는 능력

AI는 보일러플레이트, 반복 구현, 초안 작성 같은 우발적 비용을 크게 줄인다. 하지만 비즈니스 요구사항의 모호함, 설계 목표 사이의 충돌, 미래 변경 방향에 대한 불확실성 같은 본질적 복잡성은 그대로 남는다. 오히려 AI가 결과물을 더 빨리 만들수록 그 본질을 읽고 판단하는 개발자의 역량은 더 선명하게 드러난다.

마무리

월 1억 토큰을 썼다고 AI를 완전히 이해하게 된 것은 아니다. 오히려 반대에 가깝다. 많이 써볼수록 AI를 더 조심해서 써야 한다는 생각이 강해졌다.

다만 한 가지는 분명해졌다. AI는 검색 봇보다 작업 시스템에 가깝다. 좋은 프롬프트 하나보다 좋은 작업 환경과 검증 기준이 더 오래간다.

결과물을 만드는 단계는 이미 가능해졌다. 이제 차이는 더 많이 생성하는 데서만 나지 않는다. 무엇을 만들지, 왜 그렇게 만들지, 어떤 근거로 맞다고 판단할지, 그리고 나중에 어떤 비용으로 돌아올지를 설명할 수 있는지에서 난다.

처음에는 AI에게 일을 맡기는 법을 배우는 줄 알았다. 지금은 조금 다르게 생각한다. AI를 잘 쓰는 일은 결국 내가 어떤 개발자인지 더 선명하게 드러내는 일에 가깝다.

더 확인할 자료

이 글의 팩트체크에 사용한 OpenAI 자료

토큰과 비용 구조: What are tokens and how to count them?
프롬프트와 평가 기준: Prompt engineering; Working with evals
프롬프트 캐싱: Prompt caching
API 사용량 필드: Responses API reference
Retrieval/RAG 관점: Retrieval
Codex와 하네스 엔지니어링: 하네스 엔지니어링

같이 읽어볼 자료

프롬프트 패턴을 넓게 훑을 때: Prompt Engineering Guide 한국어판
agent와 context engineering 관점을 비교할 때: Anthropic: Building effective agents; Anthropic: Effective context engineering for AI agents
AI 시대 개발자 역할을 고민할 때: Evan Moon: AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다