우리 fisa 2기 '클라우드 서비스 개발' 13주차

개발하는지호 2024. 2. 18. 21:32

연휴의 후유증을 달고 이제서야 회복이 되고 있는 요즘

ㅋㅋㅋㅋㅋㅋ
매번 말하지만 !! 시간이 정말로 빠르다 ~~ 이제 찐으로 3개월이 넘어가고 있다!
프론트앤드에 이어 백엔드 과정까지 마무리 되었다. 이제 클라우드, 리눅스 등이 남았는데
새로운거 들어간다니 기분이 좋다!

일상 얘기

연휴 마지막날 나의 어릴적 친구를 만났다! 초등학교 1학년 때 부터 알고 지낸 관계인데(무려 22년이나 된 오래된 친구이다 ㅋㅋ), 이 친구가 곧 결혼을 한다... !!
현재 이 친구는 서울에 살고 있지만, 많은 친구들이 부산에 있어 청접장을 위한 모임을 부산에서 했다.
오랜만에 친구들을 보며 지나간 세월의 흔적들이 보인다. ㅋㅋ
결혼한 친구도 엄청 어렸었는데. 지금은 결혼을 한다고 분주하다니,, 그리고 그 친구의 동생도 완전 애기였는데 벌써 28살이라니,, (자기는 26살이라고 주장을 한다 ㅋ) 깨닫지 못하고 있던 세월의 흐름이 피부 표면으로 느껴지는 하루였다.

다들 바빠서 연락을 자주 못했지만, 그래도 웬만하면 어떠한 상황이고 뭘하고 있는지 안다 ㅋㅋ 우리보다 부모님들이 훨씬 친하기 때문이다.
그래서 그런지 오랜만에 봐도 전혀 어색한거 없이 여러 얘기를 했다. ~~(나 많이 잘생겨졌다고 칭찬도 했따 ㅎㅋ)~~

그냥 간단히 점심만 먹고 헤어질 줄 알았던 오래된 친구들과 밤 9시 까지 술을 마시며 놀았다 ㅋㅋㅋㅋㅋㅋ

그리고 13일 새벽 나는 ktx를 타고 바로 상암동의 우리 fisa에 왔다 ㅎㅎ,,

그래서 그런걸까..? 속이 완전 안 좋았고, 여태 우리fisa에 오면서 속 안 좋았던 적은 없었는데 이날 최악의 컨디션을 만났다 ㅠㅠ
소화도 안 되고 그러니 집중도 안 되고 완전히 난리였다. 그래서 점심을 먹고 저 소화제를 구매해서 먹었다..

그래도 소화제를 먹고 난 뒤, 조금 회복이 되었던 걸까 ? 점차 회복을 하더니 그날 저녁도 9시까지 남아 열심히 공부를 했다 ㅋㅋㅋ

요즈음 우리 층에 공사가 한창인데 원래 있던 LG U+가 나가고 뭐가 들어오나 ~ 했는데 알고보니 우리카드였다 ㅋㅋ
물론 아직 나는 우리금융의 직원은 아니지만 교육생으로서 뭔가 되게 친숙했다 ㅋㅋ

나도 나중에 저런 곳에 들어간다면 다시 이 건물 이 층에 와야겠지 !? 그러면 다음 후배 기수들을 매번 볼 수도 있겠구나 !!
하면서 상상의 나래를 펼쳤었다 ㅋㅋ

아무튼 어서와 ! 우리카드 ~ 😃

이번 주는 연휴에서 복귀하자마자 정말 정신없는 하루를 지냈다.. 사실 후유증을 극복할 시간이고 머고 없었다..

시험의 연속이었기 때문인데, 백앤드 과정이 마무리되면서 백앤드 교과목 평가 시험이 있었다.
그리고 바로 다음 날 오전에 정처기 필기 시험이 있었다 ㅋㅋㅋ ㅠ

그래도 꾸준히 공부해 왔기 때문에, 나는 나를 믿었다!!

그래서 그런지 마지막 백앤드 시험도 무사히 치루고 !

정보처리기사 필기도 당당하게 합격했다 ㅎㅎ
그래도 시험을 치면서 느꼈지만 다음에 있을 정보처리기사 실기 같은 경우는 조금 더 확실히 공부를 해야겠다는 생각이 들었다 !! 현재 공부한 것보다 더 치밀하게 준비해서 실기를 반드시 딸 수 있도록 해야겠다!

공부 얘기

1. 이번 주 배운 것

Spring Security

이번 주는 Spring 중에서도 Security에 대해 공부를 했다. 우리고 정보화 시대를 살고 있는 만큼 많은 정보들이 있고 이 정보들이 재산이 되고 있는 실정이다.

이때 보안이라는 것은 정말 중요한 요소 중에 하나이다. 우리가 사용하는 프레임 워크 중 하나인 Spring도 이를 중요시하여 적용하고 있는데,

예전에 정리한 내용을 보면

Spring 프레임워크가 등장했다. Spring 프레임워크는 매우 높은 수준으로 서버 성능, 안정성, 보안 등을 제공하는 도구이다. 이로써 개발자들은 기능 개발에 집중할 수 있게 되었다.

이렇듯 Spring은 기능 뿐만이 아니라 보안에서도 개발자의 편의를 봐주고 있다. 이는 Spring Security로 설명이 된다.

Spring Securtiy란

Spring 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크이다.
스프링 시큐리티를 이해하려면 인증과 인가에 대한 개념을 알아야 한다.

인증과 인가

인증(Authentication): 사용자의 신원을 입증하는 과정이다. 예를 들어 사용자가 사이트에 로그인을 할 때 누구인지 확인하는 과정을 인증이라고 한다.

인가(Authorization) : 인가는 인증과는 다르다. 인가는 사이트의 특정 부분에 접근할 수 있는지 권한을 확인하는 작업이다. 예를 들어 관리자는 관리자 페이지에 들어갈 수 있지만 일반 사용자는 관리자 페이지에 들어갈 수 없다. 이런 권한을 확인하는 과정을 인가라고 한다.
인증과 인가 관련 코드를 아무런 도구의 도움 없이 작성하려면 굉장히 많은 시간이 필요하다.
하지만 우리에겐 Spring Security가 있다 걱정할 필요가 없다 !!

스프링 시큐리티
앞서 말했듯이 스프링 시큐리티는 스프링 기반 애플리케이션의 보안을 담당하는 스프링 하위 프레임워크이다. 보안 관련 옵션을 많이 제공하고 있는있고, 애너테이션으로 설정도 매우 쉽다. 그리고 CSRF 공격, 세션 고정(session fixation) 공격을 방어해주며 요청 헤더도 보안 처리를 해주므로 개발자가 보안 관련 개발을 해야 하는 부담을 크게 줄여준다.

필터 기반으로 동작하는 스프링 시큐리티
스프링 시큐리티는 필터 기반으로 동작한다.

스프링 시큐리티는 이렇게 다양한 필터들로 나누어져 있으며, 각 필터에서 인증, 인가와 관련된 작업을 처리한다.

SecurityContextPersistenceFilter부터 해서 FilterSecurityInterceptor까지 순서대로 내려가며 필터를 거친다.
필터를 실행할 빨간색 화살표로 연결된 오른쪽 박스의 클래스를 거치며 실행한다.

여기서 눈여겨볼 필터 2가지가 있다.

UsernamePasswordAuthenticationFilter
- 아이디와 패스워드가 넘어오면 인증 요청을 위임하는 인증 관리자 역할을 한다.
FilterSecurityInterceptor
- 권한 부여 처리를 위임해 접근 제어 결정을 쉽게 하는 접근 결정 관리자 역할을 한다.

현 시점 가장 많이 사용하는 아이디와 패스워드 기반 폼 로그인을 시도하면 스프링 시큐리티에서는 어떤 절차로 인증 처리를 하는지 그림으로 볼 수 있다.

사용자가 폼에 아이디와 패스워드를 입력하면, HTTPServletRequest에 아이디와 비밀번호 정보가 전달된다. 이때 AuthenticationFilter가 넘어온 아이디와 비밀번호의 유효성 검사를 한다.
유효성 검사가 끝나면 실제 구현체인 UsernamePasswordAuthenticationToken을 만들어 넘겨준다.
전달받은 인증용 객체인 UsernamePasswordAuthenticationToken을 AuthenticationManager에게 보낸다.
UsernamePasswordAuthenticationToken을 AuthenticationProvider로 보낸다.
사용자 아이디를 UserDetailService에 보낸다. UserDetailService는 사용자 아이디로 찾은 사용자의 정보를 UserDetails 객체로 만들어 AuthenticationProvider에게 전달한다.
DB에 있는 사용자 정보를 가져온다.
입력 정보와 UserDetails의 정보를 비교해 실제 인증 처리를 한다.
~ 10 까지 인증이 완료되면 SecurityContextHolder에 Authentication을 저장한다. 인증 성공 여부에 따라 성공하면 AuthenticationSuccessHandler, 실패하면 AuthenticationFailureHandler 핸들러를 실행한다.

이렇게 스프링 시큐리티 폼 로그인의 인증 흐름을 정리해보았다. 스프링 시큐리티의 폼 로그인을 설정하는 것은 간단하지만 실제로는 이러한 복잡한 내부 동작을 실행한다.

조금 더 자세한 내용은 개인적으로 정리해서 블로그에 작성하려고 한다!!

@PathVariable, @RequestParam의 사용

이 번 주에 백앤드 시험에서 딱 하나 못 푼 문제가 있었따. 바로 @PathVairable, @RequestParam의 사용이었다.

REST API 에서 URI 규칙이 있는데, 특정 id로 정보를 가져오기 위해서는 @PathVariable를 이용해서 정보를 가져와야 한다.

하지만, 아이디 말고 특정 이름 등으로 가져오기 위해서는 쿼리문 작성을 해서 가져올 수 있게 해야하는데
이 때 @RequestParam을 이용하며, 코드를

이렇게 작성을 한 뒤, 쿼리문을 통해

?firstNAme=??&lastNAme=?? 이렇게 작성하여 리소스를 불러 올 수 있다.

그러면 의문이 들 수 있다. 왜? id같은 경우는 @PathVariable를 사용하며, @RequestParam과 구별지은 이유가 뭔가??

그래서 chat GPT를 참고 해 보았다.

<<CHAT GPT>>
1.
일반적으로 REST API를 설계할 때 리소스의 고유 식별자(ID) 같은 핵심 정보는 경로 변수(Path Variable)를 사용하여 표현하고, 선택적인 쿼리 파라미터(예: 검색, 필터, 정렬 등)는 요청 매개변수(RequestParam)로 사용하는 것이 일반적입니다. 이런 방식은 API의 가독성과 사용성을 높이며, 리소스에 대한 접근 방식을 명확하게 합니다.

Path Variable (경로 변수)

정의: URL의 일부로 자원을 직접 식별하는 데 사용됩니다. 경로 변수는 주로 리소스의 고유 식별자(ID)를 지정하는 데 사용됩니다.
사용 예: /users/{userId} 여기서 {userId}는 특정 사용자의 고유 식별자(ID)를 나타내는 경로 변수입니다.
목적: 리소스의 구체적인 위치를 지정하거나, 특정 리소스에 대한 작업을 수행할 때 사용됩니다.

Request Param (요청 매개변수)

정의: URL의 끝에 ? 뒤에 키-값 쌍으로 추가되는 선택적인 파라미터입니다. 주로 검색, 필터링, 정렬 등의 목적으로 사용됩니다.
사용 예: /users?name=JohnDoe 여기서 name=JohnDoe는 요청 매개변수를 사용하여 name이 JohnDoe인 사용자를 찾습니다.
목적: 리소스의 집합에서 특정 조건에 맞는 항목을 검색하거나 필터링하는 데 사용됩니다.

요약

Path Variable 사용 사례: 리소스의 고유 식별자와 같이, API의 경로 부분에 직접 포함되어 리소스를 명확하게 식별할 필요가 있는 경우 사용합니다. 이는 리소스에 대한 접근이나 특정 리소스의 세부 사항을 요청하는 데 적합합니다.
Request Param 사용 사례: 선택적인 쿼리, 필터, 페이지네이션, 정렬 조건과 같이, 리소스 집합에서 특정 데이터를 검색하거나 조회 조건을 제공할 때 사용합니다.

이러한 구분은 REST API를 더욱 명확하고 유연하게 설계할 수 있도록 도와줍니다.

2.
요청 매개변수(Request Params)를 사용하여 API 요청을 할 때, 주어진 조건(예: 필터, 검색 조건)에 맞는 모든 리소스를 가져오게 됩니다. 이는 특히 데이터를 조회할 때 유용하며, 클라이언트가 요구하는 특정 조건이나 범위의 데이터를 서버로부터 받아올 수 있도록 합니다.

예시

예를 들어, 사용자 정보를 관리하는 API가 있고, 특정 사용자 이름으로 사용자 정보를 검색하고자 할 때 요청 매개변수를 사용할 수 있습니다. 만약 /users?name=John과 같은 요청을 한다면, 이름이 'John'인 모든 사용자 정보를 반환하게 됩니다.

요청 매개변수의 사용 사례

필터링: 특정 기준에 따라 결과를 필터링할 때 사용합니다. 예: /products?category=books
검색: 사용자가 입력한 검색어에 해당하는 데이터를 조회할 때 사용합니다. 예: /search?query=rest+api
정렬: 결과를 특정 순서로 정렬해야 할 때 사용합니다. 예: /items?sort=price_asc
페이지네이션: 대량의 데이터 중 일부분만을 조회할 때 사용합니다. 예: /posts?page=2&limit=10

결과의 범위

요청 매개변수로 요청을 하면, 서버는 해당 조건을 만족하는 데이터를 모두 조회하여 반환합니다. 이 때, 서버 측에서 설정한 기본값이나 클라이언트에서 지정한 조건(예: 한 페이지당 결과 수)에 따라 반환되는 데이터의 양이 결정됩니다.

결론

요청 매개변수는 API를 통해 데이터를 유연하게 조회하고 조작할 수 있도록 하는 강력한 수단입니다. 클라이언트가 정의한 조건에 맞는 데이터를 효과적으로 필터링, 검색, 정렬, 그리고 페이지네이션 할 수 있게 함으로써, 사용자가 원하는 데이터를 보다 정확하고 효율적으로 가져올 수 있습니다.

즉, 정리하자면 @PathVariable은 특정 리소스로 경로를 설정해주는 역할을 하고, @RequestParam은 보다 유연하게 내가 찾고자 하는 정보를 모두 가져올 수 있게하는 넓은 의미인 셈이다.

2. 이 번 주 시행 착오

이 번 주의 시행착오라고 하면 연휴의 후유증이 아닐까 싶다. 하지만, 현실은 나를 기다려주지 않는다. 그렇기 때문에 쉬고 싶은 마음은 뒤로한채 얼른 정신 차리려고 노력을 했다 !! 그래서 그런지 빠르게 극복을 했다. 그리고 무사히 백앤드 시험을 치뤘고 , 정보처리기사 필기도 합격이라는 쾌거를 얻어냈다. 하지만 아직 끝난 것이 아니다. 사실 이제 시작이다 ㅋㅋㅋ 다음 주에 시작되는 백앤드 기술세미나, sqld 시험 준비 그리고 AWS, 정보처리 기사 실기 등등 아직 할게 천지이다... 😇

그래도 어쩌겠어 해내야지 !👊

3. 앞으로 어디에 적용

Spring Security를 배운 것을 토대로 보안이 무엇인지 좀 더 자세히 알 수 있었다. 앞으로 훌륭한 개발자로 성장하기 위해서는 이러한 부분도 신경을 써야 하는데, 이번 계기를 통해 내가 어떤 개발자가 되어야 하는지 그러면 어떠한 공부를 해야하는지에 대해 깨닫는 시기가 되었다. 분명 어렵다. 어려운 부분이지만, 그렇다고 피할 수 없다. 피할 수 없다면 즐기고, 내것으로 만들어서 단단한 개발자가 되어야겠다.

@PathVairable @RequestParam을 통해서 REST API에 대한 개념을 조금 더 알게된 계기가 되었다. 현 시점 REST API를 통해 정보 교환하는 일이 많다. 그렇기 때문에 REST API에 대한 명확한 지식이 필요하다. @PathVairable @RequestParam은 그 중 한 부분으로서 이번에 공부한 것을 잘 정리하여 기억해 REST API를 더욱 잘 이용하는 개발자가 되어야겠다.

4. 현재까지의 학습 평가 및 다음 학습을 위한 다짐/목표

-정보처리기사-
정보처리기사 필기는 땄지만, 아직 시작에 불과하다. 아직은 아니지만 시기적절하게 실기를 준비해서 차질 없이 유종의 미를 거둘 수 있도록 하겠다.

-기술 세미나-
나는 REST API를 주제로 발표하게 될 것인데, 다음 주 화요일이 나의 차례이다. 이 역시 잘 준비해서 동기 및 멘토에게 잘 전달할 수 있도록 최선을 다하자.

- 백앤드 -
이번 주 백앤드 과정이 마무리 되었는데, 철저하게 복습하고 지속적으로 it 공부를 통해 보다 더 깊은 이해를 바탕으로 단단한 백앤드 개발자가 되기 위해 노력할 것이다. 현재 Spring boot 책을 보고 있는데, 우선 이 책을 통해 1차적으로 복습을 할 예정이다.

-프론트 앤드 -
점점 안정적으로 되고 있는 상황 놓고 있던 프론트 앤드 공부도 다시 시작해야겠다.

- SQLD -
정보처리기사 필기가 끝났다면, 이제는 SQLD 가 3/9랄 기다리고 있다. ㅋㅋㅋ 기존 하던대로 짜투리 시간을 잘 활용해서 공부를 진행하여 SQLD 자격증도 딸 수 있도록 최선을 다할 예정이다.

- 코딩 테스트 -
인프런에서 코딩테스트를 공부해왔다. 현재 거진 다 끝나가고 있다. 이제는 인프런과 함꼐 백준에 있는 문제를 풀어 나갈 예정이다.

마음 정리

정말 바쁜 하루하루를 살고 있다. 그 사이사이 풀어진 적도 많았다. 근데 그럴수도 있다.

하지만, 기억해야 할 일이 있다.

아직 해야할 일이 많다. 이뤄야 할 것도 많다.

내면을 잘 파악하여 나를 잘 다스리자.

할 수 있다!!

다음 주도 퐈이팅 해보자 !! 😊