(A-SPICE 7회차) SUP.1: QA는 왜 두 얼굴을 가졌을까?
✅ 7회차: QA는 왜 두 얼굴을 가졌을까?
양산 품질 vs 개발 품질, 품질보증의 두 가지 세계!
“저기요, QA 팀이 또 뭐라고 하는데요?”
“아 또 뭐 검사했어?”
🤭 아니, QA는 여러분의 친구입니다!
🎯 오늘의 주제: SUP.1 – 품질 보증(Quality Assurance)
A-SPICE에서 말하는 SUP.1은
개발 품질을 책임지는 품질보증 활동입니다!
그런데 여기서 잠깐!
자동차 업계에서 말하는 QA는 사실 두 종류예요!
구분 | 개발 품질 QA | 양산 품질 QA |
---|---|---|
목적 | 개발 프로세스의 품질 확보 | 공정/제품의 품질 유지 |
시점 | 제품 출시 전 (개발 중) | 제품 양산 이후 |
활동 | 리뷰, 프로세스 준수 점검, 평가 | 불량률 분석, 현장 품질 대응 |
대표 도구 | A-SPICE, ISO26262, 프로세스 체크리스트 | FMEA, SPC, 공정품질관리, 리콜 대응 등 |
🤖 개발 QA, A-SPICE에서는 어떤 역할을 할까?
A-SPICE의 SUP.1 프로세스는 말해요:
"개발이 잘 되고 있는지, 기준대로 진행되고 있는지, 우리가 품질 좋게 만드는 법을 따르고 있는지를 지속적으로 확인해줘!"
즉, 개발 QA는 개발 과정의 '감독관'이자 '조언자'예요.
🔍 SUP.1 – A-SPICE 품질보증 프로세스 핵심 3단계!
단계 | 설명 |
---|---|
✅ 계획 (Planning) | 어떤 활동을 어떤 기준으로 확인할지 미리 정함 |
🔍 수행 (Assurance) | 실제 개발 활동을 확인하고, 규정 위반이 있는지 체크 |
📝 보고 (Reporting) | 확인 결과를 문서로 정리하고, 팀에 공유함 |
🧪 예시! 개발 QA가 하는 일
활동 | 개발 QA의 시선 |
---|---|
요구사항 정의 | “고객 요구가 명확하게 정리됐나?” |
설계 문서 | “버전 관리되고 있나? 승인자 확인했나?” |
코드 리뷰 | “코딩 표준은 따르고 있나? 주요 리스크 대응했나?” |
테스트 | “테스트 케이스는 요구사항 기반인가?” |
🧑🏫 개발 QA는 ‘틀린 걸 잡는 사람’이 아니라
‘기준대로 잘 하고 있는지’를 체크해서 팀을 더 강하게 만드는 사람이에요!
🚗 양산 QA는 뭐가 다를까?
양산 QA는 공장 쪽에서 활약합니다!
- 품질 불량률 관리
- 생산 공정의 안정성 확보
- 고객 클레임 대응
- 공정 변경 시 영향 평가
양산 QA의 주 무기는 FMEA, SPC, 8D, 리콜 분석 등
현장의 품질 데이터를 바탕으로 한 실전 대응이에요!
💡 개발 QA가 "이렇게 만들면 좋다"고 제안하고
양산 QA가 "이걸 유지하면서 잘 만들자"고 실행해요!
💥 QA가 개발자의 적이라고요? 오해예요!
개발자들이 QA를 싫어하는(?) 이유는 보통 이런 거죠:
- 문서 검토 요청 😩
- 체크리스트 요구 😫
- 리스크 지적 😱
하지만 진짜 QA는 이런 말을 해요:
“이건 팀이 실수 안 하게 도와주는 기준이에요!”
“이거 체크 안 하면 나중에 고객이 먼저 발견해요…”
“우리 개발팀 실력, 우리가 먼저 증명하자!”
👥 QA와 잘 지내는 꿀팁
- 리뷰 때 방어가 아닌 협력의 자세로 임하기
- QA 요구가 ‘귀찮은 일’이 아니라 미리 방지책임을 이해하기
- 문서만 보는 QA가 아니라, 실제 프로세스 이해자로 인정해주기
- 이슈 해결 시 QA에게 도움 요청하기 (되려 더 빨리 해결됩니다!)
✍️ 실천 미션: QA 팀과 친해지기 프로젝트!
- 우리 팀의 개발 QA가 누구인지 파악해보기
- 내가 작성한 문서 중, QA가 검토하는 항목이 뭔지 확인
- 다음 리뷰에서 “이건 왜 확인하세요?” 물어보기 (대화 시작!)
- 내가 생각하는 ‘개발 품질 향상 팁’ 하나 정리해서 공유해보기
📌 다음 회차 예고
8회차에서는
"SUP.8 – 형상 관리(Configuration Management), 개발 파일 관리의 고수가 되는 법!"을 주제로
누가 언제 뭘 바꿨는지 추적 가능한 개발 환경 만들기!
그리고 버전 관리 혼란을 줄이는 팁을 공개합니다.
“그 파일… 누가 마지막으로 수정했지?”
→ SUP.8을 알면 절대 헷갈리지 않습니다 😎