OpenClaw를 붙여보니 모델보다 먼저 봐야 할 게 있었다
OpenClaw를 붙일 때 처음엔 모델만 잘 고르면 되는 줄 알았다. 아니었다. 모델 이름보다 먼저 봐야 할 게 있었다. 노드가 살아 있는지, 게이트웨이가 붙어 있는지, 채널이 정상인지, 설정한 값과 실제 실행값이 같은지. 여기서 하나만 어긋나도 모델 성능 얘기는 별 의미가 없었다.
처음엔 나도 자연스럽게 “어떤 모델이 제일 똑똑하지?”부터 봤다. 그런데 실제로 막히는 지점은 조금 달랐다. 모델이 멍청해서가 아니라, 애초에 그 모델까지 요청이 제대로 도착하지 않는 경우가 있었다. 허무하지만 이런 일이 제일 시간을 많이 잡아먹는다.
모델보다 상태가 먼저였다
Mac mini에 로컬 자동화 축을 하나 두고 싶었다. Codex가 지금 보는 파일과 화면을 잡는다면, OpenClaw는 뒤에서 반복 작업을 굴리는 쪽으로 생각했다. 말은 단순한데 실제로 붙여보면 “뒤에서 돌아간다”는 말 안에 확인할 게 꽤 많다.
가장 헷갈렸던 건 설정에 적힌 모델과 실제 실행 가능한 모델이 늘 같은 이야기가 아니라는 점이었다. 설정 파일에는 이름을 넣을 수 있어도 런타임에서 그 모델을 못 찾으면 다른 모델로 떨어질 수 있다. 그래서 나는 “설정했다”와 “한 번 실제로 돌아갔다”를 분리해서 보기 시작했다.
내가 보는 순서
- OpenClaw 프로세스가 살아 있는지 본다.
- 게이트웨이가 붙어 있는지 확인한다.
- 채널 상태를 따로 확인한다.
- 모델 목록과 실제 응답 모델을 비교한다.
- 짧은 테스트 작업을 던져 어디서 끊기는지 본다.
예전에는 응답이 안 오면 모델부터 의심했다. 그런데 실제로는 게이트웨이만 떨어져 있던 적도 있었다. 괜히 모델 탓을 했다. 모델은 억울했을 수도 있다. 그 뒤로는 모델 이름보다 연결 상태를 먼저 본다.
운영하면서 헷갈렸던 부분
OpenClaw 같은 런타임은 켜져 있다고 끝이 아니다. 켜져 있는 것, 받을 수 있는 것, 제대로 넘겨주는 것, 결과를 다시 돌려주는 것은 각각 다르다. 화면에는 살아 있는 것처럼 보여도 중간 연결이 막혀 있으면 사용자는 그냥 “응답이 없다”고 느낀다.
이때 로그를 안 남기면 원인을 찾기가 어렵다. 특히 여러 에이전트를 같이 쓰면 더 그렇다. OpenClaw가 문제인지, Hermes가 전달을 못 한 건지, Codex 쪽 작업이 길어진 건지, 텔레그램이 막힌 건지 한 번에 섞인다. 실제로 운영해보니 자동화의 절반은 실행이고, 나머지 절반은 “어디서 멈췄는지 알아내는 구조”였다.
모델을 바꿀 때 남기는 메모
새 모델을 테스트할 때는 이름과 체감만 적지 않는다. 어떤 작업을 던졌는지, 응답이 느린지, 도구 호출이 버티는지, 실패하면 어디로 돌아갈지까지 같이 적는다. 자동화 워커에 붙일 모델은 한 번의 긴 답변보다 같은 형식을 반복해서 지키는지가 더 중요했다.
여기서 욕심을 내면 금방 꼬인다. “이 모델이 더 똑똑해 보이는데?”라는 이유만으로 바꾸면, 다음 날에는 왜 바꿨는지 다시 찾아야 한다. 그래서 요즘은 체감보다 재현성을 더 본다. 멋진 답변 한 번보다, 같은 조건에서 비슷하게 돌아가는 쪽이 운영에는 더 낫다.
Codex와 나눈 선
OpenClaw가 할 수 있다고 해서 전부 넘기지는 않는다. 로컬 파일을 직접 고치고 공개 화면까지 확인해야 하는 일은 Codex가 더 편하다. 반대로 반복 분류, 상태 확인, 초안 후보 만들기처럼 사람이 계속 화면을 볼 필요가 없는 일은 OpenClaw 쪽에 붙일 만하다.
지금 단계에서는 모든 것을 맡기는 것보다 실패해도 영향이 작은 반복 작업부터 붙이는 게 맞다고 본다. 자동화가 된다는 것과 운영할 수 있다는 것은 다르다. 하루 뒤에도 같은 방식으로 원인을 찾을 수 있어야 운영이라고 부를 수 있다. 이 기준을 세우고 나니, OpenClaw는 만능 도구라기보다 반복 작업을 맡길 후보군으로 보는 게 편해졌다.
