이 글의 배경이 되는 이야기는 15화: 감칠맛 조미료의 정체에서 읽을 수 있습니다.
이 글을 읽으면 알 수 있는 것
- 식품 성분 서비스에서 표현이 왜 기술적 문제인지
- 표시광고법이 서비스 설계에 미치는 영향
- “중립적 표현”을 코드로 강제하는 방법
문제: 말 한마디가 법적 리스크가 됩니다
이전 글에서 기피성분을 4단계로 분류한 이야기를 했습니다. 분류 자체보다 더 어려운 문제가 있었습니다. 그 분류를 사용자에게 어떻게 표현할 것인가.
MSG를 예로 들겠습니다.
표현 A: "이 제품에는 MSG(유해 첨가물)가 포함되어 있습니다."
표현 B: "이 제품에는 L-글루탐산나트륨(감칠맛 조미료)이 포함되어 있습니다."
표현 C: "이 제품에는 MSG가 포함되어 있습니다. (일부 소비자가 회피하는 성분)"세 가지 표현은 같은 사실을 말하지만, 전달하는 메시지가 전혀 다릅니다.
표현 A는 위법 소지가 있습니다. 식약처가 안전하다고 평가한 첨가물을 “유해”라고 표시하는 것은 표시광고법상 거짓·과장 표시에 해당할 수 있습니다. 더 심각한 것은, 해당 첨가물을 사용하는 제조사에게 영업 방해가 될 수 있다는 점입니다.
표현 B는 정확하지만 불충분합니다. MSG를 피하고 싶은 사용자에게 아무런 정보를 제공하지 않습니다.
표현 C가 서비스의 방향입니다. 성분이 포함되어 있다는 사실을 전달하고, 회피 이유에 대한 맥락을 제공하되, 서비스가 판단하지 않습니다.
표현 규칙: 금지와 허용
절대 금지 표현
| 금지 표현 | 이유 |
|---|---|
| ”유해”, “위험”, “독성” | 식약처 허가 물질에 대한 근거 없는 위해 판단 |
| ”암 유발 가능성” | 확정되지 않은 의학적 판단 |
| ”논란 성분” | 모호한 근거로 부정적 인식 유도 |
| ”화학적”, “인위적인” | 모든 첨가물은 화학물질이므로 비하 효과 |
| ”100% 안전” | 절대적 안전을 보장할 수 없음 |
| ”과다 섭취 시 ~“ | 부작용 서술은 서비스의 영역이 아님 |
“과다 섭취 시…”가 금지인 이유가 있습니다. 물도 과다 섭취하면 위험합니다. 특정 첨가물에만 이 표현을 붙이는 것은 해당 첨가물이 특별히 위험하다는 인상을 줍니다.
허용 표현
| 분류 | 허용되는 표현 | 필수 첨부 |
|---|---|---|
| 법정 알레르겐 | ”법정 표시 대상 알레르겐입니다” | 법적 근거 (식품위생법) |
| 특정군 주의 | ”임산부에게 주의가 필요합니다” | 출처 기관 + URL |
| 인지 기반 | ”일부 소비자가 회피하는 성분입니다” | 출처 기관 + URL |
| 기호/윤리 | ”동물성 원료입니다” | 없음 (사실 서술) |
모든 주의 표현에는 출처가 필수입니다. “식약처 권고”, “EFSA 의견서” 등 근거를 함께 보여줘야 합니다. 근거 없는 주의 문구는 서비스에 표시하지 않습니다.
갈림길: 표현 규칙을 어디에서 강제할 것인가
| 방법 | 동작 | 문제 |
|---|---|---|
| 프론트엔드 UI 코드에서 | 화면 렌더링 시 표현 규칙 적용 | 프론트엔드 개발자가 규칙을 알아야 함 |
| 가이드 문서로 | 작성 시 참고 | 강제력 없음, 실수 가능 |
| 데이터 스키마에서 | DB 필드와 Enum으로 강제 | 유연성 감소 |
세 번째를 선택했습니다. 이유는 명확합니다. 가이드 문서는 읽지 않을 수 있고, 프론트엔드 코드는 변경될 수 있습니다. DB 스키마는 바꾸지 않으면 우회할 수 없습니다.
구체적으로 세 가지를 스키마에서 강제했습니다.
구현 1: 출처 URL 필수
기피성분 규칙을 등록할 때 source_url 필드가 비어 있으면 저장할 수 없습니다. “이 성분은 주의가 필요하다”고 말하려면, 왜 그런지에 대한 근거 문서 링크를 반드시 제공해야 합니다.
근거 없이 주의 문구를 달 수 없게 만든 것입니다.
구현 2: UI 라벨과 색상을 서버에서 결정
화면에 표시되는 라벨 텍스트와 색상이 프론트엔드가 아닌 서버(API 응답)에서 결정됩니다.
API 응답 예시:
{
"classification_level": "PERCEPTION_BASED",
"ui_label": "소비자 인식 기반",
"ui_color": "blue"
}프론트엔드는 이 값을 그대로 렌더링합니다. 색상을 빨강으로 바꾸거나, 라벨을 “위험 성분”으로 바꾸려면 서버 코드를 변경해야 합니다. 프론트엔드 개발자가 임의로 표현을 바꿀 수 없는 구조입니다.
구현 3: 색상 규칙
| 분류 | 사용 색상 | 사용 금지 색상 |
|---|---|---|
| 법정 알레르겐 | 회색(gray) | 빨강 |
| 특정군 주의 | 앰버(amber) | 진주황, 빨강 |
| 인지 기반 | 연파랑(blue) | 빨강, 주황 |
| 기호/윤리 | 연보라(purple) | 빨강, 주황 |
빨강을 쓰지 않는 이유는 이전 글에서 이야기했습니다. 빨강은 “위험”을 의미합니다. 식약처가 허가한 첨가물에 “위험” 신호를 보내는 것은 서비스가 해서는 안 되는 판단입니다.
회색은 의외의 선택이었습니다. 법정 알레르겐이 가장 “중요한” 분류인데, 왜 가장 눈에 띄지 않는 색인가? 알레르겐 정보는 해당 사용자에게만 중요하고, 나머지 사용자에게는 무관합니다. 모든 사용자에게 빨간 경고를 보여주면, “이 성분이 위험하다”는 잘못된 인식을 만들 수 있습니다.
LLM 번역에도 같은 규칙 적용
이전 글(첨가물 번역)에서 LLM으로 첨가물을 번역한 이야기를 했습니다. 이 번역에도 동일한 표현 규칙을 적용했습니다.
LLM의 시스템 프롬프트에 금지 표현 목록을 명시합니다. “유해”, “위험”, “독성”, “과다 섭취 시” 같은 표현이 응답에 포함되면 거부합니다.
이 규칙이 없으면, LLM은 인터넷에서 학습한 “첨가물 = 나쁜 것” 편향을 반영할 가능성이 높습니다.
결과
| 항목 | 내용 |
|---|---|
| 금지 표현 카테고리 | 6종 |
| 출처 필수 | source_url NOT NULL |
| 색상 결정 주체 | 서버 (API 응답) |
| LLM 번역 금지어 | 프롬프트에 명시 |
한계
규칙은 있지만, 완전한 자동 검증은 없습니다. 기피성분 데이터의 function_simple 필드에 금지 표현이 들어갔는지를 적재 시점에 자동 검사하는 기능은 아직 없습니다. 현재는 수작업 검수와 LLM 프롬프트 제약에 의존합니다.
법률 검토를 받지 않았습니다. 현재 표현 규칙은 표시광고법의 원문을 참고하여 자체적으로 수립한 것입니다. 법률 전문가의 검토를 거치지 않았으므로, 법적 완전성을 보장하지 않습니다. 서비스 공개 전에 반드시 법무 검토가 필요한 영역입니다.
한 줄 교훈
식품 서비스에서 “표현”은 UX 문제가 아니라 법적 리스크입니다. 프론트엔드의 재량에 맡기면 안 되고, 서버와 스키마 수준에서 강제해야 합니다.