Huzzah, 프롬프트를 파일로 남기는 코딩 실험

채팅 프롬프트의 피로가 도구 실험을 낳았다

Daniel Vaughn의 Huzzah 글은 2026년 코딩 에이전트 붐 이후 개발자가 느끼는 피로를 정면으로 다룬다. 저자는 긴 영어로 매번 변경 사항을 설명하는 방식에 지쳤지만, 다시 모든 코드를 손으로만 쓰고 싶지도 않다고 말한다. 그래서 Huzzah라는 실험적 편집기를 만들고 있다.

Huzzah의 제안은 단순하다. 프롬프트를 길고 명령형이며 일회적인 채팅 메시지로 두지 말고, 짧고 선언적이며 지속되는 의사코드 파일로 남기자는 것이다. 예를 들어 fizz buzz를 만들 때 채팅창에 "100번 반복하고 3이면 fizz"라고 설명하는 대신 fizz_buzz.hz 파일에 의도를 의사코드로 적는다. 수정도 채팅 후속 메시지가 아니라 파일 diff로 표현한다.

의도 기록이 코드 리뷰의 새 재료가 된다

AI 코딩에서 가장 큰 손실 중 하나는 "인간이 무엇을 원했는가"의 기록이다. Git에는 결과 코드가 남지만, 프롬프트는 세션 안에 흩어지고 시간이 지나면 사라진다. Huzzah는 이 의도를 저장소 안의 파일로 남기는 쪽에 가깝다. 이는 문서, 테스트, 코드 사이의 네 번째 축이 될 수 있다.

OpenChamber, 에이전트 개발환경의 작업장 전쟁이 에이전트 작업장의 형태를 다뤘다면, Huzzah는 작업장의 입력 언어를 바꾼다. Claude Code 자동모드 기본값, 권한 피로의 전환점이 권한 승인 피로를 보여줬듯이, 사용자는 에이전트에게 계속 말하는 일 자체에 지치고 있다. Huzzah는 자연어 채팅을 줄이고, 사람이 설계한 압축된 의도를 반복 사용하려 한다.

선언형 의사코드는 만능 언어가 아니다

Huzzah 글은 장점만 말하지 않는다. 저자는 새 코드베이스에 더 적합하고, 도메인 전문성이 없으면 자연어가 더 쉬울 수 있으며, cross-file dependency 같은 문제를 신뢰성 있게 표현하기 어렵다고 인정한다. 이 솔직함이 오히려 중요하다. 코딩 에이전트 도구는 자주 "완전 자동화"를 약속하지만, 실제 병목은 사람이 문제를 얼마나 잘 모델링하느냐다.

의사코드는 사람이 설계를 더 선명하게 만들 때 효과적이다. 하지만 제품 요구가 모호하거나 레거시 코드의 암묵적 제약이 많으면, 짧은 의사코드가 오히려 위험할 수 있다. Docker Sandboxes, 코딩 에이전트 격리를 제품으로 꺼내다처럼 실행 격리와 테스트 하네스가 같이 있어야 한다. 의도 파일만으로 품질이 보장되지는 않는다.

외부 맥락도 연결된다. CRDT 기술 소개는 분산 상태를 명시적으로 모델링하는 예로 자주 언급되고, Huzzah 글도 언어 독립 의사코드가 복잡한 알고리즘의 기반이 될 수 있다고 말한다. GitHub Copilot 문서는 채팅과 IDE 보조를 중심에 둔다. Anthropic Claude Code 문서는 터미널 에이전트 흐름을 설명한다. Huzzah는 이 주류 흐름과 달리 "대화"보다 "파일"을 인터페이스로 밀어붙인다.

한국 팀에는 스펙과 코드 사이의 빈칸을 묻는다

한국의 SI, SaaS, 내부 플랫폼 팀에서 AI 코딩의 어려움은 모델 성능만이 아니다. 요구사항 문서는 길고, 코드 리뷰는 바쁘고, 프롬프트는 개인 PC와 세션 안에 묻힌다. Huzzah식 접근은 최소한 한 가지 질문을 던진다. "우리가 AI에게 맡긴 의도를 저장소에서 재현할 수 있는가?"

이를 그대로 도입하지 않아도 실천은 가능하다. 기능마다 intent.md, acceptance.md, test-plan.md처럼 짧은 의도 파일을 두고 에이전트가 이를 먼저 읽게 할 수 있다. PR에는 생성된 코드뿐 아니라 의도 파일 diff를 포함할 수 있다. 그렇게 하면 AI가 만든 변경의 품질을 결과 코드만이 아니라 원래 계약과 비교할 수 있다.

자주 묻는 질문

Q1: Huzzah는 새 프로그래밍 언어인가요?

A: 현재로서는 실험적 편집기와 의사코드 기반 워크플로에 가깝다. 핵심은 특정 문법보다 지속되는 프롬프트 파일이라는 발상이다.

Q2: 자연어 채팅보다 항상 낫나요?

A: 아니다. 모호한 탐색, 질문, 레거시 이해에는 채팅이 더 편하다. 반복 구현과 명확한 구조에는 의사코드가 유리할 수 있다.

Q3: 팀 협업에 도움이 되나요?

A: 가능성이 있다. 의도가 파일로 남으면 리뷰, 히스토리, 테스트와 함께 비교할 수 있기 때문이다.

Q4: 기존 코드베이스에도 적용할 수 있나요?

A: 적용은 가능하지만 어렵다. 이미 존재하는 암묵적 규칙과 cross-file 의존성을 의사코드로 표현해야 하기 때문이다.

Q5: 실무에서 당장 해볼 수 있는 것은 무엇인가요?

A: 큰 기능 하나를 고르고 구현 전에 짧은 의도 파일과 수용 기준을 저장소에 넣은 뒤, 에이전트가 그 파일을 기준으로 작업하게 해보는 것이다.