하네스 엔지니어링 — AI 에이전트 통제술

이 토픽을 마치면

하네스 엔지니어링이 프롬프트 엔지니어링과 어떻게 다른지, AI 에이전트를 안전하게 통제하는 핵심 개념을 이해하게 됩니다.

프롬프트 엔지니어링만으로는 부족합니다

프롬프트 엔지니어링은 "AI에게 말을 잘 거는 기술"입니다. 질문을 어떻게 하면 좋은 답변이 나오는지 연구합니다. ChatGPT에게 "전문가처럼 답해줘"라고 하면 답변 품질이 올라가는 것처럼요.

하지만 AI가 단순히 대화하는 것을 넘어 실제로 행동하기 시작하면 상황이 달라집니다. 파일을 읽고, 코드를 실행하고, API를 호출하고, 이메일을 보내는 AI — 이걸 **에이전트(Agent)**라고 합니다.

에이전트에게 "이 버그 고쳐줘"라고 했는데, 관련 없는 파일까지 수정하거나, 프로덕션 데이터베이스를 건드리거나, 비용이 많이 드는 API를 무한 호출하면 어떡할까요? 프롬프트만으로는 이런 사고를 막을 수 없습니다.

하네스 = 안전줄

하네스(Harness)는 원래 암벽등반이나 고공 작업에서 쓰는 안전벨트입니다. 자유롭게 움직이되 위험한 방향으로 가면 잡아주는 장치입니다.

하네스 엔지니어링은 AI 에이전트에게 이 안전줄을 거는 것입니다:

어떤 도구를 쓸 수 있는지 제한합니다. 파일 읽기는 허용하지만 삭제는 금지. 특정 API만 호출 가능. 이걸 도구 권한(Tool Permissions)이라고 합니다.

어디까지 할 수 있는지 범위를 정합니다. 이 폴더 안의 파일만 수정 가능. 이 브랜치에만 커밋 가능. 이 금액 이하의 API만 호출 가능. 이걸 스코프(Scope)라고 합니다.

사람의 승인이 필요한 지점을 설정합니다. 코드 수정은 자유지만 배포는 사람이 확인해야 합니다. 이걸 Human-in-the-loop라고 합니다.

프롬프트 vs 하네스

text

프롬프트 엔지니어링:
  "절대로 프로덕션 DB를 건드리지 마."
  → AI가 "지시를 잘 따르면" 안 건드림
  → AI가 "실수하면" 건드릴 수 있음

하네스 엔지니어링:
  프로덕션 DB 접속 정보 자체를 제공하지 않음
  → AI가 아무리 시도해도 물리적으로 불가능

프롬프트는 부탁이고, 하네스는 제약입니다. 프롬프트는 AI가 무시할 수 있지만, 하네스는 시스템 레벨에서 강제합니다.

좋은 AI 에이전트 시스템은 둘 다 씁니다. 프롬프트로 방향을 잡고, 하네스로 경계를 강제합니다.

실제 적용 사례

코드 에디터 AI (Cursor, Claude Code 등) — 파일 수정 전에 사용자 승인을 요청합니다. 특정 명령어(rm -rf, git push --force)는 실행 전에 경고합니다. 이게 하네스입니다.

고객 서비스 봇 — 환불 처리를 할 수 있지만 일정 금액 이상은 사람에게 에스컬레이션합니다. 고객 정보를 조회할 수 있지만 수정은 못 합니다.

자율 주행 — AI가 조향과 가속을 제어하지만, 특정 조건(센서 이상, 극한 날씨)에서는 자동으로 사람에게 제어권을 넘깁니다.

패턴은 같습니다: 할 수 있는 것과 할 수 없는 것의 경계를 시스템으로 강제하는 것.

왜 지금 중요한가

2024~2025년을 기점으로 AI 에이전트가 폭발적으로 늘었습니다. 코드를 쓰고, 회의록을 정리하고, 이메일을 보내고, 서버를 관리하는 AI가 실무에 투입되고 있습니다.

AI가 강력해질수록 실수의 파급력도 커집니다. 프롬프트 하나로 "조심해"라고 하는 것만으로는 충분하지 않습니다. 구조적인 안전장치가 필요합니다.

하네스 엔지니어링은 **"AI를 얼마나 잘 시키느냐"가 아니라 "AI가 실수해도 괜찮은 시스템을 어떻게 만드느냐"**에 대한 답입니다.

핵심

하네스 엔지니어링은 AI 에이전트의 행동 범위를 시스템 레벨에서 제한하는 기술입니다. 프롬프트가 "부탁"이라면 하네스는 "제약"입니다. 둘 다 필요합니다. AI가 실제로 도구를 사용하고 행동하는 시대에, 실수해도 괜찮은 구조를 만드는 것이 핵심입니다.