2026-01-12

오늘 한 것

Discord Clone 프로젝트 - 도메인 모델링 (Entity) 설계 및 구현
상속(Inheritance)의 효율성 체감: BaseEntity를 만들어 공통 필드(id, createdAt, updatedAt)를 추출하고, extends를 통해 중복 코드를 제거하는 구조 학습
식별자(Identity)와 상태(State)의 분리: 시스템 식별용 UUID와 사용자 로그인용 username이 왜 분리되어야 하는지 유지보수 관점에서 이해
접근 제어자의 논리적 역할: private 필드는 데이터를 보호하기 위함이고, public Getter는 외부 서비스가 데이터를 식별하고 참조하기 위한 ‘공개 창구’임을 이해
생성자(Constructor)의 역할 재정의: 필수 데이터(final)는 생성자에서 강제하고, 선택 데이터(닉네임 등)는 필수는 아니지만 편의상 받을 수 있도록 설계

개념의 혼동: “로그인 ID가 있는데 왜 굳이 UUID를 또 만들어야 하는가?”에 대한 효율성 의문
보안에 대한 오해: “고유 ID를 public Getter로 열어두면 보안상 위험한 것 아닌가?”라는 접근 제어 범위에 대한 의문
문법적 오류 (Syntax Error): BaseEntity 작성 시 생성자(Constructor) 내부 블록 {} 안에 메소드를 작성하여 “메소드를 찾을 수 없음” 에러 발생
상속 문법: super()의 개념과 부모 생성자가 자동으로 실행되는 시점에 대한 이해 부족

시스템 vs 비즈니스 분리: UUID는 변하지 않는 ‘시스템 관리 번호(주민번호)’, username은 변할 수 있는 ‘사용자 입력값(개명)’으로 분리하여 관리해야 데이터 정합성이 깨지지 않음을 논리적으로 납득
Getter의 역할: ID는 수정(Setter)만 막으면 되며, 시스템 내부의 다른 객체(Service 등)가 식별하기 위해서는 조회(Getter)가 가능해야 함을 이해
코드 구조 수정: 생성자의 닫는 괄호 } 위치를 수정하여, 메소드들을 생성자 밖으로 독립시킴으로써 컴파일 에러 해결
Top-Down 학습: 완벽한 설계보다 User 엔티티 하나를 제대로 구현해보며 파생되는 필요성(BaseEntity 등)을 역으로 추적하는 방식으로 학습 효율 증대

BaseEntity.java: 공통 필드 추상 클래스 구현
User.java: 사용자 도메인 모델 구현
비전공자에겐 말도 안되는 진도와 과제이기 때문에 시간 관계상 ‘바텀업’을 미루고 ‘탑다운’을 결정. ai를 사용하여 코드 설계 후 해체 분석하는 방식으로 코드 흐름을 읽을 수 있게 됨