안녕하세요, QA 엔지니어인 사시하시(提箸)입니다. 본 기사에서는 개발 팀에 Claude Code를 도입하는 과정에서 「에이전트의 책임 분리(Separation of Concerns)」에 도달하게 된 경위를 QA 관점에서 정리합니다. AI 에이전트를 업무에 도입하고 싶지만 품질 보증에 고민이 있는 분, 혹은 QA라는 입장에서 AI 활용에 어떻게 관여해야 할지 모색하고 있는 분들에게 참고가 되기를 바랍니다.

(주석) Claude Code의 이용은 개발 팀의 거버넌스에 따라 활용하고 있습니다.

계기: 「QA로서 할 수 있는 일은 없을까」

프로젝트는 개발 전체의 페이스가 아슬아슬한 상태로 진행되고 있었으며, 저는 평소 테스트 계획, 테스트 실시 외에도 Jira를 통한 PBI 관리나, GHAS / Snyk을 통한 취약점 대응 확인을 담당하고 있었습니다. QA라는 입장에서 테스트 공정뿐만 아니라 「개발 작업을 효율화하고 품질을 안정화」함으로써 팀에 기여할 수 없을지 고민하던 중, Claude Code를 만났습니다. 마침 몇 건의 변경 개요서와 구현(PR)이 완료된 상태였기에, 이것들을 학습 소재로 삼아 PBI로부터의 개발 플로우를 에이전트에게 맡길 수 없을지 시도해 보기로 했습니다.

첫걸음: PBI에서 PR 작성까지 시도해 보기

먼저 시도한 것은 PBI로부터 「변경 개요서 → 구현 → 타건 테스트(打鍵テスト)」까지를 Claude Code로 돌려보는 시도입니다.

• 엔지니어로부터 개발 단계에 대한 레크처를 받고 절차를 언어화
• 과거의 변경 개요서·PR을 참조 소재로 정리
• GitHub·Jira·Figma와의 연동을 순차적으로 구축하며, 트라이얼을 통해 프롬프트(Prompt)를 개수
• 엔지니어 멤버에게 프롬프트를 공유·공개하고, 저 자신도 PR을 작성

QA 엔지니어로서 강하게 의식한 것은 「재현 가능한 절차」로 떨어뜨리는 것이었습니다. 프롬프트 자체를 문서 자산으로 취급하여, 누가 실행하더라도 동일한 품질의 아웃풋이 나올 수 있도록 템플릿화를 진행했습니다.

수평 전개: 취약점 대응도 에이전트에게 맡기기

「스토리의 개수가 가능하다면 취약점 대응도 가능할 것이다」라는 발상으로, GHAS / Snyk에서 검지된 취약점도 PBI로서 Jira에 등록(현상과 대책 방침을 기재)하고, 동일한 흐름으로 제가 직접 PR을 작성하도록 했습니다. 다만, 엔지니어에게 리뷰를 받아보니 개발 관점·테스트 관점에서의 지적이 예상보다 많이 발생했습니다. 지적 내용을 프롬프트에 피드백하고, 「PBI(잠정)부터 개발까지」라는 문서로 집약하여 PBI의 기재 수준 향상, 설계·구현·PR 작성 프롬프트를 지속적으로 업데이트해 나갔습니다. 또한, PoC가 아닌 본番 적용을 염두에 두고 설계서의 리버스 엔지니어링(Reverse Engineering)도 검토하여, 「구현 → 설계 → 구현」과 같이 생성된 설계서로부터 별도의 에이전트로 동일한 구현을 재현할 수 있는지도 검증했습니다.

벽: 에이전트가 안정되지 않음

PR을 거듭할수록 품질은 조금씩 올라갔지만, 어느 단계에서 한계에 부딪혔습니다. 리버스 엔지니어링 검증 과정에서 더 심각한 과제가 보였습니다.

에이전트를 병행 기동하면 개발이 안정되지 않음

• 기동 순서나 착수 내용이 매번 바뀜
• 지시가 인계되기도 하고, 인계되지 않기도 함

QA 관점에서 말하자면, 「테스트 전제가 되는 성과물이 매번 흔들리는」 상태였으며, 이래서는 품질 보증이 성립되지 않습니다. 프롬프트를 아무리 다듬어도 에이전트 단체의 정밀도 향상만으로는 해결할 수 없는 영역에 들어서 있었습니다.

해결책: 개발 팀과 동일한 「책임 분리」를 에이전트에게도

여기서 도달한 것이 개발 팀과 동일한 역할 구성을 에이전트에게도 적용하는 접근 방식입니다. 프로젝트 운영과 마찬가지로 「관리」와 「작업자」를 나누고, 인계할 정보와 인계하지 않을 정보를 정리하여, 에이전트마다 관점(Role)을 바꾸었습니다.

구체적인 구성은 다음과 같습니다.

• 사용자가 지시를 내리는 것은 PM 에이전트(메인 대화)뿐
• PM이 **SE(변경 개요서 작성) / PG(구현 + 테스트) / QA(독립 리뷰)**로, 파일 경유를 통해 필요 최소한의 정보만을 인계
• 공정 간에 대화 이력을 전달하지 않음으로써 추인 편향(Confirmation Bias)을 배제
• QA로부터는 Edit / Write 권한을 구조적으로 제외하여, 「수정은 반드시 PG가 수행한다」를 메커니즘으로 담보

이러한 구성으로 전환하자 개발이 단번에 안정되었습니다. 서브 에이전트(Sub-agent)에게 전달하는 것은 「TICKET-ID」, 「개요서 경로」, 「브랜치명」과 같은 최소한의 컨텍스트(Context)뿐입니다. 대화 이력이나 설계 의도에 대한 해설을 전달해 버리면, 어렵게 확보한 독립적인 시각으로 바라봐야 할 에이전트에 편향(Bias)이 개입될 수 있기 때문에 이 부분은 엄격하게 규칙화하고 있습니다.

현재 위치: BA·Designer의 추가와 QA의 3분할 (v2.0)

개발 속도가 올라가자, 이번에는 PR(Pull Request)이 쌓이면서 컨플릭트(Conflict)가 증가한다는 새로운 과제가 나타났습니다. 「개발을 할 수 있다면 리뷰만도 할 수 있을 것」이라는 발상으로, 리뷰 공정 또한 에이전트에게 맡기는 방향으로 선회하고 있습니다. 다만 QA에게 직접 지시하는 형태는 품질 안정성에 대한 의구심이 남았기 때문에, 리뷰에 대해서도 PM을 경유하여 QA 에이전트를 가동하는 형태로 정리했습니다.

나아가 현재는 상기 v1.0 구성을 확장한 v2.0을 시험 운용 중입니다.

• BA (Business Analyst): SE(System Engineer) 공정의 전 단계에 배치하여, 유저 스토리(User Story) 재기술 · 수락 조건(Acceptance Criteria) 문구 확정 · 스코프 외 사항의 명문화 담당
• Designer: Figma 참조를 1개 에이전트로 집약하여, 디자인 토큰(Design Token) 추출과 PG(Programmer) 구현 후의 차이 비교를 기계적으로 실시
• QA-Unit: 단위 테스트(Unit Test) 동봉 누락, 개요서에 기재된 IT 케이스(it case) 망라 여부 체크
• QA-E2E: 시나리오 · 테스트 케이스 · E2E 코드의 3층 정합성 리뷰
• QA-Sec: Dependabot / CodeQL 잔존 여부, shell injection / 비밀 정보 혼입 검사

QA를 관점별로 3개로 분할함으로써, 병렬 실행을 통한 소요 시간 단축과 간과(Oversight) 감소를 동시에 노리고 있습니다. 특히 취약점 대응 PR이 연속되는 시기에는 Security 관점을 독립시킨 효과가 크다고 느끼고 있습니다.

QA 엔지니어로서 얻은 배움

마지막으로, 이 시도를 통해 QA 엔지니어로서 얻은 배움을 정리합니다.

• AI 에이전트는 「개별적」으로 움직이면 불안정하지만, 「조직」으로서 책무를 분리(Separation of Duties)시키면 단번에 안정된다
• 프롬프트(Prompt)는 사양서이며, 리뷰 지적 사항은 테스트 케이스의 씨앗이다
• 공정 간에 「전달할 정보 / 전달하지 않을 정보」를 설계하는 것은 편향 관리(Bias Management) 그 자체이며, QA의 특기 영역이다
• QA의 역할은 「사람의 결과물을 검사하는 것」뿐만 아니라, 「에이전트의 결과물을 검사 · 개선하는」 영역으로 확장되고 있다

향후에는 v1.0과 v2.0의 KPI(지적 건수 · 소요 시간 · 토큰 소비량)를 지속적으로 비교하여, 유효성이 확인된 구성을 본 운용으로 통합해 나갈 예정입니다. AI 에이전트 운용에 있어서의 품질 보증은 앞으로의 QA에게 큰 테마가 될 것이라고 느낍니다.

Discussion