Token Optimization - Getting More from Less

토큰 최적화 – 적은 노력으로 더 큰 효과 얻기

어제는 정밀한 도구 선택으로 맞춤형 에이전트를 구축하는 방법을 소개했습니다. 오늘은 더 깊이 들어가 보겠습니다:토큰 최적화.

적합한 도구를 선택하는 것은 성공의 절반에 불과합니다. 진정한 게임 체인저는 해당 도구가반환하는 결과를 최적화하는 것입니다. 우리는 데이터 파이프라인을 재설계하여 출력토큰을 40~80% 절감하면서도최대 정확도를 달성했습니다.

구현 과정은 다음과 같습니다.

문제점: 데이터 부풀림

scrape_as_markdown이나search_engine 같은 도구를 호출하면 API는 풍부한 데이터를 반환합니다. 하지만 문제는 대부분의 데이터가인간을 위해 포맷된 것이지,LLM을 위한 것이 아니라는 점입니다.

기존 API에는 불필요한 오버헤드가 포함됩니다:

LLM이 필요로 하지 않는 중복 서식(굵게, 기울임, 제목)
자연 검색 결과에 섞인 광고 및 스폰서 콘텐츠
토큰을 낭비하는 이미지 메타데이터 및 시각적 요소
일관성 없는 필드 명명 및 중복 메타데이터

일반적인 웹 페이지 스크래핑이나 검색 쿼리의 경우, LLM이 추론에 실제로 필요한 데이터보다3~5배 더 많은 데이터를얻는 경우가 많습니다.

해결책: 2단계 토큰 최적화

다양한 유형의 데이터를 대상으로 하는계층적 최적화 전략을구현했습니다:

웹 페이지 콘텐츠용리마크 + 스트립 마크다운(scrape_as_markdown)
검색 엔진 결과용파싱 라이트 + 페이로드 클리닝(search_engine)

각 계층을 자세히 살펴보겠습니다.

잠깐만요, TOON은 왜 안 쓰나요?

TOON(Token-Oriented Object Notation)은 어떨까 궁금하실 수 있습니다. 우리는 LinkedIn 프로필이나 Amazon 상품과 같은 구조화된 데이터셋을 위한 세 번째 최적화 계층으로 TOON을 처음 검토했습니다.

TOON은 들여쓰기와 표 형식 레이아웃을 활용해 토큰을 줄이는 영리한 형식입니다. 이론상으로는 동일한 객체로 구성된 균일한 배열에서 30~60%의 절감 효과를 제공합니다. 그러나 Bright Data의 실제 API 응답에 테스트했을 때 중요한 사실을 발견했습니다:

구분자가 병목이 아니라 데이터 자체가 문제라는 점입니다.

구분자 환상

전형적인 LinkedIn 프로필 응답을 살펴보면, 대부분의 토큰은 다음에서 비롯됩니다:

긴 텍스트 필드(소개,추천서,activity[].title)
긴 URL (avatar,banner_image,activity[].link,credential_url)

구분자(n,|,t)는 전체 토큰 수에서극히 일부에불과합니다.

줄바꿈 (n)은 이미:

모든 주요 LLM 토큰화 도구에서단일하고 매우 흔한 토큰입니다
모델이 텍스트를 분할하는 방식(줄 단위)과 자연스럽게 일치함
URL 내부나 대부분의 텍스트에 나타나지 않아 이스케이프 문제를 피함

|,^,x1F같은 특수 구분자는 일부 위치에서 인용 부호 사용을 줄일 수 있지만, 종종드문 다중 토큰 시퀀스를발생시켜 이점을 상쇄합니다.

간단한 답변: 구분자만 조정한다면,n은이미 이런 종류의 데이터에 대해 가능한 최상의 선택입니다.

TOON의 한계점

TOON은동일한 객체로 구성된 균일한 배열(예: 동일한 스키마를 가진 1,000개의 직원 기록)에 탁월합니다. 그러나web_data_linkedin_person_profile이나web_data_amazon_product같은 도구에서 가져온 실제 웹 데이터는 다음과 같습니다:

이질적— 서로 다른 스키마를 가진 중첩 객체(경력,학력,활동배열)
비균일성— 혼합된 배열 유형(일부 항목은img를 포함하고 다른 항목은 포함하지 않음)
단일 객체 응답— 대부분의 API 호출은 1,000개가 아닌 1개의 프로필 또는 1개의 제품을 반환

깊게 중첩되거나 비일관적인 구조의 경우,축소된 JSON은 TOON보다 토큰 수가 적은 경우가 많습니다. TOON 사양 자체도 이를 인정합니다—깊게 중첩된 단일 객체의 경우 TOON이 오히려 컴팩트 JSON보다더 많은토큰을 사용할 수 있습니다.

진정한 해결책: 형식이 아닌 전송 데이터 자체를 변경하라

중요한 통찰은 이것입니다:형식 수준 최적화(JSON vs TOON vs YAML)는 단순히 전송하는 데이터 자체를 변경하는 것보다 훨씬 미미합니다.

우리는 모든 것을 다 하지는 않습니다—우리 도구는 Bright Data API의 전체 데이터를 반환합니다. 하지만 웹 스크래핑 응답에 자주 나타나 정보를 추가하지 않으면서 토큰을 낭비하는null값은제거합니다.

요점은:구분자 조정은 기껏해야 5~10% 정도만 절약합니다. 콘텐츠 필터링은 20~80%를 절약합니다.TOON은 실제 웹 데이터에 대해 잘못된 변수를 최적화합니다.

도구의 미성숙

TOON은 또한완전히 새로운사양입니다—첫 커밋이 2024년 11월 2일에 이루어졌습니다. 말 그대로 한 달밖에 안 된 사양입니다. JSON은 모든 언어에 유효성 검사기, 편집기, 라이브러리가 존재합니다. TOON은 맞춤형 파싱이 필요하며 생태계 지원이 부족합니다.

한 엔지니어의 표현이 적절합니다:“TOON을 처음 봤을 때, 마치 누군가의 미완성 메모장 같았습니다. 백엔드 엔지니어에게 보여주면, 마치 새로운 문제를 안겨준 것처럼 찡그릴 가능성이 있습니다.”

우리의 결정

실제 Bright Data 페이로드(LinkedIn 프로필, Amazon 제품, Google SERP)로 TOON을 벤치마킹한 결과 다음과 같이 결론 내렸습니다:

검색 결과의 경우: Bright Data의Parsed Light형식(아래 Layer 2 참조)은 API 수준에서 필터링하여 토큰을 80% 줄입니다. 별도의 맞춤 인코딩이 필요하지 않습니다.
웹 스크래핑의 경우: 스트립 마크다운(Strip-markdown)은 응답을 사람이 읽을 수 있는 상태로 유지하면서 토큰을 40% 줄입니다. 새로운 형식이 필요하지 않습니다.
구조화된 데이터셋의 경우: 진정한 이점은 JSON을 TOON으로 대체하는 것이 아니라필드 생략및텍스트 잘라내기에 있습니다.

TOON은 적절한 사용 사례(대규모 균일 데이터셋)에 탁월한 아이디어입니다. 그러나 이질적인 웹 API 응답의 경우, 표준 최적화가 특수 형식보다 항상 우월합니다.

레이어 1: 웹 스크래핑을 위한 Remark + Strip-Markdown

과제: 마크다운 부풀림

당사의 scrape_as_markdown 도구는 모든 웹 페이지를 깔끔하고 LLM 친화적인 마크다운으로 변환합니다. 그러나 원시 마크다운 변환기는 종종 다음을 포함합니다:

LLM이 추론에 필요하지 않은 중복 서식(굵게, 기울임, 제목)
이미지 대체 텍스트 및 메타데이터
빈 줄 및 간격 불일치

일반적인 블로그 게시물이나 제품 페이지의 경우, 원시 마크다운은 핵심 콘텐츠보다3~5배 더 길수 있습니다.

해결책: Strip-Markdown

우리는remark+strip-markdown을활용해 구조를 유지하면서 마크다운을 평문으로 지능적으로 축소합니다:

우수한 마크다운 처리 라이브러리를 제공해 준remark프로젝트에 감사드립니다. 그들의 작업을 지원해 주세요!

import {remark} from 'remark';
import strip from 'strip-markdown';

// scrape_as_markdown 도구 내부
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

어떤 내용이 제거되나요?

strip-markdown플러그인은 다음을 제거합니다:

굵게/이탤릭—**Important**→Important
이미지 구문—![alt text](image.png)→alt text(필요한 경우) 또는 빈 문자열
제목—### Section Title→Section Title(텍스트 유지, 마크업 제거)
코드 블록— 백틱과 서식을 줄이면서 내용을 유지

결과는?의미론적 의미를 유지하되모든 서식 오버헤드를 제거한일반 텍스트입니다.

예시: 변경 전과 변경 후

원본 마크다운 (Web Unlocker 출처):

# 제품 리뷰

## 고객 피드백

- **John D.** - ⭐⭐⭐⭐⭐
  *"훌륭한 제품! 강력 추천합니다."*
  [더 보기](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *"가격 대비 만족스러운 제품입니다."*
  [더 보기](https://example.com/review/456)

![제품 이미지](https://cdn.example.com/product.jpg)

[지금 구매하기](https://example.com/buy)

remark().use(strip).process() 후:

제품 리뷰

고객 피드백

존 D. - ⭐⭐⭐⭐⭐
"훌륭한 제품입니다! 강력 추천합니다."
더 보기

사라 M. - ⭐⭐⭐⭐
"가격 대비 훌륭한 제품입니다."
더 보기

제품 이미지

지금 구매하기

토큰 감소:전체 페이지 기준약 40%.

LLM은 여전히 모든 리뷰 텍스트, 평점, 행동 유도 문구를 가져오지만 링크 URL, 이미지 경로 또는 마크다운 서식 구문은 제외됩니다.

스트립 마크다운 사용 시점

이 최적화는 다음과 같은 경우에 적합합니다:

요약 작업— “이 블로그 글을 요약하세요”
감정 분석— “고객들은 이 제품에 대해 어떻게 생각하나요?”
엔티티 추출— “이 페이지에서 회사명과 연락처 정보를 추출하세요”

에이전트가링크를 클릭하거나페이지를 탐색해야 하는 경우, 대신 스크래핑 브라우저 도구(scraping_browser_navigate,scraping_browser_snapshot)를 사용하세요.

레이어 2: 파스드 라이트 – AI 에이전트를 위해 설계됨

문제점: 기존 SERP API는 대규모 언어 모델(LLM)을 위해 설계되지 않았습니다

기존 검색 엔진 결과 페이지(SERP) API는 웹 인터페이스를 탐색하는 인간을 위해 설계되었습니다. 이들은 모든 것을 반환합니다:

에이전트에게 불필요한 광고 및 스폰서 콘텐츠
응답을 불필요하게 부풀리는 지식 패널 및 피처드 스니펫
여러 명명 규칙에 걸친 중복 메타데이터 필드
토큰을 낭비하는 시각적 요소(썸네일, 파비콘)
관련 검색어, 자동 완성 제안, “사람들이 또한 묻는 질문” 섹션

결과는? 단일 검색으로 10개 결과를 얻으려면2,000~3,000 토큰의JSON이 반환되지만, LLM 에이전트가 실제로 필요한 것은링크 + 제목 + 설명뿐입니다.

다단계 연구 워크플로를 실행하는 AI 에이전트에게는 치명적입니다. 추가 토큰은 컨텍스트 윈도우 전체에 누적되어, 제한에 도달하기 전에 실행할 수 있는 쿼리 수를 제한합니다.

해결책: Bright Data의 Parsed Light 형식

속도와 효율성이 필요한 AI 에이전트를 위해 특별히 설계된파싱된 라이트API 응답 형식을 도입했습니다.

차별화된 특징은 다음과 같습니다:

상위 10개 자연 검색 결과만 제공— 광고, 지식 패널, 사이드바 잡다한 정보 없음
일관된 필드 구조— 모든 결과에링크,제목,설명, 선택적global_rank 포함
설계상 깔끔함— API 수준에서 사전 최적화되어 복잡한 후처리 불필요
더 빠른 응답 시간— 더 작은 페이로드 = 더 빠른 네트워크 전송 및 파싱

일관성 없는 필드명과 불필요한 응답과 씨름할 필요 없이, Parsed Light는 AI 에이전트가 필요로 하는 것을 정확히 제공합니다:최소한의 토큰으로 실행 가능한 검색 결과.

Parsed Light 활용 사례

검색 엔진으로 Google을 지정하여search_engine도구를 호출하면, 자동으로 Bright Data의parsed_light형식을 요청합니다:

// search_engine 도구 내부 (Google용)
const response = await axios({
    url: 'https://api.brightdata.com/request',
    method: 'POST',
    data: {
        url: search_url('google', query, cursor),
        zone: ctx.unlocker_zone,
        format: 'raw',
        data_format: 'parsed_light',  // ← 핵심 매개변수
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

결과: 깔끔하고 예측 가능한 JSON

다음은 검색 쿼리에 대한 실제 Parsed Light 응답 예시입니다:

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "Best Pizza in NYC - Joe's Pizza",
      "description": "Family-owned pizzeria serving authentic New York slices since 1975...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "뉴욕 최고의 피자 가게 10선",
      "description": "5개 자치구 전체에서 최고 평점을 받은 피자 레스토랑을 발견하세요...",
      "global_rank": 2,
      "extensions": [
        {
          "type": "site_link",
          "link": "https://example.com/pizza-guide/brooklyn",
          "text": "브루클린"
        }
      ]
    }
    // ... 8개 더 결과
  ]
}

다음과 같은 요소가없다는점에 유의하세요:

광고나 스폰서 목록 없음
지식 그래프 패널 없음
“사람들이 또한 묻는 질문” 섹션 없음
중복 메타데이터 필드 없음
유니코드 제어 문자나 서식 잡음 없음

LLM이 처리할 수 있도록정렬된 깨끗한 검색 결과 10개만 제공합니다.

추가 정리: 최종 마무리

Parsed Light가 주요 작업을 수행하더라도 완벽한 일관성을 보장하기 위해 가벼운 후처리 단계를 적용합니다:

function clean_google_search_payload(raw_data){
    const data = raw_data && typeof raw_data=='object' ? raw_data : {};
    const organic = Array.isArray(data.organic) ? data.organic : [];
    const pagination = data.pagination && typeof data.pagination=='object'
        ? data.pagination : {};

    // 링크, 제목, 설명만 정규화
    const organic_clean = organic
        .map(entry=>{
            if (!entry || typeof entry!='object')
                return null;
            const link = typeof entry.link=='string' ? entry.link.trim() : '';
            const title = typeof entry.title=='string'
                ? entry.title.trim() : '';
            const description = typeof entry.description=='string'
                ? entry.description.trim() : '';
            if (!link || !title)
                return null;  // 무효 항목 건너뛰기
            return {link, title, description};
        })
        .filter(Boolean);

    const parsed_page = Number(pagination.current_page);
    const current_page = Number.isFinite(parsed_page) && parsed_page>0
        ? parsed_page : 1;

    return {organic: organic_clean, current_page};
}

이 최종 정리:

데이터 유형 검증—링크,제목,설명이문자열인지 확인
공백 제거— 선행/후행 공백을 제거합니다
잘못된 항목 필터링— 필수 필드가 누락된 결과 건너뜀
페이지 매김 정규화—current_page를일관된 숫자 형식으로 변환
선택적 필드 제거— 응답을 극도로 간결하게 유지하기 위해global_rank및extensions제거

결과는 LLM이 예외 사례 없이 파싱할 수 있는완벽한 JSON입니다.

예시: 기존 방식 vs. Parsed Light

기존 SERP API (Parsed Light 적용 전):

{
  "ads": [...],
  "organic": [
    {
      "link": "https://example.com/product",
      "url": "https://example.com/product",
      "cache": {"url": "https://webcache.google.com/..."},
      "title": "Amazingu2003Productu2003u2003Review",
      "heading": "Amazing Product Review",
      "name": "Product Review",
      "description": "This   is   a   great   product...",
      "snippet": "이것은 훌륭한 제품입니다...",
      "snippet_long": "이것은 다양한 기능을 갖춘 훌륭한 제품입니다...",
      "subtitle": "제품 특징",
      "rating": 4.5,
      "price": "$49.99",
      "image": "https://cdn.example.com/image.jpg",
      "favicon": "https://example.com/favicon.ico"
    }
    // ... 광고, 지식 패널 등 30개 이상의 추가 결과
  ],
  "knowledge_graph": {...},
  "people_also_ask": [...],
  "related_searches": [...],
  "pagination": {...}
}

일반적인 응답의 경우 약 2,500 토큰.

파싱된 라이트 버전 (AI 에이전트 최적화):

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "놀라운 제품 리뷰",
      "description": "이 제품은 정말 훌륭합니다...",
      "global_rank": 1
    }
    // ... 9개 추가 결과 (상위 10개만 표시)
  ]
}

동일한 쿼리에 대해~600 토큰.

clean_google_search_payload() 적용 후:

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Amazing Product Review",
      "description": "This is a great product..."
    }
  ],
  "current_page": 1
}

~500 토큰— 기존 SERP API 대비80% 감소.

Parsed Light가 기존 파서보다 우수한 이유

대부분의 SERP API는 전체 페이지를 파싱한 후 사용자가 정리를 맡깁니다. 파스드 라이트는 다릅니다:

출처에서 사전 필터링— 광고나 사이드바 없이 오직 유기적 결과만 추출
표준화된 스키마— 모든 쿼리에서 일관된 필드명 (snippetvs.descriptionvs.snippet_long 같은 혼란 없음)
LLM 중심 설계— 토큰 효율성을 최우선으로 고려하여 설계되었으며, 사후 보완이 아닙니다
1초 미만의 응답 시간— 미션 크리티컬 AI 애플리케이션을 위해 특별히 설계된 Bright Data의 프리미엄 라우팅 인프라를 통해 제공

이는 단순히 토큰 절약이 아닌,AI 에이전트를 위한 SERP 데이터의 작동 방식을 재고하는 것입니다.

실시간 AI 에이전트를 위해 설계됨

Bright Data의 Parsed Light는 최적화 그 이상입니다. 속도를 위해 설계되었습니다. 1초 미만의 응답 시간으로 다음에 이상적입니다:

실시간 데이터 강화— 사용자 대화 중 실시간 조회 수행 에이전트
다단계 연구 워크플로우— 지연 병목 현상 없이 여러 쿼리를 연쇄적으로 실행
사실 검증— 주장 및 진술의 즉각적 확인
사용자 대상 애플리케이션— 즉각적인 검색 기능 구현

기존 SERP API는 쿼리당 3~5초가 소요됩니다. 대규모 환경에서는 이러한 지연 시간이 누적됩니다. Parsed Light는1초 미만의 응답 시간으로 결과를 제공하여 상담원의 신속한 대응과 사용자 참여도를 유지합니다.

결합된 영향: 실제 워크플로

현실적인 에이전트 워크플로우를 통해 토큰 사용을 추적해 보겠습니다:

작업:“AI 규제 관련 기사를 찾은 후 각 출처의 핵심 내용을 요약하세요.”

1단계: 기사 검색

에이전트 호출:search_engine({query: "AI regulations 2024"})

최적화 없음 (기존 SERP API):~2,500 토큰 (10개 결과 + 광고 + 지식 패널)
Parsed Light + 정리 적용:~500 토큰
절감 효과:80%(2,000 토큰 절감)

2단계: 기사 페이지 스크래핑

에이전트 호출:scrape_as_markdown({url: "https://example.com/article"})× 5개 기사

최적화 전: ~15,000 토큰 (5페이지 × 페이지당 3,000 토큰)
remark().use(strip) 적용: ~9,000 토큰
절감 효과: 40% (6,000 토큰 절감)

3단계: 추가 연구

에이전트 호출:후속 연구를 위한search_engine({query: "EU AI Act details"})

최적화 전: ~2,500 토큰
Parsed Light + 정리 적용: ~500 토큰
절감 효과: 80% (2,000 토큰 절감)

전체 워크플로 절감 효과

최적화 전: 20,000 토큰
최적화 적용: 10,000 토큰
전체 감소율: 50% (10,000 토큰 절감)

입력 토큰 100만 개당 3달러(Claude Sonnet 가격 정책) 기준으로, 워크플로우당 0.030달러를 절약합니다. 하루에 1,000회 실행하면 하루 30달러, 연간 10,950달러를 절약하게 됩니다.

하지만 진정한 가치는 비용 절감뿐만 아니라처리량에 있습니다. 이러한 최적화를 통해 에이전트는 동일한 컨텍스트 창에서 더 복잡한 워크플로를 실행할 수 있어 작업을 더 빠르게 완료하고 정교한 쿼리를 처리할 수 있습니다.

에이전트 워크플로우에 중요한 이유

토큰 최적화는 단순히 비용 절감만이 아닙니다. 컨텍스트 창 내에서더 복잡한 워크플로우를 가능하게 하는것입니다.

20만 토큰 컨텍스트 창 기준:

최적화 전:제한에 도달하기 전까지 약 10개의 다단계 워크플로우 처리 가능
최적화 적용 시:동일한 창에서 약 20개의 워크플로우 처리 가능

동일한 인프라에서처리량이 100% 증가합니다.

이를 1일차의도구 그룹(시스템 프롬프트 토큰 60-95% 감소) 및 2일차의커스텀 도구(정밀 도구 선택)와 결합하면, 에이전트 전체 라이프사이클(시스템 프롬프트 + 도구 호출 + 도구 응답)에 걸쳐 엄청난 토큰 총량 감소를 기대할 수 있습니다.

기술적 세부사항: 패키지 종속성

두 최적화 계층 모두 검증된 오픈소스 라이브러리를 사용해 구현되었습니다:

remark— 마크다운 프로세서(MDX, Gatsby, Next.js에서 사용)
strip-markdown— 서식 제거용 Remark 플러그인

이는 매일 수백만 건의 요청을 처리하는 프로덕션 사이트에서 사용하는 것과 동일한 도구입니다.

차이점을 확인하세요

영향을 측정해 보시겠습니까? 토큰 수를 비교해 보세요:

검색 엔진도구를 호출하고 응답 내 토큰 수를 세어보세요
동일한 쿼리에 대한 기존 SERP API 응답과 비교
LLM 공급자의 토큰화 도구 사용 (예: OpenAI/Claude용tiktoken)

구글 검색에서는 80%, 스크랩된 페이지에서는 40%, 구조화된 데이터셋에서는 50% 감소 효과를 확인하실 수 있습니다.

이는 단순한 최적화가 아닙니다. 웹 데이터를 AI 에이전트에 전달하는 방식을 완전히 재고한 것입니다.

성능 통계 요약

최적화	영향을 받는 도구	토큰 감소	사용 사례
Strip-Markdown	`scrape_as_markdown`	~40%	웹 페이지 요약, 콘텐츠 추출
파싱된 라이트	`search_engine` (Google 전용)	~80%	검색 결과 파싱, 리드 생성, 연구 워크플로

다음 단계는?

내일(4일차)에는 팀이 이미 사용하는 플랫폼에 MCP 서버를 연동하는 엔터프라이즈 통합 기능을 출시합니다.

계속 지켜봐 주세요.