진짜 협업하는 팀 만들기
"QA 엔지니어가 또 버그 찾아서 일정 늦어지네..."
"개발자들이 테스트하기 쉽게 만들어주지를 않아..."
"버그 티켓이 또 이렇게 늘어나네.."
10년 넘게 QA 엔지니어로 일하면서 최근에는 많이 줄어들기는 했지만, 이런 말들을 수없이 들어왔습니다.
개발팀과 QA팀 사이의 보이지 않는 장벽
이 장벽은 왜 생기는 걸까요? 그리고 어떻게 허물 수 있을까요?
개발자는 "기능을 만들어내는 것"이 목표이고, QA 엔지니어는 "버그를 찾아내는 것"이 목표라고 생각하기 쉽습니다. 하지만 진짜 목표는 둘 다 같습니다. "사용자에게 가치 있는 제품을 전달하는 것"이죠.
한 스타트업에서 겪었던 일입니다. 개발팀은 새 기능 출시에 집중하고, QA팀은 버그 제로를 목표로 했습니다. (현실로는 불가능한 것을 알면서도 업무가 그렇다보니 버그 제로라는 결과들을 모두가 지향하고 있죠.)
결과는 어떨까요? 출시는 계속 지연되고, 팀 간 갈등만 커졌죠. 목표를 "2주 안에 핵심 기능을 80% 품질로 출시"로 바꾸자, 놀랍게도 협업이 시작됐습니다.
대부분의 조직에서 QA 과정은 개발이 "끝난 후" 시작됩니다. 이미 완성된 코드에서 문제를 발견하면? 개발자 입장에선 "이미 끝난 일"을 다시 해야 하는 부담이 되죠.
- 전통적인 프로세스: 기획 → 개발(2주) → QA(3일) → 버그 수정(2일) → 출시
- 협업하는 프로세스: 기획(QA 참여) → 개발+QA 병행(2주) → 최종 검증(1일) → 출시
요즈음에는 각 회사 색깔에 맞게 협업하는 프로세스가 만들어지죠. 여기서 "협업하는 프로세스"의 포인트는 QA팀/QA 엔지니어가 초기부터 참여한다는 점이죠.
개발자는 QA의 테스트 시나리오 작성이 얼마나 복잡한지 모르고, QA는 개발자가 왜 특정 버그 수정에 시간이 오래 걸리는지 이해하지 못합니다. 서로의 일을 모르니 공감대 형성이 어렵죠.
개발자의 이런 고충을 알아보고자 1인 기획/개발/QA를 진행했었습니다. 자세한 내용은 아래 브런치북을 한 번 읽어보시길 바랍니다.
기획 단계부터 QA 참여시키기
제가 현재 일하는 팀에서는 기획 회의에 QA 엔지니어가 항상 참여합니다. "이 기능은 어떻게 테스트할 건가요?"라는 질문 하나가 수많은 엣지 케이스를 미리 발견하게 해줍니다. 또는 과거 히스토리를 알고 있기 때문에 유사 이슈를 제기해볼 수 있습니다.
[ 기획 회의 QA 체크리스트 ]
- 이 기능의 성공/실패 기준은 명확한가?
- 엣지 케이스는 무엇인가?
- 테스트 데이터는 어떻게 준비할 것인가?
- 자동화 테스트 가능한 부분은 어디인가?
개발 중 테스트 작성
개발자가 코딩하는 동안, QA 엔지니어는 테스트 케이스를 작성합니다. 때로는 개발자와 페어로 앉아 "이런 케이스는 어떻게 처리하나요?"라고 물으며 함께 엣지 케이스를 발견합니다.
버그는 팀의 것
"QA 엔지니어가 못 찾은 버그" 또는 "개발자가 만든 버그"가 아닙니다. "우리가 놓친 버그"입니다. 한 팀에서는 프로덕션 환경의 버그가 발생하면 개발자와 QA 엔지니어가 함께 포스트모템(Post-Mortem)을 작성합니다. 책임 소재를 따지는 대신 "어떻게 하면 다음에 방지할 수 있을까?"에 집중하죠.
품질 메트릭 공유
팀 대시보드 (모두가 보는 곳에)
- 이번 스프린트 버그 발견 수: 23개
- 프로덕션 버그: 2개
- 자동화 테스트 커버리지: 67%
- 평균 버그 수정 시간: 4시간
이 숫자들은 개발팀 또는 QA팀의 성과가 아니라 "우리 프로덕트 팀의 현재 상태"입니다.
QA의 개발 경험 (의사코드;Pseudo Code)
간단한 버그 수정이나 테스트 데이터 스크립트 작성을 QA 엔지니어가 직접 해보게 합니다. 코드 한 줄 바꾸는 것도 빌드, 테스트, 배포 과정을 거쳐야 한다는 걸 체험하면 개발자의 입장을 이해하게 됩니다.
개발자의 테스트 경험
개발자가 자신이 만든 기능의 테스트 케이스를 작성해보게 합니다. "생각보다 케이스가 많네?"라는 깨달음이 QA의 가치를 인정하게 만듭니다.
같은 도구 사용하기
개발팀은 Jira, QA팀은 TestRail? No! 같은 도구에서 일하면 자연스럽게 서로의 일이 보입니다.
통합 도구 셋업 예시
- 이슈 트래킹: Jira/Linear (개발 태스크 + 버그 + 테스트 케이스)
- 문서: Confluence/Notion (기술 문서 + 테스트 계획)
- CI/CD: Jenkins/GitHub Actions (빌드 + 자동화 테스트)
- 커뮤니케이션: Slack/Teams (개발 채널 + QA 채널 + 통합 채널)
테스트 자동화를 CI/CD에 통합 (의사코드;Pseudo Code)
개발자의 PR이 자동으로 테스트되고, 결과를 함께 보면서 "이 테스트는 왜 실패했을까?"를 함께 고민합니다.
버그 우선순위 결정 미팅 (Bug Triage)
매주 30분, 개발자와 QA 엔지니어가 함께 모여 버그를 리뷰합니다. 단순히 우선순위를 정하는 게 아니라, 왜 이런 버그가 발생했는지, 어떻게 방지할 수 있을지 논의합니다.
테스트 케이스 리뷰
새 기능의 테스트 케이스를 개발자와 함께 리뷰합니다. "이 케이스는 실제로 불가능해요" 또는 "이런 케이스도 추가하면 좋겠네요"같은 피드백이 오가며 서로의 관점을 이해하게 됩니다.
회고에서 품질 이야기하기
스프린트 회고 품질 체크포인트
- 이번 스프린트에서 가장 치명적인 버그는 무엇이었나?
- 왜 사전에 발견하지 못했나?
- 개발자와 QA 엔지니어가 더 잘 협업했다면 막을 수 있었나?
- 다음 스프린트에서 시도해볼 개선점은?
개발팀과의 장벽만 허문다고 끝이 아닙니다. 기획팀과 QA팀 사이의 장벽도 반드시 허물어야 합니다. QA팀은 제품의 히스토리를 가장 깊이 이해하고 있어야 하는 팀입니다.
1. 컨텍스트가 곧 품질이다
"왜 이 기능이 추가됐는지", "어떤 기능이 deprecated 됐는지", "사용자가 어떤 순서로 기능을 사용하는지" - 이 모든 히스토리를 아는 QA 엔지니어와 모르는 QA 엔지니어의 테스트 품질은 하늘과 땅 차이입니다.
QA가 알아야 할 제품 히스토리
- 기능 추가/제거 이력과 그 이유
- 사용자 피드백으로 인한 변경사항
- 비즈니스 우선순위 변화
- 경쟁사 대응으로 인한 긴급 변경
- 기술 부채로 인한 제약사항
2. 기획 단계부터 참여하는 QA의 가치
한 이커머스 회사에서 "원클릭 구매" 기능을 기획했습니다. QA 엔지니어가 초기 기획 회의에서 "기존 장바구니 기능과 충돌하면 어떻게 하나요?"라고 물었고, 이 질문 하나로 2주의 재작업을 막을 수 있었습니다.
1. 기획 문서 리뷰 권한 부여
QA팀에게 기획 문서에 대한 리뷰 권한을 공식적으로 부여합니다. "테스트 가능성" 관점에서의 피드백은 필수입니다.
[ 기획 문서 QA 리뷰 체크리스트 ]
- 명확한 Acceptance Criteria가 있는가?
- 테스트 가능한 구체적인 시나리오가 있는가?
- 기존 기능과의 충돌 가능성은 검토됐는가?
- 롤백 계획이 있는가?
- 단계적 출시(Feature Flag) 가능한가?
2. 제품 로드맵 공유 세션
분기별로 기획팀이 QA팀에게 제품 로드맵을 상세히 설명하는 세션을 가집니다. 단순 정보 전달이 아닌, QA 엔지니어의 관점에서 리스크를 논의하는 자리입니다.
3. QA 엔지니어의 적극적인 정보 수집
QA 팀원들이 제품 변경사항에 최대한 관심을 가질 수 있도록 환경을 만들어야 합니다.
[ QA 정보 수집 채널 ]
- 기획 회의 참관 (옵저버라도 OK)
- 고객 피드백 채널 구독
- 비즈니스 메트릭 대시보드 접근 권한
- 경쟁사 분석 리포트 공유
- UX 리서치 결과 공유
4. "Why" 세션 정례화
매주 또는 격주로 "Why 세션"을 진행합니다. 기획팀이 "왜 이 기능을 만들었는지", "왜 이 기능을 제거했는지"를 설명하고, QA 엔지니어는 질문을 통해 깊이 있는 이해를 쌓습니다.
[ Why 세션 예시 ]
- 기획자: "결제 프로세스를 3단계에서 1단계로 줄였습니다"
- QA 엔지니어: "기존 3단계에서 각각 어떤 검증이 있었나요?"
- 기획자: "주소 검증, 결제수단 검증, 최종 확인이었습니다"
- QA 엔지니어: "그럼 이제 이 검증들이 한 화면에서 모두 일어나야 하는데, 동시 검증 시 우선순위는 어떻게 되나요?"
→ 이런 대화를 통해 숨겨진 복잡도를 발견
개발자와 QA 엔지니어가 함께하는 15분 스탠드업 미팅 시작
버그 리포트에 "우리가 놓친" 표현 사용 시작
메신저(Slack/Temas)에 #dev-qa 통합 채널 생성
기획 회의에 QA 엔지니어 1명 참관 시작
주 1회 30분 버그 우선순위 결정 미팅 (Bug Triage) 도입
개발자의 PR에 QA 리뷰어 추가
크로스 트레이닝 세션 월 1회 진행
공동 품질 메트릭 대시보드 구축
회고에서 품질 이슈 정례 논의
장벽을 허무는 과정에서 리더십의 역할은 결정적입니다.
리더가 먼저 "우리" 언어를 사용합니다. "개발팀이 만든 버그"가 아니라,
"우리가 놓친 이슈", "QA 엔지니어의 테스트"가 아니라 "우리의 품질 검증"
실수를 비난하지 않는 문화를 만듭니다. 버그는 학습의 기회이지 처벌의 대상이 아님을 명확히 합니다.
협업을 위한 시간과 도구에 투자합니다. "시간이 없어서 따로 일한다."는 핑계를 없앱니다.
QA 팀원들이 제품과 비즈니스를 깊이 이해할 수 있도록 학습 시간을 보장합니다. 단순히 테스트만 하는 것이 아니라 제품 전문가로 성장할 수 있도록 지원합니다.
장벽이 허물어지고 있는지 어떻게 알 수 있을까요?
[ 협업 개선 지표 ]
1. Lead Time: 개발 시작 → 프로덕션 환경 배포까지 시간
2. 버그 탈출률(Escape Rate): 프로덕션 버그 / 전체 버그 * 100
3. 첫 번째 리뷰 통과율: 첫 QA에서 통과하는 기능 비율
4. 팀 협업 만족도: 분기별 서베이
5. 지식 공유 세션 횟수: 월별 크로스 트레이닝 세션
6. 기획 단계 QA 참여율: QA 엔지니어가 참여한 기획 회의 비율
7. 제품 지식 테스트 점수: QA팀의 제품 이해도 측정
개발팀, 기획팀과 QA팀의 장벽을 허무는 것은 단순히 효율성을 위한 것이 아닙니다. 서로를 이해하고 존중하는 과정에서 더 나은 제품이 만들어지고, 더 행복한 팀이 됩니다.
제가 경험한 가장 성공적인 팀은 개발자가 "이 부분 테스트하기 쉽게 수정했어요"라고 말하고, QA 엔지니어가 "이 테스트 데이터 생성 스크립트는 제가 작성할게요"라고 말하며, 기획자가 "QA 관점에서 이 시나리오 검토해주세요"라고 요청하는 팀이었습니다. 경계가 없어진 것이 아니라, 서로의 전문성을 인정하면서도 공동의 목표를 향해 함께 나아가는 팀이었죠.
"버그를 찾는 사람과 만드는 사람이 아니라, 함께 좋은 제품을 만드는 동료"
"테스트하는 사람이 아니라, 제품을 가장 깊이 이해하는 전문가"
이것이 진정한 Quality Leadership의 시작입니다.