Posts on Kiglo

ArgoCD 연재 2편: GitLab Repository 및 대상 EKS 클러스터 연동

Thu, 08 Jan 2026 14:30:00 +0900

1편에서 설치한 ArgoCD 서버가 우리의 소스 코드를 읽어올 수 있도록 GitLab 저장소를 연결하고, 애플리케이션이 실제로 배포될 타겟 EKS 클러스터를 등록하는 과정을 다룹니다.

1. GitLab Repository 연결 (HTTPS Token 방식)

프라이빗 GitLab 저장소에 접근하기 위해 SSH Key 방식 대신, 관리 및 권한 제어가 용이한 Access Token (glpat) 방식으로 진행 합니다.

1) GitLab Service Account 생성 및 Token 발급

일반 사용자 계정에 종속되지 않도록 GitLab에서 제공하는 Service Account 기능을 활용하는 것이 보다 이상적입니다. (GitLab Premium 이상에서 Group/Project 레벨 Service Account 지원)

ArgoCD 연재 1편: EKS에 ArgoCD 설치 및 고도화 (Kustomize & Istio & Valkey)

Mon, 05 Jan 2026 10:00:00 +0900

서론

EKS 환경에서 GitOps를 구현하기 위한 도구인 ArgoCD의 설치 과정을 다룹니다. Kustomize를 통해 Helm Chart를 래핑하여 활용하는 방법을 다룹니다.

본 포스트에서 사용되는 설정 파일과 샘플 코드는 다음 레포지토리에서 확인하실 수 있습니다 Github 링크

설치 환경

EKS Cluster
Istio Service Mesh
Amazon ElastiCache (Valkey 8.2)

ArgoCD 설치 (Kustomize + Helm)

ArgoCD를 보다 선언적으로 관리하기 위해 ./argocd 디렉토리에 Kustomize 설정을 구성했습니다. 이 방식은 Helm Chart의 유연함과 Kustomize의 구조적 관리 장점을 동시에 가져갈 수 있습니다.

Home Server (5): Hugo 블로그 구축과 Cloudflare Pages 배포

Sat, 27 Dec 2025 18:04:00 +0900

블로그 플랫폼 선정: 어떤 도구를 쓸 것인가?

홈서버 연재를 결심하고 가장 먼저 고민한 것은 “어디에 글을 쓸 것인가"였습니다. 제가 고려했던 세 가지 선택지는 다음과 같았습니다.

1. Velog / Medium (External Platform)

장점: 별도의 서버 세팅이 전혀 필요 없으며, 플랫폼 자체의 유입 덕분에 글을 알리기에 가장 유리합니다. 사실 운영 효율 면에서는 가장 합리적인 선택지입니다.
단점: 디자인 커스터마이징에 제약이 있고, 무엇보다 이미 구축해둔 홈서버와 개인 도메인을 최대한 활용하고 싶다는 ‘자기만족’의 관점에서 제외하게 되었습니다.

2. Ghost (Self-hosted)

장점: UI가 다채롭고 에디터가 좋습니다. 뉴스레터 기능도 기본 탑재되어 있고 실제 프로덕션에서 Ghost 를 운영하는 기업들이 많습니다.
단점: Node.js와 데이터베이스를 직접 운영해야 합니다. 버전 업데이트나 DB도 같이 관리해야 하며, 미니 PC의 리소스를 상시 점유한다는 점이 간단한 블로그 운영을 원하는 저에게는 부담스러웠습니다.

3. Hugo (SSG)

장점: 마크다운 기반으로 로컬에서 작성하며, 결과물이 정적 HTML이므로 서버 부하나 보안 위협이 거의 없습니다. 테마를 통한 커스터마이징이 가능하고, Git으로 모든 이력을 관리할 수 있습니다.
단점: 초기 테마 세팅이나 마크다운 문법에 익숙해지는 과정이 필요합니다.

최종 선택: Hugo
홈서버 운영법을 공유하는 블로그 자체가 홈서버 부하의 원인이 되는 것은 앞뒤가 맞지 않는다고 생각했습니다. “최소한의 리소스로 최고의 퍼포먼스를 내자"는 이번 홈서버 구축 철학에 맞춰, 가장 가볍고 개발자 친화적인 Hugo를 최종 선택하게 되었습니다.

Infrastructure as Code: 전역 리전 통합 알림 아키텍처와 테라폼 전략

Mon, 22 Dec 2025 10:00:00 +0900

전역 리전 모니터링의 한계와 도전

이전 글(실전 편)에서 테라폼을 이용해 2-AZ 기반의 탄탄한 네트워크 기반을 마련했습니다. 이번에는 이렇게 구축된 인프라 위에서 발생하는 중요한 이벤트들을 전역 리전 단위로 어떻게 효율적으로 관리할 수 있는지 다뤄보겠습니다.

AWS에서 다중 리전을 운영하다 보면, 각 리전에서 발생하는 중요한 이벤트(GuardDuty 위협 감지, AWS Health의 점검 공지, 루팅 로그인 등)를 개별적으로 관리하는 것이 매우 번거롭다는 것을 알게 됩니다.

리전마다 람다(Lambda)를 띄우고 알림 채널(SNS/Slack)을 연동하는 것은 이른바 “노가다"에 가깝습니다. 이를 해결하기 위해 EventBridge의 리전 간 포워딩 기능을 활용한 효율적인 아키텍처를 소개합니다.

Terraform 실전: 2-AZ VPC와 서브넷 세팅

Sun, 21 Dec 2025 11:00:00 +0900

이론을 넘어 실전으로

VPC 세팅과 Peering vs TGW 글 내용을 기반으로, 2AZ VPC 를 terraform 으로 구성해 보겠습니다.

1. 변수 정의와 리전 설정

먼저 확장성을 위해 AZ 목록을 변수화하고 리전을 정의합니다.

variable "region" {
  default = "ap-northeast-2"
}

variable "azs" {
  description = "사용할 가용 영역 리스트"
  type        = list(string)
  default     = ["ap-northeast-2a", "ap-northeast-2c"] # 2-AZ 전략
}

variable "vpc_cidr" {
  default = "10.0.0.0/16"
}

2. VPC와 서브넷: `cidrsubnet`과 `count`의 활용

서브넷을 하드코딩하는 것은 가장 피해야 할 습관입니다. 테라폼의 내장 함수를 사용하여 자동으로 계산되게 구성합니다.

VPC 세팅과 Peering vs TGW

Sun, 21 Dec 2025 10:00:00 +0900

네트워크 레이어 설계의 핵심

클라우드 인프라의 뼈대인 VPC를 설계할 때, “가용영역(AZ)은 무조건 최대로 쓸수록 좋다"는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 비용, 성능, 관리 복잡성 사이의 균형점이 필요하다고 생각합니다.

AZ(Availability Zone) 전략: 3AZ? 2AZ?

대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 2개의 AZ가 더 효율적인 경우도 얼마든지 있습니다.

1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback

Kubernetes의 Topology Aware Routing은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 ‘버그’처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다.

Infrastructure as Code: 효율적인 테라폼 Layer 설계와 격리(Isolation) 전략

Sat, 20 Dec 2025 10:00:00 +0900

“딸깍의 함정”

테라폼을 처음 접하면 모든 리소스(VPC, DB, EC2 등)를 하나의 .tf 파일 혹은 하나의 프로젝트 폴더에 몰아넣고 terraform apply를 날리고 싶다는 유혹에 빠지기 쉽다고 생각합니다. 하지만 프로덕션 환경에서 이런 방식은 매우 위험합니다.

인프라의 규모가 커질수록 **폭발 반경(Blast Radius)**을 최소화하고 관리 효율을 높이기 위한 Layered Architecture 도입이 필수적입니다.

레이어(Layer) 도입의 계기와 의의

모든 인프라를 한 곳에서 관리하면 특정 리소스(예: 보안 그룹 규칙)를 수정하다가 실수로 VPC 전체를 재생성하거나, 상태(State) 파일이 꼬여 전체 인프라가 마비되는 리스크가 존재합니다.

Home Server (4): GitLab CI/CD로 배포 자동화하기

Fri, 19 Dec 2025 18:03:00 +0900

왜 GitLab인가? (GitHub vs GitLab)

홈서버의 배포 자동화를 위해 가장 먼저 고민한 것은 “어떤 플랫폼을 쓸 것인가?“였습니다. 흔히 쓰이는 GitHub Actions 대신 GitLab CI/CD를 선택한 이유는 다음과 같습니다.

비교 항목	GitHub (Free)	GitLab (Free)	비고
Registry 용량	500MB	5GB	홈서버 이미지 적재 시 유리
Self-hosted Runner	가능	매우 간편함	GitLab Runner의 아키텍처가 더 직관적
CI/CD 기능	유연함 (Actions)	강력한 통합	내장된 배포 관리 기능이 풍부함

특히 홈서버는 리소스가 한정적이기 때문에, Container Registry 용량이 넉넉하고 Runner 설치 및 관리가 압도적으로 편한 GitLab이 더 매력적인 선택지였습니다.

Home Server (Extra): Teleport로 안전하게 서버 접속하기

Tue, 16 Dec 2025 18:10:00 +0900

Why Teleport?

홈서버를 외부에서 안전하게 접속하기 위해 기존에는 VPN(Tailscale, WireGuard)이나 단순히 SSH 포트를 개방하는 방식을 사용했습니다. 하지만 다음과 같은 이유로 Teleport를 도입하게 되었습니다.

Access plane: SSH, RDP, Kubernetes, Database, Web App 등 다양한 프로토콜을 단일 Gateway로 통합 관리
Audit Log: 누가 언제 어디서 서버에 접속해서 어떤 명령어를 입력했는지 녹화 및 기록 (보안 감사)
RBAC: 역할 기반 접근 통제
No VPN: 별도의 VPN 클라이언트 없이 웹 브라우저만으로도 터미널 접속 가능

더 자세한 정보는 Teleport 공식 홈페이지와 공식 문서(Documentation)를 참고하세요.

Home Server (3): Cloudflare Tunnel로 안전하게 외부 접속하기

Wed, 10 Dec 2025 18:02:00 +0900

도메인 구매

저는 Cloudflare Registrar를 통해 도메인을 구매했습니다.

Cloudflare를 선택한 이유는 관리 편의성도 있지만, 도메인 등록 비용에 별도의 수수료를 붙이지 않고 도매가 수준으로 제공하기 때문입니다. 또한, 뒤에 설명할 보안 기능들을 도메인 연동 즉시 무료 플랜에서도 대부분 사용할 수 있다는 점이 큰 장점입니다.

Cloudflare Tunnel (`cloudflared`) 도입

기존의 서비스 노출 방식은 공유기에서 포트 포워딩(Port Forwarding) 을 설정하는 것이었습니다. 하지만 이 방식은 몇 가지 고질적인 문제가 있습니다.

보안 취약성: 특정 포트가 인터넷에 직접 노출되어 공격자의 타겟이 되기 쉽습니다.
유동 IP 대응: IP가 바뀔 때마다 DDNS 설정을 갱신해야 합니다.
포트 부족: 하나의 공인 IP에서 여러 서비스를 운영하기 번거롭습니다.

저는 이를 해결하기 위해 Cloudflare Tunnel을 사용했습니다.

Home Server (2): Ubuntu 24.04 설치 및 Docker 구성

Thu, 04 Dec 2025 18:01:00 +0900

OS 설치

1. Bootable USB Creation

미니 PC에 설치할 운영체제로는 **Ubuntu Server 24.04 LTS (Noble Numbat)**를 선택했습니다. 맥(macOS) 환경에서 부팅 USB를 만들기 위해 Balena Etcher를 사용했습니다.

Ubuntu Server 다운로드: Get Ubuntu Server
Balena Etcher 다운로드: Download Balena Etcher

Balena Etcher를 실행하고 다운로드 받은 ISO 파일과 USB 드라이브를 선택한 뒤 Flash! 버튼만 누르면 간단하게 설치 USB가 완성됩니다.

Initial Setup Guide

우분투 설치 후, 홈서버 운영에 필요한 필수 패키지들을 설치했습니다.

1. Essential Tools (Git, Docker, PostgreSQL Client)

기본적인 도구들과 데이터베이스 관리를 위한 클라이언트,그리고 컨테이너 런타임을 설치합니다. PostgreSQL Client는 특정 버전(16.x)이 필요하여 별도 리포지토리를 추가했습니다.

Home Server (1): 네트워크 구성과 하드웨어 아키텍처

Tue, 02 Dec 2025 18:00:00 +0900

Hardware Specification

홈서버로 사용 중인 장비는 알리익스프레스 등에서 가성비로 유명한 Intel N100 기반의 미니 PC, T8 Plus 모델입니다.

System Info (`lshw`)

주요 하드웨어 스펙은 다음과 같습니다.

Model: T8_Plus (T8P-F)
CPU: Intel(R) N100 (4 Cores, 4 Threads)
RAM: 16GB LPDDR5 4800MHz (On-board)
Storage: 512GB SSD (N900-512)
Network Interface:
- 2x Gigabit Ethernet (Realtek RTL8111/8168/8411)
- 1x Wireless AC (Realtek RTL8821CE)

저전력 프로세서인 N100을 탑재하여 24시간 켜두는 홈서버 용도로 전기요금 부담이 적으며, Docker 컨테이너 수십 개를 돌리기에 충분한 퍼포먼스를 보여줍니다.