2026년 상반기, 많은 개발자에게 코딩 에이전트는 하나의 전환점이었다. 손으로 코드를 한 줄씩 쓰지 않아도 될 만큼 도구의 완성도가 올라왔고, 반복적이고 지루한 작업에서 벗어났다는 해방감이 있었다. 그러나 이 흥분은 오래 가지 않았다. 개발자 대니얼 본(Daniel Vaughn)은 자신의 블로그에서, 코드 변경 하나하나를 긴 영어 문장으로 설명해야 하는 방식에 지쳤다고 털어놓는다. 그렇다고 예전처럼 전부 손으로 코드를 쓰는 삶으로 돌아가고 싶지도 않다. 그가 원하는 것은 자동화의 편리함과, 자기 코드가 무엇을 하는지에 대한 통제감을 동시에 갖는 것이다.
이 문제의식에서 출발해 그가 만들고 있는 것이 실험적 에디터 '허자(Huzzah)'다. 핵심 주장은 프롬프트를 다루는 방식 자체를 바꾸자는 것이다. 본에 따르면 기존 코딩 에이전트의 프롬프트는 세 가지 성질을 갖는다. 길고(longform), 명령형이며(imperative), 일회성(transient)이다. 반면 허자의 프롬프트는 의사코드(pseudocode) 형태이고, 선언형(declarative)이며, 지속적(persistent)이다. 대화창에 매번 지시를 던지고 흘려보내는 대신, 코드의 의도를 파일로 남겨 두고 그것을 계속 유지·수정한다는 발상이다.
대화 대신 파일을 고친다
동작 방식을 저자는 FizzBuzz 예시로 설명한다. 코딩 에이전트를 쓸 때는 채팅창에 '100번 반복하는 함수를 만들고, 3으로 나누어지면 fizz를, 5로 나누어지면 buzz를 출력하라'는 식의 긴 문장을 입력한다. 수정이 필요하면 '100번이 아니라 입력받은 숫자만큼 반복하도록 바꿔라'라는 후속 메시지를 다시 보낸다. 만족할 때까지 이 과정을 반복한다. 허자에서는 대신 fizz_buzz.hz 같은 파일을 만들고 그 안에 자기 방식대로 의사코드를 적는다. 파일을 저장하면 허자가 자동으로 실제 코드를 생성한다.
수정 방식도 다르다. 채팅에 새 메시지를 보내는 것이 아니라 그 .hz 파일을 직접 고친다. 저장하는 순간 허자는 파일의 변경분(diff)을 포착해 그것을 LLM에 대한 프롬프트로 사용하고, 영향받는 소스 코드를 다시 생성한다. 즉 사람이 편집하는 대상은 완성된 코드가 아니라 의도를 압축한 의사코드이고, 실제 코드는 그로부터 파생되는 산출물이 된다. 저자는 이 의사코드가 장황한 자연어 프롬프트보다 훨씬 간결하고 읽기 쉽다는 점을 장점으로 든다.
무엇이 달라지는가
이 접근의 실무적 의미는 프롬프트의 '지속성'에 있다. 대화형 도구에서 지시문은 대화 로그에 묻혀 사라지지만, 허자에서는 코드의 의도가 파일로 남아 버전 관리 대상이 된다. 소스 코드가 무엇을 하려 했는지가 별도의 문서가 아니라 코드를 생성한 원본 자체에 담긴다는 것이다. 긴 영어 설명을 반복 입력하는 피로를 줄이면서도, 개발자가 결과물의 방향을 놓치지 않게 하려는 시도로 읽을 수 있다. 저자가 표현한 '케이크를 먹으면서 동시에 가지고 있고 싶다'는 욕구, 즉 자동화의 편의와 통제감을 함께 취하려는 목표가 여기에 대응한다.
다만 저자 스스로 '만병통치약은 없다'며 예외가 존재함을 인정한다. 원문은 그 예외들의 구체적인 목록까지는 제시하지 않지만, 이 도구가 모든 상황에 들어맞지는 않는다는 점을 분명히 한다. 실제로 의사코드에서 코드를 재생성하는 구조는 생성 결과의 결정성(determinism), 부분 수정 시 의도치 않은 영역까지 다시 만들어질 가능성, 사람이 손댄 코드와 생성된 코드의 경계 관리 같은 문제를 안게 된다. 저자의 설명만으로는 이런 지점들이 어떻게 다뤄지는지 확인하기 어렵다.
아직은 실험 단계
허자는 현재 활발히 개발 중이며 실험적 상태로만 존재한다. 저자는 소스 코드와 설치 방법을 공개하고 직접 써 본 뒤 피드백을 달라고 요청한다. 바꿔 말해 이것은 완성된 제품이 아니라 하나의 패러다임 제안이며, 성능 지표나 실사용 사례 같은 검증 자료는 아직 제시되지 않았다. 한국의 실무자 입장에서 지금 당장 도입을 검토할 대상이라기보다는, AI 코딩 도구의 다음 형태를 고민하는 참고점으로 보는 편이 적절하다.
그럼에도 이 실험이 짚는 문제는 현장 감각과 맞닿아 있다. 코드 생성의 편의가 커질수록 개발자가 자기 코드에 대한 이해와 통제를 잃는다는 불안은 이미 널리 공유되고 있다. 채팅형 프롬프트를 코드 곁에 상주하는 선언적 문서로 바꾸자는 발상이 실제로 유효한지는 더 많은 사용과 시간이 답할 문제지만, '프롬프트를 어떻게 다룰 것인가'라는 질문 자체를 다시 꺼냈다는 점에서 살펴볼 가치가 있다.