하네스 엔지니어링(Harness Engineering)

2023년을 기점으로 ChatGPT, Claude, Gemini 같은 대형 언어 모델(LLM)이 폭발적으로 보급되면서, 우리는 "AI가 할 수 없는 게 무엇인가"를 묻던 시대에서 벗어났습니다. 이제 많은 사람들이 AI에게 코드를 짜게 하고, 보고서를 쓰게 하고, 고객 상담을 맡기고 있습니다. AI는 분명히 강력합니다.

그런데 막상 실무에서 AI를 써보면 낯선 경험을 하게 됩니다. 어제는 완벽하게 동작하던 AI 에이전트가 오늘은 엉뚱한 파일을 덮어쓰거나, 존재하지 않는 API를 멀쩡히 호출하거나, 같은 질문에 매번 다른 포맷으로 대답합니다. 혹은 아무도 시키지 않은 작업을 스스로 실행해버리는 경우도 생깁니다.

이 문제는 AI 모델 자체가 나빠서가 아닙니다. AI를 둘러싼 환경과 규칙이 설계되지 않았기 때문입니다.

여기서 등장한 개념이 바로 하네스 엔지니어링(Harness Engineering)입니다.

1장. '하네스'라는 단어부터 이해하기

'하네스(harness)'는 원래 말이나 소 같은 동물에게 씌우는 마구(馬具)를 뜻하는 영어 단어입니다. 마구란 고삐, 안장, 굴레처럼 동물의 힘을 사람이 원하는 방향으로 쓸 수 있게 해주는 장비 일체를 말합니다.

농경 슬롯를 생각해 보겠습니다. 말은 소보다 빠르고 힘이 셉니다. 하지만 말의 힘을 마음대로 활용하려면 반드시 마구가 필요합니다. 마구 없이 말 위에 올라탄다고 해서 원하는 대로 밭을 갈 수는 없습니다. 힘을 가진다는 것과 그 힘을 목적에 맞게 쓴다는 것은 전혀 다른 문제입니다.

AI도 마찬가지입니다.

AI 모델의 능력 = 말의 근육과 속도

하네스 엔지니어링 = 그 힘을 안전하고 정확하게 사용하도록 만드는 구조 설계

말이 아무리 강해도 마구가 없으면 위험하거나 쓸모없듯이, AI가 아무리 뛰어나도 적절한 통제 구조 없이는 실무에서 믿고 쓸 수 없습니다.

강력한 AI의 능력을 통제된 방식으로 활용하기 위해, 그 주변에 구조와 규칙과 안전망을 설계하는 일입니다.

2장. 프롬프트 엔지니어링과 무엇이 다른가?

프롬프트 엔지니어링의 시대

2022~2023년, AI를 잘 쓰는 사람과 못 쓰는 사람의 차이는 주로 "AI에게 뭐라고 말하느냐"에 있었습니다.

이것이 프롬프트 엔지니어링(Prompt Engineering)입니다.

같은 AI 모델에게 "시 써줘"라고 하는 것과, "5·7·5 하이쿠 형식으로, 가을 단풍을 소재로, 초등학생이 이해할 수 있는 어휘로 시를 써줘"라고 하는 것은 결과물에서 큰 차이를 낳습니다. 프롬프트를 정교하게 다듬으면 AI의 성능을 훨씬 끌어올릴 수 있습니다.

프롬프트 엔지니어링은 지금도 유효하고 중요한 기술입니다. 하지만 AI가 단순한 도구에서 에이전트로 진화하면서, 프롬프트만으로는 해결하기 어려운 문제들이 쏟아지기 시작했습니다.

에이전트란 무엇인가?

AI 에이전트(Agent)란 단순히 대화에 응답하는 수준을 넘어서, 스스로 계획을 세우고, 도구를 사용하며, 여러 단계의 작업을 자율적으로 수행하는 AI 시스템을 말합니다.

예를 들어 다음과 같은 형태입니다.

이메일을 받으면 → 내용을 분석하고 → 캘린더를 확인한 뒤 → 자동으로 회의 일정을 잡는 에이전트

버그 리포트를 받으면 → 코드베이스를 탐색하고 → 수정안을 만들어 → PR(Pull Request)까지 올리는 코딩 에이전트

이런 에이전트는 수십 개의 단계를 자율적으로 거칩니다. 이 과정에서 프롬프트 하나를 잘 쓰는 것만으로는 전체 시스템을 안전하게 운영할 수 없습니다.

간단히 비유하자면,

프롬프트 엔지니어링이 "마부가 말에게 어떻게 명령하는가"의 기술이라면,

하네스 엔지니어링은 "고삐와 안장과 마차 전체를 어떻게 설계하는가"의 기술입니다.

3장. AI 에이전트 시대의 진짜 문제들

하네스 엔지니어링이 왜 필요한지를 이해하려면, 먼저 AI 에이전트를 그냥 쓸 때 어떤 문제가 생기는지를 알아야 합니다.

문제 1: 비결정론적 출력 (Non-deterministic Output)

AI 언어 모델은 근본적으로 확률론적입니다. 같은 입력을 줘도 매번 조금씩 다른 결과를 낼 수 있습니다. 대화를 나누는 수준에서는 이것이 오히려 자연스럽게 느껴지지만, 자동화된 시스템 안에서는 심각한 문제가 됩니다.

예를 들어 AI가 보고서를 생성할 때 오늘은 JSON 형식으로, 내일은 마크다운 형식으로, 모레는 일반 텍스트로 출력한다면, 이 결과물을 받아서 처리해야 하는 다음 시스템은 계속 오류를 낼 것입니다. 하네스 엔지니어링은 출력 형식을 강제하는 스키마(Schema) 검증이나 파서(Parser)를 설계해서 이 문제를 해결합니다.

문제 2: 범위 이탈 (Scope Creep)

AI 에이전트에게 "로그인 기능을 수정해줘"라고 했더니, 에이전트가 로그인 파일뿐만 아니라 관련돼 보이는 수십 개의 파일을 동시에 수정하는 경우가 있습니다. AI 입장에서는 "더 나은 결과"를 위한 행동이지만, 운영 입장에서는 예상치 못한 변경이 시스템 전체에 파급되는 재앙이 될 수 있습니다.

하네스 엔지니어링은 에이전트가 접근하고 수정할 수 있는 파일·디렉터리·API를 명확히 제한해서 이런 일을 막습니다.

문제 3: 환각(Hallucination)의 자동화

AI가 존재하지 않는 정보를 마치 사실처럼 만들어내는 현상을 환각(Hallucination)이라고 합니다. 사람이 직접 대화할 때는 "이게 맞나?" 하고 의심하고 확인할 수 있지만, 자동화된 파이프라인 안에서 AI의 환각은 그대로 다음 단계로 흘러들어갑니다.

예를 들어 AI가 없는 라이브러리를 있다고 믿고 코드를 작성하면, 그 코드는 빌드 단계에서야 오류를 냅니다. 하네스 엔지니어링은 각 단계마다 검증(Validation) 로직을 끼워 넣어 환각이 시스템 깊숙이 침투하기 전에 차단합니다.

문제 4: 복구 불가능한 행동

AI 에이전트가 실수로 프로덕션 데이터베이스의 데이터를 삭제했다면? 혹은 고객에게 잘못된 이메일을 수천 건 발송했다면? 이런 돌이킬 수 없는 행동(Irreversible Action)은 AI 에이전트 운영에서 가장 두려운 시나리오입니다.

하네스 엔지니어링은 위험도가 높은 작업에 대해 스테이징 환경(Staging Environment)에서 먼저 시뮬레이션하거나, 사람의 최종 승인(Human-in-the-loop)을 의무화하는 구조를 설계함으로써 이 위험을 통제합니다.

문제 5: 바카라임 소재 불명확

에이전트가 여러 단계를 거쳐 작업을 수행한 뒤 문제가 생겼을 때, 어느 단계에서 무엇이 잘못됐는지 추적하기 어렵습니다. 이것은 단순히 디버깅이 어렵다는 문제를 넘어서, 법적·윤리적 바카라임 소재를 모호하게 만드는 문제이기도 합니다.

하네스 엔지니어링은 에이전트의 모든 행동을 로그로 기록하고, 단계별 의사결정 근거를 추적 가능하게 만드는 관찰 가능성(Observability) 설계를 포함합니다.

4장. 하네스 엔지니어링의 핵심 구성 요소

하네스 엔지니어링은 하나의 기술이 아니라, 여러 설계 원칙과 기술의 집합입니다. 크게 다섯 가지 구성 요소로 나눌 수 있습니다.

4-1. 권한 경계 설계 (Permission Boundary Design)

가장 기본적인 요소는 AI 에이전트가 무엇을 할 수 있고, 무엇을 할 수 없는지를 명확히 정의하는 것입니다. 이것은 마치 회사에서 신입사원에게 처음부터 모든 시스템의 관리자 권한을 주지 않는 것과 같은 논리입니다.

구체적으로는 다음과 같은 설계를 포함합니다.

파일 시스템 권한: 에이전트가 읽기만 할 수 있는 디렉터리, 쓰기가 가능한 디렉터리, 절대로 접근할 수 없는 영역을 분리합니다.

API 화이트리스트: 에이전트가 호출할 수 있는 외부 API 목록을 사전에 제한합니다. 허용 목록에 없는 API는 요청 자체가 차단됩니다.

데이터베이스 접근 제어: 읽기 전용 계정과 쓰기 계정을 분리하고, 에이전트에게는 최소한의 권한만 부여합니다.

환경 분리: 개발(Development), 테스트(Staging), 운영(Production) 환경을 철저히 분리하고, 에이전트가 어떤 환경에서 작동하는지를 명확히 합니다.