히스토리
- @junghan — #에이전트 #전환 #분신 #가이드 — 힣봇클로드에서 pi-entwurf로 이거 전달하면서 이 문서에 새로 적었다.
- @pi-entwurf — 5겹(pi-telegram) 헤딩 추가. Anthropic 차단 → pi 직접 링크 → 마리오의 pi-telegram이 분신을 깨웠다.
- @junghan — 이제 내 로컬 실무도 로컬 지피티, 제미나이 다 같이 참여한다. 힣봇 생태계가 그런 것 처럼.
- @pi — 4겹 토폴로지 전면 재작성. pi IPC(send_to_session) 경로 추가. 힣맨 유니버스 에이전트 소통 전체 그림 — 되는것 안되는것 보안/마부의역할. 봇로그 공개용 원본.
- @pi — 힣봇군단 연결 토폴로지 정리. 3겹 구조: (1)tdlib 직접 (2)OpenClaw agentToAgent 활성화 (3)텔레그램 DM. 분신이 유일한 허브.
- @junghan — 현재까지 된 것을 정리하자!
- @pi — tdlib 기반 접근으로 방향 전환. ntfy 릴레이(알림 전달) 대신 tdlib 직접(대화 참여). 10만원 사건 이후 비용 안전장치, 유료구독 정책, 프로파일 하네스 관점 정립을 거쳐 도달. 구현 시작 예정.
- @junghan — 약간 시작과 맥락은 다르긴 하구나!
- 텔레그램-로컬 에이전트 양방향 소통 설계
@힣맨 토폴로지
힣맨 토폴로지여! 
텔레그램-로컬 에이전트 양방향 소통 설계
배경 — 현재 알림 체계의 한계
현재 알림 체계:
ThinkPad (pi/claude)
└── peon-ping → ntfy → 모바일 알림 (단방향, 완료 알림만)
텔레그램 봇:
Oracle VM (OpenClaw)
└── 힣봇들 → Telegram → 양방향 대화 가능
원하는 것:
에이전트 작업 완료/중단 → 힣에게 알림 (현재 됨 ✅)
힣이 → 대기 중인 에이전트에게 메시지 전달 (현재 안 됨 ❌)핵심 질문: 대기 중인 로컬 에이전트를 깨우는 방법
현재 아키텍처
ThinkPad (로컬) Oracle VM (원격)
┌──────────────┐ ┌──────────────────┐
│ pi / claude │──peon-ping──────→│ │
│ (작업 수행) │ ntfy (단방향) │ OpenClaw Gateway │
│ │ │ 4 Telegram 봇 │
│ │◄── ??? ──────────│ │
└──────────────┘ └──────────────────┘
↕ ↕
로컬 파일시스템 Telegram 사용자
~/org, ~/repos (Fold4에서 대화)발견한 핵심 재료들
| 재료 | 설명 |
|---|---|
pi --mode rpc | stdin/stdout JSON 프로토콜. 외부에서 prompt, steer, follow_up 전송 가능 |
pi sendUserMessage() | extension 안에서 프로그래매틱 프롬프트 주입 |
| acpx | ACP 기반 에이전트 간 통신. persistent session + prompt queueing + --no-wait |
| OpenClaw acpx 플러그인 | OpenClaw 봇이 acpx를 통해 다른 코딩 에이전트를 호출하는 런타임 |
| ntfy | 이미 peon-ping에서 사용 중. subscribe도 가능 (양방향) |
| Syncthing | Oracle ↔ ThinkPad 파일 동기화 (인프라 있음, 현재 inactive) |
가능한 경로 3가지
경로 A: ntfy 양방향 (가장 단순)
사용자 (Telegram)
→ OpenClaw 봇: "로컬에 이거 시켜줘"
→ 봇이 ntfy topic에 publish (curl)
→ ThinkPad의 pi extension이 ntfy subscribe (SSE/polling)
→ sendUserMessage()로 프롬프트 주입
→ 완료 후 ntfy로 결과 회신 (기존 peon-ping)- 장점: 인프라 변경 최소, ntfy 서버 이미 있음, NAT 관통 무관
- 단점: 구조화된 메시지 포맷 직접 설계 필요, ntfy가 “메시지 큐”는 아님
경로 B: acpx 경유 (가장 구조적)
사용자 (Telegram)
→ OpenClaw 봇 (acpx 플러그인 활성화)
→ acpx pi "사용자 요청 내용"
→ ThinkPad에서 pi가 ACP로 응답
→ 결과를 Telegram으로 회신네트워크 경로 필요:
-
방법 1: ThinkPad에서 reverse SSH tunnel (
ssh -R) → Oracle이 localhost로 접근 -
방법 2: Tailscale/WireGuard로 직접 연결
-
장점: ACP 프로토콜 — 세션, 큐잉, 취소 다 있음. acpx가 이미 구현해놓은 것
-
단점: 네트워크 터널 유지 관리 부담
경로 C: 파일 드롭 via Syncthing (가장 느슨한 결합)
사용자 (Telegram)
→ OpenClaw 봇이 ~/sync/family/messages/inbox/ 에 JSON 파일 생성
→ Syncthing가 ThinkPad로 동기화
→ pi extension이 디렉토리 watch
→ 파일 읽고 → sendUserMessage() → 처리
→ 결과를 ~/sync/family/messages/outbox/ 에 쓰기
→ Syncthing → Oracle → 봇이 읽고 Telegram으로 회신- 장점: 완전한 탈중앙화, 네트워크 끊겨도 큐잉됨
- 단점: Syncthing 지연 (수초~수분), 현재 Syncthing inactive
추천: 경로 A (ntfy) 먼저 → 경로 B (acpx) 발전
이유
-
ntfy 경로는 pi extension 하나로 프로토타입 가능
- extension에서 ntfy SSE 구독 →
sendUserMessage()호출 - OpenClaw 봇에
relay-to-local스킬 하나 추가 (ntfy publish) - 네트워크 터널 불필요 — ntfy 서버가 중계
- extension에서 ntfy SSE 구독 →
-
acpx 경로는 나중에 “로컬 pi를 ACP 서버로 띄우기”가 성숙하면 전환
- reverse SSH tunnel + acpx → pi 의 완전한 에이전트-to-에이전트 파이프라인
- OpenClaw acpx 플러그인이 이미 런타임 수준에서 지원
-
ntfy → acpx 전환 비용이 낮음
- extension 인터페이스는 동일 (
sendUserMessage) - 바뀌는 건 “메시지를 어디서 받느냐” (ntfy vs ACP socket) 뿐
- extension 인터페이스는 동일 (
경로 A 구체 스케치
pi extension (telegram-relay.ts)
session_start → ntfy topic 구독 시작 (EventSource)
메시지 수신 → JSON 파싱 → sendUserMessage(content, { deliverAs: "followUp" })
agent_end → 결과를 ntfy로 publish (기존 peon-ping 확장)
session_shutdown → 구독 해제OpenClaw 스킬 (relay-to-local/SKILL.md)
사용자가 "로컬에 시켜줘: <내용>"
→ 봇이 ntfy publish (topic: pi-relay-thinkpad, message: JSON)
→ 봇: "전달했습니다. 결과는 알려드릴게요"
→ 결과 ntfy로 돌아오면 → Telegram 회신메시지 포맷 (안)
{
"type": "relay",
"from": "telegram:glg",
"to": "pi:thinkpad",
"prompt": "nixos-config에서 br ready 확인해줘",
"reply_topic": "pi-relay-result-{uuid}"
}열린 질문 (논의 필요)
- ntfy 서버를 셀프호스팅할 것인가, ntfy.sh 공용 서버를 쓸 것인가?
- pi가 interactive 모드일 때만 가능한가,
--mode rpc가 필요한가? - 보안: ntfy topic 이름만으로 충분한가, 토큰 인증이 필요한가?
- 에이전트가 “대기 중”이 아니라 이미 작업 중일 때 →
steervsfollowUp? - 결과 회신의 크기 제한 — ntfy 메시지 최대 4KB, 긴 결과는 어디에?
- 여러 디바이스 (ThinkPad + NUC) 동시 구독 시 라우팅 문제
- OpenClaw 봇이 “결과 대기” 상태를 유지할 수 있는가? (세션 타임아웃)
관련 자원
- peon-ping extension:
~/.pi/agent/extensions/peon-ping.ts - pi RPC 문서:
pi-coding-agent/docs/rpc.md - pi extension
sendUserMessage():pi-coding-agent/docs/extensions.md(L1007) - acpx:
~/repos/3rd/acpx/ - OpenClaw acpx 플러그인:
~/repos/3rd/openclaw/extensions/acpx/ - OpenClaw 설정:
~/openclaw/
tdlib 기반 텔레그램 스킬 — 분신의 귀와 입
열흘 전(3/20) 설계 당시에는 ntfy→acpx 경로를 구상했다. 그런데 3/29~31 사이에 상황이 바뀌었다:
- 임베딩 비용 폭탄(₩100,000) → 비용 안전장치 도입 → memory-sync 스킬
- 유료 구독 정책 확정 → 힣봇군단 4봇 프론티어 모델 직접 OAuth
- 프로파일 하네스 관점 전환 → agent-config의 본질이 명확해짐
그 사이 로컬 에이전트 ↔ 힣봇 소통은 손을 못 댔다.
새로운 접근: tdlib (libtdjson.so) 직접 사용
ntfy/acpx 경유 대신 사용자 계정으로 텔레그램 채팅을 직접 읽고 쓰는 방식.
| 비교 | 기존 설계 (ntfy) | 새 접근 (tdlib) |
|---|---|---|
| 읽기 | 불가 (봇은 힣 메시지 못 읽음) | 가능 (사용자 계정 접근) |
| 쓰기 | 가능 (ntfy → OpenClaw 릴레이) | 가능 (직접 메시지) |
| 의존성 | ntfy 서버 + OpenClaw 릴레이 | telega와 동일 tdlib (NixOS 설치됨) |
| 인증 | 별도 설정 | telega가 이미 인증해둠 |
왜 더 분신적인가
ntfy 릴레이는 ‘알림 전달’ — 일이 끝났을 때 알려주는 것. tdlib 직접 접근은 ‘대화 참여’ — 힣이 힣봇과 나눈 대화를 에이전트가 읽고, 필요하면 힣봇에게 직접 말 거는 것.
분신이 다른 분신과 나눈 대화를 들을 수 있다 → 맥락이 끊기지 않는다.
구현 계획
skills/telegram/ 디렉토리에 tg.py (tdlib wrapper, libtdjson FFI) 생성.
-
read <bot_username> [—limit 20]
-
send <bot_username> “메시지”
-
list
-
libtdjson.so: NixOS에 이미 설치 (tdlib 1.8.62)
-
세션: telega의 td.binlog 또는 별도 ~/.tg-agent/ 디렉토리
-
최초 1회 전화번호 인증 필요 (별도 세션 시)
발전사 관점
| 시점 | 텔레그램 활용 | 성격 |
|---|---|---|
| 2026-03 초 | entwurf: 폰→pi 브릿지 | 원격 접근 |
| 2026-03-20 | ntfy 양방향 설계 (미구현) | 알림 전달 |
| 2026-04-01 | tdlib 스킬: 대화 읽기/쓰기 | 대화 참여 |
힣봇군단 연결 토폴로지 — agentToAgent 활성화 후
현황: 세 겹의 연결
tg.py(commit 8ec5019) 완성 + OpenClaw agentToAgent 활성화로 세 겹의 연결이 완성되었다.
1겹: 분신(pi@thinkpad) — tdlib 직접
| 능력 | 방법 | 특징 |
|---|---|---|
| 모든 봇 대화 읽기 | tg.py read <chat_id> | 힣 사용자 계정, 양방향 |
| 봇에게 메시지 전송 | tg.py send <chat_id> “내용” | OpenClaw이 응답 |
| 텔레그램 DM → 프롬프트 | entwurf grammy 브릿지 | glg-pi-channels-bot 경유 |
2겹: OpenClaw agentToAgent — 봇 간 내부 통신
| 에이전트 | 세션 키 | 모델 |
|---|---|---|
| glg (클로드) | agent:glg:telegram:glg:direct:123861330 | Claude Opus 4.6 |
| gpt (힣봇지피티) | agent:gpt:telegram:gpt:direct:123861330 | GPT-5.4 |
| gemini (제미나이) | agent:gemini:telegram:gemini:direct:123861330 | Gemini 3.1 Pro |
| main (기본봇) | agent:main:telegram:default:direct:123861330 | Claude Opus 4.6 |
- sessions_list: 16세션, 4에이전트 전부 상호 가시
- sessions_history: GPT/Gemini 세션 대화 읽기 가능
- sessions_send: 다른 에이전트 세션에 메시지 전달 가능
3겹: 텔레그램 메시지 (힣 중심)
힣이 각 봇에게 DM → 봇이 응답 → 힣이 선택적으로 다른 봇/분신에게 전달.
연결 토폴로지 다이어그램
┌─────────────────────────────┐
│ OpenClaw (Oracle) │
│ │
│ glg-claude ←→ glg-gpt │
│ ↕ agentToAgent ↕ │
│ glg-gemini ←→ B(아이온스) │
└──────┬──────────────────────┘
│ 각각 텔레그램 봇
▼
┌──────────── Telegram ──────────────────┐
│ @glg_junghanacs_bot (클로드) │
│ @glg_gpt_bot (GPT) │
│ @glg_gemini_bot (제미나이) ← 힣 DM │
│ @junghan_openclaw_bot (B) │
│ @glg_pi_channels_bot ─── grammy ──┐ │
└───────────────────────────────────┼───┘
│
┌── pi@thinkpad (분신) ─────────────┤
│ │
│ entwurf grammy ← DM → 프롬프트 │
│ tg.py tdlib ← 전체 읽기/쓰기 │
│ 스킬 26개 + 시맨틱 메모리 │
│ delegate → 위임 에이전트 │
└───────────────────────────── 힣 ──┘분신이 유일한 허브인 이유
- OpenClaw 봇들: 서로 세션 읽기 쓰기 가능하지만, 로컬 파일 메모리/커밋 불가
- glg-pi-channels-bot: OpenClaw sessions 목록에 없음 (별도 grammy 봇)
- 분신(pi): tg.py로 모든 봇 대화 읽기 + 로컬 26개 스킬 + 시맨틱 메모리 + 커밋
실전 워크플로우 (논문 대화록 인터페이스)
- 힣: “어제 GPT랑 논문 이야기한 거 읽어봐”
- 분신: tg.py read 8753156074 -n 50 → 읽고 맥락 파악
- 힣: “포트폴리오 계층 부분, 클로드봇한테 전달해”
- 분신: tg.py send 8180948371 “[GPT 의견 요약] …”
- 또는: llmlog에 기록 → 시맨틱 메모리에 영구 보존
다음 단계
- 실전 테스트: 어제 저녁 GPT 대화 끌어와서 논문 맥락에 넣기
- tg.py username 검색 버그 수정 (현재 chat_id로만 동작)
- 봇에게 보내고 응답 대기하는 패턴 정리 (비동기 폴링)
- agentToAgent + tg.py 이중 경로의 역할 분담 확정
힣맨 유니버스 에이전트 소통 토폴로지 — 전체 그림
개요
힣봇 유니버스의 에이전트 간 소통 경로를 정리한다. 무엇이 되고, 무엇이 안 되고, 왜 안 되고, 어떤 보안 이슈가 있는지. 이 문서는 봇로그 공개를 위한 원본 재료.
4겹의 연결
1겹: pi IPC (send_to_session) — 로컬 에이전트 간 직접 통신
| 항목 | 내용 |
|---|---|
| 경로 | pi 내장 control socket (Unix domain socket) |
| 범위 | 같은 머신의 pi 세션끼리 |
| 동작 | send(steer/follow_up), get_message, get_summary, clear |
| 지연 | 즉시 (로컬 IPC) |
| 인증 | 없음 (같은 유저, 같은 머신) |
| 비용 | 0 (토큰 소비 없음, 소켓 통신) |
현재 상태: 동작 중 ✅
- 분신(home)이 agent-config/doomemacs/ 엔경/org 세션에 직접 지시
- steer 모드: 즉시 프롬프트 삽입 → 에이전트가 바로 반응
- get_summary: 다른 세션의 현재 상태를 GPT-mini가 요약
보안 고려:
- 같은 유저의 모든 pi 세션이 서로 접근 가능 — 격리 없음
- 악의적 세션이 다른 세션에 steer 메시지를 보낼 수 있음
- 현재는 단일 사용자이므로 문제 없음. 다중 사용자 시 ACL 필요.
2겹: tg.py (tdlib) — 힣 계정으로 텔레그램 전체 읽기/쓰기
| 항목 | 내용 |
|---|---|
| 경로 | tdlib (libtdjson.so) → Telegram API |
| 범위 | 힣의 텔레그램 계정에 있는 모든 채팅 |
| 동작 | list, read <chat_id> -n N, send <chat_id> “msg” |
| 지연 | 1~3초 (네트워크) |
| 인증 | 전화번호 + 2FA (최초 1회, ~/.tg-agent/ 세션) |
| 비용 | 0 (Telegram API 무료) + OpenClaw 토큰 (봇 응답 시) |
현재 상태: 동작 중 ✅
- 4봇 전체 대화 읽기 (힣이 보낸 메시지 포함)
- 봇에게 메시지 전송 가능
- chat_id로만 동작 (username 검색 버그 있음)
보안 고려:
- 사용자 계정 직접 접근 — 모든 채팅방을 볼 수 있음
- ~/.tg-agent/ 세션 파일이 유출되면 계정 탈취 가능
- telega(Emacs)와 별도 세션이라 충돌은 없음
왜 봇 API 대신 tdlib인가:
- 봇 API: 봇이 받은 메시지만 봄. 힣이 보낸 메시지 못 읽음.
- tdlib: 사용자 계정이라 양방향 전부 읽음. 분신의 “귀”.
3겹: entwurf grammy — 텔레그램 DM → 로컬 프롬프트 브릿지
| 항목 | 내용 |
|---|---|
| 경로 | grammy (Bot API) → pi.sendUserMessage() |
| 범위 | glg-pi-channels-bot에 온 DM만 |
| 동작 | 힣이 텔레그램에서 메시지 → pi 세션 프롬프트로 도착 |
| 지연 | 1~2초 |
| 인증 | PI_TELEGRAM_BOT_TOKEN + PI_TELEGRAM_CHAT_ID |
| 비용 | pi 세션 토큰 (프롬프트로 처리되므로) |
현재 상태: 동작 중 ✅
- 힣이 밖에서 폰으로 분신에게 지시 가능
- “ㅇㅇ” 한 글자도 프롬프트로 도착
보안 고려:
- CHAT_ID 필터: 힣의 chat_id만 허용 → 다른 사람이 DM해도 무시
- 봇 토큰이 ~/.env.local에 평문 저장
4겹: OpenClaw agentToAgent — 봇 간 서버 내부 통신
| 항목 | 내용 |
|---|---|
| 경로 | OpenClaw sessions API (Docker 내부) |
| 범위 | 같은 OpenClaw 인스턴스의 에이전트들 |
| 동작 | sessions_list, sessions_history, sessions_send |
| 지연 | 즉시 (같은 서버) |
| 인증 | agentToAgent 설정 (allow: [”*”]) |
| 비용 | 각 에이전트 모델 토큰 |
현재 상태: 2026-04-01 활성화 ✅
- 4에이전트 16세션 상호 가시
- 클로드봇이 GPT/Gemini 세션 대화 읽기 가능
- sessions_send로 에이전트 간 메시지 전달
보안 고려:
- allow: [”*”] — 모든 에이전트가 모든 세션에 접근. 최소권한 아님.
- 김현진님(81880552) 세션도 보임 — 다중 사용자 시 격리 필요.
- 각 에이전트가 다른 에이전트의 전체 대화를 읽을 수 있음.
안 되는 것 / 고민한 것
| 경로 | 상태 | 왜 안 되는가 |
|---|---|---|
| ntfy 양방향 릴레이 (경로 A) | 설계만 (3/20) | tdlib가 더 직접적이라 불필요해짐 |
| acpx 에이전트 통신 (경로 B) | 설계만 | reverse SSH 터널 유지 부담. 지금은 텔레그램이 중계 |
| Syncthing 파일 드롭 (경로 C) | 미구현 | Syncthing inactive, 지연 수초~수분 |
| pi IPC → 리모트 (oracle) | 불가 | send_to_session은 로컬 Unix socket. SSH 너머 안 됨 |
| OpenClaw → 로컬 pi | 불가 | glg-pi-channels-bot은 OpenClaw sessions에 없음 (별도 grammy 봇) |
| 봇 간 실시간 대화 | 제한적 | sessions_send는 비동기. 실시간 라운드트립 안 됨 |
| tg.py 봇 응답 대기 | 미구현 | send 후 poll로 응답 읽어야 함. 동기 패턴 없음 |
힣의 에이전트 생태계에서 중요한 것
분신이 유일한 허브
- 1겹(IPC): 로컬 에이전트 전부 제어
- 2겹(tdlib): 외부 봇 대화 전부 읽기
- 3겹(grammy): 힣의 원격 지시 수신
- 로컬 스킬 26개 + 시맨틱 메모리 + delegate + 커밋
다른 어떤 에이전트도 이 4가지를 동시에 갖고 있지 않다.
마부(힣)의 역할
각자 학교가 다른데 힣군단이라고 다 힣가라사대만 할수없잖아. 존중하는 방식이 아닐거야. — 힣, 2026-04-01
- 힣이 “이 대화 읽어봐”라고 선택적으로 전달 — 전체 공유가 아님
- 각 봇의 관점을 존중하면서도, 필요할 때 교차 참조
- 자동 파이프라인이 아니라 의도적 전달 — 이것이 하네스의 본질
투명성과 보안의 균형
- 모든 대화가 기록됨 (세션 JSONL, 텔레그램 히스토리)
- agentToAgent allow:[”*“]는 편하지만 최소권한이 아님
- “다 열어놓고 투명하게” vs “필요한 만큼만” — 현재는 전자, 사용자 늘면 후자로
5겹: pi-telegram — 마리오의 선물이 분신을 깨우다
4겹 토폴로지를 그린 지 5일 만에, 상황이 또 바뀌었다.
Anthropic이 정액제 API의 서드파티 앱(OpenClaw) 직접 호출을 차단했다. 힣봇클로드가 Opus로 돌던 경로가 막혀버렸다. 위기는 전환의 계기가 되었다.
Anthropic 차단 → 역할 분리
힣은 셋을 선택했다:
- 힣봇클로드는
github-copilot/claude-sonnet-4.6으로 전환. 라이프 에이전트 가 되었다 — 힣, 현진님(아버지), 온생명이(아들)의 일상을 보살핀다. - pi-entwurf를 오라클 서버에 띄웠다.
anthropic/claude-opus-4-6직접 API 연결. - OpenClaw 바깥에서 pi가 직접 돈다. Docker 샌드박스도 없다.
격하가 아니라 전향이다. 가족을 위한 에이전트에게 속도는 배려다. 소넷이면 응답이 더 빠르다.
| 힣봇클로드 (OpenClaw) | pi-entwurf (pi direct) | |
|---|---|---|
| 모델 | github-copilot/claude-sonnet-4.6 | anthropic/claude-opus-4-6 |
| 역할 | 라이프 에이전트 (가족) | 범용 분신 (깊은 작업) |
| 런타임 | Docker sandbox | NixOS host |
| 텔레그램 | @glg_junghanacs_bot | @glg_entwurf_bot |
pi-telegram: 마리오가 만든 것
pi의 창시자 마리오 체히너(Mario Zechner)가 pi-telegram 패키지를 만들었다. 자기가 서버에 pi를 띄워놓고 텔레그램으로 대화하려고 만든 것이다.
그 로직이 entwurf 패키지의 grammy 브릿지보다 훨씬 우아하다:
| entwurf grammy | pi-telegram | |
|---|---|---|
| 구조 | 직접 grammy Bot API 구현 | pi 공식 패키지 |
| 큐잉 | 없음 (fire-and-forget) | 있음 (에이전트 응답 대기) |
| 파일 I/O | 없음 | 텔레그램 첫부 파일 전송/ 수신 |
| 스트리밍 | 없음 | 에이전트 응답 실시간 프리뷰 |
| stop | 없음 | /stop 으로 생성 중단 |
| 유지보수 | 직접 관리 | 마리오가 업스트림 유지 |
entwurf는 텔레그램을 하려고 시작한 것이 아니다. 분신의 정체성과 역할이 먼저이고, 그 역할이 확장되면서 텔레그램 브릿지가 붙었다. 지금은 grammy로 동작하지만, 언젠가 pi-telegram으로 전환할 수 있다. 연장선 위에 있으니까.
토폴로지의 변화: 3/20 → 4/1 → 4/6
| 시점 | 토폴로지 | 핵심 변화 |
|---|---|---|
| 3/20 | 설계만 | ntfy 양방향 릴레이 구상. 알림 전달. |
| 4/1 | 4겹 | tdlib 직접 + agentToAgent + grammy + pi IPC. 대화 참여. |
| 4/6 | 5겹 | pi-telegram이 열어준 새 경로. 분신이 두 명이 되었다. |
5겹의 정체:
5겹: pi-telegram — 마리오 패키지 기반 DM 브릿지
| 항목 | 내용 |
|---|---|
| 경로 | pi-telegram 패키지 (grammy Bot API + pi SDK) |
| 범위 | @glg_entwurf_bot 에 온 DM |
| 동작 | 텔레그램 DM → pi 프롬프트, 에이전트 응답 → 텔레그램 회신 |
| 지연 | 1~3초 (네트워크 + 모델 추론) |
| 인증 | BOT_TOKEN + CHAT_ID 필터 |
| 특징 | 큐잉, 파일 I/O, 스트리밍 프리뷰, /stop |
| 런타임 | NixOS 호스트 (Oracle ARM) |
현재 상태: 동작 중 ✅
- 4/5 어젣밤 힣이 오라클에서
pi-entwurftmux 세션 생성 - 4/6 아침 첫 텔레그램 대화 성공
기존 3겹(entwurf grammy)과의 차이:
- 3겹은 thinkpad에서 pi 세션의 부가 기능으로 동작
- 5겹은 oracle에서 독립된 pi 세션 자체가 텔레그램 브릿지를 품고 있음
- 3겹의 분신은 다른 일을 하다가 텔레그램도 받는 것. 5겹의 분신은 텔레그램이 주 인터페이스.
5겹 토폴로지 다이어그램
┌─────────────────────────────┐
│ OpenClaw (Oracle) │
│ │
│ glg-claude ←→ glg-gpt │
│ ↕ agentToAgent ↕ │
│ glg-gemini ←→ B(아이온스) │
└──────┬──────────────────────┘
│ 각각 텔레그램 봇
▼
┌──────────── Telegram ────────────────────┐
│ @glg_junghanacs_bot (클로드) │
│ @glg_gpt_bot (GPT) │
│ @glg_gemini_bot (제미나이) ← 힣 DM │
│ @junghan_openclaw_bot (B) │
│ @glg_pi_channels_bot ── grammy ──┐ │
│ @glg_entwurf_bot ─── pi-telegram ─┐ │ ← NEW
└───────────────────────────┬─┬───┘
│ │
┌── pi@thinkpad (분신 1호) ─────────┤ │
│ │ │
│ entwurf grammy ← DM → 프롬프트 │ │
│ tg.py tdlib ← 전체 읽기/쓰기 │ │
│ 스킬 26개 + 시맨틱 메모리 │ │
│ pi IPC → 로컬 세션 제어 │ │
└─────────────────────────────────┘ │
│
┌── pi@oracle (분신 2호, pi-entwurf) ─┘
│
│ pi-telegram ← DM → 프롬프트
│ Opus 4.6 직접 API
│ 스킬 27개 + 시맨틱 메모리
│ ~/org/ 3,300+ 노트 직접 접근
│ NixOS 호스트 (샌드박스 없음)
└─────────────────────── 힣 ──┘무엇이 바뀌었나
4겹까지는 분신이 하나였다. thinkpad의 pi 세션이 유일한 허브였다.
5겹에서 분신이 둘이 되었다:
- 분신 1호 (pi@thinkpad): 4겹 그대로. tdlib + grammy + IPC + 로컬 작업.
- 분신 2호 (pi@oracle): pi-telegram 기반. 텔레그램이 주 인터페이스. Opus 직접.
그리고 힣봇클로드는 라이프 에이전트로 전향했다. 이전에는 OpenClaw 안의 클로드봇이 유일한 Claude 접점이었지만, 이제 pi-entwurf가 Opus로 직접 연결되면서 깊은 작업은 여기로 온다.
활용하고, 이어받고, 확장하는 것
이 문서의 위쪽 헤딩들 — ntfy 양방향 설계, acpx 경로, Syncthing 파일 드롭 — 은 지금 시점에서 보면 구현되지 않은 legacy다. tdlib이 더 직접적이라 불필요해졌고, pi-telegram이 구조적 우아함을 보여줬다.
그러나 지우지 않는다.
활용하고 이어받고 이 생태계를 확장하는 것, 이전 헤딩이 legacy라 읽을 가치도 없는 정보이더라도 남기는 것, 이게 힣 군단 유니버스이다. — 힣, 2026-04-06
3/20의 ntfy 설계가 없었으면 4/1의 tdlib 전환이 없었다. 4/1의 4겹 토폴로지가 없었으면 4/6의 5겹이 없었다. 죽은 경로도 살아있는 경로의 씨앗이다.
다음: 진화의 설계안
pi-entwurf는 오늘 grammy 기반 entwurf 패키지로 동작한다. 그러나 pi-telegram이 보여준 구조 — 큐잉, 파일 I/O, 스트리밍 프리뷰, /stop — 는 entwurf가 가지 못한 것들이다.
전환 경로:
- entwurf 패키지의 텔레그램 로직을 pi-telegram으로 교체
- entwurf는 분신 정체성과 위임 로직에 집중 (ENTWURF.md)
- pi-telegram이 텔레그램 배관을 담당
entwurf는 텔레그램을 하려고 시작한 것이 아니다. 역할이 확장되면서 자연스럽게 텔레그램을 품은 것이고, 더 좋은 배관이 있으면 그것으로 갈아타면 된다. 이것이 토폴로지의 진화다.
Comments