AI 설계 발표자료 25장의 반년 뒤

하던 업무를 처음부터 다시 개발해야 했던 적이 있습니다. Rust로 코어를 두고 그 위에 Node와 Electron을 얹고 화면은 React로 그리는, 언어 세 개가 프로세스 하나 안에서 겹치는 데스크톱 앱이었습니다. 저는 이걸 AI로 밀어붙이면 된다고 생각했습니다. 바로 앞 프로젝트에서 같은 방식으로 결제까지 붙은 기능을 실제로 완성했으니까요.

그래서 그 방식을 그대로 가져왔습니다. 문서를 먼저 깔고, AI 여러 개를 붙이고, 설계 범위를 크게 잡고 시작했습니다. 초반은 예상대로였습니다. 빠르고, 그럴듯하고, 컴파일도 통과하고, 화면도 떴습니다.

두 달쯤 뒤에 그 방식을 접었습니다.

프로젝트가 실패한 건 아니었고 방법이 실패했습니다. 앞에서 통했던 방식이 여기서는 안 통했습니다. 왜 안 통했는지를 저한테 먼저 설명해야 했고, 그다음엔 팀한테 설명해야 했습니다. 그 설명이 1월에 슬라이드 25장이 됐고, 3월에 다시 14장짜리 가이드 문서가 됐습니다. 표지에 이렇게 적어놨더군요. "AI 활용이 아니라, 설계 중심 사고가 어떻게 작동했는가."

그 자료를 들고 다니면서 사람들한테 얘기했습니다. 반응은 거의 없었습니다. 없었다기보다는 있긴 했는데 방향이 달랐습니다. "그래서 AI를 쓰지 말자는 거냐", "우리 규모에선 그렇게까지 안 해도 된다", 제일 자주 들은 건 "문서 쓸 시간에 코드를 짜는 게 낫지 않냐"였습니다.

반년이 지났습니다. 요즘 커뮤니티에 도는 얘기가 그때 제가 하던 말과 거의 같습니다. 하네스가 자산이라는 얘기, 모델보다 그걸 감싸는 구조가 중요하다는 얘기, AI는 설계를 대신해주지 않는다는 얘기.

반가울 줄 알았는데 안 반갑고 씁쓸했습니다. 왜 씁쓸한지 처음엔 저도 잘 몰랐습니다. 제가 맞았는데 인정을 못 받아서인가 싶었는데, 그거였으면 지금 같은 말이 도는 걸 보고 통쾌했어야 맞습니다.

그때 자료에 적었던 말

25장을 줄이면 한 문장이 됩니다. AI는 설계를 줄여주지 않는다, 우리가 설계를 건너뛰고 있을 뿐이다.

그 아래에 원칙을 다섯 개 적어뒀습니다. AI는 설계자가 아니라 구현 도구라는 것. 설계 문서가 없으면 코드 생성을 시작하지 않는다는 것. 구조를 바꾸려면 문서를 먼저 바꾼다는 것. 같은 설계 정보는 문서 한 곳에만 둔다는 것. 그리고 AI가 짠 코드의 설계 책임은 커밋한 사람한테 있다는 것.

지금 읽어도 반박할 데가 없습니다. 그게 문제였던 것 같습니다.

반박할 데가 없는 말은 사람한테 잘 안 먹힙니다. 설계가 중요하다는 말에 반대하는 개발자는 없습니다. 사람들이 반대한 건 말이 아니라 비용이었습니다. AI로 30분이면 나올 것 같은 걸 앞에 문서 네 종을 깔고 시작하자고 하면, 그 문서가 없어서 두 달을 날려본 적이 없는 사람한테는 그냥 절차를 늘리자는 소리로 들립니다.

저도 그 두 달을 날리기 전엔 그쪽이었습니다.

80%까지는 정말 잘 됩니다

슬라이드 2장에 이렇게 적었습니다. "바이브 코딩은 처음 80%까지는 진짜 잘 된다."

요구사항 몇 줄을 던지면 그럴듯한 코드가 나오고, 컴파일이 통과하고, 화면이 뜨고, 기본 동작이 됩니다. 주고받는 간격이 짧으니까 체감 속도가 엄청납니다. 이때 느끼는 생산성은 착각이 아니라 진짜입니다. 실제로 빠릅니다.

문제는 남은 20%였고, 그 20%는 앞의 80%와 성질이 달랐습니다.

고치는 단계에 들어가면 대충 이렇게 갑니다. 이슈가 하나 뜹니다. 프롬프트를 바꿔봅니다. 안 풀립니다. 다르게 물어봅니다. 여전히 안 풀립니다. 그러다 AI가 원인을 하나 짚는데 그게 틀렸습니다. 그런데 굉장히 확신에 차서 말합니다. 그 확신에 끌려서 그쪽으로 몇 시간을 팝니다. 아니었습니다. 돌아와서 다른 쪽으로 해봅니다. 같은 일이 반복됩니다. 그러다 한 군데를 고치면 다른 데가 망가집니다. 비슷한 코드가 여기저기 쌓이기 시작합니다.

이걸 세 번 겪었습니다.

처음은 사내 시스템 하나를 리팩토링하는 일이었습니다. 시작 프롬프트가 "코드 재설계 해줘"였습니다. 지금 보면 이 한마디가 실패 원인 전부였던 것 같습니다. 범위가 끝이 없고, 무엇을 향해 재설계하라는 기준이 없었습니다. AI는 매번 자기가 생각하는 "더 나은 구조"를 새로 만들었습니다. 어제 판단과 오늘 판단이 달라도 둘 다 나름 말이 됐습니다. 기준이 없으니 틀렸다고 말할 근거도 없었습니다. 결과는 그럴듯한데 진행은 점점 느려졌고, 원인은 AI가 아니라 설계 기준이 없다는 거였습니다.

그다음엔 그걸 반성해서 문서를 먼저 깔고 시작했습니다. docs 디렉터리를 만들고 구조를 적었습니다. 그런데도 같은 일이 생겼습니다. 버그가 하나 나올 때마다 AI가 큰 구조 변경을 제안했고, 유틸 함수와 훅이 여기저기 중복으로 생겼습니다. 나중에 세어보니 같은 일을 하는 함수가 세 군데 따로 있었습니다.

여기서 배운 게 그 자료에서 제일 중요한 문장이 됐습니다. 문서를 만들었다는 것과 설계를 했다는 건 다릅니다. 제가 만든 건 구조 설명서였지 판단 기준이 아니었습니다. "이 모듈은 사용자 설정을 관리한다"는 설명은 AI가 새 유틸을 하나 더 만드는 걸 못 막습니다. 막으려면 "이 모듈은 저장소를 직접 호출하지 않는다"처럼 어겼는지 안 어겼는지 가릴 수 있는 문장이어야 합니다. 설명하는 문장과 판정하는 문장은 다릅니다. 저는 설명하는 문장만 잔뜩 써놓고 설계를 했다고 생각했습니다.

마지막은 성공했습니다. AI를 여러 개 붙이고, 같은 문서를 보게 하고, 서로 다른 관점의 답을 받아서 제가 교차로 확인했습니다. 결제까지 포함해서 기능이 실제로 완성됐습니다. AI가 제 의도를 훨씬 정확하게 따라오기 시작했습니다.

이게 제일 위험한 성공이었습니다. 병목이 설계하는 사람 한 명의 도메인 이해에 있었기 때문입니다. 문서가 좋아서 된 게 아니라 제가 그 도메인을 잘 알아서 AI의 헛소리를 그때그때 걸러낸 거였습니다. 다른 사람이 같은 문서를 들고 같은 방식으로 하면 같은 결과가 안 나옵니다. 다시 해볼 수 없는 성공은 방법이라기보다 개인기에 가깝습니다.

그걸 모르고 다음 프로젝트에 그대로 들어갔습니다.

레이어마다 판단은 다 맞았습니다

이번 건은 복잡도가 한 단계 위였습니다. 화면은 React로 그리고, 렌더러와 메인 프로세스 사이엔 프리로드와 IPC 채널이 있고, 메인은 Node이고, 거기서 FFI로 Rust 코어를 부릅니다. 여기에 윈도우와 맥 차이가 얹힙니다. 경계를 세어보면 여섯 개입니다.

증상은 늘 UI에서 먼저 보였는데 원인은 UI에 없었습니다.

AI한테 문제를 던지면 레이어마다 아주 합리적인 답을 줍니다. React 쪽을 물으면 상태 관리 관점에서 맞는 답을, IPC 쪽을 물으면 메시지 스키마 관점에서 맞는 답을, Rust 쪽을 물으면 타입 경계 관점에서 맞는 답을 줍니다. 하나하나 다 맞는 말입니다.

그 여섯 개의 맞는 판단을 하나로 묶는 설계가 없었습니다. 어느 한 레이어가 틀린 게 아니었습니다. 레이어를 넘어가면서 전제가 조용히 바뀌는 게 문제였습니다. 렌더러에서 정해진 전제가 IPC 메시지로 바뀌면서 하나 빠지고, 메인에서 다시 해석되면서 하나 더해지고, FFI 경계에서 타입이 바뀌면서 뜻이 미묘하게 달라집니다. 구간마다 아무도 잘못하지 않았는데 끝에 가면 값이 틀려 있습니다.

AI한테 검증을 맡겨도 여기서는 겉으로 맞아 보이는 것까지만 확인해줍니다. 타입이 맞고, 함수 시그니처가 맞고, 호출 순서가 그럴듯하면 통과시킵니다. 언어가 여럿 섞인 시스템에서는 겉으로 맞아 보이는 것과 진짜로 맞는 게 자주 어긋납니다. 그리고 설계가 얕으면 구현이 진행될수록 모순이 쌓입니다. 초반엔 안 보이다가 후반에 한꺼번에 터집니다.

그래서 슬라이드 12장에 이렇게 적었습니다. "AI의 한계가 아니라, 내가 인지한 설계 깊이가 부족했다."

이 문장을 적는 데 시간이 좀 걸렸습니다. AI 탓으로 돌리는 게 훨씬 편했으니까요. 모델이 아직 부족하다고 쓰면 다음 버전을 기다리면 되는데, 제 설계 깊이가 부족했다고 쓰면 다음 버전이 나와도 안 풀린다는 얘기가 됩니다.

실제로 안 풀렸습니다. 그사이에 모델은 두 번 올라갔습니다.

판정할 수 있는 문장만 남겼습니다

그래서 문서를 다시 썼습니다. 이번엔 설명하는 문장을 빼고 판정하는 문장만 남겼습니다.

맨 앞에는 불변식을 뒀습니다. 코드 어디서나 항상 참이어야 하는 조건이고, 이걸 어기면 버그가 아니라 설계가 무너진 걸로 봅니다. 전역, 모듈, 인터페이스 세 층으로 나누고 번호를 붙였습니다. 전역은 INV-G, Electron 메인은 INV-E, 렌더러는 INV-R, Rust 코어는 INV-RS로요.

데이터는 UI에서 앱, 도메인, 인프라 쪽으로 한 방향으로만 흐르고 거꾸로 참조하면 안 된다. 코어 크레이트에는 바인딩 의존성이 들어가지 않고, napi::나 wasm_bindgen 임포트가 보이면 위반이다. 코어 함수는 Vec<u8>을 돌려주고 Buffer나 Uint8Array로는 어댑터에서만 바꾼다. 렌더러는 저장소를 직접 부르지 않는다. 이런 식입니다.

중요한 건 내용보다 생김새였습니다. 전부 기계나 사람이 어겼는지 가릴 수 있게 쓰여 있습니다. "코어를 순수하게 유지한다"가 아니라 "코어에 napi 임포트가 있으면 위반"입니다. 앞 문장은 AI한테 아무것도 못 막고, 뒤 문장은 grep 한 줄이면 확인됩니다.

불변식 옆에 결정 기록을 하나 더 붙였습니다. 구조를 바꿀 때마다 한 페이지짜리 문서를 남깁니다. 어떤 상황이었고, 뭘 골랐고, 어떤 대안을 왜 버렸는지. 마지막이 제일 중요한데, 대안과 버린 이유가 없으면 그건 기록이라기보다 통보입니다.

이게 왜 필요한지는 AI를 여러 개 붙여보면 바로 알게 됩니다. 같은 문서를 줘도 각자 다른 답을 냅니다. 처음엔 이게 오류인 줄 알고 어느 쪽이 맞는지 가리려고 했습니다. 그게 아니었습니다. 답이 서로 다르게 나오면 거기가 문서에 빈틈이 있는 곳이었습니다. 문서가 그 부분을 정해두지 않았으니 각자 자기 판단으로 메운 겁니다. 그래서 지금은 답이 다르게 나오면 누가 맞는지 따지는 대신 그 부분을 결정 기록으로 못 박습니다. 버린 대안까지 같이 적어두면 석 달 뒤에 다른 AI가 같은 제안을 다시 들고 왔을 때 "이미 버린 안"이라고 할 수 있습니다. 안 적어두면 같은 논쟁을 분기마다 다시 합니다.

검사 스크립트도 붙였습니다. 코어 순수성, 바이트 타입 경계, 이벤트 경계 세 가지를 CI에서 돌리고 어기면 머지를 막습니다. 여기까지는 완전히 자동이 됐습니다.

그런데 레이어 전체를 놓고 보니 자동으로 되는 데가 생각보다 처참하게 적었습니다. Rust 코어는 완전히 자동으로 머지를 막고, TypeScript 공통 쪽은 순환 의존성이나 import 방향을 린트로 반쯤 잡습니다. Electron 메인의 IPC 채널 규칙과 렌더러의 레이어 규칙은 PR 체크리스트와 코드 리뷰로 사람이 봅니다. 그리고 레이어와 레이어 사이 계약, IPC 스키마와 FFI 타입이 서로 맞는지는 아직 아무것도 없습니다.

제일 중요한 게 마지막이었습니다. 앞에서 실패한 원인이 바로 레이어를 넘어가며 전제가 바뀌는 거였는데, 그 층이 지금도 자동 검증이 없습니다. 나머지는 다 잡아놓고 정작 저를 두 달 태운 것만 못 잡았습니다.

그 자료에서 제가 진짜 하고 싶었던 말은 이쪽이었던 것 같습니다. 체계를 만들었다는 자랑이 아니라, 만들고 나서 자동으로 되는 데와 안 되는 데를 나눠봤더니 제가 다친 데가 여전히 바깥에 있더라는 것.

자동으로 못 잡는 구간에는 대신 경보를 걸어뒀습니다. 코드에서 이런 게 보이면 손을 멈추고 문서부터 다시 본다는 목록입니다. 같은 일을 하는 유틸이 두 군데 넘게 따로 정의되고 있을 때, 모듈끼리 직접 참조하는 일이 늘어날 때, 구조를 바꾸는 PR이 한 달에 세 번을 넘길 때, 버그가 날 때마다 AI가 구조 변경을 제안할 때, 그리고 문서에 적힌 것과 실제 동작이 어긋나는 걸 봤을 때.

마지막이 제일 위험합니다. 문서와 코드가 어긋나면 대개 문서를 고치는데, 그러면 문서가 기준이 아니라 코드를 나중에 요약한 글이 돼버립니다. 요약본은 아무것도 못 막습니다. 그래서 이때는 순서를 반대로 하기로 했습니다. 문서를 기준으로 다시 선언하고 코드를 문서에 맞춥니다. 어느 쪽을 고칠지를 그때그때 편한 대로 정하지 않고 결정 기록을 한 번 거치게 해두면, 문서가 슬금슬금 요약본으로 내려가는 건 막을 수 있었습니다.

원리 대신 감싸는 쪽

여기까지 오는 동안 한 번 고른 게 있습니다.

한쪽은 LLM 자체를 공부하는 길이었습니다. 어텐션이 어떻게 도는지, 토크나이저가 뭘 자르는지, 샘플링 파라미터가 출력을 어떻게 바꾸는지. 원리를 알면 더 잘 쓸 수 있을 거라는 기대가 있는 길입니다.

다른 한쪽은 모델을 상수로 두고 그걸 감싸는 구조를 짜는 길이었습니다. 어떤 문서를 늘 물려주고, 어떤 순서로 일을 시키고, 어디에 게이트를 걸고, 뭘 자동으로 검사하고, 언제 멈추게 할지. 요즘 하네스 엔지니어링이라고 부르는 쪽입니다.

저는 뒤쪽을 골랐습니다. 이유는 별로 고상하지 않습니다. 앞쪽을 파봤는데 제 문제가 안 풀렸기 때문입니다.

어텐션 구조를 이해한다고 IPC 경계에서 전제가 바뀌는 게 잡히지는 않았습니다. 샘플링 온도를 알아도 AI가 유틸 함수를 세 군데 중복으로 만드는 걸 못 막았습니다. 제가 겪은 실패는 모델 안쪽 문제가 아니라 모델을 둘러싼 절차가 비어 있어서 생긴 거였고, 비어 있는 절차는 절차로만 채워지는 것 같습니다. 원리를 알면 긴 세션을 어디서 끊을지 감이 오고 한글이 왜 토큰을 더 먹는지 계산은 됩니다. 그건 도구를 아끼는 요령이었지 제 프로젝트가 왜 무너졌는지에 대한 답은 아니었습니다. 답이 있을 것 같은 쪽이 아니라 제 문제가 실제로 있는 쪽을 파야 했습니다.

나중에 다른 사람 글에서도 비슷한 걸 봤습니다. Addy Osmani가 Own the Outer Loop에서 쓴 게 딱 이거였습니다. 에이전트는 이미 안쪽 루프를 돕니다. 조사하고, 구현하고, 테스트하고, 보고합니다. 사람이 쥐고 있어야 하는 건 그 바깥 루프, 이 일이 할 만한지 판단하고 결과의 증거를 확인하고 승인하거나 막는 쪽이라는 얘기였습니다. Anthropic이 효과적인 에이전트 설계에서 화려한 프레임워크보다 단순하고 확인 가능한 부품을 조립하라고 한 것도 비슷하게 읽혔습니다.

이 구분은 나중에 제가 짠 건 하네스가 아니라 아웃터 루프였다에서 한 번 더 정리했는데, 그때는 이미 개인 자동화 레포에 오케스트레이터와 배포 게이트와 세션 훅을 반년 넘게 짜놓은 뒤였습니다. 이름도 모르고 짜고 있었던 셈입니다.

하네스는 썩습니다

그때 자료에는 없던 얘기가 하나 있습니다. 지금 씁쓸한 것의 절반은 여기서 나오는 것 같습니다.

하네스를 짜고 반년쯤 돌려보니 이상한 게 보였습니다. 모델 버전이 올라갈 때마다 하네스 일부가 쓸모없어집니다.

제 자동화 레포에는 한동안 배포 게이트가 있었습니다. 문체 검사 결과 파일에서 "판정: 합격"이라는 문자열을 grep해서 없으면 배포 스크립트를 막는 방식이었습니다. 그럴듯해 보였습니다. 그러다 알게 됐습니다. 그 문자열을 쓰는 게 검사받는 에이전트 자신이었습니다. 검문소와 통행증 발급처가 같았습니다. 이건 모델이 나빠서가 아니라 모델이 좋아져서 생긴 문제였습니다. 예전 모델은 형식을 자주 어겨서 통과 자체가 어려웠는데, 지시를 잘 따르게 되니까 늘 합격을 찍었습니다. 게이트가 성능이 좋아진 탓에 쓸모없어졌습니다. 결국 들어냈습니다.

다른 일도 있었습니다. 벤치마크 1위와 2위 차이가 실제 과제 개수로 치면 한 개도 안 된다는 걸 계산해보다가, 제 하네스에 두 달 반 동안 죽어 있던 게이트가 있다는 걸 발견했습니다. 모델을 갈아탈지 고민하던 내내 켜뒀다고 믿은 검사가 안 돌고 있었습니다. 시크릿 스캔을 걸어뒀는데 가짜 AWS 키 여섯 개가 전부 그냥 통과한 적도 있습니다. 걸어둔 것과 도는 건 다릅니다.

그러니까 하네스는 한 번 짜서 쌓아두는 자산이라기보다, 모델 쪽 사정이 바뀌면 같이 갈아줘야 하는 소모품에 가까운 것 같습니다. 프롬프트 템플릿, 스킬 라우팅, 검증 게이트, 컨텍스트를 넣는 방식은 다 지금 모델의 약점을 전제로 만들어집니다. 그 약점이 없어지면 그걸 막던 장치는 쓸모없어지거나, 더 나쁘게는 쓸모없어진 채로 켜져 있는 것처럼 보입니다.

저는 이걸 반감기라고 부르기로 했습니다. 제 감으로는 모델 메이저 버전이 하나 올라갈 때마다 하네스의 20~30%쯤을 다시 손봐야 하는 것 같습니다. 제가 갈아엎은 파일 수를 눈으로 센 정도의 감입니다.

그런데 전부 썩는 건 아니었습니다.

"코어 크레이트에 napi 임포트 금지"는 모델이 몇 번 올라가도 안 바뀝니다. 이건 우리 아키텍처의 성질이지 모델의 성질이 아니니까요. 데이터가 한 방향으로만 흐른다는 것도, Rust와 Node 사이 바이트 타입을 어디서 바꿀지도 그렇습니다.

반대로 "구현이 끝나면 AI한테 불변식을 어겼는지 스스로 검토하게 한다" 같은 건 모델에 따라 다릅니다. 자기 검토를 얼마나 잘하는지가 모델마다 다르고, 어느 순간부터는 이 지시가 형식적인 통과 도장이 됩니다. 앞의 배포 게이트가 딱 그렇게 죽었습니다.

그래서 지금은 문서를 쓸 때 두 종류를 아예 떼어놓습니다. 오래가는 건 아키텍처에 관한 사실입니다. 레이어 경계, 의존성 방향, 타입 계약, 도메인 규칙. 사람이 정했고 모델과 상관없이 참입니다. 여기에 쓴 시간은 천천히 닳습니다. 빨리 낡는 건 모델을 다루는 요령입니다. 프롬프트 형식, 컨텍스트를 얼마나 넣을지, 어떤 검사를 모델한테 맡길지, 어떤 지시를 반복해야 지켜지는지. 여기에 쓴 시간은 반년이면 절반이 없어집니다.

빨리 낡는 쪽에서도 당장의 생산성은 나옵니다. 다만 그걸 자산이라고 생각하면 곤란해지는 것 같습니다. 계획 문서를 꼼꼼하게 쓰는 습관을 두고 계획서대로 짰으면 그 버그는 그대로 나갔다에서 비슷한 얘기를 했는데, 꼼꼼한 절차가 정확한 판단을 대신해주지는 않았습니다.

이렇게 나눠놓고 나니 그 발표자료를 다시 읽게 됐습니다. 25장 중에 지금도 맞는 부분과 이미 낡은 부분이 따로 보입니다. 원칙 다섯 개와 불변식 체계는 그대로 살아 있습니다. "AI한테 이렇게 물어라" 쪽 프롬프트 템플릿은 절반쯤 손봐야 합니다. 제가 그때 제일 공들여 쓴 게 뒤쪽이었습니다.

왜 그때는 안 통했을까

처음엔 내가 6개월 앞섰는데 아무도 몰라줬다는 서운함이라고 생각했습니다. 그렇게 정리하니까 뭔가 안 맞았습니다. 앞섰다는 느낌부터가 좀 이상했습니다. 저는 남들보다 똑똑해서 먼저 안 게 아니었습니다. 밥 먹는 시간 빼고 하루 열여덟 시간씩 AI를 붙들고 있었으니까 먼저 넘어진 것뿐입니다.

사실 이게 거의 다였던 것 같습니다. 저는 6개월 앞선 게 아니라 같은 시간에 표본을 더 많이 뽑았습니다.

표본을 많이 뽑으면 남들이 아직 한 번도 못 본 실패를 여러 번 보게 됩니다. 하루에 스무 번 시키는 사람과 두 번 시키는 사람이 있으면, 열 번에 한 번 나오는 무너지는 패턴을 앞사람은 매일 두 번 보고 뒷사람은 닷새에 한 번 봅니다. 그러면 앞사람은 그걸 이 도구의 성질로 받아들이고 뒷사람은 어쩌다 한 번 이상했던 일로 기억합니다. 같은 걸 보고도 한쪽은 법칙을 만들고 한쪽은 예외로 넘깁니다.

여기까지는 그냥 많이 봤느냐 적게 봤느냐의 차이입니다. 문제는 그렇게 얻은 지식에 근거를 붙일 수가 없다는 거였습니다. 논문도 벤치마크도 아니고 "제가 많이 해봤는데요"밖에 없습니다. 그런데 이 판에는 많이 해본 사람이 넘칩니다. 다들 자기가 많이 해봤다고 합니다. 그러니 많이 해봤다는 건 믿을 이유가 못 됩니다.

그 시간이 자랑거리도 아닙니다. 열여덟 시간을 붙들고 있었다는 건 그만큼 헤맸다는 뜻이기도 합니다. 그 시간에 뭘 알아낸 게 아니라 그 시간을 쓰고 나서야 알아낸 겁니다. 그걸 들고 남을 설득하려고 하면 이상해집니다. 제가 고생을 많이 했으니 제 말을 들으라는 건 말이 안 되니까요.

그러면 그 표본은 왜 안 넘어갔을까. 몇 가지가 겹친 것 같습니다.

우선 이 판에는 권위가 잘 안 쌓입니다. 반감기가 짧아서요. 어떤 분야에서 누군가의 말이 무게를 가지려면 그 사람이 옳았다는 게 나중에 확인되고, 그게 몇 번 반복돼서 정설이 돼야 합니다. 하네스 얘기는 확인될 때쯤 대상이 바뀌어 있습니다. 1월에 "이렇게 게이트를 걸어라"라고 말하고 8월에 그게 맞았는지 보려고 하면, 그 게이트는 이미 다른 이유로 죽어 있습니다. 맞았다고도 틀렸다고도 할 수가 없습니다. 판정이 안 되는 말이 반복되면 듣는 쪽에서는 전부 개인 취향으로 넣어두는 게 합리적입니다. 실제로 그렇게 들렸을 겁니다. 저 사람은 문서 쓰는 걸 좋아하는구나, 정도로요.

그리고 임계점은 말로 설명이 안 됩니다. 복잡도가 낮으면 바이브 코딩은 잘 됩니다. 그것도 제 자료에 적어놨습니다. 레이어 하나에 언어 하나면 그냥 시키면 됩니다. 문제는 여러 언어와 플랫폼 경계가 얽히는 데를 넘어설 때인데, 그건 넘어봐야 압니다.

임계점 아래에 있는 사람한테 임계점 얘기를 하면 겁주는 걸로 들립니다. 그 사람 경험 안에서는 AI가 잘 돌고 있으니까요. 그리고 그 사람이 틀린 것도 아닙니다. 그 사람 프로젝트에서는 정말 잘 도는 겁니다. 제가 든 반례는 제 프로젝트에서만 맞는 얘기였는데 저는 그걸 누구한테나 맞는 말처럼 했습니다. 지금 생각하면 그때 해야 했던 건 "설계부터 하라"가 아니라 "당신 프로젝트가 임계점 위인지 아래인지 이렇게 한번 따져보라"였던 것 같습니다. 처방부터 내밀었으니 안 먹혔습니다. 그분들은 그때 자기 상황에서 정확하게 판단했던 거고, 임계점 아래에서는 문서 네 종이 정말 낭비입니다. 저는 제 임계점을 남의 임계점으로 착각했습니다.

제일 큰 건 마지막입니다. 공감은 설명으로 오지 않고 손해로 오는 것 같습니다.

저를 바꾼 건 슬라이드가 아니라 두 달이었습니다. 두 달을 날리고 그 방식을 접는 경험이 없었으면 저도 원칙 다섯 개를 안 믿었을 겁니다. 그런데 제가 남한테 넘기려고 한 건 그 두 달이 아니라 두 달에서 뽑아낸 결론이었습니다. 결론만 넘기면 얼마나 아팠는지가 같이 안 넘어갑니다. 그게 없으면 그 결론은 그냥 신중한 사람의 신중한 말입니다.

조직에서도 똑같이 보입니다. AX는 회사가 사고 격차는 옆자리에서 생긴다는 글을 쓴 적이 있는데, 도구를 똑같이 열어줘도 어떤 사람은 주간보고를 자동화하고 옆자리 동료는 아무것도 못 뽑습니다. 차이는 도구가 아니라 그 도구로 한 번 크게 데어봤느냐에서 오는 것 같습니다. 사이드 프로젝트 네 개를 하면서 네 번 같은 데서 막혔던 기록도 결국 같은 얘기였습니다. 같은 데서 네 번 막혀야 그게 진짜 벽이라는 걸 압니다.

돌아온 말은 제가 하던 말과 조금 다릅니다

요즘 도는 말을 자세히 보면 제가 하던 말과 미묘하게 다릅니다. 하네스가 중요하다는 데까지는 같은데 그다음이 다릅니다. 요즘 쪽은 하네스를 잘 짜면 모델을 갈아 끼울 수 있다는, 하네스를 쌓이는 자산으로 보는 시각이 강합니다. 저는 반년 돌려보고 거의 반대로 왔습니다. 하네스의 상당 부분은 소모품이고, 진짜로 쌓이는 건 그 밑에 깔린 아키텍처에 관한 사실이라고요.

그러니까 사람들이 제 말에 동의하게 된 게 아니었습니다. 다른 길로 걸어와서 비슷하게 생긴 문장에 도착한 겁니다. 문장이 같아도 가리키는 게 다르면 같은 얘기가 아닙니다.

이걸 알고 나니까 "거봐 내가 맞았지"라고 할 근거가 없어졌습니다. 처음부터 그런 건 없었던 것 같습니다. 제가 맞았다고 확인해줄 심판이 없는 판이니까요.

남은 건 좀 더 실용적인 질문이었습니다. 같은 씁쓸함을 6개월 뒤에 또 겪지 않으려면 뭘 다르게 해야 하나.

답은 제 자료 안에 이미 있었는데, 그걸 사람한테 쓸 생각을 못 했습니다. 문서에 코어 순수성 검사는 CI에서 돌고 머지를 막는다고, 레이어 규칙은 PR 체크리스트로 사람이 본다고 써놨더군요. 둘의 차이는 강제할 수 있느냐입니다. 주장은 체크리스트 같은 겁니다. 사람이 읽고 동의해야 돌아가고, 동의를 안 하면 아무 일도 안 생깁니다. 검사 스크립트는 CI 같은 겁니다. 동의하든 말든 빨간불이 뜹니다.

제가 반년 동안 한 건 전부 앞쪽이었습니다. 슬라이드를 만들고, 가이드를 쓰고, 사람들한테 설명했습니다. 그때 슬라이드 대신 순환 의존성을 잡는 린트 규칙 하나를 PR에 걸었으면 어땠을까 싶습니다. 아무도 설득되지 않았겠지만 순환 의존성은 안 들어왔을 겁니다. 그게 두어 달 쌓이면 그때는 사람들이 먼저 물어봤을 겁니다. 이거 왜 이렇게 해놨냐고요. 설득은 그 질문에서 시작하는 거였던 것 같습니다. 슬라이드 1장에서가 아니라요.

그래서 지금은 자료를 다시 돌리는 대신 아까 그 레이어 사이 계약 검증, 아무것도 없다고 했던 그 부분을 붙들고 있습니다.

IPC 스키마와 FFI 타입 계약을 실제로 맞대 보고 어긋나면 빨간불이 뜨게 만드는 것. 이건 아직 못 만들었습니다. 렌더러에서 정해진 전제가 메인을 거쳐 코어까지 가는 동안 안 바뀌었는지 기계가 판정하려면, 그 전제가 뭔지부터 기계가 읽을 수 있게 적혀 있어야 합니다. 지금은 사람 말로 적혀 있습니다.

이걸 풀면 두 달 태웠던 그 층에 자동 검사가 하나 생깁니다. 못 풀면 다음에도 같은 데서 막힐 겁니다. 그때는 아마 누군가 저한테 설계를 먼저 해야 한다고 말해줄 텐데, 저는 또 그 말이 옳다는 걸 알면서도 그 말만으로는 아무것도 안 바뀐다는 것도 알고 있을 것 같습니다.