7겹 품질 방어선을 설계하면 AI 코딩 생산성은 2배가 되고 버그는 그대로다.

AI 코딩 에이전트를 쓰면 코드를 많이 뽑아내는 대신 품질이 떨어질 것이라는 우려는 흔하다. 개발자 Iouri Khramtsov는 이 우려가 절반만 맞다고 본다. 리뷰 없이 PR을 그대로 머지해 프로덕션으로 흘려보내면 품질은 확실히 무너지지만, 품질 관리를 여러 겹으로 설계하면 버그 수를 유지하거나 오히려 줄이면서 산출량을 2배까지 끌어올릴 수 있다는 것이다. 그는 자신의 팀과 다른 조직에서 실제로 통했다고 밝힌 7개 층의 방어 구조를 정리했다.

첫 번째 층은 요구사항을 제대로 잡는 단계다. 스펙 기반 개발(spec-driven development)을 도입한 뒤 새로 작성한 코드에서 버그가 눈에 띄게 줄었다고 한다. 도입 전에는 신규 기능 하나를 만들 때 전체 공수의 3분의 1가량을 개발 이후의 '다듬기', 즉 버그를 찾아 고치는 작업에 쏟아붓는 일이 잦았다. 예상 못 한 상호작용과 경계 조건을 놓치거나, 그날 피로한 개발자가 충분히 고민하지 못하거나, 기획·디자인 단계에서 특정 시나리오를 검토하지 않은 탓이 컸다. 여기서 결정적인 역할을 한 것은 AI에게 요구사항이나 기술 설계를 검토시켜 빈틈과 경계 조건, 기존 코드와의 예상 밖 충돌을 찾아내게 하는 단계다. AI는 지치지 않고, 프롬프트를 제대로 주면 문제를 찾다가 포기하는 일도 적다. 다만 때로 과하게 나서는 경향이 있어, 제안된 수정이 실제로 존재하지 않는 문제를 만들어내지는 않았는지 사람이 확인해야 한다.

두 번째 층은 커버리지 95% 이상의 단위 테스트다. 코딩 에이전트 덕분에 테스트 주도 개발(TDD)은 하지 않을 이유가 없을 만큼 쉬워졌다. 다만 순서가 중요하다. 요구사항을 바탕으로 테스트 시나리오와 케이스를 먼저 설계하게 하고, 그 케이스에 맞춰 구현을 검증하고 문제를 고친 뒤, 남은 커버리지 공백을 요구사항을 염두에 두고 채우는 흐름이다. 에이전트가 테스트를 대신 써주는 만큼 거의 전면적인 커버리지를 목표로 삼거나, 빠진 단위 테스트를 나중에 채우는 일을 미룰 이유가 없다는 지적이다.

세 번째 층은 사람이 직접 기능을 만져보는 수동 테스트다. 개발자든 QA든 기획자든, 실제로 기능을 실행해 경계 조건을 훑고 기대대로 동작하는지 확인하는 과정은 여전히 대체할 수 없다. 문제는 이 단계의 생산성 향상 폭이 지금까지 크지 않다는 점이다. 테스트 시나리오를 세팅하는 데 품이 들면 시간이 더 걸린다. 저자가 산출량이 10배가 아니라 2~3배 늘어나는 데 그친 주된 이유로 꼽는 지점이 바로 여기다.

네 번째 층은 폭넓은 자동화 엔드투엔드(E2E) 테스트다. 최종 사용자 관점에서 기존 기능이 깨지지 않았는지 확인하는 테스트이므로 코드베이스에서 가장 중요한 축으로 꼽힌다. 이상적으로는 PR 단계, 테스트·스테이지 환경, 그리고 배포 후 프로덕션에서 모두 돌아야 한다. AI가 E2E 테스트 작성은 쉽게 만들어주지만, 실패 원인을 디버깅하려면 브라우저 도구나 로그에 접근할 수 있는 MCP 서버 같은 수단이 함께 있어야 한다. E2E 테스트는 중요한 것이 깨지지 않았다는 거친 확인일 뿐, 수동 테스트를 대신하지는 못한다.

다섯 번째 층은 AI가 수행하는 코드 품질 점검 패스다. 저자는 코딩 에이전트가 AGENTS.md나 CLAUDE.md에 적힌 복잡한 지시를 잘 따라가지 못한다고 본다. 대신 특정 문제를 찾아 고치는 별도 패스를 붙이면 성과가 좋다. 지나치게 복잡하거나 중복된 코드 찾기, 이름 규칙·파일 구조·포맷 규칙 준수, 로직 문제를 잡는 일반 코드 리뷰, AI 특유의 문체로 길게 늘어진 주석 정리 등이 대상이다. 기획이나 구현 스킬에 얹으면 구현 시간이 5~15분 늘어나는 정도로 사실상 공짜에 가깝고, 별도로 신경 쓸 것도 없다.

여섯 번째 층은 사람과 AI가 함께하는 PR 리뷰다. 사소한 수정이나 단순 버그 픽스라면 다른 방어층이 살아 있다는 전제 아래 사람 리뷰를 선택 사항으로 둘 수 있다는 쪽으로 저자는 기울고 있다. 반면 복잡한 변경은 여전히 사람이 AI 작성 코드를 봐야 한다. 큰 그림의 실수, 다른 기능과의 나쁜 상호작용, 과하게 복잡하거나 최적이 아닌 구현이 꾸준히 나오기 때문이다. AI 리뷰도 유용하다. 현재 팀에서는 PR마다 Claude와 Cursor 리뷰를 함께 돌리는데, 두 도구가 서로 다른 문제를 찾아낸다고 한다. 보안이나 효율, 다른 저장소와의 상호작용 같은 관점을 추가할 수도 있다. 다만 AI 리뷰는 사소한 것까지 지적하는 경향이 있어, 의미 없는 지적을 다른 에이전트가 걸러내는 패스를 두는 것이 좋다.

일곱 번째 층은 모니터링과 알림이다. 최소한 주기적으로 로그를 훑거나 Fullstory 같은 도구로 사용자 세션을 확인하고, 오류율·지연 시간 대시보드를 들여다보는 것이 좋다. Sentry나 GCP Error Reporting처럼 오류를 감지하고 중복을 제거해주는 서비스를 쓰면 더 낫다. 가장 좋은 형태는 Claude나 Cursor 같은 도구가 이런 오류를 자동으로 진단해 근본 원인을 파악하고 수정 PR까지 만들어내는 구조다.

결국 핵심은 방어층을 제대로 갖추면 산출량 증가가 안정성 저하로 이어지지 않는다는 것이다. 오히려 코딩 에이전트는 더 많고 깊은 검증을 더 싸게 붙일 수 있게 해준다. 테스트를 늘리고, 리뷰 패스를 추가하고, 프로덕션 문제를 더 빠르게 진단할 수 있다는 뜻이다. 품질에 충분히 집중한다면 버그를 통제하면서 배포 속도를 2배로 올리는 것, 어쩌면 버그를 줄이는 것도 가능하다는 것이 저자의 결론이다. 다만 이는 특정 팀에서 관찰된 경험이며, 수동 테스트 자동화처럼 아직 탐색하지 못한 영역도 남아 있다.