LLM 에이전트 기반 데이터 품질 검증을 위한 하네스 엔지니어링 방법론: 관찰-검증-종합 기반 에이전트 설계

3.1 하네스 전체 구조

본 연구의 검증 방식은 프롬프트 하나에 완성된 결과를 한 번에 반환하는 일반 LLM 호출과 다르다. 하네스가 제공하는 도구와 환경 위에서 행동과 관찰을 반복하며, 식 (1)과 같이 최종 결과를 생성하는 에이전트 호출을 기반으로 한다.

여기서 M은 추론을 담당하는 LLM이다. 에이전트 호출은 최근 에이전트 기반 개발 도구들이 공통적으로 지원하는 실행 방식을 따르는데, 이들 도구는 명령행 인터페이스(CLI, Command Line Interface)의 비대화형 모드와 전용 SDK를 통한 헤드리스(Headless) 실행을 함께 제공한다. 본 연구는 이를 활용해 에이전트 호출을 단일 호출로 구성하였으며, 이 방식은 데이터셋과 조건의 조합을 사용자의 개입 없이 일괄 실행할 수 있게 한다. 대화형 모드와 달리 실행 중 도구 사용을 사용자에게 확인받을 통로가 없으므로, 어떤 도구를 허용할지는 실행 전 권한 정책으로 미리 확정해 두어야 한다.

하네스 H는 에이전트의 실행 환경을 구성하는 요소들의 결합으로, 식 (2)와 같이 형식화된다.

여기서 T는 에이전트에게 노출되는 도구 집합, C는 실행 시점에 주입되는 컨텍스트이다, P는 도구 및 파일 접근을 규율하는 권한 정책이며, G는 실행 전후의 상태 변화를 기록하는 감사 장치이다. 기존 연구가 주로 C에 집중해 온 것과 달리, 본 연구는 T의 구성과 P·G에 의한 통제를 설계의 중심에 둔다. 그림 1은 이렇게 구성된 하네스의 전체 구조를 나타낸다.

Fig. 1.

Overall architecture of the proposed harness

에이전트가 정답 데이터를 참조하지 않았다는 전제는 검증 결과의 타당성을 좌우하므로 엄격히 보장되어야 한다. 다만 파일 시스템 접근에 제한이 없는 도구는 상대 경로 탐색 등으로 정답 경로에 접근할 수 있어, 물리적 분리만으로는 충분하지 않다. 이에 P·G는 물리적 분리, 샌드박스 파일시스템 읽기 차단, 파일 도구 권한 거부, 실행 전후 스냅샷·로그 기반 사후 감사의 네 가지 통제 수단으로 구성하였다. 앞의 세 수단은 접근을 사전에 차단하고, 사후 감사는 도구 제한이 없는 조건에서도 수행된 연산을 확인할 수 있는 유일한 수단이다. 탐지 결과는 컬럼명·행 인덱스 배열로만 저장되어 평가 절차와 분리된다.

이 하네스 위에서 도구 집합 T를 구성하는 가장 단순한 방식은 에이전트에게 제약 없는 범용 코드 실행 도구 τ_python 하나만을 제공하는 것으로, 식 (3)과 같이 T_code라 정의한다.

τ_python은 파일 시스템·네트워크 접근과 임의 라이브러리 import에 제한이 없는 일반 코드 실행 도구로, 에이전트는 이 도구 하나만으로 데이터 적재부터 결과 저장까지 전 과정을 스스로 작성한 코드로 수행한다. 이는 판단의 유연성을 극대화하는 대신, 연산 과정의 사후 재구성이나 실행마다 상이하게 생성되는 코드의 자원 사용량에 대한 사전 통제 수단은 제공하지 않는다. 실제로 동일한 프롬프트를 반복 입력해도 LLM이 매번 구조가 다른 코드를 생성한다는 점이 보고된 바 있다[16], [17]. 하네스가 도구 집합의 구성 자체를 설계 대상으로 삼아야 하는 이유가 여기에 있다.

3.2 관찰-검증-종합 3단계 도구 체계

본 절은 식 (3)의 T_code가 지닌 문제를 해결하기 위해, 판단은 LLM이 수행하되 계산과 검증은 결정론적 도구에 위임한다는 원칙 아래 도구 집합을 관찰·검증·종합의 세 역할로 분리한다. LLM이 수치를 직접 집계하면 환각이 혼입될 수 있으므로 모든 수치 산출은 도구가 전담하고 LLM은 해석과 다음 행동 결정만 담당하도록 하였으며, 이에 따라 제안 방법의 도구 구성은 식 (4)와 같이 정의된다.

여기서 τ_o는 결함 후보를 형성하는 관찰 도구군, τ_v는 후보를 결함으로 확정하는 검증 도구군, τ_pandas는 명명 도구로 표현되지 않는 연산을 위한 종합 도구이다.

관찰 도구가 적으면 포착 가능한 패턴이 좁아져 탐지 성능이 저하되고, 도구가 다양할수록 탐지 정확도가 높아지는 경향이 있다. 다만 데이터셋 특화 도구는 성능을 더 끌어올릴 수 있으나, 적합한 도구를 매번 설계해야 하는 비용을 초래한다. 이에 본 연구는 pandas 데이터프레임에 보편적으로 적용 가능한 list_columns, sample, value_counts, describe, null_ratio, dtype, correlate, cardinality_ratio의 8종만으로 τo를 구성하였다. 이들은 모두 요약 통계만 반환하도록 설계되어 응답 크기가 데이터 규모와 무관하게 일정하다. 이는 고카디널리티 컬럼을 원형 그대로 직렬화하면 컨텍스트가 급격히 팽창하고 구조 이해 성능도 저하된다는 선행 연구[18], [19]와, 이것이 LLM 기반 오류 탐지의 주요 병목으로 지적되어 온 점[20], [21]을 반영한 설계이다.

τ_o가 자체 구현 도구로 구성된 것과 달리, τ_v는 검증 결과가 결함 확정이라는 최종 판단으로 직결되어 계산 로직의 정확성이 신뢰성을 좌우한다. 따라서 직접 구현 대신 산업계에서 광범위하게 검증된 오픈소스 프레임워크 GX Core의 표현식(Expectation)을 사용한다(고유성 8종, 수치 13종, 유효성 15종, 완결성 2종, 스키마 7종, 규모 3종, 다중원천 2종 등 총 50종의 expect 계열 규칙제공). 다만 GX Core는 기본 설정이 위반 행 인덱스를 반환하지 않아 완전 반환 모드로 강제하였으며, 이때도 표시되는 위반 행 수에는 50건 상한이 존재해 후술할 종합 단계 발생의 구조적 원인이 된다.

τ_pandas는 run_pandas_code 하나로 구성된, τ_python과 유사하지만 동일하지 않은 코드 실행 도구이다. 실행 환경은 pandas, numpy, 이미 적재된 공유 데이터프레임만 참조하도록 제한되고 허용된 빌트인 함수 목록 밖의 호출(파일 열기, 모듈 import, 네트워크 접근 등)은 차단되며, 반환값은 2,000자로 절단되고 명명 도구를 먼저 시도하고 표현이 안 되는 사소한 경우에만 사용하라는 사용 우선순위가 명시되어 있다. τ_o, τ_v는 검증된 관찰·검증 로직을 구조화해 제공하므로, 표현력의 상한이 낮더라도 실제 도달 성능은 오히려 더 높고 안정적일 수 있다.

τ_o, τ_v, τ_pandas는 모두 함수의 집합으로, 각 단계의 입력은 호출할 함수명과 파라미터이고 출력은 해당 함수의 출력값이다. 예를 들어 Beers 데이터셋의 state 컬럼을 검증하는 과정을 보면, 관찰 τ_o 단계는 value_counts(column="state")를 호출해 결측치 비율을 반환값으로 받고, 이를 근거로 state를 검증 후보로 지목한다. 검증 τ_v 단계는 expect_column_values_to_not_be_null(column="state")을 호출해 결측 행의 인덱스 목록을 반환값으로 받는다. 종합(τ_pandas) 단계는 이 인덱스를 반영한 교차 컬럼을 검사하는 코드를 입력받아 실행하고, 결측이 정보 손실이 아닌 통합 표기임을 판정한 결과를 출력한다.

종합(τ_pandas) 단계가 분화되는 근본 이유는 τ_o, τ_v가 고정된 도구로만 구성되어, 목록에 없는 오류 유형은 애초에 다룰 수 없기 때문이다. 이 경우 에이전트는 관찰 단계의 단서를 τ_pandas로 직접 재구성해야 한다. 검증 도구의 위반 행 표시 상한도, 상한을 초과하는 컬럼에서는 τ_v가 결함의 존재와 총 건수만 확정하고 전체 위반 행 목록은 τ_pandas로 별도 산출해야 한다. 이는 저비용 요약으로 먼저 선별하고 확정된 컬럼에만 전체 목록 조회 비용이 발생하도록 강제한다는 점에서 효율적이다. 다만 종합 단계의 τ_pandas 호출은 새 판단이 아니라 이미 확정된 판단을 산출물로 조립하는 경우가 많기 때문에 자유 코드 의존과는 구분해서 해석해야 한다.

실행 도구 궤적에 대한 특성을 정량화하기 위하여 두 지표를 정의한다. 길이 K의 도구 호출 시, 관찰 대 검증 호출 비율 ρ_obs는 식 (5)로, 관찰 대비 종합 호출 비율 ρ_free는 식 (6)으로 정의된다.

여기서 지시 함수 Π(⋅)는 참이면 1, 거짓이면 0을 갖는다. 두 지표는 판단과 직접 관련된 호출만을 대상으로 하며, load_dataset처럼 판단과 무관한 호출은 분모·분자 어디에도 포함하지 않아 재적재가 지표를 희석시키지 않는다. 같은 이유로 분모도 전체 호출 수 K가 아니라 비교 대상 두 범주의 호출 수로 한정하였다. 두 지표가 포착하려는 것은 전체 실행에서의 절대적 비중이 아니라 인접 단계 사이의 상대적 무게이기 때문이며, 이 논리에서 ρ_obs의 역수에 해당하는 검증 대비 관찰 비율은 별도로 정의하지 않았다. ρ_obs는 결함 확정까지의 탐색 폭을, ρ_free는 명명 도구 카탈로그가 해당 데이터셋의 결함을 얼마나 충분히 표현하는지를 반영한다.

4.1 실험 데이터셋

실험은 오류 탐지 연구에서 널리 사용되는 4개 벤치마크 데이터셋을 대상으로 수행하였다. 각 데이터셋의 구성과 주된 오류 유형은 표 1과 같다. 네 데이터셋은 모두 셀 단위 정답을 제공하며, 선행 연구[2], [15]가 공통으로 사용한 벤치마크이다. 이 중 일부 데이터셋은 식별자 컬럼이 실제 행 위치보다 1만큼 큰 값을 가지는데, 이러한 불일치는 탐지 결과 전체를 무효화할 수 있으므로 하네스의 결과 파서가 정규식으로 0 기반 행 위치만을 추출하도록 하여 정규화하였다.

Table 1.

Composition of experimental datasets

실험은 모든 조건에서 컨텍스트를 동일하게 고정하여, 조건 간 차이가 컨텍스트 정보량이 아니라 도구 구성 및 모델 역량에서 기인하도록 통제하였다. 컨텍스트에는 결측을 나타내는 관용적 표기(null/NaN, N/A, Not Available, Contact Airline 등)를 결측으로 인식할 것과, 무게·크기 등 숫자형 컬럼은 통상 단위 없이 사용된다는 것이라는 두 가지 일반 규칙을 포함하였다. 아울러 주입된 결측 오류 비율이 높았던 Beers(state), Flights(sched_dep_time, act_dep_time, sched_arr_time, act_arr_time), Rayyan(article_jvolumn, article_jissue)에는 결측을 허용하지 않는다고 명시하였다.

이러한 컨텍스트 위에서, 실험은 세 조건으로 구성하였다. T_code·T_ovs 실험에서는 Sonnet 5(high 추론)으로 모델 요인을 통제하였고, 모델 규모 비교 실험에서는 Haiku 4.5·Opus 5(high 추론)를 사용하였다.

4.2 자유 코드 실행 조건 실험(T_code)

T_code 조건은 도구 제한이 없는, 자유도가 가장 높은 대조군이다. 이 조건에서 에이전트는 사전에 정의된 절차 없이 관찰과 가설 생성, 검증으로 이어지는 순환 루프를 스스로 구성하였다.

표 2는 5회 실행한 결과의 평균 탐지 성능과 표준편차를 나타낸다. Hospital과 Beers는 각각 F1 0.994와 0.946으로 높은 성능을 보였으며, 표준편차도 각각 0.008과 0.043으로 낮아 안정적인 결과를 보였다. 반면 Flights와 Rayyan은 F1이 각각 0.622와 0.184로 낮았으며, 특히 Flights는 표준편차가 0.250으로 높아 실행에 따른 성능 변동이 크게 나타났다.

Table 2.

Detection performance of the Tcode condition by dataset

Beers에서 관측된 오탐은 abv 컬럼과 style 컬럼에서 발생하였다. 두 컬럼은 단위 표기나 서식이 다양하게 변형되어 나타나는 특성을 지니며, τ_python이 이 서식 변형 전반을 결함으로 과잉 일반화한 것으로 해석된다. τ_python에는 판단을 최종 결과로 확정하기 전에 걸러 낼 검증 절차가 없으므로, 판단의 유연성으로 인해 오탐이 곧바로 유입된다.

생성된 τ_python의 실행 통계를 살펴보면, 4개 데이터셋에서 Hospital 19회, Beers 13회, Flights 11회, Rayyan 11회씩 총 54회의 코드 실행이 발생하였고, 이 중 실패는 Hospital·Beers·Rayyan에서 각 1건씩 총 3건이다. 3건 모두 콘솔 문자 인코딩에 기인한 환경 문제였으며, 판단 로직의 오류로 인한 실패는 한 건도 없었다. 즉 τ_python이 생성한 판단 로직 자체는 신뢰할 수 있었으며, 문제로 남는 것은 로직의 정확성보다 앞서 확인한 오탐의 유입 쪽이었다.

τ_python 코드를 분석하면 대체로 네 단계를 거친다. 컬럼별 프로파일링으로 이상 신호를 먼저 포착한 뒤 정규식이나 허용값 목록으로 기대 형식의 위반을 검증한다. 이어서 같은 대상을 나타내는 행들을 묶어, 다수결에서 벗어난 소수값을 이상값 후보로 찾아낸다. 마지막으로 대표 사례를 직접 대조하여 근본 원인을 역추적한 뒤 전체 데이터에 재검증한다. 이 절차는 제안 방법의 관찰-검증-종합 구조와 기능적으로 대응하나, 각 단계가 명명된 도구가 아니라 매 실행마다 새로 작성되는 코드로 구현된다는 점에서 구별된다.

새성된 코드를 분석하면 Hospital은 함수 종속성 교차검증에 반복문 기반 이중 순회를 12개 컬럼에 적용했고, Beers는 행 단위 함수와 정규식을 결합한 비벡터화 패턴을 6개 호출에서 사용해 세션 내 최장 실행 시간을 기록했으며, Rayyan은 문자 인코딩 오염 탐지에 문자 단위 순회를 사용했다. 현재 규모에서는 모든 호출이 수 초 내 종료되어 체감 문제는 없었으나, 이는 T_code 조건에서 자원 사용량을 사전에 예측·통제할 수단이 없음을 보여준다.

4.3 하네스 구조 조건 실험(T_ovs)

이번 실험에서는 3.2절에서 정의한 관찰·검증·종합 도구 체계 T_ovs를 적용하였다(표 3). Hospital(F1 0.998, 표준편차 0.002)과 Beers(F1 0.995, 표준편차 0.008)는 매우 높은 탐지 성능과 안정성을 보였다. Flights는 F1 0.730이었으나 재현율이 5회 모두 0.583으로 완전히 동일해 구조적 병목의 존재를 시사했고, Rayyan은 F1 0.171, 표준편차 0.057로 네 데이터셋 중 가장 낮고 불안정했다.

Table 3.

Detection performance of the Tovs condition by dataset

컬럼 단위로 오류 원인을 보면 주로 세 가지 원인으로 분류된다. 첫째, 값이 다른 그럴듯한 값으로 바꿔치기되어 원본과 대조하지 않는 한 원칙적으로 탐지가 불가능한 오류다. Flights의 act_arr/dep_time은 비결측 오류의 85~88%가 이런 형태(예: 9:32 a.m.→9:22 a.m.)여서 재현율이 0.39·0.33에 그쳤다. 전체 주입 오류 948건 중 article_jcreated_at(월/일 순서 뒤바뀜, 예: 2/15/04→4/2/15) 컬럼이 722건(76.2%)을 차지하였다. 둘째, 컨텍스트에 결측이면 안 됨으로 명시된 컬럼은 결측형 오류를 거의 완벽하게 탐지한 반면, 명시되지 않은 컬럼(Beers의 city, Rayyan의 mojibake 오염 3개 컬럼)은 별도 지침 없이 스스로 식별해야 해 탐지가 불완전했다. 이 중 Rayyan의 author_list는 전체 오류의 8.9%를 차지함에도 재현율 손실이 두드러졌다. 셋째, 정밀도 손실은 대부분 원본에 이미 존재하던 비표준 값을 정당하게 의심했으나 주입된 오류만 정답으로 인정한 평가 기준의 한계에 가까웠다. Flights의 src(항공사 코드 vs 사이트명 형식 혼재)와 Rayyan의 journal_issn·article_language가 대표적이다.

Rayyan에서는 article_jcreated_at, author_list, article_jissue가 전체 오류의 대부분을 차지하였다. Rayyan은 실행 5회 기준 표준편차(0.057)가 크게 나타나 10회로 표본을 늘려 재계산(0.048) 후, 편차의 원인을 컬럼별로 분석하였다. auth_list는 오류 후보를 찾는 규칙 자체는 동일했지만, 후보를 원본 데이터와 대조해 오류 여부를 재검증했는지에 따라 재현률이 0%에서 70%대로 양극화되며 F1을 크게 좌우했다. 반면 article_jissue 같은 수치형 컬럼은 재현률이 항상 100%였지만, 판정 허용폭이 좁고 넓음에 따라 후보 집합이 포함관계로 확장되면서 정밀도만 0.1~1.0 사이로 요동쳤다.

오류 패턴이 단순하고 균일한 Hospital·Beers는 매 실행 동일한 범위가 일관되게 검증되어 표준편차가 0.002~0.008에 그친 것과 대조적이다.

도구 호출 로그를 분류하여 산출한 궤적 지표는 표 4에 요약하였다. τ_ovs는 1.14에서 8.50까지 데이터셋마다 큰 폭으로 나타났다. τ_v 호출이 τ_o 호출보다 많아지면 얼마든지 1 미만이 될 수 있다. 관찰은 전 컬럼에 넓게, 검증은 좁혀진 소수 컬럼에만 적용되는 패턴이 네 데이터셋 모두에서 공통적으로 나타났다. 두 지표는 데이터셋에 따라서도 뚜렷한 차이를 보인다. Hospital은 τ_ovs가 1.14로 가장 낮고 τ_free도 0.11로 최저인데, 정규식 위반과 결측 규칙만으로 판단이 대부분 종결되어 τ_v 호출이 58회에 이른 결과다. 반대로 Rayyan은 τ_v 호출이 2회에 불과하고 τ_free가 1.29로 가장 높다. 문자 인코딩 오염이나 날짜 회전 오염과 같이 검증 도구 카탈로그로 직접 표현하기 어려운 오류 유형이 다수를 차지하여, 관찰에서 얻은 단서를 τ_pandas로 재구성하여야 하였기 때문으로 해석된다. Beers 역시 τ_free가 1.03으로 높은데, 필드 병합 오류의 위반 행을 확정하는 과정에서 τ_pandas 호출이 반복되었기 때문이다.

Table 4.

Tool-call trajectories of the proposed method by dataset

그림 2는 Beers 데이터셋의 도구 호출 타임라인으로, 세로축은 호출 순번이고 가로축은 도구 범주이다. τ_o는 실행 초반에 밀집하여 전 컬럼을 광범위하게 조사하는 반면, τ_v는 실행 후반에 소수의 군집으로 나타나 관찰로 좁혀진 컬럼에만 선택적으로 적용된다. 아울러 τ_pandas 호출이 데이터 적재 호출과 쌍을 이루어 반복적으로 등장하는 것은, τ_pandas 실행 전마다 데이터프레임을 다시 적재하는 방식이 일관되게 나타나기 때문이다.

Fig. 2.

Tool-call timeline for the Beers dataset

다만 τ_pandas 개입이 모두 카탈로그 표현력 부족 때문인 것은 아니다. 세부적으로 컬럼 단위로 분석하면 Beers의 state는 다른 컬럼에서 이미 쓰인 expect_column_values_to_not_be_null을 호출하지 않고 τ_pandas의 isna() 판단으로 대체되었고, Rayyan의 article_title·journal_title·author_list는 해당 오류 유형을 다룰 τ_v 표현식이 카탈로그에 없어 τ_pandas가 판단을 전담하였다.

4.4 모델 규모 비교 실험

마지막 비교 실험은 모델만 교체해 남은 성능 격차가 도구 설계가 아니라 모델 역량에서 비롯되는지를 표 5에서 확인할 수 있다.

Table 5.

Detection performance by model(F1)

Haiku 4.5는 Hospital·Beers에서 급격히 저하됐으나(F1 0.095, 0.728), Sonnet 5에서 0.998, 0.995로 회복되어 컨텍스트 반영 능력의 한계로 해석된다. Flights는 F1이 규모에 비례해 개선되었으나(0.647→0.730→0.886), act_arr/dep_time의 분단위 오탈자는 도구 카탈로그의 표현력 한계로 규모와 무관하게 잔존하였다. Rayyan은 Opus 5로 갈수록 재현율은 개선되나(0.071→0.203) 정밀도가 하락하는데, 원본의 비표준 값을 오탐 처리하는 평가 기준의 한계에 가깝다. 정리하면, 모델 규모 확대는 컨텍스트 반영 능력 부족(Hospital, Beers)은 해소하지만, 도구 카탈로그 표현력(Flights)이나 평가 기준(Rayyan)의 병목은 해소하지 못한다.