하얀잔디

Google Calendar WebHook 연동 방법

하얀잔디 — Fri, 26 Jun 2026 16:37:28 +0900

처음에는 Google Calendar에서 일정 시작 10분 전에 우리 서버로 Webhook을 호출해주는 줄 알았는데, 찾아보니 그런 기능은 없었음.

Google Calendar에서 지원하는 Webhook은 일정이 생성/수정/삭제될 때만 호출됨.
즉, "10분 후 일정 시작" 같은 이벤트는 직접 만들어야 함.

그래서 Google Apps Script를 사용했음.

Apps Script에서 시간 기반 트리거를 등록해 일정 주기로 실행하고, 현재 시간 기준으로 앞으로 시작할 일정을 조회한 뒤 조건에 맞

으면 우리 서버 API를 호출하는 방식으로 구현.

흐름은 아래와 같음.

{
  "chatRoomId": "...",
  "content": "  '개발 회의' 일정이 곧 시작됩니다."
}

흐름

Google Calendar
        ↓
Google Apps Script
(시간 기반 트리거)
        ↓
일정 조회
        ↓
조건 만족
        ↓
POST /v1/bot/send
        ↓
채팅방 알림

참고

동일한 일정에 대해 중복 전송되지 않도록 Event ID 등을 저장하는 로직 필요.
Apps Script는 브라우저만 있으면 사용 가능하며 별도 설치 불필요.
Google Calendar 자체에서 원하는 Body로 서버를 호출하는 기능은 제공하지 않음. Apps Script가 중간에서 원하는 형식으로 가공하여 호출하는 방식 사용.

HTTP 206 Partial Content의 비밀

하얀잔디 — Thu, 25 Jun 2026 17:02:16 +0900

사내 동영상 파일 서버에서 다운로드가 왜 이렇게 기어가냐는 제보가 들어옴.

인프라팀에 확인해 보니까 QoS가 200Mbps로 잡혀 있었음..

초당 25MB 정도는 빠지는 대역폭이라 회선 자체가 대단히 쪼달리는 상황은 아닌 것 같았음.

대체 뭐가 문제인가 싶어 엑세스 로그(Access Log)부터 까봤는데, 좀 이상한 현상이 보임. 유저가 동영상 파일 하나를 요청했는데 로그가 달랑 한 줄 찍히는 게 아니라, 짧은 시간 동안 수십 번씩 연속으로 호출되는 묘한 상황이었음. 게다가 응답 코드는 익숙한 200 OK가 아니라 죄다 206 Partial Content로 찍히고 있었음.

HTTP 206...이 아니라 원래 그런 거였다 (HTTP 206 Status와 다중 호출의 원인)

HTTP 206 Partial Content가 뭐길래? 이건 브라우저나 플레이어 같은 클라이언트가 "나 이 파일 처음부터 끝까지 다 필요 없고, 딱 요만큼만(Range) 먼저 줘"라고 요청했을 때, 서버가 "ㅇㅋ, 요청한 조각(Chunk)만 잘라서 보낸다" 하고 응답하는 코드임.

그럼 왜 이렇게 로그가 여러 번 쪼개져서 찍혔을까? 동영상 스트리밍이나 대용량 파일을 받을 때, 요즘 브라우저들은 한방에 다운로드하지 않음. 효율적으로 버퍼링을 하려고 Range: bytes=0-1023 같은 헤더를 날리면서 야금야금 이어 받기를 시도함.

게다가 유저가 영상을 보다가 중간에 싱크를 뒤로 돌리거나(Seeking), 브라우저가 플레이어 버퍼를 채우려고 미리 뒷부분을 땡겨올 때마다 서버에 새로운 206 요청을 계속 때리게 됨.

결론적으로 로그에 호출이 무더기로 찍혔던 건 서버가 터지거나 에러가 난 게 아니라, 동영상 스트리밍 환경에서 아주 지극히 정상적인 동작이었음. 속도가 느린 진짜 원인은 206 코드가 아니라, 이 조각 요청들이 들어올 때 대역폭 제한(Throttling)이나 커넥션 쪽에 병목이 걸린 게 아닌가 싶음. 타임라인 따라서 조금 더 파봐야 할 듯.

DB) AutoVaccumm이란

하얀잔디 — Fri, 19 Jun 2026 16:05:49 +0900

이게 도대체 왜 필요한 거임?

PostgreSQL은 데이터를 수정(UPDATE)하거나 삭제(DELETE)할 때 바로 진짜 지우지 않음.
이거 이제 안 쓰는 데이터임 하고 껍데기(Dead Tuple)만 남겨둠. (이걸 MVCC 방식이라고 함).
이 껍데기 찌꺼기들을 제때 안 치우면 DB가 쓸데없이 비대해지고 엄청 무거워짐.
그래서 "야, 너네가 알아서 주기적으로 청소 좀 해라" 하고 시키는 게 바로 AutoVacuum(자동 진공)임.

구체적으로 뭘 하는 건데?

찌꺼기 청소: 안 쓰는 데이터 공간을 깨끗이 비워서 새로운 데이터가 들어올 수 있게 빈자리 만들어 줌.
통계 정보 최신화: DB한테 "지금 데이터 이렇게 들어있으니까 쿼리 날릴 때 이 길로 찾아가면 빠름" 하고 똑똑한 길(실행 계획)을 안내해 줌.
한 마디로 DB 성능 유지를 위한 자동 방청소(정리정돈) 기능.

데이터 많으면 성능에 지장 있지 않나?

결론부터 말하면 걱정 노노.
내 DB 기준 데이터가 2,000만 건이나 되었는데도 아무 문제 없이 아주 잘 돌아갔음. * 요즘 하드웨어 성능이 워낙 좋아서 이 정도 규모는 AutoVacuum이 돌아가도 티도 안 나고 스무스하게 처리함.
옛날 옛적 구닥다리 버전 시절에는 이거 돌면 DB 느려진다고 수동으로 끄기도 했다는데, 지금은 절대 끄면 안 되는 필수 기능임. 끄면 진짜 DB 터짐.

온프레미스 Overlay vs AWS EKS VPC CNI 차이점 정리

하얀잔디 — Wed, 17 Jun 2026 10:40:58 +0900

1. 기본 개념 정의 (Node와 Pod의 관계)

노드(Node): 인프라의 기본이 되는 가상 컴퓨터/서버 본체 (EKS 환경에서는 100% EC2 인스턴스 의미)
파드(Pod): 해당 노드(EC2) 내부에서 실행되는 컨테이너 프로세스(프로그램) 뭉치

2. 온프레미스 CNI (Calico, Flannel 등) 작동 방식

서버 본체가 사용하는 물리 IP 망 위에 가상의 네트워크 망(Overlay)을 한 겹 덧씌우는 형태.
IP 할당: Pod들은 실제 물리 인프라와 단절된 가상 IP 대역(예: 192.168.x.x)을 부여받음.
통신 원리 (캡슐화): * 다른 노드의 Pod와 통신할 때 가상 IP 패킷을 실제 서버의 물리 IP 패킷으로 한 번 더 감싸서(포장) 보냄.
- 받는 쪽 서버에서는 이 포장을 다시 뜯어서 내부에 전달해야 함.
- 매 패킷마다 포장(캡슐화) 및 해제(역캡슐화)를 위한 CPU 연산 낭비가 발생함.
- 이렇게 하는 이유: 왜 포장해야 하는가? (물리 라우터가 가상 IP를 모르기 때문임!! ( 다른 물리서버에서는 192.168.. 이런거 없을 수 있기 때문)

3. AWS EKS (VPC CNI) 작동 방식

가상 오버레이 망을 만들지 않고, AWS VPC 인프라의 실제 사설 IP를 Pod에 다이렉트로 꽂아버리는 구조.
IP 할당: 사용자가 설계한 VPC 서브넷 대역(예: 10.100.1.X/24) 안에서 EC2 본체 IP뿐만 아니라 Pod IP까지 사이좋게 나눠 가짐.
통신 원리:
- AWS VPC 입장에서는 EC2가 보낸 패킷인지 Pod가 보낸 패킷인지 구분 안 함. 둘 다 정식 사설 IP이기 때문.
- 패킷 포장/해제 같은 중간 과정이 아예 없음.
- Pod가 날린 트래픽이 AWS 물리 네트워크(가상 스위치 망) 하드웨어 레벨에서 그대로 다이렉트 라우팅되어 목적지(다른 Pod나 RDS 등)로 바로 날아감. 네트워크 레이턴시 측면에서 압도적으로 유리.

4. 치명적인 트레이드오프 (IP 고갈 문제)

온프레미스(Overlay): 가짜 가상 IP를 쓰기 때문에 서버(Node) 한 대 사양이 허락하는 한 Pod를 100개든 200개든 제한 없이 생성 가능.
EKS (VPC CNI): Pod 하나가 진짜 AWS 사설 IP를 1개씩 집어삼킴.
- EC2 인스턴스 타입별(예: m5.large 등)로 장착 가능한 보조 사설 IP 개수에 물리적인 한계가 존재함.
- 문제 발생: CPU/메모리 리소스가 널널하게 남아돌아도, 해당 EC2가 땡겨올 수 있는 AWS IP 개수가 바닥나면 스케줄링 실패(Pod 생성 불가능) 현상 발생.

Kube)NodePort vs LoadBalancer

하얀잔디 — Wed, 17 Jun 2026 10:31:31 +0900

알았다고 생각했는데 헷갈렸던 개념 살짝 정리!

가장중요한건 Port를 외부에 노출하는지, IP를 호출하는지 차이임.

NodePort (각 노드의 문을 열어두는 방식)

개념: 모든 쿠버네티스 노드(서버)의 똑같은 포트(예: 30001번)를 외부로 활짝 열어버리는 방식입니다.
접속 방법: http://노드A_IP:30001 또는 http://노드B_IP:30001로 노드 IP를 직접 치고 들어옵니다.
단점: 노드가 죽으면 그 IP로는 접속이 안 됩니다. 사용자가 노드 IP들을 일일이 다 알고 있어야 하고, 보안상 노드의 포트를 직접 노출해야 하므로 실무 운영 환경에서는 단독으로 잘 쓰지 않습니다.

LoadBalancer (단일 진입점을 제공하는 방식)

개념: NodePort들 앞에 대표 진입점(단일 IP 또는 도메인)을 가진 진짜 로드밸런서를 하나 세우는 방식입니다.
접속 방법: 사용자는 노드 IP를 몰라도 됩니다. 그냥 로드밸런서가 준 대표 IP(http://1.2.3.4) 하나로만 접속하면 됩니다.
장점: 로드밸런서가 알아서 살아있는 노드들에게 트래픽을 골고루 나눠줍니다(부하분산). 보안도 안전하고 외부에 깔끔한 하나의 주소만 노출되므로, 실제 서비스 운영 시 필수적으로 사용됩니다.

요약 표

구분	NodePort	LoadBalancer
핵심 개념	모든 노드에 동일한 외부 포트를 개방	NodePort 앞에 대표 로드밸런서(IP)를 배치
접속 주소	각 노드 IP : 지정된 포트 (여러 개)	로드밸런서 대표 IP (단 하나)
온프레미스	기본적으로 바로 사용 가능	MetalLB 같은 별도 솔루션 설치 필요
용도	개발 단계, 테스트용, 인그레스(Ingress) 연결용	실제

Terraform 으로 AWS 연동 후 EKS 띄우고 동작방법

하얀잔디 — Tue, 16 Jun 2026 16:48:50 +0900

## 배경

k3s만 써봤는데 EKS도 한번 해보고 싶어서 시작함.
온프레미스랑 뭐가 다른지 궁금했음.

---

## 사전 준비

- AWS CLI 설치
- Terraform 설치
- kubectl 설치
- IAM Access Key 발급

aws configure 로 자격증명 설정하고 시작.

---

## 구조 이해

EKS는 컨트롤 플레인(API Server, etcd 등)을 AWS가 관리해줌.
k3s는 마스터 노드 직접 관리해야 했는데 그 부분이 없어진 거임.

네트워크 구조는 이렇게 됨:

인터넷
  ↓
Internet Gateway
  ↓
Public 서브넷 (NAT Gateway, LoadBalancer 위치)
  ↓
Private 서브넷 (워커 노드, Pod 위치)

VPC는 AWS 안에 나만 쓰는 사설 네트워크 공간임.
다른 계정이랑 IP 대역 겹쳐도 완전 격리돼서 상관없음.

---

## Terraform 코드

파일 구조:

versions.tf   → provider 버전 고정
variables.tf  → 변수 선언
main.tf       → VPC + EKS 생성
outputs.tf    → 클러스터 정보 출력

커뮤니티 모듈 두 개 사용:
- terraform-aws-modules/vpc/aws
- terraform-aws-modules/eks/aws

모듈 덕분에 IGW, 라우팅 테이블, IAM Role 같은 것들을
하나하나 안 써도 됨. 핵심 설정만 넘겨주면 알아서 만들어줌.

main.tf 핵심 부분:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  cidr            = "10.0.0.0/16"
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true  # 비용 절감
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "my-eks-cluster"
  cluster_version = "1.30"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnets

  cluster_endpoint_public_access           = true
  enable_cluster_creator_admin_permissions = true

  eks_managed_node_groups = {
    default = {
      instance_types = ["t3.medium"]
      desired_size   = 2
    }
  }
}

cluster_endpoint_public_access = true 이거 없으면
로컬에서 kubectl 자체가 안 됨. 꼭 넣어야 함.

---

## 실행

terraform init
terraform plan
terraform apply  # 15~20분 소요

완료되면 kubectl 연결:

aws eks update-kubeconfig --region ap-northeast-2 --name my-eks-cluster
kubectl get nodes

---

## nginx 앱 배포

hellosion.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: hellosion-html
data:
  index.html: |
    <h1>hellosion</h1>

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hellosion
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hellosion
  template:
    metadata:
      labels:
        app: hellosion
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          volumeMounts:
            - name: html
              mountPath: /usr/share/nginx/html
      volumes:
        - name: html
          configMap:
            name: hellosion-html

---
apiVersion: v1
kind: Service
metadata:
  name: hellosion
spec:
  type: LoadBalancer
  selector:
    app: hellosion
  ports:
    - port: 80
      targetPort: 80

kubectl apply -f k8s/hellosion.yaml
kubectl get svc hellosion

EXTERNAL-IP에 AWS가 자동으로 도메인 붙여줌.
거기로 curl 치면 hellosion 출력됨.

k3s 때는 MetalLB 따로 설치해야 했는데
EKS는 type: LoadBalancer 선언만 하면 AWS가 ELB 자동 생성해줌.


## 비용 및 종료

시간당 약 $0.26 발생함. 연습 끝나면 바로 꺼야 함.

# 앱 먼저 삭제 (LoadBalancer 남으면 destroy 실패)
kubectl delete -f k8s/hellosion.yaml

# 인프라 전체 삭제
terraform destroy

# 확인
aws eks list-clusters
aws elbv2 describe-load-balancers \
  --query "LoadBalancers[*].LoadBalancerName" \
  --region ap-northeast-2

모두 빈 배열 나오면 완전히 꺼진 거임.

---

## k3s랑 비교 정리

항목              k3s              EKS
컨트롤 플레인      직접 관리         AWS 관리
kubeconfig        파일 직접 복사    aws eks update-kubeconfig
LoadBalancer      MetalLB 설치 필요  자동 생성
kubectl 사용법     동일              동일

kubectl 명령어는 완전히 동일함.
인프라 세팅 방법만 다른 거임.

Redis 모니터링 해보자

하얀잔디 — Fri, 12 Jun 2026 15:47:04 +0900

Redis-exporter 깔고 prometheus 연결하고 대시보드 976 하면 된다!

다운방법:

https://zandi123.tistory.com/453

redis exporter 다운방법 정리

# 1. /tmp 폴더로 이동해서 안전하게 다운로드 진행cd /tmp# 2. Redis Exporter 최신 안정 버전 다운로드wget https://github.com/oliver006/redis_exporter/releases/download/v1.67.0/redis_exporter-v1.67.0.linux-amd64.tar.gz# 3. 압축 해

zandi123.tistory.com

하나하나 설명하자면 뭐 언제 일어났는지 , 연결된 클라이언트 수 등.. 그런것들임!

매우 쉽고 보기에도 편하니 도입 하면 db 서버 메트릭 원인파악할때 더 좋을것같다.

별로 무겁지도않음 ( Go언어 )

redis exporter 다운방법 정리

하얀잔디 — Wed, 10 Jun 2026 13:42:19 +0900

# 1. /tmp 폴더로 이동해서 안전하게 다운로드 진행
cd /tmp

# 2. Redis Exporter 최신 안정 버전 다운로드
wget https://github.com/oliver006/redis_exporter/releases/download/v1.67.0/redis_exporter-v1.67.0.linux-amd64.tar.gz

# 3. 압축 해제
tar -xvf redis_exporter-v1.67.0.linux-amd64.tar.gz

# 4. 압축 해제된 폴더 안으로 이동
cd redis_exporter-v1.67.0.linux-amd64

# 5. 관리용 실행 파일(바이너리)을 시스템 실행 경로로 이동 (복사)
sudo cp redis_exporter /usr/local/bin/

# 6. 정상적으로 잘 옮겨졌고 실행 가능한지 버전 확인
/usr/local/bin/redis_exporter --version

(마지막 명령어를 쳤을 때 redis_exporter version: v1.67.0 이라고 뜨면 다운로드와 이동은 완벽히 성공입니다.)

2단계: 서비스 관리 파일 생성 (redis_exporter.service)

이제 언제든 올리고 내릴 수 있도록 시스템 서비스 설정 파일을 만듭니다. 비밀번호와 포트 정보를 이 파일에 미리 박아둡니다.

Bash

# systemd 설정 편집기 열기
sudo vi /etc/systemd/system/redis_exporter.service

파일이 열리면 키보드 i를 눌러 입력 모드로 전환한 뒤, 아래 내용을 그대로 복사해서 붙여넣습니다.

[Unit]
Description=Redis Exporter for Prometheus
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/redis_exporter \
  --redis.addr=localhost:6379 \
  --redis.password="비밀번호"
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

붙여넣기가 완료되면 Esc 키를 누르고 :wq를 입력한 뒤 Enter를 눌러 저장하고 빠져나옵니다.

3단계: 시스템 반영 및 최초 프로세스 올리기

설정 파일을 새로 만들었으니 리눅스 엔진에 이를 새로고침 해주고 프로세스를 올립니다.

# 1. 신규 서비스 파일(`redis_exporter.service`)을 시스템에 인식시킴
sudo systemctl daemon-reload

# 2. Redis Exporter 프로세스 올리기 (시작)
sudo systemctl start redis_exporter

# 3. 서버가 재부팅되어도 자동으로 켜지도록 등록
sudo systemctl enable redis_exporter

4단계: 올리고 내리기 & 상태 확인 (실전 관리 명령조)

이제 세팅이 끝났으니 앞으로 관리하실 때는 아래 명령어로 제어하시면 됩니다.

프로세스 내리기 (끄기):
```
sudo systemctl stop redis_exporter
```
프로ces 올리기 (켜기):
```
sudo systemctl start redis_exporter
```
현재 잘 떠있는지 상태 확인:(출력 결과 중에 초록색 불로 active (running) 상태가 보이면 정상적으로 가동 중인 것입니다.)
```
sudo systemctl status redis_exporter
```

Claude Code 개발향상을 위한 쓸만한 플러그인

하얀잔디 — Wed, 10 Jun 2026 11:24:07 +0900

Karpathy Skills & Superpowers (시니어 프로세스 강제 및 고난도 코드리뷰)
- 안드레이 카파시 가이드라인: forrestchang/andrej-karpathy-skills 마켓플레이스 등록 후 andrej-karpathy-skills@karpathy-skills 설치하고 /karpathy-guidelines 실행하면 끝임.
- 클로드가 혼자 뇌피셜로 소설 쓰면서 코드 양산하다가 에러 내는 고질병 싹 고쳐짐.
- 요구사항 모호하면 먼저 질문하게 만들고, 100줄로 끝낼 거 1,000줄로 과도하게 안늘림.
- git 참조 : https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md
- Superpowers 플러그인: obra/superpowers-marketplace 등록 후 superpowers 설치하면 코드리뷰 퀄리티가 좋아짐. 코드 퀄리티나 아키텍처 관점에서 빡세게 가이드라인 잡아줌.
- 다만, 얘네가 TDD 때문에 테스트 코드까지 같이 짜주면서 귀찮게 할 때가 있는데, 그거 무시하고 싶다면 걍 프롬프트나 대화로 "테스트 코드는 작성하지 말고 본문 비즈니스 로직만 깔끔하게 구현해줘"라고 한마디 폰트 하면됨.
- git 참조: https://github.com/obra/superpowers
Understand Anything & Claude Video (대형 프로젝트 아키텍처 파악 및 영상 분석)
- Understand Anything: 레거시 덩어리나 히스토리 파악 안 되는 대형 프로젝트 분석할 때 필수임. Egonex-AI/Understand-Anything 마켓플레이스 등록 후 플러그인 설치하고 /understand 또는 /understand-dashboard 때려 넣으면 복잡하게 꼬여있는 소스코드와 파일 간 아키텍처 관계를 한눈에 대시보드 형태로 싹 다 파악해 줌.
- git 참조 : https://github.com/Egonex-AI/Understand-Anything
- Claude Video: 텍스트 문서나 로그 분석을 넘어 claude-video 플러그인을 활용해 영상 분석 기능까지 세팅해 두면 개발 환경 개꿀임. 에러 재현 화면이나 시스템 동작 인프라 데모 영상 같은 시각적 컨텍스트까지 클로드한테 그대로 주입해서 분석시킬 수 있어서, 텍스트 가이드만 볼 때보다 개발 분석 생산성 및 트러블슈팅 속도가 차원이 다르게 올라감.

andrej-karpathy-skills/README.md at main · multica-ai/andrej-karpathy-skills

A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls. - multica-ai/andrej-karpathy-skills

github.com

Server Transport

하얀잔디 — Fri, 29 May 2026 08:30:07 +0900

Traefik이 백엔드 서버에 연결할 때의 동작 설정임.

IngressRoute가 "어디로 보낼지" 정의한다면, ServersTransport는 어떻게 연결할지를 정의함.

설정 가능한 것들:

TLS 인증서 검증 여부
연결 타임아웃
루트 CA 인증서 지정
Keep-alive 설정 등

EX)

apiVersion: traefik.io/v1alpha1

kind: ServersTransport

metadata:

name: insecure-skip-verify

namespace: seaweedfs-gateway

spec:

insecureSkipVerify: true