온라인에서나 오프라인에서나, 누군가 뭘 먹었다고 하면 항상 하는 질문이 “어디서 먹었어?” 이다. 그리고 그 답을 얻어서 나도 맛볼 것인지 결정하기 위해 일련의 대화를 나눈다. 타인이 맛 본 것에 대해서 우리는 늘 너무나 자연스러운 정보획득을 하고 있기 때문에, 내가 맛 본 것을 기록하고 공유하는데 적절한 수준의 정보를 명기해놓지 않는다면 그 컨텐츠는 상당한 미완의 것이 되어버린다.

사람들은 이를 본능적으로 알고 있기 때문에, 인스타그램에 음식 사진을 올릴 때 항상 그 음식의 출처를 밝힌다. 설령 그 식당이나 카페가 아무도 모르는 이름 없는 작은 곳일지라도, 우리는 항상 거기가 어디인지를 밝힌다. 위치에 대한 정보가 함께하지 않는다면, 그 음식 컨텐츠는 작품성이 충분해야 유통될 가치를 갖게 되는데 예술음식사진을 촬영할 수 있고 찾는 사람보다는 정보가 결합된 보통의 음식컨텐츠를 만들고 찾는 사람이 세상에는 훨씬 많다.

그래서 당연히도 ma’at을 기록하는 과정에 해당 음식의 출처를 표기해놓는 단계를 주요 프로세스로 넣기로 했다. (맛픽 서비스 소개 https://brunch.co.kr/@locamaster/12)

음식 사진을 예술로 찍는 기술이 없는 사람일지라도, 맛픽의 사용자가 되어 맛 본 위치 정보를 제대로 기록 해놓으면 가치있는 컨텐츠를 쌓고 퍼트릴 수 있으며, 우리 회사가 가지고 있는 위치인식 기술을 적용해서 다양하고 멋진 기능들을 사용할 수 있게 하는 것이다.

“어디서 먹었어?”의 ‘어디’는 어디일까?

옆 자리 개발자양반이 주말에 맛있는 보쌈을 먹었다고 자랑을 했다 치자.

나는 물어볼 것이다. “어디 어디? 어디서 먹었어요?”
이 때 나올 수 있는 답은 개발자양반의 경험과, 성격과, 처한 상황과, 나와의 관계에 따라 다양하다.

- 동네 보쌈집에서요 : 식당이 위치한 지역을 답할 수 있다. 이런 답으로는 질문자가 원하는 정보를 충분히 얻기 힘드니, 후속질문이 나가게 된다. “동네 어디요?” 이렇게 물었는데 “아 집에서 가까운덴데 잘해요" 등의 대답을 한다면 나를 싫어하거나 맛이 없었다고 간주한다.

- 뱅뱅사거리 가까이에 양재보쌈이요! : 식당이 위치한 지역과 식당 이름을 말 할 수 있다. 질문자는 충분한 답을 얻었다고 생각하게 된다.

- 시켜먹었어요~ : 어디서 먹었냐고 물어봤는데 이렇게 답하는 경우가 있다. 마치 친구를 기다리며 “어디야?” 라고 물었는데 “다 왔어" 라고 답하는 것 처럼. 동문서답을 사회적으로 통용하는 경우다. 이럴 때에도 한 단계가 더 필요하다. “어디서 시켰는데요?” “아 동네 김할머니보쌈 이라고 괜찮은데가 있어요" 이 정도면 적당하다.

- 사다 먹었어요 : 시켜먹었어요와 유사한 경우다. 음식을 운반한 주체가 달라질 뿐이다.

- 제가 만들어 먹었어요/엄마가 만들어 주셨어요/ 친구가 만들어 왔더라구요 : 오~~ 맛있었겠다~~~ 끝.

- 사무실에서요 : 맛보는 행위를 한 장소를 답하는 경우다. 질문자의 컨텍스트에 따라 이 부분이 궁금할 수도 있지만 대체로 이런 답을 원하지는 않는다. “여기 어떻게(웬일로) 왔어?” 했는데 “버스타고요” 하는 것과 유사하다.

이렇듯 ‘어디서 먹었다'라는 내용에는 다양한 개념과 상황이 존재한다.

그렇다면 우리는 ‘어디' 즉 위치를 어떻게 기록해야 할까?

일단,
인스타그램이나 페이스북의 체크인 기능에는 맛을 기록하는 데 있어서는 아쉬움이 존재한다. 해당 컨텐츠와 체크인한 장소가 관련이 있다는 것을 표현할 뿐, 거기서 먹었다는 것인지 거기서 사다 먹었다는 것인지 알 수 없고, 거기서 먹기는 했는데 그 집 음식이 아닐 수도 있다. 물론 컨텐츠 내에서 추가 설명으로 표현할 수 있겠으나 체크인 과정 자체에는 해당 컨텍스트가 녹아있지 않다.

우리가 알고 싶은 것은 그 음식이 어디에서 누구에 의해 만들어졌는가, 즉 내가 똑같은 것을 먹으려면 어디로 가야 하는가와, 갈 수 없을 경우 어떻게 할 수 있는가이다. 이 정보를 작성자 본인이 추후에 소비하든 다른 사용자가 소비하든 제대로된 정보로 사용할 수 있게 하려면 기록을 할 때 구체화해서 잘 해놓아야 하고, 입력을 잘 할 수 있도록 설계되어야 한다.

위 개발자와의 대화를 바탕으로 고려해야 할 것을 나열해보자.

- 지역만 기록하게 하는 개념은 정보로써의 가치에 큰 구멍이 뚫리게 되는 것이니 제외한다.

- 음식점의 이름과 위치가 함께 있는 것은 정보로써 훌륭하다.

- 위치를 표현하는 데 주소를 사용하는 것은 굉장히 상세한 정보일 수 있으나 주소 텍스트 자체로는 아무런 정보가 아닐 수 있다.

- 위치를 표현하는 데 지도를 사용하면 아주 익숙한 사용경험을 제공할 수 있으며 지도가 주소와 결합되면 좋은 정보가 된다.

- 음식점의 이름을 인식하고 입력하는 과정과 결과에는 상황/개인별 차이가 존재하므로, 정리된 DB를 제공하여 객관화 하는 것이 정보의 질 면에서 좋다.

- ‘어디’냐고 물었는데 ‘어떻게'를 답하고 싶은 욕구가 분명히 있다.

- 판매를 목적으로 하는 공간이 아니라 사유공간에서 제작된 음식일 수 있다.

- 사유공간의 위치는 해당 컨텐츠 생성자라면 잘 알 것이고, 다른 사용자에게는 노출되어서는 안되는 정보이다.

위 항목들을 바탕으로 사용자의 인식의 흐름에 따라 플로우를 구성해보기로 했다.
먼저 무언가를 먹고 있다고 기록을 시작 했을테니, 그 다음으로 맞이하는 익숙한 질문 ‘어디서 먹었니?’라고 질문해보는 것이다. 그 질문에 대해 답할 수 있는 항목을 미리 선택지로 제공하기로 했다.

이렇게 네 가지 상황을 선택하게 하면 그 다음으로 ‘어디'에 해당하는 위치를 어떤 식으로 기록하게 할지가 나뉘어질 수 있다. 만들어서 맛 봄의 경우에는 위치를 입력할 필요가 없다. 내가 만들어서 맛 보았든, 누군가 만들어준 것을 맛 보았든 그 상황에는 위치 정보가 몹시 개인적인 것이기 때문이다.

사와서 맛 봄 / 배달시켜서 맛 봄 / 음식점에서 맛 봄의 경우에는 그 음식이 판매를 목적으로 하는 음식점에서 만들어진 것이므로 음식점의 위치를 기록해놓게 한다.

음식점의 이름을 물어보아 입력하려 하면, 근방 100미터 안에 있는 음식점 리스트를 주소와 함께 거리순으로 보여주어 선택할 수 있게 한다. 이 리스트는 우리 회사가 가지고 있는 것으로 시장에 유통되고 있는 지도 서비스를 기반으로 한다. 리스트에서 음식점을 선택하면 해당 음식점의 이름/주소/지도상의 위치가 표현된다.

우리 회사가 제공하는 DB에 기록하고자 하는 음식점이 없을 수 있다. 그럴 때에는 리스트에 검색 결과가 없음을 알리고, 어딘가… 라고 표현해준다. 향후 DB에 없는 음식점의 위치를 추가하는 기능을 개발할 예정이다.

이렇게 기록을 해놓고 나면, 본인이 기록한 맛 컨텐츠에 네 개의 상황별 아이콘, 음식점 이름, 주소로 해당 음식을 맛 본 컨텍스트 정보가 표현된다. 주소를 터치하면 구글맵 어플을 띄워서 위치를 보여준다.
그리고, 기록된 위치 정보를 바탕으로 본인이 맛 본 음식들의 출처를 지도에서 모아볼 수 있게 했다.