요약
이 글은 응용기술검증팀의 QA 업무 프로세스를 소개하고, AI 검증을 포함한 효율성 개선 방법을 다룹니다. LLM as a Judge 평가 방식을 활용해 AI 제품의 품질 검증을 고도화했으며, 마인드맵 도구를 도입해 테스트케이스 작성 시간을 단축했습니다. 또한, Summary-TC를 활용해 검증 범위를 표준화하고, Katalon Studio를 이용한 자동화를 통해 반복 작업을 최적화했습니다. 마지막으로, 이슈의 중요도 및 보류 처리 기준을 명확히 정리하여 QA 프로세스를 더욱 체계적으로 개선한 방법을 설명합니다.
시작하며
안녕하세요 🙂
저는 응용기술검증팀에서 “한컴피디아”, “한컴서비스 계정”을 검증하고 있는 6년차 QA 정지영입니다.
이번에 저는 응용기술검증팀의 QA 업무를 소개하는 블로그를 작성하게 되었는데요.
먼저 간단하게 ‘QA 업무를 소개’하고, 저희가 ‘QA 업무 과정에서 겪었던 불편함을 어떻게 개선했는지’, 그리고 ‘현재는 어떤 방식으로 효율적으로 업무를 진행하고 있는지’ 까지 자세한 히스토리를 설명해 드리도록 하겠습니다.
응용기술검증팀 QA
먼저 저희 팀의 QA 업무를 소개해 드리겠습니다!
QA는 프로그램의 오류를 발견하고 사용성 이슈를 개선하여 전반적인 품질을 향상하는 역할이라고 생각하시면 되는데요.
그 중에서도 응용기술검증팀은 한글과컴퓨터에서 제공하고 있는 “AI 제품”, “솔루션 제품”, “웹 서비스 제품” 에 대한 품질을 보증하기 위해, 기능 및 사용성 동작에 대한 검증을 주 업무로 진행하는 팀 입니다.
저희 팀의 QA 프로세스를 간단히 설명드리면 아래와 같습니다.
저희 응용기술검증팀은 위 프로세스를 따라 검증 업무를 진행하면서, 몇 가지 불편함(?)을 경험해 왔는데요. 아마 QA 업무를 하다 보면 누구나 한 번쯤 겪어봤을 법한 불편함이라고 생각합니다.
그 불편함을 개선하기 위해 개인 리서치부터 팀 세미나까지 다양한 방식으로 고민을 했고, 그 과정에서 몇 가지 개선점을 발견하였습니다.
QA 프로세스 중, 생긴 불편함을 어떻게 개선할 수 있을까?
1. LLM as a Judge (AI 제품 검증 시)
2024년 초, 저희 팀은 한글과컴퓨터의 자사 sLLM과 AI 제품(한컴어시스턴트, 한컴피디아)의 품질 검증을 요청받았습니다. LLM이 표준을 충족하고 의도한 대로 답변을 생성하는지 확인하기 위해 검증이 필수적이었지만, 이를 평가할 대중적인 검증 방법이 부족했습니다. 또한, 약 20개의 다양한 LLM 평가 지표 중 어떤 기준을 우선적으로 활용해야 할지에 대한 명확한 가이드도 없어, 검증 방식을 정하는 데 어려움을 겪었습니다.
그러던 중 LLM as a Judge 평가 방법을 접하게 되었습니다.
이는 사람이 아닌 LLM이 다른 LLM의 성능을 평가하는 방식으로, 처음에는 새로운 접근법이라 신뢰성을 확신하기 어려웠습니다. 하지만 인간의 평가와 LLM 평가 간의 유사성(80% 이상)이 입증되었고, 이를 뒷받침하는 논문(Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena)도 발표된 적이 있어 LLM as a Judge 방법을 신뢰할 수 있는 평가 방식으로 받아들이게 되었습니다.
LLM 품질 검증 방법에 대한 자세한 내용은 아래 블로그를 참고 부탁드리겠습니다.
🔗 LLM 품질 테스팅 시작하기
✍ 작성자 : 응용기술검증팀 이수동님
이러한 방법론을 바탕으로 현재 한글과컴퓨터 AI 제품인 한컴어시스턴트, 한컴피디아, (s)LLM의 품질을 검증하고 있습니다. 기존에는 사람이 직접 평가하던 방식에서 벗어나 LLM 기반 평가를 도입함으로써 평가의 일관성과 효율성을 높였으며, 보다 신뢰성 있는 AI 품질 검증 체계를 구축할 수 있었습니다.
앞으로도 다양한 평가 지표를 반영하여 검증 프로세스를 고도화하고, 사용자 피드백도 참고하여 한글과컴퓨터 AI 제품의 품질을 지속적으로 개선해 나갈 계획입니다.
2. 마인드맵 도구 도입 (검증 시나리오 작성 시)
QA 업무는 검증뿐만 아니라, 검증을 준비하는 과정도 큰 비중을 차지하는데요. 그중 하나가 바로 “테스트 케이스(TC) 및 시나리오 작성과 관리”일 것입니다.
많은 QA 담당자분들이 TC 관리를 위해 스프레드시트를 활용하고 있을 텐데요.
개인적으로 저는 새로운 스펙에 대한 TC를 작성할 때, 스프레드시트에 바로바로 항목을 입력하는 것이 쉽지 않았습니다. 완벽하게 작성해야 한다는 부담감 때문에 산출물 작성이 어려워졌고, 그로 인해 예상보다 많은 시간이 소요되곤 했는데요.
TC/시나리오 작성은 QA 업무에서 중요한 부분이지만, 검증이 더 중요한 비중을 차지하기 때문에 검증에 더 많은 시간을 투입할 수 있도록 산출물 작성 시간을 줄일 필요가 있었습니다.
그래서 이 불편함을 해결하기 위해 다양한 업무 도구를 찾아본 결과, 마인드맵 도구를 활용하게 되었습니다.
처음부터 완벽하게 작성하려 하기보다는 떠오르는 아이디어를 마인드맵 형식으로 먼저 정리한 뒤, 이를 스프레드시트로 옮겨 정돈된 산출물을 작성하는 방식을 이용했는데요. 꽤 도움이 되었습니다.
처음에는 TC를 스프레드시트에 바로 작성하지 않고 마인드맵 도구를 활용하는 것이 산출물 작성에 더 많은 시간을 소모한다고 생각했지만, 마인드맵을 통해 생각을 정리하면서 결과적으로는 시간을 절약해 주었습니다. 그리고 자연스럽게 산출물 작성 시간이 줄어들어, 검증에 더 많은 시간을 확보할 수 있었습니다.
뿐만 아니라, 마인드맵을 작성하는 과정에서 브레인스토밍 효과로 쉽게 떠올리지 못했던 시나리오 조합이나 사용성 오류를 발견할 수 있었고, 이러한 과정이 기능 검증의 커버리지를 자연스럽게 높여 전반적인 프로그램 품질을 향상할 수 있었습니다.
3. Summary-TC (테스트 서버/배포 검증 시)
저희 팀은 매 검증/배포 시마다 탐색적 검증과 TC 기반 검증을 진행해 왔습니다.
신규 서비스를 런칭하거나 Major 업데이트를 진행할 경우에는 Full-TC를 기준으로 검증/배포를 진행하고, Minor 업데이트나 긴급 이슈를 수정해야하는 Hotfix 업데이트의 경우에는 Full-TC 중 중요한 기능 만을 필터링하여 검증하거나, 탐색적으로 검증한 후 배포를 진행해 왔는데요.
Minor와 Hotfix 업데이트 검증 시 Full-TC를 기준으로 검증하기 어려운 경우가 많았는데, 이는 주로 검증 일정이 부족하기 때문이었습니다. 또한, 배포 후 빠르게 주요 기능을 확인해 배포 검증을 마무리해야 하는 상황에서, Full-TC를 기준으로 검증하는게 비효율적이라고 느껴지기도 했습니다.
하지만 일정이 촉박하다는 이유만으로 불안정한 제품을 배포할 수는 없었고, 안정성이 확보되지 않은 상태에서 검증을 마무리할 수도 없었습니다.
또한, 탐색적 검증이나 Full-TC를 필터링하여 검증하는 과정에서 검증 담당자의 주관이 개입되면서 담당자별로 검증 범위가 달라지는 문제가 발생했습니다. 이에 따라, 어떤 기능을 우선적으로 검증해야 할지에 대한 명확한 기준이 필요했습니다.
이러한 문제를 해결하기 위해 Summary-TC를 도입하게 되었습니다.
Summary-TC는 일반 사용자가 경험하는 기본적인 시나리오로 구성된 테스트 케이스로, 사용자가 기본적으로 수행하는 동작에 오류가 없음을 확인할 수 있도록 작성되었습니다. 또한, Hotfix 검증이나 배포 검증 시에도 사용할 수 있도록 약 30분에서 1시간 정도의 수행 시간이 소요되는 적정한 볼륨으로 구성하였습니다.
현재 팀에서는 마일스톤 별로 TC를 관리하고 있으며, 필요에 따라 Summary-TC를 활용하여 기본 시나리오 위주의 빠른 검증을 진행하고 있는데요. 이를 통해 검증 범위를 명확하게 정의함으로써 누락 없이 기능 검증을 수행할 수 있었고, 검증 프로세스의 효율성과 정확성을 동시에 향상시킬 수 있었습니다.
| 검증 환경 | 신규 서비스 런칭 | 기능 업데이트 (Major) | 유지보수 업데이트 (Minor, Hotfix) |
|---|---|---|---|
| 테스트 서버 | Full-TC 기반 검증 | Full-TC 기반 검증 | Summary-TC 기반 검증 |
| 운영 서버 | Summary-TC 기반 검증 | Summary-TC 기반 검증 | Summary-TC 기반 검증 |
4. Katalon Studio 자동화 검증 (테스트 서버에서 검증 시)
QA 업무 특성 상, 기능 검증을 진행하다 보면 동일한 동작을 반복적으로 확인해야 하는 경우가 많습니다. 이러한 반복 작업은 많은 시간과 공수가 소요될 뿐만 아니라, 검증의 효율성을 저하하고 휴먼 에러를 유발할 가능성도 있는데요.
이를 해결하기 위해 최근 많은 QA들이 반복 작업을 자동화하여 효율성을 높이고 있습니다. 그래서 저희 팀도 이 불편함을 Katalon Studio(https://katalon.com/) 툴을 활용해, 기본 시나리오(Summary-TC 범위)를 자동화하며 검증 프로세스를 개선하고 있습니다.
자동화로 검증하게 되면 일단 시간 적으로 크게 효율적인데요.
예를 들어, 빌링 Summary-TC의 경우 기존에는 검증 담당자가 모든 절차를 직접 수행하는 데에 약 30-40분이 소요되었지만, 자동화 도입 이후에는 단 5분 만에 검증을 완료할 수 있었습니다.
또한, 각 검증 담당자가 대략 3~4개의 서비스를 맡고 있어 검증 일정이 겹치는 경우가 빈번한데, 이러한 상황에서도 자동화를 활용하여 일정에 지장을 주지 않고 모든 업무를 수행할 수 있었습니다.
검증 속도가 크게 향상되었고, 공수가 줄어드는 동시에 반복 작업에서 발생할 수 있는 휴먼 에러를 줄여 검증의 신뢰성과 정확성을 더욱 높일 수 있었습니다.
5. 릴리즈 품질 기준안 (이슈 등록/Sign-Off 시)
제품 검증 과정에서 발견된 오류는 현재 Jira를 통해 이슈를 등록하고 관리하고 있습니다.
잘 등록된 이슈란, 개발자가 검증 담당자에게 추가로 문의하지 않더라도 Jira 이슈만으로 오류를 명확히 이해할 수 있는 것이라고 생각하는데요.
그러나 이슈를 등록할 때 설정하는 결함 지표(중요도와 긴급도)에 대한 기준이 명확하지 않아, 동일한 오류라도 검증 담당자마다 중요도와 긴급도를 다르게 평가하는 문제가 있었습니다. 그리고 현재 Jira에 세팅된 8종류의 중요도(Severity) 값이 너무 많아 각 기준이 명확하지 않다 보니, 이슈 등록 시 중요도/긴급도에 대해서 고민하는 순간도 발생했는데요.
오류의 중요도와 긴급도에 검증 담당자의 주관적인 판단이 완전히 배제될 수는 없겠지만, 어느 정도 명확한 기준을 마련하는 것이 더 효과적이라고 판단하여 기준을 정리하게 되었습니다.
1. 중요도
| 중요도 | 내용 |
|---|---|
| Blocker | 페이지 접속 불가 / 앱 Crash 등의 사유로 검증 진행이 불가능한 경우 |
| Critical | • 메모리 / CPU 점유율 증가로 인한 성능 이슈 • 다른 작업에 영향을 줄 수 있는 중요 기능 오류 |
| Major | 기능 오류 및 오동작 |
| 사용 안 함 (Minor로 통합) | |
| Minor | • 기능을 제외한 UI / 리소스 / 디자인 이슈 • 다른 작업을 통해 수행이 가능한 중요도가 떨어지는 기능 오동작 |
| 사용 안 함 (불필요하다고 판단) | |
| Enhancement | 사용성 개선 의견 / 이슈 |
| Development | 현재 구현된 기능의 기능 고도화 / 추가가 필요한 경우 |
2. 긴급도
| 긴급도 | 내용 |
|---|---|
| 즉시 (P1) | ‘P2 이상의 잔여 이슈가 0건’인 경우에만 릴리즈 가능 조건을 참고하여, 담당 PO가 긴급도를 운영 / 조정할 수 있음 (협의 필요함) |
| 긴급 (P2) | |
| 보통 (P3) | |
| 낮음 (P4) |
그리고 릴리즈 기준과 이슈의 보류 처리(Later)에 대해서도 명확하게 정리하였습니다.
검증이 종료되어 Sign Off를 할 수 있는 기준이 Major 이상 잔여 이슈 0건이다 보니, 일정을 맞추기 위해 잔여 이슈를 Later 처리하는 경우가 종종 있었는데요. 무분별하게 이슈를 Later 처리하게 되면 제품의 품질을 신뢰할 수 없는 경우가 발생할 수 있었고, 그래서 이슈 보류에 대해서도 기준을 세우는 것이 필요했습니다.
3. 보류 처리 기준
| 중요도 | 보류 처리 방법 |
|---|---|
| Critical 이슈 보류 | 빠른 대응을 위한 Hoftix 마일스톤을 생성하고, 즉시 대응되어야 함 |
| Major 이슈 보류 | 다음 마일스톤에 반영되어야 함 |
| Minor 이슈 보류 | 검증/PO 담당자 협의를 통해, 마일스톤 설정이 가능함 |
표 내용처럼 중요도/긴급도/보류 처리에 대한 명확한 기준을 정해 QA 업무에 적용하였습니다.
이러한 기준을 바탕으로 이슈를 등록하고 보류 처리 기준을 명확히 함으로써, 자연스럽게 최종적으로는 Sign- Off까지 원활하게 진행할 수 있었습니다.
마치며
응용기술검증팀은 QA 업무의 불편함을 지나치지 않고, 효율성을 높이기 위해 ①새로운 품질 검증 방법인 LLM as a Judge 방법을 도입하여 AI 검증의 신뢰성을 높이고, ②마인드맵 도구를 활용해 테스트케이스 작성 시간을 단축하며, ③Summary-TC를 적용해 검증 범위를 표준화했으며, ④Katalon Studio 툴을 이용한 자동화 검증을 통해 반복 작업을 최적화했습니다. 또한, ⑤이슈의 중요도와 긴급도, 보류 처리 기준을 명확히 정리하여 QA 프로세스를 좀 더 체계적으로 구축하였습니다.
앞으로도 이전보다 발전된 모습을 보여드리겠습니다.
여기까지 읽어주셔서 감사합니다!