Runny

문제

사람들은 러닝을 마친 뒤 기록을 SNS에 올립니다. 그런데 단순히 기록만 올리지 않고, Strava에서 뽑은 기록 PNG 뒤에 사진이나 영상을 얹어 꾸며서 올립니다. 문제는 Strava에 꾸미기 기능이 없다는 것입니다. 매번 다른 앱으로 PNG를 넘겨야 하고, 애초에 한국 계정으로는 이용할 수 없어 해외 계정을 만들어야 다운로드가 됩니다.

측정과 공유 사이의 흐름이 끊겨 있었습니다. 그 사이를 메우는 것이 이 앱의 출발점이었습니다.

검증 먼저

이전 프로젝트에서 만들고 나서야 시장을 확인하는 실수를 했기 때문에, 이번에는 순서를 바꿨습니다. 기획서를 쓰기 전에 60명 규모 러닝 크루 두 곳에 각각 수요조사를 요청했고, 긍정적인 반응을 확인한 뒤에야 설계에 들어갔습니다.

판단

• 측정이 끝나면 곧바로 꾸미기 화면으로 유도해, 다른 앱을 거치지 않고 공유까지 한 흐름으로 끝냅니다.
• 러닝 자체에 동기를 주는 장치가 필요했습니다. 방향은 해외 앱 Finch에서 얻었습니다. 쉬운 퀘스트를 깨면 펭귄 캐릭터가 성장하는 단순한 앱인데, 높은 난이도로 사용자를 지치게 하지 않고 성취감만 남긴다는 점이 핵심이라고 봤습니다.
• 그래서 어려운 퀘스트 대신, 러닝을 하면 알아서 스탯이 오르는 강아지 캐릭터를 넣었습니다. 퀘스트 보상 코인으로 꾸미기 아이템을 살 수 있게 해 러닝 → 성장 → 꾸미기 → 공유의 순환을 만들었고, 같은 크루원의 강아지를 구경하고 자랑할 수 있는 크루(길드) 기능으로 그 순환이 끊기지 않게 했습니다.

문서화 — 6단계 명세 틀

모든 기능에 동일한 여섯 단계 틀을 적용했습니다. 개발자가 되묻지 않아도 되는 수준까지 명세를 구체화하는 것이 목표였습니다.

개발

작성한 명세를 기준으로 제가 직접 백엔드를 개발했습니다. Spring Boot 4 기반으로 REST API를 설계하고 DB 스키마를 잡았습니다. 명세 단계에서 예외를 미리 정리해둔 덕분에, 구현 중에 되돌아가 설계를 고치는 일이 거의 없었습니다. 명세에 쓴 시간이 구현 시간을 줄여준다는 걸 확인한 경험이었습니다.

완성 후에는 Swagger 명세와 함께, 프론트엔드 담당자가 바로 연동할 수 있는 정리 문서를 인계했습니다.

협업에서의 판단

게이미피케이션은 제가 가장 자신 있는 영역이라 대부분의 의견을 내고 논의를 이끌었습니다. 반면 디자인은 제가 부족한 영역이었고, 이 부분은 디자인에 강한 팀원이 채워 주었습니다. 모든 걸 직접 하려 하기보다 잘하는 사람에게 맡기고 제 역할에 집중한 것이, 결과적으로 팀 전체의 속도를 높였다고 생각합니다.

결과

• 이 기획안으로 창업입주기업 결과 발표회 은상 수상
• 현재 개발 중, 2026년 10월 출시 예정