152. 요구사항 검토 (Review) - 인스펙션, 워크쓰루

핵심 인사이트 (3줄 요약)

본질: 요구사항 검토(Review)는 소프트웨어를 실행하지 않고(정적 테스트), 기획자나 분석가가 작성한 명세서(SRS) 문서를 사람의 눈과 머리로 깐깐하게 심사하여 논리적 구멍을 찾아내는 정적 검증(Static Verification) 활동이다.

가치: 코딩이 끝나고 버그를 고치는 비용이 100만 원이라면, 요구사항 문서 단계에서 연필로 쭉 긋고 오타를 고치는 비용은 1,000원에 불과하다. 생명주기(SDLC)의 가장 앞단에서 결함(Defect)을 죽여버려 눈덩이처럼 불어나는 재작업(Rework) 파국을 막아낸다.

융합: 검토의 빡셈(격식) 정도에 따라 가벼운 발표인 **워크쓰루(Walkthrough)**와, 훈련된 전문가가 체크리스트를 들고 작성자의 숨통을 조이는 공식 심사인 **인스펙션(Inspection)**으로 융합/분리되며, 현대에는 Peer Review(코드 리뷰) 문화로 흡수되어 애자일(Agile) 속으로 스며들었다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 검토(Review)란 소프트웨어 개발 산출물(요구사항 명세서, 설계도, 소스코드 등)을 동료, 테스터, 관리자가 모여 읽고 분석함으로써, 문서에 숨어있는 오류(Error)나 표준 위반을 찾아내는 집단 품질 보증(QA) 활동이다.
필요성: 프로젝트를 혼자 기획하고 코드를 짜는 1인 천재 개발자는 세상에 존재하지 않는다. 기획자 A가 "로그인 실패 시 3번 틀리면 락(Lock)을 건다"고 적었다고 치자. 이 문서를 리뷰 없이 개발자 B에게 넘기면, B는 "비밀번호를 틀렸을 때만? 아이디를 틀렸을 때도?"라는 의문에 빠져 자기 상상대로 코딩을 해버린다. 결국 오픈 날 보안 감리를 통과하지 못해 1주일 밤을 새워 DB와 서버 코드를 뜯어고쳐야 한다. "코드 한 줄 짜기 전에, 저 문서 한 장을 테이블에 올려놓고 다 같이 뜯어보면서 빈틈을 찾아 메우자!"라는 가장 원시적이면서도 압도적인 가성비의 공학적 방어막이 필요했다.
💡 비유: 요구사항 검토는 건축물을 짓기 직전, 건축가와 감리사가 모여 **'건축 도면(명세서)만 뚫어져라 쳐다보며 도면의 오류를 찾는 회의'**입니다. 시멘트를 다 붓고 기둥을 세운 뒤(코딩 완료)에 "어? 이 기둥이 아니네" 하고 부수고 다시 짓는 건 수억 원이 깨지지만, 시멘트 붓기 전 어젯밤에 도면 위에서 빨간펜으로 선 하나 찍 긋고 위치를 고치는 건 돈이 한 푼도 안 듭니다.
등장 배경:
1. 배리 보엠(Barry Boehm)의 결함 비용 곡선: 요구사항 단계에서 발생한 결함을 나중에 운영 단계에서 고치려면 비용이 100배에서 1,000배까지 수직 상승한다는 경제적 공포가 기업을 지배했다.
2. 마이클 페이건(Michael Fagan)의 인스펙션(1976): IBM의 페이건이 "그냥 모여서 대충 읽지 말고, 역할을 나누고 군대처럼 각 잡고 깐깐하게 문서를 검사하자"며 인스펙션이라는 공식적 정적 테스팅 기법을 창시하며 결함 검출률을 80%까지 끌어올렸다.

┌─────────────────────────────────────────────────────────────┐
│          요구사항 검토의 3대 기법 (격식성/깐깐함의 스펙트럼)            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 🟩 동료 검토 (Peer Review) ➔ 비공식적, 가벼움                   │
│   - 참여: 옆자리 동료 1~2명                                    │
│   - 방법: 커피 마시면서 "야, 이 문서 한 번 쓱 읽고 이상한 거 찾아줘."   │
│   - 특징: 기록도 안 남고 룰도 없음. 애자일의 상시 코드 리뷰가 대표적.     │
│                                                             │
│ 🟨 워크쓰루 (Walkthrough) ➔ 반(Semi) 공식적, 작성자 주도          │
│   - 참여: 작성자 + 동료 개발자/기획자 5명 내외                       │
│   - 방법: 작성자가 빔프로젝터 띄우고 발표함. "제가 이렇게 짰는데요~"     │
│          참석자들이 들으면서 "저기 논리 이상한데요?" 하고 지적함.       │
│   - 특징: 지식 공유와 교육 목적이 강함. 분위기 부드러움.              │
│                                                             │
│ 🟥 인스펙션 (Inspection) ➔ 초공식적, 절대적 깐깐함 (결함 척살)      │
│   - 참여: 주재자(진행자), 낭독자, 기록자, 그리고 무서운 검토자들 (작성자 빠짐)│
│   - 방법: 작성자는 방어/변명 불가. 훈련된 전문가가 체크리스트를 들고     │
│          문서를 현미경처럼 뜯어보며 결함(Bug)만 냉혹하게 찾아냄.        │
│   - 특징: 회의록과 결함 시정 권고서가 회사 공식 문서(결재)로 떨어짐.     │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리뷰 기법을 분류하는 핵심 잣대는 **'형식성(Formality)'**과 **'작성자의 주도권'**이다. 워크쓰루는 작성자가 마이크를 잡고 회의를 이끈다. 당연히 본인에게 유리하게 설명하며, 참석자들은 설명을 듣느라 결함을 꼼꼼히 찾지 못한다(결함 발견율 30%). 반면 인스펙션은 Fagan Inspection 모델에 따라 철저히 군대처럼 룰을 지킨다. 작성자는 조용히 듣기만 해야 하며, 별도의 '낭독자(Reader)'가 문서를 읽고, '주재자(Moderator)'가 회의를 통제한다. 잔인할 정도로 결함만 후벼 파는 이 방식은 결함 발견율을 70~80%까지 끌어올리는 소프트웨어 공학 정적 테스팅의 끝판왕이다.

📢 섹션 요약 비유: 동료 검토는 친구한테 내 일기를 보여주며 "오타 있어?" 묻는 것이고, 워크쓰루는 조별 과제 발표 때 친구들 앞에서 내 생각을 칠판에 적으며 토론하는 것입니다. 하지만 인스펙션은 무서운 면접관 3명 앞에서 내 논문을 제출하고, 면접관들이 빨간펜으로 무자비하게 팩트 폭격을 날려 박살을 내는 '국정 감사'입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 인스펙션 (Inspection)의 6단계 공식 프로세스 (Fagan Model)

기술사 시험과 실무 QA 조직 셋업의 바이블이다. 그냥 회의실에 모이는 게 아니다.

단계	명칭	활동 (Activity)	핵심 포인트
1	계획 (Planning)	주재자(Moderator)가 참여자를 뽑고, 리뷰할 문서를 배포함.	리뷰할 문서가 너무 길면(2시간 치 이상) 회의를 잘라야 함.
2	사전 교육 (Overview)	참석자들에게 시스템의 배경 지식과 도메인을 짧게 교육함.	모두가 문서의 맥락(Context)을 일치시키는 과정.
3	사전 준비 (Preparation)	🌟 핵심: 회의 전 각자 자리에서 체크리스트를 들고 문서를 독파함.	회의실에 와서 문서를 처음 읽는 건 인스펙션의 죄악이다. 혼자 버그를 다 찾아와야 함.
4	인스펙션 회의 (Meeting)	낭독자(Reader)가 읽고, 기록자(Scribe)가 버그를 엑셀에 씀.	해결책을 논의하는 자리가 아님! "여기에 버그가 있다!"라고 지적만 하고 바로 넘어가야 함. (해결책 찾다 회의 터짐 방지)
5	재작업 (Rework)	작성자가 회의록(버그 리스트)을 들고 자리로 돌아가 문서를 고침.	뼈를 깎는 고통의 수정 시간.
6	후속 조치 (Follow-up)	주재자가 작성자가 버그를 진짜로 고쳤는지, 꼼수 안 썼는지 최종 승인(Sign-off).	이거 통과 못 하면 베이스라인(Baseline) 도장을 안 찍어 줌.

2. 리뷰에서 활용되는 무기: 체크리스트 (Checklist)

그냥 빈 눈으로 문서를 읽으면 사람은 자기가 아는 것만 보인다. 정적 검토의 파괴력은 '체크리스트'에서 나온다.

예시: "IEEE 830 명세서 품질 특성"을 체크리스트로 만든다.
- 1. 모든 요구사항에 REQ-001 같은 식별 번호가 박혀 있는가? (추적성)
- 1. 빨리, 최대한 같은 부사/형용사가 섞인 문장이 있는가? (명확성)
- 1. 분기 로직(If)이 있을 때, 실패(Else) 시의 에러 반환 로직이 적혀 있는가? (완전성)
📢 섹션 요약 비유: 훈련받지 않은 일반인이 중고차를 살 때는 겉에 기스(흠집) 난 것만 보입니다. 하지만 인스펙션은 자동차 정비사 명장(전문가) 3명이 "1. 엔진 누유, 2. 침수 흔적 냄새, 3. 브레이크 마모도"라는 완벽한 채점표(체크리스트)를 들고 차의 밑바닥까지 샅샅이 뒤져서 폭탄 차량을 걸러내는 초정밀 엑스레이 검사입니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: 인스펙션의 압박감 vs 개발자의 자존심 방어

리뷰 과정에서 가장 파멸적인 리스크는 IT 시스템이 아니라 **인간의 감정(Ego)**에서 터진다.

주체	회의 중 심리 상태	발생하는 실무적 참사 (안티패턴)	아키텍트/주재자의 융합적 리더십
작성자 (기획자/개발자)	내 분신 같은 문서와 코드를 까내리니 발가벗겨진 기분. 방어 기제 발동.	결함 지적 시 "아니, 그게 아니라 고객이 그렇게 해달라고 했어!"라며 변명하고 회의를 싸움판으로 맘듦.	"작성자를 공격하지 말고 산출물(문서)만 공격하라!" (Egoless Programming) 문화를 조직에 강제 주입.
검토자 (참석자)	남의 문서 까기 미안함 + 내 일 바빠서 회의 전에 안 읽어 옴.	회의실에 앉아서 문서를 처음 쓱 읽어보고 대충 "오타 몇 개 있네요" 하고 끝냄. (결함 발견 0개)	주재자가 사전 준비(Preparation) 로그를 검사하고 안 읽어온 사람은 회의실에서 쫓아내는 독재자 권한 쥐기.

과목 융합 관점

테스팅 (QA - 정적 분석의 경제학): 소프트웨어 테스팅은 크게 코드를 돌리는 동적(Dynamic) 테스트와 안 돌리는 정적(Static) 테스트로 나뉜다. 인스펙션과 워크쓰루는 정적 테스트의 쌍두마차다. 동적 테스트(블랙박스)는 화면 띄우고 버튼 눌러보느라 엄청난 세팅 비용과 시간이 들지만, 리뷰(정적 테스트)는 사람 눈만 있으면 논리적 결함을 잡아낸다. 공학적 통계에 따르면 정적 리뷰 한 시간은, 나중에 런타임 버그 잡는 시간 10시간의 디버깅 노가다를 아껴주는 극강의 레버리지(ROI)를 발휘한다.
보안 (Security - 시큐어 코딩 리뷰): 보안 사고의 70%는 해커의 신기술 때문이 아니라, 개발자가 SQL을 짤 때 바인딩 변수를 안 쓰고 평문을 섞는(SQL 인젝션 취약점) 단순한 실수에서 터진다. 코드 리뷰(워크쓰루) 과정에 사내 화이트해커(보안팀)를 인스펙터로 난입시켜, 로직이 아니라 **"입력값 검증이 뚫려있는가?"**라는 보안 체크리스트 하나만으로 코드를 난도질하게 만들면, 서버가 털리는 뉴스 데스크 참사를 99% 사전 방어할 수 있다.
📢 섹션 요약 비유: 리뷰 회의는 노래 오디션(슈퍼스타K)과 같습니다. 심사위원(검토자)이 "노래를 못 부르네요"라고 참가자(작성자)의 인신 공격을 하면 싸움이 납니다. "방금 3번째 마디에서 반음이 떨어졌습니다(객관적 결함 지적)"라고 팩트만 집어내야 참가자도 납득하고 고칠 수 있습니다. 자존심(Ego)을 떼어내는 훈련이 인스펙션 성공의 알파요 오메가입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 워크쓰루의 변질과 집단사고(Groupthink)의 참사: 차세대 은행 시스템 개발 중 핵심 이체 로직 명세서에 대한 워크쓰루가 열렸다. 개발 팀장(작성자)이 빔프로젝터를 띄우고 1시간 동안 막힘없이 설계도를 설명했다. 참석한 주니어 개발자 5명은 팀장님의 포스에 눌려 아무 질문도 못 하고 박수만 치며 "통과"를 선언했다. 한 달 뒤 이체 로직에서 0.1원의 이자가 증발하는 결함이 발생해 금감원 감사가 떴다.
- 판단: 전형적인 워크쓰루의 한계이자 '집단사고(권위자 눈치 보기)'의 파국이다. 직급이 높은 사람이 마이크를 쥐면 리뷰는 '결함 검출'이 아니라 '일방적 통보와 세뇌'의 시간으로 변질된다. 실무 아키텍트는 이런 핵심 코어 도메인에 대해서 워크쓰루를 금지하고, 외부 감리인이나 다른 부서 에이스급 시니어 2명을 **무기명 인스펙터(Inspector)**로 강제 투입해 팀장의 설계도를 갈기갈기 찢도록 조직적인 칼춤(Inspection) 판을 깔아야만 시스템 붕괴를 막을 수 있다.
시나리오 — 리뷰에서 '해결책'을 찾으려다 터지는 타임박스(Timebox) 초과: 3시간짜리 인스펙션 회의가 잡혔다. 10분쯤 지났을 때, 결제 모듈에서 동시 접속 시 데드락이 날 수 있다는 버그가 발견되었다. 순간 5명의 똑똑한 개발자들이 신이 나서 "비관적 락을 걸자!", "아니다 Redis 분산락이 낫다!"며 화이트보드에 그림을 그리며 난상 토론을 시작했다. 2시간 50분이 지나 락(Lock) 논쟁이 끝났고, 남은 90%의 문서는 읽지도 못한 채 회의가 허무하게 끝났다.
- 판단: 인스펙션 주재자(Moderator)의 무능이 낳은 재앙이다. 인스펙션 룰 제1조는 **"결함을 발견(Find)만 하고, 절대 회의실 안에서 해결책(Fix)을 논의하지 마라!"**다. 해결책 토론이 시작되는 순간 진행자는 책상을 치고 말을 끊은 뒤 "결함 번호 1번 적었으니 넘어갑시다"라며 강제로 진도를 빼야 한다. 해결은 나중에 작성자가 자기 자리에 가서 며칠 밤을 새우든 구글링하든 알아서 할 일(Rework)이다. 회의실에 비싼 인력 5명을 모아둔 이유는 그들의 '눈알'로 버그 스캔(Scan)을 치기 위함이지 수다를 떨기 위함이 아니다.

  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: 모던 애자일(Agile) 시대의 리뷰 파이프라인 융합       │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [❌ 구시대의 빅뱅 리뷰 (폭포수 환경)]                              │
  │ 요구사항 1,000장 다 씀 ➔ 회의실에 10명 모여서 1주일 동안 인스펙션 ➔ 전멸 💥│
  │ (너무 길어서 아무도 안 읽음, 집중력 저하로 뒷부분 결함은 다 뚫림)            │
  │                                                             │
  │ [✅ 모던 아키텍처: CI/CD + Pull Request (PR) 기반 마이크로 리뷰] │
  │                                                             │
  │ 1. 개발자 A가 티켓 1개(기능 1개) 단위로 코드를 짜서 GitHub에 PR을 날림. │
  │        │                                                    │
  │        ▼ [ 🤖 자동화된 정적 검증 (Static Analysis) 발동 ]         │
  │ 2. SonarQube(봇)가 1초 만에 스캔: "보안 취약점 1개, 변수명 에러 3개!"     │
  │        │ (기계가 인간의 단순 오타 검사 노가다를 100% 흡수)           │
  │        ▼                                                    │
  │ 3. 통과 시, 동료 개발자 B, C에게 슬랙(Slack) 알림이 감.              │
  │        │                                                    │
  │        ▼ [ 🧑‍💻 비동기 Peer Review (현대판 인스펙션) ]            │
  │ 4. 동료 B, C가 내 자리에 앉아서 화면에 뜬 코드(Diff)를 보며 코멘트를 담.    │
  │    "이 분기문에서 널(Null) 떨어지면 뻗겠는데요? 고쳐주세요." (결함 지적)     │
  │        │                                                    │
  │ 5. 개발자 A가 코드를 고치고(Rework), 동료 2명의 Approve(승인)를 받아야만│
  │    비로소 메인 서버(Master)로 코드가 합쳐짐(Merge)! 🌟               │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 거창하게 회의실을 빌리고 각 잡고 모이는 80년대 마이클 페이건의 인스펙션은 오늘날의 미친듯한 개발 속도(애자일)를 따라갈 수 없다. 현대 엔터프라이즈의 리뷰 아키텍처는 **비동기(Asynchronous) 코드 리뷰 (Pull Request)**라는 훌륭한 시스템으로 녹아들었다. 기계(SonarQube)가 잡을 수 있는 오타와 문법 오류는 봇(Bot)에게 100% 떠넘기고, 인간의 뇌는 오직 '비즈니스 로직의 모순'과 '설계 아키텍처의 결함'이라는 고차원적인 지능형 리뷰에만 집중한다. 회의실에 안 모여도 Github 댓글 창에서 살벌한 인스펙션이 24시간 벌어지는 것이 클라우드 네이티브 시대의 QA 혁명이다.

도입 체크리스트

기술적: 코드 리뷰(Peer Review)나 문서 리뷰 시, 리뷰어가 "코드 1줄당 지적하는 개수(Defect Density)" 통계 메트릭이 JIRA 대시보드에 뽑히고 있는가? 리뷰어가 코드를 500줄 봤는데 결함 지적이 0개라면, 그 리뷰어는 코드를 아예 안 읽고 무지성 승인(LGTM - Looks Good To Me)을 날린 가짜 검토자일 확률이 99%다.
운영·보안적: 1,000줄이 넘는 코드를 한 번의 리뷰 세션에 던지는 행위를 파이프라인에서 강제 차단(Block)하고 있는가? 인간의 뇌는 1시간에 300줄 이상의 논리를 넘어가면 집중력이 박살 나서 결함을 다 놓쳐버린다(리뷰의 한계 효용). 코드 변경분(Diff)은 무조건 300줄 이내로 잘게 쪼개어 잦은 빈도로 던져야(마이크로 커밋) 리뷰의 퀄리티가 생존할 수 있다.

안티패턴

문서 작성자를 인스펙션 주재자(Moderator)로 앉히기: 기획서 쓴 사람이 자기가 직접 진행 마이크를 잡고 회의를 이끄는 셀프 인스펙션. "아 제가 이 부분은 밤새서 썼는데, 그냥 넘어가시죠~"라며 동정심을 유발하거나 반대 의견을 깔아뭉개는 짓이다. 공식 인스펙션의 가장 거룩한 룰은, 이 문서를 한 번도 본 적 없는 냉정한 제3자(보통 별도의 QA 팀장)가 주재자 완장을 차고 무자비하게 회의 시간과 참석자의 발언권을 통제해야만 객관적인 결함이 쏟아진다는 것이다.
📢 섹션 요약 비유: 리뷰 봇(SonarQube)은 문서의 맞춤법과 띄어쓰기를 1초 만에 검사하는 '빨간 줄 자동 검사기'입니다. 동료 개발자(리뷰어)는 "이 글의 주인공이 3페이지에선 죽었는데 5페이지에선 왜 살아있어?"라는 앞뒤 로직의 모순(치명적 버그)을 찾아내는 '깐깐한 편집장'입니다. 둘이 환상적으로 융합해야 베스트셀러(무결점 소프트웨어)가 나옵니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	나 홀로 개발 (No Review)	철저한 정적 리뷰 (Inspection/PR) 통제	개선 효과
정량	운영 배포 후 서버 터지고 야근 10시간	설계/문서 단계에서 연필로 쓱 지우고 끝	결함 1개당 수정 비용 1/100 수준으로 초극단적 절감
정량	개인 코딩 스타일 중구난방 (코드 스파게티)	시니어의 리뷰 지적으로 팀 컨벤션 통일	시스템 구조적 기술 부채(Technical Debt) 사전 80% 상각
정성	"내가 짠 코드는 신성불가침이다" 자존심 고립	상시 지적과 토론을 통한 집단 지성 발현	Egoless Programming(자아 분리) 문화 정착 및 팀 역량(암묵지)의 수평적 상향 평준화

미래 전망

거대 언어 모델(LLM)에 의한 코드 리뷰 자동화: 이미 Github Copilot 등은 인간 리뷰어의 자리를 뺏어 먹고 있다. 주니어 개발자가 PR(Pull Request)을 올리면, 사내 시니어가 커피를 마시러 간 사이 AI 봇이 코드를 스캔하고 댓글을 단다. "이 부분은 SQL Injection 위험이 있습니다. 이렇게 쿼리를 튜닝하세요." AI가 인간 뺨치는 통찰력으로 로직의 모순까지 짚어내는 시대. 인간 리뷰어는 AI가 놓친 '비즈니스 정책적 의미'라는 최상위 수준의 철학적 인스펙션으로 역할이 강제 이동하고 있다.
행동 주도 개발(BDD) 텍스트 명세의 등장: 워크쓰루에서 사람이 읽으며 머릿속으로 상상해야 했던 '기획서(산문체)'가, BDD(Given-When-Then)라는 규칙적인 영단어 블록으로 진화했다. 문서가 곧 테스트 코드로 자동 실행되므로, "사람 눈으로 읽어서 오류를 찾는(정적 테스트)" 낡은 인스펙션의 파이를 기계가 돌려버리는(동적 테스트) 자동화 파이프라인이 흡수해가며 공학의 패러다임을 혁명적으로 바꾸고 있다.

참고 표준

IEEE Std 1028: 소프트웨어 검토 및 감사(Review and Audit)에 대한 국제 표준. (인스펙션, 워크쓰루, 기술 검토 등의 엄격한 공식 절차 정의)
Fagan Inspection: 1976년 마이클 페이건이 IBM 시절 확립한 6단계 정형화된 소프트웨어 인스펙션 수학적 통계 모델

"혼자 짠 코드는 시한폭탄이고, 리뷰 받지 않은 문서는 휴지조각이다." 소프트웨어 공학이 다른 공학과 가장 차별화되는 점은, 건물을 짓기 위해 수백 톤의 시멘트를 사 올 필요 없이 오직 사람의 '뇌'와 '키보드'만으로 수백억 원짜리 성을 쌓아 올린다는 것이다. 그래서 가장 저렴하면서도 가장 파괴적인 방어 무기는 코드를 실행하는 무거운 컴파일러가 아니라, 옆자리 동료의 '의심 가득한 매의 눈' 한 번이다. 내 분신 같은 문서에 동료가 빨간펜을 사정없이 그어댈 때 솟구치는 분노(Ego)를 꿀꺽 삼키고, "버그를 찾아줘서 고마워"라고 웃을 수 있는 팀. 그 이타적이고 차가운 지성주의(Egoless)야말로, 리뷰(Review) 아키텍처가 빚어내는 진정한 엔터프라이즈의 무결점 영혼이다.

📢 섹션 요약 비유: 요구사항 검토(리뷰)는 비행기가 활주로를 떠나기 직전, 기장과 부기장이 교차로 외치는 **'체크리스트 더블 체크'**입니다. "바퀴 올렸나? 확인. 연료 밸브 열었나? 확인." 하늘로 떠오른 뒤(운영 서버 배포 후)에는 엔진을 고칠 수 없습니다. 땅에 발이 닿아있을 때 깐깐한 수다(리뷰)를 떨어야만 추락사(프로젝트 폭망)를 막을 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
정적 분석 (Static Analysis)	사람이 눈으로 문서를 읽는 인스펙션의 지루함을 덜어주기 위해, 기계(SonarQube)가 텍스트 코드를 광속으로 읽어 내려가며 1차로 냄새(오류)를 걸러주는 환상의 짝꿍이다.
에고리스 프로그래밍 (Egoless)	"나는 내 코드가 아니다." 동료가 내 코드를 갈기갈기 찢어도 기분 나빠하지 않고 시스템 품질을 위해 감사히 받아들이는, 리뷰 문화를 지탱하는 핵심 심리적 철학이다.
결함 발견율 (Defect Detection Rate)	인스펙션을 빡세게 할수록 기하급수적으로 올라가는 통계 메트릭. 앞단에서 버그를 80% 죽여놓으면, 맨 뒷단 인수 테스트(UAT)가 소풍 가는 것처럼 여유로워진다.
Pull Request (PR) 기반 코드 리뷰	80년대의 딱딱한 오프라인 인스펙션 회의실을 폭파하고, Github 웹 브라우저 화면에서 전 세계 개발자들이 비동기로 댓글을 달며 융단폭격을 가하는 모던 리뷰 인프라다.
결함 수정 비용 (Cost of Rework)	기획/문서 단계에서 오타 고치는 건 10원이지만, 고객에게 납품한 뒤 시스템 터져서 DB 고치는 건 1,000만 원이라는 보엠(Boehm)의 공포 곡선. 리뷰가 존재하는 경제학적 이유다.

👶 어린이를 위한 3줄 비유 설명

내가 쓴 숙제를 선생님한테 바로 내버리기 전에, 옆자리 짝꿍한테 "혹시 내가 틀린 거 있나 한번 봐줄래?" 하고 부탁하는 게 **'워크쓰루(가벼운 검토)'**예요!
만약 틀린 채로 선생님한테 내버리면(실제 배포), 빵점을 맞고 회초리를 맞는 엄청난 손해(버그 폭발)가 생기니까요.
더 무서운 **'인스펙션(깐깐한 검사)'**은 동네 제일 똑똑한 형아 3명이 돋보기와 빨간펜을 들고 나타나서, 내가 말할 틈도 안 주고 숙제의 틀린 글자를 사정없이 잡아내어 100점짜리 무적의 숙제로 만들어주는 마법의 심사랍니다!