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

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

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

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

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

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

• 팀의 실수·재작업을 줄이고 싶은 엔지니어 / 테크 리드(Tech Lead) / EM

• 스크럼 마스터, 애자일 코치(Agile Coach)

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

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

• 「주의한다」가 아니라 「시스템으로 방지한다」로의 발상 전환

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

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

용어 보충

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

스크럼(Scrum)의 회고(Retrospective)는 이 4가지 분류를 사용하기에 절호의 장소입니다. "잘 되지 않았던 점"을 그냥 나열하는 데 그치지 않고, 분류한 뒤 개선 액션으로 연결합니다.

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

스크럼 마스터의 관점

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

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

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

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

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

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

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

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

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

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

용어 보충

스토리 포인트 (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 리뷰의 실천은 깔끔하게 대응됩니다.

• 확인은 "같은 것을 2번" 하는 것이 아니라, 사람·관점·외형을 바꾸어 이중으로 수행한다 - 실수는 "조심하겠습니다"라고 하기 전에, 4가지 분류 중 무엇인지를 특정한다 - 개선은 개인의 노력으로 돌리지 않고, 틀리기 어려운 시스템으로 승격시킨다 - 구두·기억에 의존하지 않고, PR / Issue / 의사록에 외부화한다 |

• main 브랜치 대상 PR에서 AI 리뷰를 필수로 한다 - 중요한 영역을 CODEOWNERS에 등록하여 승인을 필수화한다 - 다음 회고에서 실수 4분류 프레임워크를 사용해 본다 - 회고 액션 중 하나를 CI 또는 PR 템플릿으로 승격시킨다

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

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

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

• About code owners - GitHub Docs

• 스크럼 가이드 (Scrum Guide)

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