19화에서 사업 이야기를 했습니다. 아직 답을 찾지 못했다고요.
이번 화는 조금 다른 이야기입니다.
프로젝트를 진행하면서, 저는 식약처와 공공데이터포털의 API를 수백만 번 호출했습니다. 그 과정에서 느낀 것들이 있었어요.
감사한 것도 있었고, 아쉬운 것도 있었습니다.
만약 식약처에 편지를 쓸 수 있다면, 이런 이야기를 하고 싶습니다.
먼저, 감사한 것부터.
한국에서 판매되는 식품의 정보를 누구나 접근할 수 있는 형태로 공개하고 있다는 것. 이것 자체가 대단한 일이라고 생각합니다.
제품 100만 건 이상의 데이터가 등록되어 있고, 원재료 사전이 4만 건 넘게 관리되고 있고, API를 통해 프로그램으로 접근할 수 있도록 열어두고 있습니다.
이 데이터가 없었으면, 이 프로젝트는 시작조차 할 수 없었을 겁니다.
그런데 실제로 이 데이터를 사용해보면서, 몇 가지 아쉬운 점이 있었습니다.
가장 큰 것은 ‘변경분만 가져올 수 없다’는 것이었습니다.
100만 건의 제품 데이터 중에서 어제 바뀐 것만 가져오고 싶은데, 그런 기능이 없었어요.
“언제 이후로 변경된 것만 주세요” 하고 요청할 수가 없으니, 매번 100만 건을 처음부터 다시 받아야 합니다.
흥미로운 건, API 응답 안에 수정일 정보가 포함되어 있다는 점입니다. 데이터가 언제 바뀌었는지를 알려주는 필드가 이미 있어요. 그런데 그 날짜로 필터링하는 기능은 없습니다.
답을 알고 있는데 질문할 수 없는 상황이랄까요.
날짜 범위로 필터링할 수 있는 기능이 있으면 훨씬 효율적으로 데이터를 관리할 수 있을 것 같습니다.
두 번째는 원재료 데이터의 표준화 문제입니다.
5화에서 이야기한 것처럼, C002 API가 돌려주는 원재료 이름은 제조사가 자유롭게 입력한 텍스트 그대로입니다.
같은 원재료인데 “설탕”, “정백당”, “백설탕”으로 다르게 적혀 있어요.
그런데 식약처에는 이미 I2520이라는 표준 원재료 코드 사전이 있습니다. 4만 3천 개의 원재료에 고유 코드가 부여되어 있어요.
만약 C002 원재료 데이터에 이 표준 코드가 함께 제공된다면, 자유 텍스트를 파싱해서 사전과 매칭하는 복잡한 과정 없이 바로 정확한 연결이 가능할 겁니다.
8화, 9화, 10화, 11화에 걸쳐 이야기한 파싱과 매칭 작업의 상당 부분이 이 하나의 개선으로 해결될 수 있어요.
실제로, 같은 정부에서 제공하는 다른 API에는 원재료에 표준 코드를 붙여서 아름답게 정리된 데이터가 있었습니다. 하지만 그 데이터의 제품 번호 체계가 달라서 우리 제품 데이터와 연결할 수 없었어요. 11화에서 이야기한 그 아쉬움입니다.
세 번째는 API들 사이의 연결과 일관성 문제입니다.
같은 제품을 가리키는 번호가 API마다 달랐습니다. 식약처에서는 ‘PRDLST_REPORT_NO’라고 부르고, 공공데이터포털에서는 ‘prdlstReportNo’라고 부릅니다. 대소문자도 다르고, 밑줄과 띄어쓰기 규칙도 달랐어요.
이것만 해도 혼란스러운데, 어떤 API는 아예 다른 체계의 번호를 사용해서 서로 연결할 방법이 없는 경우도 있었습니다. 번호 자릿수부터 달라서 변환 규칙조차 찾을 수 없었어요.
응답 형식도 제각각이었습니다. 같은 포털에서 제공하는 API인데, 데이터가 담겨 오는 구조가 네 가지나 됐습니다. API를 새로 연결할 때마다 “이번에는 어떤 형식일까”부터 확인해야 했어요.
두 데이터가 같은 제품을 가리키고 있는데 연결할 수 없다는 건, 정말 아까운 일이에요.
네 번째는 첨가물 용도 정보입니다.
15화에서 이야기했듯이, 식약처 고시에는 31개의 첨가물 용도 분류 체계가 이미 있습니다. 감미료, 보존료, 유화제, 향미증진제…
그런데 이 분류 정보가 API에는 포함되어 있지 않았습니다. 용도 정보 필드가 있긴 했지만, 실제로 채워져 있는 비율이 13%에 불과했어요.
MSG처럼 3만 번 넘게 등장하는 첨가물인데도 용도 정보를 API에서 얻을 수 없었습니다.
고시 문서에는 있는 정보를 API에 반영해주기만 하면, 소비자 대상 서비스에서 첨가물의 용도를 쉽게 안내할 수 있게 됩니다.
다섯 번째는 제품 구분 문제입니다.
104만 건의 제품 데이터 중에는 소비자가 마트에서 살 수 있는 완제품만 있는 게 아닙니다. 공장에서 다른 공장으로 납품되는 반제품이나 산업용 원료도 섞여 있었어요.
“새우깡”을 검색하면 “새우깡반제품”이 함께 나오는 상황. 이걸 구분할 수 있는 필드가 API에 없어서, 제품 이름의 패턴을 보고 추정하는 수밖에 없었습니다.
완제품인지 반제품인지를 알려주는 필드 하나만 추가되어도 소비자 대상 서비스의 검색 품질이 크게 달라질 것 같습니다.
그리고 마지막으로, 14화에서 이야기한 영양성분 문제.
포장 식품에는 의무적으로 아홉 가지 영양소가 표시되어 있는데, 디지털 데이터베이스에는 이 중 일부만 채워져 있었습니다.
포화지방, 트랜스지방, 콜레스테롤의 완전도가 0.1~0.3% 수준이었어요.
모든 포장지에 인쇄되어 있는 정보가 디지털로는 접근할 수 없다는 건 너무 아까운 일입니다.
이 이야기를 하는 이유는 불만을 말하려는 게 아닙니다.
이 데이터를 실제로 사용해본 사람의 관점에서, “이 부분이 개선되면 훨씬 더 잘 활용할 수 있겠다”는 피드백을 전하고 싶은 거예요.
공공데이터의 가치는 데이터를 공개하는 것에서 끝나지 않습니다. 그 데이터가 실제로 쓰이고, 그 데이터를 기반으로 서비스가 만들어지고, 그 서비스를 통해 사람들의 일상이 조금 더 나아지는 것.
거기까지가 공공데이터의 진짜 가치라고 생각합니다.
저는 개발자가 아닌 사람이고, AI와 함께 이 프로젝트를 만들었습니다. 그런 사람도 이 데이터를 쓸 수 있었다는 것은 공공데이터가 이미 잘 열려 있다는 뜻이기도 합니다.
다만, 조금만 더 다듬어주시면 훨씬 많은 사람들이 더 좋은 서비스를 만들 수 있을 거라고 조심스럽게 이야기하고 싶습니다.
다음 화에서, 이 연재를 마무리하겠습니다.