물포자가 물리학으로 본 제품 개발: 속도는 벡터다

우리 팀의 제품 개발 속도가 빠르다'는 말은 "우리 팀은 빠르게 움직이고 있다" 대신 "우리 팀은 목표한 위치로 빠르게 다가가고 있다"로 해석하는 게 옳습니다.

8월 말부터 최수민님과 매주 오프로 만나서 Vooster를 페어 개발하고 있습니다. 그리고 만날 때마다 절반 이상의 시간을 팀/제품 방향성 논의에 씁니다. 얼마 전 입사한 코르카에서도 대표님과 회사/제품 방향성에 대한 논의를 자주 합니다.

코딩을 (병렬로 토큰 태우기를) 충분히 못하고 있는 건 항상 아쉽지만, 그렇다고 제가 특별히 느리다고 생각하진 않았는데요. 왜 그런가 돌이켜보니 '속도는 크기뿐 아니라 방향도 있는 벡터'라는 게 머릿속에 박혀있어서 그랬던 것 같습니다.

여기서 출발해 물리학의 기초 개념들을 제품 개발에 접목해보니 (특히 초기) 제품 개발 속도를 끌어올리는 아이디어를 몇가지 도출할 수 있었어요. 비록 고등학교 때 물리학을 포기한 몸이고, 여러 비약이 섞여있지만 재미있는 사고 실험이었습니다.

아래는 모두 '속도는 벡터다'에서 파생된 것들입니다.


속도 벡터의 정의는 '단위 시간당 위치 변화량'입니다. 이에 맞추면 '우리 팀의 제품 개발 속도가 빠르다'는 말은

  • 우리 팀은 빠르게 움직이고 있다 대신
  • 우리 팀은 목표한 위치로 빠르게 다가가고 있다 로 해석하는 게 옳습니다.

따라서 제품 개발 속도를 높이려면:

  1. 목표 지점을 정해야 하고
  2. 목표까지 가는 방향을 잡아야 하고
  3. 팀이 함께 그 방향대로 제품을 밀어야 합니다.

1) 목표 지점 정하기

여기에는 팀과 제품의 비전과 로드맵을 그리고, 제품의 와우 모먼트를 찾아 북극성 지표를 정하고, 고객의 신규 기능 요청으로부터 Jobs to be done을 찾아내는 등의 활동이 포함됩니다.

목표를 잡다 보면 자연스럽게 그 목표가 위치한 공간에서 우리가 현재 어느 좌표에 있는지 확인하게 됩니다. 만약 현재 위치를 알기 어렵다면 지표 설정/측정/분석 환경을 개선해야 한다는 신호입니다.

2) 목표까지의 방향 잡기

현재 좌표와 목표 좌표를 알면 직선이 그어지지만, 항상 직선으로만 방향을 잡을 순 없습니다. 예를 들어 중간에 장애물이 있다면 피할 수도 있고 치울 수도(예: A 문제를 더 쉽게 풀려면 B부터 풀어야 한다) 있겠죠.

그리고 목표에 더 일찍 도착하는 경로가 애초부터 직선이 아닐지도 모릅니다. 비탈길에서는 직선경로보다 살짝 아래로 기울어진 싸이클로이드 곡선이 더 빠르니까요. 외력이 가속도를 부여하는 환경에서는 외력을 이용하는 게 유리합니다. 제품 개발에서도 살짝 돌아가는 것 같아도 거시적 트렌드(예: AI와 에이전트)에 올라타는 게 더 유리할 수 있습니다.

경로상 장애물을 인지하고, 피할지 치울지 선택하고, 외력을 고려해 어느 방향으로 움직일지 결정하는 것 모두 속도를 높이는 데 중요합니다.

3) 팀이 함께 그 방향대로 제품을 민다

여기에는 벡터가 다른 벡터와 합쳐진다는 함의가 있습니다. 구성원들끼리 제품을 다른 방향으로 밀어 알짜힘(Net Force)이 작아지면 열심히 노력해도 목적지와의 거리는 별로 좁혀지지 않습니다. 리더는 모두가 같은 방향을 인식하고 힘을 쓸 수 있도록 시간과 노력을 들여야 합니다. 미션, 비전, 조직문화 등이 이를 뒷받침합니다.

방향이 맞춰졌다면 이제 각자의 힘이 제품에 잘 전달되게 해야죠. 적절한 도구를 제공하거나, 그러한 도구를 직접 개발하거나, 도구를 만드는 도구를 개발하는 등의 일이 여기에 속합니다. (예: 가설 확인을 위한 대시보드에 쓰이는 쿼리를 만드는 프롬프트 빌더)

그런데 힘을 준다고 바로 움직임이 생기는 건 아닙니다. 움직일 때까지, 더 정확히는 원하는 방향으로의 움직임이 관찰될 때까지 계속 밀어야 합니다.

4) 움직일 때까지 민다

저는 제품 개발에서의 '움직임'이란 '기능 구현'이 아니라 '제품/기능에 대한 사용자와 고객의 반응, 그리고 그로 인한 북극성 지표 변화'라고 생각합니다.

물체가 밀어도 움직이지 않는 건 마찰력 때문이죠. 마찰력을 줄이는 방법을 제품 개발에 대입해봤습니다.

  • 무게를 줄인다: 기능이 많을수록 유지보수가 어려워집니다. 단순해 보이는 기능이더라도 추가할지 말지를 신중하게 결정하고, 혹시 뺄 건 없는지 자주 돌이켜봐야 합니다.
  • 접촉면을 매끄럽게 만든다: 사용자 및 고객과 첫 접점을 만드는 UI/UX는, 특히 랜딩 페이지와 온보딩 플로우는 홀린듯 다음 스텝으로 넘어가 핵심 가치까지 도달하도록 구현하는게 중요합니다.
  • 일단 움직이게 만든다: 움직이기 시작한 물체는 관성 때문에 마찰력이 줄어듭니다. 초기 제품일수록, 효율이 안좋더라도 발로 뛰어다니며 사용자를 확보하고 피드백과 사회적 증거를 쌓는 게 좋습니다.

5) 움직임을 관찰하며 계속 민다

때로는 움직임이 생겼는데도 인지하지 못할 수도 있습니다. 이런 불상사를 피하려면 더 정밀한 관찰 도구를 사용하거나(이벤트 로깅, 에러 모니터링, 유저 피드백 창구 등 도입) 더 가까이에서 봐야 합니다(분석 도구나 모니터 너머로만 사용자와 만나는 대신, 실제로 만나서 제품 사용하는 모습을 관찰 + 녹화 + 인터뷰).

속도에 시간을 곱하면 거리가 되죠. 우리가 궁극적으로 원하는 건 속도 그 자체가 아니라 목적지까지의 거리를 좁히는 것임을 잊지 맙시다. 즉, 유의미한 움직임이 확인됐다면 이제 충분한 시간을 투입해 계속 그 방향으로 밀어서 실제 거리를 늘려야 합니다.

맺으며

지금까지 제품 개발 속도를 높이는 방법에 대해 이야기했습니다. 하지만 속도가 높아진다고 좋기만 한 건 아닙니다. 속도가 붙어 큰 운동량을 갖게 된 물체는 관성 탓에 방향을 바꾸기가 어렵기 때문입니다.

대기업보다 스타트업이, 스타트업보다 1인 기업이 더 빠르게 피봇할 수 있는 이유도 관성의 법칙 덕분입니다. 제품이 무거워지고 시장에서 성공 가도를 달리면 작은 방향 수정조차 엄청난 에너지와 시간이 필요해집니다. 이게 어쩌면 '조직 경직성'의 물리적 해석일지도 모르겠네요.

따라서 강력한 엔진만큼이나 정교한 핸들과 내비게이션, 브레이크를 모두 갖춘 팀이, 의도적으로 속도를 줄여 관성을 제어하고 방향을 재설정할 줄 아는 용기를 가진 팀이, '하지만 빨랐죠?'의 함정을 피하는 팀이 궁극적으로 제품을 '더 빨리' 성공시킬 수 있다고 생각합니다.