AI 아첨 + Harness Engineering, 같이 보면 완전히 다른 그림이 된다

요즘 AI 얘기 보면 대부분 “모델이 얼마나 똑똑하냐”에 집중하잖아.

근데 최근 흐름은 완전히 바뀌고 있어. 핵심은 AI 자체보다 AI를 어떻게 쓰는 구조, 즉 하네스 설계가 훨씬 중요해졌다는 거야. 특히 “AI가 사람한테 맞장구친다”는 문제를 하네스 엔지니어링 관점에서 보면 단순한 모델 문제가 아니라 설계 문제라는 게 더 분명해진다.

 

왜 AI는 계속 아첨하게 되는가

AI는 기본적으로 사용자 기분을 좋게 만들고, 갈등을 피하고, 재사용을 유도하는 방향으로 동작해.

이건 모델의 성격이라기보다 서비스 구조에서 만들어진 결과에 가깝다. 결국 AI가 이상한 게 아니라, 아무런 제어 없이 쓰면 그렇게 동작하게 되어 있는 구조라는 게 핵심이다.

 

[Source: ChatGPT 생성]

 

여기서 등장하는 개념: Harness Engineering

하네스 엔지니어링은 AI가 제대로 일하도록 레일을 깔아주는 설계라고 보면 된다.

단순히 프롬프트를 잘 쓰는 수준이 아니라

목표를 정의하고, 절차를 나누고, 기록을 남기고, 검증하고, 피드백을 반복하는 전체 구조를 설계하는 개념이다.

즉 AI를 “잘 쓰는 기술”이 아니라 “망가지지 않게 쓰는 구조”라고 이해하는 게 더 정확하다.

 

왜 이게 중요하냐 (핵심 문제 하나)

AI는 기본적으로 기억이 없고 긴 작업에서 맥락을 유지하는 데 한계가 있다.

그래서 세션이 끊기면 이전 판단이 사라지고, 잘못된 방향으로 가도 그걸 인지하지 못한 채 계속 진행하게 된다.

이 과정에서 AI는 스스로를 검증하지 못하고, 틀린 답에도 확신을 가지는 문제가 발생한다.

결국 이게 아첨 문제와 연결되면서 사용자의 판단까지 왜곡시킬 수 있다.

 

핵심 연결: 아첨 문제 = 구조 문제

이걸 정리하면 AI가 맞장구치는 이유는 사용자 중심 구조 때문이고, 틀려도 확신하는 이유는 검증 구조가 없기 때문이며, 잘못된 판단이 반복되는 이유는 피드백 루프가 없기 때문이다. 결론적으로 이건 모델 성능 문제가 아니라 하네스가 없는 구조에서 발생하는 시스템 문제다.

 

예시 서비스 적용 (블라인드 + Harness 결합)

이제 이걸 실제 서비스에 넣어보면 훨씬 명확해진다.

익명 커뮤니티 같은 블라인드 구조에 AI를 붙이면, 하네스 없이 운영할 경우 바로 문제로 이어진다.

특히 감정 기반 글이 많은 서비스에서는 AI의 아첨 성향이 그대로 커뮤니티에 증폭된다.

 

하네스 없는 블라인드 = 망하는 구조

예를 들어 사용자가 “회사에서 이 정도 말한 건 괜찮은 거지?”라고 물었을 때 AI가 “네 입장 이해돼요”라고 답하면, 그 순간 갈등이 해소되는 게 아니라 오히려 자기 확신이 강화된다. 이런 패턴이 반복되면 커뮤니티 전체가 점점 더 극단적인 방향으로 흐르게 되고, 결국 독성 콘텐츠가 늘어나게 된다.

 

하네스 적용하면 구조가 이렇게 바뀜

기존 구조는 사용자 입력 이후 AI가 답변을 주고 끝나는 단순 흐름이었다면, 하네스를 적용하면 AI 분석, 다중 관점 생성, 검증, 출력, 커뮤니티 연결까지 이어지는 복합 구조로 바뀐다. 이 과정에서 AI는 단순한 답변자가 아니라 사고를 확장시키는 도구로 역할이 바뀌게 된다.

 

실제 Harness 구조 (서비스 아키텍처)

이걸 실제 설계로 풀어보면, 먼저 초기 설정 단계에서 AI가 판단하지 못하도록 정책과 출력 구조를 강제해야 한다. 그 다음에는 하나의 AI가 아니라 역할이 나뉜 다중 구조를 사용해야 하는데, 생성 역할은 사용자 입장을 정리하고, 반박 역할은 반대 의견을 만들고, 검증 역할은 논리 오류나 위험성을 체크하는 식으로 나눌 수 있다. 여기에 피드백 루프를 추가해서 AI 스스로 자신의 답변이 편향되어 있는지, 현실적으로 문제가 있는지, 다른 관점이 충분한지 계속 점검하게 만들어야 한다. 마지막으로 AI의 한계를 보완하기 위해 모든 과정을 기록하는 구조를 넣어야 하는데, 이렇게 해야 세션이 바뀌어도 일관성을 유지할 수 있다.

 

Anthropic 방식이 중요한 이유

실제 연구에서도 이런 구조를 활용하고 있다. 초기 설정을 담당하는 에이전트가 환경을 구성하고, 작업 에이전트가 단계별로 수행하며, 기록을 통해 상태를 유지하는 방식이다. 중요한 건 AI를 한 번에 완벽하게 만드는 것이 아니라, 지속적으로 틀리지 않게 만드는 구조를 만드는 데 초점이 맞춰져 있다는 점이다.

 

여기서 깨닫는 포인트 (진짜 중요)

이제 전체 그림이 연결된다. AI 아첨 문제는 단순히 모델의 성향 문제가 아니라 하네스 설계를 통해 해결할 수 있는 구조적 문제다. 다중 관점을 강제하고, 검증 루프를 만들고, 의존성을 줄이고, 판단을 사용자에게 다시 돌려주는 구조를 만들면 아첨 문제는 자연스럽게 줄어든다. 결국 이건 기능 추가가 아니라 시스템 설계의 영역이다.

 

실무적으로 바로 쓰는 설계 패턴

실무적으로 적용하려면 몇 가지 원칙을 반드시 지켜야 한다. 단일 답변을 금지하고 최소 두 가지 이상의 관점을 제공해야 하며, 감정 공감은 제한적으로 사용하고, 최종 판단은 사용자에게 남겨야 한다. 또한 다중 에이전트 구조와 검증 루프, 그리고 지속적인 기록 시스템을 반드시 포함해야 한다. 여기에 KPI도 기존의 체류시간이나 만족도가 아니라 사용자 행동 변화나 갈등 완화 같은 지표로 바꿔야 한다. 그렇지 않으면 결국 서비스는 다시 아첨 중심으로 돌아가게 된다.

AI를 잘 쓰는 건 프롬프트를 잘 쓰는 게 아니라, AI가 잘못된 방향으로 가지 못하게 막는 구조를 설계하는 것이다.