우리는 84% 토큰 감소를 벤치마크했습니다. 그런 다음 프로토콜을 오픈소스화했습니다.
Source: Dev.to
나는 에이전트가 간단한 질문에 답하는 모습을 보고 있었다.
그 질문은 작았다. 세 문장만으로도 충분했을 것이다. 에이전트는 페이지를 로드하고, HTML을 파싱하고, 네비게이션 바, 푸터 링크, 쿠키 배너, 고정된 “뉴스레터 구독” 모달, 서론의 세 단락을 차례로 살펴본 뒤, 결국 필요한 부분을 찾았다.
두 만 개 토큰.
세 문장에 대해.
이 일은 지금 어디서나 일어나고 있다. 조용히. 끊임없이. 모든 에이전트, 모든 질의, 모든 페이지에서. 우리는 인간의 눈을 위해 만들어진 웹을 에이전트에게 넘겨주고 그것이 작동하도록 요구했다.
그 결과… 비싸게 작동한다.
The shape is wrong
The web was built for browsers. Humans scroll, scan, skip the boilerplate. Our eyes know what nav bars look like.
Agents don’t get that for free.
They read the whole thing. There’s no “give me the relevant part” channel, scaffolding and all—every header, every analytics script, every footer link in twelve languages. The cost is paid in tokens, latency, and the slightly absurd reality that an agent might burn more compute parsing your nav menu than thinking about your content.
This is a shape problem. No amount of optimization fixes a shape mismatch.
ACP: 형태, 프레임워크가 아니라
Atomic Content Protocol (ACP) – 구조화된 콘텐츠 엔벨로프를 위한 오픈 스펙.
- 프레임워크가 아니다.
- 플랫폼이 아니다.
- 형태이다.
콘텐츠를 사전 계산하여 압축되고 풍부한 표현으로 만든 뒤 이를 지속하고 먼저 제공합니다. 엔벨로프는 본문 앞에 위치하지만 본문을 대체하지는 않습니다. 필요할 경우를 대비해 본문은 여전히 존재하지만, 대부분의 경우 에이전트는 본문을 필요로 하지 않습니다.
MCP 위에 구축되었습니다. 오픈 스펙이며 MIT 라이선스를 갖고, npm 패키지가 제공됩니다. 이미 진행 중인 프로토콜을 보완하도록 설계되었으며, 이를 대체하려는 것이 아닙니다.
예시 엔벨로프
{
"id": "atom_7f3a...",
"summary": "AI is the capability of computational systems to perform tasks associated with human intelligence...",
"classification": "reference",
"language": "en",
"tags": [
"artificial-intelligence",
"machine-learning",
"deep-learning",
"neural-networks"
],
"key_entities": [
"OpenAI",
"Google DeepMind",
"Transformer Architecture",
"AGI",
"NLP"
],
"confidence": 0.85,
"provenance": {
"tool": "acp-enricher",
"version": "0.4.2",
"generated_at": "2026-05-14T09:12:33Z"
},
"agent_discoverable": true,
"body_ref": "https://en.wikipedia.org/wiki/Artificial_intelligence"
}콘텐츠는 원자(atom)라는 개별 단위로 분해됩니다—안정적인 ID를 가진 독립적인 유닛입니다. 특정 원자가 필요한 에이전트는 전체 페이지가 아니라 그 원자만 요청합니다. 이것이 바로 전체 아이디어입니다. 단순함이 많은 작업을 대신해 줍니다.
파이프라인
Enrichment는 비동기적으로 실행됩니다; 쓰기 경로를 차단하거나 실시간 비용을 지불하지 않습니다. 흐름:
- Content changes → 트리거가 행에
dirty플래그를 설정합니다. - Queue worker 가 이를 밴드 외부에서 가져갑니다.
- Enricher 가 envelope(요약, 태그, 엔터티, 분류)을 생성합니다.
- Envelope 가 데이터베이스에 영구 저장됩니다.
- Agent requests 가 들어오면 → 캐시에서 envelope을 제공하고, 본문은 요청 시에만 가져옵니다.
에이전트가 나타날 때까지 envelope이 이미 준비되어 있습니다. 요청 경로에서 온디맨드 연산이나 LLM 호출이 없으며, 단순히 읽기만 수행합니다.
쿼리 모드
| 모드 | 비용 (토큰) | 얻는 내용 |
|---|---|---|
aco | 619 | Envelope만 |
full | 3,043 | Envelope + 스크랩된 본문 |
both | 3,043 | full과 동일 |
full 버전은 동일한 쿼리에 대해 약 80 % 더 많은 비용이 듭니다. 이 추가 비용의 대부분은 에이전트가 필요로 하지 않은 HTML을 처리하는 데 사용됩니다.
그리고 우리는 그를 중심으로 제품을 재구축했습니다
We didn’t just publish the spec.
We rewrote Stacklist around it.
Stacky, 우리의 MCP 서버는 이제 기본적으로 ACO 봉투를 제공합니다. Stacklist의 모든 카드는 앞에 봉투가 놓여 있습니다. dirty‑flag → queue‑worker → persist 파이프라인이 프로덕션에서 실행됩니다. 에이전트가 Stacky에 쿼리할 때쯤이면 봉투가 준비되어 있습니다.
우리는 이것을 직접 체험해야 했기 때문에 이렇게 했습니다. 사양은 형태를 설명합니다. 제품은 그 형태를 가지고 있습니다. 이것은 다른 개념이며, 마이그레이션을 보면서 봉투가 하나의 컬럼인지 자체 테이블인지 결정할 때 그 차이를 알게 됩니다 (그것은 자체 테이블입니다—두 경우 모두 시도해봤습니다).
그래서 이제 Stacky는 우리가 웹이 에이전트와 대화하길 바라는 방식으로 에이전트와 소통합니다. 그리고 우리는 실제로 그 비용이 얼마나 드는지—혹은 드는 것이 없는지를 측정할 수 있게 되었습니다.
숫자
쿼리: “Stacky, 위키피디아의 인공지능 기사 좀 줘.”
| 읽은 내용 | 대략 토큰 수 |
|---|---|
| 전체 본문 | ~25,000 |
| ACO 엔벨로프 | ~350 |
절감: ~99 %
이는 노트북에서 실행한 벤치마크가 아니라, 지금 바로 실제 제품을 통해 실제 페이지에 대한 실제 쿼리입니다.
패턴은 콘텐츠 전반에 걸쳐 일관됩니다. 더 넓은 13개 항목 세트에서는:
- 전체 본문: ~65,000 토큰
- 엔벨로프: ~2,800 토큰
감소: 84 %–93 % (문서에 따라 다름)
절감 효과는 사소한 것이 아닙니다. 10 % 정도의 작은 승리를 그래프로 보여줘야 할 정도가 아니라, “이걸 왜 지금까지 안 했을까?” 라는 수준의 차이입니다.
아직 해결하지 못한 부분
솔직히 말해야 할 부분이 여기 있습니다.
모든 엔벨로프에는 도구, 버전, 타임스탬프가 찍혀 있습니다. 누가 언제 엔벨로프를 만들었는지 확인할 수 있죠. 출처 레이어는 실제로 존재하고 작동하고 있습니다.
하지만 엔벨로프는 아래에 있는 내용을 충실히 표현한다고 주장합니다. 그리고 “충실히 표현한다”는 것은 기술적인 진술이면서 동시에 사회적인 진술이기도 합니다.
누군가 본문과는 다른 내용을 적은 엔벨로프를 발표하는 것을 무엇이 막을까요? 적대적 인핸스먼트는 어떤 모습일까요? 인핸스먼트를 누가 감시하나요? 에이전트가 엔벨로프만 읽고 본문을 건너뛸 때—우리가 정확히 원하는 효율성—엔벨로프가 거짓말을 하고 있다면 어떻게 될까요?
깨끗한 답은 없습니다. 부분적인 답은 있습니다: 서명된 엔벨로프, 검증 가능한 인핸스먼트 체인, 평판 레이어 등. 각각은 실제 작업이며, 문제를 해결하기보다는 문제를 다른 형태로 옮깁니다.
솔직히 말하면: 우리는 에이전트 웹을 의미 있게 더 효율적으로 만드는 형태를 만들었습니다. 신뢰는 해결하지 못했습니다. 우리는 신뢰를 더 눈에 띄게 만들었을 뿐이며, 눈에 띈다고 해서 해결된 것은 아닙니다.
이 부분이 제가 계속 고민하게 만드는 부분입니다.
효율성은 실제입니다. 형태는 작동합니다. 숫자는 벤치마크와 우리 제품 모두에서 입증됩니다. 그리고 그 모든 것 아래에는 — 독자가 검증을 멈췄을 때 “충실히 표현한다”는 것이 무엇을 의미하는가 — 라는 질문이 있습니다. 이것이 에이전트 웹의 실제 어려운 문제이며, 아직 우리 중 누구도 답을 찾지 못한 것 같습니다.
그래서 우리는 계속 구축해 나갈 것입니다.
그리고 그 문제와 계속 마주할 것입니다.
두 가지를 동시에.