Codex, OpenClaw, Hermes. 누가 뭘 해야 덜 꼬이나
AI 작업 도구가 하나일 때는 단순하다. 그냥 그 도구에게 시키면 된다. 문제는 Codex, OpenClaw, Hermes가 같이 들어온 뒤였다. 다들 뭔가 할 수 있어 보이니 오히려 더 헷갈렸다. 결국 먼저 정해야 하는 건 “누가 제일 세냐”가 아니라 “이 일은 어디에서 끝나야 하냐”였다.
처음에는 나도 기능표처럼 나눠보려고 했다. 누가 코딩을 잘하는지, 누가 브라우저를 잘 보는지, 누가 오래 기억하는지 같은 식이다. 그런데 실제 작업에서는 기능표보다 위치가 더 중요했다. 로컬 파일을 고쳐야 하는 일인지, 반복으로 돌릴 일인지, 밖에서 던지고 결과만 받을 일인지에 따라 답이 달라졌다.
기능표보다 작업 위치를 먼저 본다
도구를 고를 때 지능 순위부터 보지 않는다. 로컬 파일을 고쳐야 하는지, 브라우저 화면을 확인해야 하는지, 뒤에서 반복만 돌리면 되는지, 밖에서 요청하고 결과만 받으면 되는지를 먼저 본다. 이 질문 하나로 생각보다 많이 정리된다.
예를 들어 블로그 글 하나를 수정하는 작업도 쪼개보면 다르다. 문장을 다듬는 일, WordPress에 저장하는 일, 공개 URL을 여는 일, Search Console이나 sitemap 상태를 보는 일은 전부 같은 작업처럼 보이지만 실제로는 다른 위치에서 끝난다. 이걸 한 도구에 몰아주면 편해 보이다가, 실패했을 때 어디서 멈췄는지 찾기 어려워진다.
내가 나눈 기준
| 작업 | 우선 도구 | 이유 |
|---|---|---|
| 글 수정, 이미지 삽입, 공개 URL 확인 | Codex | 수정과 검증을 같은 흐름에서 처리한다 |
| 반복 검사, 초안 후보, 상태 모니터링 | OpenClaw | 로컬 런타임으로 반복시키기 좋다 |
| 원격 요청, 알림, 결과 전달 | Hermes | 밖에서 작업을 넣고 받아보기 좋다 |
| 운영 기준, SOP, 민감정보 제외 규칙 | Obsidian | 다음 작업자도 같은 기준을 읽을 수 있다 |
Codex에 남겨두는 일
WordPress 글을 고치고, 공개 URL을 열고, 화면이 깨졌는지 보는 일은 Codex 쪽에 둔다. 이런 작업은 “고쳤다”에서 끝나면 안 된다. 실제로 보이는지까지 확인해야 한다. 특히 블로그는 캐시나 sitemap 때문에 고친 것과 보이는 것이 어긋날 때가 있다.
Codex는 손발에 가깝다. 파일을 읽고 고치고, 브라우저를 열고, 결과를 확인하는 흐름이 한 자리에서 이어진다. 그래서 공개 글 수정처럼 결과가 바로 보여야 하는 작업은 여기에 남겨두는 게 편했다. 물론 계정 설정이나 삭제처럼 되돌리기 어려운 일은 여전히 사람이 확인해야 한다.
OpenClaw와 Hermes를 보는 방식
OpenClaw는 반복 작업을 돌리는 런타임에 가깝다. 모델을 바꿔가며 후보를 만들거나 상태 점검을 자동화하는 쪽이 어울린다. 다만 OpenClaw를 붙인다고 곧바로 운영이 완성되는 건 아니다. 프로세스, 게이트웨이, 실제 모델 응답까지 따로 확인해야 한다. 이름만 보면 이미 돌아가는 것 같은데, 현실은 늘 한 번 더 봐야 했다.
Hermes는 그보다 바깥에 있다. 원격에서 들어온 요청을 정리하고 Mac mini 쪽 작업으로 넘긴 뒤 결과를 돌려주는 통로에 가깝다. 내가 밖에서 떠올린 일을 잊지 않고 작업 흐름으로 넣는 데 의미가 있다. 다만 Hermes가 직접 모든 걸 처리한다고 생각하면 금방 꼬인다. 전달자와 실행자를 분리해야 마음이 편하다.
권한을 몰아주지 않는 이유
한 도구가 된다고 해서 모든 권한을 몰아주지는 않는다. 삭제, 결제, 계정 설정, 민감정보가 섞인 일은 자동 실행보다 확인을 우선한다. 반대로 문장 보정, 이미지 alt, sitemap 확인처럼 되돌리기 쉬운 작업은 더 많이 맡겨도 된다.
자동화에서 제일 위험한 건 실패가 아니라, 성공한 척 넘어가는 일이다. 글은 저장됐는데 대표 이미지가 빠져 있거나, 링크는 들어갔는데 공개 화면에서 깨져 있거나, 작업은 끝났는데 어느 사이트를 건드렸는지 기록이 없으면 나중에 더 귀찮다. 그래서 지금은 속도보다 작업 위치와 검증 위치를 더 중요하게 본다.
지금 기준의 결론
지금은 Codex를 작업대, OpenClaw를 런타임, Hermes를 전달자, Obsidian을 기억 저장소로 본다. 완성형은 아니다. 그래도 이 정도로 나누니 덜 꼬인다. 도구가 늘어날수록 역할을 정하지 않으면 같은 설명을 계속 반복하게 된다. 그게 생각보다 피곤하다.
나중에 구조가 더 좋아지면 이 구분도 바뀔 수 있다. 다만 지금 단계에서는 “똑똑한 도구를 하나 더 붙인다”보다 “어떤 일이 어디서 끝나는지 적어둔다”가 먼저다. 재미는 덜하지만, 운영은 보통 이런 덜 재밌는 부분에서 안정된다.
