실사나 시장 분석에서 숫자를 찾는 일보다 더 어려운 순간이 있다. 숫자는 찾았는데, 검토자가 그 숫자를 다시 확인할 수 없는 경우다.
출처가 "식약처"라고만 적혀 있고 직접 링크는 없다. 표에는 숫자가 들어갔지만 단위와 기준 시점이 각주에 없다. 서로 다른 자료에서 값이 다르게 나오는데도 차이의 원인은 기록되지 않았다. 숫자가 맞더라도 이런 결과물은 FDD 보고서나 의사결정 자료에 쓰기 어렵다.
이번 2주차 학습에서는 제가 사용하던 official-statistics-research Skill을 분석했다. 처음에는 기존 Skill에 전달 절차를 조금 더 보강하면 된다고 생각했다. 작업을 나눠 보니 문제는 문구 몇 줄이 아니었다. "숫자가 맞는가"와 "검토자가 숫자를 추적할 수 있는가"는 서로 다른 책임이었다.
## 하나의 큰 Skill에 두 가지 실패가 섞여 있었다
기존 Skill은 통계 질문을 정의한 뒤 공식 출처를 찾고, 수치와 메타데이터를 검증하고, 상충하는 계열을 조정해 Excel·PPT·메모로 전달하는 구조였다.
```text
통계 질문 정의
→ 공식 출처 탐색
→ 수치·메타데이터 검증
→ 상충 계열 조정
→ 의사결정용 산출물 작성
```
겉으로는 자연스러운 흐름이다. 하지만 실패 원인을 따져보니 앞부분과 뒷부분의 검사 기준이 달랐다.
공식통계 검증 단계에서는 범위, 단위, 기간, 분류체계, 잠정·확정 여부와 원출처를 확인해야 한다. 반면 전달 단계에서는 직접 URL, 각주, caveat, discrepancy log가 실제 검토 화면에서 보이는지 확인해야 한다.
고치는 방법도 다르다. 수치가 잘못되면 원자료를 다시 조회하고 계열을 재조정해야 한다. 링크나 각주가 빠졌다면 표와 보고서 구조를 고쳐야 한다. 이 둘을 한 책임으로 묶어 두면 실패가 발생했을 때 어디로 돌려보내야 할지 모호해진다.
그래서 기존 Skill을 다음 두 후보로 나눴다.
```text
official-statistics-research
├─ official-statistics-evidence-verifier
└─ decision-ready-statistics-delivery
```
첫 번째 Skill은 공식통계 근거의 정확성과 비교 가능성을 검증한다. 두 번째 Skill은 검증을 마친 통계를 사람이 다시 추적할 수 있는 산출물로 만든다.
## 두 Skill 사이에는 숫자만 넘기지 않았다
처음에는 검증 Skill이 원자료 파일을 전달 Skill에 넘기도록 설계했다. 곧 문제가 보였다. PDF나 Excel만 받은 전달 Skill은 숫자와 단위를 다시 추출해야 한다. 앞 단계에서 끝낸 검증을 다음 단계가 반복하는 구조였다.
최 종적으로 두 Skill 사이의 handoff를 다음처럼 바꿨다.
```text
verified_statistic_record[] + 원자료 묶음
```
verified_statistic_record에는 지표명, 값과 단위, 관측기간, 공표일, 생산기관, 직접 URL, 표 ID, 조회조건, 분류 버전, 잠정·확정 상태, 정의와 제외항목, 불일치 메모가 들어간다.
전달 Skill은 이 record를 기본 입력으로 사용한다. 각주나 문맥을 다시 확인해야 할 때만 함께 받은 원자료를 연다. 이 구조라면 검증 결과를 반복해서 만들 필요가 없고, 원문으로 돌아갈 경로도 남는다.
## 일부러 불완전한 record를 넣어봤다
실제 조사에 적용하기 전에 작은 simulation을 만들었다. 완전한 record와 불완전한 record를 각각 준비했고, 불완전한 쪽에서는 다음 네 필드를 뺐다.
- 직접 URL
- 조회조건
- 분류 버전
- 불일치 메모
검증기는 불완전한 record를 metadata_missing으로 차단했고, 빠진 필드 네 개를 정확히 찾아냈다. 완전한 record는 통과했다.
이 결과만으로 Hermes runtime에서 두 Skill이 작동한다고 말할 수는 없다. 후보 Skill을 활성 프로필에 설치하지 않았기 때문이다. 다만 A에서 불완전한 record를 막고, B에는 완전한 record만 넘긴다는 책임 경계는 시험할 수 있었다.
## 실제 식약처 통계에 적용하자 차단의 필요성이 드러났다
다음 실험에서는 식약처가 발표한 2024년 바이오의약품 수출 통계를 사용했다. 같은 기관이 같은 연도에 대해 서로 다른 값을 제시하고 있었다.
| 자료 | 2024년 바이오의약품 수출 | 환산값 |
|---|---:|---:|
| [2025년 6월 27일 식약처 연간실적 자료](https://www.mfds.go.kr/brd/m_99/view.do?seq=49157) | 321,659만 달러 | USD 3.21659bn |
| [2026년 7월 8일 식약처 국가승인통계 자료](https://www.mfds.go.kr/brd/m_99/view.do?seq=50179) | 65억 달러 | USD 6.5bn, 반올림 공표값 |
단순 차이는 약 USD 3.28bn이고 두 번째 값은 첫 번째 값의 약 2.02배다. 그렇다고 이를 수출 증가율로 해석할 수는 없다.
원 페이지와 첨부 PDF·HWPX를 확인했지만, 공개 자료만으로는 두 숫자를 연결할 수 없었다. 통계표 ID, 품목 코드 범위, 분류체계 변경 내역, 과거 계열과 신규 승인통계를 연결하는 revision bridge가 없었다.
검증 Skill의 결론은 incomparable_series였다. 어느 한 숫자를 맞다고 고르는 대신 두 값을 별도 계열로 유지했다. 전달 Skill은 비교표와 함께 다음 caveat를 눈에 띄게 표시했다.
- 두 값을 하나의 시계열로 연결하지 않는다.
- 두 계열 사이의 증감률을 계산하지 않는다.
- 차이를 실제 수출 증가나 누락으로 해석하지 않는다.
- 식약처의 승인통계 메타데이터와 계열 변경 설명을 추가 확인한다.
최종 Gate는 PASS_WITH_COMPARABILITY_BLOCK으로 기록했다. 두 숫자의 호환성이 확인됐다는 뜻이 아니다. 오히려 비교할 수 없는 숫자를 보고서가 억지로 연결하지 않았기 때문에 통과했다는 의미다.
자료를 확인하는 과정에서 작은 오류도 하나 발견했다. 2026년 자료의 웹페이지 등록일은 2026년 7월 8일이지만, 내려받은 첨부파일 표지에는 2025년 7월 8일이라고 적혀 있었다. 제목과 본문은 2026년 상반기 통계를 다룬다. 원문 오류로 보이지만 임의로 고치지 않고 discrepancy log에 그대로 남겼다.
## 이번 주에 바뀐 생각
처음에는 큰 Skill을 작은 Skill로 나누는 것이 목적이라고 생각했다. 실제로 해보니 크기보다 중요한 것은 실패의 주인이었다.
숫자가 틀렸을 때 돌아갈 곳과 전달 형식이 틀렸을 때 돌아갈 곳이 다르다면, 두 책임을 분리할 이유가 있다. 반대로 이름만 다르고 같은 입력을 다시 읽고 같은 검사를 반복한다면 잘못 나눈 것이다.
이번 분해에서 가장 효과가 있었던 선택은 두 Skill 사이에 원자료만 넘기지 않은 것이다. 구조화된 검증 record와 원자료를 함께 넘기자 책임 중복은 줄고 추적 가능성은 남았다.
아직 확인하지 않은 것도 있다. 두 후보는 현재 학습용 working copy에만 있고 Hermes active profile에는 설치하지 않았다. 따라서 runtime discovery와 runtime-loaded behavior는 not_checked 상태다. 다음 실험에서는 이 record를 실제 Excel이나 PPT로 전달했을 때 직접 링크, 각주, caveat와 discrepancy log가 끝까지 유지되는지 확인할 계획이다.
공식통계 조사에서 좋은 결과물은 숫자가 많은 결과물이 아니다. 검토자가 숫자의 출처와 한계를 다시 확인할 수 있고, 비교할 수 없는 숫자는 비교하지 않는 결과물이다.
