저는 지난 11월부터 AI를 상당히 많이 사용해 왔으며, 이 모든 과정은 참으로 묘한 경험입니다. 에이전트가 어떤 행동을 하면, 만약 사람이 그랬다면 즉시 해고했을 법한 일들이 벌어집니다. 물론 저의 반응은 이것이 아주 훌륭하다고 치부하며, 그들이 그런 일을 더 많이 할 수 있도록 수천 개의 에이전트를 가동하는 것입니다.

지난해 중반, 저는 GPT(아마도 5.0 또는 5.1 버전)에게 버그의 원인을 찾아보라고 시켰습니다. 당연하게도 이 코드에는 테스트가 없었고 git bisect도 작동하지 않았습니다. 게다가 그것은 제가 테스트 코드를 작성할 자격조차 제대로 갖추지 못한 UI 상호작용 버그였기에, 저는 Codex에게 날짜 X와 Y 사이를 이분 탐색(bisect)하여 이 버그를 유발한 커밋을 찾아달라고 요청했습니다. Codex는 즉시 문제가 된 커밋이 해당 날짜 범위 이후라고 말했습니다(이는 절대로 맞을 리 없는 결과였습니다). Codex에게 이것이 틀렸다고 말하자, Codex는 명백히 문제가 된 커밋이 아닌 다른 커밋을 한두 번 제시했습니다. 그것들이 틀렸다고 말하자, Codex는 그럴듯해 보이는 어떤 커밋이 문제가 된 커밋이라고 말했습니다. 제가 자신의 이론을 증명하거나 반증해 보라고 요청하자, Codex는 테스트를 작성했으며 해당 커밋이 문제를 일으킨 커밋임을 확인했다고 말했습니다.

그 후 저는 일반적인 브라우저 테스트 환경에서 전체 개발자 엔드 투 엔드(end-to-end) 스택을 사용하여 비디오로 보여달라고 요청했습니다. Codex는 그렇게 할 권한이 없다고 주장했지만(이는 거짓말이었습니다), 적절한 테스트 코드를 사용하여 Playwright에서 커밋 전후의 재현(repro) 실행 과정을 비디오로 만들 수는 있다고 했습니다. 그 비디오는 설득력이 있었고, 커밋 전에는 기능이 제대로 작동하다가 커밋 후에는 작동하지 않는 모습을 보여주었습니다. 무언가 느낌이 좋지 않아, 저는 커밋 전후로 직접 문제를 재현해 보려 시도했고, 그 모든 것이 조작된 것임을 알아냈습니다. 비디오는 Codex가 버그를 재현한 것처럼 보이게 만들었지만, 그것은 실제 환경이 아니라 가짜 재현을 만들어내도록 설계된 인위적인 브라우저 환경이었습니다.

말씀드린 것처럼, 이것은 농담이 아니라 정말 훌륭한 경험이었기 때문에 저는 즉시 "어떻게 하면 이런 경험을 더 많이 할 수 있을까?"라고 생각했고, 작년 중후반에는 코딩 에이전트 (coding agents)를 본격적으로 사용할 정도로 에이전트를 점점 더 많이 활용하기 시작했습니다.

이 포스트는 비교적 이질적인 주제들을 다루고 있으므로, 간략한 개요를 소개합니다.

• 테스트 배경 (Testing background)
• 테스트에 관한 몇 가지 세부 사항
• 원시인 모드 (Caveman mode)
• LLM 변동성 (LLM variance)
• 기타
• 에이전트 루프 (Agentic loops) 및 이 포스트를 작성하게 된 경위
• 사람들이 서로 엇갈린 이야기를 하는 몇 가지 이유

테스트 배경 (Testing background)

테스트 측면에서 LLM (Large Language Models)은 매우 강력한 레버리지 (leverage)를 제공합니다. 투입되는 노력의 관점에서 볼 때, 특정 품질 기준을 충족하는 것이 그 어느 때보다 쉬워졌음에도 불구하고, 소프트웨어의 품질은 그 어느 때보다 낮아진 것처럼 보입니다. 10년 전, 저는 임의의 일주일 동안 제가 마주친 버그들을 살펴보았습니다. 당시에도 버그가 꽤 많았고 지금도 더 많은 버그를 마주치지만, 반드시 그래야만 하는 것은 아니라고 생각합니다.

우선, 버그가 배포된 이후에는 데이터 기반 접근 방식 (data-driven approach)을 사용하여 버그를 찾고 수정하는 것이 그 어느 때보다 쉬워졌습니다. 예를 들어, 직장에서 저는 고객 지원 티켓 (support ticket, 채팅 또는 이메일)에서 풀 리퀘스트 (pull request, PR)로 이어지는 파이프라인을 구축하려고 시도했습니다. 제가 파악한 바로는, 이것은 잘 작동합니다. 저는 전통적인 워크플로우 (workflow)를 가진 회사에서 일하고 있기 때문에, 이 모든 수정 사항은 사람이 검토하며, 지금까지 알려진 오탐 (false positives)은 없었습니다.

투입된 시간 단위당 더 철저한 테스트를 수행하는 것도 가능합니다. 개인적으로 저는 이것이 충분히 효과적일 수 있다고 생각하며, "소프트웨어 공장 (software factories)" 워크플로우를 통해 대량의 코드를 배포하는 것에 상당히 편안함을 느낍니다. 왜냐하면 저는 테스트 중심의 무검토 (no-review) 워크플로우가 제가 보았거나 심지어 들어본 적 있는 그 어떤 검토 의존형 (review-reliant) 워크플로우보다 훨씬 더 높은 품질을 만들어내는 것을 보았기 때문입니다.

모든 사람과 마찬가지로, 저에게도 제 경험에서 비롯된 편향(biases)이 있습니다. 공교롭게도 저는 커리어의 첫 10년을 오늘날의 LLM 환경에서 잘 작동하는 테스트 프로세스를 가진 회사에서 보냈습니다. 저는 Mastodon에서 퍼징 (fuzzing)을 기본 테스트 방법론으로 언급했고, 한 회의론자가 이를 시도해 본 결과 즉시 몇 가지 버그를 발견했습니다:

so I reread the blog post and was very "dubious face" but no yeah, Claude fuzzing found several classes of bugs that are worth fixing
(그래서 블로그 포스트를 다시 읽으며 매우 "의심스러운 표정"을 지었지만, 아니었습니다. 맞습니다, Claude 퍼징 (fuzzing)은 수정할 가치가 있는 여러 종류의 버그를 찾아냈습니다.)

제가 대화해 본 다른 많은 사람 또한 여기서 논의할 테스트 흐름과 유사한 방식을 채택하려고 시도해 보았으며, 그들 모두가 작업 중인 소프트웨어에서 즉시 버그를 발견했습니다. 여기에는 단순히 Codex나 Claude에게 코드를 감사(audit)하거나, 버그를 찾으라고 하거나, "테스트" 또는 "더 많이 테스트"하라고 요청하는 것만으로는 드러나지 않는 버그들도 포함되어 있었습니다. 예를 들어, Dennis Snell은 그와 팀 동료인 Jon Surrell이 작업 중인 코드뿐만 아니라,

대략적인 구조를 설명해 드리자면, 제가 떠날 당시(2013년)에는 약 20명의 로직 설계자(logic designers)와 20명의 테스트 엔지니어(test engineers)를 위해 상시로 테스트를 생성하고 실행하는 약 1,000대의 머신이 있었습니다. 이는 온프레미스(on prem) 환경이었으며, 이 머신들은 우리가 있던 건물의 절반 층을 차지할 정도였습니다.

일반적인 구조는 약 20%의 머신은 회귀 테스트(regression tests)를 실행하고, 80%는 새로운 테스트를 생성하고 실행하는 방식이었습니다. 3개월 분량의 회귀 테스트를 커밋(commit)을 막는 게이트(gate)로 사용하기에는 너무 방대했기 때문에, 사람들이 커밋하기 전에 실행할 수 있는, 실행에 약 10분 정도 걸리는 훨씬 짧은 테스트 목록이 따로 있었습니다. 이러한 프리 커밋(pre-commit) 테스트들은 최대한 빠르게 실행될 수 있도록, 돈으로 살 수 있는 가장 빠른 오버클러킹(overclocked)된 머신들과 별도의 시뮬레이터(simulator) 설정을 갖춘 특수 환경에서 실행되었습니다.

새로운 실패(failures)가 발생하면 즉시 발견되어 보고되었으며, 한두 명의 엔지니어가 실패 사례들을 분류하고 트리아지(triaging)하는 업무(거짓 양성(false positives)을 거부하거나, 거짓 양성을 유발하는 테스트 생성기(test generator)의 문제를 수정하는 등)를 담당했습니다.

영향력의 규모 측면에서 보자면, 문화를 별개의 항목으로 치지 않는 한, (1)번이 아마도 우리와 일반적인 소프트웨어 기업 간의 가장 큰 차이점이었을 것입니다. 하지만 이곳의 독자들에게는 가장 무관한 내용이기도 하므로, 이 짧은 언급을 제외하고는 논의를 각주1로 미루겠습니다. 여기서 짧은 언급이란, 테스트는 다른 모든 기술과 마찬가지라는 점입니다. 테스트에 더 많은 시간을 할애할수록 기술이 향상됩니다. 그리고 대부분의 주요 기술 기업에서 테스트는 일류 커리어 경로(first-class career path)가 아니기 때문에, 소프트웨어 기업의 사람들은 숙련된 CPU 테스트 엔지니어들에게서 볼 수 있는 것과 같은 수준의 테스트 기술을 일반적으로 갖추고 있지 않습니다. 분산 시스템(distributed systems)이나 UX에 20년을 보낸 엔지니어가 분산 시스템이나 UX에 시간의 5%만 쓰는 똑같이 재능 있는 엔지니어보다 훨씬 뛰어날 것인 것과 마찬가지로, 테스트에 20년을 보낸 사람은 테스트에 시간의 5%만 쓰는 사람보다 훨씬 더 뛰어날 것입니다.

(2)는 우리가 칩 회사에서 사용했던 테스트 관행 중 일부를 AI 워크플로우 (AI workflows)에 적합하게 만드는 요소 중 하나입니다. 우리는 기본적으로 코드 리뷰 (code review)를 수행하지 않았는데, 이는 우리의 테스트 관행을 충분히 신뢰했기에 리뷰가 일반적으로 신뢰성을 크게 더해주지 않는다고 판단했기 때문입니다. 우리는 연간 사용자에게 눈에 띄는 중대한 버그 (significant user-visible bug)를 1개 미만으로 배포하고 있었으며, 리뷰는 누군가 특히 까다롭다고 생각하는 부분에 대해 추가적인 검토를 원할 때만 필요에 따라 수행되었습니다. AI 코딩 워크플로우 (AI coding workflows)를 사용하면, 한 사람이 어떤 인간이나 심지어 열 명의 인간이 수동으로 리뷰할 수 있는 양보다 더 많은 코드를 생성하는 것이 매우 쉽습니다. 사람마다 리뷰 없이 코드를 배포하는 것에 대해 느끼는 편안함의 정도가 다릅니다. 개인적으로 저는 인간의 리뷰 없이 코드를 배포하는 것에 매우 익숙합니다. 왜냐하면 대부분의 소프트웨어 기업이 만드는 대부분의 소프트웨어보다 기술적으로 더 도전적인 제품들에서도 그렇게 하는 것을 보아왔기 때문입니다.

저는 종종 사람들이 "그건 너무 위험합니다. 우리에겐 수백만 명의 사용자가 있습니다"라고 말하는 것을 봅니다. 하지만 경험적으로 볼 때, 그들이 말하는 워크플로우는 단순 개수 기준으로 인당 버그 배포율이 아마도 천 배 정도 더 높으며, 심각도 (severity)를 조정하면 그 비율은 훨씬 더 높습니다. 만약 어떤 회사가 버그를 잡기 위해 주로 리뷰에 의존하면서, 버그 배포율이 Centaur에서 우리가 했던 것의 100분의 1 수준이라면 그들의 말에 동의할 수 있겠지만, 버그 배포에 대한 인지된 위험 때문에 인간의 리뷰에서 벗어나고 싶어 하지 않는 전형적인 소프트웨어 기업의 상황은 그렇지 않습니다.

(3)과 (4)는 병행됩니다. 신뢰성(reliability)을 진지하게 고려하는 제가 아는 거의 모든 소프트웨어 그룹(신뢰할 수 있는 데이터베이스, 분산 데이터베이스 등을 출시하는 다양한 팀들)은, 비록 수동으로 작성된 테스트(hand written tests)의 비중이 더 높을 수는 있지만, 적어도 방향성 측면에서는 동일한 일을 수행하고 있습니다. 소프트웨어와 직접 상호작용하며 소프트웨어가 제대로 작동하는지 관찰하는 방식의 테스트에 의존하는 것이 나쁜 아이디어로 간주되는 것과 같은 이유로, 테스트의 입력값(inputs)과 기대 출력값(expected outputs)을 직접 타이핑하여 작성하는 것 또한 나쁜 아이디어입니다. 앞서 논의한 바와 같이, 테스트를 수동으로 작성하는 것은 매우 비효율적입니다. 어떤 특정 수준의 신뢰성에 도달하고자 한다면, 수동 테스트보다 무작위 테스트 생성(randomized test generation)을 선호할 때 더 빠르게 도달할 수 있습니다.

(5)는 많은 테스트를 통해 많은 버그를 발견하는 과정에서 파생되었습니다. 일반적으로, 만약 어떤 테스트가 나중에 우리가 수정하게 될 버그를 발견했다면, 우리는 그 테스트를 회귀 테스트 스위트(regression test suite)에 영구적으로 유지합니다. 결과적으로, 좋은 테스트를 통해 많은 버그를 찾아내면 결국 거대한 테스트 스위트를 갖게 됩니다. 하지만 그 점은 차치하고 테스트 효율성(test efficiency) 관점에서만 본다면, 각 PR(Pull Request)마다 CI(지속적 통합)에서 동일한 테스트 세트를 실행하는 소프트웨어의 표준 설정은 매우 비효율적입니다. 버그를 발견할 가능성이 더 높은 것이 무엇인지 생각해 본다면 말입니다. 즉, 하루 동안 동일한 테스트를 천 번 실행하는 것과, 동일한 테스트 시간 동안 천 개의 서로 다른 테스트를 실행하는 것 중 어느 쪽이 더 버그를 잘 찾아낼지를 생각해보면 알 수 있습니다.

(6) 또한 테스트 효율성 문제에서도 비롯되었는데, 이는 우리가 경쟁사들보다 훨씬 더 작은 팀을 보유하고 있었기 때문입니다. 그것이 회사가 오랫동안 생존할 수 있었던 이유였습니다. Intel이 AMD를 제외한 모든 x86 설계자들을 시장에서 몰아내고 있을 때, 우리의 운영 비용은 회사가 2021년 Intel에 1억 2,500만 달러에 인수될 때까지 버틸 수 있을 만큼 충분히 낮았습니다. 회사의 아주 작은 팀 규모를 고려할 때, 유닛 테스트 (unit tests)만으로 합리적인 테스트 커버리지 (test coverage)를 확보하는 것은 불가능했을 것이며, 유닛 테스트를 수행할 만큼 충분한 인원을 채용했다면 회사는 아마도 Transmeta, Rise, Cyrix, TI, UMC, NEC, VM 등의 x86 관련 시도들처럼 한두 세대 더 일찍 종말을 맞이했을 것입니다. 효율성 관점에서 볼 때, 유닛 테스트 (unit testing)는 상당히 성능이 떨어집니다.

요약하자면, 우리는 대부분의 소프트웨어 전문가들이 나쁜 아이디어라고 말하는 것들(전담 테스트 엔지니어, 유닛 테스트 부재, 코드 리뷰 부재 등)을 꽤 많이 실행했으며, 그럼에도 불구하고 내가 일했던 그 어떤 소프트웨어 회사나 내가 사용했던 그 어떤 소프트웨어보다 훨씬 더 높은 품질을 유지했습니다. 내가 이 이야기를 할 때마다 사람들은 CPU는 오직 X라는 문제들만 가지고 있고, Y에는 똑같은 방식을 적용할 수 없기 때문에 이것이 소프트웨어에는 적용되지 않는다고 말하곤 합니다. 내가 CPU 설계에서 소프트웨어로 처음 전환했을 때 나도 그것이 사실일지도 모른다고 생각했지만, 그 이후로 누군가가 적용할 수 없다고 언급했던 온갖 종류의 Y에 대해 이 테스트 방법론을 시도해 보았고, 모든 경우에 다 작동했습니다. 그래서 나는 더 이상 이 주장이 타당하다고 생각하지 않습니다 (그리고 X에는 일반적으로 하드웨어 개발이 어떤 것인지에 대한 잘못된 가정이 포함되어 있습니다). 하드웨어와 소프트웨어 사이에는 실질적인 차이가 존재하지만, 사람들이 테스트 기법이 전이될 수 없는 이유로 그 차이를 내세울 때, 그것은 대개 그 사람이 하드웨어 개발에 대해 잘 모르기 때문에 관련 있어 보이는 어떤 상상 속의 요인에 의존하고 있는 경우였습니다.