요즘 팀내에서 토큰 부족 현상이 자주 발생한다.
Budget을 무한정 투입할 수 없는 상황이라 여러 고민을 하던 중, Github에 꽤 괜찮은 Repo가 있는 것을 발견했다. 팀에 내용을 공유하고 여기에 정리해본다.
Photo by camera obscura on Unsplash
AI 코딩 도구를 처음에 쓸땐 대부분 감탄한다. 코드를 읽고, 테스트를 수행하고, 수정안을 내놓는 속도가 생각보다 빠르다. 사람보다 빠르다는 말이 과장이 아닐 때도 있다.
그러나 오랫동안 붙잡고 있으면 문제가 나타난다. 대화가 길어질수록 에이전트가 점점 이상해진다. 방금 전까지 이해하던 문맥을 놓치고, 이미 확인한 내용을 다시 확인하고, 중요하지 않은 로그에 매달린다. 모델이 멍청해졌다기보다는 모델이 읽는 환경이 나빠졌다고 봐야한다.
RTK는 이런 문제를 해소하기 위해 등장했다. 공식 설명은 단순하다.
CLI 출력이 LLM의 context window에 들어가기전에 필터링하고 압축하는 CLI Proxy이다.
즉, 모델을 바꾸는 도구가 아니라, 모델에게 들어가는 입력의 형태를 바꾸는 도구다. CLI noise를 줄여 더 나은 reasoning, 더 긴 세션, 더 낮은 비용을 만들기 위함히다.
우리는 종종 더 큰 모델, 더 긴 컨텍스트, 더 좋은 에이전트를 원한다. 하지만 실제 사용에서 문제가 되는 것은 모델의 지능이 아니라 입력의 질이다. 지나치게 장황한 git diff, 쓸모없는 pass log로 가득한 cargo test, 사람이 터미널에서 볼 때는 무해하지만, 모델에게는 비용과 혼란만 남기는 출력들... RTK는 이 문제를 아래와 같이 접근한다.
모델이 읽는 터미널은 아직도 인간용으로 설계되어 있다.
공식 사이트를 보면 숫자가 매력적이다. 평균 89%의 노이즈 제거, 3배 더 긴 세션을 언급한다. 대체로 큰 폭의 출력 압축을 지향하지만 수치는 커맨드와 환경에 따라 다르다고 인지해야 한다.
RTK의 구조는 생각보다 단순하다. Github 아키텍처 문서를 보면 이 도구는,
- 특정 커맨드를 감지하고
- 원래 커맨드를 실행한 뒤
- stdout/stderr를 캡쳐하고
- 커맨드 종류에 맞는 필터를 적용하고
- 더 짧은 형태로 다시 출력한다.
즉, RTK는 커맨드별 규칙 기반 압축기이다. 단순해서 신뢰가 간다. 모델이 요약하는 구조가 아니라, 개발 도구의 출력 형식을 사람이 이해 가능한 규칙으로 재구성하는 쪽에 가깝기 때문이다.
그렇다고 RTK를 단순한 "토큰 절약기"로만 보는 것은 이 도구의 확장성 관점에서 아깝다. RTK는 LLM용 인터페이스 레이어라고 볼 수 있다.
우리가 사용하는 CLI는 원래 인간을 위한 인터페이스다. 행 단위로 길게 출력하고, 강조를 위해 반복하고, 상태를 친절하게 설명하고, 때때로 인테리어 장식도 넣는다. 그중 사람은 필요한 것만 골라서 본다.
반면 대부분 LLM의 경우는 사람처럼 골라보지 못한다. 읽을 수 있는 것은 읽고, 읽은 것은 비용이 되고, 비용은 곧 컨텍스트 오염이 된다. RTK는 이 오래된 CLI를 LLM 친화적으로 번역한다. 같은 사실을 더 짧고 구조적으로 표현하는 것이다.
이 아이디어는 생각보다 큰 의미를 가진다. AI 시대에 경쟁력이 모델 그 자체에서만 생기는 것이 아니라, 모델이 무엇을 어떤 형태로 읽게 하느냐에서 생길 수 있단느 점을 보여주기 때문이다.
물론, 모든 컨텍스트 문제의 해결사는 아니다. Shell 출력이라는 오염원 하나를 잘라내는 도구로 봐야 한다. 그러나 이것만 해도 꽤 큰 오염원 제거이다. 현실의 생산성 도구는 대체로 이렇게 부분적인 문제를 해결해나가기 때문이다.
이제까지 살펴본 바로는 이 프로젝트는 "더 똑똑한 모델"을 포커싱하는 것이 아니라, "더 적절한 입력"을 문제의 중심에 놓고 있다. 지금까지 AI 도구 시장은 주로 모델 교체를 경쟁처럼 진행되었다. GPT가 좋냐, Claude가 좋냐, Gemini가 좋냐 등... 그런데 현장에서는 종종 더 하위 레이어가 중요하다. 파일을 어떻게 읽히게 할 것인가, 테스트 결과는 어디까지 보여줄 것인가, diff를 어떤 단위로 잘라줄 것인가, 이런 문제들은 모델의 IQ보다 입구의 형식과 더 가깝다. RTK는 이 문제에 접근해서 풀어냈다.
이미 있는 모델이 쓸데없는 것을 덜 읽게 만든다.
이것은 화려하진 않지만 대단히 실용적이다.
그런데, 불편한 점도 존재한다. 압축은 trade-off다. 출력이 짧아진다는 것은 토큰 낭비를 덜한다는 점에서 좋아보이지만, 어떤 상황에서는 정보 손실이 될 수 있다. 상황에 따른 호불호가 있다고 생각된다. 그래서 RTK에서는 언제 압축하고 언제 원본으로 돌아갈지를 사용자가 통제할 수 있게 하였다.
이 프로젝트는 단순한 유틸리티로 볼 수도 있다. 하지만 AI Native 개발 환경 관점에서 보면 느낌이 다르다.
모델은 두뇌이고, RTK와 같은 도구는 감각을 정리하는 장치다.
두뇌를 키우는 일만큼, 들어오는 감각을 정제하는 일도 중요하다는 것을 이 도구가 보여주기 때문이다.
결국 RTK가 던지는 질문은 단순하다.
정말 필요한 것은 더 큰 모델일까? 아니면 더 깨끗한 입력일까?
아마도 답은 둘 다일 것이다. 그러나 현장에서는 두 번째가 더 중요하다. 더 큰 모델은 비싸고, 느리고, 언제나 접근 가능하지 않기 때문이다. 반면 입력을 정리하는 일은 상대적으로 싸고, 빠르고, 바로 적용이 가능하다. 이 작은 도구는 거대한 AI 혁신처럼 보이지는 않지만, 실제 사용 경험의 병목을 직접 건드린다.
"LLM이 읽는 모든 것을 더 많이 넣자!"는 방향이 아니라, "LLM이 읽을 가치가 없는 것을 빼자!"는 방향을 선택한다.
이 프로젝트가 의미 있다고 보는 이유는, 문제를 정확히 문제로 본다는 데 있다. AI 코딩의 병목은 모델안에만 있지 않다. 종종 모델 바깥, 터미널의 지저분한 출력과 도구 체인에 있을 수 있다.
즉, "AI가 일하는 환경을 인간 중심 인터페이스에서 기계 중심 인터페이스로 번역하려는 시도다."
나는 이런 종류의 시도가 앞으로 더 많아질 것이라고 본다. 모델이 좋아질수록, 오히려 모델 앞단의 정제 레이어가 더 중요해질 가능성이 크기 때문이다.
지금 이 모델은, 무엇을 읽고 있는가?
References:
0 Comments:
댓글 쓰기