AI 에이전트 하네스가 뭐지 2026 – 프롬프트보다 실행 계층이 중요한 이유

Posted on by

2026년 5월 27일 Tomasz Tunguz는 Software After AI에서 AI 이후의 소프트웨어 경쟁력이 모델 자체보다 하네스 설계에서 갈릴 수 있다고 썼다. 2026년 6월 1일 GeekNews도 이 글을 소개하면서 하네스를 Context & Memory, Tools & Action, Orchestration & Loop, State & Persistence, Sandbox & Compute, Observability & Governance, Cost & Workflow Optimization의 7요소로 정리했다.

처음 이 말을 보면 살짝 거창하다. 하네스라니, 갑자기 개발자가 말 조련사가 된 것 같고 책상 위에는 키보드 대신 당근이 필요할 것 같다. 그런데 내가 요즘 볼트에서 에이전트 운영 구조를 정리하면서 느낀 건 꽤 단순했다. 하네스는 멋진 프롬프트가 아니라, AI가 실패해도 다시 돌아올 수 있게 만드는 실행 계층이다.

먼저 한 문장으로

AI 에이전트 하네스는 LLM에게 “잘해줘”라고 부탁하는 문장이 아니다. 어떤 맥락을 줄지, 어떤 도구를 열지, 어디까지 실행하게 할지, 실패하면 어디서 재개할지, 로그를 어떻게 남길지 정하는 운영 구조다. 프롬프트가 운전자의 말이라면 하네스는 핸들, 브레이크, 계기판, 안전벨트, 정비 기록까지 포함한 차체에 가깝다.

이 관점이 중요한 이유는 모델 성능이 점점 평준화되기 때문이다. 같은 GPT, 같은 Claude, 같은 Gemini를 쓰는 회사가 늘어나면 “누가 더 좋은 모델을 샀나”보다 “누가 더 좋은 작업 환경을 만들었나”가 차이를 만든다. 같은 엔진을 달아도 브레이크 없는 차로 고속도로에 나가면 그건 자동화가 아니라 심장 박동수 테스트다.

누가 먼저 보면 좋나

이 글은 에이전트 프레임워크 이름이 너무 많아서 어디부터 봐야 할지 헷갈리는 사람에게 맞다. LangGraph, MCP, Claude Code, Codex, Routines 같은 단어를 각각 공부하고 있는데 머릿속에서는 전부 “AI가 뭔가 해주는 것”으로 뭉개진다면, 하네스 관점이 정리 기준이 될 수 있다.

또 개인 자동화가 점점 커지는 사람에게도 필요하다. URL 요약은 잘 되는데 저장 위치가 흔들리고, 블로그 초안은 나오는데 발행 전 검수가 빠지고, 트레이딩 브리프는 생성되는데 stale 데이터가 섞이면 문제는 모델이 아니라 운영 계층일 가능성이 높다.

내가 공부하면서 기준이 바뀐 지점

예전에는 에이전트 md 파일을 잘 쓰면 시스템이 꽤 안정될 거라고 생각하기 쉽다. 역할, 규칙, 출력 형식, 금지사항을 적어두면 AI가 알아서 잘 따라올 것 같은 느낌이 있다. 물론 이건 필요하다. 그런데 장기 작업으로 갈수록 역할 문서만으로는 부족하다.

내 볼트의 AGENTS 운영 기준에서도 하네스는 단순한 역할 설명이 아니다. health check, 자동 재시작, fallback, 상태 저장까지 포함하는 실행 계층으로 정의한다. 에이전트 md는 “누가 무엇을 해야 하는가”를 말하고, 하네스 코드는 “실패했을 때 어떻게 살아남을 것인가”를 맡는다.

이 차이를 Coin HQ 감사 노트에서 더 세게 느꼈다. Coin HQ에는 시트, 시각화, 개별 refresh 스크립트가 있었지만 본부 상태를 감시하고 복구하고 로그화하는 전용 runtime harness가 약했다. 그래서 마지막 실행 시각, 마지막 실패 이유, stale 데이터 여부, 텔레그램 전송 성공 여부를 한 파일에서 바로 확인하기 어려웠다. 기능은 있는데 운영 계기판이 얇은 상태였던 셈이다.

반대로 Blog HQ 쪽은 덜 화려해도 directory, harness, status, run mode가 있었다. 이 비교가 핵심이다. AI 자동화에서 화려한 결과물보다 중요한 건 “오늘 이 시스템이 정상인지 한눈에 알 수 있는가”다. 멋진 대답을 한 번 받는 것과 내일도 같은 품질로 돌아가는 건 완전히 다른 문제다.

하네스 7요소를 내 작업으로 번역하면

Tunguz의 7요소는 추상 개념으로 읽으면 좋은 말 모음처럼 보일 수 있다. 그런데 개인 자동화나 팀 업무에 붙여보면 꽤 실전적인 체크리스트가 된다.

하네스 요소 쉽게 말하면 내 볼트 기준 예시
Context & Memory 무엇을 기억하고 무엇을 불러올 것인가 .claude/MEMORY, 프로젝트 노트, SOP
Tools & Action 어떤 도구로 실제 행동할 것인가 url-summarizer, blog_sheet.py, run-skill.sh
Orchestration & Loop 생각-행동-관찰-반복을 어떻게 돌릴 것인가 /summary, /write, 에이전트 팀 흐름
State & Persistence 중간 상태를 어디에 남길 것인가 runtime state, events jsonl, 리뷰 상태
Sandbox & Compute 어디까지 격리해서 실행할 것인가 no-focus Obsidian 운영, direct write, secret 외부화
Observability & Governance 무엇을 보고 누가 승인할 것인가 lint, preflight, logs, publish gate
Cost & Workflow Optimization AI가 할 일과 코드가 할 일을 어떻게 나눌 것인가 deterministic script 우선, LLM은 판단/요약에 집중

이 표를 보면 하네스는 특정 프레임워크 이름이 아니다. LangGraph를 쓰든, Claude Code를 쓰든, Codex를 쓰든, 로컬 스크립트와 Markdown만 쓰든, 결국 같은 질문으로 돌아온다. “이 AI가 지금 무슨 근거로, 어떤 권한으로, 어디까지 실행하고 있는가?”

프롬프트만 길게 쓰면 왜 부족한가

프롬프트는 AI에게 의도를 전달하는 데 강하다. 하지만 시스템 운영의 모든 책임을 프롬프트에 맡기면 문제가 생긴다. “절대 비밀키를 저장하지 마”라고 써두는 것과 실제로 secret을 볼트 밖에 두고 실행 시점에만 주입하는 것은 다르다.

내 agent-runtime 운영 매뉴얼도 이 방향이다. secret 값은 볼트 안에 저장하지 않고, 스킬 실행 전에는 run-skill.sh <skill> --check로 필요한 env를 확인한다. 문제가 생기면 스킬부터 뜯지 않고 env -> 경로 -> check 순서로 본다. 이건 프롬프트 예절이 아니라 운영 절차다.

하네스가 없으면 실패는 매번 추리 게임이 된다. “왜 오늘 안 됐지?”를 물을 때 로그가 없고, 상태 파일이 없고, 마지막 성공 시각이 없으면 사람은 기억을 뒤진다. 기억은 가끔 친절하지만 자주 창작한다. 운영 시스템에서 창작력은 소설가에게 양보하는 편이 좋다.

개인 자동화에 필요한 최소 하네스

처음부터 거대한 플랫폼을 만들 필요는 없다. 개인 자동화나 작은 팀이라면 최소 하네스는 다섯 가지면 시작할 수 있다.

첫째, 실행 명령이 하나여야 한다. python a.py인지, bash run.sh인지, make once인지 헷갈리면 자동화가 아니라 의식 행위가 된다. “이거 실행하면 한 번 돈다”는 명령이 있어야 한다.

둘째, 상태 파일이 있어야 한다. 마지막 실행 시각, 마지막 성공 여부, 마지막 실패 이유, 다음 리뷰 시각 정도는 남겨야 한다. 사람이 매번 터미널 스크롤을 뒤지는 구조는 오래 못 간다.

셋째, 이벤트 로그가 있어야 한다. 상태 파일은 현재 상태를 보여주고, 이벤트 로그는 어떻게 여기까지 왔는지 보여준다. 특히 AI 작업은 중간 판단이 중요해서 events.jsonl 같은 단순한 로그만 있어도 복구 난이도가 크게 내려간다.

넷째, 중단 조건이 있어야 한다. 같은 오류가 3번 나면 멈추기, 데이터가 stale이면 전송하지 않기, 승인 없는 write는 막기 같은 기준이다. 자동화의 품격은 달리는 속도보다 멈추는 조건에서 드러난다. 브레이크 없는 자동화는 도구가 아니라 일정표를 찢는 기계다.

다섯째, 권한 경계가 있어야 한다. Obsidian 작업이면 앱 포커스를 건드리지 않는 no-focus 원칙, 파일 수정이면 direct write 범위, 외부 API면 secret 외부화, 블로그 발행이면 publish gate가 필요하다. “AI가 알아서 조심하겠지”는 정책이 아니다. 그건 희망사항이다. 희망사항은 귀엽지만 배포 권한을 주기엔 아직 어리다.

Routines와 하네스는 같은 말이 아니다

Claude Code Routines 같은 기능을 보면 “이제 하네스도 플랫폼이 알아서 해주나?”라는 생각이 들 수 있다. 하지만 내가 이전에 정리한 기준으로는 Routines는 trigger와 session packaging에 가깝고, 하네스 전체를 대체하지는 않는다.

예를 들어 매주 문서 drift 후보를 만들거나 PR마다 리뷰 초안을 작성하는 일은 routine과 잘 맞을 수 있다. 실패해도 사람이 확인하고 이어받으면 된다. 반면 장기 복구 루프, 상태 복원, watchdog, restart loop가 필요한 작업은 여전히 하네스가 본체다.

특히 로컬 Obsidian vault처럼 no-focus 운영, direct write, private config, 임시 로그 파일이 중요한 환경에서는 클라우드 routine보다 로컬 하네스가 더 맞을 때가 많다. 신기능이 나왔다고 모든 자동화를 한 바구니에 담으면 안 된다. 자동화 바구니도 계란 바구니만큼 섬세하다. 떨어뜨리면 노른자 대신 로그가 터진다.

하네스 공부가 블로그 운영에도 중요한 이유

이 주제는 AI 개발자만의 이야기가 아니다. 블로그 운영에도 그대로 들어온다. 글감 수집, URL 요약, 초안 작성, 채널 QC, 발행, 시트 반영, 텔레그램 알림까지 이어지는 흐름은 이미 작은 에이전트 시스템이다.

글 하나를 잘 쓰는 것과 글 생산 시스템을 굴리는 것은 다르다. 글 하나는 프롬프트로 가능할 수 있다. 하지만 매일 여러 채널을 운영하려면 중복 URL 스킵, 점수 기준, 채널 비중 게이트, 발행 전 체크, 실패 로그가 필요하다. 이건 글쓰기 감각만의 문제가 아니라 운영 설계다.

그래서 하네스 공부의 실제 결론은 “더 복잡한 에이전트를 만들자”가 아니다. 오히려 반대에 가깝다. 프롬프트로 해결할 일, 스크립트로 고정할 일, 사람이 승인할 일을 나누자는 쪽이다. AI를 더 많이 쓰는 것보다 AI가 덜 사고 치게 만드는 구조가 먼저다.

실수하기 쉬운 5가지

첫 번째 실수는 에이전트 md를 하네스라고 착각하는 것이다. 역할 문서는 필요하지만, 실행 명령과 상태 복구가 없으면 운영체계가 아니다.

두 번째 실수는 메모리를 무조건 좋게 보는 것이다. 메모리는 생산성 기능이면서 동시에 데이터 보관 정책이다. 무엇을 기억하지 않을지 정하는 게 먼저다.

세 번째 실수는 도구를 많이 붙이면 강해진다고 믿는 것이다. 도구 수가 늘수록 실패 경로도 늘어난다. 좋은 하네스는 많은 도구를 여는 구조가 아니라 안전하게 열고 실패를 다루는 구조다.

네 번째 실수는 로그를 나중으로 미루는 것이다. 자동화가 실패한 뒤에 로그를 만들 수는 없다. 사고 난 뒤 블랙박스를 주문하는 느낌이다. 택배는 오겠지만 그날의 급브레이크는 안 돌아온다.

다섯 번째 실수는 비용 최적화를 모델 가격표로만 보는 것이다. 어떤 단계는 LLM이 아니라 결정론적 스크립트가 더 싸고 안정적이다. 좋은 하네스는 비싼 모델을 덜 쓰게 만드는 구조이기도 하다.

바로 적용할 체크리스트

AI 자동화 하나를 운영 중이라면 아래 질문부터 보면 된다.

질문 없으면 생기는 문제
실행 명령 1개가 있는가 매번 실행법을 다시 찾는다
마지막 성공/실패 상태가 남는가 장애 원인을 기억력으로 추적한다
실패 이벤트 로그가 있는가 재발 방지 규칙을 만들 수 없다
민감 작업 승인 게이트가 있는가 AI가 너무 빨리 일을 저지를 수 있다
secret이 모델/볼트 밖에 있는가 편의 기능이 보안 사고로 바뀐다
stale 데이터 차단 기준이 있는가 낡은 결과가 정상처럼 전송된다
사람이 이어받는 지점이 있는가 실패하면 처음부터 다시 시작한다

이 중 3개 이상이 비어 있다면 아직 “AI 자동화”라기보다 “AI에게 부탁하는 스크립트 묶음”에 가깝다. 나쁜 출발은 아니다. 다만 이 단계에서 운영 중이라고 믿으면 나중에 사람이 운영 하청을 받게 된다.

FAQ

하네스는 LangGraph 같은 프레임워크를 뜻하나?

아니다. LangGraph 같은 프레임워크가 하네스를 구성하는 데 도움을 줄 수는 있지만, 하네스 자체는 더 넓은 운영 구조다. Markdown 규칙, shell script, 상태 파일, 로그, 승인 절차만으로도 얇은 하네스를 만들 수 있다.

개인 사용자에게도 필요한가?

반복 작업을 한 번만 시킬 거라면 필요성이 낮다. 하지만 매일 요약하고, 매주 발행하고, 여러 파일을 수정하고, 외부 API를 쓰기 시작하면 개인에게도 필요하다. 특히 Obsidian, 블로그, 트레이딩, 시트 자동화처럼 파일과 상태가 남는 작업은 더 그렇다.

하네스를 만들면 AI 성능이 떨어질 수도 있나?

가능하다. GeekNews 댓글에도 비슷한 문제의식이 있었다. 어설픈 제약은 모델의 장점을 막을 수 있다. 그래서 하네스는 무조건 많이 잠그는 구조가 아니라, 위험한 행동은 좁히고 반복 가능한 작업은 넓히는 구조여야 한다.

처음 만들 최소 단위는 뭔가?

run_once, status, events log, stop condition, secret boundary 다섯 가지다. 이 정도가 있으면 실패를 관찰하고 복구하는 최소 운영 단위가 생긴다.

마무리

AI 이후의 소프트웨어가 정말 하네스 시대로 간다면, 중요한 기술은 모델 이름 외우기가 아니다. 내 업무의 SOP를 어떻게 맥락으로 만들지, 어떤 도구를 안전하게 열지, 실패를 어디서 멈추고 어디서 재개할지 정하는 능력이다.

내가 하네스를 공부하면서 얻은 가장 실용적인 문장은 이거다. 에이전트는 역할 설명으로 태어나지만, 하네스로 살아남는다. 프롬프트가 시작 버튼이라면 하네스는 다음 날에도 다시 켤 수 있게 만드는 운영체계다.

그래서 다음에 AI 자동화를 하나 더 붙이고 싶어질 때는 모델부터 고르지 말고 이 질문을 먼저 던져보면 좋다. “이 작업은 실패했을 때 어디서 다시 시작하지?” 이 질문에 답이 나오면 그때부터 자동화는 장난감에서 시스템 쪽으로 넘어간다.

함께 보면 좋은 글

참고 자료