검증 부채: AI 생성 코드의 숨겨진 비용

Source: Hacker News

6분 읽기
방금

Source: …

Introduction

코드를 쓰는 방법을 잊어버렸다고 생각합니다. 아니면 적어도 그렇게 생각합니다. 확신하기는 어렵습니다—한동안 코딩을 해본 적이 없으니까요. 그런데 문득 생각해봅니다: 언제 마지막으로 새 서버를 랙에 올리고 Linux를 설치했나요? 물리적인 과정을 Terraform 한 줄로 줄일 수 있다면, 코딩이 왜 신성해야 할까요?

어쨌든, 저는 아직 코드를 읽을 수 있습니다. 그리고 문서도 읽을 수 있습니다. 그리고 계획도 읽을 수 있습니다. 그 양은 어마어마하고, 때때로 그 내용에 주의를 기울이기도 합니다. 대부분은 화면에 있는 큰 “I’m accountable” 버튼을 누르기 위해서일 뿐입니다(적어도 제가 상상하는 바는 그렇습니다).

“I, Lars Janssen, hereby certify that I asked at least two LLM agents to rip the submitted change to shreds in the name of review.”

거의 모든 주제에 대해 보고서를 요청하는 것은 쉽습니다. 실제로 그 보고서를 읽는 것은 또 다른 문제죠.
하지만 가끔은 구조를 파고들어 코드를 꺼내고, 서로 다른 봇 파벌이 만든 결과물을 이해해야 할 때가 있습니다. 저는 최종적인 미감의 심판자입니다. 온라인에서 수많은 자전거 논쟁이 모델에 녹아들었기 때문에, “좋은” 것이 어떤 모습이어야 하는지는 저보다 모델이 더 잘 알 수도 있겠죠.

그게 10년이 끝날 무렵 우리가 도달할 모습일까요? 몇 달 전만 해도 그 미래는 편안하게 멀리 느껴졌습니다. 그런데 무언가가 변했습니다.

지금은 열광자들이 빠져나올 수 없습니다. 책상에서 일어나면 최소 두 개의 에이전트를 띄워 두고, 그들이 생각하고 명령을 수행하도록 해야 합니다. 화장실에 있을 때조차 토큰을 소모하지 않으면 생산성이 떨어지는 겁니다. 한편, 회의론자들은—그럴 만한 이유도 있긴 하지만—AI가 자신들의 속도를 늦춘다고 불평합니다. 그들은 스스로 하면 더 빠를 수 있다고 주장하죠.

두 진영 모두 옳습니다. 오늘날 실제로 느끼는 바는 다음과 같습니다:

• 에이전트가 10분 만에 인상적인 diff를 만들어 줍니다. 하지만 그 후 한 시간을 들여 나중에 문제가 될 수 있는 부분을 놓치지 않았는지 확인합니다.
• 컨텍스트가 사라집니다. 200 000 토큰은 관대하게 들리지만, 에이전트가 대화를 압축하기 시작하면 10분 전의 합의를 잊어버립니다.
• 출력이 지나치게 장황합니다. 집중된 변경을 요청하면 원하지 않는 논평과 불필요한 리팩터링이 포함된 논문 수준의 결과물이 나옵니다.
• 도구 통합은 엇갈립니다. 어떤 MCP는 뛰어나지만, 다른 것은 누군가가 봉투 뒷면에 API 문서를 낙서해 놓고 모델이 나머지를 알아내게 한 듯합니다.

그럼에도 불구하고, 무언가가 변했습니다. 이제는 그것이 작동하는지에 대해 논쟁하지 않습니다. 어떻게 작동하는지에 대해 논쟁하고 있습니다.

파티 트릭에서 프로덕션으로

몇 년 전, ChatGPT가 등장했을 때 세계는 잠시 감각을 잃었습니다. 당시 블로그 포스트에서 나는 이를 **“상자 안의 뇌”**라고 불렀습니다 — 강력한 추론, 연결성은 제로. Apple이 네트워크 없이 iPhone을 출시했다고 상상해 보세요. 인상적인 기술 시연이지만 실제 작업에는 쓸모가 없습니다. 스니펫을 복사‑붙여넣기만 할 수 있었고, 그게 전부였습니다.

작년에는 도구들이 어느 정도 따라잡았습니다. 자동완성이 에이전트 기반 워크플로우의 시작을 알렸습니다. 하지만 여전히 투박했습니다 — 연결성이 제한적이고, 접근성이 좋지 않았으며, 모델은 당신이 눈을 떼는 순간 금방 스스로 떠돌아다니기 시작했습니다.

무엇이 바뀌었을까? 한 번에 여러 가지가 바뀌었습니다.

1. 더 나은 모델. 완벽하지는 않지만, 에이전트에게 실제 작업을 부여하고 일관된 결과를 받을 만큼 충분히 좋았습니다. 권한 프롬프트를 통과하려면 “예”를 50번 눌러야 했더라도 말이죠. Opus 4.5와 GPT‑5가 등장하면서 회의적이던 사람들도 관심을 갖기 시작했습니다.
2. 성숙한 제품. 대규모 레거시 코드베이스에 접근해 실제로 무슨 일이 일어나고 있는지 파악할 수 있는 터미널 기반 에이전트. 도구와 싸우는 대신 함께 작업하게 만들 만큼 인체공학적이었습니다.
3. 더 숙련된 사용자. 프롬프트 작성은 기술이며, 에이전트 작업 범위를 정의하는 것도 기술, 출력물을 언제 신뢰하고 언제 버릴지 아는 것도 기술입니다.

한 번의 돌파구가 아니었습니다. 더 나은 모델, 더 나은 도구, 그리고 더 경험 많은 사용자들의 복합적인 효과였으며—모두가 동시에 찾아왔습니다. 초기 인터넷처럼, 언제 유용해졌는지 정확한 날을 기억하는 사람은 없습니다. 그저… 그렇게 되었습니다.

도구가 클릭될 때

실제 변화는 더 똑똑한 모델이 아니라, 그것들을 실제 시스템에 연결했을 때 일어나는 일입니다.

제가 Claude Code를 우리 Snowflake 데이터 웨어하우스에 연결했을 때, SQL 작성을 도와주는 깔끔한 도구가 완전한 분석가로 변신했습니다. 그것은 스키마를 스스로 탐색하고, 코드와 Confluence 페이지와 교차 참조하며, 제가 생각조차 못했던 인사이트를 가져왔습니다.

“AI가 코드를 대신 써준다”가 아니라 “AI가 잘 정의된 도구를 통해 실제 세상에서 행동할 수 있다.”
통합이 잘 이루어지면, 에이전트는 화려한 자동완성 기능을 넘어 조사하고, 교차 참조하며, 제안을 할 수 있는 진정한 협업자가 됩니다.
통합이 부실하면, 마치 반쯤은 허구인 거리들로 가득 찬 지도를 인턴에게 건네는 것과 같습니다.

LLM은 이제 더 이상 “상자 안의 두뇌”가 아니라, 세상과 연결되고 있습니다.

검증 부채

모두에게 조용히 떠오르고 있는 사실은 이렇다: 물론 우리는 코드를 덜 쓰고 있다. 하지만 그 대신 검증 작업을 하고 있다는 것이다.

에이전트는 몇 분 안에 그럴듯한 diff를 만들어낼 수 있다. 테스트는 통과한다. 커밋 메시지는 사람이 쓰는 것의 절반보다 낫다. PR은 깔끔해 보인다. 그리고 여기서 함정이 있다 — “맞아 보인다”는 “맞다”와는 다르기 때문이다.

이를 verification debt 라 부른다: 우리가 출력물을 생성하는 속도와 검증하는 속도 사이의 점점 커지는 격차. 완전히 이해하지 못한 diff에 Approve를 클릭할 때마다, 우리는 빚을 지는 것이다…

(The article continues)