이전 포스팅에선 Claude code를 활용해서 자동화 코드를 생성하고 관리하는 방식을 경험했던 후기를 적어봤다면
이번에는 QA 전체적인 업무를 진행할 때 어떤 식으로 협업할 수 있을지를 생각해 봤습니다.
AI를 활용했을 때 바로 생각나는 것은 TC 생성 부분이어서 매뉴얼 TC 생성이나 자동화 코드생성 쪽으로 초점을 두고 작업을 했었는데, Claude code와 대화하면서 느낀 것은 이 친구 HTML 생성하는 것이 굉장하다는 것을 깨달아버렸습니다.
물론 csv나 ppt 다른 부분도 잘 다루지만, HTML의 시각적으로 표현하고 정리하는 방식이 뛰어나서, TC 생성 말고 관리 측면에도
활용할 수 있지 않을까라는 생각이 들었고, QA와 Claude 업무 분담에 대한 이야기를 하게 되었습니다.
오늘은 업무 분담 관련하여 Claude와 대화했던 내용을 기록 및 공유할 겸 포스팅을 시작해 보겠습니다.
서로 잘하는 것을 분담해서 업무 계획
가장 먼저 궁금한 것은 쓰면 쓸수록 모든 것을 다 잘할 것 같은 Claude의 벽을 느끼기 시작했는데, 이 친구 못하는 건 뭘까?
대화 능력? 나보다 더 체계적으로 말하는데...
업무 정리? 결과물을 보고 배우고 있을 정도로 엄청난 능력이 많다...
크래딧 관리? 그래 이 녀석 펑펑 써대서 매번 제한 걸리더라 이건 내가 관리해주지 않으면 못하더라 내 돈...
QA 능력에서 내가 더 잘하는 건 뭘까
업무 중 경험했던 것을 생각해 보면... "누가 이렇게 써요", "우리 제품 소중히 다뤄주세요"라는 얘기를 종종 들어왔는데, 예상되는 부분이 아닌 자유로운 테스트를 할 때 내가 더 잘할 수 있을 것이란 생각이 들었습니다.
그래서 Claude와 대화하면서 분담 방식을 아래처럼 나눠보게 되었습니다.
위 내용처럼 Claude가 잘하는 영역은 TC 생성, 자동화 구성, 리포트 작성 등 결과물이 발생되는 영역에서 주로 활용될 수 있을 것 같습니다.
반면에 QA가 직접 수행해야 하는 부분은 시각적인 표현, 예측 어려운 사용자의 행동, 자동화가 아닌 실제 제품 동작 수행 결과 검토, 팀 간 커뮤니케이션과 Claude가 생성한 데이터의 검증과 판단 부분이었습니다.
아무리 Claude가 TC 우선순위를 선정해서 계획해도 실제 비즈니스 리스크 판단은 QA가 직접 하며 우선순위를 조정하는 것처럼 비즈니스 관점에서 검토하고, 기획팀과 소통하여 우선순위 조정 등 실제 업무를 수행하며 협업하는 능력이 더 필요한 부분이 되는 것 같습니다.
그럼 조금 더 체계적으로 Claude와 협업하기 위해 어떤 식으로 업무를 진행해야 할까 고민하게 되었고, SDLC 방식을 기준으로 업무를 Claude와 나눈다면 어떻게 작업할지 생각해 보게 되었습니다.
SDLC 단계 별 Claude와 협업하기
SDLC 각 단계에서 Shift-left를 활용하여 사전에 결함을 예방하는 방식을 많이 사용하실 것이라 생각합니다.
저도 동일한 방식을 활용하면서 이곳저곳 많이 찾아가며 소통하고 결과를 빨리 만들어내는 방식을 사용했었는데, 이 과정에서 Claude가 참여한다면 어떤 효과를 발생할 수 있을지를 생각해 보면서 정리해 보겠습니다.
1. 요구사항 분석 단계
요구사항 분석 단계에서는 기획팀과 협업하는 일이 많은 만큼, QA의 역할이 더 많을 것이라 생각했는데, 대화를 하다 보니 Claude는 문서 기반 보조 역할을 할 수 있는 부분이 탁월하다고 느꼈습니다.
요구사항 미팅이나 소통을 통한 기능 수정 의견 전달은 당연히 QA가 수행하지만, 문서 자료 분석으로 기능의 모호한 부분 판단, 누락된 부분 검토, 제품 기능을 학습하고 있는 상태라면 유사 기능에 따른 Side-effect 분석까지 문서가 있을 때 보조 역할로 뛰어난 역할을 수행하는 것으로 보였습니다.
많은 기능이 제품에 추가되는 릴리스가 있을 때 사소한 부분은 놓칠 수 있는데, 이런 부분까지 검토하여 의견을 줄 수 있다는 것이 나만의 큰 비서 역할을 할 수 있다는 것이 놀라웠고, 실무에도 충분히 적용할 수 있을 것이라 생각했습니다.
요구사항 분석 단계에서 QA의 역할은 Claude와 검토한 내용을 QA가 1차적으로 검토하고 정리한 내용을 기획팀에 의견을 전달한다는 것이 후반부 발생할 수 있는 리스크를 많이 줄여줄 수 있을 것 같았습니다.
2. 설계 단계
설계 단계에서는 요구사항 문서 기반 TC 생성, API 테스트 시나리오 생성, TC 초안 작성 등 코드 생성과 관련된 부분 외에도 테스트플랜 작성, API 명세 검토로 보안 검토에서도 Claude를 활용해서 품질 향상에 도움 받을 수 있었습니다.
실제 개발 진행 시 변동사항이 많은 기간인 만큼 QA의 협업을 통해 변동사항을 모니터링하는 방식과 테스트 전략 협의, 환경 구성에 필요한 자료 수집 등 협업에 대한 부분은 역시 QA가 직접 수행해야 하는 부분이며, 전달받은 내용을 정리해서 Claude에 전달하면 그에 다른 테스트 전략 문서도 전달받을 수 있을 것이라 예상됩니다.
간단한 전략 예시를 만들어보게하려고, 예시 상황을 전달하며 현재 팀 구성과 어떤 식의 테스트 수행이 필요할 때 어떻게 분담해야 할지 물어봤는데, 상세한 전략과 일정까지 계획하는 모습을 보고 놀라울 따름이었습니다... 전달 받은 내용 중 검토를 통해 팀에 적용할 부분을 활용하는 것이 좋을 것 같습니다.
설계 단계에서 QA의 역할은 제품에 맞는 테스트 전략 구성과 개발팀과 협의하여 어떤 식으로 테스트를 진행할지 확인하고, Claude에서 생성된 자료 검토하며 이번 릴리스의 테스트 계획을 확정하는 부분이 중요할 것 같습니다.
3. 개발 단계
개발 단계에서는 당연히 Claude의 코드 생산 능력을 많이 활용해서 업무를 진행해야 한다고 생각했습니다.
실제로 E2E 테스트 코드나 API 테스트 코드 작성 내용을 봤을 때, 예전에 Cursor를 사용했을 때 느낌과 다르게 체계적이고 모델링과 TC 구성, 유지보수성도 고려한 코드들을 내어주는 것을 보며 정말 많이 활용해야겠다는 생각이 들었습니다.
그래서 개발 단계에서는 직접 TC를 구성하는 것보다 Claude에게 테스트 코드를 잘 작성할 수 있는 환경을 만들어주는 것이 중요하다고 생각했고, 이는 개발팀과 협업을 통해 변동사항 모니터링, 거짓 양성 결함을 예방하기 위한 생성된 TC 검토 역할이 중요하다고 생각했습니다.
개발 단계에서는 Claude를 통한 코드 및 TC 생산이 메인이고 QA가 생산된 내용을 검증하며 보조하는 느낌으로 업무를 해야 하지 않을까 생각했습니다.
4. 테스트 단계
프론트 개발도 완성된 시점이기에 테스트 단계에 진입했을 때 빠르게 E2E 스크립트를 작성하게 하고, 발생한 결함들을 리포팅하는 것에서 Claude에 역할을 부여할 수 있으며, 그동안 QA는 실 기기 테스트를 하며 사용성에 대한 검증을 수행해야 할 것입니다.
QA가 테스트 업무를 하면서 결함이 발생했을 때 관련 로그를 Claude에 전달하여 원인을 파악한 뒤 결함 리포트를 작성하면 개발팀의 수정시간도 단축시킬 수 있을 것이라 생각하고, 탐색적 테스트를 수행하며 발생한 TC를 Claude가 업데이트하게 하며 서로 협업하는 것이 중요한 부분이라 생각합니다.
테스트 단계에서는 이 결함이 진짜 결함인지, 실 기기나 브라우저에서 사용자의 기능 동작 체감 시 사용성 검토를 하는 QA의 역할도 중요하고, 문제를 빠르게 파악하고 대응 방안을 요청할 수 있으며, 회귀 테스트 케이스를 생성해 줄 Claude의 역할도 중요하여 서로 간 협업이 긴밀하게 이뤄져야 하는 단계라고 생각됩니다.
5. 배포 단계
테스트가 종료된 후 결과 보고서를 생성하는 것에 Claude의 강점이 다시 한번 발휘될 것으로 보이며, QA는 결함 수정 상황, 핵심 시나리오를 직접 수행해 보며 실제 배포가 가능할지 판단하는 역할이 주로 될 것 같습니다.
실제로 수행해보며 사전에 선정한 테스트 종료 기준을 기반으로 최종 Sing-off 판단을 해야 하는 과정이며 이후 모니터링을 통해 새로 발생된 결함에 대한 패치 일정도 생각하고, 미해결 된 결함이 있다면 추가 배포 일정도 계획해야 하는 단계이기 때문에 QA의 역할이 조금 더 중요하지 않을까 생각됩니다.
위 내용 처럼 최종 배포 전 테스트 종료 기준에 대한 체크리스트를 받아서 우리 제품에 적용할 부분들을 선정해서 활용하는 방법도 가능하며, 의견은 Claude가 전달하지만 최종 판단은 QA가 결정하는 방식으로 활용이 가능합니다.
이처럼, 배포 단계에서는 문서와 같은 산출물 작성에는 Claude의 힘을 빌리며, 판단하고 결정하며 새로운 계획을 구성해야 하는 부분에서는 QA의 역할이 중요할 것 같습니다.
정리해 보면 각 단계에 따라 QA와 Claude가 메인이 되는 시점이 변하는 것 같습니다.
전체적으로 Claude는 TC나 스크립트 생성, 업무 정리, 가이드, 산출물 생성에 큰 강점을 가졌으며, QA는 생성된 자료 검증, 사용성 검토, 타 팀과의 협업과 결정 능력이 주로 되어야 한다는 것을 알게 되었습니다.
이전에 포스팅했던 내용처럼 생성된 자료를 검토하고 판단하는 역할은 직접 수행해야 하기 때문에 이제는 코드를 생성하거나 결과를 정리하는 능력보다 검증하고 판단하는 것에 강점이 더 필요하지 않을까 생각됩니다.
개인적으로 Claude pro 라이선스를 구매해서 사용하다 보니 크래딧 이슈로 감질나게 사용하고 있지만, 사용하면 할수록 없으면 안 될 것 같다는 생각이 들고 있고, 업무에서 잘 활용할 수 있는 방법을 계속 생각해 보는 게 중요하다고 생각해서 포스팅하게 되었습니다.
Claude code를 사용한다해서 자동화 스크립트 구성쪽만 생각하는 것이 아니라, 계획 및 전략 수립, TC 초안 작성, 산출물 작성 등 문서 활용도 뛰어난 것 같아요.
언젠가 Claude Max나 자유롭게 사용할 수 있는 환경에서 일하게 된다면 실제 업무에 활용한 후기를 올릴 수 있기를 바라보며 이번 포스팅을 마치겠습니다 😊
'QA > 업무 방식' 카테고리의 다른 글
| Claude code로 TC 초안 작성하기 (2) | 2026.04.22 |
|---|---|
| 바이브 코딩 시대에서 QA에게 필요한 능력 (2) | 2026.03.28 |
| ISTQB, CSTS 취득하면 뭐가 좋은건데...? (5) | 2025.11.16 |
| AI 잘 쓰시나요?가 아닌 프롬프트 잘 쓰시나요? (3) | 2025.10.26 |
| 테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...? (4) | 2025.10.20 |
