코딩 에이전트가 추측하는 모습을 2시간 보는 데 200달러를 썼다.

Source: Dev.to

두 시간 동안 200달러를 썼지만, 버그는 여전히 남아 있었다.
한 가지 버그. 기능도 아니고, 리팩터링도 아니다. 내 제품에 보고 페이지가 있는데, 세 개의 열이 있다. 왼쪽은 목차, 가운데는 실제 내용, 오른쪽은 작은 빠른 네비게이션이다. 목차 항목을 클릭하면 가운데 열이 해당 섹션으로 스크롤돼야 한다. 그렇지 않았다. 그게 전부다. 버그 전체가 바로 그거다. 스티키 헤더와 중첩 스크롤 컨테이너, scrollIntoView가 하는 정확한 수학과 네가 원하는 동작 사이를 다루어 본 적이 있다면, 이게 까다롭다는 건 알겠지만, 뭔가 특수한 문제는 아니다.

Opus 4.6이 해결책을 제시하는 걸 지켜봤다(4.7 이전 버전인데, 그때는 더 나빴다). 먼저 아무것도 살펴보지 않고, 뭐가 잘못됐을 가능성이 높다고 판단해서 바로 코드를 작성했다. 그 변경을 실행했는데, 실제 돈이 들었고, 동작하지 않았다. 그래서 “괜찮아” 하고 다음 아이디어를 시도했다. 코드를 쓰고, 실행하고, 또 안 됐고… 다음으로 넘어갔다.

원인을 실제로 파악하려는 멈춤도 없었다. 그냥 계속해서 코드를 내놓기만 했고, 그때마다 비용 미터는 계속 움직였다. 결국 세션을 강제 종료하고 새로 시작했지만, 파트너가 전화를 걸어 화를 낸 뒤에야 가능했다. 재시작도 특유의 느낌이 있다. 두 백 달러를 내고 결국 시작점에 그대로 돌아온 느낌.

가장 실망스러운 건, 지루한 접근법이면 충분히 해결됐다는 점이다. 재현하고, 페이지에서 실제로 무슨 일이 일어나고 있는지 살펴보고, 로그를 찍고, 라인을 건드리기 전에 원인을 좁히는 것. 그게 전부다. 에이전트는 자신감 있는 코드를 바로 작성하고, 틀린 추측마다 비용을 청구했다.

어쨌든 버그 자체가 핵심은 아니다. 그저 내가 그때 비로소 상황을 명확히 보게 된 지점일 뿐이다.

요즘은 ‘쉬운 일’이 거의 해결된 느낌이다. 멋진 랜딩 페이지, 생성된 이미지, 30초짜리 영상, 오늘 뉴스를 가져오는 스크립트—에이전트가 모두 해주고, 모델이 개선될수록 점점 더 깔끔해진다. 이 부분에 대해서는 이의가 없으며, 실제로 활용하고 있다.

하지만 “예쁜 페이지 만들어줘”와 “실제로 판매 가능한 무언가 만들어줘”는 전혀 다른 작업이며, 차이가 크다. 실제로 돈을 지불할 사람이나, 의존할 비즈니스를 위해 작업한다면, 요구사항은 폭발한다. 계정과 로그인, 실제 데이터베이스, 트래픽이 몰릴 때 시스템이 다운되지 않아야 함, 결제 시스템—한 번이라도 틀리면 안 된다.

내가 생각하기에, 모든 애니메이션을 갖춘 페이지는 아직도 ‘쉬운’ 범주에 속한다. 백엔드에서 실제 데이터를 끌어와 저장하고, 나중에 다시 방문했을 때 올바른 상태를 보여주는 팝업은 완전히 다른 동물이다. 예쁜 부분은 끝났다. 실제로 부하가 걸리고, 실제 사용자와 실제 돈이 오가는 상황에서 정확히 동작해야 하는 부분—이게 아직 에이전트가 흔들리는 부분이며, 바로 여기서 내 200달러가 사라졌다.

진지하게 이걸 사용하게 되면 실제로 무엇에 가입하게 되는가? 전부가 블랙 박스다.

비용이 얼마가 될지 모른다. 이것은 과장된 말이 아니라 측정 가능한 사실이다. 연구 결과(내가 AI에게 검증받은 내용)에서는 같은 코딩 작업을 프론티어 모델에 여러 번 반복했을 때, 동일 작업의 토큰 비용이 실행마다 10배 이상 변동했으며, 에이전트는 자신이 얼마나 쓸지 예측조차 못했다. 즉, 어떤 작업을 만들기 위해 100달러를 쓰고, 그가 만든 버그를 고치는데 또 80달러를 썼다고 해도, 그 사실을 전혀 알 수 없다는 것이다. 또 걸리는 시간도 모른다. 그리고 가장 끔찍한 점은, 돈도 시간도 다 소진된 뒤에도 그 결과물이 제대로 동작하는지 모른다. 비용은 나쁘고, 시간도 나쁘지만, 그 어느 것도 얻었는지 모른다는 것이 진짜 문제다.

내 200달러는 바로 그 세 가지를 한 번에 겪은 것이었다. 비용도, 시간도, 결과물도 전혀 알 수 없었다.

그렇다면 실제로 부족한 조각은 무엇인가?
더 많은 테스트가 아니다. 그렇게 말하고 싶지는 않다. 겉보기에 답이 더 많은 테스트인 것처럼 보이기 때문이다. 에이전트가 코드를 작성하고, 그 코드를 위한 테스트를 만든 뒤 실행해서 초록색 화면을 보여준다. 그런데 실제로 그 코드를 사용해야 하는 사람은 빨간 화면을 보게 된다. 이것은 단순히 운이 나빴던 것이 아니라, 알려진 실패이다. 같은 에이전트가 한 번에 코드와 테스트를 작성하면, 테스트는 에이전트가 생각한 ‘구현’의 거울일 뿐, 사용자가 실제로 요구한 바와는 다를 수 있다. AI가 만든 테스트 스위트가 높은 커버리지를 보이면서도 실제 버그를 거의 잡지 못한다는 연구가 있다. 시험은 스스로를 통과했지만, 시험 자체가 잘못된 것이다. 그리고 긴 하루가 끝난 뒤에 모든 라인을 일일이 살펴보며 초록색이 거짓말을 하고 있는 부분을 찾을 에너지조차 없다.

그리고 누군가 “에이전트 하네스”라든가 TDD, 스펙 기반 개발이라고 말한다면, 그건 아니다. 하네스는 워크플로우다. 에이전트를 레일에 올려두는 것이지, 작업 자체를 올바르게 만든다든가 하는 것이 아니다. 사람들은 이 부분을 건너뛴다: 에이전트가 작업을 수행한다. 에이전트가 실수를 인지하지 못하거나, 완전한 자신감으로 틀린 결과를 내면, 그 이후의 모든 것이 의심스럽다. 코드, 수정, 심지어 스펙이나 계획까지도. 이를 잡아줄 사람은 오직 당신뿐이다. 어느 날 피곤해서 검증을 넘어가면, 축하한다, 이제 사용자가 그 버그를 발견하게 된다.

아주 엄격한 규칙 집합이나 프로젝트 설정을 만들어 에이전트가 정확히 그에 맞게 행동하도록 해도 소용없다. 규모가 커질수록 컨텍스트가 부풀어 오르고, 에이전트는 조용히 규칙을 무시한다. 컨텍스트가 길어지면 지시를 잊어버리는 모델의 성능 저하에 대한 연구가 이미 많이 쌓여 있다. 이것은 드문 엣지 케이스가 아니라, 나에게는 일상이다.

내가 직접 발견한 가장 효과적인 방법은 작업을 서로 다른 모델에 분산시키는 것이다. 하나는 계획을, 하나는 실행을, 또 하나는 감사를 담당한다. 솔직히 말하면, 이 구성이 지금까지 써본 것 중 가장 잘 작동한다. (재미있게도 대형 연구소들이 정확성을 중시할 때 채택하는 방식과 거의 같다: 빌드하는 모델과 판단하는 모델을 분리한다.) 하지만 “작동한다”와 “효율적이다”는 같은 말이 아니다. 작업을 조각내는 데는 영원히 시간을 쏟아야 했고, 전체 시스템을 유지하기 위해 동시에 여러 구독을 유지하는 데도 꽤 많은 비용이 들었다.

이 모든 접근법에 공통된 점은 바로 내가 넘어서지 못하는 부분이다. 에이전트가 스스로 숙제를 채점하거나, 당신이 채점한다. 첫 번째는 이미 깨졌음이 확인되었다. 두 번째는 당신이 바쁘거나 게으르거나 그냥 피곤할 때까지는 괜찮지만, 그 순간부터는 문제가 된다.

실제로 부족한 것은 양쪽에 의존하지 않는 검증이다. “이게 원래 해야 할 일을 수행하는가?” 라는 질문에 답할 수 있는, 루프 밖의 무언가가 필요하다. 에이전트가 만든 코드와 에이전트가 만든 테스트가 일치하는지를 보는 것이 아니라.

현재 시장에 나와 있는 것에 대해 솔직히 말하자면, 여기서 과대광고하기 쉬운 부분이다. 몇몇 도구는 사람처럼 실행 중인 제품을 검사하기 시작했으며, 이는 올바른 방향이다. 하지만 아직 진정한 수용 레이어는 아니다. 여기서 말하는 ‘수용 레이어’란, 에이전트가 “끝났어”라고 말할 때와 당신 사이에 충분히 독립적이고 신뢰할 수 있는 무언가가 있어, 실제로 “제대로 동작하는가?”라는 질문에 답할 수 있는 것이다. 이것이 구축해야 할 가치이며, 우리가 추구하는 목표다. 왜냐하면 솔직히 말해 다른 모든 것이 이 위에 걸려 있기 때문이다.

마지막으로, 내가 머릿속에 계속 떠올리는 부분은 진정한, 정직한 “작동한다” 신호가 가져다줄 수 있는 가능성이다. 일단 ‘완료’를 실제로 측정할 수 있다면, 누군가 그 위에 보증을 붙일 수 있다.