바이브 코딩 시대에서 QA에게 필요한 능력

요즘 핫한 Claude Code 잘 쓰고 계신가요?

많은 곳에서 클로드 코드에 대한 얘기가 정말 많아지고 실무에서도 많이 활용한다고 알고 있습니다.

 

 

저도 이전에는 바이브코딩에 대해 불신이 많고 더 손이 많이 가기 때문에 어렵다고 생각했지만, 시간이 지날수록 단점을 많이 메꿔가는 방식을 찾아가는 것 같아요.

 

 

skills 연결 방법, md 파일 관리 방식을 통한 협업 방법 등등 단순히 프롬프트로 코드를 전달받는 것에서 체계적인 요청으로 원하는 코드를 받고 있는 상황인 것 같습니다.

 

 

이런 상황에서 QA는 어떤 포지션 역할을 수행하는 것이 좋을지 고민하게 되더라고요.

 

---

QA의 역할이 확장되고 있다

 

말 그대로 테스트만 수행하는 QC 역할은 점점 없어지고, 프로세스를 관리하고, 품질 관리 전략을 구상해서 실제로 테스트를 수행하는 역할은 자동화로 대체되고 있는 느낌입니다.

 

 

물론 저 역시 자동화가 탐색적 테스트처럼 경험 기반 테스팅 방식 같은 테스트들을 대체할 수 없다고 생각하지만, 반복 테스트가 필요한 부분은 자동화로 대체하고 있습니다.

 

 

이런 자동화 테스트 코드들은 앞서 말씀드린 것처럼 API 명세나 요구사항 문서 내용을 기반으로 클로드 코드를 활용해서 테스트 코드를 뚝딱뚝딱 찍어내고 있을 것 같습니다.

 

 

저도 몇 번 맛봤는데 초안을 잡아주고, 테스트 코드를 작성해 주는 것까지 정말 순식간에 찍어낼 정도로 활용성은 정말 뛰어난 것 같습니다.

 

 

이전에 AI 관련 포스팅을 했었는데, 같은 의도라도 프롬프트를 어떻게 작성했느냐에 따라 결과물이 달라질 정도로, 프롬프트 작성 능력의 중요성은 점점 커지고 있습니다.

 

 

코드를 내가 요구하는 대로, 내 환경에 맞도록 생성하기 위해 많은 시행착오 끝에 구성된 프롬프트들이 있을 것 같습니다.

 

 

 

위 이미지처럼 어떤 식으로 프로젝트 구조를 잡고, 연결할 MCP, Claude.md 구성 방식 등등 효율적인 코드 생산과 연동을 위한 구성 방식에 대한 팁과 가이드가 쏟아져 나오고 있습니다.

 

 

어찌어찌 환경을 구성하게 되었고, 테스트 코드를 만들어보고 실행해 보면 느끼실 수 있는 상황이 있습니다.

 

 

 

이렇게 만들어진 코드는 왜 안 되는 것 인가...?  이건 왜 될까...?

 

 

바이브코딩을 써보다 보니 어느샌가 생성된 코드를 눈디버깅하면서 검증하고 있던 모습을 발견하게 되었습니다.

 

 

그래서 코드 자동 생성에 필요한 프롬프트 세팅은 이름 모를 멋도리 선배님들이 해주신 것들을 받아다가 쓸 것이고...

나는 생성된 코드가 우리에게 필요한 역할을 수행하는지 확인하는 게 더 좋지 않을까...?

 

 

그래서 가장 중요한 것은 프롬프트지만, 우리에게 잘 쓰기 위한 능력은 디버깅이 아닐까 생각해 보게 되었습니다.

 

---

디버깅, 사실 흔하게 쓰고 있었던 업무 방식

 

디버깅(Debugging)은 코드에서 발생한 오류, 결함을 찾아서 원인을 분석, 수정하여 의도대로 작동하게 만드는 과정입니다.

 

 

뭔가 사전적 설명에서 QA 냄새가 나는 것 같지 않나요...?

 

 

코드 생성은 AI가 해줘서 자동화 기반을 만들어줬다면, 생성된 코드를 이해하고, 오류가 발생했을 때, 직접 수정할 수 있는 능력을 가지고 있다면, 자동화 유지보수를 더 원활하게 할 수 있지 않을까라고 생각됩니다.

 

 

 

 

물론 이상적인 말이고, 현실은 위처럼 조금 다를 수 있습니다...

 

 

그럼 조금 더 QA스럽게 AI가 생성한 내용을 디버깅한다를 표현해 본다면, 기획 문서를 claude에 넣어서 매뉴얼 TC, API TC, 시나리오 TC를 생성 요청을 했을 때 아래처럼 전달받을 수 있었습니다. 

 

 

 

 

매뉴얼은 Happy Path, Negative, 플랫폼 간 UI 차이 검증 케이스, API는 요청 방식과 예상 응답 코드까지 바로 TC로 찍어내는 결과를 얻을 수 있습니다.

 

 

그럼 출력된 결과를 검증하며 부족한 내용을 채우거나 수정하며 업무에 활용할 수 있는 TC로 만드는 방식을 활용하고 있습니다.

 

 

디버깅은 꼭 코드에만 해당하는 얘기가 아니라고 생각합니다.

 

 

AI가 생성한 TC 목록을 받아서 QA는 "이 케이스 빠진 거 아닌가?", "이 기대값이 맞나?" 하고 검토하는 것도 결국 같은 행위일 것이고, 코드든 TC든, AI 결과물을 그냥 믿지 않고 들여다보는 것. 그게 QA식 디버깅이지 않을까 생각합니다.

 

 

---

QA가 디버깅을 직접 해야 하는 이유

 

앞서 설명한 것처럼 바이브 코딩 결과물을 받은 QA는 자연스럽게 여러 생각을 가질 것입니다.

 

✅ 정상 케이스만 되는 건 아닌가?
✅ 경계값이나 예외 상황에서도 의도대로 동작하는가?
✅ 이 동작이 기획 의도와 실제로 일치하는가?

 

이런 질문에서 "이건 좀 이상한데?" 하는 순간이 오면 디버깅이 시작됩니다.

 

 

물론 다시 물어보고 새로운 답변을 받아서 해결하는 방법도 있지만, 이렇게 주고받고 하는 과정이 반복되면 직접 고치는 것보다 오래 걸리는 순간이 생기고, 수정된 답변을 받아도 다시 검증하는 것은 사람이 하는 것 이니까요.

 

 

Playwright 자동화 코드를 예시로 들어보겠습니다. 자동화를 직접 다뤄보신 분들은 익숙한 상황일 거고, 아직 경험이 없으신 분들도 "이런 과정으로 수정되는구나" 정도로 읽어주시면 충분합니다.

 

 

await page.click('.submit-btn > span:first-child')

 

 

처음에는 자동화로 위와 같은 코드를 생성했다고 했을 때, 자동화를 써보신 분들은 바로 아시겠지만, 명확한 요소가 없어서 다른 요소가 추가, 변경되었을 때 다시 동작하지 않을 수 있는 위험한 코드로 구성되었습니다.

 

 

await page.click('[data-testid="submit-button"]')

 

 

그래서 위처럼 명확한 식별자가 있는 스크립트로 변경하였고, 정상적으로 코드는 돌아가는 듯했습니다.

 

 

하지만 간헐적으로 요소를 찾지 못해 실패하는 경우가 발생했습니다.

 

 

await page.waitForSelector('[data-testid="confirm-button"]', { state: 'visible' }) 
await page.click('[data-testid="confirm-button"]')

 

 

그래서 요소가 뜰 때까지 기다리는 조건을 넣어서 안정화 코드를 추가했지만, 또다시 10번에 2~3번 실패하는 경우가 생겼습니다.

 

 

npx playwright test --repeat-each=10

 

 

그래서 동일한 테스트를 10회 진행하면서 원인을 찾아보게 되었고, 특정 API 응답이 느릴 때 실패한다는 결과를 얻을 수 있었습니다.

 

 

await page.waitForResponse(resp => resp.url().includes('/api/submit') && resp.status() === 200 )

 

 

그래서 특정 API의 응답을 받은 후 다음 작업을 진행하는 코드를 추가해서 Flaky test 비율을 낮출 수 있었습니다.

 

 

위 과정에서 한 가지 공통점이 있습니다. AI가 코드를 수정해줬어도, "이게 진짜 해결된 건지"를 판단한 건 사람이었습니다.

 

 

실패 원인을 가설로 세우고, 재현 조건을 만들고, 결과를 보고 맞는지 틀린지 판단하는 것.

 

 

검증의 주체는 결국 사람입니다. AI는 수단이고, QA는 그 수단을 올바르게 쓰는 역할이라고 생각합니다.

 

 

 

 

그래서 저는 요즘 클로드 코드로 생성된 코드를 잘 만드는 것에 초점을 두는 것보다, 생성된 코드를 잘 이해할 수 있고 문제 발생 시 어떻게 하면 유지보수 대응이 빠를 수 있을까에 대해 고민하고 있습니다.

 

 

예전에는 할루시네이션의 빈도가 높아서 참고만 했던 AI에서 협업하는 AI가 되는 방법을 찾고 있는 중입니다.

 

 

---

너의 능력. 의심은 할건데, 같이 일해보지 않을래?

 

위 내용처럼 AI를 활용해야하는 이유는 백지에서 시작하지 않을 수 있다는 것.

 

 

기획서를 받고 어떤 TC를 구성할까 고민하는 시간을 단축시켜주며, 테스트 데이터, API 검증, 문서화까지 많은 도움을 받을 수 있습니다.

 

 

하지만, 전부 맡길 수 없는 이유는 사람이 더 잘하는 부분도 있기 때문이죠.

 

 

 

 

기획 의도에 맞는 서비스인지 판단하고, 사용자 관점으로 생각해서 기능 개선안 전달, 예상밖의 행동으로 우리를 당황하게하는 사용자들의 행동을 유추하는 탐색적 테스트, 리스크에 따른 우선순위 파악으로 Sign-Off 판단까지.

 

 

그래서 어느 한쪽으로 선택해서 업무를 하는 것 보다 AI와 QA가 서로 부족한 부분을 보완한다면 효율적인 협업이 가능할 것 같다고 생각합니다.

 

 

단순히 환각효과로 인해 생성된 내용을 검토하는것이 더 오래걸린다라고 하기엔 꽤나 좋은 자료를 많이 내어주고, 아이디어를 구상하는 시간, TC 작성하는 시간도 줄이며, 사람도 완벽하지 않기 때문에 잘 써먹는 것이 중요한 것 같아요.

 

 

위에서 설명했던 playwright 코드 디버깅 과정을 돌아보면, AI가 코드를 고쳐줬지만 "이게 진짜 해결된 건지"를 판단한 건 항상 저였습니다.

 

 

실패 원인을 가설로 세우고, 재현 조건을 만들고, 결과를 보고 맞는지 틀린지 확인하는 것. 

 

 

AI는 좋은 코드를 빠르게 만들어줄 수 있지만, 그 코드가 우리 서비스에서 올바르게 동작하는지 검증하는 주체는 결국 사람입니다. 

 

 

결론적으로 포스팅에서 전달하고 싶었던 내용은 AI가 빠르게 코드를 찍어낼수록, "이게 맞아?"를 판단하는 눈의 가치는 더 올라간다고 생각하고, 좋은 눈을 가지기 위한 노력은 AI와 협업하고 실무 적용 경험을 통해 쌓으며 만드는 것이 중요할 것 같습니다.

 

 

---

번외) 자동 생성도 좋지만, 꽃신이 되어 버리진 않을까

 

"원숭이 꽃신"이라는 동화를 아시나요?

 

 

원숭이는 신발을 신지 않고 생활했는데, 오소리의 권유와 무료 마케팅으로 신발을 신어보게 되었습니다.

 

 

굳은살이 박힌 발을 부드럽게 만들어야 한다고 설득당한 원숭이는 신발을 신는 것에 불편함도 있지만, 점차 적응하며 맨발로 다니는 방법을 잊어가고 있었습니다.

 

 

오소리는 원숭이가 꽃신을 교체할 때마다 무료에서 적은 비용을 요구하고 교체할 때마다 조금씩 더 큰 비용을 요구하게 되었습니다.

 

 

원숭이는 자금이 떨어졌고, 맨발로 다닐 수 없는 상태가 되어 오소리의 심부름을 하며 종속적인 삶을 살아가는 동화입니다.

 

 

이처럼 편하고 효율적인 방식을 추구하며 환경을 개선하는 것도 좋지만, 너무 종속적인 환경을 만들어버린다면 값 비싼 꽃신도 구매할 수밖에 없어지지 않을까 우려가 되는 부분도 있습니다.

 

 

이런 얘기를 하는 이유는 최근 이슈로 AI가 코딩을 대신해주기 때문에 앞으로 코딩하는 사람은 필요 없다는 얘기가 들려오고 있습니다. 

 

 

저 역시 자동 생성되는 코드들을 경험해 보며 직접 코드를 하나하나 찍어낼 일은 많지 않고, 어느 정도 구성된 코드를 이해하고 수정할 수 있는 능력을 키우는 게 더 좋겠다 싶어서 이번 글을 쓰는 것도 있지만, 현재 AI가 대세인 상황에서 살아남을 방법을 찾는 느낌이라 쉽지 않긴 하네요.

 

 

위처럼 모두가 꽃신을 신기에 나도 신어야 하는 상황이라면, 편안함을 즐기는 것에서 멈추지 않고, 활동 범위를 넓힐 수 있다는 마음으로 분야를 확장하는 것도 좋을 것 같습니다. 저 역시 변화에 따라가는 사람이 되기 위해 노력하는 것처럼 IT 업계 자체가 힘들지만 다른 분들도 힘내시길 바라며 다음 포스팅 때 뵙겠습니다 🫡