PDSA와 하네스는 왜 같은 모양으로 진화하는가: 품질을 만드는 네 가지 운영체계

PDSA의 학습 루프와 개발 하네스의 검증 루프가 닮아가는 이유를 살펴보고, 식스 시그마·린·겅호를 품질 문제에 맞게 조합하는 실전 프레임을 제안한다.

PDSA와 하네스는 왜 같은 모양으로 진화하는가: 품질을 만드는 네 가지 운영체계

품질 문제가 생기면 조직은 흔히 도구부터 찾는다. 테스트 커버리지를 올리고, 대시보드를 붙이고, 회의를 하나 더 만든다. 그런데 도구의 수와 학습의 속도는 같은 말이 아니다. 더 많은 검사가 더 나은 품질을 보장하지도 않는다. 진짜 차이는 관찰한 사실을 다음 행동으로 바꾸는 폐회로가 있느냐에서 난다.

PDSA와 개발 하네스가 흥미롭게 만나는 지점이 여기다. 하나는 품질경영에서 발전한 학습 사이클이고, 다른 하나는 소프트웨어를 반복 가능하게 실행·시험·평가하는 기술 장치다. 기원은 다르지만 복잡성과 불확실성을 다루다 보면 둘은 비슷한 구조로 수렴한다. 가설을 명시하고, 작은 변화를 실행하고, 결과를 증거로 판정하고, 배운 것을 다음 규칙에 반영한다.

PDSA의 핵심은 검사보다 학습이다

PDSA는 Plan–Do–Study–Act의 약자다. Plan에서 목표와 이론, 성공 지표를 세우고, Do에서 작은 규모로 실행한다. Study에서는 예상과 실제 결과를 비교해 이론이 맞았는지 공부하고, Act에서는 배운 내용을 표준화하거나 가설을 고쳐 다음 사이클로 넘긴다. Deming Institute가 강조하듯 세 번째 단계가 단순한 Check가 아니라 Study인 이유는 성공·실패 판정에 머물지 않고 새로운 지식을 만드는 데 있다.

좋은 개선 루프는 “통과했는가?”에서 끝나지 않는다. “왜 이런 결과가 나왔고, 다음 실험의 가설은 무엇인가?”까지 답한다.

따라서 PDSA는 거대한 전사 혁신 프로젝트보다 작고 빠른 실험에 특히 강하다. 배포 오류를 줄이고 싶다면 전 조직의 절차를 한 번에 바꾸기보다 한 서비스에서 배포 전 점검표를 시험하고, 실패율과 리드타임을 관찰한 뒤 확대한다. 다만 기록과 연속 측정 없이 이름만 PDSA라고 붙이면 사후 회고와 다를 바 없다. 체계적 문헌 검토에서도 반복 사이클, 지속적 데이터 수집, 소규모 시험, 이론에 근거한 예측이 자주 빠지는 문제가 지적됐다.

하네스는 학습 루프를 실행 가능한 구조로 바꾼다

개발에서 하네스는 코드를 둘러싼 실행 장치다. 입력 데이터, 격리 환경, 테스트, 정적 분석, 보안 점검, 성능 측정, 결과 기록을 같은 방식으로 반복한다. 좋은 하네스는 “작동하는 것 같다”를 “어떤 조건에서 무엇이 검증됐는가”로 바꾼다.

최근의 PDCA Harness는 이 생각을 더 직접적으로 구현한다. 명확한 브리프를 Plan으로, 제한된 범위의 구현을 Do로, 결정론적 게이트와 독립 리뷰를 Check로, 반복적으로 드러난 누락을 새 규칙과 게이트로 만드는 일을 Act로 둔다. 특히 수정 전에는 실패하고 수정 후에는 성공하는 red→green 증거, 작성자와 시야를 분리한 리뷰, 사람의 최종 승인을 결합한다. 자동화가 사람을 없애는 것이 아니라 사람이 판단해야 할 지점을 더 선명하게 만드는 설계다.

사람의 PDSA 학습 루프와 자동화된 개발 하네스가 검증된 학습으로 수렴하는 카툰
서로 다른 출발점: 왼쪽은 가설과 실험, 오른쪽은 브리프와 자동 게이트. 두 흐름은 검증 가능한 학습이라는 같은 중심에 도달한다.

수렴 진화: 닮은 모양이 생기는 네 가지 압력

여기서 말하는 수렴 진화는 생물학적 계통관계를 주장하는 표현이 아니라 서로 다른 전통이 같은 운영 문제를 만나 유사한 구조를 채택한다는 비유다. 두 접근을 닮게 만드는 압력은 네 가지다.

  1. 불확실성: 계획만으로 정답을 알 수 없으므로 작은 실험과 빠른 피드백이 필요하다.
  2. 재현성: 사람의 기억이나 감각에 의존한 판정은 반복되지 않으므로 명시적 지표와 자동 게이트가 필요하다.
  3. 변화의 부작용: 한 결함을 고치다가 다른 결함을 만들 수 있으므로 기준선과 회귀 검사가 필요하다.
  4. 학습의 축적: 한 번의 성공을 영웅담으로 남기지 않고 체크리스트·테스트·표준·관측 항목으로 고정해야 한다.

이 관계는 일방향이 아니다. 하네스가 모델이나 개발자의 실행 품질을 높이고, 그 과정에서 생긴 성공·회귀·근접 실패가 다음 하네스를 개선하는 데이터가 된다. 2026년 공개된 HELIX 연구는 이를 model–harness co-evolution으로 다뤘다. 연구의 특정 수치를 모든 조직에 일반화할 수는 없지만, 실행 환경과 실행 주체가 서로를 개선한다는 관점은 PDSA의 “학습을 다음 사이클의 설계에 반영한다”는 원리와 맞닿아 있다.

대표 방법론은 경쟁자가 아니라 서로 다른 렌즈다

PDSA, 식스 시그마, 린, 겅호가 하나의 소프트웨어 품질 흐름을 지원하는 카툰
품질 개선 도구상자: 실험, 변동 축소, 낭비 제거, 자율과 격려는 같은 일을 하는 기법이 아니라 서로 다른 실패 원인을 맡는다.

1. PDSA: 무엇이 효과가 있는지 아직 모를 때

질문: 이 변화가 실제로 더 나은 결과를 만드는가? 작은 범위에서 예측과 관찰을 비교하며 학습한다. 빠르게 시험할 수 있고 인과 가설이 아직 불완전한 문제에 적합하다.

2. 식스 시그마와 DMAIC: 변동과 결함의 원인을 데이터로 좁힐 때

DMAIC는 Define–Measure–Analyze–Improve–Control의 구조로 기존 프로세스의 성능 문제를 다룬다. 결함률, 지연 시간, 재작업률처럼 측정 가능한 출력의 변동이 크고 원인을 구분해야 할 때 강하다. PDSA가 학습의 범용 엔진이라면 DMAIC는 측정과 원인 분석, 개선 후 통제를 더 촘촘하게 만든 프로젝트 구조다. 소프트웨어에서는 배포 실패율, 장애 복구 시간, flaky test 비율처럼 반복 관측 가능한 문제에 잘 맞는다.

3. 린과 카이젠: 가치 흐름에서 낭비와 대기를 줄일 때

린은 고객 관점의 가치를 정하고, 가치 흐름을 보고, 흐름을 막는 비가치 활동을 제거한다. 인수인계 대기, 중복 승인, 지나치게 큰 배치, 사용되지 않는 기능, 반복 수작업이 주요 표적이다. 카이젠은 현장의 작은 개선을 지속적으로 쌓는 태도와 실천 방식이다. 린이 “무엇을 없애야 흐름이 좋아지는가”를 묻는다면 PDSA는 “그 제거가 실제 결과를 개선했는가”를 시험한다.

4. 겅호: 방법론을 움직이는 문화적 동력이 부족할 때

겅호는 식스 시그마처럼 통계적 품질관리 방법론은 아니다. Ken Blanchard와 Sheldon Bowles가 대중화한 프레임은 다람쥐의 정신, 비버의 방식, 기러기의 선물이라는 세 비유를 사용한다. 각각 가치 있는 일이라는 공동 목적, 목표와 경계 안에서의 자율, 진심 어린 격려를 뜻한다. 지표와 절차가 있어도 팀이 목적을 이해하지 못하고 권한이 없거나 실패가 처벌로 돌아오면 개선 루프는 멈춘다. 겅호는 그 실행 조건을 다룬다.

어떤 문제에 무엇을 써야 하나

  • 원인도 해법도 불확실하다: PDSA로 작은 실험을 설계한다.
  • 결함과 편차가 반복되며 데이터가 쌓인다: DMAIC와 통계적 공정 관리를 사용한다.
  • 대기·인수인계·불필요한 작업이 길다: 린 가치 흐름을 그려 병목과 낭비를 제거한다.
  • 기술적 해법은 알지만 팀이 움직이지 않는다: 겅호의 목적·자율·격려를 리더십 설계에 적용한다.
  • 개선이 사람의 기억에만 남는다: 하네스에 테스트, 게이트, 관측, 증거 보존을 넣는다.

하나만 선택할 필요는 없다. 예를 들어 배포 실패가 늘었다면 DMAIC로 변동과 주요 원인을 좁히고, 린으로 승인 대기와 큰 배치를 줄이며, PDSA로 카나리 배포와 새 점검 규칙을 소규모 시험한다. 검증된 변경은 하네스의 자동 게이트로 고정한다. 리더는 목표와 허용 범위를 명확히 하되 해결 방법은 팀이 선택하게 하고, 유용한 학습을 공개적으로 격려한다.

개발팀을 위한 최소 운영 설계

  1. Plan: 문제를 한 문장으로 쓰고, 예상 결과와 단일 핵심 지표를 정한다.
  2. Do: 한 서비스·한 팀·한 배포 경로처럼 되돌릴 수 있는 작은 범위에서 실행한다.
  3. Study: 기준선과 결과를 비교한다. 통과 여부뿐 아니라 예상과 달랐던 이유를 기록한다.
  4. Act: 효과가 있으면 테스트·정책·템플릿·관측 항목으로 하네스에 넣고, 없으면 가설을 수정한다.
  5. Control: 개선이 유지되는지 추세를 보고, 새 규칙이 오히려 흐름을 막지 않는지 정기적으로 폐기 여부를 검토한다.
  6. Culture: 지표를 사람을 벌주는 도구로 쓰지 않고 시스템을 배우는 증거로 다룬다.

마지막 항목이 중요하다. 측정값이 평가와 처벌에 바로 연결되면 사람은 품질보다 숫자를 최적화한다. 실패를 숨기지 않아도 되는 심리적 안전, 명확한 목적, 경계 안의 자율성이 있어야 하네스가 현실을 비추는 계기가 된다.

결론: 품질은 기법의 이름이 아니라 학습이 닫히는 방식이다

PDSA와 하네스의 닮음은 우연한 유행이 아니다. 복잡한 시스템에서 신뢰를 만들려면 가설, 실행, 증거, 적응이 순환해야 하기 때문이다. 식스 시그마는 변동을 읽는 눈을, 린은 흐름을 보는 눈을, 겅호는 사람들이 개선에 참여할 조건을 제공한다. 하네스는 그 배움을 매번 같은 방식으로 실행하고 다음 작업까지 보존한다.

좋은 조직은 방법론을 많이 아는 조직이 아니다. 지금의 실패가 어떤 종류인지 구분하고, 가장 작은 학습 루프를 돌린 뒤, 검증된 배움을 시스템에 남기는 조직이다.

참고 자료