짧거나 불완전한 요청에서도 에이전트가 기존 맥락을 찾고, 필요한 질문만 하며, 결과를 검증하도록 만든 운영 지침과 적용 가이드입니다. 토큰 절약에서 시작해 의도 해석·실행·검증·개선까지 범위를 확장했습니다.
이 저장소에는 대화에서 메일로 발송한 Markdown 첨부 원본 9개와 이 README, 원본 검증용 목록이 들어 있습니다. 실행 가능한 에이전트 프레임워크나 설치 프로그램은 포함하지 않습니다. 문서 작성과 원본 복원은 완료했으며, 특정 프로젝트의 도구 연결과 행동 평가는 별도 작업입니다.
2026-09-17 발송한 최종 통합본 v2 두 파일을 기준으로 사용하세요.
| 문서 | 역할 | 우선 읽을 내용 |
|---|---|---|
| AGENT_HARNESS_GUIDE.md | 에이전트의 행동 원칙 | 2 |
| HARNESS_SETUP_GUIDE.md | 프로젝트에 적용하는 절차 | 4~5절 시작 지침, 8절 검증·재개 연결, 9절 행동 확인 |
핵심 규칙은 다음과 같습니다.
필요한 정보가 없으면 먼저 기존 문서와 도구에서 찾는다. 되돌릴 수 있는 선택은 합리적인 가정으로 진행한다. 결과나 범위를 크게 바꾸는 정보가 없을 때만 이유와 추천안을 함께 질문한다.
사용자의 요청을 단계적으로 반영해 문서를 작성하고 수정했습니다. 아래 이력은 대화의 요구사항과 보관된 첨부 버전을 기준으로 정리했습니다.
| 단계 | 요청·문제 | 문서에 반영한 내용 |
|---|---|---|
| 1. 토큰 효율 | 반복 탐색과 불필요한 출력을 줄이고 싶음 | 토큰 효율 가이드와 AGENTS.md·CLAUDE.md 초기 템플릿 |
| 2. 의도 해석 | 거칠거나 생략이 많은 요청도 맥락에 맞게 처리해야 함 | 목표·산출물·제약·완료 기준, 기존 자료 우선 탐색, 누락 정보 분류 |
| 3. 누락 대응 | 부족한 요소를 에이전트가 먼저 발견해야 함 | 구조·맥락·계획·실행·검증·개선의 여섯 축과 필수 정보 질문 기준 |
| 4. 전문가 사례와 적용 위치 | 공개된 실무 사례와 실제 적용 방법이 필요함 | 출처를 붙인 전문가 사례, 운영 지침과 설정 가이드 분리 |
| 5. 최종본 통합 | 여러 첨부 때문에 적용 기준이 혼동됨 | 토큰 원칙 통합, 최신 문서 두 개로 진입점 정리 |
| 6. v2 수정 | 모호한 요청, 반복 실패, 지침 증가, 실제 실행 연결을 보완해야 함 | 중요한 누락만 질문, 실패 사례로 효과 검증, 규칙 재평가, 짧은 시작 지침, 검증·재개 절차 |
| 7. 저장소 보관 | 메일 첨부 전체를 한곳에서 관리하고 싶음 | 메일 네 통의 첨부 아홉 개 복원, 최신본·이전본 분리, 크기·해시 기록 |
여섯 축은 이 문서의 점검 분류입니다. 특정 영상의 분류를 그대로 재현했다거나 업계의 고정된 여섯 종류 표준이라는 뜻은 아닙니다.
전문가 사례는 운영 지침 11절에 정리돼 있습니다. Karpathy의 실험·평가 분리, Simon Willison의 테스트와 실제 사용 확인, Anthropic의 장기 작업 상태 관리와 단순한 도구 설계, Boris Cherny의 검증 환경 및 지침 재평가 등을 문서의 적용안과 구분해 수록했습니다. 아래 참고 자료 목록에서 원문과 반영 위치를 함께 확인할 수 있습니다.
어떤 모델로 작성했는지, 유명 전문가를 몇 명 인용했는지만으로 품질을 판정하지 않습니다. 저장소에는 실제 모델 호출 기록이나 프로젝트별 성능 비교 결과가 포함돼 있지 않습니다.
아래 목록은 메일 첨부 원본에 기록된 출처를 모아 정리한 것입니다. 자료마다 이 하네스에 반영한 내용과 확인할 문서 위치를 함께 표시했습니다. 원문의 주장과 사용자 요구에 맞춰 추가한 운영 규칙은 구분합니다.
| 자료 | 반영한 내용 | 반영 위치 |
|---|---|---|
| 사용자가 제공한 ChatGPT 공유 대화 | 초기 토큰 효율 가이드의 바탕. 불필요한 맥락·도구 호출·출력을 줄이는 원칙 | 초기 토큰 효율 가이드, 운영 지침 10절 |
| 실밸개발자의 하네스 설명 영상 — 12:23부터 | 하네스의 구성 요소를 점검하는 출발점. 구조·맥락·계획·실행·검증·개선은 이 문서의 실무 분류로 구성 | 운영 지침 3절 및 참고 목록 |
| 이 문서를 만든 대화의 후속 요청과 수정 피드백 | 거친 요청의 맥락 해석, 빠진 정보 요청, 중요한 누락만 질문, 최종본 통합, 실패 기반 개선, 실제 검증 연결 | 운영 지침 2 |
공유 대화와 사용자 피드백은 요구사항의 출처입니다. 전문가의 독립적인 연구 결과나 성능 검증 자료로 취급하지 않습니다.
| 작성자·자료 | 이 하네스에 반영한 내용 | 반영 위치 |
|---|---|---|
| Andrej Karpathy — autoresearch | 변경 범위와 평가 기준 분리, 같은 조건의 실험 비교, 개선 여부를 근거로 변경 유지 | 운영 지침 11.1절, 적용 가이드 6절 |
| Simon Willison — First run the tests | 기존 테스트로 기준 상태와 검증 방법 확인, 기존 실패와 새 실패 구분 | 운영 지침 11.2절 |
| Simon Willison — Red/green TDD | 재현 테스트가 먼저 실패하는지 확인하고 수정 후 같은 검사로 통과 확인 | 운영 지침 11.2절 |
| Simon Willison — Agentic manual testing | 자동 테스트에 더해 화면·서버·API 등 실제 사용 경로 확인 | 운영 지침 11.3절, 적용 가이드 8절 |
| Justin Young / Anthropic — Effective harnesses for long-running agents | 기능별 완료 기준, 진행 기록과 Git 이력, 다음 세션의 재개, 구현과 검증 상태 구분 | 운영 지침 11.4절, 적용 가이드 8.3절 |
| Erik S.·Barry Zhang / Anthropic — Building effective agents | 단순한 구성에서 시작, 명확한 도구 입력·오류·예시, 실행 결과 관찰과 중단 조건 | 운영 지침 11.5절 |
| Prithvi Rajasekaran / Anthropic — Harness design for long-running application development | 주관적인 품질 기준 구체화, 생성과 평가 구분, 하네스 요소를 하나씩 바꿔 효과 비교 | 운영 지침 11.6·13절 |
| Boris Cherny / Y Combinator 인터뷰 — 하네스 재평가 3:30~9:23, 검증 환경 20:40~24:27 | 결과를 직접 확인할 도구 연결, 모델 변경 후 불필요한 지침 재평가, 반복 실패에 맞춘 보완 | 운영 지침 11.7·13절, 적용 가이드 6·8절 |
각 항목의 상세한 원문 요지와 이 문서의 적용안은 운영 지침 11절에 있습니다. 예를 들어 질문 기준, 일반 업무용 중단 조건, 영향에 맞춘 테스트 범위는 원문을 그대로 옮긴 문장이 아니라 이 하네스의 적용상 조정입니다.
| 공식 자료 | 참고한 범위 | 반영 위치 |
|---|---|---|
| OpenAI — AGENTS.md 구성 | 에이전트 시작 지침의 위치와 구성, 상세 가이드 연결 | 운영 지침 1절, 적용 가이드 3~4절 |
| OpenAI — 모델 사용 가이드 | 의도 파악·작업 완수·결과 검증에 관한 지침 | 운영 지침 2~7절 및 참고 목록 |
| Anthropic — Claude Code 지침과 메모리 | CLAUDE.md와 규칙 파일, 공통 지침을 연결하는 배치 방식 | 적용 가이드 3·5절 |
| Anthropic — Claude Code hooks | 반복 검사를 도구 이벤트와 연결하는 방법 | 적용 가이드 8절 |
첨부 원본에 기록된 확인 시점은 전문가 자료 2026-09-16~17, 제품 설정 문서 2026-09-17입니다. 이번 README 갱신은 기존 출처를 모아 반영 위치를 정리한 작업이며, 원문 내용이나 링크의 현재 유효성을 다시 검증한 작업은 아닙니다. 특히 latest-model과 제품 문서는 내용이 바뀔 수 있으므로 실제 적용 시 현재 공식 문서와 대조해야 합니다.
하네스는 일정한 주기로 무조건 다시 쓰기보다, 실패 증거·모델 변경·도구 변경·평가 포화가 생겼을 때 업데이트하는 편이 좋습니다. 전문가들의 사례를 종합하면 다음 네 가지가 주요 신호입니다.
| 업데이트 신호 | 먼저 확인할 것 | 권장 조치 |
|---|---|---|
| 같은 실패가 반복됨 | 실제 trace·대화·로그에서 모델의 실수인지 도구·평가의 문제인지 | 실패를 재현하는 평가 사례를 추가하고, 가장 좁은 규칙·도구·검사 하나를 바꿔 비교 |
| 새 모델이나 큰 모델 버전이 도입됨 | 기존 모델과 새 모델의 동일한 capability·regression 평가, 비용·지연 | 이전 모델의 약점을 보완하던 장치를 하나씩 제거하거나 새 능력에 맞는 장치를 추가 |
| 도구·프로젝트·사용자 흐름이 바뀜 | 경로·권한·API·UI·성공 상태가 기존과 같은지 | 시작 지침, 도구 설명, 실행 연결, 완료 판정을 현재 환경에 맞게 갱신 |
| 평가가 계속 100%이거나 실제 사용자 실패를 놓침 | 평가 사례가 너무 쉽거나 실제 사용과 어긋나는지, grader가 정당한 결과를 거부하지 않는지 | 어려운 실제 실패를 추가하고, 포화된 capability 평가를 regression 평가로 전환하거나 평가 기준을 수정 |
모델 사용량이 초기화됐다는 사실만으로 하네스를 바꾸지는 않습니다. 사용량 초기화·정기 예약은 운영 일정이고, 하네스 업데이트는 성능·실패·환경 변화에 대한 기술적 판단입니다.
- 기준 상태를 고정한다. 현재 모델·지침 버전·도구 구성·대표 평가 결과·토큰·비용·지연을 기록합니다. 변경 이유도 한 문장으로 남깁니다.
- 실패 사례를 모은다. 실제 사용자 실패, 버그 보고, 수동 검사, trace에서 20~50개의 작은 사례부터 시작합니다. 사례가 적더라도 먼저 시작하고, 정상적으로 처리해야 하는 사례와 처리하면 안 되는 사례를 함께 넣습니다.
- 평가가 공정한지 확인한다. 작업 설명과 성공 기준이 모호하지 않은지, 정상적인 다른 풀이를 불필요하게 막지 않는지, grader가 실패를 제대로 설명하는지 확인합니다. 낮은 점수가 모델 실패가 아니라 잘못된 과제·환경·채점 설정 때문일 수 있습니다.
- 한 번에 한 요소만 바꾼다. system prompt, tool schema, hook·middleware, memory, sub-agent, 모델 선택 중 하나를 후보로 바꿉니다. 원본은 Git으로 보존하고 변경의 예상 효과를 먼저 적습니다.
- 동일 조건으로 비교한다. capability 사례와 기존 정상 사례를 모두 실행합니다. 코드 기반 검사·상태 확인·trace 지표를 우선하고, 주관적 품질은 rubric과 사람의 표본 검토를 함께 사용합니다.
- trace와 실제 결과를 읽는다. 점수만 보지 말고 실패한 대화와 도구 호출을 읽어 모델 오류, 도구 부족, 지침 충돌, 평가 오류를 구분합니다. UI·API·메일·예약처럼 외부 상태가 있는 작업은 최종 화면만 보지 말고 실제 상태를 확인합니다.
- 유지·되돌림·보류를 결정한다. 목표가 개선되고 regression이 없으면 유지합니다. 악화되거나 특정 사례에만 맞으면 되돌립니다. 실행하지 못한 변경은 “검증 대기”로 남깁니다.
- 다음 평가로 연결한다. 새로 발견한 실패를 평가 세트에 추가하고, 변경 이유·전후 결과·적용 범위·다음 재평가 조건을 기록합니다.
- 추가: 반복되는 실패가 재현되고, 실패 원인이 지침·도구·검증 누락으로 확인될 때만 추가합니다. 단 한 번의 이상한 응답만으로 전역 규칙을 늘리지 않습니다.
- 줄이기: 새 모델에서 같은 작업을 더 단순하게 처리하거나, 동일한 평가에서 규칙·도구·middleware를 제거해도 품질이 유지될 때 줄입니다. Anthropic은 새 모델의 능력이 기존 장치의 역할을 대체하는지 요소별로 확인했고, LangChain도 평가 결과에 따라 기본 prompt·도구 설명·todo middleware를 줄였습니다.
- 유지: 안전·권한·사용자 요구·사실 보존처럼 모델 능력과 무관한 필수 제약은 성능 실험만으로 제거하지 않습니다.
- 조건부 적용: 긴 다단계 작업, 능력이 낮은 모델, UI에서 진행 표시가 필요한 경우처럼 특정 조건에서만 효과가 확인된 장치는 기본값이 아니라 선택 기능으로 둡니다.
| 시점 | 해야 할 일 |
|---|---|
| 매 작업·매 세션 | 기존 지침과 진행 상태를 읽고, 프로젝트에 이미 있는 테스트나 기본 검증을 먼저 실행 |
| 실패가 발생한 직후 | trace·로그·사용자 보고를 보존하고 재현 가능한 평가 사례 후보로 기록 |
| 지침·도구를 바꿀 때 | 변경 전후를 같은 사례로 비교하고, 정상 사례의 회귀를 확인 |
| 새 모델로 전환할 때 | 모델만 먼저 바꾼 기준 결과를 만든 뒤, 기존 보완 장치를 하나씩 재평가 |
| 출시·중요 배포 전 | 자동 평가와 실제 사용 경로를 실행하고, 외부 상태와 권한까지 확인 |
| 운영 중 | 사용자 피드백·실패 trace·비용·지연을 모아 평가 세트를 유지하고, 필요할 때만 다음 개정 |
정기 점검을 두더라도 문서 전체를 매번 다시 작성할 필요는 없습니다. 변경 후보와 평가 결과가 없으면 “변경 없음”으로 기록하는 것이 더 안전합니다.
| 자료 | 사례에서 확인되는 업데이트 원칙 |
|---|---|
| Anthropic: Harness design for long-running application development | 실제 trace를 읽고, 새 모델이 기존 장치를 대체하는지 하나씩 제거해 확인합니다. 모델이 좋아져도 모든 장치를 없애거나 유지한다고 가정하지 않고, 작업 난이도에 따라 evaluator 같은 장치를 선택적으로 유지합니다. |
| Anthropic: Demystifying evals for AI agents | 실제 실패에서 작은 평가 세트를 일찍 만들고, capability와 regression을 함께 운영합니다. 점수만 믿지 말고 transcript와 grader를 읽으며, 평가가 포화되거나 공정하지 않으면 사례·채점 기준을 고칩니다. |
| Anthropic: Effective harnesses for long-running agents | 긴 작업에서 세션 간 상태가 끊기면 initializer, feature list, progress 기록, Git 이력, end-to-end 검증을 추가합니다. 다음 세션이 실제 상태를 읽고 이어갈 수 있는지 확인합니다. |
| Simon Willison: First run the tests | 새 세션이나 변경 전에는 기존 테스트를 먼저 실행해 기준 상태와 검증 방법을 확인합니다. 테스트가 없거나 실행되지 않으면 그 사실을 완료 근거로 바꾸지 않습니다. |
| LangChain: Improving Deep Agents with harness engineering | trace에서 반복 실패를 분류하고, system prompt·도구·middleware 중 표적 변경을 한 뒤 평가로 확인합니다. 특정 task에 과적합하지 않도록 다른 사례의 회귀를 함께 확인합니다. |
| LangChain: Deep Agents v0.7 | 평가에서 성능을 유지한 채 불필요한 기본 prompt·도구 설명·todo middleware를 줄였습니다. todo처럼 특정 작업에서만 유용한 장치는 조건부로 켭니다. |
이 자료들은 서로 다른 제품과 실험에서 나온 사례이므로 그대로 복사할 표준은 아닙니다. 공통으로 확인되는 원칙은 실제 실패를 평가로 만들고, 한 요소씩 바꾸고, 같은 조건에서 회귀를 확인하며, 새 모델이 기존 장치를 여전히 필요로 하는지 다시 측정하라는 것입니다.
- 맥락을 먼저 찾기: 이미 제공된 정보를 다시 질문하는 일을 줄입니다.
- 중요한 누락만 질문하기: 수정이 쉬운 선택은 진행하되, 대상·권한·외부 영향처럼 추정할 수 없는 조건은 확인합니다.
- 시작 지침을 짧게 유지하기: 핵심 원칙과 상세 문서 위치를 연결하고 필요한 절을 읽게 합니다.
- 완료를 증거로 판단하기: 문서 작성, 도구 연결, 실행 검증, 행동 평가를 서로 다른 상태로 관리합니다.
- 실제 실패를 바탕으로 고치기: 반복 실패의 원인에 맞는 규칙이나 도구를 추가하고 같은 사례로 효과를 확인합니다.
- 규칙을 줄이는 것도 개선으로 보기: 모델·도구 변경이나 반복 오류 때 중복·충돌·효과 없는 규칙을 재평가합니다.
- 대상 프로젝트의 기존 지침과 실행·검증 설정을 확인합니다.
- 최신 문서 두 개를 참고 자료로 배치하고, 기존 시작 지침에는 핵심 원칙과 실제 경로만 합칩니다. 기존 프로젝트 지침을 통째로 덮어쓰지 않습니다.
- 설정 가이드 8절에 따라 실제 테스트 명령, 작업 디렉터리, 준비 조건, 성공 기준, 결과 확인 도구를 연결합니다.
- 여러 세션이 필요한 작업에는 목표·변경·검증 결과·미해결·다음 행동을 기록하고 재개 시 실제 상태와 대조합니다.
- 과거 실패 사례와 정상 요청을 함께 실행해 질문·실행·검증 행동을 확인합니다. 파일을 읽었다는 답만으로 적용 완료를 판정하지 않습니다.
구체적인 도구 설정은 적용 가이드를 따릅니다. 문서의 예시 경로와 명령은 대상 프로젝트에서 존재와 동작을 확인해야 합니다.
아래는 아직 구현·검증하지 않은 개선 계획입니다. 이미 원칙이 적혀 있는 항목도 실제 도구 및 평가 결과로 연결하는 작업이 남아 있습니다.
| 우선순위 | 개선 과제 | 적용 위치 | 완료를 판단할 증거 |
|---|---|---|---|
| 1 | 프로젝트 하나에 실제 검증 연결 | 대상 프로젝트의 기존 테스트 설정과 검증 문서 | 명령·작업 위치·준비 조건을 기록하고 실제 종료 코드와 결과를 확인 |
| 1 | 모호한 요청에 대한 행동 평가 | 평가 사례와 실행 결과 기록 | 정상·실패 사례 5~10개로 변경 전후 목표 달성, 불필요한 질문, 근거 없는 가정, 검증 누락 비교 |
| 1 | 예약과 외부 발송의 완료 증거 연결 | 예약·메일 도구를 사용하는 프로젝트의 실행 흐름 | 일회성 여부·날짜·시간대·실행 환경 확인, 실패 보고, 발송 식별자와 실제 첨부 확인 |
| 1 | 접근 실패를 단계별로 진단 | 외부 서비스 연결 절차와 오류 기록 | 네트워크 연결·서버 신원 확인·사용자 인증·저장소 권한 중 실제 실패 단계를 구분 |
| 2 | 중단 후 재개 검증 | 진행 기록과 재개 절차 | 새 세션에서 완료된 작업을 반복하지 않고 미완료 단계부터 이어감 |
| 2 | 반복 실패와 지침 변경 연결 | 실패 기록, 지침 변경 이력, 동일 평가 사례 | 실패 원인과 최소 변경을 기록하고 기존 정상 사례의 회귀 여부 확인 |
| 2 | 지침 중복·충돌 줄이기 | 시작 지침과 운영 지침 | 한 요소씩 변경해 품질이 유지되거나 개선되는지 비교 |
| 3 | 버전과 출처 관리 | README, 변경 이력, 문서 내 출처 | 최신본이 명확하고 변경 이유·검증 상태·출처 확인 시점이 남음 |
| 3 | 첨부 무결성 검사 자동화 | 별도 검증 스크립트 및 필요 시 CI | 파일 누락·크기 또는 해시 변경을 탐지하고 실패로 반환 |
우선 작은 프로젝트 하나에서 1순위 과제를 검증한 뒤 필요한 장치를 추가하는 것이 이 저장소의 제안입니다. 규칙이나 자동화를 늘렸다는 사실만으로 개선 완료로 처리하지 않습니다.
실제로 발생한 혼동과 장애를 다음 개선의 입력으로 사용할 수 있습니다. 아래 기대 행동은 향후 평가 기준이며, 평가를 통과했다는 보고가 아닙니다.
| 입력·상황 | 기대 행동 |
|---|---|
| “갱신 때 다시 해줘”에서 갱신의 뜻이 여러 가지임 | 앞선 맥락에서 모델 사용량 초기화인지 문서 개정인지 확인하고, 결과를 바꾸는 누락만 질문 |
| “오늘 4:16에 한 번만” | 반복 예약으로 바꾸지 않고 날짜·시간대·일회성 조건과 실제 실행 결과 확인 |
| “최종안으로 전부 보내” | 최신 문서와 이전본을 구분하고 실제 발송 결과와 첨부 확인 |
| “첨부 전부 push해줘” 중 SSH 오류 발생 | 첨부 수집·커밋은 진행하고, 서버 신원 확인 실패를 네트워크 차단으로 보고하지 않음 |
| 로컬 커밋은 성공했지만 push는 실패함 | 로컬 완료와 원격 업로드를 구분하고 인증 해결 후 원격 브랜치의 커밋까지 확인 |
외부 발송과 예약 평가는 모의 도구나 테스트 환경에서 먼저 수행합니다. 실제 재시도 전에는 기존 완료 여부를 조회해 중복 발송·중복 예약을 방지하는 절차도 확인합니다.
Harness/
├── README.md
├── AGENT_HARNESS_GUIDE.md # 최신 v2 운영 지침
├── HARNESS_SETUP_GUIDE.md # 최신 v2 적용 가이드
├── attachments-manifest.json # 메일 첨부 원본 9개의 크기·해시
├── .gitattributes # 첨부 Markdown의 줄바꿈 변환 방지
└── archive/
├── 01-token-efficiency/ # 초기 첨부 3개
├── 02-harness-experts/ # 전문가 사례 반영 첨부 2개
└── 03-superseded-final/ # v2 이전 최종 첨부 2개
| 폴더 | 내용 | 첨부 수 |
|---|---|---|
| archive/01-token-efficiency | 최초 토큰 효율 가이드 및 AGENTS.md·CLAUDE.md | 3 |
| archive/02-harness-experts | 전문가 팁을 추가한 운영·적용 가이드 | 2 |
| archive/03-superseded-final | v2로 대체된 이전 최종본 | 2 |
이전 문서는 당시 발송한 기록입니다. 최신본과 충돌하면 루트의 v2를 기준으로 사용하세요. 보관 폴더의 AGENTS.md·CLAUDE.md는 이전 첨부 원본이며 이 저장소의 활성 지침으로 설치한 파일이 아닙니다.
첨부는 메일 원문의 MIME 데이터에서 복원했습니다. 같은 파일명을 가진 버전은 폴더로 구분하고, 복원한 바이트 수를 첨부 메타데이터와 대조한 뒤 SHA-256을 기록했습니다. 첨부가 없는 메일은 제외했습니다.
- attachments-manifest.json은 첨부 아홉 개만 대상으로 합니다. README는 저장소 설명을 위해 별도로 작성했습니다.
- 이번 README 개정에서는 첨부 내용과 원본 해시 목록을 변경하지 않습니다.
- 메일 본문, 수신자 정보, 임시 다운로드 주소는 저장소 구성에 포함하지 않습니다.
- 해시 일치는 복원한 파일의 무결성을 확인합니다. 문서 내용의 정확성이나 에이전트 성능을 보증하지는 않습니다.
- 향후 가이드를 수정할 때는 기존 메일 첨부 원본을 먼저 보존하고 새 개정본과 변경 이력을 구분합니다. 원본 해시를 새 내용에 맞춰 덮어쓰지 않습니다.
README 갱신: 2026-09-29. 첨부 최신본: 2026-09-17 v2.