Implement Minimal Change
요구와 안전 조건을 온전히 만족하는 가장 작은 검증된 변경을 만든다. 줄 수나 파일 수를 먼저 줄이지 말고, 문제를 이해한 뒤 불필요한 구현과 장기 소유 비용을 줄인다.
작게 만드는 대상은 추측성 기능·추상화·미래 대비 구조다. 문제 진단, 영향 범위 조사와 원인 파악의 깊이는 줄이지 않는다.
우선순위와 적용 경계
- 사용자에게 약속한 결과, 저장소 지침, 권한과 공개 계약을 최소화보다 우선한다.
- 보안, 개인정보, 신뢰 경계의 입력 검증, 데이터 손실 방지 오류 처리, 접근성과 실제 환경의 calibration을 축소하지 않는다.
- 사용자가 명시한 기능을 YAGNI라는 이유로 거부하거나 반복해서 재논의하지 않는다. 요구 안의 선택적·추측성 범위만 근거와 함께 생략할 수 있다.
- 아키텍처 평가·정책 검사, 서비스 역공학, dead code·미사용 의존성 정리나 문서 작성이 작업의 주목적이면 해당 전문 절차를 우선한다. 전문 Skill이 없으면 이 Skill의 범위를 억지로 넓히지 말고 필요한 분석 범위를 알린다.
- 기획·계획 단계에서 문제 정의나 대안 범위를 좁히는 근거로 사용하지 않는다. 무엇을 만들지 정해진 뒤 그것을 어떻게 작고 완전하게 구현할지 판단할 때 적용한다.
변경 전 판단
- 원하는 관찰 가능한 동작, 대표 실패 상태, 호환성·성능·운영 제약과 완료 조건을 확인한다. 안전하게 추론할 수 없는 선택이 결과를 바꾸면 구현 전에 묻는다.
- 관련 entrypoint, 실제 호출·데이터 흐름, caller, 공개 표면과 가까운 테스트를 읽는다. 버그 수정에서는 증상이 나타난 지점과 원인이 생긴 지점을 구분해 원인 지점까지 추적한다. 작은 diff를 위해 이해 범위를 줄이지 않는다.
- 저장소에서 같은 문제를 해결한 helper, type, pattern과 이미 신뢰하는 품질 관문을 먼저 찾는다.
- 다음 후보 중 실제 요구를 완전히 만족하는 것을 비교한다.
- 새 구현 없이 기존 동작이나 설정으로 해결
- 저장소의 기존 구현 재사용
- 표준 라이브러리 또는 native platform 기능 사용
- 이미 설치된 의존성 사용
- 필요한 최소 custom code 작성
- 복잡한 공통 기능에서 직접 구현보다 총복잡도와 안정성을 개선하는 유지보수되는 새 라이브러리 사용
- 둘 이상의 후보가 충분하면 정확성, 안전, 공개 표면, 변경 파일·의존성, 가독성, 검증 가능성과 장기 소유 비용을 비교해 가장 작은 변경 표면을 고른다. 증상 지점만 막는 패치의 표면이 더 작아도 원인 지점 수정이 가능한 경우에는 원인을 고친다. 한 줄 구현이나 최소 LOC는 이 조건들이 같을 때만 tie-breaker로 사용한다.
구현 후보 탐색을 별도 연구 프로젝트로 만들지 않는다. 관련 경로, 기존 manifest와 의존성의 문서·타입에서 판단할 근거가 확보되면 선택하고 진행한다. 이 제한을 원인 진단을 조기에 중단하는 근거로 사용하지 않는다.
구현
- 결함의 원인 지점이 증상 지점과 다르면 증상마다 방어 코드를 더하지 말고 root cause를 고친다. 같은 원인이 여러 caller에 나타나면 원인 지점을 한 번 수정하되, 공유 원인이 없으면 새 공통화를 만들지 않는다.
- 두 번째 실제 사용 사례가 없는 interface·factory·설정, 미래를 위한 scaffold, 쓰이지 않는 호환 계층·fallback과 불필요한 간접 계층을 추가하지 않는다.
- 원인 지점과 저장소 경계에 맞는 응집된 파일에서 기존 구조와 명명 관례를 따른다. 파일 수를 줄이려고 다른 책임 위치에 우회 로직을 넣지 않는다. 짧지만 숨은 동작이 있는 표현보다 평범하고 읽을 수 있는 구현을 택한다.
- 새 의존성을 고려하면 기존 의존성의 실제 제공 기능을 먼저 확인하고, 추가가 직접 구현보다 유지보수성과 안정성을 실질적으로 높이는지 설명할 수 있어야 한다.
- 공개 CLI·API·schema·plugin hook을 깨뜨리거나 제거하는 변경은 사용자의 명시적 결정 없이 수행하지 않는다.
- 관련 없는 사용자 변경을 보존하고 요청 범위 밖 정리를 함께 넣지 않는다. 같은 원인이 다른 위치에서도 같은 결함을 만들면 요구 범위 안에서 함께 고치고, 별도 결정이나 큰 범위 확장이 필요하면 위치와 위험을 보고한다.
검증
- 가장 가까운 기존 테스트·정적 검사부터 실행하고, 변경한 동작의 성공 경로와 대표 실패 경로를 실제로 확인한다.
- 변경한 script는 저장소 규칙에 맞는 지원 환경에서 성공·대표 실패 경로를 실행한다. 검증을 위해 새 framework나 넓은 fixture 계층을 만들지 않는다.
- diff를 읽어 진단 없이 늘어난 파일, 의존성, 공개 표면, fallback과 중복 구현이 생기지 않았는지 확인한다.
- 더 작은 결과를 만들기 위해 기존 검사나 안전 장치를 약화하지 않는다. 실행할 수 없는 검증은 이유, 마지막 성공 지점과 남은 위험을 보고한다.
완료 보고
- 구현한 결과와 재사용한 기존 수단을 먼저 알린다.
- 생략한 추측성 범위가 있으면 생략 이유와 다시 검토할 관찰 신호를 구분한다.
- 실행한 검증과 미검증 범위를 보고한다. 요청받지 않은 설계 변론이나 고정된 짧은 출력 형식을 강제하지 않는다.
1---2name: sg-implement-minimal-change3description: 실제 코드 추가·수정·리팩터링·버그 수정에서 요구와 저장소 제약을 먼저 이해하고 기존 구현·표준 기능·설치된 의존성을 검토해 추측성 범위와 불필요한 구조를 뺀 가장 작은 완전한 변경을 구현·검증한다. 기획·문제 정의, 일반 문서 작성·아키텍처 평가·서비스 역공학·미사용 코드와 의존성 정리가 주목적인 요청에는 사용하지 않는다.4---56# Implement Minimal Change78요구와 안전 조건을 온전히 만족하는 가장 작은 검증된 변경을 만든다. 줄 수나 파일 수를 먼저 줄이지 말고, 문제를 이해한 뒤 불필요한 구현과 장기 소유 비용을 줄인다.910작게 만드는 대상은 추측성 기능·추상화·미래 대비 구조다. 문제 진단, 영향 범위 조사와 원인 파악의 깊이는 줄이지 않는다.1112## 우선순위와 적용 경계13141. 사용자에게 약속한 결과, 저장소 지침, 권한과 공개 계약을 최소화보다 우선한다.152. 보안, 개인정보, 신뢰 경계의 입력 검증, 데이터 손실 방지 오류 처리, 접근성과 실제 환경의 calibration을 축소하지 않는다.163. 사용자가 명시한 기능을 YAGNI라는 이유로 거부하거나 반복해서 재논의하지 않는다. 요구 안의 선택적·추측성 범위만 근거와 함께 생략할 수 있다.174. 아키텍처 평가·정책 검사, 서비스 역공학, dead code·미사용 의존성 정리나 문서 작성이 작업의 주목적이면 해당 전문 절차를 우선한다. 전문 Skill이 없으면 이 Skill의 범위를 억지로 넓히지 말고 필요한 분석 범위를 알린다.185. 기획·계획 단계에서 문제 정의나 대안 범위를 좁히는 근거로 사용하지 않는다. 무엇을 만들지 정해진 뒤 그것을 어떻게 작고 완전하게 구현할지 판단할 때 적용한다.1920## 변경 전 판단21221. 원하는 관찰 가능한 동작, 대표 실패 상태, 호환성·성능·운영 제약과 완료 조건을 확인한다. 안전하게 추론할 수 없는 선택이 결과를 바꾸면 구현 전에 묻는다.232. 관련 entrypoint, 실제 호출·데이터 흐름, caller, 공개 표면과 가까운 테스트를 읽는다. 버그 수정에서는 증상이 나타난 지점과 원인이 생긴 지점을 구분해 원인 지점까지 추적한다. 작은 diff를 위해 이해 범위를 줄이지 않는다.243. 저장소에서 같은 문제를 해결한 helper, type, pattern과 이미 신뢰하는 품질 관문을 먼저 찾는다.254. 다음 후보 중 실제 요구를 완전히 만족하는 것을 비교한다.26 - 새 구현 없이 기존 동작이나 설정으로 해결27 - 저장소의 기존 구현 재사용28 - 표준 라이브러리 또는 native platform 기능 사용29 - 이미 설치된 의존성 사용30 - 필요한 최소 custom code 작성31 - 복잡한 공통 기능에서 직접 구현보다 총복잡도와 안정성을 개선하는 유지보수되는 새 라이브러리 사용325. 둘 이상의 후보가 충분하면 정확성, 안전, 공개 표면, 변경 파일·의존성, 가독성, 검증 가능성과 장기 소유 비용을 비교해 가장 작은 변경 표면을 고른다. 증상 지점만 막는 패치의 표면이 더 작아도 원인 지점 수정이 가능한 경우에는 원인을 고친다. 한 줄 구현이나 최소 LOC는 이 조건들이 같을 때만 tie-breaker로 사용한다.3334구현 후보 탐색을 별도 연구 프로젝트로 만들지 않는다. 관련 경로, 기존 manifest와 의존성의 문서·타입에서 판단할 근거가 확보되면 선택하고 진행한다. 이 제한을 원인 진단을 조기에 중단하는 근거로 사용하지 않는다.3536## 구현3738- 결함의 원인 지점이 증상 지점과 다르면 증상마다 방어 코드를 더하지 말고 root cause를 고친다. 같은 원인이 여러 caller에 나타나면 원인 지점을 한 번 수정하되, 공유 원인이 없으면 새 공통화를 만들지 않는다.39- 두 번째 실제 사용 사례가 없는 interface·factory·설정, 미래를 위한 scaffold, 쓰이지 않는 호환 계층·fallback과 불필요한 간접 계층을 추가하지 않는다.40- 원인 지점과 저장소 경계에 맞는 응집된 파일에서 기존 구조와 명명 관례를 따른다. 파일 수를 줄이려고 다른 책임 위치에 우회 로직을 넣지 않는다. 짧지만 숨은 동작이 있는 표현보다 평범하고 읽을 수 있는 구현을 택한다.41- 새 의존성을 고려하면 기존 의존성의 실제 제공 기능을 먼저 확인하고, 추가가 직접 구현보다 유지보수성과 안정성을 실질적으로 높이는지 설명할 수 있어야 한다.42- 공개 CLI·API·schema·plugin hook을 깨뜨리거나 제거하는 변경은 사용자의 명시적 결정 없이 수행하지 않는다.43- 관련 없는 사용자 변경을 보존하고 요청 범위 밖 정리를 함께 넣지 않는다. 같은 원인이 다른 위치에서도 같은 결함을 만들면 요구 범위 안에서 함께 고치고, 별도 결정이나 큰 범위 확장이 필요하면 위치와 위험을 보고한다.4445## 검증46471. 가장 가까운 기존 테스트·정적 검사부터 실행하고, 변경한 동작의 성공 경로와 대표 실패 경로를 실제로 확인한다.482. 변경한 script는 저장소 규칙에 맞는 지원 환경에서 성공·대표 실패 경로를 실행한다. 검증을 위해 새 framework나 넓은 fixture 계층을 만들지 않는다.493. diff를 읽어 진단 없이 늘어난 파일, 의존성, 공개 표면, fallback과 중복 구현이 생기지 않았는지 확인한다.504. 더 작은 결과를 만들기 위해 기존 검사나 안전 장치를 약화하지 않는다. 실행할 수 없는 검증은 이유, 마지막 성공 지점과 남은 위험을 보고한다.5152## 완료 보고5354- 구현한 결과와 재사용한 기존 수단을 먼저 알린다.55- 생략한 추측성 범위가 있으면 생략 이유와 다시 검토할 관찰 신호를 구분한다.56- 실행한 검증과 미검증 범위를 보고한다. 요청받지 않은 설계 변론이나 고정된 짧은 출력 형식을 강제하지 않는다.
Innnteraction