Developer.

podman build 시 too many open files 대응

제이왑 — Fri, 9 May 2025 22:12:14 +0900

podman 을 통한 image build 시, 경우에 따라 `too many open files` 에러가 발생할 수 있다.

직접 빌드를 수행하는 경우

`podman build` 명령을 통해 직접 빌드를 실행하는 경우, `--ulimit` 설정을 통해 해결할 수 있다.

podman build --ulimit=nofile=1048576:1048576 <...>

간접적으로 빌드를 수행하는 경우 (ex. docker(podman) compose 를 통한 build)

docker-compose 를 통한 빌드를 수행하게 되는 경우에는 --ulimit 설정을 직접적으로 설정하기 어려운 경우가 있다. docker-compose.yml 에서 `service.build.ulimits` 필드의 설정으로 ulimit 을 설정할 수 있지만, podman 4 버전의 경우에는 해당 필드가 무시된다. (1024 로 실행됨)

podman 5 버전에서 해결되었지만, os 버전에 따라 패키지 관리 시스템에 배포되지 않아 podman 5 지원이 되지 않아 설치가 어렵다. 그런 경우에는 아래 설정을 통해 우회 가능하다.

# ~/.config/containers/containers.conf

[containers]
default_ulimits = [
 "nofile=65535:65535",
]

container 실행 시 ulimits 기본값을 변경함으로써 발생하는 too many open files 에러를 회피할 수 있다.

정보 검색 평가 지표 ( + RAGAS)

제이왑 — Sun, 13 Oct 2024 14:59:14 +0900

https://amitness.com/posts/information-retrieval-evaluation 글을 읽고 정리한 문서입니다.

지표의 목적

상위 N 결과가 얼마나 우수한지 어떻게 평가할 것 인가?

Binary relevance

문서에 대한 관련성을 "있다 혹은 없다" 로만 판단한다.
현재 Ranking model 이 query 에 대해서 5개의 각각의 문서 관련도는 `[1, 0, 1, 0, 1]` 로 나타낼 수 있다. (*binary*)

Order-unaware metrics

Precision@k

$$
Precision@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ positives@k)}
$$

이 메트릭은 상위 K 결과의 관련 항목 수를 정량화합니다.
추출된 k 랭크 문서 중에서 관련 있는 문서의 갯수

예시) Precision@2

Recall@k

$$
Recall@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ negatives@k)}
$$

이 메트릭은 쿼리에 대한 모든 실제 관련 결과 중에서 몇 개의 실제 관련 결과가 표시되었는지 알려줍니다.
전체 관련 있는 문서 갯수 중에서 k 랭크 내에 추출된 관련 있는 문서의 갯수

예시) Recall@2

참고: Precision 과 Recall 의 집합관계

A = 모델에서 문서가 관련 있다고 예측한 영역 (예측)
B = 실제 관련 있는 문서가 있는 영역 (정답)
b 영역 = True Positive 로 모델이 추출한 관련 문서 중 실제 관련 있는 문서가 있었던 영역

모델이 반환한 결과 중에서 실제 관련도 있는 문서를 추출한 비율이 precision, 실제 관련 있는 문서 목록 중 model 이 올바르게 문서를 추출한 비율이 recall 이라고 할 수 있다.

F1@k

$$
F1@k = \frac{2*(Precision@k) * (Recall@k)}{(Precision@k) + (Recall@k)}
$$

precision 과 Recall 의 조화평균으로 계산한다.
조화 평균은 산술 평균보다 비중의 평균을 계산할 때 더 직관적이다. precision 과 recall 모두 중요한 값이기 때문에, 두 값 모두 높을 때 랭킹 모델의 성능이 더 좋다고 말할 수 있다. 따라서 두 값이 조화롭게 좋을 때 가장 높은 조화 평균을 사용한다.
- The truth of the F-measure

참고. 조화평균

개별 데이터의 역수의 평균에 대한 역수이다.

조화 평균은 비율의 평균을 계산하는 데 자주 사용되는데, 각 데이터의 가중치가 동일하기 때문에 비율에 대한 가장 적절한 측정이다.

예를 들어, 산술 평균은 큰 데이터 에 높은 가중치를 부여되고 기하 평균은 작은 데이터 요소에 낮은 가중치를 부여되는데 비해 조화평균은 전체적으로 동일한 가중치가 부여된다.

다음 표는 산술평균은 모두 같게 평가되지만, 조화평균은 각각 다름을 알 수 있다.

A	B	산술평균	조화평균
10	0	5	0
9	1	5	1.8
8	2	5	3.2
7	3	5	4.2
6	4	5	4.8
5	5	5	5
4	6	5	4.8
3	7	5	4.2
2	8	5	3.2
1	9	5	1.8
0	10	5	0

조화평균은 표에서 확인할 수 있는 것처럼, 두 값이 조화롭게 존재할 때 가장 높게 평가된다 (산술 평균과 같다). 또한 산술평균에 비해 큰 비중이 끼치는 편향이 줄어든다고 볼 수 있다.

Order-aware metrics

Mean Reciprocal Rank(MRR, Rank 역수 평균)

$$
MRR = \frac{1}{|Q|} \sum_{i=1}^{|Q|} \frac{1}{rank_{i}}
$$

where:

$|Q|$ denotes the total number of queries
$rank_{i}$ denotes the rank of the first relevant result
이 메트릭은 시스템이 가장 적절한 항목을 반환하고 해당 항목이 더 높은 위치에 있기를 원할 때 유용합니다.

Average Precision(AP, Precision 평균)

$$
AP = \frac{\sum_{k=1}^{n} (P(k) * rel(k))}{number\ of\ relevant\ items}
$$

where:

$rel(k)$ is an indicator function which is 1 when the item at rank K is relevant.
$P(k)$ is the $Precision@k$ metric
Average Precision은 모델이 선택한 모든 실측 관련 항목의 순위가 더 높은지 여부를 평가하는 지표입니다. MRR과 달리 모든 관련 항목을 고려합니다.

Example 1)

Example 2)

Mean Average Precision

$$
MAP = \frac{1}{Q} \sum_{q=1}^{Q} AP(q)
$$

where

$Q$ is the total number of queries
$AP(q)$ is the average precision for query $q$.
여러 쿼리에 걸쳐 평균 정밀도를 평가하려면 MAP를 사용할 수 있습니다.

RAGAS 에서 측정하고 있는 지표

Context Utilization (Context Precision)

https://docs.ragas.io/en/latest/concepts/metrics/context_precision.html
** context utilization 은 context precision 에서 ground truth 가 아닌 llm 답변을 사용하는 지표이다.

답변을 정답이라고 가정했을 때, 반환된 context 에서 관련된 문서가 높게 랭킹되었는 지를 수치화한다.
retriever 의 성능 지표로 사용

$$
\text{Context Precision@K} = \frac{\sum_{k=1}^{K} \left( \text{Precision@k} \times v_k \right)}{\text{Total number of relevant items in the top } K \text{ results}}
$$

$$
\text{Precision@k} = {\text{true positives@k} \over (\text{true positives@k} + \text{false positives@k})}
$$

where:

$K$ 는 context 내 Chunk 수
$v_k \in {0, 1}$ 은 $k$ 랭크에 위치한 문서가 관련되어 있는 지 없는 지를 나타내는 지표이다.

Answer Relevancy

https://docs.ragas.io/en/latest/concepts/metrics/answer_relevance.html

답변에 기반하여 생성한 질문들의 Embedding vector 와 실제 질문의 embedding vector 를 cosine similarity 로 비교하여 연관도를 측정한다.

$$
\text{answer relevancy} = \frac{1}{N} \sum_{i=1}^{N} cos(E_{g_i}, E_o)
$$

$$
\text{answer relevancy} = \frac{1}{N} \sum_{i=1}^{N} \frac{E_{g_i} \cdot E_o}{|E_{g_i}||E_o|}
$$

Context Relevancy

https://docs.ragas.io/en/latest/concepts/metrics/context_relevancy.html

context 에 포함된 문장이 답변과 얼마나 연관되어 있는 지를 나타낸다.

$$
\text{context relevancy} = {|S| \over |\text{Total number of sentences in retrieved context}|}
$$

참고 링크

서버에서 Client IP 를 추출하는 여러가지 방법

제이왑 — Sun, 13 Oct 2024 14:55:15 +0900

서비스 요구사항에 따라 Client IP 가 필요한 상황이 있다. 보안을 위해서 Client IP 를 확인하여 접근을 허용할 수 있다. 허용되지 않은 IP 의 경우 접근을 막을 수 있다. 로그 요구사항으로 어떤 사용자가 접근하고 있는 지를 기록하기 위해 Client IP 를 남겨야 할 수 있다.

하지만 사용자나 서비스의 네트워크 구성에 따라서 Client IP 를 추출하는 것이 쉽지 않을 수 있다. 프록시가 있어 직접 연결한 Client 를 실제 사용자로 판단할 수 없는 경우가 그렇다. 프록시 뒤에 있는 사용자를 찾으려고 노력하면 Client IP 를 숨기거나 우회하기 위해서 변조를 시도하는 상황을 마주하게 된다. 그래서 Client IP 를 추출하기 위한 여러 방안들을 아래에 정리하게 되었다.

결론부터 먼저 말하면, 일반적인 상황에서 나는 X-Forwarded-For 의 가장 오른쪽의 Public IP 를 Client IP 로 판단하기로 했다. 믿을 수 없는 목록 중에서 신뢰할 수 있으면서 간단하고, 빠른 방법이라 생각하기 때문이다. 하지만 여러 방안들을 조사했을 때, 어떤 상황에서는 사용할 수 있는 지, 또 어떤 지점이 문제가 되는 지 생각해볼 수 있었다. 그래서 고민했었던 여러 방안들을 소개하려고 한다.

Remote IP

프록시가 없는 간단한 구조의 서비스라면 서버에 연결된 Remote IP 를 Client IP 로 추출할 수 있다. 하지만 Remote IP 가 실제 사용자의 IP 라는 확신이 없다면, Client IP 로 사용하기 어렵다. 사용자 네트워크 구성에서 proxy 가 있다면, 서버에 연결된 Remote IP 는 실제 사용자의 Client IP 가 아닐 수 있다.

여기에서 서비스 요구사항에 대한 명확한 정의가 필요해질 수 있다. 사용자 네트워크의 사설 IP 를 추출해야 하는 지, 아니면 공인 IP 를 추출해야 하는 지 정의가 필요하다. 사설 IP 는 서비스의 입장에서 큰 의미가 없기 때문에, 보통 공인 IP 를 추출한다.

요구 사항을 어느 정도까지 정확하게 추출해야 하는 지 명확히 정의하고, 요구 사항에서 필요한 값을 추출해낸다는 생각이 필요하다.

`X-Forwarded-For` 헤더 가장 왼쪽의 값 (DON'T)

X-Forwarded-For 헤더는 요청이 어떤 IP 들을 거쳐 전달되었는 지 알 수 있도록 도와준다. 요청이 전달되면서 거쳐오는 IP 는 우측에 추가되기 때문에, 가장 왼쪽의 IP 를 Client IP 라고 생각할 수 있다.

하지만 이 값을 실제 Client IP 로 판단하는 것은 위험하다. 헤더는 요청을 전달받은 프록시에서 언제든지 수정 가능하기 때문이다. 이런 지점을 노린 X-Forwarded-For 변조는 Stack Overflow 도 당했었던 유명한 공격 기법이다. 사용자가 언제든지 수정할 수 있는 가장 왼쪽의 IP 를 Client IP 로 판단한다면 예기치 못한 결과가 발생할 수 있다.

`X-Forwarded-For` 헤더 내 `proxy hop` 수 이전의 값

앞에서 헤더는 변조 가능하다고 말했다. 하지만 서비스에서 구성해둔 네트워크로 넘어온 뒤에는 값이 변조되기 쉽지 않다. 이런 맥락에서 X-Forwarded-For 헤더에서 오른쪽에 위치한 IP 일수록 신뢰할 수 있는 IP 이다.

서버로 오기 전까지의 서비스 네트워크 hop 수를 proxy hop 이라고 하자. 이 proxy hop 을 알 수 있다면, X-Forwarded-for 헤더의 오른쪽 끝에서 proxy hop 만큼 왼쪽에 있는 IP 를 Client IP 로 판단할 수 있다. 서비스에서 진행한 proxy 구성의 hop 이 고정되어있거나, 알 수 있다면, proxy hop 이전의 값을 client ip 로 사용할 수 있다.

이 방법의 문제점은 고정된다고 생각했던 proxy hop 이 언제까지나 고정되지 않기 때문이다. 프록시가 어떻게 구성되는 지에 따라 Client IP 추출에 영향을 줄 수 있다는 점은 불필요한 의존성을 만든다. (네트워크 구성에 따라 서비스가 변경되어야 한다는 점은 권장되지 않는다. )

`X-Forwarded-For` 헤더 내 가장 우측의 Public IP

다시 X-Forwarded-For 헤더에서 오른쪽에 있는 IP 일 수록 신뢰할 수 있는 IP 라는 점에 집중하자. 그리고 사용자 요청이 인터넷을 통했다는 점을 생각하면, 사용자는 서비스로 요청을 보내기 위해서 공인 IP 를 거쳐야 한다.

실제 IP 가 x.x.x.x 인 사용자가 값을 X-Forwarded-For 값을 변조하여 1.1.1.1 을 넣었다고 하자.
이 값으로 요청을 한다면, proxy 는 x.x.x.x 가 요청한 X-Forwarded-For: 1.1.1.1 값을 받게 된다.
서비스는 X-Forwarded-For: 1.1.1.1, x.x.x.x 값을 받게 될 것이다. 이 때의 최우측 IP 는 x.x.x.x 가 되므로, 이 값을 Client IP 로 판단할 수 있다.

이 방법에서도 함정이 있을 수 있다. 다만 서비스 네트워크가 공인 IP 간에 프록시하고 있다면, 단순하게 적용하기 어려울 수 있다. 하지만 공인 IP 프록싱이 고정 대역이라면, 해당 값을 필터링하는 식으로 응용해볼 여지도 충분하다.

Proxy 에서 특정 헤더에 할당한 값

프록시에서 X-Real-IP, True-Client-IP 등의 헤더에 기존 Client IP 를 담아두는 방법이 있다. 제한된 상황에서 많이 쓰이기도 하는 방법이다.

하지만 헤더에 실제 Client IP 를 담는 방법은 보안에 취약할 수 있다. 해커가 특정 헤더에 Client IP 를 담는다는 것을 알고, 이 값을 변조한다면 이 헤더 값을 신뢰할 수 없다. 프록시에서 Client IP 헤더 값을 항상 덮어 쓰는 방법으로 대응할 수도 있다. 하지만 여러 프록시를 거쳐야 하는 경우에는 항상 덮어 쓰는 것이 어려울 수 있다. 서비스의 구성에 따라서 판단하여 사용할 수 있어야 한다.

결론

Client IP 를 추출할 때 생각했던 방안들 중에 가장 신뢰할 수 있었던 값은 X-Forwarded-For 헤더에서 가장 오른쪽에 위치한 Public IP 이다. 하지만 빠르게 처리해야 한다면 proxy hop 을 사용하는 방안도 충분히 고려해볼만 한 아이디어였다. 또 proxy 하는 상황이 없다면, 단순 Remote IP 를 가지고도 충분히 Client IP 를 찾을 수 있다.

하지만 사용자의 네트워크나 서비스 네트워크 환경에서 여러 프록시가 존재하는 일반적인 구성을 고려한다면 X-Forwarded-For 헤더 값에서 가장 오른쪽에 위치한 Public IP 를 추출하는 것이 효과적인 방법이었다.

참고

https://adam-p.ca/blog/2022/03/x-forwarded-for/

NGINX module 개발 시 참고 하기 좋은 글

제이왑 — Sun, 13 Oct 2024 14:52:41 +0900

NGINX 모듈은 언제 만드나요?

Nginx 는 많은 웹 서비스들에서 사용하는 웹 서버 프로그램 입니다. Nginx 는 그 자체로 강력하고, 다양한 모듈을 가지고 있기 때문에 많은 서비스들에서 사용됩니다.

하지만 서비스의 요구사항에 따라서, Nginx 그 자체만으로는 부족한 상황이 발생합니다. 앱 서버에서 처리하기에는 앱의 로직과는 동떨어져있어 책임원칙에 위반하고, nginx 의 설정 로직에서 처리되면 좋을 것 같은 요구사항들이 있습니다. 예를 들면, 프록시를 할 때 특정 값을 가공하여 넘겨주고 싶을 수 있습니다. 또, header 에 있는 값을 가지고 $remote_addr 를 변조하여 사용하고 싶다거나 하는 상황이 있습니다.

그런 상황에서 적절한 처리를 할 수 있는 nginx 모듈을 직접 만들어 nginx 에 적용해줄 수 있습니다. Nginx 는 C 언어로 만들어져 있어 모듈도 보통 C 로 작성됩니다. 하지만 최근에는 Lua 로 작성하거나 njs (nginx 에서 사용하기 위한 일종의 custom js) 를 사용하여 모듈이 작성되기도 합니다. 하지만 이 글에서는 C 언어로 Nginx 모듈을 작성할 때 참고하기 좋은 글들을 소개합니다.

Nginx 공식 문서

> https://nginx.org/en/docs/dev/development_guide.html

공식 문서는 어떤 상황에서든지 중요한 것 같습니다. 이미 만들어진 프로그램에 대해서 추가로 개발할 때는 설명서를 자세하게 살펴봐야 합니다.

공식 문서에서는 Nginx 에서 사용되는 자료형과 구조체, 변수, 로그 방식부터 Nginx 가 HTTP 관련 요청을 처리하는 방식 등 다양한 내용들이 기록되어 있습니다. 따라서 모듈을 개발하는 경우가 아니더라도, Nginx 를 깊게 이해하고 싶다면 한번 쯤 읽고 공부해보기 좋은 문서입니다. 하지만 이 글을 읽었다고 해서 모듈 개발을 착수하기는 어렵습니다. 개발 시에 참고하기 좋은 튜토리얼이 따로 준비되어 있지는 않습니다. 처음 접하는 사람이 읽기에 다소 이해하기 어려운 용어들도 많습니다. 하지만 개발하는 도중에는 이 문서를 계속 참고하면서 코드를 이해하고 수정해나가야합니다.

NAVER D2 - NGINX 모듈 제작하기

> https://d2.naver.com/helloworld/192785

네이버 기술블로그에 작성된 Nginx 모듈 제작 튜토리얼 글입니다. 제가 처음 모듈을 제작해야된다고 했을 때 참고했던 좋은 글이었습니다.

2012년에 작성되어 조금은 달라진 부분도 있겠지만, 크게 변경된 점이 없고 충분히 컴파일하는데 이슈가 없었습니다. 그리고 Nginx 에서 모듈이 구동되는 개념을 잘 설명하고 있고, 작더라도 구동할 수 있는 커스텀 모듈을 만들 수 있도록 잘 설명하고 있습니다. 모듈을 작성할 때 필요한 인터페이스, 변수와 핸들러, 모듈의 컨텍스트 등 필요한 개념에 대해서 자세한 설명과 함께 작성해볼 수 있는 코드를 제공하여 큰 도움이 되었습니다.

Evan Miller 의 Nginx Modules Guide

> https://www.evanmiller.org/nginx-modules-guide.html

A/B 테스트 샘플 데이터 계산기로 유명한 Evan Miller 가 작성한 nginx module 가이드입니다. Nginx 모듈의 구성을 좀 더 자세하게 설명합니다. 각 항목에 대한 개념과 형태를 잘 설명하고 있어, 자주 참고하고 여러번 읽으면서 개발해나갔습니다. 특히 개발 문서에서 디테일하게 설명되지 않는 코드 동작 흐름을 잘 설명하고 있습니다. Nginx 모듈의 전체에서 부분으로 설명해 나가는 방식은 모듈을 좀 더 쉽게 이해할 수 있도록 도와주었습니다.

Nginx 의 내부 모듈 코드

> https://github.com/nginx/nginx/tree/master/src/http/modules

실제 모듈의 사례를 참고하는 것은 빠르게 개발하는 데 중요합니다. Nginx 코드에는 이미 많은 모듈이 개발되어 함께 컴파일됩니다. 작성된 모듈들을 참고하면 request 에 저장되어 있던 데이터를 좀 더 이해 할 수 있었고, 이해하기 어려웠던 ngx 구조체들을 사용하는 방식을 참고할 수 있었습니다.

기타 다른 Nginx 모듈 레포지터리

Nginx 모듈 코드 뿐만 아니라, Nginx 써드파티 모듈들도 있어 개발 시에 참고해볼 수 있었습니다.

headersmore (openresty)

user-agent (alibaba)

Docker Image 를 로컬 파일로 저장하기

제이왑 — Tue, 19 Mar 2024 12:00:29 +0900

컨테이너 이미지를 활용하여 빠르게 서버 환경을 구축하는 건 요즘 흔한 일이다.

다만 오프라인 환경에서는 외부 환경에서 이미지를 가져올 수 없기 때문에, 컨테이너 이미지를 활용하기 위해서는 파일로 변환하여 폐쇄망으로 자료 전송하는 등의 과정이 필요하다.

외부 image 를 로컬 파일로 저장

## (online) - image download
docker pull {image}:{tag} --platform={platform}

## (online) - image -> tar package
docker save {image}:{tag} > {image_filename}.tar

로컬 파일 image 를 로드

## (offline) load image from package
docker load -i {image_filename}.tar

## (offline) check image loaded
docker image ls

여러 줄로 구성된 파일을 line-by-line loop 로 실행하기

제이왑 — Mon, 18 Mar 2024 12:00:21 +0900

하나의 파일에 여러 줄로된 정보를 저장해두고, bash로 일괄 처리하고 싶을 때 아래 코드를 복사해서 활용하자.

list=$(cat list.txt) # multi-line 으로 list 에 할당된다.

while IFS= read -r item; do 

    # TODO: do something
    echo $item

done <<< "$list"

특정 문자열을 파일에서 일괄 변경하기

제이왑 — Sun, 17 Mar 2024 12:00:02 +0900

`fruit.txt` 파일 내에 있는 모든 `apple` 을 `banana` 로 변경

# linux
sed -i 's/apple/banana/g' /fruit.txt

mac 의 경우 sed 의 -i 에 extension 파라미터가 필요하다. extension은 변경하는 파일을 복사한 뒤 붙일 일종의 postfix 이다. 원본 문서를 저장해두지 않을 경우 빈칸으로 두자.

# mac 
sed -i '.old' 's/apple/banana/g' /fruit.txt

Python 에 특정 OpenSSL 버전 연동하여 설치

제이왑 — Sat, 16 Mar 2024 12:51:05 +0900

문제

urllib3 을 사용할 때, 다음과 같은 에러가 발생하면서 python 스크립트가 실행되지 않는다.

ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with 'OpenSSL 1.0.2k-fips  26 Jan 2017'.
See: https://github.com/urllib3/urllib3/issues/2168

원인을 파악해보고자 구글링을 하니 다음과 같은 공식 가이드와 짤막한 해결방안이 있었다.
요약하면, urllib3 부터는 OpenSSL 1.1.1+ 버전만을 지원하므로, 서버에 설치되어 있는 openssl 버전을 업그레이드 하여야 한다.
제공된 가이드의 경우 RHEL7 의 경우 os 업그레이드를 하라는 배보다 배꼽이 다소 더 큰 가이드를 하고 있다.

https://urllib3.readthedocs.io/en/latest/v2-migration-guide.html#common-upgrading-issues

v2.0 Migration Guide

urllib3 v2.0 is now available! Read below for how to get started and what is contained in the new major release. Migrating from 1.x to 2.0: We’re maintaining functional API compatibility for most...

urllib3.readthedocs.io

해결방안

python 을 업그레이드한 openssl 을 연동해서 직접 컴파일하여 설치해보자. (아래의 stackoverflow 글을 참고하였습니다.)

OpenSSL 설치

# Install OpenSSL 1.1.1
cd /opt
curl https://ftp.openssl.org/source/old/1.1.1/openssl-1.1.1o.tar.gz --output openssl.tar.gz
tar xzf openssl.tar.gz
rm openssl.tar.gz
cd openssl-1.1.1o/

# --prefix 경로에 openssl 을 설치합니다. 
./config --prefix=/opt/openssl && make && make install

설치 경로를 포함한 OpenSSL 버전 확인

openssl version -d

특정 OpenSSL 을 연동하여 python 설치

# Install Python 3.8.18
cd /opt
wget https://www.python.org/ftp/python/3.8.18/Python-3.8.18.tgz
tar xzf Python-3.8.18.tgz
cd Python-3.8.18

# 아까 설치했던 openssl 경로를 입력합니다. 
./configure --with-openssl=/opt/openssl

# build and install
make
make altinstall

확인

python3.8
> import ssl
> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1o 14 Dec 2021'

참조

https://stackoverflow.com/questions/69371800/how-to-link-python3-to-use-openssl11-or-latest-version-of-openssl-1-1-1-on-c

How to link python3 to use openssl11 / or latest version of openssl (1.1.1) on centos 7

We wanted to upgrade OpenSSL in centos 7 but it didn't happen, the reason may be this. Upgrading CentOS 7 to OpenSSL 1.1.1 by yum install openssl11 I've came to know openssl11 is for "spot"

stackoverflow.com

다형성을 사용하도록 조건문 다시 작성하기

제이왑 — Sun, 26 Mar 2023 22:10:11 +0900

객체 지향 프로그래밍을 하다 보면, 필연적으로 상속 구조를 활용하게 되는데요. 이 때, 서비스 로직에서 실제 인스턴스 타입별로 어떤 코드 실행을 다르게 해주어야 하는 경우가 발생합니다.

고민하지 않고 단순히 인스턴스 별 조건분기문으로 코드를 작성하게 되면, 새로운 요구사항이 추가될 때마다 코드의 변경이 많아질 수 있습니다. 또 그런 변경들이 프로그램의 로직을 복잡하게 만들어낼 수 있는데요. 오늘은 이런 상황에서 조건문을 사용하지 않고, 다형성을 활용할 수 있는 방안에 대해서 살펴보겠습니다.

상황

새를 나타내는 Bird 클래스가 있습니다. 이 Bird 객체를 API 응답으로 내려주기 위해서는 BirdResult 객체로 변형되어야 합니다.BirdResult 는 내부 객체와 API 응답 필드들을 분리하기 위하여 사용하고 있는 DTO 입니다.

이 BirdResult 를 생성하기 위해 Builder 를 사용하고 있습니다.

Bird 로부터 BirdResult 의 각 응답 필드를 세팅하는 메서드는 아래와 같습니다.

// BirdResult.java

/**
 * Bird 값을 주입한다. (As-is)
 * @param bird 
 * @return Builder
 */
public Builder bird(Bird bird) {
	this.id = bird.getId();
	this.name = bird.getName();
	this.type = bird.getType();
	// ...

	return this;
}

새로운 요구사항

Bird 는 이제 새로운 하위타입들로 나누어져야 합니다. (Canary , Duck , MockingBird )

각 하위 타입에 따라서 BirdResult 에 채워주어야 할 필드가 달라집니다.

새로운 요구사항에 맞춰서, Builder.bird(bird) 메서드의 구현은 어떻게 달라져야 할까요?

타입을 통해 분기한다.

type 필드값이나, instanceof 를 통해 실제 객체 타입을 확인하여 분기할 수 있습니다.

// BirdResult.java

/**
 * Bird 값을 주입한다. (Conditional)
 * @param bird 
 * @return Builder
 */
public Builder bird(Bird bird) {
	this.id = bird.getId();
	this.name = bird.getName();
	this.type = bird.getType();

	switch (bird.getType()) {
		case BirdType.Canary:
			this.feather = (Canary)bird.getColor();
		case BirdType.Duck:
			this.beakSize = (Duck)bird.getBeakSize();
		case BirdType.MockingBird:
			this.message = (MockingBird)bird.getMessage();
			break;
		default:
			// ...
	}

	return this;
}

하지만 위와 같이 구현했을 때, 몇 가지 문제점을 생각해볼 수 있습니다.

타입이 새로 만들어질 때마다, 그에 맞는 케이스를 새로 추가해주어야 합니다.

위와 같은 코드가 한 곳에서만 사용되었다면, 당장은 문제가 되지 않을 수 있습니다. 하지만 코드는 계속 변경되고 추가되는 것이 문제죠. Bird 객체를 사용하는 모든 메서드를 찾아가면서 조건 분기로 되어 있는 모든 곳을 찾아서 알맞게 수정해주어야 하는 문제점이 있습니다.

새로운 코드가 추가되거나 변경이 될 때, 해당 코드를 사용하는 다른 모듈에서 모두 변경이 이루어져야 한다면, 이는 개방-폐쇄 원칙 (Open-closed principle)을 위반한 코드가 됩니다. 따라서 변경이 되더라도, 사용하는 다른 모듈에서 변경하지 않아도 되도록 수정되어야 합니다.

다형성을 사용한 이유가 줄어들었습니다.

위 코드에서는 단지 다형성을 사용한 목적이 하나의 “타입” 값으로만 사용되고 있습니다. 그리고 그 타입을 통해 분기하여 다시 타입캐스팅을 하여 필요한 메서드를 일일이 호출하고 있습니다.

다형성의 성격 중 하나는 객체가 스스로 실행할 메서드를 실행 시점에서 결정할 수 있다는 것입니다. (이것을 동적 바인딩이라고 합니다.) 상위 클래스의 메서드를 재정의(overriding) 하면, 해당 메서드의 실행 시점에서 하위 클래스에서 재정의한 메서드를 실행하도록 결정됩니다. 그렇기 때문에 객체를 사용하는 모듈에서는 수정이 되더라도 변경을 할 필요가 없어지도록 구현할 수 있을 것입니다.

다중정의(overloading) 를 사용한다.

.bird(bird) 를 다중정의(overloading)하여 사용할 수 있습니다.

// BirdResult.java

/**
 * Bird 값을 주입한다. (Overloading)
 * @param bird 
 * @return Builder
 */
public Builder bird(Bird serverGroup) {
	this.id = bird.getId();
	this.name = bird.getName();
	this.type = bird.getType();
	return this;
}

public Builder bird(Canary bird) {
	this.bird((Bird)bird)
	this.feather = (Canary)bird.getColor();
	return this;
}

public Builder bird(MockingBird bird) {
	this.bird((Bird)bird)
	this.message = (MockingBird)bird.getMessage();
	return this;
}

이렇게 구현했을 땐, 이제 받는 객체 타입에 따라서 다른 필드들이 세팅될 수 있습니다. 그리고 함께 세팅되어야 하는 공통 필드들에 대해서도 잘 설정될 수 있습니다. 하지만 아쉽게도, 위와 같은 구현 방식은 개방-폐쇄 원칙에 대해서 해결하지 못하고 있습니다.

새로운 타입이 만들어질 때마다, 새로운 메서드를 정의해주어야 한다.

위 bird 메서드를 호출하는 쪽에서, 어떤 타입인지 먼저 알고 있어야 하고, 타입에 따라 항상 타입 캐스팅을 해주어야 합니다. 그렇지 않으면 잘못된 메서드가 호출될 수 있습니다. 다시 말하면, 위 코드는 Bird 타입에 대한 분기를 Builder 를 호출하는 쪽으로 옮겨놓는 수준으로 생각할 수 있습니다.

아래 코드 예시를 통해 알아보겠습니다.

// SomethingService.java

// 상위 타입인 Bird 로 받았습니다. 실제 객체가 어떤 타입인지는 알 수 없습니다. 
Bird bird = birdService.getBird(birdId); 

Builder builder = new Bird.Builder();

// 아래 메서드에서는 bird(Bird bird) 가 호출됩니다. 상위 타입으로 전달했기 때문입니다. 
builder.bird(bird);

// SomethingService.java

// 각 타입에 맞게 호출되기 위해서는 빌더 호출 시에 아래와 같은 분기가 필요합니다. 
if (bird instanceof Canary) {
	builder.bird((Canary)bird));
} else if (bird instanceof MockingBird) {
  builder.bird((MockingBird)bird)); 
} else {
	builder.bird(bird);
}

그렇다면, 다형성을 이용하여 위 코드를 구현하려면 어떻게 할 수 있을까요?

Builder 에서 상위 타입의 메서드를 호출하도록 정의하고, 각 하위 타입에서 메서드를 재정의(Overriding) 한다.

타입에 따라 메서드의 구현이 달라져야 하는 경우에, 여러 하위 타입에서 메서드에 대해 재정의를 하면 일일이 조건문을 작성하지 않아도 다형적으로 호출되게 할 수 있습니다. 아래 처럼 상위 타입의 메서드를 호출하면, 각 하위 타입의 재정의된 메서드를 따라가도록 구현할 수 있습니다.

아래처럼 Builder 의 구현에서는 상위 타입의 putResult(Builder) 메서드를 호출합니다. putResult 에서는 전달한 builder 의 필드에 필요한 항목들을 주입해주는 역할을 해줍니다.

// BirdResult.java

/**
 * Bird 값을 주입한다. (Polymorphism)
 * @param bird 
 * @return Builder
 */
public Builder bird(Bird bird) {
	bird.putResults(this); // bird 에서 builder (this) 에 직접 주입한다.
	return this;
}

이 때 Builder 에서 구현되어 있던 필드 설정 부분들을 옮기기 위해 다음과 같이 변경합니다.

상위 타입에서 호출될 메서드를 작성하여, 하위 타입에서 재정의할 수 있도록 합니다.

각 하위 타입 별로 분기문에서 수행되었던 코드를 각 타입의 재정의한 메서드 안으로 옮깁니다.

즉, 각각의 Canary, MockingBird 타입에서는 추상 클래스 Bird.putResult(Builder) 에 대한 구현이 이루어져야 합니다.

// Bird.java
public abstract class Bird {
  // ...

	/**
	 * 서버 그룹 필드값들을 BirdResult.Builder 에 할당한다.
	 * @param builder 응답 객체 빌더
	 */
	public void putResult(BirdResult.Builder builder) {
		// 상위 타입에서 호출될 메서드를 작성하여, 하위 타입에서 재정의할 수 있도록 한다.
		builder.id(this.id);
		builder.name(this.name);
		builder.type(this.type);
	}
}

// Canary.java
public class Canary extends Bird {
  // ...

	/**
	 * 서버 그룹 필드값들을 BirdResult.Builder 에 할당한다.
	 * - Bird.putResult 를 오버라이딩하여 동적바인딩 되도록 합니다. 
	 *
	 * @param builder 응답 객체 빌더
	 */
	@Override
	public void putResult(BirdResult.Builder builder) {
		// 공통 필드 세팅
		super.putResult(builder);

		// Canary 필드 세팅
		builder.feather(this.feather);
	}
}

// MockingBird.java
public class MockingBird extends Bird {
  // ...

	/**
	 * 서버 그룹 필드값들을 BirdResult.Builder 에 할당한다.
	 * - Bird.putResult 를 오버라이딩하여 동적바인딩 되도록 합니다. 
	 *
	 * @param builder 응답 객체 빌더
	 */
	@Override
	public void putResult(BirdResult.Builder builder) {
		// 공통 필드 세팅
		super.putResult(builder);

		// MockingBird 필드 세팅
		builder.message(this.message);
	}
}

이렇게 구현을 하면, 다음과 같은 장점이 있습니다.

타입에 따라 기능이 달라지는 여러 객체가 있을 때에도 일일이 조건문을 작성하지 않고, 다형적으로 호출되게 할 수 있습니다.

새로운 타입이 추가되더라도, putResult(Builder) 만 알맞게 구현해준다면, Builder.bird(Bird) 를 변경하지 않고, 그대로 사용할 수 있습니다. 따라서 개방-폐쇄 원칙도 지킬 수 있게 되었습니다.

이 방법에 대해서 좀 더 자세하게 확인해보시고 싶으신 분들은 리팩터링(마틴 파울러)에서 조건문을 재정의로 전환 (Replace Conditional with Polymorphism) 을 살펴보시면 좋을 것 같습니다. 유명한 리팩터링 항목이기 때문에, 단순 구글링을 하셔도 다양한 글들을 확인하실 수 있습니다.

빌더 패턴을 사용한 객체의 생성

제이왑 — Sat, 18 Mar 2023 16:50:52 +0900

빌더 패턴은 객체를 생성할 때 쓰이는 유용한 패턴입니다. 하지만 빌더에 대한 추가적인 구현이 필요해서 인지, 생각보다 많은 사람들이 빌더가 필요한 상황에서도 복잡한 생성자를 사용해서 객체를 생성합니다. 그리고 그에 대한 댓가로, 개발자의 파라미터 입력 실수에 의한 오류를 접합니다.

이 글에서는 Java 환경에서 생성자와 점층적 생성자, 그리고 빌더에 대해서 알아봅니다. 그리고 계층적 클래스 구조에서 빌더를 사용하는 방법에 대해서 설명하고자 합니다.

객체의 생성

빌더에 대해서 이야기 하기 전에, 먼저 객체를 생성하는 여러가지 방법에 대해서 알아보겠습니다.

생성자

가장 많이 사용하는 방법은 생성자를 통해 객체를 생성하는 것입니다. 생성자는 정의되어 있는 class 를 기반으로 객체를 생성하는 기본적인 방법이다. new Class(…) 형태로 직관적이고, class 내에 정의만 하면 되기 때문에 군더더기 없습니다.

하지만 객체가 가지고 있는 속성이 많을 경우에는 이야기가 좀 달라집니다. java 의 생성자는 입력 받는 파라미터를 순서와 파라미터의 클래스(Class) 또는 원시 타입(primitive type)으로 구분합니다. 이 때 사용자는 다음과 같이 객체를 생성해야 합니다.

new Something(id, weight, height, message, pages, rate);

이렇게 되었을 때, weight 와 height 의 순서가 변경된다면 어떤 일이 발생할까요? 아마 Something 객체는 개발자가 의도한 것과는 정반대로 생성되어 프로그램의 동작에 문제가 발생할 것입니다. 실제로 개발하면서 이런 문제를 많이 겪습니다. 이런 문제는 변수명과 순서를 매핑할 수 없는 언어적인 한계에서 발생합니다. (python 에서는 명명된 선택적 매개변수를 지원하기 때문에 이런 문제가 없습니다.)

점층적 생성자

일반적인 생성자를 사용할 때 파라미터가 길어지는 문제점을 방지하기 위해서 점층적 생성자를 사용할 수 있습니다. 생성자에서 필요한 파라미터만 받아서, 기본값을 할당할 수 있는 방법입니다.

하지만 이럴 경우에도 모든 파라미터를 사용하여 초기화해야하는 경우에는 위 문제가 해결되지 않습니다. 또 생성자가 많아질 수록 코드를 수정하기 어려워집니다.

class Something {
	// ...
	public Something(int id, int weight, int height) {
			this(id, weight, height, "", 1, 0.0D);
		}
	}

	public Something(int id, int weight, int height, String message, int pages, double rate) {
		this.id = id;
		this.weight = weight;
		this.height = height;
		this.message = message;
		this.pages = pages;
		this.rate = rate;
	}
}

// 필요한 항목만 사용하여 생성할 수 있도록 점층적 생성자를 선언해줄 수 있다. 
new Something(id, weight, height);

// 하지만 결국에 많이 필요한 경우에는 같은 문제가 유지된다. 
new Something(id, weight, height, message, pages, rate);

빌더

빌더 패턴은 생성자와 마찬가지로 어떤 객체를 생성해주는 역할을 합니다. 아래 빌더 코드를 살펴보겠습니다.

public class Coffee {
	private int shot;
	private String type;

	protected Coffee(Builder builder) { // -- (A)
		this.shot = builder.shot;
		this.type = builder.type;
	}

	public static class Builder { // -- (B)
		private int shot;

		public Builder() {
		}

		public Builder shot(int shot) { // -- (C)
			this.shot = shot;
			return this;
		}

		public Builder type(String type) {
			this.type = type;
			return this;
		}

		public Coffee build() { // -- (D)
			return new Coffee(this);
		}
	}
}

(A) 에서 빌더를 통해 각 필드가 설정되고 객체가 생성될 수 있도록 생성자를 구현합니다.

(B) 는 Builder 클래스의 선언부입니다.
- 외부에서 Builder 를 생성할 수 있어야 하기 때문에 public 이어야 합니다.
- 객체마다 생성될 필요가 없기 때문에 static 하게 정의하였습니다.

(D) 는 최종적으로 객체를 생성하여 반환할 수 있도록 하는 build() 메서드입니다.

위 처럼 빌더 클래스를 정의해주었다면, 아래와 같이 빌더를 통해 객체를 생성할 수 있습니다. 생성자를 통한 생성과 비교해보겠습니다.

Coffee coffee = new Coffee.Builder().shot(3).type("HOT").build();

생성자처럼 한번에 객체를 만들어내는 것이 아니라, 필요한 속성들을 하나씩 모아서 개발자가 필요한 시점에 build() 를 호출하여 객체를 만들어줄 수 있습니다. 이렇게 빌더를 만들어 사용을 하면 다음과 같은 장점이 있습니다.

장점

Java 에서는 지원되지 않는 명명된 선택적 매개변수(named optional parameter) 를 흉내낼 수 있다.

객체를 일관성있게 유지할 수 있도록 돕는다. (consistent)

매개변수의 입력 시점을 다르게 정하면서도, 객체의 불변성을 유지할 수 있다.

계층적인 클래스에 대해서 사용하기 편리하다.

Java 에서는 지원되지 않는 명명된 선택적 매개변수를 흉내낼 수 있다.

Java 는 생성자나 메서드에 파라미터를 전달할 때, 이름을 지정할 수 없습니다. 순서에 의해서만 해당하는 파라미터가 무엇인지 결정됩니다. 이 때문에 앞서 생성자에서 발생했던 문제가 드러납니다.

하지만 빌더를 사용하면 이런 문제를 어느 정도 우회할 수 있습니다. 파라미터를 설정할 때 명확한 설정자를 통하기 때문에, 어떤 파라미터에 무엇을 넣는 지 개발자가 인지할 수 있습니다.

# python 이라면 다음과 같은 방법을 통해 혼란을 줄일 수 있다.
coffee = Coffee(shot=3, type="HOT")

// 자바는 명명된 선택적 매개변수를 지원하지 않지만,
// 빌더 패턴을 활용하여 명명된 선택적 매개변수의 장점을 취할 수 있다. 
Coffee coffee = new Coffee.Builder().shot(3).type("HOT").build();

객체를 일관성있게 유지할 수 있도록 돕는다.

어떤 객체가 있는데, 그 객체를 사용할 때 무결한 상태임을 유지하는 것은 중요합니다.

객체를 사용할 때마다 각 필드에 대해서 검증을 해주어야한다면, 이는 유지 보수 비용을 크게 만들 뿐만 아니라 개발할 때에도 성가시고, 어떤 위험이 있을 지 모르기 때문에 개발하기를 두렵게 만듭니다. 하지만 생성되는 순간에 무결성이 검증되고, 객체에 대한 수정이 되지 않음이 보장된다면 마음이 한결 편안해집니다.

빌더는 각각의 필드에 대해서 검증 로직을 만들어둘 수 있고, 빌드 될 때 한번 더 검증해줄 수 있기 때문에 객체의 일관성을 유지할 수 있도록 돕습니다. 더 나아가서 클래스에서 생성자의 접근자를 private 하게 만들고, 클래스의 설정자(setter)를 제거하면 객체를 불변하게(immutable) 만들 수 있습니다.

// a 는 필드를 설정하는 코드의 사이에서 사용될 수 있기 때문에, 무결한지 확인해주어야 한다.
Coffee a = new Coffee()
a.setShot(...)
// ... setType(..) 가 호출되지 않았을 때, 
// ... 이 사이에 a 가 사용된다면 이는 정상적인 객체인걸까 아닌걸까?
a.setType(...)

// b 는 생성되었을 때, 필요한 필드를 모두 가지고 있을 것이기 때문에,
// 생성된 객체는 무결함이 보장될 수 있다. (무결성에 대한 검증 코드는 build() 나 각 필드 설정자에 포함되어야 한다. )
Coffee b = new Coffee.Builder()
	.shot(...)
	.type(...)
  .build();

매개변수의 입력 시점을 다르게 정할 수 있다.

필드 마다 필요한 매개변수가 준비되는 시점이 다를 수 있습니다. 이 때 생성자라면, 매개변수가 준비된 시점과 이를 설정하는 코드가 떨어져 가독성을 떨어뜨릴 수 있습니다. 아래 코드를 살펴보겠습니다.

// blahblah 
// blahblah 
// (1) blahblah for value `Type`
String type = createType(...);

// blahblah 
// blahblah 
// (2) blahblah for value `shot`
int shot = createShot(...);

// blahblah 
// blahblah 
// blahblah 

// (3) Coffee 의 각 매개변수가 만들어진 시점과 사용하는 시점이 떨어져 있으면
//     가독성이 떨어지고, 유지보수하기 어려워 진다. 
Coffee a = new Coffee(shot, type);

(1) 과 (2) 에서 준비된 message 와 count 가 (3) 에 와서야 사용됩니다. 명명된 변수가 실제 사용되는 부분과 떨어져있게 되면 코드의 가독성이 떨어지고, 실제 사용되는 시점을 추적해야되기 때문에 유지보수가 어려워집니다.

하지만 빌더를 사용하면, 준비가 된 시점에서 빌더의 필드에 저장해둘 수 있어 가독성을 높일 수 있습니다. 아래 코드를 살펴보겠습니다.

Coffee.Builder builder = new Coffee.Builder();

// blahblah 
// blahblah 
// (1) blahblah for value `message`
builder.type(createType(...)); // 매개변수가 만들어진 시점에서 바로 활용된다.

// blahblah 
// blahblah 
// (2) blahblah for value `count`
builder.shot(createShot(...));

// blahblah 
// blahblah 
// blahblah 

// (3) 생성하는 시점에 만들어둔 매개변수는 이미 builder 에 설정되어 있기 때문에 가독성이 좋다.
Coffee b = builder.build();

(1) 과 (2) 를 보면, 변수는 따로 명명할 필요없이 builder 의 설정자에 바로 전달되어 사용됩니다. 그리고 (3) 에서 생성하는 시점에 만들어졌던 값들은 모두 builder 에 포함되어있기 때문에, build 호출만 하면 바로 생성될 수 있습니다.

생성자를 사용했을 때보다 가독성과 유지보수면에서 훨씬 간단해집니다. 실제 개발하는 경우에는 생각보다 사이에 들어있는 코드의 길이가 길어지는 경우가 발생하기 때문에, 빌더를 사용하여 가독성을 높일 수 있습니다.

계층적인 클래스에 대해서 사용하기 편리하다.

빌더는 뿐만 아니라, 계층적인 구조를 가진 클래스에서도 쉽게 사용할 수 있습니다. 부모 클래스의 빌더를 상속하는 구조로, 자식 클래스에서는 자식 클래스에 추가된 필드에 대해서만 설정하는 빌더를 만들 수 있습니다.

아래 부모 클래스의 빌더 코드를 따라가보겠습니다.

public class Coffee {
	private Type type;

	protected Coffee(Builder<? extends Builder<?>> builder) { // -- (1)
		this.type = builder.type;
		this.shot = builder.shot;
	}

	// ...

	public static abstract class Builder<T extends Builder<T>> { // -- (2)
		private Type type;

		public Builder() {
		}

		public T type(Type type) { // -- (3)
			this.type = type;
			return self();
		}

		// ...

		protected abstract T self(); // -- (4)

		public abstract Coffee build(); // -- (5)
	}
}

(1) 은 Builder 를 통해 Coffee 를 생성할 수 있도록 만들어주는 생성자입니다.
- 우리는 이 생성자를 코드 외부에서 호출하고 싶지 않지만, 상속 관계에서는 호출하여 부모 클래스의 생성자를 재사용해야 하므로 protected 여야 합니다.
- 자식 클래스 빌더도 전달될 수 있도록 하기 위해 Builder 정의와 같게 정의하였습니다. 이는 (2) 에서 더 자세하게 살펴보겠습니다.
- 생성자 내부에서는 builder 에 설정된 각 필드를 통해 객체 필드를 설정하고 생성합니다.

(2) 는 빌더의 내부 클래스 선언부 입니다.
- 하위 클래스에서 명확하게 정의해주어야 하는 추상 메서드가 존재하기 때문에 abstract class 로 정의하였습니다.
- 받을 타입 파라미터를 T extends Builder<T> 로 정의하였습니다.
  - Builder<T> 를 상속하는 T 를 타입 파라미터로 받습니다.
  - 이렇게 정의하면 T 에 Builder<T> 속성을 부여하여, 자식 클래스 빌더에서 부모 클래스 빌더에 정의된 값들을 사용할 수 있도록 합니다.
  - Java 의 제너릭에 대해 익숙하지 않다면, 다음 글을 참고해주세요.

(3) 은 빌더에서 필드의 설정자입니다.
- self() 호출하여 자식 클래스에서 명확하게 정의될 타입 파라미터 T 를 반환합니다. self() 에 대한 자세한 설명은 (4) 에서 살펴보겠습니다.
- 결국 self() 를 통해 빌더 자신을 반환하고, 반환된 빌더를 통해 메서드 체이닝으로 나머지 필드를 추가로 설정할 수 있게 됩니다.

(4) 는 this 로 부모 클래스 타입을 반환하지 않고, 자식 클래스를 반환할 수 있도록 하기 위한 추상 메서드입니다.
- this 가 아닌 self() 를 사용하는 이유는, this 를 사용하면 부모 클래스 타입으로 반환되기 때문에, 자식 클래스에서 항상 형변환을 하여 사용해야 합니다.
- 자바에서는 self 타입이 없기 때문에 이런 우회 방법을 사용하는 것인데, 이런 패턴을 simulate self-type idiom 이라고 합니다.

(5) 는 최종적으로 Coffee 객체를 생성하는 빌드 메서드입니다. 자식 클래스에서 이를 구현하여 적절한 객체를 생성하여 반환합니다.

부모 클래스에서 빌더를 정의하였다면, 이제 실제로 원하는 객체를 만들기 위해서 자식 클래스 빌더에서 부모 클래스 빌더를 상속해주어야 합니. 아래 자식 클래스의 빌더 코드를 따라가보겠습니다.

public class AmericanoCoffee extends Coffee {
	private int water;

	protected AmericanoCoffee(Builder builder) { // -- (6)
		super(builder);
		this.water = builder.water;
	}

	public static class Builder extends Coffee.Builder<Builder> { // -- (7)
		private int water;

		public Builder() {
			super();
		}

		@Override
		protected Builder self() { // -- (8)
			return this;
		}

		@Override
		public Coffee build() { // -- (9)
			return new AmericanoCoffee(this);
		}

		public Builder water(int water) { // -- (10)
			this.water = water;
			return self();
		}
	}
}

(6) 은 자식 클래스의 생성자입니다.
- (1) 에서 선언한 부모 생성자를 재사용하여, 자식 클래스에서 추가된 필드만 설정합니다.
- 자식 클래스 빌더를 파라미터로 받습니다. (1) 에서 Builder<? extends Builder<?>> 를 타입으로 정했기 때문에, 자식 클래스 빌더 타입 그대로 전달하더라도 컴파일 에러가 발생하지 않습니다.

(7) 에서 Coffee.Builder<Builder> 를 상속합니다.
- Coffee.Builder 에 자식 클래스 빌더인 Builder 를 타입 파라미터 T 로 전달해주었기 때문에, 나머지 T로 반환해주었던 메서드들을 Builder 로 반환해주어야 합니다.

(8) 에서 (4) 를 구체 메서드로 구현합니다.
- 여기에서 자기 자신 this 를 반환해줌으로써, 타입 형변환 없이 코드를 사용할 수 있습니다.
- self() 가 아니었다면, 부모 클래스의 설정자를 사용할 때마다 타입 형변환이 필요했을 것 입니다.

(9) 는 실제 자식 클래스의 객체인 AmericanoCoffee 를 생성하여 반환합니다.

(10) 은 자식 클래스에서 추가된 필드를 설정하는 메서드 입니다.

이렇게 계층화된 상속 구조에서도 빌더 패턴을 잘 활용할 수 있습니다.

단점

하지만 빌더 패턴에도 단점이 없는 것은 아닙니다. 아래와 같은 점을 생각할 수 있습니다.

객체를 생성하기 위해 빌더가 먼저 만들어져야합니다.
- 빌더가 만들어지기 위한 생성 비용이 큰 것은 아니지만, 성능이 중요한 어플리케이션이라면 충분히 단점으로 작용할 수 있습니다.

빌더를 구현하기 위한 노력이 필요합니다.
- 위에서 살펴보았듯이, 생성자를 구현하는 것보다 빌더에 대한 별도 class 정의가 필요합니다. 명확하게 필드가 증가하는 방향으로 변경되지 않는다던지, 생성 시 파라미터의 양이 적은 경우에는 빌더를 선언하는 개발 비용이 더 클 수 있기 때문에 이를 고려해보아야합니다.

정리

빌더 패턴은 생성자를 사용할 때 발생할 수 있는 여러가지 문제점을 방지할 수 있도록 도와줍니다.

Java 에서 지원되지 않는 명명된 선택적 파라미터의 장점을 가질 수 있습니다.

객체를 일관성있게 유지할 수 있도록 돕습니다.

매개변수의 입력 시점을 다르게 정하면서도, 객체의 불변성을 유지할 수 있도록 도와줍니다.

계층적인 클래스에 대해서 사용하기 편리합니다.

자바의 생성자를 통해서 생성하면 위에서 설명한 문제들이 있었다면, 빌더 패턴을 사용하여 그런 단점들을 개선해나가보는 것도 좋을 것 같습니다. 계층적 클래스에서의 빌더 패턴 구현 예제는 업로드해두었으므로 참고해주세요.

참고

계층적 클래스 빌더 패턴 예제 코드

이펙티브 자바3/E, p14, p105

Is there a way to refer to the current type with a type variable?

A	B	산술평균	조화평균
10	0	5	0
9	1	5	1.8
8	2	5	3.2
7	3	5	4.2
6	4	5	4.8
5	5	5	5
4	6	5	4.8
3	7	5	4.2
2	8	5	3.2
1	9	5	1.8
0	10	5	0

A	B	산술평균	조화평균
10	0	5	0
9	1	5	1.8
8	2	5	3.2
7	3	5	4.2
6	4	5	4.8
5	5	5	5
4	6	5	4.8
3	7	5	4.2
2	8	5	3.2
1	9	5	1.8
0	10	5	0

Developer.

podman build 시 too many open files 대응

직접 빌드를 수행하는 경우

간접적으로 빌드를 수행하는 경우 (ex. docker(podman) compose 를 통한 build)

정보 검색 평가 지표 ( + RAGAS)

지표의 목적

Binary relevance

Order-unaware metrics

Precision@k

Recall@k

참고: Precision 과 Recall 의 집합관계

F1@k

참고. 조화평균

Order-aware metrics

Mean Reciprocal Rank(MRR, Rank 역수 평균)

Average Precision(AP, Precision 평균)

Mean Average Precision

RAGAS 에서 측정하고 있는 지표

Context Utilization (Context Precision)

Answer Relevancy

Context Relevancy

참고 링크

서버에서 Client IP 를 추출하는 여러가지 방법

Remote IP

X-Forwarded-For 헤더 가장 왼쪽의 값 (DON'T)

X-Forwarded-For 헤더 내 proxy hop 수 이전의 값

X-Forwarded-For 헤더 내 가장 우측의 Public IP

Proxy 에서 특정 헤더에 할당한 값

결론

참고

NGINX module 개발 시 참고 하기 좋은 글

NGINX 모듈은 언제 만드나요?

Nginx 공식 문서

> https://nginx.org/en/docs/dev/development_guide.html

NAVER D2 - NGINX 모듈 제작하기

> https://d2.naver.com/helloworld/192785

Evan Miller 의 Nginx Modules Guide

> https://www.evanmiller.org/nginx-modules-guide.html

Nginx 의 내부 모듈 코드

> https://github.com/nginx/nginx/tree/master/src/http/modules

기타 다른 Nginx 모듈 레포지터리

headersmore (openresty)

user-agent (alibaba)

Docker Image 를 로컬 파일로 저장하기

외부 image 를 로컬 파일로 저장

로컬 파일 image 를 로드

여러 줄로 구성된 파일을 line-by-line loop 로 실행하기

특정 문자열을 파일에서 일괄 변경하기

fruit.txt 파일 내에 있는 모든 apple 을 banana 로 변경

Python 에 특정 OpenSSL 버전 연동하여 설치

문제

해결방안

OpenSSL 설치

설치 경로를 포함한 OpenSSL 버전 확인

특정 OpenSSL 을 연동하여 python 설치

확인

참조

다형성을 사용하도록 조건문 다시 작성하기

상황

새로운 요구사항

타입을 통해 분기한다.

타입이 새로 만들어질 때마다, 그에 맞는 케이스를 새로 추가해주어야 합니다.

다형성을 사용한 이유가 줄어들었습니다.

다중정의(overloading) 를 사용한다.

새로운 타입이 만들어질 때마다, 새로운 메서드를 정의해주어야 한다.

Builder 에서 상위 타입의 메서드를 호출하도록 정의하고, 각 하위 타입에서 메서드를 재정의(Overriding) 한다.

빌더 패턴을 사용한 객체의 생성

객체의 생성

생성자

점층적 생성자

빌더

장점

Java 에서는 지원되지 않는 명명된 선택적 매개변수를 흉내낼 수 있다.

객체를 일관성있게 유지할 수 있도록 돕는다.

매개변수의 입력 시점을 다르게 정할 수 있다.

계층적인 클래스에 대해서 사용하기 편리하다.

단점

정리

참고

`X-Forwarded-For` 헤더 가장 왼쪽의 값 (DON'T)

`X-Forwarded-For` 헤더 내 `proxy hop` 수 이전의 값

`X-Forwarded-For` 헤더 내 가장 우측의 Public IP

`fruit.txt` 파일 내에 있는 모든 `apple` 을 `banana` 로 변경

A	B	산술평균	조화평균
10	0	5	0
9	1	5	1.8
8	2	5	3.2
7	3	5	4.2
6	4	5	4.8
5	5	5	5
4	6	5	4.8
3	7	5	4.2
2	8	5	3.2
1	9	5	1.8
0	10	5	0