시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 8편입니다. 지금까지의 도구들이 기능을 더하거나 자유를 주는 방향이었다면, 이번 편의 Linear는 정반대로 갑니다. 철저히 덜어내고, 빠르고, 아름답게. 개발팀의 열광적 지지를 받는 이 도구가 그 단호한 미니멀리즘으로 무엇을 얻고 무엇을 포기했는지 같은 잣대로 들여다봅니다.
한눈에 보기
- 출시: 2019년, 미국 Linear(전 Uber·Airbnb 엔지니어들이 창업)
- 분류: 모던 이슈 트래커(개발팀 특화)
- 채택 이론: 애자일(사이클=스프린트), 속도와 단호한 기본값 우선
- 과금(2026년 6월 기준, 연간): 무료(사용자 무제한, 단 2팀·250이슈 제한) / Basic 약 $10 / Business 약 $16 (1인당 월) / Enterprise 별도 견적
- 주 타깃: 스타트업·성장기 기업의 소프트웨어 개발팀
1. 탄생 배경과 채택한 이론 모델
Linear는 “Jira는 너무 느리고 복잡하다”는 불만에서 출발했다. 2019년, Uber·Airbnb 출신 엔지니어들이 “개발자가 쓰고 싶어지는 이슈 트래커”를 목표로 만들었다. 키보드만으로 거의 모든 조작이 가능하고, 클릭 반응이 100밀리초 안에 떨어지는 압도적 속도가 상징이다.
이론적으로는 애자일을 따르되, Linear는 “사이클(Cycle)”이라는 자기만의 스프린트 개념을 쓴다. 핵심 철학은 단호한 기본값(opinionated defaults)이다. Jira가 “원하는 대로 다 설정하세요”라면, Linear는 “좋은 방식은 우리가 정해뒀으니 그냥 쓰세요”에 가깝다. 설정의 자유를 일부러 줄여서 속도와 단순함을 얻는다.
2. 핵심 구조와 데이터 모델
Linear의 구조는 간결하다.
팀(Team) → 프로젝트(Project)·사이클(Cycle) → 이슈(Issue) → 하위 이슈(Sub-issue)이슈가 중심 단위이고, 사이클(주기적 스프린트)과 프로젝트(기능 단위 묶음)가 이슈를 다른 각도로 묶는다. 로드맵으로 큰 그림을 보고, 트리아지(Triage)로 새 이슈를 분류한다. Jira의 에픽-스토리-서브태스크보다 단계가 적고, 무엇보다 “설정할 게 적다.” 들어오자마자 바로 쓸 수 있도록 기본값이 잘 잡혀 있다.
3. 강점 — 무엇을 잘하는가
Linear의 강점은 이 시리즈에서 특히 주목할 만하다.
첫째, 압도적 속도와 사용 경험이다. 빠르고, 키보드 친화적이고, 화면이 군더더기 없이 아름답다. 실제로 개발자들이 “쓰고 싶어 하는” 드문 도구다. 이 시리즈가 가장 중요하게 보는 “팀원이 매일 켜고 싶은가”에서, Linear는 지금까지 본 도구 중 가장 높은 점수를 받을 만하다.
둘째, 단호한 기본값이다. 설정 지옥이 없다. 들어오면 바로 정돈된 워크플로우가 깔려 있어, 세팅하는 사람과 쓰는 사람의 분리가 거의 없다. 이건 이 시리즈가 줄곧 지적해온 문제를 상당 부분 해소한 접근이다.
셋째, 개발 워크플로우 통합이다. GitHub·Slack과 매끄럽게 연결되고, AI 트리아지 같은 기능이 기본 플랜에도 포함된다. 무료 플랜도 사용자 수 무제한이라 작은 팀이 시작하기 좋다.
4. 현장의 복잡성 — 팀원이 안 쓰는 지점
Linear의 한계는 약점이라기보다 “선택의 대가”에 가깝다.
철저히 개발팀 전용이다. Linear의 모든 것 — 이슈, 사이클, 트리아지 — 은 소프트웨어 개발 워크플로우에 맞춰져 있다. 마케팅·운영·기획 같은 비개발 직군이 함께 쓰기엔 결이 맞지 않는다. 즉 Linear는 “팀원이 쓰고 싶어 하는” 문제를 풀었지만, 그 ‘팀원’이 개발자일 때만 그렇다. 다양한 직군이 섞인 조직 전체의 협업 도구로는 범위가 좁다.
덜어낸 만큼 못 하는 것도 많다. 단호한 기본값의 이면은 경직성이다. 커스텀 워크플로우, 복잡한 자동화를 Jira처럼 주무를 수 없다. 더 결정적으로, 간트 차트·시간 추적·부서 간 포트폴리오 뷰가 아예 없다. 규제 산업이나 복잡한 비표준 프로세스를 가진 팀에는 너무 빡빡하다.
관찰자에게도 돈을 받는다. 진행 상황만 보려는 이해관계자(경영진·고객)도 동일한 유료 시트를 사야 한다. 읽기 전용 무료 등급이 없어, 외부 협업자가 많은 조직은 비용이 빠르게 불어난다. 게다가 유료는 연간 결제만 가능하다. PSTA가 “계정 없이 URL로 현황 공유”를 지향하는 것과 정확히 대비되는 지점이다.
종합하면, Linear는 “팀원이 쓰고 싶은 도구”라는 이 시리즈의 이상에 가장 근접했다. 단, 그 팀원이 개발자이고, 조직이 단순한 워크플로우를 가졌을 때만. 범위를 좁힌 대가로 깊이를 얻은 도구다.
5. 한 줄 평
Linear는 순수 소프트웨어 개발팀에게는 현존 최고의 경험을 주는 도구다. 그러나 비개발 직군이 섞이거나, 간트·포트폴리오 같은 폭넓은 관리가 필요한 순간, 그 아름다운 단순함은 곧 한계로 바뀐다.
짚고 가기: Linear는 중요한 걸 증명했다 — 도구는 팀원이 ‘쓰고 싶어지게’ 만들 수 있다. 설정을 덜어내고 속도를 높이면 사람들은 실제로 도구를 연다. 다만 Linear는 그 답을 ‘개발팀’이라는 좁은 무대에서만 찾았다. 그렇다면 질문은 이렇게 바뀐다 — 개발자가 아닌 모든 팀원도 쓰고 싶어지는 도구는, 과연 어떤 모습일까?
다음 편 예고
Linear가 “덜어냄의 정교한 끝”이라면, 다음 편(09부)의 Trello는 “덜어냄의 가장 단순한 원형”이다. 칸반 보드 하나로 모든 걸 풀어내는, 누구나 5분이면 이해하는 그 도구. 가장 쉬운 도구가 왜 진지한 프로젝트 관리에서는 한계에 부딪히는지 — 단순함의 양 끝을 비교하며 살펴본다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 07. Notion — 만능 워크스페이스는 PMS가 될 수 있는가
다음 글: IT 프로젝트 관리 도구 완전 해부 – 09. Trello — 가장 단순한 칸반의 끝과 한계
