메뉴
파일 단위 단일 책임 원칙(SRP)을 점검하고 리팩토링을 수행한다. "단일 책임", "책임 분리", "파일이 너무 크다", "이 파일 쪼개자", "/srp", "/srp 300", "/goal srp 300" 등으로 트리거된다. 숫자 인자는 import/export-from 라인을 제외한 LOC 기준의 후보 발견 하한이며, 목표 라인 수나 절대 분할 기준이 아니다. 파일명과 실제 구현 책임을 대조해 책임이 1개면 유지하고, 2개 이상이면 분리 계획을 표로 명시한 뒤 분리한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | srp |
| description | 파일 단위 단일 책임 원칙(SRP)을 점검하고 리팩토링을 수행한다. "단일 책임", "책임 분리", "파일이 너무 크다", "이 파일 쪼개자", "/srp", "/srp 300", "/goal srp 300" 등으로 트리거된다. 숫자 인자는 import/export-from 라인을 제외한 LOC 기준의 후보 발견 하한이며, 목표 라인 수나 절대 분할 기준이 아니다. 파일명과 실제 구현 책임을 대조해 책임이 1개면 유지하고, 2개 이상이면 분리 계획을 표로 명시한 뒤 분리한다. |
파일명이 말하는 목적과 실제 구현의 책임을 비교하여, 파일 단위 책임 경계가 맞는지 판단한다.
일반적인 "함수가 길다", "중복 코드", "300줄이 넘는다" 같은 코드 스멜 자체는 다루지 않는다. 이 스킬은 파일 단위의 책임 경계만 다룬다.
/srp 300, srp 300, /goal srp 300의 300은 후보 파일을 찾기 위한 LOC 하한이다.
반드시 지킨다:
300은 목표 라인 수가 아니다.300은 "모든 파일을 300줄 이하로 만들라"는 완료 조건이 아니다.300은 "300줄 이상이면 반드시 쪼개라"는 분리 기준이 아니다.정식 판정식:
| 실제 책임 수 | 판정 | 행동 |
|---|---|---|
| 1개 | 유지 | 파일을 쪼개지 않는다. 필요하면 유지 이유만 기록한다. |
| 2개 이상 | 분리 | 책임별 귀속 파일과 이동 방법을 표로 명시한 뒤 분리한다. |
| 판단 불가 | 보류 | @FIXME(srp) 또는 사용자 확인으로 판단 조건을 남긴다. |
사용자가 파일을 직접 지정하면 그 파일을 점검한다. 이 경우 숫자 하한과 무관하게 지정 파일을 분석한다.
사용자가 숫자를 함께 주면 그 숫자를 import/export-from 라인을 제외한 LOC 하한으로 사용한다.
숫자가 없고 파일도 지정되지 않았으면, 최근 수정된 소스 파일 맥락을 먼저 본다. 최근 변경 맥락이 없거나 판단하기 어려우면 300 LOC를 기본 하한으로 사용한다.
후보 추림은 예를 들어 다음처럼 수행할 수 있다. 프로젝트 언어에 맞게 확장자는 조정한다.
rg --files | rg '\.(ts|tsx|js|jsx|mjs|cjs|py|go|rs|java|kt|swift)$'
LOC 계산은 정확한 파서보다 빠른 후보 선별이 목적이다. 선별 후 실제 분석은 반드시 코드를 읽고 판단한다.
후보를 사용자에게 보여줄 때는 숫자 절감 목표처럼 쓰지 않는다.
| 파일 | LOC(import 제외) | 파일명이 말하는 목적 | 의심되는 책임 | 우선순위 이유 |
|---|---:|---|---|---|
| ____ | 342 | ____ | ____ | ____ |
아래 템플릿을 순서대로 채운다. 확실한 사실을 먼저 쓰고, 추론을 거쳐, 결론은 마지막에 도출한다. 결론을 먼저 정하고 근거를 끼워맞추지 않는다.
## 단일 책임 점검
파일: ____
LOC(import 제외): ____
파일명이 말하는 목적: ____
### 사실 수집 (코드에서 확인)
이 파일이 하는 일:
1. ____ (lines ____)
2. ____ (lines ____)
### 실제 책임 식별
| 책임 ID | 실제 책임 | 근거 lines | 파일명 목적과의 관계 | 독립 변경 이유 |
|---|---|---|---|---|
| R1 | ____ | ____ | 일치/부분/불일치 | ____ |
### 책임 수 판정
| 파일 | 실제 책임 수 | 판정 | 이유 |
|---|---:|---|---|
| ____ | 1/2/... | 유지/분리/보류 | ____ |
### 분리 계획 (분리 판정일 때 필수)
| 책임 | 현재 lines | 분리 파일명 | 옮길 코드 | 원본에 남길 코드 | 공개 API/export | import 갱신 | 검증 |
|---|---|---|---|---|---|---|---|
| ____ | ____ | ____ | ____ | ____ | ____ | ____ | ____ |
### 유지 판단 (유지 판정일 때 필수)
| 파일 | 유지 책임 | 유지 이유 | 다음 조치 |
|---|---|---|---|
| ____ | ____ | 책임 1개라 분리하지 않음 | 없음/주석/테스트 |
### 보류 (@FIXME)
| 책임 | 애매한 이유 | 판단 조건 |
|---|---|---|
| ____ | ____ | ____ |
채우는 순서:
판정의 확실함을 Cynefin 기준 3단계로 표기한다. 확신도가 행동을 결정한다. 애매하면 실행하지 않는다.
| 확신 | Cynefin | 의미 | 행동 |
|---|---|---|---|
| C | Clear | 책임 수와 귀속이 명백함 | 유지 또는 분리 실행 |
| K | Complicated | 분석하면 답이 나오지만 판단이 필요 | AI 판단 제시 + 사용자 확인 후 실행 |
| X | Complex | 옮겨봐야 아는 것 | 실행하지 않음. @FIXME(srp) 주석만 남김 |
Complex(X) 판정을 받은 책임은 코드에 주석으로 남긴다.
// @FIXME(srp): [애매한 이유] - 판단 조건: [언제 Clear가 되는가]
분리 실행 전에는 분석 결과와 분리 계획 표를 사용자에게 보여준다. /goal srp 300처럼 실행 목표로 들어온 경우에도, 목표는 "300줄 맞추기"가 아니라 "300줄 이상 후보에서 책임 경계를 판정하고 필요한 경우만 분리하기"다.
분리 판정이 Clear(C)이거나 사용자가 Complicated(K) 분리에 동의하면 리팩토링을 수행한다. 유지 판정이면 파일을 건드리지 않는다.
실행 원칙:
실행 순서:
@FIXME(srp) 주석을 삽입한다.검증은 프로젝트에 존재하는 명령을 우선 사용한다. 예: tsc --noEmit, pnpm typecheck, npm run build, eslint.
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.