에이전트 하네스를 직접 만드는 개발자들, 왜 자기 도구로 돌아오나

해커뉴스에 "커스텀 하네스를 쓰고 있나"라는 질문 글이 올라와 개발자들의 자작 도구 경험이 모였다. 여기서 하네스는 LLM이 프로젝트 디렉터리의 파일을 읽고 고치며 시스템 명령을 실행하도록 감싸 주는 실행 계층을 뜻한다. 상용 코딩 에이전트의 CLI나 플러그인이 대개 이 역할을 맡지만, 이 글의 작성자는 그 자리를 직접 구현하는 쪽을 택했다.

글을 올린 japhyr는 에이전트 워크플로 도입이 늦었던 이유로 신뢰 문제를 들었다. 남이 만든 도구가 어디까지 손을 뻗는지 경계를 확신하기 어렵고, 그 권한 체계를 익히는 데 시간을 쓰고 싶지 않았다는 것이다. 그래서 프로젝트 디렉터리 안에서 파일을 읽고 쓰고 수정하는 수준의 하네스를 직접 만들었는데, 예상보다 훨씬 수월했다고 한다. 지금은 거의 매일 쓰지만 첫 버전에서 크게 늘어나지는 않았다고 덧붙였다. 직접 만들어 쓰는 사람이 얼마나 되는지, 무엇이 계속 쓰게 만드는지가 그가 던진 질문이다.

응답은 크게 세 갈래였다. 동작 원리를 익히려고 만들어 봤다는 쪽은 학습용 결과물을 GitHub에 공개했다(devoidfury/hotdog). 오랫동안 자체 하네스를 다듬어 왔다는 개발자는 로컬 모델에 맞춰 최적화하면서도 계정이 있는 외부 API로도 전환할 수 있게 설계했다고 설명했다. 현재는 한 제공자만 지원하지만 구조 자체는 다른 제공자와 로컬 모델을 붙일 수 있게 잡아 두었다는 점을 강조했다. 특정 회사의 모델이나 하네스에 묶이지 않는 것이 만족스럽다는 이유다.

기존 도구에 대한 불만도 나왔다. ravenstine은 쓰는 하네스마다 결국 싫증이 난다며, 지금은 OpenCode에서 벤더 종속적인 부분과 쓰지 않을 기능을 걷어내 최소 구성으로 만드는 중이라고 했다. 그 구성이 안정되면 핵심 동작을 파악해 Rust로 다시 구현하겠다는 계획도 밝혔다. Homebrew로 설치했더니 의존성이 잔뜩 딸려 오면서 컴파일까지 오래 걸리고 결국 멈춰 버렸다는 경험도 함께 털어놨다. 텍스트를 읽어 LLM에 넘기고 명령을 실행하는 일이 이렇게 무거워야 하느냐는 것이 그의 문제의식이다.

용어 자체가 정리되지 않았다는 지적도 있었다. mattbrewsbytes는 하네스가 계획 모드나 병렬 에이전트 루프까지 포함하는 개념인지, 클라이언트가 스스로 판단해 움직이면 그것도 하네스인지 물었다. 결과를 마크다운 파일로 남기면 자기 학습 하네스가 되는 것인지도 애매하다고 짚었다. 업계가 용어를 정의하는 속도가 실제 변화 속도보다 빠르다는 관찰이 붙었다.

배경에는 코딩 에이전트가 실무 기본 도구로 자리 잡으면서 생긴 두 가지 긴장이 있다. 하나는 권한과 파일 접근 범위를 어디까지 신뢰할 것인가, 다른 하나는 모델과 도구를 특정 공급자에 묶이지 않고 갈아탈 수 있는가다. 자작 하네스는 이 두 문제를 동시에 건드리는 선택지로 등장한다. 터미널 환경을 그대로 쓰면서 제공자만 바꿔 끼우고 싶은 수요가 oh-my-pi 같은 도구를 상시 사용한다는 응답으로도 드러난다.

개발자 입장에서 이 글의 실용적 함의는 하네스가 생각보다 얇은 층이라는 점이다. 파일 읽기·쓰기와 명령 실행, 모델 호출을 잇는 최소 루프만으로도 매일 쓸 도구가 된다면, 필요한 기능만 남기고 나머지를 걷어내는 편이 유지보수에 유리할 수 있다. 반대로 말하면 권한 제어, 샌드박싱, 오류 복구처럼 상용 도구가 감당하던 부분을 직접 떠안게 된다는 뜻이기도 하다.

다만 이 논의는 소규모 스레드에 모인 개인 경험 이상으로 확장하기 어렵다. 하네스의 정의에 합의가 없고, 자작 하네스의 성능이나 안전성을 비교한 수치도 제시되지 않았다. 로컬 모델 최적화, Rust 재구현 계획, 제공자 추상화 같은 언급은 모두 각자의 환경에서 나온 계획이거나 진행 중인 이야기다.