카테고리

이 저장소는 규칙을 여러 벌로 복사해서 쓴다. AI 도구마다 읽는 파일 이름이 정해져 있어서다.

coding-standards/CLAUDE.md                        ← Claude 가 읽는다
coding-standards/AGENTS.md                        ← Codex 가 읽는다
coding-standards/.github/copilot-instructions.md  ← Copilot 이 읽는다

셋은 같은 내용이어야 한다. 실제로 README.md에 “같은 12줄이다. 하나를 고치면 셋을 함께 고친다“고 적어놨다.

그런데 세어보니 14 / 13 / 12 줄이었다.

CLAUDE.md   에만 있는 줄   nullable 표시 규칙, ErrorCode 도메인 세분화
AGENTS.md   에 없는 줄     nullable 표시 규칙
Copilot     에 없는 줄     둘 다

문서는 “같다”고 선언하는데 파일은 다르다. 같은 저장소가 도구에 따라 다른 규칙을 배포하고 있었고, 여러 번 배포하는 동안 아무도 못 봤다.

이 글은 그걸 닫으면서, 같은 모양의 어긋남이 두 개 더 있다는 걸 발견하고 셋을 함께 닫은 기록이다.

먼저: 이 저장소는 같은 실패를 이미 한 번 겪었다

.claude/skills와 .agents/skills도 두 벌이다. Claude와 Codex가 둘 다 스킬 방식이라 같은 파일을 복사해 둔다.

그 둘이 4개 어긋난 채로 배포된 적이 있다. 그래서 배포 스크립트가 인덱스 blob 해시를 대조하게 만들었고, 그때 이런 문장을 세웠다.

사람이 계속 기억해야만 지켜지는 규칙은 언젠가 깨진다. 깨질 수 있는 규칙은 기계로 옮긴다.

이번 것은 그 문장을 세워놓고도 같은 자리에서 또 났다. 스킬 두 벌은 검사 대상이었는데 「항상 적용」 세 벌은 아니었기 때문이다.

그래서 이번엔 두 줄을 채우는 것으로 끝내지 않는다. 채우면 다음 표준에서 또 벌어진다.

원칙 1. 「항상 적용」 세 벌 중 CLAUDE.md 하나만 손으로 고친다

정해야 했던 건 이거였다 — 셋을 무엇이 같게 유지하는가.

안 A — 배포 스크립트에 대조를 하나 더 붙인다

스킬 두 벌을 대조하듯 세 파일의 규칙 목록을 비교하고 다르면 멈춘다. 얻는 것은 기존 구조 그대로 몇 줄만 는다는 것이다.

버린 이유는 어긋난 뒤에 잡는다는 것이다. 그리고 배포할 때만 잡는다. 이번 사고가 정확히 그렇게 났다 — 이미 어긋나 있었고, 그 사이 배포가 여러 번 나갔다.

안 B — 새 소스 파일을 만들어 셋을 다 생성한다

_data/always-on.yml 같은 파일에 목록을 두고 세 파일을 뽑는다. 얻는 것은 셋이 대등해지고 어긋날 수가 없다는 것이다.

버린 이유는 그 소스가 배포에 안 실린다는 것이다. _data/는 이 저장소에만 있다. 그러면 다른 프로젝트에서 규칙 문제를 발견했을 때 고칠 대상이 눈앞에 없다. 원본이 어디인지도 모른다.

골랐다 — 안 C. 셋 중 하나를 원본으로 두고 둘을 생성한다.

coding-standards/CLAUDE.md                        ← 손으로 고친다
        │  ruby tools/always-on.rb
        ├─→ coding-standards/AGENTS.md                        생성물
        └─→ coding-standards/.github/copilot-instructions.md  생성물

안 A가 못 지켜주는 건 어긋남 자체를 없애는 것이고, 안 B가 못 지켜주는 건 원본이 배포에 따라가는 것이다. CLAUDE.md는 설치기가 다른 프로젝트에도 심는 파일이라, 원본으로 지정하는 것만으로 원본이 저절로 배포된다.

CLAUDE.md를 고른 이유는 두 가지다 — 표준을 쓰는 도구가 Claude라 규칙을 정하는 자리에서 바로 고쳐지고, 셋 중 배포 경로가 가장 확실하다.

대신 셋이 대등하지 않게 된다. “왜 Claude가 기준이냐”는 질문이 남는데, 위 두 줄이 답이다.

원칙 2. 생성기는 마지막 문단만 갈아끼운다

세 파일을 나란히 놓으면 머리와 규칙 목록은 같고 마지막 문단만 다르다.

CLAUDE.md   "해당 스킬을 읽고 근거와 예외를 확인한다"
AGENTS.md   ".agents/skills/ 의 해당 스킬을 읽고..."
Copilot     ".github/instructions/ 의 표준 파일에 있다. applyTo 로 자동 적용되므로..."

꼬리가 다른 건 정상이다. 도구마다 규칙 본문이 있는 위치가 다르니까. 그래서 생성기가 하는 일은 하나뿐이다.

CLAUDE.md에서 마지막 문단만 떼고 도구별 문단을 붙인다.

꼬리 셋은 생성기 안에 둔다. 규칙이 아니라 구조라서 거의 안 바뀌고, 데이터 파일로 빼면 배포 안 되는 파일이 또 하나 생긴다.

자르는 기준은 불릿이 아니라 마지막 빈 줄이다. 규칙 한 줄이 길어져 다음 줄로 이어지는 경우가 있는데, 불릿으로 자르면 그 이어진 줄을 잘라먹는다.

원칙 3. 생성기가 지금 파일을 재현하는지부터 확인한다

만드는 순서가 결과를 가른다.

빠진 두 줄을 채우면서 생성기도 같이 만들면, 결과 파일이 바뀌었을 때 왜 바뀐 건지 가릴 수 없다.

AGENTS.md 가 바뀌었다
   ├─ 내가 일부러 넣은 줄 때문인가
   └─ 생성기가 뭔가 잘못 만든 건가

그래서 나눈다.

  1. CLAUDE.md는 손대지 않고 생성기만 만들어 돌린다. 나온 변경은 전부 생성기 몫이다
  2. 그다음에 내용을 바꾼다. 나온 변경은 전부 의도한 것이어야 한다

실제로 돌렸더니 1단계에서 딱 세 줄이 늘었다 — AGENTS.md에 nullable 한 줄, Copilot에 그 줄과 ErrorCode 한 줄. 공백도 순서도 꼬리도 한 글자 안 바뀌었다.

원래는 “변경 0”을 기대했는데, 원본에 그 세 줄이 이미 있어서 돌리자마자 모순이 닫혔다. 검증 강도는 같다 — 예상한 것 말고는 아무것도 안 바뀌었으니까.

원칙 4. 생성물에는 생성물이라고 박고, 배포 전에 검사한다

생성기가 있어도 돌리는 걸 잊으면 어긋난다. 그리고 생성물을 손으로 고치면 다음 생성 때 날아간다.

그래서 두 겹을 둔다.

첫째, 파일 머리에 주석을 박는다.

# 코딩 스탠다드 — 항상 적용

<!-- 생성물 — coding-standards/CLAUDE.md 에서 tools/always-on.rb 가 만든다. 여기서 고치지 않는다. -->

주석으로 두는 이유는 이 파일이 다른 프로젝트에도 설치되어 그대로 읽히기 때문이다. 화면에는 안 보이면서 파일을 여는 쪽에는 보인다.

둘째, 배포 스크립트가 --check를 부른다. 검사가 둘에서 셋이 된다.

1. coding-standards/ 에 커밋 안 된 변경이 있는가
2. .claude/skills 와 .agents/skills 가 같은가
3. 「항상 적용」 세 벌이 최신 생성물인가   ← 새로 붙는다

실패 메시지가 중요하다. “생성기를 돌려라”라고만 하면 손으로 고친 사람이 그냥 돌려서 자기 수정을 날린다. 그래서 이렇게 찍는다.

손으로 고친 것이라면 그 내용을 먼저 coding-standards/CLAUDE.md 로 옮긴다.
그냥 다시 뽑으면 고친 내용이 사라진다.

생성기와 검사는 대체재가 아니라 층이 다르다. 생성기가 어긋남을 없애고, 검사가 “생성기를 안 돌린 것”을 잡는다.

원칙 5. 밀어내면 반드시 태그를 단다

여기서 두 번째 어긋남이 나왔다. 도구 사이가 아니라 시점 사이의 어긋남이다.

설치 스크립트가 보는 건 브랜치가 아니라 최신 vX.Y.Z 태그다.

밀어냈다            공개 저장소 main 이 바뀐다
태그를 안 달았다     최신 태그는 그대로다
다른 프로젝트        "이미 최신입니다" 하고 아무것도 안 받는다

밀어낸 게 아무 데도 안 간다. 그런데 스크립트는 성공으로 끝나서 아무도 모른다.

지금까지는 스크립트가 마지막에 “태그를 따로 단다”고 찍기만 했다. 안 달아도 안 멈췄다. 실제로 v1.1.0과 v1.2.0은 태그만 있고 릴리스가 없는 상태로 남아 있었다.

그래서 버전을 필수 인자로 바꿨다. 안 주면 시작조차 안 한다.

버전을 지정해야 한다. 현재 최신 태그는 v1.4.0 다.

    .\tools\publish-standards.ps1 -Version v1.4.1    (고침·문구 수정)
    .\tools\publish-standards.ps1 -Version v1.5.0    (표준 추가·규칙 변경)

검사를 맨 앞에 둔 게 의도다. 밀어낸 뒤에 물으면 이미 늦다 — main은 올라갔는데 태그가 안 붙은 어중간한 상태가 만들어진다.

원칙 6. 작업을 시작하기 전에 설치 버전을 최신 태그와 맞춘다

태그를 달아도 받는 쪽이 안 받으면 그대로다.

update 스크립트가 버전 비교를 하긴 하는데 돌려야 한다. 안 돌리면 뒤처진 줄 모른다.

v1.2.0 규칙으로 한 달치 코드를 쓴다
   → 나중에 올린다
   → 그 한 달치가 전부 표준을 벗어나 있다

포맷은 빌드가 잡지만 설계 규칙은 아무도 안 잡는다.

그래서 1단 「작업 방식」에 줄을 넣는다.

- 작업을 시작하기 전에 .coding-standards/manifest.json 의 version 과
  표준 저장소의 최신 태그를 비교한다. 뒤처져 있으면 먼저 올린다.

이게 “사람이 기억하는 규칙”으로 되돌아가는 것 아닌가 — 여기서 한 번 검문해야 한다.

아니다. 1단에 올리는 것 자체가 기계화의 한 형태다.

  언제 읽히나
문서에 적는다 사람이 기억해서 찾아 읽어야 한다
스킬에 적는다 모델이 부를지 판단한다. 안 부르면 안 읽힌다
1단에 올린다 판단 없이 매 요청에 들어온다

1단이 존재하는 이유가 정확히 이거였다.

다만 완전하지 않다. 읽는다고 반드시 실행한다는 보장은 없다. 세션이 시작될 때 훅이 자동으로 비교하는 게 더 낫지만, 그건 다른 프로젝트에서 도는 거라 여기서 시험할 수가 없다. 그래서 열린 항목으로 남긴다.

원칙 7. 사본에서 규칙을 고치지 않는다. 이슈로 올린다

세 번째 어긋남이다. 원본과 사본 사이다.

CLAUDE.md라는 이름의 파일이 세 곳에 있다.

블로그 저장소     ← 원본. 여기서만 고친다
      │ publish
공개 저장소       ← 복제본
      │ update
다른 프로젝트     ← 사본

화살표가 한 방향이다. 그래서 아래에서 고친 건 반드시 사라진다.

여기서 물어야 할 게 있다 — 그럼 다른 프로젝트에서 규칙 문제를 발견하면 어떻게 하나?

먼저 짚을 것은, 거기서는 표준을 고칠 수 없다는 것이다. 파일 권한 문제가 아니다.

표준 하나가 바뀌면 함께 움직이는 것

  글            ← 왜 그렇게 정했는가
  SKILL.md 두 벌
  instructions.md
  인덱스 데이터
  장부

다른 프로젝트에는 이 중 셋만 있다. 글이 없고 인덱스가 없고 장부가 없다. 거기서 CLAUDE.md 한 줄을 고쳐봐야 근거 없이 떠 있는 규칙이 된다.

아래로만 흐르는 건 제약이 아니라 “표준은 근거와 함께 움직인다”의 결과다.

그래서 위로 올라가는 건 코드가 아니라 정보다. 이슈로 남기고, 고치는 건 원본에서 한다.

이슈에는 장부에 없는 게 담긴다. 실제로 걸린 코드다. 장부의 항목은 “정하다가 발견한 빈틈”인데 이건 “써보다가 발견한 빈틈”이라 성질이 다르고 더 값지다.

버린 안 하나 — 방향을 뒤집는다. 공개 저장소를 진짜 원본으로 만들고 거기서 PR로 고친 뒤 subtree pull로 당겨온다. 얻는 것은 어디서든 고칠 수 있다는 것이고, 지금 문제가 통째로 사라진다.

버린 이유는 공개 저장소에 글이 없다는 것이다. 규칙만 고쳐지고 근거가 담긴 글은 안 고쳐진다. 글과 규칙이 어긋난 채로 배포되고, 어긋난 걸 아무도 못 본다 — 방금 닫은 사고를 더 큰 규모로 다시 만든다.

원칙 8. 이슈 주소는 manifest.json이 든다

“고치지 마라”만 적으면 막다른 길이다. 어디로 가라는 것까지 같이 적어야 한다.

지금 manifest.json에는 공개 저장소 주소만 있었다. 여기에 둘을 더한다.

{
  "repository": "https://github.com/TaegyuHan/coding-standards",
  "source": "https://github.com/TaegyuHan/TaegyuHan.github.io",
  "issues": "https://github.com/TaegyuHan/coding-standards/issues",
  "version": "v1.5.0"
}

이슈를 블로그 저장소가 아니라 공개 저장소에 여는 이유가 있다. 블로그 저장소는 공개고, 이슈에는 다른 프로젝트의 실제 코드가 붙는다. 남의 프로젝트 코드가 공개될 수 있다. 공개 저장소 쪽은 private이라 그 문제가 없다.

그리고 스킬에는 주소를 박지 않는다. manifest.json에서 읽으라고만 적는다. 박아두면 저장소가 옮겨갈 때 스킬이 거짓말을 한다.

이슈 첫 줄은 설치 버전이다. 없으면 이미 고친 문제인지 새 문제인지 가릴 수 없다.

판단 기준 정리

질문 답 왜
「항상 적용」 세 벌을 뭐가 맞추나 CLAUDE.md에서 둘을 생성한다 대조는 어긋난 뒤에 잡고, 생성은 어긋남을 없앤다
왜 새 소스 파일이 아닌가 그건 배포에 안 실린다 다른 프로젝트에서 고칠 대상이 안 보인다
생성기를 안 돌리면 배포 검사가 멈춘다 층이 다르다 — 생성은 어긋남을, 검사는 미실행을 막는다
태그 없이 밀어내면 시작조차 안 한다 밀어내도 받는 쪽엔 안 간다. 그런데 성공으로 끝난다
뒤처진 버전으로 일하면 1단이 매 요청에 비교하라고 말한다 스킬은 안 부를 수 있고 문서는 안 읽을 수 있다
사본에서 규칙 문제를 찾으면 이슈로 올린다 표준은 근거와 함께 움직이는데 거기엔 글이 없다
이슈를 어디에 여나 공개 저장소(private) 실제 코드가 붙는다. 블로그 저장소는 공개다

이 표준을 정하기까지

시작은 「항상 적용」 세 벌이 14 / 13 / 12 줄이라는 발견이었다. 커밋 전 대기 표준을 넣으려고 세 파일을 같이 열었더니 목록이 달랐다. README.md에는 “같은 12줄”이라고 적혀 있었다.

첫 판단은 “Copilot은 빼도 되지 않나”였다. Copilot에는 applyTo 경로로 규칙 본문을 자동으로 싣는 층이 따로 있으니, 1단이 짧아도 실제로는 받는다는 주장이 성립할 수 있었다. 확인해보니 정말 성립했다 — 빠진 두 줄 모두 applyTo: **/*.java인 파일에 들어 있어서 자바 파일마다 실린다. Codex 쪽만 진짜 구멍이었다. 스킬은 모델이 부를지 판단하니까.

그래도 셋을 같게 두기로 했다. 비대칭이 숨은 연결을 만들기 때문이다. Copilot만 짧게 두려면 “무엇이 빠져도 되는가”의 기준이 필요하고, 그 기준은 자연히 “그 표준의 applyTo가 **/*.java인가”가 된다. 그런데 applyTo는 좁혀진다 — README가 그렇게 하라고 적어놨고 실제로 좁힌 표준이 이미 있다. 좁히는 날 Copilot 1단에서 뺐던 줄이 다시 필요해지는데 그걸 아무도 안 본다. 절약되는 건 두 줄이고, 대가는 표준마다 판단이 하나 늘어나는 것이었다.

여기서 방향이 한 번 꺾였다. 나는 새 소스 파일(_data/always-on.yml)에서 셋을 다 생성하자고 제안했는데, 되물음이 왔다 — “그 1개의 문서도 같이 다니지 않으면, 다른 레포에서 문제를 발견했을 때 고칠 수가 없는 것 아니냐.”

맞았다. _data/는 이 저장소에만 있다. 다른 프로젝트에서 규칙 문제를 발견해도 고칠 대상이 눈앞에 없고, 원본이 어디인지도 모른다. 그래서 이미 배포되고 있는 CLAUDE.md를 원본으로 쓰는 안으로 바꿨다. 새 파일을 안 만드는 게 핵심이었다 — 원본으로 지정하는 것만으로 원본이 저절로 따라간다.

그러자 “그럼 다른 프로젝트에서 발견한 건 어떻게 올라오나”가 이어서 나왔다. 이게 세 번째 축을 열었다. 원본이 보인다고 거기서 고칠 수 있는 건 아니다 — 표준 하나는 글까지 여섯 파일이 함께 움직이는데 다른 프로젝트에는 셋만 있다. 아래로만 흐르는 게 제약이 아니라 “표준은 근거와 함께 움직인다”의 결과라는 걸 여기서 언어로 꺼냈다.

방향을 뒤집는 안도 검토했다. 공개 저장소를 원본으로 만들면 어디서든 PR로 고칠 수 있다. 버린 이유는 거기에 글이 없다는 것이었다 — 규칙만 고쳐지고 근거는 안 고쳐지면, 방금 닫으려는 사고를 더 큰 규모로 다시 만든다.

이슈를 어디에 열지에서 답이 하나로 좁혀졌다. 처음엔 작업하는 곳(블로그 저장소)이 낫다고 생각했는데, 이슈에 다른 프로젝트의 실제 코드가 붙는다는 걸 떠올리자 답이 뒤집혔다. 블로그 저장소는 공개다. 공개 저장소 쪽이 private이라 거기가 맞다.

중간에 두 번째 축이 따로 나왔다. 버전 얘기가 나온 건 “다른 프로젝트에서 어떻게 작업을 시작하나”를 따라가다가였다. 밀어내도 태그를 안 달면 받는 쪽엔 아무것도 안 가는데, 스크립트는 성공으로 끝난다. 실제로 v1.1.0·v1.2.0이 릴리스 없이 남아 있었다. 이것도 같은 모양이었다 — 사람이 기억해야만 지켜진다.

“1단에 한 줄 적는 것도 사람 기억 아니냐”를 스스로 검문했다. 아니었다. 1단은 사람이 찾아 읽는 문서가 아니라 AI가 판단 없이 매 요청에 읽는 파일이다. 스킬과의 차이가 정확히 그 지점이다. 다만 읽는다고 실행하는 건 아니라서, 훅으로 자동 검사하는 쪽은 열린 항목으로 남겼다 — 다른 프로젝트에서 도는 거라 여기서 잴 수가 없다.

만드는 순서에서 마지막 판단이 나왔다. 빠진 줄을 채우면서 생성기를 같이 만들면 결과 diff에 둘이 섞여 가릴 수 없다. 그래서 CLAUDE.md를 손대지 않고 생성기만 먼저 돌렸다. 딱 세 줄이 늘고 나머지는 한 글자도 안 바뀌었다 — 생성기가 맞다는 증거이자, 그 순간 모순이 닫힌 것이기도 했다.

정리

  • 「항상 적용」 세 벌 중 CLAUDE.md 하나만 손으로 고친다. 나머지 둘은 생성물이다
  • 원본은 배포에 실리는 파일이어야 한다. 안 실리면 다른 프로젝트에서 고칠 대상이 안 보인다
  • 생성기와 검사는 층이 다르다. 생성은 어긋남을, 검사는 생성기 미실행을 막는다
  • 밀어내려면 버전을 줘야 한다. 태그 없이 밀어내면 받는 쪽엔 안 가는데 성공으로 끝난다
  • 작업 전에 설치 버전을 최신 태그와 맞춘다. 뒤처진 규칙으로 쓴 코드는 나중에 전부 고쳐야 한다
  • 1단에 올리는 것은 문서에 적는 것과 다르다. 판단 없이 매 요청에 들어온다
  • 사본에서 규칙을 고치지 않는다. 표준은 근거와 함께 움직이는데 거기엔 글이 없다
  • 올라가는 건 코드가 아니라 이슈다. 그리고 이슈 첫 줄은 설치 버전이다

AI 코드 어시스턴트에 바로 적용하기

Claude Code — .claude/skills/standards-sync-standard/SKILL.md

---
name: standards-sync-standard
description: 코딩 스탠다드가 여러 벌로 퍼질 때 어긋남을 막는 규칙. CLAUDE.md·AGENTS.md·Copilot 지침·.claude·.agents·.codex·config 를 고치려 할 때, 설치 버전을 확인할 때, 규칙이 코드에 안 맞아 바꿔야 할 때 적용한다.
---

# 표준 동기화 표준

이 프로젝트의 표준 파일은 **사본**이다. 원본은 표준 저장소에 있고, 업데이트가 사본을 덮어쓴다.

## 작업을 시작하기 전에

- `.coding-standards/manifest.json`의 `version`과 표준 저장소의 최신 태그를 비교한다.
- 뒤처져 있으면 먼저 올린다.

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File .\.coding-standards\update.ps1
```

```bash
bash .coding-standards/update.sh
```

## 고치지 않는 것

아래는 설치기가 관리한다. 고치면 다음 업데이트가 덮어쓴다.

```
CLAUDE.md
AGENTS.md
.github/copilot-instructions.md
.github/instructions/
.claude/          .agents/          .codex/
config/formatter.xml
config/spotless-wrap-layout.gradle
.coding-standards/
```

- 이 경로 안에 프로젝트 고유 설정을 넣지 않는다.
- 로컬 예외 파일을 만들지 않는다. 프로젝트마다 규칙이 갈린다.
- 프로젝트 고유 규칙이 필요하면 관리 경로 **밖**에 둔다.

## 규칙을 바꿔야 하면 이슈로 남긴다

여기서 표준을 고칠 수 없다. 표준 하나는 글·스킬·지침·인덱스·장부가 함께 움직이는데 이 프로젝트에는 그 일부만 있다.

**이슈를 연다**

- 규칙이 이 코드에서 안 맞는다 (반례가 있다)
- 규칙이 없어서 판단할 수 없었다
- `CLAUDE.md`·`AGENTS.md`·Copilot 지침이 서로 다르다
- 문서와 실제 동작이 다르다

**이슈를 열지 않는다**

- 규칙이 마음에 안 든다 (반례 없이 취향)
- 이 프로젝트만의 예외가 필요하다

주소는 `manifest.json`의 `issues`에 있다. 스킬이나 문서에 적힌 주소를 쓰지 않는다.

```bash
gh issue create --repo <manifest.json 의 issues 저장소> --title "..." --body-file -
```

## 이슈에 적을 것

**설치 버전을 첫 줄에 적는다.** 없으면 이미 고친 문제인지 새 문제인지 가릴 수 없다.

````markdown
## 설치 버전
v1.4.0

## 어느 규칙
"<규칙 문장 그대로>" (CLAUDE.md 1단 / <표준 이름> SKILL.md)

## 걸린 코드
```java
// 실제로 문제가 된 코드
```

## 왜 안 맞나
<언제 무엇이 깨지는가>

## 제안
<있으면. 없으면 생략한다>
````

## 원본이 어디인가

```
표준 저장소       손으로 고치는 곳은 여기 하나다
      │ publish
공개 저장소       복제본. 여기서 고치면 다음 배포가 덮어쓴다
      │ update
이 프로젝트       사본. 여기서 고치면 다음 업데이트가 덮어쓴다
```

- 화살표는 한 방향이다. 아래에서 위로 올라가는 것은 코드가 아니라 **이슈**다.
- 표준 저장소에서도 손으로 고치는 파일은 `CLAUDE.md` 하나다. `AGENTS.md`와 `.github/copilot-instructions.md`는 거기서 생성된다.
- `manifest.json`의 `source`가 표준 저장소 주소다.

GitHub Copilot — .github/instructions/standards-sync-standard.instructions.md

---
description: 표준 파일은 사본이므로 고치지 않고 이슈로 남긴다
applyTo: "**/{CLAUDE,AGENTS,copilot-instructions}.md, **/.github/instructions/**, **/config/formatter.xml, **/config/spotless-wrap-layout.gradle, **/.coding-standards/**"
---

# 표준 동기화

- 이 파일들은 표준 저장소가 소유하는 **사본**이다. 고치면 다음 업데이트가 덮어쓴다.
- 관리 경로 안에 프로젝트 고유 설정을 넣지 않는다. 로컬 예외 파일을 만들지 않는다.
- 작업을 시작하기 전에 `.coding-standards/manifest.json`의 `version`과 표준 저장소의 최신 태그를 비교하고, 뒤처졌으면 `update` 스크립트로 먼저 올린다.
- 규칙을 바꿔야 하면 `manifest.json`의 `issues` 주소에 이슈로 남긴다. 주소를 문서에서 옮겨 적지 않는다.
- 이슈에는 설치 버전, 어느 규칙인지, 걸린 코드, 언제 무엇이 깨지는지를 적는다.
- 반례 없이 취향으로 이슈를 열지 않는다. 이 프로젝트만의 예외는 이슈 사유가 아니다.
- 표준 저장소에서 손으로 고치는 「항상 적용」 파일은 `CLAUDE.md` 하나다. `AGENTS.md`와 `.github/copilot-instructions.md`는 생성물이다.
자신만의 철학을 만들어가는 중입니다.
최상단으로 이동했습니다!
확대 이미지

댓글남기기

다른 포스트