아무리 정교하고 꼼꼼한 가이드라인과 룰셋을 정의하여 인공지능 시스템에 주입해 두었다 하더라도, 실제 에이전트 서비스를 장시간 구동해 보면 하네스의 촘촘한 검증망을 교묘하게 피해 가거나 약속된 규칙을 무참히 깨뜨리는 치명적인 오작동 사례가 심심치 않게 관찰되곤 한다.
수많은 초급 엔지니어들이 프롬프트 상단에 규칙을 빽빽하게 적어두거나 단순한 필터를 달아두면 하네스가 완벽하게 작동하여 에이전트를 통제할 수 있을 것이라 안일하게 착각하지만, 실제 거대언어모델(LLM)이 작동하는 생태계의 현실은 완전히 다르다는 것이다.
아무리 뼈대를 훌륭하게 설계해 둔 에이전트 하네스 구조라 할지라도, 모델이 지닌 고유한 한계점과 규칙 간의 상호작용 관계를 명확하게 통제하지 못하면 하네스 검증 시스템 자체가 아무런 힘을 쓰지 못하고 무력화된다.
이번 글에서는 하네스가 제 역할을 해내지 못하고 허무하게 먹히지 않는 본질적인 내부 원인들을 철저하게 해부해 보고, 이를 기술적으로 방어하기 위해 아키텍처 관점에서 어떤 보완 조치를 취해야 하는지 구체적인 진단과 처방을 내리고자 한다.
1. 에이전트 하네스 구조에서 검증망이 허무하게 무너지는 3가지 핵심 원인
하네스 시스템이 제 기능을 상실하고, 모델이 내뱉은 바보 같고 규격에 맞지 않는 산출물을 아무런 필터링 없이 그대로 최종 유저에게 통과시켜 버리는 현상은 크게 세 가지의 구체적인 소프트웨어 공학적 문제점들로 요약할 수 있다.
ㄱ. 검증 역할을 맡은 모델 자체의 환각과 문맥 피로도
하네스 구조를 만들 때 문장의 톤앤매너나 흐름의 자연스러움 같은 정성적인 영역을 심사하기 위해 메인 모델 외에 또 다른 서브 LLM을 검증원으로 고용하여 배치하는 경우가 많다. 하지만 검증 역할을 맡은 그 AI 역시 결국 인간이 만든 완벽하지 않은 모델일 뿐이다. 생성된 본문 안에 명백한 규칙 위반 문장이 버젓이 포함되어 있음에도 불구하고, 검수해야 할 전체 컨텍스트의 길이가 너무 길어지거나 모델의 주의력(Attention) 메커니즘이 분산되면 “아무런 이상이 없으니 합격”이라고 대충 판정하여 패스(Pass)를 외치는 이른바 환각(Hallucination) 현상이 수시로 발생한다는 것이다.
ㄴ. 하네스 규칙들끼리 발생하는 내부적 상충(Conflict)
하네스 시스템에 부여된 다채로운 규칙들이 서로의 발목을 잡으며 충돌할 때 시스템은 논리적 마비 상태에 빠진다. 예컨대 “작성하는 콘텐츠는 무조건 1,700단어 이상의 풍부한 장문이어야 한다”는 분량 규칙과 “모든 문장은 군더더기 군살을 뺀 극도로 절제되고 담담한 어조(~이다, ~한다)만을 유지해야 한다”는 어조 규칙이 한 공간에서 강하게 부딪히는 상황을 가정해 본다.
가성비 모델이 1,700단어라는 거대한 분량 압박을 채우기 위해 억지로 글을 늘려 쓰다 보면, 자연스럽게 수식어가 덕지덕지 붙거나 친근하게 설명하려는 어조 규칙을 자신도 모르게 위반하게 된다.
이때 하네스 검증 모델은 이 모순된 두 가지 규칙 사이에서 갈팡질팡 정답을 내리지 못하다가, 결국 어느 한쪽 규칙의 끈을 느슨하게 풀어주며 타협해 버리는 치명적인 실수를 범하게 된다.
ㄷ. 소스 코드 기반 하네스의 예외 처리(Exception) 설계 미비
글자 수의 제한이나 JSON 포맷 스키마의 일치 여부처럼 파이썬(Python) 코드를 활용해 한 치의 오차도 없이 완벽하게 통제할 수 있는 영역에서도 설계 오류로 인한 구멍이 뚫린다.
시스템 개발자가 임의로 작성한 단어 카운팅 로직(예: 띄어쓰기 기준 split)과 AI 모델 내부에서 스스로 인지하는 단어(토큰)의 연산 기준이 다를 때 파이프라인에 대재앙이 찾아온다.
하네스 코드는 “기준에서 단 20단어가 부족하므로 탈락”이라며 끈질기게 반려를 때리는데, 가성비 모델은 자신만의 토큰 계산법으로 이미 분량을 채웠다고 인지하여 완벽히 똑같은 답변을 무한대로 복사해 제출하는 이른바 교착 상태(Deadlock)에 진입하기도 한다.
하네스 시스템이 이러한 예외적인 상황을 유연하게 처리하도록 설계되어 있지 않다면 하네스는 그저 먹통이 될 뿐이다.
2. 가성비 모델의 탈선을 원천 차단하는 이중 하네스 방어 벽 설계법
하네스 시스템이 가성비 모델의 변덕에 우회당하지 않고 어떤 상황에서도 규칙을 확실하게 집행하도록 만들기 위해서는, 검증 아키텍처의 체질을 구조적으로 완전히 개선해야만 한다. 하네스가 바보 짓을 하지 않도록 만들기 위해 시스템 엔지니어가 반드시 뼈대에 새겨야 할 두 가지 절대 원칙이 존재한다.
[1차 모델 답변 생성] ➔ [멀티 하네스 레이어 1: 코드 검증] ➔ [멀티 하네스 레이어 2: 톤 검증] ➔ [최종 출고]
ㄱ. 규칙 성격에 따른 철저한 ‘역할 분리’와 이원화
컴퓨터 소프트웨어가 완벽하게 계산해 낼 수 있는 정량적인 규칙들(정확한 글자 수 계산, 특수문자 포함 여부, 링크의 유효성 등)은 절대로 지능형 LLM에게 검증을 맡겨서는 안 된다. 반드시 파이썬의 엄격한 if문과 같은 하드코딩 소스 코드로 1차 차단벽을 세워 날카롭게 도려내야 한다.
반면 글의 전체적인 맥락이나 구조적 완성도 같은 정성적 규칙들은 2차 차단벽으로 넘겨 LLM 검증원에게 전담시키는 등, 하네스 내부에서도 명확한 분업이 이루어져야만 시스템의 신뢰도가 유지된다.
3. 검증 프롬프트의 극단적인 이진분류(Binary)화
어쩔 수 없이 문맥 검사를 위해 LLM을 하네스 검증 엔진으로 활용할 때는 프롬프트 단계에서 모델에게 일절 융통성을 발휘할 여지를 주어서는 안 된다.
“이 글의 전반적인 분위기와 문체가 규칙에 잘 부합하는가?”라고 부드럽게 질문을 던지면 하네스 모델은 제멋대로 후한 점수를 주며 대충 넘어가 버린다.
대신 하네스용 프롬프트를 설계할 때는 “너는 감정이 없는 엄격한 교정 로봇이다. 다음 글에서 ‘~했습니다’ 혹은 ‘~해요’라는 어미가 단 한 단어라도 검출되면 가차 없이 ‘결함’을 출력하고, 완벽히 통과했을 때만 오직 ‘패스’라는 단어 딱 하나만 뱉어라”고 행동의 반경을 사방으로 꽁꽁 묶어두어야 하네스가 똑똑하게 제 기능을 수행한다.
하네스가 현장에서 실패하는 근본적인 취약점들을 명확하게 인지하고 보완책을 세웠다면, 이제 이를 바탕으로 눈에 보이는 실전 코드를 빌드할 차례이다.
이어지는 시리즈 3편에서는 우리가 정해둔 12가지 블로그 작성 원칙을 단 하나의 예외도 없이 100% 만족시키는 실제 파이썬 하네스 에이전트 소스 코드를 밑바닥부터 직접 구현하고 구동해 보는 실전 과정을 상세하게 다루도록 한다.