확실히 개발 방식이 순식간에 바뀌었다는 것을 많이 느끼고 있다. 예전만큼 코드 개발을 많이 하고 있지 않지만, 코드 개발을 할 때 AI 코드 어시스턴트를 사용하고 있으며, 사용할 때마다 엄청난 능력에 많이 놀라고 있다. 코드를 작성할 때 가장 힘든 부분이 첫 부분인데, 그 첫 진입점을 손쉽게 해준다. 그리고 기존 코드를 설명해 주는 것도 탁월해 오랫동안 코드 개발에 손 놓고 있어도 AI 코드 어시스턴트로 빠르게 재진입할 수 있다. 확실히 과거 개발했을 때보다 생산성이 극도로 높아졌다는 것을 느끼고 있다.

사용하다 보니 DDD나 TDD와 같은 방법론이 여전히 유효할까라는 의문점이 들었다. DDD는 다른 글을 통해 나중에 이야기하고 여기서는 TDD에 관해서만 이야기를 해보려고 한다.

AI 코드 어시스턴트로 자연어를 이용해 요구사항에 맞는 케이스들을 모두 설명한 후 코드와 테스트 코드를 블랙박스 스타일로 작성해 달라고 하면 작성하고자 하는 코드를 그것에 맞게 잘 작성해 준다. 의도에 맞지 않는 부분이 있으면 그에 맞는 부분만 선택해 다시 요청하고, 그러면 AI 코드 어시스턴트는 해당 코드와 테스트 케이스도 갱신해 준다. 그러다 보니 TDD가 여전히 유효하냐는 의문이 들었다.

결론부터 말하면 TDD는 여전히 유효하다. 앞선 사례를 보면 AI 코드 어시스턴트와 프롬프트로 소통할 때 TDD에 맞게 소통했다. 습관적으로 소통하다 보니 TDD 방식에 따라 요청한 것을 잊어버려 앞서 말한 의문점이 생긴 것이다.

TDD는 앞선 글에서 설명했듯이 ‘테스트를 먼저 작성하고 코드를 작성한다’와 같은 형식적인 활동을 뜻하는 게 아니다. 요구사항을 테스트 케이스로 분해하고 이를 테스트로 관리해 안정성과 유지보수성을 높이는 설계를 해주는 활동이기 때문이다. 즉, 다음 가치를 확보하는 활동이다.

  1. 요구사항 명확화: 요구사항을 보고 테스트 케이스를 작성해 요구사항을 더 명확히 이해할 수 있다.
  2. 설계 품질 향상: 테스트 케이스는 블랙박스로 입력과 출력으로만 제공해 검증하도록 만들면 내부 로직 의존성이 줄어들도록 코드가 작성된다.
  3. 안정성 확보: 위와 같은 설계 품질 향상으로 인해 지속적인 유지보수가 있더라도 안정성을 확보할 수 있다.

위와 같은 가치 활동은 개발 프로세스 또는 개발 문화로서도 동작한다. 그러므로 AI 코드 어시스턴트가 TDD를 대체하긴 어렵다. 오히려 AI 코드 어시스턴트는 TDD와 상호 배타적인 관계가 아닌 상호 보완적인 관계이다. 앞서 프롬프트를 활용했을 때 프롬프트에서 TDD 관점에 따라 프롬프트를 작성했다. 그 후 AI 코드 어시스턴트는 그것에 맞게 코드를 작성했다. 이런 식으로 상호 보완적인 관계다.

AI 코드 어시스턴트는 실제 비즈니스가 일어나는 세상과 사람들이 소통하면서 만들어진 맥락과 관련된 데이터가 없다. 그러므로 그에 대한 한계가 있다. 상황에 맞는 데이터와 맥락이 최소한 프롬프트를 통해 제대로 주입되지 않으면, AI는 잘못된 도메인 모델을 생성하거나, 전체 아키텍처에 어울리지 않는 코드 구조를 만들 수 있다. 또한, 맥락을 알지 못하면 알 수 없는 엣지 케이스를 간과할 가능성이 크다. 그러므로 그에 대한 부분은 직접 주입을 잘 해줘야 한다. 즉, 이 부분은 TDD 방식에 따라 진행하고, 실제 코드를 작성하는 행위는 AI 코드 어시스턴트의 장점을 활용하는 게 좋다.

과거 TDD 방식은 “느리고 어렵다”는 이유로 선택되지 않는 경우가 많았다. 하지만 AI 코드 어시스턴트로 인해 이 단점을 많이 해소할 수 있게 되었다. AI 코드 어시스턴트는 단순하고 반복적인 부분에 집중하고, 개발자는 TDD를 통해 높은 수준의 설계와 문제 해결에 집중하면 된다. TDD의 가치인 명확한 요구사항 이해, 견고한 설계, 안정적인 유지보수는 AI 코드 어시스턴트만으로 아직 해결할 수는 없다.

CC by-nc-nd