A Builder in New Orleans: When Your Vibecoded App Comes on Vacation
뉴올리언스에 가져간 바이브코딩 앱, 여행에서 드러난 다음 과제
여행 계획 앱 Le Voyage를 뉴올리언스에서 실제로 쓰면서, 만든 사람은 장소를 모으는 일보다 이미 모은 장소 가운데 무엇을 고를지 돕는 일이 더 큰 문제임을 발견합니다. 이 경험을 바탕으로 AI의 역할, 소규모 맞춤형 소프트웨어의 가치, 바이브코딩 앱을 안전하게 고치는 순서를 되짚습니다.
- 주제
AI 요약
Le Voyage는 여행 일행이 식당과 관광지, 메모와 일정을 한곳에 모으는 웹 앱입니다. 파리 여행을 앞두고 만들었지만 정작 파리에서는 거의 쓰지 않았습니다. 약 9개월 뒤 뉴올리언스 여행에서는 달랐습니다. 작성자와 여동생이 실제로 앱을 열어 아침 식사와 다음 일정을 정했고, 그 과정에서 책상 앞에서는 보이지 않던 문제와 기능의 가치를 확인했습니다.
여행에서 드러난 자잘한 기능의 가치
여행을 떠나기 약 일주일 전, 작성자는 앱을 실제로 쓸 상황을 생각하며 손을 봤습니다. 여행별 필터와 지도 설정을 저장하고, 장소 정렬 기능을 넣었습니다. 메모와 일정 링크가 달린 장소를 실수로 지우지 않도록 삭제 확인 단계도 추가했습니다. 지도 조작을 개선하고 카테고리를 편집할 수 있게 했으며, 사용 중이던 AI 모델이 낡아 관련 기능도 손봤습니다.
화려한 기능은 아니었지만 여행 중에는 모두 쓸모가 있었습니다. 필터가 새로고침 뒤 초기화되는 문제는 책상 앞에서는 사소해 보여도 낯선 동네를 걸으며 아침 식사 장소를 고를 때는 성가십니다. 작성자는 실제 사용을 거치며 소프트웨어의 평범한 부분이 얼마나 중요한지 알게 됐습니다.
첫 식사 장소 MRB는 이미 앱에 저장돼 있었습니다. 여동생이 남긴 메모는 “FQ, 다이브 바, ‘독한 술’, 야외 좌석, ‘굴 바’”처럼 짧았습니다. 이 메모를 보고 장소 카드를 열어 Google에서 후기와 메뉴, 위치를 확인한 뒤 식당을 골랐습니다. 메모는 여행 글처럼 완성된 문장이 아니어도 기억을 되살리는 데 충분했습니다.
장소 수집에서 선택 지원으로
두 사람이 여행지 정보를 함께 추가하고 같은 목록과 메모를 쓰면서 앱은 작성자의 프로젝트를 넘어 일행의 도구가 됐습니다. 여동생이 뉴올리언스 장소 대부분을 추가했고, 둘은 아침과 여행 중간중간 앱을 열었습니다. 데이터가 작성자 혼자 만든 목록이 아니라 함께 쌓은 기록이 되자 약점도 더 분명해졌습니다.
앱은 관심 장소를 기억하는 문제를 해결했지만, 두 사람은 이미 68곳을 저장했습니다. 아침 식사인지, 술을 마실 곳인지, 가까운 곳인지 찾으려면 목록을 계속 훑어야 했습니다. 집에서 보면 68곳은 풍부한 자료였지만, 버번 스트리트에서 지친 채 다음 목적지를 정할 때는 일이 됐습니다. 문제는 장소를 발견하는 데서 고르는 데로 옮겨갔습니다.
앱에는 AI 추천 기능이 이미 있지만, 작성자는 그 기능이 아직 특별히 유용하지 않다고 말합니다. 뉴올리언스 식당을 새로 찾아 목록을 하나 더 만드는 일은 Yelp가 이미 합니다. 일행에게 필요했던 건 프렌치쿼터에서 아침을 먹고 싶을 때 기존 목록 가운데 걸어서 갈 만한 곳 세 곳을 고르는 기능이었습니다. 술이나 간식, 평점이 높은 근처 장소도 같은 방식으로 찾을 수 있습니다. 메모와 카테고리, 일행이 이미 고른 장소를 활용해 선택지를 좁히는 역할입니다.
이 방식에서 AI는 여행지 정보를 전부 찾아주는 대신 사용자가 모아 둔 정보 안에서 결정을 돕습니다. 작성자는 먼저 규칙과 데이터로 선택 범위를 정하고, 그 안에서 모델이 사용자 상황에 맞게 설명하거나 순위를 매기는 기능을 구상합니다. 다만 다음 여행지 오악사카에 가기 전까지 서둘러 만들지는 않으려 합니다.
여행은 계획 밖의 추천도 남깁니다
뉴올리언스에서 가장 좋았던 장소 중 일부는 미리 저장한 68곳에 없었습니다. 현지인이 추천한 벅타운의 Deanie's와 프렌치쿼터의 Lafitte's Blacksmith Shop에 갔습니다. 앱은 사전에 조사한 장소는 알았지만, 현지에서 새로 알게 된 곳은 몰랐습니다.
작성자는 여행 앱이 계획과 정리에만 맞춰지면 실제 여행의 움직임을 놓칠 수 있다고 봅니다. 현지인의 추천을 듣고, 걸어 다니다 지치고, 계획을 바꾸는 경험은 미리 세운 일정만으로 설명되지 않습니다. 앱에 “Local Tip”이나 “Found Here” 같은 표시를 두면 사전에 조사한 장소와 여행 중 만난 장소를 구분할 수 있습니다. 추천한 사람이 누구인지와 언제 들었는지도 기록하면 나중에 잊기 쉬운 맥락을 남길 수 있습니다.
바이브코딩으로 만드는 작은 규모의 소프트웨어
작성자는 Le Voyage가 바이브코딩으로 만들어졌고 자동화 테스트가 사실상 없다고 밝힙니다. 돈이나 의료 정보, 기업 인프라를 다루는 앱이었다면 전혀 다른 이야기를 했을 거라고 덧붙입니다. 하지만 이 앱은 작성자와 가족, 여행 친구 몇 명이 쓰며 호스팅과 데이터베이스 비용도 거의 들지 않습니다. AI 호출 비용도 가끔 발생하지만, 현재 AI 기능은 그 비용만큼 제 역할을 하지 못한다고 합니다.
그럼에도 앱은 흩어진 링크와 메신저 대화, 스크린샷 대신 일행이 함께 보는 여행 기록을 제공했습니다. 작성자는 이런 경험을 바탕으로 “600만 명이 아니라 여섯 명을 위한 소프트웨어”를 바이브코딩이 잘 맞는 영역으로 생각합니다. 특정한 소수에게 유용하지만 사업으로 만들 만큼 시장이 크지 않은 도구도, 이제는 한 사람이 만들어 쓸 수 있다는 뜻입니다. Le Voyage를 SaaS로 키우거나 수익화할 생각은 크지 않습니다. 두 사람에게 맞춘 표현과 메모가 더 넓은 시장을 위한 제품 요건에 맞지 않아도 괜찮다고 말합니다.
다음 기능보다 먼저 QA
실제 사용은 앱의 목적도 바꿨습니다. 작성자는 처음에 여행지를 모으는 도구를 만든다고 생각했지만, 뉴올리언스에서 목록을 어떻게 활용할지가 더 어려운 문제임을 알았습니다. 테스트는 소프트웨어가 예상대로 동작하는지 묻지만, 실제 사용은 그 예상 자체가 맞았는지 드러냅니다.
오악사카 여행을 앞두고 작성자는 상황별 추천, 현지인 추천 기록, 더 나은 검색, 시간과 피로도에 따라 달라지는 ‘근처’의 의미를 기능 아이디어로 떠올립니다. 하지만 실제 여행 기록과 메모가 앱에 쌓였고 가족도 사용하므로, 기능을 더하기 전에 무엇을 망가뜨릴 수 있는지 확인하겠다고 합니다. 현재 테스트 수준은 앱을 열고 직접 눌러 보는 정도에 가깝습니다. 그래서 우선순위는 새 기능보다 QA입니다. 앱은 완성되지 않았고 README에는 여전히 Lovable 프로젝트 안내가 남아 있으며 테스트도 부족하지만, 가족이 반복해서 썼고 이제 오악사카에도 가져갑니다.
dev.to 반응
- @sinarezaei — “여섯 명을 위한 소프트웨어, 600만 명을 위한 게 아닌 소프트웨어”라는 부분이 특히 와닿았습니다. 여기에 놓치기 쉬운 기술적 결과가 있습니다. 앱이 신뢰할 수 있는 소규모 데이터셋을 중심으로 만들어지면 AI가 더는 진실의 출처일 필요가 없습니다. 사용자의 실제 맥락 위에서 결정을 돕는 계층이 되면 됩니다. 예를 들어 LLM에게 “프렌치쿼터에서 가장 좋은 아침 식사 장소가 어디인가요?”라고 묻는 대신, 먼저 사용자의 기록에서 아침 식사 장소와 프렌치쿼터를 걸러내고 도보 15분 이내, 평점 순으로 세 곳을 고를 수 있습니다. 그러면 모델은 메모와 선호, 현재 상황을 바탕으로 그 세 곳을 설명하거나 순위를 매기면 됩니다. 검색과 필터링이 경계를 정하고 모델이 사람다운 맥락을 다루는 구분은 AI 기능에서 중요합니다. 그렇지 않으면 챗봇을 붙인 또 다른 Yelp를 만들게 됩니다. 테스트와 실제 사용의 차이에 관한 말도 더 큰 교훈 같습니다. 새로고침 때 필터가 초기화되는 일은 버번 스트리트에서 앱을 써서 아침 식사를 고르기 전까지 사소한 버그로 치부하기 쉽습니다. 실제 사용을 하면 ‘예외 상황’이 요구사항으로 바뀌곤 합니다.
- @earlgreyhot1701d — 좋은 의견 감사합니다. 네, 이제는 경계가 정해진 부분과 AI 부분을 나누는 방식이 마음에 듭니다. Le Voyage를 만들 때는 아직 제 경험이 초기라 이런 구분을 말로 설명하지 못했지만, 이후 만든 앱에서는 규칙이 범위를 정하고 모델이 그 안에서 복잡한 부분을 맡는 경우가 많습니다. 예시로 든 코드는 버번 스트리트에서 있었으면 했던 바로 그 기능입니다. 테스트와 실제 사용에 관한 말도 맞습니다. 처음에는 목록을 만드는 앱이라고 생각했지만, 써 보니 목록 작성은 앱이 해야 할 일의 일부일 뿐이었습니다. 책상 앞에서는 떠올릴 수 없었을 기능입니다. “실제 사용은 예외 상황을 요구사항으로 바꾼다”는 말도 기억에 남습니다. 실사용자 확보에 관한 논의와도 이어집니다. 제 앱 중 상당수는 해커톤용이라 이론 속에 머뭅니다. 실제로 앱을 밖에서 써 보고 고장 내는 경험은 무척 즐거웠습니다. 다만 급히 고칠 일이 생겨도 컴퓨터를 가져오지 않아 조금 불안하기도 했습니다.
- @elijahbrown — “Local Tip”이나 “Found Here”를 넣는다면 장소를 추가할 때 누가 언제 추천했는지도 기록하겠습니다. 일주일 뒤에는 그 부분을 기억하지 못하니까요. 길거리에서 장소 이름과 그 항목 하나만 입력하면 되고 나머지는 선택 사항이어야 술집에 서서도 실제로 기록할 수 있습니다. 카테고리와 동네는 호텔로 돌아간 뒤에 추가해도 됩니다.
- @earlgreyhot1701d — 좋은 지적입니다. 뉴올리언스에서 기억에 남은 건 사람들이었다고 썼는데, Deanie's를 추천해 준 사람이 누구였는지도 기억하고 싶습니다. 도착 첫날 밤, New Orleans Saints 팬이었던 분이 그곳을 알려줬습니다.
원문: dev.to / 번역·요약: Trawling