테스트 주도 개발 (TDD)을 위한 나의 에이전트 기술

AI 에이전트들은 적어도 이 글을 쓰는 시점까지는 테스트를 작성하는 데 서툰 경향이 있습니다. 그들이 작성하는 테스트는 종종 모호하고, 난해하며, 지나치게 복잡하고, 편법적(hacky)이며, 무질서하고, 동어반복적이며, 보여주기식이고, 형식적이며, 완전히 무의미합니다.

불행하게도, 저는 별도의 교육을 받지 않은 에이전트들이 조만간 테스트 작성 능력이 크게 향상될 것이라고 기대하지 않습니다. 왜냐하면 에이전트들은 인간이 작성한 예시를 통해 학습하는데, 세상에 존재하는 인간이 작성한 예시들도 유감스럽게도 그만큼 나쁜 경우가 많기 때문입니다. "아마추어"들이 작성한 테스트가 품질이 낮은 것뿐만 아니라, 슬프게도 교육자들이 설파하는 테스트 관행 또한 상당히 나쁜 경우가 많습니다. 정말 상황이 좋지 않습니다.

좋은 소식은 약간의 가이드만 있다면 에이전트들이 합리적인 TDD (Test-Driven Development) 프로세스를 따르고 명확하고 의미 있는 테스트를 작성할 능력이 있다는 것을 발견했다는 점입니다. 그 가이드가 정확히 무엇일까요? 진실에 충분히 근접한 근사치로서의 짧은 답변은 Kent Beck의 Canon TDD입니다. 만약 에이전트에게 "Kent Beck의 Canon TDD를 따르라"는 말 외에 아무것도 없는 기술을 부여한다면, 목표의 약 60% 정도는 달성할 수 있을 것이라 생각합니다. 더 긴 답변은 제가 저만의 개인적인 TDD 기술에 녹여낸 내용입니다.

나의 TDD 기술

이것은 계속 업데이트되는 문서이므로, 저의 TDD 기술을 이 블로그 포스트에 담아 시간 속에 고정시키고 싶지는 않습니다. 대신, GitHub에서 저의 TDD 기술을 확인할 수 있습니다. 그렇기는 하지만, 그 기술의 본질은 변하지 않을 것이라 확신하기에 여기서 공유할 수는 있습니다.

먼저 저는 에이전트에게 제가 specify-encode-fulfill 루프라고 부르는 것을 알려주는데, 이는 제가 red-green-refactor를 대신하여 사용하는 개인적인 대안입니다. Specify-encode-fulfill (SEF) 과정은 다음과 같습니다:

Specify (명시): 구축하고자 하는 것에 대한 사양(specifications)을 구상합니다.
Encode (인코딩): 해당 사양을 자동화된 테스트(실행 가능한 사양)로 인코딩합니다.
Fulfill (충족): 사양을 충족하는 코드를 작성합니다.

SEF는 저에게 있어 TDD가 무엇인지에 대한 상위 수준의 관점입니다. 그보다 약간 더 낮은 수준에는 Kent Beck의 Canon TDD가 있으며, 아래에 제 방식대로 설명해 두었습니다.

• 현재 TDD 세션의 범위 내에 있는 명세(specifications) 목록을 작성합니다.
• 목록의 각 항목을 자동화된 테스트(automated test)로 인코딩합니다.
• 현재의 테스트 실패를 없앨 수 있을 만큼만 아주 최소한으로 코드를 변경합니다. "추측성 코딩 (speculative coding)"을 피하십시오. 현재의 테스트 실패를 해결하기 위해 필요한 것보다 더 많은 코드를 작성하면, 어떤 테스트에 의해서도 실행되지 않는 코드가 생길 위험이 있습니다.
• 선택적으로 리팩터링 (refactor)을 수행하되, 동작 변경 (behavior change)을 커밋하기 전에는 수행하지 마십시오. 동작 변경과 리팩터링을 절대 섞지 마십시오.
• 목록이 비워질 때까지 2번 단계로 돌아갑니다.

저의 TDD 기술은 이보다 조금 더 세부적인 내용을 포함하고 있지만, 이것이 프로세스의 핵심입니다. 다만, 이 프로세스는 테스트 자체의 설계에는 큰 영향을 미치지 않으므로, 저는 이를 위해 별도의 기술인 테스트 설계 리뷰 (Test Design Review)를 사용합니다. 테스트 설계 리뷰는 (편향을 피하기 위해) 별도의 에이전트를 생성하여, 설계 원칙 위반(예를 들어, 목적이 아닌 수단에 집중하는 테스트와 같은 경우)을 찾아내고 수정을 위한 제안을 합니다. 때때로 그 "수정안"이 의심스러울 때도 있지만, 대개는 정확합니다. 제 에이전트가 특정 테스트를 작성한 방식이 마음에 들지 않을 때, 저는 테스트 설계 리뷰를 실행하여 에이전트가 스스로의 실수를 잡아내도록 시도합니다.

일반 설계 리뷰 (General design review)

많은 테스트 설계 위반은 "사물을 있는 그대로 부르라"는 원칙과 같은 일반적인 소프트웨어 설계 원칙의 위반이기도 합니다. 저는 테스트를 테스트 설계 리뷰 기술에 통과시키는 것 외에도, 소프트웨어 설계 리뷰 (Software Design Review) 기술에도 통과시키는 것을 좋아합니다.

제 에이전트는 가끔 저를 놀라게 합니다. 저는 TDD 기술에 특별히 지켜질 것이라는 큰 기대 없이, 만약 우리가 쓰고자 하는 테스트를 작성하는 것이 어렵다면 그것은 우리가 "저녁을 만들기 전에 주방을 청소해야 할(clean the kitchen before we make dinner)" 신호일 수도 있다는 지침을 포함했습니다. 어떤 이유에서인지 Claude는 이 내용을 정말 진지하게 받아들였고, 우리가 아마도 주방을 청소해야 하는 것은 아닌지 묻기 위해 상당히 자주 멈춰 서곤 하는데, 실제로 그래야 하는 경우가 꽤 많습니다.

아직 제 에이전트(agents)가 100% 항상 수용 가능한 테스트를 작성하도록 만들지는 못했습니다. 아직 갈 길이 멀지만, 저의 TDD 기술은 어떤 변경 사항을 만들 때 기본 방식이 될 정도로 충분히 잘 작동해 왔습니다. 이러한 TDD 및 테스트 설계(test design) 원칙을 적용하는 것이 이토록 좋은 결과를 낳는다는 점은 저에게 놀라운 일이 아닙니다. 제 판단으로는, 가장 큰 AI 생산성 향상은 AI가 수십 년 전에 발견되어 오늘날에도 여전히 유효하며, 앞으로 어떤 새로운 기술이 등장하더라도 결코 유용성을 잃지 않을 시대를 초월한 불변의 원칙(timeless, immutable principles)들과 결합될 때 발생합니다.