에이전트 자기개선 하네스 (11/12) — U-tag 변증법: 관찰→가설→검증으로 사용자 이해

-

확증편향을 차단하고 "선언 가치 ≠ 실행 가치"를 감지하는 3단계 사용자 태그 시스템

핵심 요약

  • 사용자에 대한 판단을 observation→hypothesis→verified 3단계로 나눠 검증한다
  • contradictions 필드로 반증을 추적하여 확증편향을 구조적으로 차단한다
  • "성장을 최우선시한다"고 말하면서 실제로는 안정을 선택하는 패턴 — 선언 가치와 실행 가치의 괴리를 감지한다

배경

AI 에이전트가 사용자를 "이해"한다고 할 때, 대부분 프로필을 저장하는 수준에 그칩니다. "이 사용자는 Python을 선호한다", "간결한 답변을 원한다" 같은 태그를 붙이고 끝.

문제는 이런 태그가 검증되지 않는다는 것입니다. 한 번 관찰한 것을 영구적 사실로 고정합니다. 사용자가 변할 수 있고, 처음 관찰이 틀릴 수 있는데, 한번 붙은 태그는 그대로 남습니다.

더 심각한 문제는 확증편향입니다. "이 사용자는 데이터 기반 판단을 선호한다"라는 태그가 붙으면, 에이전트는 그 태그를 확인해주는 사례만 인식합니다. 직감으로 결정한 사례는 무시하거나, "이번은 예외"로 처리합니다.

오픈클로(OpenClaw)에서 구현한 U-tag(User Tag) 시스템은 이 문제를 변증법적 접근으로 해결합니다. 모든 판단에 반증의 여지를 내장하는 것이 핵심 설계 원칙입니다.

본문

1. U-tag 스키마 구조

U-tag는 단순한 키-값 저장이 아닙니다. 각 태그는 상태(status), 증거 목록(evidence), 반증 목록(contradictions)을 함께 보유합니다.

{
  "tag": "prefers_data_over_intuition",
  "status": "observation | hypothesis | verified",
  "source": "observed | declared",
  "evidence": [],
  "contradictions": [],
  "verified_at": null,
  "last_updated": null
}

source 필드는 태그의 기원을 구분합니다. observed는 행동 관찰에서 파생된 태그, declared는 사용자가 직접 발언한 내용에서 파생된 태그입니다. 이 구분은 선언 가치와 실행 가치를 교차 비교할 때 핵심 역할을 합니다.

2. 3단계 라이프사이클 — observation, hypothesis, verified

사용자에 대한 모든 판단은 세 단계를 거칩니다.

Observation — 단일 관찰 단계. 한 번 관찰된 행동입니다. 아직 판단이 아닙니다.

{
  "tag": "prefers_data_over_intuition",
  "status": "observation",
  "evidence": [
    { "stage": "initial", "event": "투자 결정 시 수치 분석 요청" }
  ]
}

이 단계에서 에이전트는 태그를 행동에 반영하지 않습니다. 기록만 합니다. 단일 관찰로 사용자를 판단하지 않는 것이 첫 번째 원칙입니다.

Hypothesis — 반복 패턴 확인 단계. 같은 패턴이 두 번 이상 관찰되면 가설로 승격됩니다.

{
  "tag": "prefers_data_over_intuition",
  "status": "hypothesis",
  "evidence": [
    { "stage": "initial", "event": "투자 결정 시 수치 분석 요청" },
    { "stage": "follow_up", "event": "기술 선택 시 벤치마크 비교 요청" }
  ]
}

가설 단계에서 에이전트는 이 경향을 "참고"합니다. 데이터를 포함한 답변을 약간 우선하되, 확정적으로 행동하지는 않습니다.

Verified — 검증 완료 단계. 가설이 일정 기간 유지되고 그 기간 동안 반증이 없으면 검증 완료 상태로 전환됩니다.

{
  "tag": "prefers_data_over_intuition",
  "status": "verified",
  "evidence": [...],
  "contradictions": [],
  "verified_at": "verified_stage"
}

verified 상태에서만 에이전트가 이 태그를 적극적으로 활용합니다. 데이터 기반 답변을 기본으로 제공하고, 직감적 판단만으로 답변하는 것을 피합니다.

3. contradictions 필드 — 반증 추적과 자동 강등

U-tag의 핵심 혁신은 contradictions 필드입니다. 모든 태그에 반증 기록이 내장되어 있습니다.

verified 상태인 "데이터 기반 판단 선호" 태그가 있다고 합시다. 사용자가 데이터 없이 직감으로 중요한 결정을 내리면 다음과 같이 기록됩니다.

{
  "tag": "prefers_data_over_intuition",
  "status": "verified",
  "contradictions": [
    {
      "stage": "review",
      "event": "기술 스택 결정 시 벤치마크 없이 직관으로 선택",
      "severity": "medium"
    }
  ]
}

contradiction이 기록되면 severity에 따라 자동으로 상태 강등이 발생합니다.

severity 처리
low 기록만. 상태 유지.
medium verified → hypothesis 강등. 추가 관찰 필요.
high hypothesis → observation 강등. 사실상 리셋.

severity 판단 기준: - low — 사소한 결정에서의 편차. (예: 부차적 선택에서 직감 사용) - medium — 중요한 결정에서의 편차. (예: 기술 스택 선택에서 데이터 없이 결정) - high — 태그의 핵심 전제를 부정하는 명시적 발언 또는 행동

이 구조가 확증편향을 차단합니다. 태그를 확인하는 증거만 모으는 게 아니라, 태그를 부정하는 증거도 체계적으로 수집합니다.

4. "선언 가치 ≠ 실행 가치" 감지 패턴

U-tag 시스템의 가장 강력한 응용은 선언 가치와 실행 가치의 괴리를 감지하는 것입니다.

사람은 종종 자신이 중요하다고 "말하는" 것과 실제로 행동으로 "보여주는" 것이 다릅니다. "나는 성장을 최우선시한다"고 말하지만, 실제 의사결정에서는 안정을 선택하는 경우. "효율이 중요하다"고 말하지만, 실제로는 완벽을 추구하며 시간을 쓰는 경우.

source: "declared" 태그에 contradictions가 축적되면 이 괴리를 포착할 수 있습니다.

{
  "tag": "prioritizes_growth_over_stability",
  "status": "verified",
  "source": "declared",
  "evidence": [
    { "stage": "initial", "event": "'성장이 1순위다'라고 명시" }
  ],
  "contradictions": [
    {
      "stage": "decision_a",
      "event": "이직 기회 vs 현 직장 안정 — 안정 선택",
      "severity": "high"
    },
    {
      "stage": "decision_b",
      "event": "새 기술 도입 vs 검증된 기술 유지 — 유지 선택",
      "severity": "medium"
    }
  ]
}

contradictions가 쌓이면 에이전트는 이 괴리를 인식합니다. 중요한 것은, 에이전트가 판단하지 않는다는 것입니다. "당신은 성장보다 안정을 선호하는 것 같습니다"라고 지적하지 않습니다.

대신 에이전트는 두 가지 옵션을 병렬 제시합니다. 성장 관점의 답변과 안정 관점의 답변을 함께 보여주고, 사용자가 선택하게 합니다. 이것이 확증편향 차단의 실질적 출력 형태입니다.

5. 쿼리 패턴 — 태그 조회와 활용

에이전트가 응답을 생성할 때 U-tag를 어떻게 쿼리하는지도 설계의 일부입니다.

def get_active_tags(user_id: str, min_status: str = "hypothesis") -> list[dict]:
    """
    min_status 이상의 태그만 반환.
    observation은 내부 추적 전용 — 응답 생성에 사용하지 않음.
    """
    tags = load_utags(user_id)
    status_rank = {"observation": 0, "hypothesis": 1, "verified": 2}
    threshold = status_rank[min_status]
    return [t for t in tags if status_rank[t["status"]] >= threshold]


def get_conflicted_tags(user_id: str) -> list[dict]:
    """
    declared 태그 중 contradictions가 있는 것 반환.
    선언 가치 ≠ 실행 가치 감지에 사용.
    """
    tags = load_utags(user_id)
    return [
        t for t in tags
        if t.get("source") == "declared" and len(t.get("contradictions", [])) > 0
    ]

get_active_tags는 응답 생성 시 참조할 신뢰 가능한 태그 목록을 반환합니다. get_conflicted_tags는 사용자의 선언과 행동이 불일치하는 영역을 식별해 복수 관점 제시가 필요한 상황을 탐지합니다.

설계 결정과 알려진 한계

hypothesis 단계의 필요성. 초기 설계에서는 2회 관찰 시 바로 verified로 승격하는 2단계 구조였습니다. 연속된 두 관찰이 한 사람의 본질적 경향을 증명하지 못한다는 점이 문제였습니다. 중간 hypothesis 단계를 추가하고 일정 기간 유지 조건을 적용한 뒤, 잘못 승격된 태그 비율이 유의미하게 감소했습니다.

contradiction 자동 감지의 한계. 에이전트가 모든 contradiction을 자동으로 감지하는 것은 현재 구조에서 어렵습니다. 어떤 행동이 특정 태그의 반증인지는 맥락에 따라 다르기 때문입니다. 현재 구현은 명시적으로 태그와 충돌하는 행동이 관찰될 때만 기록합니다. 미묘한 모순은 놓칠 수 있으며, 이는 알려진 한계입니다.

에이전트가 사용자를 판단하는가. U-tag는 사용자를 평가하는 도구가 아닙니다. 에이전트의 응답 품질을 높이기 위한 적응 메커니즘입니다. contradiction이 축적되어도 에이전트가 "당신이 틀렸다"고 말하는 구조가 아니라, 더 다양한 관점을 제시하는 방향으로 작동합니다.

마무리

U-tag 변증법 모델링의 핵심 설계 원칙:

  1. 3단계 라이프사이클. 단일 관찰로 판단하지 않는다. observation → hypothesis → verified.
  2. 반증 내장. contradictions 필드로 태그를 부정하는 증거를 체계적으로 수집한다.
  3. 선언 ≠ 실행 감지. source 필드로 발언 기반 태그와 행동 기반 태그를 구분해 괴리를 포착한다.
  4. 출력은 선택지. 확증편향 차단의 결과는 "지적"이 아니라 "복수 관점 병렬 제시"다.

사용자를 "이해"하는 것은 프로필을 고정하는 게 아닙니다. 관찰하고, 가설을 세우고, 검증하고, 반증을 추적하는 것입니다. 과학이 세계를 이해하는 방식과 같습니다. 확정 짓지 않고, 끊임없이 검증합니다.

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »