[특집] '홈페이지 개선'은 왜 3주째 진행 중일까 — 이슈를 어떤 단위로, 어떻게 적을 것인가

크게 보기

들어가며: 3주째 '진행 중'인 카드 한 장

어느 팀의 업무 보드에나 이런 카드가 한 장쯤 있습니다.

월요일 회의마다 같은 대화가 오갑니다. "홈페이지 개선은 어디까지 됐어요?" "거의 다 됐습니다."

김 대리는 게으르지 않습니다. 3주 동안 메인 배너를 바꿨고, 서비스 소개 문구를 고쳤고, 모바일에서 깨지던 메뉴도 손봤습니다. 그런데도 카드는 '완료' 칸으로 넘어가지 못합니다. 이 카드에는 끝난 모습이 적혀 있지 않기 때문입니다. 무엇이 되면 끝인지 정한 적이 없으니, 고칠 곳이 눈에 띄는 한 일은 계속됩니다. 팀장은 진척을 알 수 없고, 김 대리는 일을 하고도 끝냈다는 말을 못 합니다.

지어낸 장면이지만 낯설지 않을 겁니다. 실제 기록도 있습니다. 2022년 7월, PM 박재영 님은 새로 합류한 프로젝트에서 본 것을 블로그에 이렇게 적었습니다.

Jira에 내용 요약이 한줄로 표기되어 있다. 왜 이 티켓을 진행하는지에 대한 내용이 없다.

깃 커밋에는 티켓 번호도 없었다고 합니다. 도구는 이미 있었습니다. 빠져 있던 것은 적는 법이었습니다.

이 글은 그 적는 법을 다룹니다. 할 일 관리 책과 애자일 가이드, 제텔카스텐 커뮤니티, 그리고 일하는 방식을 공개해 온 개발자와 PM의 블로그에서 반복해서 나오는 노하우를 모았습니다. 결론부터 말하면, 질문을 바꿔야 합니다.

"이 일을 얼마나 잘게 나눌까?"가 아니라 "무엇을 하나의 완료로 볼 것인가?"

읽기 전에 두 가지를 밝혀 둡니다. 첫째, 이 글에 인용한 문장은 모두 원문 페이지에서 확인한 것이고, 예시와 표는 따로 표시가 없는 한 이 글이 만든 것입니다. 둘째, 블로그와 커뮤니티의 사용기는 한 사람, 한 팀의 경험입니다. 누구에게나 같은 효과가 난다는 실험 결과가 아닙니다. 그래서 9부와 10부에서 서로 부딪히는 조언과 이 글의 한계를 따로 다룹니다.

---

1부. 적는 단위는 하나가 아니다

"일을 작게 쪼개라"는 조언이 자주 실패하는 이유는, 서로 다른 것을 같은 칸에 적기 때문입니다. '홈페이지 개선' 아래에 "배너 교체", "구글에서 경쟁사 사이트 찾아보기", "문구는 대표님 확인 필요", "모바일 메뉴는 CSS 문제였음"이 똑같은 하위 항목으로 달려 있다고 해 봅시다. 넷은 성격이 전혀 다릅니다. 하나는 결과, 하나는 지금 할 동작, 하나는 기다리는 일, 하나는 알아낸 사실입니다.

크게 보기

여기에 그릇 두 개가 더 있습니다. 여러 이슈로 달성하는 유한한 목표인 프로젝트, 그리고 이슈 하나를 끝내기 위한 내부 절차인 체크리스트입니다.

이 구분은 새로운 것이 아닙니다. 애자일 코치 리즈 키오(Liz Keogh)는 2011년 글에서 스토리와 태스크를 이렇게 갈랐습니다.

태스크란 스토리의 일부이되, 관련 이해관계자의 피드백을 받을 수 없는 부분이다.

키오는 태스크로 쪼개는 일이 협업을 돕고 빠뜨린 조각을 찾게 해 준다고 인정합니다. 동시에 부작용도 적었습니다. 태스크는 계속 끝나는데 보여 줄 수 있는 스토리는 하나도 없는 상태, 그리고 태스크 목록이 세세한 통제 수단으로 쓰이는 상태입니다. 그래서 나누기 전에 왜 나누는지를 먼저 물어야 합니다.

직접 분류해 보면 감이 빨리 옵니다.

프로젝트의 기준도 짚어 둡니다. GTD는 "둘 이상의 행동이 필요한 결과"를 모두 프로젝트라고 부릅니다. 개인의 머릿속을 비우는 데에는 좋은 정의입니다. 하지만 이 정의를 팀 도구의 메뉴 구조로 그대로 옮기면, "견적서 열기 → 금액 수정 → 메일 전송"까지 프로젝트가 됩니다. 팀에서는 별도의 목표와 책임자, 일정이 있고 여러 업무를 조율해야 할 때 프로젝트로 올리는 편이 낫습니다.

---

2부. 이슈의 단위: 확인할 수 있는 결과 하나

팀이 추적하는 이슈에는 다음 원칙을 권합니다.

이슈 하나에는, 따로 맡길 수 있고 끝났는지 확인할 수 있는 결과 하나를 담는다.

나눌지 말지 판단하는 다섯 질문

다섯 질문에 모두 '아니다'라면, 즉 담당자가 같고 늘 함께 진행되며 하나만 끝내도 의미가 없다면 체크리스트로 충분합니다.

'독립적'이라는 말의 오해

좋은 스토리의 조건으로 널리 쓰이는 INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testable)는 빌 웨이크(Bill Wake)가 2003년에 정리했습니다. 첫 글자 I가 '독립적'입니다. 그런데 웨이크는 같은 글에서 바로 덧붙입니다. "항상 그렇게 할 수 있는 것은 아니다."

의존성을 0으로 만들 수는 없습니다. 디자인이 확정돼야 구현할 수 있는 일은 얼마든지 있습니다. 그럴 때 필요한 일은 의존성을 없애는 것이 아니라 보이게 하는 것입니다. "디자인 확정 후 진행"을 본문 한 줄에 묻어 두지 말고, 선행 업무로 연결해 둡니다. 의존성은 오류가 아니라 드러내야 할 관계입니다.

계층이 아니라 작동하는 결과로

개발팀이 가장 자주 하는 분해는 데이터베이스, API, 화면, 테스트로 나누는 것입니다. 담당 파트별로 일을 나눠 주기 쉽기 때문입니다. 이 방식의 문제는 아래에서 직접 볼 수 있습니다.

두 보드의 진행률은 매주 똑같이 오릅니다. 차이는 3주 차에 누군가 "지금 뭘 써 볼 수 있어요?"라고 물었을 때 드러납니다. 왼쪽 보드는 75%인데 보여 줄 것이 없습니다.

크게 보기

Shape Up은 이 조각을 '스코프(scope)'라고 부릅니다. 라이언 싱어(Ryan Singer)는 일을 사람이나 역할별로 묶지 말고 "서로 독립적으로 끝낼 수 있는 스코프들"로 나누라고 씁니다.

예외는 있습니다. 공통 인증 체계, 백업 복구 검증, 인프라 이전처럼 그 자체로 위험을 줄이거나 운영 가치를 만드는 일은, 억지로 화면 기능처럼 포장할 필요가 없습니다. 그 일의 '확인할 수 있는 결과'는 "복구 훈련에서 30분 안에 서비스가 돌아온다" 같은 문장으로 따로 적으면 됩니다.

나눌 방향이 안 보일 때: SPIDR

"더 작게 나누세요"는 방향 없는 조언입니다. 마이크 콘(Mike Cohn)은 15년 동안 모은 유저 스토리 1,000개 이상을 출력해 놓고, 큰 스토리가 실제로 어떻게 나뉘었는지를 살펴 다섯 가지 방향을 추렸습니다. 머리글자를 따서 SPIDR입니다. 아래 예시는 업무 관리 도구를 만든다고 가정하고 이 글이 붙였습니다.

크게 보기

콘은 데이터 방향을 설명하다가 이런 말을 흘립니다. "더 단순한 버전은 아마 출시할 수 없겠지만, 그 순서로 만들 수는 있다." 만드는 순서와 내보내는 단위는 다를 수 있다는 뜻입니다. 권한 검증이 빠진 중간 조각을 고객에게 공개해도 된다는 말로 읽으면 안 됩니다.

나누기 전에 합쳐야 할 때

반대 방향의 조언도 있습니다. 리처드 로런스와 피터 그린의 스토리 분해 가이드는 나누기 전에 먼저 그 스토리가 ('작다'를 뺀) INVEST 조건을 만족하는지 보라고 합니다. 만족하지 않는다면, 즉 그 조각이 사용자에게 아무 의미가 없는 부품이라면 다음 수는 분해가 아닙니다.

스토리가 아닌 그 조각을 다른 조각들과 합쳐서, 함께 하나의 가치 증분이 되게 하라.

"DB 작업", "API 작업", "화면 작업"을 받았다면 더 쪼갤 것이 아니라 "사용자가 요청을 등록하고 결과를 확인한다"로 먼저 묶은 다음, 거기서 다시 나눕니다. 분해 도구는 병합 도구와 짝이어야 합니다.

크기에 정답이 있을까

"하루 이하로 쪼개라"는 말이 스크럼 가이드에 있다고들 합니다. 원문을 보면 이 표현은 스프린트 계획의 세 번째 주제, 개발자들이 일을 어떻게 해낼지 계획하는 대목에 딱 한 번 나옵니다. 그것도 "흔히 그렇게 한다(often)"는 서술입니다. 모든 조직의 모든 이슈에 적용할 규칙으로 쓰인 문장이 아닙니다.

그래서 이 글은 숫자 대신 다시 볼 신호를 권합니다.

• 팀 이슈는 담당자의 실작업량이 반나절에서 이틀쯤인 것부터 시작해 봅니다. 출발값이지 규칙이 아닙니다.
• 며칠째 중간 결과를 보여 줄 수 없거나, 완료 조건이 계속 늘어난다면 나누거나 범위를 줄입니다.
• 실제로 일한 시간과 승인·회신을 기다린 시간을 구분합니다. 이틀짜리 일이 2주 걸렸다면 크기가 아니라 대기가 문제일 수 있습니다.

---

3부. 이슈를 쓰는 법: '무엇을 한다'보다 '무엇이 달라진다'

제목: 대상 + 달라질 상태

고쳐 쓴 제목은 길어졌습니다. 대신 제목만 읽고도 "끝났나요?"에 예, 아니오로 답할 수 있습니다. 김 대리의 카드가 "첫 방문자가 주요 서비스 세 가지를 구분할 수 있도록 소개 영역 수정"이었다면, 배너와 모바일 메뉴는 이 카드의 일이 아니라는 것도 처음부터 분명했을 겁니다.

크게 보기

마지막 줄은 일부러 다르게 썼습니다. 아직 원인을 모르는 버그나 남에게 맡기는 요청은, 해결책이 아니라 관찰한 문제를 그대로 씁니다. "로그인 오류를 캐시 수정으로 해결"이라고 적으면 원인을 확인하기도 전에 해법을 못 박게 됩니다. Linear가 공개한 작업 원칙 'Linear Method'도 같은 말을 합니다.

(다른 사람에게 쓰는 이슈라면) 요청의 형태로 쓰거나 문제를 기술하라. 해결책은 담당자가 내도록 하고, 그런 다음 이슈를 작업으로 고쳐 쓰게 하라.

본문: 항목 하나가 질문 하나에 답한다

본문 양식을 보여 드리기 전에, 양식이 왜 있는지부터 보겠습니다.

이슈 본문의 각 항목은 담당자가 어차피 물었을 질문에 미리 답해 둔 것입니다. 메신저로 물으면 답은 두 사람만 알고 대화는 흘러갑니다. 본문에 적으면 석 달 뒤에 이 이슈를 여는 사람도 같은 답을 얻습니다.

정리하면 기본 본문은 다섯 가지입니다.

세 가지를 조심합니다.

완료 조건에는 과정이 아니라 결과를 씁니다. "열심히 개선한다", "사용성을 높인다"는 확인할 방법이 없습니다. "예정일을 바꿔도 마감일은 바뀌지 않는다"는 눌러 보면 압니다.

이슈마다 다른 조건과 모두에게 공통인 기준을 섞지 않습니다. 개발 업무라면 테스트 통과와 권한 검토, 대외 문서라면 오탈자와 공유 권한 확인 같은 것은 매번 같습니다. 스크럼이 '완료의 정의(Definition of Done)'라고 부르는 것이 이 공통 기준입니다. 공통 기준은 팀 템플릿에 한 번 적어 두고, 이슈에는 이번에만 해당하는 조건을 적습니다.

처음부터 다 채우게 하지 않습니다. 떠오른 일을 적는 순간에는 제목 한 줄이면 됩니다. 다섯 항목이 필요해지는 때는 그 일을 남에게 맡길 때, 그리고 이번 주에 하기로 고를 때입니다. 수집 단계에 긴 양식을 강제하면 사람들은 적기를 그만둡니다.

일의 종류가 다르면 '끝'도 다르다

반복 업무는 한 가지를 덧붙입니다. "매주 백업 확인"이라는 규칙과 "이번 주에 확인했고 결과가 어땠는가"라는 회차 기록은 별개입니다. 업무 하나의 날짜만 계속 다음 주로 넘기면, 어느 주에 빠뜨렸는지, 언제부터 이상이 있었는지 되짚을 수 없습니다.

---

4부. 시작하지 못하는 일에는 '첫 행동'을

프로젝트는 할 일 목록에 올리지 않는다

2010년, 라이프해커의 창립 편집자 지나 트라파니(Gina Trapani)는 패스트컴퍼니에 할 일 목록 쓰는 법을 썼습니다. 핵심은 한 문장입니다.

'차고 치우기', '5,000달러 모으기', '프랑스어 배우기'. 이것들은 프로젝트이고 목표다. 할 일 목록에 있어서는 안 된다.

할 일 목록에는 그 목표를 한 칸 전진시키는 구체적인 다음 단계가 올라가야 한다는 것입니다. 여기까지는 GTD의 '다음 행동'과 같은 이야기입니다.

다음 행동보다 한 칸 더: 첫 행동

2017년, '코치 토니'라는 필명으로 글을 쓰는 토니 스터블바인(Tony Stubblebine)은 한 칸 더 내려갑니다. 그가 든 예는 타이어입니다.

크게 보기

프로젝트는 '타이어 교체하기', 다음 행동은 '타이어 가게에 전화해 가격 묻기'입니다. 스터블바인은 여기서 한 칸 더 내려가 '구글에서 타이어 가게 전화번호 찾기'를 적습니다. 그것도 크다면 "구글 열기"까지 줄입니다.

'전화해 가격 묻기'는 흠잡을 데 없는 다음 행동입니다. 그런데도 사람들은 미룹니다. 전화하려면 번호가 있어야 하는데, 그 한 단계가 적혀 있지 않기 때문입니다. 스터블바인은 정말로 손이 움직이는 지점까지 내려가 그것을 '첫 행동'이라고 불렀습니다. 그가 가르치던 코칭 그룹에서도 이 이름을 두고 의견이 갈렸다고 스스로 적어 둔 만큼, 정설로 받아들일 것은 아닙니다. 다만 쓸모는 분명합니다.

아래 두 줄까지 팀 이슈로 만들 필요는 없습니다. 담당자가 착수할 때 보는 한 줄이면 됩니다. 손이 안 가는 일을 만나면 일을 더 쪼개기 전에 이렇게 물어보세요. "지금 이 일을 시작한다면, 가장 먼저 무엇을 열거나 확인하지?"

조사 업무는 '답'이 아니라 '준비'를 적는다

"좋은 RAG 기술 조사하기", "고객에게 통할 기능 찾기" 같은 일은 실행 단계로 쪼갤 수가 없습니다. 어떤 단계를 밟아야 할지 아직 모르기 때문입니다. 컴퓨터과학자 칼 뉴포트(Cal Newport)는 2014년 글에서 이런 일을 '결정 불가능한(undecidable) 과제'라고 불렀고, 조언 가운데 하나로 이런 일에는 결정 가능한 준비가 필요하다고 했습니다. 본격적으로 달려들기 전에 세 가지를 정리해 두라는 것입니다.

조사 이슈에 옮기면 이렇게 됩니다.

조사 이슈의 완료 조건은 "좋은 답을 찾았다"가 아니라 "다음 판단에 필요한 근거를 확보했다"입니다. 가설이 틀린 것으로 드러나도 이 이슈는 성공적으로 끝난 것입니다. 반대로 시간만 다 썼다는 이유로 아무 기록 없이 닫아서는 안 됩니다.

---

5부. 이슈는 지시서가 아니라 작업 노트다

이슈 하나에 댓글 65개

Datasette를 만든 사이먼 윌리슨(Simon Willison)은 2022년 11월, 혼자서 많은 프로젝트를 유지하는 요령을 정리한 글에서 이슈 쓰는 법을 공개했습니다. 그는 이슈를 실험 노트(laboratory notebook)처럼 씁니다. 그의 표현으로는 이렇습니다.

내가 만들고 있는 변경에 대해 사실상 나 혼자 떠드는 이슈 스레드.

배경, 관련 코드 링크, 시도한 접근, 막다른 길, 결정한 이유, 결과 스크린샷이 모두 댓글로 쌓입니다. 그가 예로 든 조사 이슈 하나는 며칠 사이에 댓글이 65개 달렸습니다. 시도 하나마다 이슈를 새로 만든 것이 아니라, 질문 하나 아래에 과정을 쌓은 것입니다. 이렇게 해 두면 한참 뒤에 그 프로젝트로 돌아와도 어디까지 했는지 다시 추리할 필요가 없습니다.

크게 보기

이렇게 보면 이슈가 생길 때 완벽할 필요는 없습니다. 시점마다 필요한 정보가 다를 뿐입니다.

윌리슨은 한 가지 구분을 더 합니다. 이슈는 그 시점의 기록이라 나중에 틀려도 괜찮습니다. 반면 일반 문서는 "최신 상태로 유지해야 한다는 큰 약속"이 따라붙습니다. 지난 이슈의 결론을 지금의 운영 기준으로 쓰려면, 이슈를 가리키기만 할 것이 아니라 가이드나 결정 기록으로 옮겨 적어야 합니다.

긴 기록 위에 짧은 요약을

댓글이 65개면 다음 사람은 어디서부터 읽어야 할까요. 2025년 4월 「On Ticketing」이라는 글을 쓴 올리버(Oliver)는 티켓을 쓸 때 다섯 질문에 답하라고 권합니다.

그는 이 질문에 답하면 AI가 티켓 초안을 써 주는 도구까지 만들었습니다. 그리고 솔직하게 적었습니다. "시간을 아꼈느냐고? 아닐지도 모른다. 하지만 글은 페이지에 적혔다." 작성 도우미의 가치를 '입력 시간이 줄었는가'로만 재면 안 되는 이유입니다. 원래는 남지 않았을 내용이 남았는가도 봐야 합니다.

요약과 기록은 둘 중 하나를 고르는 문제가 아닙니다. 위에는 지금 상태를 한눈에 보는 요약을, 아래에는 판단의 근거를 확인할 이력을 둡니다.

멈출 때는 재시작 메모를

스터블바인의 2017년 글은 원래 '사이사이 일기(interstitial journaling)'라는 습관을 소개하는 글이었습니다. 방법은 단순합니다.

방금 한 일에 대해 몇 문장을 적고, 이제 하려는 일에 대해 몇 문장을 더 적는다.

개인 일기를 팀 도구에 그대로 가져올 필요는 없습니다. 가져올 것은 일을 멈추는 순간에 다음 시작점을 적는다는 한 가지입니다.

크게 보기

"오늘 두 시간 작업함"과 비교해 보세요. 재시작 메모는 내일의 나에게도, 내가 갑자기 휴가를 갔을 때 이어받을 동료에게도 같은 값을 합니다. 업무 작성법을 따로 배운 적 없는 사람에게도 "내일의 내가 어디서 다시 시작하면 되는지 적어 주세요"는 따라 하기 쉬운 부탁입니다.

그렇다고 '티켓 처리반'이 되지는 말 것

기록을 강조하다 보면 반대편 함정에 빠집니다. 2025년 3월, 마틴 헤르츠(Martin Hertz)는 '티켓 주도 개발'을 안티패턴이라고 불렀습니다. 그가 비판한 대상은 기록이 아닙니다. 티켓이 이런 사람들에 의해 처리되는 구조입니다.

티켓을 만들고 대기열을 관리하는 일에 발언권이 거의 없는 개인들.

소수가 일을 정의하고 나머지는 카드를 옮기기만 하는 팀에서는, 이슈가 아무리 상세해도 큰 그림을 보는 사람이 줄어듭니다. 윌리슨의 이슈와 헤르츠가 비판하는 티켓은 겉모습이 비슷하지만 쓰임이 정반대입니다. 앞의 것은 생각하는 공간이고, 뒤의 것은 처리할 물량입니다.

그래서 담당자가 누를 수 있는 것이 '완료' 하나뿐이어서는 곤란합니다. "범위를 다시 확인해야 한다", "전제가 바뀌었다", "기존 업무와 합치는 게 낫다", "이제 할 필요가 없어졌다"를 남길 수 있어야 합니다. 합리적인 이유로 중단한 일도 기록할 가치가 있는 결과입니다.

---

6부. 약속과 계획을 섞지 않는다

요청은 아직 약속이 아니다

고객이 "엑셀로 내려받게 해 주세요"라고 말했다는 사실과, 팀이 "이번 주에 엑셀 내보내기를 만든다"고 정한 약속은 다른 것입니다. 들어온 요청이 곧바로 누군가의 할 일이 되는 팀에서는 목록이 끝없이 늘고, 목록에 있다는 것이 아무 의미도 갖지 못하게 됩니다.

제품들도 같은 방향으로 가고 있습니다. Linear는 2026년 4월 요청 접수용 웹 양식을 내놓으면서 이렇게 설명했습니다. "제출된 요청은 모두 팀의 트리아지(검토) 수신함에 이슈로 들어간다." 접수와 실행 사이에 검토 칸을 둔 것입니다.

같은 이유로 '오늘'은 상태가 아닙니다. 상태는 예정, 진행 중, 검토 중, 완료처럼 일이 어디까지 왔는지를 말합니다. '오늘', '이번 주', '중요'는 계획과 우선순위입니다. 둘을 한 칸에 넣으면 "오늘 하려 했지만 아직 시작 못 한 일"과 "며칠 전 시작해 지금도 하는 일"을 구분할 수 없습니다.

날짜는 세 가지다

가장 흔하게 섞이는 것은 날짜입니다.

Todoist 도움말(2026년 9월 1일 갱신)은 두 날짜를 이렇게 구분합니다.

날짜는 그 작업을 언제 할 계획인지를 정하고, 마감일은 넘겨서는 안 되는 최종 시한을 나타낸다.

팀으로 일할 때는 하나가 더 필요합니다.

크게 보기

못 한 일을 자동으로 오늘로 넘겨 주는 기능은 취향이 갈립니다. 지난 일정이 빨갛게 쌓이는 것이 싫은 사람이 있고, 날짜를 손으로 다시 정하는 일 자체를 계획을 돌아보는 과정으로 여기는 사람이 있습니다. 어느 쪽이든 지켜야 할 선은 같습니다. 예정일이 움직여도 마감일은 따라 움직이지 않아야 합니다.

막힌 일은 '대기' 칸으로 숨기지 않는다

검토 중이던 일이 고객 승인을 기다리느라 멈췄습니다. 상태를 '대기'로 바꾸면 깔끔해 보이지만, 어느 단계에서 막혔는지가 사라집니다. 상태는 그대로 두고 막힘을 따로 적는 편이 낫습니다. 막힌 이유, 기다리는 대상, 해소를 챙길 사람, 다시 확인할 날짜, 이 네 가지입니다.

칸반 가이드(2025년 5월판)는 진행 중 업무(WIP)를 "시작했지만 끝나지 않은 업무 항목의 수"라고 정의합니다. 이 정의대로라면 대기 칸으로 옮긴 일도 여전히 진행 중입니다. 대기로 보냈다고 진행 중 집계에서 빼면, 팀은 실제보다 한가해 보이고 새 일을 또 시작하게 됩니다. 가이드가 필수로 꼽는 흐름 지표 넷이 WIP, 처리량, 업무 항목의 나이, 사이클 타임인 것도 같은 맥락입니다. 끝낸 개수만이 아니라 시작하고 못 끝낸 일이 얼마나 오래 묵었는지를 보라는 것입니다.

"얼마나 걸릴까"보다 "얼마나 쓸까"

프로젝트 단위에서는 Shape Up의 구분이 쓸모 있습니다.

추정은 설계에서 시작해 숫자로 끝난다. 어피타이트(appetite)는 숫자에서 시작해 설계로 끝난다.

"다 만들려면 얼마나 걸려요?"라고만 물으면 범위는 고정되고 기간이 늘어납니다. "이 문제에 2주까지 쓸 생각인데, 그 안에서 어디까지 풀 수 있을까요?"라고 물으면 기간이 고정되고 범위가 조정됩니다. 프로젝트 설명에 '이번에 하지 않을 것'을 적어 두는 이유입니다.

Shape Up은 오래된 백로그를 쌓아 두지 말라는 것으로도 유명합니다. 여기에는 존 커틀러(John Cutler)가 2025년 11월에 단서를 달았습니다. 이 제약을 지나치게 밀면 현재 주기 밖의 것이 아무것도 기록되지 않아, 조직이 값진 통찰과 초기 신호를 놓칠 수 있다는 것입니다. 둘을 합치면 이렇게 됩니다. 실행하기로 약속한 목록은 작게 유지하되, 아이디어와 근거는 지우지 말고 약속 목록 밖에 보관합니다.

---

7부. 끝난 일에서 남길 것: 노트의 단위

이슈는 끝내려고 쓰고, 노트는 다시 쓰려고 쓴다

이슈가 닫히면 그 안의 판단도 함께 묻힙니다. "예정일과 마감일을 분리한다"는 이슈는 끝났지만, 그 과정에서 얻은 "개인의 계획 변경과 팀의 약속 변경은 구분해야 한다"는 생각은 다음 달 일정 승인 기능을 설계할 때 다시 필요합니다. 이 생각을 담는 그릇이 노트입니다.

니클라스 루만의 메모 상자에서 온 제텔카스텐은 이 블로그의 「AI 때문에 두 번째 뇌를 만들었다」에서 역사와 함께 다뤘습니다. 여기서는 단위 문제만 봅니다. 이슈와 노트는 둘 다 작은 단위를 지향하지만 생애가 다릅니다. 이슈는 완료되고, 노트는 고쳐지고, 결정은 대체됩니다. 그래서 같은 양식과 같은 상태 체계로 관리하면 안 됩니다.

원자적이라는 말은 '짧다'는 뜻이 아니다

제텔카스텐의 원자성 원칙은 "노트 하나에 한 문장", "300자 이하" 같은 규칙으로 자주 오해됩니다. zettelkasten.de의 사샤(Sascha)는 2025년 8월 글에서 원자성을 '입력 조건'으로 보는 관점과 '도달하려는 결과'로 보는 관점을 구분합니다. 넣기 전에 이미 원자적이어야 한다는 것이 전자인데, 그는 잘라 말합니다. "실제로는 그렇지 않다." 노트는 쓰고, 다시 읽고, 연결하는 과정에서 나뉘고 다듬어집니다.

앤디 마투색(Andy Matuschak)도 양쪽을 다 경고합니다. 너무 넓은 노트는 연결하기 어렵습니다. 그런데 반대쪽도 문제입니다.

노트가 너무 조각나 있으면 링크 네트워크도 조각나고, 어떤 연결은 오히려 보기 어려워질 수 있다.

예를 들어 보겠습니다.

왼쪽 세 장은 따로 읽으면 아무 말도 아닙니다. 판단 기준은 글자 수가 아니라 이것입니다. 이 노트를 다른 업무에 연결할 때, 왜 연결했는지 한 문장으로 말할 수 있는가. "프로젝트 관리 관련 자료"는 말할 수 없고, "회신 대기 업무에는 재확인일이 필요하다"는 말할 수 있습니다.

제목은 손잡이다

마투색은 노트 제목을 API에 비유합니다.

그 제목은 노트 자체의 추상화가 된다. 노트에 담긴 생각 전체를 그 손잡이로 가리킬 수 있다.

손잡이가 "회의 메모 3"이면 잡을 수가 없습니다. 다만 모든 제목을 주장문으로 강제하면 개념 정의나 아직 검증하지 않은 가설까지 단정문이 됩니다. 노트의 성격에 따라 제목 모양을 달리하는 편이 안전합니다.

팀에서 쓸 때 이 구분은 더 중요해집니다. 누군가의, 혹은 AI의 가설이 검토 없이 회사의 운영 원칙처럼 보여서는 안 되기 때문입니다.

이해를 돕는 중복은 괜찮다

개발자는 중복을 보면 지우고 싶어집니다. Org-roam을 만든 제스로 콴(Jethro Kuan)은 자기 노트 작성법을 설명하며 이렇게 적었습니다. "기술 쪽 배경을 가진 사람으로서 직관에 어긋날 수 있지만, 반복해도 괜찮다!" 노트는 그것만 읽어도 이해돼야 하기 때문입니다. 인터뷰 전문을 두 군데에 복사할 필요는 없지만, 핵심 요구를 두 노트에 각각 짧게 설명하는 것은 낭비가 아닙니다.

콴은 다른 경험도 적었습니다. 자기 노트를 친구들에게 보여 줬더니 "그들에게는 횡설수설이었다. 나를 위해 쓴 것이었으니까." 그래서 공개하는 글은 여러 노트를 독자에 맞게 다시 엮은 것이어야 한다고 봅니다. 개인 메모, 협업자가 읽는 정리, 팀의 운영 기준은 요구되는 수준이 다릅니다. 그리고 문장이 매끄럽다는 것과 내용이 검토됐다는 것은 별개입니다.

수집가의 오류, 그리고 그 반대

zettelkasten.de의 크리스티안 티체(Christian Tietze)는 2014년에 '수집가의 오류'라는 이름을 붙였습니다.

수집은 (…) 우리의 지식을 마법처럼 늘려 주지 않는다.

스크랩한 기사 300개는 읽은 기사 300개가 아니고, 이해한 기사 300개는 더더욱 아닙니다.

6년 뒤 예룬 피렌스(Jeroen Fierens)는 반대 방향의 오류를 지적했습니다. 지금 이해한 요점만 남기고 원문을 버리는 것은 이런 믿음에 기대고 있다는 것입니다.

지금의 내가, 미래의 나를 위해 무엇을 남기고 무엇을 버릴지 결정할 능력이 있다는 생각.

크게 보기

둘은 충돌하지 않습니다. 층을 나누면 됩니다.

원본을 보관하는 것은 문제가 아닙니다. 보관한 양을 생각한 양으로 착각하는 것이 문제입니다.

결정은 지우지 않고 대체한다

"왜 이렇게 했더라?"가 가장 자주 사라지는 정보입니다. 마이클 나이가드(Michael Nygard)가 2011년에 제안한 아키텍처 결정 기록(ADR)은 제목, 맥락, 결정, 상태, 결과의 다섯 칸짜리 짧은 문서입니다. 눈여겨볼 것은 결정이 뒤집혔을 때의 처리입니다.

결정이 뒤집히더라도 옛 기록은 남겨 두고, 대체됨(superseded)이라고 표시한다.

과거의 결정을 지우면 "그때는 왜 그랬는지"도 함께 지워지고, 같은 논쟁을 처음부터 다시 하게 됩니다.

링크에는 이유를 붙인다

이슈, 결정, 노트를 연결할 때는 '관련 있음'보다 한 걸음 더 나아가면 좋습니다. 근거가 된다, 반례다, 이 결정을 따른다, 이 업무에 적용했다, 이전 결정을 대체한다. 다섯 가지면 대부분 표현됩니다.

모든 업무가 이 사슬을 거쳐야 하는 것은 아닙니다. 다시 쓸 가치가 있는 판단이 나왔을 때만 남기면 됩니다.

밀린 노트를 전부 정리하고 시작할 필요는 없다

2022년 4월, 제텔카스텐 포럼에 "전부 다시 시작하고 싶다"는 글이 올라왔습니다. 2년 넘게 쓴 사용자의 고민이었습니다. "내 생각이 아니라 다른 데서 가져온 것일 뿐인 노트가 너무 많다." 답은 두 갈래였습니다. 한 사람은 예전 노트 더미를 옆에 그대로 두고 새로 시작했다고 했고, 사샤는 "그 노트들을 조금씩 정리하라"고 했습니다. 두 답에는 공통점이 있습니다. 어느 쪽도 과거를 다 치운 다음에 시작하라고 하지 않았습니다.

새 도구로 옮길 때도 마찬가지입니다. 지금 진행 중인 프로젝트 하나에 필요한 자료부터 연결하고, 나머지는 검색만 되게 보관해 두었다가 다시 꺼내 쓸 때 다듬습니다.

---

8부. AI에게 일을 맡기는 시대의 이슈

2026년의 이슈에는 독자가 하나 더 생겼습니다. AI 에이전트입니다.

길이가 아니라 경계

깃허브는 코딩 에이전트에게 일을 맡길 때의 모범 사례 문서에서, 잘 정의된 이슈의 조건으로 문제에 대한 명확한 설명과 "좋은 해결이 어떤 모습인지에 대한 완전한 수락 기준", 그리고 어느 파일을 바꿔야 하는지에 대한 안내를 듭니다. 3부의 다섯 항목과 거의 겹칩니다. 사람에게 잘 맡기는 법과 AI에게 잘 맡기는 법이 같은 방향이라는 뜻입니다.

AI에게 맡기는 이슈에 더 필요한 것은 분량이 아니라 경계입니다.

크게 보기

2026년 7월, 개발자 Jinyoung Park은 Jira 티켓에서 풀 리퀘스트(PR)까지 이어지는 AI 개발 루프를 직접 만들어 운영한 기록을 공개했습니다. 두 문장이 눈에 띕니다. "자동 병합은 없다." 그리고 "모호한 티켓은 모호한 PR이 된다." AI가 결과물을 만들었다는 것과 그 일이 끝났다는 것은 별개이고, 입력이 흐리면 출력도 흐립니다. 한 팀의 운영 경험이지만, 3부까지의 원칙이 AI 앞에서 더 엄격해진다는 점을 잘 보여 줍니다.

이슈는 AI가 결과를 돌려놓는 곳이기도 하다

로버트 마쓰오카(Robert Matsuoka)는 2025년 12월 글에서 다른 문제를 짚었습니다. AI와 일하면 조사 결과와 기각한 대안, 판단 이유가 대화창 안에 쌓였다가 세션이 끝나면 사라진다는 것입니다. 그는 에이전트가 알아낸 것을 티켓에 되적게 하는 방식을 제안합니다. "접근 하나를 기각하면, 그 이유가 기록된다." 그가 직접 만든 도구를 소개하는 글이라는 점은 감안해야 합니다. 그래도 문제 제기는 5부와 정확히 이어집니다. 윌리슨이 손으로 하던 일을 에이전트에게도 시키자는 것입니다.

AI가 일을 마치면 "완료했습니다" 한 줄 대신 이런 것을 이슈에 남기게 합니다. 처리한 범위, 참고한 근거, 그 방법을 고른 이유, 하지 않았거나 확인하지 못한 것, 사람이 봐야 할 곳.

반론: 티켓보다 맥락

존 커틀러는 2026년 9월 1일 「AI Needs Context, Not Tickets」에서 이렇게 썼습니다.

에픽, 기회, 태스크, 스토리 같은 것들은 대화와 조율, 집중을 담는 그릇이다.

그릇은 성과가 아닙니다. 이슈가 닫혔다는 것과 고객의 문제가 풀렸다는 것은 다른 사실입니다. 그의 글 제목대로 AI에게 필요한 것이 티켓이 아니라 맥락이라면, 프로젝트 → 이슈 → 하위 이슈라는 계층만 보여 줘서는 부족합니다. 고객 요청, 관련 조사, 과거 결정, 실제 결과가 이슈와 연결돼 있어야 합니다. 7부에서 링크에 이유를 붙이자고 한 것과 같은 이야기입니다.

---

9부. 서로 부딪히는 조언을 읽는 법

여기까지 읽으면 조언끼리 충돌하는 것처럼 보입니다. 잘게 나누라더니 합치라 하고, 자세히 쓰라더니 간결하게 쓰라 합니다. 대부분은 서로 다른 단위에 대한 조언을 같은 칸에 놓고 읽어서 생기는 충돌입니다.

이 표는 특정 저자의 방법론이 아니라 이 글이 앞의 자료들을 종합한 것입니다.

---

10부. 이 글에 대한 반론

1. 사용기는 실험이 아니다. 윌리슨은 혼자 일하는 오픈소스 개발자이고, 스터블바인은 코치이며, Jinyoung Park의 루프는 한 조직의 사례입니다. 이들에게 통했다는 것이 여러분의 팀에 통한다는 증거는 아닙니다.

2. 이 글의 숫자는 출발값이다. '반나절에서 이틀'은 근거 있는 통계가 아니라 시작해 볼 만한 범위입니다. 팀마다 직접 조정해야 합니다.

3. 양식은 입력 부담이다. 항목을 늘리면 이슈는 좋아지지만 적는 사람은 줄어듭니다. 그래서 효과는 완료한 개수로 재면 안 됩니다. 일을 잘게 쪼개기만 해도 완료 개수는 늘기 때문입니다. 대신 이런 것을 봅니다. 맡긴 뒤 추가 설명을 요청받은 횟수, 완료 후 다시 열린 업무와 그 이유, 다음 행동도 재확인일도 없는 프로젝트의 수, 과거의 결정이나 노트가 새 업무에서 실제로 다시 쓰인 사례.

4. 이슈를 잘 쓰는 것이 목적이 되면 안 된다. 커틀러와 헤르츠의 글이 일깨우듯, 전제가 틀렸다면 잘 쓴 이슈를 끝까지 완수하는 것은 낭비입니다. 이슈는 생각을 담는 그릇이지 생각을 대신하는 장치가 아닙니다.

5. 출처에는 이해관계가 있다. Linear와 Todoist의 문서는 자사 제품의 설계를 설명하는 글이고, 마쓰오카와 올리버의 글에는 자기가 만든 도구가 등장합니다. 저희도 예외가 아닙니다. 코어닷투데이는 지금 팀을 위한 업무 관리 도구를 만들고 있고, 이 글은 그 설계의 바탕이 된 조사를 정리한 것입니다.

---

맺으며: 미래의 나와 동료에게 쓰는 글

처음의 카드로 돌아가 봅니다. 김 대리가 이렇게 적었다면 어땠을까요.

카드는 길어졌습니다. 대신 3주가 아니라 며칠 안에 끝났을 것이고, 끝났다는 것을 모두가 같은 기준으로 알았을 겁니다. 배너와 모바일 메뉴는 각자의 카드에서 각자의 속도로 진행됐을 겁니다.

오늘 바로 해 볼 수 있는 것은 다섯 가지입니다.

크게 보기

제텔카스텐, 이슈, 프로젝트 관리는 서로 다른 방법론처럼 보이지만 하는 일은 하나입니다. 미래의 나와 동료가 같은 맥락을 처음부터 다시 추리하지 않게 하는 것. 이슈를 잘 쓴다는 것은 문서를 예쁘게 만드는 일이 아니라, 석 달 뒤 이 카드를 열어 볼 누군가의 시간을 미리 아껴 두는 일입니다.

---

출처

일을 나누는 단위

• Liz Keogh, 「Splitting stories into tasks – when, why and how (or not)」 (2011-08-23) — lizkeogh.com
• Bill Wake, 「INVEST in Good Stories, and SMART Tasks」 (2003-08-17) — xp123.com
• Mike Cohn, 「SPIDR: Five Simple but Powerful Ways to Split User Stories」 (2026-08-06 갱신) — mountaingoatsoftware.com
• Richard Lawrence & Peter Green, 「The Humanizing Work Guide to Splitting User Stories」 — humanizingwork.com
• Ryan Singer, 『Shape Up』 3장 「Set Boundaries」, 12장 「Map the Scopes」 — basecamp.com, basecamp.com
• Ken Schwaber & Jeff Sutherland, 『The Scrum Guide』 (2020-11) — scrumguides.org
• GTD Times, 「Managing Projects – Tips from David Allen」 (2010-02-15) — gettingthingsdone.com

이슈를 쓰는 법

• 박재영, 「티켓 주도 개발 (ticket-driven development)을 도입하기」 (2022-07-14) — velog.io
• Linear Method, 「Write issues not user stories」 — linear.app
• Gina Trapani, 「Work Smart: How to Write a To-Do List」, Fast Company (2010-05-03) — fastcompany.com
• Coach Tony (Tony Stubblebine), 「Replace Your To-Do List With Interstitial Journaling To Increase Productivity」, Better Humans (2017-09-07) — betterhumans.pub
• Cal Newport, 「Deep Habits: Three Tips for Taming Undecidable Tasks」 (2014-12-24) — calnewport.com

작업 노트로서의 이슈

• Simon Willison, 「Coping strategies for the serial project hoarder」 (2022-11-26) — simonwillison.net
• Oliver, 「On Ticketing」 (2025-04-27, 2025-05-12 갱신) — oliverherman.com
• Martin Hertz, 「Ticket-driven development: three modern flavors of the anti-pattern」 (2025-03-25) — computersandpeople.com

약속과 흐름

• Linear Changelog, 「Web forms for Linear Asks」 (2026-04-02) — linear.app
• Todoist 도움말, 「Introduction to deadlines in Todoist」 (2026-09-01 갱신) — todoist.com
• 『The Kanban Guide』 (2025-05판) — kanbanguides.org
• John Cutler, 「TBM 386: Understanding Enabling Constraints Using Shape Up (Basecamp)」 (2025-11-03) — cutlefish.substack.com

노트와 결정

• Sascha, 「The Principle of Atomicity – On the Difference Between a Principle and Its Implementation」 (2025-08-12) — zettelkasten.de
• Andy Matuschak, 「Evergreen notes should be atomic」 — notes.andymatuschak.org
• Andy Matuschak, 「Evergreen note titles are like APIs」 — notes.andymatuschak.org
• Jethro Kuan, 「How I Take Notes with Org-roam」 (2022-02-08) — jethrokuan.github.io
• Christian Tietze, 「The Collector's Fallacy」 (2014-01-20) — zettelkasten.de
• Jeroen Fierens, 「The Opposite Collector's Fallacy」 (2020-05-23) — technosoof.wordpress.com
• Zettelkasten Forum, 「Tempted to start all over」 (2022-04-11) — forum.zettelkasten.de
• Michael Nygard, 「Documenting Architecture Decisions」 (2011-11-15) — cognitect.com

AI와 이슈

• GitHub Docs, 「Best practices for using GitHub Copilot to work on tasks」 — docs.github.com
• Jinyoung Park, 「The Name Came Later — From Jira Ticket to PR: The Story of Building an AI Development Loop」 (2026-07-14) — jinyoung-park.dev
• Robert Matsuoka, 「TkDD: Ticket-Driven Development and the Knowledge We're Throwing Away」 (2025-12-03) — hyperdev.matsuoka.com
• John Cutler, 「AI Needs Context, Not Tickets」 (2026-09-01) — linkedin.com