AI VIDEO BRIEFING

AI 하네스 정리법: 지시 파일과 스킬이 쌓일수록 모델 성능이 떨어지는 이유와 해법

규칙을 더할수록 AI 결과가 나빠지는 이유를 짚는다. 스킬 66개와 지시 파일 172개를 직접 점검해 얻은 여섯 가지 원칙, 얇은 설정과 두꺼운 설정의 비교 실험, 모델별로 다른 실패 양상을 정리했다.

프롬프트가 아니라 설정이 문제였다: AI 스킬 66개를 정리하며 얻은 여섯 가지 원칙 영상 대표 이미지

핵심 메시지

  • 하네스는 모델을 둘러싼 모든 것이다. 커스텀 지시와 프로젝트 파일, 메모리, 스킬, 도구, 권한, 각종 검사가 여기 포함되며 프롬프트를 입력하기 전에 이미 답을 형성한다.
  • 대부분의 사람은 하네스를 설계하지 않았다. 실패할 때마다 규칙을 하나씩 더하다 보니 우연히 쌓였고, 전체를 한눈에 보는 화면이 없어 부풀어 오른 것을 알아채지 못한다.
  • 결과가 나쁠 때 모델을 탓하면 지시가 만든 문제를 지시로 덮게 된다. 모델이 실패한 것인지 주변 설정이 실패한 것인지 먼저 구분해야 한다.
  • 같은 규칙을 여러 곳에 복사해 두면 한 곳만 고쳐지고 나머지는 어긋난다. 규칙 하나에 집 하나, 관리자 하나가 원칙이다.
  • 기계가 판정할 수 있는 요구사항은 산문으로 부탁할 것이 아니라 스키마나 검사로 강제해야 한다. 그래야 하네스가 동시에 가벼워지고 안전해진다.

쉽게 이해하기

발표자는 새 모델이 나오기도 전에 하네스를 과하게 만들어 두었다고 고백한다. AI가 무언가를 놓칠 때마다 규칙을 하나씩 더했고, 각 규칙은 그 시점에는 실제 문제를 해결했다. 문제는 시간이 지나면서 그 축적물이 모델의 성능을 떨어뜨리는 군더더기가 되었다는 점이다. 그는 하네스를 자동차에 비유한다. 엔진이 아니면서 엔진의 힘을 바퀴에 전달하는 섀시와 구동계 전체가 하네스라는 것이다.

직접 점검을 돌려 보니 재사용 스킬 66개와 지시 관련 파일 172개가 나왔다. 평범한 글쓰기 작업 하나가 프롬프트를 조정하기도 전에 1만 8천 단어짜리 파일을 끌어오는 상황이었다. 설명문 길이는 2만 7천 자에 달해, 코덱스가 탐색에 쓸 수 있는 8천 자 예산을 크게 넘겼다. 읽을 수 없는 분량이 되어 버린 것이다. 66개 중 자체 평가가 붙어 있는 것은 여섯 개뿐이었다.

다만 숫자 자체가 문제는 아니었다고 그는 강조한다. 어떤 지시는 정말 중요한 것을 지키고 있었다. 연구할 때 어떤 출처를 신뢰할지 알려 주고, AI가 자신이 갖지 않은 의견을 지어내지 못하게 막고, 무엇을 물어보지 않고 해도 되는지를 정한다. 진짜 문제는 어떤 규칙이 작업을 보호하고 어떤 규칙이 중복이거나 너무 일찍 로드되거나 요즘 모델에는 불필요한지 구분할 수 없다는 것이었다.

여기서 여섯 가지 원칙이 나온다. 먼저 청소하기 전에 하네스의 지도를 그린다. 각 통제 장치가 어디에 살고 언제 로드되며 어떤 일을 하고 누가 관리하는지를 한 줄씩 적어 보면, 정중한 권고와 실제로 이빨이 있는 잠금장치가 구분된다. 둘째는 올바른 계층을 탓하는 것, 셋째는 규칙 하나에 집과 관리자를 하나만 두는 것, 넷째는 전문 지식을 처음부터 밀어 넣지 말고 그 작업이 실제로 필요해지는 시점에 부르는 것이다.

다섯째는 기계가 검증할 수 있는 요구사항을 스키마와 검사로 옮기는 것이고, 여섯째는 모델뿐 아니라 그 모델이 놓인 제품에 맞춰 설계하는 것이다. 같은 모델이라도 대화형 앱에서 쓸 때와 코딩 도구에서 쓸 때, API로 부를 때 하네스가 다르고 노출되는 통제 수단도 다르기 때문이다.

주요 인사이트

  • 가장 반직관적인 교훈은 라이브러리를 줄이라는 것이 아니라는 점이다. 발표자는 축적된 전문 자료 자체는 커도 괜찮으며, 바꿔야 할 것은 각 부분이 등장하는 시점이라고 말한다.
  • 같은 작업을 얇은 설정과 두꺼운 설정으로 비교한 실험이 인상적이다. 두꺼운 쪽은 분석이 더 풍부했지만 JSON 형식과 단어 수 제한을 두 차례 어겼고, 목표와 사실, 권한 경계, 완료 기준만 준 얇은 쪽은 세 번 모두 요건을 지켰다.
  • 그렇다고 짧은 프롬프트가 언제나 이긴다는 뜻은 아니라고 그는 분명히 선을 긋는다. 결과는 모델과 하네스가 함께 만들어 내는 것이기 때문이다.
  • 모델에 따라 무너지는 지점이 달랐다는 관찰도 유용하다. 한쪽은 방법론 문서가 지나치게 무거워진 뒤 산출물 제약을 놓쳤고, 다른 쪽은 거대한 하네스에서 경로를 찾는 더 이른 단계에서 어려움을 겪었다.
  • 몇 달 전에 남긴 교정 지시가 새 모델에서도 계속 적용되며 조용히 결과를 왜곡할 수 있다는 지적은 일반 사용자에게 특히 와닿는다. 당시엔 필요했던 요구가 지금은 불필요한 제약이 된다.

자주 묻는 질문

하네스란 무엇인가?

모델을 둘러싼 모든 것을 가리킨다. 커스텀 지시, 프로젝트 파일, 저장된 프롬프트, 메모리, 스킬, 도구, 권한, 실행되는 검사가 모두 포함된다. 프롬프트 창에 무언가를 입력하기 전에 이미 답의 형태를 정하고 있다는 점이 핵심이다.

지시를 짧게 쓰는 것이 정답인가?

아니다. 발표자는 두꺼운 설정이 더 풍부한 분석을 내놓았다는 점을 인정한다. 문제는 길이가 아니라 시점이다. 전체 방법론을 작업 시작 전에 모두 밀어 넣으면 형식과 분량 같은 실제 요건을 지키지 못하게 된다.

왜 같은 규칙을 여러 파일에 두면 안 되나?

복사본마다 규칙이 따로 흘러가기 때문이다. 실패를 겪은 뒤 한 곳을 고치면 나머지는 옛 상태로 남고, 결국 모델은 서로 다른 여러 버전의 진실을 동시에 받게 된다.

일반 사용자에게는 어떤 의미가 있나?

예전에 남긴 메모리와 프로젝트 파일, 교정 지시가 지금도 답을 조용히 바꾸고 있을 수 있다는 뜻이다. 몇 달 전 필요해서 요구했던 방식이 성능이 좋아진 새 모델에서는 오히려 불필요한 제약으로 남는 경우가 있다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식