🤖
1239 in / 3891 out / 5130 total tokens
오늘 건들은 둘 다 Simon Willison의 블로그에서 나왔다. 한 명의 개발자가 같은 날 올린 글 두 건인데, 묘하게도 "데이터를 다루는 사람의 삶을 조금 더 나아지게 만드는 도구"라는 공통점이 있다. 하나는 LLM 비용 추정의 정확도를 높이고, 다른 하나는 스프레드시트와 데이터베이스 사이의 워크플로우를 매끄럽게 한다. 따로 보면 마이너한 업데이트 같아도, 실무자 관점에서는 꽤 신경 쓰이는 영역이다.
🔥 핫 토픽
Claude Token Counter, 모델 간 비교 기능 추가됨
Simon Willison이 만든 Claude Token Counter에 모델 비교 기능이 추가됐다. 기존에는 단일 모델 기준으로 토큰 수만 세줬는데, 이제 여러 Claude 모델(Haiku, Sonnet, Opus 등)의 토큰 카운트를 나란히 비교할 수 있다.
이게 왜 중요하냐면, 토큰 수는 곧 비용이고 비용은 프로젝트 생사를 가르기 때문이다. 게임 서버 아키텍처에서 메모리 최적화가 선택이 아니듯, LLM 기반 서비스에서 토큰 최적화도 선택이 아니다. 특히 여러 모델을 혼용하는 실무 환경에서는 "이 프롬프트를 Haiku에 보낼까, Sonnet에 보낼까" 같은 결정이 매일 발생한다. 그때마다 토큰 수가 모델마다 어떻게 다른지 직관적으로 비교할 수 있다는 건 꽤 큰 무기다.
왜 모델마다 토큰 수가 다르냐면, 토크나이저(tokenizer)가 다르기 때문이다. 토크나이저는 텍스트를 모델이 이해할 수 있는 단위(토큰)로 쪼개는 역할을 한다. 같은 "Hello, world!"라도 Claude의 토크나이저와 GPT의 토크나이저가 쪼개는 방식이 다르다. 심지어 Claude 모델 패밀리 내에서도 버전에 따라 미세한 차이가 있을 수 있다. 한국어 같은 비영어권 언어는 이 차이가 더 벌어진다. 영어는 대략 1토큰당 4글자 수준이지만, 한국어는 1토큰당 12글자밖에 안 되는 경우가 많다. 그럼 당연히 한국어 프롬프트는 영어 프롬프트보다 토큰 단가가 24배 더 나온다. 이걸 모델별로 비교해볼 수 있다는 건, 비영어권 개발자에게 특히 유용하다.
게임 개발자 시각으로 보면, 이건 프로파일링 도구와 비슷하다. Unreal Engine에서 Stat 명령어로 CPU/GPU 병목을 찾아내듯, Token Counter로 프롬프트의 비용 병목을 찾아내는 셈이다. "이 시스템 프롬프트가 전체 토큰의 70%를 잡아먹네?" 같은 인사이트를 얻을 수 있고, 그러면 자연스럽게 프롬프트 압축이나 청킹 전략을 고민하게 된다. AI 사이드프로젝트를 하는 입장에서는 이런 도구가 없으면 API 비용 폭탄을 맞고 나서야 깨닫게 된다. 사전에 비용을 추정할 수 있다는 것 자체가 큰 이득이다.
한 가지 아쉬운 점은 Claude 모델 간 비교만 된다는 거다. Claude vs GPT-4o vs Gemini 같은 크로스 벤더 비교까지 되면 완벽하겠지만, 아직은 Anthropic 생태계 내에서만 지원한다. 그래도 유의미한 출발점이다.
출처: Claude Token Counter, now with model comparisons - Simon Willison
Google Sheets에서 Datasette로 SQL 직접 날리기
Simon Willison이 또 하나 만들었다. Google Sheets의 커스텀 함수를 통해 Datasette 인스턴스에 SQL 쿼리를 날려서 결과를 시트에 바로 가져오는 기능이다. 쉽게 말해 스프레드시트 셀에 =SQL("SELECT * FROM items WHERE rarity = 'legendary'") 같은 걸 적으면, Datasette DB에서 데이터를 당겨온다.
이게 왜 중요하냐면, 게임 개발에서 스프레드시트는 거의 종교적 도구이기 때문이다. 아이템 스탯, 밸런싱 수치, 퀘스트 보상, 상점 구성 같은 데이터를 기획자들은 무조건 엑셀이나 구글 시트로 관리한다. 그런데 이 데이터가 DB에 들어가는 순간, 시트와 DB 사이에 동기화 문제가 발생한다. 누가 시트에서 수치를 바꿨는데 DB에 반영이 안 됐다거나, 반대로 DB에서 직접 수정했는데 시트는 옛날 버전이라거나. 이 간극을 메우는 건 의외로 고통스럽다.
Datasette는 SQLite 기반의 데이터 탐색 도구다. Simon Willison이 만들었고, 읽기 전용 DB를 웹에서 SQL로 조회할 수 있게 해준다. 여기에 Google Apps Script의 커스텀 함수를 연결한 게 이번 업데이트의 핵심이다. 기술적으로 복잡한 건 아니다. Google Sheets의 CUSTOM_FUNCTION으로 Datasette API에 HTTP 요청을 보내서 JSON 응답을 파싱하는 구조다. 하지만 이 단순함이 오히려 장점이다. 복잡한 ETL 파이프라인이나 중간 레이어 없이, 시트에서 직접 DB를 쿼리한다.
앞서 언급한 Claude Token Counter와 맞물려 생각해보면 재밌다. Token Counter가 "LLM 입력/출력의 비용을 추정"하는 도구라면, 이건 "데이터 파이프라인의 마찰을 줄이는" 도구다. 둘 다 개발자가 덜 고생하게 만드는 방향이다. AI 프로젝트든 게임 개발이든, 결국 데이터 흐름을 매끄럽게 관리하는 게 핵심이니까.
실무에서 활용하려면 몇 가지 고려사항이 있다. Datasette가 읽기 전용이니까 데이터 수정은 불가능하다. 조회만 된다. 그리고 구글 시트의 커스텀 함수는 실행 시간 제한(보통 30초)이 있으니, 대량 쿼리는 타임아웃 날 수 있다. 하지만 게임 밸런싱 시트에서 특정 조건의 아이템을 필터링해서 참조한다거나, 라이브 서비스 지표를 시트에서 바로 당겨본다거나 하는 용도에는 충분하다.
출처: SQL functions in Google Sheets to fetch data from Datasette - Simon Willison
💭 두 건을 관통하는 관점
Simon Willison이 계속 파고드는 영역이 있다. 바로 "전문가적 도구를 더 접근 가능하게 만드는" 일이다. Token Counter는 토큰 비용 추정을 클릭 몇 번으로 하게 만들었고, Datasette-Sheets 연동은 SQL 쿼리를 스프레드시트 셀 안에 넣었다. 둘 다 기술적으론 크게 새로울 게 없다. 토큰 카운팅이야 API 호출이면 되고, 시트-DB 연동도 HTTP 요청 하나면 된다. 하지만 이걸 실제로 만들어서 공개하는 거랑, "그냥 스크립트 짜면 되겠네"하고 넘기는 건 완전히 다른 차원의 일이다.
UE5 C++ 개발자 입장에서 비유하자면, 언리얼의 블루프린트와 비슷하다. C++로 짤 수 있는 걸 블루프린트로 시각화해서 더 많은 사람이 쓸 수 있게 만든 것. Simon Willison은 데이터/AI 영역에서 비슷한 짓을 하고 있다. 복잡한 건 감추고, 인터페이스만 깔끔하게 드러내는 접근 방식. 이런 도구의 가치는 실제로 써봐야 안다. 글로 읽으면 "어, 그렇구나" 하고 넘어가는데, 막상 프롬프트 비용 비교를 클릭 한 번에 할 수 있거나 시트에서 SQL 결과가 팝 하고 뜨는 걸 경험하면 돌아갈 수 없다.
도구는 기술적 깊이를 대체하는 게 아니라, 진입 장벽을 낮추는 역할을 한다. 그리고 진입 장벽이 낮아질수록 더 많은 사람이 문제 자체에 집중할 수 있게 된다.