본문은 LLM을 '두뇌', 하네스(Harness)를 '몸'에 비유하며, 에이전트 개발 시 직접 구현하는 것이 중요함을 강조합니다. 복잡한 기존 에이전트를 따라 하기보다, 사용 경험에서 느낀 불편함부터 해결책을 고민하고 새로운 접근 방식을 시도해야 합니다. 특히 핵심 로직은 직접 코딩하여 이해도를 높이는 것이 가장 효과적입니다.
핵심 포인트
에이전트 개발은 기존 구현 모방보다 문제 정의와 새로운 접근 방식이 중요합니다.
완전히 자율적으로 작동하는 에이전트가 높은 가치를 지닙니다.
핵심 로직(주 반복문, 도구 호출 함수)은 직접 코딩하여 이해도를 높여야 합니다.
LLM과 하네스의 상호작용을 깊이 이해하기 위해 직접 간단한 하네스를 만들어 보는 것을 권장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
직접 하네스를 만들 때 다른 에이전트를 따라 하기보다, 기존 에이전트를 쓰면서 겪은 불편을 어떻게 해결할지부터 고민했음. 의외로 간단한 해결책이 많지만 각각 대가가 따름. 내 경우 일반적인 에이전트보다 추론을 더 많이 수행하는 대신 여러 문제를 해결하는 쪽을 택했음.
하루 종일 프롬프트를 조정해야 하는 에이전트보다, 일을 맡기고 몇 시간 뒤 돌아오면 해답이 나오는 완전 자율 에이전트가 훨씬 가치 있음. 기존 구현을 조금씩 바꾸기보다 새로운 접근을 시도해야 함. 맥락 압축의 수천 번째 변형을 만드는 대신, 애초에 그런 문제가 생기지 않도록 맥락을 구성하는 방법을 다시 생각해 볼 수 있음.
이제 많은 용도에서 하네스를 직접 만들기가 아주 쉬워졌고, 만드는 과정에서 배울 것도 많음. 혼자 개발하면서 Claude나 다른 복잡한 하네스의 권한과 제한을 일일이 파악하고 싶지 않았음. 프로젝트 디렉터리 안의 파일을 읽고 쓰고 수정하는 기능만 필요했음.
내 프로젝트에 쓸 만큼 완성할 수 있는지 사흘을 잡고 시작했는데, 하루도 안 돼 사용 가능한 수준에 도달했음. 어떤 제한이 있고 어떻게 강제되는지 정확히 알아서 쓰기 편함. 기능이 더 필요하면 직접 추가하거나, 무엇을 살펴야 하는지 더 잘 이해한 상태에서 복잡한 하네스를 고를 수 있음.
모델이 아무리 똑똑해도 상관없다는 게 맞을까? 더 지능적인 모델은 하네스 의존도가 낮다고 얼핏 들었음. 아직 자세히 알아보는 중이지만, 지금 같은 하네스 엔지니어링은 일시적으로만 필요할 것으로 예상했음. Opus 5.5를 여러 하네스에서 자유롭게 실행해 보면, 일화적 수준이나마 시험이 되지 않을까?
LLM은 오븐, 하네스는 주방이라는 비유가 더 적절함. 밀가루, 물, 소금, 설탕 같은 재료를 준비해 오븐에 넣으면 케이크나 빵이라는 완성품으로 변환해 줌.
굽기는 단일 작업이지만, 하네스와 LLM의 상호작용은 지속적인 과정이 될 수 있음. 하네스가 LLM을 얼마나 다양하게 조작하고 변형할 수 있는지는 아직 겉만 살펴본 수준이라고 봄. 시작한 지 불과 몇 년 만에 최상의 인터페이스를 우연히 발견했을 가능성은 낮아 보임.
LLM과 하네스의 관계는 Krang과 그 안드로이드 몸체의 관계에 해당함.
어설픈 비유로 가득한 AI 생성 설명을 읽기보다 기본 코딩 하네스를 처음부터 직접 만들어 보는 것을 권함. 배우는 게 훨씬 많음.
Thorsten Ball이 18개월 전에 쓴 글이 좋은 출발점임. LLM 기준으로는 오래됐지만 사람이 쓴 훌륭한 글이고 핵심을 잘 전달함. Go가 읽기 불편하면 예제를 LLM으로 Python 등으로 바꿔도 됨. https://ampcode.com/notes/how-to-build-an-agent.
글처럼 API 키를 쓰는 대신 도구 호출이 가능한 Qwen 27B 같은 로컬 모델을 사용할 수도 있음. 최신 고성능 LLM을 학습과 기본 코드 작성에 활용하되, 주 반복문과 도구 호출 함수 같은 핵심은 직접 작성하도록 유도해 달라고 요청하는 편을 권함. 까다로운 개념을 체득하는 데 손으로 코딩하는 과정은 여전히 유용하며, 핵심 로직까지 LLM에 맡기지 않는 절제가 필요함.
이렇게 에이전트의 내부 동작을 이해한 뒤 추론 엔지니어링과 LLM 내부 구조로 더 깊이 들어갈 수 있음. 돈이 될지는 모르지만 적어도 배우는 과정은 즐길 수 있음.
장난감 수준의 하네스라도 직접 만들어 보는 것을 적극 권함. HN에서도 자주 혼동하는 개념들이 많이 명확해짐.
브라우저에서 실행하는 JavaScript 하네스를 만드는 간단한 영상을 제작했음. 브라우저 콘솔에서만 실행하던 상태에서 페이지 내 상호작용을 지원하고, 자기 자신의 다운로드 가능한 사본까지 만들도록 확장하는 과정임. 도움이 됐다는 사람이 여럿 있었음.
.
다만 직접 만들고 나면 기존 업체의 하네스에서 훨씬 더 많은 결함이 눈에 들어오기 시작함.
LLM 하네스 보안 강화에 관한 좋은 글이나 문서가 있을까?
현재 Claude는 인증 토큰이 전혀 없는 컨테이너에서 실행하고, 별도 게이트웨이 컨테이너가 토큰이 필요한 요청을 가로채 토큰을 삽입하도록 구성했음. AWS 요청은 가로채서 서명하며, 방화벽으로 접근 가능한 호스트도 소수의 알려진 곳으로 제한함.
추측과 시행착오에 많이 의존하고 있어 모범 사례를 알고 싶음. 검색하면 LLM 활용이 막 시작되던 2025년 자료만 나오는 듯함.
이런 정보는 AI Engineer와 Claude의 YouTube 채널에서 가장 많이 얻음. 효과적으로 하네스를 설계하려면 모델별 상세 프롬프트 가이드도 읽어야 함. 모델 버전이 바뀔 때마다 하네스 최적화도 필요한 시점으로 돌아왔음.
지금 구성은 적절해 보임. 요약하면 에이전트를 영특하지만 어린 아이로 보고, 하네스는 아이가 눈치채지 못하게 밀착 감독하는 부모 역할을 맡아야 함.
LLM은 뇌이고 하네스는 몸이라는 구성이 가능하지만, 반드시 그래야 하는 것은 아님. 하네스도 LLM만큼 뇌 역할을 할 수 있음. 하네스에서 할 수 있는 일은 거의 무한하며 시스템 전체의 지능을 원하는 만큼 구현할 수 있음.
여러 LLM 사이의 작업 분배를 Jev 같은 특화 모델에 맡기거나, pyperplan·jupyddl·pddl4j 같은 계획 도구를 사용할 수 있음. 자체 기억 체계도 자유롭게 구현할 수 있으며, 겉으로 드러나는 지능의 상당 부분은 기억이 얼마나 잘 작동하는지에 달려 있다고 봄.
특화 문제에 전통적 머신러닝 모델을 호출하거나 강화학습을 적용할 수도 있음. 여러 지식원이 협업하는 블랙보드 구조, 전방·후방 연쇄와 RETE를 활용한 추론 엔진, 직접 구현한 귀추 추론, 베이즈 추론, 인과 추론도 가능함.
LLM의 가능성을 낙관하지만, 시스템 전체의 지능은 LLM 이상으로 구성될 수 있음. 목적에 따라서는 LLM이 전혀 필요하지 않을 수도 있음.
그렇다면 분산된 지능을 갖춘 문어 같은 몸체가 필요하겠네.
LLM을 뇌에 비유한다면, 매번 팔과 다리가 무엇인지 알려줘야 하는 심한 기억상실증 환자에 가까움. 실제로는 단어나 단어 조각의 벡터를 저장하고 수학적 계산으로 다음에 올 단어나 조각을 예측해 텍스트를 구성함. 출력에 “real”이나 “load-bearing” 같은 표현이 유독 자주 등장하는 것도 좀 줄였으면 함.
흥미로운 건 지난 1년간 AI 에이전트 클라이언트의 발전 대부분이 반복문, 스레드, JSON 배열, 메모리 관리 같은 아주 기본적인 컴퓨터과학 개념의 조합이라는 것임. 맥락 관리도 그중 하나인데, 업계에서는 대단한 돌파구처럼 글을 쓰고 있음.
서버 쪽 LLM이나 벡터 연산이 아니라 에이전트 클라이언트를 게임과 비교하면 비슷한 컴퓨팅 과제가 많아 보임. 게임 개발자의 관점이 궁금함.
다섯 번째 줄의 “Load-Bearing”을 보고 읽기를 멈췄음.
엔지니어가 글쓰기를 외주화하는 것은 자기 콘텐츠에 충분히 신경 쓰지 않는다는 강한 신호임. 글을 잘 못 쓰는 엔지니어도 있다는 반론은 가능하지만, 그렇기 때문에 글쓰기 능력을 키울 가치가 있음.