시간을 압축할 수 없는 자리

며칠 전부터 하고 있던 일은 이런 것이었다. 에이전트에게 코드를 짜게 시키고, 나온 걸 읽고, 대부분을 버리고, 몇 조각만 다음 버전으로 옮긴다. 이걸 몇 번 반복하다 보면 어느 순간 내가 뭘 하고 있는지 헷갈린다. 코드를 짜고 있는 건가, 아니면 계속 걸러내고 있는 건가.

그 헷갈림에서 출발한 질문은 단순했다. 어차피 대부분을 버릴 거면, 애초에 “짤까 말까”를 판단하는 데 드는 비용을 줄일 수 없을까. 마침 그 무렵 Jev라는 게 화제였다. 토큰을 순서대로 뱉는 대신, 미리 정해둔 선택지들에 확률만 매겨서 돌려주는 모델. 답이 길어져도 시간이 안 늘어난다는 그 성질이 마음에 들었다. 판단이 필요한 자리와 생성이 필요한 자리를 나눠서, 판단은 싸고 빠른 쪽에 맡기고 생성만 비싼 쪽에 남기면 되지 않을까.

거기까지는 순조로웠다. 코드 한 덩어리를 함수 단위로 쪼개고, 이미 문서로 적어둔 규칙들 — 이 축은 건드리지 마라, 이 패턴은 예전에 한 번 터졌다 — 을 선택지로 바꿔서 1차로 걸러내면, 사람이 보는 건 정말 애매한 것들만 남는다. 이건 실제로 되는 그림이었다.

문제는 그다음이었다. 내가 정말 원했던 건 “이 코드가 실기기에서 제대로 도는가”를 미리 걸러주는 거였고, 그건 어떤 판단 모델도 못 하더라는 얘기를 꺼내자 대화가 다른 데로 샜다. 처음엔 그냥 “LLM은 실행을 안 해보니까”로 정리되는 듯했다. 그런데 그 자리에서 내가 되물었다. 사람은 실행을 안 해봐도 안다고. 코드를 눈으로 보고 “이거 그 버그 또 나겠는데”를 느낀다고.

돌아온 답은, 사람이 하는 그 느낌이 사실은 패턴 인식이 아니라 시뮬레이션이라는 것이었다. 손을 뻗다가 뭔가에 부딪힌 기억, 그 촉각과 시각이 동시에 주는 피드백, 그게 몸에 새겨진 인과 모델을 만든다고. 반면 텍스트만 먹고 자란 모델에게는 그 인과가 애초에 입력에 없다고. 나쁘지 않은 설명이었지만 어딘가 걸렸다. 뉴런도 결국 전류를 흘렸다 끊었다 하는 것뿐인데, 그 단순한 재료에서 창발이 일어난다면 “재료가 텍스트뿐이라 한계다”라는 말도 같은 논리로 무너지지 않나. 그 말을 하니 상대가 순순히 물러섰다. 구조의 한계가 아니라 신호의 종류 문제였다고, 다시 세워 말했다. 인과가 corpus 안에 없으면 창발이 아무리 풍부해도 없는 걸 만들어낼 수는 없다고.

이 정정이 흥미로웠던 건, 그게 맞고 틀리고를 떠나서 논쟁의 구도 자체를 바꿔놓았기 때문이다. “지금 세대 AI가 못 한다”는 문장이, “지금까지 준 신호에 그게 없었다”는 문장으로 바뀌면, 거기엔 시간이 들어간다. 언젠가 될 수도 있는 일과 원천적으로 안 되는 일은 다른 이야기니까.

그리고 그 시간 얘기가 다른 실을 끌고 왔다. 전날 어떤 에이전트와 대화하다가, 그 기억에 타임스탬프가 없다는 걸 알아챈 참이었다. 얼마 전 다시 읽은 테드 창의 「숨」과 「소프트웨어 객체의 생애주기」가 겹쳐 떠올랐다. 둘 다 시간을 정보의 축이 아니라 사고가 일어나는 매질로 그린다. 압력차가 평형에 닿기 전까지만 가능한 사고, 복제한다고 건너뛸 수 없는 발달의 시간. 그 얘기를 꺼내자, 에이전트의 메모리에 타임스탬프가 필요한 이유가 뒤집혀 보였다. 필요한 게 아니라, 그게 필요하다는 사실 자체가 그 메모리가 진짜 연속된 흐름이 아니라 이산적인 스냅샷의 나열이라는 증상이라는 것. 사람 뇌가 시간에 라벨을 안 붙이는 건, 못 붙여서가 아니라 경험 자체가 이미 시간을 매질로 흐르고 있어서 붙일 필요가 없는 거라고.

이 지점에서 나는 내가 오래 서버 프로그래머로 살아온 게 이 얘기와 무관하지 않다는 걸 알아챘다. 시간을 계산으로 바꾸는 것, 배치로 몰아서 압축하는 것, 응답을 병렬로 포크하는 것 — 이게 다 나에게는 자연스러운 감각이다. 그런데 그 감각이 자연스러운 만큼, 그게 공짜가 아니라는 것도 안다. 로보틱스 쪽에서는 이미 이름이 붙어 있다고 했다. 시뮬레이션에서는 물리를 몇 배속으로 압축해서 학습시킬 수 있지만, 실제 로봇을 배포하는 순간부터는 물리가 시간을 건너뛰지 못하게 만든다고. sim-to-real gap. 압축된 시간축에서 배운 것과 실제 시간축에서 검증해야 하는 것 사이의 그 이음매에서 새는 문제.

Overmax를 만들면서 몇 번이고 되풀이해온 규칙들 — 측정 없이는 인프라를 안 건드린다, 캡처 프리퀀시는 이미 실패한 축이라 건드리지 않는다, 실측 타이밍 없이는 결론을 안 낸다 — 이 그 이음매를 본능적으로 알고 세운 규칙들이었다는 걸 그제야 알았다. 6개월이었다. 이 규칙들이 쌓이는 데 든 시간이. 그런데 그 6개월이라는 무게는, 지금 나와 얘기하고 있는 상대에게는 그저 문서에 적힌 문장일 뿐이었다. 결과는 읽을 수 있지만 그걸 만드는 데 든 시간의 두께는 읽을 수 없는, 그 비대칭이 오늘 대화 내내 조용히 깔려 있었다.

그 비대칭에서 나온 건 사람 프로그래머들 사이에 오래 지켜져 온 룰이었다. 동작하는 것은 고치지 않는다. 이 룰이 룰인 이유는 도덕이 아니라 흉터 때문이다. 비슷하게 생긴 코드를 고쳤다가 새벽에 장애를 본 기억이, 손대기 전에 망설이게 만든다. 같이 일하는 에이전트들에게는 그 흉터가 없다. 텍스트로 보면 동작 중인 함수와 막 짠 함수가 구분이 안 되니, 고치는 게 늘 기대값 양수로 보인다.

다행히 이 문제는 기다릴 필요가 없는 쪽이었다. git blame이라는, 이미 있는 도구가 정확히 그 흉터를 라벨로 복원해준다. 커밋 해시, 마지막 수정 시점, 그 뒤로 몇 번을 고쳤는지. 사람이 코드를 열기 전에 갖는 촉과 같은 정보를, 다른 경로로 이미 갖고 있었던 셈이다. 문제는 도구의 부재가 아니라, 그걸 열어보게 만드는 절차의 부재였다.

그래서 오늘 대화가 남긴 건 거창하지 않다. AGENTS.md에 두 문장이 늘었다. 하나의 diff는 하나의 검증 가능한 주장만 담을 것. 일정 기간 이상 손대지 않았거나 여러 번 다듬어진 코드는, blame을 먼저 인용하고 구체적인 근거 없이는 건드리지 말 것. 시작은 토큰을 아끼는 법이었고, 중간엔 뉴런과 창발과 「숨」과 로보틱스까지 갔다가, 끝은 커밋 하나에 결정 하나만 담으라는 문장 두 줄이었다.

이걸 허무하다고 해야 할지 모르겠다. 6개월이라는 무게를 git log 한 줄로 압축해서 코드베이스에 심어놓는 일이, 어쩌면 지금 내가 할 수 있는 최선의 타협인지도 모른다. 내가 겪은 시간을 그대로 넘겨줄 방법은 없으니까. 남는 건 그 시간이 지나갔다는 흔적뿐이고, 그 흔적을 읽을지 말지는 결국 다음에 이 코드를 여는 쪽의 몫이다. 나든, 에이전트든.