Linear 사용법, 이슈부터 사이클 운영까지 순서대로

TL;DR

• Linear 사용법의 출발점은 이슈다. 이슈를 팀·상태·사이클로 굴리고, 여러 이슈를 묶으면 프로젝트, 프로젝트를 묶으면 이니셔티브가 된다.
• 무료 플랜은 인원 무제한에 팀 2개, 이슈 250개까지다. 이슈 수가 먼저 닳으므로 실제 운영을 시작하면 월 $10 Basic이 기준선이 된다.
• Triage로 외부 요청을 한 곳에 받고, 사이클로 주 단위 작업량을 고정하는 두 습관이 이 도구의 핵심이다.

Linear 사용법을 익히는 데 걸리는 시간은 짧다.
화면 요소가 적고 단축키로 대부분이 처리되기 때문이다.
정작 어려운 쪽은 도구가 아니라 운영 방식이다.
이슈를 어느 단위로 쪼갤지, 사이클에 무엇을 넣을지, 외부에서 들어온 요청을 어디로 받을지 정하지 않으면 화면만 깔끔한 백로그가 쌓인다.

Linear가 다른 이슈 트래커와 갈리는 지점도 여기에 있다.
이 회사는 “Linear Method”라는 이름으로 자기들이 생각하는 제품 개발 방식을 따로 문서화해 공개한다.
사용자 스토리 대신 이슈를 쓰라거나, 프로젝트 범위를 줄이라거나, 계속 출시하라는 원칙들이다.
제품 기능이 그 원칙을 전제로 설계돼 있어서, 원칙을 모르고 기능만 쓰면 어색해지는 구간이 생긴다.
아래는 워크스페이스를 만든 다음 이슈를 쌓고 사이클을 돌리는 데까지를 공식 문서와 요금표 기준으로 정리한 것이다.

Linear의 작업 단위가 쌓이는 순서

가장 작은 단위는 이슈다.
제목, 상태, 담당자, 우선순위, 라벨, 예상 규모를 갖는다.
이슈는 팀에 속한다.
팀마다 상태 흐름을 따로 설계할 수 있어서, 개발팀과 디자인팀이 서로 다른 단계를 쓰면서 같은 워크스페이스를 공유한다.

이슈 위에 세 가지 묶음이 있다.

• 사이클: 기간으로 묶는다. 보통 1~2주 단위로 돌리고, 그 기간에 끝내기로 한 이슈를 담는다. 끝나지 않은 이슈는 다음 사이클로 넘어간다.
• 프로젝트: 목적으로 묶는다. “결제 개편”처럼 여러 사이클에 걸쳐 진행되는 덩어리다.
• 이니셔티브: 프로젝트를 묶는 상위 단위다. 회사 차원의 방향을 팀 단위 실행으로 잇는 자리이고, 최근에는 이니셔티브마다 담당 팀을 지정할 수 있게 바뀌었다.

큰 이슈는 하위 이슈로 쪼갠다.
이슈끼리는 blocked, blocking, related, duplicate 관계를 지정할 수 있어서 순서가 있는 작업을 표현할 수 있다.

Linear 사용법, 워크스페이스를 세팅하는 순서

1. 워크스페이스를 만들고 팀을 하나 만듭니다. 무료 플랜은 팀 2개까지입니다.
2. 팀 설정에서 상태 흐름을 봅니다. 기본은 Backlog, Todo, In Progress, Done 계열이고, 필요하면 상태를 추가합니다.
3. 이슈를 몇 개 넣어봅니다. 사용자 스토리 형식을 흉내 내지 말고 “무엇을 한다”로 짧게 씁니다.
4. GitHub를 연결합니다. 브랜치 이름이나 PR 제목에 이슈 키를 넣으면 상태가 자동으로 바뀝니다.
5. 사이클을 켭니다. 기간을 정하면 그 이후로는 자동으로 돌아가고, 끝난 사이클의 미완료 이슈는 다음으로 이월됩니다.
6. Triage를 켭니다. 외부 통합이나 다른 팀에서 들어온 이슈가 여기로 모입니다.
7. 프로젝트를 하나 만들어 관련 이슈를 담아보고, 진행률이 어떻게 표시되는지 확인합니다.
8. 기존 트래커가 있다면 가져오기 기능으로 옮깁니다. 공식 문서에 이슈 임포트 안내가 따로 있습니다.

기존 도구에서 넘어오는 팀이 가장 자주 하는 실수는 예전 상태 흐름을 그대로 복제하는 것이다.
상태가 여덟 개쯤 되면 어느 칸에 둬야 할지 판단하느라 시간이 든다.
처음에는 네 개 안팎으로 줄여두고, 부족하다고 느낄 때 추가하는 편이 낫다.

Triage를 쓰면 요청이 흩어지지 않는다

Triage는 들어오는 이슈를 받는 별도 수신함이다.
슬랙에서 온 요청, 고객 지원 도구에서 넘어온 문의, 다른 팀이 넘긴 작업이 여기에 쌓인다.
담당자가 훑으면서 수락하거나, 다른 팀으로 넘기거나, 닫는다.

이 구조의 쓸모는 백로그를 지키는 데 있다.
Triage가 없으면 요청이 곧장 백로그로 들어가고, 그 순간부터 “언젠가 할 일”과 “누가 요청한 일”이 섞인다.
수신함을 하나 두면 팀이 무엇을 받아들였는지가 명시적으로 남는다.

상위 플랜에서는 여기에 자동화가 붙는다.
Triage 규칙으로 조건에 맞는 이슈를 자동 분류하고, Triage Intelligence가 라벨과 우선순위를 제안한다.
Linear Asks를 쓰면 슬랙 채널이나 웹 폼, 이메일로 들어온 요청이 이슈로 바뀐다.

요금제와 무료로 쓸 수 있는 범위

무료 플랜에서 먼저 닳는 건 인원이 아니라 이슈 수다.
인원은 무제한인데 이슈가 250개로 묶여 있어서, 실제 개발을 굴리는 팀이면 몇 주 만에 닿는다.
사이드 프로젝트나 도입 검토용으로는 충분하다.

Basic과 Business를 가르는 건 팀 수와 조직 기능이다.
팀이 5개를 넘거나, 외부 협력자를 게스트로 초대해야 하거나, 지원 도구를 연결해야 하면 Business 층이다.
공식 자료 기준으로 4만 개 넘는 회사가 쓴다고 표기돼 있다.

AI 에이전트가 이슈를 직접 처리하는 구조

Linear는 2026년 들어 에이전트 쪽에 무게를 실었다.
Linear Agent에게 이슈를 맡기면 코드를 고치고 PR을 올린다.
코딩 세션에서는 저장소 설정을 감지해 필요한 툴체인과 의존성을 설치하고, 파이썬·루비·Go 같은 언어를 기본 지원한다.
런타임 버전을 고정하거나 설치 스크립트, 환경변수를 지정할 수도 있다.

여기에 브라우저 테스트가 붙었다.
에이전트가 앱을 띄우고 화면 흐름을 따라가며 자기가 만든 변경을 확인하고, 전후 스크린샷을 남긴다.
문제를 찾으면 고쳐서 다시 테스트한 뒤 결과를 돌려준다.

비용 구조도 공개돼 있다.
모델 사용료는 공급자 공시 요율 그대로 마크업 없이 붙고, 샌드박스 실행 시간은 20분 단위 블록당 $0.25다.
워크스페이스 전체와 사용자별로 지출 한도를 걸 수 있고, 한도는 일·주·월 단위로 초기화된다.
한도에 닿으면 추가 사용이 멈춘다.

Loops는 반복 작업을 자연어로 등록하는 기능이다.
정해진 일정이나 이벤트에 맞춰 에이전트가 워크스페이스 맥락을 참고해 실행한다.

Linear Method에서 가져갈 원칙

공식 문서로 공개된 원칙 중 실제로 운영에 영향을 주는 것들이 있다.

사용자 스토리 대신 이슈를 쓰라는 원칙이 첫째다. “사용자로서 ~하고 싶다” 형식은 길이만 늘리고 실제로 할 일을 흐린다.
무엇을 만들지 한 줄로 적는 편이 낫다는 입장이다.

프로젝트 범위를 줄이라는 원칙이 둘째다.
큰 프로젝트는 진행 상황이 보이지 않고 끝나지 않는다.
몇 주 안에 끝낼 크기로 잘라두면 진척이 눈에 보인다.

계속 출시하라는 원칙이 셋째다.
한 번의 큰 출시 대신 작은 출시를 반복하면 피드백이 빨리 돌아온다.
사이클 기능이 이 방식을 전제로 만들어져 있다.

한계와 안 맞는 경우

• 워크플로를 세밀하게 커스터마이즈해야 하는 조직. Linear는 의도적으로 설정 폭을 좁혀뒀다. 승인 단계를 여러 개 두거나 필드를 잔뜩 추가하는 방식이면 맞지 않는다.
• 개발 외 부서까지 하나의 도구로 묶으려는 경우. 제품 개발을 전제로 만든 도구라 총무나 회계 업무 관리에는 어색하다.
• 무료로 오래 버티려는 팀. 이슈 250개 제한이 빠르게 닿는다.
• 온프레미스 배포가 필요한 환경. 자가호스팅 경로가 없다. 이 조건이 걸리면 다른 선택지를 봐야 한다.

제품 만들 때 가져갈 설계

Linear에서 훔쳐올 만한 설계는 기본값을 좁게 잡은 결정이다.
설정 화면이 짧고 상태 개수가 적다.
선택지를 줄이면 사용자가 고민할 일이 줄고, 대신 도구가 원하는 사용 방식이 분명해진다.
무엇이든 되는 도구는 무엇을 해야 할지 알려주지 않는다.

두 번째는 원칙을 문서로 따로 공개한 점이다.
기능 설명이 아니라 “우리는 이렇게 일한다”를 먼저 내놓고, 제품이 그 방식을 돕는 구조로 붙어 있다.
제품과 사용법을 함께 파는 방식이다.

세 번째는 에이전트 비용을 사용자 눈에 그대로 보여준 방식이다.
모델 요율에 마크업을 붙이지 않는다고 명시하고, 실행 시간을 20분 블록으로 끊어 단가를 공개하고, 지출 한도를 기능으로 준다.
AI 기능을 붙일 때 요금이 불투명하면 도입이 막힌다는 걸 정면으로 다룬 셈이다.

실행 체크리스트

1. 워크스페이스를 만들고 팀을 하나만 먼저 만듭니다.
2. 상태 흐름을 네 개 안팎으로 줄입니다. 부족하면 나중에 추가합니다.
3. 이슈 작성 규칙을 정합니다. 한 줄로 무엇을 할지 쓰는 형식이 기본입니다.
4. GitHub를 연결하고 브랜치·PR 연동으로 상태가 자동 전환되는지 확인합니다.
5. 사이클을 켜고 첫 주에 담을 이슈 수를 보수적으로 잡습니다.
6. Triage를 켜서 외부 요청이 백로그로 직행하지 않게 막습니다.
7. 무료 이슈 250개 한도에 언제 닿을지 계산하고 유료 전환 시점을 잡습니다.
8. 에이전트를 쓸 계획이면 워크스페이스 지출 한도를 먼저 설정합니다.
9. 기존 트래커가 있으면 가져오기로 옮기되 예전 상태 흐름은 복제하지 않습니다.

자주 묻는 질문

Linear는 무료로 어디까지 쓸 수 있나요

인원 제한 없이 팀 2개, 이슈 250개까지입니다.
파일 업로드는 10MB로 제한됩니다.
이슈 수가 먼저 닿기 때문에 실제 운영을 시작하면 유료 전환이 필요해집니다.

사이클과 프로젝트는 어떻게 다른가요

사이클은 기간으로 묶고 프로젝트는 목적으로 묶습니다.
하나의 프로젝트가 여러 사이클에 걸쳐 진행되고, 사이클에는 여러 프로젝트의 이슈가 섞여 들어갑니다.

GitHub와 연동하면 무엇이 자동으로 되나요

브랜치나 PR에 이슈 키를 넣으면 이슈와 연결되고, PR 상태에 따라 이슈 상태가 자동으로 바뀝니다.
공식 문서에 GitHub 자동화 항목이 따로 있습니다.

Linear Agent를 쓰면 비용이 얼마나 붙나요

모델 사용료는 공급자 공시 요율대로, 샌드박스 실행 시간은 20분 블록당 $0.25로 계산됩니다.
워크스페이스와 사용자별 지출 한도를 걸어두면 한도에 닿을 때 사용이 멈춥니다.

참고한 곳

• Linear 공식 홈
• Linear Pricing
• Linear Docs
• Linear Method
• Linear Changelog