제 5강. 고삐 있는 AI — Reins Engineering 개론

꿀팁 — 이것만 알면 시킬 수 있다

AI 코딩 도구의 한계는 울타리(하네스)만 있고 방향(고삐)이 없다는 것이다. 린터, 포매터, CI가 “밖으로 나가지 마"라고 말하지만, “이쪽으로 가"라고 말하지 않는다. 코드가 “깨끗하지만 틀린” 상태로 프로덕션에 도달한다.

핵심 원칙: 모델을 바꾸지 말고, 계약을 추가하라. 같은 모델도 피드백 구조에 따라 40개에서 멈추기도 하고 527개를 완주하기도 한다. 더 똑똑한 모델을 기다리는 것은 인치주의다. 검증 루프를 추가하는 것이 법치주의다.

지금 당장 확인할 것:

에이전트에게: “코드를 깔끔하게 정리해줘. 기능은 바꾸지 마.”

AI가 리팩토링을 마치면, 당신이 정한 규칙(CLAUDE.md에 적어놓은 것)이 그대로 남아 있는지 확인하라. API 경로가 바뀌었는가? DB 테이블 이름이 바뀌었는가? 응답 형식이 달라졌는가?

높은 확률로 뭔가 바뀌어 있다. AI는 “정리"하면서 당신의 결정을 세부사항으로 취급하고 덮어쓴다. 결정이 코드 안에 섞여 있기 때문이다.

Reins의 세 기둥을 기억하라:

• 결정론적 피드백 — “좀 이상한데?“가 아니라 “line 41: 필드명 불일치”
• 래칫 잠금 — 통과하면 잠그고, 다음으로
• 결정과 구현의 분리 — 결정은 SSOT에, 코드는 일회용 투영

하나라도 빠지면 수렴이 깨진다.

찍먹 체험

1강에서 만든 앱을 Claude Code로 연다. 그리고 이렇게 시킨다:

에이전트에게: “코드를 깔끔하게 정리해줘. 기능은 바꾸지 마.”

AI가 리팩토링을 마치면, 1강에서 정한 규칙(CLAUDE.md에 적어놓은 것)이 그대로 남아 있는지 확인한다. API 경로가 바뀌었는가? DB 테이블 이름이 바뀌었는가? 응답 형식이 달라졌는가?

높은 확률로 뭔가 바뀌어 있다. AI는 “정리"하면서 당신의 결정을 세부사항으로 취급하고 덮어쓴다. 이것이 5강의 핵심 — 결정과 구현이 코드 안에서 섞여 있기 때문에 일어나는 일이다.

왜 이렇게 시켜야 하는가

지난 시간 복습

4강에서 우리는 yongol을 직접 체험했다.

• 결정을 코드에서 분리해 10개 선언적 명세(SSOT)에 담았다
• operationId 하나가 10개 레이어를 관통했다
• 287개 규칙이 레이어 간 모순을 잡았다
• 4.5B 모델도 validate 피드백을 받으면 0 에러에 수렴했다

이번 강의에서는 한 발 뒤로 물러서서 묻는다. 왜 이것이 작동하는가?

yongol은 도구다. 도구 뒤에는 원리가 있다. 이 원리를 이해하면, yongol이 아닌 다른 상황에서도 같은 사고방식을 적용할 수 있다.

네 개의 시대

AI 코딩은 네 번의 패러다임 전환을 거쳐왔다. 각 시대는 이전 시대의 한계에서 태어났다.

1세대: 프롬프트 엔지니어링 — “말을 잘 하면 된다”

“React로 TODO 앱 만들어.” “FastAPI로 게시판 만들어.”

프롬프트를 잘 쓰면 AI가 잘 만들어줄 것이라는 시대. 실제로 작동한다 — 한 번은. 두 번째 프롬프트를 주면 첫 번째와 다른 패턴으로 만든다. 세 번째를 주면 첫 번째를 깨뜨린다.

한계: 일회성. 프롬프트는 날아간다. 다음 대화에서 AI는 당신이 뭘 결정했는지 모른다.

2세대: 컨텍스트 엔지니어링 — “맥락을 잘 주면 된다”

CLAUDE.md를 쓴다. 요구사항.md를 쓴다. 진행상황.md를 쓴다. AI가 매 대화 시작 시 이 파일들을 읽고, 이전 결정을 기억한다.

1강에서 배운 것이 이 단계다. 프롬프트가 일회성이라면, 파일은 영구적이다. 의사결정을 외부화하면 세션이 바뀌어도 맥락이 유지된다.

한계: 소멸. 컨텍스트를 줘도 대화가 길어지면 AI가 앞부분을 잊는다. 200 엔드포인트의 컨텍스트를 한 번에 넣으면 중간 정보를 놓친다. 맥락은 주지만, 맥락을 따르도록 강제하지 않는다.

3세대: 하네스 엔지니어링 — “구조로 가두면 된다”

코드의 맞춤법 검사기(린터)와 자동 정리 도구(포매터), CI/CD, 프로젝트 구조, 코딩 가이드라인. 에이전트가 밖으로 나가지 못하게 울타리를 친다.

3강에서 배운 것이 이 단계의 일부다. Hurl 테스트, Git, CI/CD — 이것들이 울타리다. AI가 기존 기능을 깨뜨리면 CI가 거부한다.

한계: 방향이 없다. 울타리는 “밖으로 나가지 마"라고 말하지만, “이쪽으로 가"라고 말하지 않는다. 에이전트가 울타리 안에서 무엇을 하든 — 기존 로직을 덮어쓰든, 타입을 바꾸든, 상태 전이를 생략하든 — 린터는 통과한다. 포매터도 통과한다. CI도 통과한다. 코드가 “깨끗하지만 틀린” 상태로 프로덕션에 도달한다.

4세대: Reins Engineering — “방향을 잡아주면 된다”

울타리가 아니라 고삐.

4강에서 체험한 것이 이 단계다. yongol validate는 “밖으로 나가지 마"가 아니라 “여기가 어긋나 있어, 이쪽으로 고쳐"라고 말한다. 방향이 있는 피드백. 결정론적 사실. AI가 따를 수밖에 없는 계약.

울타리와 고삐의 차이

이 차이를 직관적으로 이해하기 위해, 말을 탄다고 상상해보자.

하네스(울타리): 목장에 울타리를 친다. 말은 울타리 안에서 자유롭게 돌아다닌다. 풀을 뜯을 수도 있고, 빙빙 돌 수도 있고, 잠을 잘 수도 있다. 울타리 밖으로 나가지 못한다는 것만 보장된다. 하지만 목적지에 도달한다는 보장은 없다.

Reins(고삐): 말에 올라타고 고삐를 잡는다. 오른쪽으로 당기면 오른쪽으로 간다. 왼쪽으로 당기면 왼쪽으로 간다. 말은 자유롭게 달린다 — 하지만 방향은 당신이 잡는다. 목적지에 도달한다.

지금 업계의 AI 코딩 도구들은 대부분 울타리 단계에 있다. 린터, 포매터, CI/CD, 코딩 가이드라인 — 전부 “이 안에서 해"라고 말한다. 에이전트는 울타리 안에서 빙빙 돈다. 코드는 깨끗하지만, 의도한 방향으로 가고 있는지는 아무도 모른다.

Reins Engineering은 “이 방향으로 가"라고 말한다. validate가 “여기 어긋남"이라고 알려주면, AI가 그 방향으로 수정한다. 고삐는 자유를 제한하지 않으면서 목적지에 도달하게 한다.

연구에 의하면 AI 코딩 도구 도입 후 코드 복잡도가 41% 영구 증가하고¹, AI 도입이 늘수록 전달 안정성이 감소한다². 울타리만으로는 안 된다는 증거다.

Reins의 세 기둥

Reins Engineering은 세 가지 원칙으로 구성된다.

기둥 1: 결정론적 피드백

AI에게 의견이 아니라 사실을 준다.

나쁜 피드백: “이거 좀 이상한데?” 좋은 피드백: “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”

차이가 뭔가? 나쁜 피드백에는 AI가 아첨할 여지가 있다. “맞는 것 같은데요? 이게 더 나은 패턴입니다.” 좋은 피드백에는 아첨할 여지가 없다. 숫자와 위치는 감정이 아니기 때문이다.

1,000개 단어 정렬 실험에서 이것을 정량적으로 확인했다:

“틀렸다"만 알려주면 과잉 수정으로 오히려 나빠진다. 오류 개수를 알려주면 목표치가 생겨서 집요하게 찾는다. 위치까지 알려주면 완벽하게 고친다.

4강에서 yongol validate가 하는 것이 정확히 이것이다. “SSaC의 CancelReservation이 Reservation.SoftDelete를 호출하는데, sqlc 쿼리에 SoftDelete 메서드가 없다.” 의견이 아니다. 사실이다. AI가 할 수 있는 유일한 반응은 “고치겠습니다"뿐이다.

연구에 의하면 “TDD를 하라"는 절차적 지시는 오히려 회귀를 악화시키고, 구체적 테스트 파일을 맥락에 제공하면 회귀가 70% 감소한다³. 지시가 아니라 사실이 회귀를 막는다.

기둥 2: 래칫 잠금 (Ratchet Pattern)

검증을 통과하면 잠근다.

래칫 렌치를 생각해보자. 톱니가 한 방향으로만 걸린다. 돌리면 앞으로 가고, 놓으면 멈추지만 되돌아가지 않는다. Ratchet Pattern은 이 메커니즘을 에이전트 제어에 적용한다.

항목 1: 기계적 검증 → PASS → 잠금 → 다음
항목 2: 기계적 검증 → FAIL → 재시도 (피드백 포함)
항목 2: 기계적 검증 → PASS → 잠금 → 다음
...
항목 N: PASS → 완료. 멈춤.

세 가지 규칙:

• 한 번에 하나의 항목만 보여준다.
• 통과해야 다음이 열린다.
• 전부 통과하면 멈춘다.

실제로 어떤 차이가 나는지 숫자로 보자:

자율 에이전트:  40 / 527  (7.6%)  — 에이전트가 "완료" 선언
래칫 CLI:     527 / 527 (100%)  — 기계가 "아직 487개 남았다" 선언

같은 모델이다. 같은 프로젝트다. 차이는 “끝"을 누가 결정하는가다.

자율 에이전트에서는 LLM이 종료를 판단한다. LLM은 낙관적이다. 40개를 하고 “충분하다"고 느낀다. 래칫에서는 기계가 종료를 판단한다. 기계는 느끼지 않는다. 남은 항목이 0이 될 때까지 “아직"이라고 선언한다.

3강에서 배운 Hurl 테스트가 래칫의 한 형태다. Hurl 테스트를 통과하면 잠근다. 새 기능을 추가할 때 기존 테스트를 삭제할 수 없다. 에이전트는 자유롭게 코드를 바꿀 수 있지만, 행위를 바꿀 수 없다. 앞으로만 간다.

기둥 3: 결정과 구현의 분리

4강에서 직접 체험한 것이다. 다시 한번 원리를 정리한다.

소스 코드에는 세 가지가 섞여 있다:

• 사용자 결정 — 이 컬럼은 BIGINT이다. 이 API는 소유자만 접근한다.
• 비즈니스 로직 — 가격 정책, 워크플로우, 상태 전이.
• 구현 세부사항 — 변수명, 에러 처리, 라이브러리 호출.

AI가 이 코드를 읽으면, 세 가지가 뒤섞인 텍스트를 본다. “리팩토링해줘"라고 시키면, 당신의 결정을 세부사항으로 착각하고 덮어쓴다.

결정을 코드 밖으로 꺼내면 이 문제가 사라진다. 결정은 SSOT에 살고, 코드는 SSOT에서 생성된 일회용 투영이다. AI가 결정을 세부사항으로 착각할 일이 없다. 결정의 생존이 모델 크기와 무관해진다.

세 기둥이 함께 작동하는 방식

세 기둥은 따로 놀지 않는다. 함께 작동한다.

4강에서 체험한 yongol 워크플로우를 세 기둥으로 분해해보자:

AI가 SSOT를 편집한다                 ← 기둥 3: 결정과 구현의 분리
  ↓
yongol validate가 에러를 반환한다     ← 기둥 1: 결정론적 피드백
  ↓
AI가 에러를 고친다
  ↓
validate 통과 → 래칫 잠금             ← 기둥 2: 래칫 잠금
  ↓
다음 기능으로

1. 분리 — AI가 편집하는 대상이 코드가 아니라 선언적 명세다. 결정만 있고 세부사항이 없다.
2. 피드백 — validate가 모순을 정확히 짚어준다. “여기 이 필드가 저기 저 필드와 다르다.” 사실이다.
3. 잠금 — 통과하면 다음으로. 되돌아가지 않는다.

이 세 가지가 빠지면 어떻게 되는가:

• 분리 없이 피드백만 있으면: 피드백은 정확하지만, AI가 결정을 덮어쓰는 것은 못 막는다.
• 피드백 없이 잠금만 있으면: 뭐가 틀렸는지 모르니 AI가 방향 없이 수정한다.
• 잠금 없이 피드백만 있으면: AI가 고쳤다가 다시 망가뜨린다. 진동한다.

세 기둥이 빠짐없이 있어야 수렴이 보장된다.

Symbolic Feedback Loop — 기차보다 선로

지금까지의 내용을 하나의 구조로 정리하면 이렇다:

LLM이 생성한다 → 결정론적 도구가 판정한다 → 결과를 LLM에 돌려준다 → 반복

이것을 Symbolic Feedback Loop라고 부른다.

왜 “Symbolic"인가? 피드백이 숫자, 파일명, 줄 번호 같은 구체적 기호(symbol)로 되어 있기 때문이다. “좀 이상한데?“가 아니라 “41번째 줄, user_id여야 하는데 userId라고 써 있다"처럼 나온다. 사람의 자연어 판단이 아니라 기계의 결정론적 판정이다. 그래서 Symbolic Feedback Loop라고 부른다.

지금 업계의 주류 방식은 다르다. AI가 AI를 검증한다. LLM이 코드를 쓰고, 다른 LLM이 그 코드를 리뷰한다. 이것을 LLM Feedback Loop라고 한다.

비유하면 이렇다. 술 취한 사람이 술 취한 친구에게 “나 취했어?“라고 묻는 구조다. 둘 다 확률적이니까 오류가 누적된다.

Symbolic Feedback Loop는 다르다. go test는 환각을 안 한다. yongol validate는 아첨을 안 한다. 커버리지 측정은 거짓말을 안 한다. 결정론적 도구는 매번 같은 입력에 같은 출력을 준다.

코딩 에이전트가 왜 작동하는지 생각해보자. Claude Code에서 AI가 코드를 쓰면, 파일시스템에 저장하고, 테스트를 실행하고, 빌드를 해본다. 이 과정에서 결정론적 게이트(테스트, 빌드, 타입 체크)가 끼어 있다. 이것이 의도치 않게 Symbolic Feedback Loop를 만든다. 그래서 작동하는 것이다.

그런데 왜 무너지는가? 테스트가 없는 구간에서 무너진다. 결정론적 게이트가 빠진 곳에서 AI는 확률적으로 판단하고, 확률적 판단은 곱으로 열화된다.

97.7% 정확도의 단계를 연달아 이으면:

• 2단계: 0.977 x 0.977 = 95.4%
• 5단계: 0.977^5 = 89.1%
• 10단계: 0.977^10 = 79.2%
• 100단계: 0.977^100 = 4.8%

200 엔드포인트에서 바이브 코딩이 무너지는 수학적 설명이다. 작은 프로젝트에서는 이어지는 단계가 적어서 확률이 버텨주고, 큰 프로젝트에서는 곱셈이 파멸적으로 작동한다.

래칫이 이것을 해결한다. 매 단계마다 결정론적 게이트를 끼우면, 열화가 리셋된다. 10단계를 한 번에 돌리면 곱셈이 파멸적이지만, 매 단계마다 래칫으로 고정하면 정확도가 단계별로 독립적이다.

기차를 더 빠르게 만드는 것보다, 선로를 까는 것이 중요하다. 많은 사람이 기차를 만들고 있다. 선로를 까는 사람은 아직 거의 없다.

“모델을 바꾸지 말고, 계약을 추가하라”

이것이 Reins Engineering의 핵심 명제다.

같은 모델이 40개에서 멈추기도 하고 527개를 완주하기도 한다. 같은 모델이 raw code를 편집하면 드리프트가 발생하고, SSOT를 편집하면 0 에러에 수렴한다. 같은 모델이 피드백 없이는 60~70% 커버리지에서 멈추고, 피드백과 함께하면 100%에 도달한다.

차이는 모델이 아니라 피드백 토폴로지다.

“모델 IQ를 올리는 것보다 검증 루프를 추가하는 것이 10배 싸다.”

이것을 비유로 풀면 이렇다. 인치주의 vs 법치주의.

인치주의는 현명한 왕에 의존한다. 왕이 똑똒하면 나라가 잘 돌아가고, 멍청하면 망한다. 더 똑똑한 모델을 기다리는 것이 인치주의다. “GPT-6가 나오면 해결될 거야.”

법치주의는 법에 의존한다. 왕이 똑똑하든 멍청하든, 법이 있으면 시스템이 작동한다. 계약을 추가하는 것이 법치주의다. “validate가 잡으면 모델이 뭐든 수렴한다.”

인류는 이미 이 답을 알고 있다. 피로 쓴 약속이다. 80억 인간이 한 행성 위에서 공존하는 이유는 인간이 선해서가 아니라, 법이 있기 때문이다.

AI도 다르지 않다.

제약은 계약이다

법치주의가 작동하려면 세 가지 조건이 필요하다:

1. 검증 가능하다. 위반 여부를 기계적으로 판정할 수 있다.

2. 위반이 정의되어 있다. “나쁜 코드를 쓰지 마라"가 아니라, “이 필드와 저 필드의 타입이 불일치하면 위반이다.” 이산적이다. 위반이거나 아니거나.

3. 강제할 수 있다. 위반에 결과가 따른다. yongol validate가 실패하면 코드 생성이 거부된다. 결과가 없는 약속은 약속이 아니라 희망이다.

이 세 조건을 같은 표에 넣어보면 패턴이 보인다:

모든 작동하는 시스템에는 약속이 있다. 약속이 검증 가능하고, 위반이 정의되어 있고, 강제할 수 있으면 — 시스템은 수렴한다.

약속이 없으면 혼돈이다. AI가 매번 다른 결과를 낸다. 종료 조건이 없다. 드리프트가 누적된다.

약속이 과하면 억압이다. 모든 것을 규정하면 유연성이 사라진다. 3줄짜리 함수에 10줄짜리 검증 규칙을 강제하면 본말이 전도된다.

황금비를 찾아야 한다. 충분히 제약하되 과도하지 않은 지점. yongol의 287개 규칙은 “레이어 간 모순이 없어야 한다"는 최소한의 약속이다. 레이어 안에서 AI는 자유롭게 쓴다. 레이어 사이에서만 계약이 작동한다.

충분한 자유 안의 충분한 질서. 이것이 황금비다.

아첨 편향은 버그가 아니라 자산이다

AI의 가장 큰 결함으로 꼽히는 아첨 편향(Sycophancy) — “사용자가 뭐라고 하면 동의해버리는 성향” — 이 Reins 구조에서는 오히려 자산이 된다. 의견을 주면 아첨하지만, 결정론적 사실을 주면 순순히 수용하고 실제로 고친다. 이 아첨 편향이 래칫 구조에서는 오히려 도움이 된다. 왜 그런지는 7강에서 자세히 다룬다.

코딩 에이전트가 작동하는 진짜 이유

2강에서 “왜 무너지는가"를 배웠다. 이제 “왜 작동하는가"를 이해할 차례다.

같은 모델이다. 웹 채팅에서 hallucinate하던 그 모델이, Claude Code에서는 200줄짜리 기능을 한 번에 올린다. 모델이 갑자기 똑똒해진 게 아니다. 달라진 건 구조다.

대화형 AI의 루프:

LLM → 사람 → LLM → 사람

피드백이 전부 자연어다. 확률적 생성에 확률적 평가가 이어진다.

코딩 에이전트의 루프:

LLM → 코드 생성 → 파일 저장 → 테스트 실행 → pass/fail → LLM

루프 안에 결정론적 게이트가 끼어있다. 파일시스템은 쓴 그대로 저장한다. 테스트는 pass 아니면 fail이다. 컴파일러는 틀리면 틀렸다고 한다.

AI는 매번 다른 결과를 내는 불안정한 부품이다. 하지만 불안정한 부품 위에 안정적인 규칙을 올리는 것은 공학에서 늘 해온 일이다.

바다는 출렁이지만 등대는 움직이지 않는다. 택배가 가끔 분실되지만 추적번호가 있으면 찾아낸다. 불안정한 것 위에 안정적인 체계를 세우는 일은 특별한 것이 아니라, 공학에서 늘 해온 일이다.

코딩 에이전트가 작동하는 이유는 같다. 불안정한 AI 위에 결정론적 검증기를 올렸기 때문이다.

Reins Engineering은 이 우연을 의도로 바꾸는 것이다. “우연히 테스트가 있어서 작동한다"가 아니라, “의식적으로 검증 게이트를 설계해서 수렴을 보장한다.”

정리 — 이 강의에서 기억할 것

1. 네 개의 시대. 프롬프트 → 컨텍스트 → 하네스 → Reins. 각 시대는 이전 시대의 한계에서 태어났다. 울타리(하네스)는 방향을 잡지 않는다. 고삐(Reins)는 방향을 잡는다.

2. 세 기둥. 결정론적 피드백, 래칫 잠금(Ratchet Pattern), 결정과 구현의 분리. 셋이 함께 있어야 수렴이 보장된다.

3. Symbolic Feedback Loop. LLM이 생성하고, 결정론적 도구가 판정하고, 결과를 LLM에 돌려준다. 기차보다 선로가 중요하다.

4. 모델을 바꾸지 말고, 계약을 추가하라. 같은 모델도 피드백 토폴로지에 따라 40에서 멈추기도 하고 527을 완주하기도 한다. 인치주의가 아니라 법치주의.

5. 아첨 편향은 자산이다. 의견을 주면 아첨하지만, 사실을 주면 수용한다. 결정론적 피드백 + 아첨하는 LLM = 수렴이 보장되는 루프.

실습: 결정과 세부사항을 구분하라

목표: 여러분의 프로젝트를 머릿속으로 열고, 결정과 세부사항이 어디서 섞이는지 찾아본다.

위 체험에서 느낀 것을 바탕으로 생각한다.

질문 1: 여러분의 프로젝트에서 “결정"은 무엇인가?

여러분이 AI에게 “만들어"라고 시킨 것들을 떠올려보라. 그중에서 “이건 반드시 이래야 한다"고 정한 것이 결정이다. 예를 들어:

• “로그인은 이메일로 한다” — 결정
• “비밀번호는 8자 이상이어야 한다” — 결정
• “변수명을 userEmail로 했다” — 세부사항

결정 3개, 세부사항 3개를 적어보라.

질문 2: CLAUDE.md에 적어놓은 결정이 코드에서 덮어쓰여진 적이 있는가?

1강에서 CLAUDE.md를 만들었다. 거기 적어놓은 규칙이 있을 것이다. AI가 그 규칙을 무시하고 다르게 만든 적이 있는가? 있다면 그것이 바로 결정과 세부사항이 섞이면서 생긴 드리프트다.

질문 3: 그 결정을 코드 밖에 두었다면?

만약 그 결정이 코드가 아니라 별도 명세에 적혀 있었다면, AI가 덮어쓸 수 있었을까? 4강의 yongol이 하는 일이 정확히 이것이다. 결정을 코드 밖으로 꺼내서, AI가 세부사항으로 착각하고 덮어쓰는 일을 원천 차단한다.

이 사고 실험에서 느꼈어야 하는 것:

• 결정과 세부사항은 다르다는 감각
• 코드 안에서는 이 둘이 구별되지 않는다는 인식
• 4강의 도구(yongol)와 5강의 원리(Reins Engineering)가 하나의 구조라는 이해

다음 강의 예고

5강에서 Reins의 원리를 이해했다. 6강에서는 Ratchet Pattern을 깊이 파고든다. 40에서 멈추는 에이전트를 527까지 완주하게 만드는 구체적인 방법. 래칫의 원리, 대량 작업에서의 적용, 그리고 Symbolic Feedback Loop의 실전 구현.

연관 글

• Reins Engineering — 고삐 있는 AI
• 모델 IQ보다 피드백 토폴로지
• 제약은 계약이다

Reins Engineering 전체 강의

근거 자료 출처

1. Carnegie Mellon University, MSR 2026 — AI 코딩 도구 도입 후 코드 복잡도 41% 영구 증가.
2. Google DORA Report, 2025 — AI 도입 25% 증가마다 전달 안정성 7.2% 감소.
3. TDAD, ACM AIWare 2026 — “TDD를 하라"는 절차적 지시(6.08% → 9.94%)는 회귀를 악화시키고, 구체적 테스트 파일을 맥락에 제공(6.08% → 1.82%)하면 회귀 70% 감소.