OpenClaw를 붙여보니 모델보다 먼저 봐야 할 게 있었다
OpenClaw를 붙일 때 처음엔 모델만 잘 고르면 되는 줄 알았다. 아니었다. 모델 이름보다 먼저 봐야 할 게 있었다. 노드가 살아 있는지, 게이트웨이가 붙어 있는지, 채널이 정상인지, 설정한 값과 실제 실행값이 같은지. 여기서 하나만 어긋나도 모델 성능 얘기는 별 의미가 없었다.
모델보다 상태가 먼저였다
Mac mini에 로컬 자동화 축을 하나 두고 싶었다. Codex가 지금 보는 파일과 화면을 잡는다면, OpenClaw는 뒤에서 반복 작업을 굴리는 쪽으로 생각했다. 말은 단순한데 실제로 붙여보면 “뒤에서 돌아간다”는 말 안에 확인할 게 꽤 많다.
가장 헷갈렸던 건 설정에 적힌 모델과 실제 실행 가능한 모델이 늘 같은 이야기가 아니라는 점이었다. 설정 파일에는 이름을 넣을 수 있어도 런타임에서 그 모델을 못 찾으면 다른 모델로 떨어질 수 있다. 그래서 나는 “설정했다”와 “한 번 실제로 돌아갔다”를 분리해서 보기 시작했다.
내가 보는 순서
- OpenClaw 프로세스가 살아 있는지 본다.
- 게이트웨이가 붙어 있는지 확인한다.
- 채널 상태를 따로 확인한다.
- 모델 목록과 실제 응답 모델을 비교한다.
- 짧은 테스트 작업을 던져 어디서 끊기는지 본다.
예전에는 응답이 안 오면 모델부터 의심했다. 그런데 실제로는 게이트웨이만 떨어져 있던 적도 있었다. 괜히 모델 탓을 했다. 그 뒤로는 모델 이름보다 연결 상태를 먼저 본다.
모델을 바꿀 때 남기는 메모
새 모델을 테스트할 때는 이름과 체감만 적지 않는다. 어떤 작업을 던졌는지, 응답이 느린지, 도구 호출이 버티는지, 실패하면 어디로 돌아갈지까지 같이 적는다. 자동화 워커에 붙일 모델은 한 번의 긴 답변보다 같은 형식을 반복해서 지키는지가 더 중요했다.
Codex와 나눈 선
OpenClaw가 할 수 있다고 해서 전부 넘기지는 않는다. 로컬 파일을 직접 고치고 공개 화면까지 확인해야 하는 일은 Codex가 더 편하다. 반대로 반복 분류, 상태 확인, 초안 후보 만들기처럼 사람이 계속 화면을 볼 필요가 없는 일은 OpenClaw 쪽에 붙일 만하다.
지금 단계에서는 모든 것을 맡기는 것보다 실패해도 영향이 작은 반복 작업부터 붙이는 게 맞다고 본다. 자동화가 된다는 것과 운영할 수 있다는 것은 다르다. 하루 뒤에도 같은 방식으로 원인을 찾을 수 있어야 운영이라고 부를 수 있다.
