생성형 AI가 등장했을 때 많은 직무가 비슷한 질문을 받았습니다. ‘이 직무는 AI로 대체될 수 있는가? 반복적인 업무는 자동화되지 않는가? 결국 사람의 역할은 줄어들지 않는가?’라는 질문들이었습니다.

QA 역시 예외는 아니었습니다. AI가 테스트 케이스를 대신 작성할 수 있다면 QA의 역할은 무엇이 될까요? 버그 분석을 AI가 수행하고 사용자 리뷰 분석까지 자동화한다면 QA는 어떤 일을 하게 될까요?

생성형 AI 기술이 빠르게 발전하면서 자연스럽게 이와 같은 질문들이 등장했고, LINE Album QA에서도 같은 고민을 했습니다. AI를 도입하면 QA의 역할이 줄어들까요? 아니면 전혀 다른 형태로 변화할까요? 실제 운영 경험을 통해 저희가 얻은 결론은 예상과는 조금 달랐습니다.

AI는 QA를 대체하지 않았습니다. 대신 QA의 사고 범위와 영향력을 확장했습니다.

저희는 AI를 단순한 생산성 도구로 사용하는 방식에는 한계가 있다고 판단했습니다. 문서를 요약하거나 테스트 케이스 초안을 생성하는 수준의 활용만으로는 QA 업무 방식 자체를 바꾸기 어렵기 때문입니다. 그래서 LINE Album QA에서는 AI를 개별 도구로 사용하는 대신, QA 운영 체계 자체를 AI 중심으로 다시 설계하는 접근을 선택했습니다.

여기에는 한 가지 중요한 전제가 있습니다. QA의 생산성은 단순히 테스트를 얼마나 빠르게 수행하느냐로 결정되지 않는다는 것입니다. 실제로 QA의 업무는 다양한 정보 속에서 맥락을 이해하고 리스크를 판단하는 과정에 더 가깝습니다. 기획 문서, 개발 변경 사항, 사용자 피드백, 테스트 결과 등 여러 출처의 정보를 빠르게 이해하고 연결하는 능력이 품질 활동의 핵심입니다.

이 관점에서 보면 QA의 문제는 테스트 속도가 아니라 정보의 양과 복잡도이며, 바로 이 지점에서 AI는 단순한 생산성 도구가 아니라, 정보를 구조화하고 사고를 확장하는 자동화 도구로 작동하기 시작했습니다.

이 글에서는 LINE Album QA에서 AI를 도입하며 경험한 변화와, AI를 중심으로 품질 운영 체계를 어떻게 재설계했는지 그 사례를 공유하고자 합니다.

QA의 역할은 원래부터 ‘테스트’가 아니었다

앞서 이야기했듯이 QA의 핵심 문제는 테스트 속도가 아니라 정보의 양과 복잡도입니다. 이 점을 이해하려면 먼저 QA의 역할을 다시 살펴볼 필요가 있습니다.

LY Corporation에서 QA 엔지니어는 단순히 기능을 검증하는 역할에 머물지 않습니다. 제품 개발 과정 전반에 걸쳐 품질 관점의 시각을 제공하는 역할을 수행합니다. 기획 단계에서는 기능 설계 과정에서 발생할 수 있는 리스크를 미리 식별하고, 개발 단계에서는 코드 변경이 제품 전체에 어떤 영향을 줄 수 있는지 분석합니다. 이후 테스트 전략을 설계하고 실제 검증을 수행하며, 릴리스 이후에는 사용자 피드백과 운영 데이터를 다시 제품 개선 과정으로 연결합니다.

이러한 관점에서 보면 QA의 역할은 단순한 테스트 수행자가 아니라 제품 개발 전 과정을 연결하는 품질 설계자(quality architect)에 가깝습니다. QA는 ‘Plan–Dev–Test–Release’로 이어지는 제품 생명 주기 전반에서 품질 관점을 유지하며 각 단계의 정보를 연결하는 역할을 합니다.

아래 그림은 각 단계의 QA의 활동과 그와 연관된 도구를 표시한 것입니다.

문제는 이러한 역할을 수행하기 위해 다뤄야 하는 정보의 규모가 계속 증가하고 있다는 점이었습니다. 실제 QA 업무에서는 다양한 출처에서 동시에 수많은 정보가 탄생해 인입됩니다. 기획 문서와 기술 설계 문서는 지속적으로 업데이트되고, Slack에는 기능 논의와 그에 따른 의사 결정이 수많은 스레드로 남습니다. Jira에는 새로운 이슈와 작업 티켓이 계속 생성되며, 서비스 릴리스 이후에는 다양한 언어로 작성된 사용자 리뷰와 피드백이 쌓이기 시작합니다. 여기에 자동화 테스트 스크립트와 실행 로그까지 더해지면서 QA가 다뤄야 하는 데이터의 양은 매우 빠르게 증가합니다.

결국 QA의 생산성을 결정하는 요소는 ‘테스트를 얼마나 빠르게 수행하는가’가 아니라, 이처럼 ‘분산된 정보를 얼마나 빠르게 구조화하고 맥락을 이해해 리스크를 판단할 수 있는가’입니다. QA는 테스트를 실행하는 사람이기 이전에 다양한 정보 속에서 품질과 관련된 신호를 찾아내는 역할을 수행하고 있었기 때문입니다. 그리고 바로 이 지점에서 AI가 중요한 역할을 하기 시작했습니다.

AI를 ‘대화 도구’에서 ‘품질 워크플로’로

AI를 처음 도입했을 때는 활용 방식이 비교적 단순했습니다. QA 엔지니어는 생성형 AI를 활용해 기획 문서를 요약하거나 테스트 케이스의 초안을 생성하고, 복잡한 버그 리포트를 정리하거나 재현 절차를 문서화하는 데 도움을 받았습니다. 이렇게 활용하는 것만으로도 생산성이 일정 수준 향상했습니다.

하지만 실제 업무에 적용해 보면서 곧 한 가지 중요한 차이를 깨달았습니다. AI를 보조 도구로 사용하는 것과 운영 체계에 통합하는 것은 완전히 다른 문제라는 점이었습니다.

초기 방식에서는 QA 엔지니어가 필요할 때마다 AI에게 질문을 던지고 결과를 받아 활용하는 구조였습니다. 이 방식은 개인의 생산성을 높이는 데는 효과적이었지만 QA 운영 전체의 효율을 개선하기에는 한계가 있었습니다. 무엇보다 QA 업무의 상당 부분은 사람이 직접 요청하기 전에 이미 시스템 안에서 다양한 형태의 이벤트로 발생하고 있었기 때문입니다.

예를 들어 새로운 Jira 티켓이나 PR(pull request)이 생성되고, 자동화 테스트가 실행되거나 사용자 리뷰가 쌓이는 순간마다 품질과 관련된 중요한 신호가 발생합니다. 하지만 기존 방식에서는 이러한 정보를 QA가 직접 모으고 정리한 뒤 AI에게 전달해야 했습니다. AI를 사용하기 위해 또 다른 수작업이 필요한 구조인 셈이었습니다.

이에 저희는 접근 방식을 바꾸기로 했습니다. ‘AI를 사람이 필요할 때 호출하는 도구로 사용하는 것뿐만 아니라 품질 이벤트에 반응하는 시스템으로 만들 수는 없을까?’ 고민했습니다. 그 고민의 결과 LINE Album QA에서는 자동화 워크플로 시스템을 구축했습니다. 현재 30개 이상의 워크플로가 운영되고 있으며, 다양한 품질 관련 이벤트가 발생하면 AI가 자동으로 분석하는 구조로 작동합니다. 아래 그림은 프로젝트 관리 단계에서 AI를 적용한 부분과 워크플로가 적용된 부분을 표기한 부분입니다.

이 시스템에서 AI는 더 이상 사람이 입력창에 질문할 때만 작동하는 대화 도구가 아닙니다. Jira 이슈 생성, 코드 변경, 테스트 실행, 사용자 피드백 수집과 같은 이벤트에 반응해 데이터를 분석하고 결과를 구조화하는 품질 운영 체계의 일부로 작동합니다.

이러한 변화는 단순히 업무 속도를 높이는 자동화를 넘어, QA가 품질 데이터를 다루는 방식 자체를 바꾸는 계기가 되었습니다.

두 가지 자동화 구조: 스케줄링과 웹훅

저희는 AI 중심의 품질 운영 체계를 구축하면서 모든 자동화를 두 가지 방식으로 나눠 설계했습니다. 하나는 정해진 시간에 실행되는 스케줄 기반 분석, 다른 하나는 이벤트가 발생하는 순간 실행되는 웹훅 기반 분석입니다. 이 두 구조는 서로 다른 목적으로 각각 QA 업무를 보완하고 지원합니다.

스케줄링 기반 자동 실행

스케줄링 기반 자동화는 특정 시간에 반복 실행하는 분석 흐름입니다. 정기적으로 발생하는 품질 데이터를 수집하고 요약해 QA 팀이 빠르게 상황을 파악할 수 있도록 돕습니다.

예를 들어 매일 App Store에서 수집하는 리뷰를 자동으로 분석해 주요 이슈를 분류하거나, API 자동화 테스트 결과를 요약해 Slack 채널로 공유하는 워크플로를 운영하고 있습니다. 또한 UI 자동화 테스트 실행 결과를 기반으로 요약 리포트를 생성하거나, 한 주 동안의 품질 활동과 주요 이슈를 정리한 주간 QA 리포트도 자동으로 작성됩니다.

이러한 자동화를 통해 QA 엔지니어의 역할도 자연스럽게 변화했습니다. 과거에는 여러 시스템에서 데이터를 직접 수집하고 정리해야 했지만, 지금은 이미 구조화된 결과를 기반으로 리스크를 판단하고 필요한 부분을 검증하는 데 집중하고 있습니다.

다음은 업무 시스템 중 하나인 Jira에서 자동으로 QA 관련 데이터를 수집해 Slack으로 알려주는 워크플로 예시입니다.

그림 3. Jira 티켓 중에 QA가 멘션된 티켓과 그 내용을 Slack에 알려주는 워크플로

웹훅 기반 이벤트 트리거

스케줄링 자동화가 정기적인 분석에 초점을 맞춘다면, 웹훅 기반 자동화는 품질 관련 이벤트가 발생하는 순간 즉시 작동하는 구조입니다.

예를 들어 새로운 Jira 티켓의 PR이 생성 후 병합되면 코드 변경 내용을 기반으로 잠재적인 영향 범위를 요약하고, Slack에서 기능을 논의하던 스레드가 종료되면 주요 의사 결정을 정리한 회의록을 생성합니다. 또한 자동화 테스트 결과가 업로드되면 실행 통계를 분석하고 시각화하는 워크플로도 함께 작동합니다.

이러한 이벤트 기반 자동화를 통해 QA 팀은 품질과 관련된 중요한 신호를 훨씬 빠르게 인지할 수 있게 되었습니다.

그림 4. PR을 분석해 변경 사항과 테스트 주요 사항을 Jira 코멘트에 추가하는 워크플로

현재 QA 업무 흐름

이 두 가지 자동화 구조를 결합하면서 QA 업무의 흐름도 이전과는 다른 형태로 정리되었습니다. AI는 정보를 수집하고 분석해 정리하는 역할을 담당하고, QA 엔지니어는 그 결과를 기반으로 리스크를 판단하고 최종 의사 결정을 수행합니다. 이는 단순히 자동화 도구를 추가하는 수준의 변화가 아닙니다. QA가 품질 데이터를 다루는 방식과 QA 업무가 시작되는 지점 자체를 바꾸는 변화였습니다.

다음은 워크플로로 자동화한 LINE Album QA의 정형화된 하루 업무 흐름을 보여주는 사례입니다. 모든 이벤트는 Slack으로 통지됩니다.

시간	작업
~ 00:00	UI 자동화 테스트 MagicPod으로 구현한 Android, iOS의 UI 자동화 테스트를 실행합니다. 테스트 결과는 자동으로 Jira 티켓으로도 업데이트하며 Slack으로 공유합니다. 만약 테스트가 실패하면 테스트 실패 분석을 실행해 플레이키 테스트(flaky test)가 발생한 것인지 그 원인을 분석합니다. 그림 5.LINE Album Android의 UI 자동화 테스트를 실행하고 결과를 Slack으로 통지
08:00	API 자동화 테스트 Pytest로 구현된 API 자동화 테스트를 실행합니다. 앞서와 마찬가지로 그 결과를 Jira 티켓으로 업데이트하며 Slack으로 공유합니다. 그림 6.LINE Album API 테스트를 실행하고 결과를 Slack으로 통지
09:00	데일리 스크럼 시작 오늘 진행할 주요 테스트 현황을 미리 공유할 수 있도록 스레드를 생성합니다. 진척 상황을 자세히 확인할 수 있도록 스크럼 보드 링크와 이슈 대시보드를 공유해 줍니다. 그림 7.데일리 스크럼을 시작하기 위한 스레드 자동 생성
09:30	미해결 이슈 확인 이어지는 스레드를 통해서 현재 진행하는 테스트 버전에서 미해결된 이슈 현황을 보고 받습니다. 또한 QA 측 확인이 필요한 이슈도 자동으로 파악돼 Slack으로 공유됩니다. 그림 8. 미해결 이슈와 QA측의 확인이 필요한 이슈를 정리하여 Slack으로 통지
09:30	멘션된 이슈 확인 Jira 티켓에서 멘션되면 메일로 알림이 오기는 하지만 이를 분류하기가 쉽지 않고 오늘 확인해야 할 멘션만 파악하는 것도 쉽지 않습니다. 따라서 스크럼 시작 시간에 미리 파악할 수 있도록 Slack에도 자동으로 멘션을 걸어줍니다. 이를 통해 메일이나 Jira 티켓으로 이동하지 않더라도 자동으로 정리된 내용을 미리 확인할 수 있습니다. 그림 9. 오늘 확인이 필요한 티켓을 담당자를 멘션해 Slack으로도 통지
09:30	앱 리뷰 분석 Android의 Google Play Store와 iOS App Store의 정보를 기반으로 매일 자동으로 리뷰 내용을 분석합니다. 리뷰 내용이 긍정인지 부정인지를 판단하고 리뷰 내용을 일본어와 한국어로 번역해 요약합니다. 이렇게 수집된 내용은 다시 한 달 단위로 묶어서 분석하고 프로젝트 팀에 공유합니다. 그림 10. App Store에 등록된 일본어 리뷰를 분석해 Slack으로 통지
10:00 ~ 17:00	집중 업무 시간 QA 엔지니어는 AI를 이용해 수집한 품질 정보를 토대로 품질 계획을 설계하고 실행합니다. 워크플로 실행 결과를 모니터링하며 워크플로 개선 작업을 진행합니다. 테스트 엔지니어는 AI 도구들을 활용해 수동 테스트와 자동화 테스트를 진행합니다. 이 시간에는 요청 이벤트에 따라 주요 대화 스레드를 위키 문서로 요약하거나 기획/개발 문서나 티켓을 분석하는 작업 등이 동시에 진행됩니다(기획/개발 문서를 분석해서 테스트 케이스까지 생성하는 워크플로에 대해서는 다음 글에 이어서 설명합니다). 그림 11. 스레드를 요약하고 Slack으로 통지 그림 12. 개발 티켓과 Git 수정 내역을 분석해 자동으로 Jira에 코멘트 추가
17:00	데일리 스크럼 종료 스크럼을 종료하기 위한 스레드를 생성합니다. 오늘 진행하기로 한 작업과 이슈 사항을 공유합니다. 그림 13. 데일리 스크럼 종료를 위한 스레드 자동 생성

AI는 테스트 파트너

테스트 케이스의 90%는 이제 AI가 작성한다

AI 중심의 품질 운영 체계를 도입한 뒤 워크플로 중 가장 크게 변화한 영역 중 하나는 테스트 설계(test design)입니다.

현재 LINE Album QA에서는 테스트 케이스를 작성할 때 그 시작의 상당 부분을 AI가 담당하고 있습니다. 2026년 기준으로 전체 테스트 케이스의 약 90%의 초안을 AI가 생성하고 있습니다. 이는 단순히 테스트 작성 속도가 빨라졌다는 의미에 그치지 않습니다. 테스트 설계의 시작 방식 자체가 바뀌었다는 뜻에 가깝습니다.

흥미로운 점은, AI를 활용한 테스트 케이스 생성 자체는 새로운 시도가 아니라는 점입니다. 이미 많은 QA 조직이 생성형 AI를 활용해 테스트 케이스 초안을 만들어 보는 실험을 해왔고, LINE Album QA 역시 초기에는 유사한 방식으로 접근했습니다. 요구 사항이나 기능 설명을 입력하면 AI가 빠르게 다수의 시나리오를 생성해 줬고 표면적으로는 꽤 그럴듯해 보였습니다.

하지만 실제 운영에 적용해 보니 한계는 분명했습니다. AI는 일반적인 기능 흐름이나 전형적인 예외 케이스를 빠르게 나열하는 데는 강점이 있었지만, 제품의 실제 맥락까지 반영하는 데는 부족했습니다. 어떤 기능이 왜 추가되었는지, 과거에 어떤 유형의 결함이 반복되었는지, 이번 변경이 기존 사용자 흐름에 어떤 영향을 줄 수 있는지와 같은 정보가 빠진 상태에서는 아무리 결과물이 많이 생성되더라도 실제 활용 가능한 테스트 케이스는 많지 않았습니다. 다시 말해 양은 늘었지만 실행 가능한 품질은 충분히 올라가지 않았습니다.

이에 저희는 단순히 AI에게 ‘테스트 케이스를 생성하라’고 요청하는 대신 QA 운영 시스템에 축적된 다양한 정보를 함께 전달하는 구조를 만들었습니다. 기능 명세, 개발 티켓, 과거 이슈, 변경 배경, 테스트 히스토리, 반복적으로 발생한 결함 패턴 등을 입력 맥락으로 연결하고, AI가 이 정보를 기반으로 테스트 시나리오를 확장하도록 설계했습니다.

이 구조는 오케스트레이터 에이전트가 조율하고 그 아래에서 5개의 서브 에이전트가 각기 다른 역할을 맡아 협업합니다. 아래 표는 각 서브 에이전트의 역할과 특징을 정리한 표입니다.

서브 에이전트	역할과 특징
Plan-Analyzer	기획 문서를 분석해 기능 목적, 핵심 흐름, 리스크, 테스트 범위를 정리
Dev-Analyzer	개발 티켓과 구현 맥락을 분석해 기술적 변경점, 의존성, 잠재적 영향 범위를 도출
TestCase-Generator	분석 결과를 바탕으로 테스트 케이스를 생성하고 시나리오를 구조화
TestCase-Validator	생성된 테스트 케이스의 커버리지, 추적성, 형식, 완성도를 평가하고 수정 포인트를 도출
Quality-Inspector	전체 워크플로 산출물을 점검하고, 피드백과 개선 이력을 다음 실행에 반영할 수 있도록 관리

먼저 Plan-Analyzer가 기획 문서와 기능 설명 및 이미지 분석을 기반으로 기본 기능 흐름을 정리하고, Dev-Analyzer가 개발 티켓과 구현 정보를 추가 분석합니다. 그다음 TestCase-Generator가 정상 흐름, 예외 흐름, 경계값 조건, 플랫폼 차이, 우선순위를 반영한 테스트 케이스를 생성합니다. 이 과정에서 단순한 요구 사항 해석에 머무르지 않고 과거 Jira 이슈나 누적된 버그 패턴을 참고해 유사 결함 가능성이 높은 확장 시나리오까지 함께 제안합니다. 즉, ‘명세에 적혀 있는 것’만 테스트하는 것이 아니라 ‘과거에 실제로 문제가 되었던 방식’까지 포함해 테스트 설계를 넓히는 것입니다.

이후 TestCase-Validator는 생성된 테스트 케이스를 다시 검토합니다. 요구 사항 커버리지, 추적 가능성, 시나리오 완성도, Given/When/Then 형식 적합성, 우선순위 분포, 플랫폼 커버리지 등을 점검하고, 부족한 부분이 있으면 다시 생성 단계로 피드백을 전달합니다. 이 검증 루프를 통해 테스트 케이스는 단순한 초안 수준을 넘어서 실제 실행 가능한 수준으로 다듬어집니다.

다음으로 Quality-Inspector가 마지막 역할을 수행합니다. 이 단계에서는 단순히 이번 실행 결과만 확인하는 것이 아니라 이전 피드백과 품질 평가 결과를 함께 참조해 다음 실행에서 더 나은 테스트 케이스를 생성할 수 있도록 개선 포인트를 축적합니다. 다시 말해, 이 워크플로는 매번 독립적으로 작동하는 자동화가 아니라 실행할수록 더 나은 테스트 설계 방향을 학습하는 운영 구조에 가깝습니다.

아래 그림은 이러한 테스트 케이스 생성 워크플로를 단계별로 정리한 것입니다.

결과적으로 AI는 기획 문서, 개발 맥락, 과거 이슈, 검증 피드백을 연결해 테스트 설계를 확장하는 중심 구성 요소가 되었습니다. 이를 기반으로 QA 엔지니어는 최종 판단, 맥락 해석, 우선순위 조정, 실제 실행 가능성 검토를 담당합니다. 그 결과 현재 테스트 설계 과정은 다음과 같은 형태로 운영되고 있습니다.

약 90%: AI가 테스트 케이스 초안을 생성
약 10%: QA가 제품 맥락과 리스크 관점에서 검증하고 보강

특히 비교적 단순한 기능이나 요구 사항이 명확한 기능은 AI가 생성한 테스트 케이스를 거의 그대로 활용하는 사례도 점점 늘어나고 있습니다.

이 변화는 QA의 역할을 줄인 것이 아니라 역할의 중심을 이동시켰습니다. QA는 더 이상 테스트 케이스를 하나씩 작성하는 데 시간을 사용하지 않습니다. 대신 AI가 생성한 테스트 전략이 실제 제품 리스크를 충분히 반영하고 있는지 판단하는 데 집중합니다.

테스트 케이스를 사람 단독, AI 단독, 사람과 AI가 함께 작성해 본 블라인드 실험

AI가 생성한 테스트 케이스 초안을 실제 운영에 활용하기 시작하면서 한 가지 질문이 생겼습니다. ‘이 방식이 정말 더 나은 결과를 만들어 내는가?’ 이를 확인하기 위해 LINE Album QA에서는 내부적으로 약 1년 정도 블라인드 실험을 진행했습니다.

실험 방식은 다음과 같습니다. 매 버전마다 테스트 엔지니어에게 테스트 케이스를 전달하고 이전과 동일하게 테스트를 진행한 뒤 피드백을 받습니다. 다만 이때 제공하는 테스트 케이스는 ‘QA 엔지니어가 직접 작성한 경우’, ‘AI가 단독 생성한 경우’, ‘AI가 생성한 초안을 QA가 검토하고 보강한 경우’가 섞여 있습니다. 각 방식의 테스트 케이스를 동일한 기준에서 리뷰하고 테스트 시나리오의 커버리지와 맥락 적합성을 중심으로 평가했습니다. 다음은 그 결과를 정리한 표입니다. 예상보다 분명한 차이를 보여줬습니다.

방식	특징
사람 단독	안정적인 시나리오 구성, 그러나 커버리지 확장에는 한계
AI 단독	다양한 시나리오 생성 가능, 하지만 제품 맥락 판단 부족
AI + 사람	커버리지와 맥락 이해가 균형을 이루는 가장 높은 완성도

사람이 작성한 테스트 케이스는 제품 맥락을 잘 반영하고 품질도 안정적이었지만 다양한 예외 상황이나 확장 시나리오를 빠르게 탐색하는 데는 한계가 있었습니다. 반대로 AI는 매우 넓은 범위의 시나리오를 제안했지만 실제 서비스 맥락이나 우선순위를 충분히 반영하지 못하는 경우가 있었습니다.

AI 모델의 성능이 향상되면서 테스트 케이스를 생성하기 위한 데이터로 기획 문서만 제공하는 경우에도 결과물이 나쁘지 않았기 때문에 테스트 엔지니어가 AI가 생성한 테스트 케이스를 사람이 작성한 것이라고 생각하는 경우가 점차 늘어났습니다. 다만 그와 같이 생성된 테스트 케이스의 수준이 평균적으로 높다고 하더라도 기능의 규모에 따라 각 테스트 케이스 간 품질 편차는 존재했습니다.

가장 결과가 좋은 것은 AI가 초안을 생성하고 QA가 이를 검증하고 보강하는 방식이었습니다. AI는 빠르게 다양한 가능성을 탐색하고, QA는 제품 맥락과 리스크 식별 관점에서 이를 정제하면서 두 접근 방식의 장점이 자연스럽게 결합되었습니다.

결론은 비교적 단순했습니다. 가장 좋은 결과를 만든 것은 AI 자체가 아니라, AI와 사람이 함께 작동하는 구조였습니다. 다시 말해 테스트 설계에서도 핵심은 AI 단독 활용이 아니라 ‘휴먼 인 더 루프(human-in-the-loop)’ 구조라는 점을 확인할 수 있었습니다.

휴먼 인 더 루프는 선택이 아니라 설계 원칙

앞서 소개한 블라인드 실험을 통해 한 가지 사실을 확인할 수 있었습니다. 테스트 설계에서 가장 좋은 결과를 만든 것은 AI 단독도, 사람 단독도 아닌 AI와 사람이 함께 작동하는 구조라는 점입니다.

이 구조를 설명할 때 자주 등장하는 개념이 바로 휴먼 인 더 루프입니다. 휴먼 인 더 루프는 AI 시스템이 모든 의사 결정을 자동으로 수행하는 것이 아니라, 사람이 중요한 판단 과정에 지속적으로 참여하는 구조를 의미합니다. 특히 품질과 같이 제품의 안정성과 사용자 경험에 직접적인 영향을 미치는 영역에서는 이 구조가 더욱 중요합니다.

AI는 특정 영역에서 매우 강력한 능력을 보여줍니다. 대량의 정보를 빠르게 요약하고, 데이터 속에서 반복되는 패턴을 탐지하며, 다양한 가능성을 기반으로 초안을 생성하는 작업은 AI가 특히 잘 수행하는 영역입니다. 또한 여러 언어로 작성된 사용자 리뷰나 피드백을 동시에 분석하는 작업에서도 AI는 높은 효율을 보여줍니다.

하지만 이러한 능력만으로 제품 품질을 결정할 수는 없습니다. 실제 제품 환경에서는 단순한 데이터 분석을 넘어 맥락과 판단이 필요한 결정이 지속적으로 발생합니다. 기능이 제품 철학에 맞는 방향으로 설계되고 있는지, 현재 우선순위가 조직 전략에 부합하는지, 사용자 감정이나 경험 측면에서 어떤 영향을 줄 수 있는지와 같은 판단은 여전히 사람의 역할에 가깝습니다. 무엇보다 최종적으로 제품 리스크를 승인하고 책임지는 과정 역시 인간의 판단이 필요합니다.

AI는 다양한 가능성을 빠르게 확장할 수 있지만, 그 방향을 결정하는 것은 사람입니다. 이런 이유로 LINE Album QA에서는 휴먼 인 더 루프를 단순한 운영 방식이 아니라 품질 시스템을 설계하는 기본 원칙으로 바라보고 있습니다. AI는 분석과 확장을 담당하고, QA는 맥락과 리스크 판단을 담당하는 구조를 명확히 구분해서 두 영역의 장점을 동시에 활용하는 것을 목표로 잡았습니다. 결국 중요한 것은 ‘AI를 얼마나 많이 사용하는가?’가 아니라, ‘사람과 AI가 어떤 구조로 함께 작동하도록 설계했는가?’였습니다.

이제 페어(pair) 테스팅은 사람과 AI가 함께

AI 활용은 정형화된 테스트 케이스 생성에만 머물지 않았습니다. 최근에는 탐색적 테스팅(exploratory testing) 영역에서도 사람과 AI가 함께 작업하는 방식이 실제 QA 운영에 적용되기 시작했습니다.

기존의 탐색적 테스팅은 테스터의 경험과 직관에 크게 의존하는 방식이었습니다. 숙련된 QA가 수행할 경우 매우 강력한 방식이 될 수 있지만, 개인의 경험 수준에 따라 테스트의 깊이나 탐색 범위가 크게 달라질 수 있다는 한계도 있었습니다. 어떤 리스크를 먼저 의심해야 하는지, 어떤 경로를 더 깊게 탐색해야 하는지는 결국 테스터 개인의 경험에 의존하는 경우가 많았습니다.

이러한 약점을 보완하기 위해 QA 현장에서는 페어 테스팅을 활용하기도 합니다. 두 명의 테스터가 함께 기능을 탐색하면서 서로 다른 관점을 교차 검증하는 방식입니다. 한 사람이 놓친 리스크를 다른 사람이 발견할 수 있기 때문에 탐색적 테스팅의 품질을 높이는 데 효과적인 방법입니다.

하지만 페어 테스팅에도 현실적인 제약이 있습니다. 가장 큰 문제는 리소스입니다. 두 명의 QA가 동시에 하나의 기능을 테스트해야 하기 때문에 항상 적용하기는 어렵습니다. 또한 두 사람이 짝을 이루더라도 경험 수준이 낮다면 충분히 깊이 탐색하지 못할 수도 있습니다.

LINE Album QA에서는 이 문제를 해결하기 위해 AI를 페어 테스팅 조력자로 활용하는 방식을 도입했습니다. 현재 탐색적 테스팅 과정에서 AI는 과거 이슈, 기능 변경 맥락, 테스트 히스토리와 같은 데이터를 기반으로 탐색적 테스트 차터(test charter)를 제안하고 추가 탐색 경로를 함께 제시합니다. QA는 이를 기반으로 테스트를 진행하면서 필요할 때 AI에게 과거 유사 이슈를 조회하거나 새로운 테스트 관점을 요청할 수 있습니다.

또한 주요 화면별로 과거에 발생한 이슈 비율을 확인해 우선순위가 높은 테스트를 제안하거나 리스크 기반의 테스트를 수행할 수 있도록 제안하기도 합니다. 아래 표는 삭제 기능과 관련된 과거 이슈를 토대로 제안 받은 내용입니다.

그림 15. 각 주요 화면의 이슈 발생 빈도 예시

이처럼 AI가 과거 데이터를 기반으로 새로운 탐색 관점을 제안하고, 테스트 엔지니어는 제품 맥락을 고려해 실제 리스크를 판단하며 테스트를 진행합니다. 비록 AI가 아직까지는 직접 탐색적 테스트를 수행하지 못하기도 하고 보완할 부분도 더 남아 있습니다만, 현재 실제 운영 과정에서 긍정적인 반응을 얻고 있습니다. 경험이 많은 시니어 테스트 엔지니어의 도움 없이도 탐색적 테스팅 과정에서 고려해야 할 관점을 더 빠르게 캐치해 확장할 수 있고, 과거 이슈를 기반으로 제안한 테스트를 참고해 더 다양한 시나리오를 탐색할 수 있기 때문입니다.

AI 도입 효과는 시간 절감이 아니라 사고 밀도 증가

AI 도입 효과를 이야기할 때 가장 자주 등장하는 질문이 있습니다. ’그래서 시간이 얼마나 줄어들었는가?’입니다. 자동화 도입 사례의 대부분이 업무 시간을 얼마나 절약했는지에 초점을 맞추기 때문입니다.

하지만 LINE Album QA에서 체감한 변화는 조금 다른 방향이었습니다. AI 기반 자동화를 도입하면서 반복 수행하던 작업의 상당 부분을 시스템으로 이전했습니다. 테스트 결과 정리, 사용자 리뷰 분석, 리포트 작성과 같은 작업을 자동화 워크플로가 처리하면서, QA 엔지니어는 이러한 데이터를 직접 수집하고 정리하는 데 시간을 쓰지 않게 되었습니다.

그 결과 QA의 업무는 자연스럽게 더 높은 수준의 판단이 필요한 영역으로 이동하기 시작했습니다. 기능 변경이 제품 전체에 어떤 영향을 줄 수 있는지 분석하고, 테스트 전략을 리스크 중심으로 재설계하며, 사용자 피드백 속에서 중요한 품질 신호를 찾아내는 활동에 더 많은 역량을 사용하기 시작했습니다. 실제로 리스크 기반 테스트의 비중도 이전보다 눈에 띄게 증가했습니다.

흥미로운 점은 이러한 변화에도 불구하고 QA의 전체 업무 시간이 극적으로 줄어들지는 않았다는 점입니다. 대신 시간을 사용하는 방식이 달라졌습니다. 반복 정리 작업에 사용하던 시간은 줄어든 반면, 제품 맥락을 이해하고 품질 리스크를 판단하는 고부가가치 의사 결정에 더 많은 시간을 사용하기 시작했습니다.

이런 경험을 통해 저희가 확인한 것은 분명합니다. AI 도입의 핵심 효과는 단순한 시간 절감이 아닙니다. AI는 QA가 더 많은 맥락을 동시에 고려하며 더 깊이 있는 판단을 할 수 있도록 사고의 밀도를 높여주는 도구에 가깝습니다.

QA는 이제 품질 오케스트레이터

AI 기반 자동화가 QA 업무에 점차 깊이 통합되면서 QA의 역할도 자연스럽게 변화하기 시작했습니다. 과거에는 테스트 케이스 작성과 실행, 결과 검증과 같은 작업이 QA 업무의 중심이었다면, 지금은 AI와 자동화 시스템을 활용해 품질 활동 전체를 설계하고 운영하는 역할이 점점 더 중요해지고 있습니다.

현재 LINE Album QA에서 QA 엔지니어의 역할은 이전보다 분명히 확장되었습니다. 먼저 AI가 생성하는 결과의 품질을 높이기 위해 어떤 맥락 정보를 입력으로 제공할지 설계하고, 결과를 어떤 형식으로 구조화할지 조정하는 작업이 중요해졌습니다. 입력 설계에 따라 AI가 생성하는 결과의 품질과 활용 가능성이 크게 달라지기 때문입니다.

또한 다양한 품질 이벤트를 자동으로 분석하도록 만들기 위해 자동화 워크플로를 설계하고 지속적으로 개선하는 작업도 중요한 역할이 되었습니다. Jira 이슈 생성, 코드 변경, 테스트 실행 결과와 같은 이벤트가 발생했을 때 어떤 분석을 수행하고 어떤 형태로 공유해야 하는지를 정의하는 과정 역시 QA 활동의 일부가 되었습니다.

이 과정에서 생성되는 다양한 데이터를 이해하고 의미 있는 품질 신호를 찾아내는 품질 데이터 분석 역할도 점점 중요해지고 있으며, 무엇보다 AI가 제시한 결과를 바탕으로 제품 리스크를 판단하고 최종 결정을 내리는 의사 결정 역할이 중요해지고 있습니다.

이러한 변화는 단순히 QA가 수행하는 작업의 종류를 바꿨다기보다는 QA의 관점을 확장한 것에 가깝습니다. QA는 더 이상 단순히 테스트를 수행하는 역할에 머무르지 않습니다. 대신 사람, AI, 품질 데이터, 자동화 워크플로가 효과적으로 작동하도록 전체 구조를 설계하고 조율하는 역할을 맡게 되었습니다.

이러한 의미에서 오늘날의 QA는 단순한 테스터라기보다 사람과 AI의 협업 구조를 설계하는 품질 오케스트레이터(quality orchestrator)에 가까워지고 있습니다.

QA에 AI를 도입하며 얻은 교훈

LINE Album QA에서 AI 중심의 품질 운영 체계는 몇 가지 분명한 교훈을 제공했습니다. 처음에는 AI 도입 자체가 중요한 과제처럼 보였지만, 실제 운영하면서 겪어보니 ‘AI를 얼마나 사용하는가’가 아니라 ‘AI를 어떻게 워크플로에 통합하느냐’가 중요하다는 점을 깨달았습니다.

AI는 단독 도구로 사용할 때보다 운영 시스템 안에서 자동으로 작동할 때 더 큰 효과를 발휘했습니다. 단순히 도구로 활용하는 게 아니라 이벤트 기반 워크플로와 결합했을 때 비로소 QA 업무 흐름 전체가 변화하기 시작했습니다.

또한 자동화가 모든 문제를 해결해 주지는 않는다는 점도 분명해졌습니다. 자동화는 반복 작업을 줄이고 분석 속도를 높이는 데에는 매우 효과적이지만, 어떤 문제를 우선 다뤄야 하는지 결정하는 일은 여전히 사람의 역할이었습니다.

테스트 설계에서도 비슷한 교훈을 얻을 수 있었습니다. 현재 테스트 케이스의 약 90%는 AI가 초안을 생성하지만, 실제 품질을 보장하기 위해서는 여전히 인간의 검증과 판단이 필요합니다. 완전한 자동화보다 사람의 판단이 결합된 구조가 더 안정적인 결과를 만들어냈습니다.

결국 저희가 얻은 결론은 비교적 단순했습니다. 가장 좋은 결과는 AI 단독 사용 구조에서 나오지 않았습니다. 언제나 AI와 사람이 함께 작동하는 구조에서 나왔습니다. 이 경험은 AI를 도입하는 조직에게 중요한 질문을 남깁니다. AI를 얼마나 많이 사용하는지가 아니라 AI와 사람이 어떤 구조로 함께 일하도록 설계했는가가 더 중요한 문제일지도 모른다는 것입니다.

결론: AI는 QA를 대체하지 않고 확장했다

생성형 AI가 등장했을 때 가장 많이 들었던 질문 중 하나는 이것이었습니다.

“QA는 AI로 대체될 수 있을까?”

실제 운영 경험을 통해 저희가 얻은 답은 분명했습니다. AI는 QA를 대체하지 않았습니다. 대신 QA의 역할과 가능성을 확장했습니다. LINE Album QA에서는 AI를 단순한 생산성 향상 도구로 사용하지 않습니다. AI로 QA 업무의 일부 작업을 대신 수행하는 게 아니라 품질 운영 체계 안에 통합하고 있습니다.

현재 LINE Album QA의 품질 시스템은 다음과 같은 구조로 운영합니다.

30개 이상의 자동화 워크플로 운영
스케줄링과 웹훅 방식을 결합한 품질 이벤트 분석
테스트 케이스의 약 90%를 AI가 초안 생성
휴먼 인 더 루프 기반 최종 품질 판단

이 구조에서 AI는 대량의 정보를 분석하고 구조화하는 역할을 담당하고 QA는 제품 맥락을 이해하고 품질 리스크를 판단하며 최종 의사 결정을 내리는 역할을 담당합니다. 이러한 역할 분담은 QA의 업무를 대체하지 않았습니다. 대신 QA가 다룰 수 있는 정보의 범위와 사고의 깊이를 확장했습니다.

QA는 더 이상 단순히 테스트를 수행하는 역할에 머무르지 않습니다. AI의 도움으로 확장한 정보에 기반해 품질 전략을 설계하고 리스크를 판단하는 역할로 이동하고 있습니다. 결국 저희가 경험한 변화는 자동화되면서 대체되는 게 아니었습니다. 사람과 AI가 함께 어우러지면서 품질 운영 체계가 확장되는 것이었습니다. 그래서 이 글을 다음 문장으로 마무리하고 싶습니다.

AI는 QA를 대체하지 않았다. 대신 QA를 확장했다.

AI는 QA를 대체하지 않았다, 대신 확장했다

댓글