LLM을 채팅창 밖으로: 유닉스 철학 기반 에이전트 하니스 설계론 'Ambiance' 공개

하니스 개발할 때 제일 도움됐던 건 결국 단순화임. 의심스러우면 제거하고 다듬고 최소화하는 거밖에 답이 없더라. 지름길은 없음

이 글에서 unix 개념을 매핑한 방식 좋다. LLM은 이미 unix에 익숙한 존재잖아. 나도 k8s 프리미티브로 비슷한 이벤트 드리븐 워크플로우 실험 중인데 이거 참고할 만함

그냥 Claude Code나 Codex 로컬에서 쓰면 되는 거 아님? 이게 왜 필요한지 진짜 모르겠음

이건 오픈소스고 폴링 대신 파일시스템 이벤트에 반응하는 구조라 다름

다들 몇 달째 같은 고민하고 있는 듯. 결국 모든 에이전트는 덜 뛰어난 Claude Code일 뿐이라고 봄. 컨텍스트 윈도우가 무손실로 1억~10억 토큰급이면 bash랑 r/w만 줘도 뭐든 다 해결될 거임

포인트는 어떤 에이전트를 써야 하냐가 아니라 에이전트가 성공할 수 있는 자연스러운 하니스가 뭐냐임. 지금도 에이전트들 자율적으로 일 처리하는데 왜 굳이 Claude Code가 다 해줘야 함?

나는 결정론적 스캐폴드를 믿는 편임. 코드가 많을수록 좋고, 테스트 돌리고 실패 진단하고 수정하는 루프 전체를 진짜 코드로 짜고 LLM은 엣지케이스 판단할 때만 불러야 함

100% 동감. ACM 블로그 글 'Manual Work is a Bug'가 딱 이 얘기임. 사람과 LLM이 뭘 해야 하는지 보고 그걸 스크립트/툴로 만든 다음 시스템에 엮는 게 맞음

여기서 신성모독 소리 들을지도 모르지만 이런 결정론적 워크플로우는 langgraph가 진짜 잘하는 영역임

나도 완전 결정론적 코드파 임. 장시간 작업 성공은 다 에이전틱 하니스(cc, codex-cli 등)를 결정론적 워크플로우와 게이트로 감싸는 데서 나왔음. 이 외곽 레이어에 이름이 필요한데 flow engineering이나 agentic exoskeleton 정도로 부를 만함

줌아웃해서 소프트웨어 엔지니어링 바깥으로 나가면 자동화하기 훨씬 어려워지는 영역이 많아서 꼭 대립하는 얘기는 아니라고 봄

나는 코드 테스트에 노력을 많이 쏟는 정책 씀. 코드랑 테스트 LOC 비율이 거의 1:1임. task.md 파일에 체크박스로 작업 관리하고, chat_log.md에 유저 메시지 전부 저장해서 의도 정렬이랑 상태 복구에 씀

에이전트 시대엔 BDD가 더 중요해진 것 같음. 행동을 기술하니까 툴들이 올바른 동작을 더 쉽게 익힐 수 있음. Gherkin 스타일 테스트도 떠오름

내가 만드는 에이전트 프레임워크의 목표도 정확히 이거임. 정의되었든 발견되었든 자동화 프로세스를 최대한 metal쪽으로 내리는 게 메타 프로세스임. 버그픽스 티켓 끝나면 LLM은 커밋 명령어도 안 보고 그냥 JSON 필드에 커밋 요약만 채워넣게 함

prompt랑 code 사이를 부드럽게 옮길 방법이 있어야 한다고 생각함. code로 가면 결정론적이고 빠르고 저렴해지고, 반대로 가면 시스템 확장이나 전제조건 완화할 때 씀. 이 비전으로 직접 뭔가 만든 건 내 실험 말곤 못 봤음

'하니스'라는 단어 요즘 다들 왜 쓰는 거임? 우리 다같이 암벽등반 하는 거 아니잖아

AI의 강력한 힘을 우리 인간들이 어떻게든 억눌러야 하니까 그런 거지

framework는 이제 너무 90년대 느낌이라 그럼

우린 야수를 조련하고 있는 거임

harness 말고 bridle이 더 맞는 단어인데 아는 사람이 별로 없음. 근데 사람들 애기랑 반려동물한테도 harness 씌우잖음

결국 하니스란 건 파일 읽고 인터넷 연결하는 API 노출하는 소프트웨어일 뿐임. LLM 출력에서 tool call 파싱해서 명령 실행하고 결과를 다시 LLM 입력에 넣는 게 전부임