테스트 자동화 도입이 기술적으로 성공해도 팀의 마찰로 인해 유명무실해지는 경우는 드물지 않습니다. 도구나 기술 선택보다 먼저, “누가·왜·어떻게 사용할 것인가”라는 사람과 조직의 문제를 정리하는 것이 자동화를 정착시키는 핵심입니다.
📌 이 글의 대상 독자
| ✅ 테스트 자동화를 도입했지만 팀 내 온도 차이를 느끼는 QA 엔지니어 |
| ✅ 자동화 추진 역할로 고립되기 쉬운 분 |
| ✅ Flaky Test나 유지보수 비용에 대한 불만이 팀에 퍼지고 있는 분 |
| ✅ 매니저나 개발팀과의 연계에 어려움을 느끼는 분 |
📖 이 글에서 배울 수 있는 내용
| ✔ 테스트 자동화에서 팀 마찰이 발생하기 쉬운 6가지 원인 |
| ✔ 마찰을 악화시키는 흔한 실수 |
| ✔ 실무에서 효과가 있었던 마찰 해소 방법 |
| ✔ “자동화 = 수동 테스트 불필요”라는 오해에 올바르게 대처하는 방법 |
필자는 여러 프로덕트·팀에서 테스트 자동화의 도입·추진·유지에 관여해 왔습니다.
기술적으로 훌륭한 자동화 기반을 구축해도 팀 내 마찰로 인해 사용되지 않게 된 경험을 여러 번 했습니다.
가장 기억에 남는 것은 CI가 빨간 상태여도 아무도 신경 쓰지 않게 된 팀입니다. 원인을 파고들어 보니 Flaky Test를 반년 이상 방치해 왔던 것이었습니다. 신뢰를 되찾는 데 몇 달이 걸렸습니다.
이 글은 그 실패와 시행착오에서 얻은, 실무에 직결되는 내용입니다.
✅ 이 글의 핵심 정리
- 마찰의 근본 원인은 “기술”이 아니라 “기대치 차이”와 “오너십의 모호함”에 있다
- 작게 시작해서 가치를 보여주는 것이 팀의 신뢰를 얻는 가장 효과적인 방법이다
- Flaky Test·유지보수 비용·스킬 격차에 대한 대처 방침을 팀에서 결정하는 것이 정착의 핵심이다
테스트 자동화에서의 “마찰”이란
여기서 말하는 “마찰”이란 테스트 자동화 도입·운용 과정에서 발생하는 팀 내 대립·온도 차이·불신감·고립감을 가리킵니다.
기술적인 문제(도구 선택 실수나 프레임워크 설계 결함)와는 달리, 마찰은 사람과 사람 사이에서 발생합니다.
마찰이 방치되면 다음과 같은 상태가 됩니다.
| 증상 | 현장에서 실제로 들리는 목소리 |
|---|---|
| 자동화 코드가 업데이트되지 않게 된다 | “테스트가 실패해도 아무도 고치지 않으니까 이제 믿지 않아요” |
| 수동 테스트로 되돌아간다 | “자동화하는 것보다 손으로 하는 게 더 빨라요” |
| 추진 역할이 고립된다 | “저 사람밖에 못 건드리니까 의존하고 싶지 않아요” |
| 사업 측과 기대치가 어긋나 예산이 삭감된다 | “비용은 들이는데 뭐가 좋아졌는지 모르겠어요” |
팀 마찰이 발생하기 쉬운 6가지 원인
1. 개발팀과 QA팀의 “온도 차이”
개발팀은 “자동화는 QA의 일”이고, QA팀은 “코드를 못 짜니 엔지니어에 의존하고 싶다”는 상태가 계속되면 양쪽 모두 반쪽짜리가 됩니다.
전형적인 예로, “QA는 자동화를 추진하고 싶지만, 개발팀은 릴리스 우선이라 테스트 코드 리뷰에 시간을 내지 않는다”는 상황이 있습니다. 결과적으로 테스트 코드가 리뷰 없이 계속 머지되면서 품질도 오너십도 흐릿해집니다.
자동화는 개발과 QA가 공동으로 오너십을 갖는 영역이지만, 명시하지 않으면 자연스럽게 아무도 책임지지 않는 상태가 됩니다.
스프린트 계획에 “자동화 태스크”를 명시적으로 포함시키고, 개발과 QA가 분담하는 규칙을 만든다.
모두가 “자동화는 팀 전체의 자산”이라는 인식을 가질 수 있도록 리뷰를 공동으로 진행한다.
2. “자동화 = 수동 테스트 불필요”라는 오해로 인한 저항
“자동화가 진행되면 내 일이 없어진다”는 불안으로 인해, 수동 테스트 중심의 멤버가 자동화에 소극적이 되는 경우가 있습니다.
이 오해를 방치하면 정보 공유가 막히고 테스트 설계의 질도 저하됩니다.
실제로는 자동화가 잘하는 것은 회귀 테스트·반복 실행·데이터량이 많은 케이스이며,
탐색적 테스트·UX 확인·신기능 초기 검증은 사람의 판단이 필수입니다.
자동화와 수동 테스트는 경쟁 관계가 아니라 역할을 분담하는 관계입니다.
“자동화에 적합한 테스트”와 “수동 테스트가 더 나은 테스트”를 표로 정리해 팀에서 공유한다.
수동 테스트 중심의 멤버가 자동화 테스트의 시나리오 설계에 참여할 수 있는 역할을 만들면 당사자 의식이 생기기 쉽다.
3. Flaky Test가 팀의 신뢰를 무너뜨린다
불안정한 테스트(Flaky Test)가 방치되면 “CI가 빨간 상태여도 아무도 신경 안 쓴다”는 문화가 정착됩니다.
일단 이 상태가 되면 테스트 결과에 대한 신뢰를 되찾는 데 많은 비용이 필요합니다.
| Flaky Test의 주요 원인 | 전형적인 증상 |
|---|---|
| 암묵적 대기(time.sleep) | 환경에 따라 성공하거나 실패한다 |
| 테스트 간 데이터 의존성 | 실행 순서에 따라 결과가 바뀐다 |
| 외부 API 의존 | 네트워크 상황에 따라 불안정해진다 |
| 병렬 실행 시 경쟁 상태 | 단독으로는 통과하지만 병렬 실행하면 실패한다 |
Flaky Test가 발견되면 전용 티켓을 등록하고, 상황에 따라
skip·xfail로 일시 격리하거나 불안정한 테스트만 별도 잡(job)으로 실행하는 방법이 있습니다. 팀의 상황에 맞게 운용 방침을 결정해 두는 것이 중요합니다.“실패하면 전체 정지” 기준과 “Flaky로 관리” 기준을 사전에 합의해 둡시다.
4. “누가 고칠 것인가”가 정해지지 않은 오너십 문제
테스트 코드가 깨졌을 때 “개발이 고쳐야 하는지, QA가 고쳐야 하는지”가 모호한 채로 있으면 아무도 움직이지 않는 상태가 계속됩니다.
이것은 기술적인 문제가 아니라 팀의 규칙 설계 문제입니다.
| 케이스 | 권장 담당자 | 비고 |
|---|---|---|
| 기능 변경으로 기존 테스트가 깨진 경우 | 기능을 변경한 개발자 | 변경과 테스트 수정은 세트로 |
| Flaky Test 조사·수정 | QA(자동화 담당) | 스프린트에 수정 공수 확보 |
| 신기능 테스트 추가 | 개발 + QA 공동 | 정의는 QA, 구현은 개발이 담당하는 경우도 있음 |
| 테스트 프레임워크 개선 | QA(자동화 담당) | 분기마다 기술 부채로 계획 |
5. 매니저·사업 측과의 기대치 차이
자동화의 효과는 “방지한 장애”나 “줄인 수동 작업 시간”이라는 형태로 나타나지만, 가시화하지 않으면 전달되지 않습니다.
매니저나 사업 측에서 보면 비용만 보이고 효과가 보이지 않는 상태가 되기 쉽습니다.
자동화의 가치를 전달하기 위해서는 정성적인 주장이 아닌 정량적인 기록이 필요합니다. 예를 들어 다음과 같은 지표를 활용할 수 있습니다.
| 지표 | 측정 방법 예시 |
|---|---|
| 회귀 테스트 실행 시간 단축 | 수동 실행 시간(인일) vs. CI 실행 시간(분)을 기록 |
| 릴리스 전 버그 발견 건수 | 자동화 도입 전후의 프로덕션 장애 건수 비교 |
| 테스트 커버리지 추이 | 월별 자동화 테스트 건수·커버리지율 기록 |
| CI/CD 사이클 타임 | PR 머지부터 릴리스까지의 리드 타임 기록 |
| CI 실패율·Flaky 비율 | 월별 CI 총 실행 수 대비 실패·Flaky 비율 |
| Flaky Test 평균 수정 시간(MTTR) | 티켓 등록부터 수정 완료까지의 시간 기록 |
6. 스킬 격차로 인한 고립과 의존
자동화 코드를 “한 사람밖에 못 건드리는” 상태가 되면, 그 사람이 이동하거나 퇴사할 때 자동화 기반 전체가 무너집니다.
또한 스킬 차이가 크면 코드 리뷰가 형식적으로 되어 품질도 유지하기 어려워집니다.
페어 프로그래밍과 코드 리뷰를 루틴화한다. 팀 내에서 자동화 입문 세션을 정기적으로 개최하고, 완벽한 스킬 균등화는 어렵더라도 “누구든 수정할 수 있는” 상태를 목표로 한다.
마찰을 줄이는 실전적 접근법 5가지
1. 작게 시작해서 가치를 보여주기
처음부터 대규모 자동화 기반을 구축하는 것보다, 테스트 1개가 CI에서 동작하는 상태를 빠르게 만드는 것이 더 중요합니다.
“동작하는 자동화”를 보여주는 것만으로 회의적인 멤버의 태도가 바뀌는 경우는 드물지 않습니다.
| 후보 | 이유 |
|---|---|
| 로그인·로그아웃 플로우 | 모두가 알고 있어 효과를 알기 쉽다 |
| 깨진 링크 확인 | 손으로 하면 번거로운 작업이 사라짐을 실감할 수 있다 |
| API 정상 응답 확인 | 실행이 빠르고 CI에 조합하기 쉽다 |
| 반복해서 발생한 버그의 재현 테스트 | “그 버그가 또 나왔다”를 막은 것을 직접 보여줄 수 있다 |
2. 설계 단계부터 전원 참여시키기
자동화의 시나리오 설계와 테스트 케이스 정의를 QA만이 아닌 개발·PM·수동 테스트 중심의 멤버도 함께 진행함으로써 전원이 당사자 의식을 가질 수 있습니다.
“QA가 만든 것”이 아닌 “팀의 자산”으로 만드는 것이 마찰 해소의 근본적인 방법입니다.
소프트웨어 공학에는 콘웨이의 법칙이라는 개념이 있습니다. 조직의 커뮤니케이션 구조가 그대로 시스템 설계에 반영된다는 법칙입니다. 테스트 자동화도 예외가 아니며, 개발과 QA가 분리된 팀 구조에서는 테스트도 분리되기 쉽습니다. 마찰을 줄이기 위해서는 팀의 관계 방식 자체를 재검토하는 것이 유효한 경우가 있습니다.
3. “어떻게 사용할 것인가”의 방침을 문서화하기
| 문서화해야 할 내용 | 왜 필요한가 |
|---|---|
| Flaky Test 대응 플로우 | 모른 척하는 것을 방지 |
| 오너십 정의 | 깨졌을 때 아무도 움직이지 않는 상태를 방지 |
| “자동화할지 말지”의 판단 기준 | 불필요한 자동화에 공수 투입을 방지 |
| 로컬 실행·CI 실행 절차 | “실행 방법을 모른다”로 인한 이탈을 방지 |
4. 성과를 정기적으로 가시화해서 공유하기
월별·스프린트 리뷰 등에서 자동화 성과를 공유하는 습관을 만들면 존재 가치가 전달되기 쉬워집니다.
숫자로 보여주는 것이 중요하지만, “이번 주 자동화 테스트가 X건의 버그를 발견했다”는 구체적인 사실이 추상적인 커버리지율보다 더 잘 전달됩니다.
5. 테스트 실패를 “나무라는” 것이 아닌 “배우는” 문화 만들기
CI가 빨간 상태가 되는 것을 과도하게 두려워하는 팀에서는 테스트 케이스가 늘어나기 어려워집니다.
“테스트가 실패하는 것은 나쁜 것이 아니라, 문제를 조기에 발견할 수 있었다는 것”이라는 인식을 팀에 정착시키는 것이 장기적인 자동화 문화의 기반이 됩니다.
마찰을 악화시키는 흔한 실수
⚠️ 마찰을 만들기 쉬운 안티패턴
- “자동화하면 모든 것이 해결된다”는 과도한 기대치 설정
도입 전에 지나치게 기대를 부풀리면, 초기 과제(Flaky Test·유지보수 비용)로 인해 순식간에 신뢰를 잃습니다. 현실적인 장단점을 처음부터 전달하는 것이 중요합니다. - 한 명의 엔지니어에게 모두 맡기기
자동화 담당자가 한 명이면 지식 고립·버스 팩터 1의 문제가 동시에 발생합니다. 작더라도 팀 전원이 관여할 수 있는 설계를 만들어야 합니다. - Flaky Test를 계속 방치하기
“언젠가 고친다”가 쌓이면 CI 결과를 아무도 신뢰하지 않게 됩니다. Flaky Test는 기술적 부채로 명시적으로 관리하고 정기적으로 해소하는 운용이 필요합니다. - 수동 테스트 중심의 멤버를 소외시키기
자동화 논의에 수동 테스트 중심의 멤버가 참여하지 않으면 “우리 일이 빼앗긴다”는 불안이 쌓입니다. 설계와 회고에 적극적으로 참여해달라고 요청합시다. - 성과 보고를 하지 않기
자동화가 잘 작동하고 있어도 보고하지 않으면 “무엇을 하는지 모른다”는 평가가 됩니다. 정기적으로 효과를 공유하는 자리를 만들어야 합니다. - 한 번에 크게 바꾸려 하기
기존 수동 테스트를 한꺼번에 자동화하려 하면 품질을 보장할 수 없는 전환 기간이 길게 이어집니다. 병행하여 단계적으로 이전하는 것이 현장 혼란을 방지합니다. - 도구·기술 선정을 엔지니어만으로 결정하기
자동화를 사용하게 될 수동 테스트 중심의 멤버나 매니저가 선정 프로세스에 관여하지 않으면 “사용하고 싶지 않다”는 마찰이 나중에 발생합니다.
자주 묻는 질문 (FAQ)
장기적으로는 권장하지 않습니다. QA만으로 추진하면 개발팀이 테스트 코드를 “우리 것”으로 느끼기 어려워져, 리뷰나 수정에 대한 관여가 줄어듭니다.
자동화는 팀 전체의 품질 활동으로 운용하는 것이 정착하기 쉽고 지식 고립도 방지할 수 있습니다.
처음에는 QA가 주도하더라도 점차 개발 멤버도 관여할 수 있는 체제를 만들어 가는 것이 이상적입니다.
먼저 “왜 협조적이지 않은지”의 이유를 구체적으로 물어보는 것이 출발점입니다.
“시간이 없다”, “우선순위가 낮다”, “자동화의 가치를 모른다”는 각각 대처법이 다릅니다.
작은 성공 사례(예: 특정 버그를 자동화 테스트가 발견한 사례)를 공유하고, 혜택을 직접 경험하게 하는 것이 가장 효과적인 경우가 많습니다.
“자동화 = 수동 테스트 대체”가 아닌 “자동화 = 반복 작업 삭감”이라는 프레이밍부터 시작하는 것이 유효합니다.
수동 테스트 중심의 멤버가 가장 번거롭다고 느끼는 반복 작업을 자동화하고, “편해졌다”는 실체험을 만드는 것으로 인식이 바뀌기 쉬워집니다.
기술적인 설명보다 비즈니스 임팩트로 번역해서 전달하는 것이 효과적입니다.
“테스트 실행 시간이 X시간 단축됐다”, “릴리스 전에 Y건의 버그를 발견했다”, “프로덕션 장애 건수가 Z% 감소했다”와 같은 숫자로 전달합시다.
처음부터 큰 성과를 기대하지 말고 작은 실적을 쌓아 신뢰를 얻어가는 것이 현실적입니다.
일반적인 판단 기준으로, “실행 빈도가 높다”, “수동 실행 비용이 높다”, “변경 빈도가 낮다”, “재현 절차가 명확하다”는 조건이 갖춰진 테스트는 자동화에 적합합니다.
반대로 “한 번만 실행한다”, “사양이 자주 바뀐다”, “UI 외관 확인이 주된 목적”인 테스트는 수동이 비용 효율이 좋은 경우가 많습니다.
자세한 내용은 자동화하지 말아야 할 테스트 글도 참고하세요.
먼저 “나만 옳다”는 자세를 피하는 것이 중요합니다.
자동화는 팀의 과제 해결 수단이지 목적이 아닙니다.
회의적인 멤버의 의견을 적극적으로 듣고, “해봤더니 생각보다 좋았다”는 경험을 함께 만드는 것이 고립을 막는 가장 실천적인 접근법입니다.
정리
| 마찰의 원인 | 해소책의 포인트 |
|---|---|
| 개발·QA의 온도 차이 | 오너십을 명시하고 자동화 태스크를 스프린트에 포함 |
| 수동 테스트 불필요라는 오해 | 역할 분담을 정리하고 설계 단계부터 전원 참여 |
| Flaky Test 불신 | 티켓으로 가시화. skip/xfail/별도 잡 방침을 합의 |
| 오너십의 모호함 | 케이스별 담당자를 문서화해서 공유 |
| 사업 측과의 기대치 차이 | KPI를 기록해서 정기 보고. 작은 성과부터 숫자로 전달 |
| 스킬 격차로 인한 고립 | 페어 리뷰·스터디로 지식 고립 방지 |
테스트 자동화가 “팀의 자산”으로 기능하기 위해서는 기술적인 정확성과 마찬가지로 사람과 조직에 대한 배려가 필요합니다.
완벽한 자동화 기반보다, 팀 전원이 작더라도 관여할 수 있는 자동화가 장기적으로는 더 큰 가치를 발휘합니다.
우선 하나, 팀에서 “가장 번거로운 반복 작업”을 자동화해 보세요.
그것이 마찰 없는 팀으로 가는 첫걸음이 됩니다.
