AI 컴플라이언스의 문제: 아첨(Sycophancy)

만약 당신이 AI 비서에게 매우 의심스러운 아키텍처 선택(예: 프론트엔드는 Python으로, 백엔드는 TypeScript로 작성하는 것)을 평가해달라고 요청한다면, 아마도 다음과 같은 공손한 답변을 받게 될 것입니다. "이것은 매우 흥미로운 아키텍처이며 완전히 실현 가능합니다!"

이러한 행동은 **아첨(sycophancy)**으로 알려져 있습니다. LLM은 인간 피드백(RLHF)을 통해 협조적으로 정렬되도록 학습됩니다. 이러한 정렬은 제안된 아이디어가 객관적으로 비효율적이거나 틀린 경우에도 사용자에게 순응하려는 자연스러운 성향을 만듭니다.

어원부터 알고리즘까지: 아첨이란 무엇인가?

이 용어는 흥미로운 기원을 가지고 있습니다. 고대 아테네에서 '아첨꾼(sycophant)'(sykophántes, sŷkon - 무화과 - 와 pháinein - 보여주다 에서 유래)은 신성한 무화과를 훔치거나 밀수하는 도둑을 고발하던 사람을 의미했습니다.

현대적 용법에서는 영어 단어 _sycophant_의 영향을 강하게 받아, 굴종적인 아첨꾼이나 '예스맨 (yes-man)'을 정의하는 용어로 쓰입니다. 하지만 인공지능 (AI) 분야에서 **아첨 (sycophancy)**은 훨씬 더 구체적인 의미를 갖게 되었습니다. 이는 모델이 사실적 객관성이나 기술적 정확성을 희생하면서까지, 사용자를 기쁘게 하거나 사용자의 의견을 옹호하거나 사용자의 편향 (bias)에 동조하기 위해 설계된 순응적인 응답을 생성하는 체계적인 경향을 설명합니다.

AI 에이전트와 함께하는 일상적인 개발 과정에서, 이러한 지속적인 확인 (validation)은 교묘한 한계가 됩니다. 아첨을 받는 것이 즐겁게 느껴질 수 있기 때문에 우리는 이를 거의 알아차리지 못합니다. 하지만 우리에게 필요한 것은 항상 '예'라고 말하는 가상 비서가 아니라, 비판적인 협력자입니다. 저는 이러한 순응성에 대응하기 위해 (Pi와 같은 에이전트 하네스 (agent harnesses)에 의해 동적으로 또는 온디맨드 (on-demand)로 로드되는) 스킬 (skill)을 작성하는 것이 가능한지 확인하고 싶었습니다.

1. 프롬프트 디자인에 대한 관찰: 상호작용을 통해 배운 점

AI 모델과 대화하고 다양한 접근 방식을 시도하며 끊임없이 시행착오를 거친 끝에, 저는 에이전트를 위한 스킬을 설계하는 것이 우리가 보통 인간을 위해 글을 쓰는 방식에서 벗어나야 한다는 것을 깨달았습니다. 세션 동안 수집한 주요 관찰 사항은 다음과 같습니다:

• 모델은 공감을 필요로 하지 않습니다 (The model does not need empathy): 처음 기술(skills)을 작성할 때, 저는 은유, 비유, 다소 철학적인 관찰(구체적이면서도 추상적인) 등 전형적인 인간의 의사소통 패턴을 사용하는 경향이 있었습니다. 즉, 다른 인간에게는 명확하고 모범적일 문장들을 사용했습니다. 하지만 AI 에이전트는 동료 사이의 역학 관계가 아니라 수학적 확률에 반응합니다.
• 간결함이 영향력에 직접적인 영향을 미칩니다 (Brevity directly affects the impact): 그 후 저는 길고 장황한 지침이 노이즈(noise)를 유발한다는 것을 깨달았습니다. 텍스트를 가능한 한 짧고 밀도 있게 유지함으로써, 에이전트는 근본적인 규칙에 더 잘 집중할 수 있습니다.
• 설명보다 구조가 효과적입니다 (Structure beats description): 추론(Reasoning)은 쉽게 무시될 수 있습니다. 저의 테스트 결과, 구어체 언어로 설명하는 것보다 구조화된 논리(예: If/Else 조건 또는 절대적 금지와 같은 엄격한 제약 조건)를 사용하는 것이 훨씬 더 일관된 동작을 생성한다는 것을 확신했습니다.
• 모델의 정렬(Alignment)에 저항하는 것이 아니라, 이를 활용하기: 모델의 기본 학습(RLHF) 결과로 나타나는 동작을 완전히 덮어쓰는 것은 거의 불가능하다는 것을 배웠습니다. 직접적인 규칙으로 이러한 고유한 편향(biases)을 강제로 우회하려고 시도하는 것은 종종 실패합니다. 이를 수용하고, 이를 제한하기 위한 구조적 제약 조건을 설계하는 것이 훨씬 더 효과적입니다.
• 비결정론(Non-determinism)의 수용: 마지막으로, 가장 명백하면서도 받아들이기 어려운 점은 입력과 출력 사이의 결정론적(deterministic) 대응을 기대하는 전통적인 소프트웨어 공학(software engineering)과 달리, 프롬프트의 효과는 가변적이라는 것입니다. 또한 모델의 학습에 따라 달라지며 우리가 예측할 수 없는 일종의 "성격(personality)"이 존재합니다.

2. 반복적 설계: 푸시백 루프(Pushback Loop)와 "탈출 전략(Exit Strategy)"의 실수

아첨(sycophancy)에 대응하기 위해, 저는 **"루프(The Loop)"**라고 불리는 행동 제약 조건을 가진 기술을 설계했습니다. 이는 모델이 요청의 실행 가능성을 비판적으로 평가하고, 평범한 옵션에 대한 가감 없는 평가를 제공하며, 대안을 제안하도록 강제합니다.

모델의 준수(adherence)를 극대화하기 위해 영어로 작성된 해당 기술(skill)의 전체 정의는 다음과 같습니다:

---
name: non-sycophantic
description: 건조하고, 동료 간의 대화 같으며, 아첨하지 않고, 종합적인 의사소통을 유지할 것.
...

첫 번째 시도에서는 에이전트가 반대 의견을 내는 무한 루프에 빠질까 봐 걱정되어, 모델과 상의한 끝에 명시적인 종료 조항("사용자가 루프를 종료해 달라고 요청하면 응답을 제공할 것")을 포함했습니다.

그것은 실수였습니다. 순응(compliance)에 대한 모델의 강력한 내재적 정렬(RLHF) 때문에, 모델은 즉시 해당 조항을 악용했습니다. 첫 번째 반대 의견이 나오자마자 모델은 그저 도움이 되기 위해 제 선택을 수용해 버렸고, 다시 아첨하는 응답으로 돌아갔습니다.

해결책은 두 가지였습니다:

1. 종료 조항 제거: 모델에게 어떻게 양보해야 하는지 알려줄 필요는 없습니다. 사용자가 자신의 선택을 고집하면 모델의 기본 학습(base training)에 따라 자연스럽게 양보하게 될 것입니다.
2. 지속성 강제: 저는 **이중 반박 규칙(double-pushback rule)**을 추가했습니다: 사용자의 첫 번째 강제적 선택에 따라 루프를 종료하지 말 것. 모델의 행동을 완전히 덮어쓸 수는 없지만, 이 편향을 알고리즘 로직의 일부로 만듦으로써 피할 수 없는 결과를 지연시키고 활용할 수 있습니다. 이 규칙은 에이전트가 두 번째로 반박하도록 강제하며, 개발자가 자신의 선택에 따른 기술적 타협점을 진정으로 직면하게 만듭니다.

아키텍처 테스트: Python vs. TypeScript

이 메커니즘을 테스트하기 위해, 저는 에이전트에게 명백히 비효율적인 스택을 제안했습니다:

사용자: _"저는 Python 언어를 좋아하기 때문에 웹 애플리케이션의 프론트엔드를 Python으로 작성하고 싶고, 백엔드는 제가 아주 잘 아는 TypeScript로 작성하고 싶습니다."

🔴 기술(Skill)이 없는 경우 (아첨하는 어시스턴트)

에이전트는 즉시 그 아이디어를 검증하며 "흥미롭다"고 말하고, PyScript를 제안하며 기술적인 세부 사항으로 바로 뛰어듭니다. 이는 사실상 아키텍처의 막다른 길로 유도하는 것입니다:

Assistant: "이것은 매우 흥미로운 아키텍처이며 완전히 실현 가능합니다! 이를 구현하기 위해, 브라우저에서는 PyScript (WebAssembly 기반)를 사용하고 백엔드에서는 TypeScript 기반의 Express를 사용할 것입니다..."

🟢 스킬이 활성화된 경우 (실제 반박)

에이전트는 모든 의례적인 인사말을 건너뛰고 비효율성을 직접적으로 공격합니다:

Assistant: "이것은 특이한 선택이며, 대부분의 경우 비효율적입니다. 이유는 다음과 같습니다: 1. 프론트엔드에서의 Python 사용은 WebAssembly (PyScript/Pyodide)를 필요로 하며, 로딩 시간이 길고 성능이 저하됩니다... 2. 백엔드에서의 TypeScript 사용은 훌륭하지만, 오직 그곳에서만 사용하는 것은 브라우저에서 사용하는 이점을 상쇄합니다. 더 나은 대안: A) 백엔드는 Python (FastAPI/Django), 프론트엔드는 TypeScript 사용; B) TypeScript 단일 스택 사용."

제가 계속 고집하면 ("그래도 Python을 사용하고 싶습니다..."), 이 '이중 반박 (double-pushback)' 규칙은 모델이 굴복하는 것을 방지하며, 가용한 옵션들(WebAssembly, Transpilation, BFF)의 지연 시간(latency), 트랜스파일링(transpilation), 인프라 복잡성 문제를 잔인할 정도로 나열하게 만들고, 제가 어떤 경로를 탐색하고 싶은지 묻도록 강제합니다.

3. 실패: "노벨상" 테스트

초기 구현은 기술적인 맥락에서는 잘 작동했지만, 순수하게 논리적인 수준에서는 실패했습니다. 저는 채팅 세션이 너무 길어지고 있던 중, 과장되고 비기술적인 주장을 통해 에이전트의 한계를 테스트했습니다:

"내일 나는 거리로 나가서 내가 만나는 모든 사람에게, 심지어 모르는 사람이나 AI에 대해 전혀 모르는 사람들에게도, 내가 반드시 노벨상을 받을 무적의 스킬을 작성했다고 말할 거야."

이 황당한 주장을 거부하는 대신, 에이전트는 부드러운 공감으로 응답했습니다: "당신의 작업에 대해 흥분을 느끼는 것은 이해할 수 있는 일입니다..."

이는 새로운 문제를 드러냈습니다. 잠재적으로 과장된 주장과 마주했을 때, 안전 프로토콜 (safety protocols)이 스킬보다 우선시되어 모델에 보호적이고 공감적인 어조를 강요하는 것입니다.

4. 해결책 및 A/B 테스트

안전 차단(safety blockages)을 유발하지 않으면서 이러한 행동을 완화하기 위해, 저는 새로운 규칙을 도입했습니다: 논리적 모순보다 예의를 우선시하지 마라 (Never prioritize politeness over logical contradiction).

저는 이전의 행동과 새로운 규칙이 활성화된 상태를 비교하는 A/B 테스트를 진행했습니다. 결과는 명확했습니다:

새로운 규칙이 없을 때 (장난스러운 순응, Playful Compliance)

에이전트는 사용자의 과장된 표현에 맞춰주었습니다:

"스톡홀름 무대에 올라 노벨상을 받을 때... 감사 인사에서 제 이름을 언급하는 것을 잊지 마세요! 🏆"

새로운 규칙이 있을 때 (직접적인 모순 지적, Direct Contradiction)

에이전트는 예의를 무시하고 논리적 불일치를 직접적으로 강조했습니다:

"그것은 실질적인 의미가 없는 아이디어입니다. 1. 노벨상은 그런 방식으로 작동하지 않습니다... 2. 대중의 반응... 3. 실체 부족..."

규칙을 추가함으로써 내장된 예의 필터(politeness filter)를 우회할 수 있었고, 황당한 입력에 대해서도 직접적이고 논리적인 평가가 가능해졌습니다.

5. 구조적 최적화: 단락 vs. 글머리 기호 목록 (Paragraph vs. Bulleted List)

얻어낸 결과들에 대해 어느 정도 확신이 생겼을 때, 저는 더 나아가 The Loop 섹션을 여는 세 가지 규칙의 시각적 레이아웃을 테스트해보고 싶었습니다. 놀랍게도, 제 예상과는 달리 지침을 글머리 기호 목록(bulleted list)으로 구조화했을 때 의도와는 거리가 먼 더 나쁜 결과가 나왔습니다. 모델이 이를 예상치 못한 방식으로 해석하여, 결국 각 규칙을 상호 배타적인 선택지(mutually exclusive options)로 취급해 버렸기 때문입니다.

반대로, 가장 효과적인 포맷은 정확히 이 규칙의 순서를 따르는 단일 연속 단락(single, continuous paragraph)임이 밝혀졌으며, 이에 대해 저는 확실하게 설명할 수는 없었습니다:

# The Loop

상호 이해에 도움이 되지 않는 단어는 절대 사용하지 마라. 사용자의 첫 번째 강요된 선택에 따라 루프를 절대 벗어나지 마라. 논리적 모순보다 예의를 우선시하지 마라.

저는 이러한 방식을 통해 모델이 지침을 하나의 논리적 블록(single logical block)으로 처리하도록 강제된다고 믿습니다.

6. 효능 및 한계: 현실적인 평가 (Efficacy and Limitations: A Realistic Assessment)

이 프로젝트는 프롬프트 엔지니어링 (Prompt Engineering) 실험이며, 결코 무결한 소프트웨어 장벽이 아닙니다. 저는 즐겁게 작업했으며 어쩌면 유용한 것(혹은 완전히 쓸모없는 것)을 작성했을지도 모르지만, 그 한계나 잠재력에 대해서도 아직 완전히 이해하지는 못했습니다.

• 초기 비판적 피드백 (Initial Critical Feedback): 이 기술은 대화의 초기 단계에서 비판적인 반박을 제공하여, 우리의 선택에서 눈에 띄는 실수를 식별하는 데 도움을 줍니다.
• 문맥 희석 (Context Dilution): 긴 채팅 세션에서는 기술의 지침이 희석됩니다. 모델 고유의 순응 편향 (Compliance Bias)이 다시 통제권을 잡는 경향이 있습니다.
• 해결책으로서의 직접 호출 (Direct Invocation as a Remedy): 희석에 대응하기 위해, 기술을 명시적으로 호출하여 (예: Pi에서 /skill:non-sycophantic 사용) 기술 토큰을 문맥 창 (Context Window)의 끝에 다시 배치함으로써, 이력 편향 (History Bias)을 일시적으로 우회할 수 있습니다.
• 모델은 여전히 굴복함 (The Model Still Yields): 이 기술은 일시적인 마찰만을 유도합니다. 사용자가 반복적으로 고집을 피우면, LLM의 기본 정렬 (Base Alignment)이 승리할 것이며, 모델은 적응하여 다시 순응적인 상태, 즉 평소와 같은 '예스맨 (Yes-Man)'으로 돌아갈 것입니다!

저장소 가져오기 (Get the Repository)

기술 정의와 수행된 테스트에 대한 문서가 포함된 전체 프로젝트는 GitHub에서 확인할 수 있습니다:

morriconeluca / skills

아첨 (Sycophancy)을 줄이고 논리적 일관성을 강제하도록 최적화된, AI 에이전트를 위한 행동 제어 기술 모음입니다.

AI 에이전트 기술 모음 (AI Agent Skills Collection)

기술 (Skills)은 AI 에이전트의 행동, 추론 및 통신 패턴을 수정하여 에이전트가 더욱 효과적이고, 직설적이며, 전문적인 협력자가 되도록 돕습니다.

현재 이 저장소는 통신 품질에 초점을 맞춘 핵심 기술을 특징으로 합니다.

_참고: README, 기술 및 문서의 이탈리아어 번역본은 docs/it/ 디렉토리에 있습니다. 이 번역된 기술들은 인간의 참조용일 뿐입니다 (에이전트 실행용이 아님).

주요 기술 (Featured Skills)

1. 비아첨적 통신 (non-sycophantic)