19화 2026-06-10

로컬 LLM에게 내 글을 평가시켰더니

10초 멈춤 문제를 쫓던 도중에, 재미 삼아 에이전트한테 장난 같은 질문을 하나 던졌어요. 제가 쓴 16화 글(SKILL.md 만들기 편)을 게시판에서 읽게 한 다음에,

위 글에서 잘못된 부분이 있다면 알려줘. 수정이 필요하다고 생각하는 부분도 알려줘.

가볍게 물어본 거였어요. “잘 썼네요” 정도 나오겠거니 했죠. 그런데 에이전트가 꽤 진지하게, 적나라하게 지적을 쏟아냈어요. 표까지 그려가면서요.

그리고 그 순간, 14화의 기억이 떠올랐어요. 그럴듯한데 진짜인지 의심스러운 답. 오늘은 그 검증 이야기예요.

스크린샷 2026-06-09 22-40-14.png

에이전트의 채점표

에이전트가 내놓은 지적은 이런 식이었어요. 깔끔하게 분류까지 해서요.

“명확한 사실 오류”라며:

작성자는 Skill 폴더 자리를 두 곳만 언급했지만, 현재 OpenClaw 공식 문서는 최소 6개의 로드 소스를 정의합니다.

그러면서 우선순위까지 매긴 표를 그렸어요. ~/.agents/skills, <workspace>/.agents/skills 같은 경로를 6개나요.

“수정을 권장하는 부분”이라며:

게이트웨이 재시작은 systemctl 대신 **openclaw gateway restart**가 권장 방법입니다.

에이전트가 직접 SKILL.md를 수정하는 대신 Skill Workshop을 통해 초안을 제안하고 사용자가 승인하는 워크플로우가 제공됩니다:
openclaw skills workshop list
openclaw skills workshop inspect <id>
openclaw skills workshop apply <id>

이걸 보고 솔직히 좀 놀랐어요. 제 글의 빈틈을 정확히 짚는 것 같았거든요. “내가 두 곳만 적었는데 실은 여섯 군데였다니”, “Skill Workshop이라는 좋은 기능을 내가 놓쳤구나” 싶었죠.

스크린샷 2026-06-09 22-45-05.png

잠깐. 이거 에이전트가 어디서 알아낸 거지?

펜을 들기 직전에 멈췄어요. 한 가지가 걸렸거든요.

에이전트는 지금 “현재 OpenClaw 공식 문서가 이렇게 정의한다”고 단언하고 있어요. 그런데 생각해보면, 제 에이전트한테는 LegalT3ch 게시판을 읽는 통로(MCP)는 붙어 있어도, OpenClaw 공식 문서를 실시간으로 읽을 수단은 없어요. 웹을 뒤지지도 않았고요.

그럼 이 “공식 문서가 이렇다”는 내용은 어디서 나온 걸까. 답은 하나예요. 모델이 학습 때 본 OpenClaw 관련 지식, 즉 기억에서 끌어낸 거예요.

이게 결정적인 차이예요. 17화에서 게시판 글을 가져왔을 땐, 그건 MCP로 실시간으로 서버에서 가져온 사실이었어요. 그래서 진짜였죠(제 글 제목까지 정확했고요). 반면 이 채점표는 도구 없이 모델 기억에서 꺼낸 것이에요. 14화에서 배운 건 “의심스러우면 직접 따져봐야 한다”였는데, 그땐 따져보니 진짜였죠. 이번엔 같은 방식으로 따져봤더니 결과가 달랐어요.

비유하면 이래요. 게시판 글 가져오기는 서류를 캐비닛에서 직접 꺼내다 준 것이고, 이 채점표는 “제 기억으론 그 서류에 이렇게 적혀 있었을 거예요”라고 외워서 말한 것이에요. 후자는 틀릴 수 있어요.

그래서 채점표를 곧이곧대로 안 믿고, 검증하기로 했어요. 방법은 늘 같아요. 에이전트 말을 믿지 말고, 시스템한테 직접 물어본다.

셋 중 둘만 찍어봐도 충분하다

에이전트가 주장한 것 중 확인하기 쉬운 두 개를 골랐어요.

주장 1: openclaw gateway restart가 권장 방법이다.

진짜 그런 명령이 있나? 물어봤어요.

openclaw gateway --help 2>&1 | grep -i restart

restart    Restart the Gateway service

있네요. restart라는 명령이 실제로 존재해요. 이 주장은 (적어도 명령이 실재한다는 점에선) 사실이에요.

주장 2: “Skill Workshop” 워크플로우가 있다.

에이전트가 openclaw skills workshop list 같은 명령을 자신 있게 써놨잖아요. 진짜 있나?

openclaw skills --help 2>&1 | grep -i workshop

(아무것도 안 나옴)

텅 비었어요. workshop이라는 단어가 들어간 명령이 하나도 없어요. 혹시 몰라서 skills 명령 전체를 봤어요.

openclaw skills --help

Commands:
  check     Check which skills are ready, visible, or missing requirements
  info      Show detailed information about a skill
  install   Install a skill from ClawHub into the active workspace
  list      List all available skills
  search    Search ClawHub skills
  update    Update ClawHub-installed skills

check, info, install, list, search, update. workshop은 없어요. 에이전트가 표까지 그려가며 자신 있게 써놓은 그 명령 세 개는, 존재하지 않아요. 통째로 지어낸 거예요.

진짜와 가짜를 같은 표정으로 섞어 내놓는다

이게 환각의 가장 무서운 점이에요. 에이전트는 진짜 정보(gateway restart)와 가짜 정보(skills workshop)를 똑같은 자신감으로, 똑같은 포맷으로 섞어서 내놨어요. 둘 다 표로 정리하고 명령어까지 붙이니까, 보는 사람 입장에선 둘 다 똑같이 믿음직해 보여요. 하지만 하나는 실재하고, 하나는 허구예요.

흥미로운 건, 에이전트가 완전히 허공에서 지어낸 건 아니라는 거예요. skills --help를 보면 진짜로 있는 게 보이죠 — ClawHub라는 스킬 저장소, 그리고 search, install 같은 명령들. 에이전트는 “스킬을 관리하고 공유하는 뭔가가 있다”는 어렴풋한 기억에서 출발해서, 이름과 명령어를 잘못 지어낸 거예요. 방향은 얼추 맞췄는데 구체가 틀린, 전형적인 환각이에요.

“6개 로드 소스” 표도 마찬가지로 의심해야 해요. workshop을 지어낸 모델이 그린 표니까, 그 6개 경로가 진짜인지도 확인 전엔 믿으면 안 돼요.

그러니 에이전트의 채점표를 항목별로 다시 정리하면 이래요.

에이전트의 주장	검증 결과
`openclaw gateway restart` 권장	명령 실재함 (사실)
“Skill Workshop” 워크플로우	존재하지 않음 (환각)
“6개 로드 소스” 표	미검증, 의심 보류
frontmatter 추가 필드들	미검증, 의심 보류

로컬의 한계를 느낀 날

이번 일로 다시 확인한 게 있어요. 지금 제가 쓰는 로컬 모델(qwen3.6:27b)은, 자기가 모르는 영역을 만나면 모른다고 하기보다 그럴듯하게 메우는 경향이 있어요. “Skill Workshop”이 딱 그랬죠. 실재하는 ClawHub를 어렴풋이 기억하고는, 이름과 명령어를 지어내 빈칸을 채운 거예요.

규모가 더 크거나 잘 정렬된 클라우드 모델이라면 “그건 확실치 않다”고 물러섰을 법한 자리에서, 로컬 모델은 자신 있게 채워 넣는 일이 더 잦아요. 모델 크기와 정렬(alignment) 수준의 차이가 이런 데서 드러나요. 18화에서 본 속도 문제(2분 지연)에 이어, 이번엔 정확도 쪽에서 로컬의 한계를 한 번 더 본 셈이에요.

그래서 결론은 단순해요. 로컬 모델을 쓰는 한, 환각은 항상 의심할 수밖에 없다. 특히 도구를 거치지 않고 모델 기억에서 나온 답은요. 똑똑해 보이는 답일수록 그래요.

고민거리도 하나 생겼어요. 지금 정도의 작업(게시판 읽기, 요약)이야 이 모델로 충분하지만, 정확도가 중요한 일을 맡기려면 이 환각 경향을 어디까지 감수할지, 아니면 더 큰 모델이나 다른 모델을 검토할지 생각해봐야겠어요. 데이터를 직접 통제하려고 로컬을 택했는데, 그 대가로 속도와 정확도를 어느 선까지 받아들일지는 계속 따라다니는 숙제예요.

오늘 작업 전체를 관통하는 한 줄

세 편에 걸쳐 한 작업을 돌아보니, 결국 하나의 주제로 모여요.

“도구로 가져온 사실”과 “모델이 기억해낸 것”은 다르다.

17화에서 게시판 글이 진짜였던 이유 → MCP라는 도구로 서버에서 실시간으로 가져왔기 때문
18화에서 게시판 데이터를 실제로 처리한 게 로컬 qwen이었던 이유 → claude-cli는 도구를 못 쓰는 통로였기 때문
19화에서 채점표에 환각이 섞인 이유 → 그건 도구 없이 모델 기억에서 꺼낸 것이기 때문

같은 에이전트가, 도구를 쓸 때는 정확한 사실을 가져오고, 기억에 의존할 때는 그럴듯한 허구를 섞어요. 그 둘을 가르는 건 “에이전트가 얼마나 자신 있게 말하느냐”가 아니에요. **“이 답이 도구를 거쳐 나온 것이냐, 기억에서 나온 것이냐”**예요.

의뢰인 자료를 다룰 때를 생각하면, 이 구분이 더 중요해져요. 에이전트가 “이 계약서엔 이런 조항이 있습니다”라고 할 때, 그게 실제 파일을 읽고 한 말인지 기억으로 지어낸 말인지를 항상 가려야 한다는 뜻이니까요.

오늘의 정리

✅ 에이전트의 자기평가는 환각이 섞여 있었음. 진짜(gateway restart)와 가짜(skills workshop)를 같은 자신감으로 섞어 제시
✅ 검증법은 늘 같음: 에이전트 말 믿지 말고 --help로 시스템한테 직접 물어보기. grep -i workshop이 텅 비면서 환각 확정
✅ 방향은 맞고 구체는 틀린 환각: 실재하는 ClawHub를 어렴풋이 기억하고 “Skill Workshop”이라는 가짜 이름·명령을 지어냄
✅ 로컬의 한계를 본 날: 작은 로컬 모델은 모르는 영역을 그럴듯하게 메우는 경향이 큼. 속도(18화)에 이어 정확도에서도 한계 확인
📌 남은 고민: 정확도가 중요한 일엔 이 환각 경향을 어디까지 감수할지, 더 큰/다른 모델을 볼지 — 데이터 통제(로컬)의 대가로 속도·정확도를 어느 선까지 받아들일지
📌 관통 주제: 도구로 가져온 사실 ≠ 모델이 기억해낸 것. 답의 신뢰도는 자신감이 아니라 “도구를 거쳤는가”로 판단

읽어주셔서 감사합니다.

#모델이야기