안녕하세요! 그로스로그 입니다!😊 🌱
모든 요청을 한 곳에서 받아 나눠주는 서블릿, 모든 상태 변경을 함수 하나로 모으는 훅, 그리고 서로 다른 수 체계를 같은 규칙으로 묶는 대수 구조. 4기 마지막 회차 세 편입니다.
4기 10회차는 2026년 2월입니다. 4기 2차 큐레이션의 마지막 편이기도 해요. 마침 세 편이 흩어져 있던 것을 한 곳으로 모으는 이야기를 하고 있습니다.
01
🚏 디스패처 서블릿이란?
노현주 님
스프링 MVC의 디스패처 서블릿을 정리한 글입니다. 역할을 네 가지로 나누고, 프론트 컨트롤러 패턴이라고 이름 붙입니다.
그런데 이 글의 중심은 실행 순서입니다. 요청이 들어와서 응답이 나갈 때까지 9단계를 번호로 적고, 필터와 인터셉터에 로그를 심은 코드까지 남겼어요.
마지막에 필터와 인터셉터를 언제 각각 쓰는지 기준을 정리합니다.
프레임워크가 요청을 어떻게 넘기는지, 그 경로를 눈으로 볼 수 있게 만든 기록입니다.
조금 더 들어가 보면
역할 네 가지를 이렇게 정리합니다.
· 요청 라우팅 — url을 보고 어떤 컨트롤러의 어떤 메서드를 호출할지 찾아간다
· 데이터 바인딩 — http 파라미터를 자바 객체로 바꾸거나 json을 객체로 매핑한다 (핸들러 어댑터)
· 뷰 렌더링 — 컨트롤러가 넘긴 model과 뷰 이름으로 뷰 리졸버를 호출한다
· 중앙 집중식 관리 — 과거에는 모든 서블릿을 web.xml에 일일이 등록해야 했다
네 번째가 왜 이 구조가 생겼는지를 알려줍니다. 예전에는 서블릿마다 등록이 필요했고, 지금은 디스패처 서블릿 하나가 다 받아서 배분하죠. 저자는 여기에 "= 프론트 컨트롤러 패턴"이라고 등호를 붙였습니다.
🧱 구조적 위치
톰캣과 스프링 컨테이너를 나눠 놓은 게 이 글에서 특히 유용한 대목입니다.
· 톰캣 — 웹 서버이자 서블릿 컨테이너. 필터 단계를 관리
· 스프링 컨테이너 — bean들이 위치. 인터셉터 단계
필터와 인터셉터가 서로 다른 세계에 산다는 것이죠. 이걸 알고 나면 다음 실행 순서가 그냥 목록이 아니라 경계를 넘나드는 경로로 읽힙니다.
📝 원문에서는 순서를 직접 찍어봅니다
설명으로 끝내지 않고 로그를 심었습니다. 필터에는 [1. Filter] 톰캣 단계: 요청이 들어옴과 [5. Filter] 톰캣 단계: 응답이 나감을, 인터셉터에는 [2. Interceptor] 컨트롤러 호출 직전과 [4. Interceptor] 뷰 렌더링까지 완료됨을요.
번호가 붙어 있어서 어느 것이 감싸고 어느 것이 감싸이는지가 보입니다. 필터가 1과 5, 인터셉터가 2와 4예요. 컨트롤러가 3번 자리에 들어갑니다.
그리고 전체 흐름을 아홉 단계로 적었습니다. 요청 → 톰캣 → Filter → DispatcherServlet (스프링의 입구) → Interceptor → Controller → Interceptor 종료 → 응답 생성 → Filter 종료 → 사용자.
여기서 나오는 실무 기준이 이 글의 결론입니다.
계층이 나뉘어 있으니 일도 나눠 놓는다는 것이죠.
마지막으로 HandlerInterceptor의 세 메서드를 정리합니다.
· preHandle() — 컨트롤러 호출 전. 반환이 boolean이라 false면 요청이 거기서 중단됩니다. 로그인 체크에 쓰는 이유예요
· postHandle() — 컨트롤러 후, 뷰 렌더링 전. @RestController 환경에서는 자주 쓰이지 않는다고 덧붙였습니다
· afterCompletion() — 모든 작업이 끝난 후. 예외가 발생해도 반드시 호출되어서 리소스 반환이나 실행 시간 측정에 유용합니다
큐레이터 노트
로그를 심어 순서를 확인한 기록이라 뽑았습니다.
디스패처 서블릿 설명은 검색하면 많이 나옵니다. 대부분 그림 한 장과 단계 목록이에요. 이 글은 필터와 인터셉터에 번호를 매긴 출력문을 직접 넣었습니다. 읽어서 아는 것과 찍어서 보는 것은 다르고, 특히 감싸는 순서는 직접 봐야 남습니다.
preHandle이 boolean을 반환한다는 것과 afterCompletion은 예외가 나도 호출된다는 것 — 이 두 가지가 인터셉터를 실제로 쓸 때 필요한 정보입니다. 앞의 것은 요청을 막는 방법이고, 뒤의 것은 정리 작업을 믿고 맡길 수 있는 근거니까요.
같은 저자가 4회차에는 크롤러 유지보수를, 10회차에는 스프링 내부 구조를 썼습니다. 모르는 코드를 읽어내는 방식이 두 글에 다 있습니다.
02
🎛️ React hook — useReducer
박현구 님
React의
useReducer를 정리한 글입니다. useState와 비교하며 "더 구조적"이라고 위치를 잡아요.Redux에서 온 세 용어 — Dispatch · Action · Reducer를 먼저 정의하고 시작합니다.
공식 레퍼런스를 따라가되 counter 컴포넌트를 직접 만들어 보고, 마지막에 state를 직접 바꾸면 안 되는 이유를 잘못된 코드와 올바른 코드로 나란히 보여줍니다.
useState를 쓰던 사람이 다음 단계로 넘어가는 지점을 짚은 글입니다.
조금 더 들어가 보면
useState와의 차이를 한 문장으로 정리합니다.
useState의 setState 함수를 외부 함수로 분리할 수 있다는 것이 가장 큰 특징이다."상태를 바꾸는 로직이 컴포넌트 안에 흩어져 있는 대신 함수 하나로 빠져나온다는 것이죠.
그리고 세 용어를 정의합니다.
· Dispatch — 상태 변경 요청을 보내는 함수
· Action — 상태의 변경 로직을 적어놓은 객체
· Reducer — 현재 상태와 행동을 받아서 새로운 상태를 반환하는 함수
요청하는 쪽 · 요청 내용 · 처리하는 쪽으로 나뉩니다. 이렇게 갈라놓으면 컴포넌트는 "무엇을 하고 싶다"만 말하고, 어떻게 바꿀지는 reducer가 정하게 돼요.
📐 레퍼런스를 짚어가며
useReducer(reducer, initialArg, init?) 의 매개변수를 하나씩 정리합니다.
reducer에는 조건이 붙습니다 — 반드시 순수 함수여야 하고, State와 Action을 인수로 받아 다음 State를 반환해야 한다고요. init은 선택인데, 없으면 초기 State가 initialArg가 되고 있으면 init(initialArg)의 결과가 됩니다.
주의 사항 중 두 가지가 실제로 걸리는 것들입니다.
· Hook이므로 최상위 또는 커스텀 Hook에서만 호출할 수 있다. 반복문이나 조건문 안에서는 못 쓴다
· Strict Mode에서는 Reducer와 init을 두 번 호출한다. 우연한 비순수성을 찾기 위해서고, 개발 환경 한정이며, 순수 함수라면 영향이 없다
두 번째는 처음 보면 버그로 오해하기 쉬운 동작입니다. 왜 그런지와 함께 "호출 중 하나의 결과는 무시한다"까지 적어뒀어요.
📝 원문에서는 직접 만들어 봅니다
counter를 만들면서 switch (action.type)으로 로직을 나눕니다. INCREMENT · DECREMENT · RESET, 그리고 default에서는 "알 수 없는 타입이 들어오면 기존 상태 반환"이에요.
payload를 쓴 것이 이 예제의 좋은 점입니다. +1 버튼과 +10 버튼이 같은 Action 타입을 쓰고 숫자만 다르게 넘깁니다.
dispatch({ type: 'INCREMENT' }) // 1씩
dispatch({ type: 'INCREMENT', payload: 10 }) // 10씩
reducer 쪽은 state.payload ?? 1로 받고요. 버튼이 늘어도 reducer의 case는 안 늘어납니다.
마지막 경고가 이 글에서 가장 중요한 대목입니다.
그리고 잘못된 코드와 올바른 코드를 나란히 놓습니다. state.count = state.count + 1로 직접 고치고 return state 하는 것(🚩)과, return { count: state.count + 1 }로 새 객체를 반환하는 것(✅)이요.
큐레이터 노트
공식 문서를 따라가되 자기 예제를 넣은 글이라 뽑았습니다.
레퍼런스 정리는 자칫 문서 번역이 됩니다. 이 글은 payload를 쓴 counter를 직접 만들어 붙였어요. 같은 Action 타입에 값만 달리 넘기는 구조를 보여준 건데, useReducer를 왜 쓰는지가 이 예제 하나로 드러납니다. 버튼이 다섯 개가 되어도 reducer는 그대로니까요.
잘못된 코드를 함께 실은 것도 그렇습니다. "이렇게 하세요"만 있으면 자기가 틀렸는지 모르고 지나갑니다. 🚩와 ✅를 나란히 두면 자기 코드가 어느 쪽인지 대볼 수 있어요. state를 직접 바꾸는 실수는 리액트 입문 구간에서 가장 흔한 것 중 하나입니다.
03
🏛️ 선형대수 8장 연습문제 풀이
최태형 님
선형대수 8장 연습문제 풀이 과정을 정의부터 짚어가며 적은 글입니다.
원소가 셋뿐인 집합 F={0, 1, 2}가 체가 되는지 확인하고, 항등원과 역원을 표에서 찾습니다.
그다음 Q(√3)의 역원을 유리화로 구하고, 마지막에 부분공간임을 증명합니다.
답만 적지 않고 어느 정의를 근거로 삼았는지를 매번 밝히는 게 이 글의 방식입니다.
조금 더 들어가 보면
첫 문제는 덧셈·곱셈 표가 주어진 F={0, 1, 2}입니다. 원소가 셋뿐인 작은 체예요.
풀이가 [정의 8.1]을 먼저 꺼내는 순서로 갑니다. 덧셈의 항등원은 "k+0=k가 성립"하는 0, 곱셈의 항등원은 "k·1=k 성립"하는 1이라고 정의를 인용하고, 그다음 표에서 확인합니다.
역원도 같은 방식입니다. 정의를 꺼낸 뒤 표에서 찾는 방법을 한 줄로 정리해요.
그러면 1+2=0이니 1의 역원은 2, 2+1=0이니 2의 역원은 1입니다. 곱셈도 같아요 — 두 수를 곱해 1이 되는 값을 찾으면 되고, 2·2=1이라 2의 곱셈 역원은 2 자신입니다.
보통의 산수와 다른 결과인데, 정의를 따라가면 그대로 나옵니다. 이 표 안에서는 2+1이 0이니까요.
📝 원문에서는 유리화로 넘어갑니다
두 번째 문제는 Q(√3) = {a+b√3 | a, b는 유리수}에서 2+√3의 곱셈 역원을 구하는 것입니다.
여기서도 정의부터 씁니다 — "곱셈의 역원은 k·k⁻¹=1 이다." 그리고 (2+√3)·k=1을 세운 뒤 분모를 유리화합니다.
$$k = \frac{1}{2+\sqrt{3}} = \frac{2-\sqrt{3}}{2^2-(\sqrt{3})^2} = \frac{2-\sqrt{3}}{4-3} = 2-\sqrt{3}$$
분모가 정확히 1이 되면서 답이 2−√3으로 떨어집니다. 이 값이 다시 a+b√3 꼴이라 Q(√3) 안에 있습니다 — 체라는 조건이 지켜지는 것이죠.
세 번째는 부분공간 증명입니다. 벡터 B와 수직인 벡터들의 집합 S가 R²의 부분공간임을 보이는 문제요.
[정의 8.4]의 조건을 꺼내고 셋을 차례로 확인합니다. 영벡터가 S에 있고, A₁+A₂가 S에 있고, kA가 S에 있다는 것을요. 각각의 계산이 한 줄씩입니다.
$$(A_1+A_2) \cdot B = A_1 \cdot B + A_2 \cdot B = 0$$
$$(k \cdot A) \cdot B = k(A \cdot B) = k(0) = 0$$
내적의 분배법칙과 스칼라 결합만 쓰면 끝납니다. 그리고 R³에서 B와 C 둘 다에 수직인 경우로 확장하는데, 조건이 하나 늘어도 같은 절차를 두 번 하면 되는 것이 보입니다.
큐레이터 노트
정의를 매번 다시 꺼내는 풀이라 뽑았습니다.
연습문제 풀이는 대개 계산만 적습니다. 이 글은 문제마다 [정의 8.1], [정의 8.4]를 먼저 인용하고 시작해요. 그러면 계산이 어디서 나온 규칙인지가 같이 남습니다. 나중에 다시 볼 때 답이 아니라 근거가 보이는 기록이 됩니다.
원소 셋짜리 체를 다룬 것도 좋은 재료입니다. 2·2=1 같은 결과는 익숙한 산수와 어긋나는데, 그래서 오히려 체가 무엇을 요구하는 구조인지가 선명해집니다. 규칙을 만족하면 되는 것이지 우리가 아는 숫자여야 하는 게 아니니까요.
방송대 컴퓨터과학과 커리큘럼에 선형대수가 있습니다. 같은 과목을 듣는 회원에게는 정의를 인용하며 푸는 방식 자체가 참고가 됩니다.
💡 세 편을 겹쳐 읽으며
세 편이 입구를 하나로 모으는 이야기를 하고 있습니다.
노현주 님의 디스패처 서블릿은 요청의 입구입니다. 예전에는 서블릿마다 web.xml에 등록해야 했는데, 이제는 하나가 다 받아서 배분해요.
박현구 님의 useReducer는 상태 변경의 입구입니다. 여기저기서 setState를 부르는 대신, 모든 변경이 reducer 하나를 지나갑니다.
최태형 님의 체는 연산의 입구입니다. F={0,1,2}든 Q(√3)든, 같은 규칙 목록을 만족하면 같은 방식으로 다룰 수 있습니다.
모으고 나면 갈라지는 자리가 생깁니다. 디스패처 서블릿에는 필터와 인터셉터라는 두 층이, reducer에는 switch (action.type)의 case들이, 체에는 정의 8.1의 조건 목록이 있어요. 입구는 하나인데 그 안에서 나뉘는 구조가 셋 다 같습니다.
그래서 새로운 것이 늘어도 입구는 안 늘어납니다. 컨트롤러를 추가해도 디스패처 서블릿은 그대로고, 버튼을 늘려도 payload만 다르게 넘기면 되고, 새 수 체계도 체의 조건만 만족하면 같은 정리들이 다 적용됩니다.
규칙을 먼저 정해두면 예외를 따로 만들지 않아도 되는 것 — 4기의 마지막 회차가 이 이야기로 모였습니다.
이번 회차에서 가져갈 것
1. 순서가 궁금하면 로그를 심어보기.
필터에 1과 5, 인터셉터에 2와 4를 찍으면 무엇이 무엇을 감싸는지가 눈에 보입니다. 그림으로 읽은 것과 다르게 남습니다.
2. 두 계층의 경계를 알면 어디에 넣을지 정해진다.
필터는 톰캣, 인터셉터는 스프링. 공통 작업은 앞쪽, 스프링 기능이 필요하면 뒤쪽입니다.
3. 중단할 수 있는 지점을 알아두기.
preHandle()이 false를 반환하면 요청이 거기서 멈춥니다. 막을 수 있는 자리를 알면 인증 처리를 어디에 둘지 정해져요.
4. 같은 Action에 값만 달리 넘기기.
+1과 +10이 같은 타입에 payload만 다르면, 버튼이 늘어도 처리 로직은 안 늘어납니다.
5. 잘못된 코드도 같이 적어두기.
state를 직접 바꾸는 것과 새 객체를 반환하는 것을 나란히 놓으면 자기 코드가 어느 쪽인지 대볼 수 있습니다.
6. 답 대신 근거를 남기기.
"[정의 8.1]에 의해"라고 적어두면 나중에 다시 볼 때 계산이 아니라 규칙이 보입니다. 규칙이 남아야 다른 문제에도 씁니다.
🌱 4기 2차 큐레이션을 마치며
10회차에 걸친 4기 2차 큐레이션이 여기서 끝납니다.
1차에서 한 번 고른 뒤 다시 읽으며 뽑은 글들이었어요. 그래서 1차와 겹치지 않는 이름들이 많이 올라왔습니다. 처음 읽을 때는 지나쳤는데 다시 보니 남는 글들이 있었고, 그런 기록을 찾는 것이 2차의 일이었습니다.
4기는 2025년 9월에 시작해 2026년 2월에 마쳤습니다. 그사이 회원들의 글은 처음 배우는 것에서 실무에서 부딪힌 것까지 넓어졌어요. 1회차에 CS 시리즈 계획을 올린 분이 4회차에 알고리즘 편을 쓰고, 4회차에 크롤러를 고치던 분이 10회차에 스프링 내부 구조를 정리했습니다. 회차를 이어서 보면 그 이동이 보입니다.
좋은 글 남겨주신 노현주 님, 박현구 님, 최태형 님께 감사드립니다! 😊
그리고 4기 동안 성장일지를 써주신 모든 분들께 감사드립니다. 🌱
- 에디터 · 성장일지 큐레이터 -
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.