에이전트 하네스
생성은 모델에, 판정·재시도·종료는 실행기에 맡기는 실행 엔진
Posts 10
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
재시도를 다 썼는데 같은 답을 계속 채점하고 있었습니다
품질 재시도가 상한을 전부 쓰고 끝났습니다. 기록을 따라가니 모델은 도구를 부르며 진행 중이었고 판정기는 직전 실패 답을 다시 채점하고 있었습니다. 점수와 후보의 수명을 한 회차로 묶은 과정입니다.
도구가 목록에는 보이는데 부를 수는 없었습니다
검색 범위를 좁히려고 허용 목록을 걸었더니 사용자가 직접 연결한 도구까지 함께 빠졌습니다. 이름 공개와 스키마 공개와 실행 권한을 각각 다른 시점에 두게 된 과정입니다.
규칙을 고친 뒤에도 남은 판정 흔들림은 공유 추론 서버에서 왔습니다
대형 유통 품질검사 에이전트가 같은 서류에 합격과 불합격을 번갈아 냈습니다. 판정 규칙, 이미지 판독, 프롬프트, 부하를 하나씩 제외하고 같은 텍스트를 10번 넣는 실험으로 공유 서버의 배치 처리까지 좁힌 과정입니다.
검증셋을 떼어뒀다고 믿었는데 아니었습니다
설정을 자동으로 탐색하게 만들면서 승격 문턱과 검증셋을 뒀습니다. 구현을 다시 읽어보니 후보를 제안하는 쪽이 그 검증 기록을 보고 있었습니다. 자동 탐색기에 무엇을 맡길 수 있고 무엇을 맡길 수 없는지 정리합니다.
제출 도구를 부르고도 실행이 멈추지 않았습니다
종착 도구가 성공했는데 실행이 계속됐고, 반대로 이전 회차의 기록만 보고 현재 회차를 일찍 끝내기도 했습니다. 다시 호출하는 이유와 종료를 소유하는 위치를 나눈 과정입니다.
답을 만든 모델에게 채점까지 맡기고 있었습니다
같은 모델이 답을 만들고 이어서 자기 답이 규칙을 지켰는지 판단하면 생성 방법과 합격 기준이 한 컨텍스트에 섞입니다. 업무를 수행하는 책임과 결과를 채택하는 책임을 나누고, 나눈 뒤에도 남은 한계를 정리합니다.
설치는 됐는데 같은 실행이라고 부를 수 없었습니다
워크플로우를 wheel로 묶어 다른 환경에 설치했습니다. 도구를 호출하자 제품 안에서만 성립하던 전제가 드러났습니다. 포장 형식을 두 번 갈아엎으며 무엇을 고정해야 실행이 옮겨가는지 확인한 과정입니다.
저장소를 나눴는데 의존성은 그대로였습니다
엔진을 별도 모듈로 옮겼지만 실행하려면 제품의 설정 객체와 데이터베이스 세션, 캔버스 노드를 먼저 불러와야 했습니다. 독립을 선언한 사흘 뒤부터 누수를 잡으며 배운, 경계가 닫혔는지 확인하는 방법입니다.
재시도 횟수로는 실행을 설명할 수 없었습니다
도구를 세 번 쓴 실행과 품질 검증에 세 번 실패한 실행이 같은 '재시도 3회'로 남았습니다. 생성·검증·도구 실행·재시도를 하나의 반복문에서 꺼내 명시적인 상태와 전이로 나눈 과정입니다.
Engineering 22
온톨로지 엔진의 이식성: 커밋 258개 격차를 파일 단위로 맞추고 출력 동일성으로 라이브러리를 검증하기
같은 온톨로지 기능을 고객 배포 라인과 다른 서비스에 반복해서 싣는 비용을 줄이려고, 고객 라인을 파일 단위와 3-way 병합으로 제품 라인에 맞추고 빌드 로직을 환경 의존 없는 라이브러리로 옮겼습니다. 동일성은 실코퍼스 14,924청크의 출력 대조로 증명했고, 남은 연동 코드 약 12,000줄은 호스트가 네 가지 포트만 구현하면 되는 어댑터 계층으로 분리하자고 제안했습니다.
그래프 크기를 따라가던 검색 비용과 흔들리던 근거: PostgreSQL 그래프 조회 계층 정비
PostgreSQL 위 GraphRAG 검색이 한 번에 54~127초 걸리거나 같은 질문에 근거가 달라지는 현상을 pg_stat_activity, 실행 계획, 로그 타임스탬프로 추적했습니다. 플래너 통계, 그래프 전체를 읽던 PPR, 검색마다 반복되던 집계, 정렬 없는 LIMIT을 차례로 고쳐 비용을 후보 크기에 묶고 근거 재현을 50/50으로 맞췄습니다.
오답 60건을 시스템 시점에서 감사하기: 실패를 근거 활용과 후보 회수로 나누고 개선안을 실측으로 거른 기록
평가 런 4개의 오답을 모아 정답 청크 60건을 골든셋 앵커 없이 시스템이 보는 정보만으로 감사했고, 오답의 60%가 검색이 아니라 근거 활용에서 난다는 것을 확인했습니다. 원인 9가지와 개선안 10가지로 기획을 세운 뒤, 검색 회수를 먼저 재는 프로토콜로 개선안 대부분을 실측으로 걸러 냈습니다.
시간 상한은 탐색에만, 합성 지연은 스트리밍으로: 근거 누출 사고에서 시작한 검색 지연 재설계
질문당 총시간을 보장하려고 건 25초 하드 상한이 합성 LLM에 4초만 남겨, 내부 근거가 답변으로 새는 사고로 이어졌습니다. 로그와 단계별 계측으로 지연의 대부분이 합성 대기임을 확인하고, 상한은 탐색에만 두고 체감 지연은 합성 입력의 문자 예산과 답변 스트리밍으로 다뤘습니다.
Fuseki 없이 지식 그래프 운영하기: PostgreSQL 테이블 3개로 옮기며 드러난 숨은 결합들
별도 JVM 트리플스토어인 Fuseki는 설정 하나가 어긋나면 그래프 계층 전체가 멈추고 폐쇄망 반입 부담도 컸습니다. 같은 빌드를 두 저장소에 이중 기록해 충실도를 대조한 뒤 Fuseki 쓰기를 기본 비활성화했고, 완료 판정·재시도·카운트·품질 지표에 숨어 있던 Fuseki 전제를 하나씩 걷어내며 검색을 라이브러리로 일원화했습니다.
xgen-seepage: 인터넷 없이 설치되는 Excel 에이전트 커넥터와 Office.js를 걷어낸 이유
XGEN 에이전트가 사용자가 열어 둔 Excel 통합문서를 직접 읽고 편집하게 하는 독립 커넥터입니다. Office 애드인 대신 COM 직결과 단일 실행 파일 배포를 택해 폐쇄망 설치를 가능하게 했고, 실제 서버와 실제 Excel에서 검증하며 압축 협상 충돌, 실행 파일의 번들 누락, Office.js 대기 멈춤을 차례로 해결했습니다.
'이전 대화가 쌓였습니다'의 오지목: 토큰 예산 계층을 고쳤더니 공유 GPU가 느려진 이유와 원복
'이전 대화가 쌓였다'는 안내만 반복하던 에이전트를 토큰 버킷 로그로 추적해 문구의 오지목, 줄일 수 없던 시스템 프롬프트·도구 스키마, 오히려 텍스트를 늘리던 truncate를 고쳤습니다. 그 수정이 잠들어 있던 압축 경로를 깨워 공유 GPU 지연을 만든 메커니즘을 확인해 원복했고, 재현으로 근본 압력이 검색 결과 크기에 있음을 확인했습니다.
XGEN MAKER: 코드 지식그래프 착지 정확도를 사람이 머지한 MR 2,827건으로 잰 개발 자동화 하네스
다중 저장소 플랫폼의 코드를 결정론적 정적 분석으로 지식그래프화하고, 자연어 요청을 파일·라인 단위로 착지시켜 구현·검증·MR 준비까지 수행하는 하네스입니다. 착지 품질은 사람이 실제로 머지한 MR 2,827건으로 측정했고, 표본을 넓히는 과정에서 작은 표본에 과적합된 순위 상수를 찾아 걷어냈습니다.
광고 심의 에이전트: 판정 권한을 LLM에서 코드 검증기로 옮겨 실제 심의 34건의 판정을 고정하기
XGEN 캔버스로 광고 심의를 자동화하는 PoC에서 10/10이던 판정이 재실행에 8/10으로 흔들린 원인을 비결정성 세 층으로 분해했습니다. 최종 판정을 코드 검증기가 확정하게 바꾸고 추출과 심의를 6개 에이전트로 나눠, 실제 심의 34건 판정 34/34와 지적 재현율 67%를 얻었습니다.
sam2-mcp: 30초 호출 한도에 맞춘 비전 MCP 서버와 이미지형 PDF 실패 추적
GPU 없는 머신에서 SAM 2 세그멘테이션과 비전 OCR을 에이전트 도구로 제공하는 FastMCP 서버입니다. 호출당 30초 한도와 세션당 단일 호출이라는 플랫폼 제약을 실측으로 확인해 병렬 처리를 서버 안으로 옮겼고, 이미지형 PDF에 몰린 심의 실패를 서로 독립된 결함들로 분해해 고쳤습니다.
XGEN CREATOR: 클릭이 실행한 백엔드 코드 라인을 증거로 산출물을 만드는 라이브 트레이서
브라우저 클릭을 프론트엔드 소스에 연결하고, 그 클릭이 실행한 백엔드 Python 라인을 sys.monitoring 기반 트레이서로 캡처해 UI 정의서·테스트결과서·API 명세서를 생성하는 도구입니다. 실제 XGEN 스택에서 관측이 대상을 멈추는 문제, 산출물은 나오는데 트레이스가 0건인 조용한 실패, 콜스택 깊이 오차를 차례로 고쳤습니다.
agethos: 성격 설명을 타입 있는 설정으로 컴파일하고, judge가 못 보는 행동 편차를 계측하기
LLM 에이전트에 성격·기억·감정을 부여하는 PyPI 라이브러리 agethos에서 성격 값이 추론 방식에 인과적으로 닿게 하고, 자연어 설명을 설정으로 컴파일하는 draft·judge·repair 루프를 만들었습니다. judge 패널로 충실도를 0.930까지 올렸지만 장착된 인격의 Mini-IPIP 측정은 0.783이었고, 그 간격을 재는 검증 계층을 더했습니다.
재시도 루프의 종점 오판 다섯 건: 텍스트 휴리스틱에서 실행 상태 신호로
제출 후 90회 반복, 빈 최종 출력, 조용히 0.7을 내던 Judge, 재시도율 80%의 기준 설계, 같은 답을 세 번 채점한 retry-death를 차례로 추적했습니다. 모두 판정이 이번 회차의 실행 상태 대신 텍스트 길이나 이전 회차의 값을 읽은 결과였고, 종료와 채점의 근거를 실행 상태로 옮겼습니다.
에이전트 기억 계층 설계: 저장만 되던 교훈이 다음 실행을 바꾸기까지
하네스의 기억을 작업 기억, 실행 상태, 장기 기억으로 수명에 따라 나눠 엔진 훅과 4스코프 메모리로 구현했습니다. 경고 없이 0행이던 상태 기록과, 실패한 답만 담긴 채 정렬 없이 공급되던 교훈을 추적해 고쳤고, 다음 실행의 첫 초안이 재시도 없이 통과하는 것을 확인했습니다.
도구 카탈로그의 단계적 공개: 검색을 pull로 옮기고 '연결'과 '탐색 허용'을 나누기까지
엔진이 도구 스키마와 검색 결과를 매 턴 밀어 넣던 구조를, 모델이 목차를 보고 필요한 것만 승격해 쓰는 pull 구조로 바꿨습니다. 미승인 도구 승격, 약한 모델의 발견 실패, 임의 가중치 검색, 연결 도구 소멸을 차례로 겪으며 가시성을 출처별로 나누고 도구 검색을 BM25F로 정했습니다.
동일 하네스 조건의 모델 비교: 41분 실행과 빈 출력은 모델이 아니라 설정과 엔진 문제였습니다
같은 하네스 노드에서 메인 모델만 바꾸고 고정 심판으로 채점해 내부 vLLM의 Qwen3.6-27B와 Claude Sonnet 4.6을 실무 과제로 비교했습니다. 41분짜리 실행은 재시도 설정이, 빈 출력은 빈 도구 결과를 성공으로 세던 엔진 결함이 원인이었고, 이를 걷어낸 뒤 재현한 6개 과제에서 두 모델은 0.01~0.05 차이의 사실상 동률이었습니다.
자가단조(Self-Forging) 설계: 지시문 대신 타입 있는 설정을 변이하고 3중 게이트로 채택하기
에이전트가 자기 지시문을 고쳐 쓰는 대신, 엔진 레지스트리가 허용하는 타입 있는 설정 변이만 제안하고 dev 상승, held-out 유지, Judge와 무관한 보조 지표 유지를 모두 통과한 변경만 채택하는 루프를 엔진에 구현했습니다. 실모델로 실행하자 Judge와 실행 중 자가조정이 각각 조용히 꺼져 있었다는 것도 드러났습니다.
플랫폼을 모르는 하네스 엔진: 코드 결합을 끊고 설정 진실원본을 하나로 모은 과정
공용 실행 코어 안에 있던 하네스를 독립 엔드포인트로 옮기고, 엔진이 알던 플랫폼 코드 2,251줄을 Protocol과 entry_points 뒤의 브리지 계층으로 넘겼습니다. 경로마다 달랐던 설정 조회는 우선순위 체인과 공용 매핑으로 모았고, 배포 이원화를 없애려 엔진을 SDK로 흡수한 뒤 다시 생긴 사본 분기까지 기록했습니다.
빌드 진행률은 어디서 읽어야 하는가: 그래프 역산을 걷어내고 PostgreSQL 카운터를 정본으로
진행률을 RDF 그래프 역질의로 복원하던 구조 때문에 74초 걸리는 진행률 API, 좀비 잡, 빌드 중 전체 API 무응답이 겹쳤습니다. 정본을 PostgreSQL로 옮겼다가 되돌리고 다시 옮긴 경위와, 진행 상태와 빌드 결과를 분리한 네 가지 원칙, 이벤트 루프 오프로드의 실측을 정리합니다.
전용 QA 노드를 범용 하네스 노드로 옮기며: 캡슐이 숨기던 기능과 엔진이 읽지 않던 채널
품질검사 전용 캡슐 노드가 암묵적으로 처리하던 이미지 입력, 서브툴 바인딩, 세션 전달, RAG 전달을 범용 하네스 노드로 옮기며 드러난 결함 15종을 고객사 개발 환경에서 실측하며 고쳤습니다. 그중 두 번은 수정값을 엔진이 읽지 않는 채널에 쓰고 있었고, 엔진 소스로 설정 해석을 재현해 살아 있는 채널로 다시 연결했습니다.
컴파일된 에이전트가 밖에서도 동작하는가: 빈 도구 정의, 빠진 패키지 초기화 파일, 0자로 잘린 RAG
캔버스에서 만든 에이전트를 wheel·npm·MCP 도구로 내보내 환경변수만으로 실행되게 하면서, 빌드와 설치는 성공하는데 실제로는 동작하지 않던 세 경로를 추적했습니다. 비어 있던 도구 정의는 서브파이프라인 동결로, PyPI 네 버전의 import 실패는 fresh-clone 빌드 검증으로, 한 번도 동작하지 않던 standalone RAG는 기본값 세 곳을 고쳐 바로잡았습니다.
에이전트 전용 상태 머신 실행기: 실행기 내장 철회에서 10단계 Python 엔진까지
기존 워크플로우 실행기에 검증 미들웨어를 넣는 시도가 하루 만에 되돌려진 뒤, 에이전트 루프를 별도 상태 머신 실행기로 분리했습니다. Rust 12단계 프로토타입을 Python으로 다시 쓰고 책임이 모호한 단계를 전략과 확장점으로 흡수해 10단계 계약을 확정했으며, 이 단계 구성은 7월까지 바뀌지 않았습니다.