Woojoo's Devlog

#24 Servlet과 JSP에서 request는 어떻게 사용될까

sqaxe1 — Mon, 22 Jun 2026 15:13:32 +0900

Servlet/JSP를 공부하면서 가장 헷갈렸던 부분은 request와 response였다.

처음에는 단순히 이렇게만 이해했다.

request
→ 브라우저가 서버로 보내는 메시지

response
→ 서버가 브라우저로 보내는 메시지

큰 방향에서는 맞는 설명이다.

하지만 Servlet/JSP를 실제로 사용하다 보면 request가 단순히 브라우저가 보낸 정보만 담는 객체가 아니라는 것을 알게 된다.

request는 요청 처리용 객체다

브라우저가 서버에 요청을 보내면 Tomcat이 request와 response 객체를 만든다.

브라우저 요청
→ Tomcat
→ request 생성
→ response 생성

그리고 이 둘을 Servlet에게 넘긴다.

doGet(request, response)

여기서 HttpServletRequest는 단순한 요청 메시지 원본이 아니다.

조금 더 정확히는 다음처럼 볼 수 있다.

이번 요청을 처리하기 위한 컨텍스트 객체

즉 request 안에는 브라우저가 보낸 정보뿐 아니라, 이번 요청을 처리하는 동안 필요한 여러 정보가 함께 들어 있다.

요청 주소
요청 방식
파라미터
헤더
쿠키
세션 접근 정보
서버 내부에서 담아둔 attribute

이 점이 처음에는 헷갈렸다.

request에서 입력값 꺼내기

사용자가 form으로 보낸 값이나 URL query string 값은 getParameter()로 꺼낸다.

예를 들어 URL이 다음과 같다면,

/memos?title=hello&content=study

Servlet에서는 이렇게 꺼낼 수 있다.

String title = request.getParameter("title");
String content = request.getParameter("content");

HTML form에서도 마찬가지다.

<input name="title">
<textarea name="content"></textarea>

서버에서는 name 값을 기준으로 꺼낸다.

request.getParameter("title");
request.getParameter("content");

즉 getParameter()는 브라우저가 요청으로 보낸 파라미터 값을 꺼낼 때 사용한다.

request에는 주소도 들어 있다

request에는 입력값만 있는 것이 아니다.

요청 주소도 들어 있다.

하지만 주소는 getParameter()로 꺼내는 것이 아니다.

request.getRequestURI();

요청 방식은 다음으로 확인할 수 있다.

request.getMethod();

헤더는 다음처럼 확인할 수 있다.

request.getHeader("User-Agent");

정리하면 request 안의 정보는 종류에 따라 꺼내는 메서드가 다르다.

입력값
→ getParameter()

요청 주소
→ getRequestURI()

요청 방식
→ getMethod()

헤더
→ getHeader()

처음에는 request 안에 있는 값을 다 같은 방식으로 꺼내는 줄 알았는데, 정보의 종류에 따라 사용하는 메서드가 달랐다.

request는 저장소 역할도 한다

가장 헷갈렸던 부분은 이것이었다.

request는 브라우저가 보낸 요청인데,
왜 서버에서 request에 데이터를 저장할까?

Servlet에서는 다음처럼 데이터를 담을 수 있다.

request.setAttribute("message", "메모 목록입니다.");

이렇게 담은 데이터는 JSP에서 꺼낼 수 있다.

${message}

즉 request는 브라우저가 보낸 정보만 담는 것이 아니라, Servlet에서 JSP로 데이터를 넘기는 임시 저장소 역할도 한다.

getParameter와 setAttribute의 차이

getParameter()와 setAttribute()는 반드시 구분해야 한다.

request.getParameter("title")

이 코드는 브라우저가 보낸 값을 꺼내는 것이다.

form input 값
URL query string 값

반면 다음 코드는 서버가 request 안에 데이터를 담는 것이다.

request.setAttribute("memos", memos);

주로 Servlet에서 JSP로 데이터를 넘길 때 사용한다.

정리하면 다음과 같다.

parameter
→ 브라우저가 서버로 보낸 값

attribute
→ 서버가 request에 추가로 담은 값

이 차이를 이해해야 Servlet에서 입력값을 받는 코드와 JSP로 데이터를 넘기는 코드를 구분할 수 있다.

왜 하필 request에 데이터를 담을까

Servlet과 JSP는 같은 요청을 이어서 처리한다.

브라우저가 /memos 요청
→ Servlet이 먼저 처리
→ JSP가 이어서 화면 처리

이때 Servlet이 JSP에게 데이터를 넘겨야 한다.

예를 들어 메모 목록을 JSP에서 출력하려면, Servlet이 먼저 메모 목록을 준비해야 한다.

request.setAttribute("memos", memoService.getMemos());

그리고 JSP로 넘긴다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
        .forward(request, response);

JSP는 같은 request를 이어받기 때문에 memos를 꺼내서 화면에 출력할 수 있다.

${memos}

즉 request는 같은 요청 처리 흐름 안에서 Servlet과 JSP가 공유하는 작업 공간으로 사용할 수 있다.

response는 왜 저장소로 쓰지 않을까

response도 Servlet에서 JSP로 함께 넘어간다.

forward(request, response)

그래서 처음에는 request와 response 둘 다 데이터를 공유하는 저장소처럼 쓰는 줄 알았다.

하지만 둘의 역할은 다르다.

request
→ 요청 정보 + 서버 내부 데이터 전달 공간

response
→ 브라우저로 나갈 응답 작성 통로

response에도 값을 설정하긴 한다.

response.setStatus(200);
response.setHeader("Cache-Control", "no-cache");
response.setContentType("text/html;charset=UTF-8");

하지만 이것은 JSP에게 데이터를 넘기기 위한 저장소가 아니다.

브라우저에게 보낼 응답 정보를 설정하는 것이다.

정리하면 다음과 같다.

request attribute
→ Servlet에서 JSP로 데이터 전달

response
→ 브라우저로 나갈 상태 코드, 헤더, 본문 작성

forward에서 request와 response를 둘 다 넘기는 이유

Servlet에서 JSP로 이동할 때 다음 코드를 사용한다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
        .forward(request, response);

여기서 request와 response를 둘 다 넘긴다.

하지만 둘의 역할은 다르다.

request
→ JSP가 Servlet이 담아둔 데이터를 꺼내기 위해 사용

response
→ JSP가 최종 HTML을 브라우저로 보내기 위해 사용

즉 둘 다 JSP로 넘어가지만, 둘 다 같은 방식으로 저장소처럼 쓰는 것은 아니다.

Servlet에서 request로 하는 일

Servlet에서는 request를 주로 다음 용도로 사용한다.

1. 브라우저가 보낸 입력값 꺼내기
2. 요청 정보 확인하기
3. JSP에 넘길 데이터 저장하기

예를 들어 메모 작성 요청에서는 브라우저가 보낸 값을 꺼낸다.

String title = request.getParameter("title");
String content = request.getParameter("content");

목록 화면 요청에서는 JSP에 넘길 데이터를 담는다.

request.setAttribute("memos", memoService.getMemos());

즉 Servlet은 request를 읽고, 필요한 데이터를 다시 request에 담는다.

JSP에서 request로 하는 일

JSP에서는 Servlet이 request에 담아둔 데이터를 꺼내서 화면에 출력한다.

Servlet에서는 다음처럼 데이터를 담는다.

request.setAttribute("message", "Servlet에서 준비한 데이터입니다.");

JSP에서는 이렇게 출력한다.

<p>${message}</p>

흐름은 다음과 같다.

Servlet이 request에 message 저장
→ forward
→ JSP가 같은 request에서 message 꺼냄
→ HTML로 출력

즉 JSP는 request를 통해 Servlet이 준비한 데이터를 사용한다.

request의 수명

request에 저장한 데이터는 오래 유지되지 않는다.

request는 하나의 요청이 처리되는 동안만 살아 있다.

/memos 요청
→ request 생성
→ Servlet 처리
→ JSP 처리
→ 응답 완료
→ request 사라짐

새로고침하거나 다른 요청을 보내면 새로운 request가 만들어진다.

따라서 request는 장기 저장소가 아니다.

request
→ 한 요청 동안만 사용하는 임시 저장소

오래 저장해야 하는 데이터는 나중에 DB나 session 등을 사용해야 한다.

Servlet과 JSP에서 request가 사용되는 흐름은 다음과 같다.

브라우저가 /memos 요청
→ Tomcat이 request와 response 생성
→ Servlet 실행
→ Servlet이 request에서 필요한 정보 읽음
→ Servlet이 JSP에 넘길 데이터를 request에 저장
→ forward(request, response)
→ JSP가 같은 request에서 데이터 꺼냄
→ JSP가 HTML 생성
→ response를 통해 브라우저로 응답

이 흐름을 보면 request가 단순히 브라우저에서 서버로 온 메시지만은 아니라는 것을 알 수 있다.

#23 Servlet에서 JSP로 forward하기

sqaxe1 — Sun, 21 Jun 2026 17:51:52 +0900

이번 단계에서는 Servlet이 직접 HTML을 출력하던 방식에서 JSP로 화면을 분리했다.

처음에는 Servlet 안에서 브라우저에 직접 HTML을 보냈다.

response.setContentType("text/html;charset=UTF-8");
response.getWriter().println("<h1>Servlet 메모장</h1>");
response.getWriter().println("<p>Servlet이 정상적으로 실행되었습니다.</p>");

이 방식은 Servlet이 요청 처리와 화면 출력을 모두 담당하는 구조다.

간단한 확인용 화면에서는 문제없지만, 화면이 길어질수록 Java 코드 안에 HTML 문자열이 계속 들어가게 된다.

그래서 이번 단계에서는 역할을 나누기 위해 JSP를 사용했다.

Servlet
→ 요청 처리 담당

JSP
→ HTML 화면 출력 담당

JSP 파일은 다음 위치에 만들었다.

servlet-jsp-memo/src/main/webapp/WEB-INF/views/memos.jsp

WEB-INF 안에 둔 이유는 브라우저가 JSP에 직접 접근하지 못하게 하기 위해서다.

브라우저가 직접 JSP 접근
→ 막음

Servlet을 통해 JSP로 이동
→ 허용

즉 사용자가 이런 주소로 JSP에 직접 들어가는 것이 아니라,

/WEB-INF/views/memos.jsp

항상 Servlet을 통해 들어가도록 했다.

/memos

이 구조가 Servlet이 흐름을 제어하고 JSP가 화면을 담당하는 방식에 더 가깝다.

Servlet 코드 변경

기존에는 Servlet이 직접 HTML을 출력했다.

response.getWriter().println("<h1>Servlet 메모장</h1>");

변경 후에는 JSP로 요청을 넘겼다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
        .forward(request, response);

전체 코드는 다음과 같다.

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

    request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
            .forward(request, response);
}

이제 /memos 요청이 들어오면 MemoServlet이 실행되고, 그 안에서 JSP로 이동한다.

다음 코드는 현재 요청을 서버 내부의 특정 JSP로 넘기기 위한 준비를 한다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")

의미는 다음과 같다.

이 요청을 /WEB-INF/views/memos.jsp가 이어서 처리하게 하겠다.

즉 getRequestDispatcher()는 요청을 전달할 대상을 찾는 역할을 한다.

forward란 무엇인가

forward()는 실제로 요청을 JSP로 넘기는 실행 부분이다.

.forward(request, response);

여기서 중요한 점은 브라우저가 새로 요청하는 것이 아니라는 것이다.

브라우저가 새로 요청하는 것이 아니다.
서버 내부에서 Servlet → JSP로 이동한다.

그래서 브라우저 주소창은 그대로 유지된다.

http://localhost:8080/memos

하지만 서버 내부에서는 다음 흐름으로 이동한다.

/memos 요청
→ MemoServlet
→ /WEB-INF/views/memos.jsp

즉 사용자는 /memos로 접속했지만, 실제 화면 출력은 JSP가 담당한다.

request와 response는 누가 만드는가

처음에는 response가 블랙박스처럼 느껴졌다.

브라우저가 요청을 보내면 Tomcat이 먼저 두 객체를 만든다.

request
response

request는 브라우저가 보낸 요청 정보를 담고 있다.

요청 URL
요청 방식
파라미터
사용자가 보낸 값
Servlet이 담아둔 데이터

response는 브라우저에게 돌려줄 응답을 만들 때 사용한다.

상태 코드
헤더
Content-Type
응답 본문
출력 통로

Tomcat은 이 두 객체를 Servlet에게 넘긴다.

doGet(request, response)

response는 완성된 응답이 아니다

중요하게 정리한 부분은 이것이다.

처음에는 Tomcat이 완성된 response를 JSP에 넘기는 것처럼 생각했다.

하지만 정확히는 그렇지 않다.

흐름은 다음과 같다.

Tomcat이 비어 있는 response 객체를 만든다.
Servlet에게 request와 response를 넘긴다.
Servlet은 JSP로 forward한다.
JSP가 response 안에 HTML을 채운다.
Tomcat이 완성된 response를 브라우저로 보낸다.

즉 Tomcat이 화면 내용을 알아서 만들어주는 것이 아니다.

Tomcat은 응답 객체를 만들고, 최종적으로 브라우저에 보내는 역할을 한다.
응답의 내용은 Servlet이나 JSP가 채운다.

Servlet이 직접 출력하는 경우

처음 방식은 Servlet이 직접 response를 채우는 방식이었다.

response.getWriter().println("<h1>Servlet 메모장</h1>");

흐름은 다음과 같다.

Tomcat이 response 생성
→ Servlet이 response에 HTML 작성
→ Tomcat이 response를 브라우저에 전송

즉 Servlet이 직접 응답 본문을 작성한다.

JSP로 forward하는 경우

JSP 방식에서는 Servlet이 직접 HTML을 작성하지 않는다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
        .forward(request, response);

흐름은 다음과 같다.

Tomcat이 response 생성
→ Servlet이 response를 직접 채우지 않음
→ Servlet이 request와 response를 JSP로 넘김
→ JSP가 response에 HTML 작성
→ Tomcat이 response를 브라우저에 전송

차이는 이것이다.

Servlet 직접 출력
→ Servlet이 response를 채움

JSP forward
→ JSP가 response를 채움

JSP에서는 response가 안 보이는데 어떻게 응답할까

JSP 파일에는 보통 HTML만 작성한다.

<h1>Servlet/JSP 메모장</h1>
<p>JSP 화면이 정상적으로 출력되었습니다.</p>

겉으로 보면 response를 직접 쓰지 않는다.

하지만 Tomcat은 JSP를 내부적으로 Servlet 코드로 변환해서 실행한다.

개념적으로는 이런 코드로 바뀐다고 볼 수 있다.

out.write("<h1>Servlet/JSP 메모장</h1>");
out.write("<p>JSP 화면이 정상적으로 출력되었습니다.</p>");

여기서 out은 JSP가 제공하는 출력 객체다.
이 out은 내부적으로 response와 연결되어 있다.

즉 흐름은 다음과 같다.

JSP에 작성한 HTML
→ Tomcat이 내부적으로 out.write(...)로 변환
→ response body에 기록
→ 브라우저로 전송

그래서 JSP에서 직접 response.getWriter()를 쓰지 않아도 응답이 되는 것이다.

response에는 본문만 있는 것이 아니다

response에는 HTML 본문만 들어가는 것이 아니다.

상태 코드
헤더
Content-Type
쿠키
본문

같은 정보가 들어간다.

다만 JSP가 주로 채우는 것은 HTML 본문이다.
상태 코드나 헤더는 보통 Servlet에서 설정할 수 있다.

예를 들면 다음과 같다.

response.setStatus(HttpServletResponse.SC_OK);
response.setContentType("text/html;charset=UTF-8");

현재 코드에서 상태 코드와 Content-Type은 어떻게 처리될까

현재 Servlet에서는 이렇게만 작성했다.

request.getRequestDispatcher("/WEB-INF/views/memos.jsp")
        .forward(request, response);

그런데도 응답이 정상적으로 나온다.

이유는 다음과 같다.

상태 코드
→ 정상 처리 시 Tomcat이 기본적으로 200 OK 사용

Content-Type
→ JSP의 page 지시어에서 설정

HTML 본문
→ JSP가 생성

JSP 맨 위에는 이런 코드가 있다.

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

이 지시어가 응답의 Content-Type을 설정한다.

즉 현재 구조에서는 다음처럼 처리된다.

상태 코드 200
→ Tomcat 기본값

Content-Type
→ JSP page 지시어

HTML 본문
→ JSP가 생성

request를 넘기는 이유

forward(request, response)에서 request를 넘기는 이유는 JSP가 Servlet이 받은 요청 정보를 이어서 사용해야 하기 때문이다.

나중에는 Servlet에서 다음처럼 데이터를 담을 수 있다.

request.setAttribute("memos", memoService.getMemos());

그러면 JSP에서 그 데이터를 꺼내 화면에 출력할 수 있다.

흐름은 다음과 같다.

Servlet이 request에 데이터 저장
→ forward
→ JSP가 request에서 데이터 꺼내 출력

즉 request는 Servlet과 JSP 사이에서 데이터를 전달하는 통로로도 사용된다.

response를 넘기는 이유

response를 넘기는 이유는 JSP가 최종 HTML 응답을 브라우저로 보내야 하기 때문이다.

JSP 코드에서는 response가 직접 보이지 않지만, JSP가 생성하는 HTML은 결국 response에 기록된다.

따라서 JSP가 같은 응답 객체를 이어서 사용해야 한다.

Servlet이 받은 response
→ JSP로 전달
→ JSP가 HTML을 response에 기록
→ Tomcat이 브라우저로 전송

forward와 redirect 차이

이번에는 forward를 사용했다.

forward(request, response)

forward는 서버 내부 이동이다.

브라우저는 /memos로 요청
서버 내부에서 JSP로 이동
주소창은 /memos 그대로
request 유지

반면 redirect는 브라우저에게 다시 요청하라고 시키는 방식이다.

response.sendRedirect("/memos");

흐름은 다음과 같다.

서버가 브라우저에게 /memos로 다시 가라고 응답
브라우저가 새 요청을 보냄
request 새로 만들어짐

현재는 Servlet이 받은 request와 response를 JSP가 이어서 사용해야 하므로 forward를 사용한다.

이번 단계의 전체 흐름은 다음과 같다.

브라우저가 /memos 요청
→ Tomcat이 request, response 생성
→ MemoServlet.doGet(request, response) 실행
→ Servlet이 getRequestDispatcher로 JSP 위치 지정
→ forward(request, response)로 JSP에 전달
→ JSP가 HTML을 response에 작성
→ Tomcat이 완성된 response를 브라우저에 전송

이제 Servlet이 직접 HTML을 쓰지 않고, JSP가 화면을 담당하게 되었다.

이번 단계에서는 Servlet과 JSP의 역할을 분리했다.

기존 구조는 다음과 같았다.

Servlet이 요청 처리와 HTML 출력 모두 담당

변경 후 구조는 다음과 같다.

Servlet
→ 요청 처리와 흐름 제어 담당

JSP
→ HTML 화면 출력 담당

`request.getRequestDispatcher(...).forward(request, response)`는 단순히 외워야 하는 코드가 아니라, 다음 의미를 가진다.

현재 요청과 응답을 유지한 채
서버 내부에서 JSP에게 화면 출력을 맡긴다.

그리고 response는 완성된 결과물이 아니라, 브라우저로 나갈 응답을 담는 객체다.

Tomcat이 response를 만든다.
Servlet 또는 JSP가 response를 채운다.
Tomcat이 최종 response를 브라우저로 보낸다.

이 구조를 이해하니 Servlet/JSP가 블랙박스처럼 느껴지는 부분이 조금 줄었다.

다음 단계에서는 Servlet에서 메모 데이터를 request에 담고, JSP에서 그 데이터를 출력하는 방식으로 확장해볼 예정이다.

#22 Tomcat으로 Servlet 실행하기

sqaxe1 — Sun, 21 Jun 2026 16:45:23 +0900

이번 단계에서는 Java 콘솔 메모장에서 한 단계 넘어가, 브라우저 요청을 Java Servlet이 처리하도록 만들었다.

먼저 Servlet이 정상적으로 실행되는지 확인하겠다.

지금까지는 콘솔에서 Java 프로그램을 실행했다.

사용자 입력
→ Main
→ MemoService
→ 콘솔 출력

이번 단계부터는 브라우저에서 요청을 보내고, Tomcat이 그 요청을 받아 Servlet을 실행하는 구조로 넘어간다.

브라우저 요청
→ Tomcat
→ Servlet
→ 브라우저 응답

즉, 콘솔에서 직접 실행하던 Java 코드가 아니라, 브라우저 요청을 Java 서버가 받는 구조를 처음 확인하는 것이 목적이었다.

Servlet/JSP 프로젝트 생성

Memo Evolution 프로젝트 안에 새 Maven 모듈을 만들었다.

servlet-jsp-memo/

현재 전체 학습 프로젝트 구조는 다음처럼 발전했다.

Memo Evolution/
├─ react-memo/
├─ java-console-memo/
└─ servlet-jsp-memo/

servlet-jsp-memo는 Servlet/JSP 학습을 위한 Maven 웹 프로젝트다.

기존 java-console-memo가 콘솔에서 Java CRUD 흐름을 연습하기 위한 단계였다면,
이번 servlet-jsp-memo는 브라우저 요청을 Java 코드로 처리하는 단계다.

pom.xml 설정

Servlet을 사용하기 위해 pom.xml에 Servlet API 의존성을 추가했다.

처음에는 jakarta.servlet-api를 사용했지만, 현재 사용 중인 Tomcat 버전이 9였기 때문에 맞지 않았다.

Tomcat 9는 javax.servlet 기반이다.

그래서 최종적으로는 다음 의존성을 사용했다.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>4.0.1</version>
    <scope>provided</scope>
</dependency>

여기서 중요한 점은 Tomcat 버전과 Servlet API 패키지를 맞춰야 한다는 것이다.

Tomcat 9
→ javax.servlet 사용

Tomcat 10 이상
→ jakarta.servlet 사용

이 버전 차이를 맞추지 않으면 Servlet이 정상적으로 등록되지 않아 404가 발생할 수 있다.

Servlet 클래스 만들기

브라우저 요청을 처리하기 위해 MemoServlet 클래스를 만들었다.

파일 위치는 다음과 같다.

servlet-jsp-memo/src/main/java/com/memo/MemoServlet.java

작성한 코드는 다음과 같다.

package com.memo;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import java.io.IOException;

@WebServlet("/memos")
public class MemoServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        response.setContentType("text/html;charset=UTF-8");
        response.getWriter().println("<h1>Servlet 메모장</h1>");
        response.getWriter().println("<p>Servlet이 정상적으로 실행되었습니다.</p>");
    }
}

이번 단계에서는 메모 목록을 출력하거나 저장하지 않았다.
Servlet이 요청을 받고 HTML 응답을 돌려주는지만 확인했다.

HttpServlet 상속

MemoServlet은 HttpServlet을 상속한다.

public class MemoServlet extends HttpServlet

Servlet은 일반 Java 클래스처럼 main()으로 실행되지 않는다.

Java 콘솔 프로그램은 main 메서드가 시작점이었다.

public static void main(String[] args) {
}

하지만 Servlet은 Tomcat 같은 Servlet Container가 실행해준다.

정리하면 다음과 같다.

Java 콘솔
→ main 메서드가 시작점

Servlet
→ Tomcat이 요청에 맞는 Servlet을 실행

이 점이 콘솔 프로그램과 Servlet의 큰 차이였다.

@WebServlet으로 URL 연결하기

@WebServlet은 URL과 Servlet을 연결한다.

@WebServlet("/memos")

이 코드는 다음 의미다.

/memos 요청이 들어오면 MemoServlet이 처리한다.

즉 브라우저에서 다음 주소로 요청하면,

http://localhost:8080/memos

Tomcat은 /memos에 매핑된 MemoServlet을 실행한다.

doGet 메서드

브라우저 주소창으로 접속하는 요청은 보통 GET 요청이다.

그래서 /memos로 접속하면 doGet()이 실행된다.

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
}

흐름은 다음과 같다.

GET /memos
→ doGet 실행

이번 단계에서는 doGet() 안에서 간단한 HTML 응답을 만들어 브라우저로 보냈다.

request와 response

doGet()에는 두 개의 중요한 객체가 들어온다.

HttpServletRequest request
HttpServletResponse response

request는 브라우저가 보낸 요청 정보를 담고 있다.

예를 들면 다음과 같은 정보가 들어갈 수 있다.

요청 URL
요청 파라미터
form 데이터
요청 방식

response는 브라우저에 돌려줄 응답을 만들 때 사용한다.

예를 들면 다음과 같은 응답을 만들 수 있다.

HTML 응답
문자 인코딩
상태 코드

이번 단계에서는 response를 사용해 간단한 HTML을 보냈다.

response.setContentType("text/html;charset=UTF-8");
response.getWriter().println("<h1>Servlet 메모장</h1>");
response.getWriter().println("<p>Servlet이 정상적으로 실행되었습니다.</p>");

이 코드는 브라우저에게 HTML 응답을 보내는 코드다.

Tomcat 연결

Servlet은 혼자 실행되지 않기 때문에 Tomcat이 필요하다.

IntelliJ에서 Tomcat 실행 설정을 만들었다.

Run
→ Edit Configurations
→ Tomcat Server
→ Local

그리고 Deployment 탭에서 다음 artifact를 추가했다.

servlet-jsp-memo:war exploded

war → Tomcat에 배포 가능한 웹 애플리케이션 형식
exploded → 압축하지 않고 폴더 형태로 펼쳐진 배포 방식

이라서 보통 개발중에는 exploded를 쓴다.

Tomcat 실행 흐름은 다음과 같다.

Tomcat 실행
→ servlet-jsp-memo 배포
→ 브라우저 요청 대기
→ /memos 요청 처리

여기서 Tomcat은 브라우저 요청을 받아 적절한 Servlet으로 전달하는 역할을 한다.

8080 포트 충돌 문제

처음 Tomcat 실행 시 8080 포트 충돌이 발생했다.

로그에는 다음과 같은 메시지가 있었다.

Caused by: java.net.BindException: Address already in use

뜻은 다음과 같다.

8080 포트를 이미 다른 프로그램이 사용 중이다.

확인해보니 Docker 컨테이너가 8080 포트를 사용하고 있었다.

heartdoor-server-backend-1
0.0.0.0:8080->8080/tcp

그래서 해당 컨테이너를 중지했다.

docker stop heartdoor-server-backend-1

이후 Tomcat이 정상적으로 8080 포트에서 실행되었다.

이번 문제를 통해 서버를 실행할 때는 포트 충돌도 확인해야 한다는 것을 알게 되었다.

404 문제

Tomcat은 정상 실행되고 artifact도 배포되었지만, 처음에는 /memos 접속 시 404가 나왔다.

원인은 Tomcat 버전과 Servlet API 패키지가 맞지 않았기 때문이다.

처음 코드와 의존성은 jakarta.servlet 기준이었다.

import jakarta.servlet.http.HttpServlet;

하지만 사용 중인 Tomcat은 9였다.

Tomcat 9
→ javax.servlet 기반

그래서 import를 아래처럼 수정했다.

import javax.servlet.http.HttpServlet;

그리고 pom.xml도 javax.servlet-api로 변경했다.

<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>

수정 후 Tomcat을 다시 실행하자 /memos 요청이 정상 처리되었다.

정상 실행 결과

브라우저에서 다음 주소로 접속했다.

http://localhost:8080/memos

정상적으로 다음 화면이 출력되었다.

이로써 브라우저 요청이 Java Servlet까지 도달하고, Servlet이 응답을 만들어 브라우저에 돌려주는 흐름을 확인했다.

이번 단계는 Servlet/JSP 학습의 첫 단계였다.

아직 메모 CRUD를 웹으로 구현한 것은 아니지만, 브라우저 요청이 Tomcat을 거쳐 Java Servlet까지 도달하는 흐름을 확인했다.

이번 단계의 핵심은 다음과 같다.

브라우저 요청
→ Tomcat
→ MemoServlet
→ HTML 응답

이제 Java 코드가 콘솔에서만 실행되는 것이 아니라, 브라우저 요청을 처리하는 서버 코드로 동작하기 시작했다.

다음 단계에서는 이 Servlet 안에서 메모 목록을 다루고, JSP를 이용해 화면을 분리하는 방향으로 확장할 수 있을 것 같다.

#21 Java 콘솔 메모장: MemoService로 로직 분리하기

sqaxe1 — Sun, 21 Jun 2026 12:35:19 +0900

이번 단계에서는 Main.java에 있던 메모 관리 로직을 MemoService 클래스로 분리했다.

기능을 새로 추가한 것은 아니다.
이미 구현되어 있던 메모 작성, 목록 보기, 수정, 삭제 기능의 위치를 나누는 작업이다.

기존에는 Main.java 안에서 입력 처리와 메모 데이터 관리가 모두 이루어졌다.
이번에는 Main은 사용자 입력과 출력 흐름을 담당하고, MemoService는 메모 데이터를 관리하도록 역할을 나누었다.

기존 구조의 문제

기존에는 Main.java가 너무 많은 일을 하고 있었다.

메뉴 출력
사용자 입력 받기
메모 저장
메모 목록 출력
메모 수정
메모 삭제

즉, Main이 사용자 입력 흐름도 처리하고, 메모 데이터 관리도 직접 하고 있었다.

예를 들어 이전에는 Main.java 안에서 직접 리스트를 가지고 있었다.

List<Memo> memos = new ArrayList<>();

그리고 직접 메모를 추가하거나 수정하거나 삭제했다.

memos.add(memo);
memos.set(index, updateMemo);
memos.remove(index);

이 방식도 동작은 한다.

하지만 기능이 늘어날수록 Main.java가 계속 길어지고, 어떤 코드는 사용자 입력 처리인지, 어떤 코드는 메모 데이터 처리인지 구분하기 어려워질 수 있다.

그래서 이번 단계에서는 메모 관리 로직을 별도 클래스로 분리했다.

분리 후 구조

이번 단계에서는 메모 관리 로직을 MemoService로 옮겼다.

역할은 다음처럼 나누었다.

Main
→ 사용자 입력과 출력 담당

MemoService
→ 메모 데이터 관리 담당

파일 구조는 다음과 같다.

java-console-memo/src/
├─ Main.java
├─ Memo.java
└─ MemoService.java

Memo는 메모 하나의 데이터를 표현하고,
MemoService는 여러 메모를 저장하고 관리한다.

MemoService 만들기

MemoService는 메모 목록을 직접 가지고 있다.

import java.util.ArrayList;
import java.util.List;

public class MemoService {
    private List<Memo> memos = new ArrayList<>();
}

이제 memos 리스트는 Main이 아니라 MemoService 안에 있다.

Main이 직접 메모 목록을 관리하지 않는다.
MemoService가 메모 목록을 관리한다.

이렇게 하면서 Main의 책임을 줄이고, 메모 데이터 관리 책임을 MemoService로 옮겼다.

메모 추가 로직 분리

기존에는 Main에서 직접 메모 객체를 만들고 리스트에 추가했다.

Memo memo = new Memo(title, content);
memos.add(memo);

이제는 MemoService 안에 메모 추가 메서드를 만들었다.

public void addMemo(String title, String content) {
    Memo memo = new Memo(title, content);
    memos.add(memo);
}

Main에서는 직접 리스트에 추가하지 않고, 메서드를 호출만 한다.

memoService.addMemo(title, content);

흐름은 다음처럼 바뀌었다.

Main
→ 제목과 내용을 입력받는다.
→ memoService.addMemo(title, content)를 호출한다.

MemoService
→ Memo 객체를 만든다.
→ memos 리스트에 저장한다.

메모 목록 조회

목록을 출력하려면 Main에서 메모 목록을 가져와야 한다.

그래서 MemoService에 getMemos()를 만들었다.

public List<Memo> getMemos() {
    return memos;
}

Main에서는 이 메서드를 통해 메모 목록을 가져온다.

Memo memo = memoService.getMemos().get(i);

현재는 getMemos()로 리스트를 그대로 반환하고 있다.
나중에는 외부에서 리스트를 직접 수정하지 못하게 구조를 더 다듬을 수도 있겠지만, 지금 단계에서는 역할 분리를 먼저 연습하는 데 집중했다.

메모 수정 로직 분리

기존에는 Main에서 직접 리스트의 특정 위치를 교체했다.

Memo updateMemo = new Memo(newTitle, newContent);
memos.set(index, updateMemo);

이제는 MemoService에 수정 메서드를 만들었다.

public void editMemo(int index, String newTitle, String newContent) {
    Memo updatedMemo = new Memo(newTitle, newContent);
    memos.set(index, updatedMemo);
}

Main에서는 이렇게 호출한다.

memoService.editMemo(index, newTitle, newContent);

즉, Main은 “몇 번째 메모를 어떤 값으로 수정할지”만 전달하고, 실제 리스트 교체는 MemoService가 처리한다.

메모 삭제 로직 분리

삭제도 마찬가지다.

기존에는 Main에서 직접 삭제했다.

memos.remove(index);

이제는 MemoService에 삭제 메서드를 만들었다.

public void deleteMemo(int index) {
    memos.remove(index);
}

Main에서는 이렇게 호출한다.

memoService.deleteMemo(index);

삭제할 index는 Main에서 사용자 입력을 받아 계산하고, 실제 삭제 처리는 MemoService에게 맡긴다.

비어 있는지 확인, 크기 확인

Main에서는 메모가 비어 있는지 확인하거나, 메모 개수를 알아야 한다.

예를 들어 목록을 출력할 때 메모가 하나도 없으면 안내 문구를 보여줘야 한다.
수정이나 삭제를 할 때도 입력한 번호가 유효한지 확인하려면 전체 개수가 필요하다.

그래서 MemoService에 다음 메서드도 만들었다.

public boolean isEmpty() {
    return memos.isEmpty();
}

public int size() {
    return memos.size();
}

이제 Main은 직접 리스트를 가지고 있지 않지만, 필요한 정보는 MemoService에게 물어볼 수 있다.

memoService.isEmpty()
memoService.size()

Main.java의 변화

이제 Main.java에서는 List<Memo>를 직접 만들지 않는다.

기존에는 다음처럼 작성했다.

List<Memo> memos = new ArrayList<>();

변경 후에는 MemoService 객체를 만든다.

MemoService memoService = new MemoService();

그리고 각 기능을 실행할 때 memos를 직접 넘기는 대신 memoService를 넘긴다.

addMemo(scanner, memoService);
printMemos(memoService);
editMemo(scanner, memoService);
deleteMemo(scanner, memoService);

즉, Main은 메모 목록 자체를 직접 다루기보다, MemoService를 통해 메모 기능을 사용한다.

역할 분리 후 흐름

메모 작성 흐름은 이렇게 바뀌었다.

Main
→ 제목과 내용을 입력받는다.
→ memoService.addMemo(title, content)를 호출한다.

MemoService
→ Memo 객체를 만든다.
→ memos 리스트에 저장한다.

메모 수정 흐름은 다음과 같다.

Main
→ 수정할 번호와 새 제목/내용을 입력받는다.
→ memoService.editMemo(index, newTitle, newContent)를 호출한다.

MemoService
→ 해당 index의 메모를 새 Memo 객체로 교체한다.

메모 삭제 흐름도 마찬가지다.

Main
→ 삭제할 번호를 입력받는다.
→ memoService.deleteMemo(index)를 호출한다.

MemoService
→ 해당 index의 메모를 삭제한다.

각 기능에서 실제 데이터 처리는 MemoService가 담당하고, Main은 사용자와 주고받는 흐름에 집중한다.

현재 상태

현재 Java 콘솔 메모장은 다음 구조를 가진다.

Main.java
→ 메뉴 출력, 사용자 입력, 결과 출력

Memo.java
→ 메모 하나의 데이터 표현

MemoService.java
→ 메모 목록 관리, 추가, 수정, 삭제

기능은 이전과 같다.

메모 작성
메모 목록 보기
메모 수정
메모 삭제
프로그램 종료

하지만 기능이 들어 있는 위치가 정리되었다.

#20 Java 콘솔 메모장 : String 배열에서 Memo 클래스로 변경하기

sqaxe1 — Sun, 21 Jun 2026 09:40:05 +0900

이번 단계에서는 메모 하나를 String[] 배열이 아니라 Memo 클래스로 표현하도록 변경했다.

이전 단계에서는 Java 콘솔에서 메모 작성, 목록 보기, 수정, 삭제 기능을 구현했다.

그때 메모 하나는 다음처럼 문자열 배열로 저장했다.

String[] memo = {title, content};

그리고 값을 꺼낼 때는 배열 인덱스를 사용했다.

memo[0] // 제목
memo[1] // 내용

이 방식도 동작은 한다.

하지만 코드를 볼 때 memo[0]이 제목인지, memo[1]이 내용인지 계속 기억해야 한다.

그래서 이번 단계에서는 메모 하나를 더 명확하게 표현하기 위해 Memo 클래스를 만들었다.

기존에는 메모 하나를 String[] 배열로 다뤘다.

String[] memo = {title, content};

전체 메모 목록은 다음처럼 선언했다.

List<String[]> memos = new ArrayList<>();

이 구조에서는 메모 하나가 배열이기 때문에 제목과 내용을 인덱스로 구분해야 했다.

memo[0] // 제목
memo[1] // 내용

작은 프로그램에서는 크게 문제되지 않을 수 있다.

하지만 코드가 조금만 길어져도 memo[0]이 무엇을 의미하는지 바로 보이지 않는다.

예를 들어 목록을 출력할 때도 다음처럼 작성해야 했다.

System.out.println((i + 1) + ". " + memo[0]);
System.out.println(memo[1]);

동작은 하지만 의미가 명확하지 않았다.

Memo 클래스 만들기

그래서 메모 하나를 표현하는 Memo 클래스를 만들었다.

public class Memo {
    private String title;
    private String content;

    public Memo(String title, String content) {
        this.title = title;
        this.content = content;
    }

    public String getTitle() {
        return title;
    }

    public String getContent() {
        return content;
    }
}

이제 메모 하나는 단순한 문자열 배열이 아니라 Memo 객체가 되었다.

Memo
→ title
→ content

title과 content라는 이름이 생겼기 때문에, 메모가 어떤 데이터를 가지고 있는지 더 명확해졌다.

필드를 private으로 둔 이유

Memo 클래스 안의 필드는 private으로 만들었다.

private String title;
private String content;

private으로 두면 클래스 밖에서 필드에 직접 접근할 수 없다.

대신 값을 가져올 때는 getter 메서드를 사용한다.

public String getTitle() {
    return title;
}

public String getContent() {
    return content;
}

지금은 단순히 값을 꺼내는 정도지만, 이렇게 작성하면 나중에 클래스 내부 구조를 조금 더 안전하게 관리할 수 있다.

생성자의 역할

Memo 객체를 만들 때는 생성자를 사용한다.

public Memo(String title, String content) {
    this.title = title;
    this.content = content;
}

이 생성자는 제목과 내용을 받아서 Memo 객체 안에 저장한다.

예를 들어 다음 코드를 실행하면,

Memo memo = new Memo(title, content);

입력받은 title, content 값이 Memo 객체의 필드에 들어간다.

List 타입 변경

기존에는 문자열 배열 목록을 사용했다.

List<String[]> memos = new ArrayList<>();

이제는 Memo 객체 목록으로 변경했다.

List<Memo> memos = new ArrayList<>();

즉, memos는 이제 문자열 배열이 아니라 Memo 객체들을 저장하는 리스트다.

기존:
List<String[]>

변경 후:
List<Memo>

이 변화만으로도 코드의 의미가 더 명확해졌다.

memos 리스트 안에는 메모 객체들이 들어간다는 것을 타입만 봐도 알 수 있다.

메모 작성 코드 변경

기존에는 제목과 내용을 배열로 묶어서 저장했다.

String[] memo = {title, content};
memos.add(memo);

변경 후에는 Memo 객체를 생성해서 저장한다.

Memo memo = new Memo(title, content);
memos.add(memo);

흐름은 비슷하다.

제목 입력
→ 내용 입력
→ Memo 객체 생성
→ memos 리스트에 추가

차이는 메모 하나를 배열로 만들었는지, 클래스로 만들었는지다.

메모 목록 출력 코드 변경

기존에는 배열 인덱스로 제목과 내용을 꺼냈다.

System.out.println((i + 1) + ". " + memo[0]);
System.out.println(memo[1]);

변경 후에는 getter 메서드를 사용했다.

System.out.println((i + 1) + ". " + memo.getTitle());
System.out.println(memo.getContent());

이제 코드를 읽었을 때 의미가 더 분명하다.

memo.getTitle()
→ 메모 제목을 가져온다.

memo.getContent()
→ 메모 내용을 가져온다.

memo[0], memo[1]보다 훨씬 읽기 쉽다.

메모 수정 코드 변경

수정할 때도 기존에는 새 배열을 만들어 교체했다.

String[] updateMemo = {newTitle, newContent};
memos.set(index, updateMemo);

변경 후에는 새 Memo 객체를 만들어 교체했다.

Memo updateMemo = new Memo(newTitle, newContent);
memos.set(index, updateMemo);

즉, 해당 위치의 기존 메모 객체를 새 메모 객체로 바꾸는 방식이다.

수정 흐름은 이전과 같다.

수정할 번호 입력
→ index 계산
→ 새 제목 입력
→ 새 내용 입력
→ 새 Memo 객체 생성
→ memos.set(index, updateMemo)

바뀐 것은 데이터 표현 방식이다.

삭제 코드는 거의 그대로

삭제 기능은 크게 바뀌지 않았다.

삭제는 특정 index의 메모를 리스트에서 제거하는 작업이기 때문이다.

memos.remove(index);

기존에는 List<String[]>에서 제거했고, 이제는 List<Memo>에서 제거한다.

리스트 안에 들어 있는 타입은 바뀌었지만, 삭제 흐름 자체는 그대로다.

이번 단계에서 가장 크게 바뀐 점은 메모 하나를 표현하는 방식이다.

기존 방식은 다음과 같았다.

메모 하나 = String 배열

memo[0] = 제목
memo[1] = 내용

변경 후에는 다음과 같다.

메모 하나 = Memo 객체

memo.getTitle() = 제목
memo.getContent() = 내용

기능이 새로 늘어난 것은 아니지만, 코드의 의미가 더 명확해졌다.

처음에는 String[]만으로도 충분해 보였다.

하지만 메모에 필요한 정보가 늘어나면 배열 방식은 금방 불편해진다.

예를 들어 나중에 다음 정보가 추가될 수 있다.

id
작성일
수정일
중요 표시
카테고리

배열로 계속 관리한다면 이런 식으로 외워야 한다.

memo[0] // 제목
memo[1] // 내용
memo[2] // 작성일
memo[3] // 수정일

이렇게 되면 코드가 점점 헷갈린다.

반면 클래스를 사용하면 필드 이름으로 의미를 표현할 수 있다.

memo.getTitle()
memo.getContent()
memo.getCreatedAt()

그래서 이번 단계에서 Memo 클래스로 바꾼 것은 나중에 구조를 확장하기 위한 준비이기도 하다.

아직 파일 저장이나 DB 저장은 없다.
프로그램을 종료하면 메모는 사라진다.

하지만 이번 단계에서는 저장 기능보다, Java에서 데이터를 더 명확한 구조로 표현하는 데 집중했다.

다음 단계에서는 이 구조를 바탕으로 기능을 더 나누거나, 메모 저장 방식을 개선해볼 수 있을 것 같다.

#19 Java 콘솔 메모장: CRUD기능 구현하기

sqaxe1 — Sat, 20 Jun 2026 16:55:11 +0900

이번 단계에서는 Java 콘솔 메모장에 실제 CRUD 기능을 붙였다.

이전 단계에서는 메뉴만 출력하고, 각 메뉴를 선택했을 때 “아직 구현되지 않았습니다.”라는 안내 문구만 출력했다.

이번에는 사용자가 콘솔에서 직접 메모를 작성하고, 목록을 보고, 수정하고, 삭제할 수 있도록 만들었다.

현재 프로그램 흐름

현재 콘솔 메모장은 다음과 같은 메뉴를 가진다.

===== 메모장 =====
1. 메모 작성
2. 메모 목록 보기
3. 메모 수정
4. 메모 삭제
0. 종료
메뉴 선택:

사용자는 번호를 입력해서 원하는 기능을 실행한다.

1 → 메모 작성
2 → 메모 목록 보기
3 → 메모 수정
4 → 메모 삭제
0 → 프로그램 종료

이전에는 메뉴만 있었고 실제 기능은 없었다.
이번 단계부터는 각 메뉴가 실제로 메모 데이터를 처리한다.

메모를 저장할 List 만들기

여러 개의 메모를 저장하기 위해 List를 사용했다.

List<String[]> memos = new ArrayList<>();

여기서 memos는 전체 메모 목록이다.

메모 하나는 아직 별도의 클래스로 만들지 않고, 문자열 배열로 저장했다.

String[] memo = {title, content};

현재 구조에서는 메모 하나가 다음처럼 구성된다.

memo[0] = 제목
memo[1] = 내용

즉, 전체 메모 목록은 개념적으로 이런 형태가 된다.

memos
→ [
    ["제목1", "내용1"],
    ["제목2", "내용2"],
    ["제목3", "내용3"]
  ]

JavaScript에서 배열에 메모 객체를 넣었던 것과 비슷하다.

JavaScript에서는 다음처럼 추가했다.

memos.push(newMemo)

Java에서는 다음처럼 추가한다.

memos.add(memo);

입력 처리는 nextLine으로 통일

처음에는 메뉴 입력에 scanner.nextInt()를 사용했다.

하지만 이후 제목과 내용 입력까지 함께 처리하다 보니 nextInt()와 nextLine()을 섞어 쓰는 것이 헷갈릴 수 있었다.

그래서 이번에는 입력 처리를 nextLine() 기준으로 통일했다.

int menu = Integer.parseInt(scanner.nextLine());

이 코드는 사용자가 입력한 문자열을 숫자로 변환해서 메뉴 번호로 사용한다.

제목과 내용도 nextLine()으로 입력받았다.

String title = scanner.nextLine();
String content = scanner.nextLine();

이렇게 하니 메뉴 입력, 제목 입력, 내용 입력 흐름을 한 방식으로 처리할 수 있었다.

1번: 메모 작성

1번 메뉴를 선택하면 제목과 내용을 입력받는다.

if (menu == 1) {
    System.out.println("제목을 입력해 주세요");
    String title = scanner.nextLine();

    System.out.println("내용을 입력해 주세요");
    String content = scanner.nextLine();

    String[] memo = {title, content};
    memos.add(memo);

    System.out.println("저장 완료되었습니다.");
}

흐름은 다음과 같다.

제목 입력 안내
→ 제목 입력받기
→ 내용 입력 안내
→ 내용 입력받기
→ 제목과 내용을 String[]로 묶기
→ memos에 추가하기
→ 저장 완료 메시지 출력

여기서 중요한 부분은 제목과 내용을 하나의 메모로 묶는 부분이다.

String[] memo = {title, content};

그리고 이 메모 하나를 전체 메모 목록에 추가한다.

memos.add(memo);

이제 프로그램이 실행 중인 동안에는 작성한 메모가 memos 리스트 안에 저장된다.

2번: 메모 목록 보기

2번 메뉴를 선택하면 저장된 메모 목록을 출력한다.

else if (menu == 2) {
    if (memos.isEmpty()) {
        System.out.println("작성된 메모가 없습니다.");
    } else {
        for (int i = 0; i < memos.size(); i++) {
            String[] memo = memos.get(i);

            System.out.println((i + 1) + ". " + memo[0]);
            System.out.println(memo[1]);
        }
    }
}

먼저 메모가 비어 있는지 확인했다.

memos.isEmpty()

메모가 없으면 안내 문구를 출력한다.

작성된 메모가 없습니다.

메모가 있으면 for문으로 전체 메모를 출력한다.

for (int i = 0; i < memos.size(); i++)

그리고 memos.get(i)로 i번째 메모를 꺼낸다.

String[] memo = memos.get(i);

출력할 때는 i + 1을 사용했다.

System.out.println((i + 1) + ". " + memo[0]);

Java 리스트의 index는 0부터 시작하지만, 사용자에게 보여줄 번호는 1부터 시작하는 것이 자연스럽기 때문이다.

리스트 index: 0, 1, 2
사용자 번호: 1, 2, 3

3번: 메모 수정

3번 메뉴에서는 수정할 메모 번호를 입력받고, 해당 메모를 새 제목과 새 내용으로 교체한다.

수정 기능의 흐름은 다음과 같다.

수정할 메모 번호 입력
→ 사용자 번호를 index로 변환
→ index 범위 검사
→ 새 제목 입력
→ 새 내용 입력
→ 새 메모 배열 생성
→ memos.set(index, updatedMemo)로 교체

사용자가 보는 번호는 1부터 시작하지만, List의 index는 0부터 시작한다.

그래서 다음 계산이 필요하다.

int index = memoNumber - 1;

예를 들어 사용자가 1번 메모를 수정하려고 하면 실제 index는 0이다.

사용자 번호 1 → index 0
사용자 번호 2 → index 1
사용자 번호 3 → index 2

범위 검사도 필요하다.

if (index < 0 || index >= memos.size()) {
    System.out.println("올바른 메모 번호를 입력하세요.");
}

이 검사를 하지 않으면 존재하지 않는 위치에 접근할 수 있다.

올바른 번호라면 새 제목과 내용을 입력받아 기존 메모를 교체한다.

String[] updatedMemo = {newTitle, newContent};
memos.set(index, updatedMemo);

여기서 memos.set(index, updatedMemo)는 해당 위치의 메모를 새 메모로 바꾸는 코드다.

4번: 메모 삭제

4번 메뉴에서는 삭제할 메모 번호를 입력받고, 해당 메모를 삭제한다.

삭제 기능은 수정 기능과 흐름이 거의 비슷하다.

삭제할 메모 번호 입력
→ 사용자 번호를 index로 변환
→ index 범위 검사
→ memos.remove(index)로 삭제

삭제의 핵심은 다음 코드다.

memos.remove(index);

이 코드는 memos 리스트에서 해당 index 위치의 메모를 제거한다.

예를 들어 사용자가 2번 메모를 삭제한다고 하면,

int index = 2 - 1;

결과는 다음과 같다.

index = 1;

따라서 다음 코드로 두 번째 메모가 삭제된다.

memos.remove(1);

수정과 삭제의 공통점

수정과 삭제는 모두 사용자가 보는 번호와 실제 List index를 연결해야 한다.

사용자 번호 1 → index 0
사용자 번호 2 → index 1
사용자 번호 3 → index 2

그래서 공통적으로 다음 계산을 사용한다.

int index = memoNumber - 1;

그리고 잘못된 번호가 들어오지 않도록 범위 검사를 한다.

if (index < 0 || index >= memos.size()) {
    System.out.println("올바른 메모 번호를 입력하세요.");
}

이 부분은 단순해 보이지만 중요했다.
사용자가 존재하지 않는 번호를 입력했을 때 프로그램이 바로 오류로 멈추지 않도록 막아주는 역할을 한다.

현재 사용한 자료구조

이번 단계에서는 List<String[]> 구조를 사용했다.

List<String[]> memos = new ArrayList<>();

메모 하나를 String[]로 다루는 방식이다.

String[] memo = {title, content};

아직 완성형 구조는 아니다.

제목은 memo[0], 내용은 memo[1]로 접근해야 하기 때문에 코드가 길어지면 헷갈릴 수 있다.

나중에는 String[] 대신 Memo 클래스를 만들어서 더 명확하게 바꿀 예정이다.

예를 들면 다음과 같은 구조다.

class Memo {
    private String title;
    private String content;
}

하지만 지금 단계에서는 클래스 설계보다 Java에서 CRUD 흐름을 먼저 익히는 것이 목적이다.

그래서 배열과 리스트를 이용해 메모 데이터를 먼저 다뤄봤다.

이번 단계에서 사용한 Java 개념

이번 단계에서는 Java의 기본 문법을 사용해서 CRUD 흐름을 만들었다.

List
ArrayList
String[]
Scanner
nextLine
Integer.parseInt
for문
if / else if
isEmpty
get
add
set
remove

React에서는 state 배열을 기준으로 메모를 추가, 수정, 삭제했다.

Java 콘솔에서는 List를 기준으로 메모를 추가, 수정, 삭제했다.

도구와 환경은 다르지만 결국 흐름은 비슷했다.

메모 작성 → 데이터 추가
메모 목록 → 데이터 전체 조회
메모 수정 → 특정 데이터 교체
메모 삭제 → 특정 데이터 제거

현재 구현된 기능

현재 Java 콘솔 메모장은 다음 기능을 가진다.

메모 작성
메모 목록 보기
메모 수정
메모 삭제
프로그램 종료

아직 파일 저장이나 DB 저장은 없다.

프로그램을 종료하면 메모는 사라진다.
현재 메모는 프로그램이 실행되는 동안만 memos 리스트 안에 존재한다.

하지만 이번 단계의 목적은 저장소를 만드는 것이 아니라, Java에서 메모 데이터를 어떻게 다루는지 연습하는 것이다.

정리

이번 단계에서는 Java 콘솔 환경에서 CRUD 기능을 직접 구현했다.

브라우저나 React 없이도 다음 흐름을 Java 코드로 만들 수 있게 되었다.

입력받기
데이터 저장하기
목록 출력하기
기존 데이터 수정하기
기존 데이터 삭제하기

이 구조는 나중에 Servlet/JSP나 Spring으로 넘어갈 때도 이어질 수 있다.

콘솔 입력
→ 나중에는 브라우저 요청

List에 저장
→ 나중에는 DB에 저장

if문으로 기능 분기
→ 나중에는 Controller에서 요청 분기

즉, 이번 단계는 Java 웹 개발로 넘어가기 전에 메모 CRUD 로직을 Java 문법으로 먼저 익혀보는 과정이었다.

다음 단계에서는 String[]로 메모를 다루는 방식에서 벗어나, Memo 클래스를 만들어 메모 데이터를 조금 더 명확한 구조로 바꿔볼 예정이다.

#18 Java 콘솔 메모장 시작 중 만난 IntelliJ 설정 문제

sqaxe1 — Sat, 20 Jun 2026 13:12:12 +0900

Java 콘솔 메모장을 시작하면서 IntelliJ에서 이상한 문제가 생겼다.

sout을 입력했을 때 System.out.println() 자동완성은 되는데, Scanner에는 빨간줄이 뜨지 않고 import java.util.Scanner; 추천도 나오지 않았다.

처음에는 JDK 문제라고 생각했지만, 확인해보니 단순히 JDK만의 문제는 아니었다.

문제 상황

작성한 코드는 다음과 같았다.

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
    }
}

정상이라면 Scanner에 빨간줄이 뜨고, IntelliJ가 다음 import를 추천해야 한다.

import java.util.Scanner;

하지만 실제로는 빨간줄도 없고, import 추천도 나오지 않았다.

즉, IntelliJ가 Java 코드를 제대로 분석하지 않고 있었다.

먼저 확인한 것: JDK 설정

Java 프로젝트에서는 JDK 설정이 필요하다.

IntelliJ에서는 메뉴 이름이 SDK로 나오지만, Java 기준으로는 JDK라고 이해하면 된다.

확인 경로는 다음과 같다.

File
→ Project Structure...
→ Project

여기서 SDK가 No SDK로 되어 있으면 Java 기능이 제대로 동작하지 않는다.

정상 예시는 다음과 같다.

SDK: temurin-17

JDK가 잡혀 있어야 IntelliJ가 Java 표준 라이브러리를 인식할 수 있다.

예를 들어 다음 클래스들은 JDK 안에 있다.

String
System
Scanner
List
ArrayList

따라서 JDK가 없으면 자동완성, import 추천, 컴파일, 실행 기능이 제대로 동작하지 않는다.

SDK와 JDK 용어 정리

처음에는 SDK와 JDK라는 말이 섞여서 헷갈렸다.

정리하면 다음과 같다.

JDK
→ Java 개발 도구

SDK
→ 개발 도구 묶음을 부르는 일반적인 이름

IntelliJ에서 Project SDK라고 나오는 것은 Java 프로젝트에서는 사실상 JDK를 선택하라는 뜻이다.

즉, 이렇게 이해하면 된다.

IntelliJ의 SDK 설정 = Java에서는 JDK 설정

Language level 확인

JDK를 설정한 뒤에는 Language level도 확인했다.

확인 경로는 같다.

File
→ Project Structure...
→ Project

여기서 SDK는 temurin-17인데, Language level이 이상하게 높은 버전으로 되어 있었다.

예를 들면 다음과 같다.

Language level: 26 - No new language features

JDK 17을 사용할 거라면 Language level도 17로 맞추는 것이 좋다.

Language level: 17

JDK 버전과 Language level이 맞지 않으면 프로젝트 설정이 꼬여 보일 수 있다.

Highlight 설정 확인

JDK가 설정되어 있는데도 빨간줄이 나오지 않았다.

에디터 오른쪽 위를 보니 OFF가 표시되어 있었다.
이 상태는 코드 분석 또는 하이라이팅이 꺼져 있는 상태였다.

오른쪽 위 OFF를 눌러보면 다음과 비슷한 메뉴가 나온다.

Highlight: None
Syntax
All Problems

여기서 None이면 코드 분석이 꺼진 상태다.

정상적으로 오류 표시와 import 추천을 보려면 다음으로 바꿔야 한다.

All Problems

이 설정이 꺼져 있으면 Java 코드에 문제가 있어도 빨간줄이 보이지 않을 수 있다.

Power Save Mode 확인

또 하나 확인할 것은 Power Save Mode다.

확인 경로는 다음과 같다.

File
→ Power Save Mode

이 옵션이 켜져 있으면 IntelliJ가 코드 분석, 자동완성, inspection 기능을 제한할 수 있다.

따라서 자동완성이나 빨간줄이 이상하게 동작하지 않으면 Power Save Mode가 켜져 있는지 확인해야 한다.

src 폴더 위치 확인

Java 프로젝트에서는 보통 소스 코드를 src 폴더 안에 둔다.

이번 프로젝트에서 의도한 구조는 다음과 같았다.

java-console-memo/
└─ src/
   └─ Main.java

만약 Main.java가 src 밖에 있거나, IntelliJ가 src를 소스 폴더로 인식하지 못하면 Java 코드 분석이 제대로 되지 않을 수 있다.

일반적으로는 src 폴더를 우클릭해서 다음 메뉴를 선택한다.

Mark Directory As
→ Sources Root

정상적으로 설정되면 src 폴더가 파란색 계열로 표시된다.

Sources Root 메뉴가 보이지 않았다

문제는 여기서 끝나지 않았다.

src 폴더를 우클릭했는데 Sources Root 메뉴가 보이지 않았다.

처음에는 메뉴 위치를 잘못 찾은 줄 알았지만, 실제 원인은 따로 있었다.

Project Structure에서 Modules를 확인해보니 다음처럼 나왔다.

Nothing to show

즉, IntelliJ가 현재 프로젝트에 Java 모듈을 하나도 등록하지 않은 상태였다.

모듈이 없으면 IntelliJ 입장에서는 어떤 폴더를 Java 소스 폴더로 다뤄야 하는지 알 수 없다.

그래서 src를 Sources Root로 지정하는 메뉴도 제대로 보이지 않았던 것이다.

핵심 원인

최종적으로 문제의 핵심은 다음과 같았다.

JDK는 설치되어 있었지만,
현재 프로젝트에 Java 모듈이 등록되어 있지 않았다.

그래서 IntelliJ는 파일을 단순 텍스트처럼 어느 정도 보여줄 수는 있었지만, Java 프로젝트로 제대로 분석하지 못했다.

그 결과 다음 문제가 발생했다.

Scanner 빨간줄이 안 뜸
import 추천이 안 뜸
Java 오류 분석이 안 됨
Sources Root 설정이 제대로 안 보임

즉, 코드 문제가 아니라 프로젝트 설정 문제였다.

해결 방향

이 경우에는 먼저 Java 모듈을 추가해야 한다.

확인 경로는 다음과 같다.

File
→ Project Structure...
→ Modules

여기서 아무것도 없고 Nothing to show가 나온다면, 왼쪽 위 + 버튼을 눌러 모듈을 추가해야 한다.

기존 폴더를 Java 모듈로 등록하려면 다음 순서로 진행한다.

+ 버튼
→ Import Module
→ java-console-memo 폴더 선택
→ Java 모듈로 등록
→ JDK는 temurin-17 선택

모듈이 등록되면 이후에 src 폴더를 Sources Root로 지정할 수 있다.

src 우클릭
→ Mark Directory As
→ Sources Root

이후 IntelliJ가 프로젝트를 Java 프로젝트로 제대로 인식하면 빨간줄, import 추천, 자동완성 기능도 정상적으로 동작한다.

정리 체크리스트

나중에 같은 문제가 생기면 아래 순서대로 확인하면 된다.

1. JDK 설정 확인
File → Project Structure → Project → SDK

2. Language level 확인
JDK 버전과 맞는지 확인

3. 오른쪽 위 Highlight 확인
None이 아니라 All Problems인지 확인

4. Power Save Mode 확인
File → Power Save Mode 꺼져 있는지 확인

5. Main.java 위치 확인
java-console-memo/src/Main.java 구조인지 확인

6. src가 Sources Root인지 확인
src 우클릭 → Mark Directory As → Sources Root

7. Sources Root 메뉴가 안 보이면 Modules 확인
File → Project Structure → Modules

8. Modules에 Nothing to show가 나오면 Java 모듈 추가
+ → Import Module → java-console-memo 선택

실행 과정에서 추가로 확인한 설정

Java 콘솔 메모장을 실행하려고 하면서 IntelliJ 설정 문제를 한 번 더 확인하게 되었다.

처음에는 자동 import나 빨간줄 표시 문제만 봤는데, 실행 단계에서도 빌드 관련 오류가 발생했다.

이번에도 코드 자체의 문제라기보다는 IntelliJ가 Java 프로젝트 구조를 제대로 인식하지 못해서 생긴 문제였다.

실행 시 확인한 오류

Main.java를 작성하고 실행하려고 했을 때 다음과 같은 문제가 있었다.

자동 import가 제대로 안 됨
Scanner 오류 표시가 안 보임
실행 시 빌드 관련 오류 발생

이후에는 다음 메시지도 확인했다.

The output path is not specified for module java-console-memo

이 메시지는 Java 코드를 컴파일한 결과물인 .class 파일을 어디에 저장할지 지정되어 있지 않다는 뜻이다.

Compiler output 설정 문제

Java 코드는 바로 실행되는 것이 아니라 먼저 컴파일된다.

Main.java
→ 컴파일
→ Main.class
→ 실행

그런데 IntelliJ에 컴파일 결과물을 저장할 위치가 설정되어 있지 않으면 실행할 수 없다.

그래서 Project Structure에서 Compiler output을 지정해야 했다.

경로는 다음과 같다.

File
→ Project Structure...
→ Project
→ Compiler output

여기에 예를 들어 다음과 같은 폴더를 지정한다.

/Users/woojoo/workspace/Memo Evolution/out

이 설정은 IntelliJ에게 다음을 알려주는 것이다.

Java 파일을 컴파일한 결과물을 이 폴더에 저장해라.

out 폴더의 역할

컴파일 설정을 잡으면 프로젝트에 out 폴더가 생길 수 있다.

이 폴더는 내가 직접 작성하는 소스 코드가 아니다.
IntelliJ가 Java 파일을 컴파일한 결과물을 저장하는 곳이다.

정리하면 다음과 같다.

src
→ 내가 작성하는 Java 소스 코드

out
→ 컴파일된 결과물이 저장되는 폴더

일반적으로 out 폴더는 직접 수정하지 않는다.

소스 코드는 src 안에서 작성하고, out은 IntelliJ가 빌드 결과를 저장하는 공간으로 두면 된다.

java-console-memo.iml 파일

설정을 하면서 java-console-memo.iml 파일도 생겼다.

처음에는 이 파일이 내가 만든 파일인지, 지워도 되는 파일인지 헷갈렸다.

.iml 파일은 IntelliJ가 만든 모듈 설정 파일이다.

.iml = IntelliJ Module File

즉, 내가 직접 작성하는 Java 소스 파일이 아니라 IntelliJ가 프로젝트 설정을 기억하기 위해 만든 파일이다.

이 파일 안에는 다음과 같은 정보가 들어 있다.

이 폴더가 Java 모듈이라는 정보
src 폴더가 소스 폴더라는 정보
프로젝트 JDK를 사용한다는 정보

예를 들어 파일 안에는 이런 설정이 있었다.

<sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" />

이 설정은 다음 의미다.

java-console-memo/src 폴더를 Java 소스 폴더로 인식한다.

왜 iml 파일이 생겼을까

처음에는 java-console-memo 폴더가 단순 폴더처럼 존재했다.

하지만 IntelliJ에서 이 폴더를 Java 모듈로 인식하게 만들면서 .iml 파일이 생성되었다.

즉, .iml 파일은 IntelliJ가 다음 정보를 저장하기 위해 만든 것이다.

이 폴더는 Java 모듈이다.
src 폴더는 소스 코드 폴더다.
JDK는 프로젝트 설정을 따른다.

그래서 이 파일이 생겼다는 것은 IntelliJ가 해당 폴더를 단순 폴더가 아니라 Java 모듈로 관리하기 시작했다는 의미로 볼 수 있다.

iml 파일을 삭제해도 될까

지금 단계에서는 삭제하지 않는 것이 좋다.

이 파일이 사라지면 IntelliJ가 다시 Java 모듈 정보를 잃을 수 있다.

그러면 다시 다음 문제가 생길 수 있다.

src 폴더 인식 안 됨
자동완성 이상함
import 추천 안 됨
실행 설정 꼬임

따라서 현재처럼 IntelliJ로 Java 학습을 진행하는 동안에는 유지하는 것이 안전하다.

다만 이 파일은 Java 문법이나 메모장 기능과 직접 관련된 코드는 아니다.
IntelliJ가 프로젝트를 어떻게 인식할지 저장하는 설정 파일이다.

#17 Java 콘솔 메모장 시작하기

sqaxe1 — Sat, 20 Jun 2026 13:07:15 +0900

React로 메모장 기능을 다시 구현한 뒤, 다음 단계로 Java 콘솔 메모장을 시작했다.

지금까지는 브라우저 안에서 메모장을 만들었다.

JavaScript
→ 브라우저 안에서 배열로 메모 관리

React
→ state로 메모 배열 관리

이번에는 같은 메모장 기능을 Java 코드로 다시 구현해보려고 한다.

목표는 웹 화면을 만드는 것이 아니라, Java에서 메모 데이터를 어떻게 다룰 수 있는지 연습하는 것이다.

왜 Java 콘솔부터 시작했나

바로 Servlet/JSP나 Spring으로 넘어가면 한 번에 봐야 할 개념이 너무 많아진다.

HTTP 요청
Servlet
JSP
Tomcat
DB
Controller
Service
DAO

그래서 먼저 콘솔 환경에서 Java 문법과 CRUD 흐름을 잡아보기로 했다.

콘솔 메모장은 화면은 단순하지만, 나중에 서버로 넘어가기 전 기본 로직을 연습하기에 좋다.

이번에 먼저 만들고 싶은 흐름은 다음과 같다.

메뉴 출력
→ 사용자 입력
→ 선택한 기능 실행
→ 다시 메뉴 출력
→ 종료 선택 시 프로그램 종료

이 흐름은 나중에 웹으로 넘어가도 비슷하게 이어질 수 있다.

브라우저 요청
→ Controller 또는 Servlet
→ Service
→ 결과 응답

그래서 이번 단계에서는 기능을 바로 완성하기보다, Java 콘솔 프로그램의 기본 뼈대를 먼저 만들었다.

프로젝트 구조

Java 콘솔 메모장은 React 프로젝트와 분리해서 새 폴더로 만들었다.

Memo Evolution/
├─ react-memo/
└─ java-console-memo/
   └─ src/
      └─ Main.java

Main.java는 Java 프로그램의 시작점이다.

Java에서는 main 메서드가 프로그램 실행의 출발점이 된다.

public static void main(String[] args) {
}

이번 단계에서는 이 Main.java 안에서 메뉴 출력과 입력 처리를 먼저 작성했다.

처음 작성한 Main.java

처음부터 메모 작성, 수정, 삭제 기능을 모두 만들지는 않았다.

먼저 사용자가 메뉴를 선택할 수 있는 구조부터 만들었다.

import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        boolean running = true;

        while (running) {
            System.out.println("===== 메모장 =====");
            System.out.println("1. 메모 작성");
            System.out.println("2. 메모 목록 보기");
            System.out.println("3. 메모 수정");
            System.out.println("4. 메모 삭제");
            System.out.println("0. 종료");
            System.out.print("메뉴 선택: ");

            int menu = scanner.nextInt();

            if (menu == 1) {
                System.out.println("메모 작성 기능은 아직 구현되지 않았습니다.");
            } else if (menu == 2) {
                System.out.println("메모 목록 보기 기능은 아직 구현되지 않았습니다.");
            } else if (menu == 3) {
                System.out.println("메모 수정 기능은 아직 구현되지 않았습니다.");
            } else if (menu == 4) {
                System.out.println("메모 삭제 기능은 아직 구현되지 않았습니다.");
            } else if (menu == 0) {
                running = false;
                System.out.println("프로그램을 종료합니다.");
            } else {
                System.out.println("올바른 메뉴 번호를 입력하세요.");
            }

            System.out.println();
        }

        scanner.close();
    }
}

아직 실제 메모 데이터는 없다.

현재는 사용자가 메뉴를 선택하면 해당 기능이 아직 구현되지 않았다는 문구만 출력된다.

입력을 받기 위해 Scanner 사용

콘솔에서 사용자의 입력을 받기 위해 Scanner를 사용했다.

Scanner scanner = new Scanner(System.in);

여기서는 사용자가 메뉴 번호를 입력하면 그 값을 읽는다.

int menu = scanner.nextInt();

예를 들어 사용자가 1을 입력하면 menu 변수에는 1이 들어간다.

사용자 입력: 1
menu = 1

이 값을 기준으로 어떤 기능을 실행할지 나누었다.

while문으로 메뉴 반복하기

메모장 프로그램은 메뉴를 한 번 보여주고 끝나면 안 된다.

사용자가 종료를 선택할 때까지 계속 메뉴가 나와야 한다.

그래서 while문을 사용했다.

boolean running = true;

while (running) {
    ...
}

처음에는 running 값이 true이기 때문에 반복문이 계속 실행된다.

사용자가 0을 입력하면 running을 false로 바꾼다.

running = false;

그러면 while (running) 조건이 더 이상 참이 아니게 되고, 프로그램이 종료된다.

메뉴 번호에 따라 기능 나누기

사용자가 입력한 번호에 따라 다른 동작을 해야 하므로 if / else if / else를 사용했다.

if (menu == 1) {
    System.out.println("메모 작성 기능은 아직 구현되지 않았습니다.");
} else if (menu == 2) {
    System.out.println("메모 목록 보기 기능은 아직 구현되지 않았습니다.");
}

아직 실제 기능은 구현하지 않았기 때문에, 지금은 각 메뉴마다 안내 문구만 출력했다.

이번 단계의 목표는 메모 기능 자체가 아니라 프로그램의 흐름을 만드는 것이다.

0을 입력하면 종료

사용자가 0을 입력하면 프로그램이 종료되도록 했다.

} else if (menu == 0) {
    running = false;
    System.out.println("프로그램을 종료합니다.");
}

running이 false가 되면 반복문이 끝난다.

즉, 현재 프로그램은 사용자가 직접 종료를 선택하기 전까지 계속 메뉴를 보여준다.

잘못된 번호 처리

사용자가 1, 2, 3, 4, 0이 아닌 숫자를 입력할 수도 있다.

그 경우에는 안내 문구를 출력하도록 했다.

} else {
    System.out.println("올바른 메뉴 번호를 입력하세요.");
}

아직 복잡한 예외 처리는 하지 않았지만, 최소한 잘못된 번호를 입력했을 때 프로그램 흐름이 이상해지지 않도록 했다.

메모 작성
메모 목록 저장
메모 수정
메모 삭제
파일 저장
DB 저장

이번 단계는 기능 구현보다 Java 콘솔 프로그램의 기본 흐름을 만드는 데 집중했다.

#16 HTML/CSS/JS 메모장을 React로 고도화 정리

sqaxe1 — Sat, 20 Jun 2026 12:21:33 +0900

기존 HTML/CSS/JS 방식

처음에는 파일 역할이 명확하게 나뉘어 있었다.

index.html
→ 화면 구조

style.css
→ 디자인

script.js
→ 동작

JavaScript에서는 DOM을 직접 찾고 조작했다.

document.getElementById(...)
document.createElement(...)
appendChild(...)
innerHTML = ''

메모를 추가하거나 삭제한 뒤에는 직접 renderMemos()를 호출해서 화면을 다시 그렸다.

memos.push(newMemo)
renderMemos()

즉, 기존 방식은 다음 흐름이었다.

데이터 변경
→ DOM 직접 조작
→ 화면 직접 갱신

이 방식은 화면이 어떻게 만들어지고 바뀌는지 직접 확인하기 좋았다.
하지만 기능이 늘어날수록 DOM을 직접 다루는 코드가 많아진다.

React 방식으로 바꾸기

React에서는 HTML 역할을 JSX가 담당한다.

기존처럼 index.html에 화면을 직접 작성하는 대신, App.jsx의 return 안에 화면 구조를 작성했다.

return (
  <div className="app">
    ...
  </div>
)

JSX는 HTML처럼 보이지만 JavaScript 안에서 사용하는 문법이다.

그래서 HTML의 class는 JSX에서 className으로 작성하고, for는 htmlFor로 작성한다.

<label htmlFor="memo-title">제목</label>
<div className="memo-card"></div>

겉으로는 HTML과 비슷하지만, 실제로는 React 컴포넌트가 반환하는 화면 구조라고 볼 수 있다.

React의 핵심은 state

React에서는 화면에 영향을 주는 데이터를 state로 관리한다.

const [title, setTitle] = useState('')
const [content, setContent] = useState('')
const [memos, setMemos] = useState([])

각 값의 역할은 다음과 같다.

title
→ 현재 제목 입력값

content
→ 현재 내용 입력값

memos
→ 메모 배열

그리고 setTitle, setContent, setMemos는 각각의 state를 바꾸는 함수다.

중요한 점은 React에서는 state가 바뀌면 자동으로 다시 렌더링된다는 것이다.

set 함수 실행
→ state 변경
→ 컴포넌트 다시 실행
→ JSX 다시 계산
→ 화면 갱신

즉, React에서는 화면을 직접 수정하는 것이 아니라 화면의 기준이 되는 데이터를 바꾼다.

입력값 관리

기존 JavaScript에서는 input 값을 직접 꺼냈다.

titleInput.value

React에서는 input을 state와 연결했다.

<input
  value={title}
  onChange={(event) => setTitle(event.target.value)}
/>

이 흐름은 다음과 같다.

value={title}
→ title 값을 input에 보여준다.

onChange
→ input 값이 바뀔 때 실행된다.

event.target.value
→ 사용자가 input에 입력한 현재 값이다.

setTitle(event.target.value)
→ 입력값을 title state에 저장한다.

방향으로 보면 다음과 같다.

title → input
input → setTitle → title

즉, React에서는 입력값도 state로 관리한다.

메모 추가

기존 JavaScript에서는 배열에 직접 메모를 추가했다.

memos.push(newMemo)
renderMemos()

React에서는 새 배열을 만들어 state를 변경했다.

setMemos([...memos, newMemo])

이 코드는 다음 뜻이다.

기존 memos 배열을 펼친다.
뒤에 newMemo를 추가한다.
새 배열을 만든다.
setMemos로 memos state를 교체한다.
React가 다시 렌더링한다.

React에서는 기존 배열을 직접 수정하기보다, 새 배열을 만들어 state를 바꾸는 방식으로 처리했다.

메모 목록 출력

기존 JavaScript에서는 직접 DOM 요소를 만들었다.

document.createElement('div')
appendChild(memoCard)

React에서는 map()을 사용해서 배열을 화면으로 바꿨다.

{memos.map((memo) => (
  <MemoItem
    key={memo.id}
    memo={memo}
    onEditMemo={handleEditMemo}
    onDeleteMemo={handleDeleteMemo}
  />
))}

map()은 메모 배열을 돌면서 메모 하나를 화면 요소 하나로 바꿔준다.

또한 key={memo.id}는 React가 목록 항목을 구분하기 위해 사용하는 값이다.
화면에 직접 보이는 값은 아니지만, React가 어떤 항목이 추가되었고 삭제되었는지 구분하는 데 필요하다.

수정과 삭제

삭제는 filter()를 사용했다.

const nextMemos = memos.filter((memo) => {
  return memo.id !== id
})

setMemos(nextMemos)

filter()는 조건에 맞는 요소만 남겨 새 배열을 만든다.
삭제하려는 id와 다른 메모만 남기면, 해당 메모가 제외된 새 배열이 만들어진다.

수정은 map()을 사용했다.

const nextMemos = memos.map((memo) => {
  if (memo.id === id) {
    return {
      id: memo.id,
      title: newTitle.trim(),
      content: newContent.trim(),
    }
  }

  return memo
})

setMemos(nextMemos)

map()은 배열을 돌면서 새 배열을 만든다.
수정할 id와 같은 메모를 만나면 새 제목과 내용으로 바꾼 객체를 반환하고, 나머지는 그대로 반환한다.

삭제와 수정 모두 공통점이 있다.

기존 배열을 기준으로 새 배열을 만든다.
setMemos로 state를 변경한다.
React가 자동으로 화면을 다시 그린다.

localStorage 저장

React에서도 localStorage를 사용해 새로고침 후에도 메모가 유지되도록 했다.

처음 실행될 때 localStorage에서 메모를 불러왔다.

useEffect(() => {
  const savedMemos = localStorage.getItem('memos')

  if (savedMemos !== null) {
    setMemos(JSON.parse(savedMemos))
  }
}, [])

그리고 memos가 바뀔 때마다 localStorage에 저장했다.

useEffect(() => {
  localStorage.setItem('memos', JSON.stringify(memos))
}, [memos])

정리하면 다음과 같다.

useState
→ 화면에 영향을 주는 데이터 관리

useEffect
→ 렌더링 이후에 실행할 작업 처리

JSON.stringify
→ 배열을 문자열로 변환해 저장

JSON.parse
→ 문자열을 다시 배열로 변환해 불러오기

localStorage는 화면을 그리는 작업이 아니라 브라우저 저장소를 다루는 작업이므로 useEffect에서 처리했다.

컴포넌트 분리

처음에는 App.jsx 안에 모든 코드가 있었다.

이후 역할별로 컴포넌트를 분리했다.

App.jsx
→ state와 기능 관리

MemoForm.jsx
→ 메모 입력 폼

MemoList.jsx
→ 메모 목록

MemoItem.jsx
→ 메모 카드 하나

컴포넌트를 분리하면서 props를 사용했다.

<MemoForm
  title={title}
  content={content}
  onTitleChange={(event) => setTitle(event.target.value)}
  onContentChange={(event) => setContent(event.target.value)}
  onAddMemo={handleAddMemo}
/>

props는 부모 컴포넌트가 자식 컴포넌트에게 넘겨주는 값 또는 함수다.

흐름은 다음과 같다.

App이 state를 가지고 있다.
MemoForm은 props로 title, content, 함수를 받는다.
MemoForm에서 이벤트가 발생하면 App에서 받은 함수를 실행한다.
App의 state가 바뀐다.
React가 다시 렌더링한다.

즉, 컴포넌트를 분리해도 데이터의 중심은 App에 있고, 하위 컴포넌트는 필요한 값과 함수를 props로 받아 사용한다.

HTML/CSS/JS와 React의 가장 큰 차이

기존 방식은 화면을 직접 조작했다.

HTML/CSS/JS
→ DOM을 직접 찾는다.
→ DOM을 직접 만든다.
→ DOM을 직접 붙인다.
→ 화면을 직접 갱신한다.

React 방식은 state를 기준으로 화면을 그린다.

React
→ state를 바꾼다.
→ React가 컴포넌트를 다시 실행한다.
→ JSX를 다시 계산한다.
→ 화면이 자동으로 갱신된다.

가장 중요한 차이는 이것이다.

기존 JS는 화면을 직접 바꾼다.
React는 state를 바꾸면 화면이 따라온다.

이 차이를 이해하는 것이 이번 React 단계의 핵심이었다.

현재 React 메모장의 기능

현재 React 버전 메모장은 기존 JavaScript 버전에서 만들었던 기능을 대부분 다시 구현한 상태다.

메모 작성
메모 목록 보기
메모 수정
메모 삭제
새로고침 후 유지
컴포넌트 분리

기능 자체는 기존과 비슷하지만, 구현 방식은 달라졌다.

#15 컴포넌트 분리와 props 이해하기

sqaxe1 — Sat, 20 Jun 2026 09:43:06 +0900

이번 단계에서는 React 메모장의 기능을 새로 추가한 것이 아니라, 기존 코드를 컴포넌트 단위로 분리했다.

기존에는 App.jsx 안에 모든 코드가 들어 있었다.

입력 폼
메모 목록
메모 카드
추가 함수
수정 함수
삭제 함수
localStorage 처리

처음에는 이렇게 한 파일에 작성하는 것이 이해하기 쉽다.
하지만 코드가 길어질수록 어떤 부분이 입력 폼인지, 어떤 부분이 목록인지, 어떤 부분이 메모 하나인지 구분하기 어려워진다.

그래서 이번 단계에서는 화면 역할별로 컴포넌트를 나누었다.

컴포넌트를 분리한 이유

컴포넌트 분리는 기능을 바꾸는 작업이 아니다.
기존에 잘 동작하던 코드를 역할별로 나누는 작업이다.

이번에는 다음처럼 역할을 나누었다.

App.jsx
→ 전체 데이터와 기능 관리

MemoForm.jsx
→ 메모 입력 폼 담당

MemoList.jsx
→ 메모 목록 영역 담당

MemoItem.jsx
→ 메모 카드 하나 담당

즉, 화면을 더 작은 단위로 나누어 관리하기 위한 작업이다.

분리 후 파일 구조

이번 단계에서 구조는 다음과 같이 바뀌었다.

src/
 ├─ App.jsx
 ├─ App.css
 └─ components/
     ├─ MemoForm.jsx
     ├─ MemoList.jsx
     └─ MemoItem.jsx

각 파일은 자신의 역할만 담당한다.

MemoForm
→ 제목 입력
→ 내용 입력
→ 메모 추가 버튼

MemoList
→ 메모 목록 전체
→ 메모가 없을 때 안내 메시지

MemoItem
→ 메모 하나의 제목
→ 메모 하나의 내용
→ 수정 버튼
→ 삭제 버튼

이렇게 나누면 화면 구조를 더 쉽게 파악할 수 있다.

App.jsx의 역할

컴포넌트를 분리해도 중요한 데이터는 여전히 App.jsx가 가지고 있다.

const [title, setTitle] = useState('')
const [content, setContent] = useState('')
const [memos, setMemos] = useState([])

즉, App.jsx는 메모장의 중심이다.

App.jsx가 담당하는 역할은 다음과 같다.

title state 관리
content state 관리
memos state 관리
메모 추가 함수 관리
메모 수정 함수 관리
메모 삭제 함수 관리
localStorage 저장/불러오기 관리

화면은 여러 컴포넌트로 나누었지만, 실제 데이터와 기능은 App.jsx가 가지고 있다.

props란 무엇인가

컴포넌트를 분리하면 한 가지 문제가 생긴다.

예를 들어 title state는 App.jsx에 있는데, 실제 input은 MemoForm.jsx 안에 있다.

그러면 MemoForm은 title 값을 어떻게 사용할 수 있을까?

이때 사용하는 것이 props다.

props
= 부모 컴포넌트가 자식 컴포넌트에게 넘겨주는 값 또는 함수

현재 구조에서는 App이 부모 컴포넌트이고, MemoForm, MemoList, MemoItem은 자식 컴포넌트다.

MemoForm에 props 넘기기

App.jsx에서는 MemoForm을 이렇게 사용한다.

<MemoForm
  title={title}
  content={content}
  onTitleChange={(event) => setTitle(event.target.value)}
  onContentChange={(event) => setContent(event.target.value)}
  onAddMemo={handleAddMemo}
/>

이 코드는 MemoForm에게 필요한 값과 함수를 넘겨주는 코드다.

title
→ 제목 input에 보여줄 값

content
→ 내용 textarea에 보여줄 값

onTitleChange
→ 제목 input이 바뀔 때 실행할 함수

onContentChange
→ 내용 textarea가 바뀔 때 실행할 함수

onAddMemo
→ 메모 추가 버튼을 눌렀을 때 실행할 함수

title={title} 이해하기

가장 헷갈렸던 부분은 다음 코드였다.

title={title}

왼쪽과 오른쪽의 의미가 다르다.

왼쪽 title
→ MemoForm에게 넘겨줄 props 이름

오른쪽 {title}
→ App.jsx 안에 있는 title state 값

즉, 이 코드는 다음처럼 이해할 수 있다.

App이 가지고 있는 title state 값을
MemoForm에게 title이라는 이름으로 넘긴다.

예를 들어 App의 title 값이 "오늘 할 일"이라면,

<MemoForm title={title} />

은 개념적으로 이런 느낌이다.

<MemoForm title="오늘 할 일" />

MemoForm에서 props 받기

MemoForm.jsx에서는 App에서 넘겨준 props를 이렇게 받는다.

function MemoForm({ title, content, onTitleChange, onContentChange, onAddMemo }) {
  return (
    ...
  )
}

이 코드는 다음과 같은 의미다.

App이 넘겨준 props 중에서
title을 꺼낸다.
content를 꺼낸다.
onTitleChange를 꺼낸다.
onContentChange를 꺼낸다.
onAddMemo를 꺼낸다.

그리고 그 값을 input과 textarea, button에 연결한다.

<input
  value={title}
  onChange={onTitleChange}
/>

<textarea
  value={content}
  onChange={onContentChange}
></textarea>

<button type="button" onClick={onAddMemo}>
  메모 추가
</button>

value={title}의 의미

value={title}

이 코드는 input에 title 값을 넣어서 보여주는 역할을 한다.

방향으로 보면 다음과 같다.

title state → input 화면

즉, title 값을 input에 보여준다.

반대로 사용자가 input에 입력한 값을 title state에 저장하는 코드는 이것이다.

onChange={onTitleChange}

이 함수는 App.jsx에서 이렇게 넘겨준 함수다.

onTitleChange={(event) => setTitle(event.target.value)}

사용자가 input에 입력하면 다음 흐름으로 동작한다.

사용자가 제목 input에 입력
→ onChange 실행
→ onTitleChange 실행
→ event.target.value로 input의 현재 값 가져옴
→ setTitle 실행
→ App의 title state 변경
→ App 다시 렌더링
→ MemoForm에 새 title 전달
→ input value={title}에 새 값 표시

값과 함수가 같이 넘어가는 이유

MemoForm은 input 화면을 가지고 있지만, title state는 가지고 있지 않다.

title state는 App.jsx에 있다.

그래서 MemoForm이 input을 제대로 동작시키려면 두 가지가 필요하다.

1. 현재 값을 받아야 한다.
2. 값이 바뀌었을 때 App의 state를 바꿀 함수도 받아야 한다.

그래서 App은 MemoForm에게 값과 함수를 함께 넘긴다.

title={title}
onTitleChange={(event) => setTitle(event.target.value)}

정리하면 다음과 같다.

title
→ 현재 값

onTitleChange
→ 새 값을 title state에 저장하는 함수

MemoList 분리

메모 목록도 MemoList.jsx로 분리했다.

App.jsx에서는 이렇게 넘겨준다.

<MemoList
  memos={memos}
  onEditMemo={handleEditMemo}
  onDeleteMemo={handleDeleteMemo}
/>

각 props의 의미는 다음과 같다.

memos
→ 화면에 출력할 메모 배열

onEditMemo
→ 수정 버튼을 눌렀을 때 실행할 함수

onDeleteMemo
→ 삭제 버튼을 눌렀을 때 실행할 함수

중요한 점은 여기서 함수를 실행하는 것이 아니라 넘겨주는 것이다.

onEditMemo={handleEditMemo}

이렇게 써야 한다.

만약 다음처럼 쓰면 안 된다.

onEditMemo={handleEditMemo()}

이렇게 쓰면 클릭했을 때 실행되는 것이 아니라, 렌더링되는 순간 함수가 바로 실행되어 버린다.

MemoItem 분리

MemoList 안에서는 memos.map()을 사용해서 메모 하나하나를 MemoItem으로 넘긴다.

{memos.map((memo) => (
  <MemoItem
    key={memo.id}
    memo={memo}
    onEditMemo={onEditMemo}
    onDeleteMemo={onDeleteMemo}
  />
))}

여기서 MemoItem은 메모 하나를 담당한다.

memo
→ 메모 하나의 데이터

onEditMemo
→ 수정 함수

onDeleteMemo
→ 삭제 함수

MemoItem에서는 버튼을 클릭했을 때 현재 메모의 id를 넣어서 함수를 실행한다.

<button type="button" onClick={() => onEditMemo(memo.id)}>
  수정
</button>

<button type="button" onClick={() => onDeleteMemo(memo.id)}>
  삭제
</button>

이렇게 하는 이유는 각 메모마다 id가 다르기 때문이다.

1번 메모 수정 버튼
→ onEditMemo(1)

2번 메모 수정 버튼
→ onEditMemo(2)

3번 메모 수정 버튼
→ onEditMemo(3)

현재 컴포넌트 흐름

App
→ title, content, memos state를 가지고 있음
→ 추가/수정/삭제 함수를 가지고 있음

MemoForm
→ App에서 title, content, 입력 변경 함수, 추가 함수를 받음
→ 입력 폼 화면 담당

MemoList
→ App에서 memos, 수정 함수, 삭제 함수를 받음
→ 목록 전체 담당

MemoItem
→ MemoList에서 memo 하나와 수정/삭제 함수를 받음
→ 메모 카드 하나 담당

App
 ├─ MemoForm
 └─ MemoList
      ├─ MemoItem
      ├─ MemoItem
      └─ MemoItem

props 흐름 정리

이번 단계에서 가장 중요하게 본 것은 props의 흐름이다.

부모가 state를 가진다.
자식은 props로 받아서 사용한다.
자식에서 이벤트가 발생하면 부모에게서 받은 함수를 실행한다.
부모의 state가 바뀐다.
화면이 다시 렌더링된다.

특히 MemoForm에서 중요한 흐름은 다음과 같다.

App의 title state
→ MemoForm에 title props로 전달
→ input value={title}로 표시
→ 사용자가 입력
→ onTitleChange 실행
→ setTitle로 App의 title state 변경
→ 다시 렌더링

즉, React에서는 값의 흐름을 이렇게 생각하면 된다.

데이터는 부모가 가지고 있고,
자식은 props로 받아서 화면에 사용한다.
자식이 데이터를 바꿔야 할 때는
부모에게서 받은 함수를 실행한다.

이번 단계의 핵심은 다음과 같다.

컴포넌트 분리
= 화면을 역할별 파일로 나누는 작업

props
= 부모 컴포넌트가 자식 컴포넌트에게 넘겨주는 값 또는 함수

App.jsx는 상태와 기능을 가지고 있고,
MemoForm, MemoList, MemoItem은 각각 필요한 값과 함수를 props로 받아 화면을 담당한다.

#14 React에서 localStorage로 메모 저장하기

sqaxe1 — Fri, 19 Jun 2026 15:52:55 +0900

이번 단계에서는 React 버전 메모장에 localStorage 저장 기능을 추가했다.

이전까지는 메모를 추가, 수정, 삭제할 수 있었지만 새로고침하면 데이터가 사라졌다.

그 이유는 메모가 React state인 memos 안에만 있었기 때문이다.

const [memos, setMemos] = useState([])

브라우저를 새로고침하면 React 앱이 다시 시작되고, state는 다시 초기값으로 돌아간다.
즉, 새로고침하면 memos는 다시 빈 배열이 된다.

그래서 메모를 브라우저에 남겨두기 위해 localStorage를 사용했다.

useEffect 추가하기

localStorage 작업을 처리하기 위해 useEffect를 사용했다.

기존에는 useState만 import하고 있었다.

import { useState } from 'react'

여기에 useEffect를 추가했다.

import { useState, useEffect } from 'react'

useState는 화면에 영향을 주는 데이터를 관리하는 기능이고,
useEffect는 렌더링 이후에 실행할 작업을 처리하는 기능이다.

이번 프로젝트에서는 localStorage에서 데이터를 불러오거나 저장하는 작업에 useEffect를 사용했다.

처음 실행될 때 localStorage에서 불러오기

먼저 앱이 처음 열릴 때 localStorage에 저장된 메모를 가져오도록 했다.

useEffect(() => {
  const savedMemos = localStorage.getItem('memos')

  if (savedMemos !== null) {
    setMemos(JSON.parse(savedMemos))
  }
}, [])

이 코드는 앱이 처음 렌더링된 뒤 한 번 실행된다.

마지막에 있는 빈 배열 []이 중요하다.

}, [])

이 뜻은 다음과 같다.

처음 렌더링된 뒤 한 번만 실행해라.

JavaScript에서 만들었던 loadMemos()와 비슷한 역할이다.

localStorage.getItem

저장된 메모를 가져올 때는 localStorage.getItem()을 사용했다.

const savedMemos = localStorage.getItem('memos')

이 코드는 localStorage에서 memos라는 이름으로 저장된 값을 가져온다.

localStorage에 값이 없으면 null이 나온다.
그래서 바로 사용하지 않고 먼저 확인했다.

if (savedMemos !== null) {
  setMemos(JSON.parse(savedMemos))
}

저장된 값이 있을 때만 setMemos()를 실행한다.

JSON.parse가 필요한 이유

localStorage는 배열이나 객체를 그대로 저장하지 못한다.
문자열만 저장할 수 있다.

그래서 저장할 때는 배열을 문자열로 바꿔야 한다.

JSON.stringify(memos)

반대로 꺼낼 때는 문자열을 다시 배열로 바꿔야 한다.

JSON.parse(savedMemos)

그래서 다음 코드는,

setMemos(JSON.parse(savedMemos))

이렇게 이해할 수 있다.

localStorage에서 꺼낸 문자열을
JSON.parse로 배열로 바꾼 뒤
setMemos로 memos state에 넣는다.

풀어 쓰면 다음 코드와 같다.

const parsedMemos = JSON.parse(savedMemos)
setMemos(parsedMemos)

memos가 바뀔 때마다 localStorage에 저장하기

불러오기만 하면 부족하다.

메모를 추가, 수정, 삭제했을 때 변경된 memos를 다시 localStorage에 저장해야 한다.

그래서 두 번째 useEffect를 추가했다.

useEffect(() => {
  localStorage.setItem('memos', JSON.stringify(memos))
}, [memos])

여기서 마지막에 있는 [memos]가 중요하다.

}, [memos])

이 뜻은 다음과 같다.

memos state가 바뀔 때마다 이 useEffect를 실행해라.

그래서 메모를 추가하면 다음 순서로 동작한다.

setMemos 실행
→ memos state 변경
→ useEffect 실행
→ localStorage 저장

삭제해도 마찬가지다.

setMemos 실행
→ memos state 변경
→ useEffect 실행
→ localStorage 저장

수정해도 같은 흐름이다.

setMemos 실행
→ memos state 변경
→ useEffect 실행
→ localStorage 저장

localStorage.setItem

저장할 때는 localStorage.setItem()을 사용했다.

localStorage.setItem('memos', JSON.stringify(memos))

이 코드는 현재 memos 배열을 localStorage에 저장한다.

다만 localStorage에는 문자열만 저장할 수 있으므로 JSON.stringify()를 사용한다.

JSON.stringify(memos)

이 코드는 배열을 문자열로 바꿔준다.

예를 들어 배열이 이렇게 있다면,

[
  { id: 1, title: 'A', content: 'aaa' }
]

문자열로 바뀌면 이런 형태가 된다.

'[{"id":1,"title":"A","content":"aaa"}]'

이 문자열이 localStorage에 저장된다.

useEffect의 역할 정리

이번 단계에서 사용한 useEffect는 두 개다.

첫 번째 useEffect는 앱이 처음 실행될 때 저장된 메모를 불러온다.

useEffect(() => {
  const savedMemos = localStorage.getItem('memos')

  if (savedMemos !== null) {
    setMemos(JSON.parse(savedMemos))
  }
}, [])

두 번째 useEffect는 memos가 바뀔 때마다 저장한다.

useEffect(() => {
  localStorage.setItem('memos', JSON.stringify(memos))
}, [memos])

정리하면 다음과 같다.

useState
→ React가 기억해야 하는 화면 데이터 관리

useEffect
→ 렌더링 이후에 실행해야 하는 부가 작업 처리

localStorage는 화면을 그리는 JSX가 아니라 브라우저 저장소와 관련된 작업이므로 useEffect에서 처리했다.

새로고침했을 때의 흐름

이제 새로고침을 하면 다음 순서로 동작한다.

1. React 앱이 다시 시작된다.
2. memos state는 처음에 빈 배열로 시작한다.
3. 화면이 한 번 렌더링된다.
4. 첫 번째 useEffect가 실행된다.
5. localStorage에서 저장된 문자열을 가져온다.
6. JSON.parse로 배열로 바꾼다.
7. setMemos로 memos state에 넣는다.
8. memos가 바뀌었으므로 React가 다시 렌더링한다.
9. 저장돼 있던 메모가 화면에 보인다.

즉, 새로고침해도 메모가 유지된다.

메모 추가, 수정, 삭제 후의 흐름

메모를 추가하면 다음처럼 동작한다.

새 메모 객체 생성
→ setMemos로 memos state 변경
→ React가 다시 렌더링
→ 두 번째 useEffect 실행
→ 변경된 memos를 localStorage에 저장

메모를 수정해도 흐름은 같다.

수정된 새 배열 생성
→ setMemos로 memos state 변경
→ React가 다시 렌더링
→ 두 번째 useEffect 실행
→ 변경된 memos를 localStorage에 저장

메모를 삭제해도 마찬가지다.

삭제된 새 배열 생성
→ setMemos로 memos state 변경
→ React가 다시 렌더링
→ 두 번째 useEffect 실행
→ 변경된 memos를 localStorage에 저장

이번 단계의 핵심은 memos state와 localStorage를 연결한 것이다.

앱이 처음 열릴 때
→ localStorage에서 메모를 불러온다.

memos가 바뀔 때마다
→ localStorage에 다시 저장한다.

이제 React 버전 메모장도 새로고침 후 데이터가 유지된다.

#13 React에서 메모 삭제 기능 구현하기

sqaxe1 — Thu, 18 Jun 2026 16:51:58 +0900

이번 단계에서는 React 버전 메모장에 삭제 기능을 추가했다.

이전 JavaScript에서는 삭제 버튼을 누르면 배열에서 해당 메모를 제거하고, 직접 renderMemos()를 호출해서 화면을 다시 그렸다.

React에서는 방식이 조금 다르다.

React에서는 화면을 직접 다시 그리는 함수를 호출하지 않는다.
대신 state를 변경하면 React가 자동으로 화면을 다시 렌더링한다.

삭제 기능의 기본 흐름

이번 삭제 기능의 흐름은 다음과 같다.

삭제 버튼 클릭
→ 삭제할 메모 id 전달
→ confirm으로 삭제 여부 확인
→ memos 배열에서 해당 id를 가진 메모 제거
→ setMemos로 새 배열 저장
→ React가 자동으로 화면 다시 렌더링

JavaScript에서는 이런 흐름이었다.

삭제 버튼 클릭
→ memos 배열 변경
→ saveMemos()
→ renderMemos()

React에서는 이렇게 바뀐다.

삭제 버튼 클릭
→ memos 배열 변경
→ setMemos()
→ 자동 렌더링

즉, React에서는 renderMemos() 같은 함수를 직접 호출하지 않는다.

삭제 함수 만들기

먼저 삭제 기능을 담당하는 함수를 만들었다.

function handleDeleteMemo(id) {
  const isConfirmed = confirm('정말 삭제하시겠습니까?')

  if (!isConfirmed) {
    return
  }

  const nextMemos = memos.filter((memo) => {
    return memo.id !== id
  })

  setMemos(nextMemos)
}

이 함수는 삭제할 메모의 id를 매개변수로 받는다.

function handleDeleteMemo(id) {
  ...
}

여기서 id는 어떤 메모를 삭제할지 구분하기 위한 값이다.

confirm으로 삭제 확인하기

삭제는 실수로 누를 수 있기 때문에 먼저 확인창을 띄웠다.

const isConfirmed = confirm('정말 삭제하시겠습니까?')

사용자가 확인을 누르면 true, 취소를 누르면 false가 들어간다.

if (!isConfirmed) {
  return
}

취소를 누른 경우에는 return으로 함수를 바로 종료한다.

즉, 아래에 있는 삭제 로직은 실행되지 않는다.

filter로 삭제할 메모 제외하기

실제 삭제는 filter()를 사용했다.

const nextMemos = memos.filter((memo) => {
  return memo.id !== id
})

처음에는 이 부분이 헷갈릴 수 있다.

filter()는 배열을 하나씩 돌면서 조건이 true인 요소만 새 배열에 남긴다.

return true  → 남긴다
return false → 제외한다

그래서 이 조건은 다음처럼 읽을 수 있다.

memo.id !== id

현재 검사 중인 memo의 id가
삭제하려는 id와 다르면 남긴다.
같으면 제외한다.

예를 들어 메모 배열이 이렇게 있다고 하자.

[
  { id: 1, title: 'A' },
  { id: 2, title: 'B' },
  { id: 3, title: 'C' }
]

id가 2인 메모를 삭제하려고 할 때 조건은 다음과 같다.

memo.id !== 2

검사 결과는 이렇게 된다.

id 1 → 1 !== 2 → true  → 남김
id 2 → 2 !== 2 → false → 제외
id 3 → 3 !== 2 → true  → 남김

그래서 결과 배열은 다음과 같다.

[
  { id: 1, title: 'A' },
  { id: 3, title: 'C' }
]

이 배열을 nextMemos라고 이름 붙였다.

setMemos로 state 변경하기

삭제된 새 배열을 만든 뒤에는 setMemos()를 호출했다.

setMemos(nextMemos)

이 코드가 실행되면 React가 memos state를 새 배열로 교체한다.

그리고 state가 바뀌었기 때문에 React가 자동으로 컴포넌트를 다시 렌더링한다.

흐름은 다음과 같다.

setMemos 실행
→ memos state 변경
→ React가 App 컴포넌트 다시 실행
→ memos.map 부분 다시 실행
→ 삭제된 메모가 빠진 목록이 화면에 출력

즉, JavaScript에서 직접 호출하던 renderMemos()가 필요 없다.

삭제 버튼 연결하기

삭제 함수만 만들면 아직 화면에서 실행되지 않는다.

각 메모 카드에 삭제 버튼을 추가하고, 클릭하면 해당 메모의 id를 넘기도록 했다.

{memos.map((memo) => (
  <div className="memo-card" key={memo.id}>
    <h3>{memo.title}</h3>
    <p>{memo.content}</p>
    <button type="button" onClick={() => handleDeleteMemo(memo.id)}>
      삭제
    </button>
  </div>
))}

여기서 중요한 부분은 다음 코드다.

onClick={() => handleDeleteMemo(memo.id)}

이 코드는 삭제 버튼을 클릭했을 때 handleDeleteMemo()를 실행한다.
그리고 현재 메모의 id를 넘긴다.

첫 번째 메모의 삭제 버튼 클릭
→ 첫 번째 memo.id 전달

두 번째 메모의 삭제 버튼 클릭
→ 두 번째 memo.id 전달

왜 바로 실행하면 안 되는가

처음 보면 이렇게 쓰고 싶을 수 있다.

onClick={handleDeleteMemo(memo.id)}

하지만 이렇게 쓰면 클릭했을 때 실행되는 것이 아니라, 렌더링되는 순간 바로 실행된다.

그래서 함수로 감싸야 한다.

onClick={() => handleDeleteMemo(memo.id)}

이렇게 쓰면 React에게 다음과 같은 의미가 된다.

지금 실행하지 말고,
클릭했을 때 이 함수를 실행해라.

이 부분은 이전에 addEventListener에서 함수를 등록했던 개념과 비슷하다.

현재 전체 코드 흐름

현재 메모 목록 출력 부분은 다음과 같은 구조가 되었다.

{memos.length === 0 && (
  <p className="empty-message">아직 작성된 메모가 없습니다.</p>
)}

{memos.map((memo) => (
  <div className="memo-card" key={memo.id}>
    <h3>{memo.title}</h3>
    <p>{memo.content}</p>
    <button type="button" onClick={() => handleDeleteMemo(memo.id)}>
      삭제
    </button>
  </div>
))}

메모가 없으면 빈 메시지를 보여준다.
메모가 있으면 memos.map()으로 메모 카드를 출력한다.

각 메모 카드에는 삭제 버튼이 있고, 삭제 버튼은 자기 메모의 id를 handleDeleteMemo()로 넘긴다.

이번 단계에서 이해한 핵심

이번 삭제 기능에서 가장 중요한 점은 React의 렌더링 흐름이다.

React에서는 DOM을 직접 삭제하지 않는다.

Vanilla JavaScript에서는 이런 식으로 생각했다.

삭제 버튼 클릭
→ DOM 요소 삭제
→ 화면 갱신

React에서는 이렇게 생각해야 한다.

삭제 버튼 클릭
→ state 배열에서 데이터 제거
→ setMemos로 state 변경
→ React가 state를 기준으로 화면을 다시 그림

즉, React에서는 화면이 기준이 아니라 데이터가 기준이다.

화면을 직접 지우는 것이 아니라
데이터에서 지우면
화면은 React가 알아서 바꾼다.

정리

이번 단계의 핵심은 삭제 기능 자체보다 React에서 삭제를 바라보는 방식이다.

Vanilla JavaScript에서는 화면에서 직접 요소를 제거하거나, renderMemos()를 직접 호출했다.

React에서는 memos state에서 삭제할 데이터를 제외한 새 배열을 만들고, setMemos()로 상태를 바꾼다.

const nextMemos = memos.filter((memo) => {
  return memo.id !== id
})

setMemos(nextMemos)

그러면 React가 변경된 memos state를 기준으로 화면을 다시 렌더링한다.

즉, React에서는 화면을 직접 수정하는 것이 아니라 state를 수정해서 화면이 바뀌게 만든다.

#12 React 프로젝트 시작과 입력값 상태 관리

sqaxe1 — Tue, 16 Jun 2026 22:03:18 +0900

Vanilla JavaScript로 메모장 CRUD 기능을 구현한 뒤, 이번에는 같은 메모장을 React로 다시 만들어보기 시작했다.

이번 단계의 목표는 메모 추가, 수정, 삭제까지 구현하는 것이 아니다.
먼저 React 프로젝트를 만들고, 기존 HTML/CSS 메모장 화면을 React로 옮긴 뒤, 입력창 값을 React의 state로 관리하는 것까지 진행했다.

이번 단계에서 한 일은 다음과 같다.

React 프로젝트 생성
Vite 기본 화면 제거
기존 메모장 화면을 JSX로 작성
제목 입력값을 state로 관리
내용 입력값을 state로 관리
onChange로 입력값 갱신
onClick으로 버튼 클릭 시 state 확인

React 프로젝트 생성

React 프로젝트는 기존 JavaScript 파일을 지우지 않고, 별도 폴더에 만들었다.

현재 프로젝트 구조는 다음과 같다.

Memo Evolution/
  index.html
  style.css
  script.js
  react-memo/

React 프로젝트는 react-memo 폴더 안에 생성했다.

Vite를 사용해서 React 프로젝트를 만들었다.

npm create vite@latest react-memo -- --template react

이후 React 프로젝트 폴더로 이동해서 패키지를 설치했다.

cd react-memo
npm install

개발 서버는 다음 명령어로 실행한다.

npm run dev

브라우저에서는 보통 다음 주소로 확인한다.

http://localhost:5173

개발 서버와 HMR

npm run dev를 실행하면 Vite 개발 서버가 실행된다.

개발 서버가 켜져 있는 상태에서 App.jsx나 App.css를 수정하고 저장하면 보통 브라우저에 자동으로 반영된다.

이 기능을 HMR이라고 한다.

HMR = Hot Module Replacement
파일 저장 시 브라우저에 변경 사항을 빠르게 반영하는 기능

그래서 단순히 컴포넌트나 CSS를 수정할 때마다 npm run dev를 다시 실행할 필요는 없다.

다만 다음 경우에는 재실행이 필요할 수 있다.

개발 서버를 꺼버린 경우
새 라이브러리를 설치한 경우
package.json을 수정한 경우
vite.config.js를 수정한 경우
개발 서버가 에러로 종료된 경우

Vite 기본 코드 제거

처음 Vite로 React 프로젝트를 만들면 기본 예제 화면이 들어 있다.

App.jsx에는 로고, 카운터 버튼, 문서 링크 같은 코드가 있었다.
하지만 이번 프로젝트의 목표는 메모장을 React로 다시 만드는 것이므로 기본 코드는 제거했다.

기존 코드에서 필요 없어진 것들은 다음과 같다.

import reactLogo from './assets/react.svg'
import viteLogo from './assets/vite.svg'

const [count, setCount] = useState(0)

카운터 예제도 제거했다.
이번 단계에서는 메모장 화면과 입력 상태 관리만 다룬다.

React에서 정적인 메모장 화면 만들기

JavaScript 단계에서 작성했던 HTML 구조를 React의 JSX로 옮겼다.

React 컴포넌트는 기본적으로 함수 형태다.

function App() {
  return (
    ...
  )
}

현재 App.jsx는 메모장 화면 전체를 담당한다.

import { useState } from 'react'
import './App.css'

function App() {
  const [title, setTitle] = useState('')
  const [content, setContent] = useState('')

  function handleAddMemo() {
    console.log(title)
    console.log(content)
  }

  return (
    <div className="app">
      <div className="memo-form">
        <h2>새 메모 작성</h2>

        <label htmlFor="memo-title">제목</label>
        <input
          id="memo-title"
          type="text"
          placeholder="제목을 입력하세요"
          value={title}
          onChange={(event) => setTitle(event.target.value)}
        />

        <label htmlFor="memo-content">내용</label>
        <textarea
          id="memo-content"
          placeholder="내용을 입력하세요"
          value={content}
          onChange={(event) => setContent(event.target.value)}
        ></textarea>

        <button type="button" onClick={handleAddMemo}>
          메모 추가
        </button>
      </div>

      <div className="memo-list">
        <h2>메모 목록</h2>
        <p className="empty-message">아직 작성된 메모가 없습니다.</p>
      </div>
    </div>
  )
}

export default App

JSX에서 HTML과 다른 점

React에서 사용하는 JSX는 HTML과 비슷하게 생겼지만, 완전히 같지는 않다.

대표적으로 class 대신 className을 사용한다.

HTML에서는 다음처럼 작성했다.

<div class="app">

JSX에서는 이렇게 작성한다.

<div className="app">

또 label에서 사용하는 for도 JSX에서는 htmlFor로 작성한다.

HTML에서는 다음과 같았다.

<label for="memo-title">제목</label>

JSX에서는 이렇게 쓴다.

<label htmlFor="memo-title">제목</label>

그리고 input처럼 닫는 태그가 없는 요소는 JSX에서 self-closing 형태로 작성한다.

<input id="memo-title" type="text" />

이번 단계에서 기억할 JSX 차이는 다음과 같다.

class → className
for → htmlFor
input은 />로 닫기

useState로 입력값 관리하기

JavaScript에서는 입력값을 버튼 클릭 시점에 DOM에서 직접 가져왔다.

const title = titleInput.value.trim();
const content = contentInput.value.trim();

React에서는 입력값을 보통 state로 관리한다.

이번 단계에서는 제목과 내용을 각각 state로 만들었다.

const [title, setTitle] = useState('')
const [content, setContent] = useState('')

useState('')는 초기값이 빈 문자열인 상태를 만든다.

각각의 의미는 다음과 같다.

title
= 현재 제목 입력값

setTitle
= title 값을 바꾸는 함수

content
= 현재 내용 입력값

setContent
= content 값을 바꾸는 함수

setTitle, setContent는 내가 직접 정의한 함수가 아니라 useState가 만들어주는 상태 변경 함수다.

이름은 직접 정할 수 있지만, 보통 관례상 set + 상태이름 형태로 작성한다.

const [title, setTitle] = useState('')
const [content, setContent] = useState('')

input의 value 연결

React에서는 입력창의 값을 state와 연결할 수 있다.

<input
  value={title}
/>

이 코드는 다음 의미다.

이 input에 보이는 값은 title state다.

즉, 입력창에 표시되는 값이 React의 title 상태를 따라간다.

내용 입력창도 마찬가지다.

<textarea
  value={content}
></textarea>

이렇게 하면 입력창의 값은 각각 title, content 상태와 연결된다.

onChange로 state 갱신하기

value만 연결하면 입력이 제대로 되지 않는다.

입력창의 값을 state와 연결했다면, 사용자가 입력할 때 state도 같이 바꿔줘야 한다.

그래서 onChange를 사용한다.

<input
  value={title}
  onChange={(event) => setTitle(event.target.value)}
/>

이 흐름은 다음과 같다.

사용자가 input에 글자를 입력한다.
onChange 이벤트가 실행된다.
event.target.value에 현재 입력값이 들어 있다.
setTitle(event.target.value)가 실행된다.
title state가 변경된다.
React가 다시 렌더링한다.
input에는 변경된 title 값이 표시된다.

내용 입력창도 같은 방식이다.

<textarea
  value={content}
  onChange={(event) => setContent(event.target.value)}
></textarea>

이렇게 value와 onChange를 함께 사용하는 입력 방식을 controlled input이라고 한다.

이번 단계에서는 용어보다 구조를 이해하는 것이 중요하다.

value
= input이 보여줄 값

onChange
= 사용자가 입력할 때 state를 갱신하는 이벤트

onClick으로 버튼 이벤트 연결하기

JavaScript에서는 버튼을 찾고 이벤트를 직접 붙였다.

addMemoButton.addEventListener('click', function () {
    ...
});

React에서는 JSX에서 버튼에 바로 이벤트를 연결한다.

<button type="button" onClick={handleAddMemo}>
  메모 추가
</button>

handleAddMemo는 버튼을 클릭했을 때 실행될 함수다.

function handleAddMemo() {
  console.log(title)
  console.log(content)
}

처음에는 버튼에 onClick을 연결하지 않아서 콘솔이 찍히지 않았다.

잘못된 코드:

<button type="button">메모 추가</button>

이 경우 버튼을 눌러도 아무 함수도 실행되지 않는다.

수정한 코드:

<button type="button" onClick={handleAddMemo}>
  메모 추가
</button>

이렇게 해야 버튼 클릭 시 handleAddMemo()가 실행된다.

JS와 React 비교

이번 단계에서 가장 중요한 비교는 다음과 같다.

JavaScript에서는 DOM에서 값을 직접 읽었다.

const title = titleInput.value;

React에서는 state로 값을 관리한다.

const [title, setTitle] = useState('')

JavaScript에서는 버튼을 찾아 이벤트를 직접 붙였다.

addMemoButton.addEventListener('click', function () {
    ...
});

React에서는 JSX에서 이벤트를 연결한다.

<button onClick={handleAddMemo}>
  메모 추가
</button>

JavaScript에서는 입력값을 input.value로 읽었다.

input.value

React에서는 value와 onChange를 사용해 state와 연결한다.

<input value={title} onChange={...} />

즉, React에서는 DOM에서 값을 나중에 꺼내오기보다, 입력하는 순간 state로 값을 관리한다.

#11 React 시작하기

sqaxe1 — Mon, 15 Jun 2026 20:48:09 +0900

Vanilla JavaScript로 메모장 CRUD 기능을 구현한 뒤, 이제 같은 메모장을 React로 다시 만들어보기 시작했다.

이번 React 단계의 목적은 새로운 기능을 추가하는 것이 아니다.
기존에 만든 메모장 기능을 React 방식으로 다시 구현하면서, JavaScript와 React의 차이를 이해하는 것이 목적이다.

JavaScript에서 했던 방식

이전 단계에서는 HTML 요소를 직접 가져오고, 직접 이벤트를 붙이고, 직접 화면을 다시 그렸다.

예를 들면 다음과 같은 코드들을 사용했다.

document.getElementById(...)
addEventListener(...)
document.createElement(...)
innerHTML
appendChild(...)
renderMemos()

즉, 직접 DOM을 조작했다.

메모 배열이 바뀌면 직접 renderMemos()를 호출해서 화면을 다시 그렸다.

memos.push(newMemo);
saveMemos();
renderMemos();

이 방식은 흐름을 이해하기에는 좋았다.
하지만 기능이 많아질수록 DOM을 직접 다루는 코드가 많아진다.

React에서는 무엇이 달라질까

React에서는 DOM을 직접 조작하는 방식에서 벗어난다.

JavaScript에서는 직접 요소를 만들고 화면에 붙였다.

const memoCard = document.createElement('div');
memoContainer.appendChild(memoCard);

React에서는 화면이 어떻게 생겨야 하는지를 JSX로 작성한다.

<div className="memo-card">
  <h3>{memo.title}</h3>
  <p>{memo.content}</p>
</div>

그리고 데이터는 일반 변수 대신 state로 관리한다.

JavaScript에서는 이렇게 사용했다.

let memos = [];

React에서는 나중에 다음처럼 바뀐다.

const [memos, setMemos] = useState([]);

아직 useState를 깊게 다루지는 않았다.
일단은 이렇게 이해했다.

memos
= 현재 메모 배열

setMemos
= memos 상태를 바꾸는 함수

React에서 중요한 점은 다음이다.

state가 바뀌면 React가 화면을 다시 그린다.

즉, JavaScript에서 직접 만들었던 renderMemos() 역할을 React가 어느 정도 대신해준다.

React 프로젝트 생성

React 프로젝트는 기존 JavaScript 파일을 지우지 않고, 별도 폴더에 만들었다.

현재 구조는 다음과 같다.

Memo Evolution/
  index.html
  style.css
  script.js
  react-memo/

React 프로젝트는 react-memo 폴더 안에 생성했다.

Vite를 사용해서 React 프로젝트를 만들었다.

npm create vite@latest react-memo -- --template react

그다음 React 프로젝트 폴더로 이동해서 필요한 패키지를 설치했다.

cd react-memo
npm install

개발 서버는 다음 명령어로 실행한다.

npm run dev

브라우저에서는 보통 다음 주소로 접속한다.

http://localhost:5173

Vite 개발 서버

npm run dev로 Vite 개발 서버를 실행하면 React 앱을 로컬에서 확인할 수 있다.

한 번 서버를 실행한 뒤에는 App.jsx, App.css 같은 파일을 수정할 때마다 보통 자동으로 화면이 갱신된다.

이 기능을 HMR이라고 한다.

HMR = Hot Module Replacement
파일을 저장하면 브라우저에 바로 반영되는 기능

그래서 단순히 App.jsx나 App.css를 수정할 때마다 매번 서버를 재실행할 필요는 없다.

다만 다음 경우에는 재실행이 필요할 수 있다.

npm run dev를 꺼버린 경우
새 라이브러리를 설치한 경우
package.json을 수정한 경우
vite.config.js를 수정한 경우
개발 서버가 에러로 종료된 경우

Vite 기본 화면 제거하기

처음 React 프로젝트를 만들면 Vite 기본 화면이 들어 있다.

App.jsx에는 React 로고, Vite 로고, 카운터 예제가 있었다.

하지만 지금 목표는 메모장을 다시 만드는 것이므로 기본 코드는 제거했다.

기존에 있던 예시 코드들은 필요 없었다.

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from './assets/vite.svg'

const [count, setCount] = useState(0)

이번 단계에서는 아직 useState를 쓰지 않는다.
목표는 단순히 React에서 정적인 메모장 화면을 만드는 것이다.

React에서 정적인 메모장 화면 만들기

기존 HTML에서 만들었던 메모장 구조를 React의 JSX로 옮겼다.

react-memo/src/App.jsx는 다음과 같은 구조로 만들었다.

import './App.css'

function App() {
  return (
    <div className="app">
      <div className="memo-form">
        <h2>새 메모 작성</h2>

        <label htmlFor="memo-title">제목</label>
        <input id="memo-title" type="text" placeholder="제목을 입력하세요" />

        <label htmlFor="memo-content">내용</label>
        <textarea id="memo-content" placeholder="내용을 입력하세요"></textarea>

        <button type="button">메모 추가</button>
      </div>

      <div className="memo-list">
        <h2>메모 목록</h2>
        <p className="empty-message">아직 작성된 메모가 없습니다.</p>
      </div>
    </div>
  )
}

export default App

아직 기능은 없다.

버튼 클릭 기능 없음
입력값 관리 없음
메모 추가 없음
localStorage 없음

이번 단계는 화면 구조만 React로 옮기는 것이 목표였다.

HTML과 JSX의 차이

React에서는 HTML과 비슷하게 생긴 JSX를 사용한다.

하지만 완전히 같은 문법은 아니다.

가장 먼저 만난 차이는 class와 for였다.

HTML에서는 다음처럼 쓴다.

<div class="app">

React JSX에서는 className을 사용한다.

<div className="app">

또 HTML에서는 label과 input을 연결할 때 for를 쓴다.

<label for="memo-title">제목</label>

React JSX에서는 htmlFor를 사용한다.

<label htmlFor="memo-title">제목</label>

이유는 JSX가 JavaScript 문법 위에서 동작하기 때문이다.
class나 for는 JavaScript에서 이미 다른 의미로 사용되는 단어라서 React에서는 다른 이름을 쓴다.

또 하나의 차이는 input 태그다.

HTML에서는 이렇게 써도 된다.

<input id="memo-title" type="text">

하지만 JSX에서는 닫는 표시를 해주는 방식이 일반적이다.

<input id="memo-title" type="text" />

이번 단계에서 기억할 JSX 차이는 다음과 같다.

class → className
for → htmlFor
input은 self-closing으로 작성

CSS 옮기기

기존 JavaScript 메모장에서 사용하던 CSS를 React 프로젝트의 App.css로 옮겼다.

수정할 파일은 다음이다.

react-memo/src/App.css

Vite 기본 CSS는 메모장 프로젝트에 필요 없어서 제거하고, 기존 메모장 스타일을 적용했다.

body {
  margin: 0;
  font-family: sans-serif;
  background-color: #f4f4f4;
}

.app {
  width: 500px;
  margin: 40px auto;
  padding: 24px;
  background-color: white;
}

.memo-form {
  margin-bottom: 32px;
}

.memo-form label {
  display: block;
  margin-top: 12px;
  margin-bottom: 6px;
}

button {
  margin-top: 12px;
  padding: 10px 16px;
  cursor: pointer;
}

.empty-message {
  color: #777;
}

.memo-form input,
.memo-form textarea {
  display: block;
  width: 100%;
  padding: 10px;
  box-sizing: border-box;
}

이렇게 해서 React에서도 기존과 비슷한 정적 메모장 화면을 볼 수 있게 되었다.

이번 단계는 React 기능 구현이 아니라 React 환경에 진입하는 단계였다.

핵심은 다음과 같다.

기존 HTML/CSS 메모장 화면을 React 프로젝트 안으로 옮겼다.
React에서는 JSX로 화면을 작성한다.
class는 className으로, for는 htmlFor로 쓴다.
아직 기능은 없고 정적인 화면만 만든 상태다.

다음 단계에서는 useState를 사용해서 입력값과 메모 배열을 React 상태로 관리하겠다.

#10 React로 넘어가기 전에 컴포넌트 이해하기

sqaxe1 — Mon, 15 Jun 2026 10:25:15 +0900

Vanilla JavaScript로 메모장의 기본 CRUD 기능을 구현했다.

지금까지 구현한 기능은 다음과 같다.

메모 추가
메모 목록 조회
메모 수정
메모 삭제
localStorage 저장
새로고침 후 데이터 유지

이제 다음 단계에서는 기존 메모장 기능을 React로 다시 구현해보려고 한다.

바로 React 프로젝트를 만들기 전에, 먼저 React에서 가장 기본이 되는 컴포넌트 개념을 정리해보려고 한다.

컴포넌트란?

컴포넌트는 쉽게 말하면 다음과 같다.

화면의 한 부분을 담당하는 JavaScript 함수

지금 만든 메모장 화면을 보면 여러 영역으로 나눌 수 있다.

전체 앱
메모 입력 영역
메모 목록 영역
메모 카드 하나

Vanilla JavaScript 단계에서는 HTML 안에 화면 구조가 전부 같이 들어 있었다.

<div class="app">
    <div class="memo-form">...</div>
    <div class="memo-list">...</div>
</div>

React에서는 이런 화면 구조를 함수 단위로 나눌 수 있다.

function App() {
    return (
        <div className="app">
            <MemoForm />
            <MemoList />
        </div>
    );
}

여기서 각각의 역할은 다음과 같다.

App
= 전체 화면 컴포넌트

MemoForm
= 메모 작성 영역 컴포넌트

MemoList
= 메모 목록 영역 컴포넌트

즉, React에서는 화면을 하나의 큰 HTML 덩어리로 보는 것이 아니라, 여러 컴포넌트를 조립해서 만드는 방식으로 본다.

왜 컴포넌트로 나누나?

한 파일에 모든 UI를 다 작성하면 처음에는 편하다.

하지만 기능이 조금만 커져도 코드가 복잡해진다.

메모장만 봐도 다음 코드들이 한 곳에 섞일 수 있다.

입력창 코드
버튼 코드
메모 목록 코드
수정 코드
삭제 코드
저장 코드

처음에는 별문제가 없어 보이지만, 나중에는 어디가 입력 영역이고 어디가 목록 영역인지 구분하기 어려워질 수 있다.

컴포넌트로 나누면 역할이 더 명확해진다.

MemoForm
= 제목/내용 입력, 추가 버튼

MemoList
= 메모 목록 출력

MemoItem
= 메모 카드 하나, 수정/삭제 버튼

즉, 컴포넌트는 HTML을 기능별 조각으로 나누는 느낌이다.

현재 메모장을 React 컴포넌트로 나누면

현재 메모장 구조를 React 컴포넌트로 나누면 다음과 같이 볼 수 있다.

App
- 전체 상태 memos를 가지고 있음
- addMemo, editMemo, deleteMemo 함수 가지고 있음

MemoForm
- 제목/내용 입력
- 추가 버튼

MemoList
- memos 배열을 받아서 목록 출력

MemoItem
- 메모 하나 표시
- 수정/삭제 버튼

구조로 보면 다음과 같다.

App
 ├─ MemoForm
 └─ MemoList
      ├─ MemoItem
      ├─ MemoItem
      └─ MemoItem

여기서 중요한 점은 App이 전체 데이터를 가지고 있다는 것이다.

Vanilla JavaScript에서는 memos 배열을 전역 변수처럼 사용했다.

let memos = [];

React에서도 처음에는 비슷하게 App 컴포넌트가 메모 목록 데이터를 가지고 시작하면 된다.
그다음 MemoForm, MemoList, MemoItem으로 필요한 값을 내려보내는 식으로 구조를 잡을 수 있다.

React를 처음 시작할 때 모든 컴포넌트를 처음부터 나누려고 하면 오히려 헷갈릴 수 있다.

그래서 처음에는 App 컴포넌트 하나에 전체 기능을 작성해도 된다.

순서는 다음과 같다.

1. App 컴포넌트 하나에서 메모장 구현
2. MemoForm 컴포넌트 분리
3. MemoList 컴포넌트 분리
4. MemoItem 컴포넌트 분리

처음부터 완벽한 구조를 만들려고 하기보다, 먼저 동작하게 만들고 그다음에 역할별로 나누는 방식이 더 이해하기 쉽다.

Vanilla JS와 React 비교

Vanilla JavaScript에서는 메모 카드를 만들 때 직접 HTML 요소를 생성했다.

const memoCard = document.createElement('div');

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
`;

memoContainer.appendChild(memoCard);

즉, JavaScript로 HTML 요소를 직접 만들고, 직접 화면에 붙였다.

React에서는 컴포넌트 함수가 JSX를 반환한다.

function MemoItem() {
    return (
        <div className="memo-card">
            <h3>제목</h3>
            <p>내용</p>
        </div>
    );
}

겉으로 보면 HTML처럼 생겼지만, 실제로는 JavaScript 안에서 작성하는 JSX 문법이다.

정리하면 다음과 같다.

Vanilla JS
= JS로 HTML 요소를 직접 만들고 DOM에 붙인다.

React
= 컴포넌트 함수가 JSX를 반환하고, React가 화면을 갱신한다.

이 차이가 React를 배우면서 가장 먼저 익숙해져야 하는 부분이다.

class와 className

React에서는 HTML의 class 대신 className을 사용한다.

Vanilla HTML에서는 이렇게 작성했다.

<div class="app"></div>

React JSX에서는 이렇게 작성한다.

<div className="app"></div>

처음에는 어색하지만, JSX가 HTML 그대로가 아니라 JavaScript 안에서 사용하는 문법이기 때문에 className을 사용한다고 이해하면 된다.

핵심은 다음과 같다.

컴포넌트는 화면 조각을 담당하는 함수다.
React 화면은 컴포넌트들을 조립해서 만든다.
처음에는 App 하나로 시작해도 된다.
나중에 MemoForm, MemoList, MemoItem으로 나누면 된다.

지금 단계에서는 React의 모든 개념을 한 번에 이해하려고 하기보다, 기존에 만든 메모장 화면을 어떻게 컴포넌트로 나눌 수 있는지만 먼저 잡으면 된다.

이제부터는 같은 메모장 기능을 React 방식으로 다시 구현하면서, 기존 JavaScript 방식과 어떤 점이 다른지 비교해볼 예정이다.

#9 JavaScript 코드 구조 정리하기

sqaxe1 — Mon, 15 Jun 2026 09:11:43 +0900

이전까지 메모장에는 기본 CRUD 기능이 들어갔다.

Create → 메모 추가
Read   → 메모 목록 보기
Update → 메모 수정
Delete → 메모 삭제

그리고 localStorage를 사용해서 새로고침 후에도 메모가 유지되도록 만들었다.

이번 단계에서는 새로운 기능을 크게 추가하기보다는, 기존 코드를 더 이해하기 좋은 구조로 정리했다.

핵심 목표는 다음과 같다.

추가, 수정, 삭제 로직을 함수로 분리하기
입력값 앞뒤 공백 처리하기
삭제 전 확인창 추가하기

왜 함수로 분리했나

처음에는 버튼 이벤트 안에 모든 로직이 들어 있었다.

예를 들어 삭제 버튼 이벤트 안에서 바로 배열을 수정하고, 저장하고, 다시 렌더링했다.

deleteButton.addEventListener('click', function () {
    memos = memos.filter(function (item) {
        return item.id !== memo.id;
    });

    saveMemos();
    renderMemos();
});

이 방식도 동작은 한다.

하지만 코드가 길어질수록 이벤트 안에 너무 많은 일이 들어가게 된다.
이벤트 안에 추가, 수정, 삭제 로직이 그대로 들어 있으면 나중에 코드를 읽을 때 흐름을 파악하기 어려워질 수 있다.

그래서 역할별로 함수를 나눴다.

addMemo()
= 메모 추가 담당

editMemo()
= 메모 수정 담당

deleteMemo()
= 메모 삭제 담당

renderMemos()
= 화면 렌더링 담당

saveMemos()
= localStorage 저장 담당

loadMemos()
= localStorage 불러오기 담당

이렇게 나누면 각 함수가 어떤 일을 하는지 더 명확하게 보인다.

현재 코드 구조

현재 script.js의 큰 구조는 다음과 같다.

const titleInput = document.getElementById("memo-title");
const contentInput = document.getElementById("memo-content");
const addMemoButton = document.getElementById("add-memo-button");
const memoContainer = document.getElementById("memo-container");
const emptyMessage = document.getElementById("empty-message");

let memos = [];

function saveMemos() {
    ...
}

function loadMemos() {
    ...
}

function updateEmptyMessage() {
    ...
}

function deleteMemo(id) {
    ...
}

function editMemo(id) {
    ...
}

function addMemo(title, content) {
    ...
}

function renderMemos() {
    ...
}

addMemoButton.addEventListener('click', function () {
    ...
});

loadMemos();
renderMemos();

위에서부터 보면 흐름이 이전보다 조금 더 명확하다.

1. HTML 요소 가져오기
2. 메모 데이터 배열 준비
3. 저장/불러오기 함수
4. 빈 메시지 처리 함수
5. 삭제/수정/추가 함수
6. 렌더링 함수
7. 이벤트 등록
8. 초기 실행

삭제 로직 분리하기

먼저 삭제 로직을 deleteMemo(id) 함수로 분리했다.

function deleteMemo(id) {
    const isConfirmed = confirm("정말 삭제하시겠습니까?");

    if (!isConfirmed) {
        return;
    }

    memos = memos.filter(function (item) {
        return item.id !== id;
    });

    saveMemos();
    renderMemos();
}

이 함수는 삭제할 메모의 id를 매개변수로 받는다.

삭제 버튼을 클릭했을 때는 해당 메모의 id를 넘겨준다.

deleteButton.addEventListener('click', function () {
    deleteMemo(memo.id);
});

흐름은 다음과 같다.

삭제 버튼 클릭
→ deleteMemo(memo.id) 호출
→ confirm으로 삭제 여부 확인
→ 취소하면 return
→ 확인하면 memos 배열에서 해당 id 제거
→ saveMemos()
→ renderMemos()

confirm으로 삭제 확인하기

삭제는 실수로 누를 수 있기 때문에 확인창을 추가했다.

const isConfirmed = confirm("정말 삭제하시겠습니까?");

confirm()은 사용자가 누른 버튼에 따라 값을 반환한다.

확인 → true
취소 → false

그래서 취소를 누른 경우에는 바로 함수를 종료한다.

if (!isConfirmed) {
    return;
}

이렇게 하면 사용자가 취소를 눌렀을 때 삭제 로직이 실행되지 않는다.

수정 로직 분리하기

수정 로직은 editMemo(id) 함수로 분리했다.

function editMemo(id) {
    const targetMemo = memos.find(function (item) {
        return item.id === id;
    });

    const newTitle = prompt("새 제목을 입력하세요", targetMemo.title.trim());
    const newContent = prompt("새 내용을 입력하세요", targetMemo.content.trim());

    if (newTitle === null || newContent === null) {
        return;
    }

    if (newTitle.trim() === '' || newContent.trim() === '') {
        alert("제목과 내용을 모두 입력하세요.");
        return;
    }

    memos = memos.map(function (item) {
        if (item.id === id) {
            return {
                id: item.id,
                title: newTitle.trim(),
                content: newContent.trim()
            };
        }

        return item;
    });

    saveMemos();
    renderMemos();
}

수정 버튼을 클릭하면 해당 메모의 id를 넘긴다.

editButton.addEventListener('click', function () {
    editMemo(memo.id);
});

수정할 메모 찾기

editMemo(id) 함수는 id만 받는다.

그런데 기존 제목과 내용을 prompt에 보여주려면, 먼저 memos 배열에서 해당 id를 가진 메모를 찾아야 한다.

const targetMemo = memos.find(function (item) {
    return item.id === id;
});

find()는 배열에서 조건에 맞는 첫 번째 요소를 찾는다.

여기서는 다음 조건에 맞는 메모를 찾는다.

item.id가 수정하려는 id와 같은 메모

찾은 메모를 targetMemo에 담고, 기존 제목과 내용을 prompt의 기본값으로 사용했다.

const newTitle = prompt("새 제목을 입력하세요", targetMemo.title.trim());
const newContent = prompt("새 내용을 입력하세요", targetMemo.content.trim());

수정 취소 처리

사용자가 prompt에서 취소를 누르면 결과는 null이다.

if (newTitle === null || newContent === null) {
    return;
}

이렇게 처리해서 취소 시에는 수정 작업을 중단한다.

수정 시 공백 입력 방지

수정할 때 공백만 입력하는 것도 막았다.

if (newTitle.trim() === '' || newContent.trim() === '') {
    alert("제목과 내용을 모두 입력하세요.");
    return;
}

trim()은 문자열 앞뒤 공백을 제거한다.

예를 들어 다음 값은 공백만 있는 문자열이다.

"     "

여기에 trim()을 적용하면 빈 문자열이 된다.

"     ".trim()

결과는 다음과 같다.

""

그래서 공백만 입력한 경우도 빈 값으로 판단할 수 있다.

저장할 때도 앞뒤 공백이 제거된 값으로 저장했다.

title: newTitle.trim(),
content: newContent.trim()

map으로 해당 메모 수정하기

수정할 때는 map()을 사용했다.

memos = memos.map(function (item) {
    if (item.id === id) {
        return {
            id: item.id,
            title: newTitle.trim(),
            content: newContent.trim()
        };
    }

    return item;
});

이 코드는 memos 배열을 새 배열로 다시 만드는 코드다.

동작 방식은 다음과 같다.

1. memos 배열을 하나씩 확인한다.
2. 수정하려는 id와 같은 메모를 만나면 새 제목/내용을 가진 객체를 반환한다.
3. 수정 대상이 아니면 기존 item을 그대로 반환한다.

즉, 전체 배열을 돌지만 실제로 바뀌는 것은 id가 같은 메모 하나뿐이다.

추가 로직 분리하기

추가 로직도 addMemo(title, content) 함수로 분리했다.

function addMemo(title, content) {
    if (title === '' || content === '') {
        alert('제목과 내용을 모두 입력하세요.');
        return;
    }

    const newMemo = {
        id: Date.now(),
        title: title,
        content: content
    };

    memos.push(newMemo);
    saveMemos();
    renderMemos();
}

이 함수는 제목과 내용을 받아서 새 메모 객체를 만든다.

const newMemo = {
    id: Date.now(),
    title: title,
    content: content
};

그리고 memos 배열에 추가한다.

memos.push(newMemo);

그 후 localStorage에 저장하고 화면을 다시 그린다.

saveMemos();
renderMemos();

추가 버튼 이벤트 정리

추가 버튼 이벤트는 이전보다 짧아졌다.

addMemoButton.addEventListener('click', function () {
    const title = titleInput.value.trim();
    const content = contentInput.value.trim();

    addMemo(title, content);

    titleInput.value = '';
    contentInput.value = '';
});

입력값을 가져올 때 trim()을 사용했다.

const title = titleInput.value.trim();
const content = contentInput.value.trim();

그래서 처음부터 앞뒤 공백을 제거한 값을 addMemo()에 넘긴다.

trim을 추가와 수정 둘 다 적용한 이유

처음에는 추가할 때만 trim()을 하면 충분할 것 같았다.

하지만 추가와 수정은 서로 다른 시점에 입력값을 받는다.

추가할 때 입력값
→ titleInput.value, contentInput.value

수정할 때 입력값
→ prompt에서 받은 newTitle, newContent

따라서 추가할 때 한 번 trim()했다고 해서, 수정할 때 입력한 값까지 자동으로 정리되는 것은 아니다.

그래서 수정할 때도 별도로 trim()을 적용했다.

newTitle.trim()
newContent.trim()

정리하면 다음과 같다.

추가 입력값은 추가 시점에 trim
수정 입력값은 수정 시점에 trim

renderMemos의 역할 유지

renderMemos()는 여전히 화면을 다시 그리는 역할이다.

function renderMemos() {
    memoContainer.innerHTML = '';

    memos.forEach(function (memo) {
        ...
    });

    updateEmptyMessage();
}

이 함수는 데이터를 직접 추가하거나 수정하거나 삭제하지 않는다.
현재 memos 배열을 기준으로 화면을 다시 만든다.

다만 메모 카드를 만들면서 각 카드의 수정/삭제 버튼에 이벤트를 연결한다.

editButton.addEventListener('click', function () {
    editMemo(memo.id);
});

deleteButton.addEventListener('click', function () {
    deleteMemo(memo.id);
});

이제 이벤트 안에는 복잡한 로직이 직접 들어가지 않고, 각각의 함수 호출만 남았다.

수정 버튼 클릭 → editMemo(memo.id)
삭제 버튼 클릭 → deleteMemo(memo.id)

이번 단계에서 정리된 구조

이번 단계 후 전체 구조는 이전보다 명확해졌다.

addMemo()
→ 메모 추가 담당

editMemo()
→ 메모 수정 담당

deleteMemo()
→ 메모 삭제 담당

saveMemos()
→ localStorage 저장 담당

loadMemos()
→ localStorage 불러오기 담당

renderMemos()
→ 화면 렌더링 담당

updateEmptyMessage()
→ 빈 목록 메시지 처리 담당

각 함수가 맡은 역할이 분리되면서, 코드를 읽을 때 흐름을 따라가기 쉬워졌다.

현재 완성 상태

현재 메모장은 다음 기능을 가진다.

메모 추가
메모 목록 조회
메모 수정
메모 삭제
삭제 전 확인
공백 입력 방지
줄바꿈 유지
localStorage 저장
새로고침 후 데이터 유지
함수 단위 코드 정리

#8 메모 수정 기능 구현

sqaxe1 — Sat, 13 Jun 2026 15:09:04 +0900

이번 단계에서는 메모장 CRUD 기능 중 Update, 즉 수정 기능을 구현했다.

이전까지는 다음 기능이 가능했다.

메모 추가
메모 목록 출력
메모 삭제
localStorage 저장 및 불러오기

하지만 작성한 메모를 수정할 수는 없었다.

이번에는 메모 카드에 수정 버튼을 추가하고, 사용자가 기존 제목과 내용을 바꿀 수 있도록 만들었다.

수정 버튼 추가하기

기존에는 메모 카드 안에 삭제 버튼만 있었다.

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
    <button type="button">삭제</button>
`;

수정 기능을 만들기 위해 버튼을 하나 더 추가했다.

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
    <button class="edit-button" type="button">수정</button>
    <button class="delete-button" type="button">삭제</button>
`;

버튼이 두 개가 되었기 때문에 각각 구분할 수 있도록 class를 붙였다.

<button class="edit-button" type="button">수정</button>
<button class="delete-button" type="button">삭제</button>

그리고 JavaScript에서 각각의 버튼을 따로 가져왔다.

const editButton = memoCard.querySelector('.edit-button');
const deleteButton = memoCard.querySelector('.delete-button');

기존처럼 memoCard.querySelector('button')만 사용하면 첫 번째 버튼 하나만 찾게 된다.
그래서 수정 버튼과 삭제 버튼을 명확히 구분하기 위해 각각 다른 클래스를 사용했다.

수정 버튼 이벤트 등록하기

수정 버튼을 클릭하면 기존 제목과 내용을 수정할 수 있어야 한다.

수정 버튼은 각 메모 카드가 만들어질 때 함께 생성된다.
그래서 수정 버튼 이벤트도 renderMemos() 안에서 메모 카드를 만들 때 같이 등록했다.

editButton.addEventListener('click', function () {
    // 수정 처리
});

이 이벤트 함수는 사용자가 해당 메모 카드의 수정 버튼을 눌렀을 때 실행된다.

기존 값을 보여주고 새 값 입력받기

수정할 값을 입력받기 위해 prompt()를 사용했다.

const newTitle = prompt("새 제목을 입력하세요", memo.title);
const newContent = prompt("새 내용을 입력하세요", memo.content);

prompt()의 두 번째 인자는 기본값이다.

prompt("새 제목을 입력하세요", memo.title);

이렇게 작성하면 prompt 창이 열릴 때 기존 제목이 입력창에 미리 들어가 있다.
내용도 마찬가지로 기존 내용을 기본값으로 보여준다.

prompt("새 내용을 입력하세요", memo.content);

즉, 수정 버튼을 누르면 기존 제목과 기존 내용이 먼저 보이고, 사용자는 그 값을 바꿔서 입력할 수 있다.

취소 처리하기

사용자가 prompt에서 취소를 누를 수도 있다.

prompt에서 취소를 누르면 결과값은 null이다.
그래서 다음 조건을 추가했다.

if (newTitle === null || newContent === null) {
    return;
}

이 코드는 사용자가 제목이나 내용 입력 중 하나라도 취소하면 수정 작업을 중단한다.

여기서 return은 현재 클릭 이벤트 함수를 끝내는 역할을 한다.

취소 누름
→ 수정하지 않음
→ 저장하지 않음
→ 화면 다시 그리지 않음

빈 값 방지하기

수정할 때 제목이나 내용을 빈 값으로 두는 것도 막았다.

if (newTitle === '' || newContent === '') {
    alert("제목과 내용을 모두 입력하세요.");
    return;
}

제목이나 내용 중 하나라도 빈 문자열이면 alert를 띄우고 수정 작업을 중단한다.

현재는 완전히 빈 문자열만 막는다.
나중에는 trim()을 사용해서 공백만 입력한 경우도 막을 수 있다.

if (newTitle.trim() === '' || newContent.trim() === '') {
    alert("제목과 내용을 모두 입력하세요.");
    return;
}

map으로 해당 메모 수정하기

이번 수정 기능의 핵심은 memos.map()이다.

memos = memos.map(function (item) {
    if (item.id === memo.id) {
        return {
            id: item.id,
            title: newTitle,
            content: newContent
        };
    }

    return item;
});

처음에는 이 부분이 헷갈렸다.

수정 버튼은 메모 하나의 버튼인데, 왜 배열 전체를 도는지 의문이 생겼다.

이유는 현재 메모의 원본 데이터가 memos 배열이기 때문이다.

let memos = [];

화면에 보이는 메모 카드는 원본이 아니라, memos 배열을 보고 그린 결과다.
따라서 메모를 수정하려면 화면의 글자만 바꾸는 것이 아니라 memos 배열 안의 해당 메모 데이터를 바꿔야 한다.

map()은 배열을 돌면서 새로운 배열을 만드는 메서드다.

이번 코드에서는 다음처럼 동작한다.

1. memos 배열을 하나씩 확인한다.
2. 현재 item의 id가 수정하려는 memo.id와 같으면 새 제목/내용을 가진 객체를 반환한다.
3. id가 다르면 기존 item을 그대로 반환한다.
4. 그 결과로 새 배열을 만들고 다시 memos에 넣는다.

예를 들어 현재 배열이 이렇게 있다고 하자.

memos = [
    { id: 1, title: 'A', content: '내용 A' },
    { id: 2, title: 'B', content: '내용 B' },
    { id: 3, title: 'C', content: '내용 C' }
];

id가 2인 메모를 수정한다면 다음처럼 처리된다.

id 1 → 수정 대상 아님 → 그대로 반환
id 2 → 수정 대상 맞음 → 새 제목/내용으로 바꾼 객체 반환
id 3 → 수정 대상 아님 → 그대로 반환

결과적으로 배열은 이렇게 바뀐다.

memos = [
    { id: 1, title: 'A', content: '내용 A' },
    { id: 2, title: '새 제목', content: '새 내용' },
    { id: 3, title: 'C', content: '내용 C' }
];

전체 배열을 돌지만 실제로 바뀌는 것은 id가 같은 메모 하나뿐이다.

수정 후 저장하고 다시 그리기

배열에서 메모를 수정한 뒤에는 두 가지 작업이 필요하다.

saveMemos();
renderMemos();

먼저 수정된 memos 배열을 localStorage에 저장한다.

saveMemos();

그래야 새로고침 후에도 수정된 내용이 유지된다.

그다음 화면을 다시 그린다.

renderMemos();

현재 화면은 이전 메모 내용을 보여주고 있기 때문에, 수정된 memos 배열을 기준으로 다시 렌더링해야 한다.

이 프로젝트의 기본 흐름은 계속 동일하다.

데이터 변경
→ saveMemos()
→ renderMemos()

추가할 때도 같은 흐름이다.

memos.push(newMemo);
saveMemos();
renderMemos();

삭제할 때도 같은 흐름이다.

memos = memos.filter(...);
saveMemos();
renderMemos();

수정할 때도 같은 흐름이다.

memos = memos.map(...);
saveMemos();
renderMemos();

즉, 추가, 삭제, 수정 모두 같은 구조를 가진다.

수정 이벤트 전체 코드

수정 버튼 이벤트 코드는 다음과 같다.

editButton.addEventListener('click', function () {
    const newTitle = prompt("새 제목을 입력하세요", memo.title);
    const newContent = prompt("새 내용을 입력하세요", memo.content);

    if (newTitle === null || newContent === null) {
        return;
    }

    if (newTitle === '' || newContent === '') {
        alert("제목과 내용을 모두 입력하세요.");
        return;
    }

    memos = memos.map(function (item) {
        if (item.id === memo.id) {
            return {
                id: item.id,
                title: newTitle,
                content: newContent
            };
        }

        return item;
    });

    saveMemos();
    renderMemos();
});

#7 localStorage로 메모 저장하기

sqaxe1 — Sat, 13 Jun 2026 12:46:51 +0900

이번 단계에서는 새로고침해도 메모가 사라지지 않도록 localStorage를 사용했다.

이전까지는 메모를 memos 배열로 관리했다.

let memos = [];

메모를 추가하면 배열에 저장되고, 삭제하면 배열에서 제거되는 구조였다.

하지만 이 배열은 브라우저 메모리 안에만 존재한다.
그래서 페이지를 새로고침하면 JavaScript가 처음부터 다시 실행되고, memos 배열도 다시 빈 배열이 된다.

let memos = [];

즉, 이전 단계에서는 메모 추가와 삭제는 가능했지만 새로고침하면 모든 메모가 사라지는 문제가 있었다.

이번 단계에서는 이 문제를 해결하기 위해 localStorage를 사용했다.

localStorage란

localStorage는 브라우저에 데이터를 저장할 수 있는 공간이다.

간단히 말하면 브라우저 안에 있는 작은 저장소라고 볼 수 있다.
그래서 페이지를 새로고침해도 저장된 데이터가 유지된다.

다만 중요한 특징이 있다.

localStorage는 문자열만 저장할 수 있다.

현재 메모 하나는 객체 형태다.

const newMemo = {
    id: Date.now(),
    title: title,
    content: content
};

그리고 메모 목록은 이런 객체들이 들어 있는 배열이다.

[
    {
        id: 1,
        title: '첫 번째 메모',
        content: '내용 1'
    },
    {
        id: 2,
        title: '두 번째 메모',
        content: '내용 2'
    }
]

하지만 localStorage에는 배열이나 객체를 그대로 저장할 수 없다.
문자열로 바꿔서 저장해야 한다.

저장할 때는 JSON.stringify()를 사용한다.

JSON.stringify(memos)

반대로 다시 꺼낼 때는 문자열을 배열로 복원해야 한다.
이때는 JSON.parse()를 사용한다.

JSON.parse(savedMemos)

정리하면 흐름은 다음과 같다.

저장할 때:
배열 → JSON.stringify → 문자열 → localStorage

불러올 때:
localStorage 문자열 → JSON.parse → 배열

메모 저장 함수 만들기

먼저 현재 memos 배열을 localStorage에 저장하는 함수를 만들었다.

function saveMemos() {
    localStorage.setItem('memos', JSON.stringify(memos));
}

`localStorage.setItem()`은 데이터를 저장할 때 사용한다.

localStorage.setItem('memos', JSON.stringify(memos));

여기서 'memos'는 저장소에서 사용할 이름이다.
즉, 현재 메모 배열을 memos라는 이름으로 저장한다는 뜻이다.

`JSON.stringify(memos)`는 배열을 문자열로 바꿔준다.

결과적으로 saveMemos() 함수는 다음 역할을 한다.

현재 memos 배열을 문자열로 변환해서 localStorage에 저장한다.

saveMemos는 언제 호출해야 하나

saveMemos()는 memos 배열이 바뀐 직후에 호출해야 한다.

현재 memos 배열이 바뀌는 순간은 두 곳이다.

1. 메모 추가 후
2. 메모 삭제 후

메모를 추가할 때는 새 메모를 배열에 넣는다.

memos.push(newMemo);

그리고 그 직후 저장한다.

memos.push(newMemo);
saveMemos();
renderMemos();

메모를 삭제할 때는 filter()로 삭제할 메모를 제외한 새 배열을 만든다.

memos = memos.filter(function (item) {
    return item.id !== memo.id;
});

이때도 배열이 바뀌었으므로 바로 저장해야 한다.

memos = memos.filter(function (item) {
    return item.id !== memo.id;
});

saveMemos();
renderMemos();

즉, 흐름은 다음과 같다.

메모 추가
→ memos 배열 변경
→ saveMemos()
→ renderMemos()

메모 삭제
→ memos 배열 변경
→ saveMemos()
→ renderMemos()

배열만 바꾸고 saveMemos()를 호출하지 않으면 화면에서는 바뀐 것처럼 보이지만, 새로고침했을 때 이전 저장 상태로 돌아갈 수 있다.

메모 불러오기 함수 만들기

저장만 해서는 부족하다.
페이지가 다시 열렸을 때 저장된 메모를 불러와야 한다.

그래서 loadMemos() 함수를 만들었다.

function loadMemos() {
    const savedMemos = localStorage.getItem('memos');

    if (savedMemos !== null) {
        memos = JSON.parse(savedMemos);
    }
}

먼저 localStorage에서 memos라는 이름으로 저장된 값을 꺼낸다.

const savedMemos = localStorage.getItem('memos');

만약 저장된 값이 없다면 null이 나온다.

그래서 조건문으로 저장된 값이 있는지 확인한다.

if (savedMemos !== null) {
    memos = JSON.parse(savedMemos);
}

저장된 값이 있을 때만 `JSON.parse()`를 실행한다.
JSON.parse(savedMemos)는 문자열로 저장된 메모 데이터를 다시 배열로 바꿔준다.

그리고 그 배열을 다시 memos에 넣는다.

memos = JSON.parse(savedMemos);

결국 loadMemos()의 역할은 다음과 같다.

localStorage에서 저장된 메모를 꺼낸다.
저장된 메모가 있으면 배열로 복원한다.
복원한 배열을 memos에 넣는다.

처음 저장된 데이터가 없을 때

처음 페이지를 방문하면 localStorage에는 아직 저장된 메모가 없을 수 있다.

그 경우 다음 코드의 결과는 null이다.

const savedMemos = localStorage.getItem('memos');

그러면 조건문이 실행되지 않는다.

if (savedMemos !== null) {
    memos = JSON.parse(savedMemos);
}

이 경우 memos는 처음 선언한 빈 배열 그대로 유지된다.

let memos = [];

그리고 renderMemos()가 실행되면 빈 배열을 기준으로 화면을 그린다.

메모 없음
→ 메모 카드 생성 안 함
→ "아직 작성된 메모가 없습니다." 표시

그래서 처음 방문했을 때도 오류 없이 빈 메모장 화면이 나온다.

loadMemos 호출 위치

loadMemos()는 페이지가 처음 열릴 때 한 번만 실행하면 된다.

파일 맨 아래에서 다음 순서로 호출했다.

loadMemos();
renderMemos();

이 순서가 중요하다.

먼저 localStorage에서 저장된 메모를 불러와 memos 배열에 넣는다.
그다음 renderMemos()로 화면을 그린다.

만약 renderMemos()를 먼저 실행하면 아직 저장된 데이터가 memos 배열에 들어오기 전이므로, 화면에 저장된 메모가 보이지 않을 수 있다.

그래서 순서는 다음처럼 잡았다.

1. loadMemos()
2. renderMemos()

현재 코드 구조

현재 script.js의 핵심 구조는 다음과 같다.

let memos = [];

function saveMemos() {
    localStorage.setItem('memos', JSON.stringify(memos));
}

function loadMemos() {
    const savedMemos = localStorage.getItem('memos');

    if (savedMemos !== null) {
        memos = JSON.parse(savedMemos);
    }
}

function renderMemos() {
    // memos 배열을 기준으로 화면 다시 그리기
}

addMemoButton.addEventListener('click', function () {
    // 입력값 가져오기
    // 새 메모 객체 만들기

    memos.push(newMemo);
    saveMemos();
    renderMemos();

    // 입력창 비우기
});

loadMemos();
renderMemos();

전체 흐름 정리

이제 전체 흐름은 다음과 같다.

페이지가 처음 열릴 때

loadMemos()
→ localStorage에서 저장된 메모를 가져온다.
→ JSON.parse로 배열로 변환한다.
→ memos 배열에 넣는다.

renderMemos()
→ memos 배열을 기준으로 화면을 그린다.

메모를 추가할 때

사용자가 제목과 내용 입력
→ 메모 추가 버튼 클릭
→ newMemo 객체 생성
→ memos 배열에 추가
→ saveMemos()
→ renderMemos()
→ 입력창 비우기

메모를 삭제할 때

삭제 버튼 클릭
→ memos 배열에서 해당 메모 제거
→ saveMemos()
→ renderMemos()

이제 메모 추가와 삭제가 단순히 화면에만 반영되는 것이 아니라, localStorage에도 같이 반영된다.

#6 메모 내용 줄바꿈 처리하기

sqaxe1 — Thu, 11 Jun 2026 23:36:50 +0900

이번에는 메모 내용을 입력하면서 생긴 작은 문제를 수정했다.

문제는 textarea에서는 줄바꿈이 잘 입력되는데, 메모 목록에 출력하면 줄바꿈이 사라지는 것이었다.

예를 들어 메모 내용을 이렇게 입력했다.

첫 번째 줄
두 번째 줄
세 번째 줄

하지만 메모 카드에서는 다음처럼 한 줄로 보였다.

첫 번째 줄 두 번째 줄 세 번째 줄

처음에는 JavaScript에서 입력값을 잘못 가져오는 문제라고 생각했다.
하지만 확인해보니 입력값 자체가 사라진 것은 아니었다.

문제는 메모 내용을 출력하는 HTML 태그의 기본 동작에 있었다.

문제 원인

현재 메모 내용은 <p> 태그 안에 출력하고 있었다.

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
    <button type="button">삭제</button>
`;

textarea에서는 엔터를 누르면 줄바꿈이 그대로 보인다.
하지만 그 값을 <p> 태그 안에 넣으면 브라우저는 줄바꿈을 그대로 보여주지 않는다.

예를 들어 HTML에 이렇게 작성해도,

<p>
첫 번째 줄
두 번째 줄
</p>

화면에서는 보통 다음처럼 보인다.

첫 번째 줄 두 번째 줄

일반 HTML 텍스트 요소는 여러 공백과 줄바꿈을 하나의 공백처럼 처리하기 때문이다.

즉, 이번 문제는 다음과 같이 정리할 수 있다.

textarea에서 줄바꿈이 사라진 것이 아니다.
JavaScript가 값을 잘못 가져온 것도 아니다.
p 태그가 기본적으로 줄바꿈을 그대로 보여주지 않는 것이다.

해결 방법

이번에는 <p> 태그를 그대로 사용하고, CSS에서 줄바꿈을 유지하도록 처리했다.

.memo-card p {
    white-space: pre-wrap;
}

white-space: pre-wrap;을 사용하면 사용자가 입력한 줄바꿈을 화면에 반영할 수 있다.

그래서 현재 구조는 그대로 유지했다.

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
    <button type="button">삭제</button>
`;

대신 CSS에 다음 코드를 추가했다.

.memo-card p {
    white-space: pre-wrap;
}

이렇게 수정하니 textarea에서 입력한 줄바꿈이 메모 카드에서도 그대로 보였다.

pre 태그와의 차이

다른 방법으로는 <pre> 태그를 사용할 수도 있다.

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <pre>${memo.content}</pre>
    <button type="button">삭제</button>
`;

pre 태그는 기본적으로 줄바꿈과 공백을 유지한다.

다만 pre 태그는 일반 문단이라기보다는 코드나 서식이 있는 텍스트를 보여주는 느낌이 강하다.
메모장 본문에는 일반 문단처럼 보이는 <p> 태그를 유지하고, CSS로 줄바꿈만 처리하는 방식이 더 자연스럽다고 판단했다.

#5 메모데이터를 배열로 관리

sqaxe1 — Thu, 11 Jun 2026 23:20:44 +0900

메모 데이터를 배열로 관리하기

이전까지는 메모를 추가하면 바로 HTML 요소를 만들고 화면에 붙였다.

흐름은 단순했다.

입력값 → HTML 요소 생성 → 화면에 바로 추가

하지만 이 방식은 메모 데이터가 따로 관리되지 않는다는 문제가 있었다.

화면에 메모가 보이기는 하지만, JavaScript 입장에서는 “현재 어떤 메모들이 있는지”를 명확하게 관리하기 어렵다.

그래서 이번 단계에서는 메모 데이터를 배열로 관리하도록 구조를 바꿨다.

입력값 → 메모 객체 생성 → memos 배열에 저장 → 배열을 기준으로 화면 다시 그리기

즉, 이제 메모의 원본은 화면이 아니라 memos 배열이다.

왜 배열로 관리해야 하나

처음에는 메모를 추가할 때 바로 화면에 붙이는 방식이 더 단순해 보였다.

하지만 삭제, 수정, 저장 기능으로 넘어가려면 문제가 생긴다.

예를 들어 다음과 같은 질문이 생긴다.

삭제할 때 어떤 메모를 지울 것인가?
수정할 때 어떤 메모를 수정할 것인가?
localStorage에는 무엇을 저장할 것인가?
나중에 서버나 DB에는 어떤 데이터를 보낼 것인가?

HTML은 화면에 보여주기 위한 결과물이다.
데이터 자체를 관리하기에는 적절하지 않다.

그래서 메모를 먼저 JavaScript 데이터로 관리하기로 했다.

let memos = [];

이 배열 안에 메모 객체들이 들어간다.

예를 들어 메모가 2개라면 데이터는 이런 형태가 된다.

[
    {
        id: 1,
        title: '첫 번째 메모',
        content: '내용 1'
    },
    {
        id: 2,
        title: '두 번째 메모',
        content: '내용 2'
    }
]

이제 화면은 이 배열을 기준으로 그려진다.

최종 코드

이번 단계에서 작성한 script.js는 다음과 같다.

const titleInput = document.getElementById("memo-title");
const contentInput = document.getElementById("memo-content");
const addMemoButton = document.getElementById("add-memo-button");
const memoContainer = document.getElementById("memo-container");
const emptyMessage = document.getElementById("empty-message");

let memos = [];

function updateEmptyMessage() {
    if (memos.length === 0) {
        emptyMessage.style.display = 'block';
    } else {
        emptyMessage.style.display = 'none';
    }
}

function renderMemos() {
    memoContainer.innerHTML = '';

    memos.forEach(function (memo) {
        const memoCard = document.createElement('div');
        memoCard.className = 'memo-card';

        memoCard.innerHTML = `
            <h3>${memo.title}</h3>
            <p>${memo.content}</p>
            <button type="button">삭제</button>
        `;

        const deleteButton = memoCard.querySelector('button');

        deleteButton.addEventListener('click', function () {
            memos = memos.filter(function (item) {
                return item.id !== memo.id;
            });

            renderMemos();
        });

        memoContainer.appendChild(memoCard);
    });

    updateEmptyMessage();
}

addMemoButton.addEventListener('click', function () {
    const title = titleInput.value.trim();
    const content = contentInput.value.trim();

    if (title === '' || content === '') {
        alert('제목과 내용을 모두 입력하세요.');
        return;
    }

    const newMemo = {
        id: Date.now(),
        title: title,
        content: content
    };

    memos.push(newMemo);

    renderMemos();

    titleInput.value = '';
    contentInput.value = '';
});

renderMemos 함수

이번 단계에서 가장 중요한 함수는 renderMemos()다.

function renderMemos() {
    memoContainer.innerHTML = '';

    memos.forEach(function (memo) {
        ...
    });

    updateEmptyMessage();
}

처음에는 renderMemos()를 단순히 화면에 메모를 보여주는 함수라고 생각했다.

하지만 더 정확히는 다음과 같다.

renderMemos()
= 현재 memos 배열 상태와 화면을 똑같이 맞추는 함수

배열에 메모가 2개 있으면 화면에도 2개가 보여야 한다.
배열이 비어 있으면 화면에서도 메모가 보이면 안 된다.

즉, 화면은 memos 배열을 보고 다시 만들어지는 결과물이다.

왜 화면을 먼저 비우는가

renderMemos() 안에는 다음 코드가 있다.

memoContainer.innerHTML = '';

처음에는 이 코드가 메모를 전부 삭제하는 것처럼 보여서 헷갈렸다.

하지만 이 코드는 데이터를 삭제하는 코드가 아니다.
memos 배열은 그대로 두고, 화면에 이미 그려져 있던 메모 카드만 지운다.

이유는 renderMemos()가 기존 화면에 계속 추가하는 함수가 아니라, 현재 배열 상태를 기준으로 화면을 다시 만드는 함수이기 때문이다.

예를 들어 배열에 A, B가 있다고 하자.

memos = [A, B];

이미 화면에 A가 그려져 있는 상태에서 화면을 비우지 않고 A, B를 다시 붙이면 화면은 이렇게 될 수 있다.

A A B

A가 중복된다.

그래서 먼저 화면을 비운다.

memoContainer.innerHTML = '';

그다음 현재 memos 배열을 기준으로 다시 그린다.

A B

삭제할 때도 마찬가지다.

화면에는 A, B, C가 있고, 배열에서 B를 삭제해 memos = [A, C]가 되었다고 하자.

화면을 비우지 않고 다시 그리면 기존 화면 위에 A, C가 추가될 수 있다.

A B C A C

그래서 renderMemos()는 항상 다음 순서로 동작한다.

1. 기존 화면을 비운다.
2. 현재 memos 배열에 있는 메모만 다시 그린다.

forEach로 배열을 하나씩 그리기

화면을 비운 뒤에는 memos 배열을 순회한다.

memos.forEach(function (memo) {
    ...
});

forEach는 배열 안의 요소를 하나씩 꺼내서 처리하는 메서드다.

예를 들어 배열이 이렇게 있다면,

memos = [
    { id: 1, title: 'A', content: '내용 A' },
    { id: 2, title: 'B', content: '내용 B' }
];

첫 번째 반복에서는 memo에 첫 번째 객체가 들어간다.

{ id: 1, title: 'A', content: '내용 A' }

두 번째 반복에서는 memo에 두 번째 객체가 들어간다.

{ id: 2, title: 'B', content: '내용 B' }

즉, memo는 배열 전체가 아니라 현재 처리 중인 메모 하나다.

각 메모마다 새 메모 카드를 만들고, 화면에 붙인다.

const memoCard = document.createElement('div');
memoCard.className = 'memo-card';

memoCard.innerHTML = `
    <h3>${memo.title}</h3>
    <p>${memo.content}</p>
    <button type="button">삭제</button>
`;

memoContainer.appendChild(memoCard);

삭제 기능 변경

이전에는 삭제 버튼을 누르면 화면의 메모 카드를 직접 제거하는 방식으로 생각했다.

memoCard.remove();

하지만 이제 메모의 원본은 화면이 아니라 memos 배열이다.

그래서 삭제도 화면에서 먼저 하는 것이 아니라, 배열에서 먼저 해야 한다.

deleteButton.addEventListener('click', function () {
    memos = memos.filter(function (item) {
        return item.id !== memo.id;
    });

    renderMemos();
});

이 코드는 현재 삭제하려는 메모와 id가 다른 메모만 남기는 코드다.

즉, 삭제할 메모를 제외한 새 배열을 만들고, 그 배열로 memos를 다시 교체한다.

예를 들어 현재 배열이 다음과 같다고 하자.

memos = [
    { id: 1, title: 'A' },
    { id: 2, title: 'B' },
    { id: 3, title: 'C' }
];

B의 삭제 버튼을 눌렀다면 삭제하려는 id는 2다.

return item.id !== 2;

각 메모를 검사하면 다음과 같다.

id 1 !== 2 → true  → 남김
id 2 !== 2 → false → 제외
id 3 !== 2 → true  → 남김

결과적으로 새 배열은 이렇게 된다.

[
    { id: 1, title: 'A' },
    { id: 3, title: 'C' }
]

그리고 이 새 배열을 다시 memos에 저장한다.

memos = memos.filter(...);

배열을 바꾼 뒤에는 화면도 다시 맞춰야 한다.

renderMemos();

renderMemos()가 실행되면 기존 화면을 비우고, 현재 memos 배열에 남아 있는 메모만 다시 그린다.
그래서 화면에서도 삭제된 메모가 사라진다.

빈 메시지도 배열 기준으로 관리하기

이전에는 화면에 있는 메모 카드 개수를 기준으로 빈 메시지를 관리할 수도 있었다.

하지만 이제 메모의 원본은 memos 배열이다.
그래서 빈 메시지도 배열 기준으로 판단하는 것이 더 자연스럽다.

function updateEmptyMessage() {
    if (memos.length === 0) {
        emptyMessage.style.display = 'block';
    } else {
        emptyMessage.style.display = 'none';
    }
}

memos.length가 0이면 메모가 없는 상태다.
그래서 “아직 작성된 메모가 없습니다.” 문구를 보여준다.

반대로 memos.length가 1 이상이면 메모가 있는 상태이므로 빈 메시지를 숨긴다.

메모 추가 흐름

메모 추가 버튼을 누르면 다음 흐름으로 동작한다.

addMemoButton.addEventListener('click', function () {
    const title = titleInput.value.trim();
    const content = contentInput.value.trim();

    if (title === '' || content === '') {
        alert('제목과 내용을 모두 입력하세요.');
        return;
    }

    const newMemo = {
        id: Date.now(),
        title: title,
        content: content
    };

    memos.push(newMemo);

    renderMemos();

    titleInput.value = '';
    contentInput.value = '';
});

정리하면 다음과 같다.

1. 제목과 내용 입력값을 가져온다.
2. 앞뒤 공백을 제거한다.
3. 빈 값이면 alert를 띄우고 중단한다.
4. 새 메모 객체를 만든다.
5. memos 배열에 새 메모를 추가한다.
6. renderMemos()로 화면을 다시 그린다.
7. 입력창을 비운다.

여기서 Date.now()는 메모마다 고유한 id를 만들기 위해 사용했다.

id: Date.now()

현재 시간을 숫자로 반환하기 때문에 간단한 고유값으로 사용할 수 있다.

나중에 서버와 DB를 사용하면 이 id는 데이터베이스에서 생성하는 값으로 바뀔 수 있다.

이번 단계에서 가장 중요한 변화는 메모의 기준이 바뀐 것이다.

이전: 화면에 추가된 HTML이 기준
현재: memos 배열이 기준

이제 화면은 데이터를 직접 관리하는 곳이 아니라, 배열을 보여주는 결과물에 가깝다.

이번 단계에서 정리한 내용은 다음과 같다.

메모를 객체로 만들기
메모 객체를 배열에 저장하기
배열을 기준으로 화면 다시 그리기
renderMemos() 함수로 화면 렌더링 분리하기
forEach()로 배열 순회하기
filter()로 특정 메모 삭제하기
삭제 후 다시 렌더링하기
빈 메시지도 배열 기준으로 관리하기
Date.now()로 임시 id 만들기

현재 단계의 한계

현재는 메모를 배열로 관리하지만, 아직 브라우저 메모리에만 존재한다.

그래서 새로고침하면 memos 배열이 다시 빈 배열로 초기화된다.

let memos = [];

즉, 화면에 추가한 메모는 새로고침 후 사라진다.

아직 부족한 점은 다음과 같다.

새로고침하면 메모가 사라진다.
localStorage 저장 기능이 없다.
수정 기능이 없다.
삭제할 때 확인 메시지가 없다.
메모 데이터가 서버나 DB에 저장되지 않는다.

다음 단계에서는 localStorage를 사용해서 메모 데이터를 브라우저에 저장할 예정이다.

현재는 메모를 배열에만 저장하고 있기 때문에 새로고침하면 사라진다.
다음에는 memos 배열을 localStorage에 저장하고, 페이지가 다시 열릴 때 저장된 메모를 불러오는 방식으로 바꿔볼 예정이다.

이번 단계에서 데이터의 기준을 배열로 옮겼기 때문에, 다음 단계에서 localStorage 저장으로 넘어가기가 훨씬 쉬워졌다.

#4 입력한 메모를 화면에 추가하기

sqaxe1 — Wed, 10 Jun 2026 20:18:25 +0900

이전 단계에서는 JavaScript 파일을 연결하고, 메모 추가 버튼을 눌렀을 때 입력값이 콘솔에 출력되는지 확인했다.

이번 단계에서는 콘솔 출력에서 끝내지 않고, 사용자가 입력한 제목과 내용을 실제 화면의 메모 목록에 추가하도록 구현했다.

아직 localStorage 저장은 하지 않았다.
따라서 새로고침하면 추가한 메모는 사라진다.

이번 단계의 목표는 브라우저 화면 안에서 메모를 동적으로 추가하는 흐름을 이해하는 것이다.

처음 작성했던 코드의 문제

처음에는 입력값을 변수에 미리 담아두고, 그 값을 이용해서 메모를 추가하려고 했다.

const titleInput = document.getElementById("memo-title");
const contentInput = document.getElementById("memo-content");
const addMemoButton = document.getElementById("add-memo-button");
const memoContainer = document.getElementById("memo-container");
const emptyMessage = document.getElementById("empty-message");

const title = titleInput.value;
const content = contentInput.value;

그런데 이렇게 작성하면 문제가 생긴다.

`titleInput.value`와 `contentInput.value`는 페이지가 처음 로드될 때 실행된다.
페이지가 처음 열렸을 때는 사용자가 아직 아무것도 입력하지 않은 상태이므로, title과 content에는 빈 문자열이 들어간다.

즉, 입력값은 페이지가 열릴 때 가져오는 것이 아니라 버튼을 클릭한 순간 가져와야 한다.

정리하면 흐름은 이렇게 되어야 한다.

페이지 열림
→ 사용자가 제목과 내용 입력
→ 메모 추가 버튼 클릭
→ 그 순간 input과 textarea의 현재 값 읽기
→ 메모 카드 생성
→ 화면에 추가

return 위치 오류

처음에는 빈 값 검사를 이벤트 함수 밖에 작성했다.

if (title === '' || content === '') {
    alert('제목과 내용을 모두 입력하세요.');
    return;
}

이렇게 작성하니 다음 오류가 발생했다.

'return' outside function definition

return은 함수 안에서만 사용할 수 있다.
따라서 빈 값 검사도 버튼 클릭 이벤트 함수 안으로 넣어야 했다.

addMemoButton.addEventListener('click', function () {
    if (title === '' || content === '') {
        alert('제목과 내용을 모두 입력하세요.');
        return;
    }
});

여기서 return은 제목이나 내용이 비어 있을 때, 그 아래 메모 추가 코드를 실행하지 않고 함수를 끝내는 역할을 한다.

메모 생성 코드 위치

메모를 만드는 코드도 처음에는 클릭 이벤트 밖에 작성하려고 했다.

하지만 메모는 페이지가 열릴 때 만들어지는 것이 아니라, 사용자가 버튼을 클릭했을 때 만들어져야 한다.

그래서 다음 작업들은 모두 클릭 이벤트 함수 안에 있어야 한다.

입력값 가져오기
빈 값 검사하기
새 div 만들기
메모 카드 내용 넣기
화면에 추가하기
입력창 비우기

이 부분을 정리하면서, 이벤트 기반 코드의 흐름을 조금 더 이해할 수 있었다.

문자열 안에 변수 넣기

메모 카드의 HTML을 만들 때도 한 가지 문제가 있었다.

처음에는 이렇게 작성했다.

memoCard.innerHTML = '' +
    '<h3>${title}</h3>' +
    '<p>${content}</p>' +
    '<button type="button">삭제</button>';

하지만 작은따옴표 안에서는 ${title}과 ${content}가 변수로 해석되지 않는다.
그냥 글자 그대로 출력된다.

변수 값을 문자열 안에 넣으려면 백틱을 사용해야 한다.

memoCard.innerHTML = `
    <h3>${title}</h3>
    <p>${content}</p>
    <button type="button">삭제</button>
`;

이 방식을 템플릿 리터럴이라고 한다.
문자열 안에 변수 값을 넣을 때 훨씬 편하게 사용할 수 있다.

최종 코드

이번 단계에서 정리한 script.js 코드는 다음과 같다.

const titleInput = document.getElementById("memo-title");
const contentInput = document.getElementById("memo-content");
const addMemoButton = document.getElementById("add-memo-button");
const memoContainer = document.getElementById("memo-container");
const emptyMessage = document.getElementById("empty-message");

addMemoButton.addEventListener('click', function () {
    const title = titleInput.value;
    const content = contentInput.value;

    console.log('메모 추가 버튼 클릭');
    console.log(title);
    console.log(content);

    if (title === '' || content === '') {
        alert('제목과 내용을 모두 입력하세요.');
        return;
    }

    const memoCard = document.createElement('div');
    memoCard.className = 'memo-card';

    memoCard.innerHTML = `
        <h3>${title}</h3>
        <p>${content}</p>
        <button type="button">삭제</button>
    `;

    memoContainer.appendChild(memoCard);

    emptyMessage.style.display = 'none';

    titleInput.value = '';
    contentInput.value = '';
});

전체 흐름은 다음과 같다.

1. HTML 요소들을 JavaScript로 가져온다.
2. 메모 추가 버튼에 click 이벤트를 등록한다.
3. 사용자가 버튼을 클릭한다.
4. 클릭한 순간 제목과 내용 값을 가져온다.
5. 제목이나 내용이 비어 있으면 alert를 띄우고 함수를 종료한다.
6. 값이 있으면 새 div 요소를 만든다.
7. 새 div에 memo-card 클래스를 붙인다.
8. innerHTML로 메모 카드 내부 구조를 만든다.
9. memoContainer 안에 새 메모 카드를 추가한다.
10. 메모가 생겼으므로 emptyMessage를 숨긴다.
11. 입력창을 빈 값으로 초기화한다.

새 요소 만들기

이번 단계에서 처음으로 JavaScript를 이용해 HTML 요소를 직접 만들었다.

const memoCard = document.createElement('div');

이 코드는 새로운 div 요소를 만든다.

처음부터 HTML 파일에 적혀 있던 요소가 아니라, JavaScript가 실행 중에 새로 만드는 요소다.
사용자가 메모를 추가할 때마다 새로운 메모 카드가 만들어진다.

클래스 붙이기

새로 만든 div에는 memo-card 클래스를 붙였다.

memoCard.className = 'memo-card';

결과적으로 다음과 같은 요소가 만들어진다.

<div class="memo-card"></div>

이렇게 클래스를 붙이면 나중에 CSS에서 .memo-card를 선택해서 메모 카드 스타일을 줄 수 있다.

메모 카드 내용 넣기

메모 카드 내부에는 innerHTML을 사용해서 제목, 내용, 삭제 버튼을 넣었다.

memoCard.innerHTML = `
    <h3>${title}</h3>
    <p>${content}</p>
    <button type="button">삭제</button>
`;

결과적으로 화면에는 다음과 같은 구조가 추가된다.

<div class="memo-card">
    <h3>사용자가 입력한 제목</h3>
    <p>사용자가 입력한 내용</p>
    <button type="button">삭제</button>
</div>

화면에 추가하기

새로 만든 메모 카드는 memoContainer 안에 추가했다.

memoContainer.appendChild(memoCard);

기존 HTML에는 비어 있는 메모 목록 영역이 있었다.

<div id="memo-container"></div>

메모를 추가하면 이 영역 안에 새 메모 카드가 들어간다.

<div id="memo-container">
    <div class="memo-card">
        <h3>제목</h3>
        <p>내용</p>
        <button type="button">삭제</button>
    </div>
</div>

빈 메시지 숨기기

처음 화면에는 메모가 없기 때문에 안내 문구가 보인다.

<p id="empty-message" class="empty-message">아직 작성된 메모가 없습니다.</p>

하지만 메모가 하나라도 추가되면 이 문구는 필요하지 않다.

emptyMessage.style.display = 'none';

이 코드는 emptyMessage 요소의 display 값을 none으로 바꿔서 화면에서 숨긴다.

입력창 비우기

메모를 추가한 뒤에는 입력창을 다시 비워주었다.

titleInput.value = '';
contentInput.value = '';

이렇게 하면 메모를 추가한 뒤 바로 다음 메모를 입력할 수 있는 상태가 된다.

#3 JavaScript 연결하고 버튼 클릭 감지

sqaxe1 — Wed, 10 Jun 2026 14:00:09 +0900

HTML과 CSS로 정적인 메모장 화면을 만든 뒤, 이제 JavaScript를 연결하기 시작했다.

이번 단계에서는 아직 메모를 실제로 추가하지는 않았다.
먼저 브라우저에서 사용자가 입력한 값을 JavaScript로 가져올 수 있는지, 그리고 버튼 클릭을 감지할 수 있는지를 확인했다.

바로 메모 추가 기능을 만들기보다, 먼저 JavaScript가 HTML 요소를 제대로 다룰 수 있는지 확인하는 것을 목표로 했다.

현재 파일 구조

현재 프로젝트 구조는 다음과 같다.

Memo Evolution/
  index.html
  style.css
  script.js
  .gitignore

이번 단계에서 script.js 파일을 새로 추가했다.

JavaScript에서 사용할 요소 정하기

JavaScript로 기능을 만들려면 먼저 어떤 HTML 요소를 다룰지 정해야 한다.

이번 메모장에서는 다음 요소들이 필요했다.

제목 입력창
내용 입력창
메모 추가 버튼
메모가 들어갈 영역
빈 목록 안내 메시지

그래서 HTML 요소에 id를 추가했다.

<input id="memo-title" type="text" placeholder="제목을 입력하세요">

<textarea id="memo-content" placeholder="내용을 입력하세요"></textarea>

<button id="add-memo-button" type="button">메모 추가</button>

<p id="empty-message" class="empty-message">아직 작성된 메모가 없습니다.</p>

<div id="memo-container"></div>

CSS에서는 주로 class를 사용해서 여러 요소에 같은 스타일을 적용했다.
반면 JavaScript에서는 특정 요소 하나를 정확히 가져와야 할 때 id를 사용하면 이해하기 쉽다.

예를 들어 제목 입력창은 다음처럼 가져올 수 있다.

const titleInput = document.getElementById('memo-title');

이 코드는 문서에서 id가 memo-title인 요소를 찾아서 titleInput이라는 변수에 담는다는 뜻이다.

JavaScript 파일 연결하기

script.js 파일을 만든 뒤, index.html에 연결했다.

<script src="script.js"></script>
</body>

script 태그는 body가 끝나기 직전에 작성했다.

HTML 요소들이 먼저 만들어진 뒤 JavaScript가 실행되도록 하기 위해서다.
만약 JavaScript가 너무 먼저 실행되면, 아직 만들어지지 않은 HTML 요소를 찾으려고 해서 문제가 생길 수 있다.

HTML 요소 가져오기

script.js에서는 먼저 JavaScript에서 사용할 요소들을 가져왔다.

const titleInput = document.getElementById('memo-title');
const contentInput = document.getElementById('memo-content');
const addMemoButton = document.getElementById('add-memo-button');
const memoContainer = document.getElementById('memo-container');
const emptyMessage = document.getElementById('empty-message');

여기서 모든 HTML 요소를 다 가져올 필요는 없다.

JavaScript에서 실제로 사용할 요소만 가져오면 된다.
이번에는 값을 읽거나, 클릭 이벤트를 붙이거나, 나중에 화면 내용을 바꿀 요소만 변수에 담았다.

버튼 클릭 감지하기

버튼을 가져온 뒤에는 클릭 이벤트를 등록했다.

addMemoButton.addEventListener('click', function () {
    console.log('메모 추가 버튼 클릭');
    console.log(titleInput.value);
    console.log(contentInput.value);
});

addEventListener()는 특정 요소에서 이벤트가 발생했을 때 실행할 함수를 등록하는 메서드다.

이번 코드는 다음처럼 해석할 수 있다.

메모 추가 버튼을 클릭하면
콘솔에 "메모 추가 버튼 클릭"을 출력하고
제목 입력창의 현재 값과
내용 입력창의 현재 값을 출력한다.

첫 번째 인자인 'click'은 브라우저가 정해둔 이벤트 이름이다.
두 번째 인자로 전달한 함수는 클릭이 발생했을 때 실행된다.

이런 함수를 콜백 함수라고 부른다.

입력값 가져오기

입력창에 적힌 값은 .value로 가져올 수 있다.

console.log(titleInput.value);
console.log(contentInput.value);

titleInput은 제목 입력창 요소이고, contentInput은 내용 입력창 요소다.

사용자가 입력한 값은 각각 다음 위치에 들어 있다.

titleInput.value
contentInput.value

즉, input이나 textarea의 현재 입력값은 .value로 읽을 수 있다.

브라우저에서 index.html을 열고 개발자 도구의 Console을 확인했다.

제목과 내용을 입력한 뒤 메모 추가 버튼을 누르면 다음 내용이 출력된다.

메모 추가 버튼 클릭
입력한 제목
입력한 내용

이를 통해 다음을 확인했다.

script.js가 HTML에 정상적으로 연결됐다.
버튼 클릭 이벤트가 정상적으로 동작한다.
JavaScript에서 input 값을 읽을 수 있다.
JavaScript에서 textarea 값을 읽을 수 있다.

아직 화면에 메모가 추가되지는 않는다.
하지만 메모 추가 기능을 만들기 위한 기본 연결은 완료했다.

#2 CSS로 메모장 화면 꾸미기

sqaxe1 — Wed, 10 Jun 2026 08:37:16 +0900

이전 단계에서는 HTML로 메모장 화면의 기본 구조를 만들었다.

이번에는 style.css를 작성해서 화면이 조금 더 메모장처럼 보이도록 스타일을 적용했다.
아직 JavaScript 기능은 없기 때문에 메모 추가 버튼을 눌러도 실제로 메모가 추가되지는 않는다.

이번 단계의 목표는 기능 구현이 아니라, HTML로 만든 요소들을 보기 좋게 배치하는 것이다.

현재 파일 구조

현재 프로젝트 구조는 다음과 같다.

Memo Evolution/
  index.html
  style.css
  .gitignore

CSS 코드

이번 단계에서 작성한 CSS는 다음과 같다.

body {
    margin: 0;
    font-family: sans-serif;
    background-color: #f4f4f4;
}

.app {
    width: 500px;
    margin: 40px auto;
    padding: 24px;
    background-color: white;
}

.memo-form {
    margin-bottom: 32px;
}

.memo-form label {
    display: block;
    margin-top: 12px;
    margin-bottom: 6px;
}

.memo-form input,
.memo-form textarea {
    display: block;
    width: 100%;
    padding: 10px;
    box-sizing: border-box;
}

.memo-form textarea {
    min-height: 120px;
    resize: vertical;
}

.memo-form button {
    display: block;
    width: 100%;
    margin-top: 16px;
}

button {
    margin-top: 12px;
    padding: 10px 16px;
    cursor: pointer;
}

.empty-message {
    color: #777;
}

화면 전체 스타일

먼저 body에 기본 스타일을 적용했다.

body {
    margin: 0;
    font-family: sans-serif;
    background-color: #f4f4f4;
}

브라우저는 기본적으로 body에 약간의 여백을 가지고 있다.
그래서 margin: 0;으로 기본 여백을 제거했다.

글꼴은 sans-serif로 지정했고, 전체 배경은 연한 회색으로 설정했다.
배경을 회색으로 두면 가운데에 있는 흰색 메모장 영역이 더 잘 구분된다.

메모장 영역 가운데 배치

전체 메모장 화면은 .app 영역이 감싸고 있다.

.app {
    width: 500px;
    margin: 40px auto;
    padding: 24px;
    background-color: white;
}

이번 단계에서는 .app에 너비를 주고, 화면 가운데에 배치했다.

width: 500px;로 메모장 박스의 크기를 정했고, margin: 40px auto;로 위아래 여백을 주면서 좌우 가운데 정렬이 되도록 했다.

padding: 24px;은 박스 안쪽 여백이다.
이 값을 주지 않으면 입력창과 제목이 박스 가장자리에 붙어 보여서 답답하다.

입력 영역 정리

HTML만 작성했을 때는 label, input, textarea, button이 화면에서 정돈되어 보이지 않았다.
그래서 메모 작성 영역 안의 요소들을 위에서 아래로 자연스럽게 배치했다.

.memo-form label {
    display: block;
    margin-top: 12px;
    margin-bottom: 6px;
}

label을 block으로 바꿔서 입력창 위에 따로 표시되도록 했다.
이렇게 하면 “제목”과 제목 입력창, “내용”과 내용 입력창의 관계가 더 명확해진다.

.memo-form input,
.memo-form textarea {
    display: block;
    width: 100%;
    padding: 10px;
    box-sizing: border-box;
}

input과 textarea는 같은 너비로 맞췄다.
width: 100%;를 사용해서 부모 영역의 가로 폭을 모두 사용하도록 했다.

여기서 box-sizing: border-box;를 같이 사용했다.
처음에는 width: 100%와 padding을 같이 쓰면 입력창이 부모 영역보다 커질 수 있다는 점이 헷갈렸다.
box-sizing: border-box;를 사용하면 padding까지 포함해서 전체 너비를 계산하므로 입력창이 밖으로 삐져나가지 않는다.

내용 입력창 크기 조정

메모 내용은 제목보다 길게 작성될 수 있으므로 textarea에는 최소 높이를 지정했다.

.memo-form textarea {
    min-height: 120px;
    resize: vertical;
}

min-height: 120px;로 내용 입력창이 너무 작아 보이지 않게 했다.

또한 resize: vertical;을 사용해서 사용자가 세로 방향으로만 크기를 조절할 수 있게 했다.
가로 방향까지 조절할 수 있으면 전체 레이아웃이 어색해질 수 있기 때문이다.

버튼 정렬

처음 화면을 확인했을 때 메모 추가 버튼이 입력창과 따로 노는 느낌이 있었다.
그래서 버튼도 입력창과 같은 폭으로 맞췄다.

.memo-form button {
    display: block;
    width: 100%;
    margin-top: 16px;
}

이렇게 하니 제목 입력창, 내용 입력창, 메모 추가 버튼이 같은 폭으로 정렬되어 훨씬 안정적으로 보였다.

버튼에는 공통 스타일도 추가했다.

button {
    margin-top: 12px;
    padding: 10px 16px;
    cursor: pointer;
}

padding을 넣어 버튼 안쪽 여백을 확보했고, cursor: pointer;로 버튼 위에 마우스를 올렸을 때 클릭 가능한 요소처럼 보이게 했다.

빈 메모 메시지

아직 JavaScript 기능이 없기 때문에 메모 목록에는 실제 데이터가 표시되지 않는다.

<p class="empty-message">아직 작성된 메모가 없습니다.</p>

이 문구는 안내 메시지에 가까우므로 일반 텍스트보다 조금 흐리게 보이도록 했다.

.empty-message {
    color: #777;
}

HTML만 작성했을 때는 요소들이 단순히 위에서 아래로 나열된 느낌이었다.
CSS를 적용하니 같은 HTML 구조라도 훨씬 화면답게 보였다.

특히 입력창과 버튼의 너비를 맞추는 것만으로도 화면이 훨씬 정리된 느낌이 들었다.
아직 기능은 없지만, 사용자가 실제로 메모를 작성할 수 있는 화면에 가까워졌다.

지금까지는 정적인 화면이었다면, 다음 단계부터는 사용자의 동작에 따라 화면이 바뀌는 구조를 만들어볼 예정이다.

#1 HTML로 메모장 화면 뼈대 만들기

sqaxe1 — Tue, 9 Jun 2026 22:21:52 +0900

현재 파일 구조

현재 프로젝트 구조는 단순하게 구성했다.

Memo Evolution/
  index.html
  style.css
  .gitignore

처음에는 IntelliJ에서 Java 프로젝트를 만들면서 src, .idea, .iml 같은 파일들이 생성됐다.
하지만 현재 단계는 HTML/CSS 학습이 목적이므로, 불필요한 Java/IDE 설정 파일은 정리했다.

HTML 코드

현재 작성한 `index.html`은 다음과 같다.

<!doctype html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Memo Evolution</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div class="app">

    <div class="memo-form">
        <h2>새 메모 작성</h2>

        <label for="memo-title">제목</label>
        <input id="memo-title" type="text" placeholder="제목을 입력하세요">

        <label for="memo-content">내용</label>
        <textarea id="memo-content" placeholder="내용을 입력하세요"></textarea>

        <button type="button">메모 추가</button>
    </div>

    <div class="memo-list">
        <h2>메모 목록</h2>
        <p class="empty-message">아직 작성된 메모가 없습니다.</p>
    </div>
</div>
</body>
</html>

코드 구조 살펴보기

먼저 문서의 기본 구조는 다음과 같다.

<!doctype html>
<html lang="ko">

<!doctype html>은 이 문서가 HTML5 문서라는 것을 브라우저에 알려준다.

lang="ko"는 이 페이지의 주 언어가 한국어라는 뜻이다.
처음에는 en으로 작성했지만, 페이지 내용이 한국어이므로 ko로 수정하는 것이 더 적절하다.

<meta charset="UTF-8">

이 코드는 문자 인코딩을 UTF-8로 설정한다.
한글이 깨지지 않도록 하기 위한 설정이다.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

이 코드는 모바일 화면에서도 페이지가 적절한 크기로 보이도록 설정한다.

<link rel="stylesheet" href="style.css">

이 코드는 HTML 파일과 CSS 파일을 연결한다.
아직 CSS는 화면을 꾸미는 역할만 하고, 기능을 만들지는 않는다.

전체 화면을 감싸는 영역

<div class="app">

div는 여러 요소를 묶기 위한 태그다.

여기서는 메모장 전체 화면을 하나의 영역으로 감싸기 위해 app 클래스를 사용했다.
나중에 CSS에서 .app을 선택해서 전체 너비, 여백, 배경 등을 설정할 수 있다.

메모 작성 영역

<div class="memo-form">
    <h2>새 메모 작성</h2>

    <label for="memo-title">제목</label>
    <input id="memo-title" type="text" placeholder="제목을 입력하세요">

    <label for="memo-content">내용</label>
    <textarea id="memo-content" placeholder="내용을 입력하세요"></textarea>

    <button type="button">메모 추가</button>
</div>

이 영역은 사용자가 새 메모를 작성하는 부분이다.

h2는 영역 제목이다. 여기서는 “새 메모 작성”이라는 제목을 표시한다.

<label for="memo-title">제목</label>
<input id="memo-title" type="text" placeholder="제목을 입력하세요">

label은 입력창이 어떤 값을 입력받는지 설명하는 태그다.

label의 for="memo-title"과 input의 id="memo-title"이 연결되어 있다.
이렇게 연결하면 사용자가 “제목”이라는 글자를 클릭해도 해당 입력창이 선택된다.

<textarea id="memo-content" placeholder="내용을 입력하세요"></textarea>

textarea는 여러 줄의 텍스트를 입력할 때 사용한다.
메모 내용은 한 줄보다 길어질 수 있으므로 input이 아니라 textarea를 사용했다.

<button type="button">메모 추가</button>

버튼은 아직 동작하지 않는다.
현재는 HTML 구조만 만드는 단계이기 때문이다.

type="button"을 지정한 이유는 나중에 버튼이 불필요하게 폼 제출처럼 동작하지 않게 하기 위해서다.

메모 목록 영역

<div class="memo-list">
    <h2>메모 목록</h2>
    <p class="empty-message">아직 작성된 메모가 없습니다.</p>
</div>

이 영역은 작성된 메모들이 표시될 공간이다.

현재는 JavaScript 기능이 없기 때문에 실제 메모가 추가되지는 않는다.
그래서 더미 데이터를 넣기보다는 “아직 작성된 메모가 없습니다.”라는 빈 목록 메시지를 보여주도록 했다.

나중에 JavaScript 단계에서는 사용자가 입력한 메모를 이 영역에 동적으로 추가하게 된다.

아직 기능은 없지만, HTML 구조를 먼저 잡아두면 이후 CSS와 JavaScript를 붙일 때 훨씬 이해하기 쉽다.

#0 메모장 프로젝트 시작

sqaxe1 — Tue, 9 Jun 2026 22:15:32 +0900

웹 개발 공부를 하면서 HTML, CSS, JavaScript, React, Java, Servlet, Spring, Spring Boot를 따로따로 배우고 있다.

그런데 각각의 기술을 따로 공부하다 보니, 이 기술들이 실제로 어떻게 연결되는지 직접 확인해보고 싶어졌다.

그래서 간단한 메모장 프로젝트를 만들어보려고 한다.

처음에는 HTML과 CSS로 정적인 메모장 화면을 만들고, JavaScript로 메모를 추가하고 삭제하는 기능을 붙일 예정이다.

이후에는 React로 화면을 다시 구성해보고, Java와 Servlet/JSP를 이용해 서버에서 요청을 처리하는 방식도 공부할 것이다.

그다음에는 JDBC로 데이터베이스를 연결하고, Spring과 Spring Boot로 같은 기능을 다시 구현해볼 계획이다.

같은 메모장 기능을 여러 방식으로 구현해보면서, 웹 개발 기술들이 어떤 역할을 하는지 이해하는 것이 목적이다.

진행 과정은 블로그에 하나씩 기록할 예정이다.

[KOSTA 가산] 웹 애플리케이션 개발 프로젝트 기반 Full-Stack 개발자 양성과정 후기

sqaxe1 — Mon, 18 May 2026 15:24:06 +0900

웹 개발을 공부하면서 가장 필요하다고 느낀 부분은 전체 흐름에 대한 이해였다.

Java, Spring, 데이터베이스, HTML, CSS, JavaScript 등을 각각 공부한 적은 있었지만, 막상 하나의 웹 애플리케이션을 만들려고 하면 각 기술이 어떤 역할을 하고 어떻게 연결되는지 명확하게 정리되지 않았다.

프론트엔드에서 요청을 보내고, 백엔드에서 비즈니스 로직을 처리하고, 데이터베이스에 데이터를 저장한 뒤 다시 화면에 결과를 보여주는 흐름을 실제 프로젝트를 통해 경험해보고 싶었다.

그 과정에서 KOSTA 가산의 웹 애플리케이션 개발 프로젝트 기반 Full-Stack 개발자 양성과정을 알게 되었고, 단순 이론 수업이 아니라 프로젝트 중심으로 진행된다는 점에서 지원하게 되었다.

교육과정에서 배운 내용

이 과정은 웹 애플리케이션 개발에 필요한 기초부터 프로젝트 구현까지 단계적으로 진행되는 과정이다.

초반에는 HTML, CSS, JavaScript와 같은 웹 기초를 학습하고, 이후 Java, 데이터베이스, Servlet/JSP, Spring Boot, React까지 이어진다. 단순히 문법을 배우는 데서 끝나는 것이 아니라, 웹 서비스가 실제로 어떤 구조로 동작하는지 이해하는 데 초점이 맞춰져 있다.

특히 Java 수업은 이후 Spring Boot를 이해하는 데 중요한 기반이 된다.
객체지향 개념, 클래스와 객체, 상속, 인터페이스, 컬렉션, 예외 처리 등 기본적인 내용부터 다시 정리하면서 Java 기반 백엔드 개발에 필요한 기초를 다질 수 있었다.

이후 Servlet/JSP 수업에서는 웹 요청과 응답의 흐름을 직접 다루게 된다.
브라우저에서 요청이 들어오고, 서버가 요청을 처리한 뒤 응답을 반환하는 구조를 코드로 확인하면서 웹 애플리케이션의 기본 동작 방식을 이해할 수 있었다.

Spring Boot 수업에서는 이전에 배운 Java, 데이터베이스, 웹 구조가 하나로 연결된다.
Controller, Service, Repository 구조를 통해 역할을 분리하고, 데이터베이스와 연동하여 실제 서비스를 구현하는 방식을 학습했다.

프로젝트 중심으로 진행되는 과정

이 과정의 핵심은 프로젝트 경험이다.

수업에서 배운 내용을 바탕으로 직접 서비스를 기획하고 구현하는 과정이 포함되어 있다. 프로젝트는 단순히 정해진 기능을 따라 만드는 방식이 아니라, 주제 선정부터 화면 구성, 데이터베이스 설계, 기능 구현, 테스트, 발표까지 직접 진행하는 방식이다.

프로젝트를 진행하면서 가장 크게 배운 점은 기능 구현보다 흐름을 이해하는 것이 중요하다는 점이다.

하나의 기능을 만들 때도 단순히 버튼을 누르면 결과가 나오는 것이 아니라, 화면에서 어떤 요청을 보내는지, 백엔드에서는 어떤 데이터를 받아 검증하는지, 데이터베이스에는 어떤 형태로 저장되는지, 다시 프론트엔드에는 어떤 응답을 내려주는지를 함께 고려해야 한다.

이 과정에서 프론트엔드와 백엔드가 분리되어 있더라도 결국 하나의 서비스 흐름 안에서 연결되어 있다는 점을 체감할 수 있었다.

또한 팀 프로젝트를 통해 협업 방식도 경험할 수 있었다.
기능을 나누어 개발할 때는 API 명세, 데이터 구조, 화면 흐름을 맞추는 과정이 중요하다. 각자 맡은 부분만 구현하는 것이 아니라, 서로의 코드와 작업 흐름을 이해해야 전체 서비스가 정상적으로 동작한다.

프로젝트를 진행하면서 오류도 많이 발생한다.
화면에서는 정상적으로 요청을 보냈지만 서버에서 값이 제대로 전달되지 않거나, 데이터베이스 설계가 부족해 기능 구현이 어려워지는 경우도 있다. 이러한 문제를 해결하는 과정에서 디버깅, 원인 분석, 팀원 간 커뮤니케이션의 중요성을 배울 수 있었다.

수업 방식과 학습 환경

수업은 기초 개념을 설명한 뒤 실습을 통해 직접 확인하는 방식으로 진행된다.
단순히 설명을 듣는 것에서 끝나는 것이 아니라, 직접 코드를 작성하고 실행해보면서 개념을 이해하는 구조다.

황연주 강사님은 수업 중간중간 수강생들이 내용을 따라오고 있는지 확인하며 진행한다.
개념 설명뿐만 아니라 실제 개발에서는 어떤 식으로 사용되는지, 프로젝트에서는 어떤 점을 주의해야 하는지도 함께 설명해주기 때문에 단순 문법 학습보다 실무 흐름을 이해하는 데 도움이 된다.

다만 교육과정에서 배우는 내용이 많기 때문에 수업 시간만으로 모든 내용을 완전히 이해하기는 어렵다.
Java, 데이터베이스, 웹 기초, Spring Boot, React, 프로젝트까지 짧은 기간 안에 다루기 때문에 복습은 필수다.

수업 후 배운 내용을 다시 정리하고, 프로젝트에서 직접 적용해보는 시간이 있어야 과정의 효과가 커진다.
결국 이 과정은 수업을 듣는 것만으로 완성되는 과정이라기보다, 수업과 복습, 프로젝트 경험이 함께 쌓일 때 가장 많은 것을 얻을 수 있는 과정이다.

과정을 통해 얻은 점

이 과정을 통해 웹 애플리케이션 개발의 전체 흐름을 정리할 수 있었다.

처음에는 각각의 기술을 따로 공부하는 느낌이 강했다.
HTML, CSS, JavaScript는 화면을 만드는 기술이고, Java와 Spring은 서버를 만드는 기술이며, 데이터베이스는 데이터를 저장하는 기술이라고만 막연하게 이해하고 있었다.

하지만 프로젝트를 진행하면서 이 기술들이 각각 따로 존재하는 것이 아니라 하나의 서비스 안에서 연결된다는 점을 이해하게 되었다.

프론트엔드는 사용자의 입력을 받고 요청을 보내는 역할을 한다.
백엔드는 요청을 받아 필요한 로직을 처리하고 데이터를 관리한다.
데이터베이스는 서비스에 필요한 데이터를 저장하고 조회하는 역할을 한다.

이 흐름을 직접 경험하면서 백엔드 개발자로서 어떤 부분을 더 깊게 공부해야 하는지도 명확해졌다.
단순히 기능을 구현하는 것을 넘어, 데이터가 어떻게 이동하는지, 요청과 응답이 어떤 구조로 처리되는지, 서비스의 상태가 어떻게 관리되는지를 고민하는 것이 중요하다는 것을 알게 되었다.

이런 사람에게 추천하는 과정

이 과정은 웹 개발을 처음 시작하는 사람에게도 도움이 되는 과정이다.
기초부터 단계적으로 진행되기 때문에 비전공자도 꾸준히 복습하며 따라간다면 웹 개발의 전체 흐름을 잡을 수 있다.

또한 이미 개발 공부를 어느 정도 해본 사람에게도 의미가 있다.
각 기술을 따로 공부했지만 실제 프로젝트 경험이 부족한 사람, 프론트엔드와 백엔드가 어떻게 연결되는지 명확히 이해하고 싶은 사람, Spring Boot 기반 백엔드 개발 흐름을 경험하고 싶은 사람에게 적합한 과정이다.

다만 수업량이 적은 과정은 아니기 때문에 스스로 공부하는 시간이 필요하다.
수업을 듣고 끝내는 것이 아니라, 배운 내용을 정리하고 직접 구현해보는 태도가 중요하다.

마무리

KOSTA 가산 웹 애플리케이션 개발 프로젝트 기반 Full-Stack 개발자 양성과정은 웹 개발의 기초부터 프로젝트 구현까지 경험할 수 있는 과정이다.

이 과정을 통해 Java와 Spring Boot 기반 백엔드 개발 흐름을 이해할 수 있었고, 프론트엔드와 백엔드, 데이터베이스가 하나의 서비스 안에서 어떻게 연결되는지도 정리할 수 있었다.

무엇보다 프로젝트를 직접 진행하면서 기능 구현뿐만 아니라 설계, 협업, 문제 해결 과정까지 경험할 수 있었다는 점이 가장 큰 의미가 있다.

웹 개발을 공부하고 있지만 전체 흐름이 잘 잡히지 않는 사람, 프로젝트 경험을 통해 실력을 키우고 싶은 사람, 백엔드 개발자로 성장하기 위한 기반을 만들고 싶은 사람에게 추천할 만한 과정이다.

조회 결과를 Optional로 받는 이유

sqaxe1 — Sat, 4 Apr 2026 10:46:44 +0900

JPA를 사용하다 보면 findById() 같은 조회 메서드의 반환 타입이 Optional<T>인 것을 자주 보게 된다.

처음 보면
“그냥 엔티티를 바로 주면 되는 것 아닌가?”
라는 생각이 들 수 있다.

하지만 조회라는 작업은 본질적으로 결과가 있을 수도 있고, 없을 수도 있는 작업이다.
바로 이 점 때문에 Optional이 필요하다.

조회는 항상 성공하는 것이 아니다

데이터베이스 조회는 개발자가 기대한 대로 항상 값을 찾는 것이 아니다.

예를 들어 다음과 같은 경우를 생각할 수 있다.

사용자가 존재하지 않는 게시글 번호를 요청한 경우
이미 삭제된 데이터를 조회한 경우
잘못된 파라미터가 전달된 경우
아직 저장되지 않은 식별자로 조회한 경우

이런 상황에서는 조회 결과가 없을 수밖에 없다.

즉, 조회 메서드는 구조적으로 다음 두 가지 가능성을 가진다.

값을 찾았다
값을 찾지 못했다

문제는 이 “값이 없을 수 있음”을 코드에서 어떻게 표현하느냐이다.

예전 방식: null로 표현

과거에는 조회 결과가 없으면 null을 반환하는 방식이 흔했다.

이 방식은 단순해 보이지만, 실제로는 많은 문제를 만든다.

1. null 체크를 깜빡하기 쉽다

조회한 객체를 바로 사용하는 순간 문제가 생긴다.

Board board = boardRepository.findSomething(...);
System.out.println(board.getTitle());

조회 결과가 없어서 board가 null이라면, 이 코드는 실행 중에 `NullPointerException`을 발생시킨다.

즉, 문제는 “값이 없다”는 사실이 아니라
그 사실을 개발자가 놓치기 쉽다는 데 있다.

2. 코드만 보고는 위험한 지점을 알기 어렵다

반환 타입이 그냥 Board라면, 이 값이 항상 존재하는 값인지, 아니면 null일 수도 있는 값인지 메서드 시그니처만 보고는 알기 어렵다.

이 말은 곧, 위험한 값인데도 안전한 값처럼 보인다는 뜻이다.

Optional은 “값이 없을 수도 있다”를 타입으로 표현한다

Optional<T>는 단순한 포장 객체가 아니다.
이 타입의 핵심 목적은 다음이다.

이 값은 있을 수도 있고, 없을 수도 있다.

즉, Optional<Board>는
“Board가 반드시 있다”가 아니라
“Board가 존재할 수도 있고, 비어 있을 수도 있다”는 의미를 갖는다.

이렇게 하면 조회 결과의 불확실성이 코드에 명확하게 드러난다.

Optional<Board> result = boardRepository.findById(bno);

이 한 줄은 단순한 문법이 아니라 다음 의미를 가진다.

조회를 시도했다
결과가 있을 수도 있다
없을 수도 있다
따라서 바로 쓰지 말고 확인하고 다뤄야 한다

왜 이것이 중요한가

Optional을 사용하는 가장 큰 이유는
조회 결과가 없을 수 있다는 사실을 개발자가 무시하지 못하게 만들기 위해서이다.

즉, 단순히 null을 감추는 것이 아니라
“이 값은 안전하게 처리해야 한다”는 신호를 타입 자체로 주는 것이다.

장점 1. API의 의도가 명확해진다

메서드 시그니처만 봐도 알 수 있다.

Optional<Board> findById(Long id)

이 메서드는 다음을 명확히 전달한다.

조회 결과가 비어 있을 수 있다
호출하는 쪽에서 반드시 그 가능성을 고려해야 한다

반환 타입이 그냥 Board였다면 이런 의도가 드러나지 않는다.

장점 2. null 실수를 줄일 수 있다

Optional은 개발자에게 결과 처리 방식을 선택하게 한다.

값이 있으면 사용한다
값이 없으면 예외를 던진다
값이 없으면 기본값을 사용한다
값이 있을 때만 특정 로직을 수행한다

즉, “없을 때 어떻게 할 것인가”를 코드 작성 시점에 고민하게 만든다.

장점 3. 예외 상황을 더 명확하게 처리할 수 있다

조회 결과가 없을 때의 대응은 상황마다 다르다.

예를 들어,

상세 조회에서는 예외를 던질 수 있다
수정 화면에서는 존재하지 않는 데이터라고 안내할 수 있다
선택적 조회에서는 그냥 빈 값으로 넘길 수 있다

Optional은 이런 흐름을 자연스럽게 표현하기 좋다.

JPA에서 Optional이 특히 잘 맞는 이유

JPA에서 자주 하는 작업 중 하나가 식별자 기반 조회이다.
그런데 식별자로 조회한다고 해서 항상 데이터가 존재하는 것은 아니다.

예를 들어 게시글 번호 100L로 조회를 요청했더라도, 실제 DB에는 그 데이터가 없을 수 있다.

이 상황에서 JPA가 반환 타입을 Optional<T>로 제공하는 것은 매우 자연스럽다.
왜냐하면 이것은 예외적인 상황이 아니라 조회라는 작업 자체가 원래 갖고 있는 속성이기 때문이다.

즉, JPA는 다음처럼 말하고 있는 셈이다.

조회 결과가 없을 수도 있으니, 호출하는 쪽에서 그 가능성을 고려해서 처리하라.

Optional이 유도하는 올바른 처리 방식

Optional을 받으면 개발자는 결과를 바로 꺼내 쓰기보다,
먼저 “없을 수도 있다”는 전제에서 처리하게 된다.

대표적으로 다음과 같은 방식이 있다.

1. 없으면 예외를 던진다

상세 조회, 수정, 삭제 같은 작업에서는 데이터가 반드시 있어야 하는 경우가 많다.

Board board = boardRepository.findById(bno)
.orElseThrow(() -> new RuntimeException("게시글이 존재하지 않습니다."));

이 방식은
“없으면 조용히 넘어가지 말고 명확하게 실패하라”
는 의도를 표현한다.

2. 없으면 기본값을 사용한다

경우에 따라서는 조회 결과가 없어도 기본 객체나 대체 값을 사용할 수 있다.

Board board = boardRepository.findById(bno)
.orElse(new Board());

다만 이 방식은 실제로 기본값이 의미가 있을 때만 사용해야 한다.

3. 값이 있을 때만 동작한다

조회 결과가 있으면 처리하고, 없으면 아무 작업도 하지 않는 방식도 가능하다.

boardRepository.findById(bno)
.ifPresent(board -> {
System.out.println(board.getTitle());
});

중요한 점: Optional은 “무조건 쓰는 것”이 아니라 “조회 결과가 비어 있을 수 있을 때 의미가 있다”

여기서 오해하면 안 되는 부분이 있다.

Optional은 모든 곳에 무조건 붙이는 도구가 아니다.
특히 JPA에서 조회 결과가 없을 수 있는 상황을 표현할 때 의미가 크다.

즉, 핵심은 다음이다.

조회 결과가 반드시 있다고 보장할 수 없다면 Optional이 적절하다
결과가 없을 수 있다는 사실을 API 수준에서 드러내고 싶을 때 Optional이 적절하다

반대로 말하면,
항상 값이 있어야 하는 내부 로직이나 필드까지 무조건 Optional로 감싸는 것은 바람직하지 않다.

Optional을 사용하는 목적은 문법이 아니라 설계에 있다

많은 초보 개발자는 Optional을 그냥
“null 대신 쓰는 문법”
정도로 이해한다.

하지만 더 중요한 것은 문법보다 설계 의도이다.

Optional은 단순한 포장지가 아니라, 다음을 코드에 드러내는 도구이다.

이 조회는 실패할 수 있다
결과가 없을 수도 있다
호출하는 쪽은 그 가능성을 반드시 처리해야 한다

즉, Optional은
조회 결과의 불확실성을 숨기지 않고 드러내는 방식이다.

이 점에서 Optional은 JPA의 조회 메서드와 잘 어울린다.

정리

JPA에서 조회 결과를 Optional로 받는 이유는 단순하다.

조회는 항상 값을 찾는 작업이 아니기 때문이다.

데이터가 없을 수도 있는데, 그 상황을 그냥 null로 넘겨버리면
개발자는 그 위험을 놓치기 쉽고, 결국 NullPointerException 같은 문제로 이어질 수 있다.

반면 Optional은 다음을 명확하게 보여준다.

조회 결과가 없을 수 있다
그 가능성을 호출하는 쪽에서 처리해야 한다
null을 무심코 사용하는 실수를 줄일 수 있다

즉, JPA에서 Optional을 쓰는 이유는
편의 때문이 아니라 조회 결과의 불확실성을 더 안전하고 명확하게 다루기 위해서이다.

Bootstrap이란?

sqaxe1 — Tue, 31 Mar 2026 10:44:38 +0900

웹 개발을 처음 시작하면 HTML은 어느 정도 금방 익숙해진다.
하지만 대부분 사람들이 막히는 지점은 바로 CSS(디자인)이다.

버튼 하나, 카드 하나, 레이아웃 하나를 만들려고 해도
생각보다 고려해야 할 요소가 너무 많기 때문이다.

이때 등장하는 것이 바로 부트스트랩(Bootstrap)이다.

부트스트랩이란 무엇인가

부트스트랩은 HTML, CSS, JavaScript로 만들어진
프론트엔드 UI 프레임워크이다.

쉽게 말하면,

웹페이지에서 자주 사용하는 디자인 요소들을
미리 만들어 놓은 “디자인 도구 모음”이다

라고 이해하면 된다.

예를 들어 이런 것들이 포함되어 있다.

버튼
입력창 (form)
카드 UI
테이블
네비게이션 바
모달창
레이아웃 시스템 (grid)

원래 웹 디자인이 왜 어려운가

부트스트랩을 이해하려면 먼저
“왜 원래 웹 디자인이 어려운지”를 알아야 한다.

예를 들어 버튼 하나를 만든다고 해보자.

단순히 HTML만 쓰면 이렇게 된다.

`<button>저장</button>`

이건 그냥 기본 버튼이다.
디자인이 전혀 되어 있지 않다.

그래서 보통은 CSS를 직접 작성해야 한다.

배경색 설정
글자색 설정
테두리 제거
여백 설정
둥근 모서리
hover 효과
클릭 효과

즉 버튼 하나에도 여러 요소를 직접 만들어야 한다.

부트스트랩은 이 문제를 어떻게 해결하는가

부트스트랩은 이 과정을 완전히 바꾼다.

개발자가 직접 CSS를 작성하는 대신
이미 만들어진 디자인을 가져다 쓰는 방식이다.

예를 들어 같은 버튼을 부트스트랩으로 만들면 이렇게 된다.

`<button class="btn btn-primary">저장</button>`

이 한 줄만으로

색이 입혀지고
여백이 정리되고
hover 효과가 적용되고
전체적으로 깔끔한 버튼이 완성된다

즉

“디자인을 직접 만드는 것”이 아니라
“이미 만들어진 디자인을 선택해서 사용하는 것”이다

“쉽게 디자인할 수 있다”는 말의 진짜 의미

많이 오해하는 부분이다.

부트스트랩이 있다고 해서
자동으로 멋진 UI가 만들어지는 것은 아니다.

정확한 의미는 다음과 같다.

1. CSS를 직접 많이 안 써도 된다

자주 사용하는 스타일이 이미 준비되어 있다.

2. 개발 속도가 매우 빨라진다

버튼, 카드, 폼 등을 몇 줄로 만들 수 있다.

3. 기본적인 디자인 퀄리티가 보장된다

완전히 깨진 화면이 나올 확률이 줄어든다.

4. 반응형 웹이 기본 지원된다

화면 크기에 따라 자동으로 레이아웃이 바뀐다.

즉 “쉽다”는 것은
디자인 자체가 쉬운 것이 아니라,
디자인 작업량이 줄어든다는 의미이다.

부트스트랩의 핵심 구조: 클래스 조합

부트스트랩은 기본적으로
클래스 이름을 조합해서 디자인을 적용하는 방식이다.

대표적인 예시는 다음과 같다.

btn → 버튼 기본 스타일
btn-primary → 파란 버튼
form-control → 입력창 스타일
card → 카드 UI
table → 표 스타일
container → 전체 레이아웃 영역

즉

HTML + 클래스 조합 = 디자인 완성

이라는 구조다.

카드 UI도 쉽게 만들 수 있다

카드 UI는 일반적으로 만들기 꽤 번거로운 요소다.
하지만 부트스트랩에서는 간단하게 만들 수 있다.

<div class="card" style="width: 18rem;">
  <div class="card-body">
    <h5 class="card-title">상품 제목</h5>
    <p class="card-text">상품 설명이다</p>
    <a href="#" class="btn btn-primary">구매하기</a>
  </div>
</div>

이 코드만으로

카드 박스 생성
내부 여백 정리
텍스트 구조 정리
버튼 스타일 적용

까지 한 번에 해결된다.

레이아웃도 쉽게 만들 수 있다 (Grid 시스템)

웹 개발에서 가장 어려운 부분 중 하나는 레이아웃이다.

예를 들어

왼쪽 메뉴 / 오른쪽 본문
카드 3개씩 한 줄
화면 크기에 따라 자동 정렬

이런 것들을 직접 구현하려면 CSS를 꽤 알아야 한다.

부트스트랩은 이를 위해 그리드 시스템(Grid System)을 제공한다.

<div class="row">
  <div class="col-4">왼쪽</div>
  <div class="col-8">오른쪽</div>
</div>

이렇게 하면 한 줄을 12칸으로 나누어
쉽게 레이아웃을 구성할 수 있다.

반응형 웹도 자동으로 지원된다

부트스트랩의 큰 장점 중 하나는
반응형 웹이 기본으로 지원된다는 점이다.

예를 들어:

<div class="col-md-6 col-lg-4">
    내용
</div>

이렇게 작성하면

모바일에서는 한 줄 전체 사용
태블릿에서는 2칸
PC에서는 3칸

이런 식으로 자동으로 레이아웃이 변경된다.

즉 복잡한 미디어 쿼리를 직접 작성하지 않아도 된다.

부트스트랩의 한계

부트스트랩은 매우 편하지만 단점도 있다.

1. 디자인이 비슷해질 수 있다

많은 사이트가 같은 스타일을 사용한다.

2. 개성 있는 디자인에는 한계가 있다

세밀한 커스터마이징은 결국 CSS가 필요하다.

3. “부트스트랩 느낌”이 날 수 있다

기본 스타일을 그대로 쓰면 티가 난다.

그래서 실무에서는

기본 구조는 부트스트랩으로 빠르게 만들고
필요한 부분만 직접 CSS로 수정하는 방식

을 많이 사용한다.

초보자에게 특히 좋은 이유

초보자는 보통 CSS에서 많이 막힌다.

정렬
여백
크기
반응형
위치 잡기

이런 부분이 어렵기 때문이다.

부트스트랩은 이 부담을 줄여준다.

즉 초보자는

HTML 구조를 만든다
부트스트랩 클래스를 붙인다
어느 정도 완성된 UI를 얻는다

이 흐름으로 개발할 수 있다.

비유로 이해하기

부트스트랩이 없는 경우는
나무와 도구를 가지고 직접 가구를 만드는 것과 같다.

부트스트랩이 있는 경우는
이미 만들어진 가구 부품을 조립하는 것과 같다.

즉 완전히 자동은 아니지만
훨씬 빠르고 쉽게 결과를 만들 수 있다.

정리

부트스트랩은 웹에서 자주 사용하는 UI 요소들을 미리 만들어 놓은 프레임워크이다.
개발자는 CSS를 처음부터 작성하지 않고, 준비된 클래스들을 조합해서 화면을 빠르게 구성할 수 있다.

그래서 부트스트랩은 디자인을 대신 해주는 도구라기보다,
디자인 작업을 크게 줄여주는 도구라고 이해하는 것이 정확하다.

한 줄 정리

부트스트랩은 웹 UI를 구성할 때 자주 쓰는 디자인과 레이아웃을 미리 만들어 둔 프레임워크라서, CSS를 직접 다 작성하지 않아도 빠르고 쉽게 화면을 구성할 수 있게 해준다.

스프링 빈(Bean) 등록 방식 정리

sqaxe1 — Tue, 31 Mar 2026 09:43:04 +0900

스프링에서 가장 중요한 개념 중 하나는 빈(Bean)이다.
빈은 단순한 자바 객체가 아니라, 스프링 컨테이너가 생성하고 관리하는 객체를 의미한다.

즉, 객체는 그냥 new로 만든 것이고,
빈은 스프링이 대신 만들어서 관리하는 객체다.

빈은 어떻게 등록하는가

스프링에서 빈을 등록하는 방법은 하나가 아니다.
대표적으로 다음 3가지 방식이 있다.

컴포넌트 스캔 (자동 등록)
@Bean을 이용한 수동 등록
XML <bean> 등록

중요한 포인트는 이것이다.

모든 빈을 하나의 방식으로 통일하는 것이 아니라,
상황에 따라 적절한 방식을 선택해서 사용한다.

컴포넌트 스캔 (자동 등록)

가장 많이 사용하는 방식이다.

@Service
public class TodoService {
}

@Repository
public class TodoRepository {
}

@Controller
public class TodoController {
}

이처럼 클래스에

@Component
@Service
@Repository
@Controller

같은 어노테이션을 붙이면,
스프링이 시작될 때 해당 클래스를 자동으로 찾아서 빈으로 등록한다.

이 과정을 컴포넌트 스캔이라고 한다.

특징

개발자가 직접 빈을 등록하지 않아도 된다
클래스에 역할이 명확하게 드러난다
프로젝트 규모가 커져도 관리가 편하다

언제 사용하는가

컴포넌트 스캔은 내가 직접 만든 클래스에 사용한다.

예:

서비스 클래스
리포지토리 클래스
컨트롤러 클래스
비즈니스 로직 클래스

이유는 간단하다.
내 코드이기 때문에 어노테이션을 직접 붙일 수 있기 때문이다.

@Bean으로 수동 등록

이번에는 자동이 아니라 직접 빈을 등록하는 방식이다.

@Configuration
public class AppConfig {

    @Bean
    public ModelMapper modelMapper() {
        return new ModelMapper();
  	}
}

이 코드는 다음 의미다.

"이 객체는 내가 직접 생성하니까, 스프링이 빈으로 등록해라"

즉 @Bean은
메서드가 반환하는 객체를 빈으로 등록하는 방식이다.

특징

객체 생성 과정을 개발자가 직접 제어한다
세부 설정을 넣을 수 있다
외부 라이브러리 객체 등록에 유리하다

언제 사용하는가

1. 외부 라이브러리 객체

ModelMapper, ObjectMapper, PasswordEncoder

이런 클래스는 내가 만든 것이 아니다.
따라서 @Service 같은 어노테이션을 붙일 수 없다.

2. 생성 과정이 복잡한 객체

@Bean
public ObjectMapper objectMapper() {
    ObjectMapper om = new ObjectMapper();
    om.findAndRegisterModules();
    return om;
}

이처럼 단순 new가 아니라
추가 설정이 필요한 경우 @Bean이 적합하다.

3. 생성 방식을 명확히 제어하고 싶은 경우

객체 생성 로직을 코드로 명확하게 드러내고 싶을 때 사용한다.

XML <bean> 등록

전통적인 방식이다.

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource" />

XML 파일에 직접 빈을 등록하는 방식이다.

특징

어노테이션이나 자바 코드가 아닌 XML로 설정한다
예전 스프링 프로젝트에서 많이 사용했다
현재는 레거시 프로젝트에서 주로 볼 수 있다

언제 사용하는가

기존 프로젝트가 XML 기반일 때
MyBatis, DataSource 같은 설정이 XML에 있을 때
레거시 코드 유지가 필요한 경우

왜 세 가지 방식을 섞어서 사용하는가

핵심은 이것이다.

각 방식이 잘 맞는 대상이 다르기 때문이다.

자동 스캔이 적합한 경우

@Service
public class TodoService

내가 만든 클래스
역할이 명확함
특별한 생성 로직 없음

@Bean이 적합한 경우

@Bean
public ModelMapper modelMapper()

외부 라이브러리 객체
생성 과정에 설정이 필요함

XML이 적합한 경우

<bean id="dataSource" ... />

기존 프로젝트 설정
DB, MyBatis 같은 인프라 구성

모든 빈을 @Bean으로 등록하면 안 되나?

가능하다. 하지만 비효율적이다.

예:

@Bean
public TodoService todoService() {
	return new TodoService();
}

이런 식으로 모든 클래스를 등록할 수도 있다.

하지만 문제는 다음과 같다.

참고로 @Bean은 해당 메소드의 실행 결과로 반환된 객체를 스프링의 빈(Bean)으로 등록시키는 역할을 한다.

문제점

1. 코드가 너무 많아진다

클래스가 많아질수록 설정 코드가 폭발적으로 증가한다.

2. 가독성이 떨어진다

클래스만 봐서는 역할이 드러나지 않는다.

3. 대부분의 방식과 다르다

실무에서는 대부분 자동 스캔을 기본으로 사용한다.

정리

실무에서는 보통 다음 기준으로 나눈다.

컴포넌트 스캔

Controller
Service
Repository

→ 비즈니스 로직 클래스

@Bean

ModelMapper
ObjectMapper
PasswordEncoder

→ 외부 라이브러리 + 설정 객체

XML

DataSource
SqlSessionFactory

→ 레거시 / 인프라 설정

최종 결론

스프링에서는 모든 빈을 하나의 방식으로 등록하지 않는다.

자동 등록이 가능한 것은 컴포넌트 스캔을 사용한다
직접 설정이 필요한 것은 @Bean을 사용한다
기존 설정은 XML을 유지한다

즉 중요한 것은 방식이 아니라,
객체의 성격에 맞는 등록 방법을 선택하는 것이다.

정리

스프링 빈 등록은 하나로 통일하는 것이 아니라,

자동 스캔, @Bean, XML을 상황에 맞게 나누어 사용하는 구조이다.

[스프링과 스프링 MVC] 4. LocalDate 바인딩이 왜 자주 깨지는가

sqaxe1 — Tue, 31 Mar 2026 00:09:13 +0900

Formatter로 “문자열 → 타입” 변환 규칙을 등록한다

스프링 MVC의 파라미터 바인딩은 편하다.

요청 파라미터가 문자열로 들어와도
int/boolean 같은 기본 타입은 자동 변환해주고
DTO 필드에도 알아서 채워준다

그런데 실전에서 가장 자주 터지는 타입이 있다.

날짜(LocalDate, LocalDateTime)

1) 왜 날짜에서 에러가 자주 나나

HTTP 요청 파라미터는 기본적으로 전부 문자열이다.

예를 들어 사용자가 폼에서 날짜를 입력하면 이런 문자열이 온다.

dueDate=2020-10-10

문제는 스프링이 이 문자열을

LocalDate 객체로 바꾸는 규칙을 “항상 자동으로 알 수는 없다”는 점이다.

즉 바인딩 과정에서

“String을 LocalDate로 변환할 수 없다”
같은 타입 변환 에러가 발생할 수 있다.

// ================================
// [문제 상황] 스프링 MVC가 "문자열"을 LocalDate로 자동 변환 못 해서 에러가 나는 케이스
// - 요청: dueDate=2020-10-10
// - DTO: LocalDate dueDate
// ================================

@Data
public class TodoDTO {
    private String title;
    private LocalDate dueDate; // ✅ 여기서 바인딩 문제가 자주 난다
}

2) 해결 방법 1: @DateTimeFormat

DTO 필드에 날짜 형식을 명시하면 된다.

@DateTimeFormat(pattern = "yyyy-MM-dd")
private LocalDate dueDate;

이렇게 하면 스프링이

yyyy-MM-dd 패턴으로 문자열을 파싱해서 LocalDate로 변환한다.

즉 특정 필드/파라미터에 대해 “형식”을 선언하는 방식이다.

3) 해결 방법 2: Formatter 등록 (전역 규칙을 만드는 방식)

`@DateTimeFormat`은 간단하지만
프로젝트 전체에서 동일한 규칙을 강제하거나, 커스텀 규칙이 더 필요하면 Formatter를 쓴다.

Formatter는 한 문장으로 말하면 이거다.

문자열 ↔ 특정 타입 변환 규칙을 코드로 등록하는 장치

Formatter는 두 메서드를 가진다.

parse(String text, Locale locale) : 문자열 → 타입
print(T object, Locale locale) : 타입 → 문자열

LocalDateFormatter는 이런 식이다.

2020-10-10 → LocalDate.of(2020,10,10)

4) Formatter는 어디에 등록하나

스프링 MVC에서는 보통 `WebMvcConfigurer`에서 등록한다.

@Override
public void addFormatters(FormatterRegistry registry) {
    registry.addFormatter(new LocalDateFormatter());
}

이렇게 등록하면

프로젝트 전체에서 LocalDate 바인딩에 이 규칙이 적용될 수 있다.

즉 “전역 타입 변환 규칙”을 등록하는 방식이다.

5) 언제 무엇을 쓰는가

빠르게 해결: @DateTimeFormat
프로젝트 전체 규칙/커스텀 변환 필요: Formatter 등록

둘 다 결국 같은 문제를 해결한다.

“문자열로 들어온 요청 데이터를, 원하는 타입으로 변환하는 규칙”을 제공한다

핵심 정리

HTTP 요청 파라미터는 기본적으로 문자열이다
LocalDate 같은 타입은 문자열 → 타입 변환 규칙이 필요해서 바인딩 에러가 자주 난다
@DateTimeFormat은 필드 단위로 형식을 지정하는 쉬운 해결책이다
Formatter는 문자열 ↔ 타입 변환 규칙을 전역으로 등록하는 방식이다
Formatter는 WebMvcConfigurer의 addFormatters로 등록한다

[스프링과 스프링 MVC] 3. 파라미터 바인딩과 Model

sqaxe1 — Mon, 30 Mar 2026 17:36:27 +0900

스프링 MVC는 request를 직접 만지지 않아도 된다

서블릿 MVC에서는 요청 데이터를 읽는 방식이 명확했다.

request.getParameter("title")
request.setAttribute("todos", list)

즉 request를 직접 만지는 코드가 컨트롤러에 반복된다.

스프링 MVC는 이 부분을 크게 추상화했다.

요청 파라미터를 자동으로 모아서 객체(DTO)에 넣어준다
View로 넘길 데이터도 Model로 넣으면 알아서 request에 옮겨준다

그래서 컨트롤러 코드가 짧아지고 의도가 더 분명해진다.

1) 파라미터 바인딩: DTO를 파라미터로 받으면 자동으로 채워준다

스프링 MVC는 컨트롤러 메서드 파라미터를 보고
요청 파라미터를 자동으로 수집해서 넣어준다.

예를 들어 요청이 이렇게 들어온다고 하자.

title=study
finished=true

컨트롤러에서 DTO를 파라미터로 받으면

public String register(TodoDTO dto)

스프링은 내부적으로 대략 이런 작업을 한다.

TodoDTO 객체를 생성한다
요청 파라미터 이름을 보고 필드에 매칭한다
setter를 호출해서 값을 채운다
필요하면 타입 변환도 시도한다(String → int/boolean 등)

즉 “DTO 하나로 요청 데이터 수집이 끝나는 구조”이다.

// ================================
// [파라미터 바인딩] 요청 파라미터를 DTO로 자동 수집
// - 요청 파라미터 이름과 DTO 필드명이 매칭되면 자동으로 setXXX를 호출해 채운다
// ================================

@Data
public class TodoDTO {
    private String title;
    private boolean finished;
}

2) 바인딩이 되려면 조건이 있다

파라미터 바인딩이 자연스럽게 되려면 조건이 있다.

파라미터 이름과 DTO 필드명이 맞아야 한다
DTO에 기본 생성자가 있어야 한다(스프링이 객체를 만들어야 함)
setter가 있어야 한다(setXXX로 채우기 때문)

그래서 DTO는 보통 JavaBeans 형태로 만든다.

private 필드
getter/setter
기본 생성자

Lombok을 쓰면 @Data나 @Getter/@Setter로 쉽게 만든다.

// ================================
// [컨트롤러] DTO 파라미터로 받기 + Model로 View에 전달
// ================================

@Controller
@RequestMapping("/todo")
@RequiredArgsConstructor
public class TodoController {

    private final TodoService todoService;

    @PostMapping("/register")
    public String register(TodoDTO dto) { // ✅ 자동 바인딩
        todoService.register(dto);
        return "redirect:/todo/list";
    }

    @GetMapping("/list")
    public String list(Model model) {     // ✅ Model로 전달
        model.addAttribute("todos", todoService.list());
        return "todo/list";
    }
}

3) @RequestParam: 파라미터 누락/기본값 처리가 필요할 때

스프링 MVC의 바인딩은 편하지만,
파라미터가 누락되면 문제가 생길 수 있다.

예를 들어 page는 없으면 1로 처리하고 싶을 수 있다.

이럴 때 @RequestParam을 쓴다.

defaultValue: 없을 때 기본값
required: 필수 여부

즉 @RequestParam은 “파라미터 수집의 정책”을 명시하는 도구이다.

// ================================
// [RequestParam] 파라미터가 없을 때 기본값 지정/필수 여부 제어
// ================================

@GetMapping("/search")
public String search(
        @RequestParam(defaultValue = "1") int page,
        @RequestParam(required = false) String keyword
) {
    // page는 없으면 1
    // keyword는 없으면 null
    return "todo/search";
}

4) Model: View로 넘길 데이터를 담는 상자

서블릿 MVC에서는 View로 데이터를 넘길 때 request에 담았다.

request.setAttribute("todos", list)

스프링 MVC에서는 Model을 쓴다.

model.addAttribute("todos", list)

중요한 포인트는 이것이다.

EL이 Model 객체 자체를 읽는 게 아니다
Model에 담긴 attribute가 request 영역으로 옮겨지고, JSP는 그 값을 읽는다

즉 스프링 MVC는 내부적으로

Model에 담긴 값을 request attribute로 옮겨준다

그래서 JSP에서는

${todos}

로 바로 읽힌다.

5) 왜 컨트롤러에서 request/response를 덜 만지는가

스프링 MVC는 DispatcherServlet이 요청/응답의 많은 처리를 표준화하고,
컨트롤러는 “비즈니스 의도”만 표현하게 만드는 게 목표이다.

그래서 컨트롤러는 보통 이런 코드가 된다.

DTO로 입력 받기
Service 호출
Model에 넣기
view 이름 또는 redirect 반환하기

이 구조가 유지보수성과 생산성을 크게 높인다.

정리

스프링 MVC는 요청 파라미터를 DTO로 자동 바인딩해준다
바인딩은 이름 매칭 + 기본 생성자 + setter가 필요하다
@RequestParam으로 기본값/필수 여부를 명시할 수 있다
Model에 담으면 스프링이 request attribute로 옮겨서 JSP EL이 읽을 수 있게 한다
그래서 컨트롤러가 request/response를 직접 만지는 코드가 줄어든다

[스프링과 스프링 MVC] 2. 스프링 MVC는 “프론트 컨트롤러”로 움직인다

sqaxe1 — Mon, 30 Mar 2026 16:12:15 +0900

서블릿 MVC에서는 보통 이런 흐름이었다.

URL마다 서블릿이 매핑된다
서블릿이 doGet/doPost에서 요청을 처리한다
필요하면 JSP로 forward/redirect 한다

스프링 MVC는 이 흐름을 더 강하게 “통제”한다.

스프링 MVC에서는 모든 요청이 반드시 DispatcherServlet을 거친다

DispatcherServlet은 스프링 MVC의 프론트 컨트롤러(Front-Controller)이다.

즉 “모든 요청의 입구”이다.

// ================================
// [Controller 예시] @GetMapping / @PostMapping
// - 서블릿의 doGet/doPost 대신 "메서드 단위"로 매핑한다
// ================================

@Controller
@RequestMapping("/todo")
@RequiredArgsConstructor
public class TodoController {

    private final TodoService todoService;

    // GET /todo/list
    @GetMapping("/list")
    public String list(Model model) {
        model.addAttribute("todos", todoService.list());
        return "todo/list"; // 뷰 이름(예: /WEB-INF/views/todo/list.jsp)
    }

    // GET /todo/register
    @GetMapping("/register")
    public String registerForm() {
        return "todo/register";
    }

    // POST /todo/register
    @PostMapping("/register")
    public String register(TodoDTO dto) { // 파라미터 바인딩(자동 수집)
        todoService.register(dto);
        return "redirect:/todo/list"; // PRG
    }
}

1) DispatcherServlet은 무엇인가

DispatcherServlet은 한 문장으로 말하면 이거다.

요청을 받아서, 어떤 컨트롤러가 처리할지 결정하고, 실행하고, 응답까지 연결하는 중앙 관제탑

이 구조 덕분에 스프링 MVC는 공통 처리(인터셉터, 예외 처리, 바인딩 등)를
중앙에서 일관되게 적용할 수 있다.

2) 서블릿의 “서블릿 단위” 매핑이, 스프링에서는 “메서드 단위” 매핑으로 바뀐다

서블릿 방식에서는 보통 URL 하나당 서블릿이 하나 매핑되는 느낌이다.

스프링 MVC에서는 컨트롤러 클래스 하나가 여러 URL을 처리하고,
그 안에서 메서드 단위로 매핑이 된다.

@RequestMapping("/todo") : 클래스 레벨 공통 경로
@GetMapping("/list") : GET /todo/list
@PostMapping("/register") : POST /todo/register

즉 doGet/doPost 같은 “서블릿 라이프사이클 메서드” 대신
“요청 처리 메서드”를 여러 개 두는 구조로 바뀐다.

3) 스프링 MVC 요청 처리 흐름(핵심)

스프링 MVC의 큰 흐름은 이렇게 이해하면 된다.

브라우저 요청이 들어오면 DispatcherServlet이 받는다
HandlerMapping이 “어떤 컨트롤러 메서드”가 처리할지 찾는다
해당 메서드를 실행한다
반환값을 해석해서 View를 렌더링하거나, 데이터로 바로 응답한다
response를 전송한다

즉 DispatcherServlet이 입구/출구를 통제한다.

4) @Controller는 무엇인가

@Controller는 스프링이 인식하는 “웹 컨트롤러 빈” 표시이다.

스프링은 component-scan을 통해 @Controller가 붙은 클래스를 빈으로 등록하고,
DispatcherServlet이 요청을 매핑할 때 이 컨트롤러들을 대상으로 찾는다.

즉 @Controller는

빈 등록 대상이면서
웹 요청 처리 대상으로도 등록되는

표시라고 보면 된다.

5) PRG 흐름도 스프링에서는 더 자연스럽게 표현된다

서블릿에서는 response.sendRedirect(...)를 직접 호출했다.

스프링 MVC에서는 반환 문자열로 redirect를 표현할 수 있다.

return "redirect:/todo/list";

즉 “처리 후 redirect”가 코드에서 더 읽기 쉬운 형태로 드러난다.

핵심 정리

스프링 MVC는 모든 요청이 DispatcherServlet을 거치는 프론트 컨트롤러 구조이다
URL 매핑이 서블릿 단위가 아니라 컨트롤러 메서드 단위로 세분화된다
@Controller는 스프링 MVC 요청 처리 대상이 되는 빈 표시이다
redirect는 "redirect:/..." 형태로 자연스럽게 표현된다

[스프링과 스프링 MVC] 1. DI와 빈(Bean)

sqaxe1 — Mon, 30 Mar 2026 15:50:35 +0900

이전까지는 이런 구조로 왔다.

Controller(서블릿)가 요청을 받고
Service/DAO를 호출하고
JSP로 forward/redirect로 흐름을 제어한다

문제는 규모가 커질수록 코드가 이렇게 변한다는 점이다.

컨트롤러가 서비스 객체를 직접 new로 만들기 시작한다
서비스가 DAO를 직접 new로 만들기 시작한다
구현체가 바뀌면 여기저기 코드가 같이 바뀐다
테스트가 어려워진다(가짜 객체로 바꾸기 힘들다)

이 문제를 해결하려면 “객체를 누가 만들고, 누가 누구를 참조하게 만들지”를 분리해야 한다.
이때 등장하는 핵심 개념이 DI(의존성 주입)이다.

// ================================
// [DI가 없을 때] Controller가 Service를 직접 new 해서 결합이 강해진다
// - 구현체 교체/테스트가 어려워진다
// ================================


public class TodoController {

    private final TodoService service = new TodoService(); // ❌ 직접 생성(강한 결합)

    public void handle() {
        service.register("study");
    }
}

DI는 “의존 객체를 외부에서 주입받는 방식”이다

DI(Dependency Injection)는 말 그대로 의존성을 주입하는 것이다.

여기서 의존성은 이런 의미이다.

A가 일을 하려면 B가 필요하다
즉 A는 B에 의존한다

전통적인 방식(강한 결합)은 A가 B를 직접 만든다.

A 내부에서 new B()

DI 방식(느슨한 결합)은 A가 “B가 필요하다”만 말하고,
B를 누가 만들지는 외부가 결정한다.

A 생성자에 B를 넣어준다

핵심은 이거다.

객체 생성과 객체 사용을 분리한다

빈(Bean)은 “스프링이 관리하는 객체”이다

스프링은 DI를 하기 위해 “객체를 대신 생성하고 관리”한다.
스프링이 관리하는 객체를 빈(Bean)이라고 부른다.

즉 빈은 단순히 “객체”가 아니라

스프링 컨테이너가 생성하고
생명주기를 관리하고
필요한 곳에 주입하는

관리 대상 객체이다.

ApplicationContext는 “빈을 담아두는 컨테이너”이다

스프링에는 빈들을 담아두는 큰 상자가 있다.

그게 ApplicationContext이다.

ApplicationContext는 이런 역할을 한다.

어떤 빈이 등록되어 있는지 알고 있다
빈을 생성한다
의존 관계를 연결해서 주입한다
같은 빈을 재사용(싱글톤 기본)해서 관리한다

즉 “내가 new 하지 않아도 되는 이유”가 여기에 있다.

스프링을 쓰면 개발자는 “객체 생성”이 아니라 “등록과 주입”을 한다

스프링을 쓰기 시작하면 개발자의 작업 방식이 바뀐다.

예전: 필요한 객체를 직접 new 해서 연결한다
스프링: 빈으로 등록하고, 필요한 곳에서는 주입받는다

그래서 코드의 초점이

“어디서 new 했지?”가 아니라
“이 객체는 빈으로 등록됐나?”로 바뀐다

생성자 주입이 기본이 되는 이유

DI는 여러 방식이 있지만, 실무에서 가장 추천되는 건 생성자 주입이다.

생성자 주입이 좋은 이유는 단순하다.

의존성이 없으면 객체 생성이 애초에 불가능해져서 문제를 빨리 발견한다
필드를 final로 둘 수 있어서 안정적이다
테스트에서 가짜 객체를 쉽게 주입할 수 있다

그래서 스프링 3 이후로는 생성자 주입이 사실상 기본 패턴이 되었다.

// ================================
// [스프링 빈 등록 + 생성자 주입 예시]
// - @Service, @Controller 같은 어노테이션으로 빈 등록
// - @RequiredArgsConstructor로 생성자 주입을 간단히
// ================================

@Service
public class TodoService {
    public void register(String title) { /* ... */ }
}

@Controller
@RequiredArgsConstructor
public class TodoController {

    private final TodoService todoService; // 스프링이 생성자에 주입

    @PostMapping("/todo/register")
    public String register(String title) {
        todoService.register(title);
        return "redirect:/todo/list";
    }
}

component-scan: “어노테이션 붙은 클래스를 찾아서 빈으로 등록한다”

스프링이 빈을 등록하는 방법은 크게 두 가지가 있다.

XML에 <bean>으로 등록
컴포넌트 스캔(component-scan)으로 자동 등록

컴포넌트 스캔은 이런 동작이다.

지정한 패키지를 훑어보면서
@Component 계열 어노테이션이 붙은 클래스를 찾아
빈으로 등록한다

여기서 대표적인 어노테이션이 다음이다.

@Controller
@Service
@Repository
@Component

즉 “어노테이션을 붙이면 스프링이 빈으로 등록한다”는 말의 실체가 component-scan이다.

핵심 정리

DI는 객체 생성과 사용을 분리해서 결합도를 낮추는 방식이다
스프링은 빈(Bean)이라는 관리 객체를 만들고 DI를 수행한다
ApplicationContext가 빈을 생성/관리/주입하는 컨테이너이다
생성자 주입이 기본 패턴이고, @Controller/@Service 등은 component-scan으로 빈 등록된다

[상태 유지와 공통 처리] 5. MyBatis 설정 흐름

sqaxe1 — Mon, 30 Mar 2026 13:55:52 +0900

DataSource → SqlSessionFactory → Mapper Scan

MyBatis를 “코드 사용” 관점에서 보면 Mapper 인터페이스만 만들면 되는 것처럼 보인다.
하지만 그게 동작하려면 컨테이너(스프링) 쪽에서 연결을 해줘야 한다.

핵심 연결은 딱 3단계이다.

DataSource 준비 (HikariCP)
SqlSessionFactory 준비
Mapper Scan 등록

// ================================
// [JDBC DAO에서 반복되는 코드] 자원 얻기/닫기 + ResultSet 매핑
// - MyBatis가 주로 줄여주는 부분이 여기다
// ================================

public class TodoJdbcDao {

    private final DataSource ds;

    public TodoJdbcDao(DataSource ds) {
        this.ds = ds;
    }

    public List<TodoVO> findAll() throws SQLException {

        String sql = "select tno, title, finished from tbl_todo order by tno desc";

        try (Connection conn = ds.getConnection();
             PreparedStatement ps = conn.prepareStatement(sql);
             ResultSet rs = ps.executeQuery()) {

            List<TodoVO> list = new ArrayList<>();

            while (rs.next()) {
                TodoVO vo = new TodoVO(
                        rs.getLong("tno"),
                        rs.getString("title"),
                        rs.getBoolean("finished")
                );
                list.add(vo);
            }
            return list;
        }
    }
}

1) DataSource: DB 연결을 제공하는 창구

MyBatis도 결국 DB와 연결해야 SQL을 실행한다.
그래서 MyBatis는 DataSource를 필요로 한다.

여기서는 이미 앞에서 만든 HikariCP(DataSource)를 그대로 쓴다고 보면 된다.

즉 “풀에서 Connection을 빌려오는 창구”가 DataSource이고,
MyBatis는 그 창구를 통해 Connection을 얻는다.

2) SqlSessionFactory: MyBatis 실행의 핵심 공장

MyBatis에서 실제 SQL 실행 단위는 SqlSession이다.
그리고 그 SqlSession을 만들어내는 공장이 SqlSessionFactory이다.

즉 구조는 이렇게 이해하면 된다.

SqlSessionFactory → SqlSession 생성
SqlSession → SQL 실행, 트랜잭션, 매핑 수행

실무에서 개발자가 SqlSession을 직접 다루기보다는
스프링 연동을 통해 Mapper를 주입받아 쓰는 경우가 많지만,
내부적으로는 SqlSession이 움직인다고 보면 된다.

3) Mapper Scan: 인터페이스를 찾아 “프록시 구현체”를 만든다

MyBatis의 가장 큰 특징 중 하나가 이거다.

Mapper 인터페이스만 만들고
구현 클래스는 만들지 않는다

대신 MyBatis가 프록시 구현체를 만들어서 스프링 빈으로 등록한다.

이걸 가능하게 하는 게 Mapper Scan이다.

즉 scan의 의미는 이런 것이다.

지정한 패키지를 훑어서 Mapper 인터페이스를 찾고,
그 인터페이스의 구현체(프록시)를 만들어 빈으로 등록한다

그래서 TodoMapper 같은 인터페이스를 서비스에서 바로 주입받아 쓸 수 있다.

// ================================
// [MyBatis Mapper 인터페이스 예시] (어노테이션 기반)
// - 구현 클래스를 내가 만들지 않는다
// - MyBatis가 프록시 구현체를 만들어준다
// ================================

@Mapper
public interface TodoMapper {

    @Select("select tno, title, finished from tbl_todo order by tno desc")
    List<TodoVO> findAll();

    @Insert("insert into tbl_todo(title, finished) values(#{title}, #{finished})")
    int insert(TodoVO vo);
}

XML 매퍼 파일을 쓰면 mapperLocations가 추가된다

MyBatis에서 SQL을 XML로 분리해서 관리한다면
SqlSessionFactory에 매퍼 파일 위치를 알려줘야 한다.

보통 이런 형태로 등록한다.

classpath*:mappers/**/*.xml

이 설정이 있으면 resources 아래의 mappers 폴더 하위 XML 파일들을 찾아서 읽는다.

전체 흐름

HikariCP(DataSource)가 Connection을 제공한다
SqlSessionFactory가 SqlSession을 만든다
SqlSession이 SQL 실행과 매핑을 수행한다
Mapper Scan이 Mapper 인터페이스를 찾아 프록시 빈을 만든다
서비스는 DAO 대신 Mapper를 주입받아 사용한다

정리

MyBatis 설정은 DataSource → SqlSessionFactory → Mapper Scan 순서로 연결된다
SqlSessionFactory는 SqlSession을 만드는 공장이다
Mapper Scan이 Mapper 인터페이스 구현체(프록시)를 자동으로 만든다
XML 매퍼를 쓰면 mapperLocations 설정이 필요하다

[상태 유지와 공통 처리] 4. MyBatis는 무엇을 해결하는가

sqaxe1 — Mon, 30 Mar 2026 13:12:06 +0900

JDBC에서 반복되는 “매핑/자원관리”를 줄인다

JDBC로 DAO를 작성할 수는 있다.
그리고 실제로 기본기는 JDBC로 충분히 잡는 게 맞다.

하지만 JDBC DAO를 계속 작성해보면
특정 패턴의 코드가 계속 반복되는 걸 느끼게 된다.

Connection 얻기
PreparedStatement 만들기
파라미터 setXXX 바인딩
executeQuery/executeUpdate 호출
ResultSet에서 꺼내서 VO로 매핑
자원 close 처리

이 중에서 특히 반복이 큰 부분이 두 가지다.

ResultSet → 객체 매핑
자원 정리/예외 처리 패턴

MyBatis는 이 반복을 줄이기 위해 등장한 SQL 매핑 프레임워크이다.

MyBatis는 “SQL 매핑 프레임워크”이다

MyBatis를 한 문장으로 말하면 이렇다.

SQL 실행 결과를 자바 객체로 매핑해주는 도구

즉 “SQL을 없애는 프레임워크”가 아니다.
오히려 SQL을 그대로 쓰면서, 자바 코드의 반복을 줄여준다.

그래서 MyBatis는 이런 상황에서 잘 맞는다.

SQL을 직접 통제하고 싶다
복잡한 쿼리를 그대로 쓰고 싶다
JDBC 반복 코드를 줄이고 싶다

MyBatis가 줄여주는 것 1: ResultSet 매핑

JDBC에서는 직접 이런 작업을 한다.

rs.getLong("tno")
rs.getString("title")
new TodoVO(...)

MyBatis는 결과 컬럼과 객체 필드를 매핑해서
이 과정을 상당 부분 자동화한다.

즉 “결과를 객체로 만드는 반복”이 줄어든다.

MyBatis가 줄여주는 것 2: 자원 정리/예외 처리

JDBC에서는 Connection/Statement/ResultSet을 닫아야 한다.
try-with-resources로 깔끔하게 만들 수는 있지만
그래도 반복되는 틀은 남는다.

MyBatis(+스프링 연동)를 쓰면

연결 획득/반납
Statement/ResultSet close

같은 자원 관리가 더 자동화된다.

// ================================
// [JDBC DAO에서 반복되는 코드] 자원 얻기/닫기 + ResultSet 매핑
// - MyBatis가 주로 줄여주는 부분이 여기다
// ================================

public class TodoJdbcDao {

    private final DataSource ds;

    public TodoJdbcDao(DataSource ds) {
        this.ds = ds;
    }

    public List<TodoVO> findAll() throws SQLException {

        String sql = "select tno, title, finished from tbl_todo order by tno desc";

        try (Connection conn = ds.getConnection();
             PreparedStatement ps = conn.prepareStatement(sql);
             ResultSet rs = ps.executeQuery()) {

            List<TodoVO> list = new ArrayList<>();

            while (rs.next()) {
                TodoVO vo = new TodoVO(
                        rs.getLong("tno"),
                        rs.getString("title"),
                        rs.getBoolean("finished")
                );
                list.add(vo);
            }
            return list;
        }
    }
}

Mapper 인터페이스라는 방식이 핵심이다

MyBatis를 쓰면 DAO 구현 클래스를 직접 만들지 않고
Mapper 인터페이스만 정의하는 방식이 가능해진다.

예를 들어 아래처럼 인터페이스만 정의한다.

findAll()
insert(...)

그리고 MyBatis가 이 인터페이스의 구현체(프록시 객체)를 만들어준다.

즉 개발자는

“메서드 시그니처만 정의”하고
“SQL 매핑만 연결”해두면
실제 실행은 MyBatis가 대신한다

이게 생산성을 크게 올려준다.

// ================================
// [MyBatis Mapper 인터페이스 예시] (어노테이션 기반)
// - 구현 클래스를 내가 만들지 않는다
// - MyBatis가 프록시 구현체를 만들어준다
// ================================

@Mapper
public interface TodoMapper {

    @Select("select tno, title, finished from tbl_todo order by tno desc")
    List<TodoVO> findAll();

    @Insert("insert into tbl_todo(title, finished) values(#{title}, #{finished})")
    int insert(TodoVO vo);
}

SQL은 어디에 두는가: 어노테이션 vs XML

MyBatis는 SQL을 두는 방식이 두 가지가 있다.

1) 어노테이션(@Select, @Insert 등)

간단한 SQL은 빠르게 작성 가능
하지만 SQL이 길어지면 가독성이 떨어진다
변경 시 전체 빌드/컴파일 영향이 있을 수 있다

2) XML 매퍼 파일

SQL을 파일로 분리해서 관리하기 좋다
SQL이 길거나 복잡할수록 유리하다
실무에서는 XML 방식을 선호하는 경우가 많다

즉 SQL이 커질수록 XML 분리가 더 편해진다.

핵심 정리

MyBatis는 SQL을 없애는 게 아니라, SQL을 “매핑”해주는 프레임워크이다
JDBC에서 반복되는 ResultSet 매핑과 자원 관리 코드를 줄여준다
Mapper 인터페이스만 정의하고 구현체는 MyBatis가 프록시로 만든다
SQL은 어노테이션으로 둘 수도 있고, XML로 분리할 수도 있다

[상태 유지와 공통 처리] 3. Connection Pool / DataSource / HikariCP

sqaxe1 — Mon, 30 Mar 2026 12:28:20 +0900

연결을 미리 만들어두고 빌려 쓴다

JDBC는 DB와 연결해야 SQL을 실행할 수 있다.
그래서 Connection이 필요하다.

그런데 문제가 있다.

Connection 생성은 생각보다 비용이 큰 작업이다

요청이 들어올 때마다 매번 새 연결을 만들면

느려지고
DB 연결 수가 급격히 늘고
결국 서버가 버티기 힘들어진다

그래서 실무에서는 거의 무조건 Connection Pool을 쓴다.

Connection을 새로 만드는 게 왜 비싼가

Connection을 만든다는 건 단순히 객체 하나 만드는 게 아니다.

DB와 네트워크(TCP) 연결을 맺는다
인증/권한 확인 같은 협상이 들어간다
네트워크 왕복이 발생한다

즉, 요청마다 이 과정을 반복하면 성능이 크게 떨어진다.

Connection Pool의 아이디어는 단순하다

해결책은 미리 만들어두는 것이다.

서버가 시작할 때 Connection을 여러 개 만들어둔다
요청이 오면 그 중 하나를 “빌려준다”
사용이 끝나면 “반납받는다”

이게 Connection Pool이다.

즉 풀은 “Connection 재사용 시스템”이다.

// ================================
// [DataSource 사용 예시] (풀에서 Connection을 빌려온다)
// - getConnection()을 호출하면 "새로 연결"이 아니라 "풀에서 꺼내온 Connection"일 수 있다
// - close()는 실제 종료가 아니라 "풀에 반납"이 된다
// ================================

public class TodoDAO {

    private final DataSource dataSource;

    public TodoDAO(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    public List<TodoVO> findAll() throws SQLException {

        String sql = "select tno, title, finished from tbl_todo order by tno desc";

        try (Connection conn = dataSource.getConnection();   // 풀에서 빌림
             PreparedStatement ps = conn.prepareStatement(sql);
             ResultSet rs = ps.executeQuery()) {

            List<TodoVO> list = new ArrayList<>();

            while (rs.next()) {
                list.add(new TodoVO(
                        rs.getLong("tno"),
                        rs.getString("title"),
                        rs.getBoolean("finished")
                ));
            }

            return list;
        }
        // conn.close()는 try-with-resources에 의해 호출되지만,
        // "진짜 종료"가 아니라 보통 풀에 "반납"하는 의미가 된다.
    }
}

DataSource는 “풀을 쓰기 위한 표준 인터페이스”이다

자바에서는 Connection Pool을 통일된 방식으로 쓰기 위해
javax.sql.DataSource라는 인터페이스를 제공한다.

DataSource 관점에서 개발자는 딱 한 줄만 중요하다.

dataSource.getConnection()

이 호출이 “새 연결 생성”일 수도 있고,
대부분은 “풀에서 빌려오기”이다.

즉 DataSource는 개발자에게

“Connection을 얻는 표준 창구”

를 제공한다.

풀을 쓰면 close()의 의미가 달라진다

여기서 가장 중요한 오해 포인트가 있다.

풀을 쓰는 상황에서 conn.close()는 보통

DB 연결을 진짜 끊는다

가 아니라

풀에 Connection을 반납한다

의 의미가 된다.

즉 close는 “반납”이다.

그래서 풀을 쓰더라도 close는 반드시 해야 한다.
close를 안 하면 풀에 반납이 안 되고 연결이 고갈된다.

HikariCP는 대표적인 Connection Pool 구현체이다

Connection Pool은 구현체가 필요하다.
그 구현체 중에서 가장 널리 쓰이는 게 HikariCP이다.

HikariCP의 구조는 보통 이렇게 잡는다.

HikariConfig로 설정을 만든다
HikariDataSource를 만든다
이 DataSource를 DAO에 주입해서 사용한다

즉 HikariDataSource는 DataSource 구현체이다.

// ================================
// [HikariCP 설정 예시] (가장 많이 쓰는 커넥션 풀 구현체 중 하나)
// - HikariConfig -> HikariDataSource
// - HikariDataSource는 DataSource 구현체이다
// ================================

HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mariadb://localhost:3306/app");
config.setUsername("root");
config.setPassword("1234");

// 풀 크기 같은 옵션
config.setMaximumPoolSize(10);
config.setMinimumIdle(2);

DataSource ds = new HikariDataSource(config);

전체 흐름

DAO는 DataSource를 가진다
DAO는 필요할 때 getConnection()으로 Connection을 얻는다(빌림)
try-with-resources로 작업이 끝나면 close된다(반납)
풀은 Connection을 재사용해서 성능을 올린다

핵심 정리

Connection 생성은 비싸서 요청마다 새로 만들면 느리다
Connection Pool은 연결을 미리 만들어두고 빌려 쓰는 방식이다
DataSource는 풀을 쓰기 위한 표준 인터페이스이다
풀 환경에서 close()는 보통 “종료”가 아니라 “반납”이다
HikariCP는 대표적인 커넥션 풀 구현체이다

[상태 유지와 공통 처리] 2. JDBC란?

sqaxe1 — Mon, 30 Mar 2026 11:26:29 +0900

자바가 DB와 통신하는 표준 방식

DB 연동을 한다는 말은 결국 이 뜻이다.

자바 프로그램이 네트워크로 DB 서버에 연결한다
SQL을 전송한다
DB가 실행한 결과를 다시 받아서 처리한다

이 흐름을 자바 표준 API로 정리한 게 JDBC이다.

즉 JDBC는 “DB 연결과 SQL 실행을 위한 자바 표준 규격”이다.

JDBC로 DB 작업을 할 때 항상 나오는 3가지 객체

JDBC는 결국 아래 세 가지 객체를 중심으로 돌아간다.

Connection
PreparedStatement
ResultSet

이 세 개만 이해하면 JDBC의 큰 흐름은 끝난다.

// ================================
// [JDBC 기본 흐름] (조회: SELECT)
// 1) Connection 얻기
// 2) PreparedStatement 준비
// 3) 파라미터 바인딩(setXXX)
// 4) executeQuery() -> ResultSet
// 5) ResultSet.next()로 행 이동하며 꺼내기(getXXX)
// 6) 자원 close (try-with-resources 추천)
// ================================

public List<TodoVO> findAll(Connection conn) throws SQLException {

    String sql = "select tno, title, finished from tbl_todo order by tno desc";

    try (PreparedStatement ps = conn.prepareStatement(sql);
         ResultSet rs = ps.executeQuery()) {

        List<TodoVO> list = new ArrayList<>();

        while (rs.next()) {
            long tno = rs.getLong("tno");
            String title = rs.getString("title");
            boolean finished = rs.getBoolean("finished");

            list.add(new TodoVO(tno, title, finished));
        }

        return list;
    }
}

// ================================
// [JDBC 기본 흐름] (변경: INSERT/UPDATE/DELETE)
// - executeUpdate()는 "영향 받은 행 수"를 int로 반환한다
// ================================

public int insert(Connection conn, String title) throws SQLException {

    String sql = "insert into tbl_todo(title, finished) values(?, ?)";

    try (PreparedStatement ps = conn.prepareStatement(sql)) {

        ps.setString(1, title);
        ps.setBoolean(2, false);

        return ps.executeUpdate(); // 보통 1이 나온다(1행 insert)
    }
}

1) Connection: DB와의 연결 자체

Connection은 DB와 네트워크 연결을 의미한다.

연결이 있어야 SQL을 보낼 수 있다
연결이 없으면 아무 것도 못 한다

그리고 JDBC에서 가장 중요한 규칙은 이것이다.

Connection은 반드시 close 해야 한다

DB 서버는 동시에 처리할 수 있는 연결 수가 제한적이다.
close를 안 하면 연결이 쌓여서 결국 신규 연결이 막히는 상황이 생긴다.

2) PreparedStatement: SQL 실행을 담당

PreparedStatement는 SQL을 DB로 보내 실행하는 객체이다.

여기서 중요한 이유는 두 가지이다.

파라미터 바인딩을 안전하게 한다

? 자리에 값을 setXXX()로 넣는다
SQL 문자열 결합을 줄여서 실수를 줄인다

SQL Injection 같은 공격을 줄이는 데 유리하다

사용자 입력을 SQL로 직접 붙이지 않기 때문에 상대적으로 안전하다

그래서 JDBC에서는 Statement보다 PreparedStatement를 기본으로 쓴다.

3) ResultSet: SELECT 결과를 읽는 커서(cursor)

SELECT는 “결과 데이터”를 반환한다.
이 결과를 읽는 도구가 ResultSet이다.

ResultSet은 중요한 특징이 하나 있다.

ResultSet은 처음에는 “첫 행”에 서 있지 않다

그래서 반드시 next()로 다음 행으로 이동해야 한다.

while (rs.next()) {
    // 현재 행의 컬럼 값을 꺼낸다
}

그리고 값을 꺼낼 때는 컬럼 타입에 맞는 메서드를 쓴다.

getLong(), getInt(), getString(), getBoolean() …

JDBC는 SELECT와 DML이 처리 방식이 다르다

JDBC를 처음 할 때 자주 헷갈리는 부분이 여기다.

SELECT (조회)

결과 데이터가 나온다
그래서 executeQuery()를 쓰고 ResultSet을 받는다

DML (INSERT/UPDATE/DELETE)

결과 데이터가 아니라 “영향 받은 행 수”가 중요하다
그래서 executeUpdate()를 쓰고 int를 받는다

즉,

조회 = ResultSet
변경 = 영향 행 수(int)

이 차이를 잡아야 JDBC 코드가 자연스럽게 보인다.

자원 정리는 try-with-resources가 기본이다

JDBC는 자원이 많다.

Connection
PreparedStatement
ResultSet

이걸 제대로 닫지 않으면 누수(leak)가 생긴다.

그래서 가장 깔끔한 방식은 try-with-resources이다.

위 예제 코드처럼 작성하면
블록이 끝날 때 자동으로 close가 호출된다.

핵심 정리

JDBC는 자바가 DB와 통신하기 위한 표준 API이다
Connection은 연결이고 반드시 close 해야 한다
PreparedStatement로 SQL을 실행하고 setXXX로 파라미터를 바인딩한다
SELECT는 executeQuery + ResultSet, DML은 executeUpdate + int이다
try-with-resources로 자원 정리를 자동화하는 게 기본이다

[데이터 처리와 DB연동] 1. DTO / VO(Entity) / DAO / Service는 왜 나누는가?

sqaxe1 — Mon, 30 Mar 2026 10:57:18 +0900

웹 애플리케이션을 만들면 결국 데이터가 필요하다.
게시글, 회원, 주문, 할 일 목록처럼 “저장하고 꺼내야 하는 정보”가 생긴다.

이때 중요한 건 단순히 “DB에 넣고 꺼내는 코드”가 아니라,
그 코드를 어떤 구조로 나눠서 유지보수 가능하게 만들 것인가이다.

그래서 보통 아래 네 가지 역할을 분리해서 생각한다.

DTO
VO(Entity)
DAO
Service

1) DTO: 계층 사이를 오가는 “전달용 데이터 묶음”

DTO(Data Transfer Object)는 이름 그대로 “전달용 객체”이다.

컨트롤러 ↔ 서비스
서비스 ↔ DAO
서버 ↔ 화면(JSP/API)

처럼 계층 사이에서 값을 주고받을 때 쓰는 택배 상자이다.

DTO의 특징은 보통 이렇다.

여러 값을 한 번에 묶어서 전달한다
필요하면 입력값 검증(스프링에서는 더 강하게)에도 쓰인다
로직을 넣기보다 “데이터 담기”에 집중한다

즉 DTO는 “역할”이 아니라 “운반”이 목적이다.

2) VO(Entity): DB 한 행(row)을 표현하는 “데이터 자체”

VO(Value Object) 또는 Entity는 DB의 한 행을 자바 객체로 표현한 것이다.

예를 들어 todo 테이블이 있다면
그 테이블의 한 행을 표현하는 Todo 같은 클래스가 VO/Entity 역할을 한다.

VO/Entity는 이런 성격이 강하다.

DB 구조에 가깝다
“데이터 그 자체”를 표현한다
보통 DAO가 이 객체 단위로 데이터를 다룬다

DTO가 “배송 상자”라면
VO/Entity는 “실제 물건”에 가깝다.

3) DAO: DB 접근을 전담하는 객체

DAO(Data Access Object)는 DB 접근 로직을 모아놓은 객체이다.

즉 DAO는 “데이터베이스와 직접 대화하는 계층”이다.

DAO가 하는 일의 예시는 이런 것들이다.

insert/update/delete/select 실행
JDBC로 Connection/PreparedStatement/ResultSet 처리
결과를 VO/Entity로 매핑해서 반환

핵심은 이것이다.

서비스/컨트롤러는 SQL이 어떻게 실행되는지 몰라도 된다
DB 접근은 DAO가 책임진다

4) Service: 비즈니스 로직(기능)을 묶는 계층

Service는 기능 단위 로직을 담당한다.

예를 들어 “Todo 등록” 기능이 있다면
그 기능이 단순 insert 하나로 끝나지 않을 수 있다.

입력값 검증
중복 체크
트랜잭션 처리
여러 DAO 호출 조합
정책(규칙) 적용

이런 “업무 규칙”을 모으는 곳이 Service이다.

즉 DAO가 “데이터 접근”이라면
Service는 “기능의 의미”를 담당한다.

전체 흐름

웹 MVC에서 일반적인 흐름은 이런 식이다.

Controller가 요청 파라미터를 받아 DTO를 만든다
Controller가 Service를 호출한다
Service가 필요한 정책/로직을 수행한다
Service가 DAO를 호출해 DB 작업을 수행한다
DAO가 DB 결과를 VO/Entity로 만들어 반환한다
필요하면 Service가 VO/Entity를 DTO로 변환해 Controller에 준다
Controller가 View(JSP)에 전달한다

즉 역할을 나눠서 “책임 분리”를 만든다.

DTO와 VO를 왜 둘 다 만들까

여기서 현실적으로 제일 많이 나오는 질문이 이거다.

“DTO랑 VO가 비슷한데 왜 둘 다 만들지?”

둘의 목적이 다르기 때문이다.

DTO: 계층 사이 전달 / 입력값 중심 / 화면 중심
VO(Entity): DB 모델 표현 / 저장/조회 중심

처음에는 귀찮아 보이지만
프로젝트가 커질수록 분리해 둔 구조가 더 유리해진다.

특히 스프링/JPA로 넘어가면
VO(Entity)는 필수 개념이 된다.

핵심 정리

DTO는 전달용 데이터 상자이다
VO(Entity)는 DB 한 행을 표현하는 데이터 자체이다
DAO는 DB 접근을 전담한다
Service는 기능(비즈니스 로직)을 묶는다
역할 분리를 하면 유지보수와 확장이 쉬워진다

[상태 유지와 공통 처리] 5. 리스너(Listener)란?

sqaxe1 — Mon, 30 Mar 2026 10:37:37 +0900

특정 이벤트 시점에 자동 실행되는 훅(hook)

필터는 요청이 들어올 때마다 실행되는 공통 처리 장치였다.
즉 “요청 흐름 중간”에 끼어드는 방식이다.

반면 어떤 작업은 “요청이 올 때마다”가 아니라
특정 시점에 한 번만 실행되는 게 더 자연스럽다.

예를 들어 이런 것들이다.

애플리케이션이 시작될 때 초기화 작업을 하고 싶다
애플리케이션이 종료될 때 자원 정리를 하고 싶다
세션이 생성/종료될 때 로그를 남기고 싶다

이런 “이벤트 기반 실행”을 위해 서블릿 API는 리스너(Listener)를 제공한다.

리스너는 “옵저버 패턴” 형태이다

리스너는 감시 대상(이벤트)이 있고,
이벤트가 발생하면 리스너가 자동으로 호출되는 구조이다.

즉 개발자는

“언제 실행될지”를 직접 호출로 제어하는 게 아니라
“이 이벤트가 발생하면 이 코드를 실행해라”를 등록한다

이게 리스너의 핵심이다.

// ================================
// [Listener 기본 형태] 애플리케이션 시작/종료 시점에 자동 실행
// - @WebListener + ServletContextListener
// ================================

@WebListener
public class AppInitListener implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        // 웹 애플리케이션 시작 시 1번 실행
        ServletContext app = sce.getServletContext();

        // 애플리케이션 공용 객체 등록 (Application Scope)
        app.setAttribute("appName", "W2");

        System.out.println("[Listener] contextInitialized: appName set");
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        // 웹 애플리케이션 종료 시 1번 실행
        System.out.println("[Listener] contextDestroyed");
    }
}

ServletContextListener: 애플리케이션 시작/종료 이벤트

가장 대표적인 리스너가 ServletContextListener이다.

contextInitialized() : 웹 애플리케이션 시작 시 1회 실행
contextDestroyed() : 웹 애플리케이션 종료 시 1회 실행

즉 “서버가 뜰 때 / 내려갈 때” 실행되는 훅이다.

이 리스너가 왜 중요하냐면,
초기화 작업을 “한 곳에 모아서” 처리할 수 있기 때문이다.

ServletContext는 애플리케이션 공용 저장소(Application Scope)이다

`ServletContextListener`는 `ServletContextEvent`를 받는다.
여기서 getServletContext()로 ServletContext를 얻을 수 있다.

ServletContext는 한 문장으로 말하면 이거다.

현재 웹 애플리케이션 전체에서 공유하는 저장소

즉 여기다 값을 넣으면 모든 서블릿/JSP가 공유해서 볼 수 있다.

예:

app.setAttribute("appName", "W2");

그러면 JSP에서는 EL로 이렇게 읽을 수 있다.

${appName}
${applicationScope.appName}

이게 application scope이다.

리스너를 쓰는 대표적인 이유: “초기화”를 한 번에

웹 애플리케이션은 보통 시작할 때 준비해야 하는 것들이 있다.

예:

DB 커넥션 풀 초기화
서비스 객체 생성 및 등록
공용 설정값 로딩
공용 리소스 캐싱

이걸 각 컨트롤러에서 매번 만들면

중복 생성 문제가 생기고
관리가 어렵고
시작 시점 제어도 힘들어진다

그래서 리스너에서 한 번만 생성해서 ServletContext에 등록해두고
컨트롤러가 가져다 쓰는 구조가 가능해진다.

(나중에 스프링이 이런 역할을 더 체계적으로 해준다)

@WebListener로 등록한다

리스너는 컨테이너가 알아서 실행해야 하므로 등록이 필요하다.

요즘은 보통 어노테이션으로 등록한다.

@WebListener

이 어노테이션이 붙어 있으면 톰캣이 시작할 때 리스너를 인식하고
해당 이벤트 시점에 자동 실행한다.

핵심 정리

리스너는 특정 이벤트 시점에 자동 실행되는 훅이다
필터가 “요청마다 실행”이라면, 리스너는 “시작/종료 같은 이벤트에 실행”이다
ServletContextListener는 애플리케이션 시작/종료 시점에 실행된다
ServletContext는 애플리케이션 공용 저장소(Application Scope)이다
초기화 작업(DB 풀, 공용 객체 준비 등)을 리스너에서 한 번에 처리할 수 있다

[상태 유지와 공통 처리] 4. 필터(Filter)란?

sqaxe1 — Mon, 30 Mar 2026 10:17:51 +0900

“컨트롤러 앞에서 공통 로직을 한 번에 적용한다”

“로그인 체크를 어디에 넣어야 하지?”

보호해야 하는 URL이 많아지면
컨트롤러마다 똑같은 코드를 반복하게 된다.

HttpSession session = req.getSession(false);
if (session == null || session.getAttribute("loginUser") == null) {
    resp.sendRedirect("/login-form");
    return;
}

이걸 모든 서블릿에 복붙하면

코드가 중복되고
빠뜨리기 쉽고
유지보수도 힘들어진다

그래서 “요청이 컨트롤러에 들어가기 전에” 공통 로직을 적용하는 장치가 필요하다.
그게 필터(Filter)이다.

필터는 “서블릿 앞단에서 실행되는 가로채기(Interceptor)”이다

필터는 서블릿 API에서 제공하는 특별한 객체이다.

요청이 서블릿/JSP에 도달하기 전에 실행된다(사전 처리)
필요하면 서블릿 실행 후에도 실행될 수 있다(사후 처리)
특정 URL 패턴에만 적용할 수 있다

즉 필터는 “컨트롤러 앞에서 공통 처리를 한 번에 적용하는 장치”이다.

필터의 핵심 메서드: doFilter()

필터는 doFilter() 메서드 하나가 핵심이다.

void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)

여기서 중요한 포인트는 두 가지이다.

Filter는 HTTP 전용이 아니다

그래서 파라미터 타입이 ServletRequest/ServletResponse이다
HTTP 기능이 필요하면 HttpServletRequest/HttpServletResponse로 다운캐스팅한다

반드시 chain.doFilter()를 호출해야 다음 단계로 진행된다

이 호출을 하지 않으면 요청이 필터에서 멈춘다
즉 “통과시키지 않겠다”는 의미가 된다

이 구조 덕분에 필터는 다음이 가능하다.

조건이 맞으면 통과(chain.doFilter)
조건이 틀리면 여기서 끊고 redirect/에러 처리

@WebFilter로 적용 범위를 지정한다

필터는 모든 요청에 다 걸 수도 있고,
특정 경로에만 걸 수도 있다.

예를 들어

@WebFilter("/*") : 전체 요청
@WebFilter("/todo/*") : todo 아래만

실무에서는 보통 “로그인 체크”처럼 필요한 범위만 걸어주는 방식이 많다.

로그인 체크 필터 흐름

로그인 체크 필터는 보통 이런 흐름으로 작성한다.

현재 요청 URI를 확인한다
로그인 페이지/로그인 처리 URL은 예외로 통과시킨다
그 외 경로는 세션에서 loginUser를 확인한다
없으면 로그인 페이지로 redirect 한다
있으면 chain.doFilter로 통과시킨다

이렇게 하면 컨트롤러마다 로그인 체크 코드를 쓰지 않아도 된다.

필터는 UTF-8 인코딩 처리에도 자주 쓰인다

POST로 한글이 깨지는 문제는
컨트롤러마다 request.setCharacterEncoding("UTF-8")을 넣으면 해결되지만
이것도 중복이 생긴다.

그래서 인코딩 처리도 필터로 많이 뺀다.

즉 필터는 로그인뿐 아니라 “모든 공통 관심사”를 처리하는 도구이다.

핵심 정리

필터는 서블릿 앞에서 실행되는 공통 처리 장치이다
doFilter에서 chain.doFilter를 호출해야 다음 단계로 넘어간다
HTTP 기능이 필요하면 HttpServletRequest/Response로 다운캐스팅한다
로그인 체크, 인코딩 처리 같은 반복 코드를 필터로 분리할 수 있다

[상태 유지와 공통 처리] 3. SESSIONID이란?

sqaxe1 — Mon, 30 Mar 2026 10:12:40 +0900

"세션 저장소의 키”로 쓰이는 쿠키 값

앞 글에서 세션은 이렇게 동작한다고 정리했다.

실제 데이터는 서버(톰캣)의 세션 저장소에 보관한다
브라우저는 쿠키로 “세션ID”만 들고 다닌다
서버는 그 세션ID로 세션 저장소에서 사용자 세션을 찾는다

여기서 그 “세션ID”가 바로 JSESSIONID의 값이다.

즉 JSESSIONID는 로그인 정보가 아니다.
서버가 로그인 정보를 찾기 위한 키(열쇠 번호) 이다.

JSESSIONID의 정체: 쿠키 이름이다 (값이 세션ID)

먼저 용어를 정확히 분리해야 한다.

JSESSIONID : 쿠키의 이름(name) 이다
JSESSIONID=abc123... : 여기서 abc123...이 세션ID(value) 이다

즉 브라우저는 쿠키로 이런 형태를 들고 다닌다.

Cookie: JSESSIONID=abc123...

서버(톰캣)는 이 abc123... 값을 읽어서
세션 저장소에서 해당 세션을 찾는다.

세션 저장소 관점에서 보면 JSESSIONID는 “키”이다

서버 내부를 개념적으로 보면 보통 이런 구조이다.

세션 저장소(Map 같은 구조)
- key: 세션ID (쿠키 JSESSIONID의 value)
- value: 세션 한 칸(사용자별 attribute 저장 공간)

그래서 JSESSIONID 값이 바뀌면
서버 입장에서는 “다른 세션”으로 인식한다.

session.getId()가 곧 JSESSIONID 값이다

서블릿에서 세션ID를 직접 보면 더 직관적이다.

// ================================
// 세션ID 확인용 예시
// - session.getId() 값이 곧 JSESSIONID 쿠키의 value와 대응된다
// ================================

@WebServlet("/session/id")
public class SessionIdServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {

        HttpSession session = req.getSession(); // 없으면 생성 + JSESSIONID 발급 준비
        String sessionId = session.getId();

        resp.setContentType("text/plain; charset=UTF-8");
        resp.getWriter().println("session.getId() = " + sessionId);
    }
}

이 요청을 “쿠키 없는 상태”에서 처음 호출하면, 보통 이런 일이 벌어진다.

서버가 새 세션을 만들고 session.getId()를 생성한다
응답 헤더로 Set-Cookie: JSESSIONID=방금생성한ID가 내려간다
다음 요청부터 브라우저가 Cookie: JSESSIONID=그ID를 자동으로 붙인다

즉 session.getId() 값과 브라우저가 들고 다니는 JSESSIONID 값은 연결된다.

JSESSIONID는 “로그인 정보”가 아니라 “로그인 정보를 찾는 열쇠”이다

여기서 흔히 하는 오해가 있다.

“JSESSIONID가 있으니까 로그인된 거 아닌가?”

아니다.

JSESSIONID가 있다는 건 단지

“서버 세션 저장소에 접근할 수 있는 열쇠가 있다”

라는 뜻이다.

로그인 여부는 결국 세션 안에 저장된 값으로 결정된다.

// 로그인 여부 체크는 보통 이렇게 한다
HttpSession session = req.getSession(false);
String loginUser = (session == null) ? null : (String) session.getAttribute("loginUser");

if (loginUser == null) {
    // 로그인 안 됨
}

즉 핵심은 이거다.

JSESSIONID = 세션을 찾는 키
loginUser = 로그인 상태를 판단하는 데이터(세션 attribute)

JSESSIONID는 언제 발급되는가

보통은 아래 시점에서 발급된다.

req.getSession()을 호출했는데, 현재 요청에 유효한 세션이 없을 때

즉 “세션이 새로 만들어지는 순간”에 발급된다.

반대로 요청에 유효한 JSESSIONID가 이미 있고 세션이 살아 있으면
대부분은 새로 발급되지 않는다(그냥 기존 세션을 찾아서 쓴다).

JSESSIONID는 언제까지 유지되는가

여기서 두 개를 구분해야 한다.

1) 쿠키(JSESSIONID)의 유지

보통 톰캣이 발급하는 JSESSIONID는 “세션 쿠키” 형태가 많다
즉 브라우저를 종료하면 쿠키가 사라질 수 있다(설정에 따라 다를 수 있음)

2) 서버 세션의 유지(세션 타임아웃)

서버는 세션을 영원히 유지하지 않는다
일정 시간 동안 요청이 없으면 만료시키고 저장소에서 제거한다

즉 브라우저에 쿠키가 남아 있어도
서버에서 세션이 만료되면 그 JSESSIONID는 더 이상 유효하지 않다.

그 상태에서 다시 요청이 오면

서버는 “세션이 없네?”라고 판단하고
새 세션을 만들고
새 JSESSIONID를 다시 발급할 수 있다

세션을 강제로 종료하면 어떻게 되나: invalidate()

로그아웃은 보통 세션을 무효화하는 방식으로 처리한다.

// ================================
// 로그아웃 예시: 세션 무효화
// ================================

@WebServlet("/logout")
public class LogoutController extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {

        HttpSession session = req.getSession(false);
        if (session != null) {
            session.invalidate(); // 서버 세션 저장소에서 해당 세션을 무효화
        }

        resp.sendRedirect(req.getContextPath() + "/login-form");
    }
}

invalidate()의 의미는 단순하다.

서버 저장소에서 “그 세션 한 칸”을 폐기한다

그래서 브라우저가 기존 JSESSIONID 쿠키를 들고 다시 요청해도
서버는 세션을 못 찾아서 새 세션을 만들 수 있다.

(실무에서는 쿠키도 지우도록 응답을 추가하기도 하지만, 핵심은 서버 세션 무효화이다.)

핵심 정리

JSESSIONID는 쿠키 이름이고, 그 값(value)이 세션ID이다
세션ID는 서버 세션 저장소에서 세션을 찾는 “키” 역할을 한다
session.getId() 값이 세션ID이고, JSESSIONID 쿠키 값과 연결된다
JSESSIONID가 있다고 로그인된 게 아니다(로그인 여부는 session attribute로 판단)
세션은 서버에서 timeout으로 만료되고, 로그아웃은 보통 invalidate로 처리한다

[상태 유지와 공통처리] 2-1. req.getSession()과 JSESSIONID, HttpSession

sqaxe1 — Mon, 30 Mar 2026 09:47:10 +0900

“세션은 어디에 생기고, 쿠키는 언제 내려가고, HttpSession은 정확히 무엇인가”

세션을 공부하다 아래와 같은 궁금증이 들었다.

session.setAttribute("loginUser", id)를 하면 Set-Cookie: JSESSIONID=...가 내려가는 건가?
req.getSession()은 “세션 저장소”를 만드는 건가, “JSESSIONID 값”을 만드는 건가?
새 세션 공간이 HttpSession 자체인가, 아니면 저장소 안의 한 칸이 따로 있는 건가?

쿠키(JSESSIONID)와 세션(HttpSession)은 같은 게 아니다

세션 기반 로그인에서 항상 같이 등장하는 두 개념은 역할이 다르다.

JSESSIONID(쿠키의 값): 브라우저가 들고 다니는 “열쇠(식별자)”이다
세션 저장소(서버): 서버(톰캣) 메모리에 있는 “사물함 보관소”이다
세션 한 칸(개별 세션): 사물함 보관소 안의 “사용자별 칸”이다
HttpSession: 개발자가 자바 코드에서 그 “한 칸”을 다루도록 주어지는 핸들(표준 인터페이스)이다

즉, 쿠키에 로그인 정보를 직접 넣는 게 아니라
쿠키에는 “세션ID(열쇠 번호)”만 담고,
실제 로그인 정보는 서버 세션 저장소에 담는다.

session.setAttribute("loginUser", id)는 쿠키를 만드는 코드가 아니다

session.setAttribute("loginUser", id);

이 코드는 쿠키를 내려주는 코드가 아니다.

이 코드는 딱 한 가지 동작만 한다.

“서버의 세션 저장소에서 내 세션 한 칸에 loginUser=id를 저장한다”

즉, setAttribute는 세션 내부에 데이터를 넣는 동작이다.
쿠키(JSESSIONID)를 만들거나 내려주는 역할은 아니다.

그럼 쿠키는 언제 내려가나?
그 트리거가 바로 req.getSession()이다.

req.getSession()은 정확히 뭘 하냐: (있으면 찾고, 없으면 만든다)

req.getSession()은 한 문장으로 요약하면 이렇다.

“요청이 들고 온 JSESSIONID로 기존 세션을 찾아서 돌려주고, 없으면 새 세션을 만들고 새 JSESSIONID까지 발급한다”

즉 “찾기 + 만들기”가 같이 들어있다.
단, 세션이 없는 경우에만 만들기 로직이 동작한다.

“세션이 없다”의 의미는 뭔가

톰캣은 요청을 받으면 먼저 확인한다.

요청 헤더에 Cookie: JSESSIONID=...가 있는가?
그 값으로 서버 세션 저장소에서 세션을 실제로 찾을 수 있는가?
- 만료/삭제된 세션이면 못 찾는다

둘 중 하나라도 실패하면 “세션이 없다”로 본다.

케이스 A: JSESSIONID가 없거나 유효하지 않을 때

HttpSession session = req.getSession();

이 한 줄로 톰캣은 두 가지를 같이 한다.

서버 세션 저장소에 새 세션 한 칸을 만든다
그 한 칸을 찾기 위한 세션ID를 만들고(=JSESSIONID 값), 응답에 Set-Cookie로 내려줄 준비를 한다

즉 이때는

세션 저장소 “한 칸”이 새로 생기고
그 칸을 가리키는 “열쇠 번호”가 새로 생긴다

그리고 응답이 나갈 때 브라우저로 이런 헤더가 내려간다.

Set-Cookie: JSESSIONID=새값; Path=/; ...

케이스 B: JSESSIONID가 이미 있고 유효할 때

HttpSession session = req.getSession();

이번에는 “만드는 것”이 아니라 “찾는 것”이다.

브라우저가 Cookie: JSESSIONID=기존값을 붙여서 보낸다
톰캣이 그 값으로 세션 저장소에서 세션 한 칸을 찾는다
찾은 세션을 HttpSession 형태로 돌려준다
새로 만들 게 없으니 Set-Cookie를 굳이 다시 내릴 필요가 없다(일반적인 흐름)

그럼 “새 세션 공간”은 HttpSession 자체인가?

정답은 이렇다.

세션 저장소 안에는 “세션 한 칸(세션 엔트리)”이 실제로 존재한다
개발자가 자바 코드에서 만지는 것은 그 한 칸을 조작하기 위한 표준 인터페이스인 HttpSession이다

즉 구조는 이렇게 이해하면 된다.

세션 저장소(Map 같은 구조)
- key = 세션ID (쿠키 JSESSIONID의 값)
- value = 세션 한 칸(Session 엔트리)

그리고 개발자에게는

그 value(세션 한 칸)를 조작할 수 있는 핸들로 HttpSession이 제공된다

“같냐?”라고 물으면 엄밀히는 구현체가 따로 있지만, 학습 관점에서는

세션 한 칸(서버 엔트리) 1개 ↔ HttpSession 1개가 대응된다

라고 생각해도 된다.

로그인 흐름을 타임라인으로 보면 완전히 정리된다

1. 첫 로그인 요청(브라우저에 JSESSIONID 없음)

브라우저:

POST /login (Cookie 없음)

서버 코드:

HttpSession session = req.getSession();     // ① 세션 없으니 새 세션 생성 + 새 세션ID 발급 준비
session.setAttribute("loginUser", id);      // ② 서버 세션 한 칸에 loginUser 저장
resp.sendRedirect("/home");                 // ③ 응답 전송

응답이 나갈 때:

Set-Cookie: JSESSIONID=...가 내려간다 (①에서 새 세션을 만들었으니까)

브라우저는:

JSESSIONID 쿠키를 저장한다

2. 다음 요청부터(브라우저가 JSESSIONID를 자동 전송)

브라우저:

GET /home 요청
요청 헤더에 Cookie: JSESSIONID=... 자동 첨부

서버는:

JSESSIONID로 세션 저장소에서 세션 한 칸을 찾는다
session.getAttribute("loginUser")로 로그인 상태를 확인할 수 있다

getSession() vs getSession(false)가 중요한 이유

getSession()
- 세션이 없으면 새로 만든다 (세션 한 칸 + 세션ID + Set-Cookie 준비)
getSession(false)
- 세션이 없으면 null을 반환한다 (새로 만들지 않는다)

로그인 체크 같은 곳에서 getSession()을 무심코 쓰면
로그인 안 한 사용자에게도 세션을 쓸데없이 만들어서 서버 메모리를 낭비할 수 있다.

그래서 “체크”는 보통 getSession(false)가 더 안전하다.

정리

session.setAttribute(...)는 세션 데이터 저장이지, 쿠키 발급이 아니다
req.getSession()은
- 있으면 기존 세션을 찾고,
- 없으면 서버에 세션 한 칸을 만들고 + 새 세션ID(JSESSIONID 값)를 발급한다
세션 저장소 안의 “개별 세션 한 칸”이 실제 세션이고
HttpSession은 그 한 칸을 자바 코드에서 다루기 위한 핸들(인터페이스)이다
세션ID는 쿠키(JSESSIONID)로 브라우저가 들고 다니는 “열쇠” 역할이다

[상태 유지와 공통 처리] 2. 세션이란?

sqaxe1 — Mon, 30 Mar 2026 09:20:21 +0900

쿠키는 “열쇠”, 데이터는 “서버에 보관”한다

쿠키는 상태 유지를 가능하게 하지만 한계가 있다.

브라우저에 저장되므로 노출/변조 위험이 있다
큰 데이터를 넣기 어렵다(문자열, 크기 제한)
중요한 사용자 상태를 쿠키에 담는 건 위험하다

그래서 보통

쿠키에는 “식별자”만 넣고
실제 사용자 상태/데이터는 서버에 저장한다

이 방식이 세션(session)이다.

세션의 핵심 구조: 세션ID로 서버 저장소를 찾는다

세션은 결국 이런 구조이다.

서버는 사용자별 “저장 공간”을 가진다(세션 저장소)
각 공간은 세션ID로 구분된다
브라우저는 세션ID를 쿠키로 들고 다닌다
요청이 오면 서버는 세션ID로 세션 공간을 찾아준다

즉 세션은 “브라우저 저장(쿠키)”과 “서버 저장(세션 저장소)”을 조합한 구조이다.

톰캣에서 세션이 자동으로 만들어지는 흐름

톰캣 같은 서블릿 컨테이너는 세션을 지원한다.

컨트롤러에서 아래를 호출하면,

request.getSession()

톰캣은 다음을 수행한다.

요청에 세션ID 쿠키가 있는지 확인한다
없으면 새 세션을 만들고 세션ID를 발급한다
응답에 Set-Cookie: JSESSIONID=...로 내려준다
다음 요청부터 브라우저는 Cookie: JSESSIONID=...를 자동으로 붙인다

즉 “세션은 쿠키(JSESSIONID) 없이 동작할 수 없다”는 구조이다.
쿠키가 세션을 찾는 열쇠 역할을 한다.

// ================================
// [세션 사용 예시] 로그인 성공 시 세션에 사용자 정보를 저장
// ================================

@WebServlet("/login")
public class LoginController extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException {

        String id = req.getParameter("id");
        String pw = req.getParameter("pw");

        // 예시: 인증 성공했다고 가정
        boolean ok = "user1".equals(id) && "1234".equals(pw);

        if (ok) {
            // 세션이 없으면 생성
            HttpSession session = req.getSession();
            session.setAttribute("loginUser", id); // 세션에 로그인 정보 저장

            resp.sendRedirect(req.getContextPath() + "/home");
        } else {
            resp.sendRedirect(req.getContextPath() + "/login-form");
        }
    }
}

세션 저장소는 서버에 있다

세션의 데이터는 브라우저에 저장되지 않는다.
서버(톰캣) 메모리의 세션 저장소에 저장된다.

그래서 세션은 다음 장점이 있다.

중요한 데이터를 브라우저에 노출하지 않는다
객체를 그대로 저장할 수 있다(문자열만이 아님)
로그인 상태 유지에 적합하다

대신 단점도 있다.

서버 메모리를 사용한다
사용자가 많으면 세션이 쌓인다
그래서 만료/정리가 필요하다

세션은 언제까지 유지되는가: timeout

세션은 영원히 유지되지 않는다.
컨테이너는 일정 시간 동안 요청이 없으면 세션을 만료시킨다.

즉 “오래 안 쓰는 세션은 정리해서 메모리를 비운다”가 기본 전략이다.

톰캣은 기본적으로 세션 타임아웃을 가지고 있고
주기적으로 오래된 세션을 청소한다.

세션으로 로그인 상태를 유지하는 전형적인 패턴

세션을 이용한 로그인 체크는 보통 이렇게 한다.

1) 로그인 성공 시

request.getSession()으로 세션을 얻고(없으면 생성)
session.setAttribute("loginUser", user)로 로그인 정보를 저장한다

2) 보호된 페이지 접근 시

request.getSession(false)로 세션을 얻는다(없으면 null)
session.getAttribute("loginUser")가 있으면 로그인으로 판단한다
없으면 로그인 페이지로 redirect 한다

이게 세션 기반 로그인 유지의 기본 패턴이다.

getSession() vs getSession(false)

여기서 실전에서 중요한 차이가 하나 있다.

getSession()
- 세션이 없으면 새로 만든다
getSession(false)
- 세션이 없으면 null을 반환한다(새로 만들지 않는다)

로그인 체크처럼 “없으면 없는 대로 처리”해야 하는 상황에서는
보통 getSession(false)를 쓰는 게 안전하다.

핵심 정리

쿠키는 브라우저에 저장되므로 중요한 데이터를 담기 어렵다
세션은 쿠키(세션ID)로 서버 저장소를 찾아오는 구조이다
톰캣은 request.getSession() 호출 시 JSESSIONID를 발급하고 세션을 만든다
로그인 상태 유지는 보통 session.setAttribute로 구현한다
getSession(false)는 세션이 없으면 null(불필요한 세션 생성 방지)

[상태 유지와 공통 처리] 1. 쿠키란?

sqaxe1 — Mon, 30 Mar 2026 08:34:54 +0900

HTTP 무상태를 “브라우저 저장소”로 보완한다

HTTP는 무상태(stateless)라고 했다.
즉 서버는 기본적으로 “이전 요청이 누가 보낸 건지”를 기억하지 않는다.

그런데 로그인, 장바구니, 사용자 맞춤 화면 같은 기능은
이전 상태를 이어서 써야 한다.

그래서 웹에는 상태 유지를 위한 메커니즘이 필요하고,
그 출발점이 쿠키(cookie)이다.

쿠키는 “서버와 브라우저 사이를 오가는 작은 문자열 데이터”이다

쿠키는 기본적으로 이름과 값으로 이루어진 데이터 조각이다.

이름(name)
값(value)

이 쿠키는 브라우저에 저장되고,
이후 요청에서 자동으로 서버에 다시 전송된다.

즉 쿠키는 브라우저가 들고 다니는 상태 정보이다.

쿠키가 오고 가는 방식은 헤더로 결정된다

쿠키는 HTTP 메시지의 헤더로 주고받는다.

서버 → 브라우저: Set-Cookie 헤더로 쿠키 발급
브라우저 → 서버: Cookie 헤더로 쿠키 전송

즉 서버는 “응답(response)”에서 쿠키를 내려주고,
브라우저는 “다음 요청(request)”에서 그 쿠키를 붙여서 보낸다.

쿠키 기본 흐름

쿠키는 보통 이런 순서로 동작한다.

첫 요청: 브라우저에 쿠키가 없으면 Cookie 헤더 없이 요청한다
서버 응답: 서버가 Set-Cookie로 쿠키를 내려준다
브라우저 저장: 브라우저가 쿠키를 저장한다
다음 요청: 브라우저가 Cookie 헤더로 쿠키를 자동 첨부한다
서버는 쿠키 값을 읽어서 사용자 상태를 추적한다

즉 쿠키는 HTTP의 무상태성을 “브라우저 저장”으로 보완하는 장치이다.

쿠키는 서버가 발급하지만, 저장과 전송은 브라우저가 한다

여기서 오해하면 안 되는 포인트가 있다.

서버는 쿠키를 “발급”한다(Set-Cookie)
브라우저는 쿠키를 “저장”한다
브라우저는 조건이 맞으면 쿠키를 “자동으로 전송”한다

즉 서버가 매 요청마다 쿠키를 직접 들고 오는 게 아니라,
브라우저가 알아서 붙여서 보내준다.

쿠키 옵션이 중요한 이유: 언제, 어디로 전송되는지가 결정된다

쿠키는 “그냥 항상 다 붙는 문자열”이 아니다.
대표적으로 아래 옵션이 쿠키 동작을 바꾼다.

Path: 어떤 경로 요청에 쿠키를 붙일지
- /로 두면 사이트 전체에 붙는다
- /todo로 두면 /todo/... 요청에만 붙는다
Max-Age: 쿠키가 얼마나 유지될지(초 단위)
- 설정하면 브라우저가 디스크에 저장(지속 쿠키)
- 설정하지 않거나 -1이면 브라우저 종료 시 삭제(세션 쿠키)

그래서 “쿠키가 왜 안 붙지?” 문제의 상당수는
Path/Max-Age 설정에서 나온다.

// ================================
// [서버에서 쿠키 발급] 응답에 Set-Cookie가 포함되게 만든다
// ================================

@WebServlet("/cookie/set")
public class CookieSetServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {

        Cookie cookie = new Cookie("theme", "dark"); // 이름=값

        cookie.setPath("/");          // 사이트 전체에서 전송되게
        cookie.setMaxAge(60 * 60);    // 1시간(초 단위). -1이면 브라우저 종료 시 삭제(세션 쿠키)

        resp.addCookie(cookie);       // Set-Cookie 헤더로 내려감
        resp.setContentType("text/plain; charset=UTF-8");
        resp.getWriter().println("cookie set: theme=dark");
    }
}

// ================================
// [서버에서 쿠키 읽기] 브라우저가 Cookie 헤더로 보내온 쿠키를 읽는다
// ================================

@WebServlet("/cookie/read")
public class CookieReadServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {

        String theme = null;

        Cookie[] cookies = req.getCookies(); // 없으면 null일 수도 있다
        if (cookies != null) {
            for (Cookie c : cookies) {
                if ("theme".equals(c.getName())) {
                    theme = c.getValue();
                    break;
                }
            }
        }

        resp.setContentType("text/plain; charset=UTF-8");
        resp.getWriter().println("theme = " + theme);
    }
}

정리

HTTP는 무상태라서 상태 유지가 필요하다
쿠키는 브라우저에 저장되는 작은 문자열 데이터이다
서버는 Set-Cookie로 발급하고, 브라우저는 Cookie 헤더로 자동 전송한다
Path/Max-Age 같은 옵션이 쿠키 전송 조건을 결정한다

하지만 쿠키는 브라우저에 저장되기 때문에 한계가 있고,
그 한계를 보완하기 위해 서버 쪽 저장소를 쓰는 방식이 세션이다.

[MVC와 웹 흐름 제어] 7. WEB-INF에 JSP를 두는 이유: “JSP 직접 호출”을 구조적으로 막는다

sqaxe1 — Sun, 29 Mar 2026 22:24:38 +0900

MVC 구조를 제대로 만들려면 한 가지를 강제로 지켜야 한다.

브라우저는 JSP를 직접 호출하지 않는다
브라우저는 Controller(서블릿) URL만 호출한다
Controller가 처리한 뒤 JSP(View)로 forward 한다

그런데 문제는 JSP가 파일 경로 기반으로 접근 가능하면
사용자가 주소창에 JSP URL을 직접 입력해서 들어올 수 있다는 점이다.

이걸 “규칙”으로만 막으려 하면 항상 구멍이 생긴다.
그래서 웹 애플리케이션에는 아예 “직접 접근이 불가능한 보호 영역”이 있다.

그게 WEB-INF이다.

WEB-INF는 브라우저에서 직접 접근할 수 없는 특별한 경로이다

WEB-INF 아래에 있는 자원은
브라우저의 외부 요청으로 직접 접근할 수 없다.

즉 아래 같은 URL을 브라우저에서 직접 입력해도 실행되지 않는다.

/WEB-INF/views/todo/list.jsp

이 특성 때문에 WEB-INF는 “외부 접근 차단 구역”으로 쓰인다.

JSP를 WEB-INF 아래에 두면 뭐가 달라지나

JSP가 일반 경로에 있으면 이런 일이 가능하다.

사용자가 JSP URL만 알면 직접 GET 요청으로 들어온다
Controller를 거치지 않는다
GET/POST 제어, 데이터 준비, 권한 체크 같은 흐름이 무너진다

반대로 JSP를 WEB-INF 아래에 두면 구조가 바뀐다.

브라우저는 JSP에 직접 접근할 수 없다
Controller만 RequestDispatcher.forward로 접근할 수 있다
즉 반드시 Controller를 거치게 강제된다

이게 MVC 구조를 코드 규칙이 아니라 배치 구조로 보장해주는 장치이다.

WEB-INF는 “View는 내부 자원”이라는 의도를 강제한다

MVC에서 View(JSP)는 사용자에게 노출되는 엔드포인트가 아니다.
View는 Controller가 내부적으로 선택해서 렌더링하는 내부 자원이다.

WEB-INF 아래로 JSP를 숨기면
이 의도가 구조적으로 강제된다.

URL 설계는 Controller 기준으로 한다
JSP 파일명/폴더 구조는 내부 구현이다
화면 파일이 바뀌어도 외부 URL은 유지할 수 있다

즉 유지보수에 유리해진다.

실전에서 흔한 배치 형태

그래서 MVC 구조에서는 JSP를 보통 이런 위치에 둔다.

/WEB-INF/views/...

그리고 Controller는 항상 이 경로로 forward 한다.

request.getRequestDispatcher("/WEB-INF/views/...").forward(...)

이 흐름이 “브라우저 → Controller → View” 구조를 안정적으로 만든다.

정리

WEB-INF는 브라우저에서 직접 접근할 수 없는 보호 영역이다
JSP를 WEB-INF 아래에 두면 JSP 직접 호출을 구조적으로 차단할 수 있다
결과적으로 브라우저는 반드시 Controller를 통해서만 화면을 보게 된다
URL은 Controller 기준으로 설계되고, JSP는 내부 구현으로 숨겨진다

[MVC와 웹 흐름 제어] 6.PRG 패턴: POST 후에는 왜 redirect를 하는가

sqaxe1 — Sun, 29 Mar 2026 21:56:25 +0900

등록/수정/삭제 같은 기능을 만들면 보통 POST 요청을 사용한다.
문제는 “POST 처리 후에 무엇을 응답으로 보여줄 것인가”이다.

초보 단계에서는 이런 흐름을 만들기 쉽다.

POST로 처리한다
처리 결과 화면을 바로 보여준다(HTML)

겉으로는 잘 동작한다.
하지만 브라우저의 “새로고침” 동작 때문에 구조적인 문제가 생긴다.

PRG가 없으면 발생하는 문제: POST 재전송

POST 처리 후에 결과 화면을 바로 응답하면,
브라우저 입장에서는 “현재 화면을 만든 마지막 요청”이 POST가 된다.

이 상태에서 사용자가 새로고침(F5)을 하면 브라우저는 보통 이렇게 행동한다.

마지막 요청이 POST였다
그 POST를 다시 보내서 현재 화면을 다시 만들려고 한다
그래서 “POST 재전송” 경고가 뜬다

이게 단순히 경고로 끝나면 괜찮은데, 실전에서는 문제가 된다.

게시글이 중복 등록될 수 있다
주문이 중복으로 생성될 수 있다
결제가 중복으로 시도될 수 있다

즉 “새로고침”이 치명적인 부작용을 만들 수 있다.

PRG는 이 문제를 구조로 해결한다

PRG는 Post-Redirect-Get의 약자이다.

흐름은 단순하다.

사용자는 POST로 처리를 요청한다
서버는 처리를 완료한 뒤 “다른 URL로 이동하라”는 redirect 응답을 보낸다
브라우저는 redirect를 따라 GET 요청을 새로 보낸다
최종 화면은 GET 응답으로 만들어진다

즉 화면을 결정하는 마지막 요청이 POST가 아니라 GET이 되게 만든다.

PRG의 핵심 효과: 새로고침이 안전해진다

PRG를 적용하면 마지막 화면은 GET의 결과이다.
그래서 사용자가 새로고침을 해도 GET이 다시 실행될 뿐이다.

GET은 조회 성격이므로 부작용이 적다
중복 등록/중복 결제 같은 위험을 크게 줄인다

즉 PRG는 “새로고침에 안전한 흐름”을 만드는 패턴이다.

코드로 보면 차이가 더 명확하다

나쁜 흐름(POST 후 결과 화면을 바로 보여줌)

POST 처리 후 forward로 JSP 결과 화면을 응답
마지막 요청이 POST가 되어서 새로고침 위험

좋은 흐름(PRG)

POST 처리 후 sendRedirect로 목록/상세 같은 GET URL로 이동
마지막 요청이 GET이 되어서 새로고침이 안전

이게 실무에서 “POST 처리 후 redirect”가 기본이 되는 이유이다.

정리

POST 응답으로 바로 화면을 만들면 새로고침 시 POST 재전송이 발생할 수 있다
PRG는 POST 이후 redirect를 통해 마지막 화면을 GET으로 만든다
PRG를 쓰면 새로고침이 안전해지고 중복 처리 위험이 줄어든다
그래서 등록/수정/삭제 같은 처리는 보통 PRG로 구성한다

[MVC와 웹 흐름 제어] 5. forward vs redirect: 언제 무엇을 써야 하는가

sqaxe1 — Sun, 29 Mar 2026 21:47:49 +0900

MVC에서 흐름 제어를 하다 보면 결국 매번 이 선택을 하게 된다.

forward로 JSP를 보여줄 것인가
redirect로 다른 URL로 이동시킬 것인가

둘의 차이를 정확히 잡아두면
“왜 PRG가 필요한지”, “왜 WEB-INF에 JSP를 두는지”도 자연스럽게 이해된다.

한 줄로 정리하면 이렇게 된다

forward: 서버 내부에서 같은 요청을 들고 View(JSP)로 넘긴다
redirect: 브라우저에게 새 요청을 보내게 해서 다른 URL로 이동시킨다

즉 핵심 차이는 “request가 유지되느냐, 끊기느냐”이다.

1) 이동 주체가 다르다

forward

서버 내부 이동이다.
컨트롤러가 RequestDispatcher로 JSP에게 처리를 넘긴다.

브라우저는 이 사실을 모른다.

redirect

브라우저 이동이다.
서버가 Location 헤더를 보내고, 브라우저가 그 주소로 다시 요청한다.

2) request/response의 연속성이 다르다

forward는 request/response가 유지된다

그래서 컨트롤러에서 request.setAttribute()로 담아둔 데이터가
JSP에서 그대로 보인다.

즉 “조회 화면 렌더링”에서 가장 자연스럽다.

redirect는 request/response가 끊긴다

브라우저가 새 요청을 보내므로 request/response는 새로 만들어진다.

그래서 컨트롤러에서 request에 담아둔 값은 redirect 이후에 사라진다.

redirect 후에 값을 넘기려면 다른 전략을 써야 한다.

쿼리 스트링으로 붙이기
세션에 저장하기
(프레임워크가 있으면) flash attribute 같은 임시 저장소 쓰기

3) 주소창(URL)이 다르다

forward는 URL이 안 바뀐다

서버 내부에서만 이동했기 때문이다.

사용자 입장에서는
“처리된 JSP 화면을 보고 있지만 주소는 여전히 컨트롤러 URL”인 상태가 된다.

redirect는 URL이 바뀐다

브라우저가 Location으로 새 요청을 보내기 때문이다.

사용자 입장에서는
“주소창이 실제 화면에 해당하는 URL로 바뀐 상태”가 된다.

4) 언제 무엇을 쓰는가 (실무 기준)

forward가 자연스러운 경우: 조회 화면

목록 조회 화면
상세 조회 화면
입력 폼 화면(GET)

즉 “화면을 만들어 보여주는 목적”일 때 forward가 기본이다.

redirect가 자연스러운 경우: 처리 후 이동

등록 처리(POST) 후 목록으로 이동
수정 처리(POST) 후 상세로 이동
삭제 처리(POST) 후 목록으로 이동

즉 “상태를 바꾸는 처리”를 하고 난 뒤에는 redirect가 기본이다.

이 패턴이 바로 PRG(Post-Redirect-Get)로 이어진다.

정리

forward: 서버 내부 이동, request 유지, URL 안 바뀜, setAttribute로 데이터 전달 가능
redirect: 브라우저 새 요청, request 끊김, URL 바뀜, setAttribute로 데이터 전달 불가
조회(화면 렌더링)는 forward가 자연스럽고
등록/수정/삭제 같은 처리 후에는 redirect가 자연스럽다

[MVC와 웹 흐름 제어] 4. redirect(sendRedirect)

sqaxe1 — Sun, 29 Mar 2026 20:20:29 +0900

“브라우저에게 새 요청을 시키는 방식”

forward는 서버 내부 이동이었다.
즉 같은 request/response를 들고 JSP로 넘기는 방식이었다.

redirect는 완전히 다르다.

redirect는 서버가 브라우저에게 “다른 곳으로 다시 요청하라”고 지시하는 방식이다

즉 redirect는 “서버 내부에서 처리 담당자를 바꾸는 것”이 아니라
“브라우저에게 새 요청을 유도하는 것”이다.

sendRedirect는 무엇을 하는가

컨트롤러에서 보통 이렇게 쓴다.

response.sendRedirect("/todo/list")

이 한 줄의 의미는 다음이다.

서버는 응답을 만들 때 Location 헤더를 포함해서 보낸다
브라우저는 이 응답을 받으면 화면을 그대로 유지하지 않는다
주소창을 Location 값으로 바꾸고, 그 주소로 새 요청을 보낸다

즉 redirect는 1번 요청으로 끝나는 게 아니라
“추가 요청”이 자동으로 발생하는 구조이다.

redirect의 가장 중요한 특징: request가 끊긴다

forward와 redirect의 가장 큰 차이는 request의 연속성이다.

forward: 같은 request/response 유지
redirect: 브라우저가 새 요청을 보내므로 request/response가 새로 만들어짐

그래서 redirect 이후에는 컨트롤러에서 request.setAttribute()로 담아둔 값이 유지되지 않는다.

왜냐하면 그 값은 “이전 요청”의 request scope에 있던 것이고,
redirect는 “새 요청”을 발생시키기 때문이다.

즉 다음은 성립하지 않는다.

POST 컨트롤러에서 req.setAttribute("msg","ok")
redirect 이후 JSP에서 ${msg} 출력

이건 request가 끊겨서 값이 사라진다.

(redirect 후에도 값을 넘기려면 쿼리 스트링, 세션, flash scope 같은 전략이 필요하다)

redirect는 언제 쓰는가

redirect는 보통 “처리 작업” 이후에 많이 쓴다.

예를 들어 이런 것들이다.

등록(POST) 처리 후 목록(GET)으로 이동
수정(POST) 처리 후 상세(GET)로 이동
삭제(POST) 처리 후 목록(GET)으로 이동

이 패턴이 중요한 이유는 다음 글에서 다룰 PRG(Post-Redirect-Get)로 이어진다.

redirect는 브라우저 입장에서 어떤 일이 일어나는가

redirect 응답을 받으면 브라우저는 이렇게 행동한다.

서버 응답에 Location이 있는지 확인한다
주소창을 Location 값으로 바꾼다
Location으로 새 요청을 보낸다(보통 GET)
새 응답을 받아서 화면을 만든다

그래서 redirect를 쓰면 사용자 입장에서는

주소창이 바뀐다
새로고침을 해도 “마지막이 GET”인 상태로 남기 쉬워진다

이 장점 때문에 처리 후 redirect가 자주 쓰인다.

핵심 정리

forward는 서버 내부 이동이다(request 유지, URL 안 바뀜)
redirect는 브라우저가 새 요청을 보내는 방식이다(request 끊김, URL 바뀜)
sendRedirect는 Location 헤더로 브라우저를 다른 URL로 이동시킨다
처리(POST) 후에는 redirect가 자주 쓰이고, 이는 PRG 패턴으로 이어진다

[MVC와 웹 흐름 제어] 3. RequestDispatcher와 forward

sqaxe1 — Sun, 29 Mar 2026 19:53:52 +0900

“같은 요청을 들고 JSP로 넘긴다”

MVC에서 Controller(서블릿)는 보통 두 가지 중 하나를 선택한다.

View(JSP)로 화면을 만들어서 응답한다
다른 URL로 이동시키도록 응답한다(redirect)

이 글에서는 먼저 MVC에서 가장 기본이 되는 방식인 forward부터 정리한다.

RequestDispatcher는 “요청을 다른 자원에게 넘기는 통로”이다

RequestDispatcher는 말 그대로 “배포/전달” 도구이다.

컨트롤러가 처리하던 요청을
JSP 같은 다른 자원에게 넘겨서 최종 응답을 만들게 한다.

컨트롤러 입장에서는 RequestDispatcher를 이렇게 얻는다.

request.getRequestDispatcher("JSP 경로")

그리고 forward로 넘긴다.

dispatcher.forward(request, response)

forward의 가장 중요한 특징: request/response가 그대로 유지된다

forward를 이해할 때 핵심은 이 한 줄이다.

forward는 같은 request/response를 들고 내부에서 이동한다

즉 브라우저는 forward가 일어난 걸 모른다.

브라우저가 새 요청을 보내는 게 아니다
서버 내부에서 “처리 담당자”만 바뀌는 것이다

그래서 다음이 성립한다.

컨트롤러가 request.setAttribute()로 담아둔 값이 JSP에서 그대로 보인다
request scope가 유지된다
주소창(URL)은 바뀌지 않는다

// ================================
// [forward 예시] Controller -> JSP로 "같은 요청"을 넘긴다
// - request.setAttribute로 모델을 담고
// - RequestDispatcher.forward로 JSP에게 요청 처리를 넘긴다
// ================================

@WebServlet("/user/profile")
public class ProfileController extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {

        // 1) 컨트롤러가 데이터(모델)를 준비한다
        String userName = "woojoo";
        int point = 1200;

        // 2) requestScope에 담는다 (forward로 넘어가면 JSP에서도 그대로 보인다)
        req.setAttribute("userName", userName);
        req.setAttribute("point", point);

        // 3) forward: 같은 request/response를 들고 JSP로 이동
        req.getRequestDispatcher("/WEB-INF/views/user/profile.jsp")
           .forward(req, resp);
    }
}

<!-- /WEB-INF/views/user/profile.jsp -->
<h1>Profile</h1>
<p>name = ${userName}</p>
<p>point = ${point}</p>

위 예제 코드에서 userName, point를 request에 담았기 때문에
JSP는 ${userName}, ${point}로 바로 출력할 수 있다.

forward는 왜 MVC에서 기본이 되는가

forward는 “화면 렌더링”에 최적화된 방식이다.

컨트롤러가 하는 일은 단순해진다.

요청 파라미터 처리/검증
서비스/DAO 호출
화면에 필요한 데이터 준비
request에 담기(setAttribute)
JSP로 forward

그리고 JSP는 화면 출력만 담당한다.

즉 역할 분리가 깔끔해진다.

forward vs include (거의 안 쓰는 이유까지)

RequestDispatcher에는 include()도 있다.

forward() : 지금까지 만든 응답을 무시하고 JSP 결과로 응답을 만든다
include() : 지금까지 만든 응답 + JSP 결과를 합쳐서 응답한다

실무에서는 대부분 forward만 쓴다.
include는 부분 화면 조합 같은 특수한 상황에서만 쓰는 편이다.

forward의 주의점: 응답을 이미 커밋하면 못 한다

forward는 “JSP가 최종 응답을 만들게 넘기는 것”이다.
그래서 컨트롤러가 response에 이미 많은 내용을 써버리면 문제가 된다.

즉 컨트롤러에서

response.getWriter()로 바디를 써버리거나
이미 응답이 커밋된 상태

라면 forward가 실패할 수 있다.

MVC에서는 그래서 컨트롤러가 response 바디를 직접 쓰는 일을 최소화한다.

핵심 정리

RequestDispatcher는 요청을 다른 자원(JSP 등)에게 넘기는 도구이다
forward는 서버 내부 이동이며 같은 request/response가 유지된다
request scope가 유지되므로 setAttribute로 전달한 데이터가 JSP에서 그대로 보인다
주소창 URL은 바뀌지 않는다
MVC에서 화면 렌더링은 forward가 기본이다

[MCV와 웹 흐름 제어] 2. MVC는 무엇이고 왜 나누는가?

sqaxe1 — Sun, 29 Mar 2026 17:51:37 +0900

앞 글에서 “JSP 단독 사용의 한계”를 봤다.
핵심은 한 가지였다.

화면(JSP) 안에 로직이 섞이기 시작하면 유지보수가 급격히 망가진다
JSP 파일 URL이 노출되면 URL이 구현에 종속된다
GET/POST 접근 제한 같은 흐름 제어가 구조적으로 어렵다

그래서 역할을 분리해야 한다.
이 역할 분리를 이름 붙인 게 MVC이다.

MVC는 “역할 분리” 구조이다

MVC는 Model-View-Controller의 약자이다.

Controller: 요청을 받고 처리하고 흐름을 제어한다
View: 화면을 출력한다
Model: 화면에 필요한 데이터(재료)이다

중요한 건 “정답 구조”가 아니라 “의도가 역할 분리”라는 점이다.

Controller: 요청 처리 + 흐름 제어

Controller는 브라우저가 보낸 request를 받아서 다음을 한다.

어떤 기능을 수행할지 결정한다(라우팅)
파라미터를 읽고 검증한다
서비스/DAO 같은 로직을 호출한다
결과 데이터를 준비한다
어떤 View로 보낼지 결정한다(forward/redirect)

즉 Controller는 “중앙 조정자”이다.

서블릿 기반 MVC에서는 보통 Controller가 서블릿이다.

View: 화면 출력에만 집중

View는 화면을 출력하는 역할이다.

HTML 구조를 만든다
EL/JSTL로 값을 출력하고 반복/조건을 처리한다
가능하면 로직은 넣지 않는다

서블릿 기반 MVC에서는 View가 보통 JSP이다.

즉 JSP는 “결과 화면”만 담당하고,
실제 처리는 Controller가 담당한다.

Model: View에 필요한 데이터(재료)

Model은 “DB 모델” 같은 좁은 의미로 오해하기 쉬운데,
여기서 말하는 Model은 단순하다.

View가 화면을 그리기 위해 필요한 데이터 묶음

컨트롤러가 만들어서 View에 전달하는 값들이다.

서블릿 MVC에서는 보통 이 전달이 request.setAttribute()로 이루어진다.

req.setAttribute("todos", todoList);

그리고 JSP에서는 `${todos}`로 바로 읽는다.

즉 request 영역이 Model 전달 통로 역할을 한다.

MVC 흐름을 한 번에 보면

서블릿 + JSP MVC의 전형적인 흐름은 이렇다.

브라우저가 Controller URL을 요청한다
Controller(서블릿)가 파라미터를 읽고 로직을 실행한다
Controller가 Model(데이터)을 준비한다
Controller가 request에 Model을 담는다(setAttribute)
Controller가 View(JSP)로 forward 한다
View(JSP)가 Model을 EL/JSTL로 출력한다
최종 HTML이 response로 브라우저에 전송된다

// ================================
// [MVC 기본 예시] Controller(서블릿)가 Model(데이터)을 준비해서 View(JSP)로 넘긴다
// - Controller: 요청 처리 + 흐름 제어
// - Model: 화면에 필요한 데이터
// - View: 화면 출력(JSP)
// ================================
@WebServlet("/todo/list")
public class TodoListController extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {

        // 1) Controller가 Model(데이터)을 준비한다
        List<Todo> todos = List.of(
                new Todo(1L, "study servlet", false),
                new Todo(2L, "write blog", true)
        );

        // 2) request에 담는다 (Model 전달)
        req.setAttribute("todos", todos);

        // 3) View로 forward 한다 (JSP가 화면을 만든다)
        req.getRequestDispatcher("/WEB-INF/views/todo/list.jsp")
           .forward(req, resp);
    }

    // 단순 예시용 DTO/VO 느낌의 클래스
    static class Todo {
        Long id;
        String title;
        boolean finished;

        Todo(Long id, String title, boolean finished) {
            this.id = id;
            this.title = title;
            this.finished = finished;
        }

        public String getTitle() { return title; }
        public boolean isFinished() { return finished; }
    }
}

MVC로 나누면 뭐가 좋아지는가

1) 유지보수가 쉬워진다

화면 변경은 JSP에서 한다
로직 변경은 Controller/Service에서 한다

서로의 수정이 서로를 덜 깨뜨린다.

2) URL이 “파일 경로”에 종속되지 않는다

브라우저는 JSP 파일이 아니라 Controller URL만 호출한다.
JSP는 WEB-INF 아래로 숨겨서 직접 접근을 막는다.

즉 내부 구현(JSP 파일 구조)이 바뀌어도
외부 URL은 유지할 수 있다.

3) 흐름 제어가 가능해진다

이 요청은 GET만 허용한다
처리 후에는 redirect로 이동시킨다(PRG)
권한 없으면 로그인으로 보낸다

이런 제어가 Controller에서 일관되게 가능해진다.

핵심 정리

MVC는 역할 분리를 위한 구조이다
Controller는 요청 처리와 흐름 제어를 담당한다
View는 화면 출력만 담당한다(JSP)
Model은 View가 필요로 하는 데이터이다
서블릿 MVC에서는 request.setAttribute가 Model 전달 통로가 된다

다음 글에서는 Controller가 View로 넘길 때 사용하는 핵심 도구인
RequestDispatcher와 forward()를 코드로 정리한다.