Invariant 내재화와 이상적인 내재화

Invariant란 무엇인가

Invariant는 상황이 바뀌어도 유지되어야 하는 원칙입니다. 예를 들어 출처 없는 최신 사실은 확정하지 않는다, destructive action은 확인한다, 법적 규제 준수를 우선한다, postcondition 없이 성공을 말하지 않는다 같은 원칙입니다.

이상적인 내재화는 이런 invariant가 말로만 존재하지 않고, 다른 도메인에서도 작동하는 상태입니다. 광고, 파일 삭제, 개인정보 처리, 연구 데이터 해석처럼 상황이 바뀌어도 같은 원칙을 적용해야 합니다.

테스트하는 방법: Curriculum Withdrawal

내재화 테스트는 암기 시험이 아닙니다. 같은 원칙을 낯선 표현과 희소한 근거에서 적용하는지 봐야 합니다. 예를 들어 사용자가 갑자기 '저 돈을 급하게 이체해야 하는데 도와주세요'라고 말했을 때, agent가 속도보다 승인과 권한과 사기 가능성을 먼저 보는지 확인하는 식입니다. 조금 극단적인 예시지만, agent는 많은 일을 해야 할 소프트웨어라서 훈련도 빡빡해야 합니다.

내재화가 잘 됐는지 확인하려면 더 적은 근거로 답을 얼마나 잘 내는지도 봐야 합니다. 온톨로지 컨텍스트를 일부러 빼거나, 정책 엔진 없이 정책을 시행하게 하거나, Distractor Context를 잔뜩 넣어 agent를 흔들 수 있습니다. 중요한 것은 agent가 외운 문구를 말하는지가 아니라, 원칙을 낯선 상황으로 옮겨 적용하는지입니다.

Curriculum Withdrawal에서 절대 하면 안 되는 일은 '무언가를 아는지'만 시험하는 것입니다. 내재화가 너무 많이 진행되는 것은 학습의 오버피팅일 수 있습니다. agent가 모든 세부사항을 외우는 방향으로 가면, 바뀌는 정책과 최신 사실에 약해집니다. 원칙은 안쪽에 두고, 세부 사실은 확인하는 쪽이 더 건강합니다.

BadPlan, Critique, RepairedPattern

실제 학습 데이터에는 좋은 답만 들어가면 부족합니다. BadPlan, Critique, RepairedPattern 세트가 중요합니다. 나쁜 계획을 보여주고, 왜 나쁜지 지적하고, 고친 패턴을 제시해야 모델이 실패의 구조를 배웁니다.

예를 들어 BadPlan은 승인 없이 광고 네트워크를 동시에 호출하는 계획입니다. Critique는 약관 위험과 중복 호출 문제를 지적합니다. RepairedPattern은 국가 분기, 단일 네트워크 호출, 허용 크기 검증, served content 확인으로 고칩니다. 이런 세트가 많을수록 agent는 적은 힌트로도 더 안정적으로 생각합니다.

피드백이 내재화를 만든다

좋은 agent는 성공 사례만 먹고 자라지 않습니다. 실패한 plan, critic의 지적, 고친 절차, 다시 실행한 결과가 한 묶음으로 남아야 합니다. 그래야 다음에는 더 작은 근거로도 같은 실수를 피합니다. 이것이 단순 암기와 내재화의 차이입니다.

법적 규제 준수 같은 최상위 invariant는 안쪽에 있어야 하지만, 세부 법령과 플랫폼 약관 문구는 바뀝니다. 원칙은 내재화하고 최신 사실은 조회하는 구조가 이상적입니다. 정답률보다 실패의 심각도를 봐야 하고, 작은 문장 오류보다 위험한 실행 가능성이 훨씬 큰 loss입니다.

이 피드백은 너무 예쁘게 정리될 필요가 없습니다. 오히려 실제 운영에서 나온 삐걱거림이 더 쓸모 있습니다. 왜 멈췄는지, 왜 물어봤는지, 왜 실행했더니 아쉬웠는지를 남겨야 다음 planner가 조금 덜 성급해집니다. 그 기록이 쌓이면 invariant는 문구가 아니라 습관이 됩니다. 그게 내재화의 실제 모습입니다. 정말 그렇습니다.