저장소의 테스트와 문서를 정돈할 때는 폴더 이름을 통일하는 것만으로 충분하지 않습니다. 무엇을 한곳에 모을지뿐 아니라, 예외를 어디까지 허용할지와 미완료 자료를 어떻게 보존할지도 정해야 합니다.

이번 제안은 큰 방향에서 수렴점이 있지만, 세 가지를 같은 뜻으로 취급하지 않도록 주의해야 합니다. 모든 테스트를 무조건 업무 코드 폴더 밖으로 옮기는 것, 규범을 모든 ADR의 요약으로 만드는 것, 계획을 동결하는 일을 완료 아카이브로 보는 것은 각각 다른 문제입니다. 아래 경로는 모두 제안 후보이며, 아직 생성되거나 이전된 상태는 아닙니다.

1. 테스트는 중앙 관리가 기본, 다만 언어별 예외를 둔다

테스트를 tests/처럼 별도 위치에서 관리하는 방식을 기본값으로 삼을 수 있습니다. 그렇다고 모든 프로젝트에서 소스 코드와 같은 디렉터리에 테스트가 하나도 없어야 한다고 정할 필요는 없습니다.

• Python: 테스트를 tests/에 모으는 방식을 우선 검토합니다. 이전할 때는 임포트 경로, 테스트 검색, 픽스처, CI 설정이 그대로 동작하는지 함께 확인해야 합니다. 현재 저장소의 CI 설정도 테스트를 중앙 경로에서 실행하는 방식을 사용합니다.
• Go: 비공개 식별자에 접근해야 하는 화이트박스 테스트는 테스트 대상 패키지에 둘 수 있습니다. 블랙박스 테스트나 여러 컴포넌트를 아우르는 통합·엔드투엔드 테스트는 중앙 관리가 더 적합할 수 있습니다. Go 도구는 패키지별로 테스트 파일을 포함해 다시 빌드하며, 같은 패키지 테스트와 외부 테스트 패키지 두 방식을 지원합니다.1416

여기서 구분할 점이 있습니다. internal 디렉터리의 임포트 제한은 디렉터리 조상 관계에 따라 적용되는 규칙이지, 그 패키지를 쓰려면 반드시 같은 디렉터리에 있어야 한다는 뜻은 아닙니다. 비공개 멤버에 접근할 수 있는지 여부는 별도의 패키지 경계 문제입니다.1016

따라서 “Go 테스트를 전부 업무 코드 디렉터리 밖으로 옮기면서 화이트박스 검증과 캡슐화도 모두 그대로 유지한다”는 조건을 기본 수용 기준으로 삼기는 어렵습니다. 단지 폴더를 깔끔하게 보이게 하려고 내부 상태를 공개하거나 업무 로직을 복제해서는 안 됩니다.

줄여야 할 대상은 가치가 낮은 티켓 조각이나 중복 검증이지, 유지보수에 필요한 독립 테스트 파일이 아닙니다. 지속적으로 회귀 검증에 쓰이는 테스트는 버전 관리하고, 한 번만 실행할 탐색용 프로브는 임시 영역에 둘 수 있습니다.

2. 규범·ADR·전역 규칙은 서로 다른 층위다

specs/를 “모든 ADR에서 공통 규범을 추출한 곳”으로 정의하는 것은 적절하지 않습니다. 세 문서 체계의 역할을 분리하는 편이 명확합니다.

구분	답하는 질문	주된 내용
전역 방법론	분석·검증·전달은 어떻게 하는가?	방법론 관리자가 정하는 작업 방식
프로젝트 진입점 AGENTS.md	이 프로젝트에서는 어떻게 작업하는가?	확인된 프로젝트 제약과 작업 안내
프로젝트 규범 specs/	현재 어떤 동작과 계약을 충족해야 하는가?	사용자 요구, 수용된 결정, 승인된 변경
결정 기록 docs/adr/	왜 이 선택을 했는가?	중요한 설계 선택과 대안 간의 절충

Cline 공식 문서는 대화가 달라져도 유지되는 지침을 위한 규칙 기능을 설명합니다.4 다만 이를 근거로 Cline이 특정 파일을 규범 디렉터리에 자동으로 작성한다고 말할 수는 없습니다. 그런 동작은 제품이 보장하는 기능이 아니라 프로젝트에서 정할 운영 규칙으로 다뤄야 합니다.

프로젝트 문서는 모두 사람이 처음부터 직접 작성해야 하는 것도 아니고, 문제가 생긴 뒤에야 만들어야 하는 것도 아닙니다. 초기에는 사용자 요구와 저장소에서 확인한 근거를 바탕으로 규범 초안을 제안하되, 모르는 내용은 미확인 상태로 남길 수 있습니다. 이후 작업에서는 관련 규범과 결정 기록을 먼저 확인하고, 이번 작업의 수용 기준과 검증 방법을 정합니다.

새로운 ADR은 중요한 선택이 생겼을 때만 제안합니다. 기존 결정이 적용된다면 이를 참조하면 됩니다. 테스트 결과는 구현이 기준을 충족하는지 판단하는 근거가 될 수 있지만, 그 결과만으로 요구사항이나 결정이 자동으로 승인되는 것은 아닙니다. 결정이 승인되고 규범이 수정되면 현재 유효한 제약을 규범에 반영하고, 관련 ADR을 연결합니다. 과거 기록을 규범 문서에 전부 복사할 필요는 없습니다.

요약하면 규범은 현재의 계약, ADR은 결정의 배경, 테스트는 실행 가능한 확인 수단입니다. 서로 연결되지만 대체 관계는 아닙니다. 한 프로젝트에서 발견한 내용을 검토 없이 전역 규칙으로 확대해서도 안 됩니다.

3. ADR 경로는 통일하되, 승인 기준은 바꾸지 않는다

새 결정 기록의 기본 위치를 docs/adr/로 정하는 것은 합리적인 프로젝트 명명 규칙입니다. 이를 유일한 업계 표준이라고 주장할 필요는 없습니다.

기록 방식은 다음 원칙을 유지할 수 있습니다.

• 제안, 수용, 거부, 대체된 결정을 모두 보존합니다. 수용된 기록만 남기는 것은 아닙니다.
• 이미 유효한 결정이 있다면 새 작업에서 참조하고, 같은 ADR을 반복해서 만들지 않습니다.
• 기존 결정이 대체되면 관련 기록을 연결하되, 당시의 근거를 사후에 고쳐 쓰지 않습니다.
• 테스트 통과를 ADR 승인 권한과 동일시하지 않습니다.

경로를 이전할 때는 파일 이동에서 끝내지 말고, 실제 참조와 라우팅, 접근 권한 제약도 함께 갱신해야 합니다.

4. 계획은 평면적으로 관리해도 되지만, 동결은 완료가 아니다

plans/ 아래에 계획을 평면적으로 두는 방식도 가능합니다. 계획이 많지 않다면 과거 파일을 위해 하위 폴더를 미리 늘릴 이유는 없습니다. 예를 들어 다음과 같은 이름을 후보로 둘 수 있습니다.

용도	후보 파일명	의미
진행 중인 계획	pending_implementation_plan.md	기본 작업 진입점으로 쓰는 활동 계획 하나
완료 후 보관	plan-20261022-example-id.md	필수 검수와 보관 승인을 마친 계획
미완료 상태로 동결	plan-20261022-example-id-frozen.md	남은 일을 보존하고 기본 실행 대상에서 제외한 계획

동결만을 위해 새 디렉터리나 별도 상태값을 즉시 추가할 필요는 없습니다. 현재 검증기가 일시 중지 상태를 지원하므로, 우선 이를 활용해 동결 사유와 남은 일, 재개 조건을 기록할 수 있습니다.

상태에 따른 의미는 분명히 달라야 합니다.

• 완료 후 보관: 필수 수용 기준을 모두 통과했고 보관 승인을 받았습니다.
• 미완료 동결: 활성 계획 목록에서는 빠지지만, 완료로 표시되지 않습니다. 검증되지 않은 제안도 사실로 격상되지 않습니다.
• 명시적 중단: 더 이상 실행하지 않기로 한 이유와 영향을 남깁니다. 단순한 일시 중단과 구분해야 합니다. 정식 종료 상태를 추가할지는 별도 계약 변경으로 다룰 수 있습니다.

기본적으로는 활동 계획 진입점만 읽고, 같은 폴더의 과거 파일을 매번 모두 검색하지 않는 편이 낫습니다. 과거 기록은 사용자가 복구나 열람을 요청할 때 찾아봅니다. 동결된 계획을 재개하려면 별도 승인을 받고, 원본을 출처로 남긴 새 실행 인스턴스를 만들어 다시 검증해야 합니다. 과거의 성공 판정을 그대로 물려받을 수는 없습니다. 이는 현재 수명주기 규칙과도 일치합니다.

파일 이름을 바꾸는 것은 저장 작업이지 검수 증명이 아닙니다. 덮어쓰기를 막고 미완료 항목을 보존하며 참조를 정리해야 합니다. 고정 진입점을 유지하겠다는 이유만으로 빈 계획 템플릿을 반드시 만들 필요도 없습니다.

5. 테스트와 코드의 관계는 일대일이 아니라 다대다다

“코드 하나당 테스트 하나”라는 대응 규칙은 권장하지 않습니다. 한 테스트가 여러 컴포넌트를 확인할 수 있고, 하나의 컴포넌트에는 단위 테스트와 속성 테스트, 통합 회귀 테스트가 함께 필요할 수 있습니다.

우선은 tests/ 안에서 모듈이나 책임에 따라 테스트를 나누고, 관련 규범에 핵심 불변 조건과 테스트 실행 경로, 범위를 제한한 검증 명령을 적는 방식으로 시작할 수 있습니다. 코드와 테스트의 관계를 찾기 어려운 경우에만 tests/test-map.yaml 같은 매핑 파일을 추가하는 편이 좋습니다.

매핑에는 모듈 또는 계약 식별자, 소스 범위, 테스트 범위, 검증 진입점처럼 필요한 관계만 담습니다. 전체 폴더 구조를 복제하거나 테스트 통과 상태까지 중복 기록하지 않습니다. 매핑 파일이 있다는 사실만으로 테스트가 충분하거나 통과했다고 입증되는 것도 아닙니다. 유지 관리 기준은 경로와 명령이 유효한지 확인하는 것입니다.

6. 임시 자료는 정리하되, 증거의 가치는 위치만으로 판단하지 않는다

일회성 초안과 임시 스크립트, 탐색 보고서를 .scratch/에 모으는 방향은 유용합니다. 다만 그 안의 모든 자료를 “1차 정보가 아님”으로 간주하거나 언제든 전부 삭제할 수 있다고 정하는 것은 위험합니다.

모델이 작성한 연구 요약은 2차 해석이므로 그 자체를 검증된 사실로 올려서는 안 됩니다. 반면 실제 테스트 출력이나 진단 기록은 임시 디렉터리에 있더라도 1차 증거일 수 있습니다. 신뢰도는 파일 위치만이 아니라 출처와 실행 환경, 시점, 기록의 완전성에 달려 있습니다.

계획이나 결정, 검수에서 아직 참조하는 유일한 증거는 임의로 지우면 안 됩니다. 정리 전에 필요한 원본을 보존하거나, 그 증거에 의존한 결론을 명시적으로 철회해야 합니다. 중요한 발견을 정리할 때도 근거 위치와 적용 범위, 남은 불확실성을 함께 남겨야 합니다. 요약 과정에서 가정을 사실로 바꾸어서는 안 됩니다.

docs/의 오래된 보고서와 아키텍처 다이어그램도 단순히 오래됐다는 이유만으로 모두 폐기할 필요는 없습니다. 현재 유지하는 문서에는 적용 범위를 표시하고 관련 계약이 바뀔 때 검토합니다. 과거 자료는 역사적·폐기·대체 상태를 명시해 현재 기준선으로 오인되지 않게 합니다. 장기적 가치도 없고 참조 의존성도 없는 과정 자료라면 승인 후 임시 영역으로 옮기거나 삭제할 수 있습니다.

보존과 기본 로딩은 별개의 문제입니다. 필요한 과거 기록을 남겨 둔다고 해서 매 작업마다 전부 읽어야 하는 것은 아닙니다. 근거를 지우기보다 필요한 자료만 선택적으로 읽고, 유효 상태를 표시해 문맥 혼선을 줄이는 편이 안전합니다.

결론: 정돈보다 중요한 것은 경계와 이력 보존

이 구조는 네 가지 경계를 함께 둔다면 채택할 수 있습니다. 테스트 중앙 관리에는 언어별 예외를 허용하고, 규범은 모든 ADR의 요약이 아니라 현재 계약으로 관리합니다. 동결된 계획은 미완료 상태를 유지하고, 임시 자료를 정리할 때는 유일한 필수 증거를 보존합니다.

다만 현재 기본 계획 경로와 허용 경로, 분석 모드의 편집 범위는 이전 구조를 기준으로 합니다. 실제 전환을 진행한다면 규칙, 템플릿, 참조, 검증기와 실행 환경에 맞춘 설정을 함께 갱신해야 합니다. 폴더 이름만 바꿨다고 새 구조가 적용되는 것은 아닙니다.

이번 검토에서는 저장소 자산을 작성·이전·동결·정리하지 않았습니다. 제시한 경로와 명명 방식은 아직 제안 단계입니다.

저장소의 테스트와 문서를 정돈할 때는 폴더 이름을 통일하는 것만으로 충분하지 않습니다. 무엇을 한곳에 모을지뿐 아니라, 예외를 어디까지 허용할지와 미완료 자료를 어떻게 보존할지도 정해야 합니다.

이번 제안은 큰 방향에서 수렴점이 있지만, 세 가지를 같은 뜻으로 취급하지 않도록 주의해야 합니다. 모든 테스트를 무조건 업무 코드 폴더 밖으로 옮기는 것, 규범을 모든 ADR의 요약으로 만드는 것, 계획을 동결하는 일을 완료 아카이브로 보는 것은 각각 다른 문제입니다. 아래 경로는 모두 제안 후보이며, 아직 생성되거나 이전된 상태는 아닙니다.

1. 테스트는 중앙 관리가 기본, 다만 언어별 예외를 둔다

테스트를 tests/처럼 별도 위치에서 관리하는 방식을 기본값으로 삼을 수 있습니다. 그렇다고 모든 프로젝트에서 소스 코드와 같은 디렉터리에 테스트가 하나도 없어야 한다고 정할 필요는 없습니다.

• Python: 테스트를 tests/에 모으는 방식을 우선 검토합니다. 이전할 때는 임포트 경로, 테스트 검색, 픽스처, CI 설정이 그대로 동작하는지 함께 확인해야 합니다. 현재 저장소의 CI 설정도 테스트를 중앙 경로에서 실행하는 방식을 사용합니다.
• Go: 비공개 식별자에 접근해야 하는 화이트박스 테스트는 테스트 대상 패키지에 둘 수 있습니다. 블랙박스 테스트나 여러 컴포넌트를 아우르는 통합·엔드투엔드 테스트는 중앙 관리가 더 적합할 수 있습니다. Go 도구는 패키지별로 테스트 파일을 포함해 다시 빌드하며, 같은 패키지 테스트와 외부 테스트 패키지 두 방식을 지원합니다.1416

여기서 구분할 점이 있습니다. internal 디렉터리의 임포트 제한은 디렉터리 조상 관계에 따라 적용되는 규칙이지, 그 패키지를 쓰려면 반드시 같은 디렉터리에 있어야 한다는 뜻은 아닙니다. 비공개 멤버에 접근할 수 있는지 여부는 별도의 패키지 경계 문제입니다.1016

따라서 “Go 테스트를 전부 업무 코드 디렉터리 밖으로 옮기면서 화이트박스 검증과 캡슐화도 모두 그대로 유지한다”는 조건을 기본 수용 기준으로 삼기는 어렵습니다. 단지 폴더를 깔끔하게 보이게 하려고 내부 상태를 공개하거나 업무 로직을 복제해서는 안 됩니다.

줄여야 할 대상은 가치가 낮은 티켓 조각이나 중복 검증이지, 유지보수에 필요한 독립 테스트 파일이 아닙니다. 지속적으로 회귀 검증에 쓰이는 테스트는 버전 관리하고, 한 번만 실행할 탐색용 프로브는 임시 영역에 둘 수 있습니다.

2. 규범·ADR·전역 규칙은 서로 다른 층위다

specs/를 “모든 ADR에서 공통 규범을 추출한 곳”으로 정의하는 것은 적절하지 않습니다. 세 문서 체계의 역할을 분리하는 편이 명확합니다.

구분	답하는 질문	주된 내용
전역 방법론	분석·검증·전달은 어떻게 하는가?	방법론 관리자가 정하는 작업 방식
프로젝트 진입점 AGENTS.md	이 프로젝트에서는 어떻게 작업하는가?	확인된 프로젝트 제약과 작업 안내
프로젝트 규범 specs/	현재 어떤 동작과 계약을 충족해야 하는가?	사용자 요구, 수용된 결정, 승인된 변경
결정 기록 docs/adr/	왜 이 선택을 했는가?	중요한 설계 선택과 대안 간의 절충

Cline 공식 문서는 대화가 달라져도 유지되는 지침을 위한 규칙 기능을 설명합니다.4 다만 이를 근거로 Cline이 특정 파일을 규범 디렉터리에 자동으로 작성한다고 말할 수는 없습니다. 그런 동작은 제품이 보장하는 기능이 아니라 프로젝트에서 정할 운영 규칙으로 다뤄야 합니다.

프로젝트 문서는 모두 사람이 처음부터 직접 작성해야 하는 것도 아니고, 문제가 생긴 뒤에야 만들어야 하는 것도 아닙니다. 초기에는 사용자 요구와 저장소에서 확인한 근거를 바탕으로 규범 초안을 제안하되, 모르는 내용은 미확인 상태로 남길 수 있습니다. 이후 작업에서는 관련 규범과 결정 기록을 먼저 확인하고, 이번 작업의 수용 기준과 검증 방법을 정합니다.

새로운 ADR은 중요한 선택이 생겼을 때만 제안합니다. 기존 결정이 적용된다면 이를 참조하면 됩니다. 테스트 결과는 구현이 기준을 충족하는지 판단하는 근거가 될 수 있지만, 그 결과만으로 요구사항이나 결정이 자동으로 승인되는 것은 아닙니다. 결정이 승인되고 규범이 수정되면 현재 유효한 제약을 규범에 반영하고, 관련 ADR을 연결합니다. 과거 기록을 규범 문서에 전부 복사할 필요는 없습니다.

요약하면 규범은 현재의 계약, ADR은 결정의 배경, 테스트는 실행 가능한 확인 수단입니다. 서로 연결되지만 대체 관계는 아닙니다. 한 프로젝트에서 발견한 내용을 검토 없이 전역 규칙으로 확대해서도 안 됩니다.

3. ADR 경로는 통일하되, 승인 기준은 바꾸지 않는다

새 결정 기록의 기본 위치를 docs/adr/로 정하는 것은 합리적인 프로젝트 명명 규칙입니다. 이를 유일한 업계 표준이라고 주장할 필요는 없습니다.

기록 방식은 다음 원칙을 유지할 수 있습니다.

• 제안, 수용, 거부, 대체된 결정을 모두 보존합니다. 수용된 기록만 남기는 것은 아닙니다.
• 이미 유효한 결정이 있다면 새 작업에서 참조하고, 같은 ADR을 반복해서 만들지 않습니다.
• 기존 결정이 대체되면 관련 기록을 연결하되, 당시의 근거를 사후에 고쳐 쓰지 않습니다.
• 테스트 통과를 ADR 승인 권한과 동일시하지 않습니다.

경로를 이전할 때는 파일 이동에서 끝내지 말고, 실제 참조와 라우팅, 접근 권한 제약도 함께 갱신해야 합니다.

4. 계획은 평면적으로 관리해도 되지만, 동결은 완료가 아니다

plans/ 아래에 계획을 평면적으로 두는 방식도 가능합니다. 계획이 많지 않다면 과거 파일을 위해 하위 폴더를 미리 늘릴 이유는 없습니다. 예를 들어 다음과 같은 이름을 후보로 둘 수 있습니다.

용도	후보 파일명	의미
진행 중인 계획	pending_implementation_plan.md	기본 작업 진입점으로 쓰는 활동 계획 하나
완료 후 보관	plan-20261022-example-id.md	필수 검수와 보관 승인을 마친 계획
미완료 상태로 동결	plan-20261022-example-id-frozen.md	남은 일을 보존하고 기본 실행 대상에서 제외한 계획

동결만을 위해 새 디렉터리나 별도 상태값을 즉시 추가할 필요는 없습니다. 현재 검증기가 일시 중지 상태를 지원하므로, 우선 이를 활용해 동결 사유와 남은 일, 재개 조건을 기록할 수 있습니다.

상태에 따른 의미는 분명히 달라야 합니다.

• 완료 후 보관: 필수 수용 기준을 모두 통과했고 보관 승인을 받았습니다.
• 미완료 동결: 활성 계획 목록에서는 빠지지만, 완료로 표시되지 않습니다. 검증되지 않은 제안도 사실로 격상되지 않습니다.
• 명시적 중단: 더 이상 실행하지 않기로 한 이유와 영향을 남깁니다. 단순한 일시 중단과 구분해야 합니다. 정식 종료 상태를 추가할지는 별도 계약 변경으로 다룰 수 있습니다.

기본적으로는 활동 계획 진입점만 읽고, 같은 폴더의 과거 파일을 매번 모두 검색하지 않는 편이 낫습니다. 과거 기록은 사용자가 복구나 열람을 요청할 때 찾아봅니다. 동결된 계획을 재개하려면 별도 승인을 받고, 원본을 출처로 남긴 새 실행 인스턴스를 만들어 다시 검증해야 합니다. 과거의 성공 판정을 그대로 물려받을 수는 없습니다. 이는 현재 수명주기 규칙과도 일치합니다.

파일 이름을 바꾸는 것은 저장 작업이지 검수 증명이 아닙니다. 덮어쓰기를 막고 미완료 항목을 보존하며 참조를 정리해야 합니다. 고정 진입점을 유지하겠다는 이유만으로 빈 계획 템플릿을 반드시 만들 필요도 없습니다.

5. 테스트와 코드의 관계는 일대일이 아니라 다대다다

“코드 하나당 테스트 하나”라는 대응 규칙은 권장하지 않습니다. 한 테스트가 여러 컴포넌트를 확인할 수 있고, 하나의 컴포넌트에는 단위 테스트와 속성 테스트, 통합 회귀 테스트가 함께 필요할 수 있습니다.

우선은 tests/ 안에서 모듈이나 책임에 따라 테스트를 나누고, 관련 규범에 핵심 불변 조건과 테스트 실행 경로, 범위를 제한한 검증 명령을 적는 방식으로 시작할 수 있습니다. 코드와 테스트의 관계를 찾기 어려운 경우에만 tests/test-map.yaml 같은 매핑 파일을 추가하는 편이 좋습니다.

매핑에는 모듈 또는 계약 식별자, 소스 범위, 테스트 범위, 검증 진입점처럼 필요한 관계만 담습니다. 전체 폴더 구조를 복제하거나 테스트 통과 상태까지 중복 기록하지 않습니다. 매핑 파일이 있다는 사실만으로 테스트가 충분하거나 통과했다고 입증되는 것도 아닙니다. 유지 관리 기준은 경로와 명령이 유효한지 확인하는 것입니다.

6. 임시 자료는 정리하되, 증거의 가치는 위치만으로 판단하지 않는다

일회성 초안과 임시 스크립트, 탐색 보고서를 .scratch/에 모으는 방향은 유용합니다. 다만 그 안의 모든 자료를 “1차 정보가 아님”으로 간주하거나 언제든 전부 삭제할 수 있다고 정하는 것은 위험합니다.

모델이 작성한 연구 요약은 2차 해석이므로 그 자체를 검증된 사실로 올려서는 안 됩니다. 반면 실제 테스트 출력이나 진단 기록은 임시 디렉터리에 있더라도 1차 증거일 수 있습니다. 신뢰도는 파일 위치만이 아니라 출처와 실행 환경, 시점, 기록의 완전성에 달려 있습니다.

계획이나 결정, 검수에서 아직 참조하는 유일한 증거는 임의로 지우면 안 됩니다. 정리 전에 필요한 원본을 보존하거나, 그 증거에 의존한 결론을 명시적으로 철회해야 합니다. 중요한 발견을 정리할 때도 근거 위치와 적용 범위, 남은 불확실성을 함께 남겨야 합니다. 요약 과정에서 가정을 사실로 바꾸어서는 안 됩니다.

docs/의 오래된 보고서와 아키텍처 다이어그램도 단순히 오래됐다는 이유만으로 모두 폐기할 필요는 없습니다. 현재 유지하는 문서에는 적용 범위를 표시하고 관련 계약이 바뀔 때 검토합니다. 과거 자료는 역사적·폐기·대체 상태를 명시해 현재 기준선으로 오인되지 않게 합니다. 장기적 가치도 없고 참조 의존성도 없는 과정 자료라면 승인 후 임시 영역으로 옮기거나 삭제할 수 있습니다.

보존과 기본 로딩은 별개의 문제입니다. 필요한 과거 기록을 남겨 둔다고 해서 매 작업마다 전부 읽어야 하는 것은 아닙니다. 근거를 지우기보다 필요한 자료만 선택적으로 읽고, 유효 상태를 표시해 문맥 혼선을 줄이는 편이 안전합니다.

결론: 정돈보다 중요한 것은 경계와 이력 보존

이 구조는 네 가지 경계를 함께 둔다면 채택할 수 있습니다. 테스트 중앙 관리에는 언어별 예외를 허용하고, 규범은 모든 ADR의 요약이 아니라 현재 계약으로 관리합니다. 동결된 계획은 미완료 상태를 유지하고, 임시 자료를 정리할 때는 유일한 필수 증거를 보존합니다.

다만 현재 기본 계획 경로와 허용 경로, 분석 모드의 편집 범위는 이전 구조를 기준으로 합니다. 실제 전환을 진행한다면 규칙, 템플릿, 참조, 검증기와 실행 환경에 맞춘 설정을 함께 갱신해야 합니다. 폴더 이름만 바꿨다고 새 구조가 적용되는 것은 아닙니다.

이번 검토에서는 저장소 자산을 작성·이전·동결·정리하지 않았습니다. 제시한 경로와 명명 방식은 아직 제안 단계입니다.