이 글의 배경이 되는 이야기는 14화: 영양정보가 0.1%만 채워져 있다면에서 읽을 수 있습니다.
이 글을 읽으면 알 수 있는 것
- 공공데이터 영양성분 API의 실제 완전도
- 서로 다른 3개 소스를 병합하는 전략과 우선순위
- 품목보고번호 기반 정확 매칭의 설계
- HACCP 포장지 텍스트에서 영양소를 파싱하는 접근
문제: 27만 건인데 포화지방이 0.2%
식품별 영양성분 API는 약 27만 건의 데이터를 제공합니다. 숫자만 보면 충분해 보입니다.
그런데 의무 영양소 9가지(열량, 탄수화물, 당류, 단백질, 지방, 포화지방, 트랜스지방, 콜레스테롤, 나트륨)의 완전도를 확인해봤습니다.
| 영양소 | 값이 채워진 비율 |
|---|---|
| 열량 | ~95% |
| 탄수화물 | ~93% |
| 단백질 | ~93% |
| 지방 | ~93% |
| 나트륨 | ~2.0% |
| 콜레스테롤 | ~0.3% |
| 포화지방 | ~0.2% |
| 트랜스지방 | ~0.1% |
열량과 3대 영양소는 비교적 잘 채워져 있었지만, 나머지 의무 항목은 거의 비어 있었습니다.
27만 건 중 트랜스지방 정보가 있는 건 약 270건. 이 데이터만으로는 “이 제품에 트랜스지방이 얼마나 들어 있는지” 알려줄 수 없었습니다.
발견: 같은 기관, 다른 경로
같은 기관에서 CSV 파일로 제공하는 영양성분 데이터가 따로 있었습니다. 이쪽은 의무 9가지가 100% 채워져 있었습니다.
다만 두 가지 제약이 있었습니다.
- 커버리지가 작습니다. API의 27만 건에 비해 수천 건 수준이었습니다.
- API가 없습니다. 포털에서 파일을 직접 내려받아야 했습니다. 자동 갱신이 불가능합니다.
흥미로운 점은, API에만 있는 데이터와 CSV에만 있는 데이터가 서로 달랐다는 것입니다. 양쪽을 합쳐야 비로소 전체에 가까워졌습니다.
갈림길: 영양정보를 제품에 어떻게 연결할 것인가
영양성분 데이터와 제품 데이터는 별개의 테이블입니다. 이 둘을 연결하는 방법이 문제였습니다.
| 방법 | 장점 | 단점 |
|---|---|---|
| 이름+제조사 유사도 매칭 | 많은 건수 연결 가능 | 오매칭 위험 |
| 품목보고번호 정확 매칭 | 정확도 100% | 번호가 없는 건은 연결 불가 |
실제로 이름+제조사 기반 매칭을 시도한 적이 있습니다. 2,434건을 매칭했는데, 교차검증을 해보니 품목보고번호가 일치하는 건은 0건이었습니다. 86.5%가 오매칭이었습니다.
이 방법은 폐기하고, 품목보고번호 정확 매칭만 남겼습니다.
설계: 3단계 병합 파이프라인
최종적으로 세 가지 소스를 순서대로 적용했습니다.
[1단계] 영양성분 API (27만 건)
→ 품목보고번호로 제품에 연결
→ 교차검증: 샘플 100건 중 불일치 5% 초과 시 배치 적용 차단
[2단계] CSV 영양성분 데이터 (수천 건)
→ 1단계에서 미연결된 제품에 보충
[3단계] HACCP 포장지 영양성분 파싱 (1,600건)
→ 위 두 단계에서도 빠진 제품에 보충우선순위의 기준은 단순합니다. 더 구조화된 데이터가 우선합니다. API/CSV는 이미 정리된 숫자이고, HACCP은 비정형 텍스트를 파싱한 것이므로 후순위입니다.
핵심: 교차검증 게이트
매칭 결과를 DB에 적용하기 전에, 반드시 교차검증을 통과해야 합니다.
# 배치 적용 전: 샘플 100건을 무작위 추출하여 검증
# 영양정보의 품목보고번호 ↔ 제품의 품목보고번호 일치 여부 확인
# 불일치율이 5%를 초과하면 ValueError → 배치 전체 적용 차단이 게이트가 없었다면, 이름 기반 매칭의 86.5% 오매칭을 그대로 DB에 넣을 뻔했습니다. 검증을 “나중에 하지 뭐”가 아니라 파이프라인 안에 강제로 심어둔 것이 핵심이었습니다.
HACCP 영양성분 파싱
HACCP 포장지 텍스트에는 영양성분이 사람 읽기 좋은 형태로 적혀 있습니다.
열량 150kcal, 탄수화물 20g, 당류 5g, 단백질 3g,
지방 6g, 포화지방 3g, 트랜스지방 0g, 콜레스테롤 0mg, 나트륨 200mg이것을 프로그램이 쓸 수 있는 구조로 변환해야 합니다. 어려운 점은 표기 방식이 제품마다 달랐다는 것입니다.
- “열량: 150kcal” vs “열량 150 kcal” vs “에너지 150킬로칼로리”
- “트랜스지방” vs “트렌스지방”(오타)
- “1g미만” 같은 표현 처리
정규식 패턴을 영양소별로 여러 개 준비하고, 순서대로 시도하는 방식으로 처리했습니다. 의무 9가지 중 최소 5가지 이상 추출해야 저장하는 품질 기준도 두었습니다.
결과
| 항목 | 수치 |
|---|---|
| 영양성분 API 적재 | ~270,000건 |
| 제품 연결 (품목보고번호 매칭) | ~130,000건 |
| HACCP 파싱 추가 적재 | ~1,600건 |
| 이름 기반 매칭 (폐기됨) | 2,434건 전량 오매칭 |
한계
104만 제품 중 대다수에는 아직 영양정보가 없습니다. 세 소스를 합쳐도 커버리지는 전체의 일부입니다. 모든 포장 식품의 겉면에는 영양정보가 인쇄되어 있지만, 그 정보가 디지털로 접근 가능한 경로는 아직 충분하지 않습니다.
CSV 데이터는 자동 갱신이 불가능합니다. API가 없으므로 수동으로 다운로드해야 하며, 언제 업데이트되었는지 알 수 있는 방법이 없습니다.
한 줄 교훈
27만 건의 데이터가 있어도 필요한 필드가 0.1%만 채워져 있으면 쓸 수 없습니다. 양보다 완전도가 중요합니다.