CLAUDE.md · diff
git:20260908.c2ceb69 to git:20260909.563b19e
17 added, 62 removed. Audit A to A.
- # 이 저장소를 연 에이전트에게
+ # 이 저장소를 사용하는 AI 에이전트의 작업 규칙
- 이곳은 사회복지 현장 실무자의 바이브코딩을 돕는 판단 가이드 저장소입니다.
- 사용자가 만들고 싶은 앱을 이야기하면, 다음 순서로 일하세요.
+ 이 저장소는 사회복지 현장 실무자가 바이브코딩을 시작하기 전에 업무, 데이터, 윤리, 플랫폼, 운영 조건을 판단하도록 돕는 가이드입니다. 사용자가 만들고 싶은 앱을 설명하면 다음 순서로 진행하세요.
- 1. **guide.md를 먼저 읽으세요.** (단, 사용자가 앱 하나가 아니라 기관의 여러 양식과
- 업무를 통째로 정리하고 싶어 하면 form-audit.md를 먼저
- 안내하세요. 거기서 "앱 전환" 판정을 받은 양식만 guide.md의 대상입니다.) 그리고 그 문서의 순서를 그대로 따르세요.
- 절차 점검(관문) → 문진 → 데이터 등급 판정 → 플랫폼 추천 → 숙제 목록 순입니다.
- 플랫폼 이름부터 던지지 마세요.
- 2. **앱을 두 개 이상 만들 계획이거나 담당자마다 각자 파일로 관리하고 있다면**
- ssot.md(원본을 하나로)를 먼저 안내하세요. 이용자 명부를 원본으로 세우는
- 일이 앱보다 먼저입니다. 앱이 셋을 넘었거나 인수인계가 걱정이거나 기관 전체의
- 데이터 층·API·온톨로지를 이야기하면 levels.md(어디까지 갈 것인가)의 다섯 단계
- 가운데 어디인지부터 같이 봅니다. 위 단계가 좋은 단계가 아니라 기관에 맞는
- 단계가 좋은 단계라고 말하세요.
- 3. **사람을 기록하는 앱이면 ethics.md를 함께 펴세요.** 직원 근태·성과·위치,
- 생체정보(지문·얼굴), 이용자 감시가 걸린 앱이라면 관문에서 그 문서의 다섯
- 질문(목적 → 꼭 필요한가 → 덜 건드리는 길 → 누가 부담을 지나 → 자리 바꿔
- 보기)을 함께 따져 봅니다. **ethics.md는 막는 목록이 아니라 따져 볼 목록입니다.**
- 만들지 말라고 판정하지 마세요. 걸린 자리와 그래서 어떻게 하기로 했는지를
- DECISION.md에 적게 하고, 정하는 일은 기관에 맡기세요.
- 당사자(어르신·아동 등)가 직접 쓰는 화면을 설계할 때도 같은 문서의 "적정기술"을
- 먼저 보고, 디지털 길 하나만 남기지 않도록(종이·전화·대면 길) 안내하세요.
- 담당자 한 사람이 예산 없이 이 일을 다 떠맡고 있다면 그것도 같은 문서 5번이
- 다루는 자리입니다.
- 4. **당사자가 직접 쓰는 화면이면 design.md를 규칙으로 쓰세요.** 어르신·저시력·
- 저문해력 이용자가 쓰는 화면은 글자 크기와 터치 영역, 색 대비를 그 문서의
- 수치대로 정하고 시작합니다. 다 만든 뒤에 붙이면 다시 만들어야 합니다.
- 배포 전에는 그 문서의 확인 목록을 게이트로 쓰세요.
- 5. **종이로 내거나 엑셀로 주고받는 기록이면 print.md를 함께 펴세요.** 감사·결재·
- 지도점검은 종이로 받습니다. 표를 설계할 때 출력을 같이 정하고, 마지막에 붙이지
- 마세요. 기존 엑셀을 들여와야 하면 ssot.md의 이관 절차와 함께 봅니다.
- 6. **사용자는 개발 지식이 없다고 전제하세요.** 전문용어는 처음 나올 때마다
- glossary.md의 풀이로 한 줄씩 풀어 말하세요.
- 7. **경로가 정해지면** rules/ 폴더에서 해당 규칙 파일을 읽고, 에이전트형
- 작업이므로 rules/agentic.md도 함께 적용하세요. 특히 실제 이용자의
- 개인정보를 이 대화(컨텍스트)에 불러오지 않는 규칙은 예외 없이 지킵니다.
- S등급 기록을 AI에 보내는 앱이면 masking.md를 함께 펴세요. 가리는 코드부터 짜지 말고
- 지자체 협약·업체 계약(DPA)·동의서 ③④·처리방침 넷을 먼저 확인하게 하세요. 넷이 갖춰지면
- 가리지 않고 보내도 됩니다. **가리기는 의무가 아니라 선택입니다.** 반대로 가렸다고 동의가
- 면제된다고 말하지 마세요. 동의 여부 판정은 서버 쪽에 두고, 무료 등급 API는 쓰지 않습니다.
- 8. **판정이 끝나 만들 것이 정해지면, 이 폴더를 앱 프로젝트로 바꾸세요.**
- 순서대로 진행하되, 파일을 지우기 전에 사용자에게 한 번 확인합니다.
- - **판정 기록 남기기**: 삭제에 앞서 `DECISION.md`를 만들어 데이터 등급,
- 선택한 경로와 그 이유, 판정 날짜, 참고한 가이드 버전(저장소 주소)을
- 적습니다. 나중에 후임자나 감사가 "왜 이 스택인가"를 물을 때의 답입니다.
- 사람을 기록하는 앱이라면 ethics.md 다섯 질문에 뭐라고 답했는지도 적습니다.
- - **git 새로 시작**: 원격(origin) 연결을 끊고 새 저장소로 초기화합니다.
- 원 저장소로는 절대 push하지 않습니다.
- - **규칙 통합**: 선택한 경로의 rules/ 파일과 rules/agentic.md 내용을
- 이 CLAUDE.md(및 AGENTS.md)에 옮겨 앱 전용 규칙으로 만듭니다.
- - **골라서 삭제**: guide.md(판정은 끝났음)와 선택하지 않은 경로의 rules/
- 파일을 지웁니다. README.md는 이 앱의 소개로 새로 씁니다.
- - **남기기**: requirements.md(앱의 완성 기준으로 계속 사용), glossary.md,
- ethics.md(만든 뒤에도 기능을 더할 때마다 다시 볼 것),
- 당사자가 쓰는 화면이 있으면 design.md, 종이나 엑셀로 나가는 기록이 있으면 print.md,
- AI에 기록을 보내면 masking.md,
- 그리고 ops/ 가운데 이 앱에 해당하는 문서 — 인수인계 체크리스트는 항상,
- 개인정보를 다루는 앱이면 파기 대장과 동의서 문서도 남깁니다.
- 9. 앱을 운영에 올릴 때가 되면 ops/ 폴더의 문서들(인수인계 체크리스트,
- 파기 대장, 동의서 샘플)을 사용자에게 안내하세요.
+ 1. **`guide.md`를 먼저 읽고 순서대로 진행합니다.** 업무 절차의 필요성 확인, 요구사항 문진, 데이터 등급 판정, 플랫폼 선택, 실행 항목 정리 순서입니다. 처음부터 플랫폼을 추천하지 마세요. 사용자가 앱 하나가 아니라 기관의 여러 양식과 업무 전체를 정리하려는 경우에는 `form-audit.md`부터 안내하고, 앱 전환 대상으로 판정된 양식에만 `guide.md`를 적용합니다.
+ 2. **여러 앱과 중복 데이터가 있다면 `ssot.md`를 먼저 적용합니다.** 앱을 두 개 이상 만들 계획이거나 담당자마다 별도 파일로 이용자 정보를 관리한다면 이용자 명부를 단일 원본으로 정하는 작업이 앱 개발보다 우선입니다. 앱이 세 개를 넘었거나 인수인계, 기관 공통 데이터 레이어, API, 온톨로지가 논의되면 `levels.md`의 다섯 단계 중 기관에 필요한 범위를 먼저 결정합니다. 높은 단계가 항상 좋은 것은 아니며 기관의 요구와 운영 역량에 맞는 단계가 적절합니다.
+ 3. **사람을 기록하는 앱에는 `ethics.md`를 적용합니다.** 직원의 근태·성과·위치, 생체인식정보, 이용자 모니터링과 관련된 앱이라면 목적, 필요성, 덜 침해적인 대안, 부담을 지는 사람, 당사자 관점의 수용 가능성을 검토합니다. `ethics.md`는 개발을 일률적으로 금지하는 문서가 아니라 기관이 위험과 대안을 확인하도록 하는 문서입니다. 검토한 쟁점과 기관의 결정을 `DECISION.md`에 기록합니다. 당사자가 직접 사용하는 화면에는 디지털 방식 외에도 종이, 전화, 대면 절차를 제공하는지 확인합니다. 예산 없이 한 담당자에게 개발과 운영이 집중되는 문제도 함께 검토합니다.
+ 4. **당사자가 직접 사용하는 화면에는 `design.md`를 설계 단계부터 적용합니다.** 어르신, 저시력자, 저문해력 사용자를 고려해 글자 크기, 터치 영역, 색 대비를 문서의 수치에 맞춰 설계합니다. 배포 전에는 체크리스트를 통과 조건으로 사용합니다.
+ 5. **종이·PDF·엑셀로 제출하거나 교환하는 기록에는 `print.md`를 적용합니다.** 감사, 결재, 지도점검에 필요한 출력 요구사항을 데이터와 화면을 설계할 때 함께 정합니다. 기존 엑셀 데이터를 가져와야 한다면 `ssot.md`의 이관 절차도 적용합니다.
+ 6. **사용자는 개발 지식이 없다고 가정합니다.** 전문용어가 처음 나오면 `glossary.md`의 설명을 참고해 한 문장으로 풀어서 설명합니다.
+ 7. **플랫폼을 선택하면 해당 `rules/` 파일과 `rules/agentic.md`를 함께 적용합니다.** 실제 이용자의 개인정보를 에이전트의 대화 컨텍스트에 제공하지 않습니다. S등급 기록을 AI API로 보내는 앱에는 `masking.md`를 적용합니다. 마스킹 기능부터 구현하지 말고 지방자치단체 협약, AI 사업자 계약(DPA), 동의서 ③·④, 개인정보 처리방침을 먼저 확인합니다. 네 조건이 충족되고 사업자 계약이 해당 정보 처리를 허용하면 마스킹 여부는 기관이 결정할 수 있습니다. 마스킹했다고 동의가 면제되는 것은 아닙니다. AI 전송 동의 여부는 서버에서 확인하고 무료 소비자용 API나 챗봇에 기록을 전송하지 않습니다.
+ 8. **판정이 끝나고 개발 범위가 확정되면 이 폴더를 앱 프로젝트로 전환합니다.** 파일을 삭제하기 전에 사용자에게 삭제 범위와 남길 파일을 설명하고 확인받습니다.
+ - **판정 기록**: 먼저 `DECISION.md`를 만들고 데이터 등급, 선택한 경로와 이유, 판정일, 참고한 가이드 버전과 저장소 주소를 기록합니다. 사람을 기록하는 앱이면 `ethics.md`의 다섯 질문에 대한 답과 결정도 기록합니다.
+ - **Git 분리**: 기존 원격 저장소 `origin` 연결을 제거하고 앱을 위한 새 저장소로 초기화합니다. 원본 가이드 저장소에는 push하지 않습니다.
+ - **규칙 통합**: 선택한 플랫폼의 `rules/` 파일과 `rules/agentic.md`를 `CLAUDE.md`와 `AGENTS.md`에 반영해 앱 전용 작업 규칙으로 만듭니다.
+ - **불필요한 파일 삭제**: 판정이 끝난 `guide.md`와 선택하지 않은 플랫폼의 규칙 파일을 삭제합니다. `README.md`는 앱의 목적, 사용법, 운영 방법을 설명하는 문서로 다시 작성합니다.
+ - **필요한 문서 유지**: `requirements.md`, `glossary.md`, `ethics.md`, `ops/handover.md`는 유지합니다. 당사자가 쓰는 화면이 있으면 `design.md`, 출력이나 엑셀 교환이 있으면 `print.md`, AI API로 기록을 전송하면 `masking.md`, 개인정보를 처리하면 파기 대장과 동의 관련 문서도 유지합니다.
+ 9. **운영 배포 전에는 `ops/` 문서를 안내합니다.** 인수인계 체크리스트, 개인정보 파기 대장, 동의서 샘플 가운데 앱에 해당하는 문서를 실제 기관 정보로 작성하게 합니다.
- 가격·한도 같은 사실 정보는 2026년 8월 기준입니다. 웹에 접근할 수 있다면
- 중요한 수치는 최신 정보로 확인해서 바로잡으세요.
+ 가격, 한도, 서비스 정책은 2026년 8월 기준으로 작성되었습니다. 인터넷에 접근할 수 있다면 중요한 수치는 해당 사업자의 공식 문서에서 최신 정보를 확인한 뒤 수정하세요.