AI의 반복 실수, 지침보다 코드로 막아야 하는 이유

AI의 반복 실수, 지침보다 코드로 막아야 하는 이유

AI 뉴스 썸네일

같은 요청을 받은 AI가 매번 같은 답을 내놓지는 않아요. 중요한 규칙을 여러 번 알려줘도 어느 순간 어길 수 있어요. Melody Koh는 이런 반복 실수를 줄이려면 규칙 일부를 문서가 아닌 코드로 옮겨야 한다고 설명해요. 1

핵심 요약

구분	핵심	실무에서 볼 점
반복 오류	문서에 적힌 규칙은 AI가 다른 정보와 함께 판단해요	반드시 지켜야 할 조건은 독립된 코드 검사로 막아야 해요
보장 범위	통과와 실패를 코드로 가를 수 있는 조건만 확실히 고정할 수 있어요	명령 차단, 파일 형식, 테스트 결과처럼 판정 기준이 분명한 작업부터 적용해요
판단 영역	분석의 미묘한 오류는 고정 규칙만으로 잡기 어려워요	코드 검사와 사람의 검토가 맡을 범위를 나눠야 해요
제품 경쟁력	같은 모델을 써도 제품마다 쌓인 기준과 통합 방식은 달라요	모델 밖의 코드, 데이터, 운영 기준이 제품 차이를 만들어요

1. AI가 규칙을 읽었다고 지키는 것은 아니에요

원문 저자는 Claude Code가 세션을 시작할 때 읽는 문서에 금지 규칙을 적어 뒀어요. AI는 규칙을 이해했다고 답했지만 같은 행동을 가끔 반복했어요. 저자는 해당 조건이 감지되면 명령을 차단하는 훅을 만들었고, 그 뒤부터 모델의 판단과 상관없이 행동이 멈췄다고 설명해요. 2

이 사례는 권고와 강제의 차이를 잘 보여줘요. 문서는 선호 사항과 프로젝트 맥락을 전달하기에 좋아요. 다만 AI는 문서 내용도 판단 재료 중 하나로 다뤄요. 서로 충돌하는 정보가 있거나 작업이 길어지면 규칙을 놓칠 수 있어요.

728x90

반면 훅은 정해진 조건을 직접 검사해요. 금지된 명령, 허용되지 않은 파일 변경, 테스트 실패처럼 참과 거짓을 분명히 가를 수 있다면 AI에게 판단을 맡길 필요가 없어요. 조건을 만족하지 못하면 다음 단계로 넘어가지 못하게 만들 수 있어요.

강제할 규칙은 판정식으로 바꿀 수 있어야 해요

"좋은 분석을 써 줘"는 코드가 바로 판정하기 어려워요. "필수 항목 4개가 모두 있는가", "테스트 종료 코드가 0인가", "보호된 경로를 수정했는가"는 코드로 확인할 수 있어요. 팀이 반복해서 겪는 오류를 이런 판정식으로 바꾸면 검토 범위도 줄어들어요.

실무에서는 아래 순서로 나누기 쉬워요.

1. 반복되는 실패 사례를 구체적인 행동이나 출력으로 기록해요.
2. 코드가 독립적으로 통과와 실패를 가를 수 있는지 확인해요.
3. 판정할 수 있으면 실행 전후의 검사로 옮겨요.
4. 판정하기 어렵다면 사람의 검토 항목으로 남겨요.

이 구분이 없으면 모든 규칙을 긴 문서에 쌓게 돼요. 문서가 길어질수록 중요한 규칙이 다른 맥락에 묻힐 수 있어요. 반대로 모든 작업을 코드로 고정하면 AI가 유연하게 판단할 공간이 사라져요.

코드 검사도 정답이 정의된 곳에서만 작동해요

고정 검사가 만능은 아니에요. 파일 형식이나 명령 사용 여부는 비교적 쉽게 확인할 수 있어요. 하지만 시장 분석이 미묘하게 잘못됐는지, 제품 설명이 독자를 오해하게 하는지는 단일 판정식으로 가르기 어려워요.

또 다른 AI에게 평가를 맡기면 검토 속도는 빨라질 수 있어요. 그래도 평가 결과가 항상 같다고 보장할 수는 없어요. 정확성이 꼭 필요한 작업에서는 자동 평가 점수만 믿기보다 근거 링크, 계산식, 사람이 확인할 체크포인트를 함께 남기는 편이 안전해요.

형식 명세를 이용한 연구도 같은 한계를 보여줘요. 사람이 정답 조건을 논리식으로 미리 정의할 수 있는 영역에서는 출력이 계약을 충족하는지 검사할 수 있어요. 사용자의 모호한 의도를 명세로 바꾸는 단계에는 다시 판단이 들어가요. 2

팀이 커지면 작은 규칙 누락의 비용도 커져요

개인 도구에서 규칙 하나를 놓치면 몇 분을 다시 쓰는 것으로 끝날 수 있어요. 여러 팀이 같은 AI 도구와 공통 설정을 쓰면 같은 오류가 여러 작업에서 반복될 수 있어요. 배포, 권한, 개인정보, 결제처럼 사고 비용이 큰 경로는 개인의 주의보다 공통 코드 검사로 막는 편이 맞아요.

모든 경로를 잠글 필요는 없어요. 빈도가 높고 실패 비용이 큰 작업부터 고정하면 돼요. 배포 전 테스트, 데이터 스키마, 접근 권한, 금지 명령은 좋은 후보예요. 아이디어 탐색, 초안 작성, 여러 대안 비교는 AI의 판단을 더 넓게 쓸 수 있어요.

모델 밖에 쌓인 기준이 제품 차이를 만들어요

기업은 비슷한 기반 모델을 빌려 쓸 수 있어요. 같은 모델을 사용해도 결과가 다른 이유는 제품이 모델을 둘러싼 방식에 있어요. 어떤 데이터를 보여 주는지, 어떤 도구와 연결하는지, 어느 단계에서 코드를 실행하는지, 무엇을 사람이 검토하는지가 실제 사용 경험을 바꿔요.

이 기준은 운영 중 발견한 실패를 고치면서 쌓여요. 경쟁사가 코드 구조를 비슷하게 만들더라도 어떤 오류를 먼저 막았는지, 어느 판단을 열어 뒀는지까지 곧바로 복제하기는 어려워요. AI 제품을 오래 운영할수록 모델 자체보다 검증 기준과 업무 통합 경험이 더 많이 남을 수 있어요.

왜 중요한가요

AI 기능을 추가할 때 모델 성능만 비교하면 운영 비용을 놓치기 쉬워요. 반복 오류를 사람이 매번 찾는 구조에서는 사용량이 늘수록 검토 시간도 함께 늘어요. 자주 발생하고 코드로 판정할 수 있는 실패부터 차단하면 사람이 판단해야 할 문제에 시간을 쓸 수 있어요. 2

제품팀은 기능마다 한 가지 질문을 먼저 적어 볼 수 있어요. 실패를 코드가 판정할 수 있다면 자동 검사로 고정하고, 판정 기준을 합의하기 어렵다면 근거와 검토 책임자를 분명히 두는 방식이에요. 이 경계를 꾸준히 다듬는 일이 AI 제품의 품질과 비용을 함께 좌우해요.

참고 자료

1. 예측 불가능한 천재를 감싸는 법 — GeekNews
2. Wrapping the Unpredictable Genius — Melody Koh, Ground Truth