[1주차] 박규빈 학습 PR 제출합니다.

week1/[1주차] 박규빈.md

@@ -0,0 +1,82 @@
+## www.google.com을 치면 일어나는일
+
+- **DNS 조회**: 도메인을 IP 주소로 변환 (예: google.com → 172.217.0.0)
+- **TCP/IP 프로토콜**: 클라이언트와 서버 간 연결 및 데이터 전송
+- **WS (Web Server)**: 정적 콘텐츠 제공 (Apache, Nginx 등)
+- **WAS (Web Application Server)**: 동적 콘텐츠 처리 (Tomcat, JBoss 등)
+- 전체 과정: 브라우저 요청 → DNS → TCP 연결 → HTTP 요청 → 서버 응답 → 렌더링
+
+---
+
+## API, HTTP통신
+
+- **API (Application Programming Interface)**: 소프트웨어 간 상호작용을 위한 인터페이스 (예: REST API)
+- **HTTP통신**: 클라이언트-서버 간 데이터 교환 프로토콜
+  - 메서드: GET(조회), POST(생성), PUT(수정), DELETE(삭제)
+  - 상태 코드: 200(SUCCESS), 404(NOT FOUND), 500(SERVER ERROR)
+- 특징: 무상태(stateless), 요청-응답 기반
+
+---
+
+## 백엔드가 하는 일
+
+웹사이트나 앱에서 눈에 보이지 않는 서버, DB, API를 관리하는 파트를 개발하는 역할.
+
+- **서버 측 로직 처리**: 데이터베이스 관리, 비즈니스 로직 실행
+- **API 제공**: 프론트엔드와 데이터 교환
+- **보안 및 인증**: 사용자 검증, 데이터 보호
+- **성능 최적화**: 캐싱, 로드 밸런싱
+
+---
+
+## 객체지향 특징 및 장점
+
+프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체로 만들고, 객체들 간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법
+
+- **특징**
+  1. 추상화
+  2. 캡슐화
+  3. 상속
+  4. 다형성
+- **장점**
+  - 모듈화, 캡슐화로 인해 유지보수성↑
+  - 객체 자체가 하나의 프로그램 → 재사용성↑
+
+---
+
+## 코드 컨벤션이란
+
+읽고 관리하기 쉬운 코드를 작성하기 위한 규약
+
+1. 정해진 규칙이 있어 명칭이나 구조를 빠르고 정확하게 파악할 수 있음.
+2. 통일된 규약이 있어 모든 사람들이 코드를 이해하기 쉬움.
+3. 유지보수성 ↑
+
+- **네이밍 컨벤션**
+  - 카멜 표기법 : 소문자로 시작, 각 단어의 첫문자는 대문자 (예: mainFrame)
+  - 파스칼 표기법 : 대문자로 시작, 각 단어의 첫문자도 대문자 (예: MainFrame)
+  - 스네이크 표기법 : 각 단어 사이를 \_(언더바)로 구분 (예: main_Frame)
+  - 케밥 표기법 : 각 단어 사이를 -(구분자)로 구분 (예: main-frame)
+- **들여쓰기 컨벤션**
+  - Tab or Space (개발 환경에 따라 들여쓰기가 다르게 보일 수 있으므로 둘 중 하나만 사용)
+
+---
+
+## MVC 패턴
+
+- **Model**
+  Controller에게 받은 데이터를 수정 및 가공하는 역할을 수행한다. 즉, 데이터와 관련된 부분을 담당하며 값과 기능을 가지는 객체
+  - 편집 및 사용을 위한 모든 데이터를 가지고 있어야 함
+  - View나 Controller에 대해서 어떤 정보도 알 수 없어야 함
+- **View**
+  사용자 인터페이스 요소를 나타낸다. Controller에게 받은 Model의 데이터를 사용자에게 시각적으로 보여주기 위한 역할을 수행한다. 즉, 사용자에게 보여지는 화면
+  - Model이 가지고 있는 정보를 따로 저장해서는 안됨
+  - Model이나 Controller를 알고 있을 필요가 없음
+- **Controller**
+  Model과 View 사이에서 데이터 흐름을 제어한다. Method를 호출 → Service에서 비즈니스 로직을 처리 → 이후 결과를 Model에 저장 → View에게 전달하는 역할을 수행한다. 즉, Model과 View의 역할을 분리하는 요소
+  - Model이나 View에 대해서 알고 있어야 함
+  - Model이나 View의 변경을 알고 있어야 함
+
+- **장점** : 역할 분리, 유지보수성 ↑, 확장성 ↑
+
+---

week2/[2주차] 박규빈.md

@@ -0,0 +1,34 @@
+# 2주차 구현 회고
+
+## 프로젝트 개요
+로또 애플리케이션을 구현하면서 **입력 처리 → 도메인 모델링 → 당첨 판정 → 통계 계산 → 예외 처리** 흐름으로 기능을 완성했다.  
+요구사항 충족뿐 아니라, 테스트 가능성과 유지보수성을 높이는 방향으로 구조를 정리했다.
+
+## 구현 과정에서 학습한 내용
+- 콘솔 입력은 `Scanner`보다 `mission-utils`의 `Console.readLine()`을 사용하는 것이 과제 환경과 테스트 안정성에 적합했다.
+- 파싱/검증/도메인 책임을 분리하니 단위 테스트 대상이 명확해지고 디버깅 속도가 빨라졌다.
+- `Rank`를 `enum`으로 관리해 등수 조건과 상금을 한곳에 모으면서 분기 로직이 단순해졌다.
+- `Lotto`를 불변 객체로 설계(`List.copyOf`)하니 외부에서 리스트가 변경되어 생길 수 있는 변수를 예방할 수 있었다.
+- 예외 메시지 포맷(`[ERROR]`)을 일관되게 유지하니 사용자 피드백과 테스트 검증이 쉬워졌다.
+- 경계값(1, 45, 1000, 1000 단위) 중심 테스트를 먼저 작성하면 누락된 예외 케이스를 빠르게 발견할 수 있었다.
+
+## 구현 중 고민했던 점과 결정
+- `InputParser`의 책임 범위:  
+  파싱만 담당할지 고민했지만, 최종적으로는 **문자열 → 타입 변환 중심** 책임으로 제한하고 핵심 규칙 검증은 도메인에 두었다.
+- 패키지 구조:  
+  단일 패키지로 할 것인지, 역할 분리를 할 것인지 고민했고, 최종적으로 **`domain` / `view` / `parser` 분리**를 선택해 코드 탐색성과 테스트 가독성을 높였다.
+- `Lotto`의 유효성 검사 위치:  
+  생성자에서 번호 개수/중복/범위를 모두 검증하도록 해 잘못된 객체 생성을 원천 차단했다.
+- 당첨 판정 로직 표현 방식:  
+  `if-else` 체인을 늘리기보다 `Rank` 기준 메서드를 통해 판정해 조건 변경 시 수정 범위를 줄였다.
+- 커밋 전략:  
+  기능 단위 커밋을 목표로 했고, “입력/파싱”, “도메인”, “판정/통계”, “예외/출력”처럼 리뷰 가능한 단위로 나누는 기준을 세웠다.
+
+## 아쉬웠던 점
+- 통계 출력 포맷 테스트를 더 세밀하게 작성했으면 출력 회귀를 더 빨리 잡을 수 있었다.
+- 커밋 시점에 변경 파일 범위를 더 꼼꼼하게 관리했으면 히스토리가 더 깔끔했을 것 같다.
+
+## 다음 개선 아이디어
+- 예외 메시지/출력 문구를 상수 또는 메시지 객체로 분리해 재사용성과 일관성을 강화한다.
+- 입력 파싱 실패 케이스(공백, 잘못된 구분자, 중복 쉼표)를 표준화된 규칙으로 문서화한다.
+- 전반적인 입/출력 UI를 개선하고싶다.