게이트웨이의 비밀 - 에이전트는 어떻게 살아있나
— 첫 응답이 느린 이유, 그리고 도구 호출의 정체
지난 편에서 한참 디버깅하고, 첫 메시지에서 답을 받았어요. 그런데 그 답이 오는 데 40초 가까이 걸렸어요. 모델이 죽지 않은 건 좋은데, 응답이 너무 느렸죠. 6편 때 Open WebUI에서 gpt-oss:20b 쓸 때는 거의 즉시 답이 왔거든요.
본인이 한 의문은 이거였어요.
“같은 ATOM, 비슷한 30B 모델인데, 왜 에이전트가 챗봇보다 느려?”
오늘 글에서 그 답을 풀어볼게요. 그리고 채팅창에 슬쩍 등장한 “Tool call”, “Continue the OpenClaw runtime event” 같은 이상한 메시지들의 정체도 같이. 본인이 만든 에이전트는 사실 본인이 생각한 것보다 훨씬 복잡한 시스템이었어요.
30초의 비밀 - System Prompt의 무게
같은 모델, 같은 하드웨어. 한 가지가 달랐어요. “누가 모델한테 말을 거느냐”.
직접 Ollama 호출 (6편 방식)
본인: "안녕"
↓
Ollama: 짧은 인사 → 짧게 답하기
↓
모델 처리: 약 200~300 토큰 생성총 처리량 ≈ 300 토큰
OpenClaw 경유 (오늘 방식)
OpenClaw가 모델한테 말 거는 메시지:
"너는 AI 에이전트야. 사용 가능한 도구:
[10개 도구 정의 - 5,000자]
[응답 형식 규칙 - 1,000자]
[Skills 설명 - 2,000자]
[에이전트 행동 규칙 - 3,000자]
...
+ 본인의 메시지: '안녕'"
총 약 3,000~5,000 토큰
↓
모델 처리: 거대한 시스템 프롬프트 다 읽기
+ 어떤 도구 쓸지 결정
+ 응답 형식 맞추기
↓
응답: 200~500 토큰총 처리량 ≈ 3,000~5,000+ 토큰
약 10배 차이예요. 그래서 첫 응답이 한참 느린 거예요.
비유로 풀면 이래요.
| 직접 Ollama | OpenClaw | |
|---|---|---|
| 상황 | 친구 집에서 라면 끓이기 | 풀코스 레스토랑 주문 |
| 셰프 | “라면!” → 바로 시작 | 메뉴 다 읽기 → 알레르기 확인 → 와인 페어링 → 그 다음 시작 |
| 시간 | 빠름 | 느림 |
| 결과 | 라면 한 그릇 | 도구 호출, 파일 접근, 다단계 작업 가능 |
OpenClaw가 더 많은 걸 할 수 있어요. 그게 비용이에요. 30초는 비싸 보이지만, 본인 책상 위에서 도는 진짜 에이전트의 첫 시동 비용이라고 보면 받아들일 만합니다.
그리고 두 번째 메시지부터는 빨라져요. 시스템 프롬프트는 캐시되거든요. 모델이 한 번 읽은 거 두 번 안 읽어요.
“Continue the OpenClaw runtime event” - 출근 신호
웹 UI를 처음 열었을 때 이상한 메시지가 있었어요. 본인이 친 메시지도 아닌데 채팅창 맨 위에 적혀있는 거.
“Continue the OpenClaw runtime event.”
이게 뭐냐? OpenClaw가 에이전트한테 자동으로 보내는 시작 신호예요. “야 일어나. 너의 메모리, 설정 확인하고 일 시작해” 라는 의미.
비유: 인공지능의 “출근 신호” 🌅. 사람도 출근하면 이메일 확인하고 일정 보고 하잖아요. 그거랑 같은 루틴.
ollama launch openclaw --model nemotron-32k 명령이 OpenClaw gateway를 재시작할 때마다, 이 메시지가 자동 발송돼요. 그리고 에이전트(Nemotron)는 이걸 받자마자 자기 일을 시작합니다. 채팅창에 줄줄이 나타나는 그 일들.
Tool Call의 정체 - Hooks가 작동하는 모습
웹 UI에 이런 박스들이 줄줄이 나타나요.
▶ Tool call (read)
▶ Tool output (read)
▶ Tool call (read)
▶ Tool output (read)
▶ Tool call (write)
▶ Tool output (write)처음엔 “뭐지?” 싶었는데, 풀어보니까 11편 마법사 때 본인이 켠 Hooks 5개가 작동하는 모습이었어요.
| 켠 Hook | 지금 보이는 모습 |
|---|---|
🚀 boot-md | 시작 시 markdown 파일 자동 로드 → 첫 read tool |
📎 bootstrap-extra-files | 추가 파일들 자동 로드 → 두 번째 read tool |
💾 session-memory | 세션 상태 저장 → write tool |
🧹 compaction-notifier | “COMPACTED HISTORY” 메시지 띄움 |
📝 command-logger | 백그라운드 로그 기록 |
read → read → write 패턴 = 에이전트가 메모리 읽고, 부팅 설정 읽고, 자기 상태 업데이트하는 모습이에요.
그러니까 본인이 “안녕” 하나 쳤을 때 일어난 일은 사실 이래요.
1. ollama launch openclaw 명령으로 gateway 재시작
2. OpenClaw가 에이전트 깨움: "Continue the OpenClaw runtime event"
3. 에이전트가 출근 루틴 시작:
- 메모리 파일 읽기 (read 1)
- 부팅 설정 읽기 (read 2)
- 세션 시작 시각 기록 (write 1)
4. 본인이 "안녕" 입력
5. 에이전트가 컨텍스트 통합해서 답변 생성본인 입장에선 그냥 “안녕” 한 마디였는데, 백엔드에선 에이전트가 자기 정체성을 챙기고 일을 시작하는 작은 의식이 일어나고 있었어요.
이게 챗봇이랑 결정적으로 다른 점이에요.
| 일반 챗봇 | 에이전트 (OpenClaw + Nemotron) | |
|---|---|---|
| “안녕”에 대한 반응 | 즉답 | 자기 메모리 확인 → 답 |
| 매번 시작 | 새로 시작 | 이전 상태 기억 |
| 도구 | 없음 | 읽기/쓰기/실행 도구 |
| 본질 | 텍스트 생성기 | 상태 관리하는 존재 |
Tool call 한 줄 한 줄이 에이전트가 살아 있다는 증거예요.
시스템의 진짜 모양 - 게이트웨이 + 클라이언트
여기까지 보니까 본인이 만든 시스템의 진짜 모양이 궁금해졌어요. 그래서 정리해봤어요.
┌─────────────────────────────────────────────┐
│ 🦞 OpenClaw Gateway (systemd 서비스) │
│ - 에이전트 두뇌 (상태, 메모리, 결정) │
│ - 항상 살아있음 │
│ - 포트 18789에서 대기 │
└──────────────────┬──────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌──▼──────┐ ┌────▼────┐ ┌──────▼──────┐
│ TUI │ │ Web UI │ │ Telegram │
│ (터미널) │ │ (브라우저) │ │ (다음 편) │
└─────────┘ └─────────┘ └─────────────┘핵심 통찰: 에이전트는 하나예요. 하지만 여러 통로로 접근할 수 있어요.
- 터미널에서 빠르게 작업할 때 → TUI
- 책상 앞에서 깊게 작업할 때 → Web UI
- 외출 중 폰에서 → Telegram (다음 편 예정)
세 입구가 다 같은 에이전트로 들어가요. 같은 대화 기록, 같은 메모리, 같은 능력.
그리고 그 게이트웨이 뒤에는 한 단계 더 있어요.
┌─────────────────────────────────────────┐
│ 🦞 OpenClaw Gateway │
│ "어떤 도구 쓸지, 답변 어떻게 만들지 결정" │
└──────────────────┬──────────────────────┘
│ HTTP 호출
▼
┌─────────────────────────────────────────┐
│ 🦫 Ollama (시스템 서비스) │
│ "Nemotron 모델 돌리는 엔진" │
│ 포트 11434에서 대기 │
└─────────────────────────────────────────┘OpenClaw는 결정 내리는 두뇌. Ollama는 그 두뇌가 시킨 일을 수행하는 모델 서버. 분리되어 있어요.
5편의 Docker 컨테이너, 7편의 venv… 본인은 계속 같은 사고방식의 변주를 보고 있어요. “각자 자기 일에만 집중, 필요한 만큼 격리, 통신은 명시적으로.” 도구마다 다른 옷을 입었을 뿐 본질은 같습니다.
systemd Lingering - 로그아웃해도 살아남는 비밀
위 그림에서 한 가지 짚고 갈 게 있어요. OpenClaw Gateway는 “systemd 사용자 서비스” 예요. 그리고 마법사가 설치할 때 슬쩍 이 메시지가 떴어요.
✓ Enabled systemd lingering for rocklassiclingering. “오래 머무르다”라는 뜻.
기본적으로 Linux는 사용자가 로그아웃하면 그 사용자가 띄운 모든 프로세스를 죽여요. 메모리 절약을 위해서요. 그런데 그러면 안 되는 서비스들이 있죠. OpenClaw 같은 게 그래요. 본인이 자리 비웠다고 에이전트가 죽으면 곤란합니다.
lingering이 활성화되면 다음과 같이 바뀌어요.
| 상황 | 일반 사용자 | lingering 활성화 |
|---|---|---|
| 로그인 중 | ✓ 사용자 서비스 동작 | ✓ |
| 로그아웃 | ❌ 사용자 서비스 종료 | ✓ 계속 동작 |
| 재부팅 후 | ❌ 수동으로 시작 | ✓ 자동 시작 |
이게 마법사가 슬쩍 처리해준 거예요. 본인이 명령어 한 줄 안 쳤는데, 컴퓨터 켜놓기만 하면 24/7 작동하는 에이전트가 자동으로 만들어졌어요.
6편에서 Docker의 --restart always 옵션이랑 비슷한 거예요. “이 서비스는 어떤 일이 있어도 살아 있게 해줘” 라는 의지인 것이죠.
메모리 30GB? - Ollama의 똑똑함
본인이 한 가지 더 걱정했던 게 있어요.
“이거 24시간 살아있다는 건, Nemotron 모델이 24시간 메모리 30GB 잡고 있다는 뜻 아냐?”
답은 아니에요. Ollama가 똑똑하게 관리해줘요.
자동 언로드
Ollama 기본 설정:
- 모델 사용 후 5분 동안 추가 요청 없으면 → 메모리에서 자동 unload
- 다음 요청 오면 → 다시 load (10~15초)
비유: 자동차 시동 🚗
| 상황 | 메모리 |
|---|---|
| 운전 중 (채팅 중) | 시동 켜짐 (~30GB) |
| 주차 5분 (자리 비움) | 자동 시동 꺼짐 (~300MB) |
| 다시 출발 (새 요청) | 재시동 (5~15초) |
본인이 잠깐 자리 비우면 모델은 자동으로 메모리에서 내려가요. 30GB가 항상 점유되는 게 아니에요. 그리고 다시 채팅하면 자동으로 올라옴.
이게 6편 모델의 3가지 상태(디스크 / 메모리 로드 / 자동 언로드)랑 같은 구조예요. 같은 사고방식이 또 등장.
여기까지 정리하면, 본인 ATOM은 이제 이런 상태예요.
🌐 Tailscale: 폰/사무실에서 ATOM에 안전하게 접근
│
▼
🖥️ ATOM 부팅 후 자동 가동:
│
├─ 🤖 Open WebUI (Docker, --restart always)
│ → localhost:8080
│ → 6편의 가벼운 ChatGPT 비슷한 거
│
├─ 🦫 Ollama (systemd 시스템 서비스)
│ → localhost:11434
│ → 모델 서버, 자동 메모리 관리
│
└─ 🦞 OpenClaw (systemd 사용자 서비스 + lingering)
→ localhost:18789
→ 에이전트 두뇌
│
├─ TUI (터미널에서 실행)
├─ Web UI (브라우저)
└─ (앞으로) Telegram (폰)이게 개인 AI 인프라의 모습이에요. 클라우드 회사들이 월 수십만 원에 임대하는 그것. 본인은 1리터 우유팩 크기 머신 위에 그걸 다 깔아서 굴리고 있는 셈이에요.
그리고 가장 중요한 건, 이 모든 게 본인 손 안에 있어요. 어떤 데이터도 외부로 안 나가요. 어떤 회사에도 사용료 안 내요. 인터넷이 끊겨도 동작해요.
1편에서 박스 열었을 때 ATOM이 약속한 게 사실 이거였어요. 12편이 돼서야 그 약속이 진짜로 손에 잡혔습니다.
한 번 더 짚어둘 보안
마지막으로 한 가지. 에이전트는 챗봇보다 본질적으로 위험해요. 11편에서도 한 번 짚었지만, 다시 한 번.
- 에이전트는 본인 파일을 읽을 수 있어요
- 에이전트는 명령을 실행할 수 있어요
- 에이전트는 외부 API를 호출할 수 있어요
이게 다 본인이 켠 Skills와 Tools가 허용하는 범위 안에서예요. 마법사에서 Skills를 “No”로 한 게 그래서 중요해요. 첫 시작은 위험한 능력 다 꺼진 상태여야 합니다.
그리고 OpenClaw 토큰(http://127.0.0.1:18789/#token=...)은 본질적으로 비밀번호예요. 절대 캡쳐로 공유하거나 GitHub에 올리지 마세요. 노출되면 이렇게 새 토큰을 발급해야 합니다.
openclaw doctor --generate-gateway-token오늘의 정리
- ✅ 에이전트가 챗봇보다 느린 이유: System prompt가 10배 크기. 첫 응답에 30초가 비싸 보이지만, 두 번째부터 캐시 hit으로 빨라짐
- ✅ “Continue the OpenClaw runtime event” = 에이전트의 출근 신호. Gateway가 자동 발송
- ✅ Tool call 줄줄이 = Hooks가 작동하는 모습. 에이전트가 메모리 읽고 자기 상태 챙기는 의식
- ✅ 에이전트 시스템 구조
- 게이트웨이(두뇌) + 클라이언트(TUI/Web UI/Telegram)가 분리
- 그 아래 Ollama가 모델 서버로 따로 작동
- 5편 Docker, 7편 venv와 같은 “격리 + 명시적 통신” 사고방식
- ✅ systemd lingering: 로그아웃해도 살아남고, 재부팅해도 자동 시작. 본인이 명령어 한 줄 안 쳤는데 24/7 에이전트 완성
- ✅ Ollama 자동 언로드: 5분 안 쓰면 모델 알아서 메모리에서 내려감. 30GB가 항상 점유되는 게 아님
- ✅ 에이전트는 챗봇보다 위험. Skills 처음엔 다 꺼두기, 토큰은 비밀번호처럼 다루기
12편까지 오시느라 수고하셨어요. 1편 처음에 책상에 올린 작은 박스가, 이제는 본인이 부르면 어디서든 응답하는 비서가 사는 집이 됐어요.
다음 편엔 그 비서를 폰에서도 부르는 방법 이네요. 텔레그램 봇으로 연결해서 출근 중 지하철에서도 에이전트에게 일을 시키는 그 마지막 한 조각이 될 예정입니다.
읽어주셔서 감사합니다.