테스터의 강점: QA 전문가가 AI와 함께 더 나은 소프트웨어를 만드는 이유

코드는 저렴해졌지만, 판단력은 그렇지 않았다.

AI가 몇 분 만에 작동하는 기능을 작성할 수 있게 되면서, 희소한 기술은 더 이상 코드를 작성하는 것이 아니다. 그것은 그 코드가 무엇을 해야 하는지, 누구를 위한 것인지, 그리고 어떻게 실패할지를 아는 것이다.

나는 소프트웨어 QA 분야에서 경력을 쌓아왔다. 이제 나는 주로 AI와 함께 나만의 제품을 만들고 배포하고 있다. 어느 순간에 문득 깨달은 것이 있다: 다른 사람의 소프트웨어를 테스트하며 수년간 익힌 직감이, AI 지원 개발이 작동하게 만드는 바로 그 직감이라는 것이다.

이는 입으로 꺼내어 질문할 가치가 있는 의문을 제기한다. AI 시대에 QA 전문가는 전통적인 개발자보다 우위에 서는가? 나는 우리가 그렇다고 생각한다. 더 나은 코드를 작성하기 때문이 아니라, 우리가 화면 건너편의 사람을 생각하도록 훈련받았기 때문이다.

두 가지 다른 사고방식

개발자와 테스터는 같은 기능을 보고 서로 다른 첫 질문들을 던진다. 어느 쪽도 틀리지 않지만, 그 결과는 다른 소프트웨어로 이어진다.

개발자의 본능은 작동하게 만드는 것이다. MVP(Minimum Viable Product)를 실행하고, 티켓을 닫고, 다음 것으로 넘어가는 것. 그 본능은 가치가 있다. 그것이 모든 것이 만들어지는 방식이다. 하지만 '작동한다'는 것은 보통 개발자가 염두에 둔 데이터로, 예상한 순서대로 클릭하는 행복 경로(happy path)에서 작동한다는 것을 의미할 뿐이다.

테스터의 본능은 그곳에서 시작된다. 우리는 다음과 같은 질문을 던진다:

• 실제로 누가 이것을 사용할 것이며, 무엇을 하려고 하는가?
• 그들이 다른 순서로, 휴대폰으로, 오타를 내거나, 중간에 멈췄다가 다음 날 돌아와 할 때는 어떻게 되는가?
• 이것이 그것을 만들지 않은 사람에게도 말이 되는가?
• 무엇이 고장 나고, 그게 발생했을 때 얼마나 심각한가?

AI가 격차를 더 벌리는 이유

AI는 궁극적인 '작동하게 만드는' 엔진입니다. 기능에 대해 요청하면 실행되는 무언가를 건네줍니다. 종종 첫 시도에서 작동합니다. 하지만 스스로 할 수 없는 것은 고객을 염두에 두는 것입니다.

AI는 사용자가 필요로 하는 것이 아니라, 설명하는 것을 만듭니다. 합리적으로 들리는 기본값(default)으로 공백을 채웁니다. 흐름이 말이 되는지, 오류 메시지가 누군가에게 도움이 되는지, 또는 입력값이 비어 있을 때 무슨 일이 일어나는지 묻는 법이 거의 없습니다. AI는 자신감 있고, 빠르며, 문자 그대로입니다.

그것은 가치가 있는 곳을 바꿉니다. 코드를 작성하는 것이 느리고 비쌌을 때는, 그것을 쓸 수 있다는 것이 강점(edge)이었습니다. 이제 AI가 코드를 생성할 수 있게 되면서, 그 강점은 그것을 지시하는 사람에게로 이동합니다: 무엇을 요청해야 하는지, 무엇을 거부해야 하는지, 그리고 무엇이 빠져 있는지 아는 사람입니다.

순수한 '작동하게 만드는' 마인드셋을 AI 앞에 두면, 아무도 사용하고 싶어 하지 않는 작동하는 소프트웨어를 매우 빠르게 많이 얻게 됩니다. 같은 AI 앞에 '이것이 어떻게 사용될까'라는 마인드셋을 두면, 놀라움이 적습니다. 왜냐하면 테스터가 반사적으로 던지는 질문들이 바로 AI 스스로는 절대 묻지 않는 질문들이기 때문입니다.

실제에서 QA의 강점은 어떤 모습인가

그 장점은 작고 일상적인 습관 속에서 나타납니다. 제가 AI와 함께 구축할 때 이것이 어떻게 보이는지 알려드리겠습니다.

1. 프롬프트 작성 전에 인수 기준(acceptance criteria)을 정의합니다. 테스터는 '작동하는가?'라는 질문을 던지기 전에 먼저 무엇이 '작동한다'는 것을 정의합니다. AI에 프롬프트를 요청할 때, 저는 사용자, 목표, 그리고 완료되었을 때 참이어야 하는 조건을 설명합니다. 대상(target)이 명확하기 때문에 결과물이 더 좋습니다.
2. 기능(features) 단위가 아닌 사용자 여정(user journeys)으로 생각합니다. 저는 '회원가입 양식'을 요청하지 않습니다. 방문자가 도착하고, 가입하고, 이메일을 확인하며, 일주일 후에 돌아와 비밀번호를 잊어버리는 전체 경로를 따라갑니다. AI는 조각들을 만듭니다. 저는 그 조각들이 연결되도록 만듭니다.
3. 불행한 경로(unhappy paths)를 찾아다닙니다. 빈 상태(Empty states), 잘못된 입력, 느린 연결, 중복 제출, 뒤로 가기 버튼 등입니다. 이것들은 테스트 케이스를 작성해 본 사람이라면 누구나 자연스럽게 하는 일이며, AI가 생성한 코드가 가장 취약할 수 있는 지점이 바로 여기입니다.
4. 단지 실행된다는 이유만으로 결과물을 신뢰하지 않습니다. 테스터는 전문적인 회의론자(skeptics)입니다. 컴파일되고 데모도 잘 되는 AI 코드라도, 제가 믿기 전까지는 의도적으로 건드리고, 클릭하고, 고장 내봅니다.
5. 엔지니어로서가 아니라 고객으로서 검토합니다. 문구가 말이 되나요? 다음 단계가 명확한가요? 기술에 익숙하지 않은 제 가장 일반적인 사용자도 여기서 막힐까요? 이러한 검토는 어떤 린터(linter)도 잡아내지 못하는 문제를 포착해냅니다.

이것들 중 어느 것도 생소한 것은 아닙니다. 이것은 QA가 항상 해왔던 일이며, 이제 프로세스의 끝이 아니라 맨 앞으로 이동했을 뿐입니다. AI를 사용하면서 테스터는 더 이상 빌드가 도착하기를 기다리지 않습니다. 테스터가 빌드를 이끌어갑니다.

개발자에게 공정하게 말하자면

이것은 일반화이며, 많은 개발자들이 이를 깨뜨립니다. 사용자 중심적인 깊은 이해를 가진 개발자가 많고, 훌륭한 테스터들조차도 자신만의 사각지대(blind spots)가 있습니다.

개발자 역시 AI 시대에 더욱 중요해지는 실질적인 강점을 가져옵니다. 그들은 아키텍처(architecture), 성능(performance), 그리고 보안(security)을 이해하며, 이러한 지식은 AI가 생성한 코드가 유지보수 불가능한 더미(pile)로 변하는 것을 막아줍니다. 그들은 디프(diff)를 읽고 나쁜 패턴을 빠르게 찾아낼 수 있습니다. AI가 스스로 모퉁이에 몰릴 때, 숙련된 개발자는 그것을 빠져나오게 하는 방법을 알고 있습니다.

따라서 QA의 강점은 저절로 주어지는 것이 아닙니다. 이를 활용하려면, 구축(build)을 원하는 테스터들 역시 성장해야 합니다:

• AI의 구조가 확장될 수 없는 경우를 인식할 만큼 충분한 아키텍처 지식을 습득해야 합니다.
• AI가 생성하는 동작뿐만 아니라, AI가 작성하는 코드를 읽어야 합니다.
• 버전 관리(version control), 배포(deployment), 디버깅에 익숙해져서 전체 루프를 직접 소유할 수 있어야 합니다.

핵심은 QA가 개발을 이긴다는 것이 아닙니다. AI가 가장 빠르게 좁히는 간극은 코딩의 간극이며, AI가 겨우 건드리는 간극이 바로 사용자 사고(user-thinking)의 간극입니다. 어느 쪽에서 오든, 그곳이야말로 메울 가치가 있는 부분입니다.

미래는 사용자의 관점에서 생각하는 구축자들에게 속한다

오랫동안 QA는 마지막 단계에 머물렀습니다. 결정이 내려진 후에 완성된 빌드를 받았고, 우리의 임무는 무엇이 잘못되었는지 찾는 것이었습니다.

AI가 코드를 스스로 작성하게 되면서 상황이 역전됩니다. 가장 중요한 작업은 코드의 앞뒤에서 발생합니다: '좋다'는 것이 무엇인지 정의하고, 사용자의 경로를 상상하며, 실제로 그 사람에게 서비스를 제공할 때까지 무언가를 완료되었다고 부르기를 거부하는 것입니다. 이것이 바로 QA 마인드셋이며, 그 어느 때보다 유용해졌습니다.

만약 테스트 분야에서 왔고 자신이 구축자(builder)의 자리에 속하는지 궁금했다면, 당신은 속합니다. 당신은 AI가 할 수 없는 부분에 대해 훈련받았습니다. 고객은 당신이 일할 때 항상 같은 공간에 있었습니다. 이제는 그들을 위해 직접 구축하게 됩니다.