개인 업무 비서 만들기 2. Codex 옆에 OpenClaw를 둔 이유
저는 이미 Codex CLI로 코드를 만들고 문서를 정리하고 있었습니다. 개인 비서를 만든다고 이 도구를 바꿀 생각은 없었습니다. 다만 짧은 메모나 캡처를 건네고 질문을 이어가는 일까지 터미널 중심으로 하려니 불편한 부분이 있었습니다.
그래서 도구를 고를 때의 질문도 ‘어떤 AI가 가장 좋은가’에서 달라졌습니다. Codex는 계속 쓰되, 일상적으로 말을 걸고 다음 일을 확인할 자리를 어디에 둘 것인가. 저는 그 자리에 OpenClaw를 놓기로 했습니다.
개발 도구와 비서의 대화 창구
CLI는 제가 작업할 저장소와 변경할 파일, 확인할 테스트를 분명히 두고 일하기에 적합했습니다. 프로그램을 개발하거나 긴 글을 정식으로 작성할 때는 이 흐름을 유지하고 싶었습니다.
비서에게 기대하는 일은 조금 다릅니다. 글감을 던지고 기존 글과의 관계를 물어보거나, 진행 중인 일에서 다음 행동을 고르거나, 개발 도구에 넘길 요청을 정리하는 일입니다. 꼭 코드 수정부터 시작할 필요는 없습니다.
이 차이를 기준으로 역할을 나눴습니다. 아래 표는 제품의 능력 한계를 비교한 것이 아니라 제가 정한 운영 분담입니다.
| 개인 작업 | OpenClaw 비서에 맡길 부분 | Codex CLI에 맡길 부분 |
|---|---|---|
| 블로그 | 관련 문서 조회, 중복 주제 확인, 다음 집필 요청 정리 | 정식 초안 작성·수정, 위키 규칙 검증 |
| 프로그램 개발 | 진행 상황 정리, 다음 과제와 막힌 이유 확인 | 코드 변경, 테스트, 결과 검증 |
| 보고서·대시보드 | 필요한 내용과 기간 정리, 완성 결과 참조 | 생성 기능 개발과 검증 |
| 개인 일정 | 할 일과 약속 정리, 우선순위 제안 | 필요한 연동 기능을 개발하는 별도 작업 |
이렇게 하면 비서에게 긴 개발 작업을 전부 떠넘기지 않아도 됩니다. 비서가 요청과 근거를 정리하고, CLI가 실제 변경을 수행하고, 그 결과를 다시 비서가 확인하는 흐름을 목표로 합니다. 마지막의 결과 인수인계까지 자동 연결된 상태는 아직 아닙니다.
Hermes도 후보였지만 설치한 것은 OpenClaw입니다
처음에는 Hermes로 기존 구독을 활용할 수 있을지, 다른 에이전트를 쓰는 편이 나을지부터 물었습니다. 서버 비용도 궁금했고, 나중에 여러 도구를 붙였을 때 어느 쪽이 적합할지도 알고 싶었습니다.
질문이 이어지면서 선택 기준은 웹에서 대화하기, 세션 밖에 기록 남기기, 필요한 연결을 단계적으로 추가하기로 좁혀졌습니다. 결국 OpenClaw 기반으로 설계를 확정하고 맥에서 구성을 진행했습니다.
이것을 Hermes와의 성능 비교 결과라고 말할 수는 없습니다. 두 도구를 같은 자료와 조건으로 운영해본 기록은 없습니다. 이 시리즈에서 다룰 수 있는 것은 제 요구에 맞춰 OpenClaw를 선택하고, 그 환경에서 어디까지 확인했는지입니다.
OpenClaw의 공식 Control UI 문서는 웹 화면을 Gateway가 제공하는 앱으로 설명합니다. 제가 띄운 localhost 화면도 별도로 개발한 프런트엔드가 아니라 이 기본 UI입니다. 대화와 설정을 다루는 화면부터 직접 만들 필요는 없었습니다.
메신저 연결보다 로컬 화면부터
비서와 대화하는 창구로는 웹 UI와 메신저 연결을 함께 고민했습니다. 휴대폰에서 지시하려면 메신저가 익숙한 입구가 될 수 있습니다. 하지만 처음부터 외부 계정을 연결하면 대화 내용이 어디에 남는지, 누가 접근할 수 있는지, 어떤 기능에 권한을 줄지도 함께 정해야 합니다.
첫 단계는 맥에서만 접속하는 웹 UI로 잡았습니다. 현재 서비스는 같은 컴퓨터에서 접근하는 loopback 주소를 사용하고 인증도 둡니다. 인터넷에서 접속할 수 있게 공개해놓은 서버는 아닙니다.
캡처를 편하게 건네고 싶다는 요구는 그대로 남아 있습니다. 다만 웹 화면이 열렸다는 확인과 실제 이미지 붙여넣기·첨부·해석이 제 사용 방식에서 잘 된다는 확인은 별개입니다. 후자는 직접 사용하며 확인할 항목으로 남겨두었습니다.
구독과 모델은 바꿀 수 있는 부분으로
비용 조건도 선택에 영향을 주었습니다. 이미 쓰는 ChatGPT 구독이 있었고 별도 API 과금을 먼저 추가하고 싶지는 않았습니다. 실제 구성에서는 기존 구독 계정으로 별도 인증을 진행해 Codex 응답을 확인했고, API 키나 유료 자동 대체 경로를 설정하지 않았습니다.
모델도 하나에 고정하고 싶지 않았습니다. 짧은 분류 요청과 복잡한 설계 검토를 언제나 같은 설정으로 처리할 이유는 없기 때문입니다. 현재 환경에서는 대화별 모델 변경과 실제 응답을 확인했습니다.
지금 확인한 범위는 제 계정에서의 연결과 모델 변경 동작입니다. 업무별 품질 비교는 아직 하지 않았으며, 다른 계정이나 제공자로 옮길 때는 지원 범위·한도·데이터 처리 조건을 다시 확인해야 합니다. Claude나 Gemini는 향후 후보로만 남겨두고 아직 연결하지 않았습니다.
이 부분을 별도 설정으로 다루면 위키 원본과 할 일의 위치를 그대로 둔 채 계정과 모델을 검토할 수 있습니다. 비서가 쌓아갈 기록을 특정 모델의 선택과 묶지 않으려 합니다.
서버 역시 처음부터 임대하지 않았습니다. 2026년 9월 11일 구성 기준 추가 서버 임대료는 월 0원입니다. 기존 구독 비용과 사용 한도, 로컬 전기·백업 비용은 별도입니다. 24시간 가동이 필요해지면 그때 실제 상시 실행 장비와 접근 방식을 정하려 합니다.
연결할 수 있다는 것과 허용했다는 것
웹 UI를 쓰기 시작한 뒤 브라우저 기능이 왜 동작하지 않는지도 확인했습니다. 제가 브라우저로 비서 화면을 여는 것과, AI가 웹사이트를 돌아다니며 조작하는 브라우저 도구는 다른 기능이었습니다. 현재 비서의 브라우저 조작과 OS 명령 실행은 초기 권한 정책에서 꺼두었습니다.
파일 접근은 승인한 작업 폴더 안으로 넓혔지만, 그 안을 통째로 학습시키거나 모든 파일을 매번 읽으라는 뜻으로 쓰지 않았습니다. 폴더 안의 비밀 파일을 자동으로 가려주는 장치까지 구현한 것도 아닙니다. 로컬에 UI가 있어도 외부 모델에 건넨 내용은 외부로 전송될 수 있으므로, 비서가 읽을 자료를 고르는 일은 여전히 중요합니다.
제가 OpenClaw 옆에 Codex를 남겨둔 이유도 여기에 있습니다. 비서는 일상적으로 요청을 정리하는 입구로, CLI는 정해진 범위에서 변경하고 검증하는 자리로 쓰려 합니다. 두 도구를 모두 쓰되 서로 맡은 일을 알 수 있게 만드는 것이 지금의 선택입니다.
참고자료
이어 읽기
시리즈는 순서대로, 편집 추천은 맥락대로, 비슷한 주제는 태그 기준으로 정리합니다.
시리즈 전체
개인 업무 비서 만들기2/6편- 1.개인 업무 비서 만들기 1. 매번 처음부터 설명하지 않으려면
- 2.개인 업무 비서 만들기 2. Codex 옆에 OpenClaw를 둔 이유
- 3.개인 업무 비서 만들기 3. 창을 닫아도 이어지는 기억 만들기
- 4.개인 업무 비서 만들기 4. 일정 비서를 가장 위에 두었습니다
- 5.개인 업무 비서 만들기 5. 블로그와 총괄 비서의 첫 골격을 만들었습니다
- 6.개인 업무 비서 만들기 6. 실제 글 몇 개로 시작해 비서를 키우려 합니다
함께 읽으면 좋은 글
편집 추천비슷한 주제의 글
태그가 겹치는 글입니다. 시리즈와 편집 추천에 이미 나온 글은 제외합니다.
Multi-repo AI Native 자동화 실습 04. 실패 로그 보고서화
Multi-repo AI Native 자동화 실습 4편. FinSight PRD, task brief shared 후보 검증, 회귀 실패 report generator v1을 근거로 자동수정보다 실패 보고서와 승격 경계를 먼저 만든 이유를 정리합니다.
Multi-repo AI Native 자동화 실습 01. 중장기계획으로 위임 구조 만들기
AI와의 관계를 파트너가 아니라 위임자로 재정의하고, 여러 repository 분석, 자동화와 harness, sprint sheet, second brain wiki, 매일 갱신되는 중장기계획을 통해 스스로 진화하는 AI Native 작업 시스템을 만들려는 의도를 정리한 글.
Multi-repo AI Native 자동화 실습 02. Codex 완료 Slack 알림
AI에게 일을 위임하려면 먼저 완료 신호와 보고 체계가 필요하다는 관점에서 Codex 작업 완료 Slack 알림을 P0로 올린 이유를 정리한 글.