RUN

[Project: Run] 04. 10km 기록 단축의 명과 암: '페이스 오버클러킹'에 대한 데이터 회고

런코리치 2026. 4. 27. 08:00

1. 서론: 기록 단축이라는 성과 뒤에 숨은 데이터의 경고

러닝 시스템 최적화 2단계에 진입했습니다. 지난 23일, 생애 첫 10km를 58분 18초로 완주하며 1시간 이내 기록의 기쁨을 맛보고 금,토요일 배드민턴을 치고, 4월 26일 오늘 다시 러닝을 하였습니다. 결과는 55분 53초. 표면적인 수치만 보면 비약적인 발전이지만, 내부 로그를 뜯어보면 '페이스 유지 실패'라는 중요한 버그(Bug)가 발견되었습니다. 오늘은 기록 단축의 기쁨보다는, 왜 일정하게 페이스를 제어하지 못했는지에 대한 뼈아픈 성찰을 기록해 보려 합니다.


2. 2026. 04. 26. 러닝 세션 데이터 개요

항목 데이터 값 (Raw Data) 비고
총 거리 10.01 km 일관된 10km 테스트베드
총 운동 시간 55분 53초 이전 기록 대비 2분 25초 단축
평균 페이스 5' 34" / km 지난 세션 대비 14초 단축
평균 심박수 152 bpm 고무적 지표: 강도 상승에도 심박 유지
평균 케이던스 167 spm 170spm을 향한 안정적 흐름
운동 칼로리 877 kcal 효율적인 에너지 연소
누적 고도 42 m 코스 일관성 유지


3. 랩 타임 분석: "나도 모르게 올라간 클럭수"

오늘의 전체적인 페이스 로그를 보면 의도치 않은 '오버클러킹' 구간이 여실히 드러납니다.

  • 초반부 (1-2km): 시작부터 공격적이었습니다. 1km를 5분 59초로 끊고, 2km 지점에서 5분 08초라는 놀라운(그러나 위험한) 페이스를 찍었습니다. 이 구간에서 몸이 너무 가볍게 느껴진 나머지 제어 장치가 풀려버린 셈입니다.
  • 중반부 (3-7km): 5분 30초대에서 안정화되는 듯했으나, 7km 지점에서 다시 5분 25초로 튀어 올랐습니다.
  • 후반부 (8-10km): 결국 중반부의 무리한 가속이 부채로 돌아왔습니다. 8km와 10km 지점에서 페이스가 5분 43초까지 밀리는 현상이 발생했습니다.

데이터는 정직합니다. 초중반에 나도 모르게 쏟아부은 에너지가 후반부 유지력을 갉아먹었다는 사실을 랩 타임이 증명하고 있습니다.

https://run-code-rich.tistory.com/entry/run-log-260423

 

[Project: Run] 03. 10km의 벽을 깨다: 데이터로 증명한 유산소 엔진의 효율성 개선

1. 서론: 한계를 재정의하다소프트웨어 최적화 과정에서 가장 짜릿한 순간은 시스템의 처리 용량(Throughput)을 두 배로 늘렸음에도 응답 속도와 자원 사용률이 안정적일 때입니다. 러닝 역시 마찬

run-code-rich.tistory.com


4. 성찰: 시스템 과부하를 초래한 페이스 관리 실패

가장 아쉬운 점은 '적정 페이스 유지'에 실패했다는 것입니다. 러닝은 100m 스프린트의 반복이 아니라, 주어진 자원을 목표 지점까지 효율적으로 분배하는 '스케줄링' 싸움입니다.

오늘 기록한 5분 8초나 5분 25초 페이스는 현재 제 엔진(심폐능력)으로는 지속 가능하지 않은 '피크(Peak) 부하'였습니다. 이 구간에서 근육에 젖산이 쌓이기 시작했고, 이는 후반 2km를 평소보다 고통스럽게 만들었습니다. 만약 2km 지점에서 5분 8초가 아닌 5분 40초를 일정하게 유지했다면, 오히려 후반부에도 5분 30초대를 유지하며 더 높은 **'전체 효율'**을 냈을지도 모릅니다.

개발자로서 '초기 성능'에 눈이 멀어 시스템 전체의 '안정성'을 놓친 꼴입니다. 아무리 빠른 응답 속도를 보여도 서버가 마지막에 뻗어버린다면 그것은 실패한 아키텍처입니다.


5. 지표의 재해석: 그래도 희망적인 심박수(152bpm)

실패에 대한 반성 속에서도 희망적인 데이터는 발견되었습니다. 평균 페이스를 14초나 당겼음에도 불구하고 평균 심박수가 지난번과 동일한 152bpm으로 측정되었습니다.

이것은 무엇을 의미할까요?

  1. 유산소 베이스의 확장: 제 신체가 5분 30초대 페이스를 받아들일 준비가 어느 정도 되어가고 있다는 뜻입니다.
  2. 회복 탄력성: 중간중간 페이스가 튀었음에도 심박수가 폭발하지 않고 제어되었다는 것은 시스템의 안정성이 기본적으로 강화되었음을 시사합니다.

결국 하드웨어(신체)는 준비되어 가고 있는데, 소프트웨어(페이스 운영 전략)가 이를 제대로 핸들링하지 못한 것입니다.


6. 결론 및 향후 계획: "적정 페이스를 찾아 유지하는 연습"

오늘의 러닝은 '기록 단축'이라는 훈장과 '운영 실패'라는 과제를 동시에 남겼습니다. 다음 빌드(Build)에서는 다음의 수칙을 엄격히 적용해 보려 합니다.

■ Next Action Plan: 페이스 안정화 로직 구현

  1. 초반 억제: 1~3km 구간은 무조건 목표 페이스보다 5~10초 느리게 설정하여 엔진 예열에 집중하겠습니다.
  2. 알람 모니터링: 갤럭시 워치의 페이스 알람 기능을 활용해 5분 30초보다 빨라질 경우 즉시 제동을 걸겠습니다.
  3. 지속 가능성 최우선: 10km 전체를 관통하는 '일관된 랩 타임 그래프'를 만드는 것을 기록 단축보다 우선순위에 두겠습니다.

기록은 나중에 따라오는 보너스일 뿐입니다. 진정한 러너는 자신의 속도를 완벽하게 컨트롤할 줄 아는 사람이라는 것을 오늘 다시 한번 배웁니다. 다음에는 더 정교하게 다듬어진 페이스 로그를 가지고 돌아오겠습니다.

코딩도, 투자도, 그리고 러닝도 결국 '적정 선을 지키는 꾸준함'이 승리하는 법입니다.