마크다운연습

💡 이 페이지 보는 법
왼쪽은 CLAUDE.md 파일에 실제로 입력된 마크다운 원문이고, 오른쪽은 깃허브나 AI 도구처럼 마크다운을 지원하는 환경에서 그 원문이 보이는 모습입니다. 이 위키는 마크다운을 직접 해석하지 않기 때문에, 오른쪽 화면은 같은 모양을 HTML로 재현한 것입니다.

① 문서 제목과 소개문 제목(#) · 문단
✏️ 입력 (.md 원문) # CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.	👀 결과 (렌더링 화면) CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.

② 강조 문단 굵게(**)
✏️ 입력 (.md 원문) **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.	👀 결과 (렌더링 화면) Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

③ 1번 원칙 제목(##) · 굵게 · 목록(-)
✏️ 입력 (.md 원문) ## 1. Think Before Coding **Don't assume. Don't hide confusion. Surface tradeoffs.** Before implementing: - State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - don't pick silently. - If a simpler approach exists, say so. Push back when warranted. - If something is unclear, stop. Name what's confusing. Ask.	👀 결과 (렌더링 화면) 1. Think Before Coding Don't assume. Don't hide confusion. Surface tradeoffs. Before implementing: State your assumptions explicitly. If uncertain, ask. If multiple interpretations exist, present them - don't pick silently. If a simpler approach exists, say so. Push back when warranted. If something is unclear, stop. Name what's confusing. Ask.

④ 2번 원칙 제목(##) · 굵게 · 목록(-) · 문단

✏️ 입력 (.md 원문) ## 2. Simplicity First **Minimum code that solves the problem. Nothing speculative.** - No features beyond what was asked. - No abstractions for single-use code. - No "flexibility" or "configurability" that wasn't requested. - No error handling for impossible scenarios. - If you write 200 lines and it could be 50, rewrite it. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

👀 결과 (렌더링 화면) 2. Simplicity First Minimum code that solves the problem. Nothing speculative. No features beyond what was asked. No abstractions for single-use code. No "flexibility" or "configurability" that wasn't requested. No error handling for impossible scenarios. If you write 200 lines and it could be 50, rewrite it. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

⑤ 3번 원칙 제목(##) · 굵게 · 목록 두 묶음

✏️ 입력 (.md 원문) ## 3. Surgical Changes **Touch only what you must. Clean up only your own mess.** When editing existing code: - Don't "improve" adjacent code, comments, or formatting. - Don't refactor things that aren't broken. - Match existing style, even if you'd do it differently. - If you notice unrelated dead code, mention it - don't delete it. When your changes create orphans: - Remove imports/variables/functions that YOUR changes made unused. - Don't remove pre-existing dead code unless asked. The test: Every changed line should trace directly to the user's request.

👀 결과 (렌더링 화면) 3. Surgical Changes Touch only what you must. Clean up only your own mess. When editing existing code: Don't "improve" adjacent code, comments, or formatting. Don't refactor things that aren't broken. Match existing style, even if you'd do it differently. If you notice unrelated dead code, mention it - don't delete it. When your changes create orphans: Remove imports/variables/functions that YOUR changes made unused. Don't remove pre-existing dead code unless asked. The test: Every changed line should trace directly to the user's request.

⑥ 4번 원칙 제목(##) · 굵게 · 목록 · 코드 블록(```)

✏️ 입력 (.md 원문) ## 4. Goal-Driven Execution **Define success criteria. Loop until verified.** Transform tasks into verifiable goals: - "Add validation" → "Write tests for invalid inputs, then make them pass" - "Fix the bug" → "Write a test that reproduces it, then make it pass" - "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: ``` 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] ``` Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

👀 결과 (렌더링 화면) 4. Goal-Driven Execution Define success criteria. Loop until verified. Transform tasks into verifiable goals: "Add validation" → "Write tests for invalid inputs, then make them pass" "Fix the bug" → "Write a test that reproduces it, then make it pass" "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

⑦ 맺음말 구분선(---) · 굵게
✏️ 입력 (.md 원문) --- **These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.	👀 결과 (렌더링 화면) These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

---

실습: 우리 팀 README.md 초안 쓰기

💡 README.md란?
깃허브 저장소에 들어갔을 때 가장 먼저 보이는 소개 문서입니다. 우리 팀 프로젝트가 무엇을, 어떤 데이터로, 어떻게 만드는지 처음 보는 사람에게 설명합니다.

아래 예시에서 왼쪽 원문의 기호가 오른쪽에서 어떻게 바뀌는지 확인합니다.

예시: 가상의 팀 README 제목 · 굵게 · 목록 · 링크 · 표 · 체크리스트
✏️ 입력 (.md 원문) # 서원지기: 조선 서원 배향 인물 지식그래프 ## 1. 프로젝트 소개 우리 팀은 **조선시대 서원 기록**을 바탕으로 서원과 배향 인물, 학맥의 관계를 지식그래프로 구축합니다. ## 2. 팀원 - 김가람 (사학과) — 데이터 수집 - 이나래 (국어국문학과) — 그래프 설계 - 박다온 (철학과) — 시각화·해석 ## 3. 데이터 출처 - [한국학자료센터](https://kostma.aks.ac.kr) ## 4. 그래프 설계 | 노드 | 주요 속성 | |---|---| | Person | name, birth, death | | Seowon | name, region | ## 5. 진행 상황 - [x] 데이터셋 선정 - [ ] 노드·관계 설계 - [ ] 중간발표 준비	👀 결과 (렌더링 화면) 서원지기: 조선 서원 배향 인물 지식그래프 1. 프로젝트 소개 우리 팀은 조선시대 서원 기록을 바탕으로 서원과 배향 인물, 학맥의 관계를 지식그래프로 구축합니다. 2. 팀원 김가람 (사학과) — 데이터 수집 이나래 (국어국문학과) — 그래프 설계 박다온 (철학과) — 시각화·해석 3. 데이터 출처 한국학자료센터 4. 그래프 설계 노드 주요 속성 Person name, birth, death Seowon name, region 5. 진행 상황 ☑ 데이터셋 선정 ☐ 노드·관계 설계 ☐ 중간발표 준비