Skip to content

study_log.md

Latest commit

 

History

History
464 lines (336 loc) · 29.4 KB

study_log.md

File metadata and controls

464 lines (336 loc) · 29.4 KB
Raw

Study Log — C# 게임 개발 과외

이 파일은 일일 과외 기록입니다. 각 수업 후 갱신합니다. 항목: 진도, 약점, 실수 패턴, 후속 수업에서 짚어줄 사항

진도 요약

Phase 주차 상태
Phase 1 (기초 문법) 1~6주차 ✅ 완료 (Gemini + Claude 병행)
Phase 2 (객체지향) 7주차 (클래스 기초) ✅ 완료
Phase 2 8주차 (접근제어/프로퍼티/네임스페이스) ✅ 완료
Phase 2 9주차 (상속/다형성) ✅ 완료
Phase 2 10주차 1~2일 (상속의 한계 / 컴포지션) ✅ 완료
Phase 2 10주차 1~3일 (상속의 한계 / 컴포지션 / 상속 vs 컴포지션) ✅ 완료
Phase 2 11주차 (인터페이스) ✅ 완료
Phase 2 12주차 1~3일 (구조체/값형참조형/얕은복사깊은복사) ✅ 완료
Phase 2 12주차 4일 (object 타입 / boxing·unboxing / struct+인터페이스 함정) ✅ 완료
Phase 3 진입 전 보강 접근 제한자 / static / 상속 키워드 / partial (2026-05-12) ✅ 완료
Phase 3 13주차 (static과 싱글턴 대안) ✅ 완료 (2026-05-13)

⚠️ 포맷으로 인해 기존 study_log 원본이 소실됨. 이 파일은 과거 대화 기록에서 복원한 것으로, 누락된 세부 사항이 있을 수 있음.

Phase 1 기록 (1~6주차)

Phase 1은 Gemini와 진행한 Day 3~7 + Claude와 재구성한 커리큘럼 기반. 개별 일차별 로그는 복원 불가하나, 확인된 약점은 다음과 같음.

확인된 약점 (Phase 1)

  • 스코프 실수: 반복문 밖에서 bool 변수를 선언해야 하는 상황에서 반복문 안에 선언하는 실수를 반복함. 2주차 커리큘럼에 이 약점을 명시적으로 다루는 항목이 포함됨.
  • 무한 루프 디버깅: Gemini와 진행한 Day 7 연쇄 번개 문제에서 무한 루프 이슈 발생. 카드 덱 관리 시스템에서 루프 탈출 조건을 잘못 설정한 사례.

7주차: 클래스 기초

수업 내용: 클래스 선언, 필드, 생성자, 메서드, 인스턴스 생성(new), List<Card> 활용, 참조 전달 개념 첫 접촉

핵심 학습 포인트

  • 병렬 배열 → 클래스 전환의 필요성을 이해함
  • new가 "메모리에 객체를 만드는 것"이고, 변수에 대입하는 것은 "이름표를 붙이는 것"이라는 개념을 이해함
  • 참조 전달: 클래스 인스턴스를 함수에 넘기면 원본이 전달된다는 점을 학습 (값 타입의 ref와 대비)

약점 / 주의사항

  • 없음 (이 시점에서는 특별한 실수 기록 없음)

8주차: 접근 제어 + 프로퍼티 + 네임스페이스

수업 내용: public/private, 프로퍼티(get/set), 자동 구현 프로퍼티, 네임스페이스

핵심 학습 포인트

  • public int HP { get; private set; } 패턴을 이해하고 적용함
  • POCU 코딩 표준의 m 접두사(private 멤버) 규칙 적용

약점 / 주의사항

  • 없음 (별도 실수 기록 미확인)

9주차: 상속과 다형성 ✅

수업 내용: 상속 기초, base 키워드, virtual/override, abstract, public/private/protected/sealed 구분, is/as 연산자, 패턴 매칭

핵심 학습 포인트

  • base(name, cost)에서 전달하는 것이 프로퍼티(Name)가 아니라 매개변수(name)라는 점을 질문 후 이해함
  • is 패턴 매칭: 검사 + 변수 선언을 동시에 하는 문법 이해
  • 이름 없는 객체 생성(Relics.Add(new AttackRelic())) 패턴을 이 시점에서 처음 인지함
  • virtual/override를 통한 다형성 구현 완료
  • abstract 클래스의 역할과 활용 학습
  • 접근 제한자 4종(public/private/protected/sealed) 구분 학습

약점 / 실수 패턴 ⚠️

  1. static 이해 부족 — 반복적 좌절 포인트

    • Main(static)에서 인스턴스 메서드를 직접 호출하려는 실수를 반복함
    • IdentifyRelic을 Relic 클래스의 인스턴스 메서드로 작성한 뒤, Main에서 객체 없이 호출하여 컴파일 에러 발생
    • "static 때문에 미치겠다"고 표현할 정도로 누적된 답답함이 있음
    • 해결: "static = 객체 없이 쓴다", "Main이 static이니까 Main에서 직접 부르는 메서드도 static이거나, 아니면 객체를 통해 호출해야 한다"는 규칙을 정리해줌
    • 후속 조치 필요: 13주차(static과 싱글턴 대안)에서 본격적으로 다루지만, 그 전에도 실습 코드 작성 시 static 관련 에러가 나면 "13주차 예습이다"라고 짚어주면서 반복 노출시킬 것

  2. 접근 제한자 혼란 (public / private / internal)

    • static과 함께 매 진도마다 발목을 잡는다고 표현함
    • 현재 단계에서는 "전부 public 쓰면 된다"로 단순화하여 부담을 줄임
    • 후속 조치: 프로젝트가 커지는 시점(10주차 이후)에서 자연스럽게 private의 필요성을 느끼게 유도할 것

  3. 메서드가 어느 클래스에 속해야 하는지 판단 미숙

    • IdentifyRelic을 Relic 안에 넣었는데, 실제로는 외부에서 판별하는 유틸리티 성격의 메서드였음
    • "이 메서드가 특정 객체의 상태를 쓰는가?" → Yes면 인스턴스 메서드, No면 static 또는 외부 클래스로 분리하는 기준을 제시함
    • 후속 조치: 10주차(컴포지션)에서 "어떤 로직이 어디에 속해야 하는가"를 설계 관점에서 다시 짚을 것

  4. new 없이 객체를 리스트에 넣을 수 있다는 사실을 모름

    • 항상 Type name = new Type() 패턴만 써왔기 때문에, list.Add(new Type())이 가능하다는 것을 9주차에서야 처음 인지
    • 심각한 문제는 아니지만, 표현식(expression)으로서의 new를 인식하지 못했던 것

10주차 1~3일: 상속의 한계 + 컴포지션 + 상속 vs 컴포지션 ✅

수업 내용: 상속의 한계(다중 상속 불가, 깊은 상속 트리), 컴포지션 개념 도입("has-a" 관계), List<Effect>를 활용한 효과 조합

핵심 학습 포인트

  • 다중 상속 불가 문제: "공격이면서 방어인 카드"를 상속만으로 만들 수 없음을 이해
  • 코드 중복 문제: 한 곳의 로직을 복붙하면 수정 시 누락 위험이 생긴다는 점을 스스로 도출
  • 깊은 상속 트리: 버그 추적 어려움, 코드 파악 불가 문제를 스스로 설명
  • 컴포지션 코드를 직접 타이핑하고 빌드·실행까지 완료
  • 컴포지션으로 독 효과 추가 문제 해결 — 각 효과가 단일 책임을 갖도록 분리하는 판단을 피드백 후 수정
  • List<Card>에 담아 반복문으로 Play() 호출하는 문제 해결

약점 / 실수 패턴 ⚠️

  1. 변수 선언과 초기화 분리 패턴 미숙

    • List<Effect> effects = new List<Effect>();(한 줄)만 써왔기 때문에, private List<Effect> mEffects;(선언만)이나 생성자 매개변수로 List<Effect> effects를 받는 패턴을 처음 봤을 때 혼란
    • int x;와 int x = 10;의 차이로 설명하여 이해시킴
    • 후속 조치: 이후 실습에서 선언과 초기화 분리 패턴이 나올 때 자연스럽게 반복 노출할 것

  2. "클래스 인스턴스가 값으로 전달된다"는 개념이 아직 완전히 체화되지 않음

    • "클래스가 변수가 될 수 있다는 개념이 안 잡힌다"고 표현
    • 직접 타이핑 후 어느 정도 와닿았으나, 완전히 체화되진 않은 상태
    • 컴포지션에서 객체가 다른 객체를 "들고 있는" 구조를 반복 접하면서 점차 익숙해지는 중
    • 후속 조치: 계속 반복 노출할 것

  3. () vs {} 혼동 (컬렉션 초기화)

    • new List<Card>(card1, card2)로 작성하여 빌드 에러
    • () = 생성자 호출, {} = 컬렉션 초기화라는 구분을 설명함
    • 후속 조치: 컬렉션 초기화 문법이 나올 때 자연스럽게 반복 확인

  4. base() 오해 — "끌어온다" vs "보낸다"

    • base(name)을 "부모의 name을 끌어다 온다"로 이해하고 있었음
    • 실제로는 "부모 생성자에 값을 보내서 처리시킨다"는 의미
    • 이 오해 때문에 base(name, "공격 카드")처럼 리터럴을 직접 보내는 게 가능하다는 걸 떠올리지 못함
    • 설명 후 이해함

  5. 생성자 매개변수 개수 불일치

    • AttackCard(string name, string cardType, List<Effect> effects) : base(name, "공격 카드")에서 cardType을 매개변수로 받으면서 동시에 base()에는 리터럴을 넣음
    • Main에서 2개만 넘기는데 생성자는 3개를 기대 → 빌드 에러
    • 불필요한 매개변수를 제거하여 해결

학습 과정 기록 ⚠️

  • 10주차 3일 문제(상속+컴포지션 조합)에서 수차례 포기 후 재도전을 반복함
  • 첫 시도: Effect에 값을 넘기는 방식에서 is로 타입 분기 → 컴포지션의 장점을 잃는 구조라는 피드백 받고 막힘
  • 수일간 파일을 열었다 닫기만 반복. 문제 자체를 축소하여 "공격 카드 1장만 만들기"부터 재시작
  • 단계별로 효과 추가 → 효과를 필드로 넣는 한계 직접 체험 → W10D2 방식(Effect가 자기 값을 보유)으로 회귀
  • base()의 의미 오해를 해소한 뒤 최종 완성
  • 교훈: 큰 문제에서 막히면 문제를 쪼개는 게 유효했음

진행 상태

  • 10주차 1일(상속의 한계): 개념 완료, 코딩 문제 스킵 (학생 판단 — 개념 이해 충분)
  • 10주차 2일(컴포지션): 개념 + 코딩 문제 2개 완료
  • 10주차 3일(상속 vs 컴포지션): 코딩 문제 완료 — 상속(카드 종류) + 컴포지션(카드 효과) 조합 구조 구현

11주차: 인터페이스 ✅

수업 내용: 인터페이스 선언/구현(I 접두사), 인터페이스 vs 추상 클래스, 다중 인터페이스 구현, 인터페이스를 매개변수로 사용

진행 상태

  • 11주차 1~4일: 개념 + 문제 풀이 완료
  • 세부 약점/실수 패턴 기록 없음 (세션 문제로 이전 대화 기록 유실)

12주차 1~3일: 구조체 + 값형/참조형 + 얕은복사/깊은복사 ✅

수업 내용: struct 선언/S 접두사/class와의 차이, stack vs heap 원리, 얕은 복사 vs 깊은 복사

학습 과정 기록

  • 12주차를 수 주간 회피한 뒤 재도전. struct 개념 자체가 어려워서 도망쳤다고 직접 언급함
  • 이번 세션에서 처음부터 차근히 재진입하여 1~3일 완주

핵심 학습 포인트

  • struct = 작은 데이터 묶음, 대입 시 값 전체가 독립 복사됨
  • 값형(struct) → stack, 참조형(class) → heap + 주소 복사
  • 얕은 복사: 참조형 필드는 주소만 복사 → 공유 상태
  • 깊은 복사: 새 객체를 만들어 내용 복사 → 완전 독립
  • 값형/참조형 예측 문제 4개 모두 정확히 맞힘 (이유 설명도 정확)

약점 / 실수 패턴 ⚠️

  1. 변수 가리기(shadowing) 규칙 오해

    • "this.를 붙이면 괜찮지 않나"라고 주장
    • POCU 표준의 shadowig 금지는 "구분 가능한가"가 아니라 "같은 이름이 두 스코프에 공존하는가"의 문제임을 설명 후 이해

  2. struct 생성자 없이 선언 시 필드 초기화 오해

    • SCardData cardDataNew; 선언 시 필드 초기화(= new KeywordList())가 실행된다고 잘못 이해
    • 필드 초기화는 new SCardData(...) 호출 시에만 실행됨을 설명

  3. S 접두사를 class에 오용

    • SKeywordList를 class로 선언하면서 S 접두사 사용
    • POCU 표준: S 접두사는 struct 전용

  4. += 오용 — 매개변수 수정

    • cardDataNew.CardName = cardData.CardName += "+" 패턴 사용
    • struct이므로 외부 영향은 없지만, 새 값을 만들 때는 + 연산자를 써야 함

  5. 기획 문서 요구사항 누락 — 독립성 검증 위치

    • Main에서 검증해야 할 키워드 추가를 UpgradeCard 내부에서 처리
    • 기획 문서를 꼼꼼히 읽는 습관 필요

12주차 4일: object 타입 + boxing/unboxing + struct+인터페이스 함정 ✅

수업 내용: object 타입 개념, boxing/unboxing 메커니즘, struct를 인터페이스에 담을 때의 함정 날짜: 2026-05-07 코딩 문제: 없음 (개념 이해 후 마무리)

수업 진행 특이사항

  • boxing 설명 도중 object 타입을 사전 설명 없이 등장시켜 학생이 혼란 → object 타입부터 먼저 설명 후 재진행
  • 후속 조치 필요: 개념 설명 순서를 더 꼼꼼히 점검할 것

핵심 학습 포인트

  • object는 C# 모든 타입의 최상위 조상. System.Object와 동일
  • 어떤 타입이든 object 변수에 담을 수 있으나, 꺼낼 때는 명시적 캐스팅 필요
  • boxing 3단계를 스스로 정확히 설명함: 힙 할당 → 값 복사 → 주소 저장
  • struct + 인터페이스: boxing 시 복사본이 생기므로 복사본 수정이 원본에 반영되지 않는 조용한 버그 발생
  • 실제 발생 지점: IHealable healable = player 같은 직접 대입보다 메서드 인자 전달, List 삽입 등에서 주로 발생

결론 / 실용적 정리

  • struct가 인터페이스를 구현해야 하는 상황이면 그냥 class를 써라
  • struct는 인터페이스 없이 순수 데이터 묶음(SDamageInfo 등)으로만 쓸 것

약점 / 실수 패턴

  • 없음 (개념 이해 수준에서 마무리, 문제 풀이 없었음)

13주차 진입 전 보강 학습 ✅

날짜: 2026-05-12 범위: 접근 제한자 / static / 상속 키워드 4종 / partial

배경

12주차 4일 종료 후 13주차 진입을 앞두고 학생이 자발적으로 보강을 요청. 학생 표현 그대로 옮기면 다음과 같음:

"static, public, private, virtual, partial, abstract, protected, override, new를 헷갈린다. 메서드든 인터페이스든 클래스든 그 '범위' 키워드가 나올 때마다 머리가 아파온다. IDE에서 오류/경고를 띄울 때마다 그냥 귀찮아서 전부 다 public, static을 붙이기 일쑤다."

→ 9주차 study_log에 기록된 "static 좌절"이 그대로 누적되어 있음을 학생이 자각. 13주차로 가기 전에 이 영역을 확실히 잡고 가기로 결정.

진행 방식

12문항 진단 퀴즈로 학생 약점 영역 정확히 파악 → 4단계로 분리해 보강 진행 → 단계마다 코드 진단 문제 풀이.

진단 퀴즈 결과 (보강 시작 전)

  • 확실히 안 것: public/private/protected 기본, sealed
  • 부분적으로 알았던 것: virtual/abstract의 큰 그림 (말하다 본인이 의심으로 무너뜨림)
  • 완전히 몰랐던 것: static 전반, override vs new, abstract의 정확한 규칙, partial, 종합 시나리오 분석

보강 단계별 결과

1단계: 접근 제한자

  • private/protected/public 정확한 의미 + 자식 클래스에서의 가시성 차이
  • 멤버에 붙을 때 vs 클래스에 붙을 때의 의미 차이 (학생 직접 질문)
  • m 접두사의 진짜 이유 (외부 알림용이 아니라 클래스 내부 가독성용 + shadowing 방지)
  • readonly + 백킹 필드 + 프로퍼티 패턴
  • 진단 코드: Review_AccessScopes/ReviewAccessScopes.cs

2단계: static

  • 본질: 객체에 속함 vs 클래스에 속함
  • Main이 static인 이유 (닭과 달걀 문제)
  • 호출 방향성의 비대칭: 인스턴스→static OK, static→인스턴스 X
  • static 클래스의 4가지 제약 (인스턴스화 불가, 모든 멤버 static, 상속 불가, 생성자 제한)
  • 일반 클래스 + 전부 static vs static 클래스 — 컴파일러 강제의 차이
  • 싱글턴 vs static 클래스 (POCU 41번): 싱글턴은 위장된 전역 변수
  • 싱글턴이 만들어진 역사적 배경 (Java/GoF 시대의 산물) — 학생 직접 질문 후 답변
  • 진단 코드: ReviewStatics/ReviewStatics.cs

3단계: virtual / override / abstract / new

  • virtual/override의 본질: 컴파일러가 결정 시점을 런타임으로 미루는 메커니즘
  • 다형성의 진짜 가치: List<Card> + foreach 패턴에서 같은 호출이 객체에 따라 다른 동작
  • 부모 타입 변수에 자식 객체 담기(업캐스팅) — 학생이 처음 본 패턴, 직접 질문하며 학습 (study_log 9주차 "list.Add(new Type()) 첫 인지"와 같은 결의 발견)
  • abstract: 자식 override 의무 + 인스턴스화 불가
  • abstract 클래스에 일반 멤버도 들어갈 수 있음 (C-4 사전 오해 정정)
  • "값이 다른가 vs 동작이 다른가" 판단 기준 정립 — 설계 의사 결정의 핵심 도구
  • new(메서드 숨김): 다형성 비활성, 변수 선언 타입에 따라 호출, 거의 안 쓰는 게 정상
  • 진단 코드 1: ReviewVirtualAbstract/ReviewVirtualAbstract.cs
  • 종합 진단: E-1 코드 (처음에 "하나도 모르겠음"이라 답한 문제) → 컴파일 에러 2개 + POCU 표준 28번 위반 1개 모두 본인 손으로 짚음

4단계: partial

  • 클래스 정의를 여러 파일로 분할
  • 실전 99%: 자동 생성 코드와 수작업 코드 분리 (WinForms/WPF/EF 등)
  • 학생이 직접 쓸 일은 거의 없음. "있다는 것만 알아두면 됨"

약점 / 실수 패턴 (이번 보강에서 발견)

  1. 1단계 회귀 — 두 번 발생, 매번 본인 손으로 정정 ⚠️

    • 새 개념(static, 상속 키워드)을 다룰 때 1단계 원칙(접근 제한자, readonly, 프로퍼티 패턴)이 일시적으로 흐려지는 현상
    • ReviewStatics.cs: 헬퍼 메서드 public으로 둠 / Name을 public 필드로 둠
    • ReviewVirtualAbstract.cs: 자식 클래스가 부모 멤버(mName/Name/mCost/Cost) 중복 선언
    • 후속 조치: 새 개념 진단 문제마다 1단계 회귀 여부 점검 필수. 이런 회귀가 학습의 단단함을 확인하는 정상적 과정임을 인지

  2. this.의 의미 오해

    • protected를 정당화하려고 this.BasicArmor를 도입. "각 인스턴스마다 다른 BasicArmor를 가져오는 메커니즘"으로 잘못 이해
    • 정정: this는 "현재 인스턴스를 명시적으로 가리키는" 키워드. 인스턴스 구분은 C# 메서드 호출의 기본 동작이며 this.가 만드는 효과가 아님
    • 후속 조치: 코드 리뷰 시 불필요한 this. 사용 확인

  3. 상속 시 자식이 부모 멤버 중복 선언 ⚠️ (9주차 "base() 오해"의 재발)

    • ReviewVirtualAbstract.cs 첫 제출에서 세 자식 클래스 모두 부모의 mName/Name/mCost/Cost를 다시 선언
    • base() 호출 후 자식 안에서도 같은 변수 추가 저장
    • 정정: 자식은 이미 부모 멤버를 상속받았음. 다시 선언할 필요 없음. base()가 부모에 저장, 자식은 그대로 사용
    • 이번에 더 깊이 잡힘. 9주차 약점의 결정적 정리

  4. override vs new의 시점 라벨 역전

    • 동작 자체("override는 자식 메서드 호출", "new는 변수 타입 보고 호출")는 정확히 인식
    • 그러나 "컴파일 시점 vs 런타임 시점" 메타 라벨이 거꾸로 묶임 (override를 컴파일 시점, new를 런타임 시점이라 답함)
    • 정정: override는 런타임(실제 객체를 봐야 하니까), new는 컴파일 시점(변수 타입만 보면 끝나니까)

  5. "값이 다르다" vs "동작이 다르다" 구분 미숙

    • Relic의 PrintName / OnTurnStart 사례에서 두 사례를 같은 카테고리로 묶음
    • 정정: 값만 다른 경우 → 일반 메서드 (부모에 정의 + 자식이 생성자에서 다른 값 주입) / 동작이 다른 경우 → virtual 또는 abstract
    • 이번에 정확한 판단 기준 정립

손에 들어온 판단 기준 (학생이 자력으로 결정 가능한 상태)

결정 항목 판단 기준
멤버의 접근 범위 필요 없으면 가장 좁게. 외부에서 부를 일 없는 메서드는 무조건 private
static vs 인스턴스 그 멤버가 객체 상태를 사용하는가? Yes→인스턴스 / No→static
static 클래스 vs 클래스 내 static 멤버 어떤 클래스와 의미적으로 묶이는가? 묶이면 그 클래스 안에 / 안 묶이면 별도 static 클래스로
virtual vs abstract vs 일반 메서드 자식마다 동작이 다른가? 다르면+부모 기본 동작 의미 있으면 virtual / 없으면 abstract / 동작 같으면 일반
자식 메서드 키워드 override(다형성 활성) vs new(다형성 비활성, 거의 안 씀)

학생의 성장 지표

  • 진단 퀴즈 E-1을 처음 풀 때: "이것도 하나도 모르겠네...."
  • 보강 후 동일 코드 진단: 컴파일 에러 2개 + POCU 표준 28번 위반 1개 본인 손으로 모두 짚음
  • 진단 퀴즈 C-3 처음: "ChildA, ChildB, ChildB" (오답, 본인이 찍었다고 인정)
  • 보강 후 동일 패턴 진단: 정답 + 추론 정확

진도 기록

  • 12주차 5일(버퍼)과 12주차 주말 과제(SDamageInfo 통합)는 학생이 명시적으로 스킵 결정
  • 13주차 진입 가능 상태 (오히려 13주차 핵심 개념을 이미 보강에서 다 다뤘으므로 실습 위주로 빠르게 통과 가능)

13주차 — static과 싱글턴 대안 ✅

날짜: 2026-05-13 진행 방식: 13주차 1~4일 개념은 2026-05-12 보강에서 모두 다뤘으므로 곧장 주말 통합 과제로 직행. 학생이 "B(13주차 진입)"를 명시적으로 선택.

통합 과제

과제 파일: ReviewTotalSystemTest/TotalSystem.cs

기획 명세 핵심 (static + 인스턴스 + 다형성 통합):

  • GameSettings (static 클래스): 게임 버전, 디버그 모드, 플레이어/몬스터 기본 체력
  • CombatLogger (static 유틸리티): 전투 로그 출력 + 누적 카운터 + 디버그 모드 ON일 때만 출력
  • Character (abstract): Player와 Monster의 공통 부모
  • Player/Monster (sealed): Character 상속, 생성자에서 GameSettings 값 사용
  • Main에서 List<Character> 다형성 활용 + 턴제 시뮬레이션

핵심 학습 포인트

  • static 도구(GameSettings, CombatLogger)와 인스턴스(Character/Player/Monster)를 한 코드에서 통합 다룸
  • 다형성: List<Character> + 부모 타입 변수 (Character player = new Player(...))
  • 상속 정석 패턴: 부모에 생성자 + 자식은 base() 위임 (3단계 보강 패턴 재적용)
  • 외부 읽기/쓰기 권한 분리: public static int TotalLogCount { get; private set; }
  • 디버그 모드 체크와 출력+카운트 묶기

발견된 회귀와 정정 ⚠️

보강 직후 첫 통합 과제에서 일시적 회귀 발생. 두 번째 라운드 정정에서 학생이 모두 본인 손으로 깔끔히 해결.

  1. 3단계 + 1단계 동시 회귀 (BUG-2/3): Character에 생성자를 두지 않고 자식 Player/Monster가 부모의 protected 멤버에 직접 대입

    • 1단계 영향: mName이 protected + readonly 누락 (자식이 직접 대입해야 했기 때문)
    • 3단계 영향: ReviewVirtualAbstract.cs에서 정확히 짰던 "부모 생성자 + base() 위임" 패턴이 일시적으로 흐려짐
    • 정정 후: Character 생성자 추가 → Player/Monster는 base() 위임 → mName private + readonly로 좁힘
    • 이번에 더 단단히 박힘. 다음 통합 과제에서 같은 회귀 가능성 낮음

  2. 명세 위반 (BUG-1): 디버그 모드 체크가 카운트만 감싸고 Console.WriteLine은 무조건 출력

    • 정정 후: 출력과 카운트 모두 if (IsDebugMode) 블록 안으로

  3. POCU 표기 위반 다수:

    • isDebugMode → IsDebugMode (부울 프로퍼티 Is 접두사)
    • static private → private static (한정자 키워드 순서)
    • AttackLog/DeathLog → PrintAttackLog/PrintDeathLog (동사+명사)
    • 멤버 등장 순서 정리

진단 퀴즈 재시도 결과 (2026-05-13)

처음(보강 시작 전) 진단 퀴즈 12문항을 보강 후 다시 풀이:

측면 처음 이번
완전 정답 2개 (A-1, A-2) 10개
부분 정답 2개 (A-3 거의, C-1 일부) 2개 (C-4, E-1)
모름/오답 8개 0개

처음에 "하나도 모르겠음", "전혀 모르겠음", "좌절" 표현이 붙어있던 영역들이 모두 학생 본인 말로 깔끔히 답해지는 상태. 외운 표현이 아니라 본인이 재구성한 표현 사용("static이면서 static이 아닌척 숨기기 때문에 나쁘다" 등).

미세 회귀 (메타인지 정상 작동):

  • C-4: abstract 메서드의 제약은 정확히 답했으나 abstract 클래스 자체의 인스턴스화 불가 제약 누락
  • E-1: 두 번째 컴파일 에러(CardFactory.CreateAttackCard에 static 누락) 놓침. 학생이 "억지로 찾은 느낌"이라 자각하고 다른 항목을 답함 — 메타인지가 정상 작동 중이라는 신호

진도 기록

  • 13주차 완료: 2026-05-13
  • 다음 진입 예정: 14주차 (제네릭) — ObjectPool<T>, where T : ... 등. 보강 학습에서 다루지 않은 새 영역. CLAUDE.md "학습 밀도 유지 지침"의 9개 요소 그대로 적용 필요.

후속 수업 시 주의사항 (튜터용)

항목 언제 어떻게
static 반복 노출 매 실습 시 2026-05-12 보강에서 정리됨. 학생이 자력으로 static 관련 판단 가능
접근 제한자 10주차 이후 2026-05-12 보강에서 정리됨. 캡슐화 원칙 손에 익음
메서드 소속 판단 10주차 2026-05-12 보강에서 정리됨. "이 로직이 누구의 책임인가" 판단 가능
변수 스코프 지속적 Phase 1에서 발견된 약점. 복잡한 중첩 구조에서 다시 나타날 수 있음
virtual/override 실습 9주차 완료 2026-05-12 보강에서 정리됨. virtual/override/abstract/new 4종 정확 구분
1단계 회귀 모니터링 매 진단 문제마다 새 개념 학습 시 접근 제한자/readonly/프로퍼티 패턴이 흐려지는지 점검. 보강 중 두 번 발생, 매번 본인이 정정. 이건 정상적 학습 현상이며 진단 시 짚어주면 즉시 회복됨
자식 클래스 작성 시 부모 멤버 중복 선언 상속 코드 작성 시 9주차 "base() 오해"의 재발. 2026-05-12에 더 깊이 정리되었으나 다른 형태로 재발 가능. 상속 코드 첫 제출 시 자식이 부모 멤버를 다시 선언하지 않았는지 확인
자기비하 표현 대응 학생이 좌절감 표출 시 "막연한 위로" 금지. 헷갈린 지점이 정확히 어디인지 짚어주는 현실적 진단으로 응대. 보강 중 한 번 발생 (3-2 abstract에서 "아무것도 모름" 표현). 짚어주자 즉시 회복

학생이 선호하는 학습 방식 (2026-05-12 발견)

이번 세션(2026-05-12)에서 학생 본인이 "지금까지 진행한 어떠한 학습보다 밀도 높고 유익하고, 가장 원하던 밀도의 학습이었다" 고 명시. Phase 3 전체 및 이후 모든 학습에서 이 방식 유지가 학생의 명시적 요청. 학생 평가: "Phase 1과 2에서는 이런 수준의 학습이 진행되지 않았다."

CLAUDE.md의 "학습 밀도 유지 지침"과 함께 참조할 것.

작동한 9개 핵심 요소 (모두 유지 필수)

  1. 단계 분리 — 한 단원을 3~4개 세부 단계로 분해. 학생이 "진행"이라 할 때만 다음으로. 한 응답에 하나의 세부 단계만.
  2. 이해 확인 루프 — 개념 설명 → 학생이 본인 말로 재설명 → 어긋난 부분 즉시 정정 → 통과 시 다음.
  3. 코드 진단 문제 형식 — 기획 명세 + 요구사항 + Main 시연 + 학생이 직접 결정할 것 + 진단 포인트(튜터만 알고 있음). 변수명/클래스 구조/시그니처 모두 학생 결정. 힌트 금지.
  4. QA 버그 리포트 피드백 — BUG-N + 위치 + 문제 + 기대 동작. 모든 POCU 표준 위반 짚기.
  5. 회귀 모니터링 — 새 단계 진단마다 이전 단계 원칙(접근 제한자, readonly, 프로퍼티 패턴) 점검.
  6. 옆길 질문도 본질로 연결 — 학생의 개념적 질문은 깊이 답변. 직감이 정답에 가까우면 분리해서 짚기. 역사적/언어 설계 배경도 충실히 답변.
  7. 답 알려주기 거부 — 학생이 명시 거부 시 끝까지. "못 찾은 게 있다"만 알림. "포기" 명시 시에만 답 제시.
  8. 자기비하 대응 — 막연한 위로 금지. 현실적 진단(헷갈린 지점이 어디인지)으로 응대.
  9. 느린 진행이 정상 — 한 개념을 깊이 파고드는 게 기본 모드. 가속 충동에 굴복 금지.

학생 측 작동 요소 (학생이 이미 잘 하는 것 — 유지)

  • 진단에서 솔직하게 "모름" 답하기 (방어 안 함)
  • 자기 말로 재설명 시도 (외운 표현 답습 안 함)
  • 막힐 때 본인 사고 과정 그대로 노출
  • 필요 시 "답 알려주지 마" 명시
  • 헷갈리는 영역을 자각하고 자발적으로 보강 요청

Phase 1, 2 vs 보강 세션의 결의 차이 (학생이 직접 언급)

학생이 "Phase 1, 2에서는 이 수준이 안 나왔다"고 했으나 구체 진단은 누락. 미래 세션에서 학생이 "이 부분은 Phase 1, 2 식이다"라고 짚으면 즉시 위 9개 요소를 점검하고 어느 요소가 빠졌는지 식별할 것.

⚠️ 복원 경고

이 문서는 2026년 3월 악성코드로 인한 PC 포맷 후, 과거 대화 기록에서 복원한 것입니다. 원본 study_log가 소실되었기 때문에 다음과 같은 한계가 있습니다.

  • Phase 1 (1~6주차)의 일일 로그는 복원 불가. 확인된 약점만 기재됨
  • 7~8주차의 세부 실수 패턴이 누락되었을 수 있음
  • 9주차 후반(virtual/override/abstract/sealed) 수업의 구체적 실수 기록 없음