hahm's period of growth

PostgreSQL의 AT TIME ZONE 완벽히 이해하기

dev-hahm — Fri, 17 Oct 2025 16:48:37 +0900

PostgreSQL에서 타임존을 다루다 보면 예상과 다른 결과가 나와 당황한 경험이 있으실 겁니다. 특히 AT TIME ZONE 구문은 입력 타입에 따라 완전히 다르게 동작하는데, 이를 제대로 이해하지 못하면 심각한 버그로 이어질 수 있습니다.

이 글에서는 실제 쿼리 결과를 통해 PostgreSQL 타임존 처리의 모든 것을 파헤쳐보겠습니다.

기본 환경 설정

먼저 테스트 환경을 확인해봅시다.

SHOW timezone;
-- 결과: UTC

SELECT current_date, now();
-- 2025-10-17 | 2025-10-17 14:34:00+00

세션 타임존은 UTC로 설정되어 있고, 현재 시각은 2025-10-17 14:34 UTC입니다.

AT TIME ZONE의 두 얼굴

AT TIME ZONE은 입력 타입에 따라 정반대로 동작합니다.

규칙 1: timestamp (타임존 없음) → timestamptz

SELECT ('2025-10-17 08:59:59'::timestamp) AT TIME ZONE 'Asia/Seoul';
-- 결과: 2025-10-16 23:59:59+00:00

동작 방식:

2025-10-17 08:59:59를 한국 시간에 있는 시각으로 해석
이를 UTC로 변환 (한국은 UTC+9이므로 -9시간)
2025-10-16 23:59:59 UTC를 timestamptz로 반환

규칙 2: timestamptz → timestamp (타임존 없음)

SELECT ('2025-10-17 08:59:59'::timestamptz) AT TIME ZONE 'Asia/Seoul';
-- 결과: 2025-10-17 17:59:59

동작 방식:

2025-10-17 08:59:59 UTC (세션 타임존이 UTC이므로)
이를 한국 시간으로 표시 (UTC+9이므로 +9시간)
2025-10-17 17:59:59를 timestamp(타임존 제거)로 반환

헷갈리는 문자열 처리

문자열에 직접 AT TIME ZONE을 사용하면 어떻게 될까요?

SELECT 
    ('2025-10-17 08:59:59') AT TIME ZONE 'Asia/Seoul' AS case1,
    '2025-10-17 08:59:59'::timestamptz AS case2,
    ('2025-10-17 08:59:59'::timestamptz) AT TIME ZONE 'Asia/Seoul' AS case3;

결과:

       case1            |        case2            |       case3
------------------------+-------------------------+------------------------
2025-10-17 17:59:59     | 2025-10-17 08:59:59+00  | 2025-10-17 17:59:59

분석:

case1: 문자열이 먼저 세션 타임존(UTC)으로 timestamptz 변환 → 한국 시간으로 표시
case2: 문자열을 세션 타임존(UTC)으로 timestamptz 변환
case3: timestamptz를 한국 시간으로 표시

case1과 case3은 결과가 같지만, 중간 과정이 다릅니다!

current_date의 함정

가장 헷갈리는 케이스입니다.

SELECT 
    current_date AS original,
    current_date AT TIME ZONE 'Asia/Seoul' AS seoul_time1,
    current_date::timestamp AT TIME ZONE 'Asia/Seoul' AS seoul_time2;

결과:

  original  |      seoul_time1       |      seoul_time2
------------+------------------------+---------------------------
2025-10-17  | 2025-10-17 09:00:00    | 2025-10-16 15:00:00+00:00

왜 이런 결과가 나올까?

seoul_time1: `current_date AT TIME ZONE 'Asia/Seoul'`

current_date = 2025-10-17 (date 타입)
암묵적으로 timestamp 변환: 2025-10-17 00:00:00
이게 세션 타임존(UTC)으로 해석됨: 2025-10-17 00:00:00 UTC
한국 시간으로 변환: 2025-10-17 09:00:00 KST
타임존 제거한 timestamp 반환

seoul_time2: `current_date::timestamp AT TIME ZONE 'Asia/Seoul'`

current_date = 2025-10-17 (date 타입)
명시적으로 timestamp 변환: 2025-10-17 00:00:00 (타임존 없음)
이를 한국 시간에 있는 시각으로 해석: 2025-10-17 00:00:00 KST
UTC로 변환: 2025-10-16 15:00:00 UTC
timestamptz 반환

실전 문제: "오늘" 데이터 조회하기

다음 쿼리는 어떤 결과를 반환할까요?

WITH data AS (
    SELECT *
    FROM (VALUES
        ('2025-10-17T07:00:00Z'::timestamptz),
        ('2025-10-17T08:00:00Z'::timestamptz),
        ('2025-10-17T09:00:00Z'::timestamptz),
        ('2025-10-17T10:00:00Z'::timestamptz),
        ('2025-10-17T11:00:00Z'::timestamptz)
    ) AS t(dt)
)
SELECT *
FROM data
WHERE dt >= (current_date AT TIME ZONE 'Asia/Seoul');

결과: 3개 행 반환 (09:00, 10:00, 11:00)

이유:

current_date AT TIME ZONE 'Asia/Seoul' = 2025-10-17 09:00:00 (timestamp)
비교 시 세션 타임존(UTC)으로 해석: 2025-10-17 09:00:00 UTC
따라서 09:00 UTC 이후의 데이터만 조회됨

이는 의도한 결과가 아닐 수 있습니다! 한국 시간 기준 "오늘"(00:00 KST)의 데이터를 조회하려면:

-- 올바른 방법 1
WHERE dt >= (current_date::timestamp AT TIME ZONE 'Asia/Seoul')

-- 올바른 방법 2
WHERE dt >= date_trunc('day', now() AT TIME ZONE 'Asia/Seoul') AT TIME ZONE 'Asia/Seoul'

다국적 서비스에서 "오늘" 집계하기

시간대가 다른 사용자들에게 각자의 "오늘" 데이터를 보여줘야 한다면?

방법 1: 사용자별 타임존으로 필터링

-- 서울 사용자
SELECT COUNT(*)
FROM events
WHERE created_at >= (current_date::timestamp AT TIME ZONE 'Asia/Seoul')
  AND created_at < (current_date::timestamp AT TIME ZONE 'Asia/Seoul') + INTERVAL '1 day';

-- 뉴욕 사용자
SELECT COUNT(*)
FROM events
WHERE created_at >= (current_date::timestamp AT TIME ZONE 'America/New_York')
  AND created_at < (current_date::timestamp AT TIME ZONE 'America/New_York') + INTERVAL '1 day';

방법 2: 더 명확한 date_trunc 사용

WITH user_timezone AS (
    SELECT 
        date_trunc('day', now() AT TIME ZONE 'Asia/Seoul') AS day_start_local
)
SELECT COUNT(*)
FROM events, user_timezone
WHERE created_at >= (day_start_local AT TIME ZONE 'Asia/Seoul')
  AND created_at < (day_start_local AT TIME ZONE 'Asia/Seoul') + INTERVAL '1 day';

방법 3: 클라이언트에서 타임존 전달 (권장)

-- API에서 user_timezone 파라미터 받기
SELECT 
    DATE(created_at AT TIME ZONE :user_timezone) AS local_date,
    COUNT(*) AS count
FROM events
WHERE created_at >= date_trunc('day', now() AT TIME ZONE :user_timezone) 
                    AT TIME ZONE :user_timezone
  AND created_at < date_trunc('day', now() AT TIME ZONE :user_timezone) 
                   AT TIME ZONE :user_timezone + INTERVAL '1 day'
GROUP BY local_date;

핵심 정리

AT TIME ZONE 동작 규칙

입력 타입	AT TIME ZONE 동작	출력 타입
timestamp	해당 타임존의 시각으로 해석 → UTC 변환	timestamptz
timestamptz	해당 타임존으로 표시 (타임존 제거)	timestamp
date/문자열	먼저 세션 타임존으로 변환 → 해당 타임존으로 표시	timestamp

실수하기 쉬운 패턴

-- ❌ 잘못된 방법 (UTC 09:00 기준)
WHERE dt >= current_date AT TIME ZONE 'Asia/Seoul'

-- ✅ 올바른 방법 (한국 00:00 기준)
WHERE dt >= current_date::timestamp AT TIME ZONE 'Asia/Seoul'

-- ✅ 더 명확한 방법
WHERE dt >= date_trunc('day', now() AT TIME ZONE 'Asia/Seoul') 
            AT TIME ZONE 'Asia/Seoul'

기억해야 할 것

문자열/date는 항상 세션 타임존으로 먼저 해석됩니다
::timestamp 명시적 캐스팅으로 타임존 없는 값을 만드세요
timestamp와 timestamptz의 변환 방향을 명확히 이해하세요
다국적 서비스에서는 사용자의 타임존을 명시적으로 관리하세요

마치며

PostgreSQL의 타임존 처리는 처음에는 복잡해 보이지만, 규칙을 이해하면 매우 논리적입니다. 특히 글로벌 서비스를 개발할 때는 이러한 동작을 정확히 이해하고 있어야 사용자에게 올바른 시간 정보를 제공할 수 있습니다.

데이터베이스에 데이터를 저장할 때는 항상 UTC로 저장하고, 사용자에게 보여줄 때만 해당 타임존으로 변환하는 것이 베스트 프랙티스입니다!

참고 자료:

gRPC 입문: 서버 간 통신을 간단하게 만드는 Google RPC

dev-hahm — Thu, 25 Sep 2025 11:18:17 +0900

gRPC 입문: 서버 간 통신을 간단하게 만드는 Google RPC

현대 웹 서비스와 마이크로서비스 환경에서 서버 간 통신은 필수적입니다.
그런데 REST API만으로는 대규모, 고성능, 실시간 통신 환경에서 부족함을 느낄 수 있습니다.
바로 이런 상황에서 등장한 것이 gRPC(Google Remote Procedure Call)입니다.

이번 글에서는 gRPC란 무엇인지, 구조와 특징, 간단한 예제까지 살펴보겠습니다.

1. gRPC란 무엇인가?

gRPC는 구글이 개발한 원격 프로시저 호출(Remote Procedure Call) 프레임워크입니다.

쉽게 말하면,

네트워크를 통해 다른 서버의 함수를 마치 내 컴퓨터에서 호출하는 것처럼 사용할 수 있게 해주는 기술

입니다.

예를 들어, 클라이언트 코드에서 이렇게 작성할 수 있습니다.

result = stub.Add(5, 7)

하지만 실제로는 localhost:50051 서버에 있는 Calculator.Add 함수를 호출하고, 결과가 돌아옵니다.
개발자는 이를 로컬 함수 호출처럼 간단하게 사용할 수 있습니다.

2. gRPC가 필요한 이유

REST API와 비교했을 때 gRPC의 장점은 다음과 같습니다.

고성능
- Protocol Buffers를 사용한 바이너리 직렬화
- HTTP/2 기반 멀티플렉싱 지원 → 요청/응답 빠르고 효율적
타입 안전
- .proto 파일로 메시지 구조와 서비스 정의 → 컴파일 시점 타입 체크 가능
자동 코드 생성
- 클라이언트/서버 스텁 자동 생성 → 개발자가 HTTP 요청, 파싱 등을 직접 구현할 필요 없음
스트리밍 지원
- 서버, 클라이언트, 양방향 스트리밍 모두 가능 → 실시간 데이터 처리에 적합

3. gRPC 기본 구성 요소

구성 요소	설명
`.proto` 파일	메시지와 서비스 정의 설계도
메시지(message)	요청/응답 데이터 구조 정의
서비스(service)	서버가 제공할 원격 호출 함수 모음
서버(Server)	실제 함수 구현 및 요청 처리
클라이언트(Client)	서버 메서드를 호출
스텁(Stub)	클라이언트에서 사용하는 “가짜 함수” → 네트워크 호출 처리

4. 협업 시 gRPC 사용 방법

서버 개발자가 .proto 파일 작성 → 서비스, 메서드, 요청/응답 구조 정의
클라이언트 팀은 .proto 파일로 Stub 생성 → 서버 코드 몰라도 함수 호출 가능
Stub을 이용해 로컬 함수처럼 서버 메서드 호출

즉, 협업 시 클라이언트와 서버 간 API 문서 대신 .proto 공유로 모든 통신이 가능합니다.

5. 간단한 예제: 계산기 서비스

`.proto` 파일

syntax = "proto3";

package calculator;

message AddRequest {
  int32 a = 1;
  int32 b = 2;
}

message AddResponse {
  int32 result = 1;
}

service Calculator {
  rpc Add (AddRequest) returns (AddResponse);
  rpc Multiply (AddRequest) returns (AddResponse);
}

서버 구현 (Python)

from concurrent import futures
import grpc
import calculator_pb2
import calculator_pb2_grpc

class CalculatorServicer(calculator_pb2_grpc.CalculatorServicer):
    def Add(self, request, context):
        return calculator_pb2.AddResponse(result=request.a + request.b)

    def Multiply(self, request, context):
        return calculator_pb2.MultiplyResponse(result=request.a * request.b)

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
calculator_pb2_grpc.add_CalculatorServicer_to_server(CalculatorServicer(), server)
server.add_insecure_port('[::]:50051')
server.start()
server.wait_for_termination()

클라이언트 호출

channel = grpc.insecure_channel('localhost:50051')
stub = calculator_pb2_grpc.CalculatorStub(channel)

response = stub.Add(calculator_pb2.AddRequest(a=5, b=7))
print(response.result)  # 12

6. gRPC 사용이 적합한 환경

서버 간 통신: 마이크로서비스, 클라우드 내부 통신
실시간 스트리밍: 채팅, 게임, IoT 데이터
멀티언어 환경: 서버와 클라이언트가 다른 언어로 구현된 경우

반대로 브라우저에서 단순한 API 호출은 REST API가 더 편리합니다.
브라우저에서 gRPC를 쓰려면 gRPC-Web을 사용해야 합니다.

7. 정리

gRPC는 서버 간 고성능 원격 호출을 간단하게 만들어주는 기술입니다.
.proto 파일로 설계 → Stub 생성 → 클라이언트/서버 구현 → 원격 함수 호출
REST API보다 성능, 타입 안전, 스트리밍 지원에 강점이 있습니다.
협업 환경에서 API 문서 대신 .proto 공유로 통신이 가능합니다.

이 글을 통해 gRPC의 기본 개념, 구조, 장점, 협업 방법까지 이해할 수 있습니다.

사무실 VLAN 설정을 통한 팀별 망분리

dev-hahm — Tue, 9 Sep 2025 16:49:31 +0900

사무실 네트워크에서 VLAN 구성: 공유기와 L2 스위치를 이용한 실무 가이드

사무실 네트워크를 효율적으로 구성하려면 **VLAN(Virtual LAN)**을 활용해 부서별, 팀별로 네트워크를 분리하는 것이 중요합니다. 이번 글에서는 공유기와 L2 스위치를 활용한 VLAN 구성 방법을 정리했습니다.

(공유기가 VLAN을 지원하며, 스위치는 L2스위치 입니다.)

1. VLAN이란?

VLAN(Virtual LAN): 물리적인 동일 네트워크를 논리적으로 나누어 서로 다른 네트워크처럼 운영하는 기술
장점:
1. 팀/부서별 네트워크 분리 가능
2. 브로드캐스트 도메인 분리 → 네트워크 효율 향상
3. 보안 강화 → 특정 VLAN만 접근 허용 가능

2. 네트워크 장비 계층과 역할

장비OSI 계층주요 기능

허브	L1	단순 신호 전달, 브로드캐스트
스위치	L2	MAC 주소 기반 패킷 전달, VLAN 지원 가능
L3 스위치	L3	IP 기반 라우팅, VLAN 간 통신, 서브넷 라우팅
공유기	L3 + L4	서로 다른 네트워크 간 라우팅, NAT, DHCP, 포트 관리

일반 공유기는 LAN과 WAN을 연결하는 L3 장치 역할을 수행하며, 일부 모델은 VLAN 설정을 지원합니다.
L2 스위치는 VLAN을 구분하고 포트를 팀별로 분리하는 역할을 수행합니다.

3. 사무실 VLAN 구성 예시

[목표 구성도]

목표

VLAN10: 팀 A
VLAN20: 팀 B
L2 스위치를 이용해 VLAN 간 분리
공유기를 통해 인터넷 연결

구성 흐름

공유기 VLAN 설정
- 공유기 LAN 포트 중 일부를 VLAN10, VLAN20으로 나누어 설정
- VLAN별 서브넷 지정 가능
L2 스위치 VLAN 설정
- 트렁크 포트 설정: 공유기와 스위치를 연결할 포트를 트렁크 모드로 설정
  - 트렁크 포트 → 여러 VLAN 패킷 전달
- 액세스 포트 설정: 팀별 PC 연결 포트를 각 VLAN에 할당
  - 포트 1~8 → VLAN10
  - 포트 9~16 → VLAN20
PC 연결
- 각 팀별 PC를 스위치 포트에 연결
- DHCP 또는 고정 IP를 VLAN 서브넷 범위에 맞게 할당

4. 트렁크 포트와 액세스 포트

포트 타입설명

트렁크 포트	한 포트에서 여러 VLAN 패킷 전달, 공유기와 스위치 간 연결에 사용
액세스 포트	특정 VLAN에만 속하며, 팀별 PC 연결에 사용

트렁크 포트를 공유기 → L2 스위치에 연결하면, VLAN10과 VLAN20이 한 물리적 케이블로 전달 가능
스위치 액세스 포트로 팀별 PC를 연결하면, VLAN에 따라 네트워크가 분리됩니다

5. VLAN 간 통신

VLAN10과 VLAN20은 L2 스위치만으로는 서로 통신 불가
서로 통신이 필요하면 L3 장비에서 라우팅 설정 필요
- L3 스위치나 공유기의 정적 라우트 설정
- VLAN10 ↔ VLAN20 간 패킷 전달 허용

6. 장점과 유의사항

장점

팀별 네트워크 분리 → 보안 강화
브로드캐스트 트래픽 감소 → 네트워크 효율 향상
관리 용이 → DHCP 풀, IP 대역 별 관리 가능

유의사항

VLAN 구성 시 IP 서브넷을 팀별로 구분해야 충돌 방지
트렁크 포트 설정과 VLAN 태깅(tagging)을 정확히 해야 함
L2 스위치만으로 VLAN 간 통신은 불가 → 필요 시 L3 장비 라우팅 설정 필요

7. 요약

사무실에서 팀별 VLAN 구성 시 공유기와 L2 스위치를 활용 가능
공유기 VLAN 설정 → L2 스위치 트렁크 포트 연결 → 액세스 포트 팀별 할당
VLAN 간 통신 필요 시 L3 라우팅 설정 필요
IP 서브넷 관리, 트렁크/액세스 포트 설정, DHCP 분리 등 필수

Git flow, 깃 브러치 관리 전략

dev-hahm — Mon, 8 Sep 2025 16:32:24 +0900

1인 개발자면 크게 와닿지 않겠지만 누군가와 협업을 하다보면 형상관리를 사용할 수 밖에 없습니다. 이 형상관리에도 개념적인 전략이 있습니다. 이 전략을 따라했을때 팀원들간에 협업에 브레이크가 걸리지 않고 시너지가 날 수 있습니다.

이런 전략 몇개 중 저는 Git Flow에 대해 얘기 해볼까 합니다.

1. Git Flow 개요

Git Flow는 Vincent Driessen이 제안한 Git 브랜치 모델입니다.

주요 목적은 개발 단계별 브랜치 분리와 릴리즈 관리를 명확히 하는 것입니다.

주요 브랜치 종류:

브랜치 용도

main (또는 master)	항상 프로덕션 배포 가능한 상태 유지
develop	개발 중인 기능을 통합하는 브랜치, 다음 배포 대상
feature/*	새로운 기능 개발
release/*	배포 준비, 버그 수정, 버전 번호 관리
hotfix/*	긴급 프로덕션 버그 수정

2. 머지 전략 (Merge Strategy)

Git Flow에서는 브랜치 간 병합 시 전략이 약속되어 있습니다.

(1) Feature → Develop

목적: 새 기능(feature)을 개발 브랜치(develop)에 통합
브랜치 구조: feature/XXX → develop
머지 방식:
- 보통 -no-ff (non-fast-forward) 머지 사용
- 이유: Feature 브랜치가 독립적이었음을 히스토리에 명확히 남기기 위해

git checkout develop
git merge --no-ff feature/test

결과: develop 브랜치에 feature 브랜치의 히스토리가 단일 merge commit으로 남음

(2) Develop → Release

목적: 다음 배포 준비
브랜치 구조: develop → release/X.Y.Z
머지 방식: 일반적으로 non-fast-forward, 충돌 해결 후 배포 전 테스트

git checkout release/1.2.0
git merge --no-ff develop

release 브랜치에서 최종 버그 픽스 가능, 버전 번호 수정 가능

(3) Release → Main / Release → Develop

목적:
- Main: 실제 프로덕션 배포
- Develop: release 브랜치에서 수정된 사항 반영
머지 방식:
- release → main: non-fast-forward
- release → develop: fast-forward 또는 non-fast-forward (충돌 방지 위해 merge commit 권장)

git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0 -m "Release 1.2.0"

git checkout develop
git merge --no-ff release/1.2.0

(4) Hotfix → Main / Hotfix → Develop

목적: 프로덕션 긴급 버그 수정
브랜치 구조: hotfix/X.Y.Z → main, develop
머지 방식: 항상 non-fast-forward, 태그로 버전 관리

git checkout main
git merge --no-ff hotfix/1.2.1
git tag -a 1.2.1 -m "Hotfix 1.2.1"

git checkout develop
git merge --no-ff hotfix/1.2.1

3. 요약

Fast-forward(Fast-forward merge): 단순히 브랜치가 직선으로 이어질 때 사용 가능, 히스토리 깨끗
Non-fast-forward (-no-ff): 브랜치 합쳤다는 기록을 남김, Git Flow에서는 주로 이 방식 사용
Git Flow 머지 전략 핵심:
1. 기능 개발은 feature → develop
2. 배포 준비는 develop → release
3. 배포 완료 후 main, develop에 반영
4. 긴급 수정은 hotfix → main → develop

혼자 프로젝트 하나 만들어서 장난감처럼 좀 가지고 놀다보면 대략적인 흐름은 금방 이해할 수 있습니다.

Jenkins 구축기

dev-hahm — Wed, 13 Aug 2025 21:14:25 +0900

요즘 사무실에서 이것저것.. 잡다하게 넓은 영역에 대해서 커버하고 있습니다. 그러다 보니 여러프로젝트를 배포할일이 많습니다.

이전에는 그렇게 바쁘지 않았어서 호스트에 접근해서 pull 받고 하나하나 배포했는데 이제는... 여력이 없습니다.

목마른 자가 우물을 파듯이 자동배포가 있어야겠다 마음 먹었지요.

우선 jenkins를 docker-compose.yaml로 작성했습니다.

version: "3.9"

services:
  jenkins:
    image: jenkins/jenkins:lts
    container_name: jenkins
    restart: unless-stopped
    privileged: true
    user: root
    ports:
      - "8080:8080"   # 웹 UI
      - "50000:50000" # 에이전트 통신 포트
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker
    networks:
      - jenkins_net

volumes:
  jenkins_home:

networks:
  jenkins_net:
    driver: bridge

저의 경우 yaml의 위치는 /opt/cicd/docker-compose.jenkins.yaml 로 만들었습니다. (조만간 Nexus도 같은 경로에 컨테이너로 만들 예정이랍니다.)

주요 포인트

jenkins_home 볼륨: Jenkins 데이터 영구 저장
/var/run/docker.sock 마운트: Jenkins에서 Docker 컨테이너 제어 가능

docker compose -f docker-compose.jenkins.yaml up -d

이제 컨테이너를 구동해줍니다.

http://{ip}:8080. 로 접속하셔서 초기 셋팅 하시고 로그인 하라고 나올겁니다. 그렇지만 우리는 초기 비밀번호를 모르죠??

docker exec -it jenkins cat /var/jenkins_home/secrets/initialAdminPassword

위 명령어로 컨테이너 접근해서 초기 비밀번호 확인해서 로그인 하시면 됩니다.

이렇게 까지 하면 jenkins 자체 설치는 끝이 납니다. 쉽죠??? 다음번엔 파이프라인 구축하는 글로 찾아오겠습니다.

쿠버네티스 (k8s) Core Dns란?

dev-hahm — Wed, 25 Jun 2025 21:29:24 +0900

쿠버네티스를 사용하다보면 파드(pod)끼리 ip로 연결 하는게 아닌 도메인명으로 통신하는 설정을 많이 보게 됩니다.

이 도메인은 뜬금없이 어디서 나타났는지 궁금하기도 하죠. 쿠버네티스는 자기만의 DNS서버를 구동합니다.

kube-system이란 네임스페이스에 보면 coredns라는 파드가 보이게 됩니다.
이 파드들이 쿠버네티스 내부에서 DNS서버 역할을 하게 됩니다.

A라는 파드가 B라는 파드에 요청을 보내는경우
<B-pod-servicename>.<namespace>.svc.cluster.local 이라는 도메인명으로 요청을 보내게 되면 됩니다.

같은 네임스페이스에 있는경우는 줄여서 <B-pod-servicename>만으로도 가능합니다.

좀 더 깊이 들여다보면 A라는 파드에 접근해서 /etc/resolv.conf를 열어보면 알 수 있습니다.

해당 파일은 지정된 클러스터 DNS로 전달되게 셋팅되어 있습니다.

그리고 Corefile이라고 CoreDNS에 주요 설정 파일이 있는데 이것도 한번 열어보면 이해하는데 도움이 많이 됩니다.

보통 열어보면 내용은 아래와 같습니다.

kubectl -n kube-system get configmap coredns -o yaml

열어보는 명령어니까 참고하시면 됩니다.

.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

위 플러그인에 설명을 조금 드리면

kubernetes : 쿠버네시트에 서비스 이름을 ip로 변환

forward : 외부 dns 서버로 요청을 전달

cache : dns 응답 캐싱

health, ready : coreDNS상태 체크를 위한 엔드포인트 제공

reload 설정 변경 시 자동 재로딩

prometheus : 메트릭 수집용 엔드보인트 제공

여기에 보통 log, debug 를 추가해서 coredns에 로그를 보기도 합니다. (제가 그러고 있네요)

이 내용을 이해하고 있어야 나중에 작성할 파드들에 연결문제를 파악하기 수월합니다.

쿠버네티스 (k8s) 워커노드 추가하기

dev-hahm — Thu, 5 Jun 2025 17:00:38 +0900

저번에 단일노드로 쿠버네티스를 설정했습니다. 그렇게 계속 사용할 순 없고 슬슬 노드를 추가해야겠지요...?

그리하여!

이번엔 사무실에 셋팅해놓은 추가적인 서버를 워커노드로 추가해보겠습니다. 추가하려는 노드들도 이전과 비슷한 작업을 우선 거쳐야 합니다. 모든 명령어는 워커노드에서 실행시켜주시면 됩니다.

1. swap 메모리 비활성화

sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

2. 커널 모듈 활성화

sudo modprobe overlay && sudo modprobe br_netfilter

3. 아이피(IP) 설정 파일

# /etc/sysctl.d/99-k8s.conf
net.bridge.bridge-nf-call-iptables = 1	
net.ipv4.ip_forward = 1	
net.bridge.bridge-nf-call-ip6tables = 1

/etc/sysctl.d/ 경로에 만들어주면 됩니다.

sudo sysctl --system

그리고 나서 적용되게 해주시면 되구요.

4. Containerd Install

sudo apt-get update && sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd && sudo systemctl enable containerd

5. kubeadm · kubelet · kubectl install

# ① 키 보관 디렉터리 생성
sudo install -m 0755 -d /etc/apt/keyrings

# ② 커뮤니티 저장소용 GPG 키 내려받아 dearmor
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key |
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/kubernetes-archive-keyring.gpg

# ③ APT 저장소 정의
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] \
https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list
  
sudo apt-get update

# (가장 간단) 최신 패치 수준 설치
sudo apt-get install -y kubelet kubeadm kubectl

# (지정 버전이 필요할 때) 먼저 버전을 확인하고 설치
apt-cache madison kubelet | head        # 1.33.1-1.1 같은 형식 확인
sudo apt-get install -y kubelet=1.33.1-1.1 kubeadm=1.33.1-1.1 kubectl=1.33.1-1.1

6. Version Hold

sudo apt-mark hold kubelet kubeadm kubectl

7. Cluster Join

# control plane node
sudo kubeadm token create --print-join-command

이 명령어는 control plane node에서 진행해주셔야 합니다. 클러스터로 가입할 키를 발급하는 명령어입니다. 그럼 위 결과로 kubeadm join <IP>:<port> —token :~ 와 같은 형태가 나타나게 되구요. 잘 복사해주세요.

# worker node
sudo kubeadm join ~~~
sudo systemctl restart kubelet

워커 노드에서 복사한 구문을 입력해주시면 됩니다.

8. Confirm Node

kubectl get nodes -o wide

control plane node에서 이렇게 확인해보시면 클러스터로 추가된걸 확인하실 수 있습니다.

쿠버네티스(k8s) 온프레미스 환경으로 설치하기

dev-hahm — Wed, 4 Jun 2025 17:15:29 +0900

현재 새로운 프로젝트에 앞서 docker compose를 이용해서 멀티 서버 환경을 구성했습니다. 서버에 장애를 확인하기 위해 모니터링까지 구축해놨지만 장애에 유기적으로 대응하는 부분은 부족하다고 느껴져 k8s에 대해 뒤적뒤적 거리게 되었습니다.

k8s를 구축하는데 있어서 클라우드를 활용할 수 있겠지만 우리의 경우 보안으로 인해 클라우드 환경은 이용할 수 없다는 제약이 존재 합니다.
그럼 결국 On-premise 환경으로 구축을 해야한다는 것을 의미합니다.

이번 k8s은 1.33.1 버전을 이용하여 구축하게 되었습니다. (2025-06-04 기준 최신버전)

우선은 서버1대 (Ubuntu 24.04 LTS)에 단일 노드 구성으로 진행하고 추후에 노드를 늘려가는식으로 진행하려 합니다.

1. 시스템 준비

sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab          # 영구 비활성화
sudo modprobe overlay br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system

기본적으로 k8s는 swap 메모리를 비활성화 해야합니다. (swap 메모리를 간단히 얘기하면 RAM 용량이 부족할때 디스크용량을 추가로 이용하겠다는 개념입니다.)

2. Containerd Install

sudo apt-get update && sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd && sudo systemctl enable containerd

최신 k8s은 docker container를 사용하지않고 Containerd를 자체적으로 사용합니다. (docker container로 내부적으론 containerd를 호출 하는 방식으로 알고 있습니다.)

그리고 config.toml파일에 SystemdCgroup = true로 변경해주어야 합니다.

3. kubelet, kubeadm, kubectl Install

# ① 키 보관 디렉터리 생성
sudo install -m 0755 -d /etc/apt/keyrings

# ② 커뮤니티 저장소용 GPG 키 내려받아 dearmor
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key |
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/kubernetes-archive-keyring.gpg

# ③ APT 저장소 정의
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] \
https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list
  
sudo apt-get update

# (가장 간단) 최신 패치 수준 설치
sudo apt-get install -y kubelet kubeadm kubectl

# (지정 버전이 필요할 때) 먼저 버전을 확인하고 설치
apt-cache madison kubelet | head        # 1.33.1-1.1 같은 형식 확인
sudo apt-get install -y kubelet=1.33.1-1.1 kubeadm=1.33.1-1.1 kubectl=1.33.1-1.1

4. Version Hold

sudo apt-mark hold kubelet kubeadm kubectl

혹시 모를 버전 변경을 방지하고자 버전 유지를 진행합니다.

5. Cluster Init

sudo kubeadm init \
    --pod-network-cidr=10.244.0.0/16 \
    --kubernetes-version=1.33.1
    
# 완료 메시지에 kubeadm join 명령(토큰, hash 포함)이 출력되므로 기록.

여기서 발생하는 토큰은 나중에 새로운 노드를 클러스터로 join할때 사용하게 됩니다. hash값은 내가 연결하려는 API서버가 올바른 CA 인증서를 가진 클러스터인지를 검증하기 위한 공개키 지문입니다. 이 또한 클러스터로 join할때 사용됩니다.

6. kubectl 환경 구성

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

7. CNI적용 (e.g., Calico)

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml

CNI(Container Network Interface)에 줄임말이다. CNI는 새 파드 생성 시 가상 NIC-IP 라우팅 할당을 담당하며 파드 삭제 시 정리도 맡아준다.

8. 단일노드 스케줄링 허용

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

kubeadm은 기본적으로 제어플레인 노드에 node-role.kubernetes.io/control-plane:NoSchedule taint를 자동 추가합니다.
이는 "시스템 파드만 올라오고 일반 워크로드 파드는 배치 금지"라는 정책입니다. 현재는 단일노드로 일반 파드까지 띄워보기 위해서는 해당 정책을 꺼준다고 생각하면 됩니다.

DTO vs VO

dev-hahm — Wed, 16 Apr 2025 14:13:21 +0900

실무에서 DTO와 VO를 구분짓지 않고 비슷하게 사용하는 경우가 많다.

이 둘은 명칭이 다른거처럼 사용하기위한 목적이 엄연히 다르다. 바로 요약부터 하자면 아래와 같다.

항목	VO (Value Object)	DTO (Data Transfer Object)
목적	값을 표현하는 객체 (불변, 의미 중심)	데이터 전송을 위한 객체 (레이어 간 전달)
용도	도메인 모델의 구성 요소	계층 간 (예: 컨트롤러 ↔ 서비스) 데이터 전달
불변성	원칙적으로 불변 (immutable)	변경 가능 (mutable)
equals/hashCode	값 기준 비교 (필수 구현)	주로 필요 없음
위치	도메인 모델 내부	계층 사이 (Controller, Service, etc)

이렇게 봐도 사실 크게 와닿지 않을 수 있다. 추가로 예시코드까지 봐보자.

이메일에 대한 VO를 예시로 보면

@Embeddable
public class Email {
    private String value;

    protected Email() {} // JPA 기본 생성자

    public Email(String value) {
        if (!value.matches("^[A-Za-z0-9+_.-]+@(.+)$")) {
            throw new IllegalArgumentException("Invalid email format");
        }
        this.value = value;
    }

    public String getValue() {
        return value;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Email)) return false;
        Email email = (Email) o;
        return Objects.equals(value, email.value);
    }

    @Override
    public int hashCode() {
        return Objects.hash(value);
    }
}

이메일에 대한 validation과 equals, hashCode 함수를 구현해놨다.

public class UserRequestDto {
    private String email;
    private String password;
    private String name;

    // getter/setter
}

단순히 요청에대한 값을 담고 get / set 하고 있다.

그럼 여기서 의문점이 하나 생긴다.

"그럼 DTO에 필드에다가 @NotBlank, @Eamil 등... validation 어노테이션을 사용하면 되는거 아닌가?"

물론 기능적으로 보면 가능하다고 할 수 있지만 위에서 얘기한바와 같이 vo와 dto는 목적이 다르게 생긴거다.
vo는 유효성 검사를 넘어 '도메인 모델링'의 목적이 있다. 더 설명을 보태자면.

1. DTO Validation (@Valid, @Email 등)

public class CreateUserRequest {
    @NotBlank
    @Email
    private String email;

    @NotBlank
    private String name;

    // getter/setter
}

✅ 장점

간단하고 빠르게 유효성 검증 적용 가능
Spring에서 자동으로 @Valid 처리됨
컨트롤러에서의 잘못된 요청을 쉽게 걸러냄

❌ 한계

오직 요청 처리 계층에서만 적용됨 (컨트롤러)
서비스, 도메인 레이어에선 다시 검증하거나 검증 안 한 채 사용될 수 있음
재사용 어려움: 다른 곳에서 같은 규칙을 또 정의해야 함

2. VO Validation (생성자에서 검사)

public class Email {
    private final String value;

    public Email(String value) {
        if (!value.matches("^[A-Za-z0-9+_.-]+@(.+)$")) {
            throw new IllegalArgumentException("Invalid email format");
        }
        this.value = value;
    }

    public String getValue() { return value; }
}

✅ 장점

한 번 생성되면 유효함이 보장된 객체
Service, Domain, Entity 어디서든 일관되게 사용 가능
도메인 개념으로써의 의미 전달력이 강력 (String 대신 Email이라는 타입 자체가 의미 있음)
테스트 코드나 다른 계층에서도 재사용성, 안전성 확보

❌ 단점

클래스가 많아짐
단순한 프로젝트에선 과할 수 있음

요약 정리

VO는 Validation 기능 + 도메인 설계 가치를 동시에 제공하는 도구이다. 단순히 “검증만 되면 된다”는 관점에서 한 발 더 나아가 **“의도를 코드로 표현”**하고 싶은 경우에 VO는 훨씬 유의미합니다.

React 프로젝트 생성 및 React 버전 다운그레이드 방법

dev-hahm — Fri, 27 Dec 2024 14:01:23 +0900

React를 사용해 프론트엔드 프로젝트를 시작하면서 최신 버전의 React(2024년 12월 27일 기준, React 19 버전)에서 문제가 발생한 경험을 공유합니다. 이를 해결하기 위해 React의 버전을 낮춰 프로젝트를 설정하는 방법을 정리했습니다.

1. 프로젝트 폴더 생성

먼저 작업을 진행할 프로젝트 폴더를 생성합니다. 아래 명령어를 순서대로 실행하세요.

cd \ 
mkdir app\frontend 
cd app\frontend

위 명령어를 실행하면 C:\app\frontend 폴더가 생성됩니다.

2. React 프로젝트 설치

React 프로젝트를 초기화하려면 npx create-react-app 명령어를 실행합니다.

npx create-react-app .

create-react-app 명령어는 프로젝트 초기 설정을 자동으로 구성해주며, React의 최신 버전(2024년 12월 27일 기준, React 19 버전)을 설치합니다.

3. React 버전 문제 및 해결 방법

React 19 버전에서 문제가 발생하는 경우, React와 React DOM의 버전을 낮춰야 합니다. 아래 명령어를 통해 React와 React DOM의 버전을 18.3.1로 다운그레이드할 수 있습니다.

npm install react@18.3.1 react-dom@18.3.1

4. package.json 확인

버전이 제대로 적용되었는지 확인하려면 프로젝트 폴더의 package.json 파일을 열어 아래 내용을 확인합니다.

"dependencies": { 
    "react": "18.3.1", 
    "react-dom": "18.3.1", ... 
}

React와 React DOM의 버전이 18.3.1로 표시된다면 성공적으로 버전이 낮춰진 것입니다.

결론

React 프로젝트 초기 설정 시, 최신 버전의 React에서 문제가 발생할 수 있습니다. 이럴 때 React와 React DOM의 버전을 낮추는 방법을 통해 문제를 해결할 수 있습니다. 위 단계를 참고하여 안정적인 환경에서 React 프로젝트를 시작해보세요!

hahm's period of growth

PostgreSQL의 AT TIME ZONE 완벽히 이해하기

기본 환경 설정

AT TIME ZONE의 두 얼굴

규칙 1: timestamp (타임존 없음) → timestamptz

규칙 2: timestamptz → timestamp (타임존 없음)

헷갈리는 문자열 처리

current_date의 함정

seoul_time1: current_date AT TIME ZONE 'Asia/Seoul'

seoul_time2: current_date::timestamp AT TIME ZONE 'Asia/Seoul'

실전 문제: "오늘" 데이터 조회하기

다국적 서비스에서 "오늘" 집계하기

방법 1: 사용자별 타임존으로 필터링

방법 2: 더 명확한 date_trunc 사용

방법 3: 클라이언트에서 타임존 전달 (권장)

핵심 정리

AT TIME ZONE 동작 규칙

실수하기 쉬운 패턴

기억해야 할 것

마치며

gRPC 입문: 서버 간 통신을 간단하게 만드는 Google RPC

gRPC 입문: 서버 간 통신을 간단하게 만드는 Google RPC

1. gRPC란 무엇인가?

2. gRPC가 필요한 이유

3. gRPC 기본 구성 요소

4. 협업 시 gRPC 사용 방법

5. 간단한 예제: 계산기 서비스

.proto 파일

서버 구현 (Python)

클라이언트 호출

6. gRPC 사용이 적합한 환경

7. 정리

사무실 VLAN 설정을 통한 팀별 망분리

사무실 네트워크에서 VLAN 구성: 공유기와 L2 스위치를 이용한 실무 가이드

1. VLAN이란?

2. 네트워크 장비 계층과 역할

3. 사무실 VLAN 구성 예시

목표

구성 흐름

4. 트렁크 포트와 액세스 포트

5. VLAN 간 통신

6. 장점과 유의사항

장점

유의사항

7. 요약

Git flow, 깃 브러치 관리 전략

1. Git Flow 개요

2. 머지 전략 (Merge Strategy)

(1) Feature → Develop

(2) Develop → Release

(3) Release → Main / Release → Develop

(4) Hotfix → Main / Hotfix → Develop

3. 요약

Jenkins 구축기

쿠버네티스 (k8s) Core Dns란?

쿠버네티스 (k8s) 워커노드 추가하기

쿠버네티스(k8s) 온프레미스 환경으로 설치하기

DTO vs VO

1. DTO Validation (@Valid, @Email 등)

✅ 장점

❌ 한계

2. VO Validation (생성자에서 검사)

✅ 장점

❌ 단점

요약 정리

React 프로젝트 생성 및 React 버전 다운그레이드 방법

1. 프로젝트 폴더 생성

2. React 프로젝트 설치

3. React 버전 문제 및 해결 방법

4. package.json 확인

결론

seoul_time1: `current_date AT TIME ZONE 'Asia/Seoul'`

seoul_time2: `current_date::timestamp AT TIME ZONE 'Asia/Seoul'`

`.proto` 파일