10초의 로딩 시간이 수십 명의 목숨을 구한다는 논리에 대하여

안녕하세요. 풀링포레스트 시니어 PM 최PM입니다.

제품 로드맵을 짜다 보면 항상 부딪히는 딜레마가 있습니다. 바로 '새로운 기능 추가(Feature)'와 '성능 최적화(Optimization)' 사이의 줄다리기입니다. 비즈니스 조직은 눈에 보이는 화려한 기능을 원하고, 엔지니어링 팀은 기술 부채 해결과 성능 개선을 외칩니다. PM으로서 저는 이 사이에서 우선순위를 조율해야 하는데, 솔직히 말해 "단순히 속도가 빨라지는 것"이 비즈니스에 얼마나 큰 임팩트를 주는지 설득하기란 여간 어려운 일이 아닙니다.

오늘은 그 설득의 기술에 대해 제가 오랫동안 곱씹어온 에피소드 하나를 나누려 합니다. 바로 1983년, 매킨토시 출시를 앞둔 애플 팀의 이야기입니다.

당시 매킨토시 개발팀은 막바지 작업에 한창이었습니다. 하드웨어 스펙상으로는 경쟁작보다 훨씬 빨랐지만, 실제 체감 성능, 특히 부팅 속도는 기대에 미치지 못했습니다. 메모리 테스트와 OS 초기화, Finder 로딩까지 몇 분이 걸리는 상황이었죠. 개발자인 래리 케니언(Larry Kenyon)은 디스크 드라이버와 파일 시스템을 담당하고 있었는데, 어느 날 스티브 잡스가 찾아와 다짜고짜 "부팅이 너무 느려!"라고 소리쳤습니다.

래리는 엔지니어로서 기술적인 한계와 최적화의 어려움을 설명하려 했습니다. 하지만 잡스는 그 기술적 디테일에는 관심이 없었습니다. 대신 그는 계산기 하나를 두드리듯 논리를 전개했습니다.

"매킨토시를 500만 명이 쓴다고 가정해보자. 그들이 하루에 딱 한 번만 부팅한다고 쳐도, 부팅 시간을 10초 줄이면 하루에 5,000만 초를 아끼는 거야. 이걸 1년으로 환산하면 수십 명의 평생 시간(Lifetime)과 맞먹어. 우리가 부팅 시간을 10초 줄이면, 사람 목숨 10개를 구하는 것과 같은 가치가 있다고."

이 논리는 매우 극단적이지만, 동시에 제품 관리의 본질을 꿰뚫고 있습니다.

저는 이 일화를 처음 접했을 때, PM으로서 큰 충격을 받았습니다. 우리는 흔히 성능 이슈를 '시스템 메트릭'으로만 접근합니다. Latency가 200ms 줄었다거나, Throughput이 15% 개선되었다는 식으로 말이죠. 하지만 사용자의 관점에서 그 숫자는 단순한 숫자가 아닙니다. 그들의 '시간'이자, 그들의 '생명'입니다.

최근 풀링포레스트 내부 대시보드 프로젝트를 진행하면서 저도 비슷한 상황을 겪었습니다. 데이터 쿼리 양이 많아지면서 초기 로딩 속도가 3초를 넘어가기 시작했습니다. 개발팀은 "기능 동작에는 문제가 없고, 캐싱 전략을 도입하려면 아키텍처를 꽤 많이 손봐야 해서 리소스가 부족하다"라고 난색을 보였습니다. 3초 정도면 참을 만하지 않냐는 의견도 있었습니다.

그때 저는 잡스의 논리를 우리 상황에 맞춰 프레임워크화해서 팀에 제시했습니다.

"우리 대시보드를 사용하는 내부 직원이 200명입니다. 하루 평균 30번 페이지를 조회합니다. 3초의 로딩 지연은 하루에 18,000초, 즉 업무 시간 5시간을 공중으로 날려버리는 셈입니다. 1년이면 직원 한 명의 연봉이 그대로 증발하는 비효율이 발생합니다. 이것은 단순한 불편함이 아니라, 회사의 비용 손실입니다."

단순히 "답답하니까 빠르게 해주세요"라고 할 때와는 반응이 완전히 달랐습니다. 엔지니어링 팀은 이 문제를 '사용자 경험(UX) 개선'이 아닌 '비즈니스 비용 절감'의 문제로 인식하기 시작했고, 결국 쿼리 튜닝과 프론트엔드 렌더링 최적화를 통해 로딩 시간을 0.8초대로 단축하는 데 성공했습니다.

성능 최적화는 단순히 코드를 깔끔하게 만드는 작업이 아닙니다. 그것은 사용자에 대한 예의이자, 그들의 소중한 자산인 시간을 지켜주는 가장 직접적인 방법입니다.

주니어 기획자나 개발자분들이 종종 "이 작은 최적화가 정말 의미가 있을까요?"라고 묻곤 합니다. 티도 안 나는 0.1초를 줄이기 위해 밤을 새우는 게 맞는지 고민될 때가 분명 있을 겁니다. 그럴 때마다 저는 이 '생명을 구하는 계산법'을 떠올려보라고 권합니다.

여러분이 줄인 그 1초가 수만 명의 사용자에게 배포되는 순간, 여러분은 그들의 인생에서 의미 있는 시간을 돌려준 것입니다. 그것만큼 제품 메이커로서 보람찬 일도 없습니다.

물론 모든 상황에서 성능이 0순위일 수는 없습니다. 하지만 적어도 성능을 타협해야 할 때, 우리가 희생시키고 있는 것이 단순히 '시스템 자원'이 아니라 '사용자의 시간'이라는 점을 인지하는 태도는 시니어와 주니어를 가르는 중요한 기준이 됩니다.

오늘 여러분이 작성한 코드 한 줄, 기획한 정책 하나가 누군가의 시간을 아껴주고 있나요? 그렇다면 여러분은 오늘도 누군가의 삶을 조금씩 구하고 있는 셈입니다.