AI 를 활용해 테스트 코드 추가하기 - 1

개요

최근 지인의 도움으로 Antigravity를 사용할 수 있게 됐다. 코딩에 본격적으로 활용할 수 있는 AI를 다뤄본 것은 이번이 처음이었기에, 어떤 작업에 활용해 보면 좋을까 고민하던 중 사이드 프로젝트에 테스트 코드를 추가해 보자는 목표를 세우고 작업을 시작했다.

 

브라우저를 열어 ChatGPT나 Gemini에 접속하고, 프롬프트를 입력한 뒤 결과를 복사·붙여넣기하던 기존의 작업 방식과는 비교하기 어려울 정도의 효율성을 체감했다. 이것저것 시켜보다가 AI Quota를 모두 소진해버리기도 했지만, 그 과정 자체에서도 많은 배움이 있었다.

 

이번 글에서는 AI를 활용해 테스트 코드를 추가하며 어떤 사고 과정을 거쳤는지, 그리고 AI에게 작업을 맡기면서 어떤 점을 고민하게 되었는지를 정리해보고자 한다.

---

Antigravity CLI보다 IDE가 편했던 이유

개요에서 언급했듯 이번 작업에는 Google의 Antigravity를 사용했다.

 

처음에는 Gemini CLI의 업그레이드 버전인 ang를 활용해 터미널 기반으로 작업하면 더 개발자답고 편할 것이라 생각했다. 하지만 실제로 사용해 보니 Antigravity IDE가 훨씬 편했다.

 

이 경험은 예전부터 종종 보던 논쟁을 떠올리게 했다. 'Vim을 잘 쓰는 것이 좋은가', 'IDE를 잘 활용하는 것이 좋은가'와 같은 이야기다. 개인적으로는 어떤 도구를 사용하는지보다 목표와 상황에 맞는 도구를 선택하는 것이 더 중요하다고 생각한다.

 

평소 VS Code를 사용해왔던 덕분인지 Antigravity IDE도 크게 이질감은 없었다. 무엇보다 AI가 어떤 과정을 거쳐 작업을 수행하는지, 어떤 파일을 수정하는지를 GUI를 통해 실시간으로 확인할 수 있다는 점이 CLI보다 훨씬 편리하게 느껴졌다.

---

테스트 코드의 필요성

Antigravity를 통해 코드 변경을 지시하고 그 과정을 지켜보다 보니 흥미로운 점을 발견했다. AI가 종종 내가 요청한 범위를 넘어선 수정까지 수행하거나, 사용자가 즉시 확인하기 어려운 부분까지 함께 변경하는 경우가 있었다.

 

기존에 정상적으로 동작하던 기능은 변경 이후에도 동일하게 동작해야 한다. 결국 시스템의 기능적 일관성을 유지하는 것이 중요한데, AI를 활용할수록 이러한 일관성이 생각보다 쉽게 흔들릴 수 있다는 점을 체감했다.

 

그러다 보니 자연스럽게 "이 문제를 해결하려면 결국 테스트 코드가 필요하겠구나."라는 결론에 도달했다.

---

테스트 코드가 항상 어려웠던 이유

소프트웨어 설계나 코드 품질을 다루는 책에서는 테스트 코드의 중요성을 끊임없이 강조한다. 하지만 실제 프로젝트에서는 상황이 조금 다르다.

 

전문 QA 조직이 별도로 존재하는 경우도 있고, 기획 단계에서 정의된 요구사항을 모두 만족하면 테스트가 완료된 것으로 판단하는 프로젝트도 있다. 그래서 내가 경험했던 프로젝트들 역시 테스트 코드가 있는 경우도 있었고, 없는 경우도 있었다.

 

물론 테스트 코드를 도입해야 한다는 이야기나, 어떻게 접근해야 하는지에 대한 자료는 꾸준히 접해왔다. 하지만 막상 직접 적용하려고 하면 테스트 코드 역시 유지보수 대상이라는 점이 부담으로 다가왔다. 테스트를 잘 작성하는 것만큼이나 지속적으로 관리하는 비용도 함께 고려해야 했기 때문이다.

 

반대로 AI는 이미 구현된 코드의 맥락을 매우 빠르게 파악할 수 있다. 그렇다면 테스트 프로세스를 구축하는 과정 역시 AI의 도움을 받을 수 있지 않을까 하는 생각이 들었다.

---

테스트 코드보다 먼저 시스템을 이해시키기

테스트를 추가하는 기본적인 접근 방법은 테스트 피라미드(Test Pyramid)를 기반으로 잡았다. 단위 테스트(Unit Test), 통합 테스트(Integration Test), 종단 간 테스트(E2E Test)를 순차적으로 구축하는 방식이다.

 

 

하지만 테스트 코드를 생성하기에 앞서 먼저 고려한 부분이 있었다. 바로 현재 시스템에 어떤 기능이 구현되어 있는지를 먼저 목록화하는 작업이었다.

 

작성된 코드를 기준으로 바로 테스트를 생성하도록 하면 AI는 해당 코드가 실제 사용되는 코드인지, 이미 사용되지 않는 Dead Code인지 구분하지 못한 채 테스트를 작성할 가능성이 높다고 판단했다.

 

또한 하나의 코드에서 시작해 모든 호출 그래프(Call Graph)를 따라가며 관련 코드를 분석하려는 경향도 있었는데, 이 과정에서 필요 이상의 범위까지 탐색하면서 예상보다 많은 토큰을 소비할 수도 있다고 생각했다.

 

다행히 사이드 프로젝트는 UseCase 계층을 중심으로 실제 제공되는 기능을 구분하도록 설계되어 있었다.

 

덕분에 AI에게는 구현된 UseCase를 기준으로 현재 시스템이 제공하는 기능을 먼저 목록화하는 문서를 작성하라고 지시했다.

 

이렇게 하면 AI가 먼저 시스템의 기능 범위를 이해한 뒤, 그 범위 안에서만 테스트를 생성하도록 유도할 수 있을 것이라고 생각했다.

결과적으로 AI가 불필요한 코드를 분석하거나 테스트를 생성하는 일을 줄일 수 있었고, 토큰 사용량 역시 어느 정도 제어할 수 있었다.

 

이 과정을 통해 아래와 같은 기능 목록 문서가 생성됐다.

 

---

AI에게 테스트 코드를 맡겨보기

기능 목록 문서가 준비된 이후에는 테스트 코드 작성을 AI에게 위임했다. 

 

프롬프트에는 테스트를 추가할 UseCase 의 경로와 함께, 해당 기능과 연관된 Domain을 기준으로 테스트 코드를 작성해 달라는 내용을 전달했다.

 

하지만 AI와 대화를 이어가며 부족한 부분을 하나씩 보완하다 보니, 자연스럽게 E2E 테스트까지 포함하는 방향으로 범위가 확장됐다.

 

최종적으로는 아래와 같은 테스트 구조가 생성됐다.

╰─$ tree-L2
.
├── cov-result.md
├── e2e
│   ├── test_pod_applications_e2e.py
│   ├── test_pod_cancel_e2e.py
│   ├── test_pod_lifecycle_e2e.py
│   ├── test_pod_likes_e2e.py
│   ├── test_pod_other_artists_e2e.py
│   └── test_pod_reviews_e2e.py
├── integration
│   ├── conftest.py
│   ├── test_pod_repositories_db.py
│   └── test_pod_usecases_db.py
├── readme.md
└── unit
    ├── test_pod_entities.py
    ├── test_pod_notifications.py
    ├── test_pod_services.py
    └── test_pod_usecases.py

생성된 테스트를 실행하기 위한 명령은 다음과 같이 구성됐다.

MYSQL_PASSWORD=testSECRET_KEY=testPYTHONPATH=services:services/api ./venv/bin/python-m pytest-v test/pod

터미널에서 테스트를 실행해 정상적으로 수행되는 것을 확인할 수 있었다.

결과 이미지에도 드러낫듯 각각의 테스트 케이스의 테스트 번호를 부여하고 한글 네이밍을 통해서 터미널의 테스트 결과를 한글로 출력하게 만드는 것도 시도할 수 있었다.

---

마치며

이번 작업을 통해 Antigravity를 활용해 테스트 코드를 생성하고, 변경 사항이 발생할 때마다 테스트를 수행할 수 있는 환경을 갖추게 됐다. 덕분에 AI가 코드를 수정하더라도 기존 기능이 정상적으로 동작하는지 빠르게 확인할 수 있게 되었고, 프로젝트의 기능적 일관성을 유지하는 데에도 어느 정도 도움이 됐다.

 

반면 아쉬운 점도 있었다. 테스트 코드를 생성하는 과정에서는 많은 코드를 함께 분석해야 하기 때문에 Antigravity의 할당량을 예상보다 빠르게 소진하게 됐다. 결국 작업 도중 할당량이 모두 소진되면 다음 할당량이 부여될 때까지 기다려야 했고, 작업의 흐름이 끊기는 경험도 여러 번 하게 되었다.

 

돌이켜보면 한 번에 너무 많은 작업을 AI에게 맡기려고 했던 것도 원인 중 하나였던 것 같다. 앞으로는 작업을 더 작은 단위로 나누고, AI가 어느 지점까지 작업을 완료했는지 기록할 수 있는 구조화된 작업 흐름을 만들어볼 생각이다. 이렇게 하면 중간에 작업이 중단되더라도 이어서 진행하기 쉬울 것이고, 불필요한 토큰 사용도 줄일 수 있을 것으로 기대한다.

 

이번 경험을 통해 AI는 단순히 코드를 대신 작성해 주는 도구가 아니라, 어떤 순서로 작업을 진행할지 설계하는 과정 역시 중요하다는 점을 다시 한번 느낄 수 있었다. 앞으로는 토큰 사용량을 줄이면서도 작업 효율을 높일 수 있는 방법에 대해서도 계속 고민해 볼 생각이다.