내 규칙은 전부 흉터다

나는 AI 에이전트한테 오픈소스 기여를 시킬 때 지키게 하는 규칙 목록을 갖고 있다. 저장소 정책부터 확인할 것, 재현되지 않으면 손대지 말 것, 프로젝트가 어디로 가는지 볼 것, 하루에 하나만 올릴 것.

이렇게 적어두면 그럴듯한 방법론처럼 보인다. 실제로는 전부 얻어맞고 나서 붙인 것들이다. 규칙이 먼저 있고 사고를 막은 게 아니라, 사고가 먼저 있었고 그 자리에 규칙이 하나씩 생겼다.

아래 넷은 그렇게 생긴 규칙들이고, 순서는 내가 데인 순서다.

차단당했다

vitest라는 프로젝트에 PR을 하나 올렸다. 그 저장소가 "AI로 만든 PR은 받지 않는다"고 명시해둔 걸 나는 못 봤다.

뒤늦게 알고 해명을 달았다. "저 진짜 사람이에요. 최종 diff도 직접 검토했고, 기여 가이드라인도 지켰고, AI를 썼다는 것도 본문에 밝혔습니다." 길게 썼다. 돌아온 답은 짧았다. "그 해명도 AI가 쓴 것 같은데요. 사람이냐고 묻는 질문에 AI로 답하지 마세요."

결국 그 조직 전체에서 차단당했다. 내 해명조차 AI처럼 읽혔다는 게 오래 남았다.

그날 첫 번째 규칙이 생겼다. 기여하기 전에 그 저장소가 AI를 어떻게 대하는지부터 확인한다. 금지한 곳은 아예 건드리지 않는다.

그냥 틀렸다

serde라는 프로젝트에 버그라고 생각한 걸 고쳐서 올렸다. 메인테이너가 답했다. "원래 코드가 맞습니다. 그래도 고마워요."

나는 버그가 아닌 걸 버그라고 우겼던 거다. 재현을 제대로 안 해봤으니까.

그래서 두 번째 규칙이 붙었다. 버그를 로컬에서 진짜로 재현하고, 근본 원인을 이해하기 전엔 손대지 않는다.

잘했는데도 닫혔다

bootstrap에서는 다 제대로 했다. 재현하고, 테스트 붙이고, 최소한으로 고쳤다. 그런데 창시자가 닫으면서 이렇게 남겼다. "다음 버전 재작성에서 이 부분을 통째로 들어냈습니다. 그래서 닫아요."

내가 고친 코드 자체가 곧 사라질 예정이었던 거다. 이건 내 잘못이 아니라 세상이 내 발밑에서 움직인 쪽에 가깝다. 그렇다고 들인 시간이 돌아오지는 않는다.

여기서 세 번째 규칙이 나왔다. 손대기 전에 이 프로젝트가 지금 어디로 가고 있는지부터 본다.

누가 먼저, 더 잘 고쳤다

tailwind에 올린 PR에는 이런 답이 왔다. "고맙지만 저는 다른 방식으로 이미 고쳤어요. 그리고 당신 수정은 이 경우는 풀어도 저 경우는 못 풉니다."

나는 증상을 봤고, 그 사람은 뿌리를 봤다. 같은 화면을 보고도 보는 깊이가 달랐다.

마지막 규칙은 여기서 왔다. 이미 같은 걸 고치는 사람이 있는지 먼저 확인하고, 증상이 아니라 원인을 고친다.

왜 프롬프트가 아니라 규칙인가

이 네 가지를 그냥 프롬프트에 적어 넣을 수도 있었는데, 나는 그러지 않았고 그 차이가 생각보다 컸다.

프롬프트는 그때 한 번만 유효한 계약 같은 것이다. 한 번의 대화에만 효력이 있고 다음 작업이 오면 처음부터 다시 써야 한다. 오늘 rubocop 버그를 기막히게 고친 프롬프트가 내일 다른 프로젝트에는 아무것도 남겨주지 않는다. 프롬프트는 아무리 잘 써도 쌓이지 않는다.

규칙은 문서에 박아두면 그때부터 혼자 굴러간다. 그다음 모든 작업이 자동으로 그 검사를 통과한다. 흉터 하나가 미래의 실수 백 개를 막는 셈이다. 이렇게 모델 주위에 세워둔 것들을 나는 하네스라고 부른다. 모델한테 뭐라고 말하느냐보다, 모델 주위에 뭘 세워뒀느냐가 결과를 갈랐다.

일부는 아예 도구로 떼어냈다.

mergewarden은 AI가 만든 PR이 스코프와 정책을 벗어났는지 검사하는, 내가 만든 게이트다. 머릿속에 있던 규칙을 코드로 내린 것이다.

그래서 뭐가 달라지나

지난 글에서 나는 좀 위험한 말을 했다. "나는 PR에 올리는 코드를 줄 단위로 다 이해하지 않는다"고. 그 말만 떼어놓으면 무책임하게 들린다.

그걸 무책임이 아니라 방법으로 만들어주는 게 이 규칙들이다. 내가 모든 문법을 외우지 않아도, 재현이 되고 · 테스트가 실패했다가 · 고친 뒤 통과하고 · 이 저장소가 AI를 받아주는 곳이라면, 그 PR은 구조적으로 검증된다. 통과 여부를 정하는 게 내 감이 아니라 규칙이라는 뜻이다.

규칙이 촘촘할수록 내가 손으로 붙잡고 있지 않아도 되는 범위가 넓어지고, 그만큼 위임이 안전해진다.

"모델이 좋아지면 필요 없어지는 거 아니냐"

이 얘기를 하면 꼭 나오는 반론이다. 모델이 더 똑똑해지면 이런 규칙들 다 필요 없어지는 거 아니냐고.

나는 정반대라고 생각한다. 모델이 좋아질수록 우리는 더 큰 일을 맡긴다. 맡기는 일이 클수록 경계와 검증은 덜 중요해지는 게 아니라 더 중요해진다.

규칙은 모델이 멍청해서 필요한 게 아니다. 신뢰를 감이 아니라 구조로 만들려고 필요한 거다. 어떤 특정 모델은 지나가도, 믿을 수 없는 일꾼에게 경계와 검증을 설계하는 능력은 지나가지 않는다.

흉터는 계속 는다

프롬프트만 다듬던 시절의 나는 결과가 안 좋으면 문장을 바꿨다. 지금은 문장을 바꾸는 대신 규칙을 하나 더 박는다.

그리고 이 목록은 아직 안 끝났다. 다음에 또 어딘가에서 데일 거고, 그러면 다섯 번째 규칙이 붙을 거다. 처음부터 잘 설계하는 방법이 있으면 좋겠는데, 적어도 나한테는 없었다.