POCU 노트

CLAUDE

8 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

---
aliases:
  - {H1과 동일한 한글 제목}
tags:
  - COMP2500
  - week{N}
---
  • aliases는 H1과 반드시 일치
  • tags의 weekN은 강의 주차

본문 구조

  • 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)

---
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과 일치하는지 확인

문제 풀이 문서 규칙 (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를 떠서 어긋난 지점을 습관 항목 후보로 제시

그래프 뷰