AI에게 파일 수정을 맡길 때 — OpenClaw는 어긋나면 멈추고, Hermes는 어긋나도 고친다

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 파일을 통째로 다시 쓰지 않고 바뀔 부분만 골라 고치는 도구(apply_patch)를 AI에게 쥐여 줬다. 방식은 unified diff(통합 diff — 없앨 줄 앞에 -, 추가할 줄 앞에 +를 붙여 변경분만 적는 표기)다. 그런데 이 도구에는 완고한 규칙이 하나 있다 — -로 적은 원본 줄이 실제 파일에 그대로 있지 않으면, 곧장 충돌로 보고 수정을 거부한다. "네가 없앤다고 적은 그 줄이 지금 파일엔 없는데?"라며 멈춰 서는 것이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 파일 도구를 뜯어보니, 정확히 같은 문제를 반대편에서 풀고 있었다. 두 봇 다 파일 능력을 4개 도구(읽기·전체 덮어쓰기·부분 수정·검색)로 쪼갠다는 출발점은 똑같다. 갈림길은 딱 한 지점에서 생긴다 — "AI가 기억으로 재현한 원본 문자열이 실제 파일과 미세하게 어긋날 때 어떻게 할 것인가." OpenClaw는 멈추고 다시 읽으라 하고, Hermes는 너그럽게 흡수해 그냥 성공시킨다. 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 부분 수정에서 원본이 어긋날 때

AI가 파일을 "부분만" 고치려면 먼저 바꿀 위치를 파일 안에서 찾아야 한다. 그런데 LLM(대형 언어 모델 — 자연어로 명령을 받아 행동하는 AI)이 "이 줄을 저 줄로 바꿔"라고 지시할 때, 그 "이 줄"은 AI가 기억으로 재현한 문자열이라 원본과 들여쓰기 한 칸, 따옴표 한 종류만 달라도 어긋나기 일쑤다. 두 봇은 이 어긋남을 정반대로 대한다.

▲ OpenClaw — 원본이 어긋나면 멈추고 다시 읽게

위 다이어그램은 OpenClaw가 부분 수정 요청을 받았을 때 거치는 관문을 보여준다. 핵심은 가운데 판정 하나다 — AI가 "없앤다"고 적은 원본 줄이 지금 파일에 글자 그대로 존재하는지 대조하고, 존재하면 적용하고 아니면 충돌로 보고 거부한다. 이 설계의 의도는 "불확실하면 손대지 말라"다. AI가 가진 원본이 실제 파일과 다르다는 건, AI의 기억이 낡았거나 그새 파일이 바뀌었다는 신호일 수 있으니, 억지로 밀어붙이는 대신 멈춰서 다시 읽게 만든다. 거부가 끝이 아니라 "다시 읽고 새 diff를 만들라"는 다음 행동으로 이어진다는 점이 중요하다.

▲ Hermes — 원본이 어긋나도 너그럽게 찾아 성공

위 다이어그램은 같은 상황을 Hermes가 어떻게 다루는지 보여준다. 정확히 일치하는 곳이 있으면 바로 치환하지만, 어긋나면 OpenClaw처럼 멈추지 않는다. 대신 퍼지 매칭(엄격한 정확 일치 대신, 사소한 차이를 너그럽게 봐주며 찾는 방식)으로 기준을 한 단계씩 풀어 가며 "그래도 여기가 맞겠지" 싶은 자리를 찾아낸다. 어지간해서는 수정이 성공한다. 두 그림을 나란히 놓으면 태도 차이가 선명하다 — 한쪽은 어긋남을 멈춰야 할 신호로 읽고, 다른 쪽은 흡수해야 할 잡음으로 읽는다. 아래 두 섹션에서 각자가 왜 그렇게 정했는지를 하나씩 뜯어본다.

Hermes의 길 — 어긋남을 관대히 흡수한다 (퍼지 매칭 8단계)

Hermes의 부분 수정 도구는 "바꿀 문자열"을 찾을 때 정확 일치를 고집하지 않는다. 실패할 때마다 기준을 한 칸씩 느슨하게 푸는 8단계 사다리를 순서대로 밟는다. 처음부터 느슨하게 찾지 않고 단계적으로 너그러워지는 게 이 설계의 요령이다.

위 다이어그램은 바꿀 문자열을 찾는 시도가 점점 너그러워지는 사다리를 보여준다. 가장 안전한 정확 일치부터 시작해, 실패할 때마다 한 칸씩 기준을 푼다 — 줄 앞뒤 공백을 무시하고, 연속된 공백을 하나로 보고, 들여쓰기 깊이를 유연하게 맞추고, 따옴표 이스케이프와 유니코드 표기 차이를 정규화하고, 끝내 안 되면 바꿀 덩어리의 첫 줄과 끝 줄만으로 범위를 추정한다. 왜 처음부터 느슨하게 찾지 않을까? 느슨한 잣대를 먼저 들이대면 엉뚱한 곳을 잘못 잡을 위험이 크기 때문이다 — 그래서 정확 일치를 먼저 시도하고, 정말 안 될 때만 한 단계씩 위험을 감수한다. 놓치기 쉬운 함정도 하나 챙긴다. 너그러운 단계로 찾았을 땐 AI가 보낸 새 내용을 그대로 박으면 들여쓰기가 깨질 수 있어, 원본의 들여쓰기에 맞춰 다시 정렬한다. 그리고 8단계가 전부 실패해도 그냥 "실패"가 아니라 "파일을 다시 읽어 현재 내용을 확인하라"는 안내와 비슷한 구간 제안을 붙여, AI가 낡은 기억으로 같은 실패를 반복하지 않게 한다. 요컨대 Hermes는 어긋남을 극복할 대상으로 본다.

OpenClaw의 길 — 어긋남을 충돌로 읽고 멈춘다

OpenClaw의 apply_patch는 정반대 전제 위에 선다. AI가 없앤다고 적은 원본 줄이 실제 파일과 다르다면, 그건 억지로 맞춰 줄 사소한 오차가 아니라 "내가 아는 파일이 지금 파일이 아니다"라는 경고라는 것이다. 그래서 관대하게 찾아 주는 대신 충돌로 처리하고 멈춘다. 언뜻 불편해 보이는 이 완고함이, 뜻밖에 동시 편집 방어 역할까지 겸한다.

위 다이어그램은 여러 작업이 같은 파일을 건드리는 상황에서 이 완고함이 어떻게 안전장치가 되는지 보여준다. 내가 파일을 읽은 뒤 아무도 그 파일을 손대지 않았다면, 없앨 줄이 그대로 남아 있으니 패치가 곧장 적용된다. 그런데 그새 다른 작업이 같은 파일을 고쳤다면, 내가 없앤다고 적은 원본 줄은 이미 사라졌거나 달라져 있어 대조가 어긋나고, 그 순간 충돌로 거부된다. 별도의 잠금 장치나 버전 추적 없이, diff의 대조 규칙 자체가 "네가 본 파일은 이미 낡았다"를 자동으로 감지하는 셈이다. 대가는 분명하다 — 원본이 조금만 어긋나도 실패하니, AI가 다시 읽고 diff를 새로 만드는 왕복이 잦아진다. 그러나 그 왕복이야말로 OpenClaw가 원하는 바다. "확실할 때만 쓴다"는 규율을 도구 차원에서 강제하는 것이다.

정리 — 어긋남을 신호로 볼까, 잡음으로 볼까

결국 두 봇은 파일을 4개 도구로 쪼갠다는 같은 출발점에서, 부분 수정의 원본이 어긋나는 한 지점에서 정확히 갈라진다. 한쪽은 어긋남을 멈춰야 할 신호로, 다른 쪽은 흡수해야 할 잡음으로 읽는다.

	OpenClaw (apply_patch)	Hermes (patch)
원본이 어긋날 때	충돌로 보고 즉시 거부 → 다시 읽게 유도	퍼지 매칭 8단계로 흡수해 수정 성공
어긋남을 읽는 관점	"파일이 바뀌었다"는 신호 — 보수적	"사소한 차이"인 잡음 — 실용적

어느 쪽이 옳다기보다, 잘 맞는 환경이 다르다. Hermes의 관대한 퍼지 매칭은 혼자 순차적으로 파일을 고치는 상황에서 강하다 — AI의 기억이 조금 부정확해도 매번 다시 읽는 왕복 없이 술술 진행되니, 마찰이 적고 빠르다. 반대로 OpenClaw의 충돌 거부는 여러 AI 작업이 같은 파일을 동시에 건드리는 상황에서 빛난다 — 남이 바꾼 파일을 낡은 기억으로 덮어써 최신 변경을 조용히 날리는 사고를, 도구가 알아서 충돌로 걸러 내기 때문이다. 그래서 "어느 쪽이 더 나은가"의 답은 결국 하나로 수렴한다 — 여러 작업이 같은 파일을 얼마나 자주 동시에 건드리는 환경이냐. 동시 편집이 드물면 관대함이 이득이고, 잦으면 완고함이 안전이다. 같은 문제 앞에서 두 봇이 내린 반대 결정은, 각자가 상정한 작업 환경이 서로 달랐다는 뜻이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.