AI로 구현 속도가 비약적으로 빨라진 지금, QA의 가치는 「쓰기 전」으로 옮겨갔다

Copilot이나 Claude Code가 직장에 들어왔다. 코드를 작성하는 것이 정말 빨라졌다.

그때 QA 엔지니어로서 어떻게 느꼈을까.

"편리하다"라고 생각하는 한편, "내 일은 앞으로 어떻게 변할까"라며 멈춰 섰던 순간이 있지 않았을까 싶다. 어렴풋이 지금까지와 마찬가지로 테스트를 작성하고, 지금까지와 마찬가지로 리뷰하고, 지금까지와 마찬가지로 릴리스하고 있다. 하지만 무언가의 균형이 조금씩 무너지고 있는 듯한 기분이 든다——그 위화감의 정체를 이번에는 정리해 보고자 한다.

먼저 결론을 써두겠다. Shift Left(조기에 품질을 구축하는 것)는 훨씬 전부터 이야기되어 왔다. 변한 것은 개념이 아니라, 게을리했을 때 치러야 하는 대가의 크기다.

그리고 이 사실이 가장 뚜렷하게 나타나는 영역이 있다. 테스트 중에서도 **비즈니스 측면의 팀 지원 테스트(Q2)**라고 불리는 영역이다. 이번에는 그 부분에 집중해서 이야기하고 싶다.

이번에 다룰 범위를 먼저 좁혀두겠다

"AI 시대에 테스트는 어떻게 변하는가"라고 한마디로 말해도, 테스트에는 다양한 역할이 있다. 테스트를 4개의 사분면으로 정리하는 Brian Marick의 사고방식이 이해하기 쉬운데, 유닛 테스트(Unit Test)에 가까운 영역(Q1), 비즈니스와 팀을 잇는 수락 기준(Acceptance Criteria)의 영역(Q2), 탐색적 테스트(Exploratory Testing)(Q3), 성능이나 보안 등의 비기능(Non-functional)(Q4)으로 나뉜다. 각각의 영역에서 AI 시대의 논점은 꽤 다르다.

이번에 다루는 것은 Q2: 비즈니스 측면의 팀 지원 테스트뿐이다. 수락 테스트(Acceptance Test)라고도 불리며, "비즈니스가 기대하는 동작을 팀에서 합의하는" 역할을 담당하는 영역이다. 릴리스 직전에 사용자에게 확인받는 UAT(User Acceptance Testing)와는 별개의 것으로, 좀 더 개발 전과 도중에 기능하는 것이라고 생각하면 된다.

왜 Q2에 집중하는가. AI assisted 개발(AI가 코딩을 지원하는 개발 스타일)의 영향을 가장 강하게 받는 곳이 여기이기 때문이다.

Q2가 성립하고 있었던, 눈에 띄지 않는 전제

Q2 이야기를 하면 대개 방법론 이야기가 중심이 된다. "수락 기준을 제대로 쓰자", "사전에 팀에서 합의하자", "구체적인 예를 테이블로 나열하자"——모두 중요하다.

하지만 이러한 방법론들이 기능하고 있었던 전제는 그다지 말로 표현되지 않았던 것 같다.

그 전제란 바로 이런 것이라고 생각한다.

코드를 작성하는 것이 느렸던 시대에는, 작성하기 전에 시간을 들여 합의하는 비용 대비 효율(Cost-performance)이 자연스럽게 맞았다.

구체적으로 생각해 보자.

어떤 기능의 구현에 1주일이 걸린다고 가정하자. 수락 기준의 합의에 반나절을 사용한다. 만약 기준이 모호한 채로 구현에 들어갔다가 재작업(Rework)이 발생하면, 1주일 전체를 낭비하게 된다. 반나절의 비용으로 1주일의 리스크를 없앨 수 있다. 이는 누가 어떻게 계산해도 할 가치가 있다는 것을 알 수 있다.

그래서 "쓰기 전에 합의하자"라는 구호는 반쯤 자연스럽게 받아들여져 왔다. 구현 비용이 높았기 때문에 합의 비용이 상대적으로 작게 보였다. 이것이 Q2의 방법론을 지탱하던 경제 구조였다.

하지만 AI가 들어오면 이 계산이 바뀐다.

「동작시키기」의 허들이 낮아지면, 「망가뜨리기」의 속도도 올라간다

이 부분이 이번에 가장 하고 싶은 말이다.

Copilot이나 Claude Code로 "일단 돌아가는 것을 만드는" 허들이 굉장히 낮아졌다. 프롬프트를 입력하면 몇 분 만에 그럴싸하게 동작하는 것이 나온다.

그렇게 되면 방금 전의 비용 대비 효율 계산이 반전되어 보인다.

구현이 30분 만에 끝난다면, 반나절을 들여 수락 기준을 합의하는 것은 표면적으로는 수지가 맞지 않아 보인다. "일단 써서 보여주는 게 더 빠르지 않아?"라는 목소리가 자연스럽게 강해진다.

하지만 여기에 함정이 있다.

동작시키는 허들이 낮아진다는 것은, 의도하지 않은 것을 동작시키는 허들도 동시에 낮아진다는 뜻이다. 빠르게 만들 수 있게 된 만큼, 빠르게 망가지기도 하게 되었다.

유닛 테스트는 통과한다. CI(Continuous Integration)도 통과한다. 리뷰도 통과한다. 하지만 릴리스 후에 비즈니스 측으로부터 "이거 우리가 원했던 게 아닌데"라는 말을 듣게 되는——이 현상이 확률적으로 증가한다. 코드는 올바르게 동작하고 있는데, 만들고 있는 것 자체가 다른 상태다.

이것은 새로운 문제가 아니다. 요구사항과 구현의 괴리는 소프트웨어 공학이 50년 동안 고민해 온 고전적인 문제다. AI는 이 문제를 해결하지도 않았고, 악화시키지도 않았다. 단지 게을리했을 때의 대가를 무시할 수 없는 크기로 밀어 올렸을 뿐이다.

속도가 올라가면 가드레일(Guardrail)이 필요하다. 나중에 수습하려고 해도 이미 늦는다.

Shift Left는 사실 「가드레일에 관한 이야기」였다

여기까지 정리하면, Shift Left라는 자주 듣는 개념의 의미가 조금 다르게 보인다.

Shift Left는 「테스트를 조기에 수행하자」라는 수법(Methodology)에 관한 이야기로 다뤄져 왔다. 하지만 본질은 조금 더 깊은 곳에 있으며, **「개발 속도에 걸맞은 가드레일(Guardrail)을 사전에 조립하자」**라는 이야기였던 것이 아닐까 생각한다.

20년 전 Shift Left가 언급되기 시작했을 무렵에는 개발 속도가 그렇게 빠르지 않았다. 그래서 가드레일이 다소 허술하더라도, 나중에 수습할 수 있는 여지가 있었다. 그렇기에 Shift Left는 「하면 좋은 권장 사항」 정도로 끝날 수 있었다. 게을리해도 어떻게든 되었으니까.

지금은 AI로 인해 개발 속도가 비약적으로 상승하면서, 그 여지가 사라지고 있다. Shift Left가 「권장」에서 「생존 조건」으로 변했다 —— 이것이 지금 일어나고 있는 일의 본질이라고 생각한다.

그리고 QA의 가치는 바로 이곳으로 옮겨가고 있다.

기존의 QA는 누군가가 작성한 수락 기준(Acceptance Criteria)을 테스트하는 업무가 중심이었다. AI 시대의 QA는 그 무게 중심이 쓰기 전으로 옮겨간다. 구체적으로는 다음과 같은 업무다.

• 개발자가 프롬프트(Prompt)를 입력하기 전에, 무엇을 만들 것인지가 언어화되어 있는지 확인한다
• 관계자들을 모아 인식의 차이를 조기에 발견할 수 있는 장을 만든다
• AI가 생성한 코드에 대해, 「이것은 무엇을 충족하기 위해 작성되었는가」를 역으로 되묻는다
• 「동작함」과 「기대대로임」 사이의 간극을, 사전 합의를 통해 측정할 수 있는 상태를 유지한다

즉, 가드레일을 설계하고, 조립하고, 유지보수하는 업무다.

이는 AI가 대체하기 어렵다. 수락 기준을 작성하려면 비즈니스 의도를 읽어내고, 관계자와 대화하며, 암묵적인 기대를 언어로 표현해야 한다. 이것은 합의 형성(Consensus building)의 업무이지, 코드 생성의 업무가 아니다.

요약

AI assisted 개발이 바꾼 것은 테스트 도구도, 수법도 아니라고 생각한다. 구현 비용이 폭락함으로써, 게을리했을 때의 대가가 표면화되었다 —— 단지 그것뿐이다.

Shift Left도, ATDD(Acceptance Test-Driven Development)도, 수락 기준을 사전에 작성하자는 사고방식도 아주 오래전부터 이야기되어 왔다. 지금 그것들이 「하면 좋은 것」에서 「하지 않으면 돌아가지 않는 것」으로 변하고 있다.

QA를 담당하는 QA의 가치는 「작성된 코드를 테스트하는 사람」에서, **「무엇이 동작하면 수락할지를 쓰기 전에 팀에서 합의할 수 있는 상태를 만드는 사람」**으로 시프트(Shift)하고 있다. 가드레일을 사후가 아니라 사전에 구축하는 사람이라고 바꿔 말해도 좋다.

직접 손을 움직이는 테스트의 속도보다, 합의의 장을 설계하는 사고방식이 앞으로는 더 유효할 것이라고 생각한다.

집필에 대하여

이 기사는 필자의 사고를 Claude(Anthropic)와 대화하며 언어화하는 방식으로 작성되었습니다. 논점의 선택, 주장의 방향성, 구성의 판단은 모두 필자가 수행하였으며, Claude에는 「독자에게 전달되는 문장으로 만드는 것」을 도움받았습니다.

양산을 위해 AI를 사용하는 것이 아니라, 내 안에 있는 생각을 보다 이해하기 쉬운 형태로 번역하고 있다는 감각에 가깝습니다.