우리 팀이 ‘더 빠른 말’을 만들게 하지 않으려면

자동차 왕 헨리 포드의 유명한 일화가 있죠. "만약 고객들에게 무엇을 원하냐고 물었다면, 그들은 '더 빠른 말'을 원한다고 답했을 것이다." 이 말은 사용자의 말 속에 숨겨진 진짜 니즈, 즉 '더 빨리 이동하고 싶다'는 본질을 꿰뚫어 봐야 한다는 통찰을 줍니다.

그런데 생각해 보세요. 만약 헨리 포드가 직원들에게 "고객들이 원하니, 세상에서 가장 빠른 말을 만듭시다!"라고만 지시했다면 어떻게 됐을까요? 아마 직원들은 밤을 새워가며 세상에서 가장 가벼운 말 안장, 가장 튼튼한 편자를 개발해냈을 겁니다. 모두가 정말 열심히 일했겠죠. 하지만 그 결과물은 결코 자동차가 될 수 없었을 겁니다.

이 이야기가 100년 전 이야기처럼 들리시나요? 저는 우리가 매일 회의실과 지라(Jira)에서 마주하는 현실이라고 생각합니다. 사실, 우리가 만드는 제품들도 대부분 자동차 보다는 더 빠른 말에 가까운 것이 사실이니까요. 우리는 분명 세상을 바꿀 자동차를 만들기로 하고 프로젝트를 시작했는데, 왜 결과물은 종종 그저 조금 더 빠른 말에 그치고 마는 걸까요? 어떻게 하면 우리 팀이 더 빠른 말이 아닌, 자동차를 만들도록 할 수 있을까요?

1. 프로젝트의 근본 목표는 쉽게 분해된다.

모든 프로젝트는 위대한 비전과 함께 시작합니다. 하지만 주의 깊게 살피지 않는다면, 그 비전은 실무로 내려오는 과정에서 잘게 쪼개지며 원래의 의미를 잃어버리는 경우가 많습니다.

1단계 (Vision): "우리의 목표는 고객의 '온라인 쇼핑 경험'을 혁신하는 것이다!" (위대한 시작)

2단계 (Epic): "이를 위해 'AI 기반 개인화 추천' 기능을 만들자." (구체화)

3단계 (User Story): "사용자는 자신의 과거 구매 데이터를 기반으로, 좋아할 만한 상품을 메인 화면에서 바로 볼 수 있다." (세분화)

4단계 (Jira Ticket): "메인 배너 캐러셀 UI 컴포넌트 개발", "추천 상품 API 연동", "이미지 로딩 속도 개선"... (완전한 파편화)

근본 목표는 어느새 사라지고 눈 앞에 태스크에만 집중하게 된다. 출처: Gemini 생성

이 과정 자체는 일을 효율적으로 분배하기 위해 반드시 필요합니다. 문제가 되는 경우는, 마지막 단계에서 개발자와 디자이너의 손에 '쇼핑 경험 혁신'이라는 근본 목표는 없고, 오직 '캐러셀 UI 컴포넌트 개발'이라는 기능 조각밖에 없을 때입니다. 당장 자신에게 주어진 과업이 있는 사람들은, 일을 하면서 근본 목표를 생각하기 어렵습니다. 그저 눈앞의 티켓을 가장 완벽하게 해치우는 데만 집중하게 되죠. 이런 방식으로 근본 목표가 분해되고 나면, 우리 팀이 쏟아부은 노력은 완전히 엉뚱한 곳에 도착해있곤 합니다.

2. 근본 목표가 분해된 팀에서 볼 수 있는 신호

우리 팀의 근본 목표가 사라지고 있다는 신호는 생각보다 명확하게 나타납니다. 혹시 당신의 팀도 이런 증상을 겪고 있지는 않나요?

증상 1. 좀비 기능의 창궐 아무도 왜 만들어야 하는지 명확히 설명하지 못하지만, 지라에 티켓이 등록되어 있으니 일단 만드는 기능들이 늘어납니다. 회의에서 "이거 왜 만들어요?"라고 물으면 "원래 만들기로 했잖아요"라는 동문서답이 돌아옵니다.

증상 2. 지엽적인 디자인 논쟁의 장기화 "이 버튼의 색깔은 파란색이 좋을까요, 빨간색이 좋을까요?" 같은 논쟁이 끝없이 이어집니다. 논쟁의 기준이 되어야 할 "우리의 목표 달성에 어떤 색이 더 도움이 되죠?"라는 근본적인 질문을 아무도 던지지 않기 때문입니다.

증상 3. 무의미한 속도 숭배 "이번 스프린트에서 티켓 50개를 닫았다!"처럼, '얼마나 많은 일을 했는가(Output)'가 '얼마나 큰 가치를 만들었는가(Outcome)'를 대체합니다. 팀은 열심히 달리고 있지만, 그 방향이 올바른지에 대해서는 아무도 신경 쓰지 않게 됩니다.

아무리 열심히 일해도, 더 빠른 말을 만들고 있다면 아무런 소용이 없다.

저는 어떤 팀이 이런 증상을 보이게 된다면, 그 팀이 만들고 있는 제품이 자동차가 아닌 더 빠른 말이 될 가능성이 높다고 생각합니다. 솔직히 말하면, 더 빠른 말이라도 되면 다행입니다. 많은 경우에는 옆으로 달리는, 신기하거나 놀랍기는 하지만 딱히 쓸 데는 없는 말이 되기도 하니까요.

3. 우리 팀이 해야 하는 일: 모든 일에 ‘근본 목표’를 붙여라.

이 슬픈 비극의 고리를 끊으려면 어떻게 해야 할까요? 생각보다 간단한 규칙에서 시작할 수 있습니다. 바로 모든 지라 티켓, 모든 피그마 디자인 프레임과 같은 실무 지시서를 통해서도 그것이 어떤 상위 목표(OKR, Epic 등)에 기여하는지를 알 수 있도록 만드는 것입니다.

사실 저는 이 지점에서 기획자의 역할이 필요하다고 생각합니다. 기획자는 단순히 요구사항을 정리해서 던져주는 사람이 아니라, 이 근본 목표를 모두에게 지속적으로 상기시켜주는 사람이어야 합니다. 개발자가 기획서를 바탕으로 자신이 무슨 일을 해야 하는지 파악할 때, 그 코드를 한 줄 치기 전에, 상위 목표를 생각하고 "아, 내가 지금 만드는 이 작은 버튼이 결국 '고객의 쇼핑 경험 혁신'을 위한 것이구나"라고 이해할 수 있어야 합니다.

이 근본 목표가 살아있을 때, 개발자는 더 나은 기술적 대안을 제안할 수 있고, 디자이너는 목표에 더 부합하는 시안을 내놓을 수 있습니다. 결국 팀이 만들고 있는 제품의 근본 목표는 팀원들을 수동적인 부품이 아닌, 능동적인 문제 해결사로 만드는 가장 강력한 동기부여이기 때문입니다.