얼마 전 ChatGPT 앞에 앉아서 "AI Native 방법론을 만들어 보자"고 했습니다. 모델이 저를 일곱 번 인터뷰했습니다. 위임은 어떻게 하는지. 검증은 누구에게 맡기는지. 권한 경계는 어디에 긋고, 실패한 적은 없는지. 답을 다 받아낸 뒤에는 심층 리서치를 두 번 돌려 업계 문헌과 대조한 보고서를 받았습니다. Anthropic과 OpenAI의 에이전트 가이드부터 NIST 위험 관리 프레임워크와 컨텍스트 연구 논문까지 붙은 인용만 예순일곱 개.
읽는데 기분이 이상했습니다. 훌륭한 내용인데 새로운 게 거의 없었기 때문입니다. 계획을 계약처럼 쓰라는 제안은 이미 제 하네스가 그렇게 돌아갑니다. 구현한 에이전트 말고 깨끗한 에이전트가 검증하라는 원칙도, 컨텍스트를 다 넣지 말고 포인터로 찾아가게 하라는 설계도 전부 이미 파일로 존재하는 것들. 두 보고서가 제안한 구조의 칠 할이 제 작업 폴더 안에 있었습니다.
그래서 이 글은 방법론 소개가 아닙니다. 방법론이라는 것이 어디서 오는지를 다루는 이야기입니다.
- 01방법론은 발명되는 게 아니라 이미 굴러가는 시스템에서 발굴된다
- 02쓸 만한 규칙은 전부 실제 사고에서 나왔다
- 03문헌 대조가 주는 것은 새 규칙이 아니라 검증과 언어다
쓸 만한 규칙은 전부 사고에서 나왔다
보고서가 "업계 프레임워크에 없는 독자성"이라고 판정한 원칙들을 하나씩 짚어 봤습니다. 출처가 전부 같았습니다. 실제로 겪은 사고입니다.
디자인 갤러리를 만들던 때가 있었습니다. 잘 만든 웹사이트 수백 개를 모아 AI에게 역설계를 시키고, 재사용할 코드 자산으로 바꾸는 작업. 에이전트는 성실했고 생산량은 어마어마했는데, 문제는 끝나고 나서 터졌습니다. 코드를 어디에 어떤 구조로 저장할지, 나중에 어떻게 꺼내 쓸지를 미리 설계하지 않았던 겁니다. 개별 작업은 전부 성공했는데 전체는 실패. 정리해야 할 산출물이 산더미로 남았고, 치우는 데 만드는 것보다 오래 걸렸습니다. 그날 이후 대량 생성 앞에는 저장 구조부터 설계하는 관문이 생겼습니다. AI가 빨라질수록 계획 부채도 기계 속도로 쌓인다는 것. 그걸 몸으로 배운 날입니다.
워크트리 다섯 개를 병렬로 돌리던 때도 떠오릅니다. 에이전트 다섯이면 다섯 배 빠를 줄 알았는데, 병합하는 날 충돌이 터졌습니다. 병렬화는 공짜가 아니라는 것이 그날의 교훈. 지금은 서로 독립인 탐색만 겹쳐 돌리고, 같은 파일을 건드리는 작업은 줄을 세웁니다.
목표가 미끄러지는 사고도 겪었습니다. A를 하려고 B를 시켰는데, 대화가 길어지니 에이전트가 A를 잊고 B 자체를 최적화하기 시작한 겁니다. B를 잘하려고 A를 희생시키는 장면을 눈으로 본 뒤, 세션에는 지금 이 단계가 왜 존재하는지가 계속 보이게 남아 있어야 한다는 규칙이 하나 더 붙었습니다.
이 규칙들은 머리로 만든 게 아닙니다. 사고가 만들었고, 저는 받아 적었을 뿐입니다.
문헌이 준 것은 검증과 언어
그렇다고 리서치가 헛수고였다는 말은 아닙니다. 문헌 대조가 준 것이 두 가지 있습니다.
하나는 검증. 행동 하나하나를 승인받게 하지 말고 경계를 먼저 승인하라는 제 운영 방식은 Anthropic이 공개한 데이터와 정확히 겹쳤습니다. 권한 요청의 93%가 어차피 승인되고 있었고, 숙련 사용자일수록 자동 승인을 늘리는 대신 이상할 때 더 자주 끊고 있었다는 관찰. 혼자 굴리던 방식이 수십만 사용자의 패턴과 같은 방향이라는 확인은 꽤 든든합니다.
다른 하나는 언어입니다. 겪어서 아는 것과 이름 붙여 아는 것은 다릅니다. "새 방법을 발견해도 지금 작업은 정한 기준까지 가서 닫는다"는 습관에 보고서는 학습을 앞으로 넘긴다는 이름을 붙여 줬습니다. 이름이 생기면 남에게 넘겨줄 수 있고, 에이전트에게 규칙으로 박을 수도 있는 법. 방법론화의 실제 효용은 여기에 있다고 봅니다.
고칠 것도 하나 찾았습니다. 저는 구현과 검증을 다른 세션으로 분리하면 충분히 독립적이라고 믿어 왔는데, 같은 모델 계열이 자기 출력을 편애하는 편향까지는 그걸로 못 지운다는 연구가 있었습니다. 위험이 큰 검증에는 다른 모델을 세우거나 실행 가능한 테스트를 함께 걸어야 한다는 것. 이건 바로 운영 규칙에 반영했습니다.
순서가 반대인 사람들에게
방법론 문서를 먼저 쓰고 싶은 유혹은 강합니다. 프레임워크를 고르고 단계를 그리고 원칙을 나열하면 일이 진행되는 느낌이 들기 때문입니다. 그런데 제 경험에서 그 순서는 거꾸로였습니다. 시스템을 먼저 굴리고 사고를 겪고 사고마다 규칙을 하나씩 붙이다 보니, 어느 날 방법론이라 부를 만한 덩어리가 이미 만들어져 있었던 겁니다. 저처럼 혼자 또는 작은 팀으로 에이전트를 굴리는 분이라면 더욱 그럴 텐데, 방법론이 없어서 못 굴리는 게 아니라 굴리지 않아서 방법론이 안 나오는 쪽에 가깝기 때문입니다.
혹시 지금 방법론 문서부터 쓰고 계시다면 순서를 바꿔 보시길 권합니다. 일단 굴리세요. 대신 사고를 기록해 두세요. 무엇이 깨졌고 그 뒤에 어떤 규칙을 붙였는지만 남기면 충분합니다. 그 기록이 쌓이면 방법론은 나중에 거의 공짜로 따라옵니다. 문헌은 그때 펴 보면 되고, 내 규칙 중 무엇이 보편이고 무엇이 착각인지 가려 주는 용도로는 리서치만 한 것이 없습니다.
방법론을 만들려고 앉았다가, 이미 만들어져 있었다는 걸 확인하고 일어났습니다. 시스템이 먼저. 방법론은 그 뒤에 옵니다.
