보뇨 다이어리

벡터 DB 기초 정리 (백엔드 개발자 관점)

보뇨 — Mon, 18 May 2026 11:36:34 +0900

일반 RDB는 잘 알지만 벡터 DB는 처음 접하는 백엔드 개발자를 위한 정리

1. 벡터 DB란 무엇인가

1.1 저장되는 데이터

핵심: 벡터(숫자 배열) + 원본 데이터(payload)

{
  "id": "doc_1",
  "vector": [0.024, -0.183, 0.471, ..., 0.092],  // 차원수만큼 (예: 1024개)
  "payload": {
    "title": "K8s 네트워킹",
    "content": "CNI는 컨테이너 네트워크를 ...",
    "category": "infra"
  }
}

vector: 임베딩 모델이 텍스트를 받아 만들어낸 숫자 배열
payload: 원본 데이터 및 메타데이터 (필터링, 결과 표시용)

1.2 임베딩의 핵심 원리

의미가 비슷한 텍스트는 비슷한 벡터로 변환됨.

"K8s 네트워킹"     → [0.02, -0.18, 0.47, ...]
"쿠버네티스 통신"  → [0.03, -0.19, 0.45, ...]  ← 거의 비슷한 벡터
"오늘 점심 뭐 먹지" → [0.81, 0.32, -0.15, ...]  ← 완전 다른 벡터

1.3 RDB와의 비교

항목 일반 RDB 벡터 DB

데이터 형태	정형 (row/column)	벡터 + payload
쿼리 방식	정확한 매칭 (=, LIKE, JOIN)	유사도 검색 (ANN)
인덱스	B-tree, Hash	HNSW, IVF 같은 ANN 인덱스
결과	조건을 만족하는 전체	Top-K (보통 5~20개)
강점	트랜잭션, JOIN, 집계	의미 검색, 유사 항목 찾기
약점	의미 기반 검색 불가	트랜잭션/JOIN 거의 없음

2. 검색 동작 방식

2.1 검색 흐름

1. 사용자 쿼리 입력
   "쿠버네티스 네트워크 어떻게 동작해?"

2. 같은 임베딩 모델로 벡터화
   → [0.025, -0.182, ...]

3. 이 벡터와 거리가 가까운 Top-K개 검색

4. 결과 반환
   [
     { "id": "doc_1", "score": 0.92, "payload": {...} },
     { "id": "doc_7", "score": 0.87, "payload": {...} },
     { "id": "doc_3", "score": 0.81, "payload": {...} }
   ]

2.2 Top-K의 의미

K = 가져올 개수. SQL의 LIMIT과 유사한 개념.

-- RDB 비유
SELECT * FROM documents
ORDER BY similarity DESC
LIMIT 5;  -- Top-5

벡터 검색에서는 거의 항상 Top-K 방식.

모든 문서가 어느 정도 점수를 가짐 (정확 일치 개념이 없음)
"조건 만족하는 전체"가 아니라 "가장 가까운 N개"가 자연스러움

참고: Recall@7 같은 지표의 @7은 Top-7으로 검색했을 때 정답 문서가 포함된 비율을 의미.

2.3 거리 계산 방법

각 항목값을 ±1씩 시도하는 게 아니라, 수식 한 방으로 계산.

코사인 유사도 (가장 흔함)

두 벡터가 이루는 각도를 측정.

쿼리 벡터 Q = [0.2, 0.5, 0.1]
문서 벡터 A = [0.3, 0.4, 0.2]
문서 벡터 B = [-0.8, 0.1, 0.6]

코사인 유사도 = (Q · A) / (|Q| × |A|)
             = 내적 / (각 벡터의 길이 곱)

Q vs A → 0.95 (방향이 비슷함, 가까움)
Q vs B → 0.12 (방향이 다름, 멈)

주요 거리 측정 방식

방식 설명 언제 씀

Cosine	각도 기반	텍스트 임베딩 (가장 흔함)
Dot Product	내적	정규화된 벡터 (빠름)
Euclidean (L2)	직선 거리	이미지 임베딩 등

정규화된 벡터(bge, OpenAI 등)에서는 Cosine = Dot Product라 Dot가 더 빠름.

2.4 Top-K를 빠르게 뽑는 방법: ANN

Brute Force (전수 검색)

모든 벡터와 거리 계산 → 정확하지만 느림 (1억 개면 수 초).

ANN (Approximate Nearest Neighbor)

정확도를 약간 포기하고 속도를 얻음. 실제 운영에서 사용하는 방식.

HNSW (Hierarchical Navigable Small World) - 가장 보편적

Layer 2 (성김):     A ─────────── E
                    │             │
Layer 1 (중간):     A ─── C ───── E ─── G
                    │     │       │     │
Layer 0 (촘촘):   A-B-C-D-E-F-G-H-I-J-K-L  ← 모든 벡터

비유:

"서울역에서 가장 가까운 카페 5개" 찾기
1. "서울 어디?" (대륙 단위)
2. "중구 근처?" (도시 단위)
3. "서울역 근처?" (동네 단위)
4. 그 동네에서만 정밀 비교

→ 1억 개에서도 수 ms 안에 검색 가능.

주요 인덱스 알고리즘

알고리즘 특징 지원 DB

HNSW	그래프 기반, 빠르고 정확, 메모리 많이 씀	Qdrant, Milvus, pgvector, Weaviate
IVF	클러스터링 기반, 메모리 효율	Milvus, FAISS, pgvector
IVF-PQ	IVF + 양자화 (벡터 압축)	Milvus, FAISS
DiskANN	디스크 기반, 초대용량	Milvus, Azure

대부분 HNSW가 기본값. 수억 건 이상부터 IVF-PQ 등 압축 방식 고려.

3. 임베딩 모델과 벡터 DB의 분리

[임베딩 모델]              [벡터 DB]
텍스트 → 벡터 생성    →    벡터 저장 + 검색
(bge-m3, OpenAI 등)        (Qdrant, Milvus 등)

임베딩 모델: 모델마다 많이 다름
벡터 DB 검색 방식: 대체로 표준화되어 있음

3.1 임베딩 모델의 차이점

차원 수 차이

모델 차원

OpenAI text-embedding-3-small	1536
OpenAI text-embedding-3-large	3072
bge-m3	1024
bge-small-en	384
Cohere embed-v3	1024

차원이 다르면 DB 스키마 자체가 달라짐. 모델 바꾸면 컬렉션 재생성 필요.

의미 공간이 다름 (중요)

같은 문장이라도 모델마다 완전히 다른 벡터가 나옴.

"K8s 네트워킹"

OpenAI:  [0.024, -0.183, 0.471, ..., 0.092]   (1536차원)
bge-m3:  [-0.512, 0.087, -0.231, ..., 0.405]  (1024차원)

임베딩 모델을 섞어 쓰면 안 됨:

❌ 문서는 OpenAI로 임베딩 → 검색 쿼리는 bge-m3
   → 의미 공간이 달라서 거리 계산이 무의미

✅ 문서도 OpenAI, 쿼리도 OpenAI
✅ 문서도 bge-m3, 쿼리도 bge-m3

정규화 여부

정규화된 벡터: 길이가 1 → 내적이 곧 코사인 유사도라 빠름
정규화 안 된 벡터: 코사인 쓰려면 길이 계산 추가 필요

bge 계열, OpenAI는 정규화 출력. 일부 오픈소스 모델은 직접 정규화 필요.

특수 임베딩 형태 (bge-m3 예시)

타입 형태 특징

Dense	[0.02, -0.18, ...] 1024개	일반 의미 임베딩
Sparse	{30522: 0.5, 1024: 0.3, ...}	BM25처럼 키워드 기반
ColBERT (multi-vector)	토큰마다 벡터 (N × 1024)	정밀 매칭, 무거움

3.2 벡터 DB의 표준화

거리 계산 방식과 인덱스 알고리즘은 DB가 달라도 대체로 동일.

주요 벡터 DB 비교

DB 특징

Qdrant	Rust, 단순한 API, payload 필터링 강함
Milvus	대규모/분산, K8s 친화적
pgvector	PostgreSQL 확장, 기존 RDB와 함께
Weaviate	GraphQL, 모듈식
Elasticsearch	검색엔진 + 벡터, BM25 통합 쉬움

DB 선택은 인덱스 알고리즘보다 **운영 환경(K8s, 규모, 기존 스택)**에 좌우됨.

4. 언제 벡터 DB를 쓰는가

4.1 벡터 DB가 적합한 경우

RAG (Retrieval-Augmented Generation): LLM에 컨텍스트로 넣을 문서 검색
추천 시스템: "이 상품과 비슷한 거"
이미지/음성 검색: 의미적으로 유사한 멀티미디어
중복 탐지, 표절 검사: 표현이 달라도 유사한 내용 찾기
이상 탐지: 정상 패턴 벡터와 멀리 떨어진 데이터

4.2 일반 DB를 써야 하는 경우

사용자, 주문, 결제 같은 트랜잭션 데이터
정확한 조건 검색이 필요한 경우
집계, 통계, 리포팅

4.3 실무 아키텍처: 둘 다 같이 사용

[원본 문서]
    ├→ RDB / Object Storage: 원본 보관, 메타데이터, 권한
    └→ Vector DB: 청크별 임베딩 + 검색용 payload

검색 시:
    1. 사용자 쿼리 → 벡터화
    2. Vector DB에서 Top-K 청크 검색
    3. (필요하면) RDB에서 원본/권한 확인
    4. LLM에 컨텍스트로 전달

하이브리드 검색: BM25(키워드 매칭) + 벡터 검색(의미 매칭)을 RRF 등으로 결합해 정확도 향상.

5. 실무 의사결정 포인트

임베딩 모델 선택이 가장 중요 — 검색 품질의 대부분이 여기서 결정됨
벡터 DB는 운영 환경에 맞춰 선택 — K8s 환경, 데이터 규모, 기존 스택 고려
모델 변경 시 전체 재임베딩 필수 — 운영 비용이 크므로 신중히 선택
하이브리드 검색 고려 — 의미 검색만으로 부족한 경우 BM25 등과 결합

6. 추가 학습 키워드

HNSW 파라미터 튜닝: M, ef_construction, ef_search
양자화 (Quantization): 메모리 절약 기법 (Scalar, Product Quantization)
Reranker: 1차 검색 후 정밀 재정렬 (Cross-encoder 기반)
청킹 전략: 문서를 어떻게 분할할지 (fixed-size, semantic, recursive)
임베딩 모델 선택 기준: 도메인/언어/문서 길이/비용
MTEB 벤치마크: 임베딩 모델 성능 비교 지표

docker buildx 에러

보뇨 — Mon, 6 Jan 2025 14:30:23 +0900

(m2 pro 기준) arm64 이기도하고 도커 엔진을 colima 로 사용하고있는데 buildx 관련해서 에러가 나와 정리해봄.

우선 아래 경로로 이동하면 아마 docker-buildx 파일이 없을수있다.

total 109464

lrwxr-xr-x 1 1004883 629569319 37B Dec 22 2022 docker-compose -> /Users/1004883/.rd/bin/docker-compose

lrwxr-xr-x 1 1004883 629569319 66B Dec 26 2022 docker-dev -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-dev

lrwxr-xr-x 1 1004883 629569319 72B Apr 6 2023 docker-extension -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-extens

ion

lrwxr-xr-x 1 1004883 629569319 67B Apr 6 2023 docker-init -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-init

lrwxr-xr-x 1 1004883 629569319 67B Dec 26 2022 docker-sbom -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-sbom

lrwxr-xr-x 1 1004883 629569319 67B Dec 26 2022 docker-scan -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-scan

lrwxr-xr-x 1 1004883 629569319 68B Apr 6 2023 docker-scout -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-scout

이때 아래 경로에 동일한 이슈로 티켓이 만들어진것을 확인했고 m 시리즈에 맞는것을 별도로 설치해야했다.

https://github.com/abiosoft/colima/discussions/273

#!bin/bash

ARCH=arm64 # change to 'arm64' for m1

VERSION=v0.8.2

curl -LO https://github.com/docker/buildx/releases/download/${VERSION}/buildx-${VERSION}.darwin-${ARCH}

mkdir -p ~/.docker/cli-plugins

mv buildx-${VERSION}.darwin-${ARCH} ~/.docker/cli-plugins/docker-buildx

chmod +x ~/.docker/cli-plugins/docker-buildx

docker buildx version # verify installation

위 커맨드를 실행해서 정상적으로 버전이 나오면 끝이다!

코틀린 디자인 패턴 - 관용구와 안티 패턴 (입력유효성 검사)

보뇨 — Wed, 18 Dec 2024 13:36:28 +0900

단순히 if 구문으로도 처리할수있지만 코틀린 철학에 맞게 설계한것들이 몇몇개가 있는데

require, check 같은것들이 대표적이라고 생각한다.

require 는 에러를 IllegalArgumentException 으로 던지지만

check 는 IllegalStateException 으로 던지기때문에 새로 wrapping 해서 쓰는것도 나쁘지않을꺼같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

class Chapter09 {
 
    @Test
    fun basic() {
        require(isTeenager()) {
            "성인이용불가 컨텐츠입니다."
        }
 
        check(isBettingMoneyLess()) {
            "충분한 베팅금액이 있지않습니다."
        }
        
        naverRequire(isTeenager()) {
            "성인이용불가 컨텐츠입니다."
        }
    }
    
    private fun isTeenager(): Boolean {
        return false
    }
 
    private fun isBettingMoneyLess(): Boolean {
        return false
    }
 
    class NaverException(message: String) : RuntimeException(message)
    private inline fun naverRequire(check: Boolean, lazyMessage: () -> String) {
        if (check) {
            throw NaverException(lazyMessage())
        }
    }
}
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 관용구와 안티 패턴 (상수 효율적으로 사용하기)

보뇨 — Tue, 17 Dec 2024 16:45:00 +0900

항상 머리속으로 외우고 넘어갔던 부분인데 정리좀 할겸...

아래와 같이 할경우 Kotlin 프로젝트만 사용할때는 MAX_SIZE_1, MAX_SIZE_2 의 차이점이 느껴지지않는다.

단순한 차이인데 MAX_SIZE_1 을 Java 에서 사용할때는 Chapter08.Companion.MAX_SIZE_1 로 접근하게 되고,

MAX_SIZE_2 을 Java 에서 사용할때는 Chapter08.MAX_SIZE_1 로 접근하게 된다.

그외에 다른 부분이라면 Java 로 변환할때 Companion 바깥쪽에도 getter 가 생긴다는 점이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Chapter08 {
 
    companion object {
        val MAX_SIZE_1 = 3
 
        @JvmStatic
        val MAX_SIZE_2 = 3
 
        const val MAX_SIZE_3 = 3
    }
 
    @Test
    fun valuee() {
        val maxSize = MAX_SIZE_1
        val maxSize2 = MAX_SIZE_2
        val maxSize3 = MAX_SIZE_3
 
        println("$maxSize, $maxSize2, $maxSize3")
    }
}
Colored by Color Scripter

cs

아래 코드가 Java 로 변환될때이다.

보면 단순하게 const val 를 선언한것이 가장 깔끔해서 앞으로도 저렇게 사용할꺼같다.

왜냐하면 Java 에서 쓸때는 @JvmStatic 추가없이 동일하게 Chapter08.MAX_SIZE_3 로 사용할수있기때문!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

@Metadata(
   mv = {1, 9, 0},
   k = 1,
   xi = 48,
   d1 = {"\u0000\u0014\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0002\n\u0002\u0010\u0002\n\u0002\b\u0002\u0018\u0000 \u00052\u00020\u0001:\u0001\u0005B\u0005¢\u0006\u0002\u0010\u0002J\b\u0010\u0003\u001a\u00020\u0004H\u0007¨\u0006\u0006"},
   d2 = {"Lcom/example/mavenkotlinexample/Chapter08;", "", "()V", "valuee", "", "Companion", "maven-kotlin-example"}
)
public final class Chapter08 {
   @NotNull
   public static final Companion Companion = new Companion((DefaultConstructorMarker)null);
   private static final int MAX_SIZE_1 = 3;
   private static final int MAX_SIZE_2 = 3;
   public static final int MAX_SIZE_3 = 3;
 
   @Test
   public final void valuee() {
      int maxSize = MAX_SIZE_1;
      int maxSize2 = MAX_SIZE_2;
      int maxSize3 = 3;
      String var4 = maxSize + ", " + maxSize2 + ", " + maxSize3;
      System.out.println(var4);
   }
 
   public static final int getMAX_SIZE_2() {
      return Companion.getMAX_SIZE_2();
   }
 
   @Metadata(
      mv = {1, 9, 0},
      k = 1,
      xi = 48,
      d1 = {"\u0000\u0014\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0002\n\u0002\u0010\b\n\u0002\b\u0007\b\u0086\u0003\u0018\u00002\u00020\u0001B\u0007\b\u0002¢\u0006\u0002\u0010\u0002R\u0014\u0010\u0003\u001a\u00020\u0004X\u0086D¢\u0006\b\n\u0000\u001a\u0004\b\u0005\u0010\u0006R\u001c\u0010\u0007\u001a\u00020\u00048\u0006X\u0087D¢\u0006\u000e\n\u0000\u0012\u0004\b\b\u0010\u0002\u001a\u0004\b\t\u0010\u0006R\u000e\u0010\n\u001a\u00020\u0004X\u0086T¢\u0006\u0002\n\u0000¨\u0006\u000b"},
      d2 = {"Lcom/example/mavenkotlinexample/Chapter08$Companion;", "", "()V", "MAX_SIZE_1", "", "getMAX_SIZE_1", "()I", "MAX_SIZE_2", "getMAX_SIZE_2$annotations", "getMAX_SIZE_2", "MAX_SIZE_3", "maven-kotlin-example"}
   )
   public static final class Companion {
      private Companion() {
      }
 
      public final int getMAX_SIZE_1() {
         return Chapter08.MAX_SIZE_1;
      }
 
      public final int getMAX_SIZE_2() {
         return Chapter08.MAX_SIZE_2;
      }
 
      /** @deprecated */
      // $FF: synthetic method
      @JvmStatic
      public static void getMAX_SIZE_2$annotations() {
      }
 
      // $FF: synthetic method
      public Companion(DefaultConstructorMarker $constructor_marker) {
         this();
      }
   }
}
 
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 동작 패턴 이해하기 (해석기)

보뇨 — Mon, 16 Dec 2024 18:11:24 +0900

책에서는 해석기라고 되어있어서 뭐지 싶었는데 interpreter 패턴을 말하는것이였다.

근데 kotlin dsl 관련내용이라 사뭇 다르지만 해당 챕터를 통해서

그동안 예를들어 SelelectClause.() -> Unit 이런 형태의 비밀?! 에 대해 알게되었다.

즉, SelelectClause 라는 객체가 인자로 들어오는 (SelelectClause) -> Unit 이런형태와 동일하다고한다.

apply 를 왜 쓰면 좋은지 간접적으로도 나와있어서 한번 코드를 직접 작성하고 디버깅해보는것도 좋은거같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

class Chapter04Interpreter {
 
    @Test
    fun query() {
        val query = select("name, age") {
            from("users") {
                where("age > 25")
            }
        }
 
        println(query) // SELECT name, age FROM users WHERE age > 25
    }
 
    fun select(columns: String, from: SelectClause.() -> Unit): SelectClause {
        return SelectClause(columns).apply(from)
    }
 
    class SelectClause(private val columns: String) {
        private lateinit var from: FromClause
 
        // 방법 1
//        fun from(table: String, where: FromClause.() -> Unit) = apply {
//            from = FromClause(table)
//            from.apply(where)
//        }
 
        // 방법 2
        fun from(table: String, where: FromClause.() -> Unit): FromClause {
            this.from = FromClause(table)
            return this.from.apply(where)
        }
 
        override fun toString() = "SELECT $columns $from"
    }
 
    class FromClause(private val table: String) {
        private lateinit var where: WhereClause
 
        fun where(condition: String) = this.apply {
            where = WhereClause(condition)
        }
 
        override fun toString() = "FROM $table $where"
    }
 
    class WhereClause(private val condition: String) {
        override fun toString() = "WHERE $condition"
    }
}
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 동작 패턴 이해하기 (책임연쇄)

보뇨 — Mon, 16 Dec 2024 17:34:01 +0900

내가 가장 좋아하는 책임연쇄패턴인데 이전 글과 동일하게 작가가 typealias 로 만들었길래 재미있어서 기록해봅니다.

우선 아래 코드는 interface 로 선언했을때 기준입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class Chapter04Chain {
 
    @Test
    fun sod() {
        val chain = BasicValidationHandler(AnswerHandler())
 
        chain.handle(Request("amugae2@naver.com", "question1 -> hello?"))
    }
 
    data class Request(val email: String, val question: String)
    data class Response(val answer: String)
 
    interface Handler {
        fun handle(request: Request): Response
    }
 
    class BasicValidationHandler(private val next: Handler) : Handler {
        override fun handle(request: Request): Response {
            if (request.email.isEmpty()) {
                throw IllegalArgumentException()
            }
 
            return next.handle(request)
        }
    }
 
    class AnswerHandler : Handler {
        override fun handle(request: Request): Response {
            println("validation OK: ${request.email}, ${request.email}")
            return Response("validation OK: ${request.email}, ${request.email}")
        }
    }
}
Colored by Color Scripter

cs

그리고 여기 코드부터가 typealias 를 사용했을때기준인데

사실 별차이는 없지만 여기서부터 확연히 느껴지는게 Javascript 고차함수와 완전히 동일한거같다는 느낌을 받았다.

그말인즉슨 더 재미있게 짤수있을꺼같은데 다만 동시에 일반 Java 개발자부터 시작하는 분들과 협업할때는 사용하기 어려울꺼같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

typealias Handler = (request: Chapter04Chain.Request) -> Chapter04Chain.Response
 
class Chapter04Chain {
 
    @Test
    fun sod() {
        val chain = BasicValidationHandler(AnswerHandler())
 
        chain(Request("amugae2@naver.com", "question1 -> hello?"))
    }
 
    data class Request(val email: String, val question: String)
    data class Response(val answer: String)
 
    class BasicValidationHandler(private val next: Handler) : Handler {
        override fun invoke(request: Request): Response {
            if (request.email.isEmpty()) {
                throw IllegalArgumentException()
            }
 
            return next(request)
        }
    }
 
    class AnswerHandler : Handler {
        override fun invoke(request: Request): Response {
            println("validation OK: ${request.email}, ${request.email}")
            return Response("validation OK: ${request.email}, ${request.email}")
        }
    }
}
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 동작 패턴 이해하기 (커맨드)

보뇨 — Mon, 16 Dec 2024 17:09:29 +0900

책에서 typealias 를 통해 interface 나 class 선언없이 하는 방법을 많이 소개해주는거같은데

지금도 그렇지만 이게 객체지향적인가? 반발감이 있긴하다..(이런식으로 쓰는건 상상도못했기때문에 어색..)

근데 어떻게보면 쉬운방법으로 사고전환이 가능해서 해당 언어가 지원해주는 방법을 많이 활용하는게 좋을꺼같다

Java 컨벤션대로 짜면 결국 Java 코드이니까 특정 언어를 만든 개발자의 의도를 따라가다보면 이점을 깨닫게 될지도...?

아래 기능에서는 undo 기능이 추가되어야하는데

커맨드패턴같은경우 저라면 그냥 interface 구현식으로 할꺼같아서 추가로 기능개발은 하지않았다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

typealias Command = () -> Unit
 
class Chapter04 {
 
    @Test
    fun test() {
        val t = Trooper()
 
        t.addOrder(moveGenerator(t, 1, 1))
        t.addOrder(moveGenerator(t, 2, 2))
        t.addOrder(moveGenerator(t, 3, 3))
        t.addOrder { t.move(4, 4) }
 
        t.executeOrders()
    }
 
    open class Trooper {
        private val orders = mutableListOf<Command>()
 
        fun addOrder(order: Command) {
            this.orders.add(order)
        }
 
        fun executeOrders() {
            while (orders.isNotEmpty()) {
                val order = orders.removeFirst()
                order()
            }
        }
 
        fun move(x: Int, y: Int) {
            println("Moving to $x:$y")
        }
        
    }
 
    val moveGenerator = fun(s: Trooper, x: Int, y: Int): Command {
        return fun() { s.move(x, y) }
    }
}
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 구조 패턴 이해하기 (상태)

보뇨 — Fri, 13 Dec 2024 13:42:53 +0900

개인적으로 자바에서 상태패턴 작성할때 고민이 되던 부분이였는데 코틀린 언어적으로 처리가 가능한게 신기해서 기록해봄.

무엇보다 switch case 문은 저도 별루지만 그 기능을 만든건 다 이유가 있다고 생각하니...

우선 sealed 키워드없이 abstract 를 쓰거나 아무것도 안적게 되면 Dead 클래스에 따른 requireMoodMessage 처리가 아직 반영되지않았기때문에 에러가 발생한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class Chapter03Test {
 
    @Test
    fun sealedTest() {
        println(requireMoodMessage(Still()))
        println(requireMoodMessage(Aggressive()))
        println(requireMoodMessage(Dead()))
    }
 
    sealed class Mood
 
    class Still : Mood()
    class Aggressive : Mood()
    class Dead : Mood()
 
    fun requireMoodMessage(mood: Mood): String {
        return when (mood) {
            is Still -> "still doing something"
            is Aggressive -> "idk why he is so aggressive"
        }
    }
}
Colored by Color Scripter

cs

 

그래서 아래와 같이 수정하게되면 더이상 에러 메시지가 나오진않는다.

다만, class 선언한쪽에서 warning 이 발생하는데 해당 이유는 equals, hashCode 를 오버라이딩해달라는 소리

이때 생각해보면 어차피 상태라는것이 중복될필요가 없기도해서 (특정 케이스의 경우 제외) 싱글톤으로 작성하면 된다.

그래서 방법은 아래를 계속 이어서 확인하면된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Chapter03Test {
 
    @Test
    fun sealedTest() {
        println(requireMoodMessage(Still()))
        println(requireMoodMessage(Aggressive()))
        println(requireMoodMessage(Dead()))
    }
 
    sealed class Mood
 
    class Still : Mood()
    class Aggressive : Mood()
    class Dead : Mood()
 
    fun requireMoodMessage(mood: Mood): String {
        return when (mood) {
            is Still -> "still doing something"
            is Aggressive -> "idk why he is so aggressive"
            is Dead -> "walking dead"
        }
    }
}
Colored by Color Scripter

cs

1
2
3
4
5
6
7
8
9
10
11
12
13

// 방법 1
data object Aggressive : Mood()
 
// 방법 2
class Dead : Mood() {
        override fun equals(other: Any?): Boolean {
            return this === other
        }
 
        override fun hashCode(): Int {
            return System.identityHashCode(this)
        }
    }
Colored by Color Scripter

cs

코틀린 디자인 패턴 - 구조 패턴 이해하기 (퍼사드, 프록시)

보뇨 — Fri, 13 Dec 2024 11:54:43 +0900

비교적 짧은 내용들이라서 2개의 패턴을 합쳐서 설명하도록하겠습니다.

근데 책을 읽으면서 사실 완전히 공감하는건 아닌데...일단 한번 소스를 보시져!

퍼사드 패턴

확장함수를 써서 처리하라고하는데 이게 좀 이해가 안되는게

그렇게되면 중구난방으로 분산되기도 하고 특정 유틸성 클래스를 두는게 좋다고 생각합니다.

무엇보다 퍼사드는 개인적으로 여러개의 ~Service 클래스를 묶어서 하나의 클래스에서 동작시키게끔하는건데 확장함수를 쓰게되면

성격이 좀 달라진다고 생각하기때문에 참고용으로 기록..!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Chapter03Test {
 
    @Test
    fun facadeTest() {
        val memberService = MemberService()
        memberService.execute()
    }
 
    class MemberService {
 
        private fun doSomething(): String {
            return "hello"
        }
    }
 
    fun MemberService.execute() {
        print("doSomethingElse...")
    }
 
}
Colored by Color Scripter

cs

 

프록시

사실 프록시에는 가상 프록시, 원격 프록시, 보호 프록시 또는 접근 제어 프록시까지 총 3개의 형태가 있는데 책에서는 가상 프록시 형태로 글을 소개하고있습니다. 다른 2개의 프록시 형태도 결국 외곽에서 보면 똑같은데 목적에 따라 이름을 다르게 지은것!

아래 소스를 실행시키면 아래와 같이 출력

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class Chapter03Test {
 
    @Test
    fun lazyProxyTest() {
        val catImage = CatImage("smile", "www.naver.com")
        catImage.printImage()
    }
 
    data class CatImage(val thumbnailUrl: String, val url: String) {
        val image: ByteArray? by lazy {
            // 매우 시간이 많이 걸리는 작업
            println("모든게 끝났습니다.")
            null
        }
 
        fun printImage() {
            println("출력하기전...")
            println(image)
            println("출력하기끝!!")
        }
    }
}
Colored by Color Scripter

cs

 

출력하기전...
모든게 끝났습니다.
null
출력하기끝!!

코틀린 디자인 패턴 - 구조 패턴 이해하기 (브릿지)

보뇨 — Wed, 11 Dec 2024 15:49:23 +0900

브릿지 패턴은 이전에도 소개했었지만 간략하게 말하자면 인터페이스 구현을 통해 모든 기능을 만들게되면

인터페이스 한개를 수정할때 구현받은 모든 클래스를 수정해야한다는 문제가 생기지만 각각 기능을 각각의 인터페이스로 쪼개서

별도의 구현 클래스로 분리하게된다면 영향도는 비교적 최소화할수있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

typealias PointsOfDamage = Long
typealias Meters = Int // java 일경우 별도의 클래스를 만들어야했는데 별칭지정하여 간단하게 구현가능
 
class Chapter03BridgeTest {
 
    @Test
    fun bridgePatternTest() {
        // 일반적인경우 구현만 받아서 처리할수있는데 하나의 인터페이스 구현만할경우 변경요소가 N개만큼 발생하기때문에
        // 초기화하기위해 각 동작에 따른 기능을 분리하여 HasA 관계로 수정
        val stormTrooper = StormTrooper(Rifle(), RegularLegs())
        val flameTrooper = StormTrooper(FlameThrower(), RegularLegs())
        val scoutTrooper = StormTrooper(Batton(), AthleticLegs())
 
        println("이동")
        stormTrooper.move(1L,1L)
        flameTrooper.move(1L,1L)
        scoutTrooper.move(1L,1L)
 
        println("공격")
        stormTrooper.attackRebel(1L, 1L)
        flameTrooper.attackRebel(1L, 1L)
        scoutTrooper.attackRebel(1L, 1L)
    }
 
    interface Trooper {
        fun move(x: Long, y: Long)
        fun attackRebel(x: Long, y: Long)
    }
 
    interface Weapon {
        fun attack(): PointsOfDamage
    }
 
    interface Legs {
        fun move(): Meters
    }
 
    class Rifle : Weapon {
        override fun attack(): PointsOfDamage = RIFLE_DAMAGE
    }
 
    class FlameThrower : Weapon {
        override fun attack(): PointsOfDamage = RIFLE_DAMAGE * 2
    }
 
    class Batton : Weapon {
        override fun attack(): PointsOfDamage = RIFLE_DAMAGE * 3
    }
 
    class RegularLegs : Legs {
        override fun move(): Meters = REGULAR_SPEED
    }
 
    class AthleticLegs : Legs {
        override fun move(): Meters = REGULAR_SPEED * 2
    }
 
    class StormTrooper(
        private val weapon: Weapon,
        private val legs : Legs,
    ) : Trooper {
        override fun move(x: Long, y: Long) {
            println("이동 - ${legs.move()}")
        }
 
        override fun attackRebel(x: Long, y: Long) {
            println("공격 - ${weapon.attack()}")
        }
    }
 
    companion object {
        const val RIFLE_DAMAGE = 3L
        const val REGULAR_SPEED: Meters = 1
    }
}
Colored by Color Scripter

cs