9. '못해요'가 아닌 '하면 되죠'

2026년 QA 컨퍼런스 아홉 번째 발표, '못해요'가 아닌 '하면 되죠' 대한 발표 내용을 정리해 보겠습니다.

이런저런 이유로 못했던 상황을 AI를 통해 해결했던 경험에 대해 발표해 주셨습니다.

공식적으로 정리하는 것이 아닌 개인적으로 정리할 겸 작성하는 포스팅이라서 주관적인 의견이 담겨있을 수 있습니다. 해당 포스팅은 컨퍼런스가 어떤 식으로 진행됐었는지 참고하는 용으로만 확인해 주세요

발표 내용의 일부분을 활용해서 포스팅이 가능하다는 사전 협의를 받았고, QA 컨퍼런스에 참여하시면 더 많은 자료를 보실 수 있으니, 내용을 참고하시어 다음 회차에 참여하고 많은 정보를 받아가시는 것을 추천드립니다!

 

 

백창준님의 '못해요'가 아닌 '하면 되죠'에 대한 발표 정리를 해보겠습니다.

 

시작은 앞선 AI 관련 발표내용처럼 코드의 속도는 빨라졌는데, 검증의 속도도 빨라졌는지에 대해 설명해 주셨고, 검증에서도 LLM을 통해 속도를 향상해야 하는 이유를 설명해 주셨습니다.

 

 

전체 발표 내용은 계획, 생성, 실행, 분석 및 개선 단계에서 활용했던 AI 시스템에 대해 설명해 주시는 방식으로 진행되었습니다.

 

계획 단계에서 못했던 부분은 리스크 기반 테스트 계획을 구성하는 것인데, 결함 발생 가능성은 어떻게 측정하고, 영향도는 어떻게 측정할지, 리스크 자체 판단 기준이 상대적인 것은 아닐지 여러 가지의 물음표가 있었던 과정에서, 아담 토른힐의 "your code as a crime scene" 이라는 책을 참고하여 동작을 하는 건 코드고, 변경이 발생한 곳, 복잡도가 높은 곳에 문제가 있을 가능성이 높다는 기준으로 리스크를 산정하는 방식으로 못하던 것을 하면 되게끔 만들었다고 알려주셨습니다.

 

파일, 클래스, 매서드, API 단위로 리스크를 측정하고 순위를 만들어서 우선적으로 테스트 자원을 활용하는 방식으로 진행한다고 하셨습니다.

 

AI를 활용해서 정해둔 리스크 규칙으로 위험도가 높은 순서로 검증할 코드들을 도출하여 우선순위를 관리한다는 것을 공유해주셨습니다.

 

생성 단계에서는 못했던 환경은 테스트 대상 코드만 주어진 환경이었고, 어떻게 테스트를 수행할 방법을 찾고 가능하게 했던 과정에 대해 설명을 해주셨습니다.

 

화이트 박스 테스트 방식처럼 기능이 수행되는 코드만 주어졌을 때 이를 어떤 식으로 테스트를 하면 될지에 대한 고민의 결과를 알려주셨고, 코드로 구성된 테스트 대상 시스템을 별도의 환경으로 분리하고, 연결되는 테스트 요청, DB, 외부연동 API를 mock 형식으로 구성하여 응답 주는 구조로 구성하여 코드 자체만 검증할 수 있는 환경을 구성했다고 알려주셨습니다.

 

모든 부분을 LLM을 통한 자동 생성을 하면 좋으나 비용이 많이 들어가기 때문에 입력합성 단계에서만 LLM을 활용했다고 하셨고, 분기 탐색 과정과 연동 캡처 단계를 통해 수행할 테스트 데이터를 만들게 된다고 하셨습니다.

 

LLM과 generator 툴을 통해 코드만 존재했던 환경에 단위 테스트 환경을 만들 수 있었고, 생성된 데이터를 예시로 보여주시며 설명해 주셨습니다.

 

실행 단계에서 못하던 부분은 크게 인증 관련 부분과 exe 형태의 커스텀 브라우저 형식이었으며, 인증 관련은 메일은 API를 활용하고, otp는 pyotp 라이브러리를 활용해서 못하던 것을 할 수 있도록 했던 결과를 공유해 주셨습니다.

 

윈도우 애플리케이션인 exe 환경에서도 내부적인 요소는 크로미움으로 구성되어 있기에 디버그 포트를 사용할 수 있었고, 제어가 가능해서 Playwright의 connectOverCDP 기능을 활용하여 테스트를 진행할 수 있었다고 알려주셨습니다.

 

분석 및 개선 단계에서 못하던 부분은 수많은 테스트가 진행된 결과를 분석하고 판정을 해야 했는데 시간 비용측면에서 부족했던 문제가 있었고, Test Impact Analysis라는 도구를 만들어서 해결했던 과정에 대해 설명해 주셨습니다.

 

테스트 별 커버하는 라인을 미리 관리해 두고, 테스트가 실패했을 때 신규 기능이나 변경 사항으로 코드 변경이 이뤄진 라인과 교집합이 이뤄진다면 근거가 만들어져서 코드 및 기능에 문제가 있다는 것을 전달하는 방식으로 구성했다고 설명해 주셨습니다.

 

앞서 생성했던 테스트 자료들의 데이터가 쌓여서 만들 수 있었던 근거 기반의 결함 판정 툴이지 않을까 싶습니다.

 

네 가지의 못해요라는 내용들을 하나씩 풀어보고 방법을 찾아갔던 과정들을 마지막에 다시 한번 정리해 주시며 전체 발표가 마무리되었습니다.

 

---

 

가장 마지막 발표였지만 내용을 이해하는 것이 쉽지 않다는 즉각적인 체감이 왔던 발표였습니다 🥲

 

사내 내부적으로 관리되는 기능들이 많기 때문에 보여주실 수 있는 게 제한적이었던 상황에서 설명해 주셔서 이번 발표 중에 가장 많이 되새김질하며 이 정리 내용이 맞을까라고 생각했던 발표였고, 사실 정리한 내용이 명확한지는 잘 모르겠습니다 😂

 

하지만 저 역시 리스크 기반 테스트를 해야 하는 것은 알지만 기준을 어떻게 잡아야 할지, 인증 방식의 테스트는 어떻게 진행해야 하며 exe 프로그램을 테스트할 땐 어떻게 진행할 수 있을지 충분히 고민할 요소와 단계가 많았고, 회사 내부적으로 고민하고 해결했던 답안지를 공유해 주신것이라 감사했습니다.

 

이번 발표 내용은 QA를 진행하며 한 번은 겪을 만한 여러 상황들이라서 다시 한번 참고해야 할 발표라고 생각하면서 이번 포스팅을 마무리하겠습니다.