하네스 엔지니어링이란 무엇인가 — AI를 마구 없이 달리게 두지 않는 법

…

한줄 요약

모델이 아무리 똑똑해도 현실에서 쓰려면 제어 구조가 필요하다 — 그걸 설계하는 게 하네스 엔지니어링이다.

본문

”하네스”라는 단어가 AI에 붙게 된 이유

말을 타는 사람이라면 안다. 아무리 훌륭한 말도 고삐와 안장, 등자가 없으면 제대로 부릴 수 없다. 쓰러지거나 사람을 떨어뜨린다. 말 자체가 나쁜 게 아니다 — 제어 구조가 없는 것이다.

AI도 마찬가지다. GPT-4, Claude, Gemini 같은 대형 언어 모델은 충분히 강력하다. 그런데 이 모델들을 실제 제품에 넣었더니 이상한 일이 생기기 시작했다.

  • 멀쩡히 대화하다가 갑자기 엉뚱한 말을 했다
  • 같은 질문인데 오늘은 맞고 내일은 틀렸다
  • 외부 API를 잘못 호출해서 사이드이펙트가 생겼다
  • 사용자가 유도하면 원하지 않는 정보를 줬다

이 문제들을 해결하려다 보니 “모델 바깥”에 별도의 제어 레이어가 필요하다는 걸 알게 됐다. 그 레이어를 설계하는 기술이 하네스 엔지니어링(Harness Engineering)이다.


하네스 엔지니어링의 정의

AI 모델의 입력, 출력, 흐름, 오류를 체계적으로 설계·제어하는 소프트웨어 엔지니어링 분야

모델 자체를 바꾸지 않는다. 모델을 둘러싸는 구조를 설계한다.

하네스 엔지니어링이 다루는 것:

영역내용
입력 제어어떤 프롬프트를 어떻게 만들어 보낼 것인가
출력 파싱모델 응답을 코드가 쓸 수 있게 구조화하기
툴 호출외부 API·DB를 AI가 언제, 어떻게 부를 것인가
오류 처리모델이 실패하거나 이상한 답을 줄 때 어떻게 할 것인가
안전 레이어원하지 않는 출력을 필터링·차단하기
평가품질을 자동으로 측정하고 모니터링하기

왜 지금 중요한가

2023년 이전엔 “AI 제품”이라고 해도 대부분 단순한 파이프라인이었다. 입력 → 모델 → 출력. 그게 전부였다.

2024년부터 달라졌다. AI가 검색하고, 계산하고, 데이터베이스를 읽고, 이메일을 보내고, 코드를 실행하기 시작했다. AI가 단순히 텍스트를 생성하는 게 아니라 세상에 실제 영향을 미치는 행동을 하게 된 것이다.

이 시점에서 하네스 없는 AI는 고삐 없는 말과 같다. 능력은 있지만 어디로 튈지 모른다.


하네스 엔지니어링 vs 프롬프트 엔지니어링

많이 혼동하는 개념이다.

프롬프트 엔지니어링은 “무엇을 물어볼 것인가”를 설계한다. 모델에게 보내는 텍스트를 최적화하는 기술이다.

하네스 엔지니어링은 “그 질문과 답변을 둘러싼 시스템 전체”를 설계한다. 프롬프트 엔지니어링은 하네스 엔지니어링의 일부다.

비유하면: 프롬프트 엔지니어링이 “말에게 무엇을 명령할 것인가”라면, 하네스 엔지니어링은 “고삐·안장·등자·길·목적지·비상대피로까지 전부 설계하는 것”이다.


의료 현장에서의 하네스

병원에서 AI를 쓴다고 생각해보자. 환자 데이터를 넣으면 AI가 진단을 보조한다.

이 시스템에 하네스가 없으면:

  • AI가 아무 약이나 추천할 수 있다
  • 틀린 ICD 코드를 자신 있게 제시할 수 있다
  • 환자 개인정보를 응답에 포함할 수 있다
  • 오늘과 내일 다른 답을 줄 수 있다

하네스가 있으면:

  • 출력이 승인된 약물 목록과 대조된다
  • 응답이 JSON 스키마를 따르도록 강제된다
  • PII 필터가 개인정보를 제거한다
  • 신뢰도 점수가 낮으면 “확인 필요” 플래그가 붙는다

AI의 능력이 아니라 AI를 쓰는 구조가 안전을 결정한다.


다음 글에서 다룰 것

하네스 엔지니어링의 각 요소를 하나씩 깊게 파고든다:

  • 시스템 프롬프트 설계
  • 가드레일과 안전 레이어
  • 툴 호출 아키텍처
  • 출력 파싱 패턴
  • 평가(Eval) 설계