• 실수는 “주의”가 아니라 “시스템(仕組み)”으로 줄인다. 빠른 팀은 주의 깊은 사람이 아니라, 확인과 학습의 루프를 설계하고 있다

AI 리뷰 ＋ CODEOWNERS = 더블 체크 3원칙 (보는 사람·보는 방식·외관을 바꾼다) - 실수는 “주의하겠습니다”라고 하기 전에
**4가지 분류 (주의 부족／전달 불량／계획 불량／학습 부족)**로 원인을 특정한다 - 회고(Retrospective)의 개선은 개인의 노력으로 돌리지 않고,
PR 규칙・CI・템플릿으로 승격시킨다 - 결과적으로 팀의
Velocity가 약 75SP → 약 150SP(약 2배)로 향상되었다 (상세 내용과 주의점은 후술)

실수가 발생했을 때, 회고가 “앞으로 주의하겠습니다”로 끝나버린 경험은 없으신가요?

“주의한다”, “조심한다”는 언뜻 타당한 대책처럼 보이지만, 사실은 개인의 주의력에 의존한 대책입니다. 사람은 반드시 지치고, 잊어버리고, 놓칩니다. 그렇기 때문에 빠르고 안정적인 팀은 “주의 깊은 사람”에게 의존하는 것이 아니라, 이중 확인과 학습의 루프를 시스템으로서 설계하고 있습니다.

본 기사에서는 실패학(Failure Studies)의 사고방식(이노 켄지 씨의 저서에서 다뤄지는 “더블 체크 3원칙”, “실수의 4가지 분류” 등)을, 필자 자신이 Scrum 팀에서 실천하고 있는 **AI 리뷰・CODEOWNERS・Retrospective(회고)**와 결합하여 정리합니다.

필자는 Scrum Master이며, 사내 AI 활용 추진 팀의 일원이기도 합니다. 개인의 반성을 “팀의 프로세스 개선”으로 승격시킨다는 관점에서 작성하고 있습니다.

• 팀의 실수와 재작업(rework)을 줄이고 싶은 엔지니어 / Tech Lead / EM

• Scrum Master, Agile Coach

• 코드 리뷰나 CI에 “AI 활용”을 도입하고 싶은 분

• “회고가 형식적으로 흐르고 있다”고 느끼는 분

• “주의한다”가 아닌 “시스템으로 방지한다”로의 발상 전환

더블 체크 3원칙을 AI 리뷰 × CODEOWNERS에 어떻게 대응시킬 것인가 -
실수의 4가지 분류를 사용한 Retrospective 진행 방법 - 회고에서 나온 개선안을 “그 자리에서만” 끝내지 않고, PR 규칙이나 CI로 승격시키는 방법

• GitHub에서 Pull Request(이하 PR) 기반의 개발을 하고 있다
• Scrum(또는 그와 유사한 반복형 개발)을 운영하고 있다
• AI 코드 리뷰 도구(GitHub Copilot의 리뷰 기능, CodeRabbit, 자체 제작 Bot 등)를 사용할 수 있다

용어 보충

CODEOWNERS: GitHub에서 “이 디렉토리/파일의 변경은 지정된 사용자/팀의 리뷰 승인을 필수로 한다”는 설정 파일. Retrospective(레트로): Scrum에서 Sprint(개발 반복 단위)의 마지막에 수행하는 회고 모임. 실패학(Failure Studies): 실패를 숨기지 않고 분석하여 재발 방지 지식으로 활용하는 학문 영역.

실수는 “기합”이 아니라 “설계”로 줄입니다. 본 기사의 주장은 다음 세 가지입니다.

확인은 “조건을 바꾸어” 이중으로 한다 —— AI 리뷰(보는 방식·외관을 바꾼다) ＋ CODEOWNERS(보는 사람을 바꾼다) -
실수는 분류한 뒤에 대책을 세운다 —— “주의 부족／전달 불량／계획 불량／학습 부족” 중 하나를 특정한다 -
개선은 그 자리에서 끝내지 않고 시스템으로 승격시킨다 —— Retrospective의 액션을 PR 규칙・CI・템플릿으로 구현한다

“더블 체크해 둬”라는 말을 듣고, 똑같은 자료를 똑같은 순서로 다시 읽는 것 —— 이것은 별로 효과가 없습니다.

첫 번째 사람이 놓치기 쉬운 부분은, 두 번째 사람도 같은 절차라면 똑같이 놓치기 때문입니다. 더블 체크의 본질은 “같은 확인을 두 번 하는 것”이 아니라, 확인의 “조건”을 바꾸는 것에 있습니다.

예를 들어 Excel로의 전기(transcription) 작업에서는 다음과 같이 역할을 교체합니다.

【입력 시】
A가 원고를 낭독한다 → B가 입력한다
【더블 체크 시】
...

이 삼원칙은 그대로 **PR의 이중 구조(AI 리뷰 ＋ CODEOWNERS)**에 대응됩니다.

Before / After로 비교해 보면, 확인의 "관점"과 "담당"이 분리되어 있는 것이 포인트입니다.

Before는 "같은 diff를 비슷한 순서로 읽기" 때문에 놓치는 부분이 중복됩니다. After는 AI와 인간이 **보는 방식(view), 보이는 모습(appearance), 보는 사람(viewer)**이 모두 달라지기 때문에, 놓치는 부분의 중복이 줄어듭니다.

• PR은 반드시 AI 리뷰를 통과하도록 설정한다 (예: main 대상 PR에서는 필수 체크로 설정)
• CODEOWNERS의 승인을 필수로 하여, "반드시 이 영역의 사람이 본다"는 것을 보장한다
• AI가 잡아내지만 인간이 놓치기 쉬운 사례(예: 예외 처리 누락, 경계값, 기밀 정보의 하드코딩)를 팀 내에서 하나씩 공유하면 도입에 대한 납득도가 높아집니다.

주의: AI 리뷰는 "최소한의 품질 기준"을 기계적으로 확보하는 역할입니다. 설계 의도나 도메인 타당성 판단은 인간(CODEOWNERS)의 몫으로 남겨두는 역할 분담을 명문화해 두어야 형해화되지 않습니다.

실수가 발생했을 때 "주의하겠습니다"로 끝나면, 원인이 특정되지 않은 상태이므로 같은 실수가 재발합니다. 실패학(Failure Studies)에서는 업무상의 실수를 우선 다음 4가지로 분류하고, 분류에 따라 대책의 방향을 바꿀 것을 권장합니다.

포인트는, 같은 "테스트 누락"이라도 분류가 다르면 대책이 다르다는 점입니다.

• 단순 확인 누락 → ①주의 부족 → 체크리스트 / CI
• 사양 인식 차이로 테스트 관점이 빠짐 → ②전달 불량 → 사양 작성 방식·수락 조건(Acceptance Criteria) 재검토
• 애초에 테스트 시간을 견적에 포함하지 않음 → ③계획 불량 → 견적 프로세스 개선

스크럼(Scrum)의 회고(Retrospective)는 이 4가지 분류를 활용하기에 최적의 장소입니다. "잘 되지 않았던 점"을 단순히 나열하는 데 그치지 않고, 분류한 뒤 개선 액션(Action Item)으로 도출합니다.

## 회고 (실수의 4가지 분류)
- 주의 부족 : 설정 실수, 테스트 누락 등
- 전달 불량 : 사양 인식 차이, 인수인계 부족 등
...

스크럼 마스터의 관점

회고의 역할은 "범인 찾기"가 아니라, 개인의 반성을 팀의 프로세스 개선으로 전환하는 것입니다. "누가"가 아니라 "어떤 분류의 실수가 어떤 시스템의 허점으로부터 발생했는가"로 대화의 방향을 돌리면, 심리적 안전감(Psychological Safety)을 유지하면서 원인 분석을 할 수 있습니다.

실패학에서는 좋은 개선이란 "담당자가 열심히 주의하는 것"이 아니라, 틀릴 수 없는 상태를 작업 절차 그 자체에 심어 넣는 것이라고 합니다 (저서에서는 노포 화과자점 '아카후쿠(赤福)'의 제조·품질 관리 사례로 소개되어 있습니다).

여기서 중요한 것은, 개선을 "사람의 노력"으로 되돌려서는 안 된다는 원칙입니다. 사람의 노력에 의존한 대책은 담당자가 바뀌거나 바빠지는 순간 무너집니다.

회고에서 나온 개선 사항을 다음과 같이 팀의 자산(시스템)으로 승격시킵니다.

이렇게 "주의한다"라는 대책을 AI 리뷰·CI·CODEOWNERS·템플릿이라는 "틀리기 어려운 시스템"으로 교체해 나가는 것이 아카후쿠의 가르침입니다.

실패학 서적에는 이메일(=기록으로 남는 전달 수단)의 사용법을 다루는 장이 있습니다. 요점은, 중요한 정보를 "구두"나 "머릿속"에 두지 않고, 나중에 참조할 수 있는 형태로 외부화(Externalization)하는 것입니다. 구두 지시나 기억은 전달 불량(실수 분류 ②)의 온상이 됩니다.

개발 현장에서는 다음의 것들이 모두 "외부화"의 수단입니다.

## PR description 템플릿 예시
### 목적 / 배경
- 왜 이 변경이 필요한가 (Issue: #123)
...

'확인한 관점'을 적어두면, 리뷰어는 다른 관점에서 체크하기 쉬워지며, 이는 1장의 더블 체크(Double Check) 3원칙과도 연결됩니다. 구두로 끝냈던 일을 PR이나 Issue에 적는 것만으로도 전달 불량은 크게 줄어듭니다.

이러한 시스템화(Systematization)를 진행한 결과, 팀의 베로시티 (Velocity) (1스프린트에서 완료할 수 있었던 스토리 포인트의 합계)가 명확하게 증가했습니다.

용어 보충

스토리 포인트 (Story Point, SP): 태스크의 상대적인 크기(규모·복잡성)를 나타내는 추정 단위. 베로시티 (Velocity): 1스프린트에서 완료할 수 있었던 SP의 합계. 팀의 '처리 가능한 양'의 척도.

마침 Sprint 72에서 모든 PR에 대한 AI 리뷰를 필수화했습니다. 이 전후로 베로시티가 크게 변했습니다.

Jira의 베로시티 보드(Velocity Board)로 보면, Before / After는 다음과 같습니다.

베로시티 (SP)
Before Sprint 67-71 ██████████ 약75
After Sprint 72- ████████████████████ 약150 (약 2배)

AI 리뷰와 CODEOWNERS를 통해 재작업(Rework)이 줄어들고, 회고(Retrospective)를 통한 개선이 시스템으로 쌓이면서, '동일한 지적의 재발'이나 '리뷰 대기·수정의 반복'에 소비하던 시간이 가치 있는 개발로 전환되었다고 판단하고 있습니다.

주의 (수치 읽는 법)

베로시티는 팀 내부의 상대적 지표이며, 타 팀과 비교하거나 생산성 그 자체와 동일시할 수 있는 값은 아닙니다. 또한, 이 향상은 시스템화만이 요인이라고 단정할 수 없으며, 멤버의 숙련도나 태스크의 성격 등 여러 요인이 겹친 결과입니다. 어디까지나 '시스템화와 같은 시기에 팀의 아웃풋이 늘어났다'는 사실로 받아들여 주십시오.

실패학(Failure Studies)의 사고방식과 스크럼(Scrum) × AI 리뷰의 실천은 깔끔하게 대응합니다.

'주의 깊은 사람'을 늘리는 것이 아니라, '주의하지 않아도 틀리기 어려운 팀'을 설계해 나갑시다.

• 이노 켄지 『일이 빠른데 실수하지 않는 사람은 무엇을 하고 있는가?』 (실패학 사고방식의 출처)

• ※ 본 기사의 '더블 체크 3원칙', '실수의 4분류', '아카후쿠', '메일의 장'은 해당 저자의 실패학 관련 서적에서 소개된 사고방식을 필자가 재구성한 것입니다. 정확한 기술은 서적을 참조해 주십시오.

• About code owners - GitHub Docs

• 스크럼 가이드 (Scrum Guide)

• 심리적 안전성과 생산성을 양립하는 자동 소스 리뷰 도입 (CodeRabbit 활용)