TIL - 2025.03.06

[Yumi-Park996]

Public record

📌 1. public record란?

✅ 정의

• record는 불변 데이터 객체(Immutable Data Object)를 간단하게 표현할 수 있게 해주는 Java 16에서 정식 도입된 기능입니다.

• 데이터를 담는 객체(DTO)를 만들 때 getter, equals(), hashCode(), toString() 같은 보일러플레이트 코드 작성을 자동화해줍니다.

• 필드는 기본적으로 final이기 때문에, 한 번 값이 설정되면 변경 불가능합니다.

📌 2. 왜 나왔을까? (기존 문제점)

예전 DTO 작성 방식 (Java 클래스)

public class Person {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() { return name; }
    public int getAge() { return age; }

    @Override
    public boolean equals(Object o) { /* equals 구현 */ }
    @Override
    public int hashCode() { /* hashCode 구현 */ }
    @Override
    public String toString() { /* toString 구현 */ }
}

• DTO는 주로 데이터를 담고 전달하는 역할인데, 매번 이런 보일러플레이트 코드를 작성해야 했습니다.
• 불필요한 코드가 많아 가독성 저하 & 유지보수 부담 증가.

개선: record

public record Person(String name, int age) { }

• 단 1줄로 끝!
• 생성자, getter, equals, hashCode, toString 자동 생성
• 필드는 final로 강제 → 불변성 보장

📌 3. public record 특징 요약

특징	설명
보일러플레이트 제거	생성자, getter, equals, hashCode, toString 자동 생성
불변성	필드가 자동으로 final 처리 (수정 불가)
상속 불가	record는 final이라 상속할 수 없음
명확한 목적	순수 데이터 저장 및 전달용으로 최적화
컴팩트한 문법	필드 선언만 하면 끝!

---

📌 보일러플레이트란?

• 매번 똑같이 작성해야 하는 필수 코드.
• 실제 로직이나 핵심 기능과는 별 상관없는데, 언어나 프레임워크 특성상 꼭 필요한 코드.
• 안 쓰면 동작은 안 되지만, 쓰는 게 너무 번거롭고 비효율적인 코드들.

📌 보일러플레이트 정리

특징	내용
의미	반복적이고, 거의 의미 없는 필수 코드
예시	getter, setter, 생성자, toString, equals, hashCode
문제	반복 작성으로 가독성 저하, 실수 가능성 증가
해결책	record, Lombok @DaTa, IDE 자동 생성 기능 등

💡 왜 이름이 "Boilerplate"일까?

• 원래는 인쇄·출판 업계 용어
• 틀(Template)처럼 복사해서 쓰는 내용을 의미
• 코딩에서도 거의 똑같은 구조로 반복되니까 같은 의미로 사용

📚 한 줄 정리

보일러플레이트란, 의미는 별로 없지만 언어 특성상 반복적으로 써야 하는 코드

[Yumi-Park996]

naver-search-v2 파악 및 분석

1. 강의 의도

지금 수업에서 배우는 핵심은 다음 4가지입니다.

① 웹 서비스 개발 방법 (Servlet 기반)

• 웹 서비스는 클라이언트(브라우저)가 서버에 요청을 보내고, 서버가 응답을 주는 프로그램입니다.
• 그 서버 쪽 프로그램을 만드는 게 바로 **서블릿(Servlet)**입니다.
• 웹 브라우저가 http://내서버주소/search?keyword=코딩 이렇게 요청하면,
• 서버 쪽에서 서블릿이 이 요청을 받고, 네이버 API에 요청 보내고, 결과를 다시 클라이언트한테 주는 역할을 합니다.

② 네이버 API 사용법

• 서버에서 네이버 API를 호출해서 검색 결과를 받아오는 기능을 만들고 있습니다.
• 외부 서비스(API)를 내 서비스 안에서 사용하는 방법을 배우는 겁니다.

③ Docker로 배포하는 방법

• Docker는 내 프로그램을 실행하는 환경을 통째로 감싸서 어디서든 똑같이 실행되게 해주는 도구입니다.
• 내 개발 환경(내 컴퓨터)과 서버 환경(클라우드)이 다르면 에러가 날 수 있는데, Docker로 감싸면 어디서든 똑같이 돌아갑니다.
• 서블릿 프로젝트를 Docker로 감싸서 배포하는 방법을 배우는 겁니다.

④ Render에 배포하는 방법

• Render는 무료로 Docker 같은 걸 올려서 실제 웹 서비스로 사용할 수 있게 해주는 서비스입니다.
• 네이버 검색 API를 활용하는 내 프로그램을 실제로 인터넷에서 사용할 수 있게 배포하는 방법을 배우는 거예요.

---

2. 각 파일의 의미 (한 줄씩 상세 설명)

📁 config

ServletConfig.java

• 톰캣이 웹 서비스를 시작하거나 종료할 때 실행되는 프로그램.
• 서버 시작할 때 필요한 초기 설정이나 정리 작업할 때 사용.
• 지금은 "서버 시작됨", "서버 종료됨" 로그만 찍고 있지만, 실제로는 DB 연결 같은 것도 여기에 넣을 수 있음.

---

📁 controller

SearchController.java

• 클라이언트(웹 브라우저)가 /search 주소로 요청하면, 이 서블릿이 실행됨.
• 클라이언트가 넘긴 keyword 파라미터를 받아서,
• SearchService.java를 호출해서 네이버 검색 결과를 받아오고,
• 받아온 검색 결과를 JSON 형태로 클라이언트에게 보내줌.

---

📁 model

APIClientParam.java

• 네이버 API 요청할 때 필요한 정보를 담는 클래스.
• URL, 요청 방식(GET, POST), 요청 본문(body), 헤더 같은 걸 담음.

NaverAPIResultItem.java

• 네이버 검색 결과 한 건을 저장하는 클래스.
• 기사 제목, 링크, 설명, 날짜를 저장.

NaverAPIResult.java

• 네이버 검색 결과 전체를 저장하는 클래스.
• 검색 결과 리스트와 API 응답 시간을 저장.

---

📁 service

SearchService.java

• 실제 네이버 API를 호출하는 핵심 로직.
• 검색 키워드를 받아서 네이버 API를 호출하고, 결과를 파싱해서 리스트로 반환.
• API 호출은 APIClient라는 클래스가 실제로 하고, 여기는 그걸 호출하는 역할.

---

📁 util

APIClient.java

• 실제로 네이버 API 서버에 HTTP 요청을 보내는 클래스.
• HttpClient를 이용해서 네이버 서버에 GET 요청을 보내고, 응답을 받아서 그대로 반환.

MyLogger.java

• 로그 찍는 클래스.
• 개발 모드에서는 더 많은 로그를 보여주고, 운영 모드에서는 중요한 로그만 보여줌.
• 환경변수(MODE)가 DEV면 정보 로그(INFO)를, PROD면 에러 로그(SEVERE)만 출력하게 설정되어 있음.

---

📁 webapp

web.xml

• 웹 서비스 전체 설정 파일.
• 원래는 서블릿 등록, 필터 등록 같은 걸 여기에 적는데,
• 지금은 @WebServlet으로 서블릿 등록해서 비어 있음.
• 그래도 없어도 되는 건 아님. 기본적인 프로젝트 구성으로 필요.

---

📄 pom.xml

• Maven 프로젝트 설정 파일.
• 어떤 라이브러리를 쓸지, Java 버전은 몇인지 적는 파일.
• 빌드할 때 필요한 정보들이 여기 다 있음.

---

📄 Dockerfile

• Docker로 감싸기 위한 설정 파일.
• 이 파일을 보면, 프로젝트를 어떻게 감싸서 Docker 이미지로 만들지 알 수 있음.
• 지금은 두 단계로 나눠서:
  1. Maven으로 Java 프로그램(war 파일)을 먼저 만들고
  2. 그 war 파일을 Tomcat 서버에 올리는 구조

---

3. tomcat+docker로 바꾸기 위해 건드릴 파일 (실제로 필요한 작업들)

✅ 필요한 작업 정리

1. Dockerfile 작성 (현재는 이미 있음)

• 현재 Dockerfile은 기본적으로 잘 작성되어 있음.
• 다만 아래 부분은 꼭 확인해야 함.
  • target/파일명.war 파일 이름 정확히 맞추기
  • (지금은 naver-search-v2-1.0-SNAPSHOT.war로 나올 가능성 높음)

---

2. 환경변수 설정

• 네이버 API 키 같은 건 코드에 직접 적지 않고, 환경변수로 관리해야 함.
• Render에서는 이 환경변수를 따로 설정해줘야 함.
• Render 대시보드 → Environment 탭에서 NAVER_CLIENT_ID, NAVER_CLIENT_SECRET, MODE 이런 걸 추가해야 함.

---

3. Render에 Docker 서비스로 연결

• Render에서 새 웹 서비스 만들 때 "Deploy from GitHub" 선택.
• GitHub 리포지토리 연결.
• Dockerfile 자동 인식해서 빌드하고 배포.

---

4. 톰캣 기본 포트는 8080

• Render가 외부에서 접근할 수 있게 포트 설정은 기본적으로 8080으로 맞춰야 함.
• Dockerfile에서 EXPOSE 8080으로 이미 지정되어 있음.
• Render에서도 8080으로 서비스 오픈됨.

---

5. 테스트

• 배포 완료되면, Render에서 나온 URL로 접속.
• 예: https://내서비스.onrender.com/search?keyword=뉴스
• 이런 식으로 직접 네이버 검색 결과를 받아볼 수 있음.

---

4. Servlet은 꼭 필요해?

반드시 필요함.

• 지금 프로젝트는 서블릿 프로젝트입니다.
• 서블릿은 클라이언트 요청을 받고, 필요한 작업을 하고, 응답을 보내주는 역할.
• 서블릿이 없으면 톰캣 서버에서 실행할 수 없습니다.
• 지금은 @WebServlet("/search")로 매핑해놨기 때문에, 톰캣이 알아서 이 서블릿을 등록하고 실행해줍니다.

---

결론 (요점 정리)

단계	작업 내용
1	코드 작성 (현재 거의 다 작성됨)
2	Dockerfile 작성 (이미 있음, 이름만 확인)
3	환경변수 관리 (.env → Render 환경변수로 이전)
4	Render에서 Docker 서비스로 배포
5	배포 URL 확인하고 테스트 (서버+네이버 API 연동 확인)

[Yumi-Park996]

naver-search-v2 파악 및 분석

1. Express, Glitch로도 가능하지 않아?

✔️ 맞아요! 가능합니다.

Express는?

• Node.js로 서버 만드는 도구.
• app.get('/search', ...) 이런 식으로 요청 받고, 응답하는 역할을 합니다.
• 서블릿이랑 역할은 똑같아요.
• 차이점은 언어가 다릅니다.
  • 서블릿 = 자바(Java)
  • Express = 자바스크립트(Node.js)

Glitch는?

• Glitch는 개발 환경을 제공하는 서비스일 뿐입니다.
• 거기에 Express 서버를 만들 수 있는 거예요.
• Glitch = 개발 환경 (온라인 에디터 제공)
• Express = 서버 프레임워크 (서버 로직 담당)

결론

• 기능 자체는 똑같이 만들 수 있음.
• 단, 지금 강의는 **자바 기반 웹 서비스 (서블릿)**을 배우는 수업이라 Express 대신 서블릿을 배우는 거예요.
• 언어와 프레임워크가 다를 뿐, 하는 일은 거의 비슷합니다.

---

2. Docker로 감싸면 서버 배포 끝이야?

✔️ 거의 맞아요, 하지만 완벽히 끝은 아닙니다.

Docker로 감싸는 게 뭐냐?

• 내 프로그램 + 프로그램이 실행되는 환경(자바 버전, 톰캣 버전 등)을 하나로 포장.
• 이걸 **이미지(Image)**라고 부릅니다.
• 이 이미지를 서버에서 실행시키면 **컨테이너(Container)**가 됩니다.

그럼 Docker로 감싸면 바로 인터넷에서 접근할 수 있어?

• ❌ 그건 아님.
• Docker로 감싸면 실행은 되지만, 외부에서 접근할 수 있는 주소는 따로 필요.
• Render 같은 서비스가 바로 "인터넷에서 접근할 수 있는 주소(URL)를 제공"하는 역할을 합니다.
• 즉, Docker + Render가 합쳐져야 진짜 배포 끝.

정리

단계	설명
1	프로그램을 Docker로 감싼다 (이미지 생성)
2	Render 같은 서비스에 Docker 이미지를 올린다
3	Render가 외부에서 접속할 수 있는 주소를 준다 (https://내서비스.onrender.com)

---

3. 파일 이름 정확히 맞추라는 게 무슨 말이야?

💡 Maven이 만든 파일 이름과 Dockerfile에서 찾는 파일 이름이 일치해야 한다는 뜻입니다.

지금 Dockerfile 보면 이런 줄 있어요:

COPY --from=builder /app/target/*.war /usr/local/tomcat/webapps/ROOT.war

이게 무슨 뜻이냐면?

• Maven이 만든 파일은 target 폴더 안에 저장돼요.
• 예를 들어, 프로젝트 이름이 naver-search-v2면 기본적으로

  target/naver-search-v2-1.0-SNAPSHOT.war
  

  이런 이름으로 파일이 만들어져요.
• 근데 Dockerfile에서는 그냥 *.war로 적어놨죠? 이러면 파일이 하나만 있으면 알아서 선택해요.
• 근데 혹시라도 파일 이름이 예상과 다르면 Dockerfile이 찾지 못할 수 있어요.
• 그래서 Maven이 만든 파일 이름과 Dockerfile에서 참조하는 파일 이름을 꼭 확인하라는 뜻입니다.

📌 추천 방법

• 실제로 빌드해보고, target 폴더 안에서 파일 이름을 확인한 뒤, Dockerfile에서 그 이름을 정확하게 적는 게 안전합니다.
• 예)

COPY --from=builder /app/target/naver-search-v2-1.0-SNAPSHOT.war /usr/local/tomcat/webapps/ROOT.war

---

4. 톰캣 기본 포트 8080 어떻게 설정해?

✔️ Dockerfile에서 이미 설정되어 있어요.

EXPOSE 8080

이게 무슨 뜻?

• Docker 컨테이너 안에서 톰캣이 8080번 포트에서 대기하도록 만든다는 뜻.
• 그리고 Render는 기본적으로 Docker 컨테이너의 8080 포트를 인터넷에 열어줍니다.
• 그래서 특별히 더 설정할 건 없어요.

클라이언트가 접속할 때는?

• Render가 주는 주소로 접속하면, 그 주소가 자동으로 8080으로 연결됩니다.
  • 예: https://naver-search-v2.onrender.com
  • 내부적으로는 https://naver-search-v2.onrender.com:8080 이렇게 된다고 보면 됩니다.
• 따라서 별도 설정 안 해도 됩니다.

---

5. 톰캣이 뭐야? 왜 필요해?

💡 톰캣 = 서블릿 전용 웹 서버

웹 서버란?

• 브라우저 요청을 받고, 요청에 맞는 응답을 보내주는 프로그램.
• 대표적으로 아파치, NGINX 등이 있어요.

근데 서블릿은?

• 서블릿은 자바로 작성된 웹 프로그램입니다.
• 서블릿은 그냥 웹 서버에서 바로 실행되지 않습니다.
• 서블릿을 실행할 수 있는 특별한 서버가 필요합니다.
• 그게 바로 **톰캣(Tomcat)**입니다.

왜 톰캣이 필요한가?

• 자바 서블릿 프로그램은 톰캣 없으면 실행이 안 됩니다.
• 톰캣은 서블릿이 동작할 수 있는 "환경"을 제공합니다.
• 예를 들어, 서블릿 매핑, 요청 파싱, 응답 작성 같은 걸 톰캣이 알아서 해줍니다.

정리

구분	설명
일반 웹 서버	정적인 HTML/CSS 파일 제공 (아파치, NGINX)
톰캣	서블릿을 실행시켜주는 서버
서블릿	자바로 만든 웹 프로그램 (요청 받고 응답하는 역할)
Docker + 톰캣	서블릿 프로그램을 어디서든 실행할 수 있게 포장하는 방법

---

추가 보너스 - 전체 흐름 정리

1. 서블릿으로 프로그램 작성
2. Maven으로 war 파일 빌드
3. Docker로 톰캣 + war 파일 감싸기
4. Render에 Docker 이미지 올리기
5. Render가 인터넷 주소 제공
6. 브라우저에서 주소로 접속해서 서비스 확인

---

초보를 위한 비유 없는 핵심 요약

개념	설명
서블릿	자바로 만든 웹 프로그램 (요청 받고 응답)
톰캣	서블릿을 실행시켜주는 서버 프로그램
Docker	프로그램+환경을 하나로 감싸서 어디서든 실행되게 하는 도구
Render	Docker로 감싼 프로그램을 인터넷에 공개해주는 서비스
EXPOSE 8080	Docker 컨테이너 안에서 8080 포트를 열어둠
Dockerfile	Docker가 프로그램을 감쌀 때 참고하는 설명서

[Yumi-Park996]

naver-search-v2 파악 및 분석

servlet 코드 주석

// 패키지 선언 - 이 클래스가 속한 패키지를 정의합니다.
package controller.search;

// JSON 데이터 처리를 위한 라이브러리
import com.fasterxml.jackson.databind.ObjectMapper;

// 서블릿 관련 라이브러리 (서블릿의 부모 클래스 역할)
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 model.dto.NaverAPIResultItem;

// 실제 네이버 API를 호출하고 결과를 가져오는 서비스 클래스
import service.search.SearchService;

// 예외 처리 및 입출력 관련 라이브러리
import java.io.IOException;
import java.io.PrintWriter;
import java.util.List;

// 이 서블릿 클래스가 "/search"로 들어오는 요청을 처리하겠다고 선언하는 부분
// Express로 치면 app.get('/search', ...)에 해당
@WebServlet("/search")
public class SearchController extends HttpServlet {

    // HTTP GET 요청이 왔을 때 실행되는 메서드
    // Express로 치면 app.get('/search', (req, res) => {}) 안에 들어가는 함수 역할
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        // 요청에서 keyword라는 이름의 쿼리 파라미터 값을 꺼냄
        // 예: /search?keyword=코딩 이면 "코딩"이 들어옴
        String searchKeyword = req.getParameter("keyword");

        // 클라이언트에 보낼 JSON 문자열을 담을 변수
        String json;

        try {
            // 서비스 객체 생성 (네이버 API 호출 로직을 담당하는 객체)
            SearchService searchService = new SearchService();

            // 네이버 API에서 keyword로 뉴스 검색 결과를 받아오는 부분
            // result는 뉴스 검색 결과의 목록(List)
            List<NaverAPIResultItem> result = searchService.searchByKeyword(searchKeyword);

            // JSON 변환기 (자바 객체 -> JSON 문자열로 바꾸는 도구)
            ObjectMapper objectMapper = new ObjectMapper();

            // 검색 결과 리스트(List)를 JSON 문자열로 변환
            // Express에서 res.json() 하는 거랑 비슷한 역할
            json = objectMapper.writeValueAsString(result);

        } catch (Exception e) { // 만약 에러가 발생하면
            // HTTP 상태 코드를 500으로 설정 (서버 에러)
            resp.sendError(500);

            // 에러 메시지를 JSON 형태로 구성
            // Express에서는 res.status(500).json({...}) 와 비슷한 역할
            json = """
                    {
                    "error": "%s"
                    }
                    """.formatted(e.getMessage());  // 실제 에러 메시지를 삽입
        }

        // 응답을 JSON 형식으로 보내기 위해 컨텐츠 타입을 지정
        resp.setContentType("application/json");

        // 응답의 문자 인코딩을 UTF-8로 지정 (한글 깨짐 방지)
        resp.setCharacterEncoding("UTF-8");

        // 실제로 응답을 클라이언트(브라우저)에게 전송하는 출력 스트림 준비
        PrintWriter out = resp.getWriter();

        // 준비해둔 JSON 데이터를 응답 본문으로 출력
        out.print(json);

        // 출력 스트림 닫기 (출력 마무리)
        out.flush();
    }
}

[Yumi-Park996]

깨알 상식

Servlet은 왜 Jakarta일까?

1. 원래 이름은 Java Servlet이었다

과거에는 서블릿을 그냥 Java Servlet이라고 불렀어요.
왜냐하면, 자바 언어로 만든 웹 요청/응답 처리 기술이니까 딱 맞는 이름이었죠.

---

2. 왜 이름이 바뀌었을까?

이유: 오라클과 아파치 재단 싸움 때문

• 원래 **자바(Java)**는 오라클(Oracle)이 소유하고 있어요.
• 근데 **서블릿, JSP 같은 기술은 아파치 재단(Apache Foundation)**이 관리하고 있었어요.
• "자바"라는 단어는 오라클 상표권이라서, 아파치가 자기들이 관리하는 기술 이름에서 "Java"를 못 쓰게 된 거예요.

---

3. 그래서 새 이름: Jakarta Servlet

• "Java Servlet"이라는 이름을 못 쓰니까, 아파치 재단이 Jakarta Servlet으로 이름을 바꾼 거예요.
• 여기서 "Jakarta"는 아파치 재단이 예전에 운영하던 프로젝트 그룹 이름이에요.
• 원래는 아파치에서 다양한 오픈소스 프로젝트를 묶어서 관리하던 팀 이름이 "Jakarta Project"였어요.
• 옛날 이름 재활용한 거죠.

---

4. 정리

시기	이름	설명
옛날	Java Servlet	정식 이름 (자바 기반 서블릿 기술)
지금	Jakarta Servlet	오라클과 싸움 끝에 바뀐 이름

[Yumi-Park996]

Snowflake Server VS Phoenix Server

🧊 1. Snowflake Server Pattern (눈송이 서버 패턴)

❄️ 개념

• 서버마다 환경 설정, 라이브러리 버전, OS 패키지, 설정 파일 등이 전부 제각각인 상황.
• 즉, 세상에 하나밖에 없는 서버(눈송이처럼 독특한 서버)들이 생기는 거야.
• 같은 서비스라도 서버마다 설정이 다 달라서, 운영, 배포, 디버깅이 엄청 어려움.

❄️ 문제점

• 버그 재현 어려움: 개발 서버에서는 안 나는데, 운영 서버에서만 에러?
• 배포 리스크 증가: "서버 1은 잘 됐는데, 서버 2는 또 에러네?"
• 운영 효율 저하: 서버 이전(마이그레이션)하거나, 신규 서버 추가할 때마다 설정 새로 해야 함.

❄️ 왜 이런 일이 생김?

• 수동으로 설정하거나, 서버마다 담당자가 달랐던 경우.
• 서버마다 핫픽스 적용 시점이 다르고, 설정을 깜빡해서 빠진 것도 있고...
• 이런 환경에서 **서블릿 컨테이너 (Jetty, Tomcat)**도 서버마다 설정이 다르니까 관리가 지옥임.

❄️ 요즘은?

• Docker 같은 컨테이너로 패키징해서 "어디서나 똑같이" 돌려버리는 방식 선호.
• 서버 설정도 코드로 관리 (Infra as Code, IaC).
• 서버 자체를 눈송이처럼 다르게 만드는 게 아니라, 모든 서버가 똑같은 이미지에서 만들어지도록 함.

---

🔥 2. Phoenix Server Pattern (피닉스 서버 패턴)

🐦 개념

• 서버는 언제든 새로 만들 수 있음.
• 서버 설정, 애플리케이션 환경, 구성 정보 등이 전부 코드화돼있고,
• 필요할 때마다 서버를 불사조처럼 새로 생성해서 부활하는 방식.
• 기존 서버 고쳐 쓰는 게 아니라, 필요할 때마다 신규 서버 생성해서 서비스.

🐦 특징

• 서버 수명이 짧음.
• 고장 나면 고치는 게 아니라, 그냥 새로 만듦.
• 서버 자체가 소모품처럼 다뤄짐 (Cattle, 가축 서버라고도 함).
• Docker, Kubernetes 같은 컨테이너 환경에서 자연스럽게 구현 가능.

🐦 요즘 트렌드

• 클라우드 환경에서는 거의 기본.
• 서버 자체를 사랑하지 않고, 그냥 필요하면 생성하고, 필요 없으면 날리는 방식.
• Immutable Infrastructure (불변 인프라)랑 찰떡궁합.

---

✅ 정리 포인트

• Snowflake 서버 = 골치 아픈 레거시 서버 패턴
• 서버마다 설정이 달라서 문제 덩어리.
• Phoenix 서버 = 요즘 힙한 서버 패턴
• 고치지 말고, 언제든 새로 뽑아서 쓰는 방식.

[Yumi-Park996]

🔥 Phoenix 서버 패턴 = 힙한 이유 (한줄 요약)

"고치지 말고, 그냥 새로 뽑아서 써라!"
(기존 서버 붙잡고 고생하지 말고, 새 서버 뚝딱 만들어서 바꿔치기하는 거)

---

🧵 왜 힙한데? (배경 설명)

옛날 서버 관리 방식 (눈송이 서버 시절)

• 서버를 만들면 그 서버 하나를 소중히 아낌.
• 서버에 버그 생기면 → 서버 접속해서 설정 고치고, 로그 보고, 삽질하면서 고쳐야 함.
• 서버 100대면? → 100대 다 제각각 상태임.
  (심지어 담당자가 다르면 더 난리남)
• 이게 Snowflake Server Pattern (= 골치 아픈 구시대 유물)

요즘 서버 관리 방식 (Phoenix 서버 패턴)

• 서버를 아끼지 않음. 사랑하지 않음.
• 고장 나거나 버그 생기면?
• 서버 버린다 (안 고친다)
• 새 서버 바로 만든다 (자동화로 뚝딱 생성)
• 고치는 데 시간 안 씀. 새로 뽑는 게 더 빠르고 안전함.
• 이게 Phoenix Server Pattern (= 힙한 트렌드)

---

🐳 도커랑 왜 찰떡궁합인데?

도커 없는 시절에는?

• 서버 새로 뽑으려면
• OS 설치하고
• 라이브러리 설치하고
• 서버 설정하고
• 서비스 올리고
• 테스트하고
• 이거 반복하려면? 골치 아프고 시간 엄청 걸림.
• 그러니까 기존 서버 고쳐 쓰는 게 편해서 Snowflake 패턴이 많았음.

도커 있으면?

• 서버 구성 자체를 도커 이미지로 만들어서 보관.
• 필요할 때마다 도커 이미지로 새 컨테이너 생성.
• 이 과정이 몇 초~몇 분이면 끝남.
• 새 서버 만들 때 수작업 제로.

---

💣 핵심 포인트

• 도커 없을 땐: 서버 새로 뽑기 = 엄청 귀찮고 느림 → 기존 서버 고쳐쓰자!
• 도커 있으면: 서버 새로 뽑기 = 몇 초컷 → 기존 서버 버리고 새로 뽑자!

결과적으로:

패턴	도커 전	도커 후
Snowflake	필요하면 서버마다 손으로 설정	Docker로 서버 구성 통일
Phoenix	새로 뽑는 거 너무 귀찮음	Docker로 새로 뽑는 게 더 쉽고 빠름

---

🌟 그래서 왜 힙한데?

힙한 포인트 총정리

힙한 이유	설명
수명이 짧아서	서버를 고치는 게 아니라, 필요할 때마다 새로 뽑음
자동화 덕분	도커, 쿠버네티스 덕에 서버 새로 뽑는 게 쉽고 빠름
실수 예방	서버 설정 실수? 어차피 새로 뽑을 때 다 똑같이 맞춰서 문제 없음
운영 효율	장애 대응도 "서버 교체"로 해결하니까 운영이 편해짐
확장성	서버 추가/삭제도 자동화돼서 스케일 아웃에 유리함

---

💡 진짜 찐 요점

Phoenix 서버 패턴은
**"서버를 고치지 말고, 언제든 새로 뽑아서 교체하는 방식"**인데,
이게 Docker랑 만나면 진짜로 몇 초만에 서버 교체 가능해져서 개꿀조합인 거임.