AI 시대에 테스트 코드를 잘 쓰는 기준이 달라진다.

한컴에서 Claude Code로 개발하며 세션이 끊길 때마다 같은 설명을 반복하게 되는 문제를 겪고, 테스트 코드를 "미래 세션의 AI가 읽는 실행 가능한 프롬프트"로 다시 정의한 글이다. 맥락 전달 수단으로 주석과 문서를 검토했지만 코드와의 동기화가 강제되지 않는다는 점에서 테스트 코드가 가장 적합하다고 본다. 다만 테스트가 보장하는 것의 한계도 분명히 짚는다.

핵심 포인트

AI는 세션이 종료되면 작업 맥락을 안정적으로 보존한다고 보기 어렵고, 다음 세션에서 맥락을 다시 전달하는 비용이 반복 발생한다.
주석은 코드가 바뀌어도 그대로 남는 경우가 많아 동기화가 강제되지 않지만, 테스트는 기대와 구현이 어긋나면 깨져 신호를 보낸다.
그렇다고 항상 최신 정책을 보장하는 것은 아니다. 정책이 바뀌었는데 테스트와 구현이 모두 이전 정책에 묶여 있으면 테스트는 그대로 통과한다.
테스트가 강제하는 것은 과거에 합의한 기댓값을 현재 코드가 유지하는지까지다.
새 세션의 AI에게 테스트 파일을 컨텍스트로 제공하는 것만으로 상당 부분 맥락이 복원된다.

상세 정리

반복되는 질문들: 이 엔드포인트가 어떤 케이스를 커버하는지, 특정 값이 없을 때 어떻게 처리하기로 했는지 같은 것들을 세션이 바뀔 때마다 다시 설명해야 했다.
이 문제는 멀티테넌트 백엔드 서비스를 개발하며 반복적으로 떠올랐고, 그 과정에서 테스트 코드의 역할을 다시 생각하게 됐다.
테스트가 담는 정보: 테스트 이름과 @DisplayName은 그 함수가 다뤄야 하는 상황을, 실패 케이스는 어떤 예외가 어떤 상황에서 발생하는지를 전달한다.
글이 제시하는 실천 항목으로 @DisplayName에 구현이 아니라 비즈니스 의도와 왜(Why)를 담는 방법, 인간이 명세를 확정하고 AI가 구현하는 협업 방식, 교차 검증과 역 추론 루프를 든다.
멀티테넌트 서비스의 격리 정책을 사례로 삼아 이름 짓기 방법을 구체적으로 다룬다.
한계도 함께 짚는다. 과잉 명세처럼 테스트 코드가 지닌 근본적인 문제를 실무 관점에서 살펴본다고 밝힌다.
기존에 알려진 테스트의 역할인 "이미 만든 기능이 망가지지 않게 지키는 안전장치"에 더해, AI 협업 시대의 맥락 동기화 장치라는 역할을 하나 더한 것이 이 글의 논지다.
"AI가 소스 코드를 직접 읽을 수 있는데 왜 굳이 테스트가 필요한가"라는 반문을 스스로 던지고 답하는 구성을 취한다.