첵잇은 매일 새벽 4시에 식약처 서버에 접속합니다.
그리고 104만 건의 식품 데이터를 처음부터 끝까지 전부 다시 읽어옵니다.
“바뀐 것만 가져오면 되지 않나요?”
네, 저도 그러고 싶었습니다. 정말로.
동네 도서관에 매일 가는 사서가 있다고 상상해 보세요.
어제도 갔고, 오늘도 갑니다. 효율적인 방법은 “어제 이후로 바뀐 책만 알려주세요”라고 물어보는 거예요.
그런데 도서관 사서가 이렇게 답합니다.
“그런 목록은 없어요. 직접 다 확인하셔야 합니다.”
식약처 공공 API가 딱 이런 상태입니다.
“이 날짜 이후로 바뀐 데이터만 주세요”라고 요청하는 기능이 없어요. 변경 날짜 필드가 있긴 한데, 신뢰할 수 없습니다. 과거 데이터를 수정하면서 변경일을 안 바꾸는 경우가 있거든요.
도서관에서 “이 책은 수정판인데 출간일은 초판 날짜로 적어뒀어요”라고 하는 셈이에요.
그래서 매일 전부 다시 읽습니다. 느리지만 확실한 방법을 택한 거예요.
성분 해석 서비스에서 “빠르지만 가끔 틀리는 것”은 선택지가 아니니까요.
재미있는 건, 이 “전부 다시 읽기”가 꼭 비효율적이지만은 않다는 점이에요.
데이터베이스에는 “upsert”라는 기능이 있습니다. “있으면 업데이트하고, 없으면 새로 넣어라.” 매번 전부 넣되, 이미 있는 건 자동으로 비교해서 바뀐 부분만 반영됩니다.
택배 기사가 매일 같은 주소에 가되, 문 앞에 이미 택배가 있으면 그냥 지나가는 것과 비슷해요.
그런데 데이터의 품질 문제도 있었습니다.
97만 8천 건의 원재료 데이터를 분석하다가 발견한 건데, 괄호가 안 맞는 데이터가 있었어요.
보통 프로그래밍에서 괄호는 짝이 맞아야 합니다.
( 로 열면 ) 로 닫아야 하고, [ 로 열면 ] 로 닫아야 해요.
그런데 식약처 데이터에는 [ 로 열고 ) 로 닫는 경우가 7건 있었습니다.
97만 8천 건 중 7건. 비율로 치면 0.0007%.
104만 페이지짜리 소설에서 오타 7개. 무시해도 될 것 같죠?
문제는, 그 7개를 무시하면 다음에 오는 성분이 통째로 합쳐진다는 거였어요.
괄호가 안 닫히면 프로그램은 “아직 괄호 안이구나”라고 생각하고 다음 성분까지 같은 덩어리로 묶어버립니다.
“수크랄로스”와 “프로필렌글리콜”이 하나로 합쳐져서 사용자는 성분 2개를 놓치게 됩니다.
그래서 파서(데이터를 분해하는 프로그램)를 관대하게 만들었습니다. “짝이 안 맞아도, 있는 대로 최선을 다해 분리하라.”
완벽하지 않은 데이터를 다루는 첫 번째 규칙은, 완벽을 기대하지 않는 것이었습니다.
그리고 하나 더.
이 모든 작업을 돌리는 서버는 AWS 프리티어(무료)입니다. 메모리 914MB, 월 비용 0원.
무료의 대가가 있었습니다.
새벽에 아무도 안 쓰면, 데이터베이스가 잠듭니다. 다음 날 아침 첫 검색에 5초씩 걸리는 이유가 이거였어요.
무료 주차장인데, 3시간 이상 세워두면 잠기는 주차장. 다시 차를 꺼내려면 관리인을 깨워야 하는.
해결은 했지만 (연결을 끊지 않도록 설정을 바꿨습니다), “무료”라는 단어 뒤에 숨어있는 비용이 있다는 걸 배웠어요.
매일 새벽 4시. 11단계 파이프라인이 자동으로 돌아갑니다.
데이터 가져오기 → 성분 매칭 → 무결성 검증 → 리포트 생성.
사용자는 이 과정을 알 필요가 없습니다. 아침에 검색하면 어제와 같은, 또는 조금 더 나아진 데이터가 조용히 기다리고 있으면 됩니다.
신뢰는 보이지 않는 곳에서 매일 반복되는 일로 쌓입니다.
다음 화에서는, 3,744만원짜리 데이터를 사지 못한 이야기를 해볼게요. 바코드 하나에 1,100원. 괜찮은 것 같죠? 그 계산을 끝까지 해보면 좀 달라집니다.