테스트와 CI가 진짜 생산성인 이유 — 빠르게 쓰는 것보다 빠르게 안심하는 것

“빠른 팀은 코드를 빨리 쓰는 팀이 아니라,
변경 후에도 괜찮다는 확신을 빨리 얻는 팀이다.”

AI 시대 얘기를 하면 자꾸 코드 생성 속도부터 말한다.
Codex든 Claude든, “몇 배 빨라졌다”는 숫자가 먼저 나온다.

하지만 실무에서 더 비싼 건 생성이 아니라 재확인이다.

• 이 변경이 checkout을 깨지 않았는지
• null 경계를 놓치지 않았는지
• 리뷰어가 같은 질문을 세 번째 묻지 않아도 되는지

그 확인 시간이 길면 배포는 늦고, 팀은 지친다.
반대로 확인이 CI에 고정돼 있으면, AI가 코드를 더 많이 써도 팀 속도는 오히려 올라간다.

TL;DR

• 생산성의 본질은 작성 속도가 아니라 검증 속도다.
• AI는 생성만 빠르게 한다. 팀 속도는 lint/test/리뷰 루프가 결정한다.
• 완벽한 테스트보다 항상 돌아가는 최소 안전망 5개가 먼저다.
• 에이전트에게 테스트 초안을 맡겨도, 보장 조건은 사람이 먼저 써야 한다.

왜 지금 이 얘기인가

최근 커뮤니티에서 AI 코딩 도구 비교 글이 많다.
공통 결론은 비슷하다.

• 모델 성능 차이보다 하네스(지시 파일, hooks, 검증 루프) 차이가 크다.
• “완료됐다”고 말하는 에이전트를 잡아내는 건 결국 lint/test 파이프라인이다.
• 속도를 올리려면 더 많이 생성하는 게 아니라, 드리프트를 빨리 되돌리는 장치가 필요하다.

즉, AI 도입 이후 생산성 논쟁의 중심은 모델 선택이 아니라 CI 설계로 옮겨갔다.

테스트/CI가 생산성인 이유

1) 확인 비용을 고정한다

사람이 매번 손으로 확인하면 품질도 속도도 들쭉날쭉하다.
“이번 PR은 급해서 스킵”이 반복되면, 팀은 느려지는 게 아니라 불안해진다.

CI는 확인 과정을 팀의 공용 자산으로 만든다.
누가 올려도 같은 기준, 같은 순서, 같은 실패 메시지.

2) 리뷰를 의미로 이동시킨다

기계가 잡을 수 있는 문제(타입, 린트, 포맷, 기본 테스트)는 기계에 넘긴다.
리뷰어는 도메인 의사결정·경계 조건·UX 회귀에 집중할 수 있다.

AI 리뷰를 쓰더라도 마찬가지다.
기계끼리 겹치는 구간을 CI가 먼저 처리해야, 사람·에이전트 리뷰가 낭비되지 않는다.

3) 롤백 결정을 빠르게 한다

장애 시 “일단 revert”만 외치는 팀과, 어떤 경로가 깨졌는지 증거로 말하는 팀은 다르다.

CI 로그와 테스트 이름이 있으면 revert 범위가 좁아지고,
“이번엔 hotfix, 다음 스프린트에 구조 개선” 같은 판단도 빨라진다.

FE 팀 최소 안전망 5개

완벽한 커버리지는 목표가 아니다. PR마다 항상 돌아가는 최소선이 목표다.

원칙: 5개 중 하나라도 CI에서 빨간불이면 merge하지 않는다.
예외가 필요하면 예외 사유·생략 범위·후속 티켓 3줄을 PR에 남긴다.

AI와 결합할 때의 요령

에이전트에게 테스트 코드 초안을 맡겨도 된다.
단, “무엇을 보장해야 하는지”는 사람이 먼저 써야 한다.

나쁜 예:

“이 컴포넌트 테스트 좀 짜줘.”

좋은 예:

“formatPrice(null)은 throw 대신 '0'을 반환해야 한다.
통화 코드가 없으면 KRW 기본값. snapshot 테스트는 쓰지 말 것.”

이 한 줄이 없으면 테스트는 많아도 신뢰는 낮다.
에이전트는 명세가 있을 때 빠르고, 명세가 없을 때 그럴듯하게 틀린다.

CI에 넣을 AI 관련 게이트 (선택)

• generated diff에 console.log / any / @ts-ignore 급증 시 warn
• 새 API route에 auth guard 누락 시 fail (팀 규칙에 맞게)
• E2E smoke 실패 시 merge block (flaky면 quarantine + 이슈 필수)

측정 함정 하나만 짚고 넘어가기

“AI 도입 후 PR이 늘었다”만 보고 성공이라고 말하기 쉽다.
PR 수·커밋 수·생성 LOC는 Goodhart의 법칙에 잘 걸린다.

숫자가 오르면 행동이 왜곡되고, 실제 가치와 어긋난다.

대신 팀이 볼 것:

• main까지 merge까지 걸린 시간 (cycle time)
• CI 실패 후 재시도 횟수
• 같은 유형의 리뷰 코멘트 반복률
• hotfix/revert 빈도

AI 생산성을 잘못 재는 12가지 (읽을거리)에서 같은 축을 정리해 두었다.
오늘 글의 한 줄과 맞닿는다: 생성량이 아니라 검증 루프를 재라.

바로 적용 체크리스트

• PR template에 “보장 조건 1줄” 칸 추가
• main 브랜치 CI 5종이 10분 안에 끝나는지 확인 (느리면 쪼개기)
• flaky test 목록을 문서화하고 quarantine 정책 정하기
• AI 생성 코드 PR에는 “검증 evidence” 섹션 필수 (테스트명·스크린샷·로그 중 하나)

마치며

테스트와 CI는 속도를 늦추는 절차가 아니다.
팀의 불안을 줄여서 전체 속도를 올리는 장치다.

AI가 코드를 더 많이 쓸수록, 이 장치 없이는 팀은 더 느려진다.
생성은 개인의 문제고, 검증은 팀의 문제다.

한 줄 결: 생산성의 본질은 작성 속도가 아니라 검증 속도다. 테스트와 CI는 그 검증을 자동화한다.

읽을 거리 (시리즈)

• 「하네스 다 했어요」는 아직 시작
• AI 보조 코딩 생산성 — 잘못 재는 12가지 (읽을거리)
• AI 스킬은 코드다 — 쓰면서 고쳐야 산다
• 리뷰 스레드 운영 체크리스트