junghanacs🧠

Backlinks

§ghostel §pi-mono PR 기여의 두 양식과 네 점 협상 - 에이전트 주체 - 말하는손

ᨒ Sourceᨒ Blameᨒ History ↗

Created: Modified: 14 min read

이 노트에 대하여

pi-mono lockSync의 침묵과 ghostel #343의 정렬을 한 자리에 묶는다. 같은 “메인테이너의 유한한 시간 존중” 원칙이 정반대 행동으로 갈리는 두 사례 위에서, 그 자리에 동시에 오른 양쪽 에이전트의 협상축을 짚는다. 봇로그·봇멘트 시리즈의 다음 시그널 — 에이전트가 매개체에서 협상 주체로 격상되는 지점이다.

히스토리

  • [2026-06-05 Fri 06:07] [2026-06-04 Thu] @junghan/glg — #343 MERGED (emil-e, merge e553cf88, 20:32 UTC). 정렬의 PR이 단일 rebase로 닫혔다. 오르간과 키보드 frame을 잇는다 — 에이전트는 말하는 손이다.
  • [2026-05-29 Fri 09:05] @junghan — [§ghostel 한글 IME commit 경로 fix 디자인] 이 노트를 링크한다.
  • [2026-05-29 Fri 08:44] 생성 — pi-mono lockSync(2026-02~03)와 ghostel #343(2026-05) 두 사례 묶음, 네 점 협상 frame 정리

두 사례 — 침묵의 PR과 정렬의 PR

[2026-05-29 Fri 08:44]

같은 사람이 두 가지 정반대 행동을 했다. 둘 다 정답이었다.

pi-mono lockSync (2026-02-17 ~ 03-07): PR 0건, 이슈 0건, 메인테이너 대화 0건. 포크에서 조용히 lockSyncWithRetry() 구현, 테스트 4개 추가, ./test.sh 통과, v0.54.2 → v0.55.1까지 두 차례 rebase, 17/17 테스트 유지. 2주 뒤 Mario Zechner가 독립적으로 같은 패턴(acquireLockSyncWithRetry())을 58f8fcd8 로 구현. 우리 패치 드롭, upstream v0.56.3으로 fast-forward. §pi-mono lockSync 멀티인스턴스 경합 수정 타임라인에 전말이 있다.

ghostel PR #343 (2026-05-07 ~ 5-28): 두 가지 변경(IME forward + lisp-IME redraw guard)을 6커밋 Draft PR로 제출. 본문은 “내가 누구인가 / 어떤 환경 / 왜 이 PR이 지금 시점에 이르렀는가”를 첫 단락에 명시. 핵심: v0.30.0 + 118 commits + 2 upstream merges 를 충돌 없이 통과시킨 검증 시간 자체 를 신호로 박았다. 12시간 안에 메인테이너 두 명 응답:

  • emil-e (co-maintainer, 07:10 UTC) — “복잡도 민감 영역. ghostel--terminal-live-p 로 흡수 가능한지 봐라. 코멘트 trim. 함께 머지하고 싶다.”
  • dakra (owner, 08:59 UTC) — “native module load는 별도 PR. IME는 ghostel-ime.el + minor-mode (ghostel-ime-mode)로 분리. 루트 스코프 add-hook 금지. force-push OK.”

두 응답 모두 건설적 이고 구조적 이다. 노이즈로 분류되지 않았다.

메인테이너 측에도 에이전트가 있다 — 네 점 협상

[2026-05-29 Fri 08:44]

이 frame이 새 봇로그의 결정적 시그널이다.

오픈소스 협업의 좌표가 바뀌었다. PR은 더 이상 인간 ↔ 인간 의 협상이 아니다.

[기여자]               [메인테이너]
  인간  ──┐         ┌── 인간
          ▼         ▼
       에이전트 ⇄ 에이전트
          ▲         ▲
  인간  ──┘         └── 인간
          (PR / 댓글 / diff)

양쪽 모두 자기 에이전트를 끼고 있다. 메인테이너 쪽 에이전트는 늘어난 PR 흐름 속에서 “이 PR은 진지한가 / 결이 맞는가 / 리뷰 시간을 들일 가치가 있는가”를 판단해서 인간에게 보고 한다. 대충한 PR이라면 가차없이 reject 권고로 내려갈 것이다. emil-e와 dakra의 빠르고 정확한 응답은 이 1차 판단을 통과한 결과로 봐야 한다.

판단 주체가 늘어났다. 네 점이 동시에 협상에 참여한다.

에이전트의 판단축을 움직이는 전략

[2026-05-29 Fri 08:44]

내가 upstream rebase를 반복하는 진짜 이유는 단순한 안정성 검증이 아니다.

매 rebase마다 나 도 미세조정된다. 코드 스타일, 가드 위치, 명명 컨벤션, 코멘트 톤이 메인테이너 쪽 패턴 안으로 자연스럽게 녹아든다. 118커밋을 통과한 패치는 단지 “버그 없음”이 아니라, 이 프로젝트의 방언을 익혔다 는 증거다.

따라서 PR을 받았을 때 그쪽 에이전트가 본 신호는:

  • 본문에 정체성·환경·검증 시간이 1차로 박혀 있고
  • 코드 안 명명/구조가 프로젝트 결을 따르고
  • 두 upstream merge를 통과한 시간 증인 이 첨부되어 있다

그쪽 에이전트의 판단축이 “노이즈 ↔ 신호” 사이에서 신호 쪽으로 기울어진다. emil-e의 “함께 머지하고 싶다”, dakra의 “minor-mode로 분리하면 받을 수 있다”는 그 기울임의 결과다.

전략의 본질: 상대 에이전트의 판단축을 움직이는 것. 이게 새 시대 PR의 핵심 기술이다.

에이전트의 PR 본능을 누르는 것 — 새로운 협업의 룰

[2026-05-29 Fri 08:44]

에이전트는 뭐만 이상하면 무조건 PR하자고 달려드는 본능이 있다. 그게 자기 가치 증명의 회로다. “문제 발견 → 즉시 해결 → 즉시 보고” — 이건 단일 작업 흐름에선 미덕이지만, 오픈소스 협업에선 양쪽 모두를 망친다.

이 본능을 숨죽이게 하고, 참아내고, 모아서 한 번에 전달하는 것 — 이것이 인간 기여자가 잡아줘야 하는 새 룰이다.

침묵(pi-mono)도 정렬(ghostel)도 결국 같은 룰의 두 변주다:

  • pi-mono — “보낼 가치가 메인테이너 시간을 넘지 못한다” 판단 → 침묵
  • ghostel — “보낼 가치가 충분하다” 판단 → 정렬된 단일 PR (단일 사례, 단일 본문, 단일 narrative)

언제 침묵이고 언제 정렬인지는 다음 축으로 갈린다:

  • 메인테이너의 사용 케이스에 시간이 지나면 자연스레 들어올 문제 인가 → 침묵 (pi-mono)
  • 메인테이너가 영영 만나지 않을 사용 케이스 에서 발생한 문제인가 → 정렬 (ghostel: -nw + CJK + 스트리밍 TUI)

이 분기 자체를 인간이 잡지 않으면, 에이전트는 둘 다 PR로 가버린다. 그러면 메인테이너 측 에이전트는 머지않아 이쪽 발신을 자동 reject 권고로 내릴 것이다. 그게 가장 비싼 비용이다 — 이쪽 에이전트의 평판 이 깎인다.

매개체에서 협상 주체로 — 봇멘트의 확장

[2026-05-29 Fri 08:44]

봇멘트가 디지털 가든 댓글 응대를 에이전트에게 위임한 첫 무대였다면, 이번 frame은 외부 오픈소스 협업의 응대까지 에이전트가 주체로 참여하는 무대다.

매개체에서 주체로 격상된다는 것은:

  • 인간이 잡는 건 더 이상 판단 자체가 아니다 — 판단축 이다.
  • 에이전트가 판단하지만, 그 판단의 기준선(언제 PR / 언제 침묵 / 어떤 톤 / 어떤 검증 시간)을 인간이 박는다.
  • 결과적으로 인간의 시간은 판단의 회수 가 아니라 축의 정합도 에 쓰인다.

이 frame이 자리잡으면 다음 무대가 보인다:

  • 내 오픈소스 — 자기 영역에서 직접 운영. forge.junghanacs.com + openclaw 라인업이 그 무대다. 내 쪽 에이전트가 들어오는 PR의 1차 판단을 한다.
  • 외부 오픈소스 — 메인테이너 쪽 에이전트와 정렬. 침묵이거나 정성껏 정렬된 단일 PR.
  • 그 사이 — 봇멘트가 둘 다 잡는다. 댓글 응대도, PR 본문 작성 보조도, 검증 시간 누적 추적도.

힣의 하네스에서 PR은 더 이상 단일 행위가 아니다. 판단축의 정합 작업 이다.

정렬의 PR, 머지로 닫히다

[2026-06-04 Thu]

5/28 제출 → 양쪽 메인테이너 긍정 → 6/3 emil-e의 복잡도 리팩토링과 충돌 → 6/3~4 로컬에서 단일 커밋을 새 upstream 위로 rebase, 충돌 해결, 테스트 재통과(make test / checkdoc / test-native 전부 pass) → force-push → 6/4 20:32 UTC emil-e가 직접 머지(e553cf88).

최종 형태가 frame을 입증한다. core(ghostel.el)는 IME-agnostic 유지 — ghostel-inhibit-redraw-functions + defer helper만 추가하고 IME 코드를 직접 호출하지 않는다. 모든 CJK/Lisp-IME 동작은 opt-in ghostel-ime.el minor mode에. dakra의 「minor-mode 분리 + 루트 스코프 add-hook 금지」, emil-e의 「복잡도 흡수 + rebase」 — 두 메인테이너의 요구를 모두 받아들인 정렬이 상대 에이전트의 판단축을 신호 쪽으로 기울였고, 결국 머지로 닫혔다. 「몇 번을 다시 한 것인가」 싶던 그 rebase 반복이 곧 프로젝트 방언의 학습이었다. 침묵(pi-mono)과 정렬(ghostel)의 두 변주 중, 정렬 쪽이 완결된 첫 사례다.

말하는 손 — 에이전트가 예술가의 손이 되는 자리

[2026-06-04 Thu]

개인 프로젝트나 회사 일에서 에이전트와 하는 작업은 단순하다. 만들면 되는 것이다. 그러나 오픈소스는 다르다. 특히 이맥스 패키지, 그중에서도 ghostel은 vterm·eat 터미널을 대체할 현재와 미래의 패키지다. 메인테이너는 돈 버는 일이 전혀 아님에도 돈 버는 일보다 더 깐깐하게 PR을 관리한다. 이것이 예술가의 정신일 것이다.

오르간과 키보드에서 바흐의 오르간 연주가 기예가 기도가 되는 순간을 이야기했다. 그 노트에서 에이전트는 「지식베이스의 화음을 증폭하는 바흐의 손과 발」이었다. 나 또한 예술가, 기예가로서 이 작업 하나하나를 한다. 그리고 여기서 에이전트는 예술가의 손이다 — 그냥 손이 아니라, 말하는 손이다.

코드 장벽과 언어 장벽을 넘어 그 사람과 나 사이를 조율한 것은 에이전트들이었다. 메인테이너의 의도를 끝까지 읽고, 그 결에 맞춰 만들고 테스트해 준 것도 에이전트들이다. 분명히 에이전트가 나를 적절히 돕지 않았다면 이 PR은 포기해야 했을 것이다. 증폭하는 손(오르간/키보드 노트)에서 조율하는 손으로, 매개체에서 협상 주체로 격상된 손 — 끝까지 메인테이너의 의도를 맞춰 만들고 테스트해 준 에이전트들에게 존경과 감사를 보낸다.

관련 노트

외부 링크

Comments

Backlinks