AI가 개발의 속도를 바꾸고 있다. 코드를 작성하고, 문서를 만들고, 테스트 코드를 생성하고, 기존 코드를 분석하는 데 걸리는 시간은 계속 줄어들고 있다. 예전에는 하루가 걸렸을 작업이 몇 시간 안에 끝나고, 몇 시간이 걸리던 변경은 몇 번의 대화만으로 만들어지기도 한다.
처음에는 이 변화를 보면서 QA도 더 빨라져야 한다고 생각했다. 자동화 범위를 넓히고, 테스트 실행 시간을 줄이고, AI를 이용해 테스트 케이스를 더 빠르게 만드는 식으로 말이다. 그런데 일을 하면서 조금 다른 문제가 보이기 시작했다.
만드는 속도가 빨라진다고 해서 그것이 맞는지 판단하는 속도까지 같이 빨라지지는 않았다.
AI가 만든 결과물은 꽤 그럴듯하다. 코드는 빌드되고, 요구한 기능도 얼핏 잘 동작한다. 하지만 때로는 요청하지 않은 곳을 바꾸거나, 기존 동작을 깨뜨리거나, 특정 조건에서만 드러나는 문제를 남긴다.
여기서 내가 관심을 갖게 된 것은 AI가 얼마나 자주 틀리는가가 아니었다. 조금 더 근본적인 질문이었다.
우리는 무엇을 근거로 이 결과물을 믿고 다음 단계로 넘기고 있는가?
이 질문을 따라가다 보니 몇 가지 물음이 꼬리를 물었다.
우리는 틀릴 수 있다는 사실을 어떻게 받아들여야 할까.
이번 결과가 맞았다는 것과, 이 결과를 만들어낸 과정을 계속 믿을 수 있다는 것은 같은 말일까.
검증하는 시스템 자체는 무엇을 근거로 믿을 수 있을까.
이번 글에서는 이 질문들에 답을 내리려고 하지 않는다. 대신 앞으로 이 연재에서 품질과 검증을 어떤 관점으로 바라볼 것인지, 그 지도를 먼저 펼쳐보려고 한다.
틀릴 수 있다는 것을 전제로 시작한다
좋은 품질이란 무엇일까. 처음에는 당연히 오류가 적은 결과물을 만드는 것이라고 생각했다. 물론 지금도 그것이 중요하다는 생각에는 변함이 없다.
다만 AI가 대량으로 결과물을 만들어내는 환경에서는 모든 결과물이 처음부터 정확할 것이라고 기대하는 것보다, 틀린 결과가 만들어질 수 있다는 사실을 전제로 시스템을 설계하는 편이 현실적이지 않을까 하는 생각을 하게 됐다.
그렇다면 목표도 조금 달라진다. 오류가 없는 생산에서 오류 가능 → 발견 → 수정 → 다시 검증으로.
실패를 품질 시스템 밖에서 발생한 예외로 보지 않는다. 실패를 발견하고, 원인을 이해하고, 수정하고, 다시 검증하는 과정까지 품질의 일부로 본다.
다만 여기에는 함정이 있다. 틀릴 수 있다고 해서 모든 것을 더 많이 검증해야 하지는 않는다. 모든 오류를 사전에 막으려고 하면 검증 자체가 새로운 병목이 된다. 버튼의 문구를 바꾸는 것과 결제 금액을 계산하는 로직을 바꾸는 것에 같은 수준의 검증을 적용하는 것은 합리적이지 않다.
중요한 건 오류를 완전히 없애는 일이 아니다. 어떤 오류는 반드시 막아야 하고, 어떤 오류는 빠르게 발견해 복구하는 것으로 충분한지 가려내는 일이다. 내가 생각하는 품질 시스템은 여기에서 시작한다.
좋은 품질 시스템은 절대로 틀리지 않는 시스템이 아니라, 위험한 오류를 적절한 시점에 발견하고 수정할 수 있는 시스템이다.
만드는 것과 믿을 수 있게 만드는 것은 다르다
AI가 코드를 만드는 시간이 8시간에서 1시간으로 줄었다고 해보자. 굉장한 생산성 향상이다.
하지만 그 결과물을 확인하는 데는 여전히 4시간이 필요하다. 요구사항에 맞는지 확인하고, 영향 범위를 파악하고, 기존 기능이 깨지지 않았는지 보고, 실제로 배포해도 되는지 판단해야 하기 때문이다. 그러면 12시간 걸리던 일이 5시간이 될 뿐, 전체 과정이 8배 빨라지지는 않는다. 생산 속도와 검증 속도 사이에 차이가 생긴다.
여기까지만 보면 답은 단순해 보인다. 생산이 빨라졌으니 검증도 같은 속도로 빨라져야 한다. 하지만 이것도 정확한 표현은 아니다. 생산된 모든 결과물을 같은 깊이로 검증할 필요는 없기 때문이다.
AI가 하루에 열 개의 변경을 만들다가 백 개의 변경을 만들게 됐다고 해서 QA가 열 배 더 필요해지는 구조라면, 생산 자동화의 효과는 결국 사람의 판단 속도 앞에서 멈춘다.
필요한 건 검증량을 생산량에 맞춰 늘리는 일이 아니다. 사람이 들이는 검증 부담이 생산량에 비례해서 늘지 않도록 만드는 일이다. 그러려면 이렇게 해야 한다.
변경의 위험을 먼저 판단한다.
위험이 작은 변경은 가볍게, 위험이 큰 변경은 깊게 검증한다.
반복적으로 판단할 수 있는 것은 시스템이 확인하게 한다.
내가 생각하는 AI 시대의 품질 문제는 단순히 테스트를 얼마나 빨리 실행할 수 있느냐가 아니다. 생산이 늘어날수록 사람의 판단도 함께 늘어나야 하는 구조를 어떻게 바꿀 것인가. 여기에 더 관심이 간다.
한 번 맞은 것과 계속 믿을 수 있는 것은 다르다
AI가 코드를 만들었다. 그리고 실제로 완벽하게 동작했다. 그렇다면 이번 결과는 좋다. 하지만 같은 방법으로 천 개의 변경을 만들었을 때도 우리는 그 결과를 계속 믿을 수 있을까?
여기에는 서로 다른 두 질문이 있다.
“이번 결과가 맞는가?”
“이 결과를 만들고 검증하는 방식을 계속 사용해도 되는가?”
사람이 결과물을 하나씩 확인해서 품질을 유지하는 조직에서는 결국 개인의 경험과 능력이 중요한 신뢰의 근거가 된다. 하지만 생산량이 인간의 검토 능력을 넘어가기 시작하면 그 구조는 확장되기 어렵다.
앞으로 QA 일의 무게중심은 결과물을 하나씩 확인하는 것에서 결과물이 어떤 조건을 통과해야 다음 단계로 갈 수 있는지 설계하는 것으로 옮겨 갈 것이라고 생각한다.
그렇다고 단순히 “믿을 수 있는 과정”을 만들면 끝나지도 않는다. 어떤 방식이 특정 종류의 변경에서 잘 동작한다고 해서 다른 영역에서도 똑같이 잘 동작하리라는 법은 없다. 결제 변경을 잘 검증하는 기준이 영상 재생 문제도 잘 찾는다는 보장은 없다.
막연하게 “이 과정은 믿을 수 있다”고 말하기보다, 어떤 조건에서 어떤 종류의 실패를 발견할 수 있는지 알아야 한다. 신뢰에도 범위가 필요하다.
사람이 반복해서 판단하지 않아도 되는 것을 늘린다
우리는 이미 개발 과정 곳곳에서 이런 일을 하고 있다.
코드 규칙을 어기면 린트가 실패한다.
타입이 맞지 않으면 빌드가 실패한다.
테스트가 깨지면 병합을 막는다.
정적 분석에서 위험한 코드가 발견되면 경고하거나 다음 단계로 진행하지 못하게 한다.
이런 장치들에는 공통점이 있다. 사람이 결과물을 하나씩 보고 같은 판단을 반복하지 않아도 된다. 사람이 기준을 정하면 시스템이 반복적으로 그 기준을 적용한다.
AI 시대에는 이 범위가 더 넓어질 수 있다고 생각한다. 예를 들면 이런 판단들이다.
“이 변경이 결제 영역에 영향을 주는가?”
“과거에 발생했던 장애와 비슷한 변경인가?”
“요구사항과 구현 사이에 빠진 조건이 있는가?”
“이 변경이라면 반드시 실행되어야 하는 테스트가 빠져 있지는 않은가?”
이런 판단까지 시스템이 보조할 수 있다면, 사람이 모든 변경을 처음부터 읽고 판단하는 비용을 줄일 수 있다. 내가 원하는 건 모든 판단에서 사람을 없애는 일이 아니다. 사람이 반복해서 같은 판단을 해야 하는 상황을 줄이는 것에 가깝다.
하지만 여기에서도 중요한 문제가 생긴다. 자동화할 수 있다고 해서 그 판단이 옳아지지는 않는다. 잘못된 기준을 자동화하면 우리는 잘못된 판단을 더 빠르고 더 일관되게 반복하게 된다.
처음 세운 원칙은 이랬다. 사람은 기준을 만들고, 시스템은 그 기준을 반복해서 확인한다. 지금은 여기에 한 문장을 더 붙이고 싶다.
그리고 시스템이 발견하지 못한 실패는 다시 기준을 바꾼다.
기준도 완성품이 아니다. 계속 고쳐 나가야 한다.
“맞는가?”보다 “무엇을 보면 다시 의심해야 하는가?”
테스트를 할 때 우리는 흔히 “정상적으로 동작하는가?”라고 묻는다. 물론 필요한 질문이다. 하지만 AI가 매우 그럴듯한 결과를 만드는 환경에서는 다른 방향에서도 질문해볼 필요가 있다.
무엇을 발견하면 우리는 이 변경을 다시 의심해야 하는가?
두 질문은 비슷해 보이지만 생각하는 방향이 조금 다르다. 첫 번째 질문은 정상 동작을 확인하게 만든다. 두 번째 질문은 실패 조건과 경계 조건, 예상하지 못했던 경우를 먼저 생각하게 만든다.
다만 테스트가 실패했다고 해서 구현이 반드시 잘못된 것은 아니다. 다른 가능성도 있다.
테스트가 틀렸을 수 있다.
환경에 문제가 있을 수 있다.
우리가 세운 기준이 잘못됐을 수 있다.
요구사항 자체가 틀렸을 수 있다.
그래서 시스템이 실패를 알려줬을 때 필요한 것은 단순한 선언이 아니라 해석이다.
단순한 선언:
실패 → 코드가 틀림필요한 해석:
실패 → 우리가 세운 가정 중 하나가 깨짐 → 어떤 가정인지 확인
좋은 검증 시스템은 답을 대신 내려주는 시스템이라기보다, 우리가 어디를 다시 의심해야 하는지 알려주는 시스템일지도 모른다.
검증 장치는 많을수록 좋은가
그렇다면 검증 장치를 많이 만들면 품질이 좋아질까? 꼭 그렇지는 않다.
AI가 코드를 만들고, 같은 정보와 같은 가정을 가진 AI가 테스트를 만들고, 다시 같은 방식으로 코드를 검토하고, 실패하면 같은 방식으로 수정한다고 생각해보자.
코드 생성 → 테스트 생성 → 검토 → 수정
겉으로는 네 단계를 거치며 여러 번 확인한 것처럼 보인다. 하지만 네 단계가 모두 같은 잘못된 요구사항이나 같은 잘못된 가정을 공유하고 있다면 하나의 오류가 모든 검증을 통과할 수도 있다.
반대로 서로 다른 AI를 사용한다고 해서 자동으로 독립적인 검증이 되지도 않는다. 모델이 달라도 같은 잘못된 요구사항을 기준으로 판단한다면 같은 문제를 놓칠 수 있다. 따져야 할 것은 검증 도구의 개수가 아니다.
각 검증 단계가 서로 다른 실패를 발견할 수 있는가?
검증을 여러 겹 쌓는 것보다 서로 다른 관점에서 실패를 발견할 수 있도록 만드는 것이 더 중요할 수 있다.
모든 검증을 통과하면 옳은 결과일까
여기에서 더 근본적인 문제가 하나 남는다. 모든 검증이 정상적으로 동작했다고 해보자.
✅ 코드 검사 통과
✅ 단위 테스트 통과
✅ 회귀 테스트 통과
✅ 영향 범위 확인 통과
✅ 업무 규칙 확인 통과
그렇다면 이 결과물은 옳은 것일까? 꼭 그렇지는 않다. 요구사항 자체가 틀렸을 수 있기 때문이다.
잘못된 요구사항을 정확하게 구현하고, 그 요구사항을 기준으로 완벽한 테스트를 만들고, 모든 검증을 통과할 수도 있다. 우리는 잘못된 제품을 아주 높은 완성도로 만들 수도 있다.
내가 생각하는 검증 우선(Verification First)이라는 관점도 이 한계에서 자유롭지 않다. 검증 장치는 옳음을 보장하지 않는다. 우리가 합의한 기준에서 벗어나는 것을 발견할 뿐이다. 그리고 그 기준 자체가 옳은지는 여전히 별개의 문제다.
나는 검증 우선이 모든 품질 문제의 답이라고 생각하지 않는다. 오히려 검증을 중요하게 생각할수록, 무엇을 기준으로 검증하고 있는지 더 자주 의심해야 한다.
검증은 신뢰가 아니라 신뢰할 근거를 만든다
처음에는 검증 → 신뢰라고 생각했다. 하지만 지금은 이 표현도 조금 위험하다고 생각한다. 검증을 많이 통과했다는 사실이 오히려 잘못된 확신을 만들 수도 있기 때문이다. 그래서 지금은 검증 → 근거 → 판단으로 고쳐 쓴다.
검증 장치가 만드는 것은 신뢰 그 자체가 아니다. 우리가 왜 이 결과물을 믿고 다음 단계로 보냈는지를 설명할 수 있는 근거다.
예를 들어 하나의 변경이 다음 과정을 거친다고 해보자.
변경
↓
코드 규칙 확인
↓
단위·통합 테스트
↓
영향 범위 확인
↓
업무 규칙 확인
↓
검증 결과와 근거
↓
다음 단계 진행 여부 판단목표는 마지막 판단을 무조건 없애는 데 있지 않다. 판단에 드는 비용을 낮추고, 같은 판단을 사람이 반복할 필요를 줄이는 데 있다.
위험이 충분히 낮고 기준이 명확하다면 그 판단까지 자동화할 수 있다. 반대로 위험이 높거나 기준이 모호하다면 사람의 판단이 필요할 수 있다. 자동화의 목적은 사람을 없애는 것이 아니다. 사람의 판단이 정말 필요한 곳에 사람을 남기는 것이다.
그리고 검증 장치도 틀릴 수 있다
여기까지 오면 처음 이야기했던 질문으로 다시 돌아온다.
AI가 틀릴 수 있다. 개발자가 틀릴 수 있다. QA도 틀릴 수 있다. 그렇다면 우리가 만든 검증 기준과 자동화된 검증 장치도 당연히 틀릴 수 있다. 이 사실을 인정하면 중요한 원칙 하나가 생긴다.
검증 장치도 검증의 대상이다.
어떤 장애가 모든 검증을 통과한 뒤 발생했다면, “왜 이 버그를 못 잡았지?”라고 묻는 것에서 끝나서는 안 된다. 다음을 봐야 한다.
어떤 기준이 없었는지
어떤 검증이 잘못된 확신을 줬는지
기존 검증들이 같은 가정을 공유하고 있었는지
이 실패를 다음에는 더 일찍 발견하려면 어떤 기준을 바꿔야 하는지
그러면 품질 시스템은 하나의 순환 구조가 된다.
완벽한 기준을 한 번 만들어놓고 지키는 시스템이 아니다. 실패를 통해 검증 방식 자체도 계속 변하는 시스템이다.
그래서 내가 생각하는 Evidence-Driven Quality
처음 이 생각을 시작했을 때는 비교적 단순했다. AI로 생산이 빨라졌으니 검증도 빨라져야 한다.
지금은 조금 다르게 생각한다. 모든 것을 더 많이 검사하는 것이 답은 아니다. 모든 판단을 자동화하는 것도 답은 아니다. 검증 단계를 많이 만든다고 해서 신뢰가 저절로 생기지도 않는다.
내가 지금 생각하는 Evidence-Driven Quality는 이런 구조를 만드는 것에 가깝다.
우리가 틀릴 수 있다는 것을 전제로 한다.
위험한 실패를 적절한 시점에 발견할 수 있는 기준을 만든다.
반복 가능한 판단은 시스템이 수행하게 한다.
그 판단의 근거와 한계까지 다시 검증한다.
앞으로 QA에게 중요한 질문도 조금씩 달라지리라 본다. “이 기능을 어떻게 테스트할까?”뿐만 아니라 이런 질문까지 던져야 한다.
“이 변경에서 가장 위험한 실패는 무엇인가?”
“그 실패는 어디에서 발견되는 것이 가장 비용이 적은가?”
“이 판단을 사람이 계속 반복해야 하는가?”
“자동화할 수 있다면 무엇을 기준으로 판단해야 하는가?”
“그 기준이 틀렸다는 것은 어떻게 알 수 있는가?”
내가 궁금한 것은 QA라는 직무가 AI 시대에도 필요한가가 아니다.
생산하는 주체가 사람이든 AI든, 우리는 어떻게 그 결과물을 믿을 만하다고 판단할 수 있는가? 그리고 한 걸음 더 나아가, 그 판단 자체는 무엇을 근거로 믿을 수 있는가?
이 연재는 그 질문의 답을 하나씩 찾아가는 과정이 될 것 같다. 다음 글부터는 그중 첫 번째 문제를 조금 더 깊게 들여다보려고 한다.
모든 것을 검증할 수 없다면, 우리는 무엇을 먼저 검증해야 할까?