46%라는 숫자보다 무서운 건 그 옆에 있는 숫자야
Linear이 8월 21일 자사 제품에서 뽑은 사용 데이터를 공개했어. 헤드라인 숫자는 이거야. 2024년 6월에는 Linear에서 만들어지는 이슈 중 AI가 쓴 게 0.2%도 안 됐어. 2026년 8월 지금은 약 46%야.
주간 절대량으로 보면 더 선명해. 에이전트가 만드는 이슈가 주당 243만 5천 건, 사람과 연동 시스템이 만드는 게 246만 8천 건. 사실상 동률이고, 추세대로면 곧 뒤집혀.
여기까지는 예상 가능한 이야기야. AI가 일을 대신 한다, 익숙하지.
문제는 그 옆에 붙은 숫자야. 2025년 6월부터 2026년 6월까지, 사람이 이슈를 만들고 분류하고 코멘트하는 데 쓴 시간이 거의 모든 직무에서 늘었어. 엔지니어링은 생성·분류 항목만 놓고 봐도 약 17% 증가했어. 창업자 직군은 변동 폭이 더 컸고.
AI가 이슈의 절반을 쓰는데 사람의 이슈 작업 시간은 늘었다. 이 두 문장이 동시에 참이야. Linear이 이걸 설명하는 표현이 정확해 — AI는 기존 일을 줄인 게 아니라 새로운 층을 하나 더 깔았어.
등장인물 정리 — Linear과 '이슈 트래킹은 죽었다'는 선언
Linear은 이슈 트래커야. 지라(Jira)의 무겁고 느린 경험에 질린 스타트업들이 대거 옮겨가면서 성장한 제품이지. 속도와 절제된 디자인이 브랜드고, 개발자 커뮤니티에서 유독 애정을 받는 도구야.
이 회사가 2026년 3월 24일 Linear Agent를 내놨어. 이슈에 에이전트를 배정하고, 코멘트 스레드에서 에이전트를 멘션하고, 반복 작업을 자연어로 설명해두면 일정이나 이벤트에 따라 에이전트가 알아서 돌리는 기능이야. 워크스페이스 전체 맥락을 읽고 움직여.
발표 당시 화제가 된 건 기능보다 CEO의 발언이었어. **"이슈 트래킹은 죽었다"**고 했거든. 이슈 트래커 회사의 CEO가 할 말치고는 과감하지. 레지스터와 데브클래스가 그 발언을 제목으로 뽑았을 정도야.
이번 데이터 공개는 그 선언에 대한 5개월 뒤의 증거 제출이야. 그리고 자사 제품의 사용 데이터라는 점에서 강점과 약점이 동시에 있어. 강점은 설문이 아니라 실제 행동 로그라는 것. 사람들이 "AI를 얼마나 쓰나요"라는 질문에 답한 게 아니라, 시스템이 기록한 이벤트야. 약점은 표본이 Linear 사용자라는 것 — 즉 애초에 도구 도입에 적극적인 조직들에 치우쳐 있어.
표본 규모는 밝혀뒀어. 회사 규모가 확인된 유료 사용자 19만 9천 명, 그중 2026년 1월과 6월에 모두 활성이었던 사람들 기준이야. 코호트를 고정해서 같은 사람들의 변화를 본 거니까, 신규 유입 때문에 비율이 움직이는 착시는 걸러낸 설계야.
직무별로 뜯어보면 — 가장 크게 뛴 건 엔지니어가 아니야
2026년 1월에서 6월 사이 AI 도입률 변화가 이래.
| 직무 | 2026년 1월 | 2026년 6월 | 증가폭 |
|---|---|---|---|
| 프로덕트 | 12% | 34% | +22%p |
| 엔지니어링 | 12% | 30% | +18%p |
| 창업자 | 14% | 30% | +16%p |
| 디자인 | 6% | 22% | +16%p |
| GTM(영업·마케팅) | 5% | 18% | +13%p |
엔지니어링이 1위가 아니야. 프로덕트 직군이 +22%p로 가장 크게 뛰었어. 반년 만에 12%에서 34%로, 거의 세 배야.
이게 왜 의미가 있냐면, AI 코딩 도구의 서사는 지금까지 개발자 중심이었거든. "개발자가 코드를 더 빨리 짠다"가 이야기의 전부였어. 그런데 실제 데이터는 개발자 인접 직군이 더 빠르게 들어오고 있다고 말하고 있어. 디자인이 6%에서 22%로 거의 4배, GTM도 5%에서 18%로 3배 넘게 늘었어.
경영진 쪽은 더 극적이야.
| 직책 (직원 201명 이상 조직) | 2026년 1월 | 2026년 6월 | 증가폭 |
|---|---|---|---|
| CEO | 9% | 36% | +27%p |
| CTO | 11% | 35% | +24%p |
CEO의 증가폭이 CTO보다 커. 그리고 6월 시점에서 CEO의 도입률(36%)이 CTO(35%)를 앞질렀어. 큰 조직의 CEO가 이슈 트래커 안에서 AI를 쓰고 있다는 건 몇 년 전이라면 상상하기 어려운 그림이야. 이슈 트래커는 실무자의 도구였으니까.
이 역전에는 그럴듯한 설명이 있어. 코딩 도구는 배우는 비용이 있어. 엔지니어는 이미 자기 워크플로우가 정교하게 최적화돼 있어서 새 도구를 끼워 넣는 마찰이 오히려 커. 반면 프로덕트나 디자인 직군은 원래 "코드에 손댈 수 없다"는 벽에 막혀 있던 사람들이야. 그 벽이 낮아졌을 때 얻는 이득이 훨씬 크지. 도입률 증가폭이 큰 곳은 대체로 원래 못 하던 걸 하게 된 쪽이야.
CEO 쪽 숫자도 같은 논리로 읽을 수 있어. 큰 조직의 CEO가 이슈 트래커에 들어와 뭘 하려면 예전에는 누군가에게 물어봐야 했어. 대화형 인터페이스가 그 중간 단계를 없앤 거지. 다만 여기엔 다른 해석도 가능해 — 경영진의 도입률은 실제 업무 사용보다 '탐색'이 섞이기 쉬워. 반년 뒤에도 36%가 유지되는지가 진짜 지표야.
진짜 이상한 지표 — PR을 쓰는 사람이 바뀌었어
출력 쪽 지표는 더 흥미로워. 2년간 풀 리퀘스트 수가 111% 늘었어. 두 배가 넘어.
그런데 누가 PR을 만드는지가 바뀌었어.
| 직무 | PR을 만든 사람 비율 (2년 전 → 현재) |
|---|---|
| 프로덕트 매니저 | 3% → 10% |
| 디자이너 | 1% → 8% |
디자이너의 8배야. 절대 수치는 여전히 작지만 방향이 분명해. 코드를 제출하는 행위가 엔지니어의 전유물에서 벗어나고 있어.
그리고 팀 단위 비교가 이 데이터의 하이라이트야.
| 팀 유형 | 주당 PR 수 (2년 전 → 현재) |
|---|---|
| 코딩 에이전트를 쓰는 팀 | 21 → 65 |
| 안 쓰는 팀 | 8 → 10 |
에이전트를 쓰는 팀은 주당 21건에서 65건으로 3배 넘게 늘었고, 안 쓰는 팀은 8건에서 10건으로 거의 제자리야. 두 그룹의 격차가 2.6배에서 6.5배로 벌어졌어.
이 표를 읽을 때 조심할 게 하나 있어. 인과가 어느 방향인지 이 데이터만으로는 알 수 없어. 에이전트를 써서 PR이 늘어난 걸 수도 있고, 원래 PR을 많이 뽑던 빠른 팀이 에이전트를 먼저 도입한 걸 수도 있어. 아마 둘 다일 거야. 그리고 PR 수는 산출량이지 가치가 아니야. PR 65개가 PR 21개보다 3배 좋은 소프트웨어를 뜻하지는 않아.
각자의 이득 — 그런데 일이 왜 늘었을까
이 리포트에서 가장 깊이 볼 대목은 헤드라인이 아니라 일이 줄지 않았다는 발견이야.
Linear의 설명은 이래. AI와 대화하는 것, 에이전트에게 이슈를 위임하는 것 — 이 두 가지는 1년 전에는 존재하지 않던 작업 범주야. 그런데 지금은 모든 직무의 한 주 안에 나타나. 기존 업무가 사라진 자리에 들어온 게 아니라, 위에 얹혔어.
생각해보면 당연한 구조야. 에이전트가 이슈를 46% 만든다는 건 누군가 그 이슈들을 읽고, 우선순위를 매기고, 맞는지 확인하고, 방향을 잡아줘야 한다는 뜻이거든. 생성이 자동화되면 검토가 병목이 돼. 그리고 검토는 사람이 해.
그래서 Linear이 "모든 구성원이 빌더가 되고 있다"고 표현한 게 절반만 낙관적인 말이야. 나머지 절반은 모든 구성원이 리뷰어가 되고 있다는 뜻이지. 그리고 리뷰는 만드는 것보다 재미없는 일인 경우가 많아.
Linear이 이 데이터에서 가져가는 건 명확해. "이슈 트래킹은 죽었다"는 CEO의 발언이 제품 전략의 근거를 얻었어. 이슈 트래커의 역할이 사람의 작업 목록에서 에이전트 작업의 배정·검토·통제 공간으로 옮겨가고 있다는 서사지. 그 서사가 맞다면 Linear은 지라와 경쟁하는 회사가 아니라 새 카테고리를 정의하는 회사가 돼.
또 하나 조심할 게 있어. 이슈의 46%를 AI가 쓴다는 건 '작성 주체'의 비율이지 '중요도'의 비율이 아니야. 에이전트가 자동으로 만드는 이슈는 대체로 작고 반복적인 것들 — 로그에서 발견한 이상, 테스트 실패, 의존성 업데이트 같은 항목이 많아. 제품 방향을 정하는 큰 결정이 담긴 이슈는 여전히 사람이 쓸 가능성이 높지. 숫자만 보고 "의사결정의 절반을 AI가 한다"고 읽으면 과장이야. 리포트에도 이슈를 중요도별로 나눈 수치는 없었어.
과거 유사 사례 — 자동화가 일을 줄인 적이 있었나
이 패턴은 처음이 아니야. 이메일이 대표적이지. 이메일은 편지와 팩스와 사내 우편을 대체하면서 통신 비용을 극적으로 낮췄어. 그 결과 커뮤니케이션에 쓰는 시간이 줄었을까? 정반대였어. 비용이 낮아지니까 양이 폭증했고, 사람들은 예전보다 훨씬 많은 시간을 메시지 처리에 쓰게 됐어.
컴파일러와 고급 언어도 비슷해. 어셈블리를 직접 쓰던 시절보다 코드 한 줄의 비용이 극적으로 낮아졌지. 프로그래머가 한가해졌나? 아니, 소프트웨어의 규모와 복잡도가 그만큼 커졌어. 경제학에서 제번스 역설이라고 부르는 구조가 여기서도 반복돼 — 효율이 올라가면 소비가 늘어.
반대 사례가 없는 건 아니야. 자동화가 실제로 특정 직무를 소멸시킨 경우도 많아. 전화 교환수, 조판공, 은행 창구의 상당 부분. 다만 그 경우들의 공통점은 작업이 완전히 표준화돼 검토가 필요 없었다는 거야. 지금 AI가 만드는 이슈와 PR은 아직 그 단계가 아니야. 검토가 필요한 한 사람의 일은 형태만 바뀌지 사라지지 않아.
그래서 지금 데이터가 보여주는 건 "AI가 일을 뺏는다"도 "AI가 일을 줄여준다"도 아니야. 일의 성격이 생산에서 감독으로 이동하고 있다는 거지.
검토 부하가 어디로 가는지도 생각해볼 만해. 이슈를 만드는 건 에이전트지만 그걸 닫는 판단은 사람이 해. 그런데 조직에서 리뷰 역량은 균등하게 분포하지 않아. 맥락을 많이 아는 시니어에게 몰리지. 생성량이 3배가 되면 그 몰림도 3배가 돼. Linear 데이터에서 엔지니어링의 생성·분류 시간이 17% 늘어난 건 그 압력의 초기 신호로 볼 수 있어. 팀 차원에서 리뷰를 분산시킬 장치 — 자동 분류 규칙, 신뢰도 기반 자동 승인, 에이전트 출력의 품질 게이트 — 를 안 만들면 이 부하는 조용히 몇 사람에게 쌓여.
경쟁자 카운터 플레이
아틀라시안(지라)은 훨씬 큰 설치 기반을 갖고 있고, 대기업 시장에서 여전히 지배적이야. 하지만 이 데이터가 그리는 방향 — 에이전트가 작업 항목을 만들고 사람이 검토하는 구조 — 은 대기업 워크플로우와 궁합이 미묘해. 승인 단계와 감사 추적이 많은 조직일수록 자동 생성된 항목이 늘어날 때 병목이 심해지거든. 아틀라시안이 이 문제를 거버넌스 기능으로 풀면 오히려 강점이 될 수도 있어.
깃허브와 깃랩은 다른 각도에서 들어와. 이슈와 PR을 이미 갖고 있고, 코드와 같은 자리에 있다는 게 구조적 이점이야. 에이전트 작업의 시작과 끝이 결국 저장소에서 일어나니까, 별도 트래커를 거칠 필요가 있느냐는 질문이 계속 나올 거야.
노션이나 에어테이블 같은 범용 워크스페이스 도구도 변수야. "모든 직무가 빌더가 된다"는 방향이 맞다면 엔지니어 전용 도구의 경계가 흐려지고, 범용 도구가 그 자리를 노릴 유인이 생겨.
그리고 가장 큰 변수는 모델 회사들이야. 앤트로픽과 오픈AI 모두 코딩 에이전트를 자사 제품으로 직접 밀고 있어. 에이전트가 작업 관리까지 하기 시작하면 트래커 레이어가 얇아질 수 있어. Linear이 지금 데이터를 공개하며 자리를 선점하려는 이유가 아마 거기 있을 거야.
그래서 뭐가 달라지는데
엔지니어링 리더라면 — 팀 생산성 지표를 다시 볼 때야. 지금 쓰는 대시보드가 산출량만 세고 있다면 AI 도입 이후의 팀을 평가할 수 없어. PR 수와 이슈 처리량이 AI 도입으로 부풀려지는 구간에 들어섰어. 주당 65 PR과 21 PR의 차이가 실제 성과 차이인지, 아니면 잘게 쪼개진 커밋의 차이인지 구분할 지표가 필요해.
프로덕트 매니저라면 — 같은 직군에서 PR을 제출하는 비율이 3%에서 10%로 늘었어. 코드를 직접 건드리는 PM이 예외가 아니라 소수 표준이 되어가는 중이야.
팀에 에이전트를 도입 중이라면 — 이 데이터의 경고를 새겨. 생성이 늘면 검토 부하가 따라 늘어. 리뷰 용량을 같이 늘리지 않으면 병목이 사람 쪽으로 옮겨올 뿐이야.
조직 데이터를 보는 입장이라면 — 표본이 Linear 유료 사용자라는 편향을 감안해야 해. 도구 도입에 적극적인 조직들의 숫자니까, 산업 평균보다 앞서 있다고 보는 게 맞아.
그냥 개발자라면 — 당장 뭘 바꿀 필요는 없어. 다만 "코드를 쓰는 사람"이라는 정체성이 "에이전트가 쓴 코드를 판단하는 사람"으로 이동하는 중이라는 건 알아둘 만해. 그리고 그 판단 능력은 코드를 직접 많이 써봐야 생긴다는 점에서, 이 이행기는 신입 개발자에게 특히 까다로운 구간이야.
채용을 하는 입장이라면 — 디자이너의 8%, PM의 10%가 PR을 낸다는 건 직무 경계가 흐려지고 있다는 뜻이야. 직무기술서를 예전 경계 그대로 두면 실제 팀에서 벌어지는 일과 어긋나기 시작해.
🥄 남은 궁금증 세 가지
— AI가 이슈의 46%를 쓰면 사람 일자리는 어떻게 되는 거야? 이 데이터만 놓고 보면 줄지 않았어. 오히려 이슈를 만들고 분류하는 데 쓰는 시간이 늘었어. 생성이 자동화되면서 검토가 새로운 병목이 된 구조야. 다만 이건 지금 시점의 스냅숏이고, 검토까지 자동화되면 이야기가 달라질 수 있어. 단정하긴 일러.
— 에이전트 쓰는 팀이 주당 65 PR이면 6배 생산적인 거야? 그렇게 읽으면 안 돼. PR 수는 산출량 지표지 가치 지표가 아니야. 에이전트가 작업을 잘게 쪼개면 같은 일도 PR 개수가 늘어. 그리고 인과 방향도 불분명해 — 원래 빠르던 팀이 에이전트를 먼저 도입했을 가능성이 커.
— 이 숫자를 우리 회사에 그대로 적용해도 돼? 편향을 감안해야 해. 표본이 Linear 유료 사용자라 도구 도입에 적극적인 조직 쪽으로 기울어 있어. 방향성은 참고할 만하지만 절대 수치를 자기 조직의 기준선으로 삼는 건 위험해.
참고 자료
- Linear — AI usage patterns in software teams (2026-08-21, 공식 데이터 리포트 원문)
- Linear Changelog — Introducing Linear Agent (2026-03-24, 공식 체인지로그)
- Linear Docs — AI Agents in Linear (에이전트 배정·멘션 공식 문서)
- Linear Developers — Getting Started with Agents (에이전트 개발 공식 가이드)
- The Register — Linear adopts agentic AI as CEO declares issue tracking dead (2026-03-26)
- DevClass — Linear moves sideways to agentic AI as CEO declares issue tracking dead (2026-03-27)
수치는 발표 시점 기준이라 바뀔 수 있어.



