러닝을 하고 돌아온 뒤에야 초미세먼지가 좋지 않았다는 걸 알게 된 적이 있었다. 뛰는 동안에는 크게 이상하다고 느끼지 못했는데, 확인해보니 그 시간대의 공기질은 좋은 편이 아니었다. 더 아쉬웠던 건 몇 시간만 기다렸다면 조건이 나아질 수도 있었다는 점이었다.

그때의 불편은 단순히 정보를 확인하지 않았다는 문제가 아니었다. 러닝 전에 앱을 몇 개 더 열어볼 수도 있고, 미세먼지 수치를 따로 볼 수도 있다. 하지만 실제로 알고 싶었던 건 수치 하나하나가 아니었다.

오늘 몇 시쯤 달리는 게 가장 좋을까?

이 질문이 달릴시간의 출발점에 가까웠다. 오늘 달릴지 말지, 달린다면 지금이 나은지 조금 기다리는 게 나은지, 나중으로 미루면 실제로 더 좋은 조건이 되는지 알고 싶었다.

체감되지 않는 위험과 몸으로 느끼는 부담

러닝 조건을 어렵게 만드는 요소들은 서로 성격이 달랐다. 초미세먼지처럼 몸으로 바로 느끼기 어렵지만 주의 깊게 봐야 하는 요소가 있고, 습도나 WBGT처럼 같은 페이스를 더 무겁게 만드는 요소도 있다. 바람은 페이스와 피로도에 영향을 주고, UV는 퍼포먼스보다 노출 부담에 가깝다.

그래서 이 요소들을 모두 같은 방식으로 보면 이상해진다. 어떤 요소는 조금만 나빠도 조심해야 하고, 어떤 요소는 다른 조건과 함께 볼 때 부담이 커진다. 러너에게 필요한 판단은 단순 평균이 아니라, 공기질처럼 주의가 필요한 조건과 체감·퍼포먼스 부담을 구분해서 읽는 쪽에 더 가까웠다.

달릴시간이 만들고 싶었던 것도 바로 그 지점이었다. 환경 수치를 많이 보여주는 앱이 아니라, 러너가 오늘의 실행 타이밍을 더 쉽게 판단하도록 돕는 앱. 지금 뛰어도 되는지, 조금 기다리는 게 나은지, 오늘 중 언제가 더 나은지를 먼저 읽게 하는 앱이었다.

점수보다 먼저 필요했던 질문

Running Condition Score는 그 질문을 다루기 위한 하나의 표현 방식이었다. 숫자 하나로 모든 것을 단순화하려는 게 아니라, 여러 환경 조건을 러너의 판단 단위로 다시 묶어보려는 시도였다.

처음부터 완성된 알고리즘이 있었던 것은 아니다. 오히려 반대였다. 어떤 요소를 주의 신호로 볼지, 어떤 요소를 체감 부담으로 볼지, 어떤 조건에서는 조심해야 한다고 말해야 할지 계속 나눠 봐야 했다.

이 프로젝트의 첫 질문은 그래서 “좋은 날씨를 어떻게 보여줄까”가 아니었다. 더 정확히는, 러너가 앱을 열었을 때 이런 답을 먼저 받을 수 있느냐였다.

지금 달려도 괜찮은가.
아니면 조금 기다리는 편이 나은가.

달릴시간은 그 질문에 답하기 위해 시작한 앱이다. 다음 단계에서는 이 질문을 실제 점수와 알고리즘으로 옮기려 할 때, 왜 초미세먼지·WBGT·습도·바람 같은 요소를 같은 방식으로 합칠 수 없었는지를 더 자세히 다루게 된다.

초미세먼지, WBGT, 습도, 바람을 모두 점수로 바꿔 평균내면 러닝하기 좋은 시간이 나올까? 처음에는 그렇게 생각하기 쉽다. 하지만 달릴시간을 만들면서 가장 먼저 부딪힌 문제는, 바로 그 평균이 러너에게 이상한 답을 줄 수 있다는 점이었다.

초미세먼지가 높은데 기온과 바람이 괜찮다는 이유로 “달리기 좋음”에 가까운 점수가 나오면 위험하다. 반대로 보조 신호까지 모두 강하게 깎으면, 조심해서 달릴 수 있는 시간도 지나치게 나쁘게 보인다.

같은 숫자로 바꿀 수 있다고 해서, 같은 방식으로 합쳐도 되는 것은 아니었다.

그냥 평균내면 이상해지는 이유

러닝 조건은 모두 같은 신호가 아니었다. 초미세먼지는 뛰는 동안 바로 힘들게 느껴지지 않아도 주의해야 한다. 습도와 WBGT는 몸이 느끼는 부담에 더 가깝고, 바람은 페이스와 피로도를 흔든다. UV는 퍼포먼스보다 노출 부담에 가깝다.

초미세먼지가 높은데 기온과 바람이 괜찮다는 이유로 “달리기 좋음”에 가까운 점수가 나오면 위험하다. 반대로 보조 신호까지 모두 강하게 깎으면, 조심해서 달릴 수 있는 시간도 지나치게 나쁘게 보인다.

그래서 달릴시간의 점수는 예쁜 평균값보다 일관되고 설명 가능한 판단이어야 했다. 어떤 요소는 점수를 직접 크게 제한하고, 어떤 요소는 보조적으로만 반영하고, 어떤 요소는 점수보다 설명에서 더 잘 다뤄야 했다.

요소	앱에서 본 역할	처리 방향
초미세먼지 PM2.5	체감이 약해도 주의가 필요한 공기질 신호	주요 기준으로 강하게 반영
PM10	독립 주지표보다는 보조 공기질 신호	modifier로 반영
WBGT / 열 부담	같은 페이스를 더 힘들게 만드는 신호	열 스트레스 판단에 반영
UV / 바람 / 습도	상황에 따라 부담을 키우는 보조 신호	단독으로 과하게 무너뜨리지 않음
강수 / 천둥	실행 가능성과 안전 문제	강한 제한 또는 blocker

이 구분이 없으면 앱은 숫자를 많이 계산해도 러너에게는 덜 믿기는 답을 줄 수 있었다.

PM2.5는 평균 안의 한 항목이 아니었다

특히 초미세먼지는 따로 다뤄야 했다. 달리면서 바로 체감되지 않을 수 있다는 점 때문에 더 그렇다. 몸이 괜찮다고 느끼는 것과 실제 노출 부담가 낮다는 것은 같지 않다.

그래서 RCS v1에서는 PM2.5를 primary factor로 두고, 일정 구간 이상에서는 하루 점수의 상한을 제한하는 guardrail을 뒀다.

PM2.5가 하루 절반 이상 지속될 때의 day score 상한
25-35  → 최대 69
35-50  → 최대 54
50+    → 최대 39

이 상한은 두 가지를 막기 위한 장치였다.

• 짧은 좋은 시간대 하나 때문에 하루 전체가 지나치게 좋아 보이는 것
• 종일 애매하게 나쁜 공기질이 “그럭저럭 괜찮음”처럼 포장되는 것

달릴시간이 알려주고 싶은 것은 “가장 좋은 숫자 하나”가 아니라, 오늘 남은 시간 안에서 실제로 달릴 만한 선택지가 있는지였다.

좋은 시간은 길이와 분포까지 봐야 했다

또 하나의 문제는 시간대였다. 한두 시간만 조건이 좋아도 오늘의 best time은 있을 수 있다. 하지만 그 짧은 구간 하나 때문에 하루 전체를 좋게 말하면 안 된다.

그래서 day score는 단순 평균이 아니라 세 가지를 함께 보도록 잡았다.

best 2-hour rolling average      55%
remaining-hour coverage >= 70    25%
median remaining-hour score      20%

이 구조는 완벽한 정답이라기보다, 당시 앱이 가져야 할 첫 번째 판단 기준이었다. 오늘 남은 시간 중 가장 나은 구간이 어디인지 보되, 그 구간이 너무 짧거나 나머지 시간이 크게 나쁘면 점수가 과하게 좋아지지 않게 하려는 시도였다.

점수는 결론이 아니라 설명의 입구였다

RCS를 만들면서 계속 조심해야 했던 것은 숫자가 모든 설명을 대신하게 만드는 일이었다. 점수는 빠르게 읽히는 입구가 될 수 있지만, 사용자가 믿으려면 왜 그런 점수가 나왔는지도 이어져야 한다.

그래서 Home hero에는 점수와 한 줄 해석이 필요했고, 그 아래에는 Best Time과 상세 근거가 필요했다. 어떤 날은 PM2.5가 핵심 이유가 되고, 어떤 날은 열 부담이나 강수 가능성이 더 중요해진다. 점수 하나는 같아도 이유는 다를 수 있다.

달릴시간의 두 번째 고민은 여기 있었다.

같은 60점이라도, 왜 60점인지 설명할 수 있어야 했다.

이 지점에서 앱은 단순히 숫자를 계산하는 쪽에서 벗어나기 시작했다. 공기질처럼 주의가 필요한 조건과 체감 부담을 나눠 보고, 시간대별로 다시 묶고, 그 결과를 사용자가 읽을 수 있는 말로 바꾸는 일이 필요해졌다.

그리고 이 모델을 더 깊게 다루는 과정에서, 프로젝트는 예상치 못한 운영 문제도 만나게 된다. 실험과 문서가 임시 폴더에 쌓여 있다가 한 번에 사라지면서, 다음에는 기능보다 먼저 “무엇을 다시 믿고 이어갈 수 있는가”를 정해야 했다.

달릴시간을 만들면서 한 번 크게 멈춘 지점이 있었다. 작업하던 코드와 판단의 일부가 임시 폴더 안에 있었고, 그 흐름이 한 번에 사라졌다. 기능 하나가 깨진 정도가 아니라, 어디까지가 현재 기준이고 어디서부터 다시 이어야 하는지 자체가 흐려진 순간이었다.

사라진 것은 파일만이 아니었다. “지금 무엇을 믿고 이어갈 수 있는가”라는 기준도 함께 흔들렸다.

복구보다 먼저 필요했던 기준

처음에는 당연히 복구가 먼저라고 생각하기 쉽다. 하지만 실제로는 파일을 되살리는 일만으로는 충분하지 않았다. 이전 후보가 어떤 판단을 했는지, 현재 앱이 어느 빌드를 기준으로 움직이는지, 사용자가 보게 될 화면이 어느 흐름의 결과물인지가 함께 정리되어야 했다.

그래서 질문은 “어떻게 빨리 다시 만들까?”에서 조금 바뀌었다.

무엇을 현재 truth로 볼 것인가?
무엇은 archive로만 남길 것인가?
어떤 판단은 다시 검증한 뒤에만 가져올 것인가?

이 구분이 없으면 같은 기능을 다시 만들어도, 다음 QA에서 또 다른 기준을 보고 판단하게 된다. 특히 달릴시간처럼 점수·화면·설명·릴리즈 빌드가 함께 맞아야 하는 앱에서는 이 차이가 작지 않았다.

워크트리를 나눈 이유

이후에는 본선 개발과 PM reset 흐름을 분리해서 보기 시작했다. 하나는 실제 앱을 앞으로 밀고 가는 자리였고, 다른 하나는 사라진 판단과 남은 근거를 다시 읽어 현재 기준을 재구성하는 자리였다.

이 방식은 일을 더 복잡하게 만들기 위한 것이 아니었다. 오히려 반대였다. 본선 개발 안에서 복구와 검증과 기록을 모두 섞어두면, 무엇이 제품 결정이고 무엇이 임시 수습인지 금방 흐려졌다.

그래서 달릴시간에서는 한동안 다음과 같은 구분이 필요했다.

• 현재 사용자가 보게 될 앱 기준
• 후보 모델을 실험하는 기준
• 과거 기록을 다시 읽는 기준
• 출시나 QA에서만 쓰는 기준

이 구분을 세우고 나서야, 다음 기능을 붙이는 일이 조금 덜 불안해졌다.

잃어버린 뒤에 생긴 운영 감각

이 경험은 제품 자체의 기능은 아니지만, 이후 작업 방식에는 꽤 큰 영향을 줬다. 달릴시간은 단순한 화면 앱이 아니라 판단 모델을 계속 조정해야 하는 앱이었다. 그렇다면 코드만큼이나 “왜 이 판단을 했는지”도 함께 남아 있어야 했다.

특히 러닝 조건 점수처럼 미세한 보정이 쌓이는 영역에서는, 과거 결정을 잃어버리면 같은 논의를 반복하기 쉽다. PM2.5를 얼마나 강하게 볼지, WBGT를 언제부터 기본 기준으로 볼지, 바람과 강수를 어디까지 제한할지 같은 질문은 코드보다 판단의 맥락이 더 중요할 때가 많았다.

이후의 달릴시간 작업은 그래서 조금 더 느려졌지만 더 명시적이 되었다. 기능을 바로 붙이는 대신, 어떤 기준으로 붙이는지부터 적었다. 다음 회차의 WBGT 도입도 이 흐름 위에서 읽어야 한다. 새 지표를 넣는 일은 단순히 계산식을 추가하는 일이 아니라, 앱이 어떤 근거를 사용자에게 보여줄지 다시 고르는 일이었기 때문이다.

러닝하기 좋은 시간을 판단할 때 더위는 생각보다 까다로웠다. 기온이 높다는 사실만으로는 충분하지 않았고, 체감온도도 러너가 실제로 느끼는 부담을 모두 설명해주지는 못했다. 같은 27도라도 습도, 바람, 햇볕, 복사열에 따라 몸이 받아들이는 부담은 달라졌다.

“덥다”를 숫자로 보여주는 것과 “지금 달릴지, 조금 기다릴지”를 판단하는 것은 다른 문제였다.

왜 WBGT였나

WBGT는 Wet Bulb Globe Temperature의 약자로, 단순 기온보다 열 부담을 더 입체적으로 보려는 지표다. 야외 활동과 스포츠 환경에서 열 스트레스 판단에 참고되는 이유도 여기에 있다. 달릴시간에서는 이 지표를 그대로 권위처럼 가져오고 싶었던 것은 아니었다. 다만 러너에게 필요한 질문은 분명했다.

오늘 몇 시가 덜 위험하고,
덜 힘들고,
그래도 달릴 만한 시간인가?

기온 하나만 보면 이 질문에 답하기 어려웠다. 습도와 바람, 햇볕의 영향이 빠지면 실제 러닝 부담과 앱의 판단이 어긋날 가능성이 컸다. 그래서 WBGT는 더위를 더 잘 설명하기 위한 후보가 되었다.

바로 켜지 못했던 이유

그렇다고 WBGT를 바로 기본값으로 넣을 수는 없었다. 우선 데이터가 문제였다. 모든 지역에서 바로 쓸 수 있는 신뢰도 높은 직접 WBGT 데이터가 있는 것은 아니었고, 앱이 이미 쓰고 있던 Open-Meteo 기반 입력값으로 모델링할 수 있는 범위와 한계를 따져야 했다.

또 하나는 설명의 문제였다. 사용자는 WBGT라는 단어를 처음 볼 수 있다. 앱이 갑자기 낯선 지표를 앞세우면 “정확해 보인다”보다 “이게 뭐지?”가 먼저 올 수 있다. 그래서 내부 모델에서는 열 부담을 더 잘 보되, 화면에서는 러너가 이해할 수 있는 문장과 근거로 풀어야 했다.

이때 기준은 세 가지였다.

• 기존 입력값으로 계산 가능한가
• 기존 점수 모델을 과하게 흔들지 않는가
• 사용자가 납득할 수 있는 언어로 설명 가능한가

WBGT는 이 기준을 통과해야 했다. 지표를 추가하는 것보다 중요한 것은, 지표가 앱의 판단을 더 믿을 만하게 만드는지였다.

숫자보다 근거가 보이는 화면이 중요했다

결국 WBGT는 단순히 점수 하나를 더하는 일이 아니었다. 홈 화면, 일별 상세, 정보 시트, 법적 고지, QA 기준까지 이어지는 사용자가 근거를 읽을 수 있는 화면의 문제였다. 앱 안에서 “WBGT를 보고 있다”고 말하려면, 실제 화면의 근거도 그 방향으로 정렬되어야 했다.

그래서 이후 작업은 WBGT v2를 후보로 붙이고, 실제 위치 기준으로 확인하고, Daily detail과 Home hero가 같은 근거를 말하도록 맞추는 방향으로 이어졌다. 이 과정에서 낡은 기온/체감 중심 설명이 남아 있으면 오히려 신뢰가 깨졌다.

달릴시간이 WBGT를 다룬 방식은 거창한 과학 모델을 만든다기보다, 러너에게 더 덜 틀린 판단을 주기 위한 조정에 가까웠다. 더위는 기온 하나로 충분하지 않았고, 앱은 그 부족함을 인정한 뒤 더 나은 근거를 찾아야 했다.

달릴시간의 점수 모델이 어느 정도 형태를 갖추고 나자, 다음 문제는 점수 자체가 아니었다. 사용자가 앱을 열었을 때 “그래서 왜 지금이 좋은가, 왜 조금 기다리라는가”를 읽을 수 있어야 했다. 점수는 빠르게 읽히지만, 혼자서는 충분히 믿기 어렵다.

좋은 점수보다 중요한 것은, 그 점수가 나온 이유를 같은 화면 안에서 납득할 수 있는가였다.

같은 점수, 다른 이유

예를 들어 같은 60점이라도 이유는 다를 수 있다. 어떤 날은 초미세먼지가 높아서 조심해야 하고, 어떤 날은 WBGT가 높아서 열 부담이 크고, 어떤 날은 비나 바람 때문에 실행 가능성이 떨어진다. 숫자만 보면 비슷하지만 사용자가 취해야 할 행동은 달라질 수 있다.

그래서 홈 화면은 단순히 점수와 캐릭터만 보여주면 안 됐다. 지금 뛰어도 되는지 판단하는 데 필요한 근거가 무엇인지, 기다리면 나아지는지, 어떤 근거 때문에 그렇게 말하는지를 함께 보여줘야 했다. 달릴시간의 홈은 점수판이 아니라 판단의 이유를 함께 읽는 화면에 가까워져야 했다.

이때 정리한 방향은 비교적 단순했다.

1. 지금 바로 읽을 수 있는 결론
2. 그 결론을 만든 핵심 근거
3. 시간이 지나면 달라지는지 보는 다음 행동

이 구조가 있어야 사용자는 앱의 판단을 그대로 외우는 대신, 자기 상황에 맞춰 받아들일 수 있다.

Home과 Daily detail이 같은 말을 해야 했다

또 하나의 문제는 화면 사이의 일관성이었다. 홈에서는 WBGT와 PM을 중심으로 말하는데, 상세 화면에 들어가면 다시 낡은 기온·체감 중심 설명이 나오면 사용자는 금방 헷갈린다. 앱 내부에서는 새 판단 모델을 쓰고 있는데, 화면 일부가 예전 언어를 계속 말하는 상태가 되는 것이다.

그래서 Daily detail도 Home hero와 같은 근거 모델을 말하도록 맞췄다. WBGT, PM2.5, PM10, UV, 습도, 바람이 서로 다른 역할로 읽히고, 사용자가 특정 시간대를 눌렀을 때도 같은 판단 구조가 이어지도록 했다.

이 작업은 UI 문구 수정처럼 보일 수 있지만, 실제로는 신뢰를 맞추는 일이었다. 같은 앱 안에서 서로 다른 기준이 말하면, 사용자는 어느 쪽을 믿어야 하는지 모르게 된다.

출시 기준도 함께 바뀌었다

점수와 이유를 맞추기 시작하자 QA 기준도 달라졌다. 화면이 보인다는 것만으로는 충분하지 않았다. 실제 위치에서 Home, Daily detail, 정보 시트, 모델 입력값이 같은 방향을 가리키는지 확인해야 했다. 오래된 빌드나 중간 후보가 섞이면, 잘못된 화면을 보고 맞다고 판단할 수도 있었다.

그래서 달릴시간의 후반 작업은 기능 추가보다 기준 맞추기에 가까웠다. 어떤 빌드가 현재 기준인지, 어떤 후보가 release default인지, 어떤 화면이 아직 legacy 설명을 갖고 있는지 하나씩 확인했다.

이 과정 끝에 앱은 조금 더 분명한 방향을 갖게 됐다. 달릴시간은 날씨 정보를 많이 보여주는 앱이 아니라, 러너가 오늘의 실행 타이밍을 판단하도록 돕는 앱이어야 했다. 점수는 그 시작점이고, 신뢰는 그 점수를 설명하는 표면에서 만들어졌다.

달릴시간의 아이콘을 고를 때 처음 기준은 꽤 자연스러웠다. 앱의 어두운 UI 톤과 잘 맞고, 러너 캐릭터가 너무 가볍지 않아 보이고, 하나의 브랜드 마크처럼 정리된 이미지를 찾고 있었다. 그래서 초반 후보 중에는 더 어둡고 프리미엄해 보이는 방향도 있었다.

하지만 실제 홈화면에 올려놓고 보니 질문이 달라졌다.

예쁜 아이콘인가보다 먼저, 많은 앱 사이에서 바로 발견되는 아이콘인가를 봐야 했다.

좋은 그림과 좋은 앱 아이콘은 달랐다

아이콘 후보를 만드는 과정에서는 여러 방향을 시험했다. 신발과 시계 조합, 추상적인 속도/시간 마크, 러너가 시계 링 안에 들어간 형태, 어두운 네이비/틸 계열의 프리미엄한 버전, 손목의 빛이나 러너의 자세를 강조한 버전까지 있었다.

그중 일부는 단독 이미지로 보면 더 그럴듯했다. 하지만 앱 아이콘은 갤러리에 걸리는 이미지가 아니라, 사용자의 홈화면에 놓이는 작은 표면이다. 크기가 줄어들고, 다른 앱과 섞이고, 배경이 밝거나 어두워질 때도 살아남아야 했다.

그래서 판단 기준은 조금씩 바뀌었다.

브랜드 톤과 잘 맞는가
→ 작은 크기에서도 러너와 시간이 읽히는가
→ 실제 홈화면에서 눈에 들어오는가

이 변화가 중요했다. 달릴시간은 사용자가 “오늘 몇 시에 달릴까?”를 떠올릴 때 바로 열어야 하는 앱이다. 그렇다면 아이콘도 조용히 예쁜 것보다, 순간적으로 찾기 쉬운 쪽이 더 맞았다.

실제 홈화면에서 어두운 후보가 약해졌다

결정적인 장면은 실제 아이폰 홈화면에 후보를 올려놓고 본 순간이었다. 어두운 후보는 앱 내부 UI와는 잘 어울렸지만, 홈화면에서는 생각보다 묻혔다. 특히 다크 배경이나 다른 강한 앱 아이콘 사이에서는 존재감이 약했다.

반대로 밝은 피치 계열 배경의 러너 아이콘은 조금 덜 프리미엄해 보일 수는 있었지만, 훨씬 빨리 보였다. 러너가 있고, 손목 쪽 빛이 있고, “달릴 시간”을 확인하는 느낌도 더 직접적이었다.

선택은 취향보다 사용 맥락에 가까웠다

이 과정에서 배운 것은 간단했다. 아이콘은 브랜드 자산이지만 동시에 배포 표면이다. 앱을 설치한 사람이 매번 찾고 누르는 위치에 놓이기 때문에, 단독 이미지의 완성도만으로는 부족했다.

그래서 최종 선택은 “가장 멋진 아이콘”이라기보다 “테스터가 실제로 찾기 쉬운 아이콘”에 가까웠다. 어두운 버전이 더 정제되어 보이는 순간도 있었지만, 달릴시간의 첫 외부 테스트 기준에서는 밝은 러너 아이콘이 더 맞았다.

이 판단은 이후 콘텐츠에도 남겨둘 필요가 있다. 달릴시간은 날씨를 많이 보여주는 앱이 아니라, 러너가 지금 실행할지 판단하게 돕는 앱이다. 아이콘도 같은 방향이어야 했다. 설명보다 먼저, 사용자가 앱을 찾는 순간부터 “달릴 시간”이라는 행동이 떠올라야 했다.

제주에서 실제 기기로 확인하던 중, 실제로는 비가 꽤 오는데 달릴시간의 현재 점수와 하루 흐름은 너무 괜찮게 보이는 순간이 있었다. 이건 단순히 “비 점수를 조금 더 깎자”로 끝낼 문제가 아니었다.

러너가 앱을 열었을 때 가장 먼저 믿어야 하는 것은 점수 자체가 아니다. 그 점수가 지금 이 위치의 날씨를 제대로 보고 있는가다.

점수 튜닝보다 먼저 봐야 할 것

처음에는 강수 감점을 더 키우거나, 비가 올 때 점수 상한을 더 낮추면 될 것처럼 보였다. 물론 그런 정책도 필요하다. 하지만 그보다 앞에 있는 질문이 있었다.

앱은 지금 어떤 데이터를 보고 “달려도 괜찮다”고 말하고 있는가?

기존 구조에서 Open-Meteo는 중요한 기본 데이터였다. 전 세계 위치를 다룰 수 있고, 다른 출처가 불안정할 때 대체 데이터로도 유용했다. 하지만 한국에서 먼저 쓰는 러닝 앱이라면 현재 비와 가까운 시간대 예보, 미세먼지 관측값은 한국에서 제공되는 출처를 먼저 봐야 했다.

그래서 방향은 점수 공식을 조금 고치는 쪽에서, 데이터 출처를 다시 세우는 쪽으로 이동했다.

한국에서는 한국 데이터를 먼저 보기로 했다

새 구조에서는 한국 위치에 대해 기상청과 AirKorea를 더 앞에 두었다. 기상청 초단기실황과 초단기예보는 지금부터 가까운 시간대의 비, 바람, 습도, 낙뢰 같은 신호를 본다. AirKorea는 가까운 측정소의 PM2.5와 PM10을 본다. Open-Meteo는 없애지 않고, 대체 데이터와 UV/WBGT 보조 데이터로 남겼다.

한국 위치의 러닝 판단
→ 기상청: 현재/근접 시간대 비와 바람
→ AirKorea: 측정소 기반 미세먼지
→ Open-Meteo: 대체 데이터 + UV/WBGT 보조
→ Running Condition Score

핵심은 데이터를 더 많이 붙이는 것이 아니었다. “오늘 달려도 되는가”라는 질문에 더 가까운 데이터를 먼저 보게 만드는 일이었다.

데이터	앱에서 맡은 역할
기상청 초단기실황	지금 비가 실제로 오는지 확인한다
기상청 초단기예보	앞으로 몇 시간의 강수와 바람을 보강한다
AirKorea 측정소	국내 PM2.5 / PM10 값을 우선 반영한다
Open-Meteo	해외 위치, 장애 상황, UV/WBGT 보조로 남긴다

이렇게 바꾸고 나서야 Running Condition Score(RCS)는 단순한 계산식이 아니라, 출처가 있는 판단에 가까워졌다.

19개 지역을 돌려보며 드러난 것

데이터 출처를 바꿨다고 바로 끝난 것은 아니었다. 실제로 한국 여러 지역에서 데이터가 어떻게 들어오는지 확인해야 했다. 제주, 서울·경기, 미세먼지 민감 지역, 남부·동해안·산간·섬 지역까지 19개 위치를 샘플링했다.

구현 과정에서는 AI를 코드 작성 속도를 높이는 보조 도구로도 썼지만, 더 유용했던 지점은 예외 케이스를 빨리 넓혀보는 일이었다. 어떤 지역에서 측정소가 멀어질 수 있는지, 과거 데이터가 현재처럼 섞일 여지는 없는지, 화면에서는 그 불확실성을 어디까지 드러내야 하는지를 반복해서 점검했다.

대부분은 기상청과 AirKorea 조합으로 잘 들어왔다. 하지만 검증을 하면서 두 가지가 보였다.

1. 과거 시간대 데이터가 현재처럼 보이면 실제 현재값과 다르게 읽힐 수 있었다.
2. 섬이나 산간 지역에서는 가까운 AirKorea 측정소가 10km 이상 떨어질 수 있었다.

이건 단순한 버그라기보다, 사용자가 앱을 어떻게 믿게 되는가의 문제였다. 데이터가 맞아도 오래된 row가 현재처럼 보이면 신뢰가 깨진다. 측정소가 멀리 있는데 그 사실을 숨기면, 앱은 모르는 것을 아는 척하는 셈이 된다.

모르는 것을 아는 척하지 않기

그래서 후속 작업은 화려하지 않았다. 과거 시간대 데이터가 현재나 미래 판단처럼 섞이지 않도록 현재 시간 이후만 보게 정리했다. AirKorea 측정소가 멀어지는 경우에는 조용한 신뢰 노트를 둘 수 있게 했다.

이 변화가 크지 않아 보일 수도 있다. 하지만 달릴시간 같은 앱에서는 이런 작은 경계가 중요하다. 점수 하나가 높아도, 사용자가 “이 앱이 지금 내 상황을 제대로 보고 있나?”라고 느끼면 판단은 바로 흔들린다.

결국 이번에 바뀐 것은 날씨 데이터 목록만이 아니었다. 달릴시간이 신뢰를 다루는 방식이었다.

좋은 러닝 시간은 공식 하나로 나오지 않는다. 어떤 데이터를 먼저 보고, 얼마나 최신인지 확인하고, 지역적으로 얼마나 가까운지 의심하고, 부족한 부분은 부족하다고 남기는 일까지 포함된다.

“오늘 달려도 될까?”라는 단순한 질문 뒤에는, 생각보다 많은 신뢰 구조가 필요했다.

처음에는 달릴시간을 조금 조심스럽게 설명했다. 미세먼지, 더위, 습도, 바람, 비를 함께 보고 지금 뛰어도 괜찮은지 알려주는 앱. 틀린 말은 아니었다. 실제로 이 앱이 풀고 있는 문제도 거기서 시작했다.

하지만 홈페이지와 앱스토어 문구를 다시 보면서, 그 설명만으로는 부족하다는 생각이 들었다. 러너가 달리기 전에 앱을 여는 이유는 단순히 위험을 피하기 위해서만은 아니기 때문이다.

러너는 오늘 더 잘 뛰고 싶어서 조건을 본다.

기록 앱은 달린 뒤를 보여준다

달리기를 끝내고 나면 기록 앱을 본다. 거리, 페이스, 시간, 루트, 심박, 구간 기록 같은 것들이 남는다. 그 데이터는 중요하다. 내가 어떻게 뛰었는지, 다음에는 무엇을 바꿔야 할지 알려준다.

하지만 기록 앱은 대부분 달린 뒤의 이야기를 보여준다. 정작 나가기 전에는 아직 기록이 없다. 그때 필요한 질문은 조금 다르다.

오늘 나가도 괜찮을까?
조금 기다리면 더 나을까?
어느 시간대가 덜 힘들까?

달릴시간이 들어가야 할 자리는 바로 그 앞이었다. 달린 뒤를 평가하는 앱이 아니라, 달리기 전에 오늘의 조건을 먼저 고르는 앱. 이 차이가 보이자 앱을 설명하는 문장도 달라져야 했다.

날씨앱도, 기록앱도 아닌 자리

일반 날씨앱은 수치를 보여준다. 기온, 강수, 바람, 미세먼지, 습도. 정보는 많지만 그 정보를 보고 오늘 뛸지 말지는 다시 사용자가 판단해야 한다.

기록앱은 반대편에 있다. 이미 뛴 뒤의 결과를 잘 보여준다. 하지만 러너가 집을 나서기 전, 지금 나갈지 조금 기다릴지에 대한 답은 직접 주지 않는다.

그래서 홈페이지에서는 달릴시간의 자리를 더 분명하게 보여줘야 했다. “날씨 정보를 많이 보여주는 앱”도 아니고, “기록을 분석하는 앱”도 아니라는 것. 여러 환경 조건을 러너의 실행 타이밍으로 번역하는 앱이라는 것.

이 비교는 단순한 소개 문구가 아니었다. 제품의 위치를 정하는 일이었다. 사용자가 왜 이 앱을 기록 앱 전에 열어야 하는지, 그리고 왜 일반 날씨앱만으로는 부족한지 한 번에 이해하게 만들어야 했다.

안전만으로는 충분하지 않았다

기존 설명은 주로 안전과 건강 리스크에 가까웠다. 초미세먼지가 나쁜지, 더위 부담이 큰지, 비나 바람이 달리기를 방해하는지를 보는 앱. 이 설명은 정확하다. 하지만 러너가 매번 앱을 열 만큼의 이유를 모두 담지는 못했다.

러너에게는 “위험하지 않은가”만큼이나 “오늘 더 잘 뛸 수 있는가”도 중요하다. 같은 훈련을 하더라도 조건에 따라 몸이 받아들이는 느낌은 달라진다. 습도가 높으면 페이스가 쉽게 무너지고, 바람이 강하면 같은 속도도 더 힘들게 느껴진다. 미세먼지나 비는 강도와 시간을 다시 보게 만드는 이유가 되기도 한다.

그래서 질문은 이렇게 바뀌었다.

이 앱은 날씨를 알려주는가, 아니면 오늘의 러닝 조건을 골라주는가?

앱스토어 키워드를 볼 때도 같은 방향이 보였다. 러닝 날씨, 달리기 좋은 시간, 러닝 미세먼지, 습도 러닝, 바람 러닝 같은 검색어는 사용자가 단순한 날씨 정보보다 러닝 기준의 판단을 찾고 있다는 신호에 가까웠다.

달리기 전 조건을 고르는 앱

결국 달릴시간은 날씨 앱도 아니고, 기록 앱도 아니다. 날씨 데이터를 러너의 실행 타이밍으로 번역하려는 앱에 가깝다.

오늘의 점수와 이유를 보고, 남은 시간대 흐름을 보고, 지금 나갈지 조금 기다릴지 판단한다. 달린 뒤에 기록을 확인하기 전에, 먼저 오늘의 조건을 고르는 것이다.

이렇게 정리하고 나서야 홈페이지, 앱스토어 문구, 화면 캡션이 같은 방향을 보기 시작했다.

기록 앱은 달린 뒤를 보여준다.
달릴시간은 달리기 전에 조건을 고르게 돕는다.

이 문장은 이후 RCS 프로모션 계산기를 만들 때도 기준이 됐다. 달릴시간이 말하려는 것은 “기록을 올려준다”가 아니라, 기록에 영향을 줄 수 있는 조건을 더 잘 읽게 돕는다는 쪽에 가까웠기 때문이다.

제주에서 실제로 비가 오는데 앱은 달리기 괜찮은 조건처럼 보였던 적이 있었다. 처음에는 비 점수를 더 세게 깎으면 해결될 문제처럼 보였다. 하지만 곧 그게 전부가 아니라는 생각이 들었다.

사용자가 “이 판단은 안 맞는 것 같아요”라고 말해도, 그 말만으로는 무엇을 고쳐야 할지 알기 어렵다. 비 때문인지, 미세먼지 때문인지, 위치 기준 때문인지, 아니면 앱이 보여준 문장이 체감과 어긋났는지 다시 복원할 수 있어야 했다.

피드백은 의견이 아니라, 그 순간의 판단을 다시 읽을 수 있는 기록이어야 했다.

맞았는지 묻는 것만으로는 부족했다

처음 필요한 것은 가벼운 입력이었다. 러너가 앱을 열고 현재 판단을 본 뒤, 그 판단이 지금 체감과 맞는지만 빠르게 알려줄 수 있어야 했다.

그래서 피드백은 세 가지 선택으로 줄였다.

O 맞아요
△ 애매해요
X 안 맞아요

메시지는 선택 사항으로 두었다. 베타 테스트에서 중요한 것은 긴 설명을 받는 일이 아니라, 어느 조건에서 판단이 어긋났는지 반복해서 볼 수 있는 구조였다.

하지만 선택값만 남기면 다시 같은 문제가 생긴다. “안 맞아요”가 남아도, 그때 앱이 무엇을 보고 있었는지 모르면 점수와 문구를 고치기 어렵다.

판단이 만들어진 순간을 함께 남기기

그래서 피드백에는 사용자의 선택만 붙이지 않았다. 앱이 그 순간 보고 있던 조건도 함께 묶었다.

• 플랫폼과 앱 버전
• 선택한 위치와 좌표 기준
• Running Condition Score와 상태
• 화면에 보인 판단 문구
• 날씨와 공기질 데이터의 주요 값
• 사용자가 남긴 선택값과 선택 메시지

이렇게 남기면 피드백은 단순한 불만이나 칭찬이 아니다. 특정 시간, 특정 위치, 특정 데이터 상태에서 앱이 어떤 판단을 했고 사용자는 그것을 어떻게 느꼈는지 볼 수 있다.

구글 시트는 이 단계에서 가장 가벼운 저장소였다. 처음부터 거대한 분석 시스템을 만들기보다, 베타 단계에서 빠르게 행을 보고 문제 유형을 나누는 편이 더 맞았다.

대부분 테스트 데이터였지만, 이 화면은 구조를 확인하기에 충분했다. 피드백은 메모 한 줄이 아니라, 나중에 “왜 그 판단이 맞거나 틀렸다고 느꼈는지” 다시 추적할 수 있는 단서가 되어야 했다.

피드백은 제품 한가운데 있으면 안 됐다

기술적으로는 홈 화면 안에 피드백 카드를 바로 넣을 수 있었다. 실제로 그 방식이 가장 빨리 확인하기 쉬웠다. 하지만 화면을 보고 나니 문제가 보였다.

달릴시간의 홈은 러너가 “지금 나가도 될까?”를 판단하는 자리다. 그 자리에 피드백 카드가 너무 강하게 들어오면, 앱이 제품이라기보다 내부 QA 도구처럼 보였다.

그래서 피드백 경로를 둘로 나눴다.

1. 사용자가 원할 때 들어갈 수 있는 설정 → 러닝 판단 피드백
2. 홈에서는 조건이 맞을 때만 조심스럽게 나타나는 바텀 시트

수동 경로는 항상 열어두고, 홈의 질문은 자주 보이지 않게 했다. 기본 지연 시간과 쿨다운을 두고, 점수가 낮거나 주의 문구가 있거나 비 관련 문장이 있는 순간처럼 피드백 가치가 높은 상황에서만 더 빨리 묻도록 했다.

묻는 타이밍도 제품의 일부였다

피드백을 잘 받으려면 많이 물어보면 된다고 생각하기 쉽다. 하지만 러너가 앱을 여는 이유는 피드백을 주기 위해서가 아니다. 오늘 뛸지, 조금 기다릴지 판단하기 위해서다.

그래서 피드백은 판단을 방해하지 않아야 했다. 현재 조건을 읽고 나서야 묻고, 한 번 닫으면 일정 시간 동안 다시 묻지 않게 했다. 제출한 뒤에도 며칠 동안은 반복해서 묻지 않는다.

이 조정은 작아 보이지만 중요했다. 피드백 기능은 앱을 개선하기 위해 필요하지만, 사용자가 느끼는 제품의 중심을 빼앗으면 안 된다.

분석은 넓게가 아니라 필요한 만큼만

이벤트 트래킹도 같은 기준으로 봤다. 베타 단계에서는 실제로 예보가 로드되는지, 결제 흐름이 열리는지, 피드백이 제출되는지 확인해야 한다. 하지만 모든 행동을 넓게 자동 수집하거나 세션을 다시 보는 방식은 달릴시간에 맞지 않았다.

달릴시간은 위치와 컨디션을 다루는 앱이다. 그래서 분석은 더 조심스러워야 했다. 필요한 이벤트만 직접 남기고, 민감한 값은 공개 콘텐츠나 운영 기록에서 드러나지 않도록 구분했다.

PostHog는 그래서 “사용자를 추적하는 도구”라기보다, 베타에서 핵심 흐름이 실제로 지나갔는지 확인하는 제한적인 장치에 가까웠다. 구글 시트는 피드백의 맥락을 보는 도구였고, 이벤트 트래킹은 흐름이 작동하는지를 보는 도구였다.

판단을 고치는 앱이 되려면

러닝 조건을 점수로 만드는 일은 한 번에 끝나지 않는다. 실제 러너가 보고, 뛰어보고, 다르게 느끼는 순간이 쌓여야 한다. 그때 중요한 것은 피드백을 많이 받는 일이 아니라, 나중에 다시 고칠 수 있는 형태로 받는 일이다.

달릴시간의 피드백 구조는 그 기준을 세우기 위한 첫 번째 장치였다.

사용자는 가볍게 말한다.
앱은 그 순간의 조건을 함께 남긴다.
그리고 다음 판단은 그 기록을 보고 다시 조정된다.

이렇게 보면 피드백은 출시 전 체크리스트가 아니다. 달릴시간이 계속 러너의 체감에 가까워지기 위한, 작은 학습 루프에 가깝다.

앱을 만들다 보면 기능을 설명하는 일과 알리는 일이 다르다는 생각을 하게 된다. 달릴시간은 러너가 “오늘 몇 시에 달릴까?”를 판단하도록 돕는 앱이다. 그런데 이 가치를 말로만 설명하면 조금 건조했다.

러너가 주변 러너와 이야기할 만한 질문을 만들 수 있다면, 달릴시간의 가치는 더 자연스럽게 전해질 수 있다고 봤다. 그래서 “내 기록도 조건이 좋았다면 달라졌을까?”를 직접 넣어보고 공유할 수 있는 작은 비교 페이지를 만들었다.

달릴시간의 대표 지표인 RCS와 기록을 입력하면, 더 좋은 조건이었다면 어느 정도 범위가 가능했을지 보여준다. 결과를 보장하는 계산기가 아니라, 조건의 차이를 러너끼리 이야기할 수 있게 만드는 단순한 프로모션 사이트다.

다만 이 장치를 만들수록 조심해야 할 선도 분명했다. 좋은 조건에서 달리면 기록이 달라질 수 있다. 이 말은 러너라면 직관적으로 이해한다. 하지만 앱이 “기록을 좋아지게 해준다”고 말하는 순간, 그건 너무 멀리 간 표현이 된다.

기록은 훈련, 수면, 코스, 컨디션, 보급, 장비, 전략 같은 여러 요소에서 나온다. 환경 조건은 그중 하나일 뿐이다. 그래서 RCS를 외부에서 설명할 때도 선을 분명히 그어야 했다.

기록을 예측하지 말고, 조건의 차이를 이야기할 수 있는 참고 범위로 보여주자.

홍보 문구보다, 러너가 이야기할 질문 만들기

RCS는 Running Condition Score의 줄임말이다. 기온, WBGT, 미세먼지, 바람, 비 같은 조건을 러닝 관점에서 0–100으로 묶어 보여주는 점수다. 높을수록 달리기 좋은 조건에 가깝다.

하지만 “RCS가 높습니다”라는 말만으로는 충분하지 않았다. 러너가 궁금한 것은 점수 자체가 아니라 그 점수가 내 달리기에 어떤 의미가 있는지였다. 그리고 홍보 관점에서는 이 질문이 다른 러너와 나눌 만한 이야기로 이어져야 했다.

그래서 프로모션 페이지의 질문은 이렇게 잡았다.

그날 조건이 달랐다면,
기록도 달라졌을까요?

이 질문은 조심스럽지만 강했다. 기록을 보장하지 않으면서도, 환경 조건이 기록 체감에 영향을 줄 수 있다는 사실을 러너가 자기 경험으로 다시 떠올리게 만들 수 있었다. 동시에 결과를 공유했을 때도 설명이 쉬웠다. “좋은 조건이었다면 내 페이스가 이 정도 달라졌을 수도 있대”라는 대화가 바로 시작될 수 있기 때문이다.

입력값은 최소한으로 줄였다

계산기가 너무 많은 정보를 요구하면 러너는 시작하기 어렵다. 반대로 너무 적게 물으면 결과를 믿기 어렵다. 그래서 처음 입력은 네 가지로 줄였다.

• 그날의 RCS
• 달린 거리
• 평균 페이스
• 가장 크게 느낀 방해 요인

여기서 방해 요인은 원인을 확정하기 위한 질문이 아니다. 더위·습도, 미세먼지·대기질, 비·바람처럼 사용자가 그날 가장 크게 느낀 부담을 태그처럼 남기는 장치에 가깝다.

계산기는 이 입력을 바탕으로 RCS 90 또는 95 조건이었다면 어느 정도 범위가 가능했을지 보여준다. 중요한 것은 단일 숫자가 아니라 범위다. “정확히 몇 초 빨랐을 것이다”가 아니라 “이 정도 차이는 조건의 영향을 받은 것으로 볼 수 있다”에 가깝게 말해야 했다.

근거는 가져오되, 과하게 말하지 않기

RCS 프로모션 페이지를 만들면서 가장 신경 쓴 부분은 근거의 쓰임이었다. 더위, 습도, 대기질, 비, 바람이 러닝 성과와 체감에 영향을 줄 수 있다는 연구와 기관 자료는 있었다. 하지만 그 자료를 그대로 개인 기록 예측 모델처럼 쓰면 안 된다.

그래서 근거는 네 가지 역할로 낮춰 썼다.

참고한 방향	계산기에 반영한 방식
더위·습도는 같은 페이스를 더 힘들게 만들 수 있다	WBGT와 열 부담을 주요 조건으로 다룬다
미세먼지와 대기질은 호흡 부담과 노출 시간을 바꿀 수 있다	공기질을 단순 보조 지표가 아니라 별도 제한 요인으로 본다
비·바람은 기록보다 실행 난이도와 안전에 영향을 준다	강한 조건에서는 점수를 보수적으로 제한한다
원인을 모를 수도 있다	하나의 원인으로 단정하지 않고 복합 조건으로 처리한다

결국 이 계산기는 논문을 엄밀하게 재현한 도구가 아니다. 러너가 자기 기록을 다시 읽어보는 연습 도구에 가깝다. “그날 내가 못 뛰었다”가 아니라 “그날 조건이 내 몸에 어떤 부담을 줬을까”를 생각하게 만드는 장치다.

참고: Ely et al. (2007), El Helou et al. (2012), Marr & Ely (2010), Cusick et al. (2023), Nikolaidis et al. (2019), Weiss et al. (2024), WHO Air Quality Guidelines, NWS WBGT guidance.

보장하지 않는 쪽이 더 믿을 만했다

처음에는 더 강하게 말하고 싶어질 때도 있었다. 좋은 조건이라면 기록도 더 좋아질 수 있다. 러너에게는 분명 매력적인 메시지다.

하지만 달릴시간이 지켜야 할 선은 그 반대쪽에 있었다. 기록을 약속하지 않기. 개인의 성과를 단정하지 않기. 대신 더위, 습도, 대기질, 비, 바람 같은 조건이 달리기 체감과 실행 난이도에 어떤 영향을 줄 수 있는지 더 잘 보이게 만들기.

그래서 RCS 계산기의 결과는 예측이 아니라 시나리오다. “이 기록은 원래 이랬어야 한다”가 아니라, “더 좋은 조건이었다면 이런 범위를 참고해볼 수 있다”는 정도의 말이다.

이렇게 선을 낮추고 나니 오히려 제품이 더 분명해졌다. 달릴시간은 러너의 기록을 대신 설명하는 앱이 아니라, 러너가 자기 기록을 조건과 함께 다시 읽을 수 있게 돕는 앱에 가까웠다.

RCS 프로모션 사이트는 달릴시간을 설명하기 위한 작은 홍보 장치였다. 러너가 자기 기록을 넣어보고, 주변 러너와 이야기할 만한 결과를 얻고, 그 과정에서 달릴시간이 말하는 “조건 판단”의 가치를 자연스럽게 느끼게 하는 것이 목표였다.

그래서 계산이 맞는 것만으로는 부족했다. 결과가 러너에게 남지 않으면 프로모션 페이지로는 약했다. 저장하고 공유하고 싶어야 했다. 그래야 RCS가 앱 안의 점수에 머물지 않고, 러너들 사이의 대화 소재가 될 수 있었다.

처음 결과 화면은 설명에 가까웠다. 어떤 값을 입력했고, 어떤 조건으로 비교했고, 어느 정도 범위가 나왔는지 차분히 보여주는 방식이었다. 기능적으로는 맞았다. 그런데 너무 표 같았다.

러너가 기억할 장면은 조금 달랐다.

“그날 더 좋은 시간대에 달렸다면, 내 기록도 이렇게 달라졌을 수 있구나.”

결과는 읽는 것이 아니라 남기는 것이어야 했다

RCS 계산기는 개인 기록을 보장하지 않는다. 그렇지만 결과는 개인적인 느낌을 가져야 했다. 내가 달린 기록, 내가 느낀 조건, 그리고 더 나은 조건이었다면 가능했을지 모를 범위가 한 장 안에 들어와야 했다.

그래서 결과를 표가 아니라 카드로 바꾸기 시작했다. 중심에는 스톱워치를 두었다. 기록을 말하는 페이지라면, 숫자보다 먼저 눈에 들어오는 상징이 필요했기 때문이다.

카드 안의 문장도 줄였다. “RCS 78에서 달린 기록을 RCS 95로 환산하면…”처럼 설명이 길어지면 다시 계산기처럼 보였다. 대신 한 문장으로 좁혔다.

더 좋은 시간대에 달렸다면,
기록도 달라졌을 수 있어요.

그 아래에만 필요한 숫자를 남겼다. 실제 페이스, RCS 95 시뮬레이션 범위, 그리고 대략적인 차이. 사용자가 저장하거나 공유했을 때도 핵심이 바로 읽혀야 했다.

축하는 짧게, 숫자는 정확하게

결과 카드에는 작은 축하감도 필요했다. 계산 버튼을 누르고 바로 표가 나타나는 것보다, 잠깐의 변화가 있으면 “결과가 나왔다”는 느낌이 생긴다. 그래서 짧은 confetti와 스톱워치 숫자 전환을 붙였다.

다만 과하면 안 됐다. 이 페이지는 기록을 보장하는 이벤트 페이지가 아니다. “좋은 조건이었다면 이런 범위도 가능했을 수 있다”는 참고값을 보여주는 페이지다. 축하는 결과를 읽기 쉽게 만드는 정도에 머물러야 했다.

디테일도 생각보다 중요했다. 스톱워치 안의 숫자는 조금만 어긋나도 완성도가 떨어져 보였다. 그래서 화면 위에서 눈대중으로 맞추는 대신, 숫자가 들어갈 영역을 따로 측정하며 위치를 조정했다. 아주 작은 조정이지만, 결과 카드가 하나의 이미지로 저장될 때는 이런 차이가 더 크게 보인다.

공유 가능한 순간으로 만들기

마지막으로 붙인 것은 저장과 공유였다. 결과가 웹페이지 안에만 있으면 한 번 보고 끝난다. 하지만 이미지로 저장하거나 공유할 수 있으면, RCS는 단순 설명을 넘어 러너가 자기 기록을 다시 이야기하는 소재가 된다. 홍보도 그때 조금 자연스러워진다. 제품이 먼저 말하는 대신, 러너가 자기 기록을 두고 다른 러너에게 말을 걸 수 있기 때문이다.

여기서도 조심할 선은 그대로였다. 카드가 말하는 것은 “이 기록이 반드시 이렇게 바뀐다”가 아니다. “그날 조건이 기록 체감에 영향을 줬을 수 있다”는 참고 시나리오다.

그래서 결과 카드는 과장된 성과 이미지가 아니라, 조건을 다시 읽게 만드는 작은 리포트에 가까워야 했다. 달릴시간이 하고 싶은 말도 그쪽에 있었다. 기록을 대신 판단해주는 것이 아니라, 기록을 조건과 함께 다시 볼 수 있게 돕는 것.

계산기가 설명의 장치라면, 결과 카드는 그 설명이 남는 방식이었다.