[TIL] 25일차 _ 숙련 Spring #1

Seoyeon Lee·2025년 11월 7일

Today I Learned ...

오늘은 코드카타 SQL과 알고리즘 31, 32번 문제를 풀고, 숙련 Spring 강의를 듣기 시작했다!


🗒️ 코드카타 #18

오늘 진행한 SQL 문제들은 join을 활용해 두개의 테이블을 연관지어 데이터를 가공하는 것이었다.
사전캠프를 진행하여 join을 활용하는 방법에 대해 다뤘었기 때문에 큰 어려움 없이 해결할 수 있었다.

오늘은 총 2개의 알고리즘 문제를 풀었는데,
첫 번째 문제는 입력받은 숫자만큼 '수박'을 출력하는 것인데, 예를 들어 3을 입력하면 '수박수', 4를 입력하면 '수박수박'을 출력하는 것이다.
나는 if문을 활용해 입력받은 숫자가 짝수일 때와 홀수일 때를 나눠서 진행했는데,
다른 사람들의 풀이를 보니 입력받은 수가 짝수이든 홀수이든 상관없이 '수박' String을 만들어두고, substr로 필요한 만큼 잘라서 사용할 수도 있었다.

두 번째 문제는 입력받은 두 배열의 동일 인덱스의 곱의 합을 출력하는 것이었다.
for문을 활용해 쉽게 해결할 수 있었다.
IntStream을 활용하여 해결하고 싶었는데, forEach를 사용하는 데에 계속 오류가 나서 해결하지 못했었다.
그런데 다른 사람의 풀이를 보니 forEach가 아니라 map을 사용해야 했던 것이다..
애증의 스트림... 어떤 상황에 무엇을 써야 하는지 정리해봐야겠다.

각각의 문제와 풀이는 깃허브를 통해 업로드해두었다.
GitHub 보러가기


📚 숙련 Spring #1

오늘부터는 Spring 숙련 강의를 듣기 시작했다!
내가 벌써 숙련이란 말을 붙일 수 있나 싶긴 하지만...

총 3주차의 강의 중 오늘은 1주차와 2주차의 내용을 들었다.
1주차의 내용은 스프링이 작동하는 원리에 대해 조금 더 자세하게 설명해주는 내용이었다.

먼저, 스프링의 대표적인 컨셉인 IoC/DI에 관한 것이다.
IoC란 '제어의 역전'이라는 뜻으로, 기존에는 개발자가 직접 객체를 생성하고 관리했던 것을 이제는 스프링이 대신 생성하고 관리해준다는 개념이다.
그리고 DI란 '의존성 주입'이라는 뜻으로 IoC 개념을 실제로 구현하는 방법이다.

스프링은 IoC 컨테이너라는 공간에 Bean이라는 이름으로 객체를 만들어서 관리하고, 개발자는 이곳에 있는 Bean을 의존성 주입을 통해 가져와서 사용한다.
이렇게 사용하면 편리해질 뿐만 아니라 코드 실수의 여지가 줄어들어 안정성과 효율성도 확보된다.

하지만 그렇다고 무작정 Bean에 등록해서 사용해서는 안 된다.
재사용되거나 교체 가능한 비즈니스 로직이나 인프라, 즉 3계층의 각각의 클래스 같은 경우에 Bean으로 관리하고,
매번 새로운 상태를 가지는 데이터 객체, 즉 Entity 혹은 DTO 클래스 같은 경우에는 기존처럼 new를 사용해 직접 생성해야 한다.
3계층의 클래스에 사용하는 어노테이션에는 해당 클래스를 Bean에 자동 등록해주는 @Component 어노테이션이 포함되어 있다.

또, 지난 과제의 Lv.7에서 요구했던 필수값 처리와 예외 처리에 대한 부분도 1주차 강의에서 다루었다.
내가 놓쳤던 Controller 계층에서의 필수값 처리는.. @Valid 어노테이션을 활용할 수 있었다.
@Valid 어노테이션이 붙으면 컨트롤러 단계에서 자동으로 검증을 실행하고,
공백을 불가하게 하는 @NotBlank, 이메일 형식을 강제하는 @Email, 문자열의 길이나 컬렉션 크기를 제한하는 @Size 등의 어노테이션을 Entity 클래스에서 함께 활용할 수도 있다.

Lv.7에서 비밀번호가 일치하지 않는 상황이나 존재하지 않는 ID를 조회한 경우에 커스텀 에러를 만들어서 사용했는데,
무작정 인터넷을 보고 따라했던 내용들을 강의를 통해 다시 정리할 수 있었다.
나 혼자 할때는 공통 부모 커스텀 에러라는 존재를 몰라서 모든 커스텀 에러마다 메서드를 만들어서 사용해야 했는데...
역시 이래서 개념을 확실히 알고 적용해야 하나보다.


2주차에서 다룬 내용의 핵심은 인증과 인가이다.

인증이란 사용자가 누구인지를 확인하는 것이고, 인가란 인증된 사용자에게 접근 권한이 있는지를 확인하는 것이다.
즉, 로그인과 유저의 접근 제어이다.

HTTP는 Stateless, 서버가 없는 무상태 프로토콜이기 때문에 요청할 때마다 내가 누구인지를 알려주어야만 한다.
그래서 HTTP의 Header에 인증 관련 데이터를 주고받을 수 있는 공간이 존재한다.

HTTP에서 사용자 인증을 유지하는 방법에는 2가지가 있는데, 세션과 JWT이다.
세션은 서버가 사용자의 로그인 상태를 기억하는 방식이고, JWT는 서버가 로그인을 저장하지 않고 JWT에 모든 인증 정보가 담겨있는 방식이다.

이번 강의에서는 세션을 활용해 사용자 인증을 유지했는데, 이렇게 하니 너무 너무 편하다!!
이전에는 매번 ID와 패스워드를 줘가면서 실습을 해왔는데,
PostMan에서도 알아서 세션 키를 저장해두어서 별다른 비밀번호를 주지 않고도 수정하고, 삭제하는 등의 작업을 할 수 있었다.

@RequestParam를 활용해 HTTP의 body 내용을 파라미터로 가져왔던 것처럼
@RequestHeader를 활용하면 HTTP의 header 내용을 가져올 수 있다.
@RequestHeader는 헤더의 전체 내용을 가져와 그 안에서 가공해야 하는데, 인증 유지를 위해서는 세션ID의 값만 사용하면 된다.
이때 @SessionAttribute 어노테이션을 활용하면 헤더의 전체 내용이 아닌 세션ID만 가져와 사용할 수 있다.

강의의 자세한 설명은 노션에 정리해두었다.
Notion 확인하기


🙃 오늘의 느낀점

강의를 들으면서 점점 내가 사용하는 웹페이지와 어플리케이션들이 어떻게 동작되고 있는지 그림이 그려지고 있다.
어려운데.. 이러니까 너무 재미있다.
아직 강의를 조금 더 들어야 하지만 빨리 강의를 다 듣고 실습을 시작해보고 싶다.

profile
백엔드 개발자 지망생

0개의 댓글