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