Linear로 애자일 이슈·사이클 관리 시작하기

노션에 이슈를 쌓다 보면 엔지니어링 특화 기능(키보드 중심, 사이클, Git 연동)이 아쉽습니다. Linear는 가볍고 빠른 이슈 트래커로 소규모 제품 팀에 잘 맞습니다.

준비물#

Linear 계정·워크스페이스
GitHub/GitLab 연동(선택)
팀원 1명 이상과 상태 이름 합의

따라 하기#

Team 생성 — 예: Engineering
워크플로 상태 예: Backlog → Todo → In Progress → In Review → Done
Label 최소셋: bug, feature, chore, priority-high
Issue 템플릿 (설명 필드에 고정):

1
## 배경
2
## 재현/요구
3
## 완료 조건 (Acceptance)
4
- [ ]
5
## 메모 / 스크린샷

Cycle — 1~2주 단위. 이번 사이클에 넣을 이슈만 Todo로.
주간 루틴 — 월요일 계획, 매일 15분 triage, 금요일 완료 이슈 정리.

이슈 작성 좋은 예 / 나쁜 예#

나쁜 제목	나은 제목
로그인 이상	로그인 시 400: 빈 비밀번호에도 API 호출됨
개선	설정 페이지 로딩 3s→1s: 이미지 lazy load

Notion vs Linear (짧은 비교)#

	Notion	Linear
문서·위키	강함	이슈 링크 위주
키보드·속도	보통	강함
비개발 협업	쉬움	학습 필요

FAQ#

Q. 무료로 팀 사용? 플랜은 시점에 따라 변경. 공식 가격 페이지 확인.

Q. 스프린트 용어와 사이클? 개념적으로 유사. 팀 용어를 하나로 통일하세요.

키보드·단축 습관#

이슈 생성 직후 완료 조건 3줄
상태 변경은 보드 드래그보다 단축키
Git 연동 시 PR에 이슈 ID 포함

사이클 실패 패턴#

사이클에 이슈 과다 → 우선순위 라벨로 상한
Done 정의 없는 카드 → 리뷰 거부
개인 할 일과 엔지니어링 이슈 혼선 → Notion GTD와 분리 (포스트 22)

우선순위 규칙 예#

P0: 장애·보안·데이터 손실
P1: 이번 사이클 약속
P2: 개선 P0가 쌓이면 사이클 중간에 범위를 줄입니다.

추가 FAQ#

Q. 이슈 없이 핫픽스? 사후 이슈를 만들고 원인·재발방지를 남기세요. 기록 없는 핫픽스는 반복됩니다.

주말 실습: 이슈 템플릿 적용#

진행 중 작업 3개를 이슈 트래커에 옮기고 완료 조건 체크박스 2개 이상. 제목만 있는 카드는 금지.

현장 시나리오: 사이클 중반 범위 폭발#

월요일에 넣지 않았던 요청이 수요일에 세 건 들어오면, 도구가 아니라 거절/이연 규칙이 필요합니다.

새 요청은 무조건 Backlog.
P0인지 15분 안에 판단.
P0가 아니면 “다음 사이클 후보” 라벨.
넣으려면 기존 카드 1장을 빼는 교환 규칙을 팀과 합의.

Linear 자동화 팁: 완료 시 Git 브랜치 정리 알림을 켜 두면 “Done인데 브랜치 남음”이 줄습니다. 다만 자동 삭제 전에 보호 브랜치를 확인하세요.

한계와 현실적인 기대#

애자일 도구는 회의를 없애 주지 않습니다. 완료 조건이 없는 카드와 과다한 사이클 범위가 진짜 적입니다. Linear든 Jira든 상태 이름만 바꾸고 습관이 같으면 결과는 같습니다. 주간 계획 회의에서는 “새로 넣을 것”보다 “무엇을 뺄 것인가”를 먼저 물으세요. 도구 알림이 많다면 이슈 구독을 줄이고 P0만 강하게 받는 편이 집중력에 낫습니다.

실습 체크리스트 (Linear)#

팀·프로젝트·라벨 최소 세트를 정했는가
이슈 템플릿(재현/수용 기준)을 적용했는가
사이클 기간과 완료 정의를 합의했는가
GitHub/PR 연동을 확인했는가
개인 할 일과 엔지니어링 이슈를 분리했는가

사이클 운영 플레이북#

Linear를 설치만 하고 사이클을 안 돌리면 예쁜 이슈 저장소가 됩니다. 아래 리듬을 2주만 지켜보세요.

사이클 시작: 용량의 70%만 채움 (예상 오버 버퍼)
매일: In Progress는 인당 1~2개
중간: Blocked 이슈 원인 라벨 강제
종료: 미완료는 다음 사이클로 이동 + 원인 한 줄

이슈 제목 규칙#

좋음: 결제 웹훅 재시도 시 중복 반영 수정
나쁨: 버그, 개선, 로그인

제목이 검색·사이클 리뷰·릴리즈 노트 초안의 품질을 결정합니다. AI로 제목을 다듬을 때는 “동사+대상+조건” 형식을 강제하세요.

Git 연동 최소 설정#

PR 제목에 이슈 키를 포함해 자동 링크되게 하면 상태 업데이트가 수월합니다. 다만 자동 Done 전환 규칙은 팀 합의 없이 켜면 “리뷰 전 Done” 사고가 납니다. 처음 2주는 수동 상태 변경을 유지하는 것을 권장합니다.

이 글을 끝내면 할 수 있는 것#

Linear에 팀·이슈 템플릿·사이클을 세팅한다.
상태 흐름과 WIP를 팀과 합의한다.
Notion 개인 할 일(GTD)과 역할을 분리한다.

최소 상태 머신#

Backlog → Todo → In Progress → In Review → Done Blocked는 상태 또는 라벨로 두고, 사유 코멘트 필수로 만드세요.

트러블슈팅#

증상	원인	해결
이슈 폭발	템플릿 없음	재현/수용 기준 필수
사이클 미완료 상습	과다 커밋	용량 70%만 계획
Git 연동 안 됨	권한	앱 설치·레포 선택
알림 피로	구독 과다	팀 단위 알림 축소
개인 할 일 혼입	도구 혼용	GTD와 분리

FAQ 보강#

Q. 무료 플랜 한도는? 시기별로 다릅니다. 공식 요금표를 기준으로 하세요.

Q. 스크럼 의식이 꼭 필요한가요? 도구보다 사이클+리뷰 리듬이 중요합니다. 의식은 팀에 맞게 축소 가능합니다.

현장에서 바로 쓰는 Linear 애자일 운영 노트#

이 절은 Linear 애자일 본문을 읽은 뒤 다음 영업일 안에 실행할 때 참고하는 운영 메모입니다. 도구 이름보다 중요한 것은 반복 가능한 순서와 실패 기록입니다. 처음 한 주는 완벽한 세팅보다 ‘최소 성공 1회’를 목표로 하세요. 성공 기준을 숫자나 체크박스로 적어 두면 나중에 회고할 때 감이 아니라 데이터로 판단할 수 있습니다.

첫 48시간 실행 계획 (Linear 애자일)#

준비물 절을 보고 계정·설치·권한을 먼저 끝낸다. 본론 중간에서 설치하면 흐름이 끊긴다.
본문의 핵심 절차 중 가장 작은 단위 하나만 끝까지 재현한다.
트러블슈팅 표에서 해당 증상 행을 찾아 해결을 적용하고, 없으면 새 행을 메모한다.
FAQ에서 비용·보안·팀 도입 질문을 읽고 내 환경에 해당하는지 표시한다.
실습 체크리스트를 인쇄하거나 이슈 한 장에 옮겨 완료 표시를 남긴다.
동료가 있다면 5분 데모를 보여 주고, 설명 중 막힌 지점을 문서에 보완한다.

품질을 유지하는 주간 루틴#

Linear 애자일 관련 설정과 문서는 한 번 만들고 방치하면 금방 낡습니다. 매주 15분만 투자해 다음을 점검하세요. 지난주에 새로 생긴 예외 상황, 팀원이 물은 질문, 실패한 명령, 유료 결제 여부, 보안 정책 변경 여부입니다. 변경이 있으면 본문 요약이 아니라 체크리스트와 트러블슈팅 표를 먼저 고칩니다. 긴 서론을 고치는 것보다 표 한 줄이 다음 독자를 더 많이 구합니다.

혼자 일할 때와 팀에서 쓸 때의 차이#

개인 사이드 프로젝트에서는 속도와 실험이 우선일 수 있습니다. 하지만 팀 저장소·고객 데이터·공통 인프라가 걸리면 Linear 애자일 사용 방식이 달라져야 합니다. 권한, 감사 로그, 승인 단계, 공유 채널 공지 같은 사회적 절차가 기술적 절차만큼 중요합니다. 모호하면 보수적으로 선택하세요. 막힌 시간을 줄이려다 사고를 키우는 경우가 더 비쌉니다. 팀 합의 문장이 없다면 이 글의 체크리스트를 복사해 ‘우리 팀 버전’ 헤더만 바꿔 공유하는 것으로 충분합니다.

측정 지표 제안#

지표	측정 방법	해석
첫 성공까지 시간	타이머	온보딩 문서 개선 신호
주간 재사용 횟수	간단한 해시 체크	습관 정착 여부
실패 재발	같은 증상 메모	트러블슈팅 보강 필요
도움 요청 횟수	슬랙/구두	문서 공백 위치
중단 결정	2주 후 유지/폐기	도구 과잉 방지

폐기 기준 (중요)#

Linear 애자일가 팀에 안 맞을 수도 있습니다. 실패를 인정하는 기준을 미리 정하세요. 예를 들어 2주 동안 핵심 절차를 3회 이상 재현하지 못했거나, 보안 검토에서 막혔거나, 기존 도구 대비 명확한 이득이 없으면 중단이 올바른 결정입니다. 중단할 때도 설정 내보내기·권한 회수·문서 보관 위치를 남겨 두면 다음에 재도전할 때 비용이 줄어듭니다. 생산성 글의 목적은 도구 수집이 아니라 더 적은 마찰로 같은 품질의 결과를 내는 것입니다.

독자가 자주 놓치는 디테일#

버전을 안 적으면 한 달 뒤 같은 글이 거짓이 됩니다. 환경 절에 버전을 남기세요.
스크린샷만 있고 텍스트 명령이 없으면 접근성과 검색성이 떨어집니다.
성공 로그만 남기고 실패 로그를 지우면 학습이 사라집니다.
다른 글과 주제가 비슷할 때는 이 글의 완료 정의만 다시 읽고 범위를 지키세요.
공유 전에 시크릿·사내 URL·고객명이 있는지 검색하세요.

정리#

도구 교체보다 완료 조건이 적힌 이슈가 생산성입니다. 템플릿 한 줄부터 적용하세요.

참고: Linear · Linear Docs