(1/3) 불평이 가장 좋은 입력이다?
Note
이 글은 제가 elendirna라는 MCP 도구를 만들며 도달한 일반화 가능한 패턴을, Claude·Codex·Gemini와의 대화를 통해 종합·추출한 결과입니다. 사고의 주체는 저이고, 표현의 작업은 Claude로 진행했습니다.
저는 직관과 working implementation을 가졌고, AI들은 vocabulary와 narrative structure를 가져왔습니다. 이 분업의 명시화 자체가 이 연재의 주제 — "사고를 밖에 두는 법" — 의 일부로 봐주시면 감사하겠습니다.
불평이 가장 좋은 입력이다?
레거시 코드를 한참 들여다보다 보면, 분석 지시 같은 건 잘 안 나온다. 대신 불평이 나온다. "이 코드는 왜 이 모양이야." "이렇게 짜면 안 됐던 거 아닌가." "여기 이거 고치면 어떻게 되지."
도구를 만들기 전에는 이런 발화를 그냥 흘려보냈다. 메모할 가치가 없는, 감정 섞인 군말이라고 생각했다. 그런데 vault에 AI를 붙여놓고 일하면서 정반대라는 걸 알았다. 불평은 AI에게 가장 고밀도의 입력이다.
불평 안에 압축된 것
"이 코드는 왜 이 모양이야"라는 한 문장 안에는 세 가지가 압축되어 있다. 코드의 현재 상태에 대한 관찰, 그게 왜 문제인지에 대한 나의 평가 기준, 그리고 어떤 모양이었어야 하는지에 대한 지향점. 깔끔하게 정리된 "이 함수를 분석해줘"라는 지시보다 정보 밀도가 훨씬 높다.
실제로 그랬다. 어떤 거대한 레거시 모듈을 보며 내가 내뱉은 "이건 C++의 탈을 쓴 절차적 C 코드잖아"라는 직관적 불평은, 에이전트에 의해 'God Function'과 '절차적 패러다임의 오용'이라는 객관적 아키텍처 비판으로 번역되어 기록으로 박제됐다. 나는 짜증을 냈을 뿐인데, 도구는 그걸 진단서로 만들었다.
지시는 깔끔하지만 얕다. 불평은 지저분하지만 깊다. 도구가 그 깊이를 받아낼 그릇을 갖고 있으면, 가장 자연스러운 발화가 가장 좋은 입력이 된다.
시간차 페어 프로그래밍
이렇게 박제된 파편들이 임계점을 넘으면 다른 일이 일어난다. 개별 기록 하나하나가 아니라, 여러 기록을 가로지르는 패턴을 에이전트가 추출하기 시작한다. 그 시점부터 vault는 저장소가 아니라 추론의 기질(reasoning substrate) 이 된다.
이때 만들어지는 보고서는 단순한 요약이 아니다. 과거의 내가 흘려놓은 파편들을, 현재의 맥락으로 불러와 합성한 결과물이다. 나는 이걸 시간차 페어 프로그래밍이라고 부른다.
보통의 페어 프로그래밍에는 인지적 마찰이 있다. 두 사람의 사고 모델이 다르기 때문이다. 그런데 이건 '나'라는 일관된 사고 모델 위에서, 과거의 나와 현재의 나 사이의 미묘한 시차만을 이용한다. 다른 사람과의 마찰 없이, 시각의 시차만으로 통찰을 증폭한다. 미래의 나가 과거의 나와 협업하는 셈이다.
그래서 무언가를 기록한다는 건 단순한 저장이 아니다. 미래의 나에게 건네는 가장 강력한 힌트를 남기는 일이다.
곁가지: 시간을 잡아주는 닻
기록에는 의도하지 않은 부작용도 있었다. 긴 세션에서 AI와 대화하다 보면, 에이전트가 대화 턴을 하루의 경과로 착각하는 '시간 표류'가 종종 생긴다. 어제 한 일을 일주일 전 일처럼 말하는 식이다.
vault 환경에서는 이게 눈에 띄게 줄었다. 모든 기록과 리비전이 ISO 8601 절대 타임스탬프를 달고 있기 때문이다. 에이전트는 '이전 메시지'라는 상대적 순서에 기대는 대신, 데이터에 박힌 절대 시간을 참조해 자기 인지 모델을 현실의 시간 축에 동기화한다. 지식의 저장소가 동시에 시간 감각의 닻이 되는 것이다.
결국 vault는 지식 창고를 넘어, 내 사고 방식이 응축된 외부의 뇌가 된다. 이 스타일은 다른 작업 문서로도 자연스럽게 번져 사고의 일관성을 강제한다. 도구가 단순한 망치가 아니라 내 인지를 매개하고 확장하는 협력자가 될 때, '기록'이라는 행위의 의미가 바뀐다.
깔끔하게 말하려 애쓰지 말 것. 불평하라. 도구가 그릇을 갖고 있다면, 그게 가장 좋은 입력이다.