왜 우리는 할 일 목록을 버렸는가

최종 업데이트: 2026년 8월 19일

대부분의 업무 관리 소프트웨어 중심에는 상상 가능한 모든 업무를 담아두는 전통적인 할 일 목록이 있습니다. 하지만 할 일 목록은 애초에 업무 관리 시스템이 관장해야 할 복잡함을 다루도록 만들어진 적이 없습니다.

우리가 도달한 해법은 업무 트리가 떠받치는 중첩 체크리스트입니다. 이 글은 그 원래의 논거를 담고 있습니다.

긴 할 일 목록이 우리를 짓누르는 데는 인지적인 이유가 있습니다. 심리학자 E.J. Masicampo와 Roy Baumeister의 연구에 따르면, 끝내지 못한 업무는 구체적인 계획을 세우기 전까지 계속해서 생각 속에 파고들어 지금 하는 일에서 집중력을 빼앗아 갑니다. 계획을 세운 순간 그 마음속 잡음은 잦아듭니다.

평면적인 할 일 목록은 업무 자체는 담아내지만 계획은 담아내지 못합니다. 바로 이 지점이 평면 목록의 한계입니다. 이것이 단순한 목록 대신 제대로 된 업무 관리 도구가 필요한 핵심 이유입니다. 업무 관리 도구는 업무뿐 아니라 계획까지 담아냅니다.

할 일 목록은 어떤 목적을 위한 것인가요?

우리가 업무를 글로 적기 시작하는 것은 관리하기 어려울 만큼 그 수가 많아졌을 때입니다. 글이나 시각적인 형태로 남기면 업무는 어느 정도 "손에 잡히는" 것이 되고, 그만큼 우선순위를 매기고 완료 여부를 추적하기도 쉬워집니다.

간단히 말해, 할 일 목록은 업무를 기억하고(추적) 비교하는(순위 매기기) 데 도움을 줍니다.

할 일 목록은 언제 제 역할을 하지 못하나요?

업무 수가 늘어나면 긴 목록을 들여다보는 것만으로는 업무를 비교하고 우선순위를 매기는 데 큰 도움이 되지 않습니다. 결과적으로 모두가 똑같이 중요해 보이는 긴 업무 목록이 남습니다.

이렇게 똑같이 중요해 보이는 업무가 목록에 잔뜩 쌓이면, 다시 한번 업무를 추적하고 순위 매기는 일이 어려워집니다.

서로 "비교 불가능한" 업무를 한데 적어 이질적인 목록을 만들면, 그 업무들을 비교하거나 순위 매기기가 어려워집니다. 여기서 "비교 불가능하다"는 것은 규모와 맥락이 지나치게 달라 비교나 순위 매기기 자체가 무의미해진다는 뜻입니다.

예를 들어 할 일 목록에 "Book X의 n페이지 읽기"와 "조종사 면허 따기"가 함께 있다면, 이 둘은 읽기 업무가 속한 맥락을 이해해야만 비로소 비교 가능해집니다.

만약 "내일 마감인 프로젝트"를 위해 먼저 Book X의 그 n페이지 내용을 소화해야 한다는 사실이 떠오른다면, 그제야 "내일 마감인 프로젝트"와 "조종사 면허 따기" 사이의 우선순위를 저울질할 수 있습니다.

즉 이질적인 목록에서는 각 업무에 얽힌 모든 맥락을 기억해야 하는데, 이는 결코 쉬운 일이 아닙니다.

할 일 목록의 유용성을 무너뜨릴 수 있는 모든 경우를 낱낱이 따져보지 않더라도, 업무 수가 충분히 많아져 모두가 똑같이 중요해지거나 목록이 이질적으로 변하는 순간 할 일 목록은 더 이상 충분하지 않다는 점만은 분명합니다.

우리가 기존 업무 관리 시스템에 적어 넣는 업무들도 이런 한계와 충돌할까요?

규모가 크고 기간이 긴 업무는 실행 가능하도록 반드시 더 다루기 쉬운 실행 항목들로 쪼개져야 합니다.

일부 큰 업무는 이렇게 쪼개지고 확장되지만, 아직 그 단계까지 가지 못한 업무들도 있기 마련이라, 우리는 자기도 모르게 이질적인 목록을 만들게 됩니다.

목록 안의 모든 업무가 균질한 상태로 쪼개질 때까지 이런 혼란은 계속됩니다. 그때쯤이면 부풀어 오른 할 일 목록은 다들 똑같이 중요해 보이는 항목들로 가득한, 지나치게 긴 목록이 되어 있습니다.

업무 관리 시스템의 관장이 필요한 업무는 대개 규모가 크고 기간도 깁니다. 이런 업무를 기존의 할 일 목록에 그대로 적어 넣으면 필연적으로 목록이 이질적으로 변하고, 업무들은 결국 똑같은 중요도를 갖는 방향으로 수렴합니다. 이는 암묵적으로 각 업무의 중요성을 떨어뜨리는 결과로 이어집니다.

업무 관리 소프트웨어는 할 일 목록의 한계를 어떻게 다루나요?

이런 한계를 감안해, 가장 널리 쓰이는 해법은 원래 하나였던 할 일 목록을 여러 개의 다른 목록으로 나누는 것입니다. 예를 들어 "형제" 관계에 있는 업무들은 흔히 "하위 업무"라 불리는 또 다른 목록에 배치되고, "상위" 업무는 "섹션" 같은 다른 이름의 목록에 지정되기도 합니다.

더 유연한 시스템에서는 하위 업무가 자신만의 하위 업무를 가질 수 있는데, 이는 결국 또 다른 목록을 자기 자신에게 무한히 이어붙이는 셈입니다. 이 방식은 아래와 같은 위계 구조를 만들어냅니다.

어떤 업무나 하위 업무에도 또 다른 하위 업무 목록을 붙일 수 있는 유연함이 있으면, 우리는 언제든 업무를 "확대"해서 더 잘게 쪼갤 수 있습니다. 이 과정에서 위계가 생겨나고, 그 위계는 곧 업무 간의 의존 관계를 드러냅니다.

이로써 똑같이 중요한 업무들이 늘어선 평면 목록의 문제는 사라졌습니다. 그리고 이제 업무의 위계가 생겼으니, 각 단계의 업무들이 균질함을 이루도록 조직할 수 있습니다.

중첩 체크리스트란 무엇인가요?

같은 개념이 중첩 할 일 목록, 계층적 업무 목록, 트리 구조 할 일 목록 등 여러 이름으로 불립니다. 이름이 무엇이든 중요한 것은 하나, 업무를 확대해서 들여다보면서도 그것이 어디에 속하는지 절대 놓치지 않는다는 약속입니다.

그렇다면 중첩된 업무 목록은 어떻게 전달해야 할까요?

가장 유연한 업무 관리 도구라면 무한한 위계 구조를 허용하겠지만, 중첩된 목록을 그대로 보여주는 것은 UI 설계 관점에서 현실적이지 않습니다.

하지만 위계를 따라 모든 업무를 보여주지 않으면, 업무를 관리하는 데 필요한 맥락을 쉽게 놓치게 됩니다. 다음과 같은 업무 구조를 예로 들어 보겠습니다.

"Complete A" 아래의 "Get Report B2–1"은 "Complete B" 아래의 "Do Report B2–1"이 끝나야 진행할 수 있습니다. 하지만 중첩 목록을 보여주는 데는 제약이 있어서, 타협된 화면은 다음과 같이 나타납니다.

또는

어느 쪽이든 "Review A3"가 "Do B2"에 의존한다는 사실을 완전히 놓치게 됩니다. "Do B2"가 화면에서 숨겨진 하위 업무 목록 안에 있기 때문입니다.

두 화면 모두 이 맥락을 전달하지 못합니다. 사실은 한 업무 위계에 속한 하위 업무 하나가 다른 위계의 하위 업무에 의존하고 있음을 보여줘야 하는데 말이죠.

결국 사용자가 보게 되는 것은 여전히 원초적인 형태의 할 일 목록일 뿐입니다. 다만 이제는 여러 개로 늘어났고, 업무의 맥락과 관계는 전혀 보여주지 못한 채로 말입니다.

트리 구조는 업무의 본래 위계를 어떻게 지켜내나요?

문제는 필요한 위계를 만들기 위해 여러 목록을 이어 붙이는 순간, 그 목록들이 각각 별개의 개체로 남는다는 것입니다. 맥락을 전달하는 데 몇 개의 목록이 필요한지 그대로 다 보여주는 것은 UI의 제약상 불가능합니다.

대신 우리는 이 위계가 트리 구조로 표현될 때 더 잘 드러난다는 사실을 알아냈습니다. 각 하위 업무는 한 업무의 자식 노드가 됩니다. 하나의 업무를 불러오면, 전체 맥락을 이루는 모든 상위·하위 업무 노드도 함께 불러와집니다.

이 구조 안에서는 업무와 그 의존 관계가 업무 관리 시스템 안에 명확하게 나타납니다. 업무 묶음과 중첩 목록이 실제로 어떻게 작동하는지는 Quire의 업무 묶음과 중첩 개념에 관한 모든 것에서 더 깊이 다루며, 실제 팀에 적용된 사례는 6가지 실제 Quire 하위 목록 활용 사례에서 확인할 수 있습니다.

Quire는 중첩된 업무 목록을 어떻게 다루나요?

Quire에서는 모든 업무가 하위 업무를 가질 수 있고, 각 하위 업무도 자신만의 하위 업무를 가질 수 있어서, 하나의 프로젝트는 여러 목록이 쌓인 형태가 아니라 하나의 트리를 이룹니다. 업무를 열면 상위·하위 업무가 함께 나타나고, 여러 가지에 걸친 의존 관계도 계속 눈에 보이며, 가지 전체를 드래그하거나 지금 다루지 않는 가지는 접어둘 수 있습니다.

이것이 목록을 쌓는 것과 트리를 키우는 것의 차이이며, 목록이 아니라 업무 트리가 Quire의 근간이 된 이유입니다.

업무는 계획도 없고 완료에 필요한 배경지식도 없는 막연한 목표에서 시작하는 경우가 많습니다. 목표를 이루는 데 필요한 구체적인 단계들은 더 많은 고민과 협업을 거치고 나서야 비로소 모습을 드러냅니다.

업무를 계획하고 조직하는 과정에서, 트리 노드로 표현된 업무들은 아래와 같이 드래그 앤 드롭으로 의존 관계에 맞춰 손쉽게 재배치할 수 있습니다.

업무가 화면을 어지럽혀 집중력을 흐트러뜨리지 않도록, 지금 당장 다룰 업무와 관계없는 업무 트리는 간단히 접어둘 수 있습니다. 비슷한 방법으로 드릴 다운을 쓰면 나머지를 일일이 접지 않고도 특정 업무와 그 하위 업무만 확대해서 볼 수 있습니다.

할 일 목록은 우리의 목표를 좀 더 "손에 잡히게" 만들어주지만, 애초에 업무 관리 소프트웨어의 근간이 되도록 만들어진 것은 아니었습니다.

중첩 할 일 목록은 팀워크와 협업이 필요한 프로젝트에서 마주치는 것과 같은 더 복잡한 작업에 논리적인 위계를 제공합니다. 하지만 중첩 목록도 여전히 별개의 목록들이며, 업무의 맥락을 여러 조각으로 나눠버립니다. 게다가 이 맥락을 사용자 인터페이스에서 효과적으로 보여줄 수도 없습니다.

우리는 트리 구조의 위계가 업무가 생애 주기를 거치며 진화하는 방식을 자연스럽게 포착한다는 것을 확인했습니다. 트리는 업무 간 관계를 한눈에 조망할 수 있게 해줍니다.

업무 트리는 업무 관리 시스템의 더 나은 근간이 됩니다. 이 아이디어가 여러분에게도 잘 맞는지 궁금합니다. Quire로 무료로 시작해서 업무 트리를 직접 경험해 보세요.

트리 구조는 더 큰 그림의 한 조각일 뿐입니다. GTD, 칸반, 타임 블로킹과 함께 이 구조가 어떻게 맞물리는지는 끝까지 버텨내는 업무 관리 시스템 만들기에서 확인해 보세요.

자주 묻는 질문

할 일 목록은 원래 무엇을 위한 것인가요?

할 일 목록은 업무를 눈에 보이게 만들어 기억하고 순위를 매기도록 도와줍니다. 원래는 적당한 규모의 업무를 위해 만들어진 것이지, 완전한 업무 관리 시스템이 다루는 복잡한 작업을 위한 것이 아니었습니다.

업무가 쌓이면 왜 할 일 목록이 제 기능을 못 하나요?

목록이 길어질수록 모든 항목이 똑같이 중요해 보이기 시작하면서 순위 매기기 자체가 무너집니다. 규모가 전혀 다른 업무들이 뒤섞이면 목록을 공정하게 비교하는 것 자체가 불가능해집니다.

중첩 목록으로도 문제가 완전히 해결되지 않는 이유는 무엇인가요?

중첩 목록은 하나의 업무가 가진 맥락을 여러 개의 별도 목록으로 흩어놓는데, 이를 한 번에 모두 보여주는 것은 현실적이지 않습니다. 서로 다른 가지에 속한 업무들 사이의 의존 관계는 여전히 놓치게 됩니다.

트리 구조가 평면 목록보다 나은 이유는 무엇인가요?

트리 구조는 업무의 본래 위계를 보존해서, 업무를 열면 상위·하위 노드도 함께 나타납니다. 의존 관계는 계속 눈에 보이며, 드래그 앤 드롭이나 가지 접기로 집중력을 유지할 수 있습니다.

중첩 체크리스트란 무엇인가요?

항목들이 자신만의 하위 항목을 가질 수 있는 할 일 목록으로, 한 줄짜리 평면 구조 대신 상위·하위 단계를 이룹니다. 작은 단계 하나하나는 그것이 속한 더 큰 업무에 계속 붙어 있습니다.

Quire는 중첩된 업무 목록을 어떻게 다루나요?

모든 업무는 하위 업무를 가질 수 있고, 각 하위 업무도 자신만의 하위 업무를 가질 수 있어서 하나의 프로젝트는 하나의 트리를 이룹니다. 업무를 열면 상위·하위 업무가 함께 따라오고, 작업하면서 가지 전체를 드래그하거나 접을 수 있습니다.