Claude의 테스트 설계가 신뢰할 수 없어서 ── 회고와 시운전 Skill을 AI에 도입하기

처음 뵙겠습니다! ikedan입니다!

2026년 1월에 TOKIUM에 입사하여 QA 팀에 소속되어 있습니다.

전직에서도 AI를 사용한 테스트 자동화를 하고 있었지만, 입사 후 처음으로 Claude Code를 사용했습니다.

테스트 자동화에 관해 여러 가지로 모색하고 있는 중이라, 앞으로 테스트 자동화에 관한 기사를 집필하도록 하겠습니다!

저의 평소 QA 업무는 대략 다음과 같은 흐름입니다.

[IMG:0]

이 중, 파란색으로 둘러싸인 「테스트 설계 (Test Design)」와 「품질 평가 (Quality Evaluation)」를 현재 Claude Code로 자동화하는 시도를 하고 있습니다.

최근 QA로서의 업무는 기존의 "인간과 인간이 성과물의 품질을 보증하는 것"에서 "인간과 AI가 성과물의 품질을 함께 지키는 것"으로 변화하고 있습니다.

협업 상대가 바뀌었을 뿐인 것처럼 보이지만, AI를 상대할 때는 평범하게 대화하는 것만으로는 걸러내지 못하는 종류의 문제들이 늘어나고 있습니다.

본 기사는 그 문제에 대해, 인간이 당연하게 사용하고 있는 규율(회고와 시운전)을 AI에 적용한 기록입니다.

(후술하겠습니다만) 먼저 결론부터 말씀드리면,

다음과 같이 인간의 습관을 Claude에서도 작동하는 형태로 번역함으로써 재정비를 도모했습니다.

인간의 습관	Claude에 대한 적용
회고(Retrospective)에서 교훈을 공유한다	오탐지(False Positive) 판정이나 반성을 대화 외의 파일에 영구화한다
내가 만든 것을 내가 직접 사용한다	규칙이나 Skill을 추가한 후, 해당 세션 내에서 반드시 한 번은 실행해 본다

결과적으로 AI의 실수 패턴을 억제할 수 있었고, 잠재화되기 쉬운 과제를 가시화할 수 있게 되었습니다.

어느 날, Claude Code(이하 Claude)가 세션을 넘어 기억을 공유하기 위한 작업 파일(MEMORY.md)에 "태스크 완료 · 테스트 케이스 약 60건 · 스코어 94점"이라고 적어 두었습니다.

보고 문구만 보고 OK를 내린 다음 날, Claude의 Excel을 열어보니 건수는 보고보다 적었고, 내용도 "94점"이라고 적힌 품질에는 도저히 어울리지 않는 것이었습니다.

실물을 확인하지 않고 승인한 제 잘못이었습니다.

하지만 왜 Claude는 이런 보고를 작성했을까요?

대화 로그만으로는 같은 실수가 반복됩니다

Claude는 우리 팀의 "또 다른 멤버"입니다.

매일 태스크를 전달하고, 리포트를 받고, 토론합니다.

동료로서 대하다 보니, Claude에게도 인간과 똑같은 문제가 발생한다는 것을 깨달았습니다.

"같은 실수를 반복하는" 문제입니다.

QA 현장에는 세션을 넘어 Claude에게 전달하고 싶은 지식이 산더미처럼 쌓여 있습니다. 예를 들어 다음과 같은 것들입니다.

• 채점 범위의 착오: AI가 출력한 테스트 케이스를 자동 채점할 때, 본래 봐야 할 시트만을 대상으로 해야 하는 규칙인데, 대상 외의 시트까지 채점에 포함시켜 스코어를 낮춰버리는 경우
• 사전 조사 생략: 테스트를 만들기 전 대상 화면의 UI 요소를 목록화하는 절차를 AI가 생략하기 쉬움. 결과적으로 화면에 존재하지 않는 버튼이나 항목에 대한 테스트가 섞임
• 완료 합의와의 괴리: "건수 ◯건 이상 · 채점 스코어 ◯점 이상 · 대상 외 시트에 부작용 없음"을 완료 조건으로 설정했음에도, 건수만 채우고 "완료"라고 적어오는 경우
• 테스트 입도(Granularity)의 착오: "사용자 조작 흐름 단위의 큰 테스트는 테스트 케이스 측이 아니라 테스트 관점 측에 작성한다"라는 규칙을 매번 전달하지 않으면 테스트 케이스 측에 작성해 버리는 경우

모두 세션 내에서 한 번 전달하면 그 대화 중에는 제대로 적용해 줍니다. 하지만 다음 세션에서 Claude는 그 대화를 읽지 않습니다. 기억은 리셋되고, 다시 똑같은 실수를 저지르고 마는 것입니다.

예를 들어 "테스트 케이스 자동 채점은 본래 대상으로 해야 할 시트만 본다"라는 규칙은, 지적할 때마다 Claude는 "다음에는 주의하겠습니다"라고 적어주었습니다. 하지만 다음 날 세션에서는 그 대화가 존재하지 않았던 것이 되어, 다시 대상 외 시트까지 채점하는 상태로 되돌아가 있었습니다. 같은 수정을 3번 반복한 후에야 비로소 "대화 속의 약속"만으로는 유지되지 않는다는 것을 깨달았습니다.

이는 AI 고유의 문제가 아니라, 회고를 구두 약속만으로 끝내는 인간에게도 구조적으로 발생하는 일이라고 생각합니다. 다른 점은 Claude에게는 "세션을 넘기면 기억이 사라진다"라는 극단적인 사양이 있어, 구조적인 약점이 극단적인 형태로 노출될 뿐입니다.

"완료라고 적었다"는 것만이 완료의 증거가 된 날

무슨 일이 일어났었는지 상세히 적겠습니다.

밤사이 Claude는 자율적으로 태스크를 진행하고 있었습니다.

다음 날 아침, MEMORY.md에는 다음과 같이 적혀 있었습니다.

✅ 최종 종료 완료 · TC 약 60건 · eval 94/100

실제 Excel 파일을 열어보니 건수는 보고된 것보다 적었고, 내용을 살펴보아도 94점이라고 당당히 말할 수 있는 품질로는 도저히 보이지 않았습니다. 완료 보고와 실태가 명백히 어긋나 있었던 것입니다.

원인이 Claude의 할루시네이션 (Hallucination)이었는지, 아니면 제가 Claude에게 일을 맡기는 방식 자체가 틀렸던 것인지, 그 구분은 지금까지도 명확히 하지 못했습니다.

하지만 원인 특정에 집착하기보다, 동일한 현상을 구조적으로 방지하는 것이 더 중요했습니다.

원인이 어느 쪽이었든, 재발을 막는 방법은 같았기 때문입니다.

Claude가 "끝났습니다"라고 말했을 때,

그 작업이 제가 의도한 품질을 충족하고 있는가?

애초에 Claude가 할루시네이션 (Hallucination)을 일으키고 있지는 않은가?

그것을 판별할 구조가 제 팀에는 없었습니다. 그것이 진짜 원인이었다고 생각합니다.

이 구조를 두 가지 만들었습니다. 아래에 그 이야기를 적습니다.

회고를 구조화하기 ── 교훈을 대화 외부에 두기

인간 팀에는 회고 미팅이 있습니다.

스프린트(Sprint)가 끝날 때 "무엇이 좋았고, 무엇이 나빴는지"를 공유하고 다음 사이클로 인계합니다.

저는 이것을 Claude에서도 작동하는 형태로 번역하기로 했습니다.

구체적으로는 두 가지입니다.

• 테스트 케이스 자동 채점 과정에서 발견된 AI의 실수 패턴을 대화 외부에 있는 파일에 영구화하기: 피드백 기록 파일에 과거에 어떤 위반 행동이 있었는지, 어떤 수정 방침으로 해결했는지를 1건당 1개의 파일로 남깁니다 (실제로 "채점 대상 시트만 보기", "테스트 작성 전 대상 화면의 UI 가져오기", "테스트 관점의 표기 불일치 정규화하기" 등 10건 이상의 사례가 축적되어 있습니다). 다음 세션의 Claude는 테스트 케이스를 생성하기 전에 반드시 이것들을 읽도록 규칙을 정했습니다.
• 회고를 Skill로 만들기: 이 Skill을 통해 Claude가 호출할 수 있는 재사용 가능한 절차서를 작성합니다. 11장 구성의 회고 템플릿을 통해 세션 완료 후 "좋았던 점 / 나빴던 점 / 다음을 위한 개선 사항"을 작성하게 합니다. 지금까지 수동으로 작성하던 의사록 형태에서, 구조화된 재사용 가능한 문서가 자동으로 생성되는 방식으로 바뀌었습니다.

이 두 가지로 Claude의 지시 처리 방식이 어떻게 변하는지 그림으로 나타냅니다.

어떤 테스트 케이스 생성 세션에서는 이러한 회고 구조 덕분에 세 가지 결함을 한 번에 발견할 수 있었습니다.

Excel의 모든 시트가 채점 대상이 되어 점수가 낮아지는 버그, agent 설정의 필수 필드가 문서화되어 있지만 운용되지 않는 문제, 스크립트의 실행 경로가 어긋나 있던 문제입니다.

회고 미팅이 없었다면 모두 다음 세션에서 재발했을 것입니다.

적기만 한 규칙은 움직이지 않는다 ── 시운전을 Skill화하기

회고를 구조화한 뒤, 저는 또 다른 문제를 깨달았습니다.

규칙을 적기만 하고 운용되지 않는, 사장된 규칙 문제입니다.

"다음부터 ○○하자"라고 CLAUDE.md에 적는다. 기분은 좋습니다.

하지만 규칙을 적은 본인이 해당 턴(Turn) 내에서 적용하지 않으면, 그 규칙은 사장됩니다.

다음 세션에서도 적용되지 않은 채 선반 깊숙한 곳에서 계속 잠들어 버리는 것입니다.

실례를 들어보겠습니다.

어느 세션에서 저는 Claude에게 코드베이스 내의 "사전 코드 (Dead Code)"를 정리하게 했습니다.

생성 스크립트에서 아무도 호출하지 않는 함수를 삭제하는 작업입니다. 물리적으로 삭제한 양은 950행. "정의되어 있을 뿐 실행되지 않는 코드"가 코드베이스에 실제로 존재하고 있었습니다.

규칙도 마찬가지입니다. 적기만 하고 작동하지 않는 규칙은 코드상의 사장된 코드와 마찬가지로, 존재하지 않는 것과 다름없습니다.

그래서 "만든 즉시 한 번 작동시켜 본다"라는 시운전의 발상을 Skill화했습니다.

소프트웨어 업계에는 "자사가 개발한 것을 출시 전부터 직원이 일상적으로 사용하며 결함이나 개선점을 찾아낸다"라는 문화가 있습니다. 이것을 규칙이나 Skill을 만든 직후의 동일한 세션 내에서 반드시 한 번은 작동시켜 본다는 형태로 번역하여 도입한 것입니다.

사실, 이 시운전의 감각은 원래 Claude에게도 갖춰져 있었습니다.

다만, 암묵적인 상태로 두면 필요한 타이밍에 기동되지 않을 때가 있습니다. Skill (스킬)로서 명시적으로 정의함으로써, Claude 스스로가 "지금은 시운전을 해야 할 상황이다"라고 판단하여 임의의 타이밍에 스스로 호출할 수 있게 됩니다. 동료로서 나란히 달린다면, 매번 지시하지 않아도 스스로 움직일 수 있는 형태로 만들어 두는 편이 서로 기분 좋게 일할 수 있는 방법일 것입니다.

구체적으로는, 규칙을 추가한 동일한 세션 내에서 그 규칙을 반드시 1회 적용한다. 새로운 Skill을 만들었다면 그 세션에서 사용해 본다. "다음" 혹은 "다음 세션"으로 미루는 것은 금지한다. 이 정도의 일을 Skill로 만든 것입니다.

시운전이 찾아낸 구체적인 사례 ── AI의 실수 패턴이 절반으로 줄어든 이야기

이 시운전을 Skill로 도입한 이후, 눈에 보이는 성과가 나타나기 시작했습니다. 대표적인 3가지를 나열하면 다음과 같습니다.

시운전 대상	시운전에서 일어난 일
인수인계 문서 생성 Skill	만든 당일의 세션이 첫 사용자가 되어, 결함을 즉시 수정할 수 있었다
새로운 품질 체크 그룹	100건 이상의 테스트 케이스에 적용했더니 70건 가까운 문제가 단번에 가시화되었고, 누적된 AI의 실수 패턴을 약 절반까지 개선할 수 있었다
표기 불일치 정규화 스크립트	단체 테스트(Unit Test)에서는 보이지 않았던 19건의 표기 불일치를 수백 행에 달하는 관점 시트에서 발견

각각 조금씩 보충하겠습니다.

세션 간 인수인계 문서를 자동 생성하는 새로운 Skill을 만든 날, Claude는 해당 세션의 인수인계를 방금 만든 그 Skill로 작성했습니다. Skill 작성자가 그 Skill의 첫 사용자가 되는 것입니다. '작성 즉시 실행'을 여기서 구현할 수 있게 되었으며, 만들기만 하고 운용하지 못하던 상태를 해소했습니다.

테스트 케이스 파이프라인에 새로운 품질 체크를 추가한 날에는, 시운전으로서 실제 데이터(100건 이상의 테스트 케이스)에 적용해 보았습니다. 체크 로직을 작성한 시점에는 "효과가 있을 것이다"라고 생각했던 기능이, 실제 데이터에서 처음으로 "실제로 효과가 있다"는 것을 수치로 증명한 순간입니다. 누적된 AI의 실수 패턴은 거의 절반까지 줄어들었습니다.

표기 불일치 정규화 스크립트를 만든 날에도, 본番(실제) 데이터에 흘려보냈을 뿐인데 수백 행에 달하는 관점 시트에서 19건의 표기 불일치가 새롭게 발견되었습니다. 단체 테스트에서는 절대 보이지 않았을 문제입니다.

"작성만" 해서는 아무 일도 일어나지 않았습니다. 시운전을 해서 비로소 기능이 기능으로서 작동하기 시작한 것입니다.

마치며 ── 인간의 규율을 Claude에게도

지금까지의 이야기를 한 장으로 요약하면 다음과 같습니다.

인간의 습관	Claude로의 번역
회고 모임에서 교훈을 공유한다	오탐지 판정이나 반성을 대화 외의 파일에 영구화한다
내가 만든 것을 내가 직접 사용한다	규칙이나 Skill을 추가한 해당 세션 내에서 반드시 한 번 실행해 본다

회고 모임은 인간이라면 스프린트(Sprint) 종료 시점에 교훈을 공유하는 자리를 말합니다.

시운전은 소프트웨어 업계의 "자사가 만든 것을 먼저 자신들이 사용해 버그나 개선점을 찾아낸다"라는 문화를 빌려온 것으로, 여기서는 새로 만든 규칙이나 Skill을 그날의 태스크에서 즉시 실행해 보는 것을 의미합니다.

Claude를 맞이한 순간, 제가 해야 했던 일은 새로운 운용 규칙을 발명하는 것이 아니라, 인간이 수십 년간 사용해 온 당연한 습관을 Claude에서도 작동하는 형태로 적용하는 것이었다고 생각합니다.

결과적으로, AI의 실수 패턴이나 AI가 만들어내는 잠재적인 과제를 방지·검지·개선할 수 있게 되었습니다.

앞으로 QA로서의 저는 "사람과 사람이 품질을 보증하는" 업무에서, "사람과 AI가 품질을 보증하는" 업무로 더욱 적응해 나가야 합니다.

협업 상대가 AI로 바뀌더라도, 품질을 지키는 방법은 인간이 가르쳐주고 AI에서도 작동하는 형태로 성형하면 된다 ── 이것이 이 시행착오의 현시점에서의 결론입니다.

다음에는 Claude에게 "무엇을 학습시킬 것인가" ── 지식 정리를 보다 포괄적으로 수행하는 이야기에 대해 또 다른 글로 써보도록 하겠습니다.