헌장과 배관: AI 개발 지침이 늘 원론적으로 들리는 이유

요즘은 조직마다 AI 개발 지침을 내놓는다. 내용도 대체로 비슷하다. 품질을 우선하라. 사람이 실제로 검토할 수 있을 만큼 PR을 작게 유지하라. 에이전트로 사람의 리뷰를 대체하지 마라. 제출하는 모든 코드에 책임을 져라. AI의 출력을 비판적으로 검토하라. 모두 옳은 말이다. 반박하기 어렵다. 그런데 바로 그 점이 문제다. ## 옳은 말과 강제되는 규칙은 다르다 "우리는 모든 코드에 책임을 진다"는 강제 장치가 아니라 다짐이다. "AI 출력을 비판적으로 검토한다"는 원칙도 좋다. 하지만 무엇으로, 어떻게 검토할 것인가? "우리는 장인 정신에 자부심을 느낀다"는 문장을 어떻게 검증할 수 있을까? 할 수 없다. 측정할 수 없는 문장은 아무리 옳아도 결국 벽에 걸린 액자가 된다. 이런 문서는 대개 새로운 능력을 부여하기보다 사고를 막기 위해 존재한다. 그것이 나쁘다는 뜻은 아니다. 문화를 정렬하고 최악의 결과를 막는 헌장으로서는 제 역할을 한다. 문제는 헌장을 배관으로 착각할 때 시작된다. ## 반복문은 종료 조건을 충족해도 여전히 틀릴 수 있다 공개된 한 에이전트 스택 구축 가이드에서 이런 문장을 본 적이 있다. 반복문이 종료 조건을 충족했더라도 결과는 틀릴 수 있다. 모든 테스트 표시가 초록색이어도 실제로 통과한 테스트가 하나도 없을 수 있다. 리뷰어 두 명이 승인을 눌렀다고 해도, 그 승인은 증거가 아니라 의견일 뿐이다. 그래서 좋은 시스템은 사람의 양심에 기대지 않는다. 환경에 사실을 남긴다. 관문은 회의가 아니라 스크립트여야 한다. 완료의 정의는 "리뷰어가 승인했다"가 아니라 "통과한 테스트 레코드가 데이터베이스에 존재한다"여야 한다. 판정은 의견이고 레코드는 증거다. 둘을 섞으면 하위 계층은 상위 계층에 사실 대신 요약을 넘기게 되고, 상위 계층은 거짓된 전제 위에서 작업을 종료한다. 한 가지 더 있다. 같은 계열의 모델끼리 서로를 검토하게 하면 사각지대를 공유한다. 작성자가 틀린 지점을 같은 계열의 검토자도 같은 방식으로 놓칠 가능성이 높다. 가능하다면 검토는 다른 계열의 모델이 맡아야 한다. 채점하는 쪽과 답안을 작성하는 쪽이 같은 사고방식을 공유한다면, 그것은 제대로 된 채점이 아니다. ## 비용도 다짐만으로는 줄일 수 없다 이런 지침에서 가장 실질적인 부분은 대개 비용 절감 항목이다. 단순한 도구 호출은 더 저렴한 모델에 맡겨라. 프롬프트 캐싱을 켜라. 모델 티어는 프로젝트마다 흩어 두지 말고 한곳에서 관리하라. 가장 비싼 모델이 모든 작업에 필요한 것은 아니다. 이것은 조언이 아니라 조작 가능한 설정값이다. 바꾸면 비용이 줄어든다. 다른 미덕과 다른 점도 여기에 있다. 비용 규칙은 검증할 수 있다. 캐시가 실패했는지, 저렴한 모델이 실제로 도구 호출을 처리했는지는 로그에서 확인할 수 있다. 측정되는 규칙만 지속적으로 지켜진다. 나머지는 지켜지기를 바랄 뿐이다. 여기서 주의할 점이 하나 있다. 하위 에이전트를 절대 사용하지 말라는 식의 규칙을 종종 보는데, 이는 과잉 대응이다. 문제는 하위 에이전트 자체가 아니다. 자식 에이전트가 부모의 추론 수준을 그대로 상속받아 전체 작업이 최고 비용으로 실행되고, 한 번에 컨텍스트를 소진하는 것이 문제다. 통제해야 할 대상은 "사용하지 말라"가 아니라 추론 수준과 예산 상한이다. 도구를 금지하는 것과 도구의 비용을 제한하는 것은 전혀 다른 선택이다. ## 그래서 실제로 해야 할 일 이 글은 지침이 필요 없다는 주장이 아니다. 헌장은 필요하다. 방향을 제시하고 최악의 결과를 막아 준다. 다만 지침을 읽은 뒤에는 문장마다 한 가지를 물어야 한다. "이 원칙을 어기면 무엇이 나를 막는가?" 아무것도 없다면, 그것은 지침이 아니라 바람이다. 측정할 수 없는 미덕 열 가지보다, 통과한 테스트가 없으면 초록색 상태라도 통과시키지 않는 관문 하나가 팀을 더 정직하게 만든다. 좋은 가치를 나열하는 일과 그 가치를 어기기 어렵게 만드는 일은 완전히 다르다. 대부분의 조직은 전자에서 멈춘다. 헌장은 이미 누구에게나 있다. 늘 부족한 것은 배관이다.