다크 모드
Linear 사용 규칙
Linear는 개인 할 일 앱이 아닙니다. 팀 전체가 "지금 뭘 하고 있고, 다음에 뭘 해야 하는지" 한눈에 보기 위한 도구입니다. 여기 적힌 내용은 금지 목록이 아니라, 우리가 반복해서 겪은 문제를 줄이기 위해 합의한 working agreement입니다.
이슈 라이프사이클
이슈는 세 가지 경로로 만들어집니다. 어떤 경로든 최종 품질 기준은 동일합니다.
머릿속 아이디어나 버그를 빠르게 캡처하고 싶을 때.
- Triage에 이슈 생성 (제목만으로 충분)
- Claude Code Linear 스킬로 설명·라벨·완료 조건 보강
- 트리아지에서 검토 후 Backlog 또는 Todo로 배치
Slack 스레드에서 논의 중 바로 이슈화할 수도 있습니다. Slack Linear App으로 스레드에서 이슈를 생성하면 Triage로 들어가고, 대화 맥락이 자동으로 링크됩니다. 이후 다듬기 과정은 동일합니다.
급한 버그 리포트, 회의 중 나온 아이디어, Slack 논의에서 나온 작업 항목에 적합합니다.
이슈 단위: "이게 이슈인가?"
Reviewable deliverable의 최소 단위
이슈 하나가 끝나면 팀원에게 보여줄 결과물이 있어야 합니다. 코드라면 PR diff, 디자인이라면 시안, 문서라면 변경된 페이지. "검토해주세요"라고 말하면서 실제로 보여줄 수 있는 것이 없다면, 이슈가 아닙니다.
이 기준이 왜 중요한지, 프로젝트 진행률로 설명하겠습니다.
주의
진행률 착시 주의. 프로젝트에 이슈 20개, 완료 15개면 75%처럼 보입니다. 그런데 완료된 15개가 각각 30분짜리고, 남은 5개가 각각 2일짜리라면? 실제 진행률은 30%에 가깝습니다. 이슈 단위가 균일해야 프로젝트 가시성이 의미를 가집니다.
반대로, "버튼 색상 #FF0000으로 변경" 같은 건 별도 이슈가 아니라 기존 이슈의 체크리스트 항목입니다. 5분이면 끝나는 작업에 이슈 번호를 붙이면 관리 비용만 늘어납니다.
5가지 테스트
작업이 아래 중 3개 이상 통과하면 별도 이슈로 만듭니다. 아니면 기존 이슈의 체크리스트 항목입니다.
| 테스트 | 질문 |
|---|---|
| PR 테스트 | 이 작업이 자체 PR을 만드는가? |
| 담당자 테스트 | 다른 사람이 작업할 수 있는가? |
| 배포 테스트 | 독립적으로 배포 가능한가? |
| 블로커 테스트 | 다른 작업을 막거나 막히는가? |
| 시간 테스트 | 2~3시간 이상의 집중 작업이 필요한가? |
1~2일에 끝낼 수 있는 크기가 이상적입니다. 3일이 넘으면 분해가 필요하고, sub-issue가 10개를 넘기면 프로젝트로 승격하세요.
| 결과물 유형 | 예시 | 리뷰 방법 |
|---|---|---|
| 코드 | PR, 커밋 | GitHub PR 리뷰 |
| 디자인 | Figma 시안, 프로토타입 | 디자인 리뷰 |
| 문서 | 위키 페이지, 스펙 | 문서 리뷰 |
| 조사 | 선택지 비교, 기술 검토 | Spike 결과 리뷰 |
| 설정 | 인프라 변경, CI/CD | 변경 diff 리뷰 |
이슈 작성 규칙
제목
제목만 보고 무엇을 해야 하는지 바로 알 수 있어야 합니다. "~관련", "~작업", "~처리" 같은 제목은 나중에 본인도 뭔지 모릅니다.
액션 동사로 시작합니다:
| 접두어 | 용도 | 예시 |
|---|---|---|
| Fix | 버그 수정 | Fix 룹 생성 시 카테고리 미적용 |
| Add | 새 기능 | Add 비회원 참여자 SMS 재발송 |
| Update | 기존 기능 개선 | Update 리캡 썸네일 선택 로직 |
| Remove | 기능/코드 삭제 | Remove deprecated Story 엔드포인트 |
| Refactor | 리팩토링 | Refactor 미디어 업로드 파이프라인 |
| Design | 디자인 | Design 온보딩 v2 화면 |
| Investigate | 조사/분석 | Investigate 푸시 알림 미수신 원인 |
User Story 형식은 쓰지 않습니다
"As a user, I want to..." 형식은 우리 규모에서 오버헤드만 늘립니다. 직접적이고 구체적인 작업을 기술하세요. 전략적 맥락(왜 이 작업이 필요한지)은 프로젝트 설명에서 관리합니다.
설명 템플릿
### 현상
어떤 문제가 발생하는지 한 문장으로.
### 재현 방법
1. [구체적 단계]
2. [구체적 단계]
### 기대 동작
정상적으로 동작해야 하는 방식.
### 영향 범위 (선택)
- 심각도: Critical / Major / Minor / Cosmetic
- 빈도: 항상 / 간헐적 (재현율 N%)
- 우회 방법: 있음 (설명) / 없음
### 완료 조건
- [ ] [구체적이고 검증 가능한 조건]
- [ ] [회귀 테스트 조건]완료 조건
완료 조건 없이 이슈를 만들면, 나중에 "이거 끝난 거 맞아?" 하는 대화가 반복됩니다. 완료 기준을 체크리스트로 적어두면 그 대화가 사라집니다.
모든 조건은 독립적으로 검증 가능해야 합니다. "빠르게 응답" 대신 "2초 이내 응답" 같이 구체적 수치를 쓰세요.
크로스 플랫폼 작업
iOS + Android + Backend에 걸치는 작업인 경우:
- 플랫폼별 sub-issue로 분리 (각각 별도 담당자)
- 부모 이슈에 전체 요구사항, sub-issue에 플랫폼별 구현 범위
- API 스펙이 필요하면 Linear Document로 작성하여 이슈에 링크
단일 담당자 원칙
이슈 하나에 담당자 1명. "같이 하자"가 필요하면 sub-issue로 나누세요. 담당자가 두 명이면 아무도 책임지지 않게 됩니다.
라벨 체계
Type (이슈 유형) — 필수, 1개만 선택
| 라벨 | 용도 |
|---|---|
| Feature | 새 기능 |
| Bug | 버그 수정 |
| Chore | 유지보수, 설정, CI/CD |
| Tech Debt | 기술 부채 해소 |
| Documentation | 문서 작업 |
| Security | 보안 관련 |
Area (영역) — 필수, 1개만 선택
| 라벨 | 용도 |
|---|---|
| Product | 제품 기획 |
| Design | 디자인 |
| iOS | iOS 클라이언트 |
| Android | Android 클라이언트 |
| Backend | 서버 사이드 |
| Web | 웹 프론트엔드 |
Type과 Area가 없으면 트리아지에서 분류할 수 없습니다. 이슈 생성 시 바로 붙여주세요.
우선순위 가이드
| 우선순위 | 기준 | 예시 |
|---|---|---|
| Urgent | 프로덕션 장애, 데이터 손실 위험 | 서버 다운, 크래시 |
| High | 핵심 사용자 흐름 차단, 현재 사이클 목표 | 로그인 불가, 룹 생성 실패 |
| Medium | 다음 릴리스에 포함할 기능/개선 | 새 기능, UX 개선 |
| Low | 급하지 않은 개선 | 코드 정리, 문서 보강 |
모든 이슈에 우선순위를 설정하세요. 미설정 이슈는 트리아지에서 병목이 됩니다.
워크플로우
Triage
새 이슈가 생성되면 여기로 들어옵니다. 트리아지에서 팀 리드가 검토하고 다음 상태로 이동시킵니다.
Todo
트리아지를 통과하여 이번 사이클에 처리할 작업입니다. 담당자가 배정되어 있어야 합니다.
In Progress
담당자가 작업을 시작했습니다. 담당자가 직접 이동시킵니다.
In Review
PR 리뷰 중입니다. GitHub 연동으로 자동 이동을 권장합니다.
Done
작업이 완료되고, 머지 및 배포까지 끝난 상태입니다. 완료 조건이 모두 충족된 이후에만 이동합니다.
트리아지 규칙
주간 트리아지에서 Triage 상태의 이슈를 검토합니다:
| 확인 항목 | 조치 |
|---|---|
| 제목이 액션 동사로 시작? | 수정 |
| 설명과 완료 조건 있음? | 작성 요청 |
| 우선순위 설정됨? | 설정 |
| Type, Area 라벨 있음? | 추가 |
| 담당자 지정됨? | 지정 또는 Backlog 이동 |
| 중복 이슈? | Duplicate 처리 |
| Backlog 30일 초과? | 아카이브 검토 |
정보
Backlog에 30일 넘게 머무는 이슈는 "언젠가 할 거야"가 아니라 "안 할 거야"에 가깝습니다. 아카이브하세요. 정말 필요하면 다시 만들면 됩니다.
Estimation
왜 estimate를 하는가
Estimation은 정밀한 예측이 목적이 아닙니다. **"이 사이클에 현실적으로 이 작업들을 완료할 수 있는가?"**에 답하기 위한 안전장치입니다. 매주 야근하고 있다면 estimation이 아니라 scope이 문제입니다.
AI 시대의 Estimate: 무엇을 측정하는가
AI Agent가 코딩의 대부분을 수행하는 환경에서, 코딩 자체는 빨라졌습니다. 하지만 나머지는 줄지 않거나 오히려 늘어났습니다:
- 설계/사고: 어떤 접근을 택할지 결정하는 시간 — 변함없음
- 리뷰: AI가 생성한 코드를 검증하는 시간 — 증가
- 테스트/디버깅: "거의 맞지만 미묘하게 틀린" AI 출력을 잡아내는 시간 — 증가
- 배포/통합: 변함없음
따라서 estimate = 사람이 투입해야 하는 설계 + 리뷰 + 검증 시간입니다.
T-Shirt Sizes
| 사이즈 | 의미 | 기준 |
|---|---|---|
| S | 리뷰 최소 | Agent가 거의 자율 처리 가능. 단일 시스템, 단순 변경. 리뷰 30분 이내. |
| M | 리뷰 보통 | Agent가 처리하되, 여러 파일에 걸친 변경. 설계 판단 약간 필요. |
| L | 설계 필요 | 사람이 설계를 주도해야 함. 멀티 시스템, 리뷰 부담 큼. |
| XL | 분해 필요 | 한 번의 리뷰 세션으로 검증 불가능한 크기. 이슈를 쪼개세요. |
Estimate 논쟁이 2분을 넘기면, 이슈가 너무 크거나 모호하다는 신호입니다. 분해하세요.
주의할 안티패턴
위험
5분 착각. "AI가 금방 하겠지" — 리뷰, 테스트, 엣지케이스 비용이 빠져 있습니다. 복잡한 코드베이스에서는 오히려 더 느려질 수 있습니다.
| 안티패턴 | 왜 문제인가 |
|---|---|
| 5분 착각 | AI가 코드를 빠르게 뱉어도, 리뷰·테스트·엣지케이스 처리 시간은 사람 몫입니다. |
| 70% 함정 | AI가 70%를 빠르게 만들지만, 나머지 30%(엣지케이스, 보안, 에러 처리)가 처음부터 짜는 것보다 비쌀 수 있습니다. |
| 양산 공장 | AI가 빠르니까 이슈를 많이 만들어 많이 처리 — PR은 늘지만 리뷰 병목이 발생하고 품질이 떨어집니다. |
단계적 도입
estimation은 팀의 데이터가 쌓여야 의미가 있습니다. 처음부터 완벽하게 하려 하지 마세요.
Cycle 1~3: Baseline 확보
Estimate를 설정하지 않습니다. 사이클당 완료 이슈 개수만 추적하여 팀 throughput의 baseline을 확보합니다. Linear의 자동 capacity 계산(최근 3사이클 평균)이 이 데이터를 활용합니다.
Cycle 4~8: T-Shirt Size 도입
이슈 크기 편차가 크다고 느껴지면 위의 T-shirt 사이즈를 도입합니다. Capacity는 70~80%만 계획합니다. 나머지는 예상 못 한 버그, 리뷰, 운영 이슈를 위한 버퍼입니다.
Cycle 9+: 팀 판단
더 세밀한 계획이 필요하면 Fibonacci로 전환합니다. 이슈 크기가 대체로 균일해졌다면 estimation을 드롭해도 됩니다. 불필요한 의식을 유지하는 것보다 낫습니다.
Point를 시간으로 환산하지 마세요("1pt = 1일" 같은 매핑). Velocity를 팀원 간 성과 지표로 비교하지 마세요. 둘 다 시스템을 망가뜨리는 지름길입니다.
사이클 관리
- 2주 사이클
- 사이클 시작 시 Backlog에서 Todo로 이동
- 미완료 이슈는 다음 사이클로 이동 또는 Backlog 복귀
매 사이클이 끝날 때 "왜 남았는가"를 간단히 복기하세요. 이슈가 너무 컸는지, scope이 과했는지, 외부 블로커가 있었는지. 그 피드백이 다음 사이클의 계획 품질을 올립니다.
변경 이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-03-15 | 최초 작성 |