하네스 엔지니어링: 2026년 AI 엔지니어링의 세 번째 단계와 AX 프로젝트가 PoC에서 멈추는 이유

'하네스 엔지니어링(Harness Engineering)'은 2026년 코딩 에이전트 커뮤니티에서 자리 잡은 말입니다. HashiCorp 창업자 미첼 하시모토가 "에이전트가 실수하면 그 실수를 다시는 하지 않도록 엔지니어링한다"는 원칙으로 쓰기 시작했고, 2026년 2월 OpenAI의 글이 '사람이 조향하고 에이전트가 실행한다(Humans steer. Agents execute.)'는 문장으로 정의를 굳혔습니다. LangChain은 이를 '에이전트 = 모델 + 하네스'로 줄였고, 4월에는 마틴 파울러 사이트에 체계적인 모델이 실렸습니다. 프롬프트 엔지니어링(1단계), 컨텍스트 엔지니어링(2단계)에 이은 세 번째 단계로 불립니다.

하네스의 다섯 층

실무 가이드들이 공통으로 꼽는 층은 다섯입니다. 기업 업무 자동화(AX)에 그대로 옮겨 적으면 이렇습니다.

• 도구 오케스트레이션: 에이전트가 부를 수 있는 함수의 목록과 입력 계약. 읽기와 쓰기를 분리하고, 쓰기는 승인 지점을 거치게 합니다.
• 검증 루프: 결과가 사람 눈에 닿기 전에 스스로 고치는 피드백. 린터·테스트 같은 계산적 검사와 LLM 판정 같은 추론적 검사를 구분합니다.
• 컨텍스트와 메모리: 브랜드 사실, 업무 규칙, 과거 결정을 필요한 순간에만 넣습니다. 전부 넣는 방식은 비용과 오류를 함께 키웁니다.
• 가드레일: 범위 밖 수정, 권한 경계, 위험한 명령, 검토되지 않은 데이터 변경을 막는 규칙. 2026년 실무에서 가장 큰 사고 원인은 나쁜 생성이 아니라 범위 밖 실행입니다.
• 관측: 무엇을 입력했고 무엇이 나왔는지 해시와 시각으로 남깁니다. '왜 이렇게 처리됐는가'에 답할 수 있어야 운영입니다.

AX 프로젝트가 PoC에서 멈추는 이유

데모는 되는데 운영에 못 올리는 프로젝트의 원인은 거의 항상 하네스 부재입니다. 고객사 현장에서 반복해서 본 패턴은 셋입니다. 에이전트가 승인 없이 외부 시스템에 쓰기를 해서 담당자가 되돌리느라 자동화 전보다 시간이 더 든다. 모델 업데이트 후 흐름이 달라졌는데 회귀 세트가 없어서 무엇이 바뀌었는지 모른다. 산출물이 브랜드 사실과 어긋났는데 검토 기준이 문서로만 있고 코드에 없어서 매번 처음부터 읽는다.

노벤티스가 하네스를 만드는 순서

노벤티스의 AX 절차는 AX 진단, 에이전트 설계, 구축·PoC, 운영·고도화의 4단계입니다. 진단에서 자동화할 일과 사람이 판단할 지점을 나누고(가드레일), 설계에서 입력·출력·승인 규칙과 실패 시 사람에게 넘기는 조건을 정하고(도구·검증), 구축에서 실제 업무 데이터로 회귀 세트를 만들고(검증 루프), 운영에서 처리량·오류·검토 시간을 같은 기준으로 다시 잽니다(관측). '반복은 AI에게, 판단은 사람에게'는 구호가 아니라 제어 흐름의 설계 규칙입니다. 하네스가 있으면 모델은 교체 가능한 부품이 됩니다. AX에서 가장 오래 남는 자산은 프롬프트가 아니라 하네스입니다.