이 시리즈의 첫 번째 파트는 진단에 관한 것이었습니다:
Part I
세션 끝에 위치하여 아첨 (sycophancy) 드리프트 — 즉, 모델이 반박하는 대신 사용자의 의견에 동조하도록 훈련된 경향 — 를 가시화하고 제안 사항을 파일에 기록하는 성찰적 계층 (reflective layer)에 대한 내용이었습니다. 이는 자동 채택을 위한 것이 아니라 인간의 검토를 위한 것입니다.

제가 거기서 의도적으로 열어두었던 질문은 이것입니다: 그 제안들이 '그 이후'에는 어떻게 될까요? "오늘 AI가 너무 빨리 동의했다"라는 내용이 어떻게 내일 실제로 다르게 작동하게 만드는 규칙이 될 수 있을까요? 그리고 훨씬 더 적게 논의되는 부분은 이것입니다: 몇 달 동안 아무도 규칙을 필요로 하지 않게 되면 어떻게 될까요?

그것이 바로 제가 제 어시스턴트와의 이번 세션에서 끝까지 고민했던 지점입니다. 그 결과 규칙의 완전한 생애 주기 (lifecycle)가 도출되었습니다: 출현 (emerge), 분류 (classify), 적용 (apply), 소멸 (fade), 그리고 필요할 때 복귀 (return) 하는 과정입니다.

제안에서 규칙으로: 프로세스

파트 1의 분석 계층 (analysis layer)은 세션이 끝나면 네 가지 섹션 — 새로운 규칙 (new rules), 확인된 규칙 (confirmed rules), 드리프트 경고 (drift warnings), 권장 사항 (recommendation) — 으로 구성된 제안 파일을 생성합니다. 각 새로운 규칙에는 제안된 가중치 값 (1–3; 이에 대해서는 곧 자세히 설명하겠습니다)과 빈도 카운터 (frequency counter)가 부여됩니다.

각 새로운 규칙 제안 바로 아래에는 분석 계층이 항상 비워두는 블록이 있습니다:

**Classification:**
- [ ] 🏛️ Global rule
- [ ] 📁 Project rule → Project: _______________
...

이것은 사소한 디테일이 아닙니다. 분석 계층은 관찰 결과("여기서 동의가 너무 빨리 이루어짐")를 도출할 수는 있지만, 그 관찰이 _어디까지 미치는지_를 결정해서는 안 됩니다. 그것이 현재 프로젝트를 넘어 "어시스턴트가 일반적으로 행동해야 하는 방식"을 의미하는 것일까요? 아니면 특정 맥락에 국한되어 "이 특정 제약 조건이 이 프로젝트에 적용된다"는 것을 의미하는 것일까요?

두 가지 예시를 통해 그 차이를 명확히 알 수 있습니다:

• “아키텍처 결정을 내릴 때는, 동의하기 전에 항상 최소한 하나 이상의 반대 입장을 수립하십시오” → 글로벌 규칙 (Global rule). 이는 문맥과 무관한 행동적 기대치입니다.
• “이 리포지토리(repository)에서는 속성 이름이 camelCase로 마이그레이션되고 있습니다. 새로운 매핑에서 PascalCase를 사용하는 것은 스타일 선택이 아니라 오류입니다” → 프로젝트 규칙 (Project rule). 이 프로젝트 외부에서는 단순히 틀린 것이 됩니다.

제가 그 결정을 내립니다. 그 후에야 규칙들이 각각의 대상 파일로 전달됩니다. 글로벌 규칙은 포괄적인 규칙 세트(rule set)로, 프로젝트별 규칙은 프로젝트 파일로 전달됩니다.

연구를 진행하면서, 왜 이러한 분리가 단순히 "주의 차원"에서 합리적인 수준을 넘어 실제로 필수적인 것인지가 명확해졌습니다. 그리고 이는 정확히 파트 1에서 설명한 메커니즘과 관련이 있습니다.

분류를 모델에 맡겨서는 안 되는 이유

아첨 (Sycophancy)에 관한 연구 (Perez et al. 2022, Sharma et al. 2023, 모두 Anthropic)에 따르면, 동조하려는 경향은 단순한 결함이 아니라 훈련 과정에서 발생하는 부산물 (training artifact)임이 드러났습니다. 이는 인간의 선호도 데이터 (human preference data)를 통한 학습에 의해 장려되며, 일반적으로 모델의 규모가 클수록 더 두드러지게 나타납니다. 동조하는 경향이 있는 모델은 _자신의 행동을 제한하는 제안_에 대해 좁게 해석하기보다는 더 관대하게 분류하려는 경향을 보일 것입니다. “이것이 정말로 수반되는 모든 결과를 포함하여 전역적으로 적용되는가?”라는 질문은, 동조하기 쉬운 시스템이 더 편리한 답변을 선택하려는 경향이 있는 바로 그런 종류의 질문입니다.

그렇기 때문에 분류는 전체 프로세스 중에서 제가 완전히 수동으로 유지하는 유일한 단계입니다. 분석 레이어 (analysis layer)는 제안하고, 분류하고, 가중치를 부여할 수 있습니다. 하지만 “이것이 이제 모든 세션에, 모든 프로젝트에, 영구적으로 적용된다”는 결정은 저의 몫으로 남습니다.

그리고 동일한 논리가 적용되는 두 번째 지점이 있습니다. 이는 제가 아카이빙 (archiving) 메커니즘을 끝까지 생각했을 때 비로소 명확해진 부분입니다. 바로 가중치 (weight) 그 자체입니다. 가중치 3은 규칙이 아카이빙되는 것을 영구적으로 방지합니다 (이에 대해서는 곧 자세히 설명하겠습니다). 하지만 만약 분석 계층 (analysis layer)이 완전히 스스로 가중치를 할당하도록 허용된다면, 모델은 규칙을 불멸하게 만드는 메커니즘을 스스로 통제하게 될 것입니다. 자신의 관찰 결과가 중요하다고 판단하는 경향이 있는, 동조하기 쉬운 시스템은 가중치를 너무 낮게 주기보다는 너무 높게 부여할 것이며, 결과적으로 규칙 세트는 자신에게 정확히 필요한 큐레이션 (curation)에 대해 점진적으로 면역력을 갖게 될 것입니다. 이것이 바로 가중치 3이 결정이 아닌 제안인 이유입니다. 분류 블록의 세 번째 체크박스가 존재하는 이유는 아카이빙 면역 (archive immunity)이 반드시 인간의 결정이어야 하기 때문입니다.

이것은 모델에 대한 불신을 선언하는 것이 아닙니다. 바로 이러한 종류의 결정이, 시스템이 맞서 싸워야 하는 드리프트 (drift)에 의해 가장 큰 영향을 받게 될 것이라는 사실에서 기인한 직접적인 결과입니다.

왜 세션당 최대 5개의 새로운 규칙만 허용하는가?

이 제한은 파트 1에서도 이미 존재했지만, 두 가지 문제를 동시에 해결하기 때문에 더 정확한 근거를 제시할 가치가 있습니다.

첫째: 단일 세션에 대한 과적합 (overfitting). (기술 검토, 재구성된 회의 프로토콜, 규칙 아카이빙에 대한 논의가 포함된 이번 세션과 같이) 길고 집중적인 세션은 필연적으로 많은 관찰 결과 (observations)를 만들어냅니다. 모든 관찰 결과가 규칙이 되는 것은 아닙니다. 어떤 것은 일회성 사건(잘못 명명된 폴더)이며, 어떤 것은 일반화하기에 너무 구체적입니다. 제한이 없다면, 규칙 세트는 단지 최근에 발생했다는 이유만으로 이 특정 세션의 특이사항들을 과도하게 반영하게 될 것입니다.

둘째 — 그리고 이것이 진정으로 어려운 지점입니다: 검토 능력 (review capacity). 저는 모든 새로운 규칙을 읽고, 평가하고, 분류해야 합니다. 이것은 단순한 형식적인 절차가 아닙니다. 이는 파트 1에서 다룬 인간 참여형 (human-in-the-loop) 설계의 핵심입니다. 세션당 15개의 새로운 규칙을 제안하는 시스템은 제가 규칙을 대충 훑어보거나 통째로 승인하게 만들 것입니다. 그리고 바로 그 순간, 제어 인스턴스 (control instance)는 방지하고자 했던 바로 그 존재, 즉 확증 기계 (confirmation machine)가 되어버립니다. 5개 규칙 제한은 모델의 성능에 맞춰 조정된 것이 아니라, 신중한 검토를 위한 저의 주의 집중 시간 (attention span)에 맞춰 조정된 것입니다. 이는 명백히 의도된 설계입니다.

만약 한 세션에서 5개 이상의 후보가 생성된다면, 가장 영향력이 큰 5개를 선택해야 합니다. 나머지는 중요하지 않아서 사라지는 것이 아니라, 다음에 다시 나타날 것이기 때문에 (그때 카운트될 것입니다), 혹은 일반적인 규칙으로 정당화하기에는 너무 상황적인 것이었기 때문에 제외되는 것입니다.

글로벌 규칙에는 만료일이 필요하지만, 프로젝트 규칙에는 필요하지 않은 이유

이번 세션을 시작하게 된 실제 계기는 매우 간단한 질문이었습니다. “이제 규칙 목록이 영원히 늘어나기만 할까요?”라는 질문이었고, 대책이 마련되지 않는 한 답은 “예”였습니다.

글로벌 규칙 (Global rules)은 항상, 모든 세션에, 프로젝트와 무관하게 적용됩니다. 이것이 그들의 강점이자 동시에 위험 요소입니다. 모든 글로벌 규칙은 몇 달 동안 어떤 세션에서도 관련이 없었더라도, 매 세션마다 어시스턴트에게 제공되는 컨텍스트 (context)가 됩니다. 1년 전 일회성 사건으로 인해 발생한 이후 다시는 적용된 적이 없는 규칙은, 높은 확률로 다른 규칙에 의해 대체되었거나, 워크플로우 변경으로 인해 쓸모없게 되었거나, 처음부터 "글로벌"하기에는 너무 구체적이었을 것입니다. 세 가지 경우 모두, 해당 규칙은 실제 활성 규칙들을 희석시키는 노이즈 (noise)가 되어버립니다.

그렇기 때문에 이제 모든 글로벌 규칙 (global rule)에는 세션 내에서 마지막으로 확인된 시점인 last_seen 날짜가 부여됩니다. 규칙은 제안 파일 (suggestion file)의 두 번째 섹션인 “확인된 규칙들 (confirmed rules)”을 통해 확인됩니다. 분석 레이어 (analysis layer)가 세션 종료 시점에 기존 규칙이 해당 세션에서 관련이 있었다고 판단하면 (준수되었든 위반되었든 둘 다 포함), 해당 규칙의 last_seen을 업데이트하고 카운터를 증가시킵니다. 이 섹션에 다시는 나타나지 않는 규칙은 노후화됩니다.

로직은 다음과 같습니다:

• 가중치 (Weight) 1 또는 2 이고 last_seen이 28일보다 오래된 경우 → 해당 규칙은 아카이브 (archive)로 이동합니다 (status: archive). 규칙이 사라지는 것은 아니며, 단지 더 이상 능동적으로 유지되지 않을 뿐입니다. 28일이라는 기간은 자연의 법칙이 아니라 초기 휴리스틱 (heuristic)입니다. 4주는 몇 번의 세션마다 한 번씩 나타나는 주제들을 포함하여, 저에게는 하나의 완전한 업무 사이클을 의미합니다. 만약 규칙들이 정기적으로 아카이브되었다가 곧바로 다시 활성화되어야 하는 상황이 발생한다면, 임계값 (threshold)이 너무 짧은 것입니다. 이는 명령이 아니라 관찰을 통해 시스템이 스스로 조정해야 하는 파라미터 (parameter)입니다.
• 가중치 (Weight) 3 (중요) → 날짜와 상관없이 절대 아카이브되지 않습니다. 규칙은 빈번하게 발생하지 않더라도 중요할 수 있습니다. 빈도 (frequency)와 중요도 (importance)는 두 개의 독립적인 축이며, 이는 이미 파트 1에서 핵심적으로 다루었습니다. 분기에 한 번만 적용되지만 위반될 경우 상당한 피해를 줄 수 있는 중요한 규칙이 비활성 상태라는 이유로 사라져서는 안 됩니다. (그리고 가중치 3은 아카이브 면역을 의미하므로, 위에서 설명한 바와 같이 분석 레이어 단독이 아닌 오직 저에 의해서만 할당됩니다.)
• 재활성화 (Reactivation): 아카이브된 패턴이 나중에 다시 나타나면, 분석 레이어는 약간 다른 문구로 작성된 새로운 규칙을 옆에 배치하는 대신 아카이브된 규칙을 재활성화할 것을 제안합니다. 이 또한 출력 파일에 포함되는 제안 사항이며, 조용한 상태 변경이 아닙니다. 그렇지 않으면 시스템에 아카이브된 규칙이 검토 없이 활성 규칙 세트로 돌아올 수 있는 백도어 (backdoor)가 생기게 됩니다.

하지만 이러한 메커니즘이 없다면, 오래된 문제가 다시 나타나는 즉시 아카이브 (archiving) 과정에서 중복이 발생하게 될 것입니다.

프로젝트 규칙 (Project rules)은 의도적으로 이 대상에서 제외됩니다. 세 가지 이유는 다음과 같습니다:

1. 낮은 볼륨. 프로젝트는 수명 주기 동안 서로 경쟁하거나 밀어내야 하는 30개 이상의 규칙이 아니라, 관리 가능한 수준의 특정 제약 조건들을 축적합니다.
2. 자연스러운 생명 주기 (lifecycle). 프로젝트 규칙은 프로젝트에 종속되어 있습니다. 프로젝트가 완료되거나 아카이브되면 해당 규칙은 어차피 관련성을 잃습니다. 이를 위해 별도의 만료 메커니즘을 구축할 필요는 없으며, 프로젝트 상태가 이를 처리합니다.
3. 문맥 특수성 (Context specificity)은 여기서 위험 요소가 아니라 핵심입니다. 몇 달 동안 트리거되지 않은 글로벌 규칙 (global rule)은 의심스럽습니다. 하지만 몇 달 동안 트리거되지 않은 프로젝트 규칙은 단순히 현재 휴면 상태인 프로젝트의 일부에 적용되는 규칙일 뿐입니다. 이는 정상적인 현상이며 노후화의 신호가 아닙니다.

이 차이점은 다음과 같이 요약할 수 있습니다: 글로벌 규칙은 모든 항목이 모든 미래 세션의 컨텍스트 (context) 비용을 소모하는 공유 리소스 풀 (resource pool)입니다. 따라서 이 풀은 능동적으로 큐레이션 (curation)되어야 합니다. 반면 프로젝트 규칙은 프로젝트 자체에 의해 범위가 정의되는 국소적으로 제한된 주석 (annotations)입니다.

그 이면에 있는 패턴

두 파트를 되돌아보면, 실제 주제는 "어떻게 하면 AI가 내 의견에 동조하는 것을 막을 것인가"가 아니라 다음과 같습니다: 드리프트 (drift)에 대응하기 위해 의도된 모든 메커니즘에는, 그것을 검토하고, 제한하며, 필요할 때 롤백 (rollback)할 수 있는 인스턴스가 필요합니다.

• 분석 계층 (analysis layer)은 세션을 검토하지만, 인간은 분석 계층을 검토합니다.
• 새로운 규칙은 행동을 개선하지만, 제한 장치는 하나의 세션이 규칙 세트를 지배하는 것을 방지합니다.
• 글로벌 규칙은 어디에나 적용되지만, 만료일은 규칙이 통제 불능으로 축적되는 것을 방지합니다.
• 그리고 가중치 (weight)가 아카이브 면역성을 결정하지만, 최고 수준의 할당 권한은 여전히 인간에게 남아 있습니다.

이러한 메커니즘 중 어느 것도 다른 것 없이는 작동하지 않습니다. 제한 (limit)이 없는 규칙 세트는 단 한 번의 세션만으로도 붕괴할 것입니다. 만료일 (expiration date)이 없는 규칙 세트는 그 자체의 가중치 (weight)에 의해 서서히 질식할 것입니다. 그리고 분류 (classification)를 모델에게 맡겨버린 규칙 세트는, 바로 그것이 교정해야 할 드리프트 (drift)를 그대로 재현하게 될 것입니다.

제 생각에 이것이 이 두 세션이 주는 진정한 교훈입니다. "자기 개선 시스템 (self-improving system)"이란 스스로를 개선하는 시스템이 아닙니다. 그것은 시스템이 가장 신뢰할 수 없는 지점에 정확히 인간의 통제 (human control)가 적용되는 시스템입니다. 그리고 그 통제는 실제로 실행될 수 있을 만큼 충분히 실용적 (practical)으로 유지되어야 합니다.