Agent Engineering
LLM이 도구를 사용해 작업을 완결하도록 만드는 실행 구조
Posts 12
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
에이전트마다 빌드하면 같은 문서를 에이전트 수만큼 다시 읽어야 했습니다
은행 관리 설정에서 늘어나는 에이전트를 온톨로지로 보여 주려 했습니다. 문서 지식은 자산마다 한 번만 빌드하고, 에이전트의 소유·자산·배포·실행 관계는 설정 테이블에서 LLM 없이 구성해 규칙 인사이트까지 낸 과정입니다.
재시도를 다 썼는데 같은 답을 계속 채점하고 있었습니다
품질 재시도가 상한을 전부 쓰고 끝났습니다. 기록을 따라가니 모델은 도구를 부르며 진행 중이었고 판정기는 직전 실패 답을 다시 채점하고 있었습니다. 점수와 후보의 수명을 한 회차로 묶은 과정입니다.
도구가 목록에는 보이는데 부를 수는 없었습니다
검색 범위를 좁히려고 허용 목록을 걸었더니 사용자가 직접 연결한 도구까지 함께 빠졌습니다. 이름 공개와 스키마 공개와 실행 권한을 각각 다른 시점에 두게 된 과정입니다.
규칙을 고친 뒤에도 남은 판정 흔들림은 공유 추론 서버에서 왔습니다
대형 유통 품질검사 에이전트가 같은 서류에 합격과 불합격을 번갈아 냈습니다. 판정 규칙, 이미지 판독, 프롬프트, 부하를 하나씩 제외하고 같은 텍스트를 10번 넣는 실험으로 공유 서버의 배치 처리까지 좁힌 과정입니다.
가까운 기억이 항상 이기게 두면 안 됐습니다
세션 요청이 플랫폼 정책보다 구체적이니 우선해야 할 것 같았습니다. 그렇게 두면 사용자가 정책을 덮어쓸 수 있었습니다. 실행 간 기억의 범위와 종류를 나누고 충돌을 푼 과정입니다.
검증셋을 떼어뒀다고 믿었는데 아니었습니다
설정을 자동으로 탐색하게 만들면서 승격 문턱과 검증셋을 뒀습니다. 구현을 다시 읽어보니 후보를 제안하는 쪽이 그 검증 기록을 보고 있었습니다. 자동 탐색기에 무엇을 맡길 수 있고 무엇을 맡길 수 없는지 정리합니다.
제출 도구를 부르고도 실행이 멈추지 않았습니다
종착 도구가 성공했는데 실행이 계속됐고, 반대로 이전 회차의 기록만 보고 현재 회차를 일찍 끝내기도 했습니다. 다시 호출하는 이유와 종료를 소유하는 위치를 나눈 과정입니다.
답을 만든 모델에게 채점까지 맡기고 있었습니다
같은 모델이 답을 만들고 이어서 자기 답이 규칙을 지켰는지 판단하면 생성 방법과 합격 기준이 한 컨텍스트에 섞입니다. 업무를 수행하는 책임과 결과를 채택하는 책임을 나누고, 나눈 뒤에도 남은 한계를 정리합니다.
설치는 됐는데 같은 실행이라고 부를 수 없었습니다
워크플로우를 wheel로 묶어 다른 환경에 설치했습니다. 도구를 호출하자 제품 안에서만 성립하던 전제가 드러났습니다. 포장 형식을 두 번 갈아엎으며 무엇을 고정해야 실행이 옮겨가는지 확인한 과정입니다.
저장소를 나눴는데 의존성은 그대로였습니다
엔진을 별도 모듈로 옮겼지만 실행하려면 제품의 설정 객체와 데이터베이스 세션, 캔버스 노드를 먼저 불러와야 했습니다. 독립을 선언한 사흘 뒤부터 누수를 잡으며 배운, 경계가 닫혔는지 확인하는 방법입니다.
재시도 횟수로는 실행을 설명할 수 없었습니다
도구를 세 번 쓴 실행과 품질 검증에 세 번 실패한 실행이 같은 '재시도 3회'로 남았습니다. 생성·검증·도구 실행·재시도를 하나의 반복문에서 꺼내 명시적인 상태와 전이로 나눈 과정입니다.
Engineering 29
DB 도구가 느린 이유는 DB가 아니었다: LLM 왕복 99.8%와 이름 충돌, 방언 등록 구조로 통합
에이전트에 DB 도구를 여러 개 연결하면 일부가 조용히 사라지던 문제를 도구 이름 충돌로 진단해 고치고, 느리다는 제보는 실행 기록 27건에서 시간의 99.8%가 LLM 왕복이라는 사실로 좁혔습니다. 결과 행 상한, 테이블·컬럼 사전 적재, DB 방언 등록 구조로 바꿔 질문당 LLM 호출을 4회에서 2회로 줄였습니다.
온톨로지 엔진의 이식성: 커밋 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가지로 기획을 세운 뒤, 검색 회수를 먼저 재는 프로토콜로 개선안 대부분을 실측으로 걸러 냈습니다.
은행 관리 콘솔 에이전트 온톨로지: 운영 테이블에서 LLM 없이 구성하고 분포로 판정하기
관리자가 300여 개 에이전트와 컬렉션·DB·도구의 관계를 탐색하고 질문할 수 있도록, 문서를 다시 추출하지 않고 운영 테이블에서 에이전트 그래프를 결정론적으로 구성했습니다. 상태 서명 기반 증분, 분포 기반 인사이트 규칙, 그래프 근거 질의, 서버 측 그래프 요약까지 설계 판단과 실측을 정리합니다.
판단 주체가 없는 사전 검색: 규칙 엔진에서 LLM 사전 검색으로, 노드 교체 없이 엔진 전환하기
매 턴 코드가 검색하는 사전 검색 모드가 특정 조항을 못 찾던 원인을 판단 주체의 부재로 정의하고, 규칙 엔진을 거쳐 검색어·폴더 선택만 LLM에 맡기는 구조로 다시 설계했습니다. 엔진은 노드 ID를 바꾸지 않고 관리 설정으로 전환하며, 배포 뒤 드러난 404·스트리밍·마스킹 결함까지 정리했습니다.
jermes-app: PC와 폰을 pod로 연결한 에이전트 런타임과, 클러스터는 세우고 보고는 틀린 5회 실험
XGEN 코드를 고치지 않고 사용자의 PC와 폰을 pod로 연결해 로컬 자원을 도구로 쓰는 에이전트 런타임을 만들었습니다. 같은 k3s 과제를 5회 맡겨 과제 완수 3회, 정확한 보고 0회라는 격차를 계측하고, 한 번의 호출로 끝나는 검증 도구와 파괴적 명령 차단으로 대응했습니다.
시간 상한은 탐색에만, 합성 지연은 스트리밍으로: 근거 누출 사고에서 시작한 검색 지연 재설계
질문당 총시간을 보장하려고 건 25초 하드 상한이 합성 LLM에 4초만 남겨, 내부 근거가 답변으로 새는 사고로 이어졌습니다. 로그와 단계별 계측으로 지연의 대부분이 합성 대기임을 확인하고, 상한은 탐색에만 두고 체감 지연은 합성 입력의 문자 예산과 답변 스트리밍으로 다뤘습니다.
Fuseki 없이 지식 그래프 운영하기: PostgreSQL 테이블 3개로 옮기며 드러난 숨은 결합들
별도 JVM 트리플스토어인 Fuseki는 설정 하나가 어긋나면 그래프 계층 전체가 멈추고 폐쇄망 반입 부담도 컸습니다. 같은 빌드를 두 저장소에 이중 기록해 충실도를 대조한 뒤 Fuseki 쓰기를 기본 비활성화했고, 완료 판정·재시도·카운트·품질 지표에 숨어 있던 Fuseki 전제를 하나씩 걷어내며 검색을 라이브러리로 일원화했습니다.
엑셀 요청이 항상 실패하던 문서 생성 도구: 폴백 대신 계산되는 데이터 시트로 변환하기
LLM이 마크다운으로 넘긴 엑셀 요청이 항상 실패하던 렌더러 분기를 단순 폴백이 아닌 데이터 시트 변환으로 고쳐 숫자·표시형식·틀고정을 살렸습니다. 셀 검색 도구 부재와 반복 한도 계산 오류로 편집이 중단되던 문제, 코드 생성 없이 차트를 그리는 경로도 함께 정리했습니다.
xgen-seepage: 인터넷 없이 설치되는 Excel 에이전트 커넥터와 Office.js를 걷어낸 이유
XGEN 에이전트가 사용자가 열어 둔 Excel 통합문서를 직접 읽고 편집하게 하는 독립 커넥터입니다. Office 애드인 대신 COM 직결과 단일 실행 파일 배포를 택해 폐쇄망 설치를 가능하게 했고, 실제 서버와 실제 Excel에서 검증하며 압축 협상 충돌, 실행 파일의 번들 누락, Office.js 대기 멈춤을 차례로 해결했습니다.
Jermes: 홀드아웃에서 이득이 재현된 절차만 스킬로 승격하는 엔진과, 실측이 찾은 게이트의 구멍들
에이전트 실행 기록에서 재사용 절차를 뽑되, 작성에 쓰지 않은 홀드아웃 케이스에서 이득이 재현될 때만 스킬로 승격하는 자가학습 엔진입니다. dev에서만 오른 스킬의 승격, 1건짜리 홀드아웃, 부호가 뒤집히는 평균 같은 게이트의 구멍을 실측으로 막았고, 실제 XGEN 에이전트 노드의 정답이 0/6에서 6/6이 됐습니다.
'이전 대화가 쌓였습니다'의 오지목: 토큰 예산 계층을 고쳤더니 공유 GPU가 느려진 이유와 원복
'이전 대화가 쌓였다'는 안내만 반복하던 에이전트를 토큰 버킷 로그로 추적해 문구의 오지목, 줄일 수 없던 시스템 프롬프트·도구 스키마, 오히려 텍스트를 늘리던 truncate를 고쳤습니다. 그 수정이 잠들어 있던 압축 경로를 깨워 공유 GPU 지연을 만든 메커니즘을 확인해 원복했고, 재현으로 근본 압력이 검색 결과 크기에 있음을 확인했습니다.
날짜 경계처럼 보인 도구 멈춤의 실체: HWP 파서가 남긴 UTF-16 서로게이트와 보이지 않던 도구 오류
8월 5일 이후 보도자료만 멈추던 에이전트 도구를 첨부 형식별 전수 대조로 추적해, HWP 파서가 한컴 사설 영역 문자를 UTF-16 서로게이트 쌍으로 남겨 UTF-8 인코딩이 실패한 것과 도구 오류 이벤트가 UI로 전달되지 않던 것을 찾았습니다. 서로게이트를 무손실 복원하는 정규화를 발원지와 공통 길목에 적용했습니다.
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월까지 바뀌지 않았습니다.