bluewhale-korea 님의 블로그

스파르타코딩클럽 Spring 7기 본캠프 32일차(트러블 슈팅)

bluewhale-korea — Fri, 15 Nov 2024 13:50:53 +0900

오늘 진행한 학습 요약

1. Member 와 Schedule 을 Entity, RequestDto, ResponseDto, service, repository 로 스파르타코딩클럽 구현 과제로 진행하였다.

2. API 명세서 쓰기부터 구현까지 진행하려 했으나 난이도가 너무 높게 느껴져서 제대로 API 명세서 작성과 코드 구현을 제대로 하지 못했다.

학습 정리

Member와 Schedule 를 Create 하는 건 완성했지만 CRUD 전체를 완성하지 못했다. 필수 과제인 일정 CRUD, 유저 CRUD, 회원가입, 로그인(인증) 을 완성하지 못했다. 시간배분에 실패했다. 첫 3일 동안 강의를 수강했으나 이해하기가 어려웠다. 원래 계획은 강의를 완전히 다 수강한 다음 구현과제와 JPA를 구현하려 했는데 실패했다. JPA 를 완전히 익히기 위해 다시 강의를 보면서 개념정리를 하도록 해야겠다.

스파르타코딩클럽 Spring 7기 본캠프 31일차

bluewhale-korea — Thu, 14 Nov 2024 18:08:24 +0900

오늘 진행한 학습 요약

1. Spring 숙련 - 3주차 JPA

1) 객체와 관계형 데이터베이스 : 객체는 클래스를 통해 만들어지며 속성(field)와 기능(method)를 포함하며 관계형 데이터베이스는 데이터를 테이블 형식으로 표현하며 각 테이블은 열(column)과 행(row)으로 구성된다.

2) 패러다임 불일치 문제 1 : 객체에서는 상속과 다형성을 통해 객체 관계를 표현할 수 있지만 RDB는 이 개념을 직접 지원하지 않고 별도 매핑이 필요하다. 또한, 객체는 참조로 관계를 표현하고 RDB는 JOIN을 사용하여 관계를 결합한다.

3) 패러다임 불일치 문제 2 : 객체 지향 언어에서 데이터와 동작을 함께 캡슐화하는 방식과, RDB가 데이터를 정규화된 테이블에 관계 중심으로 저장하는 방식의 차이에서 발생한다. 이로 인해 객체를 데이터베이스에 저장하거나 조회할 때 복잡한 매핑과 변환이 필요해지고 코드의 복잡성과 개발자의 부담이 증가한다.

JPA

1) JPA : 객체 지향 프로그래밍 언어인 Java와 관계형 데이터베이스 간의 패러다임 불일치 문제를 해결하여 데이터베이스 작업을 객체지향적으로 수행할 수 있도록 지원한다. JPA의 사용 목적은 SQL 중심적인 개발에서 객체 중심으로 개발하기 위함에 있다.

2) hibernate.dialect : Hibernate가 사용하는 데이터베이스 방언(dialect)을 지정하는 설정으로 데이터베이스와 Hibernate가 상호작용할 때 특정 데이터베이스에 맞게 SQL 구문을 자동으로 조정하는 역할을 수행한다.

영속성 컨텍스트

1) 영속성 컨텍스트 : Entity 객체를 영속성 상태로 관리하는 일종의 캐시 역할을 하는 공간으로 여기에 저장된 Entity는 데이터베이스와 자동으로 동기화되며 같은 트랜잭션 내에서는 동일한 객체가 유지된다.

2) Entity : 데이터베이스에서 Entity란 저장할 수 있는 데이터의 집합을 의미한다.

3) Entity 상태 : 엔티티 상태는 비영속, 영속, 준영속, 삭제 상태로 나뉘며 영속 상태일 때만 JPA의 영속성 컨텍스트가 데이터를 관리한다.

4) 1차 캐시 : 엔티티를 영속성 컨텍스트에 저장할 때 생성되는 메모리 내 캐시이다. 엔티티는 먼저 1차 캐시에 저장되고 이후 같은 엔티티를 요청하면 DB를 조회하지 않고 1차 캐시에서 데이터를 반환하여 성능을 높일 수 있다.

5) 동일성 보장 : 동일한 트랜잭션 안에서 특정 엔티티를 여러 번 조회해도 항상 같은 객체 인스턴스를 반환한다. 영속성 컨텍스트는 1차 캐시를 사용하여 같은 엔티티를 중복 조회해도 동일한 객체를 참조하게 하여 일관성을 유지한다.

6) 쓰기 지연 : 엔티티 객체의 변경 사항을 DB에 바로 반영하지 않고 트랜잭션이 커밋될 때 한 번에 반영하는 방식으로 이를 통해 성능을 최적화하고 트랜잭션 내에서의 불필요한 DB 쓰기 작업을 최소화한다.

7) 변경 감지(Dirty Checking) : 영속성 컨텍스트가 엔티티의 초기 상태를 저장하고 트랜잭션 커밋 시점에 현재 상태와 비교해 변경 사항이 있는지 확인하는 기능이다.

8) flush : 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 기능으로, 변경된 엔티티 정보를 SQL로 반환해 데이터베이스에 동기화한다. 트랜잭션 커밋 시 자동으로 실행되지만 특정 시점에 데이터베이스 반영이 필요할 때 수동으로 호출할 수도 있다.

Entity 만들기

1) @Entity : 클래스에 @Entity가 있다면 JPA가 관리하는 Entity로 만들어진다.

2) hibernate.hbm2ddl.auto : JPA는 Application 로딩 시점에 DDL을 자동으로 생성하는 기능을 지원한다. 방언(dialect)을 사용하여 Entity Mapping만 하여도 데이터베이스에 맞는 적절한 DDL이 생성된다.

3) 제약조건 설정 : JPA를 사용하면 DDL 생성 시 제약조건을 설정할 수 있다. 실행 로직과는 별개로 DDL 생성시에만 활용된다.

4) 필드 매핑 : JPA로 관리되는 클래스인 Entity의 필드는 테이블의 컬럼과 매핑된다.

5) 기본 키 : JPA Entity를 생성할 때 기본키는 필수로 생성해야 한다.

연관관계 Mapping

1) 단방향 : 단방향 연관관계는 객체 간의 관계가 한쪽에서만 참조될 수 있는 관계를 말한다. 설정이 단순하고 유지 관리가 쉬우며 불필요한 데이터 접근을 방지할 수 있다.

2) 양방향 : 양방향 연관관계는 객체 간의 관계가 양쪽에서 서로를 참조할 수 있는 관계를 의미한다. 이를 통해 양쪽에서 데이터를 쉽게 접근할 수 있지만 관계를 관리할 때 한쪽에서만 연관관계를 설정하거나 삭제하지 않도록 주의가 필요하다.

3) 양방향 연관관계의 주인 : mappedBy는 JPA 양방향 연관관계 설정 시 사용되는 속성으로 두 엔티티 간의 관계에서 연관관계의 주인이 아닌 쪽에 선언한다. 이를 통해 외래 키 관리 책임을 주인 엔티티에 두고 매핑이 중복되지 않도록 한다.

스파르타코딩클럽 Spirng 7기 본캠프 30일차

bluewhale-korea — Wed, 13 Nov 2024 17:02:30 +0900

오늘 진행한 학습 요약

1. 숙련 Spring 2주차

- Cookie

- Session

- Token

- JWT

- Filter

Cookie, Session, Token을 알아보고 인증/인가에 대해 학습한다.

Servlet Filter를 사용하여 공통 관심 사항을 처리한다.

학습 정리

- Cookie : 사용자의 웹 브라우저에 저장되는 정보로 사용자의 상태 혹은 세션을 유지하거나 사용자 경험을 개선하기 위해 사용된다.

- Session : Cookie를 사용한 방식은 여러가지 보안 문제가 있다. 결국 보안 문제를 해결하려면 중요한 정보는 모두 서버에서 저장해야한다. Client와 서버는 예측이 불가능한 임의의 값으로 연결해야 한다.

* 서버에서 중요한 정보를 보관하며 로그인 연결을 유지하는 방법을 Session 이라고 한다. 앞서 배운 Cookie는 중요한 정보를 Client 측에서 보관하고 있는 것이다.

- Token : Web Application 이나 APi 인증(Authentication)과 인가(Authorization)과정에서 사용되며 사용자 또는 시스템의 신원과 권한을 증명하고 요청의 유효성을 검증하는 데 사용되는 디지털 문자열이다.

* Token을 사용하는 이유

1) Token은 서버가 아닌 클라이언트에 저장되어 서버의 부담을 덜 수 있다.

2) Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증을 처리할 수 없다.

3) Token 방식은 Stateless를 기반으로 하여 확장성이 뛰어나다.

4) 인증된 사용자임을 확인하기 위한 고유한 서명을 포함하여 위조된 요청인지 확인할 수 있다.

* Token의 단점

1) Cookie/Session 방식보다 Token 자체의 데이터 용량이 많다. - 요청이 많아지면 그만큼 트래픽이 증가한다.

2) Payload(전송되는 데이터)는 암호화되지 않아서 중요한 데이터를 담을 수 없다.

3) Token을 탈취당하면 대처하기 어려워 만료 시간(30분)을 설정한다.

- JWT(JSON Web Token) : JWT는 Base64로 인코딩되어 쉽게 복호화 할 수 있따. Payload가 그대로 노출되기 때문에 비밀번호나 민감한 정보를 저장하지 않는다.

* JWT 장단점

- JWT장점

1) Signature로 서버의 보안성이 증가한다.

2) Token 자체가 필요한 정보(유저 및 검증 정보)들을 모두 가지고 있다.

3) 서버는 인정 정보와 관련된 별도의 저장소를 사용하지 않는다.

4) 서버의 수평 확장성(Scale Out)이 높아진다.

5) Cookie가 없는 다른 환경에서도 인증/인가를 적용할 수 있다.

6) DB를 조회하지 않아도 된다.

- JWT단점

1) Payload는 암호화 된 것이 아니라 민감한 정보를 다루지 못한다.

2) Token의 길이가 길어서 트래픽이 증가하면 네트워크에 부하가 증가한다.

3) 클라이언트 측에서 Token을 관리하기 때문에 탈취당하면 대처하기 어렵다.

Access Token, Refresh Token

- Token은 클라이언트에서 관리하여 탈취당할 위험성이 높기 때문에 만료 시간 설정이 필요하다. 이때 발생하는 단점을 극복하기 위해 Access Token과 Refresh Token을 사용한다.

- Token의 유형

1) Access Token

- 사용자 인증 후 서버가 발급하는 유저 정보가 담긴 토큰이다.

- 유효 기간 동안 API 나 리소스에 접근할 때 사용한다.

2) Refresh Token

- Access Token은 보안을 위해 짧은 수명을 가진다

- AccessToken이 만료된 경우 재발급 받기위해 사용한다.

- 주로 데이터베이스에 유저 정보와 같이 저장한다.

- Filter : 공통 관심 사항(cross-cutting concerns), 같은 말로 횡단 관심사라고 하며 여러 위치에서 공통적으로 사용되는 부가 기능이고 Filter 가 나오게된 이유는 공통 관심사(Cross Cutting Concern)의 처리 때문이다.

- Servlet Filter : Servlet Filter는 보안, 로깅, 인코딩, 인증/인가 등 다양한 작업을 처리하기 위해 사용된다.

스파르타코딩클럽 Spirng 7기 본캠프 29일차

bluewhale-korea — Tue, 12 Nov 2024 18:01:00 +0900

오늘 진행한 학습 요약

1. 숙련 Spring 1주차

- Spring의 핵심 개념

- IOC/DI(제어의 역전, Inversion Of Control)

- 싱글톤 패턴

- Spring Bean 등록

학습 정리

1. Spring의 핵심 개념

- Spring으로 구성된 애플리케이션에서 객체(Bean)를 생성, 관리, 소멸하는 역할을 담당한다. 애플리케이션 시작 시, 설정 파일이나 Annotation을 읽어 Bean을 생성하고 주입하는 모든 과정을 컨트롤한다.

2. IOC(제어의 역전, Inversion Of Control)

- 객체의 생성과 관리 권한을 개발자가 아닌 Spring 컨테이너가 담당하는 것을 말한다. 기본적으로 개발자가 객체를 직접 생성하고 관리했지만, Spring에서는 컨테이너가 객체 생성, 주입, 소멸을 관리한다.

3. DI(의존성 주입, Dependency Injection)

- Spring이 객체 간의 의 존성을 자동으로 주입해주는 것을 의미한다. 한 객체가 다른 객체를 사용할 때, 해당 객체를 직접 생성하지 않고 Spring이 주입해주는 방식이다. IOC를 구현하는 방식 중 하나이다.

3. 싱글톤 패턴

- 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴이다.

- 싱글톤 패턴의 주의점 : 객체의 인스턴스를 하나만 생성하여 공유하는 싱글톤 패턴의 객체는 상태를 유지(stateful)하면 안된다.

4. Spring Bean 등록

- @ComponentScan : Spring이 특정 패키지 내에서 @Component, @Service, @Repository, @Controller 같은 Annotation이 붙은 클래스를 자동으로 검색하고, 이를 Bean으로 등록하는 기능이다. 개발자가 Bean을 직접 등록하지 않고도 Spirng이 자동으로 관리할 객체들을 찾는다.

1) 특정 패키지 내에 @Component Annotation 이 붙은 클래스를 자동으로 찾아서 Spring Bean으로 등록한다.

- Annotation을 이용해 Bean을 등록할 수 있어 코드가 간결해지고 유지보수가 쉬워진다.

2) 스캐닝 범쥐는 주로 애플리케이션의 루트(최상위) 패키지에서 시작된다.

3) @SpringBootApplication : SpringBoot로 프로젝트를 생성하면 main() 메서드가 있는 클래스 상단에 @SpringBootApplication Annotation 이 존재한다.

4) @ComponentScan의 동작 순서

1. Spring Application이 실행되면 @ComponentScan 이 지정된 패키지를 탐색한다.

2. 해당 패키지에서 @Component 또는 Annotation이 붙은 클래스를 찾습니다.

3. 찾은 클래스를 Spring 컨테이너에 빈으로 등록합니다.

4. 등록된 빈은 의존성 주입(DI)과 같은 방식으로 다른 빈과 연결됩니다.

스파르타코딩클럽 Spirng 7기 본캠프 28일차

bluewhale-korea — Mon, 11 Nov 2024 12:55:19 +0900

오늘 진행한 학습 요약

1. CH 3 일정 관리 앱 만들기 해설영상

- CURD 코드 작성 복습

학습 정리

1. CH 3 일정 관리 앱 만들기 해설영상

- CURD 코드 작성 복습해보기

1) 일정 생성 및 조회

- 일정 등록 API 구현

- 전체 일정 조회 API 구현

- 선택 일정 조회 API 구현

- 트러블 슈팅

- 문제

RowMapper 를 왜 이용하는가? 조회 결과를 내가 원하는 객체로 바꾼다.

2. 일정 수정 및 삭제

- 선택 일정 수정 API 구현

- 선택 일정 삭제 API 구현

-트러블 슈팅

- 문제

- 없음

스파르타코딩클럽 Spirng 7기 본캠프 27일차

bluewhale-korea — Fri, 8 Nov 2024 17:20:14 +0900

오늘은 과제 제출일이었다. 나는 일치감치 일정 관리 앱 필수 구현까지 끝냈다. 그리고 강의 5주차와 6주차를 복습했다. 왜 도전 과제를 진행하지 않았느냐는 말에는 기존 필수과제를 완전히 이해하지 못했기 때문에 강의를 보면서 이해도를 높이려고 했다고 할 수 밖에 없다. 그리고 실제로 어노테이션 사용하는 부분이 많이 약했는데 오늘 강의 5주차와 6주차를 다시 복습한 덕분에 이해도가 조금 높아졌다.

그러나 아직 완전히 이해한 것도 아니고 완전히 암기한 것도 아니다. 그래도 5주차와 6주차 강의를 복습하면서 안보이던 것들이 조금 씩 보였다. 어노테이션 사용법이라던가 HTTP 요청와 응답에 대한 이해가 높아진 것이다. 클라이언트와 서버와의 관계도 다시보이기 시작했고 400 Bad Request, 404 Not Found, 500 Internal Server Error 를 직접 구현으로 응답 할 수 있다는 사실도 깨달았다.

무엇보다 강의 5주차와 6주차 복습을 하면서 Entity, DTO, Controller, Service, Repository 간의 관계를 더 확실하게 기초를 다질 수 있었다. 특히 RequestDto 와 ResponseDto 에 대해 아리송 했는데 이번 공부로 HTTP 요청과 응답을 할 때 쓰는게 이 둘이라는 것을 확실하게 알 수 있었다. Controller 는 클라이언트가 웹 요청을 할 때 쓰는 어노테이션이고, Service 는 비즈니스 로직을 작성하는 어노테이션이고, Repository는 데이터베이스에 접근하는 어노테이션이라는 것, 그리고 Entity는 테이블을 만드는 어노테이션이며, DTO는 레이어간 데이터 교환을 위한 어노테이션이라는 걸 확실하게 알게 되었다.

앞으로 과제가 이런식으로 진행된다면 저 다섯가지 기본적인 어노테이션은 완전히 익힐 수 있을 듯 하다.

스파르타코딩클럽 Spirng 7기 본캠프 26일차(트러블 슈팅)

bluewhale-korea — Thu, 7 Nov 2024 17:45:27 +0900

오늘 일정 관리 앱 백엔드 과제를 완성했다. Lv2 까지 하고 강의를 들었다.

트러블 슈팅을 하자면 비밀번호 일치 여부 확인 문제가 가장 어려웠고 이태현 튜터님의 도움을 받았다. 문제를 명확히하자면 요청값에 비밀번호를 넣고, 데이터베이스에 저장된 비밀번호를 꺼내어 둘을 비교하여 같지 않으면 400 Bad request 에러를 내도록 해놓았다.

요청 값에 비밀번호를 넣는 부분은 어렵지 않았는데, MySQL 에서 저장된 비밀번호를 꺼내는 부분이 가장 어려웠다. JDBC 템플릿에 있는 queryForObject 쿼리를 사용하여 문제를 해결했는데 값을 String 형식으로 리턴하도록 해서 내가 원하는 비밀번호가 id 값에 의해 MySQL에서 검색되어 String 으로 가져왔다.

그리고 password(요청 값), 과 currPassword(MySQL응답 값) 을 비교해서 다르면 400 Bad request 에러가 뜨도록 만들고 같으면 코드를 계속 진행시켰다.

그 결과 잘 작동하는 걸 확인할 수 있었다. 오후 내내 이 문제를 붙잡고 있었는데 해결책을 찾아서 다행이라고 생각한다.

스파르타코딩클럽 Spirng 7기 본캠프 25일차

bluewhale-korea — Tue, 5 Nov 2024 19:27:22 +0900

오늘은 '일정 관리 앱' 백엔드 코딩 작업을 하는데 오전 시간을 썼다. 그런데 6주차 강의를 듣고 코딩을 했었어야 했다는 생각이 든다. 왜냐하면 DB 다루는 방법을 6주차 강의 때 실습으로 황원욱 튜터님이 가르쳐 줬기 때문이다. 아무튼 지금까지 작업한 부분을 많이 바꿔야 한다. '일정 관리 앱' 과제 제출일자는 금요일 오후 2시까지다. 시간 내에 다 할 수 있을지 모르겠지만 포기하지 않고 최선을 다해야겠다.

스파르타코딩클럽 Spirng 7기 본캠프 24일차

bluewhale-korea — Mon, 4 Nov 2024 20:36:21 +0900

오늘은 코딩을 많이했다. 오전에는 스프링 입문 5주차 강의를 들으면서 실습까지 했다. 그리고 실습한 걸 바탕으로 오후에는 백엔드 일정 관리 앱 만들기를 했다. 크게 어렵지는 않았는데 한 가지 문제가 있었고 해결한 방법을 이야기해보고자 한다.

문제는 요청으로 데이터를 줬는데 응답으로 데이터가 나오지 않는 문제였다. 이 문제는 응답 코드를 잘못 짜서 생긴 문제로 30분 정도 걸려서 해결했다.

프로젝트 규모가 작았기 때문에 쉽게 수정을 했지만 프로젝트 규모가 크다면 많이 헤메었을 것이라는 생각이 든다. 이번 프로젝트에서 디버거도 써봤는데 데이터는 똑바로 들어오는데 schedule 엔티티로 값이 들어가지 않는 문제였다. ScheduleResponseDto 에 Schedule 객체를 파라미터로 갖는 코드를 추가하고 this 명령어로 모든 필드 값을 삽입해주니 문제는 쉽게 해결 되었다.

어떻게 이 문제를 해결하지? 하고 고민하는 태도가 정말 중요하다고 생각되었다. 의문을 갖고 이건 왜 이럴까? 이 코드는 어떻게 동작하고 있는가? 하는 고민이 나를 조금씩 성장시켜주고 있는 것 같아서 좋았다.

스파르타코딩클럽 Spirng 7기 본캠프 23일차

bluewhale-korea — Fri, 1 Nov 2024 17:02:35 +0900

API 명세서 작성을 완료했다. 박성원 튜터님께 함격 판정을 받았다. 오전 내내 작업한 보람이 있었다. 요구사항(스파르타코딩클럽 과제 내용) 을 API 명세서로 만드는 단계는 설계 이후 직접 구현(코딩)하는 단계 전에 완료되어야 하는 단계로 시간을 많이 들여야 한다.

내가 만든 API 명세서는 개선할 점이 많지만 설계와 이후 구현에 있어서 선행자료로는 문제가 없는 것 같다. API 명세서는 핵심적인 내용만 정리하면 설계와 구현할 API 를 문서화하고 그에 대한 스펙을 적는 정도이다. 스펙이란 요청과 응답에서 어떤 값을 받느냐 정의하는 것인데 백엔드 과정이다보니 프론트엔드는 있다고 생각하고 API 를 명세서에 작성하는 정도 였다.

김순철 튜터님에게 어제 자주가서 몇 시간 동안 과외를 받다시피 했는데 그 과정이 나에겐 꼭 필요한 과정이었다. 요구사항에 대한 명세서를 작성함에 있어 '의문'을 가져야하고 왜 이런 요소가 필요한 지에 대한 깊은 고민이 필요했다. API 명세서를 작성하기 전 요구사항을 파악하는데 있어서 나는 약점을 가지고 있었는데 요구사항을 자세히 읽지 않고 내 마음대로 API 명세서를 작성하는 문제였다. 앞으로는 요구사항을 먼저 정확히 파악하고 API 명세서를 작성하고 설계 이후 구현까지 나아가는 과정을 명확히 할 필요가 있었다.

핵심은 이런 게 왜 필요한지 '의문'을 갖는 것이고 요소 하나하나가 필요한 이유에 대한 깊은 고민을 하는 것이었다. 이 단계를 튜터님에게 세 번이나 지적을 받았는데 쉽게 고쳐지지 않는 습관인 것 같다. 습관을 형성하는 데에는 66일이 필요하다는데 요구사항을 먼저 명확히 파악하는 일부터 습관을 들여야겠다. 무작정 API 명세서를 작성하면서 요구사항을 파악하기 보다는 요구사항을 명확히 파악하고 그 뒤 API 명세서를 작성하는 습관을 들여야한다. 어쨌든 하면 된다. 세상에 안 될일은 없다.