Dog Agent 만들기: 왜 반려견 산책 모험을 위한 AI 기반 커뮤니티를 만들었는가 (그리고 그 과정에서 무엇이 망가졌는가)

솔직히 말해서, 제 반려견을 위한 앱을 만드는 것에 대해 기술적인 글을 쓰게 될 줄은 꿈에도 몰랐습니다. 3개월 전만 해도, 제 골든 리트리버가 새로운 산책 경로를 찾을 수 있도록 80시간 이상 코딩에 매달리게 될 거라고 말했다면 저는 당신을 비웃었을 겁니다. 하지만 우리는 지금 여기에 와 있고 — 솔직히 말해서, 이것은 제가 지난 몇 년간 만든 사이드 프로젝트 중 가장 놀랍도록 재미있는 프로젝트 중 하나였습니다.

잠시 시간을 되돌려 보겠습니다. 제 반려견 Max는 3살이며 수천 마리의 강아지가 모인 것 같은 에너지를 가지고 있습니다. 우리는 매일 산책을 나가고, 매일 새로운 경로를 기대합니다. 만약 같은 경로를 너무 여러 번 반복하면, 그는 중간에 지루해하며 인도에 엉덩이를 붙이고 앉아 움직이기를 거부합니다. 농담이 아닙니다 — 실제로 그것이 이 프로젝트 전체를 시작하게 된 계기였습니다.

저는 AllTrails, Google Maps, 심지어 몇몇 반려견 전용 산책 앱까지 일반적인 앱들을 모두 시도해 보았습니다. 하지만 그 어떤 것도 저의 문제를 진정으로 해결해주지는 못했습니다. 저는 도시에서 50마일 떨어진 인기 있는 하이킹 코스가 필요했던 것이 아닙니다. 저는 실제로 그곳을 산책하는 지역의 다른 반려견 주인들이 공유하는, 반경 2마일 이내의 흥미롭고 새로운 동네 산책로를 찾을 필요가 있었습니다. 그리고 저는 AI가 우리의 에너지 수준에 맞는 경로를 추천해 주기를 원했습니다 — 때로는 빠른 20분짜리 루프를 원하고, 때로는 풀밭과 수영할 수 있는 장소가 많은 2시간짜리 모험을 원하기 때문입니다.

그래서 저는 반려견이 지루해할 때 모든 엔지니어가 하는 일을 했습니다: 저만의 앱을 만든 것입니다. 그렇게 Dog Agent가 탄생했습니다.

Dog Agent란 무엇인가?

Dog Agent는 반려견 산책 모험을 위한 오픈 소스 (open-source) AI 기반 커뮤니티입니다. 이를 통해 다음과 같은 것들을 할 수 있습니다:

• 가장 좋아하는 반려견 산책 경로 공유
• 위치와 거리를 기반으로 주변의 새로운 경로 발견
• 사용자의 에너지 수준과 반려견의 성격에 맞는 AI 추천 받기
• 즐겨 찾는 경로를 저장하고 다녀온 곳 기록하기
• 모든 사진은 저장 공간 절약을 위해 자동으로 압축됨 (정말 필요할 거예요)
• 개인정보 보호 우선: 모든 개인 데이터는 사용자의 통제하에 유지되며, 누구에게도 데이터를 판매하지 않음

기술 스택 (tech stack)은 다음과 같습니다:

• 백엔드 (Backend): Go (빠르고 단순하며, 단일 바이너리로 컴파일되기 때문에 사이드 프로젝트에 완벽합니다)
• 모바일 앱 (Mobile App): React Native (iOS와 Android 모두에서 작동하므로 한 번만 작성하면 됩니다)
• 데이터베이스 (Database): 공간 쿼리 (spatial queries)를 위한 PostGIS 확장이 포함된 PostgreSQL (이 마법 같은 기능에 대해서는 나중에 더 자세히 다루겠습니다)
• AI: 경로 추천을 위한 OpenAI text-embedding-3-small + 코사인 유사도 (cosine similarity) 매칭
• 스토리지 (Storage): 사진을 위한 Cloudflare R2 (데이터 전송 비용(egress fees)이 없음 — 사이드 프로젝트의 게임 체인저입니다)

전체 코드는 여기서 확인할 수 있습니다: https://github.com/kevinten10/dog-agent

솔직히 말해서 아직 베타 버전입니다. Android 테스트는 거의 완료되었지만 몇 가지 문제점들을 다듬고 있는 중입니다. 하지만 이미 소수의 지역 반려견 견주들이 매일 사용할 정도로 충분히 잘 작동합니다. 그래서 제가 이 프로젝트를 만들며 배운 것들 — 좋은 점, 나쁜 점, 그리고 "왜 한 달 만에 청구 금액이 80달러나 급증했는가"에 대한 부분을 공유하고 싶었습니다.

좋은 점: PostGIS가 모든 것을 바꾸어 놓았다

이 프로젝트를 시작했을 때, "내 현재 위치에서 2마일 이내의 모든 경로 찾기"와 같은 공간 쿼리 (spatial queries)를 수행해야 한다는 것을 알고 있었습니다. 처음에는 Elasticsearch나 다른 화려한 별도의 공간 데이터베이스가 필요할 것이라고 생각했습니다. 하지만 곧 기억해 냈습니다. PostgreSQL에는 PostGIS가 있고, 이것이 실제로 이런 작업에 매우 뛰어나다는 사실을 말이죠.

저는 대부분의 사이드 프로젝트 공간(spatial) 요구 사항을 충족하기 위해 화려하고 특화된 공간 데이터베이스(spatial database)가 필요하지 않다는 것을 고생 끝에 배웠습니다. PostGIS는 제가 필요한 모든 것을 수행하며, 확장을 활성화하기만 하면 이미 일반적인 PostgreSQL 설정의 일부로 포함되어 있습니다.

기본적인 설정 방법은 다음과 같습니다:

-- PostGIS 확장 활성화
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS postgis_topology;
...

그러고 나서 근처의 경로를 쿼리하는 것은 정말 간단합니다:

// Go 코드 예시: 현재 위치에서 2km 이내의 모든 경로 찾기
query := `
  SELECT 
...

이게 전부입니다. 이것이 공간 쿼리(spatial query)의 전부입니다. 제가 생각했던 것보다 100배는 더 간단하며, 빠릅니다. 수천 개의 경로가 있더라도 쿼리는 20-30ms 내에 반환됩니다. 저는 충격을 받았습니다.

여기서 얻은 핵심 교훈은 이것입니다: 일을 너무 복잡하게 만들지 마세요. PostGIS는 대부분의 사람들이 공간 애플리케이션(spatial applications)을 위해 필요로 하는 기능의 99%를 수행합니다. 수백만 개의 경로를 보유하기 전까지는 화려하고 특화된 솔루션이 필요하지 않습니다. 이와 같은 사이드 프로젝트에는 완벽합니다.

AI 부분: 단순한 것이 복잡한 것보다 낫다

이와 같은 서비스에 AI 추천(AI recommendation)을 적용하는 것에 대해 말씀드리자면, 모델 전체를 처음부터 훈련할 필요는 없습니다. Max가 어떤 종류의 경로를 좋아하는지 학습하도록 모델을 미세 조정(fine-tuning)하는 것을 생각해보았지만, 솔직히... 그것은 과잉 대응(overkill)입니다.

대신 제가 하는 방식은 다음과 같습니다:

1. 사용자가 경로를 생성할 때 짧은 설명을 작성합니다: "풀밭이 많고 평탄한 산책로, 강가 접근 가능, 너무 붐비지 않음"
2. OpenAI의 text-embedding-3-small을 사용하여 해당 설명에 대한 임베딩 (embedding)을 생성합니다.
3. 사용자가 "강가에 접근할 수 있는 평탄한 산책을 원해"라고 말하면, 해당 쿼리에 대한 임베딩을 생성합니다.
4. 쿼리 임베딩과 모든 경로 임베딩 사이의 코사인 유사도 (cosine similarity)를 계산합니다.
5. 유사도와 거리를 기준으로 정렬하여 상위 일치 항목을 반환합니다.

이게 전부입니다. 이것이 AI 추천 시스템의 전부입니다. 약 50줄의 코드로 놀라울 정도로 잘 작동합니다.

다음은 Go 언어로 작성된 임베딩 생성 코드입니다:

package main

import (
...

저는 전체 1536 차원 대신 512 차원을 사용합니다. 이렇게 하면 임베딩 크기가 3분의 2가 줄어들고, 제 사용 사례에서는 추천 품질에 아무런 차이를 느끼지 못했습니다. 비용은요? 무시할 만합니다. 512 차원은 임베딩당 512개의 float이며, 이는 경로(route)당 2KB입니다. 10,000개 경로를 사용하더라도 20MB에 불과합니다. 아무것도 아닙니다.

그리고 OpenAI API 비용은요? 임베딩당 $0.00002입니다. 따라서 1,000개의 임베딩을 생성해도 단 두 센트밖에 들지 않습니다. 장난합니까? 이건 아무것도 아니에요.

이 접근 방식이 너무 단순할까 봐 걱정했지만, 솔직히 말해서 — 기대했던 것보다 더 잘 작동합니다. 사용자들은 실제로 자신이 요청하는 내용과 일치하는 추천을 받게 되고, 저는 복잡한 AI 인프라를 유지 관리할 필요가 없습니다.

예상치 못한 놀라운 어려움들

자, 현실적으로 이야기해 봅시다. 모든 것이 순조롭게 진행된 것은 아닙니다. 저를 완전히 당황하게 만든 세 가지 가장 큰 어려움을 소개합니다.

1. Mapbox 가격 책정 때문에 난감했습니다

저는 React Native 앱에 지도를 표시하기 위해 처음에는 Mapbox를 사용하기 시작했습니다. 그들의 무료 등급은 월간 활성 사용자(MAU) 50,000명입니다. 이건 지역 반려견 산책 앱을 운영하는 데 제가 필요로 할 것보다 훨씬 많은 수처럼 들리죠? 아닙니다.

잠깐만요 — 사실, 제가 가격 책정을 잘못 읽었습니다. Mapbox의 가격은 _월별_이며, 월간 활성 사용자를 기준으로 합니다. 하지만 함정이 있습니다. 무료 등급을 초과하면 단순히 추가 사용량에 대해서만 청구되는 것이 아니라, 모든 사용자에게 소급하여 청구됩니다. 그래서 지역 반려견 주인 12명이 정기적으로 사용하기 시작했을 때, 저는 $80의 청구서를 받았습니다. 단 12명의 사용자에게요. 이건 제 서버 전체 비용보다 많은 금액입니다.

저는 충격을 받았습니다. Mapbox가 저렴하지 않다는 것은 알고 있었지만, 그런 가격 모델은 예상하지 못했습니다. 그래서 현재 대안을 평가하고 있습니다 — Google Maps는 소규모 앱에 더 나은 가격 모델을 가지고 있으며, 오픈 소스인 MapLibre도 있습니다. 아직 전환하지는 않았지만, 확실히 로드맵에 포함되어 있습니다.

배운 교훈: 제3자 서비스를 통합하기 전에는 항상 가격 책정의 세부 사항을 읽으세요.

사용자들이 산책 사진과 강아지 사진을 업로드할 때, 그 사진들은 매우 큽니다. 최신 스마트폰의 12MP(메가픽셀) 사진처럼 사진 한 장당 4-5MB에 달합니다. 만약 이를 있는 그대로 저장하고 직접 서비스한다면, 스토리지(Storage)와 대역폭(Bandwidth)을 매우 빠르게 소진하게 될 것입니다.

저는 일주일 만에 이 사실을 뼈아프게 배웠습니다. 사진 50장이 업로드되었을 뿐인데 이미 200MB의 스토리지를 사용했습니다. 별로 많아 보이지 않을 수도 있지만, 앱이 성장한다면 이는 빠르게 불어납니다.

그래서 업로드 전 클라이언트 측에서 자동 이미지 압축(Image Compression) 기능을 추가했습니다. React Native에서는 react-native-image-compressor 패키지를 사용하여 매우 간단하게 구현할 수 있습니다:

import ImageCompressor from 'react-native-image-compressor';

const compressedImage = await ImageCompressor.compress(imageUri, {
...

그게 전부입니다. 이렇게 하면 대부분의 사진 용량이 모바일로 보기에는 품질 저하가 거의 느껴지지 않는 수준인 200-300KB로 줄어듭니다. 10배나 작아진 것이죠. 게임 체인저(Game-changer)입니다. 저는 첫날부터 이 작업을 했어야 했습니다. 저와 같은 실수를 하지 마세요.

3. 개인정보 보호가 중요합니다 — 반려견 산책 앱이라 할지라도

이 앱은 커뮤니티 앱이기 때문에, 사용자들은 현재 위치와 즐겨 찾는 경로를 공유합니다. 저는 기본적으로 모든 경로를 공개(Public)로 만들까 생각했지만, 문득 이런 생각이 들었습니다. 만약 누군가가 정말 조용한 자신만의 비밀 장소를 공유했는데, 다음 주말에 수백 명의 사람이 나타난다면 어떻게 될까요? 그것은 모두의 경험을 망치는 일입니다.

그래서 개인정보 보호 설정(Privacy Controls)을 추가했습니다. 각 경로에 대해 다음과 같이 선택할 수 있습니다:

• 공개 (Public, 모두에게 보임)
• 미등록 (Unlisted, 링크가 있는 사람에게만 보임)
• 비공개 (Private, 본인에게만 보임)

이렇게 하면 사람들은 원할 경우 자신만의 비밀 장소를 비밀로 유지할 수 있습니다. 저는 이것이 매우 중요하다고 생각합니다. 특히 과도한 이용이 좋은 환경을 망칠 수 있는 하이킹이나 반려견 산책 같은 활동에서는 더욱 그렇습니다.

또한 모든 사용자 인증(User Authentication)은 기존의 이메일/비밀번호 방식과 JWT(JSON Web Token)로 처리하고, 사진은 제가 직접 운영하는 Cloudflare R2 버킷(Bucket)에 저장하기 때문에, 저장을 위해 사용자 데이터를 제3자에게 보낼 필요가 없습니다. 이는 개인정보 보호 측면에서 이점이며, 비용을 예측 가능하게 유지해 줍니다.

장단점: 솔직하게 말해봅시다

너무 많은 프로젝트의 README(리드미)들이 좋은 점만 나열하고 나쁜 점은 무시한다고 생각합니다. 그래서 Dog Agent와 AI 기반 커뮤니티 앱을 구축하는 이 방식에 대한 저의 솔직한 장단점 분석을 공개합니다.

장점

1. 실제 개인적인 문제를 해결함: 이 프로젝트는 단순히 "AI를 배우기 위해" 또는 "VC(벤처 캐피털) 투자를 받기 위해" 만든 것이 아닙니다. 제가 실제로 필요해서 만들었습니다. 이는 상황이 답답해질 때 동기 부여를 유지해 줍니다.

2. 단순한 아키텍처, 쉬운 해킹 (Hack): 화려한 마이크로서비스(Microservices)나 Kubernetes(쿠버네티스) 없이, 그저 Go 백엔드 + React Native 앱 + PostgreSQL로 구성되어 있습니다. 무엇을 해야 하는지 알고 있다면 10분 안에 전체 시스템을 로컬에서 실행할 수 있습니다.

3. 설계 단계부터 고려된 개인정보 보호 (Privacy by design): 사용자가 자신의 데이터를 직접 제어하며, 사용자 데이터를 판매하지 않습니다. 모든 것이 오픈 소스(Open source)이므로 원한다면 직접 호스팅(Self-host)할 수도 있습니다.

4. 비용이 거의 들지 않음: 활성 사용자 100명 기준, 저의 총 월간 비용은 다음과 같습니다: 서버 $5, Cloudflare R2 $0.10, OpenAI 임베딩 (embeddings) $0.50. 그게 전부입니다. 예상보다 훨씬 저렴합니다.

5. AI가 복잡할 필요는 없음: 단순한 임베딩 (embeddings) + 코사인 유사도 (cosine similarity)만으로도 대부분의 추천 사용 사례에서 80%의 효과를 얻을 수 있으며, 비용이 매우 저렴하고 유지보수가 쉽습니다.

단점

1. 여전히 베타 버전이며, Android 테스트가 완전히 이루어지지 않음: 저는 iOS 사용자이기 때문에 Android 테스트가 더뎠습니다. 만약 Android 개발자이시고 도움을 주고 싶으시다면, PR(Pull Request)을 환영합니다!

2. Mapbox 의존성을 여전히 교체해야 함: 앞서 언급했듯이, 성장에 따른 가격 책정이 매우 부담스럽습니다. 현재 MapLibre로 전환하는 작업을 진행 중입니다.

3. 아직 소셜 기능이 없음: 댓글, 좋아요, 다른 반려견 산책러 팔로우 기능이 없습니다. 이는 로드맵(Roadmap)에 포함되어 있지만, 아직 완료되지 않았습니다.

4. 셀프 호스팅(Self-host) 시 개인 OpenAI API 키가 필요함: 개발자들에게는 큰 문제가 아니지만, 기술적 지식이 없는 사용자들은 쉽게 실행하기 어렵다는 것을 의미합니다.

5. 추천 품질이 사용자 설명에 의존함: 사람들이 설명을 제대로 작성하지 않으면 추천 품질도 떨어집니다. 이는 이 방식의 내재적인 한계입니다. 메타데이터에서 더 나은 설명을 자동으로 추출하는 작업을 진행 중이지만, 아직 완벽하지는 않습니다.

이것을 만들며 배운 점

솔직히 이 프로젝트는 저를 놀라게 했습니다. 반려견을 즐겁게 해주기 위한 사소한 사이드 프로젝트(Side project)로 시작했지만, 예상치 못했던 많은 것들을 배우게 되었습니다: