Linear의 '제로 버그 정책', '퀄리티 수요일'을 우리 팀에 이식하는 설계 — AI 버그 자동 수정 10%를 넘어선 것

TL;DR

• Linear는 2026년 기준으로 버그의 10%를 AI가 자동으로 수정하고 있습니다 (영상 속 발언 기반). 하지만 이는 품질 전략의 일부일 뿐이며, 나머지 90%는 인간의 판단이 설계의 핵심에 놓여 있습니다.
• **제로 버그 정책(Zero Bug Policy)**이란 '버그를 백로그에 쌓지 않는다'는 운영 방침입니다. 도입 시 3주간 신규 기능 개발을 완전히 중단하여 버그를 제로화하며, 현재는 통상적으로 2~3시간 이내, 최대 7일 이내에 수정 완료를 목표로 합니다 (영상 속 발언 기반).
• **퀄리티 수요일(Quality Wednesday)**은 매주 30분 동안 모든 엔지니어가 스스로 발견하고 수정한 품질 개선 사항을 1건씩 데모하는 정례 회의입니다. 시작 이후 2,500~3,000건에 달하는 세부적인 품질 문제가 수정되었다고 합니다 (영상 속 발언 기반).
• AI가 효과적인 영역은 '설계 사상을 필요로 하지 않는 태스크(버그 수정 등)'이며, UX의 좋고 나쁨을 판단하는 Taste는 인간만이 할 수 있는 역할이라는 역할 분담이 전제됩니다.
• 품질 저하가 AB 테스트에는 반영되지 않고 사용자의 느린 이탈로 나타날 수 있습니다. 이를 방지하기 위해서는 관측 가능성 설계(Observability Design)와 SLA 명시가 필요합니다.
• 자팀으로의 이식 우선순위는 '① 버그 SLA 설정 → ② 주간 품질 데모 시간 확보 → ③ AI 투입 태스크 라벨 정의' 순서가 현실적입니다.

대상 독자와 전제 조건

대상:

• GitHub Copilot / Cursor 등을 일상적으로 사용하며, 팀에 품질 프랙티스를 도입하거나 버그 관리 플로우 개선을 고려하는 시니어 엔지니어, 테크 리드, EM, SRE.
• 'AI로 버그를 자동 수정하는 플로우'의 구체적인 구현 이미지를 갖고 싶거나, 현재의 버그 트리아지(triage)를 재검토하고 싶은 사람.

전제 조건:

• CI/CD 파이프라인에 대한 기본적인 지식 (Job 설계, PR 체크, 배포 플로우).
• 버그 트래커(GitHub Issues / Linear / Jira 등)를 사용한 버그 관리 경험.
• 팀 규모는 무관하나, 컨텍스트는 '소수~수십 명 규모의 제품 개발팀'을 가정합니다.

다루지 않을 내용:

• Linear라는 제품(이슈 트래킹 SaaS) 자체의 사용법 및 도입 절차.
• Tuomas Artman 씨의 개인 경력이나 Linear 사의 사업 전략.
• '어떤 AI 코딩 툴이 좋은가'에 대한 비교 평가.
• Linear 사의 내부 구현 상세 (영상에서 공개되지 않은 정보는 포함하지 않습니다).

배경: AI가 비용 장벽을 없앤 후의 '의사결정 게이트' 문제

AI 에이전트에 의한 개발 자동화가 실무 수준에 도달한 2026년, 엔지니어링 팀은 새로운 종류의 문제에 직면하고 있습니다.

Linear CTO인 Tuomas Artman은 다음과 같이 말합니다 (영상 요약본에서, [00:54]).

"기능 요청이 들어오면 지금 바로 구현할 수 있는 위치에 있다는 것이 문제입니다."

과거에는 엔지니어링 비용 자체가 '정말로 만들어야 하는가'를 되묻는 자연스러운 게이트(gate) 역할을 했습니다. 설계, 구현, 테스트, 리뷰에 며칠이 걸리기 때문에 '이것을 정말 우선순위에 두어야 할까?'라는 검토 과정이 생길 여지가 있었습니다. AI 에이전트는 그 게이트를 제거했습니다.

이 변화가 품질에 미치는 영향은 두 가지 측면입니다.

• 속도층(Speed Layer): 기능이 추가되는 속도가 빨라집니다. 결과적으로 UI의 복잡성이 증가하고, 세부적인 품질 문제가 쌓이기 쉬워집니다.
• 판단층(Judgment Layer): '무엇을 만들 것인가'라는 의사결정 부하가 상대적으로 상승합니다. 구현 비용만으로는 필터링할 수 없기 때문에 다른 판단 축이 필요해집니다.

Linear의 품질 설계는 이 두 가지 층위 모두에 구체적인 제도로 대응한 사례로서 읽을 가치가 있습니다. 본 기사에서는 영상에서 언급된 프랙티스를 '우리 팀에 이식 가능한가'라는 관점에서 해부합니다.

주: 본 기사의 인용 및 수치는 모두 YouTube 동영상 리터러처 노트(AI 생성 요약)를 거친 2차 정보에 기반합니다. 발언의 구어적 정확성은 보장되지 않습니다. 각 타임스탬프의 영상을 직접 참조하시기 바랍니다.

전체 아키텍처: Linear의 품질 설계 3 레이어

Linear의 품질 프랙티스는 독립된 도구가 아니라, 3가지 레이어가 상호 보완하는 설계가 되어 있습니다.

이 3개 레이어는 '버그를 쌓지 않는다(L1) → 세부 문제를 지속적으로 발견한다(L2) → 기계적인 수정을 AI에 맡겨 인간의 여력을 확보한다(L3)'라는 순환을 형성하고 있습니다.

구현 / 주요 단계

단계 1: 제로 버그 정책 설계 — 버그 SLA와 도입 스프린트 계획

기본 방침

제로 버그 정책의 핵심은 '버그를 백로그에 쌓지 않는다'는 운영 규율입니다. Linear의 설계에서는 다음과 같은 SLA가 설정되어 있습니다 (영상 속 발언 기반, [16:31]~[18:20]).

버그 분류	수정 기한
일반 버그	2~3시간 이내
최대 허용	7일 이내

이 SLA가 기능하기 위한 전제 조건으로 Artman은 다음과 같이 말합니다 (영상 요약본에서, [18:20]).

"버그를 수정하는 비율이 일정하다면 필요한 것은 단 하나입니다. 신규 기능 개발을 멈추고, 버그를 제로화할 때까지 계속 수정하는 것. 그 후에는 버그를 쌓지 않는 규칙만 지키면 됩니다."

도입 시 버그 제로화 스프린트 설계 패턴

Linear는 도입 시 3주간 신규 기능 개발을 완전히 중단하여 버그를 제로화했습니다 (영상 속 발언 기반). 이 판단의 논리는 다음 등식에 근거합니다.

버그 수정 총 비용 = 지금 할 경우에도 나중에 할 경우에도 변함없음
∴ 미루는 만큼 '쌓인 버그 관리 비용'이 추가됨
∴ 지금 제로화하는 것이 장기적으로 더 낮다

자팀 적용을 검토할 때의 판단 체크리스트는 다음과 같습니다.