9월 29일 화요일 Tech Daily

01오늘의 깊이 읽기

고정 파이프라인을 벗어난 에이전트 스택의 두 축

문서를 해석 가능한 상태로 만드는 컨텍스트 레이어와 작업을 분해·감시·표현하는 실행 레이어를 분리해 보면, 정확도·비용·지연시간을 어디에서 조정해야 하는지가 선명해진다.

ai-llm3분

검색 함수가 아니라 탐색 루프를 설계한다

초기 RAG는 문서를 청크로 나누고 임베딩한 뒤 고정된 top-k 결과를 모델에 넘기는 선형 파이프라인이었다. 에이전트형 RAG에서는 검색의 복잡성이 한 단계 위로 이동한다. 에이전트가 목표에 맞는 검색어를 고르고, 결과를 읽고, 부족하면 다시 질의하며, 필요한 도구를 바꿔 호출한다. 이때 BM25·grep·벡터 검색·문서 읽기는 서로를 대체하는 단일 우승자가 아니라 탐색 루프가 선택하는 도구 세트가 된다. 설계의 초점도 ‘어떤 검색기를 붙일까’에서 ‘어떤 근거를 찾을 때 어떤 도구를 쓰고, 언제 원문으로 돌아가며, 무엇을 확인해야 종료할까’로 바뀐다. 긴 컨텍스트나 압축이 발전해도 올바른 문서와 도구를 연결하는 문제가 사라지지 않는 이유다. 모델의 추론 능력과 조직의 실제 문서·데이터에 접근하는 계층을 분리해야 검색 실패가 모델 한계인지, 잘못된 컨텍스트 공급인지 진단할 수 있다.

빠른 전체 패스와 느린 정밀 패스를 나눈다

문서 컨텍스트 레이어는 파싱, 의미·저장, 반복 워크플로우의 세 층으로 볼 수 있다. PDF의 글자는 문장보다 좌표를 가진 글리프에 가깝고, 표는 선분과 셀 위치에 놓인 텍스트의 조합일 수 있다. Word와 PowerPoint도 구조 정보와 장식용 태그가 섞여 있다. 따라서 원시 파일을 모델에 밀어 넣는 것만으로는 읽기 순서와 표의 관계, 근거 위치가 안정적으로 복원되지 않는다. 휴리스틱 파이프라인은 빠르고 저렴하지만 복잡한 시각 구조에 약하고, VLM은 레이아웃 이해를 보완하지만 비용이 높으며 텍스트 페이지에서 환각이나 근거 부족이 생길 수 있다. 제시된 해법은 빠른 파서로 전체를 스캔한 뒤 표·차트처럼 깊은 해석이 필요한 페이지만 VLM 경로로 보내는 하이브리드다. ParseBench도 사람 검증을 거친 2,000페이지에서 표·차트·내용 충실도·의미론적 포맷을 측정하고 약 50개 모델을 비교한다. 즉 파서 평가는 텍스트 추출률 하나가 아니라 실제 에이전트가 문서를 이해하는지, 그리고 그 정확도를 어떤 비용과 지연시간에 얻는지를 함께 봐야 한다.

컨텍스트 위에 동적 실행면을 올린다

해석 가능한 컨텍스트가 준비돼도 복잡한 과업을 한 에이전트의 긴 대화로만 밀어 넣으면 병렬성, 격리, 외부 이벤트 대응, 결과 표현이 뒤엉킨다. Antigravity 사례는 실행면을 세 기본 단위로 나눈다. 리드 에이전트는 목표에 따라 프런트엔드·백엔드·인프라·연구·QA 같은 하위 에이전트를 동적으로 만들고 샌드박스나 원격 환경에서 병렬 실행한다. Sidecar는 메시지, 웹훅, 예약 작업, GitHub PR 같은 사건을 장기간 듣다가 모델을 깨우는 트리거를 제공한다. 생성형 UI는 분석 결과에 맞춰 차트·표·필터·상호작용 화면을 그때 구성한다. 이 조합은 모델이 좋아질수록 고정 단계와 고정 화면을 다시 짜지 않고도 더 복잡한 일을 받아들일 여지를 만든다. 다만 하위 에이전트 수와 토큰, 실행 시간은 곧 계산 비용이며 외부 사건을 받는 경로는 권한 경계가 된다. 그래서 작업 분해 능력만 확장할 것이 아니라 샌드박스, 권한 시스템, 관찰 가능한 진행 상태, 자원 예산을 같은 실행 구조에 포함해야 한다. 컨텍스트 레이어가 ‘무엇을 근거로 일하는가’를 책임진다면 실행면은 ‘누가, 언제, 어떤 격리와 비용 안에서 일하고 결과를 어떻게 검토받는가’를 책임진다.

02한 흐름으로 보기

자율성 평가는 최고 점수보다 검증 경계를 먼저 설계한다

연구 기록 경신과 실제 PR 품질 데이터를 함께 보면, 에이전트의 성능 주장은 목적 함수·접근 권한·실행 비용·실패 분포를 분리해 읽을 때 비로소 운영 판단이 된다.

ai-llm4분

에이전트가 인간 기록을 넘거나 인간 코드와 비슷한 평균 품질을 보였다는 결과를 실제 시스템 선택과 배포 기준으로 어떻게 번역해야 하는가?

두 자료는 서로 다른 현장에서 같은 경고를 준다. Optimizer Speedrun에서 Claude Code와 Codex는 인간 기록보다 나은 결과를 냈지만, 실험 기간에 완전히 새로운 옵티마이저나 메커니즘을 독자적으로 발견하지는 못했다. 한편 Greptile이 실제 기업 PR을 관찰한 데이터에서는 AI 주도 PR의 평균 품질이 인간 PR과 대체로 비슷했지만, 에이전트별 오류 종류는 달랐다. 앞선 결과는 명확한 보상과 반복 가능한 실행 환경에서 에이전트가 강한 최적화 작업자가 될 수 있음을 보여주고, 뒤의 결과는 생산 환경에서 평균치만으로 위험을 설명할 수 없음을 보여준다. 따라서 평가 스택은 최고 점수 하나가 아니라 네 층을 가져야 한다. 목표와 성공 조건을 고정하고, 정보·계산·권한 예산을 기록하며, 여러 실행에서 재현성을 확인하고, 마지막으로 실패가 실제 사용자 계약을 어떻게 깨는지 실행 환경에서 검증해야 한다.

01
목적 함수와 접근 권한을 고정한다
Speedrun은 같은 데이터와 목표 손실, 수치로 판정되는 보상을 사용해 아이디어의 성패를 빠르게 반복할 수 있다. 그러나 첫 실험에서는 Claude의 중단과 Codex의 지속 실행, 하위 에이전트 수, 토큰 사용량이 달랐고 최신 인간 기록에 접근할 수도 있었다. 최종 기록만 비교하면 모델 능력과 실행 예산, 정보 이점을 섞게 된다. 제안된 평가 방향은 여러 seed, 동일한 시간·계산량·실행 권한을 적용하고, 사전 학습 지식만 쓰는 트랙·논문만 허용하는 트랙·최신 기록까지 여는 트랙을 분리하는 것이다. ‘얼마나 좋은 점수를 냈나’와 함께 ‘무엇을 볼 수 있었고 얼마나 오래·많이 시도했나’를 결과의 일부로 남겨야 한다.
02
기록 경신과 새로운 발견을 분리한다
두 에이전트는 인간의 Optimizer Speedrun 기록을 넘어섰지만 주된 개선은 기존 논문의 기법을 찾고 조합하는 점진적 탐색이었다. 이는 가치 있는 연구 자동화지만 곧바로 새로운 과학적 메커니즘의 발견을 뜻하지 않는다. 발견을 주장하려면 기존 결과 복제와 새 아이디어를 분리하는 novelty 조건, 작은 실험에서 얻은 개선을 더 큰 규모에서도 다시 확인하는 절차, 생성기와 판정기 및 인간 연구자가 서로의 결과를 검토하는 루프가 필요하다. 벤치마크가 잘 정의될수록 에이전트는 그 목적 함수를 빠르게 최적화할 수 있으므로, 점수 상승이 벤치마크 밖에서도 일반화되는지 따로 시험해야 한다.
03
평균 품질 대신 실패 프로필을 본다
Greptile 데이터에서 Codex·인간·Devin의 되돌리기 비율은 각각 약 1,000건당 1건, 2.5건, 3.5건이었고 병합까지의 리뷰 라운드도 비슷했다. 하지만 되돌리기는 모든 결함을 포착하지 않으며, AI 생성 여부 역시 author·PR footer·branch prefix를 조합한 추정이다. 더 중요한 신호는 평균 아래의 오류 분포였다. Claude는 인간보다 SQL injection 지적 가능성이 약 1.5배 높았고 Devin은 off-by-one 오류 가능성이 인간의 절반 정도였다. 따라서 ‘AI 코드가 인간과 대등하다’는 평균 결론을 자동 승인 정책으로 바꾸면 안 된다. 보안·성능·경계값처럼 제품이 감당하기 어려운 실패 유형별로 에이전트의 프로필을 만들고, 작업 유형과 검증기를 그 프로필에 맞춰야 한다.
04
검증을 실행 경로에 붙인다
코드 생산량이 늘면 정적 리뷰 하나로 처리량과 검증 깊이를 함께 유지하기 어렵다. 제시된 운영 기준은 변경이 현재 사용자 계약을 위반하는지, 미래 위반 가능성을 높이는지, 작성자의 의도를 실제로 충족하는지 묻는 것이다. 이를 확인하려면 변경 파일만 보는 데서 멈추지 않고 샌드박스에서 코드를 실행하고, 의존성을 설치하고, 입력을 모킹하고, 브라우저 에이전트로 사용자 흐름을 조작해야 한다. 사람 없는 병합 비율 자체는 성공 지표가 아니다. 자동 병합은 이런 실행 증거와 에이전트별 실패 모드에 맞춘 guardrail이 먼저 충족될 때만 결과가 된다.

에이전트 도입의 승인 기준은 인간을 한 번 이겼는지가 아니라, 같은 조건에서 결과가 재현되고 실패 원인을 추적할 수 있으며 제품의 위험 기준을 실행 증거로 확인할 수 있는지여야 한다. 연구 에이전트라면 점수·novelty·계산 예산을 분리하고, 코딩 에이전트라면 평균 품질·오류 유형·사용자 계약 검증을 분리한다. 그 위에서만 더 많은 하위 에이전트, 더 긴 실행, 자동 병합 같은 자율성 확대가 비교 가능한 기술 선택이 된다.