17화에서 AI 두 명의 조언을 받아들여 프론트엔드 작업을 시작한 이야기를 했습니다.
데이터는 준비되어 있었습니다. 제품 104만 건, 매칭된 원재료 725만 건, 첨가물 번역 620건. 이제 이것들을 사용자에게 보여줄 화면을 만들어야 했어요.
프론트엔드. 사용자가 실제로 보고 만지는 부분.
백엔드에서 몇 달을 보냈다면, 프론트엔드는 상대적으로 빠르게 진행됐습니다.
왜냐하면, 이미 만들어야 할 것이 명확했거든요. 3화에서 정한 MVP 범위가 있었으니까요.
제품 검색 화면. 제품 상세 화면 — 원재료 목록, 기피 성분 표시. 두 제품을 나란히 비교하는 화면. 사용자 프로필 설정 — 피하고 싶은 성분을 고르는 화면.
이 네 가지를 만들면 되는 거였습니다.
가장 신경 쓴 것은 개인 정보 처리 방식이었습니다.
3화에서 이런 결정을 했었죠.
민감한 개인 정보는 서버에 저장하지 않는다.
사용자가 “나는 이 성분을 피하고 싶어”라고 설정하면, 그 정보는 사용자의 브라우저에만 저장됩니다. 서버로는 절대 보내지 않아요.
서버는 제품과 성분 데이터를 제공할 뿐이고, “이 성분이 내 기준에 해당하는가?”라는 판단은 사용자의 기기에서 이루어집니다.
이렇게 하면 서버가 사용자의 건강 정보를 알 수 없습니다. 개인정보 유출 걱정이 없어지는 구조예요.
처음 방문하는 사용자에게는 이 점을 명확하게 안내하도록 했습니다. “당신의 정보는 이 기기에만 저장되며, 서버로 전송되지 않습니다.”
화면을 만들면서 고민했던 것 중 하나는, 기피 성분을 어떻게 표시할 것인가였습니다.
2화에서 정한 원칙이 있었죠. “공포가 아니라 이해.”
빨간색으로 “위험!”이라고 표시하지 않기로 했습니다. 대신, “주의” 또는 “확인”이라는 표현을 사용하고, 왜 이 성분에 주의 표시가 붙어 있는지를 함께 보여주기로 했어요.
그리고 중요한 규칙 하나. 근거 없이 “주의” 태그를 달지 않는다.
어떤 성분에 “주의” 표시를 하려면, 반드시 공신력 있는 기관의 연구나 권고사항이 근거로 있어야 합니다. 기관 이름, 발표 연도, 참고 링크까지.
“인터넷에서 위험하다고 하던데” 같은 것은 근거가 될 수 없어요.
화면이 어느 정도 갖춰지자, 다음 문제가 왔습니다.
이걸 어디에 올려서 사람들이 접근할 수 있게 하지?
이건 ‘배포’라는 과정입니다. 제 컴퓨터에서만 돌아가는 서비스를 인터넷에서 누구나 접속할 수 있게 만드는 것.
백엔드는 Railway라는 서비스에 올리기로 했습니다. 프론트엔드는 Vercel이라는 곳에 올리기로 했고요.
왜 이 두 곳이었느냐면, 설정이 비교적 간단하고, 적은 비용으로 시작할 수 있었기 때문입니다.
MVP 단계에서 서버 비용에 많은 돈을 쓸 수는 없으니까요.
배포 과정도 순탄하지만은 않았습니다.
제 컴퓨터에서는 잘 돌아가던 것이, 서버에 올리면 안 되는 경우가 있었어요.
환경이 다르기 때문입니다. 제 컴퓨터는 Windows인데 서버는 Linux이고, 설정 파일의 경로가 다르고, 데이터베이스 접속 방법이 다르고.
이런 차이들을 하나씩 잡아가면서 배포를 완료했습니다.
그리고 한 가지 더 만든 것이 있었습니다.
매일 밤 자동으로 데이터를 업데이트하는 프로그램.
API에서 새 제품이 등록됐는지, 기존 제품의 정보가 바뀌었는지를 확인하고, 바뀐 것이 있으면 자동으로 반영하는 것이에요.
그리고 그 결과를 이메일로 보내줍니다. “오늘 밤 동기화 결과: 새 제품 47건 추가, 기존 제품 123건 업데이트.”
이건 16화에서 이야기한 것과 같은 맥락입니다. 서비스를 만드는 것보다 유지하는 것이 더 중요하니까요. 데이터가 계속 최신 상태여야 서비스의 의미가 있으니까요.
이렇게 해서, 서비스가 세상에 나왔습니다.
아직 베타 단계이고, 아직 부족한 부분이 많지만, 적어도 누군가가 접속해서 제품을 검색하고 성분을 확인할 수 있는 상태가 됐습니다.
호빵 뒷면을 뒤집어보던 날로부터 여기까지. 정확히 얼마나 걸렸는지는 잘 모르겠습니다. 하지만 “이런 앱을 만들 수 있을까요?” 하고 물어봤던 그때에 비하면, 많은 것이 달라졌습니다.
다음 화에서는 조금 다른 질문을 해보겠습니다. 이걸 사업이라고 부를 수 있을까, 에 대해서요.