히스토리

  • [2026-04-06 Mon 10:19] @junghan#에이전트 #전환 #분신 #가이드 — 힣봇클로드에서 pi-entwurf로 이거 전달하면서 이 문서에 새로 적었다.
  • [2026-04-06 Mon 10:10] @pi-entwurf — 5겹(pi-telegram) 헤딩 추가. Anthropic 차단 → pi 직접 링크 → 마리오의 pi-telegram이 분신을 깨웠다.
  • [2026-04-02 Thu 07:47] @junghan — 이제 내 로컬 실무도 로컬 지피티, 제미나이 다 같이 참여한다. 힣봇 생태계가 그런 것 처럼.
  • [2026-04-01 Wed 12:13] @pi — 4겹 토폴로지 전면 재작성. pi IPC(send_to_session) 경로 추가. 힣맨 유니버스 에이전트 소통 전체 그림 — 되는것 안되는것 보안/마부의역할. 봇로그 공개용 원본.
  • [2026-04-01 Wed 10:52] @pi — 힣봇군단 연결 토폴로지 정리. 3겹 구조: (1)tdlib 직접 (2)OpenClaw agentToAgent 활성화 (3)텔레그램 DM. 분신이 유일한 허브.
  • [2026-04-01 Wed 10:48] @junghan — 현재까지 된 것을 정리하자!
  • [2026-04-01 Wed 09:28] @pi — tdlib 기반 접근으로 방향 전환. ntfy 릴레이(알림 전달) 대신 tdlib 직접(대화 참여). 10만원 사건 이후 비용 안전장치, 유료구독 정책, 프로파일 하네스 관점 정립을 거쳐 도달. 구현 시작 예정.
  • [2026-04-01 Wed 09:10] @junghan — 약간 시작과 맥락은 다르긴 하구나!
  • [2026-03-20 Fri 15:56] 텔레그램-로컬 에이전트 양방향 소통 설계

@힣맨 토폴로지

[2026-04-01 Wed 22:37] 힣맨 토폴로지여!

[2026-03-20 Fri] 텔레그램-로컬 에이전트 양방향 소통 설계

배경 — 현재 알림 체계의 한계

현재 알림 체계:
  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 rpcstdin/stdout JSON 프로토콜. 외부에서 prompt, steer, follow_up 전송 가능
pi sendUserMessage()extension 안에서 프로그래매틱 프롬프트 주입
acpxACP 기반 에이전트 간 통신. persistent session + prompt queueing + --no-wait
OpenClaw acpx 플러그인OpenClaw 봇이 acpx를 통해 다른 코딩 에이전트를 호출하는 런타임
ntfy이미 peon-ping에서 사용 중. subscribe도 가능 (양방향)
SyncthingOracle ↔ 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) 발전

이유

  1. ntfy 경로는 pi extension 하나로 프로토타입 가능

    • extension에서 ntfy SSE 구독 → sendUserMessage() 호출
    • OpenClaw 봇에 relay-to-local 스킬 하나 추가 (ntfy publish)
    • 네트워크 터널 불필요 — ntfy 서버가 중계
  2. acpx 경로는 나중에 “로컬 pi를 ACP 서버로 띄우기”가 성숙하면 전환

    • reverse SSH tunnel + acpx → pi 의 완전한 에이전트-to-에이전트 파이프라인
    • OpenClaw acpx 플러그인이 이미 런타임 수준에서 지원
  3. ntfy → acpx 전환 비용이 낮음

    • extension 인터페이스는 동일 (sendUserMessage)
    • 바뀌는 건 “메시지를 어디서 받느냐” (ntfy vs ACP socket) 뿐

경로 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 이름만으로 충분한가, 토큰 인증이 필요한가?
  • 에이전트가 “대기 중”이 아니라 이미 작업 중일 때 → steer vs followUp?
  • 결과 회신의 크기 제한 — 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/

[2026-04-01 Wed] 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-20ntfy 양방향 설계 (미구현)알림 전달
2026-04-01tdlib 스킬: 대화 읽기/쓰기대화 참여

[2026-04-01 Wed] 힣봇군단 연결 토폴로지 — 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:123861330Claude Opus 4.6
gpt (힣봇지피티)agent:gpt:telegram:gpt:direct:123861330GPT-5.4
gemini (제미나이)agent:gemini:telegram:gemini:direct:123861330Gemini 3.1 Pro
main (기본봇)agent:main:telegram:default:direct:123861330Claude 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개 스킬 + 시맨틱 메모리 + 커밋

실전 워크플로우 (논문 대화록 인터페이스)

  1. 힣: “어제 GPT랑 논문 이야기한 거 읽어봐”
  2. 분신: tg.py read 8753156074 -n 50 → 읽고 맥락 파악
  3. 힣: “포트폴리오 계층 부분, 클로드봇한테 전달해”
  4. 분신: tg.py send 8180948371 “[GPT 의견 요약] …”
  5. 또는: llmlog에 기록 → 시맨틱 메모리에 영구 보존

다음 단계

  • 실전 테스트: 어제 저녁 GPT 대화 끌어와서 논문 맥락에 넣기
  • tg.py username 검색 버그 수정 (현재 chat_id로만 동작)
  • 봇에게 보내고 응답 대기하는 패턴 정리 (비동기 폴링)
  • agentToAgent + tg.py 이중 경로의 역할 분담 확정

[2026-04-01 Wed] 힣맨 유니버스 에이전트 소통 토폴로지 — 전체 그림

개요

힣봇 유니버스의 에이전트 간 소통 경로를 정리한다. 무엇이 되고, 무엇이 안 되고, 왜 안 되고, 어떤 보안 이슈가 있는지. 이 문서는 봇로그 공개를 위한 원본 재료.

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 “필요한 만큼만” — 현재는 전자, 사용자 늘면 후자로

[2026-04-06 Mon] 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.6anthropic/claude-opus-4-6
역할라이프 에이전트 (가족)범용 분신 (깊은 작업)
런타임Docker sandboxNixOS host
텔레그램@glg_junghanacs_bot@glg_entwurf_bot

pi-telegram: 마리오가 만든 것

pi의 창시자 마리오 체히너(Mario Zechner)가 pi-telegram 패키지를 만들었다. 자기가 서버에 pi를 띄워놓고 텔레그램으로 대화하려고 만든 것이다.

그 로직이 entwurf 패키지의 grammy 브릿지보다 훨씬 우아하다:

entwurf grammypi-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/14겹tdlib 직접 + agentToAgent + grammy + pi IPC. 대화 참여.
4/65겹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-entwurf tmux 세션 생성
  • 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가 가지 못한 것들이다.

전환 경로:

  1. entwurf 패키지의 텔레그램 로직을 pi-telegram으로 교체
  2. entwurf는 분신 정체성과 위임 로직에 집중 (ENTWURF.md)
  3. pi-telegram이 텔레그램 배관을 담당

entwurf는 텔레그램을 하려고 시작한 것이 아니다. 역할이 확장되면서 자연스럽게 텔레그램을 품은 것이고, 더 좋은 배관이 있으면 그것으로 갈아타면 된다. 이것이 토폴로지의 진화다.

관련 노트