직장 생활에서 가장 우리를 괴롭히는 것은 ‘어디서부터 시작해야 할지 모를 정도로 막막한 업무’입니다. 거대한 프로젝트를 앞에 두면 뇌는 본능적으로 회피 반응을 보이죠. 장영실이 물시계의 자동 알림 장치를 개발할 때도 분명 처음에는 막막했을 것입니다. 당시 기술로 물의 흐름을 멈추고 시간을 알리는 신호를 만드는 것은 현대의 소프트웨어 개발만큼이나 복잡한 난제였기 때문입니다. 이 문제를 해결하기 위해 그가 사용했던 단계적 접근법을 업무에 적용해 보겠습니다.
[거대한 난제를 작게 쪼개는 ‘데커디션(Decomposition)’]
장영실이 자격루(자동 물시계)를 설계할 때 가장 먼저 한 일은 전체를 한 번에 만드는 것이 아니라, 기능을 3가지 모듈로 나눈 것이었습니다. 첫째는 물을 일정한 속도로 흘려보내는 ‘수위 조절 장치’, 둘째는 흐른 물의 양을 측정하는 ‘계측 장치’, 마지막으로 이를 신호로 바꾸는 ‘자동 알림 장치’입니다. 이렇게 기능을 쪼개자 비로소 각 부품에 필요한 최적의 재료와 구조가 보이기 시작했습니다.
내가 프로젝트 매니지먼트를 할 때, 팀원들에게 가장 강조하는 것이 ‘태스크 세분화(Task Breakdown)’입니다. “자격루를 만들어라”라는 목표는 너무 크고 무겁지만, “일정한 수압을 유지하는 파이프를 설계하라”는 목표는 구체적이고 당장 시작할 수 있습니다. 여러분도 업무가 너무 막막하다면, 일단 큰 목표를 종이 위에 적고 그것을 가장 작은 단위의 ‘액션 아이템’으로 쪼개보세요. 하나씩 해결할 때마다 느껴지는 작은 성취감이 당신의 집중력을 다시 불러올 것입니다.
[첫 번째 해결책은 항상 프로토타입이다]
많은 사람이 완벽한 설계를 하느라 시간을 다 보내고 정작 실행은 하지 못합니다. 하지만 장영실은 일단 나무와 흙으로 모형을 만들어 작동 원리를 검증했습니다. 바로 ‘프로토타입’입니다. 완벽한 자격루를 만드는 것이 목표가 아니라, ‘물이 제대로 흐르는가?’를 확인하는 것이 목표였던 셈입니다.
업무를 하다 보면 ‘이게 과연 될까?’라는 의구심이 드는 지점이 있습니다. 이때는 고민하지 말고 일단 가장 빠르게, 가장 저렴하게 결과물을 확인해볼 수 있는 프로토타입을 만드세요. 보고서 전체를 쓰기 전에 목차와 핵심 그래프 1장만 그려서 리더에게 피드백을 받는 것, 코딩하기 전에 종이에 로직을 그려보는 것 모두가 프로토타입입니다. 실패하더라도 빨리 실패하고, 그 경험을 바탕으로 다시 설계하는 것이 가장 빠른 문제 해결법입니다.
[단계적 문제 해결을 위한 체크리스트]
모듈화: 지금 고민하는 거대한 업무를 3~4개의 작은 독립적인 태스크로 나눌 수 있는가?
우선순위: 전체 시스템을 망가뜨리지 않으면서, 가장 먼저 해결해야 할 ‘핵심 변수(수위 조절 장치 같은)’는 무엇인가?
가설 검증: 이론적으로 완벽한 계획인가, 아니면 실질적으로 작동 여부를 확인할 수 있는 작은 실행안이 포함되어 있는가?
병목 인지: 지금 막혀있는 구간이 전체 업무의 순서상 어느 지점에 위치하는가? (초기인가, 마무리인가?)
[주의사항과 한계]
물론 모든 업무를 쪼개는 것만이 능사는 아닙니다. 때로는 전체적인 맥락과 큰 그림(Big Picture)을 잃지 않는 것이 중요합니다. 너무 파편화된 업무에만 집중하다 보면, 결국 ‘각 부분은 완벽한데 전체 시스템은 작동하지 않는’ 비극이 발생할 수 있습니다. 태스크를 쪼개되, 그 조각들이 다시 합쳐졌을 때 어떤 모습이어야 하는지를 잊지 마세요. 단계적 접근법은 어디까지나 전체를 완성하기 위한 수단이지 목적이 아닙니다.
복잡한 문제는 사실 우리가 두려워하는 만큼 크지 않습니다. 다만 우리가 그 덩어리를 통째로 삼키려 하기 때문에 체하는 것입니다. 오늘 여러분이 맡은 복잡한 과제, 딱 10분만 투자해서 가장 작은 단위로 쪼개보세요. 첫 번째 모듈이 완성되는 순간, 막막함은 희망으로 바뀔 것입니다.
핵심 요약
거대한 난제는 독립적인 단위(모듈)로 쪼개어 해결할 때 비로소 구체적인 해결책이 보인다.
완벽한 계획보다 실 작동 여부를 확인하는 프로토타입을 통해 문제 해결의 속도를 높여야 한다.
태스크를 세분화하되, 항상 전체 시스템이 조화를 이룰 수 있도록 통합적 관점을 유지해야 한다.
0 댓글