DevLog - Gpt는 유닛 테스트와 합이 좋다

요약

유닛테스트를 잘 짜두면, gpt가 개선해준 코드를 검토하는데 들이는 에너지를 줄일 수 있으며.
gpt를 잘 활용하면 설계비용 < 검토비용이 된다. 

 

---

UnitTest는 정말 필요한가?

최근 유닛테스트의 효용성에 대해서 고민하고 있었는데, 회사에서도 그렇고.. 정보원이 있는 타사 프로젝트 중 그 어느곳에서도 유닛테스트를 붙이는 곳이 없었다. 심지어 3년 간 일하면서 "역시 테스트는 정말 좋구나" 라고 체감할 만한 일이 별로없다보니, 좀 유난을 떠는 것 같다는 생각이 들었다. 굳이 몇 번 하지도 않는 리팩토링을 위해 이렇게까지 해야 하나? 싶은 부분이 있었다.

GPT-4o의 등장과 사이드 프로젝트

그러던 도중 Gpt-4o이 나오면서, 사이드 프로젝트에 좀 더 적극적으로 gpt를 사용하게 되었는데. 클래스가 들어간 파일들을 잔뜩 때려넣으면 즉시 테스트코드를 자동으로 뽑아낼 수 있다는 점이 좋았기 때문이다. ( 응답속도가 빨라서, 작업흐름이 끊기지 않는다는 점이 진짜 좋다!) 

Gpt에게 코드 개선을 부탁하지 않았던 이유

발견의 계기

하지만 이런 좋은 성능에도 불구하고. Gpt에게 테스트 코드 생성만을 맡길 뿐, 최근까지 코드 리뷰나 개선을 부탁하지 않았던 이유는. 빠르게 무언가가 튀어나오기는 하지만, 새로이 생성되는 함수가 개선을 부탁한 함수와 동일하게 동작함이 보장되지 않기 때문에 결국 그것을 검토하느라 내가 만들때와 비슷한 에너지가 소모되었기 때문이다. 
그러다 어느날 별 생각 없이 Gpt에게 코드 개선을 한번 시켜보고 그걸 검토하다가 문득 그런 생각이 들었다.

1. 어떤 함수 A와 A에 대한 테스트 AT가 있다고 가정하자
2. 내가 A라는 함수를 면밀하게 검토하여 A'로 새로 만들었을 때(리팩토링)
3. A'가 AT를 완전히 통과한다면, 적어도 테스트가 보장하는 범위내에서 A'는 A와 동일하다고 할 수 있다.  
4. 따라서 Gpt-4o가 생성한 A''가 테스트 AT를 통과한다면. A''는 A와 동일하다.

즉, AT(A) = AT(A') = AT(A'')라면 AT 범위 내에서 A = A' = A'' 라고 할 수 있다.

따라서 UnitTest가 필요하다

하지만 위는 AT⊆(A ∩ A′′) 만을 보장할 뿐, A ∩ A′′의 여집합이 반드시 ∅ 임을 보여주는 것은 아니기 때문에. AT를 최대한 확장할 필요가 있다. 다시 말해 AT가 충분한 크기라면 A = A''임을 내가 굳이 검증할 필요가 없다는 이야기이다.

당연한 이야기를 왜 굳이 써 놓았냐면, 유닛테스트는 반복적인 부분들이 제법 있어서 Gpt에 맡겨버렸을 때 검토에 대한 비용이 크지 않기 때문이다. 즉 테스트 환경을 잘 구성해 놓으면, 적은 비용으로 내 코드를 개선할 수 있다는 것이다!

물론 이러한 저비용은 일반적인 리팩토링에도 동일하게 적용되지만, 수제 리팩토링은 자주 할 일이 없는 반면 Gpt는 부담없이 자주 시도할 수 있으므로 이 때마다 유닛테스트의 효용을 느낄 수 있다. 

마치며

위와 같은 이유로 인하여 유닛테스트는 딱히 유난스러운게 아니며 Gpt를 적극적으로 사용할 수 있는 환경에서는 충분히 경제적인 선택임을 알 수 있다.