같은 팀에서 같은 시간을 일하는데, 누군가는 점점 더 큰 영향력을 갖게 되고, 누군가는 그 자리에 머문다. 실행 속도의 차이가 아니다. 코드 품질의 차이도 아니다. 둘 다 잘한다. 그런데 결과가 다르다.
차이는 대부분 사고의 출발점에 있다. 주어진 것에서 위로 올라가는 사람과, 전체에서 아래로 내려오는 사람. Bottom-up과 top-down의 차이다.
시킨 일을 잘하는 함정
Bottom-up 사고란, 주어진 것에서 출발하는 방식이다. 티켓을 받으면 그 기능의 구현에 집중한다. "이 API를 어떻게 만들까?" "이 컴포넌트를 어떻게 최적화할까?" 눈앞의 과제를 풀어내는 데 에너지를 쏟는다.
이것이 나쁜 건 아니다. 실행력을 기르는 데 필수적이고, 커리어 초반에는 자연스러운 사고방식이다. 문제는 이것이 유일한 모드로 굳어질 때 발생한다.
특히 빠르게 움직이는 조직일수록 이 습관이 강화된다. 빠른 실행이 미덕이고, 시야를 넓힐 여유가 없고, "일단 만들고 보자"가 문화다. 매일 불을 끄다 보면, 불이 왜 나는지 생각할 틈이 없다. 2년, 3년을 그렇게 보내면 bottom-up이 사고의 기본값이 된다.
요리에 비유하면, 재료를 잘 다루는 것과 코스 전체를 설계하는 것의 차이다. 재료를 잘 다루는 능력은 필수지만, 코스를 설계하려면 전혀 다른 차원의 시야가 필요하다. 손이 빠른 것과 방향이 맞는 것은 별개의 문제다.
출발점이 결론을 결정한다
Bottom-up 사고에는 전형적인 패턴이 있다. 수단에서 출발해서 목적을 역추론하는 것이다. "이 기능을 만들면 좋지 않을까?" → "만들 수 있으니까 만들자" → "만들었으니 효과가 있을 것이다." 수단이 목적을 정당화하는 구조다.
반대 방향은 이렇다. "돈을 1억 벌려면 무엇을 해야 할까?" → "고객이 가장 아파하는 문제는 무엇인가?" → "그 문제를 풀 수 있는 가장 효과적인 방법은?" 같은 역량을 가진 사람이라도, 질문의 방향만 바뀌면 완전히 다른 결론에 도달한다.
"페이지 로딩을 200ms 줄이자"는 bottom-up이다. "사용자가 이탈하는 진짜 이유가 뭘까?"는 top-down이다. 후자의 질문을 던지면, 로딩 속도가 아니라 온보딩 플로우 자체가 문제라는 걸 발견할 수도 있다. 같은 시간을 쓰되, 전혀 다른 곳에 쓰게 된다.
설계에서도 마찬가지다. "검색 결과 필터링"을 "상품 목록 페이지"의 부속 기능으로만 보면, 필터가 검색·카테고리·추천 등 여러 진입점에서 공통으로 쓰인다는 사실을 놓친다. 특정 페이지의 요구사항에서 출발하면 거기에 맞춘 구조가 나오고, 전체 사용자 플로우에서 출발하면 간결하면서도 범용적인 구조가 나온다.
출발점이 다르면 도착지가 다르다.
실행력만으로 갈 수 있는 곳
커리어 초반에는 실행력만으로 충분하다. 주어진 문제를 빠르고 정확하게 풀 수 있다면, 그것만으로도 가치가 있다. 하지만 어느 시점부터 실행력만으로는 넘을 수 없는 벽이 나타난다.
- 기술적 의사결정에서 "왜 이 방식이어야 하는가"를 설명하지 못할 때
- 내 작업이 다른 팀에 미치는 영향을 예측하지 못할 때
- 문제를 정의하지 못하고, 정의된 문제만 풀 수 있을 때
- 우선순위를 스스로 판단하지 못할 때
연차가 올라갈수록, 전체 시스템에 대한 이해도가 핵심 평가 기준이 된다. 내가 만드는 것뿐 아니라, 제품 전체, 업계 전체를 보는 시야.
이것은 능력의 문제가 아니라 습관의 문제다. Bottom-up이 체화되면, top-down을 시도할 기회 자체를 만들지 않게 된다. 주어진 일을 끝내고, 다음 일을 집어 들고, 또 끝내고. 바쁘지만 시야는 넓어지지 않는 루프.
Top-down으로 본다는 것
Top-down 사고는 "큰 그림을 봐라"라는 모호한 조언이 아니다. 구체적인 사고의 전환이다.
- "이 API를 어떻게 만들까?" → "이 API가 왜 필요한가? 정말 API가 답인가?"
- "이 버그를 어떻게 고칠까?" → "이 버그가 발생하는 구조적 원인은 무엇인가?"
- "이 피처를 어떻게 출시할까?" → "이 피처가 풀고 있는 고객의 문제는 무엇인가?"
일을 더 많이 하라는 것이 아니다. 같은 일을 다른 해상도에서 보라는 것이다. 지도 앱에서 줌 레벨을 조절하는 것과 같다. 줌인하면 거리 이름이 보이고, 줌아웃하면 도시 전체의 동선이 보인다. 둘 다 필요하지만, 줌인만 할 줄 아는 사람은 목적지까지의 최적 경로를 찾지 못한다.
Why를 모른다면, 그건 당신 탓이 아니다
실행의 시대에 질문이 사라진다에서 What과 How를 이야기했더니, "Why는요?"라는 질문이 많았다.
솔직한 생각을 말하면, 한 팀인데 Why를 모른다면, 그건 개인의 문제가 아니라 조직 시스템의 문제다. Why는 개인이 찾아 헤매야 할 것이 아니라, 조직이 자연스럽게 흘려보내야 할 것이다.
하지만 현실은 다르다. 대부분의 조직에는 Why가 자연스럽게 싱크되는 장치가 없다.
- 전사 미팅에서 한 번 언급되고 끝나거나
- 노션 어딘가에 묻혀 있거나
- 아예 명문화되지 않았거나
"우리가 왜 이걸 하는가"가 팀 전체에 당연하게 공유되는 조직은 드물다.
그래서 top-down 사고를 하고 싶어도, 출발점인 Why가 없으면 시작할 수가 없다. 역설적으로, 조직이 Why를 잘 싱크하는 것 자체가 구성원의 top-down 사고를 가능하게 하는 인프라다. Why가 흐르는 조직에서는 구성원이 자연스럽게 top-down으로 사고하게 되고, Why가 막힌 조직에서는 bottom-up 외에 선택지가 없다.
그렇다고 개인이 할 수 있는 것이 없는 건 아니다. Why가 주어지지 않는 환경에서도, 시야를 넓히는 훈련은 가능하다.
시야를 넓히는 훈련
Top-down 사고는 타고나는 것이 아니라 훈련된다.
자기 작업의 상위 컨텍스트를 파악한다. 내가 만드는 컴포넌트가 속한 페이지, 그 페이지가 속한 플로우, 그 플로우가 풀고 있는 비즈니스 문제. 한 단계 위를 항상 인식하는 습관이다. 티켓을 받으면 바로 구현에 들어가지 말고, 이 티켓이 존재하는 이유를 한 단계만 거슬러 올라가본다.
다른 팀의 일을 이해한다. 백엔드, PM, 디자인, 비즈니스 팀이 지금 무슨 문제를 풀고 있는지 안다. 내 작업이 그들의 작업과 어떻게 연결되는지 안다. 이것만으로도 시야가 달라진다. 아는 만큼 보이고, 보이는 만큼 영향을 줄 수 있다.
역방향으로 계획을 세워본다. "6개월 뒤 이 제품이 이런 상태가 되려면, 지금 무엇을 해야 하는가?"라는 질문에서 출발해서 현재의 할 일을 역추론한다. 미래의 목표에서 현재의 행동을 도출하는 것. 이것이 top-down 계획의 기본 구조다.
세 가지 모두 거창한 것이 아니다. 매일 하던 일을 하되, 출발점을 한 단계 위로 옮기는 것이다.
나무를 심되, 숲의 지도를 가져라
Bottom-up이 나쁜 것이 아니다. 나무 하나를 제대로 심을 줄 모르면 숲을 만들 수 없다. 실행력 없는 시야는 공허하다.
하지만 나무만 보면서 숲을 만들 수도 없다. 두 가지 사고방식은 대립이 아니라 보완이다. 성장은 이 둘을 오갈 수 있는 유연함에서 온다. 줌인과 줌아웃을 자유롭게 전환할 수 있는 것. 나무를 심으면서도, 숲 전체의 지도를 머릿속에 가지고 있는 것.
지금 나무를 보고 있다면, 한 번쯤 줌아웃해볼 때다.