week-4-day-1-report주차 week-4-day-1-report일차 일일보고서

[4주차 1일] 오늘의 수업 이야기

날짜: 2025년 07월 07일

오늘의 주제

DDD 패턴과 레이어드 아키텍처 - 진짜 개발자처럼 설계하기

수업 진행 기록

4주차가 시작되었다. 주 강사가 화이트보드에 레이어드 아키텍처 다이어그램을 그리며 설명할 때, 학생들의 표정이 복잡해졌다. “왜 이렇게 복잡하게 나누나요?”라는 질문이 바로 나왔다.

지금까지 만든 Todo 프로그램은 모든 코드가 한두 개의 클래스에 몰려있었다. 이제 이것을 Presentation, Application, Domain, Infrastructure 계층으로 나누는 작업을 시작했다.

처음에는 반발이 있었다. “잘 돌아가는 코드를 왜 복잡하게 만드나”라는 의견이었다. 하지만 새로운 기능을 추가하거나 저장 방식을 바꿔야 할 때 얼마나 편해지는지 직접 경험하도록 했다.

Repository 패턴을 도입해 데이터 저장소를 추상화했다. 처음에는 메모리에 저장하다가 CSV 파일로 바꾸는 과정에서, 비즈니스 로직은 전혀 수정하지 않아도 되는 것을 보고 학생들이 놀라워했다.

의존성 주입(DI)의 개념도 실습했다. 생성자를 통해 필요한 의존성을 주입받는 방식이 처음에는 어색했지만, 테스트와 확장성 면에서의 장점을 설명하니 이해했다.

학생 상담 노트

• 레이어를 나누는 기준이 모호하다는 질문. 각 계층의 책임과 역할을 명확히 설명.
• Repository가 뭔지 이해가 안 된다는 경우. 데이터 저장소를 추상화한 인터페이스로 설명.
• 의존성 주입이 복잡해 보인다는 의견. 레고 블록처럼 조립하는 것으로 비유.
• YAGNI 원칙에 대한 질문. 필요할 때 만들되, 확장 가능하게 설계하라고 조언.

교육자 성찰

실무에서 사용하는 아키텍처 패턴을 가르치는 것은 도전이었다. 당장은 오버엔지니어링처럼 보일 수 있지만, 프로젝트가 커질수록 이런 구조의 장점이 드러난다.

학생들이 “왜?”라는 질문을 많이 했는데, 이것이 좋은 신호다. 맹목적으로 따라하는 것이 아니라 이유를 이해하려고 노력하고 있다.

코드가 복잡해 보이지만 각 부분의 책임이 명확해졌다. 이것이 좋은 설계의 시작이다.

메모

• 각 레이어의 책임 다이어그램 준비
• DI 컨테이너 라이브러리는 나중에 소개
• 실무 프로젝트 구조 예시 준비