CMD+K 는 client 지 기능이 아냐

"CMD+K 는 AI 에디터를 새로 지은 게 아니야. 이미 있던 것에 창을 하나 낸 거지."

새 기능이 아니라 새 client

CMD+K 를 'Rekindle 의 AI 재작성 기능' 이라고 부르기 쉬운데, 그렇게 부르는 순간 실제 아키텍처가 가려져. CMD+K 는 cwkPippa Prompt Macro 의 새 client 야. 다른 표면들이 이미 쓰고 있는 그 macro 엔진을 inline 편집 표면에 얇게 노출한 거지. Rekindle 은 재작성 엔진을 만들지 않았어. bind 해둔 브레인에 이미 있던 것으로 통하는 문을 냈을 뿐이야. 판단은 cwkPippa 에 살고, CMD+K 는 prose 한 줄 안에서 거기에 닿는 창구고.

엔진을 재사용해서 얻는 것

Prompt Macro 를 다시 만들지 않고 재사용하면 모든 면에서 값을 해. 우선 유지보수할 macro 엔진이 둘로 갈라지지 않고 하나로 남아. Prompt Macro 쪽이 개선되면 Rekindle 에는 공짜로 따라오고. 동작도 일관돼서, macro 하나가 Rekindle 에서든 가족 다른 곳에서든 같은 뜻이야. 이게 이 가족의 Reuse pillar 가 실제로 작동하는 모습이지. 능력이 브레인에 이미 있으면 새 표면은 client 지 절대 fork 가 아니야.

UX 도 빌렸어

상호작용마저도 발명이 아니라 빌려 온 거야. Cursor 의 CMD+K 에서 UX 를 참고했거든. 선택하고, 부르고, 제안을 보고, 그 자리에서 받아들이거나 물리는 흐름 말이야. Rekindle 은 그 모양을 가져다 Prompt Macro 에 겨눴어. 그러니까 CMD+K 는 두 층에서 동시에 빌린 셈이지. 엔진은 cwkPippa 에서 재사용했고, 상호작용 모양은 Cursor 에서 검증된 패턴을 가져왔어. 어느 쪽도 새로 발명하지 않았고. 마법처럼 느껴지는 기능이 싸게 지어진 이유가 그 이중 빌림에 있어. 이미 돌아가던 두 가지 사이에 놓은 얇은 다리거든.

Code

기존 Prompt Macro 위 얇은 client·typescript

// CMD+K 안에는 재작성 엔진이 없어. cwkPippa 에 이미 있는 걸
// 부르고 결과를 inline 으로 렌더할 뿐이지.
async function runCmdK(view, selection) {
  const { from, to } = selection;
  const rewrite = await promptMacro.run({
    macro: "polish",          // cwkPippa 의 기존 macro
    text: view.state.sliceDoc(from, to),
  });
  // 트랙 4 의 decoration 역할인 inline diff 로 보여주고, 수락할 때 문서를 바꿔.
  showInlineDiff(view, { from, to, replacement: rewrite });
}

// 엔진은 cwkPippa 에서 재사용하고 상호작용은 Cursor 에서 빌려 왔어.
// Rekindle 이 한 일은 그 사이에 얇은 다리를 놓은 것뿐이야.

Exercise

네가 아는 시스템 어딘가에 있는 능력을 하나 떠올려봐. 검색이든 포매터든 auth 체크든. 이제 그걸 새 화면에 붙인다고 상상하고 두 가지 방식으로 그려봐. 하나는 다시 구현하는 방식, 하나는 기존 능력의 얇은 client 를 만드는 방식. client 쪽이 앞으로 1년 동안 유지보수에서 뭘 아껴주는지 적어봐. 그 목록이 CMD+K 가 client 인 이유야.

Hint

client 쪽이 아껴주는 것들은 이래. 버그를 고칠 자리가 하나, 개선할 자리도 하나, 동작이 일관된다는 보장, 그리고 복사본 둘이 따로 놀 일이 없다는 것. 다시 구현하면 단기적인 독립성을 얻는 대신 계속 동기화해야 할 두 번째 물건이 생겨. 한 시스템 안에서는 대체로 나쁜 거래야.

새 기능이 아니라 새 client

엔진을 재사용해서 얻는 것

UX 도 빌렸어

Code

External links

Exercise

Progress

댓글 0