AI를 위한 하네스, 사람을 위한 하네스
AX 공유회에서 한 동료가 이런 말을 했다.
“AI를 위한 하네스는 있는데, 왜 사람을 위한 하네스는 없을까?”
이어진 말도 인상 깊었다. 인간도 에이전트 중 하나이고, Claude Code 같은 도구는 인간의 서브에이전트라고 볼 수 있다는 이야기였다. 들으면서 머릿속에서 “와, 그렇게도 볼 수도 있겠구나!” 하는 생각이 들었다. 그러면서 자연스럽게 다음 생각이 이어졌다. 그렇다면 사람을 위한 하네스란 정말 무엇일까.
AI 에이전트는 모델 하나만으로 잘 작동하지 않는다. 아무리 좋은 모델이라도 그냥 던져놓으면 금방 한계가 드러난다. 이전 맥락을 잊고, 도구 호출에 실패하고, 엉뚱한 방향으로 가고, 결과를 검증하지 못한다. 그래서 모델 주변에는 일을 받쳐주는 여러 장치가 붙는다. 이 전체 실행 환경을 하네스라고 부른다.
같은 모델이라도 어떤 하네스를 붙이느냐에 따라 성능이 크게 달라진다는 사실이 알려지면서, 최근에는 모델 자체보다 그 주변의 하네스를 어떻게 설계할지에 대한 관심이 빠르게 커지고 있다. 문제를 단순히 “모델이 멍청하다”로 끝내지 않고, “모델이 잘 작동할 환경을 만들어줬는가”로 다시 묻기 시작한 것이다.
사람(모델) 탓에서 하네스 점검으로
그렇다면 사람은 어떨까. 사람도 목표를 받고, 맥락을 해석하고, 도구를 쓰고, 행동하고, 결과를 관찰하며 다음 행동을 고른다. 그런 의미에서 사람도 하나의 에이전트라고 볼 수 있다. 그런데 사람에게는 이상하게도 하네스보다 의지와 태도를 먼저 요구한다.
- 일을 까먹으면 꼼꼼하지 못하다.
- 미루면 의지가 약하다.
- 집중하지 못하면 태도의 문제다.
- 실수하면 책임감이 부족하다.
물론 개인의 의지와 태도가 중요하지 않다는 말은 아니다. 다만 AI가 원하는 결과를 내지 못할 때 우리는 모델 탓에 머물지 않는다. 어떻게 하면 그 모델이 일을 더 잘하게 만들지를 먼저 고민한다. 사람에게도 같은 태도를 적용할 수 있다. 누군가 잘 해내지 못할 때, 그 사람의 의지나 태도를 탓하기 전에 어떻게 하면 그 사람이 더 잘 해낼 수 있게 도울지를 먼저 묻는 것이다.
모델을 당장 바꾸기 어렵다면 하네스를 바꾼다. 사람도 마찬가지다. 사람의 성격이나 의지를 바꾸는 일은 느리고 어렵다. 하지만 사람을 둘러싼 구조는 비교적 빠르게 바꿀 수 있다.
사람을 위한 하네스의 구성요소
사람을 위한 하네스란 무엇일까. 정의를 단정적으로 먼저 내리기보다, 이미 잘 정리된 AI 하네스의 구조를 빌려와 사람에게 하나씩 비추어보고 싶었다. Akshay Pachaar이 AI 에이전트 하네스를 12가지 구성요소로 정리해둔 글이 좋은 출발점이었다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 프롬프트 구성, 출력 파싱, 상태 관리, 오류 처리, 가드레일과 안전, 검증 루프, 하위 에이전트 오케스트레이션, 도구 범위 전략이다. 이 12가지를 사람에게 하나씩 옮겨보았다. 그러자 사람을 위한 하네스가 막연한 생산성 이야기가 아니라 꽤 구체적인 모양을 갖추기 시작했다.
원글의 도식은 이 12요소를 LLM을 중심으로 세 겹의 동심원으로 정리한다. 가장 안쪽 런타임(Runtime) 층은 모델이 매 턴마다 굴리는 실행 사이클이고, 그 바깥 기능(Capabilities) 층은 모델이 가진 정보와 외부 자원을 다루는 영역이며, 가장 바깥 안전과 확장(Safety & Scale) 층은 그 둘이 무너지지 않게 받쳐주는 신뢰성 영역이다. 이 세 겹을 사람에게 그대로 옮겨보면 다음과 같다.
| 층 | AI 하네스 구성요소 | 사람을 위한 하네스 |
|---|---|---|
| 런타임 (Runtime) | 오케스트레이션 루프 | 하루의 사이클 (계획 → 실행 → 기록 → 다음) |
| 프롬프트 구성 | 작고 분명한 다음 행동, 입력과 기대 결과의 명시 | |
| 출력 파싱 | 회의록의 결정/액션 아이템, 보고서의 한 줄 요약 | |
| 오류 처리 | 회고, 재발 방지 기록, 되돌릴 수 있는 작업 단위 | |
| 기능 (Capabilities) | 도구 | 캘린더, 할 일 앱, 메모 앱, AI 어시스턴트 |
| 메모리 | 작업 일지, 결정 기록, 위키/노트 | |
| 컨텍스트 관리 | 작업 시작 전 짧은 브리프, 마지막에 남긴 진행 메모 | |
| 상태 관리 | 할 일 앱의 오늘/예정 목록, 칸반 보드, 이슈 트래커 | |
| 안전과 확장 (Safety & Scale) | 가드레일과 안전 | 중요한 결정 전 체크리스트, 더블체크 절차 |
| 검증 루프 | 셀프 리뷰, 동료 리뷰, 페어 작업, 모니터링 알림 | |
| 하위 에이전트 오케스트레이션 | 동료·AI·자동화 스크립트에게 일 맡기기 | |
| 도구 범위 전략 | 집중 시간엔 알림 차단, 시간대별 도구 분리 |
표를 펼쳐 놓고 보면 사람을 위한 하네스가 막연한 다짐이 아니라 꽤 구체적인 설계 대상이라는 게 보이기 시작한다. 나는 최근에 오픈클로를 내 삶에서 다양한 형태로 활용하고 있었는데 이 구성요소에 기반해서 AI와 함께 나를 위한 하네스 중에 어떤 부분이 잘 되어 있고 어떤 부분이 부족한지 알 수 있었다. 자연스럽게 내 하네스를 지속적으로 어떻게 평가하고 개선할 것인지에 대한 고민도 함께 하게 되었다.
사람을 바꾸기 전에 조건을 설계하라
우린 직접 AI의 모델을 변화시키기는 어렵다는 것을 잘 알고 있다. 그렇기에 하네스라는 환경을 통해서 AI가 일을 더 잘할 수 있도록 노력한다. 사람도 마찬가지다. 나의 능력을 발전시키기 전에, 나의 능력을 잘 발전시킬 수 있는 하네스는 무엇인지를 고민하는 태도가 중요하다고 생각한다.
좋은 하네스는 사람을 통제하지 않는다. 사람이 잘 해낼 수 있는 조건을 만들어줄 뿐이다.
좋은 하네스는 모델을 지나치게 통제하지 않고, 모델이 자율적으로 행동하면서도 목표를 잃지 않도록 해준다. 인간을 위한 하네스도 통제가 아니라, 인간의 장점과 자율성을 보존하면서 목표를 잘 달성할 수 있도록 돕는 형태가 되어야 할 것이다.