It's Not the Size: Harness Design Determines Operational Stability in Small Language Models

본 논문은 20~30 억 파라미터 규모의 소형 언어 모델의 경우 구조화된 4 단계 하네스 파이프라인이 운영 안정성과 작업 성공 측면에서 원시 프롬프팅이나 최소한의 래퍼보다 현저히 우수함을 입증하는 동시에, 불충분한 발판이 특정 모델에서 구조적 형식 붕괴를 초래할 수 있음을 보여줍니다.

핵심

상상해 보세요. 매우 똑똑하지만 약간 산만하고, 작고 (AI 용어로 "소규모 언어 모델"인 "2B" 또는 "3B" 두뇌 크기를 가짐) 조수 한 명이 있다고 가정해 봅시다. 여러분은 이 조수에게 보고서 작성, 웹 검색, 다단계 지시 따르기 등 복잡한 작업들을 수행하게 하고 싶습니다.

이 논문은 단순한 질문을 던집니다: 이 조수에게 지시를 내리는 방식이 조수 자체의 "똑똑함"보다 더 중요할까요?

답은 명확한 예입니다. 저자들은 지시를 내리는 방식을 "하네스 (harness)"라고 부릅니다. 하네스를 말에게 채우는 장비라고 생각하세요. 아무리 빠른 말이라도 고삐와 줄 (하네스) 을 주지 않으면, 제자리를 빙글빙글 돌거나 지치거나 명령을 무시할 수 있습니다.

다음은 일상적인 비유를 통해 실험과 발견 사항을 정리한 내용입니다:

1. 지시 내리는 세 가지 방법 (하네스들)

연구자들은 이 AI 조수들과 대화하는 세 가지 다른 방식을 테스트했습니다:

• "원시 프롬프트 (Raw Prompt)" (모델 전용): 이는 조수가 점심을 먹고 있을 때 작업 지시를 외치는 것과 같습니다. "이봐, 보고서 좀 써줘!" 구조도 규칙도 없는, 그야말로 raw 한 요청입니다.
• "최소 쉘 (Minimal Shell)" (래퍼 태그): 이는 "작업 시작"과 "작업 종료"라고 적힌 고급스러운 상자 안에 작업을 넣는 것과 같습니다. 정리된 것처럼 보이지만, 실제로 조수가 단계를 생각하도록 도와주지는 않습니다.
• "4 단계 파이프라인 (Full Harness)": 이는 조수에게 상세한 체크리스트를 주는 것과 같습니다:
  1. 계획: "먼저, 무엇을 해야 할지 생각해보라."
  2. 실행: "이제 일을 하라."
  3. 검증: "작업을 확인하라. 실수했는가?"
  4. 복구: "실수했다면 고치고 다시 시도하라."

2. 큰 놀라움: "더 많은 도움"이 때로는 "덜한 도움"이 될 수 있음

연구자들은 이상하고 반직관적인 사실을 발견했습니다.

두 가지 모델의 경우, **"최소 쉘" (고급 상자)**은 실제로 "원시 프롬프트"보다 조수의 수행을 더 나쁘게 만들었습니다.

• 비유: 친구에게 케이크를 구워달라고 요청한다고 상상해 보세요. 그냥 "케이크 구워줘"라고 하면 그들은 제법 잘 해낼지도 모릅니다. 하지만 밀가루를 섞기 전에 채워야 하는 상자가 있는 딱딱하고 혼란스러운 양식을 건네주면, 그들은 압도당해 레시피를 잊어버리고 케이크를 태워먹을 수 있습니다.
• 결과: 추가된 "래퍼 태그"는 작은 모델들을 혼란스럽게 만드는 정신적 혼란 (인지 부하) 을 초래하여, 단순한 명령만 받았을 때보다 더 자주 시간 초과가 발생하거나 실패하게 했습니다.

3. "발판 붕괴 (Scaffold Collapse)" (조수가 형식을 잃어버릴 때)

가장 흥미로운 발견 중 하나는 LLaMA 3.2 모델과 관련이 있습니다.

• 상황: 특정 형식 (예: JSON 목록) 으로 보고서를 작성하라고 요청받았을 때, 이 모델은 종종 혼란을 느껴 규칙을 무시하고 일반적인 단락을 작성하곤 했습니다.
• 용어: 저자들은 이를 **"발판 붕괴 (Scaffold Collapse)"**라고 부릅니다.
• 비유: 벽돌 쌓기 (콘텐츠 생성) 는 훌륭하지만 청사진 (형식) 을 계속 잊어버리는 건설 노동자를 상상해 보세요. "청사진을 확인해, 잘못 짓고 있어"라고 말하며 그들 위에 서서 감독하는 현장 감독 (하네스) 이 없다면, 그들은 그냥 하고 싶은 대로 지을 것입니다. 하네스는 벽돌 쌓기를 더 똑똑하게 만들지는 않았지만, 청사진을 따르도록 강요했을 뿐입니다.

4. "4 단계 파이프라인"이 승리한 이유

완전한 파이프라인 (계획 → 실행 → 검증 → 복구) 은 특히 복잡한 작업에서 명백한 승자였습니다.

• 계획: 이는 "정신적 닻" 역할을 했습니다. 모델이 쓰기를 시작하기 전에 "계획" 단계는 제약 조건 (예: "200 자 이내로 유지") 을 기억하도록 강요했습니다. 이 단계가 없으면 모델은 제한을 잊고 장편 소설을 써버립니다.
• 복구: 이는 안전망이었습니다. 모델이 막히거나 시간 초과가 발생하면 "복구" 단계가 다시 시도할 수 있게 했습니다.
• 결과: 완전한 파이프라인을 사용하면 모델들은 거의 완벽한 성공률 (95% 이상) 을 달성한 반면, 그렇지 않으면 크게 어려움을 겪었습니다.

5. "검증"의 함정

연구자들은 또한 "검증" 단계가 얼마나 자주 실수를 잡아냈는지 측정했습니다.

• 통계: 시스템은 오류의 약 **62.5%**를 잡아내어 수정했습니다.
• 함정: 때로는 "검증" 단계가 속기도 했습니다. 예를 들어, 모델이 문자 수를 세도록 요청받았을 때, 모델이 숫자를 잘못 추측하면 검증자도 잘못 추측하여 일이 끝났다고 생각하며 실제로는 그렇지 않은 경우를 놓치는 식이었습니다.

6. "도구" 문제 (실험의 결함)

논문에는 AI 가 웹을 검색해야 하는 작업이 포함되었습니다.

• 문제: "원시" 및 "최소" 버전의 AI 는 검색 도구에 전혀 접근할 수 없었으므로 자동으로 실패했습니다. "파이프라인" 버전은 도구를 가지고 있었지만, 너무 많은 질문을 너무 빠르게 물어보면서 DuckDuckGo 검색 엔진에 차단당해 실패했습니다.
• 교훈: 저자들은 이 테스트 부분이 "좋은 하네스" 대 "나쁜 하네스"를 비교하는 것이 아니라, "도구 보유" 대 "도구 미보유"를 비교했기 때문에 결함이 있었다고 인정합니다.

요약: 이것이 무엇을 의미합니까?

핵심 교훈은 간단합니다: 작은 AI 모델의 경우, 모델을 선택하는 것보다 작업을 어떻게 조직하는지가 더 중요합니다.

• 과도하게 복잡하게 만들지 마세요: 고급스러운 레이블 (최소 쉘) 을 추가하는 것은 때로는 작은 모델들을 돕는 것보다 더 혼란스럽게 만들 수 있습니다.
• 구조가 핵심입니다: 작업을 "계획, 실행, 확인, 수정"으로 나누면 "작은" 두뇌조차도 복잡한 작업을 신뢰성 있게 수행할 수 있습니다.
• 하네스가 영웅입니다: "하네스" (지시 시스템) 는 실수를 수정하는 안전망이자 실수가 발생하기 전에 예방하는 가이드 역할을 합니다.

이 논문은 작고 효율적인 AI 모델이 현실 세계에서 잘 작동하기를 원한다면, 어떤 모델을 선택할지 걱정하는 것보다 "하네스" (워크플로우) 를 설계하는 데 더 많은 시간을 투자해야 한다고 결론 내립니다.

기술 요약

기술 요약: 소형 언어 모델의 운영 안정성은 하네스 설계에 의해 결정됨

문제 제기

소형 언어 모델 (SLM, 23B 파라미터) 은 엣지 및 온프레미스 배포를 위한 대규모 모델의 비용 효율적인 대안을 제공하지만, 다단계 작업에서의 운영 안정성은 아직 충분히 연구되지 않았습니다. 기존 문헌은 정적 벤치마크 정확도 (예: MMLU, HumanEval) 에 집중하여 실제 시나리오에서 실행 구조가 출력 완성도 및 형식 준수를 어떻게 영향을 미치는지에 대한 이해의 공백을 남겨두고 있습니다. 더 나아가, Reflexion 및 ReAct 와 같은 프레임워크는 실행 흐름이 중요함을 시사하지만, 구체적으로 2B3B 모델을 대상으로 한 이러한 구조의 효능에 대한 체계적인 증거는 부족합니다.

방법론

저자들은 Gemma4 E2B(2B), Qwen3.5:2B(2B), LLaMA 3.2(3B) 의 세 가지 SLM 에 걸쳐 세 가지 수준의 "하네스 엔지니어링 (실행 구조)"을 비교하는 실험적 분석을 수행했습니다. 연구는 구조화된 지식 추출, 검색 및 근거 확보, 워크플로우 완료, 제약 조건 민감 작업 등 여섯 가지 범주의 24 개 작업을 활용했습니다.

하네스 조건:

1. 모델 전용: 작업 설명만 포함된 원시 프롬프트.
2. 최소 쉘: 실행 흐름 논리 없이 구조적 태그 ([TASK START], [OUTPUT]) 로 작업을 감싼 형태.
3. 4 단계 파이프라인: **계획 (Plan) → 실행 (Execute) → 검증 (Verify) → 복구 (Recover)**로 구성된 구조화된 워크플로우. 복구 단계는 검증 실패 또는 타임아웃 시 최대 두 번의 재시도를 허용합니다.

평가 지표:

• 작업 성공률 (TSR): 완전한 성공 (점수=2) 을 달성한 작업의 비율.
• 유효 TSR(VTSR): 부분적 성공 이상 (점수≥1) 을 달성한 작업의 비율.
• 검증 포착률 (VCR): 검증 단계에서 포착되어 이후 재시도된 결함의 비율.
• 임계값: 운영 안정성은 TSR ≥ 0.65 및 VTSR ≥ 0.80 을 충족하는 것으로 정의됨.

애블레이션 연구:
성능 향상에 대한 개별 기여도를 정량화하기 위해 계획, 검증 + 복구, 복구 등 파이프라인의 특정 구성 요소를 분리하여 분석했습니다.

주요 발견 및 결과

1. 하네스 설계를 통한 운영 안정성

이 연구는 SLM 이 제한된 작업 범위 내에서 운영 임계값을 충족할 수 있음을 보여주지만, 성공은 파라미터 수 자체보다는 하네스 설계에 크게 의존함을 입증했습니다.

• Gemma4 E2B: 4 단계 파이프라인 하에서 TSR=0.952 및 VTSR=1.000 을 달성하여 모델 전용 기준 (TSR=0.762) 보다 크게 우위를 보였습니다.
• LLaMA 3.2(3B): 모델 전용 조건은 복잡한 형식 요구 사항 하에서 모델이 JSON 구조를 포기하는 "발판 붕괴 (scaffold collapse)"로 인해 운영 임계값 (TSR=0.429) 을 충족하지 못했습니다. 파이프라인 하네스는 안정성을 회복시켰으나, Gemma 에 비해 절대적 향상폭은 낮았습니다.

2. 비단조적 효과

중요한 발견은 비단조적 현상입니다. Gemma4 와 Qwen3.5 모두에서 최소 쉘 조건이 모델 전용 조건보다 낮은 TSR 을 보였습니다.

• 관찰: Gemma 의 경우 최소 쉘 TSR(0.714) < 모델 전용 TSR(0.762); Qwen 의 경우 최소 쉘 (0.857) < 모델 전용 (0.952).
• 가설: 저자들은 복잡한 워크플로우에서 래퍼 태그가 인지 부하를 증가시켜 추가적인 타임아웃을 유발할 수 있다고 제안하지만, 인과관계를 입증하기 위해서는 추가적인 통제 실험이 필요합니다.

3. 구성 요소 기여도 (애블레이션)

• 계획: 정량적 제약 조건을 위한 "형식 앵커" 역할을 합니다. 계획 단계를 제거하면 TSR 이 감소했는데, 특히 문자 수 제한이 있는 작업 (예: T1-04) 에서 명시적 분해 없이는 모델이 제한을 준수하지 못했습니다.
• 복구: 복구 메커니즘은 성능 향상의 주요 기여 요인으로, 총 향상분의 약 **24.7%**를 차지했습니다. 이는 타임아웃 실패와 형식 위반을 성공으로 전환했습니다.
• 검증: 모든 파이프라인 실행에 걸친 검증 포착률 (VCR) 은 0.625였습니다. 특히 LLaMA 3.2 는 VCR 이 1.000(모든 결함 포착) 이었으나 항상 이를 수정하지는 못했고, Qwen 의 VCR 은 0.000(결함 포착 실패) 이었습니다.

4. 실패 모드 분류

이 논문은 하네스 수정 가능성에 따라 실패 모드를 분류합니다:

• 수정 가능 (반응형): 타임아웃 및 규칙 감지 가능 제약 (예: 금지된 단어) 은 복구 재시도를 통해 성공적으로 해결됩니다.
• 수정 가능 (예방형): "발판 붕괴 (형식 포기)"는 계획 및 프롬프트 구조화 단계를 통해 해결됩니다.
• 수정 불가: 정량적 제약 (예: 정확한 문자 수) 은 내재된 LLM 의 계수 한계로 인해 종종 실패하며, 할루시네이션은 하네스 수정 범위를 벗어납니다.

중요성 및 주장

이 논문은 하네스 설계가 SLM 의 운영 안정성에 있어 결정적인 요소이며, 종종 원시 모델 크기의 이점을 능가한다고 주장합니다.

• 발판 vs. 재시도: 저자들은 두 가지 독립적인 하네스 기능을 구분합니다: 반응형 복구(발생 후 오류 수정) 와 예방형 발판(프롬프트 및 실행 흐름 구조화를 통한 오류 예방). 이 연구는 이러한 역할이 구별되며 상호 교환 불가능하다고 주장합니다.
• "적은 것이 더 많다"는 경고: 비단조적 결과는 하네스 설계의 "반쪽짜리 조치"(예: 전체 파이프라인 없이 태그만 추가) 가 원시 프롬핑팅보다 성능을 저하시킬 수 있음을 시사합니다.
• 한계: 저자들은 소규모 작업 세트 (24 개 작업), 분산 추정 부재 (단일 실행), 그리고 도구 구비 대 도구 부재 조건을 비교한 웹 검색 작업 (T6) 의 특정 설계 결함 등 한계를 겸손하게 인정합니다.

결론적으로, 이 논문은 SLM 이 운영 환경에 신뢰성 있게 배포되기 위해서는 모델 선택 자체만큼이나 실행 하네스의 엔지니어링이 중요하다고 주장합니다. 향후 연구는 포착률을 높이기 위한 규칙 기반 검증과 도구 접근과 오케스트레이션 효과를 분리하기 위한 작업 재설계에 초점을 맞출 것을 제안합니다.