[WIL] 7주 차 회고

배운 점

• 팀 프로젝트를 진행하며 API와 DB 테이블 설계에 대한 경험을 쌓았다.
• 첫 화면에 들어갔을 때 어떤 데이터들을 화면에 필요한지를 생각해서 보내줄 수 있도록 구현했다.
• CRUD 기능을 다시 한번 구현해보며 REST API에 대한 익숙함이 생겼다.
• 별생각 없이 어노테이션을 가져다 사용했었는데, 자세히 알고 사용하는 게 아니라면 문제가 발생할 수도 있다는 것을 깨달았다.
• Spring version 4부터 등장한 @RestController는 @Controller + @ResponseBody의 조합인 것을 알게 되었다.
• 컨트롤러 클래스에서 반환 값을 문자열로(ex. return "index.html")해서 그 html로 넘어가기 위해서는 @RestController가 아닌 @Controller만 작성해서 처리해줘야 한다는 것을 알게 되었다.

---

• 인증(Authentication)과 인가(Authorization)의 차이점
  • 인증: 사용자의 신원을 확인하는 행위 (ex. 로그인을 통해 본인임을 확인)
  • 인가: 사용자의 권한을 확인하는 행위 (ex. 회원 등급 별로 접근 가능한 게시판 권한 확인)

인증과 인가

---

• 쿠키와 세션
  • HTTP는 상태를 저장하지 않기 때문에(Stateless) 사용자를 구별하지 못한다.
  • 그렇기 때문에 쿠키와 세션을 사용해서 HTTP에 상태 정보를 유지(Stateful)하게 한다.
  • 즉, 쿠키와 세션을 통해서 서버에서는 클라이언트 별로 인증 및 인가를 할 수 있게 된다.
  • 쿠키: 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일
  • 세션: 서버에서 일정 시간 동안 클라이언트 상태를 유지하기 위해 사용
    • 서버에서 클라이언트 별로 유일무이한 '세션 ID'를 부여한 후 클라이언트 별 필요한 정보를 서버에 저장

• 위 그림에서와 같이 서버는 세션 ID를 사용해서 세션을 유지한다.
  • 1. 클라이언트가 서버에 1번 요청
  • 2. 서버가 세션 ID를 생성하고, 응답 헤더에 전달
    • 세션 ID 형태: "SESSIONID = 12A345"
  • 3. 클라이언트가 쿠키를 저장 ('세션 쿠키')
  • 4. 클라이언트가 서버에 2번 요청
    • 쿠키값(세션 ID)을 포함하여 요청
  • 5. 서버가 세션 ID를 확인하고, 1번 요청과 같은 클라이언트임을 인지한다.

 

• 세션을 사용하면 좋은데 왜 쿠키를 사용할까?
  • 세션은 서버의 자원을 사용하기 때문에 무분별하게 만들다 보면 서버의 메모리가 감당할 수 없게 되거나 속도가 느려질 수 있기 때문이다.

---

• 스프링 시큐리티: 스프링 서버에 필요한 인증 및 인가를 위해 많은 기능을 제공해 줌으로써 개발의 수고를 덜어준다.
• 마치 스프링 프레임워크가 웹 서버 구현에 편의를 제공해주는 것과 같다.
• @Secured를 통해 인가 처리를 하는 것을 확인할 수 있었다.

---

느낀 점

미니 프로젝트를 진행하며 정신없이 한 주가 지나갔다.

아직 스프링과 DB에 대해서도 확실하게 개념을 이해하지 못한 부분이 많다고 느껴진 한 주였다.

멘토링 때 물어보니 추상화하여 이해한 후 차차 구체화시키는 방식으로 지식을 습득했다는 이야기를 들었고, 나도 핵심적인 내용들 먼저 알고 차차 확장시키는 방식으로 진행할 계획이다.

또, 잠을 줄이며 하는 것보다 초반에 했던 것처럼 매일매일 꾸준히 하는 것이 능률적이고 생활 패턴도 유지하기 좋다는 것을 깨달았다.

이번에도 참 좋은 팀원분들을 만나서 더욱 열심히 할 수 있는 계기가 되었고 앞으로 프로젝트를 잘 마무리하기 위해 부단히 노력해야겠다.