저는 AI 스레드에서 계속해서 똑같이 잘못된 질문이 나오는 것을 봅니다:

GPT-5, Claude, Qwen, 또는 Llama가 벌써 법률 업무를 할 수 있나요?

그 질문은 곧바로 최악의 데모들로 이어집니다.

매끄러운 텍스트, 가짜 자신감, 그리고 누군가 실제로 확인하기 전까지는 그럴싸해 보이는 인용문들을 보게 됩니다.

그러다 저는 일본에서의 이혼 및 양육권 소송 중에 OpenClaw를 사용한 누군가가 r/openclaw에 올린 스레드를 접하게 되었는데, 이는 제가 본 법률 에이전트 (legal-agent) 설정 중 운영 측면에서 가장 제정신이라고 느껴진 첫 번째 사례였습니다.

화려했기 때문이 아닙니다.

제약(constrained)이 있었기 때문입니다.

사용자는 OpenClaw에게 변호사가 되어달라고 요청하지 않았습니다. 그들은 OpenClaw를 수많은 기록에 접근할 수 있지만 스스로 행동할 권한은 전혀 없는, 매우 규율 잡힌 법률 보조원 (paralegal)처럼 사용하고 있었습니다.

그 차이가 모든 것을 결정합니다.

전체 설정을 신뢰할 수 있게 만든 단 하나의 규칙

이 문장이 핵심이었습니다:

“경계(Boundaries)가 존중됩니다. 나의 명시적인 승인 없이는 외부로 그 어떤 것도 전송되지 않습니다. 그것은 초안을 작성하고, 내가 승인합니다.”

그것이 법률 AI를 위한 올바른 아키텍처 (architecture)입니다.

다음과 같은 것이 아닙니다:

• “이제 모델이 똑똑해졌다”
• “벤치마크 점수가 더 높아졌다”
• “법률 시스템 프롬프트 (system prompt)를 추가했다”

그저 엄격한 경계입니다:

OpenClaw가 초안을 작성한다.
인간이 승인한다.

이것은 대부분의 법률 AI 담론보다 더 성숙한 접근 방식입니다.

실제 스택 (stack)의 모습

사용자는 Mac mini에서 Discord 채널, Obsidian 리포지토리 (repo), 그리고 이메일, 캘린더, 파일 시스템에 대한 접근 권한을 가진 설정을 설명했습니다.

약 6개월 동안 그들은 이를 다음과 같은 용도로 사용했습니다:

• 수천 개의 사건 증거물 (case artifacts) 정리
• 연대기 (chronology) 유지
• 문서 번역
• 이중 언어 서신 초안 작성
• 출처 간의 증거 교차 확인
• 변호인을 위한 개인 사건 사이트 구축

아키텍처는 한 줄로 설명할 수 있을 만큼 간단했습니다:

Mac mini + Discord + Obsidian + 이메일/캘린더/파일

이것은 “AI 변호사”가 아닙니다.

이것은 증거 운영 스택 (evidence operations stack)입니다.

그렇기에 이것이 대부분의 챗봇 데모보다 더 안전하게 느껴지는 것입니다.

유용한 법률 에이전트 패턴은 사람들이 원하는 것보다 더 좁습니다

모델에게 최종적인 법률적 답변을 요구하는 순간, 당신은 모델을 가장 취약한 행동 방식으로 몰아넣게 됩니다.

LLM (Large Language Models)은 패턴을 완성하고 싶어 합니다. 답변이 마무리된 것처럼 들리고 싶어 하죠.

그것이 바로 법률 업무에서 당신이 원하지 않는 바로 그 지점입니다.

하지만 업무 범위를 좁히면, 에이전트(agents)는 훨씬 더 유용해집니다.

실제로 의미 있는 네 가지 작업은 다음과 같습니다:

1. 연대기(chronology) 정리
2. 전송하지 않고 번역 및 초안 작성
3. 시스템 간 증거 교차 참조(cross-reference)
4. 취약한 근거 및 누락된 인용(citations) 표시

이것이 패턴입니다.

"법률 업무를 수행하라"가 아닙니다.

그보다는 "출처(provenance)를 잃지 않으면서 엉망인 기록을 관리하도록 도와달라"에 가깝습니다.

이것이 원샷(one-shot) 법률 챗봇보다 더 나은 이유

원샷 챗봇은 빠르게 답변할 수 있습니다.

하지만 근거 없는 헛소리를 자신 있게 내뱉을 수도 있습니다.

저는 다음과 같이 말하는 느린 워크플로(workflow)를 택하겠습니다:

이 주장은 다음 항목에 의해 뒷받침됩니다:
- 사진
- 타임스탬프(timestamp)
...

...다음과 같이 말하며 인용을 지어내는 빠른 워크플로보다는 말이죠:

관련 법률에 근거하여...

이 허위 인용(false-citation) 문제는 스레드에서도 언급되었는데, 솔직히 말해 다행입니다. 사람들은 이에 대해 편집증적일 정도로 경계해야 합니다.

해결책은 막연한 원칙으로서 "모델을 덜 신뢰하라"가 아닙니다.

해결책은 모델이 주로 다음 사항들을 처리하도록 워크플로를 설계하는 것입니다:

• 검색 (retrieval)
• 구조화 (structure)
• 초안 작성 (drafting)
• 비교 (comparison)
• 증거 순위 지정 (evidence ranking)

최종적인 법적 권위(final legal authority)가 아니라 말입니다.

가장 영리한 부분: 증거 신뢰도 계층 (evidence confidence tiers)

전체 설정에서 가장 훌륭한 디테일은 사용자가 증거의 강도를 생각하는 방식이었습니다.

그들은 사진과 스마트워치의 GPS 데이터를 교차 참조하여, 아이와 함께 보낸 시간에 대해 타임스탬프가 찍힌 계층적 기록을 구축하는 육아 일기를 설명했습니다.

그 패턴은 기본적으로 다음과 같았습니다:

사진 존재 -> 사진 + GPS 경로가 위치를 확인

이것은 "AI가 내 파일을 요약했다"라는 프레임보다 훨씬 더 나은 프레임입니다.

모든 증거가 동일하지 않기 때문입니다.

• 스크린샷은 메타데이터가 포함된 스크린샷과 같지 않습니다.
• 사진은 GPS로 입증된 사진과 같지 않습니다.
• 기억된 날짜는 이메일, 캘린더, 메시지 내보내기를 통해 확인된 날짜와 같지 않습니다.

이 아이디어는 매우 범용적으로 적용될 수 있습니다.

다음 분야에서 작동합니다:

• 법률 보조 (legal assist)
• 컴플라이언스 검토 (compliance reviews)
• 인사(HR) 조사
• 보험 분쟁
• 내부 감사

즉, 다음을 구분해야 하는 모든 곳에서 유용합니다:

artifact exists (아티팩트가 존재함)

artifact is corroborated (아티팩트가 상호 확인됨)

OpenClaw 스타일의 에이전트가 일반적인 채팅과 다르게 느껴지는 이유

OpenClaw의 흥미로운 점은 단순히 채팅을 한다는 것이 아닙니다.

ChatGPT도 채팅을 합니다. Claude도 채팅을 합니다. 로컬 Qwen도 채팅을 합니다.

진정으로 유용한 부분은 에이전트가 여러 연결된 시스템에서 정보를 가져와 사용자가 검토할 수 있는 방식으로 상호 참조(cross-reference)할 수 있을 때입니다.

그것이 진정한 업그레이드입니다.

접근 방식에 대한 비교는 다음과 같습니다:

만약 실제 법률 보조 업무를 위해 하나를 선택해야 한다면, 저는 언제나 OpenClaw 패턴을 선택할 것입니다.

그것이 마법 같아서가 아닙니다.

증거를 존중하기 때문입니다.

직접 이 시스템을 구축한다면, 제가 사용할 아키텍처는 다음과 같습니다

높은 수준(High level)에서의 흐름:

sources (소스) -> ingestion (수집) -> normalization (정규화) -> chronology (연대기) -> evidence scoring (증거 점수화) -> drafting (초안 작성) -> human review (인간 검토)

더 구체적으로는:

email exports (이메일 내보내기)
calendar events (캘린더 이벤트)
chat logs (채팅 로그)
...

증거 계층(evidence layer)을 명시적으로 모델링하고 싶다면, 간단한 스키마(schema)만으로도 도움이 됩니다:

{
  "claim": "2024-03-14 학교 픽업 시 부모가 참석함",
  "support_level": "corroborated (상호 확인됨)",
...
}

이는 "부모가 관여한 것으로 보임"이라고 말하는 텍스트 덩어리보다 훨씬 더 유용합니다.

신뢰 모델은 간단합니다: 적절하게 불신하십시오

에이전트 중심의 워크플로우를 신뢰할 수 있을까요?

오직 적절하게 불신할 수 있을 때만 가능합니다.

그것이 역설입니다.

잘 만들어진 버전이라도 명백한 실패 모드(failure modes)가 존재합니다:

• 요약 과정에서 미묘한 차이(nuance)가 평탄화됨
• 번역에서 어조(tone)를 놓침
• 추출된 타임라인이 잘못된 날짜를 영구적으로 전파할 수 있음
• 인용(citations)이 틀릴 수 있음
• 신뢰도(confidence)가 실제보다 높게 보일 수 있음

따라서 모델보다 안전장치(safeguards)가 더 중요합니다.

저의 기본 규칙은 다음과 같습니다:

1. 모든 주장(claim)에 소스 링크를 첨부할 것

타임라인 항목이 존재한다면, 그것은 근거가 되는 아티팩트(artifact)로 다시 연결되어야 합니다.

주장(claim) -> 소스 문서(source document) -> 정확한 메시지/사진/이메일/이벤트

2. 신뢰도 단계(confidence tiers)를 명시적으로 표시할 것

다음 항목들을 서로 모호하게 섞지 마십시오:

• 가능성 있음 (possible)
• 뒷받침됨 (supported)
• 확증됨 (corroborated)

3. 법률 인용(legal citations)은 검증될 때까지 신뢰할 수 없는 것으로 취급할 것

GPT-5, Claude, Qwen 또는 그 어떤 것이라도 권위 있는 근거를 제공한다면, 그것이 틀릴 수도 있다고 예상하고 검증하십시오.

때로는 실제로 틀리기 때문입니다.

이것이 제대로 작동할지를 실제로 결정하는 지루한 문제

가장 큰 문제는 모델의 IQ가 아닙니다.

바로 운영(operations)입니다.

OpenClaw를 강력해 보이게 만드는 바로 그 Reddit 스레드들이 OpenClaw를 취약해 보이게 만들기도 합니다:

• 업데이트로 인한 오류 (breaking updates)
• 고정된 버전 (pinned versions)
• 속도 대 품질의 트레이드오프 (speed vs quality tradeoffs)
• 비용이 많이 드는 프롬프트 (expensive prompts)
• 일관되게 실행하기에 너무 번거로워지는 워크플로 (workflows)

수천 개의 메시지를 인덱싱하고 몇 달 동안 기록을 다시 검토해야 한다면, 이 점은 매우 중요합니다.

당신에게는 다음이 필요합니다:

• 버전 관리 규율 (version discipline)
• 백업 (backups)
• 반복 가능한 워크플로 (repeatable workflows)
• 안정적인 커넥터 (stable connectors)
• 예측 가능한 LLM 비용 (predictable LLM costs)

마지막 항목은 사람들이 인정하는 것보다 훨씬 더 중요합니다.

법률 보조 파이프라인(legal-assist pipeline)은 많은 반복 작업을 수행합니다:

• 검색 (retrieval)
• 비교 (comparison)
• 번역 (translation)
• 초안 재작성 (redrafting)
• 타임라인 업데이트 (timeline updates)
• 증거 재확인 (evidence re-checking)

매 단계가 택시 미터를 올리는 것처럼 느껴진다면, 사람들은 분석을 아끼기 시작합니다.

그 지점에서 토큰당 과금 방식(per-token pricing)이 이상할 정도로 파괴적인 영향을 미칩니다.

당신은 재검토를 중단하게 됩니다.
유용한 비교를 건너뛰게 됩니다.
넓은 컨텍스트 윈도우(context windows) 사용을 피하게 됩니다.
에이전트가 지루하지만 필수적인 검토 단계를 수행하도록 맡리기를 주저하게 됩니다.

그러면 워크플로는 더욱 악화됩니다.

이러한 에이전트 중심의 프로세스에는 월정액 요금제(flat monthly pricing)가 운영하기에 훨씬 더 쉽습니다.

그것이 바로 여기서 Standard Compute가 흥미로운 이유 중 하나입니다. 이는 예측 가능한 월정액 요금으로 무제한 AI 컴퓨팅 (AI compute)을 제공하며, 즉시 사용 가능한 OpenAI 호환 API (OpenAI-compatible API)로 작동하고, 가끔씩 사용하는 채팅 용도보다는 자동화 (automations) 및 에이전트 (agents)를 위해 구축되었습니다.

만약 여러분이 OpenClaw, n8n, Make, Zapier 또는 자체 스택 (stack)에서 법률 지원 (legal-assist), 컴플라이언스 (compliance), 또는 증거 중심의 워크플로 (workflows)를 연결하고 있다면, 예측 가능한 비용은 벤치마크 (benchmark) 성능을 과시하는 것보다 훨씬 더 중요합니다.

유용한 질문은 다음과 같은 것이 아닙니다:

어떤 모델이 가장 똑똑한가?

진짜 질문은 이것입니다:

이 워크플로가 토큰 소모 (token burn)를 걱정하지 않고 한 달 내내 실행될 수 있는가?

이것이 실제 엔지니어링 문제에 훨씬 더 가깝습니다.

실질적인 구현 스케치

만약 제가 이 워크플로를 프로토타이핑 (prototyping)한다면, 의도적으로 제어 흐름 (control flow)을 지루하게 유지할 것입니다.

# 1. 산출물 (artifacts) 수집
python ingest_email.py
python ingest_calendar.py
...

그리고 승인 경계 (approval boundary)를 절대 놓칠 수 없도록 만들 것입니다:

if outbound_message.status != "approved_by_human":
    raise Exception("차단됨: 외부 전송에는 명시적인 승인이 필요합니다")

이 단 하나의 가드레일 (guardrail)이 더 나은 프롬프트 (prompt)보다 더 가치 있습니다.

훔칠 만한 가치가 있는 패턴

최고의 에이전트 워크플로는 보통 "전문가를 대체하는 것"이라기보다 "시스템에 명확한 증거 게이트 (evidence gates)가 있는 한정된 작업을 부여하는 것"에 가깝습니다.

이는 법률 지원에 완벽하게 부합합니다.

합리적인 워크플로는 다음과 같습니다:

1. 이메일, 캘린더, 파일, 노트, 내보내기 및 미디어에서 기록 수집
2. 날짜, 이름, 언어 및 문서 유형 정규화 (Normalize)
3. 출처 참조를 포함한 연대기 구축
4. 약한 산출물부터 상호 확인된 기록까지 증거 강도 점수화
5. 요약 또는 서신 초안 작성
6. 취약한 주장, 누락된 근거 및 검증되지 않은 인용구 표시
7. 외부로 전송되기 전 반드시 인간의 검토 요구

이것이 전부입니다.

로봇 변호사라는 환상은 필요 없습니다.

나의 견해

여기서의 돌파구는 사람들이 원하는 것보다 작지만, 대부분의 데모 (demos)보다 유용합니다.

AI가 가치 있기 위해서 반드시 변호사를 대체할 필요는 없습니다.

그저 사람들이 증거를 더 잘 다룰 수 있도록 도와주기만 하면 됩니다:

• 증거 정리 (organize)
• 증거 교차 참조 (cross-reference)
• 증거 번역 (translate)
• 증거 순위 지정 (rank)
• 증거를 바탕으로 초안 작성 (draft)
• 승인 과정에 인간을 포함 (keep humans in the approval loop)

그것만으로도 이미 대단한 일입니다.

따라서 저의 주관적인 견해는 이렇습니다:

법률 자동화는 최종 답변을 요구하는 것을 멈추고, 인간의 검토 (human review)가 포함된 증거 파이프라인 (evidence pipelines)을 구축하기 시작하는 순간 유용해집니다.

정답 엔진 (answer engines)이 아니라,

증거 파이프라인 (evidence pipelines)이어야 합니다.

해당 OpenClaw 설정은 그 경계를 진정으로 존중하는 제가 본 첫 번째 법률 에이전트 (legal-agent) 사례입니다.

그리고 이해관계가 큰 (high-stakes) 워크플로우 (workflows)에서는, 바로 그 경계가 가장 중요합니다.