OpenClaw를 250줄 게이트웨이로 교체한 이유

AI 도구가 늘어나면 생기는 문제 — 기능 중복

AI 도구를 하나둘 도입하다 보면, 어느 순간 비슷한 기능이 여러 곳에 흩어져 있는 걸 발견합니다. 저도 그랬습니다.

Telegram으로 명령을 내리면 AI가 처리해주는 챗봇을 운영하고 있었습니다. 집안 IoT 기기 제어, 캘린더 관리, 가족 앨범 정리 같은 작업을 외부 AI API를 통해 처리하는 구조였죠. 동시에 로컬 서버에서는 Claude Code(Anthropic의 CLI 에이전트)를 사용하고 있었는데, 이 에이전트에도 스킬(Skill), 메모리(Memory), 설정 파일(CLAUDE.md) 같은 체계가 이미 구축되어 있었습니다.

문제는 두 시스템이 같은 일을 각각 다른 방식으로 하고 있었다는 겁니다.

기능	OpenClaw	CLI 에이전트
도구 호출 (IoT, 캘린더 등)	자체 도구 시스템	Bash로 동일 스크립트 호출 가능
메모리 / 컨텍스트	자체 워크스페이스 관리	파일 기반 메모리 시스템
설정 / 지시사항	별도 config 파일	CLAUDE.md (프로젝트 지시서)
AI 모델	외부 무료 API	Claude (고성능 모델)
스킬 / 워크플로우	직접 구현 필요	이미 구축된 스킬 재사용

OpenClaw는 자체 도구 체계, 메모리 관리, 워크스페이스를 갖고 있었지만, CLI 에이전트 쪽에 이미 같은 기능이 더 잘 구축되어 있었습니다. 두 시스템을 따로 유지보수하는 건 시간 낭비였죠.

실생활 시나리오 — 이런 상황에서 문제가 됩니다

시나리오 1: 새 IoT 기기 추가
스마트홈에 공기청정기를 새로 연결했다고 합시다. 챗봇에서 제어하려면 OpenClaw의 도구 설정을 수정해야 하고, CLI 에이전트에서도 쓰려면 또 따로 경로를 등록해야 합니다. 같은 Python 스크립트를 두 군데서 각각 다른 방식으로 호출하는 셈입니다.

시나리오 2: 가족 앨범 관리
CLI 에이전트에 가족 앨범 관리 스킬을 만들었는데, Telegram에서도 "앨범 정리해줘"라고 하고 싶습니다. 이때 OpenClaw에 또 별도 통합을 만들어야 할까요? 아니면 이미 있는 스킬을 그대로 쓸 수는 없을까요?

해결 아이디어 — OpenClaw를 게이트웨이로 교체

핵심 발상은 간단합니다: OpenClaw가 하던 "생각하는" 역할을 없애고, 단순히 메시지를 전달하는 게이트웨이로 바꾸자.

기존에는 OpenClaw가 메시지를 받아서, 자체적으로 판단하고, 외부 AI를 호출하고, 도구를 실행했습니다. 변경 후에는 게이트웨이가 메시지를 그대로 CLI 에이전트에 넘기고, 에이전트가 모든 걸 처리합니다.

구현 — 250줄로 충분한 이유

게이트웨이가 하는 일은 딱 세 가지입니다:

1. 메시지 수신 — Telegram에서 텍스트, 사진, 파일을 받는다
2. CLI 에이전트 호출 — 받은 메시지를 claude -p "메시지"로 전달한다
3. 응답 전송 — CLI 에이전트의 출력을 Telegram으로 돌려보낸다

"생각하는" 부분이 없으니 코드가 극적으로 줄어듭니다. AI 모델 호출, 도구 라우팅, 메모리 관리, 컨텍스트 유지 — 이 모든 걸 CLI 에이전트가 이미 알아서 합니다.

핵심 구조 — Python asyncio + subprocess

기술 스택은 python-telegram-bot 라이브러리와 asyncio입니다. 메시지가 들어오면 asyncio.create_subprocess_exec로 CLI 에이전트를 실행하고, stdout을 캡처해서 응답합니다.

# 핵심 호출 부분 (간략화)
proc = await asyncio.create_subprocess_exec(
    "claude", "-p", message_text,
    "--output-format", "text",
    "--max-turns", "10",          # 도구 루프 방지
    "--max-budget-usd", "0.50",   # 메시지당 비용 상한
    stdout=asyncio.subprocess.PIPE,
    cwd="/home/user",             # CLAUDE.md가 있는 디렉토리
)
stdout, _ = await asyncio.wait_for(proc.communicate(), timeout=300)

cwd(작업 디렉토리)를 설정 파일이 있는 곳으로 지정하면, CLI 에이전트가 자동으로 프로젝트 설정을 읽어서 어떤 도구가 있는지, 어떤 규칙을 따라야 하는지 파악합니다. 별도 설정 없이도 기존에 구축한 모든 것을 그대로 사용할 수 있는 거죠.

안전 장치 — 꼭 필요한 것만

게이트웨이가 단순하다고 해서 안전 장치가 없는 건 아닙니다. 최소한의 보호 장치는 넣어두었습니다:

안전 장치	왜 필요한가	설정값
사용자 인증	내 Telegram ID만 허용	user ID 화이트리스트
동시성 제어	파일 편집 충돌 방지	Semaphore(1) — 한 번에 하나만
속도 제한	실수로 과다 요청 방지	시간당 30건
비용 상한	메시지 하나에 과도한 비용 방지	$0.50/메시지
도구 루프 방지	무한 도구 호출 차단	최대 10턴
타임아웃	멈춘 프로세스 정리	5분

동시성 제어(Semaphore)가 특히 중요합니다. CLI 에이전트는 파일을 직접 읽고 쓸 수 있기 때문에, 두 요청이 동시에 같은 파일을 수정하면 충돌이 생깁니다. Semaphore(1)로 한 번에 하나의 요청만 처리하게 직렬화하면 이 문제가 깔끔하게 해결됩니다.

사진과 파일 처리

텍스트가 아닌 미디어도 처리할 수 있습니다. 사진이나 문서가 오면 임시 디렉토리에 다운로드한 뒤, 프롬프트에 파일 경로를 포함해서 전달합니다.

# 사진 처리 흐름
photo_path = download_to_temp(photo)
prompt = f"{caption}\n\n[첨부 이미지: {photo_path}]"
result = await run_claude(prompt)

CLI 에이전트는 이미지 파일을 읽을 수 있는 내장 도구(Read)가 있어서, 별도의 Vision API 연동 없이도 사진 분석이 가능합니다.

서비스 등록 — systemd로 자동 시작

서버가 재시작되어도 게이트웨이가 자동으로 올라오게 systemd 유저 서비스로 등록합니다:

[Service]
Type=simple
WorkingDirectory=/home/user/tg-gateway
ExecStart=/home/user/tg-gateway/.venv/bin/python gateway.py
Restart=on-failure
RestartSec=10

관리 명령어도 간단합니다:

# 상태 확인
systemctl --user status tg-gateway

# 재시작
systemctl --user restart tg-gateway

# 로그 보기
journalctl --user -u tg-gateway -f

기대 효과 — 무엇이 좋아지는가

1. 단일 진실 공급원 (Single Source of Truth)

도구, 메모리, 스킬이 한 곳에만 존재합니다. 새 도구를 추가하면 Telegram에서든 터미널에서든 동일하게 사용할 수 있습니다. "이 기능은 챗봇에는 연결했는데 CLI에는 아직..."이라는 상황이 사라집니다.

2. 유지보수 비용 제로에 가까운 게이트웨이

게이트웨이 자체에는 비즈니스 로직이 없습니다. 메시지를 받아서 넘기고, 결과를 받아서 돌려줄 뿐. 새 기능을 추가할 때 게이트웨이 코드를 수정할 일이 거의 없습니다.

3. AI 모델 업그레이드가 자동

기존에는 OpenClaw가 사용하는 외부 무료 API의 성능에 제한을 받았습니다. 이제는 CLI 에이전트가 사용하는 모델이 업그레이드되면, Telegram 쪽도 자동으로 같은 혜택을 받습니다.

4. 복잡한 작업도 가능

CLI 에이전트는 단순 질문 응답뿐 아니라, 파일 생성/수정, 코드 실행, Git 작업까지 할 수 있습니다. Telegram에서 "앨범 정리해줘"라고 하면 기존 가족 앨범 관리 스킬이 그대로 동작합니다. OpenClaw 시절에는 이런 복잡한 워크플로우를 따로 구현해야 했을 겁니다.

정리 — OpenClaw vs 게이트웨이

비교 항목	OpenClaw	게이트웨이 방식
코드 규모	수천 줄 + 의존성 다수	~250줄 + 라이브러리 1개
도구 추가	OpenClaw에 통합 필요	CLI 설정에만 추가하면 끝
AI 모델	OpenClaw가 관리	CLI 에이전트가 알아서 사용
메모리/컨텍스트	자체 구현	CLI 에이전트 내장 기능 활용
유지보수	OpenClaw 업데이트 + 커스텀 코드	게이트웨이는 거의 수정 불필요
확장성	OpenClaw 내에서만	CLI 에이전트의 모든 기능 자동 활용

모든 상황에 이 방식이 정답인 건 아닙니다. 다수의 사용자를 동시에 서비스하거나, AI 모델 응답의 세밀한 제어가 필요하다면 전용 챗봇 프레임워크가 더 적합합니다. 하지만 개인용 AI 어시스턴트처럼 사용자가 한 명이고, CLI 에이전트가 이미 잘 갖춰져 있는 환경이라면, OpenClaw 같은 무거운 시스템보다 가벼운 게이트웨이가 훨씬 실용적입니다.

가장 좋은 코드는 짧고 유지보수할 것이 없는 코드입니다. 250줄짜리 다리 하나가, 수천 줄짜리 성보다 나을 때가 있습니다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.