품질 문화를 조직에 뿌리내리는 법
진짜 품질은 프로세스가 아닌 마인드셋에서 시작됩니다
품질 문화, 왜 이렇게 어려울까?
"우리 팀도 품질이 중요하다는 건 알아요. 근데..."
QA 리더로 일하면서 가장 많이 듣는 말입니다. 모두가 품질의 중요성을 알지만, 정작 품질 문화를 만드는 건 왜 이렇게 어려울까요?
답은 간단합니다.
품질을 '누군가의 일'로 생각하기 때문입니다. QA팀이 있으니 품질은 QA팀이 책임지는 것, 개발자는 기능 구현에만 집중하면 되는 것. 이런 사일로 사고방식이 진짜 품질 문화의 가장 큰 적입니다.
* 사일로(Silo): 조직 내 부서나 팀이 서로 소통하지 않고 독립적으로 일하는 현상. 마치 곡물 저장고(사일로)처럼 각자 격리되어 있다는 의미에서 유래했습니다.
품질의 재정의: "버그 찾기"에서 "가치 전달"로
전통적 관점 vs 현대적 관점
Before (전통적 QA)
개발 완료 후 테스트
버그 발견이 주 목적
QA팀만의 책임
문제 지적자 역할
After (품질 문화)
기획 단계부터 품질 고려
사용자 가치 전달이 목적
모든 구성원의 책임
품질 촉진자 역할
한 스타트업에서 있었던 일입니다. 개발팀이 3주간 열심히 만든 기능을 출시했는데, 사용자들이 전혀 사용하지 않았습니다. 버그는 없었지만 실패한 기능이었죠. 이때 CTO가 한 말이 인상적이었습니다.
"버그 없는 쓸모없는 기능보다, 약간의 버그가 있더라도 사용자가 원하는 기능이 낫다."
흥미롭게도, 때로는 사소한 버그가 고객과의 소통 창구가 되기도 합니다. 완벽해 보이는 제품은 오히려 사용자가 피드백을 주기 어렵게 만들 수 있습니다. "이미 완성된 것 같은데 내가 뭘 더 말하겠어?"라는 심리적 장벽이 생기죠.
반면 작은 버그를 제보하면서 시작된 대화가 "그런데 이 기능이 이렇게 바뀌면 더 좋을 것 같아요"로 이어지는 경우를 많이 봤습니다. 버그 리포트가 단순한 문제 제기를 넘어 사용자의 진짜 니즈를 파악하는 기회가 되는 것입니다.
품질 문화는 여기서 시작합니다. 품질을 단순히 '결함 없음'이 아닌 '사용자 가치 전달'로 재정의하는 것입니다. 그리고 그 과정에서 사용자와의 지속적인 소통이 진짜 품질을 만든다는 것을 이해하는 것입니다.
Small Wins: 작은 성공부터 시작하기
파일럿 프로젝트 전략
품질 문화를 한 번에 조직 전체에 이식하려 하면 실패합니다. 왜일까요?
사람들은 변화를 두려워합니다. 특히 "지금까지 잘 해왔는데 왜 바꿔야 하지?"라는 생각이 강할 때 더욱 그렇습니다. 게다가 대규모 변화는 리스크가 큽니다. 실패했을 때 돌아갈 곳이 없고, 실패의 영향 범위가 너무 넓어 조직 전체가 혼란에 빠질 수 있습니다.
대신 이렇게 시작해보세요. 작은 성공을 만들고, 그 성공이 자연스럽게 퍼져나가도록 하는 것입니다.
Week 1-2: 자원자 모집
"다음 스프린트에 새로운 품질 접근법을 시도해볼 자원자 2-3명을 찾습니다. 실패해도 괜찮습니다."
단순한 참여자가 아닌, 자원자를 찾는 이유는 간단합니다. 강제로 참여한 사람보다 자발적으로 참여한 사람이 더 열정적이고, 실패해도 비난받지 않는다는 심리적 안전감이 있기 때문입니다.
Week 3-4: 작은 실험
일일 5분 품질 체크인 미팅
코드 리뷰에 테스트 시나리오 추가
개발자-QA 페어 테스팅 30분
버그 바운티 프로그램 (재미요소 추가)
Week 5-6: 결과 공유
프로세스 개선 효과 (정량적)
팀원들의 피드백 (정성적)
배운 점과 개선할 점
중요한 것은 이슈 수가 아닙니다.
발견한 버그가 3개든 30개든 그것이 성공의 기준은 아닙니다. 오히려 다음과 같은 질문이 더 중요합니다.
팀원들이 품질에 대해 더 많이 생각하게 되었는가?
사용자 관점에서 생각하는 습관이 생겼는가?
품질 활동이 부담이 아닌 자연스러운 일상이 되었는가?
실제 사례: 5분 품질 스탠드업
한 팀에서 시작한 "5분 품질 스탠드업"이 전사로 확산된 사례입니다.
형식
매일 오전 스탠드업 후 5분 추가
어제 발견한 품질 이슈 1개 공유 (버그가 아니어도 OK)
오늘 주의할 품질 포인트 1개 선언
3개월 후 변화
"어? 이거 사용자가 헷갈릴 수 있겠네요" 같은 대화 증가
개발 중 서로의 코드를 자연스럽게 리뷰
QA 엔지니어에게 미리 테스트 시나리오 문의
작은 성공이 입소문을 타고 다른 팀들이 "우리도 해보고 싶다"고 먼저 찾아왔습니다. 강제하지 않았는데 자발적으로 퍼져나간 것이죠.
품질 앱배서더 네트워크 구축하기
각 팀의 품질 앰배서더
QA 리더 혼자서는 품질 문화를 만들 수 없습니다. 왜 그럴까요?
첫째, 물리적 한계가 있습니다. 한 사람이 모든 팀, 모든 프로젝트를 커버할 수 없습니다.
둘째, 심리적 거리감이 존재합니다. "QA팀에서 또 뭘 시키네"라는 반감이 생길 수 있습니다.
셋째, 컨텍스트 부족입니다. 각 팀의 상황과 도메인을 QA 리더가 모두 이해하기는 어렵습니다.
그래서 각 팀에 품질 앰배서더를 육성해야 합니다. 품질 앰배서더는 QA 리더의 대리인이 아닙니다. 그들은 자기 팀의 품질 전도사이자, 품질 문화의 현지 번역가입니다. (품질 앰배서더는 가칭입니다. 다른 명칭도 좋습니다. 의미하는 바가 일치되면 됩니다.)
품질 앰배서더의 역할
팀 내 품질 관련 질문의 첫 번째 연락처
주간 품질 메트릭 수집 및 공유
팀 회고에서 품질 이슈 제기
다른 팀 앰배서더와 모범 사례 공유
팀 특성에 맞는 품질 practice 제안
앰배서더 선정 기준
[ X ] 기술력이 뛰어난 사람
[ O ] 영향력과 신뢰가 있는 사람
[ X ] QA 경험이 많은 사람
[ O ] 품질에 관심이 많은 사람
[ X ] 시니어 개발자
[ O ] 열정적인 누구나
실제로 한 회사에서는 2년차 주니어 개발자가 품질 앰배서더가 되어 팀 전체의 테스트 문화를 바꾼 사례도 있습니다. 중요한 것은 경력이 아니라 열정입니다.
앰배서더 네트워크 운영법
월 1회 품질 앰배서더 미팅 (30분) - agenda 예시
1. 체크인 (5분)
- 이번 달 우리 팀의 품질 하이라이트
2. 성공 사례 공유 (10분)
- 각 팀에서 1개씩 품질 개선 사례
- "이렇게 하니 좋더라" 경험 공유
3. 도전 과제 논의 (10분)
- 현재 겪고 있는 품질 이슈
- 크로스팀 협력 필요 사항
4. 다음 달 실험 (5분)
- 새로 시도해볼 품질 practice
- 누가 먼저 시도해볼지 결정
앰배서더 지원 프로그램
월 1회 외부 품질 교육 지원
품질 관련 도서 구매 지원
컨퍼런스 참가 우선권
품질 개선 프로젝트 시간 할당 (주 4시간)
가시화: 품질을 눈에 보이게 만들기
품질 대시보드의 힘
"측정하지 않으면 관리할 수 없다"는 피터 드러커의 말이 있습니다. 하지만 더 중요한 진실이 있습니다.
"보이지 않으면 신경쓰지 않는다"
품질도 마찬가지입니다. 품질이 추상적인 개념으로 남아있는 한, 사람들은 우선순위에서 뒤로 밀어냅니다. 하지만 품질을 숫자로, 그래프로, 색깔로 보여주면 갑자기 관심이 생깁니다. "어? 우리 팀 빨간색이네? 이거 왜 이래?" 같은 반응이 나오기 시작합니다.
필수 품질 메트릭 Top 5
1. 배포 성공률
전체 배포 중 롤백되지 않은 비율
목표: > 95%
왜 중요한가: 배포 품질의 직접적 지표
2. 평균 버그 해결 시간
발견부터 수정 완료까지 소요 시간
목표: Critical 24시간, Major 3일, Minor 1주
왜 중요한가: 팀의 반응성과 우선순위 관리 능력
3. 테스트 커버리지
단위 테스트 + 통합 테스트 커버리지
목표: 핵심 기능 80% 이상
왜 중요한가: 안전망의 촘촘함
4. 고객 발견 버그 비율
전체 버그 중 고객이 먼저 발견한 비율
목표: < 20%
왜 중요한가: 내부 품질 프로세스의 효과성
5. 품질 리드 타임
코드 커밋부터 프로덕션 배포까지
목표: 지속적 단축
왜 중요한가: 품질과 속도의 균형
주의사항
이슈 수에 집착하지 마세요. 버그를 100개 찾았다고 품질이 좋은 것도, 10개만 찾았다고 나쁜 것도 아닙니다. 중요한 것은 추세와 맥락입니다.
팀 품질 스코어카드
매주 금요일, 각 팀의 품질 스코어를 공유합니다.
품질 점수 산정 기준
품질 점수 = (배포 성공률 × 30%)
+ (버그 해결 속도 × 25%)
+ (테스트 커버리지 × 20%)
+ (코드 리뷰 참여율 × 15%)
+ (품질 활동 참여도 × 10%)
(A+: 95점 이상 / A : 90-94점 / B+: 85-89점 / B : 80-84점 / C : 70-79점 / D : 70점 미만)
Week 45 품질 스코어카드
Payment Team
- 배포 성공률: 100% (30/30점)
- 버그 해결 속도: 평균 18시간 (23/25점)
- 테스트 커버리지: 82% (16/20점)
- 코드 리뷰 참여율: 95% (14/15점)
- 품질 활동: 매우 적극적 (10/10점)
- 종합 점수: 93점 (A)
User Team
- 배포 성공률: 85% (25/30점)
- 버그 해결 속도: 평균 72시간 (15/25점)
- 테스트 커버리지: 65% (13/20점)
- 코드 리뷰 참여율: 70% (10/15점)
- 품질 활동: 보통 (5/10점)
- 종합 점수: 68점 (D)
- Action: 테스트 자동화 workshop 예정
중요한 점
이것은 팀을 평가하거나 처벌하기 위함이 아니라, 어디에 도움이 필요한지 파악하고 지원하기 위함입니다.
프로세스에 품질 체크포인트 삽입하기
소프트웨어 개발 생명주기 이해하기
품질 게이트를 설명하기 전에, 먼저 소프트웨어 개발 생명주기(SDLC)를 간단히 이해해봅시다.
[ 전통적인 Waterfall 모델 ] 요구사항 분석 → 설계 → 개발 → 테스트 → 배포 → 유지보수
[ 현대적인 Agile/DevOps 모델 ] 기획 ↔ 설계 ↔ 개발 ↔ 테스트 ↔ 배포 (반복적이고 순환적)
현대적 개발에서는 각 단계가 명확히 구분되지 않고 지속적으로 반복됩니다. 그래서 품질 체크포인트도 각 단계에 자연스럽게 녹아들어야 합니다.
개발 생명주기별 품질 게이트
품질을 사후 활동이 아닌 전 과정에 녹여넣는 것이 핵심입니다.
1. 기획 단계 - "품질 리스크 평가"
품질 체크포인트
[ ] 이 기능의 실패 시 비즈니스 영향도는?
- High: 매출/핵심 기능 직접 영향
- Medium: 사용자 경험 저하
- Low: 부가 기능 영향
[ ] 예상되는 사용자 시나리오 3가지는?
[ ] 테스트 가능한 수용 기준이 명확한가?
[ ] 엣지 케이스와 예외 상황을 고려했는가?
2. 설계 단계 - "테스트 가능성 리뷰"
품질 체크포인트
[ ] 단위 테스트 전략 수립
- 테스트 가능한 구조인가?
- Mock/Stub 전략은?
[ ] 통합 테스트 포인트 식별
- 외부 시스템 연동 부분
- 데이터 흐름 검증 지점
[ ] 모니터링 지표 정의
- 성능 메트릭
- 비즈니스 메트릭
[ ] 롤백 계획 수립
3. 개발 단계 - "지속적 품질 체크"
품질 체크포인트
[ ] TDD 또는 테스트 동시 작성
[ ] 일일 코드 리뷰
- 로직 검증
- 가독성 체크
- 보안 취약점 검토
[ ] CI 파이프라인 통과
- 빌드 성공
- 린트 규칙 통과
- 테스트 통과
[ ] 페어 프로그래밍 (복잡한 로직)
4. 배포 전 - "품질 사인오프"
품질 체크포인트
[ ] 자동화 테스트 100% 통과
[ ] 수동 탐색 테스트 완료
[ ] 성능 테스트 기준 충족
- 응답 시간 < 목표치
- 동시 사용자 처리 능력
[ ] 보안 체크리스트 확인
[ ] 롤백 계획 검증
[ ] 스테이징 환경 최종 확인
5. 배포 후 - "품질 모니터링"
품질 체크포인트
[ ] 에러율 모니터링 (첫 24시간 집중)
[ ] 핵심 지표 추적
- 응답 시간
- 에러율
- 사용자 행동 패턴
[ ] 사용자 피드백 수집
[ ] 품질 회고 미팅 (1주일 후)
실패를 학습 기회로 전환하기
Blameless Post-Mortem 문화
버그는 숨기는 것이 아니라 배우는 기회입니다. 하지만 많은 조직에서 장애가 발생하면 첫 번째로 하는 일이 "누구 잘못인가?"를 찾는 것입니다. 이것은 최악의 접근법입니다.
Blameless Post-Mortem의 핵심
"누가(Who)"가 아닌 "무엇(What)"과 "왜(Why)"에 집중합니다.
사람을 비난하면 다음과 같은 일이 발생합니다.
실수를 숨기게 됨
방어적인 태도 증가
혁신 시도 감소
팀워크 붕괴
Post-Mortem에서 다루는 내용
1. 타임라인 재구성
장애 타임라인
- 14:23 - 첫 번째 알람 발생
- 14:25 - 온콜 엔지니어 확인 시작
- 14:30 - 장애 범위 파악 (결제 시스템)
- 14:45 - 원인 파악 (DB connection pool 고갈)
- 15:00 - 임시 조치 (커넥션 풀 확장)
- 15:15 - 서비스 정상화
- 15:30 - 근본 원인 수정 배포
2. 영향 범위 분석
비즈니스 영향
- 영향받은 사용자: 약 5,000명
- 실패한 거래: 342건
- 예상 손실: 약 500만원
- 고객 문의: 127건
- 브랜드 신뢰도 영향: 측정 중
3. 5 Whys 분석
문제: 결제 시스템 30분 장애
- 데이터베이스 연결이 끊어졌다. → Why 1. connection pool이 고갈되었다.
- connection pool이 고갈되었다. → Why 2.: 느린 쿼리가 연결을 잡고 있었다.
- 느린 쿼리가 연결을 잡고 있었다. → Why 3. 인덱스가 없는 테이블 조인이 있었다.
- 인덱스가 없는 테이블 조인이 있었다. → Why 4. 최근 추가된 기능의 쿼리 최적화를 놓쳤다.
- 쿼리 최적화를 놓쳤다. → Why 5. 코드 리뷰에서 쿼리 성능을 체크하는 프로세스가 없었다.
근본 원인: 코드 리뷰 프로세스의 빈틈
4. 교훈과 개선 조치
배운 점
1. 쿼리 성능은 기능만큼 중요하다.
2. 코드 리뷰 체크리스트가 불완전했다.
3. 스테이징 환경이 프로덕션과 달라 문제를 못 잡았다.
개선 조치 (Action Items)
5. 긍정적인 점 찾기
Well Done
- 온콜 대응 시간 2분 (목표: 5분)
- 정확한 원인 파악 (20분 내)
- 고객 커뮤니케이션 신속 처리
- 팀워크를 통한 빠른 해결
실패 박물관 만들기
한 회사에서 시작한 "실패 박물관" 사례
형식
매월 마지막 금요일 30분
각 팀에서 1개의 실패 사례 발표
실패에서 배운 점 공유
가장 큰 교훈을 준 실패에 "이달의 실패상" 수여
발표 템플릿
무엇을 시도했는가? (1분)
어떻게 실패했는가? (2분)
무엇을 배웠는가? (2분)
다음엔 어떻게 할 것인가? (1분)
효과
실패를 숨기지 않는 문화 형성
다른 팀의 실수에서 배우기
심리적 안전감 증대
"실패해도 괜찮아"라는 메시지
경영진의 지원 확보하기
품질의 비즈니스 가치 증명
경영진은 숫자를 좋아합니다. 품질을 비즈니스 언어로 번역하세요.
품질 ROI 계산 예시
프로덕션 버그 1개당 비용
- 개발자 디버깅 시간: 평균 4시간 = 20만원
- QA 재테스트 시간: 평균 2시간 = 8만원
- 고객 지원 처리: 평균 10건 = 10만원
- 고객 이탈 가능성: 5% = 50만원
- 브랜드 신뢰도 하락: 측정 어려움 (잠재 비용)
총 비용: 약 88만원 + α
월 평균 프로덕션 버그 20개 = 1,760만원
품질 개선으로 50% 감소 시 = 월 880만원 절감
연간 절감액: 약 1억 560만원
품질 개선 투자비: 약 3,000만원
ROI: 352%
경영진 대시보드 구성
주간 경영진 품질 리포트 (1 page)
Week 45 품질 Executive Summary
비즈니스 임팩트
- 품질 이슈로 인한 손실: 320만원 (전주 대비 -45%)
- 고객 이탈률: 2.3% (전주 대비 -0.5%)
- NPS 스코어: 72 (전주 대비 +3)
긍정적 지표
- 배포 성공률 95% (전주 대비 +5%)
- 고객 만족도 4.5/5.0 유지
- 자동화 테스트로 120시간 절약
주의 필요 영역
- 결제 모듈 안정성 (버그 3건)
- 모바일 앱 크래시율 0.5% (목표: 0.3%)
다음 주 집중 영역
- 결제 모듈 리팩토링 (예상 효과: 장애 70% 감소)
- 모바일 테스트 커버리지 확대
품질 투자 대비 효과
- 이번 달 품질 투자: 500만원
- 예방된 장애 비용: 2,300만원
- ROI: 460%
지속 가능한 품질 문화 만들기
품질 문화의 성숙도 단계
조직의 품질 문화 수준을 진단하고 다음 단계로 나아가기 위한 로드맵입니다.
Level 0: Oblivious (무관심)
품질이 무엇인지 모름.
버그는 당연한 것으로 받아들임.
고객 불만에만 반응
테스트 = 시간 낭비라고 생각
개선 의지 없음.
Level 1: Chaotic (혼돈)
품질은 우연히 달성됨.
영웅적인 개인의 노력에 의존
프로세스 없음.
화재 진압식 대응
반복되는 같은 실수
Level 2: Reactive (반응적)
문제 발생 후 대응
QA팀만 품질 책임
기본적인 테스트 존재
버그 추적 시작
일부 문서화
Level 3: Proactive (능동적)
품질 체크포인트 존재
팀 전체가 품질 인식
테스트 자동화 시작
코드 리뷰 정착
기본 메트릭 추적
Level 4: Managed (관리됨)
품질 메트릭 기반 의사결정
지속적 개선 프로세스
자동화 테스트 80% 이상
품질 예측 가능
모든 팀원이 품질 챔피언
Level 5: Optimized (최적화)
품질이 DNA에 각인됨.
혁신과 품질의 균형
예방 중심 문화
AI/ML 활용한 품질 예측
업계 벤치마크 수준
Level 6: Leading (선도)
업계 품질 표준 선도
품질 혁신 창출
오픈소스 기여
품질 문화 전파
제로 디펙트 지향
성숙도 레벨 진단 체크리스트
현재 우리 조직은 어느 레벨일까요?
Level 0-1 신호
□ "테스트할 시간이 없어요"가 일상적
□ 프로덕션에서 처음 발견되는 버그가 대부분
□ 같은 종류의 버그가 반복 발생
□ QA가 뭐하는 팀인지 모르는 사람 존재
Level 2-3 신호
□ QA팀은 있지만 개발 완료 후에만 참여
□ 테스트는 하지만 대부분 수동
□ 버그는 추적하지만 분석은 안 함
□ 품질 메트릭이 있지만 활용 안 함
Level 4-5 신호
□ 모든 코드에 테스트 코드 존재
□ 품질 메트릭으로 의사결정
□ 장애 발생 전 예측 가능
□ 품질 개선 아이디어가 바텀업으로 제안
Level 6 신호
□ 다른 회사가 우리 품질 프로세스 벤치마킹
□ 품질 관련 오픈소스 프로젝트 운영
□ 품질 컨퍼런스 발표 요청 받음
□ 업계 품질 표준 제정 참여
다음 레벨로 가는 방법
Level 0→1: 인식 만들기
품질 비용 가시화
작은 성공 사례 만들기
경영진 설득
Level 1→2: 기초 다지기
QA 프로세스 수립
버그 추적 시스템 도입
기본 테스트 문서화
Level 2→3: 문화 시작
품질 챔피언 육성
코드 리뷰 도입
자동화 테스트 시작
Level 3→4: 체계화
품질 메트릭 대시보드
CI/CD 파이프라인 구축
전사 품질 목표 설정
Level 4→5: 최적화
AI/ML 도입
예측적 품질 관리
지속적 실험과 혁신
Level 5→6: 선도
품질 R&D 투자
외부 공유와 기여
산업 표준 참여
도구와 자동화로 품질 문화 강화하기
품질을 쉽게 만드는 도구들
좋은 도구는 품질 문화의 촉매제입니다. 하지만 도구는 수단일 뿐, 목적이 아닙니다.
필수 품질 도구 스택:
코드 품질
SonarQube: 코드 품질 자동 분석
ESLint/Prettier: 코드 스타일 통일
Git Hooks: 커밋 전 자동 검사
Danger JS: PR 자동 리뷰
테스트 자동화
Jest/Pytest: 단위 테스트
Cypress/Playwright: E2E 테스트
k6/JMeter: 성능 테스트
Postman/Newman: API 테스트
CI/CD 파이프라인
품질 게이트 예시:
- 코드 커밋 → 린트 체크 (1분)
- PR 생성 → 자동 테스트 실행 (5분)
- 머지 → 통합 테스트 (10분)
- 배포 → 스모크 테스트 (3분)
통과 기준:
- 테스트 커버리지 > 80%
- 코드 복잡도 < 10
- 중복 코드 < 5%
- 보안 취약점 0개
모니터링
Sentry: 에러 추적
Datadog/New Relic: 성능 모니터링
Hotjar/FullStory: 사용자 행동 분석
PagerDuty: 인시던트 관리
품질 문화는 하루아침에 만들어지지 않습니다. 작은 습관의 변화가 모여 큰 문화를 만듭니다.
제가 경험한 가장 성공적인 품질 문화 변화는 한 스타트업에서였습니다. 처음엔 "테스트는 사치"라고 생각하던 10명의 개발팀이, 1년 후에는 "테스트 없는 코드는 미완성"이라고 말하게 되었습니다.
비결은 간단했습니다.
작게 시작했습니다.
강요하지 않았습니다.
성공을 축하했습니다.
실패를 학습으로 전환했습니다.
꾸준히 지속했습니다.
기억할 세 가지
품질은 모두의 책임이다
- QA팀만의 일이 아닌 모두의 일
- 역할에서 품질 기여
측정할 수 없으면 개선할 수 없다
- 품질을 숫자로 보여주기
- 하지만 숫자가 전부는 아님
실패는 성장의 기회다
- Blame이 아닌 Learn
- 심리적 안전감이 핵심
품질 문화를 만드는 것은 마라톤과 같습니다. 처음엔 힘들지만, 일단 momentum이 생기면 관성의 법칙이 작동합니다. 그리고 어느 날, "우리가 원래 이렇게 일했나?" 싶을 정도로 자연스러워집니다.
가장 중요한 것은 시작하는 것입니다. 완벽한 계획을 기다리지 마세요. 내일 아침, 5분 품질 체크인부터 시작해보세요.
"Culture eats strategy for breakfast" - Peter Drucker
전략보다 문화가 중요합니다.
품질 전략을 세우기보다, 품질 문화를 만드세요.
그것이 진짜 경쟁력입니다.