메모장

HTML, DevTools Sources에 안 보이는 문제 해결 (sourceURL 사용)

dddzr — Fri, 17 Apr 2026 10:27:57 +0900

개발자 모드에서 디버깅이 필요한데, 소스코드가 보이지 않는 문제가 있었다.

요약

HTML 내부 <script>의 마지막에 다음을 추가

//# sourceURL={파일명지정}.js

1. 문제 상황

서버 렌더링 방식으로 HTML을 반환하는 구조에서,
Chrome DevTools의 Sources 탭에 스크립트가 보이지 않는 문제가 발생.

- 에러 메시지

content unavailable. resource was not cached
요청이 리디렉션되었기 때문에 사용 가능한 콘텐츠가 없습니다.

2. 현재 구조

- 컨트롤러 (서버 렌더링)

@RequestMapping(value = "/openPage.do") 
public ModelAndView openPage(...) {
    ModelAndView mv = setPledgeStatusViewParams(request);
    mv.setViewName(baseUrl + "/page");
    return mv;
}

요청 시 서버에서 page.html을 렌더링하여 반환한다.

3. 원인 분석

3-1. inline script는 “파일”이 아니다

HTML 내부에 다음과 같은 <script>가 있다고 가정한다.

// JS 코드

</script>

이 스크립트는:

별도의 JS 파일이 아님
URL(경로)이 없음
브라우저가 파일로 식별할 수 없음

즉, DevTools 기준에서는 “파일이 아닌 익명 스크립트”이다.

3-2. Chrome의 처리 방식 (VM 파일)

브라우저는 이름 없는 스크립트를 다음과 같이 처리한다.

VM123

VM456

임시 가상 파일(VM)로 생성한다.

이 때문에:

Sources 탭 트리에 안 보이거나
어디 코드인지 찾기 어려움
브레이크포인트 유지 불가

3-3. window.open + redirect 환경 영향

서버 렌더링 과정에서 redirect 발생 가능
캐시가 없는 상태

이 경우 DevTools는:

원본 리소스를 정확히 추적하지 못함
파일 기반으로 매핑 실패

4. 해결 방법: sourceURL 사용

4-1. 적용 코드

sourceURL은 브라우저에게 "이 스크립트의 이름은 이것이다” 라는 정보를 제공한다.

HTML 내부 <script>의 마지막(</script> 윗줄)에 다음을 추가한다.

//# sourceURL=workplace-page.js

workplace-page.js라는 이름으로 소스탭에서 파일 확인이 가능하다.

즉, inline script를 파일처럼 다룰 수 있게 된다.

DevTools에 고정된 파일명으로 표시됨
Sources 트리에 노출됨
브레이크포인트 가능

5. 실무 주의사항

5-1. inline script는 최소화한다

가능하면 외부 JS 파일로 분리하는 것이 가장 안정적이다.

5-2. 동적 실행 환경에서는 디버깅 문제가 발생하기 쉽다

다음 조건이 겹치면 문제가 잘 발생한다.

inline script
window.open
redirect
캐시 없음

이 경우 sourceURL이 매우 유용하다.

자바스크립트 모듈 패턴 (IIFE, Closure)

dddzr — Fri, 10 Apr 2026 11:05:44 +0900

자바스크립트 모듈 패턴을 활용한 안전한 데이터 관리 전략

✅ 1. 개요: 전역 변수 선언의 구조적 취약점

자바스크립트에서 var 키워드를 사용해 파일 최상단에 변수를 선언하는 방식(Global Scope)은 데이터 노출과 오염에 매우 취약하다. 조회용 데이터라 할지라도 브라우저 콘솔을 통해 누구나 접근하고 수정할 수 있다면, 런타임 환경에서 데이터 무결성을 보장할 수 없다. 본 글에서는 즉시 실행 함수(IIFE)와 클로저(Closure)를 활용하여 데이터를 캡슐화하는 모듈 패턴에 대해 기술한다.

✅ 2. 개념 및 패턴 기본 구조

✅ 2-1. 개념

즉시 실행 함수(IIFE): 함수 정의와 동시에 실행되는 패턴으로, 내부 변수가 전역 스코프에 침범하는 것을 방지한다.
클로저(Closure): 함수가 선언될 당시의 렉시컬 환경을 기억하여, 외부 함수가 종료된 후에도 내부 변수에 접근할 수 있는 메커니즘이다.
모듈 패턴(Module Pattern): 클로저를 이용하여 외부에서 접근 불가능한 Private 변수를 생성하고, 필요한 기능만 Public 메서드로 노출하는 설계 방식이다.

✅ 2-2. 기본 구조

var ModuleName = (function() {
    // Private: 외부에서 직접 접근 불가
    var _privateData = []; 

    // Public: 외부로 노출되는 인터페이스
    return {
        setData: function(data) {
            _privateData = data;
        },
        getData: function() {
            return _privateData;
        }
    };
})();

✅ 3. 구조적 개선 비교 (Before vs After)

✅ 3-1. [Before] 전역 변수 방식 (Global Variable)

데이터가 전역 스코프에 노출되어 보안과 관리 측면에서 위험하다.

// 각 JS 파일 최상단 선언
var factoryListRowData = []; 

// 위험성 예시: 콘솔창에서 즉시 변조 가능
// > factoryListRowData = "malicious data"; (기존 데이터 파괴)

✅ 3-2. [After] 모듈 패턴 적용 (Encapsulated)

데이터를 함수 스코프 안에 가두어 외부의 직접적인 접근을 차단한다.

var FactoryModule = (function() {
    var _factoryListRowData = []; // 금고 내부

    return {
        setList: function(list) {
            _factoryListRowData = list;
        },
        getRow: function(id) {
            return _factoryListRowData.find(function(item) {
                return item.portlet_id === id;
            });
        }
    };
})();

// 호출 시: FactoryModule.getRow('ID01');
// 조작 시도: FactoryModule._factoryListRowData; // undefined (접근 불가)

✅ 4. 데이터 검문소 역할을 통한 안정성 확보

단순히 변수를 숨기는 것을 넘어, 모듈 패턴은 데이터의 입구(Setter)에 '검문소'를 세워 데이터 무결성을 확보할 수 있다.

✅4-1. 수정 의도의 명확한 제한 (Validation)

데이터 입력 시 유효성 검사 로직을 포함하여 잘못된 데이터가 유입되는 것을 방지한다.

setList: function(list) {
    if (!Array.isArray(list)) {
        console.error("배열 형식이 아닙니다.");
        return;
    }
    _factoryListRowData = list;
}

✅4-2. 읽기 전용 상태 구현 (Read-Only)

최초 1회만 데이터 저장을 허용하여 런타임 중 의도치 않은 수정을 원천 차단한다.

var isInitialized = false;

return {
    setList: function(list) {
        if (isInitialized) {
            console.warn("이미 초기화된 데이터는 수정할 수 없습니다.");
            return; 
        }
        _factoryListRowData = list;
        isInitialized = true;
    }
};

✅ 4-3. 디버깅의 효율성 증대 (Traceability)

데이터 변경이 일어나는 시점에 로깅이나 스택 추적을 수행하여 오류 발생 원인을 빠르게 파악할 수 있다.

setList: function(list) {
    console.trace("데이터 변경 추적:"); // 호출 스택 출력
    _factoryListRowData = list;
}

✅ 5. 결론: 모듈 패턴의 필요성

모듈 패턴은 관심사의 분리(SoC)를 실현하고, 데이터의 무결성을 보장하며, 예측 가능한 코드를 작성하게 한다. 이는 대규모 프로젝트에서 전역 오염을 방지하고 보안 사고의 실미를 차단하는 가장 기본적인 방어적 프로그래밍의 시작이다!!

인덱스 파편화와 해결 전략

dddzr — Wed, 8 Apr 2026 15:34:00 +0900

UUID PK 사용 시 필수 고려사항: 인덱스 파편화와 해결 전략

이번에 메뉴테이블의 PK를 시스템 확장성을 위해 Sequence 대신 UUID(Universally Unique Identifier)로 변경하는 작업을 진행했다.

하지만 무작위 UUID는 DB 인덱스 성능을 저하 시킬 수 있기에 인덱스 파편화는 UUID PK 채택 시 고려사항 중 하나다!!

인덱스 관리가 필요한 이유와 실무적인 해결책을 정리한다.

1. 인덱스 파편화(Index Fragmentation)의 정의

DB 인덱스는 '번호 순서대로 정렬된 백과사전'과 같다. 데이터를 빠르게 찾기 위해 내부적으로 일정한 정렬 상태를 유지해야 한다.

Sequence(1, 2, 3...) 방식: 새 데이터가 들어오면 기존 인덱스 페이지의 맨 뒤 빈 공간에 차곡차곡 쌓인다. 물리적 저장 순서와 논리적 순서가 일치하여 매우 효율적이다.
UUID(Random) 방식: 새 값의 ID가 a1..., f5... 처럼 무작위다. 이미 데이터가 꽉 찬 사전 중간 어딘가에 억지로 끼워 넣어야 하는 상황이 발생한다.
페이지 분할(Page Split): 중간에 자리가 없으면 DB는 기존 데이터를 옆으로 밀거나, 공간 확보를 위해 페이지를 반으로 쪼개는(Page Split) 작업을 수행한다.

이 과정이 반복되면 인덱스 페이지 내부에 사용하지 않는 빈 공간이 생기고 데이터가 물리적으로 흩어지게 된다. 이를 **'인덱스 파편화'**라고 부른다!!

2. 인덱스 관리가 필요한 이유 (정렬, 검색 성능)

비즈니스 로직에서 ORDER BY menu_id를 호출하지 않더라도, 단건 검색(WHERE menu_id = '...') 성능에 직접적인 타격을 준다.

✅ 이유 1: 검색 효율(Select) 저하

파편화가 심해지면 DB가 읽어야 할 '페이지' 수가 늘어난다.

정상 상태: 데이터 100개가 페이지 1장에 모여 있음 → 디스크 I/O 1회 발생.
파편화 상태: 데이터 100개가 쪼개진 페이지 10장에 흩어져 있음 → 디스크 I/O 10회 발생.
결과적으로 동일한 데이터를 조회하더라도 서버 자원을 더 많이 소모하고 응답 속도가 느려진다.

✅ 이유 2: 삽입 성능(Insert) 저하

데이터를 저장할 때마다 최적의 위치를 계산하고 페이지를 쪼개는 추가 연산이 발생한다. 데이터가 쌓일수록 저장 속도가 점진적으로 저하되는 원인이 된다.

3. 실무적인 DB 설계 및 대응 전략

Oracle 등 주요 DBMS 환경에서 이를 방어하기 위한 3가지 전략이다.

✅ 전략 1: 일반적인 Heap 테이블 방식

데이터는 빈 공간에 자유롭게 쌓고(Heap), 인덱스만 별도로 정렬하여 관리하는 가장 보편적인 방식이다.

정렬, 검색의 기준이 되는 데이터로 보조 인덱스를 생성한다.
만약 정렬/검색이 전혀 이루어 지지 않는다면 보조 인덱스 생성은 생략.

-- 테이블 생성 (PK는 UUID)
CREATE TABLE MENU (
    MENU_ID      VARCHAR2(32) NOT NULL,
    MENU_NM      VARCHAR2(100),
    SORT_NUMBER  NUMBER(5), -- 비즈니스 정렬용 컬럼
    CREATED_AT   DATE DEFAULT SYSDATE,
    CONSTRAINT PK_MENU PRIMARY KEY (MENU_ID)
);

-- 실제 조회가 빈번한 SORT_NUMBER와 생성일자에 보조 인덱스 생성
CREATE INDEX IX_MENU_SORT ON MENU (SORT_NUMBER, CREATED_AT);

-- 사용 여부와 메뉴명을 묶은 인덱스 
CREATE INDEX IX_MENU_NAME_SEARCH ON MENU (USE_YN, MENU_NM);

✅ 전략 2: 인덱스 리빌드 (운영 단계)

랜덤 UUID를 사용 중이라면, 정기적으로 인덱스를 재구성하여 빈 공간을 제거해야 한다.

메뉴 ID(PK)로 검색할 때 성능(속도)를 위해 필요하다.
메뉴 ID(PK)로 검색하는 로직이 아예 없고, 오직 메뉴명(MENU_NM)으로만 검색한다면 PK 인덱스 리빌드는 신경 쓰지 않아도 된다.
보통 트래픽이 적은 시간대에 배치 작업으로 수행하여 인덱스 밀도를 높인다.

-- 서비스 중단 없이 인덱스 재구성 (Oracle 기준)
ALTER INDEX PK_MENU REBUILD ONLINE;

✅ 전략 3: Sequential UUID (설계 단계 - 권장)

가장 근본적인 해결책이다. Java 등 애플리케이션 레이어에서 UUID v7이나 Sequential UUID 라이브러리를 사용하여 식별자를 생성한다.

특징: UUID의 유일성은 유지하되, 앞부분에 타임스탬프를 포함하여 생성 순서대로 정렬되는 성질을 갖는다.
장점: DB 입장에서는 데이터가 순차적으로 들어오는 것으로 인식하여 페이지 분할을 방지하고 삽입 성능을 극대화할 수 있다.

요약 및 결론

현상: 랜덤 UUID는 인덱스 중간에 삽입되며 '페이지 분할'과 '파편화'를 유발한다.
결과: 직접적인 정렬 로직이 없더라도 조회 성능 저하와 디스크 자원 낭비로 이어진다.
결론: 신규 설계 시 Sequential UUID 도입을 최우선으로 검토하고, 운영 중인 시스템은 Index Rebuild를 통해 성능을 유지해야 한다.

Functional Interface(함수형 인터페이스)

dddzr — Tue, 7 Apr 2026 09:54:13 +0900

1. Functional Interface(함수형 인터페이스)란?

단 하나의 추상 메서드만 가지는 인터페이스를 말함. (default, static 메서드는 추가로 있어도 상관x)
이 인터페이스를 사용하면 람다식(Lambda Expression)이나 메서드 참조(Method Reference)로 구현 가능.
자바 8부터 도입됨.

즉, “하나의 기능을 표현하는 인터페이스”라고 생각하면 편함.

예시

// *@FunctionalInterface = 단 하나의 추상 메서드만 가지도록 강제하는 어노테이션
@FunctionalInterface
public interface MyFunctionalInterface {
    void doSomething(); // 단 하나의 추상 메서드
}

// 람다식으로 구현 가능:
MyFunctionalInterface f = () -> System.out.println("Hello, Functional Interface!");
f.doSomething(); // 출력: Hello, Functional Interface!

2. 자바에서 제공하는 대표 Functional Interface

인터페이스	메서드	용도	예제
Supplier	T get()	값 공급, 지연 생성, 기본값	Supplier<String> s = () -> "Hello"; s.get(); // "Hello"
Consumer	void accept(T t)	입력값 소비, 처리만 하고 반환 없음	Consumer<String> c = s -> System.out.println(s); c.accept("Hi");
Function<T,R>	R apply(T t)	입력값 변환, 매핑, 계산	Function<Integer,String> f = n -> "Number: "+n; f.apply(5); // "Number: 5"
Predicate	boolean test(T t)	조건 검사, 필터링	Predicate<String> p = s -> s.length()>3; p.test("Hi"); // false

추가 포인트

Supplier → Stream.generate(), 기본값, 난수 등
Consumer → Stream.forEach(), 값 처리만
Function → Stream.map(), 값 변환
Predicate → Stream.filter(), 조건 검사

3. 사용 이유

"그냥 메서드 직접 쓰기"랑 비교했을 때 뭐가 좋을까?

공통적으로: 단순 실행보단 재사용성 + 조합성 + 스트림 API 활용성 때문에 유용하다!!

Consumer → "실행 동작을 넘겨줄 수 있다"
Function → "변환 로직을 독립시켜 재사용/조합할 수 있다"
Predicate → "조건식을 객체화해서 필터링과 조합에 강력하다"
Supplier → "값을 생성하는 책임을 분리할 수 있다"

✅ 3-1. Supplier 사용 이유

Supplier<Double> randomSupplier = () -> Math.random();
System.out.println(randomSupplier.get()); // 0~1 사이 난수

⭐ 그냥 Math.random() 호출하면 되는데 왜 Supplier?
1️⃣ 지연 실행 → get() 호출할 때만 실행됨 (Lazy Evaluation). 불필요한 자원 낭비를 줄이고 효율적으로 실행.
2️⃣ 재사용성 → 값 생성 로직을 변수로 저장해서 여러 곳에서 활용 가능.
3️⃣ 전략 교체 용이 → randomSupplier = () -> new Random().nextDouble();→ 구현체 교체 가능, 호출 코드는 그대로 randomSupplier.get() 사용
4️⃣ 스트림/테스트에서 유용 → Stream.generate(randomSupplier) 가능(무한스트림, .limit(N)으로 제한), 테스트 시 고정값 주입 가능.

➡️ 즉, "즉시 실행"이 아니라 "값을 공급하는 동작을 객체화해서 유연하게 쓸 수 있다" 가 장점.

✅ 3-2. Consumer 사용 이유

Consumer<String> printer = s -> System.out.println("Hello, " + s);
printer.accept("Java"); // Hello, Java

⭐ 그냥 System.out.println("Hello, Java") 쓰면 되는데 왜 Consumer?
1️⃣ 재사용성 → Consumer를 변수로 저장해서 여러 군데 넘겨 쓸 수 있음.
2️⃣ 조합 가능 → andThen 같은 메서드 체이닝 지원 → 여러 Consumer를 합쳐서 실행 가능.
3️⃣ 전략 교체 용이 → 같은 메서드 로직이라도 상황에 따라 다른 Consumer를 주입 가능 (DI, 전략 패턴처럼).

➡️ 즉, "한번 실행"보다 "동작을 넘기고, 조합하고, 교체할 수 있다" 가 장점.

✅ 3-3. Function<T, R> 사용 이유

Function<Integer, String> intToStr = i -> "Number: " + i;
System.out.println(intToStr.apply(10)); // Number: 10

⭐ 그냥 ("Number: " + 10) 해도 되는데 Function을 쓰는 이유?
1️⃣ 맵핑 로직을 변수화 → 변환 과정을 객체처럼 전달할 수 있음.
2️⃣ 스트림 API에서 강력 → map(Function) 과 같이 데이터 흐름에서 변환에 활용.
3️⃣ 함수 합성 지원 → andThen, compose 로 여러 Function을 합쳐서 파이프라인 처리 가능.

➡️ 즉, "데이터 변환 로직을 독립시켜 재사용 + 스트림 처리에 최적화".

✅ 3-4. Predicate 사용 이유

Predicate<Integer> isEven = n -> n % 2 == 0;
System.out.println(isEven.test(4)); // true

⭐ 그냥 if (n % 2 == 0) 하면 되는데 왜 Predicate?
1️⃣ 조건을 객체처럼 전달 가능 → 메서드 파라미터로 "조건"을 넘겨줄 수 있음.
2️⃣ 스트림 필터링에서 핵심 → filter(Predicate) 와 같이 조건을 활용.
3️⃣ 조건 조합 가능 → and, or, negate 등으로 여러 조건을 유연하게 합칠 수 있음.

➡️ 즉, "조건을 코드로 직접 쓰는 대신, 독립된 객체로 다루면서 조합/전달 가능".

4. 참고 - Java에서 제공하는 Functional Interface 전체

자바 8 이후 java.util.function 패키지에 약 43개 정도가 있음 (2~3에서 설명한 대표4개만 알아두자.. )
크게 입력/출력/조건/조합/특화형으로 나뉜다.
*Runnable과 Callable도 Functional Interface의 일종이다!!

1️⃣ 입력과 출력 기준

타입	예시
매개변수 X, 리턴 O	Supplier<T>
매개변수 O, 리턴 X	Consumer<T>, BiConsumer<T,U>
매개변수 O, 리턴 O	Function<T,R>, BiFunction<T,U,R>
매개변수 O, 리턴 boolean	Predicate<T>, BiPredicate<T,U>

2️⃣ 특화형(Primitive용)

성능 최적화 위해 int, long, double 버전 제공

타입	예시
int	IntSupplier, IntConsumer, IntFunction<R>, IntPredicate
long	LongSupplier, LongConsumer, LongFunction<R>, LongPredicate
double	DoubleSupplier, DoubleConsumer, DoubleFunction<R>, DoublePredicate

3️⃣ 조합용

기존 Functional Interface를 연결하거나 변형할 때 사용

예시	설명
UnaryOperator<T>	Function<T,T>와 같음, 자기 자신으로 매핑
BinaryOperator<T>	BiFunction<T,T,T>와 같음, 두 값으로 결과 생성

Docker 개념 및 예제

dddzr — Tue, 7 Apr 2026 09:42:10 +0900

0. Docker 개념

✅ 0-1. 개념

Docker는 응용 프로그램과 그 의존성을 하나의 패키지로 묶어 실행할 수 있는 컨테이너 기술

Docker: 가장 널리 사용하는 컨테이너 엔진
컨테이너 엔진: 컨테이너를 생성하고 실행하는 소프트웨어 (컨테이너 구현 기술)
컨테이너: 애플리케이션을 실행하기 위한 격리된 실행 환경 (OS커널 공유, VM보다 가볍고 빠름)

*VM: OS까지 포함한 완전한 가상환경
컨테이너: OS 없이 실행 환경만 격리

✅ 0-2. 사용 이유

성능 때문 ❌
운영/관리 때문 ⭕

환경 통일: 내 PC·팀원·서버 어디서든 동일한 실행 환경 보장
버전 관리: 이미지로 버전을 고정하여 환경 충돌 없이 안정적인 실행 가능
한 번에 실행: DB·Redis·서비스 등을 한 번에 실행하여 세팅 시간 최소화
격리 (Isolation): 서비스별로 분리되어 포트 및 라이브러리 충돌 방지
삭제/초기화 쉬움: 명령어 한 번으로 환경을 빠르게 초기화하고 재구성 가능
확장성: 서비스를 쉽게 추가·확장하고 독립적으로 실행 및 테스트 가능

⭐ Tip

Docker 이미지는 보통 인터넷에서 다운로드

Docker Hub / 사설 레지스트리 → pull → 로컬 저장

폐쇠망에서는?

이미지 파일로 옮김

docker save -o mariadb.tar mariadb:10.6

docker load -i mariadb.tar

✔ 외부망 → 내부망 이동 가능

✔ 폐쇄망에서도 사용 가능

✅ 0-3. 설치 가능 서비스 예시

데이터베이스 및 캐시 (RDBMS: MariaDB / NoSQL: MongoDB / 캐시: Redis 등)
메시지 브로커 (Kafka, RabbitMQ 등)
웹 서버 및 애플리케이션 서버 (웹 서버: Nginx / 애플리케이션 서버: Tomcat 등)
개발 도구 (CI/CD 툴: Jenkins / 코드 품질 분석: ESLint / 로컬 개발 환경: Adminer )
빅데이터 및 분석 ( Hadoop / Elasticsearch + Kibana (ELK Stack) / Spark )
네트워크 및 보안 (프록시 서버 / 보안 스캐너)
모니터링 및 로깅
머신러닝 및 데이터 사이언스
기타 (버전 관리 및 협업: Git, SVN / CMS / VPN 및 네트워크 관리)
운영 자동화 (Ansible AWX, Terraform)

1. Docker 기본

✅ 1-1. Docker 설치 (윈도우 기준)

Docker Desktop 설치

https://www.docker.com/products/docker-desktop/

✔ 그냥 Next Next 설치
✔ WSL2 자동 설정

설치 완료 시 아래 두개 창이 뜸. (둘 다 닫아도 된다.)

Docker Desktop => 작업표시줄에서 Docker Desktop이 실행중인지 확인 (미실행 중이면 docker 명령어 안 먹음)

WSL(Windows Subsystem for Linux) => WSL 직접 쓸 필요 거의 없음, 그냥 Docker 쓰면 자동으로 돌아감

확인 방법. Version이 2면 제대로 실행중.

$ wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

*후에 성능 최적화 필요시 wsl에 우분투를 깔고, wsl 내부에서 도커 실행 가능하나 지금은 넘어간다!

설치 후

# 설치 버전 확인
docker --version

# Docker Desktop 실행 중인지 확인
docker p

✅1-2. 컨테이너 실행 확인

컨테이너 실행

docker run hello-world

✔ Docker 설치하면 docker 명령어가 시스템 PATH에 등록됨 어느 경로에서든 명령어 실행 가능

성공하면 도커 정상 작동 (성공 출력)

$ docker run hello-world
Unable to find image 'hello-world:latest' locally # ✔️이미지 로컬에서 찾을 수 없어서 다운로드 시작
latest: Pulling from library/hello-world # ✔️Docker Hub에서 이미지 받아옴
17eec7bbc9d7: Pull complete
ea52d2000f90: Download complete
Digest: sha256:85404b3c53951c3ff5d40de0972b1bb21fafa2e8daa235355baf44f33db9dbdd
Status: Downloaded newer image for hello-world:latest

Hello from Docker! # ✔️컨테이너 실행성공
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

2. 컨테이너 관리

✅2-1. Docker 핵심 명령어 정리

명령어	설명	언제 씀	예시
docker ps	실행 중 컨테이너만 조회	지금 돌아가는 것 확인	docker ps
docker ps -a	전체 컨테이너 조회 (종료 포함)	과거 실행 기록 확인	docker ps -a
docker run	컨테이너 생성 + 실행	처음 실행할 때	docker run nginx
docker start	중지된 컨테이너 다시 시작	재사용	docker start my-container
docker stop	실행 중 컨테이너 종료	종료할 때	docker stop my-container
docker restart	재시작	설정 변경 후	docker restart my-container
docker rm	컨테이너 삭제	완전히 제거	docker rm my-container
docker images	이미지 목록 조회	다운로드된 이미지 확인	docker images
docker rmi	이미지 삭제	용량 정리	docker rmi nginx
docker logs	컨테이너 로그 확인	에러/디버깅	docker logs my-container
docker exec	컨테이너 내부 접속	DB 확인, 테스트	docker exec -it my-container bash
docker pull	이미지 다운로드	미리 받아둘 때	docker pull nginx
docker build	이미지 직접 생성	Dockerfile 사용 시	docker build .

✅2-2. 개별 컨테이너 실행

각 컨테이너를 일일이 docker run으로 실행해야 해서 잘 쓰지 않는다!!

# MariaDB
docker run -d \
 --name mariadb \
 -e MYSQL_ROOT_PASSWORD=root \
 -p 3306:3306 \
 -v mariadb_data:/var/lib/mysql \
 mariadb:10.6

# Redis
docker run -d \
 --name redis \
 -p 6379:6379 \
 -v redis_data:/data \
 redis

단점

컨테이너 간 의존성 관리 힘듦 (depends_on 같은 기능 없음)
네트워크 연결 직접 설정 필요
서비스 추가/삭제 시 명령어 길게 반복
멀티 컨테이너 환경에서 실행 순서 관리 어려움

3. Docker Compose

✅ 3-1. Docker Compose 개념

Docker Compose = 여러 컨테이너를 한 번에 정의하고 실행하는 도구

docker-compose.yml 한 파일 안에서 서비스(컨테이너) 정의 + 포트 + 환경 변수 + 볼륨 + 네트워크 모두 관리
명령어 한 번(docker-compose up -d)으로 여러 컨테이너 실행, 연결, 데이터 영속성까지 처리 가능
개발 환경에서 MSA/인프라 전체 스택 구성할 때 매우 유용

장점

항목	장점
자동화	단일 명령어로 모든 서비스 실행 가능
연결 관리	컨테이너끼리 네트워크 이름으로 바로 통신 가능
환경 분리	dev/test/prod 환경 별 Compose 파일 가능
재현성	팀원 모두 동일 환경 재현 가능

✅ 3-2. docker-compose.yml 작성

docker-compose.yml은 “프로젝트 폴더 루트”에 둔다.

Spring Boot(application.properties) 예시

# DB (3307)
spring.datasource.url=jdbc:mariadb://localhost:3307/mydb
# 다른 컨테이너로 접근할 때 (localhost X → 컨테이너 이름, 3306)
# spring.datasource.url=jdbc:mariadb://mariadb:3306/mydb
spring.datasource.username=root
spring.datasource.password=root
spring.jpa.hibernate.ddl-auto=update #테이블 자동 생성

# Redis
spring.redis.host=localhost
spring.redis.port=6379

* mariadb는 이미 로컬에서 3306으로 수행 중.

학습을 위해 3307로 테스트. 실제로는 이미 데이터 들어있어서 그냥 로컬 썼음.

service.msc에서 로컬 db 종료하고 도커에서 3306써도 됨. (동시 실행 불가)

docker-compose.yml 예시

services:
  mariadb:
    image: mariadb:10.6
    container_name: mariadb
    environment:
      MYSQL_ROOT_PASSWORD: root
    ports:
      - "3307:3306" # 로컬 PC에 mariaDB가 있어서 포트 변경
    volumes:
      - mariadb_data:/var/lib/mysql   # DB 데이터 영구 저장

  redis:
    image: redis
    container_name: redis
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data             # Redis 데이터 저장

volumes:
  mariadb_data:
  redis_data:

설정 항목

항목	역할	예시
환경 변수	컨테이너 내부 설정 전달	MYSQL_ROOT_PASSWORD=root
포트	호스트 ↔ 컨테이너 매핑	3306:3306, 6379:6379
네트워크	컨테이너끼리 통신	app ↔ mariadb 동일 네트워크
볼륨	데이터 영속성	/var/lib/mysql → mariadb_data

✅ 3-3. 실행/종료

프로젝트 루트 경로(docker-compose.yml와 같은 경로)에서 실행.

생성, 실행: up

docker-compose up -d

컨테이너 없으면 → 생성 + 실행
컨테이너 있으면 → (Compose.yml 수정) 변경사항 반영해서 → 재생성 + 실행
*Dockerfile 수정 시: docker-compose up -d --build → 시작 + 생성 + 실행

제거: down

docker-compose down

컨테이너 삭제
네트워크 삭제
✔ “완전히 종료 + 제거”
❗volume은 기본 유지

정지: stop

docker-compose stop

컨테이너 “정지”만 함
삭제 안 함 “일시정지 느낌”

재실행: start

docker-compose start

stop된 컨테이너 다시 실행
✔ “재시작 (이미 존재해야 함)”

정지, 재실행: restrart

docker-compose restart

stop + start

4. 볼륨(volume)

✅4-1. Volume 개념

Volume=데이터 영속성

Docker 볼륨 = 컨테이너 외부에 데이터를 저장하는 공간
컨테이너는 원래 임시 공간에서 동작 → 삭제 시 데이터도 삭제
볼륨을 쓰면 컨테이너 삭제 후에도 데이터 유지 가능

예시: DB 데이터 저장

컨테이너 내부 기준: /var/lib/mysql (MariaDB)
여기 안에 DB 파일, 테이블, 인덱스, 로그 등 모두 저장

✅ 4-2. 볼륨 종류

종류	설명	예시
Named Volume (추천)	Docker가 관리, 안전하게 데이터 유지	mariadb_data:/var/lib/mysql
Bind Mount	PC 경로와 컨테이너 연결, 파일 직접 확인 가능	./dbdata:/var/lib/mysql

✔ 실무 기준: 기본은 Named Volume, 필요 시 Bind Mount

✅ 4-3. 볼륨 확인 방법

1️⃣ 볼륨 리스트 확인

docker volume ls

2️⃣ 볼륨 실제 경로 확인

docker volume inspect mariadb_data

결과 예시:

[
 {
   "Name": "mariadb_data",
   "Mountpoint": "/var/lib/docker/volumes/mariadb_data/_data"
 }
]

✔ /var/lib/docker/volumes/mariadb_data/_data ← 실제 DB 파일 저장 위치

✅ 4-4. 인프라 초기화 예제

많이 쓰는 외부 인프라 MariaDB와 Redis로 실습해보았다.

*GUI에서도 생성/확인 가능하다!!

인프라 초기화 총정리

docker-compose up -d → 공용 MariaDB, Redis, ES 컨테이너 실행
MariaDB 접속 → 서비스별 DB 생성 (orders, products)
테이블 생성 → SQL 직접 작성 또는 Spring Boot JPA 자동 생성
Redis 초기화 → redis-cli 사용
서비스 실행 → DB/Redis 연결 확인 → 볼륨 덕분에 데이터 영구 저장

✅ 4-4-1. mariaDB

1️⃣ MariaDB 접속 및 DB 생성

① 컨테이너 내부 접속

docker exec -it common-mariadb mysql -uroot -p
# 비밀번호: root

② 호스트에서 접속 (포트 매핑 활용)

mysql -h 127.0.0.1 -P 3306 -uroot -p

③ 서비스별 DB 생성

-- Order 서비스용 DB
CREATE DATABASE orders;

-- Product 서비스용 DB
CREATE DATABASE products;

-- 권한 부여 (root 계정은 기본으로 모든 DB 접근 가능, 필요 시 별도 계정 생성)
GRANT ALL PRIVILEGES ON orders.* TO 'root'@'%';
GRANT ALL PRIVILEGES ON products.* TO 'root'@'%';
FLUSH PRIVILEGES;

포인트: 공용 MariaDB 하나지만, DB 이름만 다르게 생성 → MSA 서비스별 데이터 분리

2️⃣ 테이블 생성

방법 1: SQL 직접 작성 (기존 코드 없을 때!!)

-- orders DB
USE orders;

CREATE TABLE order_info (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  status VARCHAR(50) DEFAULT 'ORDERED',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

방법 2: Spring Boot JPA 자동 생성 (기존 코드 있을 )

- application.properties 예시 (Order 서비스 기준)

# DB
spring.datasource.url=jdbc:mariadb://localhost:3306/orders
spring.datasource.username=root
spring.datasource.password=root
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

JPA 엔티티 기반으로 테이블 자동 생성
장점: 코드 중심 테이블 관리, 컨테이너 재시작해도 볼륨 덕분에 데이터 유지
단점: 운영 환경에서는 SQL 스크립트/마이그레이션 툴 권장

3️⃣ 테이블 조회

방법 1: Docker Desktop → 컨테이너 접속

mariadb 컨테이너 Terminal에서.

mysql -u root -p
비번: root
SHOW DATABASES;
USE orders;
SHOW TABLES;

방법 2: DB 툴 (추천 )

연결 정보

host: localhost

port: 3307 (나는 로컬에 mariaDB가 3306써서 이렇게 설정함)

user: root

password: root

database: orders

# DB

spring.datasource.url=jdbc:mariadb://localhost:3307/orders

✅ IDE에서 실행할 때

jdbc:mariadb://localhost:3307/orders

✅ Docker 안에서 실행할 때

jdbc:mariadb://mariadb:3306/orders

✅ 4-4-2. Redis 초기화 / 확인

컨테이너 접속:

docker exec -it common-redis redis-cli

데이터 확인 / 삭제

> KEYS * # 모든 key 확인

> FLUSHALL # 모든 데이터 삭제 (초기화)

Redis는 기본적으로 메모리 기반이라 초기화는 이렇게 CLI로 간단하게 가능

5. Docker 네트워크 & DNS

컨테이너는 각각 localhost를 가진다

각 컨테이너는 다른 컴퓨터 취급
localhost = 자기 자신

컨테이너 간 통신 방법

Docker Compose는 컨테이너끼리 통신용 DNS를 자동 생성한다.
서비스 이름으로 통신 (eureka-server)

외부 ↔ 컨테이너 통신

포트 매핑 (8761:8761)
포트 포워딩(port mapping) => 내 로컬 PC에서 실행중인 프로그램 or 브라우저로 직접 접속 시에는, localhost로 컨테이너에서 실행중인 서비스에 접속가능하다!!

컨테이너 → 로컬 PC 접근

Host.docker.internal => Docker가 특별히 제공하는 가짜 DNS 이름
*Linux는 안 될수도 있다고 한다.

네트워크 흐름 총정리

[내 PC]
   localhost:8080  → 컨테이너 (포트포워딩)
   localhost:8761  → 컨테이너 (포트포워딩)

[컨테이너 내부]
   localhost       → 자기 자신 ❌
   eureka-server   → 다른 컨테이너 ✅
   host.docker.internal → 내 PC ✅

6. 환경변수

로컬/컨테이너 실행환경이 다르기 때문에 환경변수 설정이 필요하다.

Docker-compose.yml에 환경 변수 설정하면 application.yml 설정 덮어써서 로컬실행, 도커실행 둘다 가능하다.

✅ 6-1. 환경 변수 이름

Spring boot 설정파일 (application.yml or application-properties)랑 매핑된다.

eureka.client.service-url.defaultZone

↓

EUREKA_CLIENT_SERVICEURL_DEFAULTZONE

예시

# 로컬 pc에서 서비스 실행 시 (eureka, gateway)
# application.yml
eureka.client.service-url.defaultZone=http://localhost:8761/eureka/
↓
# 도커쓰면 서비스 네임으로 컨테이너 간 통신
# docker-compose.yml
environment:
 - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/

7. 실습: MSA 공통 인프라 자동 실행

기존 존재하던 MSA 프로젝트에서 애플리케이션 인프라를 컨테이너 시작 시 같이 실행되게 하려고한다!

eureka-server와 api-gateway는 공통 인프라는 변경이 적고, 항상 먼저 실행되어야 한다.
컨테이너로 고정 실행하여 안정적으로 서비스 의존성 순서 보장 (eureka → gateway → 서비스)하고자 한다.
비즈니스 서비스(order, product 등)는 개별로 수동 실행

✅ 7-1. Compose.yml 수정 (나머지 부분은 3번 예제 참고!)

포트 매핑
Healthcheck과 depends_on으로 실행 순서 제어. (의존성 관리)
Environment로 환경변수 설정
Profile 설정

 # =====================
  # 자동 시작 MSA
  # =====================
  eureka-server:
    build: ./eureka
    container_name: eureka-server
    ports:
      - "8761:8761"
    depends_on:  # 리스트 방식 (예시임. 얘는 의존성 필요없다)
      - mariadb
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8761/actuator/health"]
      interval: 5s
      retries: 10

  api-gateway:
    build: ./gateway
    container_name: api-gateway
    ports:
      - "8080:8080"
    Depends_on: # 객체 방식
        mariadb:
            condition: service_started
        eureka-server:
            condition: service_healthy
    environment:
      - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/
    # healthcheck:
    #   test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
    #   interval: 5s
    #   retries: 10


# =====================
# 다른 서비스 (수동 실행)
# =====================
  order-service:
    build: ./order-service
    container_name: order-service
    profiles: ["optional"]
    ports:
      - "8085:8080"
    depends_on:
      eureka-server:
        condition: service_healthy
    environment:
      - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/
  product-service:
    build: ./product-service
    container_name: product-service
    profiles: ["optional"]
    ports:
      - "8083:8080"
    depends_on:
      eureka-server:
        condition: service_healthy
    environment:
      - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/

✅ 7-2. JAR 파일 준비

1️⃣ Build.gradle

tasks.bootJar {
    archiveFileName = 'gateway.jar'                // JAR 이름
    destinationDirectory = file("$buildDir/target") // 경로
}

2️⃣ \gradlew bootJar 수행

3️⃣ build/target/{}.jar 파일 생성 확인.

✅7-3. 도커 이미지 준비

각 서비스(폴더) 안에 Dockerfile 필요

- Dockerfile (eureka)

FROM eclipse-temurin:17-jdk # jdk버전 유의 (유효버전 검색)
COPY build/target/eureka-server.jar /app.jar # 실제 jar 위치
ENTRYPOINT ["java", "-jar", "/app.jar"]

✅ 7-4. docker-compose up 실행 옵션

기본 실행

profile 속성이 없는 서비스 전체 실행

docker-compose up -d

profile 포함 실행

profiles: ["optional"] 속성 포함 전체 서비스 실행

*비즈니스 서비스 개발 시에는 로컬PC IDE에서 실행, 운영에서는 컨테이너에서 실행 가능!!

docker-compose --profile optional up -d

개별 서비스 실행

Profiles여부와 상관없이 개별로 실행가능.

docker-compose up -d order-service

여러개 선택 실행도 가능.

docker-compose up -d eureka-server api-gateway mariadb redis

1️⃣ 스프링부트 Jar 파일 직접 실행 (Dockerfile 없이)

이미 빌드된 jar 파일이 있다면 image: + command:로 바로 컨테이너 실행 가능

api-gateway:
 image: openjdk:17
 container_name: api-gateway

 ports:
   - "8080:8080"

 volumes:
   - ./api-gateway/target:/app

 working_dir: /app
 command: ["java", "-jar", "api-gateway.jar"]
 depends_on:
   - eureka-server

✔ ./api-gateway/target/api-gateway.jar 경로에 실제 jar 파일 있어야 함

✔ Dockerfile 없이도 컨테이너에서 실행 가능

확인

# 컨테이너 상태 확인
docker ps

# Eureka 서버가 정상 구동됐는지 확인
docker logs eureka-server

# Gateway 정상 구동 확인
docker logs api-gateway

크롤링(Crawling)

dddzr — Sun, 25 Jan 2026 13:22:22 +0900

1. 크롤링(Crawling)이란?

웹 크롤링은 인터넷 상의 웹 페이지를 자동으로 탐색하고, 그 내용을 수집하는 기술 또는 과정! 보통 검색 엔진(예: 구글)이나 데이터 수집 봇이 사용하는 기술이다.

크롤링의 기본 원리

1️⃣ 크롤러(bot, spider)가 시작 URL(예: https://example.com)에 접속
2️⃣ 해당 페이지의 HTML 문서를 읽고, 내부에 있는 링크들을 수집
3️⃣ 수집한 링크를 따라가면서 다른 페이지도 탐색
4️⃣ 이 과정을 반복하면서 점점 더 많은 데이터를 수집

크롤링을 사용하는 이유

✅ 웹사이트의 정보를 자동으로 모으기 위해
✅ 상품 가격, 뉴스 기사, 게시글 등을 수집해 분석하기 위해
✅ 검색 엔진이 웹사이트를 인덱싱하기 위해

크롤링 vs 스크래핑

크롤링: 웹페이지를 돌아다니며 데이터를 모으는 과정
스크래핑: 그 페이지 안에서 원하는 정보를 뽑아내는 작업

항목	크롤링	스크래핑
목적	페이지 탐색 및 링크 수집	페이지에서 특정 정보 추출
예시	여러 뉴스 사이트 순회	뉴스 기사에서 제목/본문 추출

2. 크롤링 구현 방법 (파이썬)

파이썬에서 크롤링 라이브러리를 이용한다.

✅ 크롤링 라이브러리

BeautifulSoup → 정적 HTML에서 데이터 추출
Selenium → 동적으로 생성되는 데이터 (JS 렌더링된 페이지)
Scrapy → 대규모 크롤링에 적합

✅ 2-1. 기본 웹 크롤링 방식 (requests & BeautifulSoup)

requests.get(url)을 사용하면 웹사이트의 HTML을 가져올 수 있다.

import requests
from bs4 import BeautifulSoup

url = "https://example.com"
headers = {"User-Agent": "Mozilla/5.0"}
response = requests.get(url, headers=headers)

soup = BeautifulSoup(response.text, "html.parser")
print(soup.prettify()) # 사이트의 HTML 코드 출력

✅ 2-2. 동적 웹페이지 크롤링 (Selenium)

requests는 HTML 코드만 가져오기 때문에, JavaScript로 렌더링되는 데이터(예: 유튜브 댓글, 쿠팡 상품 목록 등)는 크롤링할 수 없음!
Selenium을 사용하면 실제 브라우저를 띄우기 때문에 JavaScript로 렌더링된 데이터도 가져올 수 있음!

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
import time

# 크롬 드라이버 실행
service = Service("chromedriver.exe")
driver = webdriver.Chrome(service=service)

# 웹사이트 접속
driver.get("https://example.com")
time.sleep(2) # 페이지가 로딩될 때까지 대기

# HTML 가져오기
html = driver.page_source
print(html)

#뉴스 제목 가져오기
titles = driver.find_elements(By.CLASS_NAME, "sa_text_strong")
print(" 네이버 뉴스 제목:")
for idx, title in enumerate(titles, 1):
print(f"{idx}. {title.text}")

# 브라우저 종료
driver.quit()

✔ find_elements(By.CLASS_NAME, "클래스이름") 으로 원하는 데이터를 가져올 수 있음.
✔ driver.quit()으로 브라우저를 닫아야 함.

2-3. 크롤링 방식 비교

방식	가져올 수 있는 데이터	주요 라이브러리
requests + BeautifulSoup	서버에서 제공하는 정적인 HTML	requests, BeautifulSoup
Selenium	JavaScript로 동적으로 생성된 데이터 (예: 무한 스크롤)	Selenium, webdriver
Scrapy	대량의 웹페이지에서 데이터 수집 (크롤링 속도 빠름)	Scrapy

어떤 데이터를 크롤링하느냐에 따라 적절한 라이브러리를 선택!

3. 크롤링 주의사항

✅3-1. robots.txt 확인 (사이트 크롤링 허용 여부 체크)

웹사이트마다 크롤링 허용 여부를 설정한 robots.txt 파일이 있다.
➡️ 크롤링 가능 여부를 먼저 체크!!

확인 방법:

https://사이트주소/robots.txt

예시 (네이버 뉴스)

https://news.naver.com/robots.txt

✔ User-agent: * 부분에서 Disallow 된 URL이 있으면 크롤링하면 안 됨!
✔ 만약 Allow: / 라고 되어 있으면 크롤링 가능!

✅3-2. User-Agent 설정 (크롤링 차단 방지)

서버가 봇(자동 크롤러)인 걸 감지하면 차단할 수도 있다.
➡️ User-Agent를 설정하면 사람이 요청하는 것처럼(브라우저 처럼) 보일 수 있음!

예시 (네이버 뉴스 크롤링)

import requests

url = "https://news.naver.com/"
headers = {"User-Agent": "Mozilla/5.0"} # 크롬 브라우저처럼 보이게 설정
response = requests.get(url, headers=headers)

print(response.status_code) # 200이면 정상 접속

✅3-3. IP 차단 방지 (요청 간격 조절)

너무 빠르게 요청하면 차단될 수도 있어!
➡️ time.sleep(1) 같은 코드를 추가해서 요청 간격을 조절.

예제 (10초마다 뉴스 크롤링)

import time

for _ in range(5):
    response = requests.get(url, headers=headers)
    print("크롤링 완료, 10초 대기 중...")
    time.sleep(10) # 10초 대기

4. 추가 기능

✅4-1. API 데이터 가져오기 (requests + JSON 활용)

웹사이트에서 제공하는 API를 이용하면 더 빠르고 안정적으로 데이터를 가져올 수 있다.
( API는 데이터를 JSON 형식으로 제공하는 경우가 많음!)

API 요청 예제 (jsonplaceholder.typicode.com 사용)

import requests

url = "https://jsonplaceholder.typicode.com/posts"
response = requests.get(url)

data = response.json() # JSON 데이터를 파이썬 딕셔너리로 변환

# 5개의 제목 출력
for post in data[:5]:
print(post["title"])

✔ 장점: 크롤링보다 빠르고 정확함! (robots.txt 걱정 없음)
✔ 단점: API를 제공하는 사이트에서만 사용 가능

✅4-2. 크롤링 데이터 가공 후 시각화 (pandas + matplotlib)

크롤링한 데이터를 분석하고 그래프로 시각화할 수 있다.

설치 방법

pip install pandas matplotlib

CSV 데이터 불러와서 시각화 예제

import pandas as pd
import matplotlib.pyplot as plt

# CSV 파일 불러오기
df = pd.read_csv("news.csv")

# 뉴스 개수 확인
print(df.head()) # 상위 5개 출력

# 뉴스 제목 글자 수 분포 시각화
df["title_length"] = df["뉴스 제목"].str.len()

plt.hist(df["title_length"], bins=10, color="skyblue", edgecolor="black")
plt.xlabel("제목 길이")
plt.ylabel("기사 개수")
plt.title("뉴스 제목 길이 분포")
plt.show()

✔ pandas로 데이터를 다룰 수 있음
✔ matplotlib로 데이터를 그래프로 표시 가능

멀티 모듈 (Multi-module)이란?

dddzr — Sun, 25 Jan 2026 12:49:40 +0900

msa 프로젝트 구성 중 각 시스템(서비스)에서 공통으로 필요로 하는 코드들이 많았다.

이 중복을 줄이기 위해서 멀티 모듈로 관리하는 방법이 있다는 걸 알게되었다.

결론적으로 내 프로젝트에는 멀티모듈 구조가 적합하지 않다고 판단해서 적용하지 않았지만, 멀티 모듈에 대해 알아본 것들을 정리했다!

1. 멀티 모듈 (Multi-module)이란?

멀티 모듈은 하나의 큰 프로젝트 내에서 여러 개의 모듈을 정의하는 방식.
단일 애플리케이션에서 여러 모듈로 나누어 관리하는 방식
MSA에서는 서비스 간의 의존성 관리나, 공통 라이브러리 등을 관리하기 위해 멀티 모듈을 사용할 수 있다.
예시: common-utils라는 모듈을 만들고, 여러 서비스가 이 모듈을 의존성으로 추가하여 공통 기능(로그 처리, 유효성 검사, 예외 처리 등)을 공유.

2. 멀티모듈 구조가 적합한 경우

모든 서비스가 동일한 기술 스택(예: Spring Boot + Gradle)을 사용하는 경우.
각 서비스가 동일한 코딩 스타일과 공통 라이브러리를 사용하는 경우.
개발자 간 협업이 원활하고, 서비스 간 높은 결합도가 있어야 하는 경우.
각 서비스가 동일한 배포 주기를 가질 수 있는 경우.

3. 멀티모듈 구조가 적합하지 않은 경우

서비스마다 기술 스택이 다양한 경우.
- 예: 주문 서비스(Java), 사용자 서비스(Python).
서비스마다 DB가 달라서 독립적으로 관리해야 하는 경우.
- 예: MySQL, PostgreSQL, MongoDB 등 다양한 DB를 사용하는 경우.
서비스별 개발팀이 다르거나, 각 팀의 작업 속도가 크게 다른 경우.
각 서비스가 독립적으로 배포 및 테스트가 가능한 구조를 원할 때.

4. 대안: 독립 서비스로 관리

멀티모듈 대신 각 서비스를 독립적으로 관리하면서도, 공통 코드를 공유하는 방식

공통 코드(예: DTO, 유틸리티 등)를 별도의 공통 라이브러리 프로젝트로 관리.
- => Git 서브모듈이나 별도의 공통 라이브러리 Git 저장소를 만들어 공유.

각 서비스는 완전히 독립적으로 개발 및 배포.
서비스별로 독립적인 빌드 및 파이프라인을 설정.

5. 예시 (이벤트 기반 통신)

이벤트 기반 통신에서 발행하는 쪽과 수신하는 쪽의 Event 객체를 동일하게 사용.

root-module/

├── order-service/

│ └── 발행자

├── product-service/

│ └── 수신자

├── common-events/

└── OrderEvent.java

✔️ 장점

코드 재사용성: 발행 및 수신 양쪽에서 동일한 객체를 사용하므로 코드 중복을 방지.
일관성 유지: 이벤트의 스키마(필드 구조)가 항상 동일하게 유지. 이벤트를 발행할 때와 수신할 때 필드가 다를 위험x.
의존성 관리 용이: 공통 모듈로 이벤트 클래스를 두면, 발행 서비스와 수신 서비스 모두 해당 모듈을 의존성으로 추가해 사용할 수 있다.
테스트 효율성 증가: 동일한 이벤트 객체를 사용하면, Mocking이나 Serialization 테스트 시 같은 클래스를 사용할 수 있어 효율적.

✔️ 고려할 점

서비스 간 강결합 가능성
- 공통 이벤트 객체를 사용하면 서비스 간 간접적인 의존성이 생김.
- 이를 완화하려면 공통 모듈의 변경을 신중히 하고, 이벤트 버전 관리(예: OrderEventV1, OrderEventV2)를 도입해야함.
모듈 간 독립성 손상 가능성
- 각 서비스가 독립적으로 배포되고 관리되어야 하는 경우, 공통 이벤트 클래스에 변경이 생기면 각 서비스의 독립 배포 주기를 방해할 수 있다.
메시지 호환성
- 발행자가 오래된 이벤트를 사용하고, 수신자가 새 이벤트를 수신할 경우 호환성 문제가 발생할 수 있다. JSON 직렬화 구조를 유연하게 처리하거나 필드 추가만 허용하는 방식으로 관리해야함.
직렬화 라이브러리
- 이벤트 객체를 직렬화/역직렬화하는 라이브러리(예: Jackson, Gson) -> 같은 직렬화 라이브러리를 사용하는 것을 권장.

6. 공통 모듈 설정 방법

common 모듈은 공통 코드를 포함하는 별도의 프로젝트로 만들고, 각 서비스가 이를 참조하도록 설정할 수 있다.

✅ 방법 1: JAR 파일로 사용

1️⃣common 모듈을 빌드하여 JAR 파일을 생성, 파일은 common/build/libs/에 생성된다.

cd common
./gradlew build

2️⃣각 서비스의 build.gradle에 common JAR 파일을 의존성으로 추가합니다.

dependencies {
    implementation files('../common/build/libs/common-0.0.1-SNAPSHOT.jar')
}

✅ 방법 2: 로컬 프로젝트 참조

1️⃣각 서비스의 build.gradle에서 common 폴더를 직접 참조하도록 설정.

service-a/build.gradle

dependencies {
    implementation project(':common')
}

2️⃣상위 settings.gradle에서 common 모듈을 포함시킨다.

workspace-folder/settings.gradle

include ':common', ':service-a', ':service-b', ':service-c'

Spring Boot DTO ↔ Entity 변환 방법

dddzr — Sun, 25 Jan 2026 12:42:19 +0900

왜 DTO ↔ Entity 변환이 필요한가?

Entity는 DB 모델이고, DTO는 입출력·뷰 모델이기 때문.

엔티티를 그대로 노출하면 보안·커플링·유효성 검증·API 스펙 분리 문제가 생기므로,

DTO로 변환해서 외부와 내부를 분리하는 것이 Spring 실무 표준이다.

객체 변환 3가지 방법 비교

Spring Boot에서 DTO ↔ Entity 변환 시 대표적으로 아래 3가지를 비교할 수 있다.

비교 기준

컬렉션(List) 변환
연관 관계 필드 변환 (예: User → Address 포함)
타입 변환 (예: LocalDateTime → String)

방법	List 변환	연관 관계 필드 변환	타입 변환 (예: LocalDateTime → String)
BeanUtils.copyProperties()	❌ 수동 처리 필요	❌ 자동 변환 불가	❌ 직접 변환 필요
ModelMapper	✅ 자동 변환 가능	일부 변환 가능	✅ 커스텀 변환 지원
수동 변환 (직접 매핑)	✅ 완벽한 제어 가능	✅ 원하는 대로 변환 가능	✅ 원하는 방식으로 변환 가능

✅ 1. BeanUtils.copyProperties()

Spring의 BeanUtils.copyProperties()는 간단한 DTO 변환에 유용.
하지만, 연관 관계 필드(@OneToMany, @ManyToOne)나 타입 변환(LocalDateTime → String)이 자동으로 처리되지 않아서 직접 변환해야 한다.

예제 코드

OrderItemDetails orderItemDetails = new OrderItemDetails();
BeanUtils.copyProperties(orderItem, orderItemDetails);

장점 & 단점

✔ 장점
빠르고 단순
필드명이 같으면 자동 변환

❌ 단점
커스텀/중첩 필드 처리 거의 없음

리스트 변환 및 연관 관계 변환 예제 (수동 처리 필요)

orderItemDetails.setOrderId(orderItem.getOrder().getOrderId()); // 연관 관계 필드 직접 매핑
orderItemDetails.setProductName(orderItem.getProduct().getName());

✅ 2. ModelMapper

ModelMapper는 List 변환, 연관 관계 변환, 타입 변환을 자동으로 처리.
하지만 성능이 다소 저하될 수 있음.

예제 코드

ModelMapper modelMapper = new ModelMapper();
OrderItemDetails orderItemDetails = modelMapper.map(orderItem, OrderItemDetails.class);

장점 & 단점

✔ 장점
자동 매핑, 컨벤션 기반

❌ 단점
설정 복잡, 런타임 성능 이슈 가능

리스트 & 연관 관계 자동 변환 예제

modelMapper.createTypeMap(Product.class, ProductDTO.class)
    .addMappings(mapper -> {
        mapper.map(Product::getName, ProductDTO::setProductName);
        mapper.map(src -> src.getCategory().getCategoryName(), ProductDTO::setCategoryName);
    });

✅ 3. 수동 변환

연관 관계(@OneToMany, @ManyToOne) 필드 변환, 리스트 변환, 타입 변환을 완벽하게 제어할 수 있다.
하지만 코드가 길어질 수 있음.

예제 코드

public static ProductDTO convertToDto(Product product) {
    ProductDTO productDTO = new ProductDTO();
    productDTO.setId(product.getId());
    productDTO.setName(product.getName());

    // 연관 관계 변환
    productDTO.setCategoryName(product.getCategory().getCategoryName());

    // 리스트 변환
    List<ProductDetailDTO.ProductStockDto> stockDTOs = product.getStocks().stream()
        .map(stock -> new ProductDetailDTO.ProductStockDto(
            stock.getSize().getSizeName(),
            stock.getColor().getColorName(),
            stock.getStockQuantity()))
        .collect(Collectors.toList());

    productDTO.setProductStocks(stockDTOs);

    return productDTO;
}

장점 & 단점

✔ 장점
가장 명확, 유지보수 쉬움

❌ 단점
코드가 길어질 수 있음

최종 결론: 어떤 방법을 선택할까?

방법	추천 사용 경우
BeanUtils.copyProperties()	필드명이 동일한 간단한 DTO 변환일 때
ModelMapper	자동 변환이 필요한 경우 (연관 관계 포함)
수동 변환	최대 성능 & 정확한 제어가 필요한 경우

Elasticsearch > analyzer

dddzr — Sun, 25 Jan 2026 12:11:11 +0900

1. settings / analysis / analyzer 개념

1-1. settings란?

인덱스의 구성 설정을 정의하는 영역이다.
샤드 수, 리플리카 수, 분석기(analyzer) 설정 등이 포함된다.

1-2. analysis란?

텍스트 분석기 관련 설정 전부를 담는다.
내부 구성:
- analyzer
- tokenizer
- filter
- char_filter

1-3. analyzer란?

텍스트를 쿼리 시 또는 색인 시 “어떻게 쪼개고(normalizing) 처리할지”를 정의하는 도구이다.
최소 구성 요소:
- tokenizer (필수)
- filter (선택)
- char_filter (선택)

2. analyzer는 필수인가?

analyzer를 반드시 설정해야 하는 것은 아니며, 기본 분석기만으로도 충분한 경우가 많다.

항목	필수 여부	설명
analyzer 설정 자체	❌ 선택	설정하지 않으면 Elasticsearch 기본 분석기(standard analyzer)가 적용됨
tokenizer	✅ 필수	custom analyzer를 정의할 때 반드시 지정해야 함
filter	❌ 선택	필요 시 lowercase, stopword 등을 추가
char_filter	❌ 선택	HTML strip 등 전처리 용도

✔ analyzer가 필요한 경우

한국어 검색 → ✔ 필수
자동완성, 부분 검색 → ✔ 필수
동의어(synonym) → ✔ 필수
검색 정확도 높이기 (형태소, 불용어, 대소문자) → ✔ 필수
특수 문자 기반 토큰 분리 → ✔ 필수

✔ analyzer가 필요 없는 경우

exact match(keyword) 필드
단순 영어 검색 + 기본 기능으로 충분한 경우

3. settings와 analyzer의 기본 구조

Elasticsearch 인덱스를 생성할 때 아래처럼 settings와 analyzer를 지정할 수 있다.

PUT /my_index

{

"settings": {

"analysis": {

"analyzer": {

"my_custom_analyzer": {

"type": "custom",

"tokenizer": "standard",

"filter": [ "lowercase", "asciifolding" ]

}

"mappings": {

"properties": {

"message": {

"type": "text",

"analyzer": "my_custom_analyzer"

}

4. 주요 구성 요소 설명

analyzer

사용자 정의 분석기(custom) 또는 기본 분석기를 의미한다.

tokenizer (필수)

텍스트를 쪼개는 기준이다.

standard
whitespace
ngram
nori_tokenizer (한국어 형태소 분석기)

filter

토큰에 대한 후처리를 진행한다.

lowercase
asciifolding
nori_part_of_speech
stop (불용어 제거)

예제 1: 영어용 소문자 분석기

"analyzer": {

"my_lowercase_analyzer": {

"type": "custom",

"tokenizer": "standard",

"filter": ["lowercase"]

}

예제 2: 한글용 nori 분석기

"analyzer": {

"korean_analyzer": {

"type": "custom",

"tokenizer": "nori_tokenizer",

"filter": ["nori_part_of_speech"]

}

5. analyzer를 필드에 적용하는 법 (mapping)

"mappings": {

"properties": {

"title": {

"type": "text",

"analyzer": "my_custom_analyzer"

}

⚠️ analyzer를 정의해도 mapping에서 지정하지 않으면 적용되지 않는다.

6. analyzer 테스트 방법

설정이 잘 되었는지 확인하려면 _analyze API를 호출!

POST /my_index/_analyze

{

"analyzer": "my_custom_analyzer",

"text": "Hello WORLD!"

}

7. analyzer 수정

✅ analyzer는 생성 후 수정 불가!

❌ 왜 수정이 불가능한가?

analyzer는 인덱스 생성 시 Lucene 구조로 고정됨.
중간에 기준을 바꾸면 기존 문서의 분석 기준과 신규 문서 기준이 달라짐

8. analyzer 수정이 필요한 경우는?

기존 인덱스를 복사해서 새로 만드는 방식

1️⃣ 새 인덱스를 원하는 설정으로 생성
2️⃣ 기존 인덱스에서 데이터 가져오기 (reindex API)
3️⃣ 기존 인덱스 삭제 (선택)
4️⃣ 별칭(alias)을 바꿔서 기존 인덱스처럼 사용

1️⃣ 새 인덱스 생성

PUT /my_index_v2

{

"settings": {

"analysis": {

"analyzer": {

"my_custom_analyzer": {

"type": "custom",

"tokenizer": "standard",

"filter": ["lowercase"]

}

"mappings": {

"properties": {

"title": {

"type": "text",

"analyzer": "my_custom_analyzer"

}

2️⃣ 데이터 복사 (reindex)

POST /_reindex

{

"source": { "index": "my_index" },

"dest": { "index": "my_index_v2" }

}

3️⃣ alias 전환

POST /_aliases

{

"actions": [

{ "remove": { "index": "my_index", "alias": "current_index" }},

{ "add": { "index": "my_index_v2", "alias": "current_index" }}

]

}

9. Spring Boot에서 analyzer 매핑하는 법

✅9-1. 도메인 클래스

Spring Data Elasticsearch는 @Document와 @Field 어노테이션 기준으로 매핑을 잡아줌.
@Field(analyzer = "my_custom_analyzer") 를 반드시 명시해야 커스텀 analyzer 사용됨.

@Document(indexName = "article_index")
public class Article {

    @Id
    private String id;

    @Field(type = FieldType.Text, analyzer = "my_custom_analyzer")
    private String title;

    @Field(type = FieldType.Text)
    private String content;

}

✅ 9-2. ElasticsearchRepository 작성

findByXXX() 자동 쿼리 or @Query 커스텀 사용
복잡한 구현에선 repository 안 쓰고 ElasticsearchClient 직접 호출해서 쓸 수도 있다.

public interface ArticleRepository extends ElasticsearchRepository<Article, String> {

    List<Article> findByTitle(String title);

    @Query("{ \"match\": { \"title\": \"?0\" } }")
    List<Article> findByCustomTitle(String title);

}

✅ 9-3. 검색 테스트

@Autowired
private ArticleRepository articleRepository;
public void testSearch() {
    List<Article> articles = articleRepository.findByTitle("hello world");
    articles.forEach(System.out::println);
}

DTO / VO / DAO / Entity / Model 비교

dddzr — Sun, 25 Jan 2026 12:02:57 +0900

DTO / VO / DAO / Entity / Model은 모두 Spring에서 데이터와 관련된 객체들로, 각기 다른 역할을 한다. 헷갈리는 개념들을 한 번에 정리해보자!

1. DTO / VO / DAO / Entity / Model 비교

구분	역할/목적	특징	사용하는 층(Layer)	변경 가능성	예시
VO	값 객체 (Value Object)	불변 객체 (immutable)	DTO, Entity와 연동 가능	변경 X	Money, Point, Address
DTO	데이터 전달 객체 (Data Transfer Object)	계층 간 데이터 전달용	Controller ↔ Service ↔ DAO	변경 O	UserDTO, LoginDTO
DAO	DB 접근 객체 (Data Access Object)	DB 호출/쿼리 수행	Repository Layer	변경 O	UserDao, OrderDao
Entity	실제 DB 테이블과 매핑되는 객체	JPA 사용 시 @Entity	DB ↔ Application	변경 O	User, Product
Model	View에 넘겨주는 데이터 묶음 (MVC용)	UI에 최적화	Controller ↔ View	변경 O	Model.addAttribute("user", user)

➡️ DTO는 계층 간 데이터 전달, VO는 값 객체, DAO는 DB 접근, Entity는 DB 테이블과 매핑, Model은 View에 데이터를 전달하는 역할을 한다.

2. 각 객체 개념 상세 설명

✅ VO (Value Object)

값 자체가 중요한 객체 (예: Address, Money, Coordinate)
일반적으로 불변 객체로 설계 (getter만 있고 setter 없음)
값 세팅은 객체가 생성될 때 생성자(constructor)에서함. (예: AddressVO address = new AddressVO("서울", "테헤란로");)
equals(), hashCode() 오버라이딩해서 값 비교 중심
주로 DDD(도메인 주도 설계)에서 많이 등장함
JPA에서 @Embeddable로 쓰이기도 함

예시

public class AddressVO {
    private final String city;
    private final String street;

// 생성자 + getter만 있음
    public AddressVO(String city, String street) {
        this.city = city;
        this.street = street;
    }

    public String getCity() { return city; }
    public String getStreet() { return street; }

    // equals / hashCode override
}

✅ DTO (Data Transfer Object)

계층 간 데이터를 전달하기 위한 객체
일반적으로 getter/setter 다 있음
Controller ↔ Service ↔ DAO(Repository) 간에 데이터를 넘기기 위해 사용
가공된 데이터나 UI에 맞는 구조로 만들어짐
네트워크 전송, API 요청/응답 등에 사용됨
Validation용 어노테이션 붙기도 함 (@NotNull, @Size 등)

예:

public class UserDTO {
    private String username;
    private String email;
    
    // getter / setter
}

✅ DAO (Data Access Object)

DB와 직접 통신하는 역할 (CRUD 수행)
SQL 또는 MyBatis, JPA 등으로 실제 DB 쿼리 실행
보통 interface + 구현체 (UserDao, UserDaoImpl)
내부에서 DTO나 VO를 주고받음
주로 @Repository or @Mapper 붙음

예:

@Repository
public interface UserDao {
    User findById(String id);
}

// or

@Mapper
public interface UserMapper {
    User selectUserById(String id);
}

@Repository나 @Mapper는 DAO 역할 인터페이스, 사용하는 프레임워크에 따라 다름

@Repository → 스프링 일반 컴포넌트 등록 (MyBatis에서도 사용 가능)
@Mapper → MyBatis에서 자동으로 Mapper Proxy를 등록해주는 전용 애노테이션

Spring Boot에서는 @Mapper를 자주 사용, Spring에서는 @Repository + MapperScannerConfigurer 조합도 흔함

✅ Entity

DB 테이블과 매핑되는 객체 (ORM 용도)
JPA, Hibernate에서 @Entity로 사용됨
데이터 변경 감지를 위해 setter 있음
비즈니스 로직 포함하기도 함

예:

@Entity
public class User {
    @Id
    private Long id;
    private String name;
}

✅ Model (Spring MVC)

View(ViewResolver, JSP 등)에 데이터를 넘기기 위한 객체
컨트롤러에서 View로 데이터 전달 시 사용
Model.addAttribute("key", value) 식으로 전달

예:

@GetMapping("/user")
public String userDetail(Model model) {
    model.addAttribute("user", userDTO);
    return "userPage";
}

3. 정리 그림 (흐름)

[Client]

⬇

[Controller] → View (Model)

⬇ (DTO 사용)

[Service]

⬇ (Entity, VO 사용)

[DAO/Repository] ⬅→ DB (Entity 매핑)