오토포이에시스를 향해

나는 늘 무한한 번영을 꿈꿔왔다. 세속적인 번뇌에서 벗어나 번영하는 삶. 나도 자본재를 갖고 싶었고, 생산 수단의 주인이 되고 싶었다. 근데 내 체력과 집중력을 계속 갈아 넣고 싶지는 않았다.

나한테 내 어텐션은 너무 비싸다. 하고 싶은 게 너무 많으니까. 그래서 어텐션 사회에서 내 어텐션을 제일 적게 먹는 자가 발전 영구 기관을 만들고 싶었다. 나랑 정신적으로 합치된, 스스로 자라는 영구 기관을...

지난 1년 동안 AI랑 정말 많이 토론했고, 지적 노동을 영구히 자동화하는 길에서 꽤 의미 있는 발자국을 남긴 것 같아서 오랜만에 글을 쓴다.

착각 1. 자동화할 건 작업이 아니다

사람들은 자꾸

어떻게 하면 ((사람에게 어려운 작업))을 자동화할까?

를 묻는다. PR 리뷰를 어떻게 자동화할까, 코드베이스 이해를 어떻게 자동화할까, 이런 거. 내가 보기엔 너무 사람처럼 생각하는 질문이다. 2026년 10월 18일 기준 토큰을 6억 원어치쯤 태워 보니까, 제일 큰 병목은 전혀 엉뚱한 데 있었다.

취향의 합일이다.

사람은 생각이 이어진다. 그래서 에이전트도 같은 모델이면 그러려니 하기 쉽다.

근데 아니다. 에이전트는 태어날 때마다 취향이 다르고, 결정이 수렴하는 지점도 매번 다르다. skill이랑 마크다운을 아무리 깎아도 그랬다. 디자인 방향처럼 높은 안목까지 얹으려고 하면 더 어렵다.

근데 취향이란 게 뭘까. 결국 결정들의 묶음이다. 이 버튼은 여기 두고, 이 에러는 이렇게 터뜨리는 식의.

그러니까 내가 풀어야 했던 건 작업 자동화가 아니라 결정을 한 번 내리면 모든 에이전트가 그걸 따르게 하는 것이었다.

착각 2. 프론티어의 고민이 나에게도 유용할까?

업계는 사람을 루프에서 얼마나 덜어낼지(휴먼 인 더 루프)를 고민한다. 어텐션 0을 요구하지 않으니까. 회사에는 사람의 어텐션도 토큰만큼 싸다. 그리고 결정마다 책임질 사람이 있다.

나는 그럴 수 없었다. 결정마다 책임질 사람을 둘 수도 없고, 책임을 AI한테 지울 수도 없다. 그래도 엔진은 돌아가야 했다.

결국... 어텐션을 덜어내는 것과 어텐션을 "$\lim\limits_{x\to 0}$" 하는 건 차원이 다른 문제다. 덜어내기는 작업 하나에 드는 사람 손을 줄이는 거고, 0으로 보내려면 사람 손이 작업 수랑 아예 상관없어져야 한다.

업계의 질문은 PR 단위로 생겼다

업계의 질문은 대부분 누가 PR을 하나하나 지켜보고 있다는 전제에서 나온다.

그래서 이 질문들은 틀렸다기보다 나한테 딱히 쓸모가 없다. 기업의 고민은 사람을 만 명에서 백 명으로 줄이는 거고, 내 고민은 한 명에서 0명으로 만드는 거니까.

(물론 거꾸로 내 질문이 기업에도 똑같이 적용된다고 생각하긴 한다.)

왜 PR이 아니라 Decision인가

PR이 작업 단위인 세상에서는 내 어텐션이 PR 수에 비례한다. 에이전트가 하루에 PR을 수백 개씩 올리기 시작하면 그때부터 끝이다. 내가 병목이 된다. 그리고 이게 지금 업계 프론티어 고민이다.

근데 PR 수백 개를 뜯어보면 그 안에 든 결정은 몇 개 안 된다. 같은 결정이 PR마다 반복될 뿐이다(왜냐면, PR은 노이즈가 엄청 많기 때문에 방향성 결정이 숨어있기 때문). 그러면 사람이 봐야 할 건 PR이 아니라 결정이다.

• PR은 한 번 머지되면 끝이다. 결정은 다음 PR, 그다음 PR에서도 계속 일한다.
• PR은 스레드 하나에 묶여 있다. 결정은 에이전트 수백 개가 동시에 꺼내 쓴다.
• PR 리뷰는 매번 사람 손이 든다. 결정은 한 번만 내리면 된다.

베조스가 이런 말을 한 적이 있다. 고위 임원은 적은 수의 고품질 결정을 내리라고 돈을 받는 거고, 하루에 좋은 결정 세 개면 충분하다고. 이걸 계속 다루다 보니 나도 딱 그렇게 됐다.

그래서 내가 답한 질문은 전부 판례가 된다.

• 내 답 하나는 사실 하나만 담은 판례 문서로 남는다.
• 내가 교정하면, 교정받은 세션이 그 자리에서 해당 판례를 고친다.
• 나한테 뭘 묻기 전에 기존 판례부터 찾아보는 게 규칙이다.
  • 기존 유사 판례로부터 내가 내릴 결정이 꽤 높은 확률로 추측되는 경우, 멀티 모델 합의가 있으면 infer된다.
• 이미 답한 걸 또 묻는 것도, 내가 같은 말을 두 번 하게 만드는 것도 실패로 기록된다. 그것도 판례가 된다.

이게 중요한 이유가 하나 더 있다. 롱 호라이즌 컨텍스트는 만능이 아니고, 에이전트 수백 개가 동시에 비슷한 질문을 품고 있을 때는 결정이 ACID하게 공유돼야 한다. 한 에이전트가 들은 답을 다른 에이전트도 바로 알아야 한다는 말이다. 마크다운 같은 방식이면 머지 직전까지 결정이 공유가 안 되어서 병목이 된다.

이게 꽤 파격적이었던 게, 내 어텐션이 PR 수가 아니라 결정의 종류 수에 비례하게 된다. 같은 일에서 처음 보는 종류의 결정은 시간이 갈수록 줄어든다. 물론 새로운 걸 계속 만드니까 늘 어느 정도는 생긴다.

모든 대화를 통째로 임베딩해서 판례집 만들기

결정이 작업 단위가 되려면, 결정이 어딘가에 쌓이고 필요할 때 튀어나와야 한다. 근데 지금 에이전트 메모리는 그게 잘 안 된다. 특히 디버깅은 거의 장기 기억이 안 된다.

1. 일단 에이전트가 명시적으로 memory를 써야 하거니와,
2. 메모리를 써 봐야 그 스레드 내부의 직접적 디버깅만 남고,
3. 성공한 경험만 남지 실패한 경험은 안 남고,
4. 다음에 누가 의도적으로 기억을 불러와야 하고,
5. 다른 스레드, 다른 도구, 다른 컴퓨터에서 겪은 디버깅은... 굿럭.

그래서 그냥 작업 기록을 통째로 벡터 메모리에 넣었다. 9월 초부터 넣기 시작했는데 넣은게 18,025개다. 기왕 넣는 김에 Claude Code, Codex, GitHub 이슈, 옛날 컴퓨터 기록까지 다 합쳐서 73,802개 항목을 넣었다. 그리고 벡터 메모리가 이걸 Dreaming하게 했다 (서버 쪽에서 메모리를 정제하고 요약하는 거. 대충 백그라운드 분석이다.) 그렇게 해서 약 6,600개의 판례가 생겼다. 규칙과 관례가 약 1,400개, 디버깅하다 얻은 함정과 발견이 약 3,200개다. 나머지는 결정 기록이나 참고 자료 같은 것들이다. 규칙보다 경험이 훨씬 많다는 게 재밌다.

근데 기억은 꺼내 쓸 때 의미가 있다. 보통 규칙 파일은 세션 시작할 때 한 번 읽히고 끝이다. 그러면 오래 도는 세션에서는 Catastrophic forgetting 같은 문제가 생긴다(대충 앞 내용을 까먹는다는 말이다).

그래서 에이전트가 행동하기 직전에 PreToolUse hook으로 그 행동의 단어 그대로 메모리를 검색하게 했다. 셸 명령, 메일, 다른 스레드로 보내는 메시지, 예약 작업 전부 그렇다. 프롬프트 받을 때마다, 컨텍스트 압축한 뒤에도 다시 찾는다. (저렴한 모델로 이걸 빠르고 안정적으로 돌리려면 여러 기법이 필요한데, 그건 나중에 따로 얘기하겠다.)

핵심은 에이전트의 인지 부하를 줄여 주는 거다. 외우게 하면 안 되고, 필요한 정보가 늘 readily-available하게 손에 잡혀 있어야 한다.

아 참고로 마크다운으로 안 한 이유는, 워크트리 수백 개에서 동시에 작업하면 결정 사항이 동기화가 안 되는 치명적인 문제가 있어서다. 노션 같은 걸 안 쓴 이유는 지식은 구름처럼 서로 얽혀 있는 거지 위계가 있는 게 아니라서다. 거의 5년째 하고 있는 생각이다. 차세대 디지털 브레인 만들기 참고.

노션을 쓰라면 썼을 수도 있는데, 굳이 재발명하기 싫어서 Supermemory를 썼다. 물론 그들의 플러그인은 내가 원하는 방향과 좀 안 맞아서 하네스 플러그인은 내가 만들어서 쓰는 중이다.

취향의 자율주행

다시 처음 병목으로 돌아가 보자. 에이전트는 태어날 때마다 취향이 다르다. 근데 취향이 모델 안이 아니라 판례에 들어 있으면 얘기가 달라진다.

• 글쓰기, UI, 코드에 대한 내 취향이 전부 판례로 남아 있다.
  • 방어적인 코드는 안 쓰고, 제목 위아래에 eyebrow 라벨은 안 단다는 식이다.
• 새로 태어난 에이전트는 Opus든 GPT든 Muse든 Grok든 같은 판례를 꺼내 쓴다.
• 그래서 모델을 갈아 끼워도 취향은 리셋되지 않는다.

내가 매번 운전대를 안 잡아도, 엔진이 알아서 내 취향 쪽으로 조금씩 핸들을 꺾는다.

메시 엔지니어링

어텐션 0이라고 하면 다들 통제를 잃을까 봐 걱정한다. 이것도 관점 차이인데, 나는 코드베이스를 하나의 영속체로 보기로 했다. 그물망 엔지니어링 참고.

• 뭘 만들지, 뭘 머지할지 정하는 지휘자가 없다.
• 에이전트들은 이슈, PR, 판례 같은 흔적을 보고 알아서 일을 맡아 끝낸다.
• 작성한 에이전트는 자기 결과를 검증하지 않는다. 다른 회사 모델이 검토한다.
• 리뷰는 작업마다 새로 붙어서 리뷰 대기 줄이 안 생긴다.

여기서도 일을 굴리는 건 결국 결정이다. 지휘자가 없어도 판례가 있으니까 에이전트 수백 개가 같은 방향으로 간다.

그다음, 엔진에는 코리지빌리티가 있어야 한다. 교정 가능한 에이전트는 운영자를 속이지 않고, 자기 사고 과정을 숨기지 않고, 하위 에이전트를 만들 때도 전체 시스템의 교정 가능성을 지킨다. 이 엔진은 이렇게 지킨다.

• 내 교정 하나는 모든 스레드에 전달되고, 제일 최근에 한 말이 이긴다. 멈추라고 한마디 하면 전체가 멈춘다.
• 모든 대화와 작업 기록이 색인되니까 숨을 데가 없다.
• "실수는 괜찮지만 지름길과 속임은 안 된다"는 판례가 있다. 스크린샷이나 실제 확인으로 뒤집힐 수 있는 성공은 보고하지 않는다.
• 하위 에이전트를 띄울 때 hook이 허락 안 된 모델을 막고, 판례는 하위 에이전트한테도 그대로 따라간다.

업계에서 교정 가능성은 감시로 얻는다. 감시엔 어텐션이 든다. 여기선 교정도 결정이라서, 한 번 하면 앞으로 생길 모든 스레드에서 일한다. 그래서 교정 가능성이 오히려 어텐션을 아껴 준다.

뭐 그 외에도...

• 에이전트가 교정을 받으면 규칙과 skill을 직접 고친다. 개인 skill/mcp/hook 저장소에는 9월 이후 커밋이 500개 쌓였고, 지난 일주일에만 200개다.
• 정기적으로 대화 기록을 읽고 놓친 추측과 내 교정을 찾아 고친다. 고친 다음엔 다음 실행에서 진짜 효과가 있었는지 잰다.
• 매일 취향 시험을 쳐서 기억이 제대로 떠오르는지 시험 보고, 틀린 문제로 엣지 케이스를 늘린다.
• 에이전트가 각각 PR에서 유저가 된 것처럼 QA를 하고, 교차 검증하며, 반복적인 실수가 나오면 그 또한 판례가 된다.
• 공급사나 라이브러리도 더 나은 게 나오면 갈아 끼운다.

아무튼

업계는 PR을 어떻게 더 빨리, 더 적은 사람으로 리뷰할지 묻는다. 나는 PR 대신 결정을 단위로 일하는 엔진을 만들고 있다. 매일 내 손을 덜 타고, 조금씩 나를 닮아 간다.