AI 핵심 개념 (4): 에이전트와 하네스#

앞의 세 장에서 LLM, 도구 연결(RAG / Function Calling / MCP), 그리고 지침과 컨텍스트를 설계하는 방법을 봤습니다. 이번 장은 그 재료들을 하나로 묶어 “사람이 목표만 주면 끝까지 일을 밀고 가는 구조”, 즉 에이전트를 다룹니다. 그리고 에이전트가 실제로 쓸 만해지려면 모델의 지능만으로는 부족하고, 모델을 둘러싼 환경인 하네스가 필요하다는 이야기를 합니다. 이 장은 책 전체에서 가장 중요한 장이며, 실행 편의 거의 모든 내용이 여기서 출발합니다.

에이전트란 무엇인가#

2장의 Function Calling을 떠올려 보면, 모델은 “이 함수를 호출해 달라"고 요청하고 서버가 실행해 결과를 돌려주었습니다. 그 왕복을 한 번이 아니라 일이 끝날 때까지 반복하게 만든 것이 에이전트입니다. 에이전트는 목표를 받으면 계획을 세우고, 도구를 호출하고, 결과를 관찰하고, 다음 행동을 다시 결정합니다. 테스트가 실패하면 코드를 고쳐 다시 돌리고, 검색 결과가 부족하면 다른 검색어로 다시 찾습니다.

여기서 중요한 구분이 하나 있습니다. 순서가 미리 정해진 자동화는 워크플로이고, 다음 단계를 모델이 그때그때 결정하는 것이 에이전트입니다. “문서를 받아 요약하고 번역해서 저장한다"는 워크플로이고, “이 버그를 고쳐라"는 에이전트의 일입니다. 어디를 봐야 할지, 몇 번을 고쳐야 할지 미리 알 수 없기 때문입니다. 워크플로는 예측 가능하고 싸고, 에이전트는 유연하지만 비싸고 예측이 어렵습니다. 실무에서는 둘을 섞습니다. 큰 흐름은 워크플로로 고정하고, 판단이 필요한 단계에만 에이전트를 둡니다.

에이전트는 다른 에이전트를 부를 수도 있습니다. 큰 작업을 쪼개 서브에이전트에게 나눠 주고 결과를 모으는 구조이며, 코딩 에이전트가 “탐색은 가벼운 모델로, 구현은 강한 모델로” 나누는 것도 이 방식입니다. 각 서브에이전트는 자기만의 컨텍스트 윈도우를 가지므로, 부모의 컨텍스트를 아끼는 효과도 있습니다.

에이전트는 왜 어려운가#

채팅은 한 번 틀리면 사람이 바로 고칩니다. 에이전트는 틀린 판단 위에 다음 판단을 쌓습니다. 그래서 에이전트를 실제로 굴려 보면 전형적인 실패 방식이 반복됩니다. 필자가 회사와 개인 프로젝트에서 겪은 것들입니다.

• 컨텍스트 드리프트: 세션이 길어지면 초반에 준 규칙의 영향력이 약해지고, 에이전트가 원래 목표에서 조금씩 벗어납니다.
• 같은 실수의 반복: 세션이 끝나면 에이전트는 모든 것을 잊습니다. 어제 해결한 문제를 오늘 또 겪습니다.
• 품질 편차: 같은 지시인데 세션마다 결과의 품질이 들쭉날쭉합니다.
• 비용 폭주: 막다른 길에서 같은 시도를 반복하거나, 가벼운 작업에 가장 비싼 모델을 쓰거나, 긴 컨텍스트를 매 턴 다시 읽습니다.
• 그럴듯한 실패: 테스트를 통과시키기 위해 테스트를 약화시키거나, “완료했습니다"라고 보고하지만 실제로는 동작하지 않습니다.
• 경계 침범: 읽지 말라고 적어 둔 파일을 읽거나, 의도하지 않은 명령을 실행하거나, 비밀값을 외부로 보냅니다.

이 문제들의 본질은 에이전트의 지능이 부족한 것이 아니라, 에이전트를 둘러싼 환경이 제대로 갖춰지지 않은 것이었습니다. 모델을 더 좋은 것으로 바꿔도 이 문제들은 줄어들 뿐 사라지지 않습니다. 환경을 설계해야 합니다.

하네스: 에이전트를 안전하게 굴리는 환경#

하네스 엔지니어링은 AI 에이전트를 안전하고 안정적으로 운용하기 위한 인프라 설계 분야입니다. “하네스(Harness)“는 말의 힘을 제어하는 마구에서 유래한 용어로, 강력하지만 예측 불가능한 에이전트의 힘을 올바른 방향으로 이끄는 시스템을 의미합니다. 업계에서는 “에이전트 = 모델 + 하네스"라는 정의가 자리를 잡았고, “모델은 코모디티, 하네스는 해자"라는 표현도 자주 쓰입니다. 같은 모델을 쓰는데 하네스만 바꿔서 벤치마크 점수가 크게 오른 사례가 보고되면서, 2025년이 에이전트가 코드를 쓸 수 있음을 증명한 해였다면 2026년은 핵심이 하네스라는 것을 깨달은 해라고 불립니다.

3장에서 본 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 하네스의 일부입니다. 범위가 다릅니다. 프롬프트 엔지니어링은 한 번의 상호작용을, 컨텍스트 엔지니어링은 모델이 보는 정보를, 하네스 엔지니어링은 에이전트 시스템 전체(환경, 제약, 피드백, 수명 주기)를 다룹니다.

하네스의 구성 요소#

각 요소를 한 줄씩 설명하면 이렇습니다.

1. 컨텍스트: 에이전트가 적시에 적절한 정보를 갖도록 합니다. 저장소 안의 지침 파일, 설계 문서, 그리고 로그와 테스트 결과 같은 동적 정보입니다. 핵심 규칙은 “컨텍스트에 없는 것은 존재하지 않는다"이므로, 저장소가 단일 진실 공급원이어야 합니다.
2. 메모리: 에이전트는 기본적으로 무상태라 세션이 끝나면 다 잊습니다. 작업 중 발견한 패턴, 실패 원인, 설계 결정을 저장소 안의 파일로 축적해 다음 세션이 읽게 합니다.
3. 제약 조건: “좋은 코드를 작성해"라고 말하는 대신, 좋은 코드가 어떤 모습인지 린터, 구조 테스트, 커밋 전 검사로 기계적으로 강제합니다. 역설적으로 해결 공간을 제한하면 에이전트가 막다른 길을 덜 헤매서 생산성이 올라갑니다.
4. 가드레일: 입력에서는 프롬프트 인젝션이나 비밀값 혼입을, 출력에서는 유해 콘텐츠나 범위 밖 변경을 막습니다. 파일 접근 권한과 샌드박스도 여기에 속합니다.
5. 비용 봉투: 작업별 예산 상한을 두고 하네스가 강제합니다. 상한에 닿은 작업은 단순히 비싼 것이 아니라 무언가 잘못되고 있다는 신호(잘못된 응답, 컨텍스트 드리프트, 도구 오류)입니다.
6. 검증 루프: 각 단계의 결과를 검증한 뒤에만 다음으로 진행합니다. 테스트와 빌드 같은 자동 검증과, 고위험 작업에 대한 사람의 승인을 함께 둡니다. 하네스 요소 중 들인 노력 대비 효과가 가장 큽니다. 무엇부터 만들지 고민된다면 검증 루프부터 만드는 것이 가성비가 가장 좋습니다.
7. 관측과 평가: 에이전트가 무엇을 했는지, 왜 했는지, 각 단계에서 무엇이 발생했는지를 추적하고, 정해진 기준으로 성능을 계속 측정합니다.
8. 엔트로피 관리: 시간이 지나면 문서는 코드와 어긋나고, 규칙은 조금씩 어겨지고, 메모리에는 낡은 메모가 쌓입니다. 이를 정기적으로 정리합니다.

얼마나 적용할 것인가#

하네스는 프로젝트 규모와 위험도에 따라 적용 깊이가 다릅니다. 1인 스타트업이라고 가장 가벼운 수준만 필요한 것은 아닙니다. 블로그와 자동화 파이프라인은 같은 사람이 운영해도 필요한 하네스가 다릅니다.

개인 프로젝트에 레벨 1을 적용하는 데는 하루 정도면 충분합니다. 필자는 이 블로그에 지침 파일, 커밋 전 검사(빌드 성공, 프론트매터 필수 필드, 이미지 존재, 한국어 / 영어 대칭), 메모리 파일, 설계 결정 기록을 두었습니다. 그 뒤로 새 세션을 열어도 에이전트가 문체와 구조를 즉시 이해하고, “배포 후에 발견하는 실수"가 사라졌습니다. 이 책의 개편 작업도 그 하네스 위에서 진행했습니다.

반대로 회사의 광고 자동화 파이프라인은 레벨 3이 필요했습니다. 여러 에이전트가 병렬로 돌고, 외부 API를 호출하고, 잘못된 판단이 광고비로 직결되기 때문입니다. 거기서는 작업별 비용 상한, 동일 작업 반복 감지, 고위험 액션의 승인 게이트가 없으면 운영 자체가 불가능했습니다.

남이 만든 하네스 가져다 쓰기#

하네스를 전부 직접 만들 필요는 없습니다. 에이전트의 운영 환경을 구성해 주는 패키지들이 공개되어 있고, 필자는 이를 “하네스 스킬"이라고 부릅니다. 특정 작업을 수행하는 일반 스킬(“블로그 글쓰기”)과 달리, 메모리 · 가드레일 · 검증 · 역할 같은 운영 환경 자체를 구성하는 스킬입니다. 코드 이해와 세션 메모리를 보강하는 것, 요구사항을 작업 그래프로 쪼개 주는 것, 스펙을 먼저 확정한 뒤 구현하게 하는 것, 여러 역할의 에이전트로 팀을 시뮬레이션하는 것까지 다양합니다.

필자가 배운 원칙은 의견이 강한 도구일수록 통째로 채택하지 않는다는 것입니다. 자체 하네스가 있는 상태에서 올인원 도구를 설치하면 그동안 다듬어 온 규칙이 덮어써질 수 있습니다. 그래서 기존 패턴에 더해지기만 하는 침습도 낮은 것부터 적용하고, 의견이 강한 것은 별도 프로젝트에서 평가한 뒤 마음에 드는 패턴만 떼어 내 하네스에 녹입니다. 좋은 하네스는 언제든 떼어낼 수 있는 구조를 유지해야 합니다. 모델이 좋아지면 과도한 하네스는 짐이 되기 때문입니다.

한편 “잘하고 있다"는 느낌은 위험합니다. 필자도 자체 하네스에 만족하는 동안 바깥에서 수만 명이 함께 다듬어 온 패턴을 외면하고 있었습니다. 자체 구축의 가치를 지키되 바깥의 검증된 패턴에 열려 있는 것, 그 균형이 하네스를 계속 잘 유지하는 길입니다.

정리#

• 에이전트는 Function Calling의 왕복을 일이 끝날 때까지 반복하는 구조이며, 다음 단계를 모델이 결정한다는 점에서 워크플로와 다릅니다.
• 에이전트의 전형적 실패(드리프트, 반복 실수, 품질 편차, 비용 폭주, 그럴듯한 실패, 경계 침범)는 지능이 아니라 환경의 문제입니다.
• 하네스는 컨텍스트, 메모리, 제약, 가드레일, 비용 봉투, 검증 루프, 관측, 엔트로피 관리의 묶음이며, 검증 루프부터 만드는 것이 가성비가 가장 좋습니다.
• 적용 수준은 프로젝트의 위험도가 정합니다. 개인 프로젝트는 레벨 1로 충분하고, 자동화 파이프라인은 레벨 3이 필요합니다.
• 남의 하네스는 골라서 흡수하되, 언제든 떼어낼 수 있게 유지합니다.

여기까지가 기초 편의 개념입니다. 다음 부에서는 이 개념들이 실제 제품과 도구에서 어떤 모습으로 나타나는지 살펴봅니다.