Parameter와 Attribute의 차이

1. Parameter (파라미터)

Parameter는 클라이언트가 서버로 보낸 요청의 데이터를 포함하는 값입니다. 예를 들어, HTML 폼 데이터, 쿼리 문자열, URL 매개변수 등이 이에 해당합니다. 주로 String 타입으로 다루며, 사용자가 입력한 값을 서버에서 읽어올 때 사용합니다.

• 저장 위치: 클라이언트가 요청 시 보내는 데이터로, 주로 URL 쿼리 문자열이나 POST 폼 데이터로 전달됩니다.
• 주요 메서드:
  • getParameter(String name): 지정한 이름의 요청 파라미터 값을 String으로 반환합니다.
  • getParameterValues(String name): 동일한 이름을 가진 여러 요청 파라미터의 값을 String[] 배열로 반환합니다. (예: 체크박스)

예시

클라이언트가 login.jsp?username=johndoe&password=1234 같은 URL로 요청할 때, username과 password는 요청 파라미터가 됩니다.

String username = request.getParameter("username");
String password = request.getParameter("password");

• 여기서 username과 password는 클라이언트가 보낸 값이며, request.getParameter()를 통해 String으로 읽어올 수 있습니다.

2. Attribute (속성)

Attribute는 서버에서 요청(request) 객체에 추가하는 데이터입니다. 주로 서블릿과 JSP 간의 데이터 전달에 사용됩니다. Attribute는 객체(Object) 형태로 저장되며, 서버에서 요청 처리 중 필요한 데이터를 공유하는 용도로 사용됩니다. 클라이언트가 직접 접근하거나 변경할 수 없고, 서버 내에서만 유효합니다.

• 저장 위치: 서버에서 설정하는 값으로, 주로 서블릿에서 JSP로 데이터를 전달할 때 사용합니다.
• 주요 메서드:
  • setAttribute(String name, Object value): 지정한 이름으로 객체를 속성으로 저장합니다.
  • getAttribute(String name): 지정한 이름의 속성 값을 반환합니다.
  • removeAttribute(String name): 지정한 이름의 속성을 제거합니다.

예시

서블릿에서 데이터를 JSP로 전달할 때 Attribute를 사용합니다. 예를 들어, 사용자의 이름과 같은 데이터를 JSP로 넘겨야 할 때 Attribute에 저장하여 전달합니다.

// 서블릿에서 설정
request.setAttribute("username", "John Doe");

// JSP에서 접근
String username = (String) request.getAttribute("username");

이 경우, username이라는 속성은 서블릿에서 JSP로 전달되어 JSP에서 사용할 수 있습니다. 클라이언트는 이 데이터를 직접 변경할 수 없으며, 서버 측에서만 유지됩니다.

Parameter와 Attribute의 용도 비교

1. Parameter는 클라이언트가 전송한 데이터를 읽는 데 사용됩니다.
   • 예: 로그인 폼의 사용자명과 비밀번호를 읽어와 인증 처리
2. Attribute는 서버 내부에서 데이터를 공유하거나 전달하는 데 사용됩니다.
   • 예: 서블릿에서 처리한 결과 데이터를 JSP로 전달하여 클라이언트에게 표시

요약

• Parameter: 클라이언트 요청 시 보내는 데이터. getParameter()로 문자열 값을 읽습니다.
• Attribute: 서버에서 추가한 데이터로, 요청 처리 중 서버 내에서 데이터 전달에 사용. setAttribute()와 getAttribute()로 객체를 저장하고 읽어옵니다.

이처럼 Parameter는 클라이언트가 보낸 값을 읽을 때, Attribute는 서버에서 요청 처리 중 데이터를 전달할 때 사용하여 요청의 성격에 맞게 데이터를 다루는 것이 중요합니다.

1. HttpServletRequest - 클라이언트 요청 정보

HttpServletRequest 객체는 클라이언트가 서버에 전송한 HTTP 요청 정보를 포함하고 있습니다. 클라이언트가 전송한 요청의 메타데이터와 데이터(쿼리 파라미터, 헤더, 쿠키, 세션 정보 등)에 접근할 수 있도록 다양한 메서드를 제공합니다.

주요 메서드

1. getParameter(String name):
   • 클라이언트가 전송한 요청 파라미터를 가져옵니다. 폼 데이터와 쿼리 문자열을 읽을 때 주로 사용됩니다.
   • 예: request.getParameter("username")
2. getParameterValues(String name):
   • 동일한 이름을 가진 여러 파라미터의 값을 배열 형태로 가져옵니다. 예를 들어, 체크박스와 같이 여러 값을 선택할 수 있는 요소에서 유용합니다.
   • 예: request.getParameterValues("hobbies")
3. getMethod():
   • 요청의 HTTP 메서드(GET, POST 등)를 반환합니다.
   • 예: request.getMethod()
4. getRequestURI():
   • 클라이언트가 요청한 URI를 반환합니다.
   • 예: request.getRequestURI()
5. getHeader(String name):
   • 요청 헤더의 값을 가져옵니다. 예를 들어, User-Agent 헤더를 통해 클라이언트의 브라우저 정보를 얻을 수 있습니다.
   • 예: request.getHeader("User-Agent")
6. getSession():
   • 현재 요청과 관련된 세션 객체를 반환합니다. 세션을 통해 사용자의 상태를 유지할 수 있습니다.
   • 예: request.getSession()
7. getRemoteAddr():
   • 클라이언트의 IP 주소를 반환합니다.
   • 예: request.getRemoteAddr()

예시

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String username = request.getParameter("username");
    String userAgent = request.getHeader("User-Agent");
    String requestURI = request.getRequestURI();

    System.out.println("사용자 이름: " + username);
    System.out.println("User-Agent: " + userAgent);
    System.out.println("Request URI: " + requestURI);
}

2. HttpServletResponse - 서버 응답 정보

HttpServletResponse 객체는 서버가 클라이언트로 전송할 HTTP 응답을 구성하는 데 필요한 정보를 제공합니다. 이 객체를 통해 응답 헤더, 상태 코드, 컨텐츠 유형 등을 설정하고, 최종적으로 클라이언트에게 데이터를 보낼 수 있습니다.

주요 메서드

1. setContentType(String type):
   • 응답의 컨텐츠 유형(Content-Type)을 설정합니다. 예를 들어, text/html, application/json 등을 지정할 수 있습니다.
   • 예: response.setContentType("text/html;charset=UTF-8");
2. setCharacterEncoding(String charset):
   • 응답의 문자 인코딩을 설정합니다. 주로 UTF-8로 설정하여 다국어 지원을 합니다.
   • 예: response.setCharacterEncoding("UTF-8");
3. setStatus(int statusCode):
   • 응답 상태 코드를 설정합니다. 예를 들어, 200(성공), 404(찾을 수 없음), 500(서버 오류) 등의 상태 코드를 지정할 수 있습니다.
   • 예: response.setStatus(HttpServletResponse.SC_OK);
4. getWriter():
   • 출력 스트림을 반환하여, 클라이언트에게 텍스트 데이터를 보낼 수 있도록 합니다. 주로 HTML이나 JSON을 작성할 때 사용됩니다.
   • 예: PrintWriter out = response.getWriter(); out.println("<h1>Hello, World!</h1>");
5. sendRedirect(String location):
   • 클라이언트를 다른 URL로 리다이렉트합니다. 주로 로그인 성공 후 특정 페이지로 이동할 때 사용됩니다.
   • 예: response.sendRedirect("/home");
6. addCookie(Cookie cookie):
   • 클라이언트에게 쿠키를 전송합니다. 이를 통해 사용자 세션을 유지하거나 사용자 맞춤 설정을 제공합니다.
   • 예: response.addCookie(new Cookie("user", "JohnDoe"));

예시

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    response.setContentType("text/html;charset=UTF-8");
    response.setStatus(HttpServletResponse.SC_OK);

    PrintWriter out = response.getWriter();
    out.println("<html><body>");
    out.println("<h1>Hello, this is the server's response!</h1>");
    out.println("</body></html>");
}

HttpServletRequest와 HttpServletResponse의 활용 예

다음은 사용자로부터 요청을 받아 처리하고 응답을 생성하는 간단한 예제입니다.

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

import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/greet")
public class GreetServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 요청 파라미터에서 이름 가져오기
        String name = request.getParameter("name");

        // 응답 설정
        response.setContentType("text/html;charset=UTF-8");

        // 응답 출력
        PrintWriter out = response.getWriter();
        out.println("<html><body>");
        if (name != null && !name.isEmpty()) {
            out.println("<h1>안녕하세요, " + name + "님!</h1>");
        } else {
            out.println("<h1>안녕하세요, 방문자님!</h1>");
        }
        out.println("</body></html>");
    }
}

• HttpServletRequest: request.getParameter("name")을 통해 클라이언트가 입력한 이름을 가져옵니다.
• HttpServletResponse: response.setContentType("text/html;charset=UTF-8");로 응답 유형과 인코딩을 설정하고, PrintWriter를 통해 HTML 응답을 출력합니다.

요약

• HttpServletRequest는 클라이언트의 요청 정보를 처리하며, URL, HTTP 메서드, 파라미터, 헤더 정보, 쿠키 등 요청과 관련된 다양한 메서드를 제공합니다.
• HttpServletResponse는 서버의 응답을 구성하며, 컨텐츠 유형, 상태 코드, 리다이렉트, 쿠키 등 응답과 관련된 여러 메서드를 통해 클라이언트에게 응답을 보낼 수 있습니다.

이 두 객체는 서블릿에서 요청과 응답을 처리하는 기본적인 도구로, HTTP 통신을 통해 클라이언트와 서버 간에 데이터를 주고받는 데 중요한 역할을 합니다.

MVC Model 2의 주요 구성 요소

1. Model (모델):
   • 비즈니스 로직과 데이터베이스와의 상호작용을 담당합니다.
   • DAO(Data Access Object)와 DTO(Data Transfer Object)를 사용하여 데이터를 관리합니다.
   • 서블릿이 처리한 데이터는 모델을 통해 JSP에 전달됩니다.
2. View (뷰):
   • 클라이언트에게 보여질 화면을 담당하는 부분으로, JSP가 주로 이 역할을 수행합니다.
   • 화면에 표시할 데이터를 모델로부터 받아와 사용자에게 전달합니다.
   • 비즈니스 로직은 포함하지 않고, 데이터 표시와 UI만을 담당합니다.
3. Controller (컨트롤러):
   • 클라이언트의 요청을 받아서 어떤 작업을 수행할지 결정하고, 필요한 데이터를 준비한 뒤 적절한 뷰로 데이터를 전달합니다.
   • 서블릿이 컨트롤러 역할을 수행하며, 요청을 받고 모델과 뷰 간의 흐름을 제어합니다.
   • 컨트롤러는 사용자 요청을 해석하고, 비즈니스 로직을 처리하며, 최종적으로 데이터를 뷰에 전달하는 책임을 가집니다.

MVC Model 2의 흐름

1. 클라이언트의 요청: 사용자가 웹 브라우저에서 특정 URL을 통해 요청을 보내면, 이 요청이 컨트롤러(서블릿)로 전달됩니다.
2. 컨트롤러의 요청 처리: 컨트롤러는 요청을 해석하고, 필요한 경우 모델(비즈니스 로직 또는 데이터베이스 작업)을 통해 데이터를 처리합니다.
3. 뷰 선택 및 데이터 전달: 컨트롤러는 요청 처리 후, 결과 데이터를 뷰(JSP)에 전달하고, 클라이언트에게 보여질 페이지를 결정합니다.
4. 응답 생성 및 반환: JSP 뷰는 전달받은 데이터를 사용자에게 보여줄 HTML 페이지로 렌더링하여 클라이언트에게 반환합니다.

MVC Model 2 간단 예제

아래는 간단한 게시판 예제로, 게시글 리스트를 조회하는 흐름을 통해 MVC Model 2의 구조를 이해해 보겠습니다.

구성 파일

1. BoardDTO.java - 게시글 데이터를 저장하는 데이터 전송 객체.
2. BoardDAO.java - 데이터베이스와 연결하여 게시글을 조회하는 데이터 접근 객체.
3. BoardListServlet.java - 클라이언트 요청을 처리하고 뷰로 데이터를 전달하는 컨트롤러.
4. boardList.jsp - 클라이언트에게 게시글 목록을 보여주는 뷰.

1. BoardDTO.java (Model)

public class BoardDTO {
    private int id;
    private String title;
    private String content;

    // 기본 생성자 및 getter, setter
    public int getId() { return id; }
    public void setId(int id) { this.id = id; }
    public String getTitle() { return title; }
    public void setTitle(String title) { this.title = title; }
    public String getContent() { return content; }
    public void setContent(String content) { this.content = content; }
}

• BoardDTO는 게시글 데이터를 저장하는 객체로, 데이터베이스에서 조회한 데이터를 JSP로 전달할 때 사용됩니다.

2. BoardDAO.java (Model)

import java.sql.*;
import java.util.ArrayList;
import java.util.List;

public class BoardDAO {
    public List<BoardDTO> getAllPosts() throws Exception {
        List<BoardDTO> postList = new ArrayList<>();
        Connection conn = null;

        try {
            conn = DriverManager.getConnection("jdbc:mariadb://localhost:3306/boarddb", "root", "password");
            String sql = "SELECT * FROM board ORDER BY id DESC";
            PreparedStatement pstmt = conn.prepareStatement(sql);
            ResultSet rs = pstmt.executeQuery();

            while (rs.next()) {
                BoardDTO post = new BoardDTO();
                post.setId(rs.getInt("id"));
                post.setTitle(rs.getString("title"));
                post.setContent(rs.getString("content"));
                postList.add(post);
            }
        } finally {
            if (conn != null) conn.close();
        }
        return postList;
    }
}

• BoardDAO는 데이터베이스에서 모든 게시글을 조회하여 BoardDTO 리스트로 반환합니다.

3. BoardListServlet.java (Controller)

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

import java.io.IOException;
import java.util.List;

@WebServlet("/board/list")
public class BoardListServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        BoardDAO dao = new BoardDAO();
        try {
            List<BoardDTO> postList = dao.getAllPosts(); // 데이터 조회
            request.setAttribute("postList", postList); // 데이터 뷰로 전달
            request.getRequestDispatcher("/WEB-INF/views/boardList.jsp").forward(request, response);
        } catch (Exception e) {
            throw new ServletException(e);
        }
    }
}

• BoardListServlet은 /board/list URL 요청을 처리하는 서블릿으로, 게시글 리스트를 가져와 boardList.jsp로 전달합니다.
• request.setAttribute 메서드를 통해 게시글 데이터를 뷰에 전달하고, RequestDispatcher를 사용해 boardList.jsp로 포워딩합니다.

4. boardList.jsp (View)

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <title>게시글 목록</title>
</head>
<body>
    <h2>게시글 목록</h2>
    <table border="1">
        <tr>
            <th>번호</th>
            <th>제목</th>
            <th>내용</th>
        </tr>
        <c:forEach var="post" items="${postList}">
            <tr>
                <td>${post.id}</td>
                <td>${post.title}</td>
                <td>${post.content}</td>
            </tr>
        </c:forEach>
    </table>
</body>
</html>

• boardList.jsp는 서블릿에서 전달받은 postList 데이터를 출력하는 역할을 합니다.
• 게시글의 각 항목은 <c:forEach> 태그를 사용해 테이블 형식으로 화면에 표시됩니다.

MVC Model 2의 장단점

장점

1. 유지보수성 향상: 비즈니스 로직, 데이터, 프레젠테이션이 각각 Controller, Model, View로 나뉘어 있어 유지보수가 용이합니다.
2. 재사용성 증가: Model, View, Controller의 역할이 분리되어 재사용성이 높습니다.
3. 코드의 가독성 증가: 역할이 명확히 나누어져 있어 코드를 쉽게 이해할 수 있습니다.

단점

1. 구현 복잡도 증가: 각 부분이 독립적으로 분리되므로 구조가 복잡해질 수 있습니다.
2. 작은 프로젝트에는 비효율적: 구조가 분리되기 때문에, 간단한 웹 애플리케이션에서는 구현이 비효율적일 수 있습니다.

요약

• MVC Model 2는 JSP와 서블릿을 기반으로 하는 구조로, 모델, 뷰, 컨트롤러를 분리하여 역할을 명확히 하고 유지보수성을 높입니다.
• Controller(서블릿)는 클라이언트 요청을 처리하고, Model(DAO, DTO)은 데이터 처리를 담당하며, View(JSP)는 사용자에게 화면을 출력합니다.
• 이 구조는 대규모 애플리케이션에서 관리와 확장이 용이하며, Java 웹 애플리케이션 개발에서 널리 사용되는 패턴입니다.

@WebServlet 애너테이션의 기본 사용법

@WebServlet 애너테이션을 통해 서블릿의 URL 패턴을 지정할 수 있습니다. 애너테이션은 서블릿 클래스 위에 추가하며, web.xml에 별도로 서블릿을 등록할 필요 없이 자동으로 매핑됩니다.

기본 예제

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

import java.io.IOException;

@WebServlet("/hello")  // 서블릿 URL 매핑 설정
public class HelloServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.setContentType("text/html;charset=UTF-8");
        resp.getWriter().write("<h1>Hello, Servlet with Annotation!</h1>");
    }
}

• @WebServlet("/hello"): /hello 경로로 요청이 오면 HelloServlet이 실행되도록 설정합니다.
• 서블릿 컨테이너는 애너테이션을 통해 web.xml 파일 없이도 서블릿을 인식하고, 매핑 설정을 자동으로 처리합니다.

@WebServlet 애너테이션의 주요 속성

@WebServlet 애너테이션은 다양한 속성을 통해 서블릿의 동작을 세부적으로 설정할 수 있습니다.

1. value 또는 urlPatterns: 서블릿이 매핑될 URL 패턴을 지정합니다.

    @WebServlet(value = "/hello")  // 단일 URL 패턴
    @WebServlet(urlPatterns = {"/hello", "/greet"})  // 여러 URL 패턴

2. name: 서블릿 이름을 지정합니다. 기본값은 클래스 이름이 사용됩니다.

    @WebServlet(name = "HelloServlet", urlPatterns = "/hello")

3. loadOnStartup: 서블릿의 로드 우선순위를 설정합니다. 값이 0 이상이면 서버 시작 시 서블릿이 로드됩니다.

    @WebServlet(urlPatterns = "/hello", loadOnStartup = 1)

4. initParams: 서블릿에 초기화 매개변수를 전달합니다. 여러 매개변수를 설정할 수 있습니다.

    @WebServlet(urlPatterns = "/hello", initParams = {
        @WebInitParam(name = "param1", value = "value1"),
        @WebInitParam(name = "param2", value = "value2")
    })

애너테이션 방식과 web.xml 방식의 차이점

언제 애너테이션을 사용하고, 언제 web.xml을 사용할까?

1. 애너테이션 사용 시기:
   • 서블릿, 필터, 리스너의 설정이 단순할 때.
   • 소규모 애플리케이션에서, 설정이 복잡하지 않고 코드와 설정이 함께 있으면 더 직관적일 때.
   • 빠르게 프로토타입을 개발하거나 테스트하는 경우.
2. web.xml 사용 시기:
   • 복잡한 설정이 필요한 경우(예: 여러 URL 패턴, 보안 설정, 필터 체인 설정 등).
   • 설정 파일을 따로 관리하여 설정의 유연성과 유지보수성을 높여야 하는 경우.
   • 환경마다 설정이 달라질 수 있는 대규모 애플리케이션에서, 배포 환경에 따라 설정을 쉽게 변경할 수 있어야 하는 경우.

애너테이션과 web.xml 혼합 사용

애너테이션과 web.xml을 함께 사용할 수도 있습니다. 예를 들어, 주로 간단한 서블릿 매핑은 애너테이션을 사용하고, 복잡한 필터와 리스너 설정이나 환경별 설정이 필요한 경우에는 web.xml을 사용하는 방식으로 혼합 사용이 가능합니다.

요약

• @WebServlet 애너테이션은 서블릿 매핑을 간단하고 직관적으로 설정할 수 있는 방법입니다.
• 코드와 설정을 한 곳에서 관리할 수 있어, 소규모 프로젝트나 간단한 서블릿 매핑에는 애너테이션이 유리합니다.
• web.xml은 복잡한 설정이 필요한 경우에 유리하며, 보안 설정, 필터, 리스너 등 전체 애플리케이션 설정이 필요한 경우 여전히 중요한 역할을 합니다.
• 두 방식을 혼합하여 사용하는 것도 가능하며, 애플리케이션의 요구 사항에 따라 유연하게 선택할 수 있습니다.

web.xml의 주요 역할

1. 서블릿 매핑: 서블릿 클래스와 URL 경로를 연결하여 특정 URL 요청이 들어올 때 해당 서블릿이 실행되도록 합니다.
2. 필터와 리스너 설정: 요청 전/후 작업을 처리하는 필터와 애플리케이션 상태 변화에 대한 이벤트 처리를 담당하는 리스너를 설정할 수 있습니다.
3. 초기화 매개변수 설정: 애플리케이션과 서블릿에 필요한 초기 매개변수를 설정할 수 있습니다.
4. 보안 설정: 보안 설정을 통해 특정 URL에 접근 권한을 부여하거나, 인증을 적용할 수 있습니다.

기본 web.xml 구조

web.xml 파일은 WEB-INF 폴더에 위치하며, 웹 애플리케이션의 설정을 XML 형식으로 정의합니다.

<web-app xmlns="<http://xmlns.jcp.org/xml/ns/javaee>"
         xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xsi:schemaLocation="<http://xmlns.jcp.org/xml/ns/javaee>
                             <http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd>"
         version="3.1">

    <!-- 서블릿 설정 -->
    <servlet>
        <servlet-name>HelloServlet</servlet-name>
        <servlet-class>com.example.HelloServlet</servlet-class>
    </servlet>

    <!-- 서블릿 매핑 설정 -->
    <servlet-mapping>
        <servlet-name>HelloServlet</servlet-name>
        <url-pattern>/hello</url-pattern>
    </servlet-mapping>

    <!-- 초기화 매개변수 설정 (필요시 추가) -->
    <context-param>
        <param-name>configLocation</param-name>
        <param-value>/WEB-INF/config.properties</param-value>
    </context-param>

</web-app>

web.xml의 주요 구성 요소

1. : 서블릿 클래스를 정의합니다. 서블릿 이름과 클래스 경로를 설정합니다.
   • <servlet-name>: 서블릿의 이름을 지정합니다. <servlet-mapping>과 연결됩니다.
   • <servlet-class>: 서블릿 클래스의 전체 경로를 지정합니다.
2. : 특정 URL 요청이 해당 서블릿으로 매핑되도록 설정합니다.
   • <servlet-name>: 요청을 처리할 서블릿의 이름을 지정합니다. <servlet>의 servlet-name과 일치해야 합니다.
   • <url-pattern>: 서블릿과 연결할 URL 패턴을 지정합니다. 예를 들어, /hello 경로에 매핑하여 http://localhost:8080/프로젝트명/hello로 요청이 들어오면 HelloServlet이 실행됩니다.
3. : 웹 애플리케이션 전체에서 사용할 수 있는 전역 매개변수를 정의합니다.
   • <param-name>과 <param-value>를 통해 전역적으로 필요한 설정 값을 지정할 수 있습니다. 예: 설정 파일 경로.
4. : 특정 서블릿에 대한 초기화 매개변수를 설정합니다.
   • <servlet> 태그 내부에서 설정하여 특정 서블릿에만 적용되는 초기 설정 값을 지정할 수 있습니다.

web.xml을 사용한 서블릿 설정 예제

HelloServlet 서블릿을 web.xml에 설정

<web-app xmlns="<http://xmlns.jcp.org/xml/ns/javaee>"
         xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xsi:schemaLocation="<http://xmlns.jcp.org/xml/ns/javaee>
                             <http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd>"
         version="3.1">

    <!-- HelloServlet 서블릿 설정 -->
    <servlet>
        <servlet-name>HelloServlet</servlet-name>
        <servlet-class>com.example.HelloServlet</servlet-class>
    </servlet>

    <!-- HelloServlet 매핑 설정 -->
    <servlet-mapping>
        <servlet-name>HelloServlet</servlet-name>
        <url-pattern>/hello</url-pattern>
    </servlet-mapping>
</web-app>

• HelloServlet 서블릿 설정: servlet-name과 servlet-class를 사용하여 서블릿 이름과 클래스를 지정합니다.
• 서블릿 매핑 설정: url-pattern을 /hello로 지정하여 클라이언트가 /hello로 요청하면 HelloServlet이 실행되도록 설정합니다.

추가 기능

1. 초기화 매개변수 설정 (서블릿에 대한 init-param)

서블릿에 특정 초기 설정 값을 전달하려면 <init-param> 태그를 사용할 수 있습니다. 예를 들어, message라는 초기 매개변수를 설정할 수 있습니다.

<servlet>
    <servlet-name>HelloServlet</servlet-name>
    <servlet-class>com.example.HelloServlet</servlet-class>
    <init-param>
        <param-name>message</param-name>
        <param-value>Hello from init-param!</param-value>
    </init-param>
</servlet>

• 이 초기화 매개변수는 HelloServlet 내에서 getServletConfig().getInitParameter("message")로 접근할 수 있습니다.

2. 필터 설정

필터는 요청과 응답의 전후에 처리할 작업을 수행할 수 있게 해줍니다. 예를 들어, 요청 로깅, 응답 압축, 인증 등을 수행할 수 있습니다.

<filter>
    <filter-name>LoggingFilter</filter-name>
    <filter-class>com.example.LoggingFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>LoggingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

• LoggingFilter라는 필터를 설정하고, 모든 URL 패턴 (/*)에 대해 요청을 가로채서 필터가 처리하도록 설정합니다.

3. 리스너 설정

리스너는 웹 애플리케이션의 상태 변화를 감지하고 처리할 수 있습니다. 예를 들어, 애플리케이션 시작 시 초기화 작업을 수행하는 리스너를 추가할 수 있습니다.

<listener>
    <listener-class>com.example.AppListener</listener-class>
</listener>

• AppListener 클래스는 ServletContextListener를 구현하여, 애플리케이션 시작과 종료 시 특정 작업을 수행할 수 있습니다.

요약

• web.xml은 서블릿 매핑, 초기화 매개변수, 필터, 리스너 등을 설정하여 웹 애플리케이션의 전반적인 동작을 정의하는 역할을 합니다.
• *와 을 통해 서블릿 클래스를 정의하고, 요청이 들어올 URL 패턴과 연결하여 특정 요청이 어떤 서블릿에서 처리될지 설정합니다.
• *과 을 사용하여 전역 및 서블릿에 대한 초기화 설정을 적용할 수 있습니다.

web.xml은 특히 대규모 애플리케이션에서 구조적 설정을 관리하는 데 유용하며, 서블릿의 동작과 웹 애플리케이션 전반의 설정을 한 곳에서 관리할 수 있게 해줍니다.

DTO (Data Transfer Object) - 데이터 전송 객체

DTO는 Data Transfer Object의 약자로, 데이터를 운반하는 역할을 하는 객체입니다. DTO는 주로 여러 계층(예: 데이터베이스, 서비스, 웹 등) 간에 데이터를 전달할 때 사용됩니다.

DTO의 주요 특징

• 순수한 데이터만 저장: DTO에는 오직 데이터와 그에 해당하는 getter/setter 메서드만 존재합니다.
• 비즈니스 로직 없음: 계산이나 처리 등의 복잡한 로직은 포함하지 않으며, 단순히 데이터를 담고 전달하는 역할만 합니다.
• 데이터 구조를 정의: 각 필드는 데이터베이스의 컬럼이나 비즈니스 로직에서 필요로 하는 데이터와 매핑됩니다.

DTO 예시 - UserDTO

예를 들어, User 정보(아이디, 이름, 이메일 등)를 담아 전달하는 UserDTO 클래스는 다음과 같습니다.

public class UserDTO {
    private int userId;
    private String username;
    private String email;

    // 기본 생성자
    public UserDTO() {}

    // getter와 setter
    public int getUserId() {
        return userId;
    }

    public void setUserId(int userId) {
        this.userId = userId;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

• 필드: userId, username, email 필드가 있으며, 이는 데이터베이스나 애플리케이션에서 필요로 하는 사용자 정보를 담습니다.
• getter/setter: 각 필드에 대한 getter와 setter 메서드를 통해 데이터를 주고받습니다.

이렇게 DTO를 통해 데이터를 주고받으면, 서비스 계층이나 다른 클래스에서 데이터를 쉽게 주고받을 수 있습니다.

2. DAO (Data Access Object) - 데이터 접근 객체

DAO는 Data Access Object의 약자로, 데이터베이스와의 상호작용을 담당하는 객체입니다. 주로 데이터베이스에 접근하여 데이터를 저장하거나 조회, 수정, 삭제하는 역할을 수행합니다.

DAO의 주요 특징

• 데이터베이스 작업 전담: 데이터베이스와의 연결, SQL 실행 등을 처리합니다.
• CRUD 작업 담당: Create(생성), Read(조회), Update(수정), Delete(삭제) 작업을 수행하는 메서드를 포함합니다.
• DTO와 함께 사용: DAO는 주로 DTO와 함께 사용하여, 데이터베이스로부터 조회한 데이터를 DTO에 담아 반환하거나, DTO에 담긴 데이터를 받아 저장합니다.

DAO 예시 - UserDAO

다음은 UserDAO 클래스에서 UserDTO 객체를 활용하여 데이터베이스에서 사용자 정보를 조회, 삽입하는 예시입니다.

import java.sql.*;
import java.util.ArrayList;
import java.util.List;

public class UserDAO {
    private Connection conn;

    // 데이터베이스 연결 메서드
    private Connection getConnection() throws Exception {
        String url = "jdbc:mariadb://localhost:3306/mydatabase";
        String username = "root";
        String password = "password";
        conn = DriverManager.getConnection(url, username, password);
        return conn;
    }

    // 사용자 추가
    public void addUser(UserDTO user) throws Exception {
        try {
            conn = getConnection();
            String sql = "INSERT INTO users (user_id, username, email) VALUES (?, ?, ?)";
            PreparedStatement pstmt = conn.prepareStatement(sql);
            pstmt.setInt(1, user.getUserId());
            pstmt.setString(2, user.getUsername());
            pstmt.setString(3, user.getEmail());
            pstmt.executeUpdate();
        } finally {
            if (conn != null) conn.close();
        }
    }

    // 모든 사용자 조회
    public List<UserDTO> getAllUsers() throws Exception {
        List<UserDTO> userList = new ArrayList<>();
        try {
            conn = getConnection();
            String sql = "SELECT * FROM users";
            PreparedStatement pstmt = conn.prepareStatement(sql);
            ResultSet rs = pstmt.executeQuery();

            while (rs.next()) {
                UserDTO user = new UserDTO();
                user.setUserId(rs.getInt("user_id"));
                user.setUsername(rs.getString("username"));
                user.setEmail(rs.getString("email"));
                userList.add(user);
            }
        } finally {
            if (conn != null) conn.close();
        }
        return userList;
    }
}

• getConnection 메서드: 데이터베이스에 연결합니다.
• addUser 메서드: UserDTO 객체를 인자로 받아 데이터베이스에 사용자 정보를 삽입합니다.
• getAllUsers 메서드: 데이터베이스에서 모든 사용자 정보를 조회하고, 각 사용자 정보를 UserDTO 객체에 담아 리스트로 반환합니다.

이렇게 DAO는 데이터베이스와의 직접적인 상호작용을 처리하여, 다른 클래스에서 데이터베이스와의 의존성을 줄일 수 있습니다.

DAO와 DTO의 역할 요약

예제 흐름

1. 데이터베이스에 접근할 필요가 있는 서비스나 JSP 페이지에서 UserDAO의 메서드를 호출합니다.
2. UserDAO는 데이터베이스에 연결하고, 데이터 조회나 삽입 작업을 수행합니다.
3. UserDTO 객체를 통해 데이터를 DAO와 서비스, JSP 페이지 간에 주고받습니다.

@Slf4j는 Lombok에서 제공하는 애너테이션으로, 클래스에 Logger 객체를 자동으로 생성해주는 역할을 합니다. 이 애너테이션을 사용하면 코드에서 Logger 객체를 생성하는 번거로움을 줄이고 간결하게 로그를 처리할 수 있습니다.

Slf4j와 Logging의 개념 이해

1. Slf4j란?

Slf4j(Simple Logging Facade for Java)는 Java의 로깅 프레임워크를 통합하기 위한 추상화 계층입니다.

Slf4j 자체는 로깅을 처리하지 않고, 실제 로깅 구현체(e.g., Logback, Log4j)를 연결하여 사용합니다.

장점: Slf4j를 사용하면 로깅 구현체를 변경하더라도 코드 수정 없이 설정만으로 변경이 가능합니다.

2. 로깅이란?

로깅은 애플리케이션의 실행 과정 중 중요한 정보를 기록하는 작업입니다.

• 왜 로깅이 필요한가?
  • 디버깅과 문제 해결: 오류 발생 시 원인 파악 가능.
  • 시스템 분석: 실행 흐름과 성능을 분석.
  • 모니터링: 애플리케이션 상태와 동작 확인.

@Slf4j의 사용 방식

1. Logger 수동 생성 방식 일반적으로 Logger를 직접 생성하려면 아래와 같은 코드를 작성해야 합니다.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Example {
    private static final Logger log = LoggerFactory.getLogger(Example.class);

    public void doSomething() {
        log.info("This is an info log");
        log.error("This is an error log");
    }
}

1. @Slf4j 애너테이션 사용 방식@Slf4j를 사용하면 Lombok이 Logger 객체를 자동으로 생성합니다.

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class Example {

    public void doSomething() {
        log.info("This is an info log");
        log.error("This is an error log");
    }
}

자동 생성된 Logger 필드: private static final org.slf4j.Logger log

Slf4j 로그 레벨

Slf4j를 통해 다양한 로그 레벨로 메시지를 기록할 수 있습니다.

Slf4j와 @Slf4j 사용 시 주의할 점

1. 의존성 확인 Slf4j를 사용하려면 로깅 구현체(e.g., Logback)를 추가해야 합니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-logging' // 기본적으로 Logback 포함
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

1. 로그 레벨 설정application.properties 또는 application.yml에서 로그 레벨을 설정합니다.

logging.level.root=INFO
logging.level.com.example=DEBUG

추가 이해를 돕는 비유

• Slf4j는 전원 멀티탭처럼 다양한 로깅 구현체(Logback, Log4j, JUL 등)를 연결해주는 역할.
• @Slf4j는 자동으로 플러그를 꽂아주는 비서 역할을 합니다. 즉, 개발자는 로그를 직접 관리하지 않고 로그를 더 편리하게 사용할 수 있습니다.

System.out.println()과 Slf4j 로거의 차이점

Java 애플리케이션에서 로그 메시지를 출력하기 위해 System.out.println()과 Slf4j 로거를 사용할 수 있습니다. 하지만 둘 사이에는 기능, 성능, 사용 편의성 등 여러 측면에서 차이가 있습니다.

용도

System.out.println()

• 용도: 간단한 디버깅이나 테스트 시 주로 사용.
• 작동 원리: 메시지를 표준 출력(콘솔)에 출력.
• 한계: 로그 레벨, 출력 포맷, 설정 변경 등의 기능이 없음.

Slf4j 로거

• 용도: 전문적인 로깅을 위한 도구.
• 작동 원리: Slf4j는 추상화 계층으로, Logback, Log4j 같은 로깅 구현체를 통해 다양한 로그 출력 및 관리 가능.
• 장점: 로그 레벨, 포맷, 파일 출력, 성능 최적화 등의 고급 기능 제공.

차이점 비교

성능 차이

System.out.println()

• 즉각 실행: 출력할 메시지를 바로 처리하며, 출력이 완료될 때까지 스레드가 대기.
• 비효율성: 모든 메시지를 출력하므로 불필요한 출력 작업이 발생.

Slf4j 로거

• 조건부 실행: 로그 레벨 조건을 체크한 후 필요할 때만 출력.

    if (log.isDebugEnabled()) {
        log.debug("This is a debug log");
    }
  

• 효율적인 메시지 처리: 문자열 연결 작업을 줄이고, 실행 시점에만 필요한 계산 수행.

    log.debug("User ID is {}", userId); // 문자열 연결 작업이 없으므로 성능 최적화.

비교

System.out.println()

System.out.println("Application started");
System.out.println("User ID: " + userId);

Slf4j 로거

log.info("Application started");
log.debug("User ID: {}", userId);

차이점:

• System.out.println은 문자열 연결 연산이 항상 실행됨.
• Slf4j는 로그 레벨 조건에 따라 출력 여부를 결정하며, 문자열 연결 연산을 생략할 수 있음.

왜 Slf4j를 사용해야 하는가?

1. 로그 레벨 관리
   • Slf4j는 로그의 중요도에 따라 DEBUG, INFO, WARN, ERROR로 구분하여 관리 가능.
   • 운영 환경에서는 DEBUG 로그를 비활성화하고, ERROR 로그만 남길 수 있음.
2. 출력 대상 설정
   • Slf4j는 로그를 콘솔뿐 아니라 파일, 데이터베이스, 원격 서버 등 다양한 출력 대상으로 설정 가능.
3. 성능 최적화
   • Slf4j는 불필요한 로그 연산을 피하며, 성능 손실을 최소화.
4. 장기적인 유지보수
   • System.out.println은 대규모 애플리케이션에서 관리하기 어렵지만, Slf4j는 체계적인 로깅 관리가 가능.

System.out.println()를 사용할 때의 한계 사례

문제 상황: 불필요한 디버깅 출력

운영 환경에서 디버깅 메시지가 계속 출력되면 다음과 같은 문제가 발생:

• 보안 문제: 민감한 정보가 콘솔에 출력될 위험.
• 성능 저하: 디버깅 메시지로 인해 시스템 속도가 느려짐.
• 로그 과잉: 중요한 로그를 분석하기 어렵게 만듦.

Slf4j를 사용하면 로그 레벨과 설정 파일로 쉽게 제어 가능.

• System.out.println()은 간단한 디버깅 용도로 사용하기엔 적합하지만, 대규모 애플리케이션에서는 유지보수와 성능 측면에서 한계가 있음.
• Slf4j는 로깅을 체계적으로 관리하며 성능과 확장성을 제공하므로, 실제 애플리케이션에서는 Slf4j 사용이 권장됩니다.

• 클라이언트가 서버에게 “무엇을 하고 싶은지”를 나타내는 요청 방식

예를 들어

GET /users
POST /users

같은 URL이라도 HTTP 메서드에 따라 의미가 완전히 달라진다.

2. GET (조회)

정의

• 서버에서 데이터를 조회할 때 사용

특징 • 데이터를 조회(Read) 할 때 사용 • 서버 상태를 변경하지 않음 (Safe) • URL에 파라미터를 포함

예시

GET /users
GET /users/1

Spring 코드

@GetMapping("/users")
public String getUsers() {
    return "user list";
}

@GetMapping("/users/{id}")
public String getUser(@PathVariable String id) {
    return "user id = " + id;
}

3. POST (생성)

정의

• 서버에 새로운 데이터를 생성할 때 사용

특징 • 데이터를 생성(Create) 할 때 사용 • 요청 바디에 데이터 포함 • 서버 상태 변경 발생

예시

POST /users

Spring 코드

@PostMapping("/users")
public String addUser() {
    return "create user";
}

4. PATCH (수정 - 일부 변경)

정의

• 기존 데이터의 일부를 수정할 때 사용

특징 • 데이터를 부분 수정(Update 일부) 할 때 사용 • 변경된 필드만 전달

예시

PATCH /users/1

Spring 코드

@PatchMapping("/users/{id}")
public String updateUser(@PathVariable String id) {
    return "update user id = " + id;
}

5. DELETE (삭제)

정의

데이터를 삭제할 때 사용

특징 • 데이터를 삭제(Delete) 할 때 사용 • 서버 상태 변경 발생

예시

DELETE /users/1

Spring 코드

@DeleteMapping("/users/{id}")
public String deleteUser(@PathVariable String id) {
    return "delete user id = " + id;
}

HTTP (HyperText Transfer Protocol) 는 클라이언트(브라우저)와 서버 간 데이터를 주고받기 위한 통신 규약(프로토콜)이다. • 기본 포트: 80번 • 특징: 암호화 없음 (평문 통신)

2. HTTPS란?(HTTPS over SSL)

HTTPS (HTTP Secure) 는 HTTP에 SSL/TLS 암호화 계층이 추가된 프로토콜이다. 로그인 자격 증명이 필요한 웹사이트는 HTTPS를 사용해야 한다. HTTP 프로토콜을 사용하기 위해서는 인증기관(CA) 로부터 인증서를 발급받아야 한다. • 기본 포트: 443번 • 특징: 데이터 암호화

3. 암호화 방식

대칭키 방식

하나의 같은 키로 암호화와 복호화를 모두 수행하는 방식

특징

• 속도가 매우 빠르다.
• 대량데이터 처리에 적합하다.

단점

• 키를 안전하게 전달하기 어려움 (가장 큰 문제) ex) AES

비대칭키 방식

공개키 + 개인키 두 개의 키를 사용하는 방식 • 공개키: 누구나 볼 수 있음 • 개인키: 서버만 가지고 있음

특징 • 키 교환이 안전함 • 보안성이 높음

단점 • 속도가 느림

ex) RSA

하리브리드 방식

실제 HTTPS는 이걸 사용합니다. 동작 방식

1. 비대칭키로 대칭키를 안전학 전달
2. 이후 통신은 대칭키로 빠르게 처리 보안 + 성능 둘 다 잡음

4. SSL 인증서 동작 원리

1) SSL인증서 발급 과정

흐름

1. 서버 → 공개키 생성
   2. 서버 → CSR (인증서 요청) 생성
   3. 서버 → CA(인증기관)에 요청
   4. CA → 도메인 검증
   5. CA → 디지털 서명 후 인증서 발급

2) CA의 서명

CA는 서버의 공개키를 검증하고 자신의 개인키로 서명을 한다.

클라이언트는 CA 공개키를 검증

3) Self-Signed SSL

서버가 자기 자신이 서명한 인증서

특징

• 무료
• 테스트용으로 사용

단점

• 브라우저에서 "신뢰할 수 없음" 경고

4) SSL 인증서를 통한 암호화된 통신 원리

핵심 흐름

1.    클라이언트 → 서버 접속
2.    서버 → SSL 인증서 전달
3.    클라이언트 → CA로 인증서 검증
4.    안전하다고 판단하면 통신 시작

5) SSL Handshake

단계별 흐름 1. Client Hello • 지원 가능한 암호화 방식 전달 2. Server Hello • 사용할 암호화 방식 선택 • SSL 인증서 전달 3. 인증서 검증 • CA를 통해 서버 신뢰 여부 확인 4. 키 교환 • 대칭키 생성 후 공개키로 암호화하여 전달 5. 세션 생성 • 이후 통신은 대칭키 사용

Spring Boot 기반 이커머스 프로젝트를 진행하면서 핵심 도메인(Entity)을 먼저 설계했다.

단순 CRUD가 아닌 실제 서비스 흐름을 고려하여 회원 → 상품 → 주문 → 주문상품 구조를 설계하였다.

전체 구조 및 관계

Member
Product
Order
OrderItem
Cart(나중에)

Member (1) : (N) Order
Order (1) : (N) OrderItem
Product (1) : (N) OrderItem

MemberEntity

package com.jeongbeom.ecommerce.member.entity;

import com.jeongbeom.ecommerce.common.entity.BaseTimeEntity;
import com.jeongbeom.ecommerce.common.entity.Role;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@Getter
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED) // 기본 생성자 자동 생성, 외부 생성 차단
public class Member extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; //PK

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String password;

    @Column(nullable = false)
    private String phone;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private Role role;

    public Member(String email, String password, String phone, Role role) {
        this.email = email;
        this.password = password;
        this.phone = phone;
        this.role = role;
    }
}

• Member 엔티티는 사용자 정보를 관리하며, email에 unique 제약조건을 설정하여 중복 데이터를 방지하였다.
• Role을 Enum 타입으로 관리하여 사용자 권한을 명확하게 구분할 수 있도록 설계하였다.

MemberRepository

package com.jeongbeom.ecommerce.member.repository;

import com.jeongbeom.ecommerce.member.entity.Member;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.Optional;

public interface MemberRepository extends JpaRepository<Member, Long> {
    Optional<Member> findByEmail(String email);
}

OrderEntity

package com.jeongbeom.ecommerce.order.entity;

import com.jeongbeom.ecommerce.common.entity.BaseTimeEntity;
import com.jeongbeom.ecommerce.member.entity.Member;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class Order extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; //PK

    //Member 연결
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id", nullable = false)
    private Member member;

    @Column(nullable = false)
    private String orderNumber;

    @Column(nullable = false)
    private int totalPrice;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private OrderStatus status;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String phone;

    @Column(nullable = false)
    private String address;

    public Order(Member member, String orderNumber, int totalPrice, OrderStatus status, String name, String phone, String address) {
        this.member = member;
        this.orderNumber = orderNumber;
        this.totalPrice = totalPrice;
        this.status = status;
        this.name = name;
        this.phone = phone;
        this.address = address;
    }
}

• Order 엔티티는 주문 상태를 OrderStatus Enum으로 관리하여
  주문의 lifecycle을 명확하게 표현할 수 있도록 설계하였다.
• 배송 정보를 별도로 저장하여 회원 정보 변경과 관계없이 주문 시점의 배송 정보를 유지할 수 있도록 하였다.
• Member와의 연관관계를 통해 주문 주체를 명확히 하고 데이터 정합성을 유지하도록 설계하였다.

OrderRepository

package com.jeongbeom.ecommerce.order.entity.repository;

import com.jeongbeom.ecommerce.order.entity.Order;
import org.springframework.data.jpa.repository.JpaRepository;

public interface OrderRepository extends JpaRepository<Order, Long> {
}

OrderStarus

package com.jeongbeom.ecommerce.order.entity;

public enum OrderStatus {
    CREATED,    //주문 생성됨 (결제전)
    PAID,       //결제 완료
    PREPARING,  //상품 준비중
    SHIPPED,    //배송 시작
    DELIVERED,  //배송 완료
    CANCELLED   //주문 취소
}

OrderItemEntity

package com.jeongbeom.ecommerce.order.entity;

import com.jeongbeom.ecommerce.common.entity.BaseTimeEntity;
import com.jeongbeom.ecommerce.product.entity.Product;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@Getter
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class OrderItem extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; //PK

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id", nullable = false)
    private Product product;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id", nullable = false)
    private Order order;

    @Column(nullable = false)
    private int orderPrice;

    @Column(nullable = false)
    private int orderQuantity;

    public OrderItem(Product product, Order order, int orderPrice, int orderQuantity) {
        this.product = product;
        this.order = order;
        this.orderPrice = orderPrice;
        this.orderQuantity = orderQuantity;
    }
}

• OrderItem은 주문(Order)과 상품(Product)을 연결하는 핵심 엔티티로 설계하였다.
• 상품 가격은 변동될 수 있기 때문에 주문 시점의 가격(orderPrice)을 별도로 저장하여, 이후 상품 가격이 변경되더라도 주문 당시의 정보를 유지할 수 있도록 하였다.
• 주문 수량(quantity)을 함께 저장하여 주문 상세 정보를 구성할 수 있도록 설계하였다.

OrderItemRepository

package com.jeongbeom.ecommerce.order.entity.repository;

import com.jeongbeom.ecommerce.order.entity.OrderItem;
import org.springframework.data.jpa.repository.JpaRepository;

public interface OrderItemRepository extends JpaRepository<OrderItem, Long> {
}

ProductEntity

package com.jeongbeom.ecommerce.product.entity;

import com.jeongbeom.ecommerce.common.entity.BaseTimeEntity;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@Getter
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class Product extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; //PK

    @Column(nullable = false)
    private String name; //상품 이름

    @Column(nullable = false)
    private String description; //상품 상세 설명

    @Column(nullable = false)
    private int price;  //상품 가격

    @Column(nullable = false)
    private int stock;  //상품 재고 수량

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private ProductStatus status;  //상품 상태

    // 생성자
    public Product(String name, String description, int price, int stock, ProductStatus status) {
        this.name = name;
        this.description = description;
        this.price = price;
        this.stock = stock;
        this.status = status;
    }

    // 재고 감소
    public void decreaseStock(int quantity){
        if(stock < quantity){
            throw new IllegalArgumentException("재고 부족");
        }
        this.stock -= quantity;
    }

    // 재고 증가
    public void increaseStock(int quantity){
        this.stock += quantity;
    }
}

• 재고 감소 및 증가 로직을 Entity 내부에 포함시켜 비즈니스 로직이 도메인에 집중되도록 설계하였다. 이를 통해 도메인 중심 설계(Domain-driven design)를 적용하였다.

ProductRepository

package com.jeongbeom.ecommerce.product.entity.repository;

import com.jeongbeom.ecommerce.product.entity.Product;
import org.springframework.data.jpa.repository.JpaRepository;

public interface ProductRepository extends JpaRepository<Product, Long> {
}

ProductStatus

package com.jeongbeom.ecommerce.product.entity;

public enum ProductStatus {
    ON_SALE, SOLD_OUT, HIDDEN
}

ERD

Dependencies

• .gitignore에 # .env 파일 설정해주고, root에 .env파일 만들어서 민감한 부분 .env에 따로 넣어 관리해준다 (부트캠프 당시에 깃을 처음 써봐서 민감한 정보 다올렸던 기억이있다.)

• git 레포에 연동 및 초기 셋팅 부분 세분화 Commit

• develop 브렌치 생성 및 Git WorkFlow 작성

• Git 레포 주소 https://github.com/ShinJeongBeom/E-Commerce

프로젝트 선택 이유

• 결제시스템 및 로그인 등 내가 맡아보지 못한 기능들이 다 들어가 있는것 같아서 선택하게 됬다. ( 이것 저것 추가하다보면 면접에서도 할말이 많아지지 않을까 싶다)
• 프론트도 취업 준비하는 지인을 꼬셔볼까(?) 했지만 요즘 뜨고있는 LLM MCP Claude 한테 프론트 부분만 맡겨볼까 생각중이다.

1. 프로젝트 개요

본 프로젝트는 Spring Boot 기반 이커머스 서비스를 구현하는 것을 목표로 한다. 사용자는 상품을 조회하고 장바구니에 담아 주문할 수 있으며, 관리자는 상품 및 주문을 관리할 수 있다.

2. 기획 및 설계

목표 • RESTful API 기반 이커머스 서비스 구현 • 사용자 → 상품 → 장바구니 → 주문 흐름 설계 • 확장 가능한 구조 설계 (MSA 고려 가능)

핵심 기능 흐름

   회원가입 → 로그인 → 상품 조회 → 장바구니 담기 → 주문 → 결제(확장 예정)

시스템 구조

•    Backend: Spring Boot (Java)
•    DB: MariaDB
•    Cache: Redis
•    Infra: Docker
•    인증: JWT (예정)

3. 구현 기능

👤 사용자 (User)

•    회원가입
•    로그인 (예정)
•    사용자 정보 조회

📦 상품 (Product)

•    상품 등록 (관리자)
•    상품 목록 조회
•    상품 상세 조회
•    카테고리 기반 조회

🗂 카테고리 (Category)

•    카테고리 생성
•    계층형 구조 (parent_id)

🛒 장바구니 (Cart)

•    장바구니 생성
•    상품 담기
•    수량 변경
•    삭제
•    장바구니 조회

📦 주문 (Order)

•    주문 생성
•    주문 상품 저장
•    총 금액 계산
•    주문 상태 관리

🖼 상품 이미지 (Product Image)

•    상품별 이미지 관리
•    썸네일 여부 관리
•    정렬 순서 관리

API 명세서

이번 글에서는 Spring MVC가 요청을 처리하는 전체 구조와 핵심 컴포넌트들을 정리한다.

1. DispatcherServlet

Spring MVC의 핵심은 DispatcherServlet이다.

모든 HTTP 요청은 DispatcherServlet을 통해 처리된다.

DispatcherServlet은 Front Controller 패턴을 기반으로 만들어진 컴포넌트이며 요청 처리 흐름 전체를 관리한다.

즉, • 요청을 받고 • 컨트롤러를 찾고 • 컨트롤러를 실행하고 • View를 찾아 응답을 반환하는

전체 과정을 조정하는 역할을 한다.

2. Spring MVC 전체 요청 흐름

Spring MVC에서 요청이 처리되는 전체 흐름은 다음과 같다.

Client
  │
  ▼
DispatcherServlet
  │
  ▼
HandlerMapping
  │
  ▼
HandlerAdapter
  │
  ▼
Controller
  │
  ▼
ModelAndView
  │
  ▼
ViewResolver
  │
  ▼
View
  │
  ▼
Response

각 단계의 역할을 살펴보자.

3. HandlerMapping

정의

요청 URL에 맞는 컨트롤러를 찾아주는 역할

클라이언트 요청이 들어오면 DispatcherServlet은 먼저 HandlerMapping을 통해 실행할 컨트롤러를 찾는다.

예를 들어 다음과 같은 컨트롤러가 있다고 가정하자.

@Controller
@RequestMapping("/members")
public class MemberController {

    @GetMapping
    public String members() {
        return "members";
    }
}

요청

GET /members

HandlerMapping은 @RequestMapping 정보를 기반으로

MemberController.members()

4. HandlerAdapter

HandlerMapping이 컨트롤러를 찾았다고 해서 바로 실행할 수 있는 것은 아니다.

왜냐하면 컨트롤러의 형태가 다양할 수 있기 때문이다.

그래서 등장한 것이 HandlerAdapter이다.

정의

찾아낸 컨트롤러를 실제로 실행해주는 역할

HandlerAdapter는 다음 두 가지를 수행한다.

1. 해당 컨트롤러를 실행할 수 있는지 확인
2. 컨트롤러 실행

   RequestMappingHandlerAdapter

5. Controller 실행

HandlerAdapter를 통해 컨트롤러가 실행된다.

@GetMapping("/members")
public String members(Model model) {

    List<Member> members = memberRepository.findAll();
    model.addAttribute("members", members);

    return "members";
}

컨트롤러는 다음 두 가지 정보를 반환한다.

1. View 이름
2. View에 전달할 데이터(Model)

6. ModelAndView

컨트롤러의 반환값은 내부적으로 ModelAndView 형태로 변환된다.

ModelAndView는 다음 두 가지 정보를 가진 객체이다.

ModelAndView
 ├ ViewName
 └ Model (데이터)

즉

어떤 화면(View)을 보여줄지
어떤 데이터(Model)를 전달할지를 함께 담고 있는 객체이다.

7. ViewResolver

컨트롤러는 실제 View 경로를 반환하지 않는다.

예

return "members";

이것은 실제 경로가 아닌 논리적인 View 이름(Logical View Name)이다.

ViewResolver의 역할은

논리적인 View 이름을 실제 View 경로로 변환하는 것이다.

예

members
↓
/WEB-INF/views/members.jsp

대표 구현체

InternalResourceViewResolver

8. View

View는 실제 화면을 생성하는 역할을 한다.

대표적인 View 기술

JSP
Thymeleaf

예를 들어 JSP에서는 다음과 같이 Model 데이터를 사용할 수 있다.

<c:forEach var="member" items="${members}">
    <tr>
        <td>${member.username}</td>
        <td>${member.age}</td>
    </tr>
</c:forEach>

View는 Model 데이터를 기반으로 HTML을 생성한다.

9. Model vs ModelAndView vs ModelMap

Spring MVC에서 View에 데이터를 전달하는 방식은 여러 가지가 있다.

Model

가장 많이 사용하는 방식이다.

@GetMapping("/members")
public String members(Model model) {

    List<Member> members = memberRepository.findAll();
    model.addAttribute("members", members);

    return "members";
}

특징

데이터는 Model에 저장
View 이름은 String으로 반환

*ModelAndView * Model과 View를 하나의 객체로 묶는 방식이다.

@GetMapping("/members")
public ModelAndView members() {

    List<Member> members = memberRepository.findAll();

    ModelAndView mv = new ModelAndView("members");
    mv.addObject("members", members);

    return mv;
}

ModelMap

Model과 비슷하지만 Map 구조로 동작한다.

@GetMapping("/members")
public String members(ModelMap model) {

    model.addAttribute("members", members);

    return "members";
}

10. Spring MVC의 요청 처리 흐름은 다음과 같다.

DispatcherServlet
 → HandlerMapping (컨트롤러 찾기)
 → HandlerAdapter (컨트롤러 실행)
 → Controller
 → ModelAndView
 → ViewResolver
 → View
 → Response

각 구성 요소의 역할

DispatcherServlet → 전체 흐름 제어
HandlerMapping → 실행할 컨트롤러 찾기
HandlerAdapter → 컨트롤러 실행
ViewResolver → View 경로 변환
Model → View에 전달할 데이터

1. 서블릿 MVC에서 발생하는 중복 문제

① View로 이동하는 코드의 중복 (forward 중복)

컨트롤러 역할을 하는 모든 서블릿에서 JSP로 이동할 때마다 아래 코드가 반복된다.

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

회원 목록, 회원 저장, 회원 폼 등 모든 서블릿에서 동일한 코드가 계속 등장한다. • 메서드로 분리할 수는 있음 • 하지만 결국 매번 직접 호출해야 함 • 컨트롤러의 핵심 로직이 아닌 코드가 계속 눈에 띔

-컨트롤러가 비즈니스 흐름 제어에만 집중하지 못한다.-

② View 경로 문자열 중복 (ViewPath 중복)

String viewPath = "/WEB-INF/views/new-form.jsp";

여기에는 두 가지 문제가 숨어 있다.

✔ prefix / suffix가 하드코딩됨 • prefix: /WEB-INF/views/ • suffix: .jsp

모든 컨트롤러에서 이 문자열을 직접 작성해야 한다.

✔ View 기술 변경에 취약 만약 View를 JSP → Thymeleaf로 바꾸면?

// 기존
"/WEB-INF/views/new-form.jsp"

// 변경 후
"/templates/new-form.html"

모든 컨트롤러 코드를 수정해야 함

즉, • 컨트롤러가 View 기술(JSP, Thymeleaf)에 강하게 결합 • 변경에 매우 취약한 구조

2. 문제의 본질: 책임이 흩어져 있다

현재 구조에서는 • 요청 분기 • 비즈니스 로직 호출 • View 선택 • forward 처리

이 모든 책임이 각 서블릿마다 흩어져 있음, 컨트롤러가 너무 많은 일을 함.

3. 해결 아이디어: 공통 로직을 한 곳으로 모으자

여기서 자연스럽게 나오는 질문:

“이 공통 코드를 한 곳에서 처리할 수는 없을까?”

그래서 등장하는 개념이 바로 프론트 컨트롤러(Front Controller) 이다.

4. 프론트 컨트롤러란?

모든 요청을 단 하나의 컨트롤러가 먼저 받는 구조

클라이언트 요청
      ↓
[Front Controller]
      ↓
각 기능별 컨트롤러
      ↓
View

5. 프론트 컨트롤러가 해결해주는 것들

   1) forward 로직을 한 곳에서 처리

   RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
   dispatcher.forward(request, response);

   이 코드는 프론트 컨트롤러에 단 한 번만 존재한다. 개별 컨트롤러에서는 “어떤 뷰를 쓸지”만 반환하면 된다.

2) ViewPath 조립 책임 분리

개별 컨트롤러:

return "new-form";

프론트 컨트롤러:

String viewPath = "/WEB-INF/views/" + viewName + ".jsp";

prefix / suffix가 한 곳에만 존재 View 기술 변경 시 수정 포인트 단 하나

3) 컨트롤러의 역할이 명확해짐

컨트롤러는 이제 딱 이것만 한다. • 요청 파라미터 처리 • 비즈니스 로직 호출 • 논리적인 View 이름 반환

Controller = 요청 처리 + 흐름 결정
View 처리 = Front Controller

— HTTP 요청 메시지 받는 방법 중심

웹 애플리케이션에서 클라이언트의 요청(Request)을 서버가 어떻게 받는지는 가장 기본이면서도 중요한 개념이다.

서블릿(Servlet)에서는 이 요청 정보를
HttpServletRequest 객체를 통해 처리한다.

1. HttpServletRequest란?

HttpServletRequest는 클라이언트가 서버로 보낸 HTTP 요청 정보를 담고 있는 객체이다.

이 객체를 통해 다음과 같은 정보를 읽을 수 있다.

• 요청 방식 (GET, POST)
• URL, URI
• 파라미터 값
• HTTP 헤더
• 요청 바디(JSON 등)
• 세션 정보

즉, 사용자가 서버로 보낸 모든 정보의 집합이다.
(Spring에서는 이 객체를 추상화해 더 편하게 사용할 수 있다.)

2. 요청 메시지를 받는 방법 3가지

서블릿(또는 Spring MVC)에서 요청 데이터를 받는 방식은
크게 3가지로 나눌 수 있다.

2-1. HTTP 파라미터 방식 (Query String / Form Data)

✔ 사용 예

• GET 쿼리 스트링
• POST application/x-www-form-urlencoded

/login?username=kim&age=25
쿼리 파라미터에 정보를 전달하는 부분이다. 

``` java
String username = request.getParameter("username");
String age = request.getParameter("age");

복수 파라미터

String[] hobbies = request.getParameterValues("hobby");

특징 • 항상 String 타입으로 전달됨 • 단순 데이터 처리에 적합 • HTML form 전송 방식

② HTTP 메시지 바디(JSON)

REST API에서 가장 많이 사용하는 방식이다.

요청예시

{
  "name": "jeongbeom",
  "age": 25
}

서버 처리 코드

ObjectMapper objectMapper = new ObjectMapper();

UserDto user = objectMapper.readValue(
    request.getInputStream(),
    UserDto.class
);

• JSON으로 파라미터 값을 읽으려면 ObjectMapper.readValue(변수명, 클래스이름)을 사용한다.

특징 • 객체 단위로 데이터 처리 가능 • 타입 안정성 확보 • RESTful API에 적합

③ Path Variable (경로 변수)

URL 경로 자체에 값을 포함하는 방식이다.

GET /users/10

@GetMapping("/users/{id}")
public String find(@PathVariable Long id) {
    return "id = " + id;
}

특징 • 리소스 식별에 적합 • URL 의미가 명확 • REST API 설계에 필수

3. 요청 메시지 방식 한눈에 비교

4. request vs response

요청 데이터는 무조건 request에서 읽는다

5. 정리

• 서블릿에서 요청은 HttpServletRequest 객체를 통해 처리한다
• 요청 메시지를 받는 방법은 크게 3가지가 있다
  1. HTTP 파라미터 방식
  2. JSON 메시지 바디 방식
  3. Path Variable 방식
• JSON 데이터는 ObjectMapper.readValue()를 사용해 객체로 변환한다

1. 캐시가 필요한 이유

•    네트워크 비용 절약
•    서버 부하 감소
•    웹 페이지 로딩 시간 단축
•    사용자 경험 개선

2. Cache-Control 주요 옵션

1) max-age

Cache-Control: max-age=60

• 캐시가 60초 동안 유효하다는 의미 • 유효 시간 동안은 네트워크 요청 없이 캐시 데이터를 바로 사용

2) no-cache

Cache-Control: no-cache

• 데이터를 캐시할 수는 있음 • 하지만 사용하기 전 반드시 원 서버에 검증(ETag)해야 함

저장은 가능하지만 검증 없이 사용은 불가.

*3) no-store *

Cache-Control: no-store

• 아예 저장조차 하지 않음 • 보안성 높은 데이터(개인정보, 금융 데이터 등)에 필수

4) Expires

Expires: Mon, 01 Jan 2025 00:00:00 GMT

• 캐시 만료 시간(절대 시간) 지정 • HTTP/1.1에서는 Cache-Control이 우선순위 더 높음

3. Last-Modified / If-Modified-Since

Last-Modified

Last-Modified: 2024-12-01 00:00:00 GMT

서버가 리소스가 마지막으로 변경된 시점을 알려줌.

If-Modified-Since

클라이언트가 다음 요청 때:

If-Modified-Since: 2024-12-01 00:00:00 GMT

서버가 변경된 내용이 없으면…

→ 304 Not Modified 응답 → 캐시 데이터 재사용

4. ETag / If-None-Match (더 정교한 캐싱)

파일 해시 기반으로 변경 여부 판단.

서버:

ETag: "abc123"

클라이언트:

If-None-Match: "abc123"

변경 없음 → 304 Not Modified

5. 프록시 캐시

• 브라우저 캐시 → private 캐시 • 프록시(중간 캐시 서버) → public 캐시

public 캐시 허용:

Cache-Control: public

개인별 캐시만 허용:

Cache-Control: private

s-maxage 프록시 캐시만 별도 캐싱 시간 지정

Cache-Control: s-maxage=120

6. 캐시를 완전히 막고 싶을 때

로그인 정보나 중요한 페이지는 캐시되면 안 된다.

Cache-Control: no-cache, no-store, must-revalidate

7. no-cache 동작 예시

1.    클라이언트 요청 (no-cache + ETag 포함)
2.    캐시 서버는 원 서버에 검증 요청
3.    서버가 304 Not Modified 응답
4.    캐시 서버는 저장해둔 데이터 재사용

검증 후 캐시 사용 구조이다.

1. 쿠키란?

쿠키는 웹 브라우저가 저장하는 작은 데이터 조각이며, 브라우저는 매 요청마다 자동으로 해당 쿠키를 서버로 전송한다.

따라서 서버는 브라우저가 보내는 쿠키를 확인해 사용자를 식별할 수 있다.

2. 쿠키의 동작 방식

1. 서버가 응답할 때 쿠키를 설정

Set-Cookie: sessionId=adfasdf; Expires=Sat, 26 Dec 2025 00:00:00 GMT; Path=/; Domain=google.com; Secure

2. 브라우저는 쿠키를 저장한다. 3. 이후 해당 도메인의 요청은 항상 쿠키를 포함한다.

Cookie: sessionId=adfasdf

3. 쿠키의 주요 사용처

•    로그인 상태 유지(세션 ID 저장)
•    광고/트래킹 정보 저장
•    간단한 사용자 상태 관리
•    장바구니 데이터 유지 등

4. 쿠키 저장 시 주의사항

쿠키는 매우 중요한 특징이 있다:

브라우저는 모든 요청마다 쿠키를 서버에 자동 포함한다.

→ 결과적으로 • 네트워크 트래픽 증가 • 개인 정보 노출 위험 증가

따라서 민감한 정보는 쿠키에 절대 저장하면 안 된다. (예: 비밀번호, 주민번호, 카드번호 등)

쿠키에는 최소한의 정보(PK, 세션 ID, 인증 토큰 등)만 저장해야 한다.

만약 서버로 보내지 않고 브라우저 내부에만 저장하고 싶다면 → Web Storage(LocalStorage / SessionStorage)를 사용해야 한다.

5. 쿠키 속성 정리

Expires / Max-Age • Expires: 절대 시간 (해당 시간이 되면 쿠키 삭제) • Max-Age: 쿠키 유지 시간(초 단위) • *Max-Age=0 *또는 음수 → 쿠키 삭제

세션 쿠키(Session Cookie) • Expires/Max-Age 생략 • 브라우저 창을 닫을 때 삭제됨

영속 쿠키(Persistent Cookie) • Expires 또는 Max-Age 지정 • 지정된 날짜까지 유지됨

Domain • 쿠키가 적용되는 도메인 지정 • 예: Domain=google.com → google.com + 모든 서브도메인에서 사용 가능 • 생략하면 현재 문서 도메인에서만 적용

Path • 쿠키가 전송되는 경로 • 기본적으로 Path=/ 로 설정하여 전체 경로에서 사용하도록 설정

Secure • HTTPS에서만 전송됨 • HTTP에서는 전송되지 않음

HttpOnly • JavaScript에서 쿠키 접근 불가 • XSS 공격 방지용

SameSite • CSRF 공격 방지용 정책 • Lax / Strict / None 설정 가능

6. 쿠키 요약

•    서버가 Set-Cookie로 브라우저에 저장
•    브라우저는 모든 요청에 쿠키를 자동 포함
•    민감 정보 저장 금지
•    로그인/세션유지/트래킹 등에 사용
•    보안 속성(secure, httpOnly, sameSite)을 반드시 설정해야 함

1. 문제 발생

MariaDB 삭제 후 MySQL을 설치하고 실행했지만, 계속해서 MySQL 서버에 연결되지 않는 오류가 발생했습니다.

오류 내용

Error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

MySQL 서버가 실행되지 않고, 소켓 파일(mysql.sock) 역시 생성되지 않는 상태였습니다.

2. 문제 확인 (mysql.err 로그 분석)

단순 소켓 문제가 아닐 수도 있다고 판단해 MySQL 에러 로그를 확인했습니다.

에러 로그 확인

cat /opt/homebrew/var/mysql/*.err

로그를 확인해보니, • Port 3306 is already in use • Can't start server: Bind on TCP/IP port: Address already in use 와 같은 메시지가 포함되어 있었고,이미 삭제했다고 생각했던 MariaDB(mysqld) 데몬이 3306 포트를 점유 중이라는 사실을 알 수 있었습니다.

즉, MySQL이 실행되지 않은 원인은 소켓 자체 문제가 아니라 3306 포트가 MariaDB 프로세스에 의해 점유되어 있었기 때문이었습니다.

3. 문제 해결

3-1. MariaDB 프로세스 종료

먼저 3306 포트를 점유하고 있는 MariaDB 프로세스를 강제로 종료했습니다

kill -9 <PID>

종료 확인:

lsof -i :3306

3-2. MariaDB 완전 삭제

MariaDB가 완전히 제거되도록 아래 순서로 처리했습니다.

1) 서비스 종료

brew services stop mariadb

2) 패키지 삭제

brew uninstall mariadb

3) 남아 있는 데이터 디렉토리 삭제

rm -rf /opt/homebrew/var/mysql

이 디렉토리가 남아 있으면 MySQL이 소켓 파일을 생성하지 못하고 오류가 반복됩니다.

3-3. MySQL 재설치 및 서버 실행

MySQL 설치

brew install mysql

서버 실행 스크립트로 직접 구동

cd /opt/homebrew/Cellar/mysql/*/support-files
./mysql.server start

이제 MySQL 서버가 정상적으로 실행되며 mysql.sock 파일도 생성되었습니다.

3-4. mysql_secure_installation 정상 실행

mysql_secure_installation

다음 화면이 뜨면 문제 없이 작동하는 것입니다.

Securing the MySQL server deployment.

Connecting to MySQL using a blank password.

이후 안내에 따라 비밀번호와 보안 설정을 완료했습니다.

3-5. 최종 접속 확인

mysql -u root -p

정상적으로 접속되면 모든 과정이 성공적으로 완료된 것입니다.

이번 문제의 핵심은 삭제된 줄 알았던 MariaDB의 데몬 프로세스가 백그라운드에서 실행 중이며 3306 포트를 차지하고 있었던 점이었습니다. 에러 로그(mysql.err)를 직접 확인한 것이 문제 해결의 실마리가 되었습니다.

같은 환경(M1/M2 + Homebrew)에서 MySQL 환경을 구성하는 분들에게 도움이 되었으면 합니다.

백엔드 개발을 하다 보면 “클라이언트가 서버에 요청을 보낸다”라는 말을 매일 듣습니다.
그런데, 실제로 요청이 어떻게 전달되고, 서버는 어떤 과정을 거쳐 응답을 돌려주는지 알아보겠습니다.

이번 글에서는 제가 공부하면서 정리한
클라이언트 ↔ 서버 통신의 핵심 개념을 정리해봤습니다.

🧭 클라이언트 - 인터넷 - 서버

모든 서버 개발의 출발점은 요청(Request) 과 응답(Response) 입니다.
클라이언트(브라우저)가 서버에 요청을 보내면,
인터넷을 거쳐 서버가 응답을 돌려주는 구조죠.

하지만 단순히 "요청 → 응답"만 있는 게 아닙니다.
그 뒤에는 IP, TCP, DNS 등 수많은 통신 계층이 존재합니다.

💡 IP (Internet Protocol)

IP는 인터넷 상의 주소 체계입니다.
사람에게는 주소가 있고, 컴퓨터에는 IP가 있습니다.

• 예시: 192.168.0.1
• 데이터는 패킷(packet) 단위로 쪼개져 전송됩니다.
• 각 패킷은 목적지 IP를 보고 라우터를 통해 전달됩니다.

단, IP만으로는 데이터가 제대로 도착했는지 보장할 수 없습니다.
그래서 TCP나 UDP 같은 상위 프로토콜이 등장합니다.

⚙️ TCP / UDP

🔹 TCP (Transmission Control Protocol)

“정확하게” 데이터를 주고받는 연결형 프로토콜

TCP는 데이터 전송의 안정성을 보장합니다.
연결 전에는 다음과 같은 3-way handshake 과정을 거칩니다.

1. 클라이언트 → 서버 : SYN (연결 요청)
2. 서버 → 클라이언트 : SYN + ACK (요청 수락)
3. 클라이언트 → 서버 : ACK (확인 응답)

이제 연결이 완료되면 안전하게 데이터를 전송할 수 있습니다.
로그인, 결제, 파일 다운로드 같은 정확성이 중요한 요청에서 주로 사용됩니다.

🔹 UDP (User Datagram Protocol)

빠르지만 “확실하지 않은” 비연결형 프로토콜

UDP는 TCP처럼 연결 과정을 거치지 않습니다.
그냥 “하얀 도화지에 던지는 느낌”으로 데이터를 전송하죠.

• 연결 없이 빠름 🚀
• 대신 손실 가능성 있음 ⚠️
• 사용 예: 게임, 실시간 스트리밍, 영상 통화 등

UDP는 데이터 전송 시 포트 번호 + 체크섬 정보만 포함합니다.

🌍 DNS (Domain Name System)

사람은 www.google.com처럼 이름을 기억하지만,
컴퓨터는 142.250.196.142 같은 IP 주소로 통신합니다.
이 둘을 연결해주는 시스템이 바로 DNS입니다.

예시 흐름:
클라이언트 → “google.com 요청”
DNS 서버 → “142.250.196.142” IP 응답
클라이언트 → 해당 IP로 실제 요청 전송

🔐 HTTP / HTTPS

HTTP는 웹에서 데이터를 주고받는 프로토콜입니다.
거의 모든 서버 통신은 HTTP를 기반으로 동작합니다.

• HTTP : Hyper Text Transfer Protocol
• HTTPS : HTTP + SSL/TLS 보안 계층 (암호화된 통신)

즉, HTTPS는 보안이 강화된 HTTP라고 생각하면 됩니다.
요즘은 대부분 HTTPS를 기본으로 사용하죠.

🔄 상태 유지 vs 무상태 (Stateful vs Stateless)

🟢 Stateful

서버가 클라이언트의 상태(로그인 등)를 기억하는 구조입니다.
예를 들어 로그인 후 "내 정보"를 조회할 때 같은 서버가 계속 나를 알아야 하죠.

• 장점: 사용자의 상태 유지 가능 (세션, 쿠키)
• 단점: 같은 서버로 요청을 보내야 함 (확장성 낮음)

⚪ Stateless

HTTP는 기본적으로 무상태(Stateless) 프로토콜입니다.
즉, 서버는 클라이언트의 상태를 기억하지 않습니다.

• 장점: 서버 확장(Scale-out) 용이
• 단점: 매 요청마다 인증정보를 다시 전달해야 함

👉 그래서 JWT 같은 토큰 기반 인증이 자주 쓰입니다.

📩 HTTP 메시지 구조

HTTP 통신은 메시지(Message) 기반으로 이루어집니다.

# 요청 메시지 예시
GET /members HTTP/1.1
Host: example.com
User-Agent: Chrome/127.0.0.1

응답 메시지 예시

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1,
  "name": "정범"
}

🚦 HTTP 상태 코드 요약

📘 주요 상태 코드 정리

✅ 200 OK

정상적으로 요청이 성공적으로 처리됨.
예시: GET /members 요청 시 회원 목록을 정상적으로 응답받았을 때.

✅ 201 Created

요청이 성공적으로 처리되어 리소스가 생성됨.
예시: POST /members 요청 시 새로운 회원이 생성된 경우.

⚙️ 204 No Content

요청이 성공했지만, 응답 바디가 없음.
예시: DELETE /members/{id} 요청 시 정상 삭제 후 응답 바디가 없을 때.

🚀 301 Moved Permanently

요청한 리소스의 URI가 변경되었음을 의미.
브라우저는 이후 요청부터 새 URI로 자동 전환함.

🔁 302 Found

임시로 다른 URI로 요청을 보낼 것을 지시.
보통 로그인 후 리다이렉트 등에서 사용됨.

🚫 400 Bad Request

클라이언트의 요청이 잘못됨.
예시: 필수 파라미터 누락, 잘못된 JSON 포맷 등.

🔐 401 Unauthorized

인증이 필요함.
로그인이나 토큰이 필요한 API 요청 시 인증 누락 시 발생.

🧱 403 Forbidden

인증은 되었으나 접근 권한이 없음.
예시: 일반 사용자가 관리자 페이지에 접근하려는 경우.

❓404 Not Found

요청한 리소스를 찾을 수 없음.
예시: 존재하지 않는 회원 ID 요청 시.

💣 500 Internal Server Error

서버 내부 오류.
서버 로직, DB 문제 등 서버 측에서 발생한 예외 상황.

🧭 RESTful API 설계 핵심 정리

RESTful API를 설계할 때는 리소스 중심(Resource-Oriented) 으로 생각해야 합니다.
즉, “무엇을” 다루는지를 URI로 표현하고, “어떻게” 다루는지는 HTTP 메서드로 구분합니다.

📂 URI 설계 규칙

🧾 알아두면 좋은 URI 설계 개념

RESTful 설계를 할 때 URI를 단순히 “주소”로만 보면 부족합니다.
리소스의 구조적 의미를 명확히 하기 위해 다음 네 가지 개념을 함께 이해해두면 좋습니다.

📄 문서(Document)

• 단일 개념의 리소스를 의미합니다.
  (파일 하나, 객체 인스턴스, 데이터베이스의 한 행 등)
• 주로 고유 ID를 통해 접근합니다.
  예시: /members/100 /files/star.jpg

📚 컬렉션(Collection)

• 서버가 관리하는 리소스의 디렉터리입니다.
• 서버가 리소스의 URI를 생성하고 관리합니다.
  (보통 POST 요청으로 새로운 리소스를 생성)
• 예시:
  /members /products

🏬 스토어(Store)

• 클라이언트가 관리하는 리소스 저장소입니다.
• 클라이언트가 직접 URI를 지정하고 관리합니다.
  (즉, 클라이언트가 리소스의 이름을 정함)
• 예시:
  /files /uploads

⚙️ 컨트롤러(Controller, Control URI)

• 문서/컬렉션/스토어로 표현하기 어려운 추가 동작(프로세스) 을 수행할 때 사용합니다.
• 이 경우 동사(verb) 를 URI에 직접 사용합니다.
  예시:
  /members/{id}/delete /orders/{id}/cancel /emails/send

💡 TIP:
RESTful 설계에서는 기본적으로 “명사형 리소스”를 사용하지만,
명령형 프로세스가 필요한 경우엔 이렇게 컨트롤러 URI 형태로 확장합니다.

🧩 멱등(Idempotent) 개념

"같은 요청을 여러 번 보내더라도 결과가 동일해야 한다"

💡 POST는 멱등하지 않음 — 같은 요청을 반복하면 중복된 데이터가 생길 수 있음.

💬 자바스크립트를 이용한 서버 통신 (AJAX)

AJAX란?

Asynchronous JavaScript And XML 의 약자로, 페이지 전체를 새로고침하지 않고도 서버와 데이터를 주고받을 수 있게 해주는 기술입니다.

fetch('/members')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error(error));

•    fetch() 함수는 비동기 통신을 수행합니다.
•    서버로부터 JSON 형식의 응답을 받으면 .then()으로 처리합니다.
•    에러 발생 시 .catch()에서 처리합니다.

✅ 장점: 페이지 새로고침 없이도 데이터 요청 및 갱신 가능 ✅ 활용: 검색 자동완성, 댓글 등록, 좋아요 기능 등

Spring Framework는 Java 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로, 개발자가 대규모 엔터프라이즈 애플리케이션을 효율적으로 개발할 수 있도록 다양한 기능을 제공합니다. IoC(Inversion of Control)와 DI(Dependency Injection) 같은 핵심 개념을 기반으로 하여, 복잡한 Java 애플리케이션의 설계와 구성을 간결하게 만들고, 유지보수성을 높이는 데 도움을 줍니다.

Spring은 웹 애플리케이션, 데이터베이스 연동, 보안, 배치 작업, 클라우드와의 연동 등 다양한 모듈을 제공하며, 특히 Spring Boot의 등장으로 빠르게 애플리케이션을 시작할 수 있는 표준이 되었습니다.

Spring Framework 개요

1. Spring Framework란?
   • Java 플랫폼을 위한 오픈 소스 경량 애플리케이션 프레임워크로, 엔터프라이즈급 애플리케이션 개발을 더 쉽고 빠르게 할 수 있도록 돕습니다.
   • 다양한 모듈을 통해 IoC (제어의 역전), DI (의존성 주입), AOP (관점 지향 프로그래밍), MVC (모델-뷰-컨트롤러) 패턴을 지원합니다.
2. Spring Framework의 주요 특징
   • 경량 컨테이너: 객체의 생성과 소멸을 포함한 생명 주기를 관리합니다.
   • DI 지원: 외부에서 두 객체 간의 관계를 결정하여 결합도를 낮춥니다.
   • AOP 지원: 비즈니스 로직과 공통 관심 사항(로깅, 보안 등)을 분리하여 재사용성을 높입니다.
   • POJO 지원: 특정 인터페이스나 상속이 필요 없는 일반 자바 객체를 지원하여 유연성을 제공합니다.
   • 트랜잭션 관리: 일관된 방법으로 트랜잭션을 처리할 수 있습니다.
   • 데이터 영속성 지원: 다양한 데이터베이스 접근 기술(JPA, Hibernate, JDBC)과 쉽게 연동됩니다.
   • API 연동: JMS, 메일, 스케줄링 등 엔터프라이즈 기능을 쉽게 통합합니다.
3. Spring MVC
   • MVC 패턴을 기반으로 웹 애플리케이션을 설계할 수 있도록 지원합니다. 클라이언트의 요청을 Controller에서 받아 Model을 통해 비즈니스 로직을 처리하고, 최종 결과를 View로 출력합니다.

Spring의 핵심 개념

1. IoC (Inversion of Control) - 제어의 역전
   • IoC는 객체의 생성과 관리 권한을 개발자가 아닌 프레임워크가 맡는 것을 의미합니다. 이를 통해 개발자는 객체 간의 의존성을 직접 설정할 필요 없이, Spring이 이를 관리하도록 맡길 수 있습니다.
   • Spring에서는 주로 XML 설정 파일이나 애너테이션을 사용하여 객체의 생성과 의존성 주입을 제어합니다.
2. DI (Dependency Injection) - 의존성 주입
   • DI는 객체가 다른 객체와의 의존성을 가지는 경우, 필요한 의존성을 외부에서 주입받도록 하는 방식입니다. 이를 통해 객체 간의 결합도를 낮추고, 코드의 재사용성과 유지보수성을 높일 수 있습니다.
   • Spring은 필드 주입, 생성자 주입, 세터 주입 등 다양한 DI 방식을 지원합니다.
3. AOP (Aspect-Oriented Programming) - 관점 지향 프로그래밍
   • AOP는 애플리케이션의 핵심 비즈니스 로직과 부가적인 기능(예: 로깅, 트랜잭션 관리)을 분리하는 데 사용됩니다.
   • Spring AOP를 통해 트랜잭션 관리나 보안 등의 기능을 코드에 직접 작성하지 않고, 특정 관심사(Aspect)로 분리하여 관리할 수 있습니다.
4. MVC (Model-View-Controller) 패턴
   • Spring은 웹 애플리케이션을 구축하기 위해 Spring MVC 모듈을 제공합니다. 이는 모델, 뷰, 컨트롤러를 분리하여 클라이언트 요청을 효과적으로 처리하고 응답을 생성할 수 있도록 설계되었습니다.
   • Spring MVC를 사용하면 클라이언트 요청을 컨트롤러에서 받아, 비즈니스 로직을 처리한 후 적절한 뷰로 데이터를 전달하는 구조를 쉽게 구현할 수 있습니다.

Spring의 주요 모듈

Spring은 다양한 모듈로 구성되어 있으며, 각 모듈은 특정 기능을 제공하여 전체 애플리케이션의 효율성과 생산성을 높입니다.

1. Spring Core:
   • Spring의 기본적인 DI와 IoC 기능을 제공하는 모듈로, Spring Framework의 근간이 됩니다. 모든 Spring 애플리케이션은 이 Core 모듈을 사용하여 객체 생성과 의존성 관리를 수행합니다.
2. Spring AOP:
   • AOP(Aspect-Oriented Programming) 기능을 제공하여, 비즈니스 로직에 영향을 주지 않고 로깅, 보안, 트랜잭션 관리와 같은 부가 기능을 구현할 수 있습니다.
3. Spring MVC:
   • 웹 애플리케이션을 위한 MVC 패턴을 구현한 모듈로, RESTful 웹 서비스 개발에도 많이 사용됩니다. 클라이언트의 요청을 컨트롤러가 처리하고, 필요한 뷰를 생성하는 구조를 지원합니다.
4. Spring Data:
   • 데이터베이스와의 연동을 쉽게 하기 위한 모듈로, JPA, MongoDB, Redis 등의 데이터베이스를 다루는 기능을 제공합니다. 개발자는 직접 쿼리를 작성하지 않고도 데이터를 CRUD(Create, Read, Update, Delete)할 수 있습니다.
5. Spring Security:
   • 인증과 인가 기능을 제공하는 보안 모듈로, 사용자 인증, 권한 관리, 접근 제어 등을 제공합니다. 이를 통해 안전한 애플리케이션을 구축할 수 있습니다.
6. Spring Boot:
   • Spring Boot는 Spring Framework를 쉽게 시작할 수 있도록 돕는 모듈입니다. 자동 설정 기능을 제공하여, 최소한의 설정으로 애플리케이션을 빠르게 개발할 수 있습니다. 개발자가 더 이상 복잡한 XML 설정을 작성할 필요 없이, 기본 설정으로 시작할 수 있습니다.
7. Spring Cloud:
   • 클라우드 환경에서 마이크로서비스를 개발할 수 있도록 지원하는 모듈입니다. 마이크로서비스의 구성, 로드 밸런싱, 분산 트랜잭션 등을 관리하기 쉽게 합니다.

Spring을 사용한 애플리케이션 개발 흐름

1. 객체 간의 의존성 설정 (IoC와 DI)
   • Spring을 통해 애플리케이션에 필요한 객체 간의 의존성을 설정합니다. XML 또는 애너테이션을 통해 객체 간의 관계를 정의하고, Spring이 이를 관리하게 합니다.
2. 컨트롤러 작성 (Spring MVC)
   • Spring MVC를 사용하여 클라이언트 요청을 처리할 컨트롤러 클래스를 작성합니다. 각 컨트롤러는 URL 매핑을 통해 클라이언트의 요청을 특정 메서드로 연결하며, 요청을 처리한 후 적절한 뷰로 응답을 보냅니다.
3. 비즈니스 로직 구현 (Service 계층)
   • 비즈니스 로직을 서비스 계층에 작성하여, 컨트롤러와 분리합니다. 서비스 계층에서는 주로 DAO(Data Access Object)와 협력하여 데이터베이스와의 상호작용을 처리합니다.
4. 데이터 처리 (Spring Data)
   • Spring Data JPA를 사용하여 데이터베이스와 상호작용합니다. Spring Data는 CRUD 작업을 추상화하여, 데이터베이스와의 작업을 더 쉽게 수행할 수 있도록 돕습니다.
5. 보안 설정 (Spring Security)
   • Spring Security를 사용하여 애플리케이션의 보안을 설정합니다. 권한별 접근 제어를 설정하거나, 인증 절차를 구성하여 애플리케이션을 보호할 수 있습니다.

Spring의 장점

1. 의존성 관리의 용이성: IoC와 DI를 통해 객체 간의 결합도를 낮춰 유연하고 확장성 있는 애플리케이션을 개발할 수 있습니다.
2. 모듈화된 구조: Spring은 필요한 모듈만 선택적으로 사용하여, 애플리케이션에 필요한 기능만을 구현할 수 있게 합니다.
3. 확장성과 유지보수성: Spring은 구조가 일관되어 있어 유지보수가 쉽고, 모듈 확장이 용이하여 대규모 애플리케이션에 적합합니다.
4. 방대한 커뮤니티와 지원: Spring은 방대한 사용자 커뮤니티와 풍부한 문서가 있어 학습과 문제 해결이 비교적 쉽습니다.
5. Spring Boot로 간편한 설정: Spring Boot는 자동 설정 기능을 통해 빠르게 애플리케이션을 개발할 수 있도록 지원하며, 특히 간단한 웹 애플리케이션 개발에 유리합니다.

자료 및 링크

Spring

Spring Framework

Spring Documentation - Core Concepts 표준프레임워크 포털 eGovFrame