코딩 에이전트 시대, 우리는 이제 QA 엔지니어임

달라진 개발 프로세스

• 코딩 에이전트를 쓰면서 저자의 접근 방식이 완전히 바뀜. 예전엔 "프로토타입을 위한 최소 변경은?" 이었다면, 지금은 "이걸 어떻게 테스트하지?" 부터 시작
• 에이전트에게 아무리 상세한 스펙을 줘도, 검증 수단이 없으면 반쯤 작동하는 코드를 자신있게 내놓음. 다들 경험해봤을 것
• 결국 역할이 "프롬프트 엔지니어"가 아니라 테스팅 하네스를 만드는 QA 쪽으로 이동하고 있다는 주장

단일 서비스 vs 서비스 경계

• 하나의 서비스 안에서는 테스트가 비교적 쉬움 — 컨테이너 띄우고, 스토리지 준비하고, 데이터 넣으면 됨
• 서비스 경계를 넘는 변경에서 테스트 난이도가 급격히 올라감. 여러 시스템을 같이 돌리고, 상호작용시키고, 전체 상태를 검증해야 함. UI까지 끼면 더 복잡해짐

에이전트용 테스팅 하네스의 4가지 조건

• 재현성(Reproducibility): 에이전트는 테이블 날리고, DB 통째로 드롭하고, 엉망인 상태 위에 계속 빌드함. 환경을 처음부터 재생성할 수 있어야 함
• 진정성(Authenticity): Mockito 같은 프레임워크로 가짜 데이터 만들면 에이전트가 현실과 동떨어진 데이터를 기대하는 코드를 작성하는 전형적인 실패 패턴이 나옴. 실제 데이터와 최대한 가까워야 함
• 조합성(Composability): 하나의 서비스용 하네스로는 부족. 여러 팀이 같은 프레임워크 위에 구축하면 전체 E2E 검증이 가능해짐. 이건 조직 차원의 역량임
• 프로그래밍 가능(Programmatic): UI 클릭이나 콘솔 복붙이 필요하면 다시 사람이 루프에 들어옴. 환경 구동 → 시나리오 실행 → 검증 → 정리까지 전부 자동화되어야 함

관련 도구

• Testcontainers: 로컬에서 서비스 컨테이너 띄우기
• Localstack: AWS 에뮬레이션
• Miniflare: Cloudflare Workers 에뮬레이션
• 다만 대규모 프로젝트는 각자 고유해서, 자기 시스템에 맞는 프레임워크를 만드는 게 진짜 어려운 부분