🧑💻 오늘의 메이커 : 유민준 개발자님
오늘 함께할 메이커는 햇빛과 이동 조건을 함께 고려하는 길찾기 앱 ‘그늘로: 뚜벅의 여름길’을 만든 유민준 님입니다.
그늘로는 건물과 가로수의 그림자, 태양의 움직임을 계산해 그늘이 많은 도보 경로를 안내합니다. 이제는 대중교통을 이용할 때의 도보 구간과 버스 창가, 산책, 러닝 코스까지 다루며 ‘그늘길 앱’을 넘어 개인의 상황에 맞는 이동 경험으로 범위를 넓혀가고 있어요.
오늘 인터뷰에서는 그늘로가 하나의 이동 경험으로 확장된 과정, AI의 제안을 실제 제품으로 바꾸는 검증 방식, 갑작스러운 성장 이후의 우선순위, 그리고 유민준님이 다음으로 해결하고 싶은 문제에 대해 이야기 나눴습니다.
레시피 하나, 그늘길에서 ‘개인화된 이동’으로
Q. 안녕하세요! 팁스터 구독자분들께 간단한 자기소개 부탁드립니다.
안녕하세요! ‘그늘로: 뚜벅의 여름길’ 앱을 개발하고 서비스를 제공하고 있는 서울대학교 수학교육과 23학번 벤처경영학 전공 유민준입니다.
통학길에서 직접 느낀 불편으로 시작했는데, 많은 분들의 관심 덕분에 반려견과 산책하는 분들, 유모차를 끄는 부모님, 출퇴근하는 직장인과 러너까지 각자의 방식으로 이동 방식을 확장해나가고 있습니다. 최근 누적 사용자가 10만 명까지 늘면서 더 많은 사람의 일상과 맞닿은 서비스로 만들어가고 있습니다.
Q. 현재는 그늘길뿐 아니라 버스 창가, 러닝 코스까지 이동 경험을 확장하면서 가장 중요하게 생각한 사용자 경험은 무엇이었나요?
기존 상용 지도 서비스는 오랜 기간 쌓아온 데이터가 많기 때문에 시간 정보나 대중교통 정보, 도보 네트워크의 정확도와 성능에서 분명한 격차가 있다고 생각해요. 그 부분을 계속 개선하는 것도 중요하지만, 제가 가장 우선하는 건 기존 길찾기에서 해결하지 못했던 불편과 개인의 조건을 반영하는 일이었습니다.
저와 비슷한 사용자뿐만 아니라, 자신에게 맞는 이동 경험을 원하는 모든 분들에게 도움이 되는 앱이 되었으면 해요. 그래서 사용자가 기능을 이해하고 선택하는 흐름은 최대한 단순하게 만들고, 정확도와 성능은 그다음 과제로 꾸준히 개선해가려고 합니다.
Q. 많은 분들의 관심을 받으며, 처음 생각했던 타깃이나 제품 방향이 달라지기도 했을까요?
처음에는 제가 통학할 때 조금 더 편하게 다니자는 생각으로 만들었어요. 그래서 “출퇴근길에 정말 도움이 된다”는 반응이 가장 먼저 와닿았죠. 그런데 출시하고 보니 제가 처음에는 생각하지 못했던 사용자들이 있었어요. 반려견과 산책하는 분, 유모차를 끄는 분들이 그늘이 있는 길을 필요로 한다는 피드백을 주셨거든요.
그 의견을 계기로 산책 기능을 차근차근 만들기 시작했어요. 초기에는 러닝 기능도 없었는데, 더운 날에도 야외에서 달리는 분들이 기능을 많이 요청해 주셔서 개발하게 됐고요. 저도 실제로 밖에 나가 그늘진 곳으로 뛰어보며 테스트했어요. 처음에는 한 명의 통학생을 떠올렸지만, 사용자들의 생활을 만나면서 서비스의 페르소나가 넓어진 셈이에요.
Q. 공공데이터를 활용하고 핵심 기능을 무료로 제공하고 있어요. 많은 사람이 쓸 수 있는 서비스와 수익성 사이에서는 어떤 판단을 하셨나요?
처음부터 사업으로 크게 시작한 서비스가 아니라, 복학을 앞둔 학생이 만든 사이드 프로젝트였어요. 출발점도 “내가 편하게 다니자”였기 때문에 제가 잘 쓰면 되고, 다른 분들이 사용하지 않아도 괜찮다는 마음이었죠. 그래서 공개하거나 무료로 제공하는 데 큰 부담이 없었어요.
물론 수익성을 전혀 생각하지 않은 건 아니에요. 다만 애초에 운영비가 많이 들지 않는 구조로 설계했고, 현재는 운영비를 충당할 수 있는 정도의 광고를 붙여 서비스하고 있습니다.
Q. 반대로 그늘로에 의도적으로 넣지 않으려는 기능도 있나요?
전문적인 분석 도구 수준의 기능을 원하는 분들도 계셨어요. 하지만 지금 확보할 수 있는 공공데이터만으로는 그 정도의 정확성을 내기 어렵다고 판단했어요. 모든 지역의 3D 형상이나 충분히 정밀한 GIS 정보가 필요할 텐데, 현재 데이터의 품질이 거기까지 미치지는 않거든요.
저에게도 지리 정보를 다루는 건 이번이 처음이라, 전문 분석 도구가 요구하는 수준까지 책임 있게 제공하기는 어렵다고 판단했어요. 할 수 있는 것보다 더 정확해 보이게 만들기보다는, 지금 검증할 수 있는 범위 안에서의 이동 경험에 집중하려고 합니다.
Q. 앱스토어, 구글 플레이스토어, 앱인토스까지 다양한 플랫폼을 대응했던 과정도 궁금해요.
처음부터 그늘로는 웹앱으로 MVP를 만들었어요. 웹앱이 작동하는 순간부터 앱인토스에도 낼 수 있겠다고 생각했어요. 실제 수요를 확인하고 피드백을 받는 발판으로 삼고 싶어서 토스에 먼저 제출했습니다.
앱인토스 콘솔은 운영 체계와 버전 관리가 편하게 구성돼 있었어요. 여러 과정이 MCP로 연결돼 있어 개발자뿐 아니라 바이브 코딩으로 처음 서비스를 만드는 비개발자에게도 친화적인 플랫폼이라고 느꼈고요.
반면 가장 까다로웠던 건 안드로이드였어요. 신규 개발자가 거쳐야 하는 비공개 테스트 절차도 있고, 세부 정책도 많아요. 무엇보다 기기마다 화면 비율과 성능이 천차만별이라 소규모 개발자가 하나씩 대응하기 쉽지 않았어요. 다만 테스트와 QA가 번거롭게 느껴지더라도, 자기 앱을 더 발전시키는 중요한 단계라고 생각하면 좋을 것 같아요.
레시피 둘, AI가 제안하고 사람은 검증한다
Q. AI로 서비스를 만들며, 내가 직접 판단하는 것과 AI의 결정을 믿는 나름의 기준도 있을 것 같아요.
아무래도 지도 기반 서비스를 처음 만들다 보니 AI가 추천해 주는 지식이 맞는지 제가 바로 판단하기 어려운 순간이 많았어요. 하지만 AI의 답은 실제 값이 아니라 학습된 모델이 만들어낸 텍스트잖아요. 그래서 구현했을 때 제대로 작동하는지는 다시 확인해야 해요. 그래서 AI가 제안한 내용을 일단 테스트하고, 그 결과를 근거로 제가 판단하는 편입니다.
문제를 인식하고 정의하는 건 제가 해요. 그 문제를 AI에 제시해 여러 방향을 추천받고, 왜 그런 방향을 제안했는지 이해하려고 공부해요. 계획의 범위가 커지면 지금 가진 조건에서 현실적인지 다시 평가받고, 자료 조사와 테스트를 거쳐 실행 계획을 세웁니다. 작업물이 나온 뒤에는 처음 정한 기준과 목표를 얼마나 달성했는지, 원하는 방향으로 구현됐는지를 다시 평가하고요.
정리하면 AI는 가능한 길을 빠르게 넓혀주지만, 어떤 길을 선택할지와 결과가 사용자에게 실제로 도움이 되는지는 제가 책임지는 구조인거죠.
Q. AI의 판단과 직접 세운 기준이 충돌했던 사례도 있었나요?
방범 시설이 많은 경로를 추천하는 기능에서 정확도 문제가 있었어요. AI는 서버 비용과 계산량을 고려해 처리 부담이 적은 방식을 먼저 제안했는데, 이 방식은 모든 시설을 같은 기준으로 계산했어요. 하지만 CCTV와 비상벨처럼 시설 종류가 다르면, 경로에서 어느 거리까지 효과가 있다고 볼지도 달라야 하거든요. 초기 제안은 계산량을 줄이는 대신 이 차이를 반영하지 못한 거였죠.
저는 사용자가 바로 알아차리지 못할 수는 있지만, 실제로 도움이 되는 경로를 만들려면 시설별 조건과 반경을 반영하는 게 맞다고 판단했어요. 그래서 제품의 목표와 사용자가 기대하는 수준을 기준으로 다시 수정했어요. AI가 놓칠 수 있는 맥락을 잃지 않으려고 기록을 많이 남기고, 프롬프트의 앞부분에도 그 기준을 명시하게끔 했습니다.
에디터 : AI가 작업 맥락을 잊거나 잘못된 답을 만들 때도 있었을 것 같아요!
최근에는 좋은 모델을 사용하면서 엉뚱한 코드를 내놓거나 환각을 만드는 문제는 초기에 비해 많이 줄었어요. 지금 더 크게 느끼는 한계는 컨텍스트의 양이에요. 작업이 길어지고 이전 내용이 압축되면 중요한 맥락이 빠질 수 있거든요.
그래서 결정과 기준을 명세로 남겨 GitHub에서 관리하고, 별도의 마크다운 PRD도 계속 최신화하고 있어요. 자동화 루틴과 훅도 연결해 AI가 순간의 대화만 보고 작업하지 않도록 보완하고 있습니다. 결국 AI를 잘 쓰는 일은 좋은 질문 한 번보다, 잊어서는 안 될 맥락을 계속 남기는 일에 더 가깝다고 느껴요.
Q. 서비스를 만드는 과정에서 기술적으로 가장 풀기 어려웠던 문제는 무엇이었나요?
가장 어려웠던 건 데이터였어요. 공공데이터는 관리 주체별로 흩어져 있고, 검수를 거쳐 공개됐더라도 추가 정제가 필요한 부분이 분명 존재해요. 그래서 여러 자료를 수집하고 같은 기준으로 가공하는 과정부터 쉽지 않았습니다.
또 지도 서비스 사용자는 다른 상용 지도 앱에서 경험한 수준의 속도와 안정성을 기대해요. 그러려면 전국 단위의 지도 데이터를 저장해두고, 사용자가 요청한 위치에 필요한 부분만 빠르게 가져오는 자료 구조와 알고리즘이 필요하죠. AI가 여러 방식을 추천해 줄 수는 있지만, 어떤 구조가 실제 성능과 장기 운영에 유리한지는 결국 테스트를 반복해야만 알 수 있었어요. 이 검증 과정에 가장 많은 에너지가 들었습니다.
에디터 : 직접 가볼 수 없는 지역도 많을 텐데, 계산 결과와 실제 현장은 어떻게 검증하셨나요?
제가 이동할 수 있는 지역에는 한계가 있으니 검증을 최대한 자동화했어요. 시뮬레이터로 위치를 바꿔가며 확인할 수 있는 스크립트를 만들고, 기능을 개발할 때마다 평가 지표를 정해 결과를 측정했습니다.
물론 자동화만으로 끝내지는 않았어요. 밖에 나갈 때마다 의식적으로 제 앱을 사용하며 사용자의 입장에서 흐름을 확인했어요. 그리고 처음부터 완벽한 성능을 만들고 공개하기보다는, 빠르게 시작해 실제 사용자에게 검증받는 방식을 중요하게 생각했어요. 토스에 일찍 공개한 것도 그 이유였구요.
레시피 셋, 2만 명이 몰린 이틀
Q. 좋은 소식이지만, 예상치 못한 관심을 받은 직후 가장 먼저 해결해야 했던 문제도 있었을 것 같아요.
네 맞아요(웃음). 바이럴이 시작됐을 때 사용하던 API의 무료 사용량이 약 1,000건 정도였어요. 무료 한도가 끝난 뒤 유료로 전환되도록 설정해 두지 않은 상태라, 먼저 결제를 연결하고 다른 API로 보강해 쿼터가 끊기지 않도록 했습니다.
트래픽이 몰리면서 무료 쿼터를 넘어서는 문제도 생겼어요. 초기에는 저와 몇십 명 정도가 쓰는 서비스를 상정했기 때문에 대규모 사용을 고려하지 않았거든요. 캐싱을 적극적으로 활용하고, 가능한 처리는 로컬에서 하도록 구조를 바꿨어요.
초기 구조가 아주 복잡하지 않아 변경 자체는 가능했지만, 대응은 급했어요. 이틀 정도 밤을 새우며 새벽에는 업데이트하고, 낮에는 인터뷰와 사용자 응대를 했던 것 같습니다. 그리고 동시에 부담도 생겼어요. 제 눈에는 아직 그 정도의 관심을 받을 만큼 완성된 앱이 아니었거든요. 더 빨리 유지보수하고 개선해야 한다는 책임감이 함께 커졌습니다.
에디터 : 정말 정신없으셨겠지만, 앱 차트 1위까지 경험한 이틀동안 어떤 마음이었나요?(웃음)
처음에는 당황스러웠고, 최대한 빨리 처리해야 한다는 생각에 정말 정신이 없었어요(웃음). 그래도 많은 분이 앱을 알게 되고 연락을 주시는 건 정말 기뻤습니다. 개인 개발자로서 언젠가 이루고 싶었던 일을 하루이틀 만에 경험하고, 전체 차트 1위까지 해봤으니까요. 중학교 때부터 개발을 배우며 꿈꿨던 순간이어서 감사했어요.
에디터: 우와 중학교 때부터 직접 서비스를 만들어오셨다고요?
네, 코딩은 초등학생 때 알고리즘 대회에 나가면서 익숙해졌고, 중학교 때는 학교 정보를 받아볼 수 있는 안드로이드 앱을 공모전에 내기 위해 만들었어요. 그때도 제가 필요하다고 느낀 걸 더 편하게 사용할 수 있도록 만드는 데 관심이 있었어요.
사실 앱이 첫 출발은 아니었어요. 불편을 해결하는 과정 자체가 재미있어서 발명도 해보고, 아두이노나 라즈베리파이 같은 하드웨어로 이것저것 만들기도 했죠. 그런데 스마트폰으로 할 수 있는 일이 많아지면서 자연스럽게 앱에 더 관심을 갖게 됐어요. 플랫폼보다는 문제를 직접 해결하는 일이 계속 좋았던 것 같아요.
Q. 다운로드 수나 사용자 수 외에 “그늘로가 잘되고 있다”고 느끼게 한 지표나 장면이 있나요?
초기에는 활성 사용자 수를 많이 봤어요. 특히 시간대에 따라 이용자가 달라지는 모습이 재미있었습니다. 하루 종일 비슷한 숫자가 유지되는 게 아니라 출퇴근 시간에 사용자가 몰렸거든요.
그걸 보면서 사람들이 단순히 화제가 된 앱을 구경하는 게 아니라, 실제 이동이 필요한 순간에 기능을 사용하고 있다는 걸 느꼈어요. “내가 정말 쓸 만한 기능을 만들었구나”라는 만족감이 들었던 장면입니다.
레시피 넷, 많이 만드는 것보다 방향에 맞게 만드는 법
Q. 사용자 요청, 데이터 보완, 새로운 기능, 서버 운영이 한꺼번에 생길 때 무엇을 먼저 하나요?
우선 할 일을 세네 단계의 우선순위로 나눠 관리하려고 해요. 긴급한 오류는 바로 핫픽스하고, 그 외에는 제가 세운 제품 계획과 방향에 얼마나 맞는지를 가장 먼저 봅니다.
예를 들어 새로 개발한 핵심 기능이 제대로 작동하지 않는 문제와, 기존 기능의 아주 특수한 사례를 추가해 달라는 요청이 동시에 들어온다면 전자를 먼저 해결해요. 더 많은 요청을 처리하는 것보다, 그늘로가 가기로 한 방향과 얼마나 맞닿아 있는지를 우선순위의 기준으로 삼습니다.
그 방향은 분명해요. 대중교통을 이용하는 뚜벅이들이 더 편하게 이동하도록 돕고, 각자의 상황과 조건에 맞춘 개인화된 이동 경험을 제공하는 종합 길찾기 앱으로 나아가는 것입니다.
Q. 처음 구상한 설계와 실제 구현이 충돌해 기능을 바꾸거나 포기한 순간도 있었나요?
구현한 결과가 기대한 수준에 미치지 못해 기획 자체를 뒤집은 경우는 거의 없었어요. 계획을 세울 때 비교적 신중하게 보고, 현실적으로 구현할 수 있는 범위를 반영하려고 하기 때문이에요. 계획대로 만들다가 뒤늦게 방향을 바꾸기보다는, 계획을 정하기 전에 충분히 수정하는 편이기도 하구요.
또 제가 작업물에 대해서는 완벽주의적인 성향도 있어요. 좋은 쪽으로는 앱의 품질을 높이는 힘이 되지만, 요즘 업데이트가 느려진 이유이기도 해요. 사용자가 많아지면서 기대하는 품질의 기준도 다양해졌고, 하나씩 모두 고민하다 보면 제 기준까지 계속 높아져 힘들 때가 있어요.
에디터 : 그렇다면 요청을 그대로 기능으로 만들지 않고 다른 방식으로 해석하거나 뒤로 미룬 사례도 있나요?
사용자의 요청이 낯설게 느껴질 때는 그분의 지역이나 기기 정보, 사용 조건을 함께 보면서 왜 그 기능이 필요한지 이해하려고 해요. 다만 필요를 이해한다고 해서 모든 요청을 바로 만드는 건 아니에요.
예를 들면 자전거 도로 지원이 그런 사례예요. 자전거 도로는 데이터를 따로 가공해야 하는데, 지금은 보행 네트워크를 고도화하는 것만으로도 개발 여력이 한계에 가까운 상황이거든요. 그늘로의 현재 성격과 남은 여력을 함께 고려하면 자전거 기능의 우선순위는 낮다고 판단했습니다. 데이터를 쉽게 확보할 수 있는 지원이나 협업 기회가 생기면 다시 검토하겠지만, 지금은 뒤로 미뤄둔 상태예요.
레시피 다섯, 여름을 넘어 더 많은 이동의 불편으로
Q. 회원가입 없이 핵심 기능을 무료로 제공하고 있어요. 앞으로의 운영 비용과 수익 모델은 어떻게 고민하고 있나요?
앞으로도 사용자에게 직접 비용을 부과하는 방식은 아닐 가능성이 커요. 지금은 애드몹 광고로 큰 수익을 내지는 않지만 운영비를 충당하고 있고, 서비스가 성장하면 수익 구조도 조금씩 다각화하려고 합니다.
지도 서비스인 만큼 장소 데이터나 장소 제공자를 소개하는 방식의 광고를 상상할 수 있고요. 앞으로 쌓일 데이터가 충분한 가치를 만든다면 B2B나 B2G 모델도 고민해 볼 수 있다고 생각합니다. 아직 하나로 확정하기보다는, 사용자가 핵심 기능에 쉽게 접근할 수 있다는 원칙 안에서 가능성을 살펴보는 단계예요.
Q. 앞으로는 정확도를 더 높이는 일과 더 많은 상황을 해결하는 일 중 어디에 무게를 두고 있나요?
현재 데이터의 품질이 완벽하지는 않지만, 혼자서 확보하고 가공할 수 있는 범위에서는 최대한 해냈다고 생각해요. 더 높은 정확도를 내려면 외부 협업과 큰 규모의 데이터 고도화가 필요하기도 하고요. 지금 제가 할 수 있는 다음 단계는 기능을 더 다양한 상황으로 넓히는 일에 가까워요.
모든 지역에서 완벽하게 정확하지 않더라도 현재 기능이 일정 수준의 효과와 성능은 낸다고 판단했고, 그래서 이동 상황의 다각화를 더 고민하고 있습니다. 밤에는 방범시설이 많은 길로 안내하고, 대중교통 경로의 도보 구간을 더 최적화하는 기능을 개발하고 있어요. 앞으로는 비를 피하는 길이나 겨울철 얼어 있는 길을 피하는 기능도 생각하고 있습니다.
Q. 그늘로를 만든 뒤 다른 서비스를 바라보는 관점도 달라졌나요?
이제는 비슷한 영역의 서비스를 사용할 때 자연스럽게 벤치마킹하게 돼요. 길찾기처럼 이미 익숙한 서비스에서는 새로운 시도가 사용자에게 반감이나 장벽으로 느껴질 수도 있거든요. 반대로 완전히 다른 UI/UX를 적용하면 기능을 이해하는 데 더 많은 노력이 들 수 있고요.
그래서 다른 서비스가 어떤 흐름으로 기능을 제공하는지, 사용자가 어떤 순서로 움직이도록 설계했는지를 이전보다 분석적으로 보게 된 것 같아요. 새로움만 강조하기보다 사용자가 이미 아는 문법과 새로운 경험 사이의 균형을 고민하고 있어요.
Q. 10만 명이 넘는 사용자를 만나면서 서비스 만드는 사람에게 정말 중요하다고 새롭게 깨달은 것이 있다면요?
처음에는 경험이 많지 않다 보니 기능을 구현하고 성능을 높이는 일에 집중했어요. 그런데 많은 분이 사용하고 후기와 피드백을 주시는 걸 보면서 결국 사용성을 고민해야 한다는 걸 배웠습니다.
기능이 있다고 해서 사용자가 자연스럽게 쓸 수 있는 건 아니잖아요. 어떤 흐름으로 제공해야 하는지, 어떻게 해야 더 친근하고 쉽게 사용할 수 있는지를 지금은 더 중요하게 보고 있어요. 기능 자체에서 사용자가 기능을 만나는 방식으로 관심이 옮겨간 거죠.
에디터 : 장기적으로는 AI를 활용해 교육 격차를 줄이는 에듀테크에도 관심이 있다고 하셨어요. 메이커로서 그리고 있는 다음 모습이 궁금합니다.
이번 경험을 통해 제가 느끼거나 주변과 사회가 겪는 불편을 해결하는 일이 큰 의미가 있다는 걸 배웠어요. 저 역시 그 과정을 정말 즐긴다는 것도 알게 됐고요.
서비스로 더 효율적이고 최적화된 해결책을 제공할 수 있다면 앞으로도 즐겁게 작업할 것 같아요. 일상의 사소한 불편일 수도 있고, 교육 환경의 차이처럼 사회 전반에 크게 작용하는 문제일 수도 있죠. 형태는 달라져도 사람들이 실제로 겪는 문제를 해결하는 메이커로 일하고 싶습니다.
Q. 마지막으로, 일상의 작은 불편을 자신만의 서비스로 만들어보고 싶은 예비 메이커들에게 전하고 싶은 이야기가 있다면요?
제가 아직 많이 부족해 쉽지 않은 질문인데요. 감히 조언을 드리자면, 자신이 공감할 수 있는 문제에서 시작해 보면 좋겠어요. 서비스를 기획하고 개발하다 보면 문제의식보다 특별한 솔루션이나 기술에 더 집중하게 되는 경우가 많거든요. 기술적으로 좋은 해결책을 발전시키는 일도 중요하지만, 서비스를 사용하는 사람은 결국 자신이 겪는 문제에서 출발한다고 생각해요.
내가 느낀 불편이 다른 사람에게도 같은 불편일 수 있고, 직접 겪지 않은 문제라도 그 상황을 충분히 이해하려고 노력할 수 있어요. 솔루션을 먼저 자랑하기보다 어떤 문제를 왜 해결하려는지에 조금 더 무게를 두셨으면 좋겠습니다.
그늘로는 ‘그늘이 많은 길’이라는 한 가지 답에서 시작했지만, 사용자들을 만나며 각자에게 더 나은 길을 묻는 서비스로 변하고 있습니다. 빠른 길만이 정답이 아니듯, 좋은 제품을 만드는 방법도 하나는 아닐 거예요. 다만 유민준 님의 이야기를 따라가다 보면 한 가지 기준은 또렷하게 남습니다. 문제는 사람이 발견하고, 도구는 가능성을 넓히며, 마지막 판단은 다시 사람에게 돌아온다는 것.
여러분이 오늘 그냥 지나치지 않고 오래 바라보고 싶은 불편은 무엇인가요?
의견을 남겨주세요