[17] 숙련주차 과제 (개념 부분 - 키워드 정리)

개인 과제 질문

 

1. 처음 설계한 API와 ERD에 변경사항이 있었나요? 변경되었다면 어떤 점 때문일까요? 첫 설계의 중요성에 대해 생각해보세요.

과제 레벨 1 까지만 구현했기 때문에 처음 설계한 API와 ERD에 큰 변경사항은 없었지만, 만약 레벨2로 넘어가야 했다면, 게시문의 댓글을 담당하는 Comment Entity를 하나 더 생성하고 FK를 이용해 게시글과 맵핑해주는 작업을 추가하는 수정이 필요했을 것 같다.

---

2. ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?

 

ERD(Entity Relationship Diagram)

• 엔티티와 이들 간의 관계를 알기 쉽게 약속된 도형을 이용하여 일목요연하게 그림으로 표현한 것이다.
• ER모델의 구성요소는 엔티티(Entity), 관계(Relationship), 속성(Attribute) 을 기본으로 하여 관계 수, 식별자, 서브타입 등으로 세분화 할 수 있다.
• 문장 형식의 업무 처리 규정을 약속된 도형 형태로 나타내어 전체 업무 및 데이터의 구조를 쉽게 파악할 수 있다.
• 문장으로 기술하지 않고 공통적인 약속을 통해 표현함으로써 업무의 파악과 이해가 용이하다.
• 데이터베이스를 구현할 때 정규화(Normalization)된 테이블을 만들기 위한 근거 자료로 활용한다.

---

3. JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?

1. 간편하다. 세션/쿠키는 별도의 저장소의 관리가 필요하다. 그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다. 이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이다. 여기서 Stateless는 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미. 이는 서버를 확장하거나 유지,보수하는데 유리하다.
2. 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. 예를 들어 Facebook 로그인, Google 로그인, 카카오 OAuth2 로그인 등은 모두 토큰을 기반으로 인증을 한다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있다.
3. 동시 접속자가 많을 때 서버 측 부하를 낮춰줄 수 있다.

---

4. 반대로 JWT를 사용한 인증/인가의 한계점은 무엇일까요?

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어갈 수 있다. 
2. Payload 정보가 제한적이다. 위에서 언급했다시피 Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. (세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관된다) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.
3. JWT의 길이. 세션/쿠키 방식에 비해 JWT의 길이는 길다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 된다. = 비용 증가
4. 구현의 복잡도가 증가한다.
5. Secret key 유츌 시 JWT 조작 가능하다.

---

5. 만약 댓글 기능이 있는 블로그에서 댓글이 달려있는 게시글을 삭제하려고 한다면 무슨 문제가 발생할까요? Database 테이블 관점에서 해결방법이 무엇일까요?

 

게시글에 달려있는 댓글 또한 동시에 삭제해야 한다. @OneToMany(cascade= CASCADE.REMOVE)를 사용하여 게시글이 삭제 될 때 그와 연관된 여러개의 댓글도 동시에 삭제되도록 해결할 수 있을 것 같다.

---

6. IoC / DI 에 대해 간략하게 설명해 주세요!

 

DI(Dependency Injection)

• DI(Dependency Injection)란 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능이다.
• 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다.
• DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아진다.

Ioc(Inversion of Control)

• IoC(Inversion of Control)란 "제어의 역전" 이라는 의미로, 말 그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다.
• IoC는 제어의 역전이라고 말하며, 간단히 말해 "제어의 흐름을 바꾼다"라고 한다.
• 객체의 의존성을 역전시켜 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있게 하여 가독성 및 코드 중복, 유지 보수를 편하게 할 수 있게 한다.

---

Spring 공통 질문

1. 스프링 프레임워크

[19] 스프링 프레임워크

[19] 스프링 프레임워크

 

2. 스프링에서 DI (의존성 주입) 를 사용하는 이유

[20] 의존성 주입 DI(Dependency Injection)

[20] 의존성 주입 DI(Dependency Injection)

---

3. ORM, JPA, Spring Data JPA 

[21] ORM, JPA, Spring Data JPA

[21] ORM, JPA, Spring Data JPA

---

인증, 인가의 차이

[18] 인증과 인가 (1) 세션/쿠키, JWT

[18] 인증과 인가 (1) 세션/쿠키, JWT

참고자료 : https://jake-seo-dev.tistory.com/76

---

절차지향 프로그래밍, 객체지향 프로그래밍, 관점지향 프로그래밍 

 

① 절차지향 프로그래밍 (Procedural Programming)

1. 컴퓨터가 해야 할 일을 시간의 흐름에 따라 순차적으로 프로그래밍하는 방식
2. 장점
   1. 객체나 클래스를 만들 필요 없이 바로 프로그램을 코딩할 수 있어서 시간적으로 유리하다.
   2. 필요한 기능을 함수로 만들어 두기 때문에 같은 코드를 복사하지 않고 호출하여 사용할 수 있다.
   3. 프로그램의 흐름을 쉽게 추적할 수 있다.
3. 단점
   1. 각 코드가 매우 유기성이 높기 때문에 수정하기가 힘들다. (새로운 데이터나 기능을 추가하기가 어려움)
   2. 프로그램 전체에서 코드를 재사용 할 수가 없어 프로젝트 개발 비용과 시간이 늘어날 수 있다.
   3. 유지보수 및 디버깅이 어렵다.

 

② 객체지향 프로그래밍 (Object-Oriented Programming)

• 데이터와 기능(함수)들을 묶어 하나의 객체로 만들어 진행하는 방식 / 하나의 사물 (객체) 에 하나의 의미를 부여하는 것처럼 프로그래밍

• 장점
  1. 모듈화, 캡슐화로 하드웨어가 같은 기능을 중복으로 연산하지 않도록해 유지보수에 용이하다.
  2. 모듈을 재활용 하기 때 문에 하드웨어의 처리양을 획기적으로 줄여줌.
  3. 객체지향적이기 때문에 현실 세계와 유사성에 의해 코드를 이해하기 쉽게 만든다.
  4. 객체는 그 자체가 하나의 프로그램이기 때문에 다른 프로그램에서 재사용이 가능하다.
• 단점
  1. 대부분의 객체 지향 프로그램은 속도가 상대적으로 절차지향보다 느려지고 많은 양의 메모리를 사용하는 경향이 있다.
  2. 설계 과정에 시간이 많이 투자된다.

 

③ 관점지향 프로그래밍 (Aspect-Oriented Programming)

1. 객체지향을 더욱 발전 시키기 위한 개념의 하나. 하나의 소프트웨어가 하나의 거대한 OOP로써 설계, 프로 그래밍 되었다면 이것을 각 기능별로 모듈화 해서 분리 시키는 개념.
2. 관점지향의 핵심은 공통 모듈을 분리시켜 해당 소스 코드가 외부의 다른 클래스에서 존재하는 것.
3. 장점
   1. 각 비즈니스 로직마다 복붙을 통해 생겨난 중복 코드가 사라진다.
   2. 각 비즈니스 로직을 구현하는 개발자는 자기 자신의 비즈니스 코드에만 집중할 수 있어 코드가 간결해지고, 유지보수가 쉬워진다.
   3. 재활용성이 더욱 높아진다.

• CORE CONCERN(핵심관심): 각 서비스의 핵심 비즈니스 로직예: 계좌이체, 입출금, 이자계산
• Crosscut Concern(횡단관심): 공통 모듈예: 보안, 예외처리, 로깅 등

•  

---

팀 질문 ( 키워드 5개)

생성자 자동완성 어노테이션

@NoArgsConstructor

기본 생성자를 생성해준다.

이 경우 초기값 세팅이 필요한 final 변수가 있을 경우 컴파일 에러가 발생함으로 주의한다.

@NoArgsConstructor(force=true) 를 사용하면 null, 0 등 기본 값으로 초기화 된다.

 

@RequiredArgsConstructor

final 변수, Notnull 표시가 된 변수처럼 필수적인 정보를 세팅하는 생성자를 만들어준다.

 

@AllArgsConstructor

전체 변수를 생성하는 생성자를 만들어준다.

 

참고 자료 : https://minji6119.tistory.com/44

---

영속성 컨텍스트란?

• 영속성 컨텍스트란 엔티티를 영구 저장 하는 환경 이라는 뜻
• 어플리케이션(자바 코드 그 자체)이 데이터베이스에서 꺼내온 데이터 객체를 보관하는 역할을 한다.
• 영속성 컨텍스트는 엔티티 매니저를 통해 엔티티를 조회하거나 저장할때 엔티티를 보관하고 관리한다.
• 엔티티 매니저마다 개별적으로 부여되는, 어떠한 논리적 공간같은 개념으로 비유적으로 이해할 수 있다.
• 자바의 엔티티 객체를 엔티티 매니저마다 가지고 있는 영속성 컨텍스트라는 공간에다 넣고 빼고 하면서 사용하는 것
• “영속화 한다” 라는 말을 “엔티티 매니저가 자기의 영속성 컨텍스트에 넣어준다”로 이해할 수 있다.

---

Refresh token과 Access token

 

Access Token(JWT)를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점입니다.

유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편합니다.

그러나 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됩니다. 

이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 "Refresh Token"입니다. 

해결법 

Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다(여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미입니다.) 

 

사용 예

Refresh Token의 유효기간은 2주, Access Token의 유효기간은 1시간이라 하겠습니다. 사용자는 API 요청을 신나게 하다가 1시간이 지나게 되면, 가지고 있는 Access Token은 만료됩니다. 그러면 Refresh Token의 유효기간 전까지는 Access Token을 새롭게 발급받을 수 있습니다. 

 

* Access Token은 탈취당하면 정보가 유출되는건 동일합니다. 다만 짧은 유효기간 안에만 사용이 가능하기에 더 안전하다는 의미입니다. 

 * Refresh Token의 유효기간이 만료됐다면, 사용자는 새로 로그인해야 합니다. Refresh Token도 탈취될 가능성이 있기 때문에 적절한 유효기간 설정이 필요해보입니다(보통 2주로 많이 잡더군요)

 

 

참고 자료 : https://tansfil.tistory.com/59?category=475681

---

JWT 장단점

장점

• 동시 접속자가 많을 때 서버 측 부하 낮춤
• Client, Sever 가 다른 도메인을 사용할 때 - 예) 카카오 OAuth2 로그인 시 JWT Token 사용

단점

• 구현의 복잡도 증가
• JWT 에 담는 내용이 커질 수록 네트워크 비용 증가 (클라이언트 → 서버)
• 기 생성된 JWT 를 일부만 만료시킬 방법이 없음
• Secret key 유출 시 JWT 조작 가능

---

느슨한 결합 / 강한 결합 

강한 결합

객체 내부에서 다른 객체를 생성하는 것은 강한 결합도를 가지는 구조이다. A 클래스 내부에서 B 라는 객체를 직접 생성하고 있다면, B 객체를 C 객체로 바꾸고 싶은 경우에 A 클래스도 수정해야 하는 방식이기 때문에 강한 결합이다.

 

느슨한 결합

객체를 주입 받는다는 것은 외부에서 생성된 객체를 인터페이스를 통해서 넘겨받는 것이다. 이렇게 하면 결합도를 낮출 수 있고, 런타임시에 의존관계가 결정되기 때문에 유연한 구조를 가진다.

강한 결합에서 느슨한 결합으로 바뀌는 것을 IoC(제어 반전)이라고 하고, SOLID 원칙에서 O 에 해당하는 Open Closed Principle 을 지키기 위해서 IoC를 한다고 생각할 수 있다.

*Open Closed Principle란 객체 지향의 5대 원칙 중 하나로, 확장에는 열려(Open) 있으나, 변경에는 닫혀(Closed)있어야 한다는 것을 의미한다. (유지 보수를 위해 처음부터 설계를 잘해야 한다는 의미인듯)