에이전트에게 TDD·형식 기법을 지시해도 Zstd 구현 정확도가 일관되게 좋아지지는 않는지 비교

벤치마크만 계속 던지는데 모델은 시스템의 한 부분일 뿐임. 하니스도 조율해야 하고, 조율하다 보면 전에 통과했던 기능을 잃을 수도 있음.

글에서 말한 mutation testing은 에이전트가 코드를 손으로 바꿔 테스트 실패를 확인하는 방식처럼 보임. mutation-testing 프레임워크를 붙이고 일정 비율의 mutation을 죽이지 못하면 빌드를 실패시켜야 에이전트가 절차를 무시할 여지가 없음.

자동화하고 게이트로 막아도 에이전트가 다른 방식으로 지표를 속일 가능성은 있지 않을까?

오늘 실제로 수정 코드와 mutation 코드 양쪽에서 통과한 에이전트 작성 테스트를 봤는데, 게이트만 그걸 잡았음. 비율 기준이 아니라 mutation 하나라도 살아남으면 실패시켜야 한다고 봄.

이 실험은 테스트 방식과 코드 아키텍처를 떼어놓고 봐서 별로 유용하지 않다고 생각함. 효과적인 테스트의 80% 이상은 프레임워크가 아니라 구조에서 나오고, 나는 DI나 헥사고날 구조와 간단한 커버리지 검사를 강제하면 적은 노력으로도 결과가 좋아졌음.

같은 에이전트가 테스트 지시를 받고 구현까지 했으니 코드 구조에 외부 제약이 있던 건 아니라고 읽었음. 테스트 전략을 알고 있는 상태에서 구조도 만들게 한 셈임.

테스트는 구조가 아니라 행위를 검증해야 한다고 봄. Redis 같은 의존성을 테스트마다 몽키패치하기보다 composition root에서 fake로 바꾸는 편이 유지보수하기 낫다고 생각함.

Verus, TLA+, Creusot, Lean 코퍼스는 일반 코드보다 너무 작으니 에이전트가 사소한 증명 이상을 하기 어려운 결과는 납득감. 사람이 비자명한 시스템의 liveness 같은 고수준 명세를 쓰고, 에이전트가 guided refinement로 구현을 만족시키는지 보는 쪽이 더 흥미로움.

형식 기법의 재미는 부분 명세로 LLM에 원하는 바를 적고, 일반 구현에 증명 작업을 더해 의도가 실현됐는지 확인하는 데 있음. 도구 이름만 프롬프트에 던져서 정확도가 오르길 기대하는 건 원래 잘 안 될 것 같았음.

모델은 한 줄 주석을 바꿔도 lint와 수천 개 단위·통합 테스트를 전부 돌리고 싶어함. 비싼 테스트는 가설이 있을 때만, 변경 부근부터 넓혀가며 돌리라고 규칙을 계속 써도 잘 안 지켜서 잘못된 테스트 실행을 막는 결정적 hook까지 만들게 됨.

에이전트가 테스트를 꽤 잘한다고 생각했는데, 내가 테스트를 거의 리뷰하지 않았기 때문일 수도 있음. 최근에는 assert(CONSTANT_CONFIG == valueOfConfig)나 프롬프트에 저장소 URL 문자열이 있는지만 확인하는 테스트를 많이 봤음.

결과가 보여주는 건 추가 테스트 프롬프트의 오류율 차이가 크고, 최악은 최선보다 오류율이 두 배라는 점임. 그런데 기본 프롬프트도 꽤 괜찮고, 맞춤 프롬프트 대부분은 지시를 안 주는 것보다 나빠 보임.

에이전트는 종종 사람이 놓치는 edge case를 더 떠올리지만, 특정 skill을 주면 업무 로직을 잊고 기계적으로 변함. Superpowers로 TDD를 강제하면 Send 버튼 존재 여부 같은 저가치 테스트부터 채우고, 전송 허용 조건이나 성공·실패 뒤 동작, 중복 제출 같은 행위는 잘 끌어내지 못하더라.