AI가 코드를 쓰는 시대에, QA는

요즘 자주 듣는 말이 있다. "AI가 코드를 다 짜는데, QA 엔지니어가 필요한가."

반은 맞는 말이다. 실제로 자동화되는 게 많아졌다. 테스트 케이스 초안, 회귀 스크립트, 심지어 버그 재현까지 모델이 거들어준다. 그런데 이 말에는 착각이 하나 있다. QA(분야)를 "테스트 실행"과 같은 것으로 본다는 점이다. QA는 실행과 판단, 두 가지 일이다. 자동화되는 건 실행이지, "이걸 내보내도 되는가"라는 판단이 아니다. 그리고 그 판단은 전체에서 작은 조각처럼 보이지만, 대개 결과를 가르는 건 그 조각이다.

이 구분은 말로만 하면 방어적인 변명처럼 들린다. 그래서 지난 몇 달, 나는 이걸 손으로 확인해보기로 했다. QA 엔지니어로서 팀이 쓰는 스택으로 직접 도구를 만들어보면, 어디까지 자동화되고 어디서 사람이 필요한지가 추상론이 아니라 코드 위에서 드러난다. 자동화·임베딩·LLM을 QA 업무에 직접 붙여 도구 네 개를 만들었고, 그 과정에서 배운 걸 정직하게 적는다 - 잘된 것만이 아니라, 어디서 멈췄는지까지.

1. 실행은 정말 자동화된다

먼저 자동화가 잘 되는 쪽을 인정하고 시작하자. 테스트 실행은 자동화가 강한 영역이다. 그걸 직접 확인하려고, Jira 이슈 하나를 테스트 시나리오 단위로 삼아 pytest + Playwright를 돌리고 결과를 다시 Jira 코멘트로 회신한 뒤 이슈 상태까지 자동으로 전이시키는 도구(QAlity)를 만들었다. 이슈 → 실행 → 회신 → 상태 전이의 왕복이 끊기지 않고 돈다. 일부러 실패하는 케이스를 하나 넣어, 통과뿐 아니라 실패도 정확히 회신·전이되는지까지 확인했다.

그런데 여기서 배운 건 도구 자체가 아니었다. Playwright를 도입했다는 사실은 그 자체로 아무 의미가 없다. 그 실행이 이슈 트래커·릴리즈 결정 같은 일의 흐름에 어떻게 박혀 있는지가 자동화의 값을 정한다. 그러니까 "실행을 자동화한다"조차, 무엇을 어디에 연결할지를 정하는 판단이 먼저 있어야 값이 선다. 실행은 값싸지지만, 그 실행을 어디에 둘지는 여전히 사람이 정한다.

2. 좁혀주지만 결정하진 못한다 (임베딩 중복 탐지)

두 번째 실험은 작지만 QA 백로그에서 매일 새는 비용을 골랐다. 이슈 트래커가 커지면 같은 버그가 다른 표현으로 여러 번 등록된다. 새 멤버가 들어올 때, 슬랙·이메일·메모에서 이슈가 옮겨올 때, 이미 있는 이슈인 줄 모르고 또 들어온다. 사람이 매번 검색해서 잡기엔 백로그가 너무 빨리 큰다. 그래서 대개 그냥 방치되고, 그 비용은 보이지 않는 채로 쌓인다.

키워드 검색은 여기서 약하다. "결제가 안 됨"과 "구매 버튼 눌러도 반응 없음"은 같은 버그일 수 있지만 겹치는 단어가 없다. 그래서 문자열이 아니라 뜻을 비교하기로 했다. Jira API로 이슈를 대량으로 가져와 제목과 본문을 임베딩(text-embedding-ada-002)으로 바꾸고, 코사인 유사도로 가까운 쌍을 중복 후보로 띄우는 Python CLI를 만들었다. 임베딩은 캐시해서 재실행 비용을 줄였고 - 대량 비교에서도 1센트 안팎이라 "한 번 돌려보는" 부담이 없다 - 결과에는 비교한 쌍 수, API 호출, 토큰, 예상 비용까지 같이 찍었다. 자동화 자체의 비용이 투명해야 도입을 판단할 수 있으니까.

작동은 했다. 그런데 여기서부터가 진짜 배운 부분이다.

첫 번째 한계는 임계값이었다. 유사도 몇 점 이상을 "중복 후보"로 볼 것인가 - 이 숫자 하나가 도구의 성격을 정한다. 낮추면 무관한 쌍까지 잡혀 오탐(false positive)이 늘고, 오탐은 중복 아닌 걸 중복이라 말하는 거라 사람 리뷰 시간을 되레 늘린다. 높이면 진짜 중복을 놓친다. 이 precision/recall 트레이드오프를 어디에 둘지는 도구가 정해주지 않는다. 그건 판단이다. 게다가 "중복"의 기준 자체가 프로젝트마다 다르다 - 근본 원인이 같으면 중복인가, 증상이 같으면 중복인가. 임계값을 config에 박아둔 걸 나는 스스로 한계로 적어뒀다.

두 번째 한계는 더 근본적이었다. 임베딩 유사도가 높다고 진짜 중복인 건 아니다. "로그인이 안 됨"과 "로그아웃이 안 됨"은 벡터 공간에서 아주 가깝지만 전혀 다른 버그다. 반대로 진짜 중복인데 한쪽은 컴포넌트 이름으로, 한쪽은 사용자 증상으로 적혀 있으면 유사도가 낮게 나와 놓친다. 도구는 "가깝다"를 줄 뿐, "같다"를 결정하진 못한다. false positive를 걸러내고 "이 둘은 같은 이슈다"라고 최종 결정한 건 결국 QA 엔지니어였다.

정직하게 말하면, 이 도구가 어느 팀의 QA 리뷰 시간을 몇 % 줄였다는 지표는 없다. 측정 전이다. 실무의 필요를 던 개인 CLI일 뿐이다. 다만 한 가지는 분명해졌다. 도구는 후보를 좁혀 사람이 볼 범위를 줄여준다. 그 좁혀진 자리에서 "같다/아니다"를 정하는 건 여전히 판단이고, 그 판단이 이 일의 값어치였다.

3. AI가 QA를 대신 써줘도, 그 QA는 누가 믿나 (CaseMaker)

세 번째 실험은 한 발 더 나갔다. AI가 QA를 돕는 게 아니라, QA 산출물을 아예 대신 만들게 해봤다. 공개 Notion 문서 URL을 넣으면 GPT-4o-mini가 그 문서에서 QA 테스트 체크리스트를 초안·그룹핑해주는 풀스택 도구(CaseMaker)를 만들었다. 명세가 완성되기 전에도 산출물만으로 QA를 앞단으로 당기자는 shift-left 가설이었다. 인증·저장·결제까지 SaaS 골격을 다 세웠다.

그런데 만들면서 부딪힌 벽은 기능이 아니라 검증이었다. 자동 생성된 체크리스트는 그럴듯하다. 문제는 "이게 정확한가, 뭐가 빠졌나"를 어떻게 측정하느냐다. 게다가 GPT-4o-mini는 같은 문서를 넣어도 실행마다 다른 항목과 그룹을 낸다. 정확도를 재려면 기준이 고정돼야 하는데, 출력 자체가 매번 흔들리니 회귀 검증을 설계할 자리가 없었다.

그래서 이 프로젝트는 멈췄다. 기능이 부족해서가 아니라, AI가 만든 QA 산출물을 검증할 방법을 못 세워서다. 항목이 아무리 그럴듯해도 정확도와 누락을 회귀로 잡을 설계가 없으면 신뢰가 안 선다 - 그게 이 프로젝트가 남긴 QA 교훈이고, 정직하게 "멈춘 결정"으로 적어뒀다. (이름은 Figma2Checklist였지만 실제로 붙인 건 Notion 경로였다는 간극도 감추지 않고 그대로 뒀다.)

여기서 방향이 뚜렷해졌다. AI는 QA 산출물을 만들어낼 수 있다. 하지만 그 산출물을 믿어도 되는지 판단하는 건 여전히 사람 몫이고, 그 판단은 "재현되지 않는 걸 어떻게 검증하나"라는 더 어려운 문제로 이어진다. 이 문제를 다음 도구에서 정면으로 다뤘다.

4. 가장 무거운 판단 (ReleaseGate)

네 번째는 더 크게 걸었다. 중복 판단이 QA 업무의 작은 조각이고 체크리스트 생성이 앞단의 보조라면, 릴리즈 판단은 QA 엔지니어가 회의실에서 하는 가장 무거운 일이다. "이거 내보내도 되나"를 0-100 신뢰도 점수와 GO / CONDITIONAL / HOLDING / NO-GO 권고 한 줄로 압축하는 도구(ReleaseGate)를 만들었다.

출발 가설은 이랬다. 릴리즈 회의에서 결함 목록은 트래커에, 사용자 영향도는 슬랙에, 변경 위험은 PR 코멘트에 흩어져 있고, 결국 가장 목소리 큰 사람의 감으로 결정된다. 같은 정보를 같은 화면에서 같은 점수로 보면, 결정이 토론에서 검증으로 옮겨가지 않을까. 그래서 테스트 커버리지·미해결 결함·변경 위험 영역을 가중합으로 묶어 점수를 냈다. 회의가 "몇 점?"으로 시작하도록.

여기서 CaseMaker에서 못 넘은 그 벽 - 재현되지 않으면 검증할 수 없다 - 을 정면으로 만났다. LLM에게 점수를 매기게 하면 같은 입력에 같은 점수가 안 나온다. 판단을 자동화하려는데 그 판단이 재현되지 않으면, 회귀 검증 자체가 불가능하다. 어제 82점이던 릴리즈가 오늘 76점이면 나는 무엇을 신뢰해야 하나. 점수를 신뢰할 수 없으면 그 점수로 릴리즈를 막을 수도 없다.

그래서 방향을 틀었다. LLM 응답을 결정론적 목(mock)으로 고정하고, 경계값(빈 입력·50,000자 초과)과 블로커 유무에 따른 출력 구조를 회귀 대상으로 못박았다. 점수 산출이 재현 가능해진 다음에야 도구가 신뢰할 만해졌다. 이게 QA의 오래된 습관이다 - "가끔 안 됨"은 다룰 수 없다. "100번 중 3번 실패"라야 고칠 수 있다. 재현되지 않는 건 검증할 수 없다.

파는 게 릴리즈 게이트이다 보니, 내 릴리즈에도 같은 게이트를 걸었다. GO 조건과 NO-GO 조건, 롤백 기준(5XX 분당 10건 이상, 로그인 실패율 50% 이상)을 문서에 먼저 적고, 리스크 하나하나에 "검증 방법"과 해결/미해결 상태를 붙였다. 모든 변경은 문서를 먼저 고치고 그다음 구현하는 식으로.

그런데 여기서 제일 정직해야 할 부분이 있다. 내 도구는 아직 내 게이트를 다 통과하지 못한다. 커밋된 자동화 테스트는 CLI 루브릭 엔진에 몰려 있고, 정작 웹앱의 E2E와 커버리지 목표는 문서상 목표로만 남아 있다. 판정 로직의 핵심 테스트 파일 하나는 아직 빈 껍데기다. 이 도구는 MVP고, 회사 도입 사례도 정량 지표도 없다. 측정 전이다. 그 사실을 숨기지 않고 문서에 적어둔 것 - 그것도 QA에서 가져온 습관이다.

한 가지 더 배웠다. 첫 라운드에서 단일 점수를 헤드라인으로 크게 띄웠더니 "그 숫자를 믿을 수 있냐"는 질문이 너무 빨리 왔다. 점수는 결정의 시작점일 뿐이고, "어떻게 그 점수가 나왔는지"를 보여주는 근거 화면이 결정의 안전망이었다. 그래서 GO/HOLD는 끝까지 "권고"로만 뒀다. 최종 결정은 사람이 한다. 도구는 판단을 대신하는 게 아니라, 판단이 앉을 자리를 정리해줄 뿐이다.

그래서 배운 것

네 실험은 크기도 방식도 달랐지만 같은 곳을 가리켰다. 실행은 자동화된다(QAlity). 하지만 후보를 좁히는 것과 "같다"를 결정하는 것은 다르고(중복 탐지), AI가 QA를 대신 써줘도 그 결과를 믿어도 되는지는 판단이며(CaseMaker), 가장 무거운 릴리즈 판단은 재현 가능하게 만들어야 비로소 검증된다(ReleaseGate). AI는 "무엇이 잘못됐는가"를 더 빨리, 더 넓게 찾아준다. 하지만 "그래서 내보내도 되는가"는 여전히 판단이다.

오히려 AI 때문에 이 판단은 더 어려워진다. 코드가 더 빨리, 더 많이 나올수록 변경 범위가 넓어지고, 회귀 위험이 커지고, "이번 릴리즈에 뭐가 바뀌었는지"를 아무도 다 못 본다. 자동화가 실행을 값싸게 만들수록, 무엇을 실행할지와 언제 멈출지를 정하는 판단의 값어치는 오히려 올라간다.

네 도구가 결국 같은 걸 가르쳐줬다. 자동화는 실행하고, 좁히고, 생성하는 데 강하고, 결정하고 검증하는 데 약하다. 그리고 QA의 무게는 앞쪽이 아니라 뒤쪽에 있다.

그리고 이건 QA만의 얘기가 아니다. 비개발자 동료에게 LLM 사용법을 가르치려고 만든 도구(Prompt Forge)에서도, 내가 첫 화면에 박아둔 원칙은 똑같았다 - "AI는 초안 작성자, 사실 검증은 사람의 몫." QA에서 익힌 이 구분이, 일반적인 AI 사용의 첫 규칙이기도 하다는 뜻이다.

결론

"AI 시대에 QA 엔지니어는 필요 없다"는 절반만 맞다. 실행만 하는 QA 엔지니어의 자리는 줄어든다. 판단하는 QA 엔지니어의 자리는 오히려 는다.

QA(분야)가 사라지는 게 아니라, 그 무게중심이 실행에서 판단으로 옮겨가는 것이다. 리스크를 기능 설계의 입력으로 다루고, 릴리즈 판단을 조직의 기준으로 세우고, 자동화가 어디서 멈추는지를 정확히 아는 일 - 그게 내가 QA 리드/엔지니어로 돌아가려는 이유다.

도구는 계속 만들 것이다. 다만 도구를 만들어 본 이유는, 도구가 어디서 멈추는지를 알기 위해서였다. 그리고 도구가 멈추는 그 자리가, QA 엔지니어가 서 있어야 하는 자리다.

마지막으로, 개인적인 생각 하나를 덧붙이고 싶다. AI 시대에 어떤 일이든 90%는 AI가 커버할 수 있을지 모른다. 하지만 나머지 10%는 사람만이 할 수 있는 영역으로 자리매김한다. 무엇이 그 10%인지는 상황마다 다르지만, 대개 이런 것들이다. 상충하는 것들 사이에서 무엇을 포기할지 정하는 일 - 마감과 품질과 범위가 동시에 부딪힐 때. AI가 그럴듯하게 내놓은 답을 맥락을 근거로 "이건 아니다"라고 뒤집는 일. 아직 아무도 기준을 세우지 않은 자리에서 첫 기준을 세우는 일. 그리고 결정이 틀렸을 때 책임지는 일 - AI는 책임을 질 수 없다.

10%는 작아 보인다. 하지만 사업의 성패를 좌우하는 건 대개 그 10%다. 무엇을 내보낼지, 언제 멈출지, 무엇을 믿을지를 정하는 판단이 결과를 가른다. 90%를 자동화할수록, 그 10%의 값어치는 오히려 커진다.