2화에서 방향을 잡았습니다. “공포가 아니라 이해.” 판단은 사용자가 하고, 서비스는 정보를 정리해서 건네주는 것.
좋습니다. 그런데 방향만으로는 아무것도 만들어지지 않습니다. 실제로 뭘 만들 건지를 정해야 했어요.
처음에 제가 머릿속에 그린 건 꽤 거창했습니다.
바코드 스캔도 되고, 내 알레르기 정보를 넣으면 자동으로 위험 성분을 걸러주고, 비슷한 제품끼리 비교도 해주고, 더 나은 대안도 추천해주고, AI가 성분을 쉬운 말로 설명도 해주는.
다 좋은 기능들이에요. 문제는, 이걸 한꺼번에 만들 수 있는 사람이 아니라는 거였습니다.
저는 개발자가 아니고, AI와 함께 만들고 있다고 해도 시간과 에너지는 유한하니까요.
그래서 AI에게 물어봤어요. “이 중에서 제일 먼저 만들어야 하는 게 뭘까요?”
이때 처음 알게 된 개념이 있습니다. MVP라는 것이에요.
Minimum Viable Product. ‘최소한으로 작동 가능한 제품’이라는 뜻입니다.
쉽게 말하면 이런 거예요. 레스토랑을 열고 싶다고 해서 처음부터 100가지 메뉴를 준비하지는 않잖아요. 일단 가장 자신 있는 메뉴 서너 가지로 시작해서, 손님이 오는지, 반응이 어떤지를 먼저 확인하는 거죠.
앱도 마찬가지였습니다. 모든 기능을 다 넣고 출시하는 게 아니라, 가장 핵심적인 것만 먼저 만들어서 사람들에게 보여주는 것.
그래서 기능을 네 단계로 나눴습니다.
반드시 있어야 하는 것. 제품을 검색할 수 있어야 하고, 그 제품의 성분을 보여줄 수 있어야 하고, 내 기준에 맞는 기피 성분이 있으면 표시해줘야 합니다. 그리고 비슷한 제품을 나란히 비교할 수 있어야 해요.
이게 없으면 서비스의 의미가 없는 것들이에요.
가능하면 넣고 싶은 것. “이 제품보다 이게 더 나은 이유”를 한 줄로 알려주는 대안 추천. 최근에 본 제품 목록. 즐겨찾기.
있으면 좋지만, 없어도 핵심 경험은 가능한 것들입니다.
여건이 되면 넣을 것. AI가 성분을 쉬운 말로 설명해주는 기능. 영양성분 정보. 처음 방문한 사람을 위한 안내 화면.
첫 버전에서는 빼기로 한 것. 바코드 스캔, 회원가입, 커뮤니티, 구매 연결.
특히 바코드 스캔은 고민이 됐어요. 프랑스의 그 앱이 바코드 스캔으로 성공했으니까요. 하지만 바코드 스캔을 하려면 모바일 앱을 따로 만들어야 하고, 그러면 시간이 훨씬 더 오래 걸립니다.
일단 웹에서 검색으로 시작하기로 했습니다. 핵심 경험을 먼저 검증하고, 바코드는 나중에.
또 하나 중요한 결정이 있었습니다.
민감한 개인 정보는 서버에 저장하지 않는다.
알레르기 정보나 건강 상태 같은 것들이요. 이건 사용자의 기기(브라우저)에만 저장하고, 서버로는 절대 보내지 않기로 했습니다.
기술적으로 복잡한 이야기는 아닌데, 왜 이렇게 정했냐면요.
저도 누군가의 앱에 “저는 이런 알레르기가 있어요”라고 입력하라고 하면 솔직히 좀 망설일 것 같았거든요. 그 정보가 어디에 저장되는지, 누가 보는지 모르니까요.
그래서 아예 서버가 그 정보를 모르게 만들기로 했습니다. 서버는 제품과 성분 데이터만 제공하고, “이 성분이 내 기준에 해당하는지”는 사용자의 기기에서 판단하는 구조예요.
이렇게 첫 번째 버전의 범위가 정해졌습니다.
정리하면 이렇습니다.
- 제품 검색
- 성분 요약 + 기피 성분 표시
- 비슷한 제품 비교
- 사용자 프로필은 기기에만 저장
많지 않아 보이죠. 하지만 이것만 제대로 작동하게 만드는 데도 생각보다 많은 일이 필요했습니다.
가장 먼저 필요한 건 데이터였어요. 제품 정보, 성분 정보, 원재료 사전. 이런 데이터가 없으면 검색도, 비교도, 태깅도 할 수 없으니까요.
다행히 한국에는 이런 데이터를 공개하는 곳이 있었습니다. 정부가 운영하는 공공데이터라는 것인데요.
다음 화에서 그 이야기를 하겠습니다. ‘정부가 데이터를 공개한다’는 것이 실제로 어떤 의미인지에 대해서요.