htmx 사례가 보여준 AI 코딩의 좋은 거리감

아주 작은 버그가 큰 교훈을 준다

Carson Gross의 htmx 에세이는 AI 코딩 논쟁을 추상론이 아니라 hyperscript 버그 수정 과정으로 풀어낸다. 그는 AI에 대해 양가적이라고 말하면서도, 원인 분석과 테스트 생성에서 도움을 받았다고 설명한다. 동시에 AI가 제안한 해결책은 너무 좁거나 불필요한 복잡도를 만들 뻔했다고 지적한다.

사례는 hyperscript 0.9.91에서 fetch 명령의 as JSON이 잘못 바인딩된 문제다. go와 fetch 명령의 공통 파싱 로직을 리팩터링하면서 fetch 뒤의 URL 파싱이 일반 expression을 먹어버렸고, as가 fetch modifier가 아니라 conversion expression으로 해석됐다. AI는 원인을 빠르게 찾았지만, 최종 설계 판단은 유지보수자가 했다.

AI가 잘한 일과 못한 일

AI는 코드베이스를 훑고 회귀 원인을 좁히는 데 강했다. 또 테스트 케이스를 여러 개 만드는 데도 유용했다. 하지만 첫 해결책은 string-like leaf를 먼저 파싱하는 좁은 패치였고, 두 번째 해결책은 parser에 noConversions 플래그를 추가하는 방식이었다. 둘 다 동작할 수 있지만 시스템 복잡도를 늘릴 수 있었다.

hyperscript 저장소, htmx의 Code is Cheap(er) 에세이, recursive descent parser 설명, ACM의 context-sensitive parsing 고전 논의를 같이 보면 이 사례는 파서라는 특수 영역을 넘어선다. 기존 시스템에는 이미 나름의 이상한 규칙과 지역적 관습이 있다. 좋은 수정은 그 관습을 이해하고 최소한으로 건드린다.

바이브 코딩보다 어려운 것

요즘 AI 코딩 담론은 "얼마나 빨리 만들 수 있는가"에 치우치기 쉽다. 그러나 운영 중인 코드에서 중요한 것은 빨리 쓰는 능력이 아니라 덜 망치는 능력이다. 특히 parser, billing, permission, migration, security 같은 영역에서는 새 코드 한 줄이 장기 비용을 만든다.

Claude Code 사고 로그, 감사 추적의 착시는 에이전트가 만든 결과를 나중에 감사하기 어렵다는 문제를 다뤘다. TesterArmy, QA 에이전트가 배포 관문이 되다는 테스트와 검증이 AI 도입의 병목임을 보여줬다. htmx 사례는 그 사이의 실무 감각을 제공한다. AI가 테스트를 늘려줘도 무엇을 바꾸지 말아야 할지는 사람이 알아야 한다.

이 관점에서 시니어 개발자의 역할은 줄어들지 않는다. 오히려 더 선명해진다. AI가 여러 패치를 빠르게 제안할수록, 어떤 패치가 코드베이스의 미래 비용을 낮추는지 판단하는 사람이 필요하다.

한국 개발팀에 필요한 워크플로

한국 개발팀도 AI 코딩 도구를 이미 많이 쓰고 있다. 문제는 도입 여부가 아니라 사용 방식이다. 좋은 기본값은 세 단계다. 첫째, AI에게 원인 후보와 재현 테스트를 만들게 한다. 둘째, 수정안은 기존 아키텍처와 관습에 맞는지 사람이 좁힌다. 셋째, AI가 만든 테스트를 사람이 읽고 누락된 실패 케이스를 보강한다.

Oak, 에이전트 시대 버전관리의 새 실험에서 보았듯 에이전트가 코드 변경을 많이 만들면 버전관리와 리뷰 방식도 바뀐다. 하지만 가장 중요한 원칙은 단순하다. AI가 제안한 복잡도는 공짜가 아니다. 지금 10분을 아끼려고 parser 상태 플래그 하나를 늘리면, 6개월 뒤 회귀와 교육 비용으로 돌아올 수 있다.

좋은 거리감의 기준

이 에세이가 설득력 있는 이유는 AI를 무조건 배척하지도, 맹신하지도 않기 때문이다. 원인 분석, 검색, 테스트 생성은 적극적으로 맡긴다. 하지만 설계의 경계, 책임 범위, 기존 구조와의 적합성은 유지보수자가 판단한다. 이 거리감이 앞으로의 AI 코딩 표준에 가깝다.

Codex 에이전트 업무 경제성의 관점으로 보면, AI 코딩의 손익분기점은 생성 속도가 아니라 리뷰 가능한 변경 단위에 있다. 작은 테스트와 작은 패치, 명확한 실패 재현이 있으면 AI는 생산성을 높인다. 반대로 큰 추상화와 넓은 리팩터링을 무심코 받아들이면 생산성은 기술부채로 바뀐다.

자주 묻는 질문

Q1: AI가 최종 패치를 못 만들었다는 뜻인가요?

A: 아니다. AI는 가까운 답을 제안했다. 다만 기존 구조에 가장 잘 맞는 좁은 수정은 유지보수자의 이해에서 나왔다.

Q2: 테스트 생성은 믿어도 되나요?

A: 보조로는 유용하다. 하지만 테스트가 올바른 행위를 검증하는지, 누락된 회귀가 없는지는 사람이 확인해야 한다.

Q3: 주니어 개발자는 AI를 쓰면 위험한가요?

A: 위험할 수 있지만 금지할 문제는 아니다. 리뷰, 작은 변경 단위, 설명 요구, 테스트 실행을 기본 규칙으로 두면 학습 도구가 된다.

Q4: 시니어 개발자의 역할은 어떻게 바뀌나요?

A: 직접 타이핑보다 설계 경계, 변경 범위, 품질 기준을 정하는 일이 더 중요해진다.

Q5: 팀 규칙으로 무엇을 정해야 하나요?

A: AI 생성 패치는 재현 테스트, 변경 이유, 대안 검토, 롤백 가능성을 같이 제출하게 하는 규칙이 좋다.