Stacked Research

Stacked Research

결과가 쌓이게 만드는 규율. 막는 것은 하나다 — 이미 아는 것을 다시 사는 것.

§0 트레이드오프

이 규율은 처리량보다 누적을 택한다. 일회성 확인·탐색적 질문 하나에는 과하다. 연구 프로그램이 여러 날 이상 이어지고 결과가 서로를 참조해야 할 때만 켠다.

§1 3층 분리 — 목표 / 가설 / 수단

셋을 한 문서에 섞으면 가설 교체가 목표 변경처럼 보여서, 반증된 가설 주변을 맴돌게 된다.

★승인 대상은 "발사"가 아니라 "가설"이다. 등록된 가설 범위 안에서 발사는 자율. 범위 밖이면 승인. 발사마다 승인을 받으면 루프 주기를 사람이 정하게 되고, 승인이 필요 없는 활동(문서 쓰기)으로 시간이 샌다.

반증된 가설을 같은 자리의 다른 가설로 교체하는 것은 목표 변경이 아니다. 이 구분이 없으면 죽은 경로에 갇힌다.

§1.1 목표는 사다리로 쪼갠다 — 안 쪼개면 아무 실험도 목표에 안 닿는다

목표 한 문장은 실험이 조준할 수 없다. 독립 검증 가능한 링크의 사슬 (A 표현 → B 획득 → C 보존 → D 인출 → E 사용 → F 이득)로 쪼개고, 각 링크의 상태를 한 화면에 둔다. 틀·상태 표기·유지: references/constitution-template.md

읽는 법 두 가지.

• 깨진 링크 아래의 실험은 전부 무의미하다 — C가 깨졌는데 C를 쓰는 팔을 돌리면 널이 보장된다.
• ★깨진 링크가 있는데 F가 양성이면, 가치는 그 링크를 우회하는 경로로 오고 있다. 그 우회 경로를 찾는 것이 다음 실험이다. 실측: C·D가 깨진 채로 F가 +1 이었고, 판정문이 우회 후보를 이름까지 적어 놓았는데 9일간 아무도 열지 않았다.

§2 발사 전 게이트 여덟 — 전부 기계 검사

하나라도 못 대면 발사하지 않는다. 통과를 문서에 적지 말고 명령으로 확인한다.

★G5~G8은 전부 앞 게이트를 전부 통과한 실패가 만들었다. 한 줄씩만:

• G5 실측: 테스트 918개 초록인 채로 한 능력이 4주간 0 — 발견까지 열흘.
• G6 실측: 사전등록 8건 중 목표 링크 위 1건, 그 1건이 유일한 양성. 소음을 좇으면 정의상 로컬 미니마다.
• G7 실측: 올리려던 중간지표가 기존 로그 회귀 2분에서 최종지표와 −0.90 이었다.
• G8 실측: 팔 이름을 믿고 돈 9시간 66런이 통째로 무효 — 정체는 매니페스트에 평문으로 있었다.

구현·스니펫·각 게이트의 탄생 전말: references/gates.md

§2.1 지표는 가설에서 유도한다 — 있는 지표를 쓰지 않는다

가장 흔한 실패는 게이트를 안 지킨 게 아니라 잴 수 없는 지표를 들고 게이트 앞에 선 것이다. 실측: 주 지표가 0/419 로 고정된 채 11일을 돌았다 — 무엇을 해도 0이니 실험이 구별되지 않았다.

유도 절차 다섯 — ① 가설을 구별 진술로("X를 배운 모델과 안 배운 모델이 무엇에서 갈리나") ② 갈리는 조작을 찾고 ③ 바닥을 실제로 돌리고 ④ 천장을 만들고 ⑤ 조작 자체를 배선검사한다. 각 단계는 명령으로 확인한다. 절차·조작 표·실례(색치환): references/gates.md G3-0

판별 질문 셋 — 하나라도 걸리면 주 지표로 쓰지 않는다. ① 암기로 이 수를 올릴 수 있나(실측: 암기로 1.0000 인 모델의 규칙 성분이 0) ② 바닥~천장 간격이 잡음바닥보다 넓은가 — 팔 비교 전에 A-vs-A 를 먼저 잰다 ③ 최종지표와 인과로 연결되나 — 상관뿐이면 대리 지표다(실측: 자릿수 22개 괴리).

지표는 가설마다 하나, 프로그램 전체에 고정한다. 실측: 사전등록 76건이 주 지표를 거의 76개 만들었고, 그래서 결과가 위로 안 쌓이고 옆으로 늘어섰다. 새 주 지표 도입은 승인 사항으로 둔다(§9).

§3 2트랙 — 탐색과 확증에 다른 기어를

Registered-Report 규율은 확증용이다. 탐색에 적용하면 관측 하나가 임상시험 비용이 된다.

확증에는 탐색이 고른 것만 올라온다. 버림률이 0이면 규율의 증거가 아니라 탐색을 안 했다는 증거다.

§3.1 슬롯 예약 — 소음이 목표를 못 밀어내게

동시 진행 실험은 두 개로 제한하고, 그중 최소 하나는 목표 링크(G6) 위에 둔다.

규율이 아니라 주의 배분 장치다. 회귀 부검이 목표 실험을 이기는 것은 게을러서가 아니라 부검이 구조적으로 더 매력적이기 때문이다 — 질문이 날카롭고, 답이 확정적이고, 빨리 닫히고, 바로 옆에 있다. 예약이 없으면 매번 진다.

⚠미결 실험이 슬롯 수를 넘으면 새 발사 금지. 실측: 미결 8건이 쌓인 채로 이미 닫힌 부정 공간을 다시 좁히는 팔을 넷 더 냈다.

§3.2 슬롯 집행 — 예약은 선언이 아니라 선점이다 (2026-08-06 신설)

등록된 G6 목표 링크 실험은 항상 한 슬롯을 선점한다. 그 슬롯이 실행·종료되기 전에는 새 탐색·문헌·감사 커밋을 하나만 허용하고, 등록 범위 내 발사는 승인 대기로 15분 이상 중단할 수 없다.

실측(0806): §3.1이 선언만 있고 집행이 없어서 GPU 가 9시간 유휴였다 — §9가 허용해 둔 발사를 발사마다 다시 물었고, §1이 예고한 그대로 문서 쓰기로 시간이 샜다. 전말: references/case-studies.md §12

⚠혼동 금지: 학습 0 이어도 사전등록·판정 밴드·판정문이 있으면 값싼 CONF 다. 값싼 확증은 장려하고, 승인 대기만 금지한다.

기계 집행 셋:

1. 매 커밋에 EXP/CONF/OPS · G6 링크 · GPU 예상시간 · 승인등급을 적는다.
2. GPU 15분 유휴 → 알람. 문서·승인 대기 활동을 즉시 중단하고 예약된 슬롯을 발사한다.
3. CONF 판정이 학습 가능한 타깃을 열었을 때만 다음 슬롯에 학습 실험을 우선 예약한다. (비율 규칙은 쓰지 않는다 — 값싼 CONF 를 부당하게 학습으로 강제한다.)

§4 실험 후 의무 — CLAIMS 갱신 없이 판정문 금지

기록이 서사적(무슨 일이 있었나)이면 안 쌓인다. 규범적(이제 무엇이 금지되나)이어야 한다.

주장마다 세 필드가 반드시 있어야 한다:

• 닫는 것 — 이제 무의미해진 실험들. 이게 없어서 닫힌 문을 두드린다.
• 여는 것 — 부정 결과가 지정하는 다음 수. 없으면 부정이 그냥 끝난다.
• 재확인 계수기 — 같은 결론을 다시 산 횟수. 2 이상이면 §7.

정정은 덮어쓴다. 주장 대장에 ⛔블록을 쌓으면 "지금 무엇이 참인가" 를 읽을 수 없게 된다.

스펙·실례: references/claims-schema.md

§5 코드 원칙 — 새 실험 = 새 파일이 아니라 새 config

승인 게이트가 있으면 승인이 필요 없는 새 파일을 만드는 쪽이 항상 싸다. 그래서 고아가 쌓인다.

1. 조합으로 되면 코드를 안 쓴다. 등록된 손실·자·조건화의 조합이면 config만.
2. 새 원자가 필요하면 core/ 에 등록한다. 파일 하나 = 개념 하나. 등록되면 모든 실험이 쓴다.
3. 일회성 진단은 probes/ 에 격리. 학습 금지를 코드로 강제하고, 기한이 지나면 archive/.
4. ★도구도 등록한다 — 관문에 안 걸린 도구는 "완성"이 아니라 "미배선"이다. 만들면 그 자리에서 게이트·CI·CLAIMS 중 하나에 건다. 못 걸면 미완성으로 적는다. 실측 셋(감사기 미갱신 · 벽 프로토콜 스크립트 부재 · 불변 기계 0회 발화)이 전부 나중에 처음부터 다시 만들 뻔했다.
5. 버림 예산. 새 실험 디렉터리를 열 때 닫힌 실험 하나를 접는다 — 스크립트는 공용 하네스로 흡수하거나 지우고 판정문만 남긴다. 실측: 어느 구간에서 파일 추가 113 / 삭제 3(2.7%), 진단 스크립트 디렉터리는 삭제 0건.

정본 고정은 아키텍처만이 아니라 트레이너까지 건다. 안 그러면 잠긴 파일을 피해 포크가 생긴다.

§5.6 저장소 배치 — 수명이 다른 것을 같은 곳에 두지 않는다

정리가 안 되는 이유는 게으름이 아니라 삭제 기준이 없어서다. 실측: 고아 스크립트 43/59 인데 하나도 못 지웠다 — 수명이 다른 파일이 한 디렉터리에 섞여 "지워도 되나" 에 답할 수 없었다. 구역 다섯(core/runners/experiments/probes/artifacts)이 갈리면 삭제 규칙이 자동으로 정해진다 — 그게 정리의 전부다. 배치도 · 단계별 experiments/ · 이관 규약(이동≠수정 커밋 · 매 이동 후 G5) · git 정책(결과 json 은 커밋) · 자기점검 넷: references/repo-layout.md

§6 붉은 깃발 — 이 생각이 들면 멈춘다

(§10 말미에 있던 수정 규율 깃발 7행을 이 표로 합쳤다. 아래 ①~⑥은 §10의 규칙 번호다.)

§7 이 스킬을 언제 고치는가

• 재확인 계수기가 2를 넘으면 — 색인이 아니라 이 스킬을 고친다. 왜 게이트가 못 잡았는지가 결함이다.
• 게이트를 통과했는데 실패가 났으면 — 게이트를 추가한다.
• ★새 스킬을 만들지 않는다. 이 스킬을 개선한다. 스킬이 늘면 스킬도 안 쌓인다 — 이 규율이 막는 실패와 같은 실패다.

§8 사람에게 보고하는 법

중간 보고는 길이가 아니라 결정 유무로 결정된다. 규약: references/briefing.md

핵심만: 결정이 없으면 5줄, 결정이 있으면 선택지와 비용. 진행 상황 나열은 보고가 아니다.

§9 실행 규율 — 승인은 어디에 걸고 변경은 어떤 단위로 자르나

코드를 쓰는 규율(단순하게·수술적으로·검증 루프)은 karpathy-guidelines 가 담당한다. 여기서 정하는 것은 승인 경계와 변경 단위다. (§10에 있던 "변경의 네 형식"을 여기로 합쳤다.)

승인 경계 — 세 등급. §1대로 승인은 발사가 아니라 층에 건다.

단계 분할 — 한 승인 = 되돌릴 수 있는 한 덩어리. 덩어리 하나는 이 넷을 다 갖는다: ① 무엇을 바꾸나(파일·줄) ② 무엇이 증명되면 성공인가(명령) ③ 깨지면 무엇으로 되돌리나 ④ 이게 여는 링크(G6). ③이 없으면 덩어리가 너무 큰 것이다.

변경의 네 가지 합법 형식. 새 코드를 쓰기 전에 어느 형식인지 선언한다. 다섯째는 없다.

순수 추가(append)는 정말 새 개념일 때만 허용하고, 그때도 수명·주인·발화 검사 셋을 함께 단다.

승인 서식 — 네 칸. 못 채우면 요청 자체가 무효.

1 차분        프롬프트·헌법·정본 코드의 바이트 차분
2 G5          회귀 벤치 전 → 후
3 G2          이 변경이 발화하는가 (기록된 런에서 ≥1회)
4 G3·G6       주 지표 해상도 / 여는 링크

⚠에이전트가 고른 숫자로 승인을 받으면 안 된다. 실측: 승인 근거가 "주 지표 2.8→1.0, 정확도 0.32→0.95" 였고 둘 다 사실이었으며, 같은 변경이 다른 능력을 4주간 0으로 만들었다. 빠진 칸은 하나뿐이었다 — 1번(차분).

§10 수정 규율 — 덧붙이기는 예외지 기본이 아니다

§5가 새 파일을 막고 §9가 변경 단위를 자른다면, 여기는 기존 파일에 계속 얹는 것을 막는다. (네 형식 표는 §9로, 붉은 깃발 표는 §6으로 합쳤다.)

① 뺄셈을 먼저 적는다. 모든 변경 제안은 "무엇을 지우나"를 첫 줄에 쓴다. 빈칸이면 제안이 안 끝난 것이다.

사람은 체계적으로 뺄셈을 놓치고(Nature 2021), 신호를 받았을 때만 달라진다 — 처방이 의지가 아니라 체크리스트 한 줄인 이유. 실측: 파일 추가 113 / 삭제 3(2.7%).

② 구조 변경과 행동 변경을 같은 커밋에 넣지 않는다.

Tidy First? — 구조(동작 불변)와 행동은 다른 커밋. 실측: 80커밋 대재구성에 프롬프트 한 문장이 섞여 한 능력이 4주간 0, 국소화에 열흘. 분리돼 있었다면 그날 잡혔다.

③ 기본값이 진실이다 — 옳다고 측정된 수정은 즉시 승격한다. 플래그 뒤에 있는 수정은 존재하지 않는 것과 같다.

실측: 회귀 원인을 확정하고(0727) 대가 없음까지 측정하고(0.009 vs 0.009) 기본값으로 안 올렸다. 그런 기본 OFF 플래그가 21개 — 기본 실행 = 몇 주 전 동작 + 그 뒤 전부 꺼짐.

④ 플래그에 수명과 주인을 붙인다. 없으면 만들지 않는다.

임시 토글은 몇 주 안에 만료돼야 하고, ★"나중에 정리하자"는 실패한다 — 수명주기가 자동이어야 한다. 실측: 가장 많이 켜진 플래그가 39회 켜지고 산출물 0개(무효 레버).

⑤ 먼저 자리를 만들고 나중에 채운다. 두 모자를 동시에 쓰지 않는다.

"변경을 쉽게 만들어라(이게 어려울 수 있다), 그 다음 쉬운 변경을 하라." 구조를 안 고치고 얹으면 얹기 쉬운 자리에만 얹게 되고, 그 자리가 옳은 경우는 드물다.

⑥ 고친 뒤 전체를 다시 읽는다 — 부분 수정의 합은 전체가 아니다. 어떤 성분(채점기·선택기·트리거)을 고쳤으면 그 성분 전체가 지금 무엇을 하는지 한 문장으로 쓴다. 못 쓰면 수정이 안 끝난 것이다.

절차 — 성분 지도. 그 성분에 입력되는 모든 경로를 한 표에 놓고 경로마다 ① 언제 도나 ② 무엇을 쓰나 ③ 어떤 조건에서 를 적은 뒤 두 질문: 덮어쓰는 쌍이 있나 · 상쇄하는 쌍이 있나. 실측: 한 채점기에 경로가 여덟이었는데 한 표에 놓자마자 결함 둘이 즉시 보였다 — 따로 읽으면 안 보인다. ⚠국소적으로 옳은 수정들이 합쳐서 틀린다. 전말: references/case-studies.md §13

§11 확인 사다리 — 위에서 답이 나오면 아래로 안 내려간다

실험은 가장 비싼 확인 수단이다. 그런데 하니스가 제공하는 게 그것뿐이면 습관적으로 거기부터 간다.

★①을 건너뛰면 ⑤가 통째로 무효가 될 수 있다.★ 실측: ①(매니페스트 한 줄)을 안 봐서 ⑤를 9시간 돌린 뒤 팔의 정체가 믿은 것과 달랐음이 드러났다. 같은 날 ①③만으로 같은 프로젝트의 결함 7건이 3시간·새 실행 0회로 나왔다.

규칙 둘. ⑤는 하루 한 세트. ⑤ 전에 반드시 G8(팔 차분).

§12 의도 대조 — 지시는 맥락이 아니라 체크리스트다

사람이 준 설계 문장("요소 넷, A는 코드, 나머지는 자연어, 평가는 두 축")을 배경설명으로 분류하면 그 순간 코드가 사양서 자리를 차지한다. 그러면 의도와의 어긋남은 원리적으로 안 보인다 — 어긋남이 기준으로 삼은 그 물건 안에 있기 때문이다.

★받는 즉시 체크리스트로 변환하고, 항목마다 grep 한 줄을 붙여 실행한다.★ 실측: 네 항목 전부 한 줄 조회였고 10분이면 끝났다. 대신 9시간을 썼고, 그동안 네 항목 중 둘이 이틀 전 삭제된 상태였다(코드 주석에 평문으로 적혀 있었다).

수정 한 건 = 의도 대조 한 번. 커밋마다 "이 변경이 체크리스트의 어느 항목을 만족시키나"를 적는다. 못 적으면 그 변경은 의도 위가 아니다. 이 체크리스트가 §13의 미결 인벤토리의 씨앗이다.

⚠사람은 의도를 알고 코드는 이력을 안다. 둘이 어긋날 때 코드만 보면 이력을 의도로 착각한다. 한 문장 질문("이 팔이 정확히 뭘 합니까")이 가장 싼 게이트다.

§12.1 단일 의도 계약 — 연구 문서는 하나만 정본으로 둔다

긴 실험에서는 README, 계획서, 프롬프트, 판정문이 의도를 복사해 서로 다른 목표를 말하기 쉽다. 프로젝트마다 사람이 승인한 INTENT.md 하나를 의도 정본으로 두고, 다음 필드만 관리한다.

목표(불변) · 가설(교체 가능) · 수단(자율 변경) · 소유 경계
평가 정의 · 목표 사다리 · G1–G8 상태 · 미결 inventory · 다음 확인 명령

• 다른 문서는 의도를 다시 쓰지 말고 INTENT.md를 링크한다. 계획서는 발사 순서, 프롬프트는 역할별 행동 규칙, 판정문은 실제 결과만 가진다.
• 코드와 문서가 어긋나면 먼저 INTENT.md의 필드별 명령으로 발화를 검사한다. 문서가 말한 성분이 로그에 없으면 “미구현/미배선”으로 기록하며 성공으로 해석하지 않는다.
• 목표를 바꾸지 않고 가설·수단을 바꿀 때는 의도 문서의 상태와 닫는 것/여는 것/재확인 계수기만 갱신한다. 새 목표를 조용히 추가한 보조 문서를 만들지 않는다.
• 발사 매니페스트에는 INTENT.md 해시, actor/editor/planner 프롬프트 해시, arm, seed, budget을 남긴다. 해시가 없거나 다른 의도 문서를 읽으면 발사를 무효 처리한다.

이 규칙의 최소 확인은 다음 네 명령이다: rg로 정본 링크를 찾고, 단위 테스트로 계약을 검사하고, 이전 로그를 재생하고, 마지막에만 새 실행을 한다. 의도 문서는 실험 결과를 꾸미는 보고서가 아니라 다음 결정을 제한하는 계약이다.

§13 진행 중 감사 — 착지를 기다리지 않는다

긴 작업(워크플로·다중 에이전트·장시간 실행)은 끝나고 보면 늦다. 두 주기를 건다.

10분 · 진행 중 감사 — 정본(헌법) · 대장(CLAIMS) · 사용자 지시 · 이 스킬에 대조

볼 것은 다섯뿐이다. 없으면 "없다"고 적고 끝낸다 — 볼 게 없을 때 문서를 쓰는 것이 대체활동이다.

⑴~⑷는 전부 "돌고 있는 것이 맞나" 다. ⑸만이 "없는 것" 을 본다. 실측(0807): ⑸가 없어서 지시 22건 중 10건만 구현되고 9건이 조용히 빠졌는데 아무 검사에도 안 걸렸다. 전말: references/case-studies.md §15

★어긋난 것을 찾으면 착지를 기다리지 않는다.★ 실측: 착지를 기다린 워크플로 둘에서 +146줄 순증과 감사기 출력 오독을 끝나고서야 발견했고, 되돌리는 데 한 사이클을 더 썼다. 반대로 10분 감사가 발사 전에 조항 하나를 잡았다 — 실측하니 쓸 수 있는 것의 88%를 버리는 설계였다.

미결 인벤토리 — 긴 작업의 정본은 이 표다

시작할 때 선언된 항목 전부(사용자 지시 · 사전등록 · 헌법 의무)를 한 표로 만들고 끝까지 유지한다.

• 항목마다 상태 하나만: BLOCK / OPEN / DECIDE / CLOSED.
• ★안 하기로 한 것도 적는다. 범위를 좁히면 뺀 항목과 이유를 그 자리에서 사람에게 말한다. 실측(0807): "이유는 있었으나 말하지 않은 축소"가 하루에 두 번 났다.
• 30분 산출물에 인벤토리 n/m done 숫자를 반드시 넣는다. 숫자가 안 움직이면 그게 신호다.

30분 · 아이도 이해할 언어로 산출물을 낸다

무엇을 시험했고 · 무엇이 됐고 · 무엇이 안 됐고 · 왜 · 다음은 무엇 · 인벤토리 n/m done. 전문용어를 쓰면 그 자리에서 풀어 쓴다.

★이것은 보고 형식이 아니라 오류 탐지 장치다 — 미룬 설명은 자기 틀 안에서 정리돼 오류가 숨는다. 실측 셋: "초록" 한 단어를 세 뜻으로 써 왔음이 드러남(셋째 뜻은 옳다는 뜻이 아니다) · 절단 규칙을 "참고서 43권 중 8권만 갖고 시험" 으로 풀자 88%를 버리는 설계가 즉시 보임 · 개수 손실과 선택 손실이 갈라짐(후자가 2.9배). 전말: references/case-studies.md §14

§13.1 병렬은 측정에 걸고 구현에 걸지 않는다

★모듈 시험과 의도 점검은 다른 층이다. 둘 다 병렬로, 따로 돌려라.★ 모듈 층은 "이 부품이 도는가", 의도 층은 "도는 것이 시킨 일인가" 를 묻는다. 부품이 다 초록인데 시킨 일이 아닐 수 있다 — 실측: 27개 모듈 중 다수가 ✅인 상태에서 사양 위반 3건이 동시에 살아 있었다.

★누락 감사관 1팔은 상설이다. 인벤토리 전 항목에 done / not-done / 이유 한 줄씩을 강제한다. "안 하기로 한 결정" 자체도 검증 대상이다 — 이유가 사실과 다르면 지적한다. 실측(0807): 이 팔이 없어서 "복원했다"고 커밋된 기계가 호출자 0 인 채 그 팔이 통제군과 바이트 동일이었다(G8 미실행과 겹친 사고).

⚠구현을 병렬로 돌린 대가는 실측됐다. 동시 21개 구현에서 사양 위반 3건 — 비용을 이유로 사양을 대체한 것 1건(사용자가 잡아냄), 착지 직전에 잡은 것 1건, 오판 1건. 파일 소유를 갈라도 사양 대조는 한 사람이 해야 한다. 그 한 사람이 21개를 동시에 보면 못 본다.

⇒ 측정은 넓게 병렬로, 구현은 좁게 순차로. 병렬 측정의 산출물은 "무엇을 고칠지" 이지 "고친 것" 이 아니다. 고치는 순서는 판정을 다 보고 정한다.

두 주기는 상한이지 알람이 아니다

커밋이 들어오거나 단계가 바뀌면 그때 본다. 10·30은 "이보다 오래 안 본 채로 두지 않는다" 는 뜻이다. ⚠주기를 지키느라 볼 것도 없이 도구를 부르지 마라 — 그것도 대체활동이다.

§14 사람의 역할 — 다섯. 에이전트가 구조적으로 못 하는 것만

②가 가장 값싸고 가장 강하다. 실측된 최대 사고 한 건이 이 질문 하나로 잡혔을 것이다.

근거: 이 규칙들은 전부 실패가 산 것이다. 규칙마다 "이게 없어서 무엇을 잃었나" 는 references/case-studies.md 에 실측으로 있다. 규칙이 과하게 느껴지면 거기부터 읽어라.

⚠이 스킬 자체는 사후 진단에서 나왔고, 앞으로 실패를 실제로 막는지는 미검정이다. 검정 방법은 §4의 재확인 계수기다 — 도입 이후 "같은 결론을 다시 산" 건수가 줄지 않으면 이 스킬이 실패한 것이다. 색인을 고치지 말고 §7대로 이 스킬을 고쳐라.