표 QA는 대모델이 읽게 할까, 코드가 계산하게 할까?
계산할 수 있는 것은 코드에 맡기고, 설명할 수 있는 것은 모델에 맡긴다. 단 전제는 필드, 단위, 통계 기준을 먼저 통일하는 것이다.
1층 입력 정규화 (표 헤더, 단위, 날짜, 결측값, 소수 자릿수. 시스템이 받는 것이 깨끗한 입력인지를 결정)
2층 계산 경계 (합계, 정렬, 전년 대비, 전기 대비, 임계값 판정은 일률적으로 코드에 맡기고 모델에게 현장에서 암산시키지 말 것)
3층 답변 기준 (월간/분기/추정치/최종치 등 다중 기준을 답변에서 명확히 밝혀야 하며, 이 층이 답변을 상용에 올릴 수 있는지를 결정)
네 종류의 이상
- 필드 결손 — 표 구조가 불완전
- 버전 충돌 — 같은 데이터에 여러 버전이 존재
- 만료 상태 — 데이터가 이미 실효
- 권한 변화 — 주체에 따라 가시 범위가 달라짐
입력 정규화 (가장 무서운 것은 표를 못 읽는 게 아니라 읽고서 잘못 계산하는 것)
- 핵심 판단: 표 QA에서 가장 무서운 것은 표를 인식하지 못하는 것이 아니라 표를 이해하고서 잘못 계산하는 것이다
- 정규화할 5항: 표 헤더, 단위, 날짜, 결측값, 소수 자릿수 — 정규화한 뒤에야 모델은 각 열이 도대체 무엇을 나타내는지 알 수 있다
- 이 단계의 의미: 시스템이 받는 것이 깨끗한 입력인지를 결정한다
- 가점 포인트: 모델 성능만 말하지 말고 세 가지 경계를 보충할 것 — 입력 경계, 상태 경계, 버전 경계
- 반면 경고: 이 층이 빠지면 뒤의 리랭크든 도구 호출이든 프롬프트 최적화든 전부 더러운 입력 위에 포장을 씌우는 것일 뿐이다
- 보존해야 할 세 가지
- 원시 데이터 — 소스 데이터로 역추적 가능
- 처리 후의 구조 필드 — 정규화가 무엇을 했는지 설명
- 최종 선택 이유 — 왜 이 답을 냈는지 설명
계산 경계 (코드에 맡길 것인가 모델에 맡길 것인가)
- 코드가 실행할 것
- 합계 / 정렬
- 전년 대비 / 전기 대비
- 임계값 판정
- 모델이 담당할 것
- 명시적 금지
반드시 기록할 3항: 후보 결과, 필터링 사유, 최종 선택 — 이 세 가지가 있어야 나중에 도대체 소환, 계획, 실행, 생성 중 어디서 문제가 났는지 위치를 특정할 수 있다.
평가: 기준을 측정 가능한 지표로 쪼개기
- 성공률 — 종단간 정상 완료 비율
- 지연 — 응답 소요
- 사람 개입 — 사람이 인수해야 하는 비율
- 롤백 횟수 — 오류 후 되돌리는 빈도
- 이상 샘플 비율 — 경계/이상 입력의 비율
핵심 통찰
- 「읽기」와 「계산하기」는 서로 다른 두 능력이며 섞어 쓰면 틀린다 — 모델은 의미 이해와 설명에 능하고 코드는 결정론적 연산에 능하다. 표 QA가 좋은 문제인 이유는 이 두 능력선을 동시에 압박해 경계를 명시적으로 나누게 만들기 때문이다. 이식 가능한 원칙: 결정론적 알고리즘이 있는 모든 하위 작업은 생성 모델이 맡아서는 안 된다.
- 정밀도 문제의 근원은 대개 입력층에 있지 모델층에 있지 않다 — 표 헤더가 모호하고, 단위가 통일되지 않고, 결측값의 의미가 불명확하고, 소수 자릿수가 제각각이면 뒤의 모든 최적화(리랭크, 도구 호출, 프롬프트)가 「더러운 입력 위에 포장을 씌우는 것」으로 전락한다. Prompt를 조정하기 전에 입력 계약부터 볼 것.
- 기준은 데이터 품질 문제가 아니라 의미 모호성 문제다 — 월간, 분기, 추정치, 최종치가 전부 올바른 숫자일 수 있고, 충돌하는 것은 「당신이 어떤 질문에 답하고 있는가」다. 그래서 답변에는 반드시 기준을 명시적으로 선언해야 하며, 그러지 않으면 「전부 맞는 것처럼 보이는 결론」이 환각의 온상이 된다.
- 「맞아 보이는 것」 ≠ 「상용에 올릴 수 있는 것」 — 통과 판정 기준은 마지막 문장이 그럴듯한지가 아니라 중간의 증거, 상태, 지표, 이상이 기록되었는지다. 중간 상태 기록이 없는 정답은 재현 불가능한 정답이다.
- 세 가지 증거가 복기 능력을 결정한다: 원시 증거, 처리 후의 구조 필드, 최종 선택 이유. 어느 하나가 빠지면 상용에서 문제가 생겼을 때 추측할 수밖에 없다. 이는 모든 Agent 시스템에 공통이다 — 설명 가능성은 모델의 능력이 아니라 기록의 설계다.
- 오류 위치 특정에는 계층별 귀인이 필요하다 — 후보 결과, 필터링 사유, 최종 선택을 기록해야 장애를 「소환 / 계획 / 실행 / 생성」 중 어느 고리로 귀속시킬 수 있다. 계층이 없으면 모든 버그가 「모델이 별로다」로 퇴화한다.
- 평가는 「그럴듯한가」에서 「다차원 측정 가능」으로 업그레이드해야 한다 — 성공률, 지연, 사람 개입, 롤백 횟수, 이상 샘플 비율. 이 다섯 지표가 경험 문제를 공학 문제로 바꾼다. 측정 가능해야만 지속적 개선을 논할 수 있다.
- 강등은 방안 완전성의 표지다 — 리스크가 높으면 강등하고, 증거가 부족하면 되묻고, 상태가 불확실하면 조회하거나 보상한다. 강등을 능동적으로 말할 수 있다는 것은 「실패하면 어떻게 하나」를 생각해봤다는 뜻이지 happy path만 생각한 것이 아니라는 뜻이다.
- 기준은 프롬프트가 아니라 평가 케이스에 써넣을 것 — 프롬프트는 쉽게 변하고 검증되지 않지만 평가 케이스는 실행 가능하고 회귀를 막을 수 있다. 규칙의 올바른 착지점은 테스트지 문구가 아니다.
엔지니어링 실전 Tips
- 「이 열이 무엇인가」를 먼저 묻고 「이 문제를 어떻게 답할까」를 나중에 물을 것: 정규화의 목적이 바로 각 열이 무엇을 나타내는지 모델이 알게 하는 것이며, 이 단계는 생략할 수 없다.
- 전년 대비/전기 대비, 임계값 판정에서 은밀한 오류가 가장 잘 난다: 모델이 「계산해낼 수는 있지만 맞다는 보장이 없는」 전형적인 「할 줄 아는 것처럼 보이지만 신뢰할 수 없는」 구간이므로 반드시 코드로 내려야 한다.
- 후보 결과를 저장하지 않으면 정렬 최적화를 논할 수 없다: 후보와 필터링 사유를 기록해야 제대로 정렬한 것인지 노이즈를 끌어올린 것인지 알 수 있다.
- 「마지막 한 문장이 맞는가」를 검수 기준으로 쓰지 말 것: 그것은 「찍어서 맞힌」 구현에 보상을 주고 링크의 결함을 덮어버린다.
- 기준이 다른 필드를 그대로 더하는 것이 최고빈도 사고다: 데이터층에서 교차 기준 집계를 차단해야지 Prompt로 모델에게 주의를 주면 안 된다.
- 답변의 4단 구조: 입력 정규화 → 계산 경계 → 답변 기준 → 평가와 강등. 앞의 세 단이면 기본 합격이고, 네 번째 단(모니터링, 복기, 평가 케이스)을 보충할 수 있어야 상용 경험이 드러난다.
- 「마무리는 기록이다」라는 말을 답변에 넣을 것: 관측성을 사후 패치가 아니라 프로세스의 고정 고리로 여긴다는 것을 한 마디로 보여준다.