AI 에이전트를 팀에 붙이고 나서 가장 먼저 느끼는 감각은 '빠르다'다. 그다음에 오는 감각은 대부분 '왜 이렇게 비싸지?'와 '이 사람, 진짜로 이해하고 코드 짠 건가?'다. 에이전트는 속도를 주지만, 그 속도가 만들어내는 비용 구조와 팀 역량 문제는 아무도 자동으로 해결해주지 않는다. 에이전트를 켜는 것과 에이전트를 운용하는 것은 전혀 다른 설계 작업이다.
오늘은 세 가지를 묶어서 다룬다. 토큰 비용을 보이게 만드는 것, 컨텍스트 윈도우 안에서 토큰이 어디로 가는지 추적하는 것, 그리고 AI 도구가 일반화된 지금 채용 기준을 어떻게 바꿔야 하는지다. 각각 독립적인 주제처럼 보이지만, 세 가지 모두 에이전트를 도입한 팀이 자동으로 해결받지 못하고 직접 설계해야 하는 구조 문제다.
첫 번째: 토큰 비용을 클라우드 청구서처럼 볼 수 있게 만들어라
클라우드 비용은 대시보드에서 실시간으로 보인다. CI 사용 시간도 파이프라인에서 추적된다. 그런데 AI 에이전트의 컨텍스트 토큰 비용은? 청구서에 숫자가 나올 때까지 거의 보이지 않는다. dev.to에 공개된 tokenscope 프로젝트가 정확히 이 문제를 짚는다. 문제는 토큰 비용이 '한 번의 큰 지출'이 아니라 '수천 토큰짜리 컨텍스트가 하루에 수백 번 재전송'되는 방식으로 쌓인다는 점이다. 콜 단위 로그는 멀쩡해 보이는데 월말 청구서는 충격적인 이유가 여기 있다.
대부분의 에이전트 프레임워크는 매 스텝마다 누적된 컨텍스트 전체를 다시 전송한다. 메모리, 히스토리, 툴 정의까지 전부. 그러니까 시스템 프롬프트가 2,000토큰 무거워지면 그건 일회성 비용이 아니라 2,000 × 호출 수 × 유저 수다. 누군가 '일단 이거 추가해두자'며 프롬프트에 few-shot 예시를 잔뜩 박아두는 순간, 그 결정은 매 요청마다 비용으로 전환된다. tokenscope 저자는 타이머에 걸린 에이전트가 하룻밤에 별다른 작업도 없이 1억 3,600만 토큰을 소비하는 걸 직접 목격했다고 밝힌다. 같은 패턴이다.
npx @wartzar-bee/tokenscope scan . 한 줄로 에이전트 프롬프트·툴·설정 파일의 토큰 풋프린트를 파일 단위로 즉시 확인할 수 있다. 토크나이저 의존성 없이 동작하고 오픈소스(Apache-2.0)다. 더 실용적인 활용은 두 가지다. 하나는 git pre-push 훅에 걸어서 토큰 한도를 넘는 프롬프트 변경이 로컬에서 아예 커밋되지 않게 막는 것, 다른 하나는 GitHub Action으로 PR마다 토큰 델타를 코멘트로 달고 한도 초과 시 머지를 블록하는 것이다. '이 PR이 얼마나 비싼가'를 코드 리뷰 단계에서 가시화하는 구조를 만드는 게 핵심이다.
팀 리드 입장에서 이 도구의 가치는 단순히 비용 절감이 아니다. 프롬프트 변경을 비용 영향이 측정되는 엔지니어링 행위로 만드는 것이다. '그냥 추가해두자'는 결정이 CI에서 수치로 반환되는 순간, 팀의 의사결정 방식 자체가 달라진다.
두 번째: 컨텍스트 윈도우 안을 프로파일러로 뜯어봐라
토큰 총량을 아는 것과 그 토큰이 어디서 왔는지 아는 것은 다르다. 청구서는 전자를 알려주고, 후자는 알려주지 않는다. ctxlens는 이 두 번째 문제를 다룬다. CPU 프로파일러가 어떤 함수가 시간을 잡아먹는지 알려주듯, ctxlens는 에이전트 세션 트랜스크립트를 분석해서 컨텍스트 윈도우 안의 토큰이 어떤 세그먼트에 얼마나 분포하는지 보여준다.
system, tool_definitions, user, assistant, thinking, tool_call, tool_result—모든 메시지를 이 버킷 중 하나로 분류하고 세그먼트별 토큰 수와 대화 턴별 증가 추이를 출력한다. Claude Code의 JSONL 세션 파일, OpenAI/Codex 롤아웃 세션, 일반 OpenAI 채팅 배열을 모두 지원한다. pip install ctxlens-cli 후 ctxlens analyze session.jsonl 한 줄이면 된다. 저자가 실제로 가장 자주 보게 되는 결과는 tool_result가 컨텍스트의 절반 가까이를 점유하는 패턴이다. 같은 파일을 여섯 번 읽거나, 단 한 턴에만 필요했던 12,000토큰짜리 툴 결과가 이후 내내 컨텍스트에 남아있거나.
ctxlens의 '낭비 보고서'는 네 가지 소스를 측정한다. 중복 토큰(같은 파일·툴 결과의 중복 전송), 툴 결과 비대화(결과 하나가 설정 한도를 초과하는 부분), 스테일 툴 출력(동일 참조를 여러 번 읽었을 때 최신 것에 덮어씌워진 이전 값들), 툴 정의 초과(매 턴마다 지불하는 스키마 토큰). 각 항목은 "Read:file_path=config.py가 6회 등장, 약 2,410토큰"처럼 구체적인 수치와 함께 출력된다. '컨텍스트를 잘 관리하세요'가 아니라, 정확히 어디를 잘라낼 수 있는지 알려주는 것이다.
CI 연동도 간단하다. ctxlens analyze session.jsonl --fail-over-ratio 0.30으로 낭비 비율이 30%를 넘으면 빌드를 실패시킬 수 있고, ctxlens diff before.jsonl after.jsonl로 프롬프트 변경 전후의 낭비 회귀를 추적할 수 있다. 절대 수치보다 비율과 추이가 중요하다는 점에서 토크나이저 없이도 충분히 실용적이고, 정확한 청구 수치가 필요하면 tiktoken을 추가 설치하면 된다.
두 도구를 함께 보면 구조가 보인다. tokenscope는 코드베이스 수준에서 '무거운 파일이 어디냐'를 잡아내고, ctxlens는 실제 런타임 세션에서 '어느 세그먼트가 낭비되고 있냐'를 잡아낸다. 전자는 배포 전, 후자는 운용 중—이 두 레이어를 모두 덮어야 토큰 비용 통제가 완성된다.
세 번째: 채용 기준을 '코드 작성 능력'에서 '코드 검증 능력'으로 바꿔라
에이전트가 팀의 코드를 생성하기 시작하면, 그 코드를 검증하고 방향을 잡는 사람이 중요해진다. 그런데 지금 채용 시장의 기술 면접은 이 변화를 얼마나 반영하고 있을까? dev.to에 올라온 RedYellow Technologies 강사의 관찰에 따르면, 기술 면접의 실질적 평가 기준은 이미 이동했다. 단지 채용 준비 가이드들이 따라가지 못하고 있을 뿐이다.
변화의 방향은 명확하다. 이전에는 '처음부터 올바른 코드를 메모리에서 꺼낼 수 있는가'였다. 지금은 AI가 생성한 코드를 건네주고 '버그를 찾아라, 설계 결정을 설명해라, 최적화 포인트를 제시해라'를 묻는 방식으로 바뀌고 있다. 일부 기업은 면접 중 AI 도구 사용 자체를 허용하되, 도구를 얼마나 잘 지시하고 결과를 검증하며 실수를 잡아내는지를 평가한다. 평가 대상이 '코드 생성 능력'에서 '코드와 함께 추론하는 능력'으로 이동한 것이다.
후보자들이 반복적으로 실패하는 패턴은 세 가지로 정리된다. 학위나 수료증을 완주 지점으로 착각하는 것, AI 도구 결과를 그대로 제출하고 설명을 못 하는 것, 그리고 코드를 작성하는 연습만 하고 코드를 읽고 디버깅하고 말로 설명하는 연습은 하지 않는 것이다. 세 번째가 특히 중요하다. AI 도구가 초기 코드 작성을 가져갈수록, 사람의 가치는 리뷰·디버깅·결정 설명으로 이동하기 때문이다.
팀 리빌딩 관점에서 이 변화는 채용 프로세스 재설계를 요구한다. 화이트보드에서 함수 작성을 요구하는 면접은 이미 현업과의 괴리가 크다. 대신 AI가 생성한 코드의 결함을 찾게 하거나, 설계 결정의 근거를 말로 설명하게 하거나, 실제 툴을 사용하는 방식을 관찰하는 형식이 현재 팀의 실제 작업 방식과 훨씬 가깝다. 이 면접 방식의 변화는 동시에 '어떤 능력을 가진 사람을 뽑아야 하는가'에 대한 답이기도 하다.
이 세 가지가 하나의 설계 문제인 이유
비용 가시화, 컨텍스트 프로파일링, 채용 기준 재정의—언뜻 별개 주제처럼 보이지만 공통된 구조 문제를 가리킨다. 에이전트는 팀에게 속도를 주지만, 그 속도가 만들어내는 비용·품질·역량 문제는 자동으로 해결되지 않는다는 것이다. 토큰 비용은 누군가 파이프라인에 게이트를 만들지 않으면 계속 보이지 않는다. 컨텍스트 낭비는 누군가 세션을 분석하지 않으면 계속 쌓인다. 채용 기준은 누군가 면접 방식을 바꾸지 않으면 현업과 계속 어긋난다.
에이전트를 켜는 건 쉽다. 에이전트가 만드는 구조적 부채를 설계로 막는 건 팀 리드의 일이다. 이 세 가지는 그 설계의 시작점이다.