LINE Album QA 팀이 "생성형 AI 가 QA 를 대체하나"라는 질문에, AI 는 QA 를 대체하지 않고 확장한다는 결론으로 답한 1년 운영기를 다룬다. QA 의 병목은 테스트 속도가 아니라 기획·Slack·Jira·PR·로그·리뷰에 흩어진 정보를 구조화하고 판단하는 일이며, AI 를 대화 도구가 아닌 30여 개 자동화 워크플로로 운영 체계에 통합한 게 핵심이다.
핵심 포인트- QA 병목은 테스트 속도가 아니라 분산된 정보의 양·복잡도이며, AI 를 보조 도구가 아닌 운영 워크플로로 통합해야 효과가 난다.
- 스케줄 기반(매일 리뷰 분석·UI/API 테스트·주간 리포트)과 웹훅 기반(티켓 생성·PR 머지·테스트 결과)의 30여 개 워크플로를 운영한다.
- 테스트 케이스의 약 90%를 5개 에이전트 구조가 초안 생성하고 사람이 약 10%를 검증·보강한다.
- 1년 블라인드 실험에서 AI+사람 협업이 사람·AI 단독보다 커버리지와 맥락 균형이 가장 좋았다.
- 업무 시간이 극적으로 줄진 않았지만 반복 수집에서 리스크 판단·전략 설계로 사고 밀도가 올라갔다.
상세 정리- 문제 정의: QA 생산성은 테스트 속도가 아니라 기획 문서·Slack·Jira·PR·자동화 로그·사용자 리뷰에 흩어진 정보를 구조화하고 맥락을 이해해 리스크를 판단하는 데서 갈린다.
- 초기 한계: 기획 문서 요약·테스트 케이스 초안·버그 리포트 정리로 AI 를 쓰자, QA 가 정보를 모아 AI 에 넘기는 수작업 병목과 품질 이벤트를 수동 처리하는 반응성 부족이 남았다.
- 재정의: AI 를 "대화 도구"에서 "품질 워크플로"로 바꿔 30개 이상의 자동화를 구축하고 스케줄·웹훅 두 구조를 병행했다.
- 스케줄 자동화: 매일 App Store 리뷰 분석→Slack, MagicPod UI 테스트→Jira+Slack, Pytest API 테스트, 주간 QA 리포트 자동 작성을 돌린다.
- 웹훅 자동화: Jira 티켓 생성 시 변경 분석, PR 머지 시 변경 범위 요약을 Jira 댓글로, 테스트 결과 업로드 시 통계 시각화, Slack 스레드 종료 시 회의록 생성을 트리거한다.
- 테스트 케이스 생성: Plan-Analyzer(기획 분석), Dev-Analyzer(Git 변경 분석), TestCase-Generator(정상·예외·경계·플랫폼 차이·과거 버그 시나리오), TestCase-Validator(커버리지·추적성 평가), Quality-Inspector(피드백 축적) 5개 에이전트를 오케스트레이터가 조율한다.
- 맥락 반영: 단순 요구사항 해석을 넘어 과거 Jira 이슈와 누적 버그 패턴을 참고해 "명세에 적힌 것"과 "실제 문제가 됐던 방식"을 함께 담는 재귀 검증 루프를 둔다.
- 블라인드 실험: 1년 운영에서 사람 단독은 안정적이나 커버리지 한계, AI 단독은 시나리오는 다양하나 맥락 판단 부족, AI+사람이 커버리지와 맥락 균형으로 완성도가 가장 높았다.
- 탐색적 테스팅: 과거 이슈·기능 변경·테스트 히스토리 기반으로 테스트 차터를 제안하고 화면별 이슈 빈도를 시각화해, 시니어 없이도 관점을 확장하게 했다.
- 효과: 테스트 케이스 90%를 AI 초안으로 만들지만 업무 시간이 극적으로 줄진 않았고, 반복 수집에서 리스크 식별·전략 설계로 일의 성격이 바뀌었다.
- 역할 변화: QA 가 테스트 실행자에서 입력 설계·워크플로 개선·품질 데이터 분석·시스템 영향 분석을 맡는 "품질 오케스트레이터"로 재정의됐다.
- 교훈: AI 는 요약·패턴 탐지·초안에 강하고 맥락 판단·우선순위·최종 리스크 승인에 약하므로, 휴먼 인 더 루프는 선택이 아니라 설계 원칙이다.
왜 읽나AI 를 QA·품질 조직에 도입하려는 엔지니어에게, 개별 도구 활용을 넘어 워크플로 통합과 사람-AI 협업 구조 설계의 1년 운영 레퍼런스.
LINE Engineering·
인프런 (인프랩)·
네이버 D2·
Vercel Blog·