쏙핀

만들게 된 계기

인스타그램에서 맛집이나 카페를 발견하면 일단 저장은 해둡니다. 그런데 막상 약속 장소를 정하거나 여행을 준비할 때면, 저장한 게시물을 다시 찾고 주소를 복사하고 지도에 검색해야 했습니다. 저장은 많아지는데 실제로 쓸 수 있는 목록은 되지 않는 경험이 계속 쌓였습니다.

쏙핀은 이 과정을 줄이기 위해 시작했습니다. 사용자가 인스타그램에서 발견한 장소를 공유 한 번으로 내 지도에 남기고, 나중에는 위치와 폴더를 기준으로 다시 찾을 수 있게 하는 것이 첫 목표였습니다.

공유 흐름을 제품의 시작점으로 삼다

처음부터 별도의 장소 검색 화면을 중심에 두지 않았습니다. 사용자는 이미 인스타그램에서 장소를 발견한 상태이기 때문입니다. 그래서 공유 확장에서 쏙핀을 선택하면, 링크를 받아 장소 정보 확인과 저장 흐름으로 바로 이어지게 설계했습니다.

이 선택은 입력 단계를 줄이는 것 이상이었습니다. 사용자가 “나중에 봐야지”라고 미루기 전에, 발견의 맥락을 저장 경험으로 자연스럽게 옮기는 방법이었습니다.

웹 데이터를 다루며 세운 기준

이 과정을 만들면서 웹 데이터와 크롤링을 많이 공부했습니다. 단순히 외부 페이지를 가져오는 일이 기술적으로 가능하다고 해서, 제품에서 사용해도 되는 것은 아니라고 생각했습니다.

그래서 쏙핀은 무단으로 대량 수집하는 봇을 두는 방식이 아니라, 사용자가 직접 공유한 URL을 요청했을 때만 필요한 공개 메타데이터를 확인하는 흐름을 기준으로 잡았습니다. 본문을 복제하거나 플랫폼 콘텐츠를 저장하는 대신, 페이지가 외부 공유를 위해 제공하는 Open Graph 메타데이터를 활용해 장소 후보를 만드는 접근입니다.

이 방식도 모든 사이트에서 자동으로 허용된다는 뜻은 아닙니다. 서비스 정책, robots 지침, 저작권과 개인정보 이슈를 계속 확인하고 요청량을 제한하며, 문제가 될 수 있는 수집 범위는 제품에 넣지 않는 것을 원칙으로 삼았습니다. 네이버 페이지를 무단으로 크롤링하는 방식은 사용하지 않았습니다.

Gemini API로 장소 단서 정리하기

공유된 인스타그램 게시물에는 장소명, 메뉴, 지역처럼 사람이 읽으면 알 수 있는 단서가 텍스트 곳곳에 섞여 있습니다. 하지만 그대로는 지도에 저장할 수 있는 구조화된 정보가 아닙니다.

처음에는 OpenAI 모델로 이 단서를 정리하려 했습니다. 하지만 공유 후 저장 결과를 기다리는 흐름에서는 응답 시간이 길게 느껴졌습니다. 2025년 12월, 같은 입력과 출력 형식으로 gpt-5-mini와 gemini-2.5-flash-lite를 각각 100회 비교했고, 평균 응답 시간이 약 10초와 4초 이내로 차이 났습니다. 그래서 쏙핀의 장소 단서 추출에는 Gemini를 선택했습니다.

관련 기록 · 쏙핀에서 GPT 대신 Gemini를 택한 이유는, 정확도보다 먼저 기다림이었다

Gemini는 사용자가 공유한 URL에서 확인한 텍스트와 메타데이터를 바탕으로 장소명, 지역, 메뉴 같은 단서를 정리합니다. AI가 임의의 장소를 만들어 내는 역할이 아니라, 불완전한 문장을 장소 검색에 사용할 수 있는 후보 정보로 바꾸는 역할입니다. 이후에는 Google Places 결과와 대조해 실제 장소인지 확인하는 흐름으로 연결했습니다.

이때도 추출 결과를 그대로 확정하지 않고, 후보가 모호하면 사용자가 직접 선택하거나 수정할 수 있어야 한다고 봤습니다. AI의 결과는 자동 저장을 위한 근거가 아니라, 사용자의 다음 선택을 빠르게 만드는 보조 정보에 가깝습니다.

장소 수에 따라 저장 방식을 달리하다

추출되는 장소 수는 게시물마다 달랐습니다. 적은 후보는 사진과 주소를 한 장씩 보며 각자 다른 쏙에 분류하는 편이 자연스러웠지만, 많은 후보를 같은 방식으로 처리하면 반복 피로가 커졌습니다. 그래서 기본 5개를 기준으로 카드 방식과 목록 방식을 나눴고, 사용자가 원하는 방식을 고정하거나 전환 기준을 바꿀 수 있게 했습니다.

목록 방식에서는 기본 쏙을 먼저 적용한 뒤 필요한 장소만 다른 쏙으로 바꾸거나 제외하게 했습니다. 저장할 때는 쏙별로 장소를 묶어 배치 처리하고, 완료 뒤에는 저장한 핀을 지도에서 바로 확인하게 연결했습니다.

관련 기록 · 장소가 적을 때와 많을 때, 쏙핀의 저장 방식을 다르게 만든 이유

Lambda로 필요한 순간에만 실행하기

공유 URL을 확인하는 작업은 계속 켜져 있는 서버가 아니라 요청이 있을 때만 실행되면 되는 작업입니다. 초기 제품 단계에서 유휴 시간까지 서버 비용을 내는 것은 아까웠고, 그래서 이 처리 흐름을 Lambda 기반으로 구성했습니다.

사용자가 공유를 요청하면 함수가 실행되고, 필요한 메타데이터와 장소 후보를 정리한 뒤 결과를 돌려줍니다. 덕분에 초기에 비용을 과하게 고정하지 않으면서도 기능을 빠르게 검증할 수 있었습니다.

장소를 지도 위의 정보로 연결하기

인스타그램 게시물에서 얻은 단서만으로는 사용자가 바로 길을 찾기 어렵습니다. 그래서 Google Places 연동을 통해 장소 후보의 이름·주소·좌표 같은 구조화된 정보를 확인하고, 저장 결과가 실제 지도 위의 핀이 되도록 연결했습니다.

국내에서 장소를 다시 확인하고 이동하는 경험에는 네이버 지도 연동도 중요했습니다. 쏙핀 안에서 저장한 장소를 보고, 사용자가 익숙한 지도 서비스에서 바로 길찾기로 이어지도록 연결했습니다. 데이터 수집이 아니라 사용자 이동 경험을 연결하는 용도입니다.

저장이 많아졌을 때의 지도 경험

저장한 장소가 늘어나면 지도는 곧바로 복잡해집니다. 그래서 가까운 핀을 묶어 보여 주는 클러스터링을 적용했습니다. 넓은 범위에서는 장소의 밀도를 먼저 이해하고, 지도를 확대하면 개별 장소를 확인할 수 있도록 했습니다.

폴더별 색상과 필터도 같은 이유로 만들었습니다. 지도는 단순한 결과 화면이 아니라, “이 근처에 내가 저장한 곳이 있나?”를 빠르게 답하는 도구여야 했습니다.

개발·사업적으로 남은 판단

AI 추출은 답이 아니라 검색 품질을 높이는 단계다

처음에는 텍스트에서 장소를 바로 확정하고 싶었습니다. 하지만 게시물은 지점명, 별칭, 메뉴, 지역 단서가 섞여 있어 한 번의 추출만으로는 정확도를 보장하기 어려웠습니다. 그래서 Gemini의 결과를 최종 데이터가 아니라 Places 검색을 더 잘하기 위한 후보로 두었습니다. 이 구조가 잘못된 저장을 줄이고, 모델이나 프롬프트를 바꿔도 제품의 핵심 데이터 흐름을 지킬 수 있게 했습니다.

외부 의존성은 기능보다 먼저 운영 비용과 위험을 계산해야 한다

공유 링크 처리에는 AI API, 장소 API, 외부 웹 페이지가 함께 들어갑니다. 기능 하나를 만들 때도 요청당 비용, 실패율, 정책 변경, 속도 저하를 함께 봐야 했습니다. Lambda를 선택한 이유도 초기 트래픽에서 상시 서버를 유지하는 비용보다 요청 기반 비용이 더 합리적이었기 때문입니다. 제품 초기에는 “잘 돌아가는가”와 함께 “트래픽이 없어도 얼마나 드는가”를 봐야 한다는 판단이 남았습니다.

지도 UX는 정보량이 아니라 탐색 밀도를 다루는 문제다

장소가 적을 때는 모든 핀을 보여 주는 것이 편합니다. 하지만 저장이 쌓이면 그것은 곧 노이즈가 됩니다. 클러스터링, 폴더별 색상, 필터는 보기 좋은 장식이 아니라 사용자가 어느 범위에서 무엇을 찾는지에 따라 정보 밀도를 조절하는 장치였습니다. 지도 기능을 만들 때는 핀을 찍는 것보다, 데이터가 늘어난 뒤에도 탐색이 무너지지 않는지를 먼저 설계해야 했습니다.

배포된 제품은 사용자 흐름만큼 측정과 수정의 흐름이 중요하다

공유에서 저장까지의 과정은 짧지만, 어느 단계에서 멈추는지에 따라 문제의 원인이 완전히 달라집니다. 링크 확인 실패, 장소 후보 불일치, 지도 저장 전 이탈을 구분해서 볼 수 있어야 제품을 개선할 수 있습니다. 앞으로 기능을 추가할 때도 화면을 만드는 것과 함께, 어떤 신호를 보고 다음 판단을 할지까지 설계하려 합니다.