에이전트에 원시 데이터 공급 중단
Source: Dev.to
나는 문제의 원인이 에이전트라고 생각했다.
큰 JSON 파일을 넘겨주고 “무엇이 바뀌었는지, 위험해 보이는 부분은 무엇인지, 릴리즈 전에 조사해야 할 점은 무엇인지” 같은 합리적인 질문을 하면,
에이전트는 무언가를 찾아냈다. 언제나 뭔가를 찾아냈다.
하지만 필드를 놓치고, 관련 없는 값에 과도하게 주목하며, 실제 존재하지 않는 JSON 패턴을 환상처럼 만들어냈다.
눈에 띄는 하나의 레코드만 보고, 그 레코드가 의미를 갖게 하는 평범한 분포는 무시했다. 그래서 나는 보통의 해결책을 시도했다: 더 엄격한 프롬프트, 더 긴 지시문, 더 큰 컨텍스트 윈도우, 더 많은 예시.
실제 문제는 훨씬 단순했다.
나는 에이전트에게 시끄러운 컨텍스트를 제공하고 있었던 것이다.
데이터 자체가 나쁜 것이 아니라, 컨텍스트가 나빴다.
원시 구조화 데이터는 반복, 우연한 형태, 스키마 잡음, null, ID, 타임스탬프, 중첩된 보일러플레이트, 그리고 집계될 때만 의미를 갖는 필드들로 가득하다. 인간도 이를 다루기 힘들고, 에이전트도 마찬가지다.
거대한 API 응답, GitHub 내보내기, 로그 덤프, CSV, 혹은 소스 트리를 모델에 붙여넣고 “중요한 부분을 찾아라”고 하면, 모델에게 두 가지 일을 동시에 시키는 셈이다:
- 데이터를 측정한다.
- 그 측정값에 대해 추론한다.
이 두 작업은 서로 다른 일이다.
Vajra는 이 둘을 분리하려는 시도다.
모델이 추론하기 전에 Vajra가 측정한다. 에이전트가 계획을 세우기 전에 Vajra가 원시 입력을 증거 형태로 축소한다.
기본 에이전트 워크플로는 아직도 복사‑붙여넣기에 너무 가깝다.
레포지토리를 주고, JSON 덤프를 주고, 로그 더미를 주고, 반구조화 파일 디렉터리를 주고, 그 다음에 “구조를 추론하고, 이상을 식별하고, 드리프트를 감지하고, 증거를 보존하고, 다음에 무엇을 할지 결정하라”고 요구한다.
그것은 강력해 보이지만, 노동 분업이 잘못된 것이다.
에이전트는 해석, 종합, 계획, 트레이드오프 분석에 유용하지만, 중첩 문서의 모든 경로를 세거나, 값들의 엔트로피를 계산하거나, 두 분포를 비교하거나, 타입 불안정을 감지하거나, 형태의 반복 가능한 지문을 만드는 일에는 최적의 도구가 아니다.
그런 작업은 지루한 소프트웨어가 해야 한다.
항상 같은 답을 반환하는 신뢰할 수 있는 소프트웨어.
그것이 내가 에이전트 앞에 두고 싶었던 레이어다.
Vajra는 구조화 데이터를 분석하기 위한 Rust CLI와 라이브러리다.
처음엔 거대한 JSON에 대한 단순한 좌절감에서 시작했지만, 이제는 에이전트가 일상적으로 섭취하는 데이터에 대한 신호 레이어로 성장했다:
- JSON, NDJSON, YAML, CSV, TSV 같은 구조화 데이터
- Markdown, PDF 텍스트, CPU 프로파일, strace 로그 같은 운영 아티팩트
- 레포지토리, GitHub 내보내기, tree‑sitter 로 파싱한 소스 코드
목표는 흐릿한 요약이 아니라 안정적인 측정이다.
예시:
vajra inspect payload.json
vajra stats events.ndjson
vajra anomalies batch.json
vajra drift baseline.json current.json
vajra essence payload.json --profile ai --format compact-ai --budget 500 --redact
vajra inspect src/main.rs --input-format source --lang rust --semantic-paths
vajra governance commits.json이 명령들은 경로, 타입, 지문, 엔트로피, 카디널리티, 이상치, 희소성, 스키마 드리프트, 소스 코드 구조, 기여자 집중도, 인간이나 에이전트가 읽을 수 있도록 설계된 압축된 에센스 등을 제공한다.
핵심 키워드는 안정성이다.
같은 입력, 같은 설정, 같은 버전이면 언제나 같은 결과가 나온다.
이는 겉보기에 생각보다 더 중요한 요소다.
에이전트가 도구를 호출하고, 계획을 업데이트하고, 권고를 만든 뒤 다시 도구를 호출한다면, 그 도구는 기분 반지처럼 변덕스러워서는 안 된다. 악기처럼 일관된 측정값을 제공해야 한다.
내가 계속 저지른 실수는 다음과 같다.
“모델에 가능한 것”을 “모델이 사용할 수 있는 것”과 동일시했다.
하지만 두 개념은 다르다.
5 MB JSON 내보내기가 컨텍스트 윈도우에 들어간다고 해서 좋은 컨텍스트가 되는 것은 아니다. 대부분의 토큰은 반복되는 객체 구조, 복제된 ID, 공통 타임스탬프, 신호가 낮은 값, 혹은 집계 분석을 해야 의미가 드러나는 필드일 수 있다.
Vajra는 그런 원시 입력을 측정된 주장의 작은 집합으로 변환한다.
예를 들어, 에이전트에게 모든 레코드를 주고 “어떤 경로가 불안정한지”를 눈으로 찾아보게 하는 대신, 다음과 같은 측정된 신호를 제공한다:
Path: $.claims[*].status
Dominant type: string
Cardinality: 7
Entropy: 1.82
Rare values: reversed_manual, pending_external_review
Null rate: 0.00두 개의 페이로드 사이의 스키마 드리프트를 눈으로 확인하게 하는 대신, 다음과 같은 드리프트 보고서를 제공한다:
Removed path: $.member.coverage.plan_id
Added path: $.member.coverage.policy_ref
Type changed: $.claim.amount string -> number
Distribution drift: $.claim.status high
Severity: critical전체 레포지토리 내보내기를 검사하게 하는 대신, 다음과 같은 프로젝트 건강 신호를 제공한다:
- Bus factor: 2
- Contributor concentration: high
- One‑commit contributor rate: 0.61
- Most active author share: 0.44
- Velocity trend: declining
위 예시들은 대표적인 형태일 뿐이며, 모든 명령이 정확히 이 줄들을 출력한다는 약속은 아니다. 핵심은 워크플로다: 도구가 측정을 수행하고, 에이전트가 그 측정값을 기반으로 추론한다.
이제 에이전트는 실제로 유용한 작업을 할 수 있다.
결과에 대해 추론하고, 드리프트가 의도된 것인지 물으며, 마이그레이션 계획을 제안하고, 보고서에 어떤 증거를 포함할지 결정하고, 원시 데이터 덩어리가 아니라 관련 필드를 포함한 이슈를 열 수 있다.
내가 원하는 에이전트 워크플로는 다음과 같다:
raw data / repo / logs / API export
→ deterministic analysis
→ compact evidence bundle
→ agent reasoning
→ action plan or code change
→ re‑analysis
→ verification이 루프는 기존의 “붙여넣고‑희망” 루프와 다르다.
에이전트는 원시 레코드에서 직접 측정을 추론할 이유가 줄어들고, 측정된 사실을 기반으로 추론한다.
Vajra는 모델 앞에 자리 잡아 무엇이 주목받아야 하는지 결정한다. 창의력을 가장한다 척 하지 않고 압축한다. 모든 이상을 자동으로 중요하게 여기지 않는다. 경로와 증거를 보존해 에이전트가 데이터로 다시 돌아갈 수 있게 한다.
요약과 악기의 차이는 다음과 같다.
- 요약: “무언가가 바뀌었다.”
- 악기: “이 경로가 바뀌었고, 이 값 분포가 이동했으며, 이 타입이 불안정하고, 여기 증거가 있다.”
예를 들어, 릴리즈 전 GitHub 프로젝트를 검토하는 에이전트를 생각해 보자.
나이브 버전은 이슈, 풀 리퀘스트, 커밋, 릴리즈를 대량으로 받아 원시 레코드에서 프로젝트 건강을 추론한다. 최근 실패를 눈치채지만 기여자 집중도를 놓치고, 이슈 제목만 요약해 오래된 소유 패턴을 놓