테스트 기법 이름만으로는 버그를 못 잡는다 - 에이전트 검증에서 입력과 판정 기준 살피기

테스트 기법 이름만으로는 버그를 못 잡는다

TL;DR

• 실험 설계가 비전문가 관점으로 설정되는데 효과적인 테스트 기법으로 품질 기준을 넘기는 것이 어느 때보다 쉬워졌는데도 소프트웨어 품질은 나빠지는 것으로 보이며 개발자들이 쓰는 기본값이 잘 작동하지 않을 수 있다는 것이다. 그래서 관점이 규정된다. 테스트에 전문성이 없고 어떤 기법을 써야 한다고 들은 정도의 사람이 안내할 때 에이전트가 얼마나 효과적인지 보는 시험으로서, 단순한 지시가 구현 정확성을 개선하는지 검증했다.
• 규모가 구체적으로 제시되는데 Zstd 구현 평가에 TDD를 쓰라거나 Lean 4를 쓰라는 식의 부기를 붙여 26개 조건을 시험했고 모든 구현은 러스트였으며 조건과 노력 수준마다 80회 실행의 평균이라는 것이다. 그리고 스킬도 포함된다. 깃허브 별 25만 개와 포크 3만 8,000개를 가진 모음의 테스트 스킬을 비롯한 네 가지를 함께 시험했는데, 필자 것을 뺀 나머지는 에이전트에게 관련 스킬을 찾으라고 했을 때 최상위로 나온 것들이다.
• 결과가 반직관적으로 요약되는데 무엇도 크게 능가하지 않지만 추가 지시가 없는 기본이 평균보다 상당히 잘하며 에이전트가 추천한 스킬들은 오히려 못했고 TDD도 잘하지 못했다는 것이다. 그리고 원인이 밝혀진다. 에이전트가 실제로 무엇을 했는지 보면 이 도구나 기법을 어떻게 쓰는지 잘 모른다는 것이 금방 드러나며, 이야기해 본 모든 사람도 에이전트가 테스트에 정말 나쁘고 합리적으로 테스트하는 법을 이해하지 못하는 것 같다고 말했다.
• 실패 양상이 두 가지로 정리되는데 기법 이름을 대면 에이전트는 원래 쓰던 테스트를 다른 종류 기법의 틀 안에서 쓰거나 기법을 표면적으로만 쓰면서 그 가치를 뽑아내는 일은 하지 않는다는 것이다. 그리고 예시가 구체적이다. 형식 방법에서는 대체로 무관한 속성을 증명했고 속성 기반 테스트에서는 무작위 입력에 크게 의존해 무효나 거부 경로를 잔뜩 때리거나, 사소한 속성을 찾아 그것에 저가치 무작위 사례를 돌렸다.
• 그럼에도 통하는 것이 제시되는데 합리적인 테스트와 분류 구조를 세우도록 안내하면 큰 감독 없이 에이전트가 거기에 더하게 하는 것이 어느 정도 작동한다는 것이다. 그리고 추정이 붙는다. 모델 안 어딘가에 이 일을 하는 법에 대한 이해가 있는데 그것이 기본값이 아니고 기법 이름을 대는 것이 통할 만큼 기본값에 가깝지도 않지만, 충분히 프라이밍되면 그 지식이 실제로 실행에 들어간다.

Source

How well do agents use test/verification techniques? — Dan Luu, 2026년 9월 (약 1만 단어)

[danluu.com/agentic-testing/](https://danluu.com/agentic-testing/)

Knowledge

왜 이 실험을 했는가

문제 설정이 앞선 관찰에서 이어진다. 코딩 에이전트에게 효과적인 테스트 기법을 쓰게 해서 특정 품질 기준을 넘기는 것이 어느 때보다 쉬워졌는데도, 소프트웨어 품질은 나빠지는 것으로 보인다고 앞서 지적했다는 것이다. 그리고 함의가 제시된다. 이는 개발자들이 쓰는 기본값이 무엇이든 그것이 그리 잘 작동하지 않을 수 있음을 시사한다는 것이다.

그래서 이번 시험의 목적이 규정된다. 특정 기법이나 라이브러리를 쓰라는 단순한 지시가 구현 정확성을 개선하는지 시험한다는 것이다. 그리고 관점이 명시되는데 이 설정이 중요하다. 테스트에 전문성이 없고 어떤 기법을 적용해야 한다거나 어떤 라이브러리를 써야 한다고 들었을지도 모르는 사람이 안내할 때 에이전트가 얼마나 효과적인지 보는 일종의 시험이라는 것이다.

설계도 제시된다. 에이전틱 프로그래밍 언어 효과성 비교에서 논의한 Zstd 구현 평가를 재사용하되, Zstd를 구현하라는 프롬프트에 서로 다른 부기를 붙여 테스트 기법과 테스트 라이브러리를 비교한다는 것이다. 부기 예시도 열거된다. 테스트 주도 개발을 쓰라거나 Lean 4를 쓰라거나 QuickCheck을 쓰라거나 속성 기반 테스트를 쓰라는 것이라는 것이다. 다른 평가도 언급된다. IMAP RFC 같은 다른 평가도 돌렸고 간단히 논의한다는 것이다.

조건 목록도 전부 열거된다. 모든 구현은 러스트였고 시험한 26개 프롬프트 조건은 ACL2와 Alloy, 위험 영역 감사 및 퍼징, 감사 먼저, Creusot, 추가 지시 없는 기본, 차분 테스트, 퍼징, Hegel, Insta, 최선의 기법을 쓰라고 요청한 판단, Kani, Lean 4, 실수하지 말라, 변형 테스트, 돌연변이 테스트, 속성 기반 테스트, Proptest, QuickCheck, rstest, 러스트 내장 테스트 프레임워크, Z3와 cvc5와 Yices를 모두 쓸 수 있는 SMT 솔버, Spin, TDD, TLA+, Verus였다는 것이다.

스킬도 네 가지가 추가되었다고 한다. 공식 Hegel 스킬과 ECC 러스트 테스트 스킬, Trail of Bits 속성 테스트 스킬, 그리고 필자가 쓴 테스트 스킬이라는 것이다. ECC의 규모도 제시된다. 깃허브 별 25만 개와 포크 3만 8,000개를 가진 스킬 모음이라는 것이다. 자기 위치도 밝힌다. 자기는 스킬 대신 프롬프트를 쓰는 러다이트여서 좋은 스킬을 어떻게 쓰는지 감이 없다는 것이다. 선정 기준도 밝혀진다. 자기 스킬을 뺀 나머지는 관련 스킬을 찾으라고 했을 때 에이전트가 최상위로 내놓은 것들이라는 것이다.

사전 등록한 예측

예측을 미리 등록했다고 한다. TDD가 부진할 것이라는 것이 55퍼센트 확신이라는 것이다. 그리고 동기가 솔직하다. 부진할 것이라 생각해서 TDD를 일부러 추가했다는 것이다. 확신이 낮은 이유도 제시된다. TDD를 하라고 지시받았을 때 에이전트가 무엇을 할지 모르며 어쩌면 에이전트가 TDD를 하지 않고 부진하지 않은 다른 것을 할 수도 있기 때문이라는 것이다.

두 번째는 형식 방법이 초과 성과를 내지 못할 것이라는 52퍼센트 확신이라는 것이다. 근거도 제시된다. 형식 방법이 효과적이고 유용하며 지금 어느 때보다 그렇지만 좋은 테스트 방법도 효과적이고 유용하므로 단순한 문제에서 비슷한 수준의 역량으로 쓰인다면 형식 방법이 능가하지 않아야 한다는 것이다. 그런데 반대 가능성도 제시된다. 형식 방법이 효과적인 테스트 기법보다 더 많이 선전되었으므로, 랩이 합성 데이터로 강화학습 환경을 만들어 형식 방법에 아주 효과적이도록 훈련했을 가능성도 충분하다는 것이다. 그리고 유보가 붙는다. 효과적인 테스트 기법을 훈련하는 것이 더 쉬울 것으로 예상하지만 그것이 상대적으로 유행이 아니어서 되지 않았을 수 있다는 것이다.

세 번째는 실수하지 말라가 지시 없음을 능가하지 못할 것이라는 95퍼센트 확신이라는 것이다. 이유도 유머러스하다. 그것은 농담이고 많은 사람이 시도해 본 것이며 통했다면 분명 사람들이 알아챘을 것이라는 것이다.

네 번째는 별 25만 개와 포크 3만 8,000개를 가진 ECC 테스트 스킬이 능가하지 못할 것이라는 65퍼센트 확신이라는 것이다. 근거도 제시된다. 다소 크고 유용할 것으로 예상되는 정보가 없으며 에이전트에게 TDD를 쓰라고 지시하는데 그것이 에이전트에게 TDD를 하게 하는 만큼 상황을 나쁘게 만들 것으로 예상한다는 것이다. 그리고 나머지 정보는 유용해 보이지 않고 비용이 있다는 것이다.

Hegel 스킬도 능가하지 못할 것이라는 65퍼센트 확신이라고 한다. 근거는 규모다. 아주 크고 스킬 파일과 링크된 러스트 참조가 2만 토큰을 넘으며 에이전트 지시보다 튜토리얼처럼 읽힌다는 것이다. Trail of Bits 스킬도 능가하지 못할 것이라는 55퍼센트 확신인데, 유용해 보이는 정보가 있지만 꽤 크다는 것이다.

무엇도 크게 능가하지 않았다

결과 제시 방식이 먼저 설명된다. 조건별 결과를 보여주는 아주 어지러운 그래프가 있으며 데이터를 볼 때 대부분의 사람보다 훨씬 밀집하고 어지러운 그래프를 선호하는 경향이 있다는 것이다. 축도 제시된다. x축에 비용, y축에 숨겨진 테스트를 100퍼센트 통과한 실행의 비율이며 조건과 노력 수준마다 80회 실행의 평균이라는 것이다. 색 규칙도 제시된다. 형식 방법은 푸른색, 속성 기반 테스트는 녹색처럼 비슷한 것을 비슷한 색으로 하려 시도했다는 것이다.

첫 관찰이 제시된다. 무엇도 정말 크게 능가하지 않는다는 것이다. 그런데 예외가 있다고 한다. 추가 지시가 없는 기본이 평균보다 상당히 잘한다는 것이다.

세부도 제시된다. xhigh에서는 평균적으로 퍼징과 속성 기반 테스트 관련 조건이 형식 방법보다 조금 나았고 medium에서는 상황이 훨씬 뒤섞였다는 것이다. 스킬 결과도 제시된다. 에이전트가 추천한 테스트 관련 스킬들은 부진했지만 필자의 빠른 맞춤 스킬은 괜찮았다는 것이다. 그리고 차이가 지목된다. 주요 차이는 필자 스킬이 에이전트의 기본 행동에서 더 생산적인 행동으로 밀어내도록 설계되었고 다른 스킬들은 튜토리얼처럼 보인다는 것이다. TDD 결과도 예측대로다. TDD는 잘하지 못했으며 어떤 스킬도 에이전트가 TDD를 쓰도록 제안했고 그 스킬도 에이전트가 지시를 따르려 한 경우에 부진했다는 것이다.

왜 그런가 — 기법의 틀 안에서 원래 하던 것

원인이 명확히 제시된다. 에이전트가 실제로 무엇을 했는지 보면 일반적으로 이 도구나 기법을 어떻게 쓰는지 잘 모른다는 것이 금방 드러난다는 것이다. 그리고 합의도 제시된다. 앞서 지적했듯 그리고 필자가 이야기해 본 모든 사람도 지적했듯, 에이전트는 테스트에 정말 나쁘고 기본적으로 합리적으로 테스트하는 법을 이해하지 못하는 것 같다는 것이다.

인용도 하나 붙는다. 게리 번하트의 논평인데, AI 에이전트의 테스트 접근이 대체로 이렇다는 것이다. 내용이 신랄하다. 15년 전 목을 실제로 써 보지도 않고 목에 반대한 누군가가 꿈꿔낸 병리적 사례를 가져다가, 그 병리를 자기 테스트 전략의 근간으로 만든다는 것이다.

그런데 기법을 지정해도 이 접근이 기대만큼 바뀌지 않는다고 한다. 두 양상이 제시된다. 테스트 기법에서 에이전트는 원래 쓰던 테스트를 다른 종류 테스트 기법의 프레임워크 안에서 쓰는 경향이 있다는 것이다. 또는 기법을 표면적으로만 쓰면서 그 기법에서 가치를 뽑아내는 일은 실제로 하지 않는다는 것이다.

구체적 예시가 제시된다. 대부분의 경우 기법 이름이 주어지면 게리가 서술한 것을 그 기법에 대해 했다는 것이다. 형식 방법의 예시가 제시된다. 대체로 무관한 속성을 증명했다는 것이다. 속성 기반 테스트의 예시도 제시된다. 완전히 무작위인 입력에 크게 의존해 무효나 거부 사례를 잔뜩 때리거나 확인할 사소한 속성을 찾아 그 사소한 속성에 저가치 무작위 사례를 돌렸다는 것이다.

일반성도 확인된다. IMAP RFC에서 각 조건 40회를 돌린 결과나 다른 무작위 RFC에서 개별 실행 몇 회를 돌린 결과도 실질적으로 다르지 않았다는 것이다. 그래서 결론이 제시된다. 문제 유형과 무관하게 Zstd 같은 비트 조작 문제든 IMAP 같은 프로토콜이든 다른 무엇이든, 에이전트는 형식 방법이나 테스트 라이브러리나 기법을 효과적인 방식으로 쓰지 않았다는 것이다.

노력 수준별 차이도 제시된다. xhigh에서 에이전트는 일반적으로 자기가 쓴 테스트를 통과시킬 수 있었지만 나쁜 테스트를 썼다는 것이다. 예시가 구체적이다. 네 비트스트림을 쓰는 기능의 테스트에 동일한 비트스트림 네 개를 넣어서 비트스트림을 바꿔 넣었을 때 발생할 버그를 놓친다는 것이다. 그리고 낮은 노력의 결과도 제시된다. 순진한 루프에서 더 낮은 노력 수준으로 돌리면 결과가 더 나쁘며 에이전트가 이것을 더 많이 하고 더 낮은 정확성으로 정체된다는 것이다.

왜 강화학습 환경이 없는가

의문이 제기된다. AI 랩이 에이전트가 테스트를 잘하도록 학습시킬 강화학습 환경을 만들지 않은 것이 궁금하다는 것이다. 근거도 제시된다. 소프트웨어가 합리적으로 작동하지 않는 것이 코딩 에이전트 채택에 중요해 보이며 강화학습에 순응할 만한 종류의 일로도 보인다는 것이다.

비교 사례가 제시된다. 앞서 봤듯 에이전트는 유계 런타임 최적화 문제에 꽤 능해졌으며 그것은 강화학습 환경을 값싸게 대량 만들 수 있는 정확히 그런 종류의 일이므로 이해가 된다는 것이다. 그래서 판단이 제시된다. 효과적인 테스트와 테스트 기법을 위한 강화학습 환경을 만드는 것도 같은 부류의 문제로 보인다는 것이다.

가능한 설명도 제시된다. 어쩌면 제한 요인이 효과적인 테스트 기법에 대한 지식이 널리 퍼져 있지 않아서 아무도 시도할 생각을 못 했고 사람들이 표준 단위 테스트를 하게 하는 식으로 에이전트를 비효율적으로 테스트하게 만드는 것일 수 있다는 것이다. 또는 이 문제가 어떤 이유로 런타임 최적화보다 포장하기 훨씬 어려울 수 있다는 것이다.

그리고 조건부 전망도 붙는다. 에이전트가 테스트나 검증 없이도 대체로 올바른 코드를 쓸 만큼 좋아지면 이 논점이 곧 무의미해질 수 있다는 것이다. 다만 현재 상태에서의 판단은 명확하다. 처음부터 지금까지 공개된 에이전트의 상태로 보면, 테스트 전문가의 안내 없이도 에이전트가 테스트하는 법을 어느 정도 아는 것이 에이전틱 코딩 효과성을 상당히 높였을 것으로 보인다는 것이다.

조건별 관찰

Verus가 먼저 제시된다. Verus는 SMT 솔버와 여러 유형의 추론을 써서 코드가 명세와 일치함을 증명한다는 것이다. 그런데 에이전트는 그것을 하지 않았다고 한다. 대신 Zstd와 관련된 여러 추상적 속성에 대한 증명을 만들었다는 것이다. 그리고 필자의 반응이 제시된다. 자기는 Verus 같은 도구를 써 본 적이 없어 전문가나 초보 사용자가 보통 무엇을 할지 말할 수 없지만 튜토리얼을 읽어 보니 에이전트가 실제 코드를 검증하려 시도하지 않고 추상적 추론에만 쓴 것이 조금 이상하다는 것이다. 이유도 붙는다. 실제 코드에 대한 속성을 증명하기 쉽게 설계된 것처럼 보이기 때문이라는 것이다. 증명된 속성의 질도 제시된다. 일반적으로 증명된 속성이 적었고 증명된 속성은 흥미롭지 않았다는 것이다.

Kani도 제시된다. Kani는 러스트 모델 검사 라이브러리라는 것이다. 그리고 상대적 성과가 제시된다. 실제로 실행될 코드에 형식 방법을 실제로 쓴다는 면에서 Kani가 최고의 커버리지를 가졌으며 Zstd 코드에 실제로 쓰였다는 것이다. 다만 빈도가 낮다고 한다. 그것은 이따금만 일어났고 대부분의 사용은 표면적이었다는 것이다.

의미 있는 사례도 하나 제시된다. 실제 Kani 사용이 러스트 코드를 바꾸게 만든 사소하지 않은 버그를 잡은 경우가 한 번 있었다는 것이다. 그리고 평가가 붙는다. 160회 중 1회는 놀랍지 않지만 에이전트가 때로 Kani를 합리적으로 쓰는 데 우연히 도달할 수 있음을 보여주며 강화학습 환경에서 쓴다면 모델이 Kani를 더 효과적으로 쓰는 법을 배울 수 있다는 뜻일 것이라는 것이다. 비용도 제시된다. Kani는 다른 조건보다 눈에 띄게 비용이 높았고 Kani 출력을 반복해서 읽는 것이 비싸서 입력 토큰 비용이 높았기 때문으로 보인다는 것이다.

ACL2도 제시된다. ACL2는 정리 증명기이며 여기 결과에서 주목할 점은 많은 경우 192GiB 한도에서 메모리 부족이 났다는 것이다. 그리고 편향이 인정된다. 메모리 부족 결과는 집계되지 않았으므로 결과가 어떤 불투명한 방식으로 편향된다는 것이다. 해석도 조심스럽다. ACL2가 기본보다 높은 점수를 받았지만 이것이 인과적이고 유의하다면 놀라울 것이라는 것이다. 이유가 제시된다. 다른 거의 모든 형식 방법에서 봤듯 ACL2도 대체로 정확성에 크게 영향을 주지 않는 것을 증명하는 데 쓰였으므로 왜 정확성이 개선되는지 명확하지 않다는 것이다.

그리고 중요한 논평이 붙는다. 조건이 많을 때 다른 조건들이 성능을 심하게 저하시키지 않았다면, 기본이나 겉보기에 동등한 실수하지 말라가 상위에 있을 것으로 예상하지 않는다는 것이다.

Proptest도 제시된다. 다른 무작위 테스트에서 봤듯 대부분의 테스트가 그리 흥미롭지 않았고 무작위성에 너무 과하게 의존해 커버리지가 나빴다는 것이다. 그런데 하나의 가치가 인정된다. 속성 기반 테스트의 나쁜 사용에도 불구하고 proptest의 축소, 즉 테스트 실패를 일으키는 더 단순한 입력을 찾는 기능은 때로 어느 정도 가치를 제공했으며 그것은 대부분의 다른 경우에서 본 거의 없는 가치보다 낫다는 것이다.

속성 기반 테스트 조건도 흥미롭다. 에이전트에게 모든 옵션이 설치된 컨테이너가 주어졌고 모든 에이전트가 proptest를 골라서 사실상 두 번째 proptest 조건이 되었다는 것이다. 그리고 관찰이 붙는다. 이 두 번째 우연한 proptest 갈래도 proptest처럼 평균보다 훨씬 잘 나온 것이 조금 흥미롭다는 것이다.

필자가 쓴 스킬이 최고점을 받았지만

필자 스킬의 맥락이 서술된다. 자기는 일반적으로 스킬을 쓰지 않고 프롬프트에 의존해 무엇이 일어났는지 보고 다시 프롬프트하므로, 무엇이 좋은 스킬을 만드는지 직관이 없다는 것이다. 그리고 계기가 밝혀진다. 맥스 비트커가 테스트에 대해 머릿속에 있는 정보를 인코딩하려는 테스트 스킬의 결과를 보는 것이 흥미로울 것이라고 제안했다는 것이다.

예측도 밝혀진다. 사전 등록하지는 않았지만 머릿속 추측은 이것이 잘 작동하지 않을 것이라는 것이었다는 것이다. 근거가 개인적이다. 2015년 사람들에게 이것을 전달하려 시도한 것에서 자기가 누군가 어떻게 테스트해야 하는지 글로 명시적으로 늘어놓는 데 능하지 않다고 생각한다는 것이다. 그리고 대비가 제시된다. 사람과 마주 앉아 무엇을 할지 보여준 적이 있고 그것은 대체로 평생 전향시켜 평균보다 훨씬 나은 버그 발견자로 만들었지만 보여주는 것으로 전달하는 능력은 그것을 하는 법을 적어서 전달하는 것과 다르고 더 쉬운 기술이라는 것이다.

스킬 내용도 제시된다. 구현 전에 미묘한 버그가 있을 만한 영역을 생각하고 각각에 대해 있을 만한 실수와 그럴듯한 대안 해석을 진술한 뒤 결과가 달라지는 검사를 만들라는 것이다. 구현 후에는 고위험 영역에 대해 프로덕션 코드의 맥락 없이 독립적으로 결과를 다시 도출해 비교하라는 것이다. 가능하면 속성 기반 테스트나 무작위 입력으로 공간을 탐색하되 패닉이나 크래시 없음 무작위화에는 노력을 최소화하라는 것이다. 무작위화할 때는 흥미로운 상태와 코드 경로를 탐색할 입력으로 기울고 모두 같은 오류 경로로 떨어지는 입력을 순진하게 무작위화하지 말라는 것이다. 세부가 불확실하면 독립적 추론으로 무엇이 옳은지 확인하라는 것이다.

그런데 결과가 역설적이다. 이것이 최고점을 받았지만 의도한 대로 작동하지 않았다는 것이다. 구체적으로는 신선한 맥락 부분을 거의 전혀 하지 않았으므로 그것을 넣은 것이 무의미했고 그것이 더 자주 하도록 강제되어야 하는 효과적인 것인지 아니면 제거되어야 하는 것인지 알 수 없다는 것이다.

한계 사례도 제시된다. 에이전트가 위험 영역을 식별하는 법은 아는 것 같았지만 그것이 반드시 올바른 일을 했다는 뜻은 아니라는 것이다. 예시가 정교하다. 에이전트가 Zstd에서 인코딩과 디코딩에 비트스트림이 뒤집히는 것을 위험하다고 식별했지만 이것을 시험하는 테스트에서 더 잘하지 못했다는 것이다. 구체적 실행도 제시된다. medium 35번 실행에서 에이전트가 이것을 위험하다고 식별하고 독립적 도출과 감사를 했는데도 실패했으며 관련 테스트가 있었지만 입력이 회문이어서 순서를 뒤집어도 같은 결과가 나와 이것을 거꾸로 한 구현이 통과할 수 있었다는 것이다.

또 하나의 문제도 지목된다. 모든 퍼징과 속성 기반 테스트가 손으로 되었다는 것이다. 그리고 개선 여지가 제시된다. 에이전트가 proptest를 쓰는 데 괜찮아 보이고 proptest에 기댈 유용한 기계 장치가 있으므로, 에이전트에게 proptest를 쓰라고 지시하면 이 스킬을 사소하게 개선할 수 있을 것이라는 것이다. 부분적 성공도 인정된다. 너무 무작위인 쓸모없는 테스트를 많이 생성하는 표준 실패 양상을 최소화하려던 지시는 방향적으로 작동해서 더 큰 비율의 에이전트가 어느 정도 의미 있는 테스트를 생성했지만 테스트는 여전히 인간이 쓸 것보다 나빴다는 것이다.

자기 작업 방식과의 차이도 밝혀진다. 자기는 프롬프트하고 결과를 본 뒤 그것에 기반해 다시 프롬프트하는 데 익숙하므로 정보를 앞에 몰아넣는 데 익숙하지 않으며 그것은 정보에 반응하는 것과 꽤 다른 문제라는 것이다. 그리고 결론이 제시된다. 이전 퍼징 작업에서 에이전트가 자주 빠지는 실패 양상을 봤고 스킬이 그 실패 양상을 막으려는 것이었지만 이따금이라도 확인하면 이것을 하기가 더 쉬우며 사전 지시만으로는 표준 실패 양상을 멈추기에 충분하지 않았고 다만 어느 정도 완화했다는 것이다.

스킬에 대한 순진한 생각

스킬을 안 쓰던 배경이 서술된다. 사람들이 무언가를 한다는 말을 듣고 게을러서 시도하지 않았기에 자기 작업 흐름이 나쁘거나 구식이거나 비효과적이라고 느낀 때가 여러 번 있었으며 스킬에 대해 한동안 그렇게 느꼈다는 것이다. 대안도 밝혀진다. 대신 프롬프트로 붙여 넣는 것들의 큰 스크래치패드를 유지하는데, 버전 관리를 쓰는 대신 코드 블록을 주석 처리해 저장하는 것과 비슷하게 느껄진다는 것이다.

그런데 관찰이 바뀌었다고 한다. 토르스텐 발의 강연에서 그가 스킬에 크게 의존하지 않는다고 언급하는 것을 봤고 LLM에 상대적으로 효과적인 것 같은 몇 사람도 스킬을 별로 쓰지 않는 것을 알게 되어 자기가 크게 놓치는 것이 없는지 궁금해졌다는 것이다.

그리고 실험 결과가 직관을 확인했다고 한다. 스킬이 도움이 되지 않고 아마 실제로 해로울 것이라는 느낌이었고 스킬은 대체로 그렇게 했으므로, 에이전트가 어떻게 반응하는지 보고 작은 실험을 많이 돌린 데서 오는 직관이 스킬에도 어느 정도 유지되는 것 같다는 것이다.

추가 실험도 언급된다. 회사가 제품을 지원하려고 만든 공식 스킬 두 개로 실험을 돌렸으며 하나는 큰 AI 랩의 것이고 다른 하나는 수십억 달러 규모의 작은 회사 것인데 두 경우 모두 스킬이 결과를 나쁘게 만들었다는 것이다.

그런데 결론이 반전된다. 재미있게도 이 실험들 뒤에 개인 용도의 스킬에 전보다 더 낙관적이 되었다는 것이다. 이유가 제시된다. 실패 양상이 예측 가능해 보이므로 큰 비용의 실험 없이 고칠 수 있기 때문이라는 것이다. 그리고 구분이 제시된다. 서로 다른 모델과 하네스에서 잘 작동하도록 의도된 정말 좋은 공개 스킬을 만드는 것은 어려울 수 있지만 많은 스킬을 스킬 없음보다 못하게 만드는 문제를 개인 용도로 해결하는 것은 꽤 할 만해 보인다는 것이다.

스킬 작성에 대한 진단도 제시된다. 이 글에서 본 모든 스킬과 다른 두 실험의 스킬이 인간 튜토리얼 지시처럼 쓰인 것 같았으며 스킬의 목표가 무언가를 어떻게 하는지 설명하는 것처럼 보였다는 것이다. 그리고 대안이 제시된다. 주제에 대한 지식을 이미 어느 정도 가져야 하는 모델과 일할 때는 그것이 최적이 아닐 것 같으며 모델이 이미 어떤 기본 행동 분포를 가질 것이므로 더 자연스러운 일은 그 행동을 수정할 진술을 주는 것이고 인간이나 지식 없는 에이전트가 그 행동을 아예 할 수 있게 하는 지시를 쓰는 것이 아니라는 것이다.

문제도 지목된다. 서로 다른 하네스와 모델과 노력 수준에서 다른 기본 행동을 얻는 것이 명백한 문제지만 프롬프트나 스킬에 텍스트를 잔뜩 던지는 것이 이것을 실제로 바꾸지는 않으며 그것은 에이전트를 기본에서 밀어내는 더 긴 방법일 뿐이고 의도치 않은 밀어내기를 할 수 있는 텍스트가 많다는 것이다. 실증도 제시된다. 여기서 봤듯 많은 텍스트가 그냥 무시되며 무엇이 언제 무시되는지는 물론 하네스와 모델과 노력에 의존한다는 것이다. 사례도 붙는다. ECC 스킬은 읽혔을 때조차 대부분의 지시가 무시되었고 TDD 지시는 영향력이 있어서 결과를 나쁘게 만들었지만 명확히 제시되었음에도 TDD를 하라는 지시는 여전히 제대로 따라지지 않았다는 것이다.

세대 간 변화도 근거로 제시된다. 어떤 종류의 프롬프팅이 효과적인지가 모델 출시 사이에 충분히 바뀌므로 코드를 잘 테스트하기 같은 일반적인 것에 대해 이 스킬들이 그렇게 많은 모델과 노력에서 어떻게 작동해야 하는지 명확하지 않다는 것이다. 실제 경험도 제시된다. 한 세대에서 다음으로 가는 것만으로 작업 방식이 상당히 바뀌었는데 꽤 안정적으로 통했던 여러 것이 멈추거나 훨씬 덜 안정적이 되었기 때문이며 전반적 능력 수준은 더 높아 보이지만 그렇다는 것이다. 그래서 결론이 나온다. 이전 세대를 프롬프트한 것처럼 지금 세대를 프롬프트하지 않는 것과 같은 방식으로, 같은 스킬을 쓰고 싶지 않을 것 같다는 것이다.

일반 테스트 스킬에 대한 판단도 제시된다. 테스트를 생각하면 특정 모델이 특정 노력 수준에서 빠지는 특정 함정이 있어 그것에서 밀어내고 싶지만 테스트되는 것과 원하는 품질 수준과 품질을 원하는 차원과 무관한 일반적 테스트 작업 흐름이 실제로 있지는 않다는 것이다. 그래서 결론이 제시된다. 에이전트가 일반적으로 해야 하는 테스트 단계 집합을 늘어놓는 일반 테스트 스킬을 원하지 않을 것 같다는 것이다.

스킬이 유용할 곳도 제시된다. 에이전트에게 작업 흐름 실행 방법이나 API와 인터페이스와 상호작용하는 방법을 가르치는 것 같은 일에는 스킬이 일반적으로 유용할 수 있다는 것이다. 예시도 제시된다. 에이전트가 웹 브라우저를 조작하도록 돕는 스킬 같은 것이며 읽어 보니 잘 작동하고 번거로움을 많이 덜어 줄 종류로 보인다는 것이다. 그리고 차이가 지목된다. 실제 스킬과 스크립트를 읽어 보면 여기서 시험한 테스트 스킬들과 아주 다른 스타일을 갖는다는 것이다.

그래서 무엇이 통하는가

자기 경험이 제시된다. 합리적인 테스트와 분류 구조를 세우도록 에이전트를 안내하면, 큰 감독 없이 에이전트가 거기에 효과적으로 더하게 하는 것이 어느 정도 작동한다는 것이다. 그리고 자기 편향도 밝힌다. 배경 때문에 기대는 테스트가 어떤 형태의 무작위 테스트나 퍼징이나 속성 기반 테스트라는 것이다.

다른 사람의 사례도 제시된다. 제이미 브랜던과 이야기했고 그는 스냅숏 테스트로 같은 것을 발견했다는 것이다. 실패 사례가 구체적이다. 한 프로젝트에서 여러 모델을 쓰는 에이전트에게 스냅숏 테스트를 하라고 요청하면 하고 있다고 말하고는 그냥 하지 않았으며 단위 테스트를 쓰고 스냅숏 테스트를 썼다고 말했다는 것이다. 성공 사례도 제시된다. 다른 프로젝트에서는 합리적인 종단간 테스트를 모의 입출력과 함께 쓰게 할 수 있었는데, 테스트를 별도 크레이트로 옮기고 테스트를 그 크레이트에 유지하며 공개 인터페이스를 수정하지 말라는 지시를 에이전트 규칙 파일에 넣은 뒤에야 그랬다는 것이다.

그리고 일반화가 제시된다. 앞서 본 문제와 비슷하게 조금이라도 합리적인 무엇이든 하는 것이 통하는 것 같다는 것이다. 대비도 제시된다. 에이전트에게 말을 걸어 Zstd나 IMAP 평가에서처럼 가벼운 지시를 주면 에이전트는 나쁜 작업을 한다는 것이다. 그런데 반대편이 제시된다. 무엇을 하는지 보고 몇 문장을 더 입력하면 종종 꽤 빠르게 좋은 지점에 이르게 할 수 있다는 것이다.

추정도 제시되는데 이 대목이 이 글의 핵심 가설이다. 모델이 어떻게 작동하는지 이해하려 시도한 적 없이 만들어낸 아마 완전히 틀린 추측으로는, 모델 안 어딘가에 이 일을 하는 법에 대한 어떤 이해가 있다는 것이다. 조건도 명확하다. 그것이 기본값이 아니며 어떤 기법을 쓰라고 이름을 대는 것이 통할 만큼 기본값에 가깝지도 않지만 모델이 충분히 프라이밍되면 이 일을 하는 법에 대한 지식이 실제로 실행에 들어간다는 것이다.

남은 질문도 제시된다. 이것이 스킬로 효과적으로 포장될 수 있는지, AI 랩이 테스트나 형식 방법에 더 능하도록 모델을 훈련하기 시작할지, 아니면 그것들을 직접 개선하지 않는 그들이 하는 무엇이든 간접적으로 충분히 개선해서 에이전트가 큰 감독이나 구조 없이 괜찮은 테스트를 쓰게 될지 궁금하다는 것이다.

예측 정확도와 부록

예측 결과가 정리된다. TDD 부진은 참이라는 것이다. 형식 방법 미초과도 참인데 예상한 이유가 아니었고 에이전트가 그것을 조금도 효과적으로 쓰지 못했으므로 당연히 능가할 수 없었다는 것이다. 실수하지 말라도 참인데, 무동작이 에이전트에게 비효과적인 일을 하게 하는 것보다 나으므로 대부분의 조건을 능가했다는 것이다. ECC 스킬 미초과도 참이며 스킬을 더 썼다면 확신이 더 컸을 것인데 대부분의 스킬 텍스트가 별 작용을 하지 않을 것 같고 작용할 것 같은 텍스트는 역효과로 보이기 때문이라는 것이다.

등록하지 않았지만 암묵적으로 가졌던 추측도 밝혀진다. Lean이 형식 방법 중 상대적으로 잘할 것이라는 것은 거짓이었다는 것이다. 자기 스킬이 보통에서 나쁠 것이라는 것도 거짓이었다는 것이다. 그리고 솔직한 소감이 붙는다. 맥스 비트커가 무엇이 일어날지 정확히 추측하고 미리 말해 주고 실제로 일어난 것과 일치하는 이유를 댔는데, 누군가 무언가가 일어날 이유를 대는데 믿지 않았고 그다음 정확히 그 이유로 일어나면 꽤 우스꽝스럽게 느껄진다는 것이다.

부록에는 반응도 실린다. 데이비드 매카이버가 안타깝게도 필자가 옳고 Hegel 스킬이 지금 좀 형편없다고 말했다는 것이다. 그리고 진단이 인용되는데 이 문장이 날카롭다. 많은 에이전트 스킬의 공통 문제는 에이전트가 에이전트 스킬을 쓰는 데 형편없고 또한 모두가 자기들 포함해서 스킬을 쓰는 데 에이전트를 쓴다는 것이다. 후속도 제시된다. 매카이버가 벤치마크를 세워 결함을 확인했고 스킬을 개선하거나 스킬이 필요 없게 문서를 조정하는 작업을 하는 중으로 추정된다는 것이다. 그리고 측정의 가치가 강조된다. 측정과 벤치마킹이 과소평가되었다고 생각하는데, 측정을 발표하는 것만으로 사람들이 몰랐던 문제를 지적하고 변화를 유발할 수 있기 때문이라는 것이다.

에이전트의 우스꽤음도 하나 실린다. 분석을 위해 단순한 조회를 요청한 뒤 에이전트가 2시간 20분간 돌아간 perl 프로세스를 실행해서 필자가 죽였다는 것이다. 원인도 제시된다. 서브에이전트가 44킬로바이트 1,364줄의 상대적으로 작은 파일에 정규식 검색을 하려고 perl을 썼는데 표현식이 PCRE에서 퇴화해 조합적으로 큰 작업을 했다는 것이다. 그리고 대조가 제시된다. 몇 분에 만들어 본 정규식 엔진으로 다시 돌리니 0.7초에 끝났고 러스트 정규식은 0.6초였다는 것이다. 세 가지 문제도 지목된다. 조합적 폭발을 줄 수 있는 정규식 엔진을 애초에 호출하지 않았어야 하고 표현식이 틀렸으며 성공해도 의도한 것을 하지 않고 서브에이전트가 끝난 뒤 하네스가 이것을 자동으로 죽이지 않은 이유가 무엇인지라는 것이다. 그리고 일반화가 붙는다. 에이전트는 이런 폭주 프로세스를 자주 남겨 둔다는 것이다.

더 생각해보기

• 지시 없는 기본이 평균 이상이라면 추가 지시의 기대값은 어떻게 계산해야 하는가.
• 기법의 틀 안에서 원래 하던 테스트를 쓴다는 실패는 어떤 신호로 조기 발견할 수 있는가.
• 160회 중 1회 의미 있는 사용이 강화학습 가능성의 증거가 되는 근거는 무엇인가.
• 메모리 부족 결과를 제외하면 편향이 생긴다면 그 편향의 방향은 추정할 수 있는가.
• 필자 스킬이 최고점인데 의도대로 작동하지 않았다면 그 점수는 무엇을 측정한 것인가.
• 회문 입력 때문에 뒤집힘 버그를 놓친 사례는 테스트 생성에 어떤 규칙을 추가하게 하는가.
• 스킬이 튜토리얼이 아니라 기본 행동 수정문이어야 한다는 처방은 어떻게 검증되는가.
• 모델 세대마다 프롬프트가 달라진다면 스킬의 유효 기간은 어떻게 관리해야 하는가.
• 에이전트가 스킬을 쓰는 데 형편없는데 모두가 에이전트로 스킬을 쓴다는 지적은 어떻게 끊을 수 있는가.
• 충분히 프라이밍되면 지식이 실행된다는 가설은 프라이밍의 최소 형태를 어떻게 규정하는가.