“우리 프로젝트는 왜 항상 막판에 불이 나는 걸까?”
10년 넘게 프로젝트 현장을 돌아다니다 보면, 이 질문에 대한 답이 거의 항상 같은 곳에서 나온다는 걸 알게 된다. 범인은 늘 품질관리였다.
들어가며 — 현장에서 목격한 ‘품질의 역습’
몇 년 전, 필자가 참여했던 한 대형 SI 프로젝트가 생각난다. 6개월짜리 프로젝트였는데, 처음 4개월은 정말 순항이었다. 일정은 맞아 떨어지고, 팀원들도 의욕이 넘쳤다. 그런데 막판 두 달이 지옥이었다. 테스트 단계에서 결함이 폭발적으로 터져 나오기 시작한 것이다. 결국 오픈은 두 달 지연됐고, PM은 번아웃으로 중간에 교체됐으며, 팀 전체가 주말도 없이 야근을 반복했다.
나중에 돌아보니 문제는 명확했다. 프로젝트 초반에 품질관리를 ‘나중에 할 일’로 미뤄뒀던 것이다. 요구사항 정의 단계에서 애매하게 넘어간 것들이 설계에서 구멍이 됐고, 설계의 구멍이 개발에서 버그가 됐고, 개발의 버그들이 테스트에서 한꺼번에 폭발했다. 이걸 업계에서는 **’품질의 눈덩이 효과’**라고 부른다.
이 글을 쓰는 이유가 바로 이것이다. 품질관리는 ‘완성된 결과물을 검사하는 행위’가 아니다. 프로젝트의 모든 단계에 녹아들어 있어야 하는 생활 방식이다. 오늘은 그 이야기를 제대로 해보려 한다.
1. 품질관리란 무엇인가 — 개념부터 제대로 짚고 가자
QA, QC, QM — 이 셋을 헷갈리면 현장에서 바보 된다
현장에서 의외로 많이 혼동되는 개념들이다.
**QC(Quality Control, 품질 통제)**는 산출물을 검사하고 결함을 찾아내는 활동이다. 완성된 코드를 테스트하고, 문서를 검토하고, 산출물이 기준에 맞는지 확인하는 것. 사후적이고 반응적이다.
**QA(Quality Assurance, 품질 보증)**는 프로세스가 올바르게 설계되고 실행되는지를 감시하는 활동이다. “우리가 올바른 방식으로 만들고 있는가”를 묻는다. QC보다 예방적이고 시스템 지향적이다.
**QM(Quality Management, 품질 관리)**은 이 모든 걸 아우르는 상위 개념이다. 조직의 품질 정책, 목표, 전략, 그리고 QA와 QC를 포함하는 전체 프레임워크다.
PMBOK(프로젝트관리지식체계) 7판은 품질을 “고객과 이해관계자의 요구를 충족하고 기대를 뛰어넘는 정도”로 정의한다. 단순히 스펙을 만족하는 것이 아니라 가치를 전달하는 것이 품질의 본질이라는 뜻이다.
품질의 세 가지 차원
품질을 얘기할 때 반드시 구분해야 하는 세 가지 차원이 있다.
첫째, 제품 품질(Product Quality): 결과물 자체의 품질. 기능이 올바로 작동하는가, 성능이 기준치를 넘는가, 보안에 취약점은 없는가.
둘째, 프로세스 품질(Process Quality): 만드는 과정의 품질. 요구사항 관리가 체계적인가, 리뷰 프로세스가 작동하는가, 변경 관리가 통제되는가.
셋째, 프로젝트 품질(Project Quality): 프로젝트 관리 자체의 품질. 일정, 비용, 범위가 계획대로 관리되고 있는가, 이해관계자 소통은 제대로 되는가.
많은 팀이 제품 품질에만 집중하다가 프로세스 품질과 프로젝트 품질을 놓친다. 그 결과는? 막판 불지르기다.
2. 프로젝트 품질관리의 핵심 프로세스
2-1. 품질 계획 수립 — 시작 전에 결판을 내라
품질계획서(Quality Management Plan)는 프로젝트 헌장이 승인된 직후에 작성돼야 한다. 개발 시작 전에. 적어도 설계 전에는.
품질계획서에 반드시 들어가야 할 내용:
- 품질 기준(Quality Standards): 어떤 기준을 만족해야 하는가. 코드 커버리지 80% 이상, 응답시간 3초 이내, 결함 밀도 페이지당 0.5개 이하 같은 숫자로 표현된 기준.
- 품질 메트릭(Quality Metrics): 품질을 어떻게 측정할 것인가. 측정 방법과 측정 도구.
- 품질 체크리스트: 각 단계별로 검토해야 할 항목 목록.
- 프로세스 개선 계획: 프로젝트 진행 중 발견된 문제를 어떻게 개선할 것인가.
현장에서 흔히 보는 실수가 있다. “우리는 품질이 중요하다”고 말하면서 막상 품질계획서는 한 장짜리 형식적 문서를 만들어 두는 것. 그 문서는 프로젝트 내내 서랍 속에서 잠을 잔다.
2-2. 품질 보증 활동 — 프로세스가 살아 숨쉬게 하라
품질 보증은 크게 두 가지 방법으로 실행된다.
**프로세스 감사(Process Audit)**는 팀이 정해진 프로세스를 실제로 따르고 있는지 확인하는 활동이다. “우리가 정한 코드 리뷰 절차를 지키고 있나?” “요구사항 변경이 발생했을 때 변경 관리 프로세스를 통했나?” 이런 질문들에 답을 구하는 과정이다.
**품질 감사(Quality Audit)**는 외부 또는 독립적 관점에서 프로젝트의 품질 활동을 전반적으로 검토하는 것이다. 내부 사람들끼리만 검토하면 놓치는 것들이 있다. “당연하다”고 생각했던 것들이 실은 문제였음을 외부 시선이 잡아낸다.
**동료 검토(Peer Review)**도 핵심 QA 활동이다. 코드 리뷰, 문서 리뷰, 설계 검토 등이 여기에 포함된다. 연구에 따르면 정식 인스펙션(Inspection)을 통해 발견된 결함은 테스트에서 발견될 때보다 처리 비용이 최대 10배까지 저렴하다.
2-3. 품질 통제 활동 — 결함을 빨리, 더 빨리 잡아라
품질 통제의 핵심 원칙은 하나다. 결함은 발생한 곳에서 가장 가까운 시점에 발견할수록 처리 비용이 낮아진다.
요구사항 단계에서 발견한 결함 수정 비용을 1이라고 하면, 설계 단계에서 발견하면 5~10배, 개발 단계에서는 10~50배, 테스트 단계에서는 50~200배, 운영에서 발견되면 100~1000배가 든다고 알려져 있다. 이게 바로 결함 조기 발견의 경제학이다.
주요 품질 통제 기법들을 살펴보자.
제어 차트(Control Chart): 프로세스가 통계적으로 안정적인 상태에 있는지 시각화하는 도구. 결함 발생 추이, 일일 테스트 통과율 등을 추적해서 이상 징후를 조기에 포착한다.
파레토 차트(Pareto Chart): “결함의 80%는 20%의 원인에서 비롯된다”는 파레토 법칙을 활용해 가장 중요한 문제에 집중하게 해주는 도구. 산더미 같은 결함 목록 앞에서 멍때리지 않게 해준다.
피쉬본 다이어그램(Ishikawa Diagram): 결함의 근본 원인을 추적하는 도구. 사람(People), 프로세스(Process), 장비(Machine/Tool), 환경(Environment), 재료(Material), 측정(Measurement) 이 여섯 가지 범주로 원인을 체계적으로 탐색한다.
산포도(Scatter Diagram): 두 변수 사이의 상관관계를 시각화한다. “복잡도가 높은 모듈일수록 결함이 많은가?” 같은 가설을 검증할 때 유용하다.
3. 2025~2026년 현재, 품질관리 현장에서 무슨 일이 벌어지고 있나
AI와 자동화 — 품질관리의 판을 바꾸는 중
지금 품질관리 현장에서 가장 뜨거운 화제는 단연 AI다. 업계 전반의 기업들은 규정 준수를 강화하고 프로세스를 간소화하며 제품 품질을 개선하기 위해 데이터 기반, AI 강화, 클라우드 지원 QMS 플랫폼을 채택하는 방향으로 빠르게 이동하고 있다.
이게 단순한 유행처럼 들릴 수도 있다. 그런데 실제 수치를 보면 이야기가 달라진다. 현재 프로젝트 관리 소프트웨어의 약 70%에는 예측 분석 및 자동화된 일정 관리를 위한 AI 기반 기능이 포함되어 있다. 불과 3년 전만 해도 AI가 들어간 PM 도구가 이렇게 많지 않았다. 시장도 폭발적으로 성장 중이다. 품질 관리 소프트웨어 시장은 2035년까지 연평균 성장률 13%로 성장할 것으로 전망된다.
실제 현장에서 AI 기반 품질관리는 어떻게 작동하는가?
예측적 품질 모니터링(Predictive Quality Monitoring): 과거 데이터를 학습한 AI가 현재 진행 중인 프로젝트에서 품질 문제가 발생할 가능성이 높은 구간을 미리 예측한다. “이 모듈은 복잡도가 높고 담당 개발자의 업무 부하가 최근 급증했습니다. 결함 발생 위험이 높습니다.” 같은 경보를 내보낸다.
자동화 테스트의 진화: 단순 반복 테스트를 AI가 자동으로 생성하고 실행한다. 개발자가 코드를 커밋하는 순간 자동으로 테스트가 돌아가고, 결과가 리포트된다. CI/CD(지속적 통합/지속적 배포) 파이프라인에 품질 게이트가 자동으로 연동된다.
NLP 기반 요구사항 품질 분석: 자연어로 작성된 요구사항 문서에서 모호한 표현, 충돌하는 요건, 누락된 엣지 케이스 등을 AI가 자동으로 탐지한다. 초기 단계에서 요구사항의 품질을 끌어올리는 것이다.
그러나 여기서 한 가지 반드시 짚고 넘어가야 할 것이 있다.
AI 품질관리의 함정 — 기술만 믿으면 다친다
AI가 만능이 아니라는 사실은 최근 크고 작은 사건들이 잘 보여준다. 다수의 조사에서 AI 프로젝트의 80% 이상이 기대 성과를 달성하지 못하고 실패하는 것으로 나타났다. 이러한 실패는 단순한 기술적 결함이 아니라, 경영 전략, 데이터, 인적 자원, 기술의 한계, 배포 후 운영 등 여러 요소가 복합적으로 얽혀 발생하는 시스템적 문제다.
특히 AI를 품질관리에 도입할 때 빠지기 쉬운 함정이 있다. AI 프로젝트를 외주에 의존하는 것은 실패를 부를 수 있다. AI 프로젝트를 주관하는 임원들의 기대가 필요 이상으로 크고, 프로젝트 결과는 항상 기대에 못 미치는 경우가 많다.
맥도날드의 사례가 교훈적이다. 맥도날드는 IBM과 협력해 드라이브 스루 음성 주문에 AI를 적용하는 실험을 3년간 이어오다 2024년 6월 전면 중단했다. AI가 주문을 제대로 인식하지 못하는 문제가 계속됐기 때문이었다. 3년이다. 세계 최고의 IT 기업과 세계 최대의 패스트푸드 체인이 손잡고 3년을 시도했는데 실패했다. AI 도구를 도입하면 저절로 품질이 올라갈 것이라는 생각은 환상이다.
품질은 도구가 보장하는 게 아니다. 사람이 프로세스를 통해 만들어내는 것이다.
IoT와 실시간 품질 데이터 — 건설·제조 현장의 혁명
건설·제조 분야에서는 IoT 기반 품질관리가 빠르게 확산되고 있다. 포스코이앤씨는 철근 누락 같은 중대 사고를 막기 위해 IoT 기반 철근 스마트 품질관리 시스템을 개발했다. 이 시스템은 OCR 기술을 활용해 설계 도면과 실제 발주 물량을 자동으로 비교·검토함으로써 인적 오류를 획기적으로 줄인다.
서울시는 2026년 3월 ‘알기 쉬운 건설공사 품질관리’ 책자를 발간했으며, 무량판 건축물의 설계부터 준공 후까지 전 과정 안전관리를 강화하는 정책도 추진 중이다.
이런 흐름이 시사하는 바는 명확하다. 품질관리가 현장의 직관과 경험에 의존하던 시대에서, 데이터 기반의 실시간 관리 체계로 전환되고 있다는 것이다.
4. 품질관리 실패의 전형적 패턴 — “우리도 이렇게 망했다”
현장에서 반복적으로 목격하는 품질관리 실패 패턴들이 있다. 읽으면서 “어, 우리 얘기네”라는 분들이 반드시 계실 것이다.
패턴 1: ‘나중에 테스트로 잡지 뭐’ 증후군
일정 압박이 오면 가장 먼저 희생되는 것이 품질 활동이다. 코드 리뷰 건너뛰기, 단위 테스트 생략, 요구사항 검토 대충 넘어가기. “지금은 일단 만들고, 나중에 테스트에서 다 잡으면 되지”라는 논리다.
결과는? 테스트 단계에서 결함이 폭발한다. 그리고 아이러니하게도 일정이 더 지연된다. 처음부터 품질을 챙겼을 때보다 훨씬 더 많은 시간을 쓴다.
비유를 하자면, 건물을 지으면서 “나중에 페인트칠할 때 균열도 같이 메우면 돼”라고 하는 것과 같다. 균열은 페인트로 메울 수 없다.
패턴 2: 체크리스트 형식주의
품질 체크리스트가 있다. 매 단계마다 체크한다. 그런데 막상 보면 체크리스트 항목들이 실질적인 내용 확인 없이 기계적으로 체크되고 있다. “이 문서 리뷰 완료했나요?” “네.” 그게 끝이다. 무엇을 리뷰했는지, 무슨 이슈가 있었는지, 어떻게 해결했는지는 기록이 없다.
이런 체크리스트는 오히려 해롭다. “우리는 품질관리 하고 있어”라는 착각을 심어주면서 실제 문제를 놓치게 만든다.
패턴 3: 품질 담당자의 고립
품질 담당자 또는 테스터가 팀 내에서 ‘잔소리꾼’으로 취급받는 문화. “걔는 맨날 결함 올리고 뭐 하는 거야”라는 분위기가 형성되면, 품질 담당자는 점점 눈치를 보게 된다. 결함을 발견해도 보고를 주저하게 된다.
품질 담당자는 팀의 적이 아니라 팀의 안전장치다. 이 인식이 팀 전체에 공유되지 않으면 품질관리는 작동하지 않는다.
패턴 4: 품질 기준의 부재 또는 모호함
“품질 좋게 만들어 주세요.”
이게 품질 기준이 될 수 없다. 무엇이 ‘좋은’ 품질인지 숫자로 정의되지 않으면, 나중에 반드시 “이 정도면 됐다” vs “이건 아직 멀었다”의 싸움이 벌어진다. PM과 고객이 최종 산출물 앞에서 서로 다른 기준으로 이야기하면서 충돌한다.
품질 기준은 반드시 측정 가능하고 검증 가능한 형태로 정의되어야 한다.
패턴 5: 교훈(Lessons Learned)의 무덤
프로젝트가 끝나면 교훈 문서를 작성한다. 이번에 겪은 문제들, 잘 된 것과 안 된 것들을 정리한다. 그리고 그 문서는 서버 어딘가에 저장되어 다시는 열리지 않는다.
다음 프로젝트에서 똑같은 실수를 반복한다. “어, 이거 예전에도 이런 문제 있었던 것 같은데…”라고 하면서.
조직 수준의 품질 개선은 교훈이 다음 프로젝트에 실제로 적용될 때만 일어난다.
5. 방법론별 품질관리 — 워터폴, 애자일, 하이브리드
워터폴(Waterfall) 환경의 품질관리
전통적인 워터폴 방법론에서는 각 단계별 품질 게이트(Quality Gate)가 핵심이다. 요구사항 → 설계 → 개발 → 테스트 → 배포의 각 단계를 넘어가기 전에 공식적인 검토와 승인이 이루어진다.
장점은 명확하다. 각 단계에서 기준을 충족하지 못하면 다음 단계로 넘어가지 않으므로, 결함이 후속 단계로 전파되는 것을 막을 수 있다.
단점도 있다. 모든 것을 앞에서 완벽하게 정의하기 어려운 현실에서, 초기 요구사항이 잘못되면 그 오류가 전체 품질을 망친다. 그리고 테스트가 개발 이후에 집중되다 보니 후반부에 결함이 몰리는 경향이 있다.
애자일(Agile) 환경의 품질관리
애자일에서는 품질이 프로세스에 내재화되어야 한다. 매 스프린트마다 잠재적으로 출시 가능한 수준의 완성도를 갖춰야 하기 때문이다.
주요 애자일 품질 실천법들:
TDD(Test Driven Development, 테스트 주도 개발): 코드를 작성하기 전에 테스트를 먼저 작성한다. 코드가 무엇을 해야 하는지를 테스트로 명확히 정의한 다음, 그 테스트를 통과하는 코드를 작성한다. 처음엔 번거롭지만, 장기적으로 코드 품질과 회귀 테스트 커버리지를 획기적으로 높인다.
BDD(Behavior Driven Development, 행동 주도 개발): TDD를 비즈니스 언어 수준으로 끌어올린 방식. 개발자, 테스터, 비즈니스 관계자가 함께 “이 기능이 어떻게 동작해야 하는가”를 시나리오 형태로 정의한다. 요구사항의 명확성을 높이고 오해를 줄인다.
데피니션 오브 던(Definition of Done, DoD): “완료”가 무엇인지를 명확히 정의한다. 기능이 구현됐다고 완료가 아니다. 코드 리뷰 통과, 단위 테스트 통과, 인수 테스트 통과, 문서화 완료 — 이 모든 것이 충족됐을 때 비로소 ‘완료’다.
지속적 통합(CI)과 자동화 테스트: 코드 변경이 있을 때마다 자동으로 빌드하고 테스트를 실행한다. 결함을 코드 커밋 직후에 발견하므로 수정 비용이 최소화된다.
하이브리드 방법론에서의 품질관리
요즘 현장에서 가장 많이 보이는 형태다. 대규모 요구사항 확정은 워터폴 방식으로, 실제 개발은 애자일 방식으로 진행하는 혼합 접근법이다.
하이브리드 환경에서 품질관리의 핵심 과제는 일관성이다. 워터폴 단계와 애자일 단계 사이에서 품질 기준이 흔들리지 않도록 하는 것, 그리고 각 방식의 품질 산출물이 서로 연결되도록 하는 것이 중요하다.
6. 품질 비용(Cost of Quality) — 돈으로 설득하라
기술적 주장만으로는 경영진을 움직이기 어렵다. 품질에 투자해야 한다는 주장을 돈의 언어로 번역해야 한다. 그게 바로 품질 비용(CoQ, Cost of Quality) 개념이다.
품질 비용은 크게 두 가지로 나뉜다.
예방 비용(Prevention Costs): 결함이 발생하지 않도록 미리 투자하는 비용. 교육, 프로세스 설계, 도구 도입, 품질 계획 수립 등. 이것은 투자다.
실패 비용(Failure Costs): 결함이 발생한 후 처리하는 비용.
- 내부 실패 비용: 고객에게 전달되기 전에 발견된 결함 처리 비용. 재작업, 스크랩, 재테스트.
- 외부 실패 비용: 고객에게 전달된 후 발견된 결함 처리 비용. 클레임 처리, 환불, 법적 분쟁, 브랜드 손상. 이건 투자가 아니라 손실이다.
전통적으로 품질 전문가들은 총 품질 비용이 매출의 15~25% 수준이라고 추정한다. 그리고 이 비용의 대부분이 예방보다 실패에서 발생한다.
“품질관리에 예산을 더 주시오”가 아니라 “지금 품질 투자를 늘리면 실패 비용을 이만큼 줄일 수 있습니다”라고 말할 때 경영진의 귀가 열린다.
7. 실전에서 바로 쓸 수 있는 품질관리 체크리스트
착수 단계 (Initiation)
- 품질 목표가 프로젝트 목표와 연계되어 있는가
- 핵심 이해관계자의 품질 기대치가 파악되었는가
- 품질 담당자의 역할과 책임이 명확히 정의되었는가
- 적용할 표준 및 규정이 확인되었는가
기획 단계 (Planning)
- 품질관리 계획서가 작성되었는가
- 측정 가능한 품질 지표가 정의되었는가
- 품질 체크리스트가 마련되었는가
- 품질 보증 및 통제 활동 일정이 계획에 반영되었는가
- 결함 추적 시스템이 구축되었는가
실행 단계 (Execution)
- 동료 리뷰가 정기적으로 수행되고 있는가
- 결함이 즉시 기록되고 추적되고 있는가
- 품질 메트릭이 주기적으로 수집되고 있는가
- 품질 이슈가 적시에 보고되고 있는가
- 코드/산출물 기준이 일관되게 적용되고 있는가
감시 및 통제 단계 (Monitoring & Controlling)
- 품질 성과가 계획 대비 추적되고 있는가
- 결함 추이가 분석되고 있는가
- 근본 원인 분석(RCA)이 수행되고 있는가
- 품질 보고서가 정기적으로 발행되고 있는가
- 개선 조치가 실행되고 효과가 검증되고 있는가
종료 단계 (Closure)
- 모든 품질 기준이 충족되었음이 공식 확인되었는가
- 품질 교훈이 문서화되었는가
- 품질 메트릭 최종 보고서가 작성되었는가
- 프로세스 개선 사항이 조직 자산으로 등록되었는가
8. 2026년을 향한 품질관리의 변화 — 무엇을 준비해야 하는가
에이전틱 AI와 자율적 품질 감시
Gartner의 2026년 전략 기술 트렌드 보고서는 생성형 AI를 넘어 ‘에이전틱 AI(Agentic AI)’의 시대가 도래했음을 강조한다. AI는 더 이상 실험 대상이 아니라 운영의 기본값이 되었다.
품질관리에서 이것이 의미하는 바는 무엇인가? 단순히 AI가 결함을 탐지하는 수준을 넘어서, AI 에이전트가 결함을 발견하고, 분석하고, 수정 방안을 제안하고, 심지어 간단한 수정은 직접 실행하는 단계로 가고 있다는 것이다.
이미 일부 소프트웨어 회사들은 AI가 코드 리뷰를 수행하고, 결함을 자동으로 분류하고, 우선순위를 제안하는 시스템을 운영하고 있다. 인간 리뷰어의 역할이 ‘결함을 찾는 것’에서 ‘AI가 제안한 내용을 판단하고 승인하는 것’으로 변화하고 있다.
지속가능성과 품질의 결합
ESG가 화두가 되면서, 품질의 정의 자체가 확장되고 있다. 기술적으로 완벽한 제품이라도 환경에 해롭거나 사회적 책임을 다하지 못하면 ‘고품질’로 인정받지 못하는 시대가 되고 있다.
프로젝트 품질관리도 이에 대응해야 한다. 소프트웨어의 에너지 효율성, 데이터 처리의 탄소 발자국, 알고리즘의 공정성 — 이런 것들이 새로운 품질 지표로 부상하고 있다.
인간 중심 품질 관리 — 기술이 아무리 좋아도
마지막으로, 아무리 AI와 자동화가 발전해도 품질관리의 핵심은 결국 사람이라는 점을 강조하고 싶다.
AI는 워크플로를 사용자 행동에 맞게 조정하여 인지 부하를 최소화하고 오류를 줄인다. 그러나 이러한 개인화가 실제로 효과를 발휘하려면 직원의 적극적 참여가 필수적이다.
도구는 도구다. 품질에 대한 오너십을 가지고, 결함을 발견했을 때 보고하는 용기를 내고, 팀원의 실수를 공격이 아닌 개선의 기회로 보는 문화 — 이것이 어떤 도구나 프로세스보다 강력한 품질의 토대다.
9. 핵심 인사이트 — 현장에서 건져 올린 진실들
지금까지 긴 이야기를 했다. 마무리로 현장에서 뼈저리게 배운 인사이트들을 정리한다.
인사이트 1: 품질은 프로젝트의 ‘부산물’이 아니라 ‘목적지’다.
많은 팀이 “기능을 완성하면 품질은 자연히 따라올 것”이라고 믿는다. 아니다. 품질은 의도적으로 설계하고, 측정하고, 개선해야 도달할 수 있는 목적지다.
인사이트 2: 품질 문화는 PM이 만드는 게 아니라 PM이 촉진하는 것이다.
“내가 품질 담당자니까 내가 다 챙기겠다”는 생각은 위험하다. 품질에 대한 책임은 팀 전체에 분산되어야 한다. PM의 역할은 그 분산이 잘 일어나도록 환경을 만드는 것이다.
인사이트 3: 숫자로 말하지 못하는 품질은 품질이 아니다.
“전반적으로 품질이 좋아졌습니다”는 보고가 아니다. “결함 밀도가 지난 분기 대비 23% 감소했고, 코드 커버리지는 67%에서 82%로 향상됐습니다”가 보고다. 품질을 측정하지 않으면 개선할 수 없다.
인사이트 4: 나쁜 소식은 빨리 전달될수록 좋다.
품질 문제를 발견했을 때 “나중에 한꺼번에 말하지 뭐”라는 생각은 버려야 한다. 결함은 하루가 지날수록 수정 비용이 복리로 늘어난다. 나쁜 소식을 빨리 전달하는 팀이 결국 좋은 품질을 만들어낸다.
인사이트 5: 완벽함의 적은 ‘충분히 좋음’이 아니라 ‘아직 검토 안 됨’이다.
“이 정도면 충분히 좋은 품질 아닌가요?”라는 질문은 합리적일 수 있다. 그러나 “아직 검토하지 않았으니 일단 넘어가죠”는 품질의 무덤이다. 의식적으로 “충분히 좋다”고 판단한 것과, 검토 자체를 생략한 것은 전혀 다른 결과를 낳는다.
인사이트 6: AI는 품질관리를 대체하지 않는다, 증폭시킨다.
좋은 품질관리 문화와 프로세스 위에 AI를 올리면 강력해진다. 나쁜 품질관리 문화 위에 AI를 올리면 나쁜 결과가 더 빠르게 양산된다. AI는 증폭기다. 방향을 정하는 것은 여전히 인간이다.
마치며 — 품질은 결국 태도다
오래전 선배 PM에게 들은 말이 아직도 기억에 남는다.
“품질관리를 잘하는 팀과 못하는 팀의 차이는 도구나 방법론에 있지 않아. 팀원들이 자기 일에 얼마나 자부심을 갖느냐에 있어.”
처음엔 추상적으로 들렸다. 지금은 이 말의 뜻을 완전히 이해한다. 자기가 만든 것에 자부심을 갖는 사람은 결함을 그냥 넘기지 않는다. 테스트를 귀찮아하지 않는다. 코드 리뷰에서 “이건 제가 잘 이해 못했는데 설명해 주실 수 있나요?”라고 당당히 묻는다.
품질관리는 결국 팀 문화의 문제다. 그리고 그 문화는 리더가 어떻게 행동하느냐에서 시작된다.
오늘 여러분의 프로젝트에서 품질은 어디에 있는가? 서랍 속 체크리스트 파일 안에만 있지는 않은가? 그 질문에서 출발하면 된다.