POCU 노트

CLAUDE

11 min read

COMP2500 문서 규칙

이 폴더의 강의 노트(index.md)는 아래 규칙을 따른다.

폴더 구조

COMP2500/
  {NNN}-{topic-slug}/                  # 섹션 (예: 006-object-modeling-2)
    {NNN}-{MMM}-{lesson-slug}/         # 레슨 (예: 006-007-change-time-with-carry)
      index.md
      images/
        {lesson-slug}-1.png
        {lesson-slug}-2.png
  • 섹션/레슨 폴더 이름: kebab-case 영문
  • 각 레슨은 자체 images/ 폴더를 가짐 (섹션 공용 image/ 폴더는 구식)
  • 이미지 이름은 {lesson-slug}-N.png 형태로 의미를 담음
  • 제목이 “코드보기: …”인 레슨은 폴더명을 항상 {NNN}-{MMM}-code-example로 통일 (구체 주제는 H1에만 표기, 이미지는 code-example-N.png). 같은 섹션에 여러 개면 레슨 번호로 구분

index.md frontmatter

---
title: {H1과 동일한 한글 제목}
aliases:
  - {H1과 동일한 한글 제목}
tags:
  - COMP2500
  - week{N}
---
  • title은 H1과 반드시 일치 — 파일명이 index라 이게 없으면 배포 사이트 제목이 “index”로 나옴 (Quartz는 title 없으면 파일명 사용, H1은 제목으로 안 씀)
  • aliases도 H1과 반드시 일치
  • tags의 weekN은 강의 주차
  • title에 콜론(:)·따옴표 등이 있으면 YAML 인용 필요 (예: title: '코드보기: 개체 비교')

본문 구조

  • H1: 한글 제목 (aliases와 동일)
  • H2: 소주제별 섹션
  • 강의 슬라이드 이미지를 먼저 배치하고, 그 아래에 정리된 텍스트 코멘트
  • 이미지 경로는 절대 경로 스타일: 
    ![](pocu-note/COMP2500/{section}/{lesson}/images/{name}.png)
  • 코드 블록은 ```java 사용
  • 본문·H2 제목에서 클래스명·메서드명·키워드 등 코드 식별자를 언급할 때는 backtick으로 감쌈 (예: equals(), HashSet, final)
  • 코드 식별자를 언급할 때 종류를 함께 명시: 메서드는 calculateDamage() 메서드, 변수는 hp 변수, 상수는 MAX_HP 상수, 클래스는 Monster 클래스, 키워드는 final 키워드
  • 다른 노트로 링크할 때는 전체 경로 + 표시 텍스트 형식 사용 (alias만 쓴 [[제목]] 형식 금지): 
    [[pocu-note/COMP2500/{section}/{lesson}/index|표시 제목]]
  • 설명은 짧은 불릿 위주, 보조 설명은 - 들여쓰기로 한 단계 더
  • 종결어미는 ~함, ~좋음, ~음 같은 명사형/축약형 사용

예시 (005-001-inheritance-intro/index.md)

---
title: 상속, 부모/자식 클래스 소개
aliases:
  - 상속, 부모/자식 클래스 소개
tags:
  - COMP2500
  - week4
---
# 상속, 부모/자식 클래스 소개
 
## 상속(inheritance)
 
![](pocu-note/COMP2500/005-inheritance/005-001-inheritance-intro/images/inheritance-intro-1.png)

마이그레이션 메모

  • 기존 006-xxx 등은 섹션 공용 image/img_XX.png 패턴을 사용 중 → 점진적으로 레슨별 images/ 구조로 이전
  • 마이그레이션 시: mv 사용 (cp 금지), aliases가 H1과 일치하는지 확인

ANKI 카드 규칙

  • 위치: anki/{NN}-{slug}.md — 번호는 기존에서 이어서 증가, frontmatter 없이 H1 한글 제목
  • 역할 분담: 서술 개념은 ANKI 카드, 코드 읽기/작성 문제는 801-exam 연습 문서
  • 노트 유형을 반드시 명시: H1 아래에 노트 유형: **Basic** 또는 노트 유형: **Cloze**
    • Basic: **앞면** / **뒷면** 섹션
    • Cloze: **Text** / **Back Extra** 섹션에 평문으로 작성 (코드 블록으로 안 감쌈 — 섹션 통째로 Anki에 복붙). {{c1::답}} 문법 사용, Anki에서 렌더링 안 되는 마크다운(백틱, ==강조==)은 넣지 않음. 출처 줄까지 Back Extra에 포함해서 붙여넣음
    • Cloze의 Text에서는 빈칸으로 물을 수 있는 내용을 최대한 빈칸(c2, c3, …)으로 물음 — 빈칸 수는 많아도 됨 (노트 하나에서 카드 여러 장 생성). 인출 대상이 아닌 보조 설명은 Back Extra에 넣음
    • 노트 유형 표기가 없는 기존 카드(1~13번 등)는 Basic으로 간주
  • 인출 대상(빈칸·앞면 질문)은 시험에 나올 만한 것만 — 기준은 801-exam/final-exam-info.md의 문제 유형(“어떤 개념에 대한 설명하기”)과 공부 주제 목록
    • 유래·잡학·여담(예: “C++에서 가져온 방법”, 이름 관습의 언어 습관)은 빈칸으로 뚫지 않음 — 문맥이 필요하면 평문이나 Back Extra로만
  • 앞면은 단일 인출 목표로 좁힘 — “~란 무엇인가?” 같은 광범위 질문 금지. 답의 형태가 정해지는 질문(정의 한 구절, N가지, 어떤 키워드)으로 작성
    • 사실·용어·표기 카드는 Cloze가 적합, 이유를 설명하는 카드는 Basic(Q&A) 유지
    • Cloze 빈칸은 구절 통째로 뚫을 것 (주변 문맥이 답을 흘리지 않게)
  • 마지막 줄에 출처 표기: 해당 레슨의 배포 사이트 URL (https://pocu-site.pages.dev/pocu-note/COMP2500/...)

문제 풀이 문서 규칙 (Assignment / Lab 공통)

풀이 과정 문서화의 목적은 해설 작성이 아니라 사고 습관 교정 피드백 루프임. 이 규칙의 배경 논의(각 결론에 도달한 질문과 논거)는 pocu-note/COMP2500/problem-solving-methodology.md 참고 — 방법론에 새 의문이 생기면 그 문서와 종합해서 수정할 것. 3층 구조를 따름:

  1. 탐험 일지 — 풀면서 기록 (주 산출물)
  2. 재구성 도출 — 풀고 나서 수행하는 정당화 감사 (리뷰 도구)
  3. 습관 로그 — 문제마다 누적, 유일하게 재독하는 문서

탐험 일지 지침 (풀면서)

  • 파편 불릿으로 기록, 다듬지 않음. 독자는 몇 시간 뒤 리뷰하는 나 자신뿐
  • 반드시 기록할 것:
    • 검증 전 예측: “X가 될 것 같음, 이유는 Y” — 나중에 실제 결과와 대조하는 핵심 피드백 신호
    • 결정 지점: 선택의 당시 이유 한 줄 (사후에 “옳은 이유로 옳았는지” 구분하려면 필수)
    • 막힌 지점: 뭘 시도했는지, 무엇이 뚫어줬는지 (스펙 재독? 예제 손추적?)
    • 외부(LLM 등)에 묻기 전 스냅샷: 시도한 것 · 최선의 추측과 이유 · 정확히 막힌 지점을 먼저 기록. 받은 답은 출처 표기하고 “출처 달린 가설”로 취급
  • 하지 말 것:
    • 사후에 논리적으로 보이도록 수정 (기록 오염)
    • 풀이 중 형식 다듬기 (사고 방해)

재구성 도출 지침 (풀고 나서)

  • 목적: 남기기 위한 문서가 아니라 정당화 감사(audit). 검증 대상은 스펙이고 내 풀이는 피고인
  • 뼈대는 4질문 (고정 순서 아님, 문제에 맞게 전개):
    1. 정의: 스펙 자연어의 애매함 제거 — 용어를 술어/수식으로, 시간 모델 고정
    2. 상태: 답이 입력만의 함수인가 이력의 함수인가 → 저장할 최소 상태(멤버 변수) 결정
    3. 불변식: 매 단위 작업 후 유지할 성질 하나 → 코드는 그 성질을 복구하는 최소 행동, 자료구조는 필요한 연산 집합에서 도출
    4. 검산: 조건 배타성 · 경계 케이스 · 스펙 예제 추적
  • 감사 규율:
    • 모든 단계에 그것을 강제하는 스펙 문장 인용을 요구. 못 대면 “도출”이 아니라 “선택”으로 표기하고 대안 나열
    • 갈림길마다 기각된 후보와 기각 이유를 명시 (기각 이유를 말 못 하면 검증이 아니라 사후 합리화)
    • 파괴적 연산(삭제·덮어쓰기·상태 전이)마다 “미래에 다시 필요 없음을 무엇이 보장하는가?” — 보조정리 소환 트리거
    • 재구성과 코드가 충돌하면 코드가 짐 (코드에 맞춰 논리를 구부리지 않음)
    • 외부에서 빌린 단계도 면제 없음 — 스펙에서 직접 재도출해야 내 것이 됨
  • 리뷰: 일지의 실제 사고 경로와 도출의 논리 경로가 어긋난 지점 = 습관 버그
    • 막힌 원인 분류: 지식 갭(습관 아님, ANKI행) / 도구 미사용(습관 버그) / 정의 애매함 방치(습관 버그)
    • 외부에 물었던 경우 “묻지 않았어도 무엇이 뚫어줬을까?”를 함께 물음

습관 로그

  • 위치: pocu-note/COMP2500/habit-log.md (없으면 생성)
  • 리뷰에서 나온 항목을 문제마다 누적, 다음 문제 시작 전에 읽고 시작
  • 같은 항목이 반복 등장하면 진짜 습관, 한 번 나오고 재발 없으면 삭제 — 짧게 유지

Claude의 역할

  • 풀이 중 힌트 요청 시: 정답 대신 단계적 힌트(놓친 스펙 문장, 던져야 할 질문) 우선
  • 탐험 일지는 다듬거나 재구성하지 않음 (기록 오염 금지)
  • 리뷰를 도울 때: 일지와 도출의 diff를 떠서 어긋난 지점을 습관 항목 후보로 제시

그래프 뷰