| title | Jira and Linear Are Legacy Software | ||||||
|---|---|---|---|---|---|---|---|
| date | 2026-03-30 | ||||||
| tags |
|
||||||
| aliases |
|
||||||
| description | 이슈 트래킹이 핸드오프 모델을 위해 설계됐으며 AI 에이전트 시대에 더 이상 유효하지 않다는 주장. 코드를 계획의 매체로 삼는 '먼저 만들고 스펙 쓰기' 방식이 왜 더 나은지를 설명한다. | ||||||
| importance | 3 | ||||||
| author | Theo - t3.gg | ||||||
| source | https://youtu.be/pzUn9wTCgcw?si=fPKPmo63hr3dv90I |
Jira와 Linear 같은 전통적인 이슈 트래커는 소프트웨어 개발의 핸드오프 모델을 중심으로 설계됐다. PM이 작업 범위를 잡고, 엔지니어가 나중에 받아서 처리하는 구조였다. 역할 간 간극을 메우기 위해 우선순위 조정, 협상, 워크플로우가 시스템 안에 가득 쌓였다. 이런 의식적인 절차는 진짜 제약 조건에서 비롯됐다. 엔지니어링 시간이 부족했고, 팀은 기능별로 작업을 신중하게 분배할 방법이 필요했다. 그러나 시간이 지나면서 복잡성이 세련됨처럼 보이기 시작했다. 시스템이 더 많은 프로세스를 흡수할수록 더 발전해 보였고, 오버헤드는 계속 늘어났다. 결국 프로세스 자체가 일이 되어버렸다.
Jira가 이 실패 패턴의 가장 명확한 사례다. Twitch에서 Jira 대시보드를 여는 데 2분 이상 걸렸다. 필드, 데이터 링크, 티켓 간 관계가 너무 복잡하게 쌓였기 때문이다. 이런 시스템에서는 제공되는 모든 기능이 결국 한계에 부딪힐 때까지 사용되고 남용된다.
"이슈 트래킹은 핸드오프를 위해 만들어졌다. Linear는 맥락을 실행으로 바꾼다."
Linear는 항상 반대 믿음 위에 세워졌다. 최고의 시스템은 오버헤드를 없애서 팀이 실제 빌딩에 집중하게 해야 한다는 것이다. 그래서 엔지니어들이 Linear를 선호했다. Linear는 엔지니어가 회사에서 중요한 결정을 내린다는 데 베팅한 도구였다. Jira는 PM들이 선택한 도구였고, Linear는 엔지니어들이 원하는 도구였다. 그 베팅은 충분히 성공했다.
AI 에이전트가 등장하기 훨씬 전에도 스펙을 먼저 쓰는 것보다 더 나은 대안이 있었다. 거의 항상 부정확한 20페이지짜리 스펙을 쓰는 대신, 1~3일 안에 작동하는 프로토타입을 먼저 만드는 것이다.
핵심은 빠르게 배포하는 게 아니었다. 작동하는 프로토타입을 만들고, 기술적 미지수를 수면 위로 끌어올리고, 그다음에 훨씬 나은 스펙을 쓰는 것이었다. 먼저 만들면 UX 테스트에 필요한 것들이 자연스럽게 드러나고, 건드려야 할 시스템 범위를 파악하고, 내부 및 사용자 테스트에 바로 쓸 수 있는 데모 가능한 버전을 갖게 된다. 더 놀라운 결과는 이렇다. 약 절반의 경우 그 초기 버전을 조금 다듬어서 그냥 배포했다. 더 나아갈 이유가 없었기 때문이다.
"먼저 버전 하나를 만들고, 그다음에 스펙을 쓰고, 그다음에 제대로 만들어라. 어떻게 작동할지 안다고 가정하고 스펙을 쓰고, 틀린 채로 만들고, 계속 임시방편을 붙이는 방식과는 반대다."
이 접근법이 저항을 받은 이유는 효과가 없어서가 아니었다. 대형 회사의 승진 구조와 프로세스 기계가 배포보다 긴 문서에 보상을 줬기 때문이다. 엔지니어링 문화는 사람들이 명백히 가치 있는 것 외에는 자동화하거나 프로토타입을 만들려는 충동을 억누르도록 훈련시켰다. 코드가 비쌌을 때는 맞는 본능이었다. 이제 그 본능은 짐이 됐다.
Linear 자체 데이터가 이 변화를 구체적으로 보여준다. 코딩 에이전트는 이제 Linear 엔터프라이즈 워크스페이스의 75% 이상에 설치됐다. 사이드 프로젝트가 아닌 실제 엔터프라이즈 계약 기업들이다. 지난 3개월 동안 에이전트가 완료한 작업량은 5배 증가했다. 에이전트가 새 이슈의 약 25%를 직접 생성하기도 했다.
계획, 구현, 코드 리뷰가 하나로 압축되고 있다. 에이전트가 절차적 작업을 흡수하면서다. 프로세스의 기계적인 부분을 관리하는 시간은 줄고, 의도와 판단, 취향에 더 많은 시간을 쓸 수 있게 됐다. PM이 스펙을 쓰고, 엔지니어가 실행하고, 시스템이 핸드오프를 추적하는 옛 모델은 이제 에이전트가 대부분의 절차적 단계를 처리하는 현실을 반영하지 못한다.
Linear가 제안하는 새 모델은 핸드오프가 아닌 맥락 중심의 시스템이다. 피드백, 의도, 결정, 계획, 코드를 모두 담고, 그 맥락을 인간과 에이전트 모두를 위한 실행 가능한 작업으로 변환한다. 이 모델에서 눈에 띄게 사라진 것들이 있다. 이슈, 스프린트 계획, 백로그 정리다. 새로운 구조는 기본적으로 이렇다: 맥락 → 규칙 → 에이전트 → 제품.
개발자들이 자동화를 간과하는 경향이 있다. 이미 코드를 써서 자동화하는 방법을 알고 있고, 그게 얼마나 많은 작업인지도 알기 때문이다. 그래서 명백히 가치 있는 것만 자동화하도록 스스로를 훈련시켜왔다.
비개발자들에게는 그런 정신적 장벽이 없다. 한 번도 자동화를 해본 적 없는 사람들이 갑자기 할 수 있게 됐고, 적극적으로 활용하고 있다. 자동화 도구를 가장 열정적으로 사용하는 사람들은 개발자가 아니라 비개발자들이다. 이는 Linear와 유사 도구들이 출시하는 자동화 기능이 엔지니어들 눈에는 별것 없어 보일지 몰라도, 이런 시스템 안에서 하루를 보내는 PM, 리드, 운영자들에게는 아마 변혁적일 것임을 의미한다.
이 영상의 가장 핵심적인 주장은 구조적이다. PM, 디자이너, 스태프 엔지니어, QA 리드 같은 별도 역할이 존재하는 이유는 한 사람이 이것들 중 하나만 할 수 있었기 때문이다. 전문가는 귀했고, 성장시키기 어려웠다. 그 제약 속에서 일을 쪼개는 방식이 만들어진 것이다.
모델이 CEO, 스태프 엔지니어, 디자이너, 디버거, QA 리드를 동시에 할 수 있을 만큼 똑똑하다면, 우리는 왜 아직도 이 역할들을 정의하고 그 사이의 핸드오프 프로세스를 유지하는가? 인간이 했을 때는 이렇게 일을 쪼개는 게 맞았다. 이제 AI가 대부분을 처리할 수 있다면, 전통적인 역할 분담은 더 이상 의미가 없다.
GitHub가 경고의 사례로 제시된다. 별도의 제품 조직과 엔지니어링 조직이 있고, 공유 리더십이 전혀 없다. 제품 담당자는 코딩을 하지 않고, 엔지니어는 제품 결정을 내리지 않는다. 그 결과물은 발전할 수 없는 제품이다. 인간 조직의 제약 조건에 맞게 설계된 프로세스가 실제 제품 품질을 방해하고 있다.
이 모든 것의 함의는 다단계 계획 프로세스가 쓸모없어지고 있다는 것이다. 계획에 몇 시간이 걸릴 이유도, 전체 컨텍스트 창을 채울 이유도, 모델이 빌드를 시작하기 전에 스펙, 기술 설계 문서, 결정 사항, 요약이 필요할 이유도 없다.
더 나은 접근: 모델이 먼저 빌드를 시작하고, 맥락을 도구로 활용하고, 첫 번째 시도 자체가 계획이 되도록 하는 것이다. 모델이 빌드하면서 관련 코드베이스 부분을 건드리는 과정이 함정이 어디 있는지, 복잡성이 어디에 숨어 있는지, 무엇이 실제로 필요한지를 드러낸다. 그다음, 그리고 그때서야 더 단순하고 더 정보에 입각한 계획을 쓰고 다시 만든다.
"세 번 만들고, 처음 두 번은 버려라."
코드가 비쌌을 때는 이런 방식이 말이 안 됐다. 이제 코드는 싸다. AI 시대에 대한 올바른 대응은 복잡한 계획 프로세스를 재발명하는 것이 아니라, 코드 자체를 탐색의 매체로 삼아 의도와 구현 사이의 거리를 좁히는 것이다.
출처: https://youtu.be/pzUn9wTCgcw?si=fPKPmo63hr3dv90I
2026-04-06
Linear CEO Karri Saarinen은 2026년 3월 24일 "Issue tracking is dead"를 선언하며 제품 철학을 재정의했다. 핵심은 핸드오프 중심 시스템에서 맥락 중심 시스템으로의 전환이다. 새 아키텍처는 네 계층으로 구성된다:
| 계층 | 역할 | 기존에 이걸 누가 했나 |
|---|---|---|
| Context | 로드맵, 피드백, 코드, 스레드를 하나의 워크스페이스에 통합 | PM이 스펙 문서로 정리 |
| Rules | 이슈가 들어오면 자동 분류/라우팅/액션 (Triage Automations) | PM/리드가 수동 트리아지 |
| Agents | 자연어 명령으로 프로젝트/이슈/문서 생성, 피드백 분석 | 엔지니어가 티켓 받아서 실행 |
| Product | 아이디어에서 구현까지 사람+에이전트 협업 | 핸드오프 체인 전체 |
기존 개념의 대체도 구체적이다. 수동 이슈 생성은 Linear Agent가 피드백 분석 후 자동 생성으로, 수동 트리아지는 Automations가 즉시 분류/라우팅으로, 반복 워크플로우는 Skills(성공한 워크플로우를 재사용 가능한 스킬로 코드화)로 대체된다. PM → 엔지니어 핸드오프는 에이전트가 컨텍스트를 직접 읽고 실행하는 구조로 바뀐다.
Saarinen의 핵심 주장: "에이전트는 독심술사가 아니다. 맥락을 통해 유용해진다." 에이전트에게 좋은 티켓을 쓰는 게 아니라, 풍부한 맥락이 담긴 시스템 자체를 제공하면 에이전트가 알아서 실행한다는 것이다.
실제 수치도 이 변화를 뒷받침한다. 엔터프라이즈 워크스페이스 75%에 코딩 에이전트 설치, 3개월 만에 에이전트 작업량 5배 증가, 신규 이슈의 25%가 에이전트 자동 생성이다.
Linear는 Code Intelligence, Code Diffs, Linear Coding Agent까지 출시를 예고하며 코딩 에이전트 시장에 진입하려 한다. 하지만 [[ai-product-strategy-4d-framework|AI 제품 전략 4D 프레임워크]]의 핵심 주장을 적용하면, 코딩 에이전트 자체는 해자가 아니다. 누구나 프론티어 모델에 접근 가능하고, 단순한 API 래퍼는 쉽게 복제 가능하기 때문이다. Cursor, GitHub Copilot, Claude Code 등 코딩 에이전트는 이미 넘쳐나고 있다.
그러나 Linear의 진짜 베팅은 코딩 능력이 아니라 맥락의 밀도다:
| 코딩 에이전트 (복제 가능) | Linear의 진짜 베팅 |
|---|---|
| 코드 작성 능력 | 제품 맥락 -- 로드맵, 피드백, 결정, 코드가 한 곳에 |
| 프론티어 모델 API 래퍼 | 맥락이 쌓일수록 에이전트가 더 똑똑해지는 플라이휠 |
| Cursor/Copilot과 동일 영역 | "이 버그가 어떤 고객 요청에서 왔는지" 아는 유일한 시스템 |
[[ai-saas-per-seat-pricing-dying|AI SaaS: Per-Seat Pricing의 종말]]에서도 같은 결론이 나온다: 살아남는 기업은 UI/UX 중심의 해자를 데이터와 통합으로 옮기는 기업이다. Linear의 방어 가능한 자산은 코딩 에이전트가 아니라, 팀의 모든 제품 결정이 쌓여 있는 System of Record 지위다.
다만 위험도 있다. 4D 프레임워크 노트에서 Chegg, Jasper, Duolingo가 AI 통합 방식의 실패로 큰 타격을 입었다고 했듯, 코딩 에이전트에 집중하다 핵심 제품의 품질이 떨어질 수 있다.
Linear의 "맥락 → 규칙 → 에이전트 → 제품" 파이프라인은 nexus vault의 구조와 놀라울 정도로 겹친다:
| Linear의 비전 | nexus 현재 구조 |
|---|---|
| Context (로드맵, 피드백, 결정) | vault 노트들 (PARA 구조) |
| Rules (자동화, 트리아지) | .claude/rules/ |
| Agents (Skills, Linear Agent) | .claude/skills/ |
| Product (실행 결과물) | 코드, 문서, 콘텐츠 산출물 |
에이전트 중심 세상을 가정하면, 마크다운 파일 집합이 더 나은 접근일 수 있다. 첫째, 에이전트 접근성 -- 마크다운은 에이전트가 가장 잘 읽고 쓸 수 있는 포맷이다. 별도 API 없이 파일 시스템에서 직접 읽고, 검색하고, 편집할 수 있다. Linear는 독점 데이터베이스이므로 API나 MCP를 거쳐야 한다. 둘째, 벤더 종속 없음 -- 마크다운은 50년이 지나도 읽을 수 있고 어떤 에이전트든 처리 가능하다. 셋째, 규칙과 스킬의 코드화 -- git으로 버전 관리되므로 왜, 언제 바뀌었는지 추적 가능하다.
다만 팀 규모가 커지면 약점이 드러난다. 실시간 동시 편집이 어렵고(git conflict), 비개발자가 git 워크플로우를 배워야 하며, 권한 관리가 제한적이다. 1인 또는 소규모 팀에서는 마크다운 + git이 최적이지만, 팀 확장에는 별도 협업 레이어가 필요하다.
개발자는 자동화의 비용을 정확히 계산할 수 있기 때문에, 오히려 명백히 가치 있는 것만 자동화하도록 스스로를 훈련시켜왔다. "이거 자동화하면 3시간인데 수동은 5분이니까" 같은 ROI 계산을 무의식적으로 한다.
| 개발자 | 비개발자 | |
|---|---|---|
| 자동화 경험 | "예전에 해봤는데 이만큼 걸렸어" | "처음이라 비용 감각이 없음" |
| AI 도구를 보면 | "이거 내가 스크립트로 짜면 되는데" | "세상에, 이게 가능해?" |
| 비교 기준 | 직접 코딩 | 수동 반복 작업 |
비개발자에게는 비교 기준이 "직접 코딩"이 아니라 "수동 반복 작업"이다. 매일 티켓을 분류하고 스프레드시트를 정리하던 PM에게 "이걸 자동으로 해줄게"라고 하면 그건 진짜 변혁적이다. Theo의 핵심 포인트는, 엔지니어 눈에 별것 없어 보이는 자동화 기능이 PM과 리드에게는 하루의 상당 부분을 돌려주는 도구라는 것이다.
GitHub은 제품 조직과 엔지니어링 조직이 완전히 분리돼 있고, 공유 리더십이 없다. PM이 "이걸 만들어주세요"라고 스펙을 넘기면, 엔지니어가 "기술적으로 안 됩니다"라고 돌려보내고, 협상을 거쳐 원래 의도가 희석된 타협안이 나온다.
더 깊은 문제는 "내 영역 아닌 건 판단하지 않는다"는 문화다. 엔지니어가 구현 중 "이렇게 바꾸면 10배 좋아지는데"라고 생각해도 제품 결정 권한이 없고, PM은 코드를 모르니 기술이 열어주는 새로운 가능성을 상상조차 못한다. 그 결과 Copilot, Actions, Projects, Codespaces 각각은 잘 작동하지만, 전체가 하나의 비전으로 엮이지 않는다.
반대 사례가 Linear다. "엔지니어가 회사에서 중요한 결정을 내린다"에 베팅한 도구였고, 코딩을 할 줄 아는 사람이 제품 감각도 가지면 핸드오프 없이 의도에서 구현까지 한 사람 안에서 일어난다.
스펙을 먼저 쓰는 것보다 먼저 만들고 스펙을 쓰는 것이 더 나은 계획을 만든다. 코드베이스는 문서로 설명할 수 없는 정보를 품고 있기 때문이다 -- 엣지 케이스, 영향 범위, 기존 시스템과의 충돌은 실제로 건드려봐야 드러난다.
비유하면 집 리모델링과 같다. 도면을 완벽히 그려도 벽을 뜯으면 예상 못한 배관이 나온다. 차라리 벽을 먼저 뜯어 배관을 확인하고, 그 위에 도면을 그리는 게 낫다. "세 번 만들고 처음 두 번은 버려라"는 말이 이 맥락이다 -- 처음 두 번은 제품이 아니라 탐사다.
코드가 비쌌을 때는 탐사 비용이 너무 높았지만, AI 에이전트가 코드를 빠르고 싸게 만들어주는 지금은 탐사가 가장 효율적인 계획 방법이 됐다.
이슈 트래킹이 죽는 이유는 AI가 코드를 짜서가 아니라, 핸드오프라는 전제 자체가 무너지고 있기 때문이다. 에이전트 시대의 핵심 자산은 코딩 능력이 아니라 맥락의 밀도다 -- 풍부한 맥락이 담긴 시스템을 가진 쪽이 가장 좋은 에이전트를 갖게 된다.
- [[issue-tracking-is-dead|Issue Tracking Is Dead]]: Linear CEO Karri Saarinen의 선언문. 맥락 → 규칙 → 에이전트 → 제품 파이프라인의 원문
- [[ai-product-strategy-4d-framework|AI 제품 전략 4D 프레임워크]]: AI 해자 분석. "AI 자체는 해자가 아니다"
- [[ai-saas-per-seat-pricing-dying|AI SaaS: Per-Seat Pricing의 종말]]: 좌석당 과금 모델 붕괴와 에이전트 시대 SaaS 생존 전략