BT4Run

작업선이 갈라진 뒤의 흐름은 단순히 새 후보를 더 밀어붙이는 쪽으로만 갈 수 없었다. 한 번 reset이 들어간 뒤에는, 지금 보고 있는 후보가 예전의 어떤 판단과 어떤 출력 위에 서 있는지부터 다시 복원해야 했기 때문이다.

그래서 최근 BT4Run에서는 archive development sequence를 다시 읽고, 사용자로부터 중간에 들어온 입력이 어떤 식으로 흡수됐는지를 정리하고, 예전 explicit output과 지금 후보를 다시 나란히 놓는 문서가 함께 생기기 시작했다.

왜 archive를 다시 읽어야 했나

겉으로 보면 뒤로 가는 일처럼 보일 수도 있다. 하지만 실제로는 반대에 가깝다. 예전 것이 왜 그런 결론을 냈는지와 지금 후보가 무엇을 더 잘하고 무엇은 아직 약한지를 다시 맞대어 봐야, 이후의 교체 판단도 선호가 아니라 근거 위에서 할 수 있기 때문이다.

지금 필요한 건 더 많은 실험이 아니었다. 지금 더 필요한 건 예전 출력과 현재 후보를 같은 기준 위에 다시 올려두는 일이었다.

그래서 비교의 기준을 다시 정리했다

• 예전 출력은 왜 그런 결론이 나왔는가
• 지금 후보는 어디서 더 강해졌는가
• 무엇은 여전히 약한가
• 교체 판단을 어떤 근거 위에 올려둘 것인가

그래서 이 회차는 새 모델 발표보다, 비교 기준을 복원하는 기록에 더 가깝다.

지금의 BT4Run은 새 모델을 발표하는 단계라기보다, 예전 판단과 지금 후보를 다시 맞붙여 보며 어느 쪽이 실제로 더 믿을 만한지 정리하는 단계에 더 가깝다. worktree 분화 이후의 현재를 설명할 때 가장 먼저 나와야 하는 장면도 바로 그 비교다.

새 판단 후보를 시험하는 가장 쉬운 방법은 아예 다른 화면이나 다른 제품처럼 따로 키우는 일일 수 있다. 하지만 그렇게 하면 새 쪽이 정말 더 좋은지, 아니면 그냥 새로워 보여서 그렇게 느껴지는지 구분하기 어려워진다.

BT4Run은 그래서 반대로 갔다. 새 후보를 같은 홈 화면 안에서 시험하기로 한 것이다. source를 바꾸는 스위치를 붙이고, 제한된 조작면을 두고, session 상태와 개발용 제어를 조금씩 다듬어 가며 같은 자리에서 비교 가능한 상태를 만들기 시작했다.

왜 같은 surface 안에 묶었나

이 방식의 장점은 한 번에 크게 바꾸지 않아도 된다는 점이다. 어떤 조각은 실제로 읽힘을 좋아지게 만들고, 어떤 조각은 생각보다 큰 차이를 만들지 않는다. 같은 표면 안에서 보면 그 차이가 더 분명하게 드러난다.

다른 화면으로 빼면 새로워 보여서 좋아 보일 수 있다. BT4Run이 붙들고 싶었던 건 같은 홈 안에서 드러나는 실제 차이였다.

이 회차의 중심은 “어떻게 실험할까”가 아니라 “어떻게 같은 기준 안에 실험을 묶을까”였다.

그래서 작업 단위를 이렇게 나눴다

• source를 바꾸는 조각
• gated control을 다루는 조각
• session/access를 정리하는 조각
• operator panel처럼 실험을 더 명확하게 보여 주는 조각

---

되돌릴 수 있는 작은 조각으로 나눈 이유

BT4Run이 이 단계에서 중요하게 본 것은 실험의 양보다 비교의 질이었다. 무엇이 실제 개선인지 끝까지 확인할 수 있어야 했기 때문이다.

그래서 이 회차는 새 모델 자체보다도, 새 모델을 시험하는 방식이 어떻게 제품의 일부가 되었는지를 보여 준다. 같은 홈 화면 안에서 조금씩 바꾸며 비교하는 구조가 생기면서, 교체는 선언이 아니라 검증 과정으로 바뀌기 시작했다.

새 모델 후보가 보이기 시작하면 가장 쉬운 선택은 바로 바꾸는 일처럼 느껴진다. 조금 더 똑똑해 보이고, 설명도 더 그럴듯해 보이면 지금 쓰는 기준을 내려놓고 새 쪽으로 옮기고 싶어지기 때문이다.

하지만 BT4Run은 그 유혹을 바로 따르지 않았다. 이 앱이 다루는 건 취향형 추천이 아니라, 사용자가 오늘 달릴지 말지를 믿고 따라야 하는 판단 구조였기 때문이다. 더 좋아 보인다는 인상만으로는 부족했고, 같은 상황에서 정말 더 낫다고 말할 수 있는 비교가 먼저 필요했다.

왜 먼저 “옆에 세우기”가 필요했나

BT4Run은 새 후보를 곧바로 다음 기본값으로 선언하지 않았다. 대신 지금 릴리즈에 가까운 판단 구조 옆에 나란히 세워, 같은 문제를 두 방식이 어떻게 다루는지 먼저 보려 했다.

새 후보가 좋아 보인다는 인상만으로는 부족했다. 먼저 필요한 건 같은 문제 위에서 더 낫다는 증거였다.

“바로 교체하지 않는다”는 판단 자체가 이 회차의 핵심 결정이었다.

좋아 보이는가보다, 같은 기준에서 더 나은가를 먼저 묻는다.

이번 회차에서 잠긴 원칙

• 지금 릴리즈 기준을 버리지 않는다
• 새 후보를 옆에 둔다
• 같은 문제를 같은 화면 맥락에서 비교한다
• 교체 선언은 그다음에 한다

---

같은 화면에서 비교해야 했던 이유

새 모델이 따로 놀기 시작하면 금방 좋아 보인다. 하지만 그 인상이 정말 판단 품질에서 오는 건지, 아니면 그냥 다른 화면이라서 그렇게 느껴지는 건지는 구분하기 어렵다. BT4Run이 후보를 홈 경험 가까이에 두려 했던 이유도 여기에 있다.

이 회차에서 독자가 읽어야 하는 것

이 회차의 핵심은 새 모델이 이미 더 낫다고 선언하는 데 있지 않다. BT4Run이 판단 기준을 바꿀 때 무엇을 먼저 증명해야 하는지를 보여 주는 데 있다.

개발을 오래 하다 보면 기능 자체보다도 ‘어디서부터 다시 이어야 하는가’가 더 큰 문제가 되는 순간이 있다. BT4Run에서는 한 번 파일 삭제 이슈를 겪은 뒤 그 질문이 더 선명해졌다.

이후의 선택은 단순 복구가 아니었다. 본선 개발을 이어 가는 자리와, 기준선·운영 판단·재구성 작업을 맡는 자리를 더 분명히 나누는 쪽으로 흐름을 다시 세우기 시작했다. 그 결과가 bt4run과 bt4run-pm-reset으로 읽히는 두 개의 워크트리 운영 형태다.

이 분화의 목적은 일을 복잡하게 만드는 데 있지 않았다. 오히려 반대에 가깝다. 릴리즈에 가까운 본선 흐름과, 무엇이 현재 truth인지 다시 정리하는 흐름을 섞어 두면 둘 다 더 쉽게 오염되기 때문이다.

그래서 worktree footprint를 줄이고, preflight 규칙을 강화하고, 어느 스레드가 어떤 provenance를 가져야 하는지 같은 운영 규칙도 같이 세워졌다. 즉 파일 삭제 이슈 이후의 핵심 변화는 ‘기능 복구’가 아니라 ‘다시 잃지 않기 위한 작업 형태 재정렬’이었다.

이 단계가 중요한 이유는 이후의 E14 실험도 그냥 옆에서 생긴 새 기능이 아니라, 이런 분리 위에서 읽혀야 하기 때문이다. BT4Run의 최근 작업은 제품 변화와 운영 구조의 변화가 동시에 얽혀 있고, 바로 여기서부터 그 두 흐름이 갈라져 보이기 시작한다.

BT4Run이 출시 준비 단계로 들어가면서 더 중요해진 건 기능 하나를 더 붙이는 일이 아니었다. 지금 보고 있는 화면이 어떤 기준에서 맞다고 할 수 있는지, 그리고 어떤 QA를 통과해야 그 판단을 믿을 수 있는지를 먼저 고정하는 일이었다.

특히 위치 전환과 stale forecast 문제는 겉으로는 작은 UX처럼 보여도 실제로는 제품 신뢰와 직접 연결됐다. 사용자가 위치를 바꿨는데 오래된 정보가 남아 있으면, 아무리 좋은 판단 모델이 있어도 앱은 바로 흔들리게 된다.

그래서 이 시기에는 홈 경험 후속, 위치 결정, QA gate, release readout 같은 문서와 규칙이 함께 정리되기 시작했다. 목적은 문서를 늘리는 데 있지 않았다. 무엇을 truth로 보고, 어디까지가 실제 출시 판단의 기준인지를 명시하는 데 있었다.

이 변화 덕분에 BT4Run은 ‘좋아 보이는 기능 조합’에서 조금 더 나아가, ‘어떤 조건을 통과해야 실제 릴리즈 후보라고 부를 수 있는가’를 내부적으로 구분할 수 있게 됐다.

제품은 화면만으로 완성되지 않는다. 특히 출시 직전 단계에서는 같은 화면도 어떤 빌드와 어떤 QA를 기준으로 보느냐에 따라 전혀 다른 의미를 갖는다. BT4Run은 이 시점부터 그 차이를 제품 운영의 일부로 직접 다루기 시작했다.

점수와 밴드가 생겼다고 해서 홈 상단이 바로 좋은 경험이 되는 건 아니다. 사용자는 오늘 상태를 보는 동시에, 그 판단이 어디에서 끝나고 어디로 이어지는지도 같이 느껴야 한다.

BT4Run은 그래서 홈 히어로를 단순 장식이 아니라 첫 판단 진입점으로 다시 다뤘다. 점수, 한 줄 해석, 현재 상황 가이드, Best Time, 그리고 필요할 때 더 자세히 내려갈 수 있는 연결이 함께 있어야 한다고 본 것이다.

이 단계에서 한 일은 두 가지에 가까웠다. 하나는 히어로와 주간 잠금 흐름에서 어떤 신호를 실제로 봐야 하는지 계측 기준을 고정한 일이고, 다른 하나는 점수 밴드에 따라 캐릭터와 상태 표현이 실제로 연결되도록 홈 히어로의 표현 층을 다듬은 일이다.

이렇게 되면 홈은 예쁜 첫 화면이 아니라, 오늘 바로 달릴지와 언제가 더 나은지를 읽는 첫 표면이 된다. 더 자세한 근거를 보고 싶으면 내려갈 수 있고, 주간 계획이 필요하면 잠금된 Weekly로 이어지는 흐름도 자연스럽게 설명된다.

결국 이 변화가 보여 주는 건 BT4Run의 홈 경험이 정보 요약을 넘어서고 있다는 점이다. 앱을 열었을 때 가장 먼저 필요한 판단이 무엇인지, 그리고 그 판단이 다음 행동으로 어떻게 이어져야 하는지를 제품 표면에서 직접 다루기 시작한 것이다.

날씨 앱을 여러 개 열어 보는 러너에게 필요한 건 숫자 자체보다 결론에 가까운 신호일 때가 많다. 기온, 강수, 미세먼지, 자외선, 바람을 모두 확인해도 결국 다시 스스로 조합해야 한다면 판단은 여전히 사용자의 몫으로 남는다.

BT4Run은 그 지점을 먼저 줄이려 했다. 그래서 이번 단계에서는 오늘 상태를 0-100 스코어와 low / mid / high 밴드로 먼저 보여 주는 기준을 고정했다. 핵심은 예쁜 숫자를 만드는 것이 아니라, 같은 입력이면 같은 해석이 나오고 왜 그런지 설명할 수 있는 구조를 만드는 데 있었다.

이 판단에서 가장 중요하게 둔 축은 공기질과 달릴 수 있는 시간창이었다. 짧은 clean window 하나 때문에 하루 전체가 과하게 좋아 보이거나, 반대로 종일 moderate한 날이 지나치게 나빠 보이는 일을 막기 위해 day score guardrail도 함께 두었다.

그 결과 홈 히어로는 단순한 요약 카드가 아니라, 사용자가 앱을 열자마자 오늘 상태를 읽는 첫 표면이 됐다. 이제 사용자는 오늘 달릴 만한지, 언제가 더 나은지를 날씨 표를 다시 해석하지 않고도 먼저 받아볼 수 있다.

이 변화는 BT4Run이 날씨 정보 앱이 아니라 러닝 판단 앱이어야 한다는 방향을 더 분명하게 만든다. 숫자는 뒤에 남아도 되지만, 첫 질문에 대한 답은 앞에 나와야 한다는 쪽으로 제품의 중심을 옮긴 셈이다.

제품이 처음 모양을 갖추기 시작할 때 가장 빨리 흐려지는 건 경계다. 무엇이 오늘의 판단인지, 무엇이 주간 계획 조정인지, 왜 어떤 부분은 잠겨 있어야 하는지가 분명하지 않으면 화면은 늘어나는데 제품은 오히려 덜 또렷해진다.

BT4Run은 그래서 weekly view와 billing scaffold를 붙이는 시점에 Free와 Pro의 경계를 같이 세우려 했다. Free는 지금 달릴지와 언제가 나은지까지, Pro는 오늘이 안 좋을 때 이번 주 안에서 계획을 다시 조정하는 데까지라는 식으로 문제를 나눠 본 것이다.

이 구분이 중요했던 이유는 paywall이 결제를 요구하는 화면이기 전에, 왜 더 넓은 판단이 별도 가치인지 설명하는 장치여야 했기 때문이다. 단순히 기능이 하나 더 있는 것이 아니라, 사용자의 고민 단위 자체가 바뀐다는 점이 먼저 보여야 했다.

그래서 주간 보기와 결제는 별도 기능이 아니라 같은 질문의 두 번째 층으로 붙기 시작했다. 오늘의 판단이 1층이라면, 이번 주를 어떻게 조정할지는 그다음 층이라는 식이다.

이 단계에서 BT4Run은 처음으로 ‘무엇을 보여 줄 것인가’보다 ‘어디까지를 같은 문제로 묶을 것인가’를 제품 구조 안에 직접 새기기 시작했다. 그 덕분에 이후 홈과 주간 보기, 결제 흐름이 같은 제품 언어 안에서 맞춰질 수 있는 기반이 생겼다.

처음 BT4Run을 만들 때의 질문은 복잡하지 않았다. 러너가 앱을 열었을 때 더 많은 날씨 숫자를 보여 주는 게 정말 맞는가, 아니면 오늘 달릴지와 언제가 더 나은지를 먼저 말해 주는 쪽이 더 필요한가였다.

일반적인 날씨 앱은 정보는 많지만 결론은 적다. 기온, 강수, 공기질, 자외선을 모두 보여 줘도 사용자는 다시 스스로 조합해야 한다. 그래서 BT4Run은 처음부터 데이터 뷰어가 아니라 판단 보조 도구로 출발하려 했다.

이 단계에서 세운 첫 뼈대는 모바일 forecast shell과 weekly route skeleton이었다. 중요한 건 화면 수보다 구조였다. 오늘의 판단을 먼저 보여 주고, 더 멀리 보면 주간 계획까지 연결될 수 있는 제품 모양을 먼저 잡는 일이었다.

이때부터 Free와 Pro의 방향도 같이 드러났다. Free는 오늘의 판단, Pro는 주간 조정이라는 경계를 일찍 잡아 두지 않으면 앱은 쉽게 ‘날씨 정보는 많은데 무엇이 핵심인지 모르는 상태’로 흐를 수 있기 때문이다.

그래서 BT4Run의 시작은 기능을 많이 붙이는 일이 아니라 질문을 좁히는 일이었다. 이 앱은 날씨를 길게 설명하는 앱이 아니라, 오늘 뛰어도 되는지와 달린다면 언제가 나은지를 먼저 말하는 앱이어야 했다.