TDD 스킬, 코딩 에이전트 검증의 기본 단위
AI 코딩의 품질 문제는 더 강한 모델만으로 풀리지 않는다. 작은 절차를 skill로 고정하고 독립 리뷰 에이전트로 테스트 설계를 검토하는 방식이 실무적 해법에 가깝다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
에이전트가 테스트를 못 쓰는 이유
SaturnCI의 My Agent Skill for Test-Driven Development는 AI 코딩 에이전트가 테스트를 쓰는 방식에 대한 짧지만 중요한 글이다. 글쓴이는 에이전트가 쓰는 테스트가 모호하고, 장황하고, 구현 세부에 묶이고, 때로는 의미 없는 통과 의식이 되기 쉽다고 지적한다. 흥미로운 점은 모델만 탓하지 않는다는 것이다. 에이전트가 학습한 인간의 테스트 예제 자체가 좋지 않은 경우가 많기 때문에, 무작정 테스트를 쓰라고 하면 나쁜 습관도 같이 재생산된다.
해법으로 제시된 것은 거대한 프롬프트가 아니라 skill이다. 글은 Kent Beck의 Canon TDD를 중요한 기준으로 삼고, specify, encode, fulfill이라는 루프를 설명한다. 먼저 범위 안의 명세를 쓰고, 그 명세를 실행 가능한 테스트로 인코딩한 뒤, 그 테스트를 통과시키는 최소 구현을 한다는 흐름이다. 이는 전통적인 red, green, refactor를 AI 에이전트가 따르기 쉬운 언어로 바꾼 셈이다.
Constraint Decay, 코딩 에이전트의 구조 망각 문제, Weave 채용공고가 보여준 AI 개발 측정 시장, 지루한 언어가 AI 코딩에 강한 이유는 모두 AI 코딩의 병목이 생성이 아니라 검증과 구조 유지에 있음을 보여줬다. 이번 글은 그 병목을 작업 절차로 낮추는 방법을 보여준다.
skill은 프롬프트가 아니라 운영 규칙이다
많은 팀이 AI 코딩 도입을 프롬프트 공유로 시작한다. 그러나 실무에서는 한 번 잘 먹힌 프롬프트가 다음 작업에서 같은 품질을 보장하지 않는다. skill은 특정 작업에서 반복해야 할 절차, 금지할 행동, 리뷰 기준을 파일로 고정한다는 점에서 다르다. 에이전트에게 테스트를 쓰라고 말하는 것이 아니라, 테스트를 쓰기 전 어떤 명세 목록을 만들고, 어떤 순서로 구현하며, 언제 refactor를 분리할지 지시한다.
SaturnCI 글에서 특히 중요한 부분은 별도의 Test Design Review skill이다. 에이전트가 작성한 테스트를 같은 맥락의 에이전트가 그대로 칭찬하게 두지 않고, 독립 리뷰를 통해 테스트가 수단이 아니라 결과를 검증하는지 살핀다. 최근 TDAD 논문은 테스트 주도 프롬프트만으로는 회귀가 늘 수 있고, 어떤 테스트를 확인해야 하는지 알려주는 문맥 그래프가 더 중요할 수 있다고 보고했다. SWE-Skills-Bench 역시 skill이 항상 큰 개선을 만들지는 않으며 실제 저장소와 요구사항에서 검증해야 한다고 지적한다.
| 방식 | 장점 | 위험 |
|---|---|---|
| 단순 테스트 생성 | 빠르게 커버리지 숫자를 올림 | 의미 없는 테스트가 늘 수 있음 |
| TDD skill | 절차를 반복 가능하게 만듦 | 잘못된 규칙도 고착될 수 있음 |
| 독립 테스트 리뷰 | 테스트 설계 결함을 잡음 | 비용과 시간이 추가됨 |
| 테스트 영향 분석 | 필요한 검증 범위를 좁힘 | 코드 그래프 품질에 의존함 |
한국 개발팀이 바로 적용할 수 있는 기준
첫째, 테스트 품질 기준을 자연어로만 두지 말고 repo 안에 skill 또는 작업 규칙으로 둬야 한다. 둘째, AI가 쓴 테스트는 커버리지보다 실패 이유가 분명한지 봐야 한다. 셋째, behavior change와 refactor를 같은 커밋에 섞지 않는 규칙은 AI 코딩 시대에 더 중요해진다. 에이전트는 한 번에 많이 바꾸는 경향이 있으므로 리뷰어가 행동 변화와 구조 정리를 분리해서 볼 수 있어야 한다.
넷째, 테스트 리뷰 에이전트는 구현 에이전트와 다른 역할을 가져야 한다. 같은 목표를 가진 에이전트가 자기 결과를 검토하면 낙관 편향이 생긴다. 코드 리뷰에서 작성자와 리뷰어를 분리하는 오래된 원칙이 AI에도 그대로 적용된다.
경쟁 구도는 IDE보다 워크플로 파일로 이동한다
Cursor, Claude Code, Codex, Copilot 같은 도구 경쟁은 계속되지만, 팀이 장기적으로 축적할 자산은 도구 자체보다 내부 skill과 평가 데이터다. 특정 모델이 바뀌어도 테스트 작성 절차, 리뷰 체크리스트, 위험 작업 기준은 남는다. 이것이 잘 쌓인 팀은 새 모델을 빠르게 바꿔 타도 품질을 유지할 수 있다.
따라서 AI 코딩 투자 우선순위는 모델 구독, 에디터 확장, 테스트 생성 순서가 아니다. 먼저 중요한 개발 흐름을 skill로 문서화하고, 그 skill이 실제로 결함을 줄이는지 측정해야 한다. 결국 AI 코딩의 경쟁력은 더 많은 코드를 쓰는 능력이 아니라 더 적은 불확실성으로 코드를 배포하는 능력이다.
자주 묻는 질문
Q1: TDD skill은 그냥 프롬프트와 다른가요?
A: 다르다. 프롬프트는 한 번의 요청에 가깝지만, skill은 반복 가능한 작업 절차와 리뷰 기준을 저장소나 에이전트 환경에 고정한다.
Q2: AI가 테스트를 먼저 쓰면 품질이 자동으로 좋아지나요?
A: 아니다. 테스트가 구현 세부를 검증하거나 의미 없는 assertion이면 오히려 유지보수 비용이 늘어난다.
Q3: specify, encode, fulfill은 무엇인가요?
A: 명세를 정하고, 명세를 테스트로 바꾸고, 그 테스트를 통과하는 최소 코드를 작성하는 루프다.
Q4: 독립 테스트 리뷰 에이전트가 필요한 이유는 무엇인가요?
A: 구현 에이전트가 자기 테스트를 낙관적으로 평가할 수 있기 때문에 다른 역할의 리뷰가 필요하다.
Q5: 팀에서 가장 먼저 만들 skill은 무엇인가요?
A: 버그 수정 TDD skill이 좋다. 재현 테스트, 최소 수정, 회귀 검증, refactor 분리 규칙을 넣기 쉽기 때문이다.
관련 토픽 더 보기
📰 원본 출처
saturnci.com이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.