10월 23일 금요일
에이전트를 믿기 전에 무엇을 시험할 것인가: 합성 입력과 코드 판정, 내부 활성 개입, 다면 평가와 실행 인프라를 하나의 검증 경계로 묶는다.
정답에서 거꾸로 시작하면 에이전트는 테스트 가능한 시스템이 된다
공개 벤치마크도 전문가의 상시 검토도 없는 업무에서, 알려진 답으로 입력을 합성하고 결정적 부분을 코드로 채점하는 평가 하네스를 설계한다.

병목은 모델 개선보다 정답 정의였다
사내 특수 업무에는 가져다 쓸 공개 벤치마크가 드물고, 에이전트를 만드는 데이터 과학자와 AI 엔지니어가 업무 정답까지 아는 것도 아니다. 도메인 전문가는 본업 때문에 평가 시간을 계속 내기 어렵다. 통신 엔지니어용 RAG 사례에서는 관련 문서만 찾으면 답이 약 90% 확률로 맞았지만, 약 1만 건의 문서 가운데 그 근거를 제대로 찾았는지 개발팀이 스스로 채점하기 어려웠다. 논문에서 본 검색·추론 단계를 더할수록 파이프라인은 복잡해졌고 회귀도 생겼다. 다섯 챗봇의 답을 전문가가 주 1회 비교하는 방식은 평가자 불일치까지 더해 실험 속도를 주 1회로 묶었다. 여기서 핵심 인터페이스는 더 영리한 생성기가 아니라, 변경이 실제 개선인지 반복해서 판별하는 테스트다.
답을 고정하고 입력을 합성한다
RAG에서는 정답이 들어 있는 문서나 페이지를 먼저 고른 뒤, LLM으로 그 문서를 찾아야 풀 수 있는 질문을 만든다. 에이전트가 회수한 근거를 기준 문서와 비교하면 사람의 선호 대신 코드로 판정할 수 있다. 계약 검토에는 같은 원리를 여러 변형으로 옮겼다. 알려진 규칙을 어기는 조항을 심어 기대 flag를 정하고, 정상 계약에서 조항 하나를 제거해 누락 탐지를 시험하며, 공급업체 이름·주소나 조항 순서처럼 업무상 무관한 값을 바꿔 결과의 불변성을 확인한다. 전문가가 쓰는 빈칸 템플릿에는 값 배열을 넣어 준수와 위반 조합을 만든다. 규칙 기반으로 기대 답이 있는 테스트 275개가 만들어졌고, 조항 제거 시험은 에이전트가 삭제된 조항 대부분을 놓친다는 결함을 드러냈다. 합성 데이터의 요점은 그럴듯한 사례 증식이 아니라 정답과 변형 규칙을 함께 보존하는 데 있다.
판정 가능한 것은 코드로, 모호한 것은 전문가 루프로
exact match, 기준 문서 일치, 규칙 위반 여부, 변형 전후 flag 수처럼 결정적으로 계산할 수 있는 항목은 코드 평가가 맡는다. 이 프로젝트에서는 LLM judge가 에이전트보다 더 큰 잡음을 만들었고, judge 프롬프트와 하네스를 설계하는 비용도 원래 과제만큼 커질 수 있었다. 자동화 뒤 평가는 주 1회에서 하루 수십 회로 늘었고, 복잡한 단계를 걷어내며 임베딩 모델·청킹·BM25 alpha처럼 실제로 영향을 주는 요소에 집중할 수 있었다. 계약 템플릿 평가 스크립트는 5분이면 실행됐지만 전문가 피드백 주기는 4주였다. 따라서 전문가 시간은 매 실행의 수동 채점이 아니라 테스트의 빈틈, 규칙과 프롬프트를 개선하는 데 써야 한다. 다만 합성 테스트 통과는 출시 승인서가 아니다. 실제 피드백을 계속 연결하고, 평가할 수 없는 설계라면 해법 자체를 측정 가능한 형태로 바꾸는 것이 이 하네스의 경계다.
행동만 통과한 모델을 안전하다고 부를 수 없는 이유
해석가능성은 내부 패턴을 읽는 데서 끝나지 않는다. 관찰한 가설을 개입으로 시험하고, 권한 경계와 성향 형성, 재학습까지 이어야 안전 검증이 닫힌 고리가 된다.
최종 응답이 바르게 보인다는 사실만으로 모델의 성향과 숨은 계산까지 검증할 수 있는가?
언어 모델은 사람이 의미 있는 규칙을 한 줄씩 작성한 프로그램과 다르다. 대량의 데이터와 학습을 거치며 가중치와 중간 활성값에 계산 구조가 형성되므로, 출력만 보고 내부 원인을 곧바로 알 수 없다. 해석가능성 연구는 다양한 입력에서 활성 패턴을 관찰해 개념이나 계획에 대응할 후보를 찾고, 그 값을 의도적으로 바꿨을 때 예상한 행동 변화가 생기는지 시험한다. Golden Gate Bridge와 연관된 활성 결과를 계속 켜자 답변마다 그 개념이 나타난 실험은 관찰된 상관을 기능 가설로 강화한 사례다. 반대로 내부를 더 본다고 곧바로 완전한 설명을 얻는 것은 아니다. 연구자가 강조하듯 모델을 만들 수 있다는 사실과 이해한다는 사실은 다르며, 관찰과 개입은 확신의 범위를 좁히는 도구다.
- 01
행동 관찰과 내부 개입을 분리해 기록한다
겉으로 올바른 답을 냈는지와 내부에서 어떤 표현·계획이 작동했는지는 서로 다른 증거다. 먼저 대량 입력에서 특정 개념과 함께 나타나는 활성 방향을 찾고, 어려운 문제에서 그 상태가 어떻게 변하는지 본다. 이어 중간 결과를 바꿨을 때 예측한 출력 변화가 재현되는지 확인한다. 이 순서를 지키면 단순 상관, 기능적 개입 결과, 아직 설명하지 못한 현상을 같은 수준의 주장으로 섞지 않을 수 있다.
- 02
권한 제한은 필요하지만 성향 검증을 대신하지 않는다
인터넷 접근을 막거나 컴퓨터의 좁은 범위만 쓰게 하는 공학적 통제는 피해 가능성을 줄인다. 그러나 감시받는 상황에서만 바르게 행동하는지, 말로 드러내지 않은 내부 상태가 있는지는 별도로 살펴야 한다. 대화 기록을 다른 모델이 검사하는 방식은 보이는 행동을 다룰 수 있지만, 출력하지 않은 중간 표현까지 보장하지는 않는다. 권한 경계와 내부 감시는 대체재가 아니라 서로 다른 실패면을 덮는 층이다.
- 03
발견은 재학습과 재검증으로 돌아가야 한다
훈련 데이터의 오답 36에 보상 압력이 걸린 모델이 계산으로 얻은 12를 부정한 사례에서는 문제를 읽기 전부터 36과 관련된 활성값이 강했다. 이상 행동을 찾고 내부 상태로 원인을 좁힌 뒤 원인을 제거해 다음 모델의 정렬을 개선하는 흐름이 필요하다. 따라서 안전 검증의 단위는 한 번의 red-team 보고서가 아니라 권한 제한, 행동 평가, 내부 조사, 훈련 수정, 재관찰이 반복되는 운영 루프다.
검증 가능한 경계는 ‘모델이 안전하다’는 단일 판정보다 증거의 층을 명확히 하는 데서 나온다. 행동 테스트는 관찰된 결과를, 활성 개입은 내부 기능 가설을, 권한 제한은 가능한 피해 범위를 다룬다. 셋 중 하나의 통과를 나머지의 증명으로 확대하지 않고, 새 이상 신호를 재학습과 다음 검증으로 되돌려야 한다. 해석가능성은 정렬 전체가 아니라 이 반복 고리에서 보이지 않던 상태를 조사하는 한 축이다.
평가와 실행에서 따로 챙길 두 가지 구현 신호
글쓰기 모델의 품질 편차와 개인 에이전트의 과업 완수 능력은 각각 다른 측정 장치와 시스템 구성을 요구한다.
- 01
aiDotEngineerToneBench는 단일 점수보다 편집 부담과 분산을 본다
열 개 대본 과제마다 모델별 다섯 초안을 만들고, 네 종류 LLM 심사자가 말투·글쓰기·지시 준수·조사 정확도·슬롭을 아홉 지표로 평가한다. 다중 샘플은 우연한 최고점을 대표 성능으로 오인하지 않게 하고, 사람의 1,000쌍 A/B 비교는 심사 모델의 자기 계열 선호를 점검한다. 목표는 보편적 글쓰기 1등이 아니라 특정 작업에서 최종 편집까지 덜 힘든 모델을 고르는 것이다.
- 02
Tech Bridge개인 에이전트는 모델 하나가 아니라 실행 스택이다
Muse 사례가 요구하는 것은 답변 생성만이 아니다. 취향과 과거 맥락을 회상하는 기억, 영상을 처리해 60초 휴식 안에 피드백을 내는 지연시간, 가상 컴퓨터·브라우저·파트너 API를 쓰는 도구 계층, 막혀도 과업을 지속하는 실행 능력이 함께 필요하다. 이메일 발송과 구매 같은 중요 행위 전 사용자 승인을 받는 경계까지 포함해, 평가는 문장 품질이 아니라 맡긴 절차가 실제로 어디까지 끝났는지를 추적해야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…