악분의 블로그

Claude Code + Codex로 티스토리 스킨 제작 후기

악분 — Mon, 6 Apr 2026 00:03:58 +0900

claude code, codex를 사용해서 티스토리 스킨을 만들었습니다. 총 6시간정도 걸렸는데 걸린시간에 비해 만족스럽습니다.

티스토리 스킨 코드: https://github.com/choisungwook/portfolio/tree/master/product/tistory-skin/akbun

claude code와 codex두개를 쓴 이유는, 로컬에서 잘 실행되었던 스킨을 티스토리에 적용하니 오류가 나서 서로 컨텍스트를 교환하면서 수정하게 했습니다.

재밌었던 점은 cmux를 사용함으로써 playwright mcp 직접 사용 안했습니다. cmux처럼 웹브라우저가 내장된 터미널이 유행일 수 있겠다 생각했습니다.

UI

homepage의 주요 패널은 4개입니다.

왼쪽 레이아웃: 글 검색, 카테고리, 태그
오른쪽 레이아웃: 최신글(글 제목과 글 생성날짜만 보이게 함)

글의 내용은 크게 5가지입니다. 글의 내용은 3개를 신경썼습니다.
1. 글 내용을 보여주는 가로길이
2. 오른쪽 목차를 보여주는 ToC
3. 헤더 H1의 글씨색깔을 다크레드로 설정

어려웠던 점

티스토리 스킨 개발 가이드

티스토리 스킨 가이드는 공개되어 있습니다. 기준도 명확하고 내용이 길지 않습니다. 하지만, AI agent가 가이드를 보고 많이 헤맸습니다. 그래서 저는 UI에 원하는 부분만 작업할 수 있도록 해당 내용만 마크다운으로 추출했습니다. 이 과정에서 토큰소모를 엄청했습니다.
- https://tistory.github.io/document-tistory-skin/

배포

티스토리 배포는 관리자페이지에서 파일 한개 한개 업로드하는 방법이어서 자동화를 못했습니다.

스킨을 적용할 때 에러가 발생하는데 어떤 에러가 발생하는지 알 수 없습니다. 신기하게 에러가 발생해도 스킨은 적용됩니다.

소켓 누수는 어떻게 시스템 전체를 불안정하게 만드는가?

악분 — Sun, 5 Apr 2026 23:24:47 +0900

공부목표

리눅스에서 소켓 누수 문제에 대해 공부하고 재현합니다.

어떻게 소켓 누수 문제를 확인할 수 있는지?
소켓 누수가 계속 발생하면 어떤 문제가 발생할 수 있는지?

소켓 누수란

소켓 누수는 종료되어야 할 소켓이 닫히지 않고 계속 남아있는 현상입니다. 사용한 소켓을 close하지 않으면 발생합니다.

소켓과 fd의 관계

리눅스는 소켓을 생성할 때 fd(파일 디스크립터)를 할당합니다. 리눅스에서 소켓은 파일로 관리되기 때문입니다.

/proc/{pid}/fd에서 프로세스가 사용 중인 fd를 확인할 수 있습니다. socket 문자열이 보이는 fd가 소켓입니다.

ls -l /proc/{pid}/fd

fd 고갈과 시스템 장애

fd는 무한히 만들 수 없어 소켓 누수가 계속되면 fd 를 고갈시킵니다. 이 영향으로 소켓, 파일 등 입출력 리소스를 생성하지 못하고 Too many open files 에러가 발생합니다.

소켓 누수를 방치하면 벌어지는 일

소켓 누수가 지속되면 fd가 고갈되면서 리눅스에서 실행 중인 모든 프로세스가 영향을 받습니다. 더 나아가서 시스템 전체에 영향을 미쳐 서비스 장애가 발생할 수 있습니다.

예를 들어 Java 프로세스에서는 누수된 소켓을 정리하기 위해 GC(가비지 컬렉터)가 빈번하게 실행됩니다. CPU, 메모리등 시스템 리소스 사용률이 함께 올라갑니다. 리소스 사용률이 100%에 육박하면 서버는 불안정상태가 됩니다.

이 영향으로 서버가 원래 처리해야할 일을 못하고 일들이 남은 서버로 전달되게 됩니다. 남은 서버들이 부하를 견디지 못하면 서비스 장애가 시작됩니다. http프로토콜 관점에서는 남은 서버에서 부하가 발생하면 클라이언트에서 connection timeout이 발생하고 재시도를 실행하는 retry storm 현상이 발생합니다.

테스트

mariadb-java-client 2.7.2에서 SocketException 발생 시 소켓을 close하지 않는 버그를 이용해 소켓 누수를 재현했습니다.

실습자료: https://github.com/choisungwook/portfolio/blob/master/computer_science/leak_linux_socket/docs/hands-on.md

실습 환경

MariaDB 10.11 컨테이너
Spring Boot 2.7.18 앱 컨테이너 (커넥션 풀 없이 Raw JDBC 직접 사용, fd를 64로 제한)
mariadb-java-client 2.7.2 (예외 시 소켓을 닫지 않는 드라이버)
socketTimeout=3000 (3초 제한)

결과

k6로 부하를 발생시키고 Prometheus, Grafana로 모니터링했습니다. 부하가 발생하자 fd 사용률이 거의 100%에 도달했습니다.

Spring Boot 컨테이너를 확인하면 fd가 대량으로 쌓여 있었습니다.

소켓 상태가 전부 ESTABLISHED였습니다. 닫혀야 할 소켓이 닫히지 않고 남아있는 것입니다.

fd가 고갈되면서 Too many open files 에러가 발생했습니다.

Too many open files 에러는 시간이 갈수록 증가했습니다.

JVM에서는 GC 발생 빈도가 증가했습니다. 제가 JVM GC 동작을 잘 모르는데, 누수된 소켓을 정리하기 위해 GC가 계속 실행되는 것 같습니다.

Access Key 없이 IAM user가 AWS CLI 쓰는 방법(aws login)

악분 — Sun, 29 Mar 2026 20:38:14 +0900

해결하려는 문제

AWS는 임시 자격증명(temporary credentials)을 사용하라고 권장합니다. 하지만 로컬에서 개발할 때는 assume 등을 위해 Access Key가 필요했습니다. 그래서 울며 겨자 먹기로 Access Key를 생성하고 주기적으로 철회하는 로직을 관리자는 구현해야 합니다.

이제 이 관리로직을 설정안해도 됩니다! 2025년 11월 AWS에서 IAM user도 임시 자격증명을 발급받는 aws login 기능을 출시했습니다. OAuth 기능을 사용하여 임시 자격증명을 받습니다.

준비

AWS IAM user는 SignInLocalDevelopmentAccess IAM policy를 사용할 수 있어야 합니다.

사용 방법

AWS CLI v2.32.0 이상이 필요합니다.

멀티 계정 프로필

aws login --profile prod-admin
aws login --profile staging-dev
aws s3 ls --profile staging-dev

로그아웃

aws logout은 발급받은 액세스 토큰을 15분 안에 만료시킵니다.

aws logout           # default 프로필
aws logout --all     # 전체 프로필

웹브라우저를 못쓰는 곳이라면?

웹브라우저를 못쓰는 곳이어도 aws login을 쓸 수 있습니다. remote파라미터를 사용하면 웹브라우저를 쓸 수 있는곳에서 접속할 수 있는 URL이 나옵니다.

aws login --remote

기대효과

aws login을 사용하면 관리자는 Access Key 로테이션 등 관리를 안 해도 됩니다. 사용자는 $HOME/.aws/credentials 파일을 더 이상 사용하지 않고 $HOME/.aws/config 파일만 사용하면 됩니다.

[default]
region = ap-northeast-2
output = json

[profile prod-admin]
region = ap-northeast-2
output = json

내부적으로 OAuth 2.0 + PKCE(Proof Key for Code Exchange) 흐름을 사용합니다. OAuth의 동작은 제가 이전에 작성한 블로그를 참고하시면 됩니다.

OAuth 원리: https://malwareanalysis.tistory.com/889

참고자료

aws login 출시: https://aws.amazon.com/ko/about-aws/whats-new/2025/11/console-credentials-aws-cli-sdk-authentication/
aws login 사용방법: https://aws.amazon.com/ko/blogs/security/simplified-developer-access-to-aws-with-aws-login/

custom EKS AMI 만들기 - Managed Node Group과 Karpenter 설정 차이

악분 — Sun, 29 Mar 2026 18:46:46 +0900

해결하려는 문제
AMI를 생성하는 방법
custom AMI로 만든 node가 클러스터에 조인할 수 있을까?
Managed Node Group에서 custom AMI 사용
Karpenter에서 custom AMI 사용
custom AMI를 만들때 주의 사항

해결하려는 문제

EKS node에 모니터링 에이전트, 보안 패키지 등 추가 소프트웨어를 설치해야 하는 경우가 있습니다. 간단한 작업이면 user data로 충분합니다. 하지만 설치할 내용이 많아지면 두 가지 문제가 생깁니다.

user data가 비대해져서 관리가 어려워집니다
node가 부팅될 때마다 패키지를 설치하므로 node 생성 속도가 느려집니다

이 문제를 해결하는 방법이 custom EKS AMI입니다. 필요한 패키지를 미리 설치한 AMI를 만들어 두면, node 생성 시 추가 설치 없이 바로 사용할 수 있습니다.

EKS custom AMI설정 요약

Managed Node Group은 custom AMI 사용 시 user data에 NodeConfig를 직접 설정해야 합니다
Karpenter는 NodeConfig를 자동 생성하므로 별도 설정 없이 AMI ID만 지정하면 됩니다

AMI를 생성하는 방법

AMI를 생성하는 방법은 본인의 환경마다 다릅니다. 보통 Packer만 사용하거나 Packer + Ansible 조합을 사용합니다.

base AMI는 EKS optimized AMI를 사용하는 편이 작업하기 편합니다. EKS optimized AMI에는 nodeadm, kubelet, containerd 등 node가 클러스터에 조인하는 데 필요한 패키지가 설치되어 있습니다. nodeadm은 AL2023 EKS AMI에서 node를 클러스터에 조인시키는 도구입니다. 임의의 AMI를 base로 사용하면 클러스터 조인이 실패합니다.

EKS optimized AMI는 GitHub release에서 찾는 것이 쉽습니다.
- EKS optimized AMI release: https://github.com/awslabs/amazon-eks-ami/releases

이 글의 예제에서는 간단히 Packer와 shell script를 사용했습니다.
- Packer 예제: https://github.com/choisungwook/portfolio/blob/master/aws/eks-custom-ami/packer/eks-custom-ami.pkr.hcl

build {
  name    = "eks-custom-ami"
  sources = ["source.amazon-ebs.eks"]

  provisioner "shell" {
    script = "${path.root}/scripts/setup.sh"
  }
}

... 이하생 략

custom AMI로 만든 node가 클러스터에 조인할 수 있을까?

custom EKS AMI를 만들 때 가장 먼저 드는 고민은 “이 AMI로 만든 node가 EKS 클러스터에 조인할 수 있나?”입니다.

결과만 먼저 말씀드리면 node를 어떻게 생성하느냐에 따라 설정 방법이 다릅니다. EKS node는 Managed Node Group으로 관리되는 EC2와 Karpenter로 생성되는 EC2가 있습니다.

Managed Node Group에서 custom AMI 사용

Managed Node Group로 EKS custom AMI를 사용하면, 사용자가 직접 user data에 NodeConfig를 설정해야 해야합니다. NodeConfig는 nodeadm이 EKS에 조인할 때 사용하는 설정 파일입니다. MIME 타입으로 설정해야 하며, 필수 파라미터가 필요합니다.

name — EKS 클러스터 이름
apiServerEndpoint — EKS 클러스터 API endpoint
certificateAuthority — 클러스터 CA 인증서 (base64)
cidr — 서비스 CIDR

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: <클러스터 이름>
    apiServerEndpoint: <API endpoint>
    certificateAuthority: <CA 인증서>
    cidr: <서비스 CIDR>

--BOUNDARY--

Terraform을 사용한다면 아래 예제처럼 Terraform 리소스를 참조하여 자동화할 수 있습니다.
- Terraform 예제: https://github.com/choisungwook/terraform_practice/pull/117/changes

Karpenter에서 custom AMI 사용

Karpenter에서 custom AMI를 사용하는 방법은 간단합니다. EC2NodeClass에서 AMI ID를 지정하면 됩니다. Managed Node Group과 달리, Karpenter는 NodeConfig를 자동으로 생성합니다. 사용자가 직접 user data에 NodeConfig를 작성할 필요가 없습니다.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: custom-ami
spec:
  amiFamily: AL2023
  amiSelectorTerms:
    - id: "${CUSTOM_AMI_ID}"

custom AMI를 만들때 주의 사항

custom AMI를 만들 때 추가 패키지만 설치하고, EKS 핵심 컴포넌트는 건드리지 않아야 합니다. 이 컴포넌트들은 EKS 버전에 맞게 사전 구성되어 있습니다. 변경하면 node 조인이 실패할 수 있습니다.

nodeadm을 삭제하거나 업데이트하지 않습니다
kubelet, containerd 버전을 변경하지 않습니다
/etc/eks/ 하위 기존 설정 파일을 수정하지 않습니다

cafe24 wordpress를 cloudflare연동할 때 주의할점, ssl 인증서 갱신 오류

악분 — Sat, 28 Mar 2026 22:30:33 +0900

Cafe24에서 구매한 도메인의 NS 레코드를 Cloudflare에 위임하면 Cafe24 SSL 인증서 자동 갱신이 중단됩니다. Cloudflare SSL 모드를 Flexible로 변경하고 WordPress 설정을 수정하여 해결하는 방법을 정리합니다.

만난 오류
오류 원인
오류 해결 방법

만난 오류

Cafe24에서 구매한 도메인을 Cloudflare NS에 등록해서 WordPress 블로그를 운영하고 있었습니다. 잘 되다가 어느 시점 이후부터 Cafe24 SSL 인증서 갱신이 실패하면서 Cloudflare에서 Origin SSL 에러가 발생했습니다.

오류 원인

Cloudflare에 Cafe24 도메인의 NS 레코드 관리를 위임한 것이 원인이었습니다.

Cafe24는 자사에서 구매한 도메인을 Cafe24가 직접 관리해야만 SSL 인증서를 자동 갱신합니다. NS 레코드 관리를 Cloudflare에 위임하면 Cafe24 입장에서는 관리 대상 도메인으로 취급하지 않아 SSL 인증서 갱신을 하지 않습니다.

그래서 인증서 갱신일이 되기 전까지는 WordPress가 정상 접속되었지만, 인증서가 만료되면서 에러가 발생한 것입니다.

오류 해결 방법

Cloudflare에서 Cafe24 WordPress를 호출할 때 HTTP로 변경해야 합니다. Cafe24에서 인증서 갱신을 못하니 어쩔 수 없이 HTTP 통신으로 변경합니다.

WordPress 최초 진입 구간은 Cloudflare이고, Cloudflare가 HTTPS 통신을 하기 때문에 WordPress를 HTTP로 변경해도 보안에 문제될 건 없어 보였습니다. 다만, WordPress는 Cafe24만 접속할 수 있도록 IP 접근 제한을 걸어야 합니다. WordPress 주소에 HTTP로 누구나 접근할 수 있기 때문입니다.

WordPress를 HTTP로 호출하려면 3단계를 설정합니다.

1단계. Cloudflare에서 WordPress 호출을 HTTP로 변경

Cloudflare 메뉴에서 SSL/TLS -> Overview -> Flexible로 변경합니다.

Flexible은 Cloudflare가 원본 서버(WordPress)를 호출할 때 HTTP로 호출하는 모드입니다.

2단계. WordPress의 wp-config.php 설정

WordPress를 HTTP로 설정하면 이미지 등 에셋이 보이지 않게 됩니다. 에셋 URL이 HTTPS 기준으로 되어 있기 때문입니다.

이 문제를 해결하려면 Cloudflare가 HTTP로 호출하더라도 WordPress가 HTTPS로 요청받은 것처럼 동작하게 설정해야 합니다. 그래야 WordPress가 반환하는 에셋 URL이 HTTPS로 응답됩니다.

wp-config.php에서 아래 코드를 추가합니다.

if (isset($_SERVER['HTTP_CF_VISITOR'])) {
  $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
  if ($visitor && $visitor->scheme === 'https') {
    $_SERVER['HTTPS'] = 'on';
  }
}

define('WP_HOME', 'https://{yourdomain}');
define('WP_SITEURL', 'https://{yourdomain}');

만약 이미지 등 에셋이 안 보여도 괜찮다면 아래처럼 설정하면 됩니다.

define('WP_HOME', 'http://{your-domain}');
define('WP_SITEURL', 'http://{your-domain}');

3단계. IP 접근 제한

WordPress는 Cloudflare만 접근하도록 설정합니다. Cafe24 WordPress는 Apache로 호스팅하므로 .htaccess 파일에 Cloudflare IP를 추가하면 됩니다.

<IfModule mod_authz_core.c>
      Require ip 173.245.48.0/20
      Require ip 103.21.244.0/22
      Require ip 103.22.200.0/22
      Require ip 103.31.4.0/22
      Require ip 141.101.64.0/18
      Require ip 108.162.192.0/18
      Require ip 190.93.240.0/20
      Require ip 188.114.96.0/20
      Require ip 197.234.240.0/22
      Require ip 198.41.128.0/17
      Require ip 162.158.0.0/15
      Require ip 104.16.0.0/13
      Require ip 104.24.0.0/14
      Require ip 172.64.0.0/13
      Require ip 131.0.72.0/22
</IfModule>

Cloudflare IP는 아래 페이지에서 확인할 수 있습니다.

https://www.cloudflare.com/ips/

Cloudflare IP 주소는 수시로 변경될 수 있으니 update history를 정기적으로 확인해야 합니다.

회고: Site to Site VPN을 적용하며 배운 것들

악분 — Sun, 22 Mar 2026 22:49:21 +0900

Site to Site VPN을 적용하면서 배운 것들을 회고합니다.

Site to Site VPN을 적용하는 대표적인 2가지 케이스

첫 번째는 법 때문에 VPN 통신을 해야 하는 경우입니다.
법에 VPN 통신이 명시되어 있으면, 원하지 않아도 VPN을 써야만 합니다.

두 번째는 오래된 관례입니다.
다른 팀이나 다른 회사에서 비슷한 상황에 VPN을 사용했다는 관례가 있다 보니, 큰 고민 없이 VPN을 도입하는 케이스가 있습니다 저도 관례상 VPN을 써야 하는 상황이 있었지만, 법적인 검토와 보안팀 검토를 거쳐 VPN을 사용하지 않았습니다.

VPN을 써야 한다면 확인할 것들

1. VPN 물리 장비의 제약사항

클라우드는 Site to Site VPN의 대부분 기능을 지원하므로 고민할 게 적습니다. 하지만 VPN 물리 장비를 사용해야 한다면 장비의 제약이 많습니다.

아래 항목을 반드시 확인해야 합니다.

첫 번째는 Active/Active VPN 터널을 만들 수 있는지입니다.
Active/Standby만 지원하면 VPN 터널이 끊길 때 Standby가 Active로 전활될때까지 통신이 안 됩니다. 모든 이해관계자에게 이 사실을 인지시키고, 사업적 손해가 얼마나 발생하는지 사전에 파악해야 합니다.

두 번째는 ECMP 지원 여부입니다.
Active/Active가 지원되더라도 ECMP가 지원되지 않으면 두 VPN 터널을 균등하게 사용하지 못합니다.

세 번째는 BGP 지원 여부입니다.
VPN 터널에 문제가 생겼을 때 다른 터널로 빠르게 라우팅하려면 BGP가 지원되어야 합니다.

2. VPN 유지보수 작업 시간

물리 장비든 클라우드든 정기적으로 유지보수 작업을 합니다. VPN도 예외가 아닙니다. VPN 유지보수의 영향 범위를 모든 이해관계자가 알아야 하고, 작업 시간도 함께 고민해야 합니다.

보안 관점에서 Site to Site VPN 고민

VPN은 두 네트워크(Site)를 연결하는 것입니다. VPN 목적대로 사용하려면 같은 회사의 네트워크 망을 연결하는 게 이상적입니다.

반대로 말하면, 다른 회사끼리 Site to Site VPN을 연결하는 것은 이상적이지 않습니다. 서로 다른 회사의 네트워크가 연결되기 때문입니다.

그럼에도 불구하고 다른 회사와 Site to Site VPN을 연결해야 한다면, 방화벽과 라우팅을 설정하여 통신 대상만 접근하도록 네트워크를 구성해야 합니다. 이러한 이유로 AWS애서는 VGW가 아닌 TGW를 사용합니다. TGW는 라우팅 설정이 되기 때문입니다. VGW는 라우팅을 설정할 수 없습니다.

또한, Site to Site VPN을 2개 이상 사용하는 경우에는 VGW 대신 TGW를 필수로 사용해야 합니다. VGW를 사용하면, Site 간에 VGW를 통한 네트워크 통신이 가능해집니다. 보안 관점에서 일어나서는 안 되는 일입니다. 반면 TGW는 route table로 VPN이 접근할 수 있는 리소스를 제어할 수 있습니다.

Cache-Control, 브라우저부터 CDN까지

악분 — Sun, 22 Mar 2026 20:27:00 +0900

목차
공부 배경
이 글을 읽고 답할 수 있는 질문
CDN이란?
캐시 수명 주기는 누가 정할까?
캐시 레이어와 304 Not Modified의 정체
Cache-Control 지시어(디렉티브)
- no-cache vs no-store
- public vs private
CDN 캐시에서 헷갈리는 점 정리
실습
결론
참고자료

공부 배경

CDN 설정을 다룰 일이 많이 없었는데, 최근에 CDN 설정에 대해 고민할 것이 있었습니다. 이 기회를 통해 CDN 설정에 대해 공부하게 되었고, 이 글에서는 Cache-Control에 대해 공부한 것을 정리합니다. 메인 주제는 Cache-Control 입니다.

이 글을 읽고 답할 수 있는 질문

Cache-Control은 무엇이고 어떤 곳에 영향을 받고, Cache-Control 설정은 누가 정할까요?
HTTP응답 중 304 Not Modified는 언제, 왜 발생할까요?
HTTP request헤더의 If-None-Match의 의미를 이해합니다.

CDN이란?

CDN(Content Delivery Network)은 전 세계에 분산된 엣지 서버들을 통해 이미지, 영상, HTML 등을 제공하는 서비스입니다. 사용자에게 지리적으로 가까운 서버가 빠르게 응답을 줍니다. 사용자는 DNS 서버 응답을 통해 지리적으로 가까운 엣지 서버를 알 수 있습니다.

엣지 서버는 사용자가 요청한 콘텐츠가 캐시 목록에 있으면 가지고 있는 캐시를 그대로 사용자에게 응답합니다. 캐시가 없다면 오리진 서버에서 콘텐츠를 가져와 캐시를 저장하고 사용자에게 응답을 줍니다.

캐시 수명 주기는 누가 정할까?

캐시의 수명 주기는 max-age라는 HTTP 필드가 정합니다. 그렇다면 max-age 필드는 누가 결정할까요?

바로 오리진 서버가 max-age를 설정합니다. 오리진 서버는 캐시 주기를 HTTP 응답에서 Cache-Control 필드에 담아서 전달합니다.

엣지 서버는 오리진 서버가 전달한 Cache-Control 헤더를 사용하지 않고, 엣지 서버 본인만의 Cache-Control을 사용할 수 있습니다. 엣지 서버가 오리진 서버의 Cache-Control 헤더를 사용하면 존중한다는 의미로 respect라는 단어를 사용합니다.

아래 그림은 AWS CloudFront가 AWS S3 설정의 Cache-Control을 존중한다는 예제입니다.

정리하면, 캐시 수명 주기는 오리진 서버가 정하지만 엣지 서버의 설정에 따라 바뀔 수 있습니다. 이 부분이 실무에서 중요합니다.

이상적인 CDN 또는 캐시 서버는 중간에 한 개만 있으면 좋지만, 캐시 서버가 여러 대 있을 수 있습니다. 의도한 대로 캐시가 동작하지 않으면 중간에 캐시 서버가 Cache-Control을 변경하지 않았나 의심해야 합니다.

캐시 레이어와 304 Not Modified의 정체

지금까지 캐시 수명 주기를 설명할 때 CDN 또는 엣지 서버만 이야기했습니다. 실제 CDN 캐시를 말할 때는 웹 브라우저 캐시도 같이 생각해야 합니다. 웹 브라우저에서 오리진 서버까지 도달하는데 마주치는 캐시들을 캐시 레이어라고 합니다.

웹 브라우저는 사용자 PC의 메모리 또는 디스크를 사용해서 캐시를 합니다. 처음 요청 후 받은 max-age 동안 웹 브라우저는 엣지 서버에 요청을 전송하지 않고 웹 브라우저 내부에서 요청을 처리합니다. max-age가 끝나면 엣지 서버에게 요청합니다.

이 때 HTTP request 헤더에 ETag를 같이 포함해서 전송합니다. ETag는 내가 요청한 콘텐츠의 해시값이라고 생각하면 됩니다.

엣지 서버는 받은 ETag를 보고 요청의 콘텐츠와 엣지 서버의 캐시 데이터가 일치하는지 비교합니다. 만약 같다면 엣지 서버는 콘텐츠를 주지 않고 304 Not Modified 응답을 줍니다. 반대로 ETag와 엣지 서버 캐시 데이터가 다르다면 200 응답을 주고 웹 브라우저가 요청한 콘텐츠를 줍니다. 이 과정을 조건부 요청이라고 합니다.

조건부 요청을 할 때 ETag는 HTTP 헤더의 If-None-Match 필드에 있습니다.

Cache-Control 지시어(디렉티브)

Cache-Control은 캐시 수명 주기 말고도 여러 지시어(디렉티브)가 있습니다.

max-age=N	O	O	모든 캐시에서 N초간 유효
s-maxage=N	X	O	shared cache(공유 캐시, CDN/프록시)에만 적용
public	O	O	모든 캐시가 저장 가능
private	O	X	브라우저만 저장 가능, CDN은 저장 불가
no-cache	O	O	저장하되 사용 전 반드시 재검증
no-store	O	O	어디에도 저장 금지

no-cache vs no-store

많이 사용하는 지시어 중 하나는 no-cache, no-store입니다.

store”는 브라우저 캐시만 의미하는 게 아니라 모든 캐시 레이어에 적용됩니다. 어디에도 저장하지 말라는 뜻입니다. no-cache는 저장해둔 캐시가 있으므로 ETag(리소스의 고유 식별자) 기반 재검증(304 응답)이 가능합니다. no-store는 저장된 게 없으므로 매번 전체 응답을 받아야 합니다.

no-cache: 캐시를 저장은 하지만, 사용할 때마다 오리진 서버에 “이거 아직 유효해?”라고 물어봅니다
no-store: 캐시를 아예 저장하지 않습니다. 매번 오리진 서버에서 새로 받아옵니다

public vs private

다음에 많이 사용하는 Cache-Control 지시어는 public, private입니다. 사용자별 응답(프로필, 장바구니 등)에는 private을 사용해야 합니다. public으로 설정하면 CDN이 사용자 A의 응답을 캐시해서 사용자 B에게 전달하는 보안사고가 발생합니다.

public: 모든 캐시(브라우저, CDN, 프록시)가 저장 가능
private: 브라우저만 저장 가능. CDN이나 프록시 같은 shared cache는 저장하면 안 됨

CDN 캐시에서 헷갈리는 점 정리

CDN Invalidation은 CDN 캐시만 삭제합니다. 브라우저 캐시는 별개의 장소에 있으므로 영향을 받지 않습니다
no-cache는 “캐시하지 마”가 아닙니다. 캐시는 저장하되 매번 재검증하라는 뜻입니다. 캐시를 아예 하지 말라는 것은 no-store입니다
웹 브라우저가 아닌 애플리케이션도 CDN을 사용합니다. 모바일 앱, 서버 간 통신도 CDN을 경유해 요청할 수 있습니다. 차이점은 브라우저 캐시 레이어가 없다는 것입니다. HTTP 클라이언트(requests, axios 등)는 대부분 기본적으로 캐시하지 않으므로, CDN 캐시만 동작합니다

실습

실습자료는 저의 GitHub에 있습니다:

github 주소: https://github.com/choisungwook/portfolio/tree/master/computer_science/cache_control

결론

Cache-Control은 “오리진 서버 → CDN” 정책이 아니라, “오리진 서버 → 모든 캐시 레이어(CDN + 브라우저)” 정책입니다. max-age는 브라우저 캐시에도 적용되고, s-maxage로 CDN만 별도 제어할 수 있습니다. 캐시 정책을 설정할 때는 CDN뿐 아니라 브라우저 캐시까지 고려해야 합니다.

참고자료

MacOS에서 압축해제할때 Inappropriate file type or format오류 해결방법

악분 — Mon, 2 Mar 2026 12:38:27 +0900

현상

맥북 또는 MacOS에서 압축을 해제하면 “Inappropriate file type or format”에러가 발생할 때가 있습니다.

오류가 나는 이유

맥북에서는 Archive Utility라는 도구를 기본 압축프로그램으로 사용합니다. 그런데 Archive Utility는 4GB가 용량이 넘으면 압축해제를 못합니다.

해결방법

다른 압축도구를 설치해서 압축을 해제합니다. 저는 p7zip을 사용했습니다.

(주의: -o뒤에 공백이 있으면안됩니다.)

$ brew install p7zip
$ 7z x {파일이름}.zip -o~/Downloads/ tmp

KMS 봉투암호화 쉽게 이해하기 - data key와 root key의 관계(실습, AWS KMS)

악분 — Mon, 2 Mar 2026 09:26:07 +0900

요약
KMS란
헷갈리면 안되는 점: KMS ARN은 암호화키가 아니다
KMS 원리: HSM
암호화/복호화 원리: 봉투암호화
- KMS에서 관리하는 키는 외부에 공개되지 않는다
AWS KMS 암호화/복호화 실습
부록A: AWS KMS를 오프라인에서 실행하는 방법(generate-data-key API)
부록B: 봉투암호화 시연 웹 페이지
참고자료

이 글은 KMS에서 어떻게 암호화 키를 관리하는지 설명합니다.

요약

KMS(Key Management Service)는 암호화 키를 안전하게 생성, 저장, 관리하는 시스템이다
AWS KMS 콘솔에 보이는 ARN과 key material ID는 암호화키가 아니다
KMS의 핵심 원리는 HSM(하드웨어 보안 모듈)과 봉투암호화이다
봉투암호화는 data key를 root key로 한번 더 암호화하여 키를 보호하는 방식이다

KMS란

KMS(Key Management Service)는 암호화 키를 안전하게 생성, 저장, 관리하는 시스템입니다. AWS에서도 KMS를 제공하고, AWS 이외에 대표적인 KMS 오픈소스는 Hashicorp의 Vault입니다.

KMS가 별도로 필요한 이유는 암호화 키를 소스코드에 보관하면 보안사고가 발생하기 때문입니다. 그렇다고 암호화 키를 암호화해서 소스코드에 보관한다면, 그 암호화키를 또 별도로 보관하는 프로세스가 필요합니다. KMS는 이런 암호화키 관리의 불편한 점을 해결하기 위해 탄생했습니다.

또한, KMS는 암호화 키를 안전하게 관리할 뿐만 아니라 암호화/복호화 기능도 같이 제공합니다.

헷갈리는 점: AWS KMS ARN은 암호화키가 아니다

AWS KMS 콘솔에 가면 KMS ARN과 key material ID가 보입니다. 처음에 헷갈리는 점이 이 두 개의 값이 암호화에 사용되는 값이 아니라는 점입니다.

ARN은 AWS가 인식하는 AWS 리소스 ID입니다. 따라서 데이터 암호화와 관련이 없습니다.

데이터 암호화는 key material이 관여합니다. key material이 여러 개 있을 때 구분하기 위해 ID화 한 게 key material ID입니다. 따라서 KMS ARN과 key material ID는 유출되어도 상관이 없지만, IAM access key와 같이 유출된다면 위험합니다.

KMS 원리: HSM

AWS KMS처럼 키를 관리하는 KMS의 핵심 원리는 HSM(Hardware Security Modules, 하드웨어 보안 모듈)과 봉투암호화에 있습니다.

HSM은 하드웨어 보안 모듈로 KMS의 핵심 기능입니다. HSM은 보안 인증을 받아야 하며, AWS KMS는 FIPS 140-3 보안인증을 받았습니다.

출처: https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html

HSM은 암호화 키 생성, 암호화, 복호화 연산 등 암호의 모든 작업을 수행합니다.

AWS KMS는 IAM policy로 KMS 리소스에 접근 가능한지 확인하고, 암호화/복호화 연산 권한을 검사합니다. 권한 검사가 끝난 후 사용자가 요청한 작업을 수행합니다.

출처: https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html

암호화/복호화 원리: 봉투암호화

KMS에서 핵심 기능 중 하나는 어떻게 암호화키를 보관할 것인가입니다. AWS KMS는 봉투암호화를 사용하여 키를 관리합니다.

봉투암호화는 두 가지 키워드로 나눌 수 있습니다.
1. data key: 데이터 암호화에 사용되는 키
2. root key(또는 wrapper key): data key를 암호화하는 키

정리하면, data key로 데이터를 암호화하고, 그 data key를 root key로 한번 더 암호화하는 방식이 봉투암호화입니다. 마치 편지를 봉투에 넣는 것처럼 키를 한번 더 감싸는 것입니다.

출처: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html

KMS에서 관리하는 키는 외부에 공개되지 않는다

AWS KMS에서 관리되는 root key, data key는 절대 복호화된 상태로 외부에 제공되지 않습니다. 따라서 사용자는 root key, data key의 원본을 볼 수 없습니다. 그저 사용자는 KMS API를 사용해서 암호화/복호화를 요청할 뿐입니다.

반대로 AWS KMS에서 관리하지 않는 key는 외부에 공개될 수 있습니다. AWS KMS는 AWS KMS가 아니라 사용자가 직접 데이터 암호화/복호화할 수 있는 기능을 제공하는데, 이 방법을 사용하면 키들은 사용자가 직접 잘 관리해야 합니다.

AWS KMS 암호화/복호화 실습

실습 github: https://github.com/choisungwook/portfolio/blob/master/computer_science/kms/examples/aws-cli.md

portfolio/computer_science/kms/examples/aws-cli.md at master · choisungwook/portfolio

portfolio. Contribute to choisungwook/portfolio development by creating an account on GitHub.

github.com

부록A: AWS KMS를 오프라인에서 실행하는 방법(generate-data-key API)

대용량 데이터를 암호화/복호화할 때는 네트워크 제약이 있을 수 있습니다. 이런 상황을 위해 AWS KMS는 generate-data-key API를 제공합니다.

generate-data-key API를 사용하면, 사용자는 평문 data key와 암호화된 data key를 얻을 수 있습니다. 이 key를 사용해서 오프라인으로 암호화/복호화를 수행할 수 있습니다. 암호화/복호화는 AWS Encryption SDK를 사용해도 되고, 다른 암호화 알고리즘을 사용해도 됩니다.

출처: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html

generate-data-key를 사용한 순간 key 관리에 대한 책임은 사용자에게 있으니 주의가 필요합니다.

실습 자료는 저의 github에 있습니다.
- 실습 github: https://github.com/choisungwook/portfolio/blob/master/computer_science/kms/examples/aws-cli.md

portfolio/computer_science/kms/examples/aws-cli.md at master · choisungwook/portfolio

portfolio. Contribute to choisungwook/portfolio development by creating an account on GitHub.

github.com

부록B: 봉투암호화 시연 웹 페이지

봉투암호화를 간단히 시연할 수 있는 웹 페이지를 만들었습니다. claude code와 codex가 만들었고, astro 프레임워크를 사용했습니다.

시연 페이지: https://envelopelab.akbun.com/

참고자료

KMS 구조: https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html
AWS KMS overview: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
AWS KMS generate key: https://docs.aws.amazon.com/kms/latest/developerguide/data-keys.html

리눅스에서 tmp 디렉터리가 메모리 사용률을 올리는 이유

악분 — Sun, 1 Mar 2026 22:13:55 +0900

들어가며
요약
tmpfs 파일시스템을 사용하는 /tmp는 메모리를 사용한다
실습
/tmp 디렉터리를 주기적으로 삭제하는 systemd-tmpfiles-clean.timer 데몬

들어가며

이 글은 리눅스 운영체제에서 /tmp 디렉터리가 메모리에 미치는 영향에 대해 설명합니다.

요약

/tmp 디렉터리의 파일시스템이 tmpfs이면, /tmp에 파일을 쓸 때 디스크가 아닌 메모리를 사용한다.
/tmp에 큰 파일을 쓰면 shared memory와 buff/cache가 증가하여 메모리 사용률이 급격히 올라간다.
systemd-tmpfiles-clean.timer 데몬이 /tmp 디렉터리를 주기적으로 정리해준다.

tmpfs 파일시스템을 사용하는 /tmp는 메모리를 사용한다

/tmp 디렉터리의 파일시스템이 tmpfs로 되어 있다면, 메모리 모니터링과 메모리 알람에 대해 신경을 써야 합니다. tmpfs 파일시스템은 작업을 디스크에 하는게 아니라 메모리에 하기 때문입니다.

리눅스의 /tmp 디렉터리는 임시 디렉터리 목적으로 많이 사용합니다. 리눅스 패키지 설치과정에서 필요한 파일을 /tmp 디렉터리에 저장하거나, 임시 파일이 필요한 경우 /tmp 디렉터리를 사용합니다.

만약 /tmp 디렉터리의 파일시스템이 tmpfs라면, /tmp 디렉터리에 큰 파일을 쓰는 경우 메모리 사용률이 올라갑니다. 파일 크기만큼 shared memory가 올라가고, I/O가 발생할 때마다 buff/cache 메모리가 증가합니다.

실습

이 내용이 정말 맞는지 직접 확인했습니다.

실습 github 주소: https://github.com/choisungwook/portfolio/blob/master/computer_science/linux_tmp_memory_monitoring/imgs/manual_test_4.png

실습방법

메모리 2GB를 갖는 ubuntu 컨테이너에서, 256MB씩 파일을 계속 생성했습니다. dd 명령어로 파일을 생성했습니다.

docker exec tmpfs-lab bash -lc 'mkdir -p /tmp/tmpfs-memory-manual'
for i in 1 2 3 4 5 6; do
  docker exec tmpfs-lab bash -lc "dd if=/dev/zero of=/tmp/tmpfs-memory-manual/chunk_${i}.bin bs=1M count=256 conv=fsync status=none"
  docker exec tmpfs-lab free -mh
  docker exec tmpfs-lab grep -E "MemTotal|MemAvailable|Shmem|Cached" /proc/meminfo
  sleep 15
done

모니터링 방법

프로메테우스로 cgroup 메트릭을 수집하여 컨테이너 메모리 사용률을 측정했습니다. 그리고 쉘에서 free 명령어와 /proc/meminfo를 확인했습니다.

$ free -mh
$ grep -E "MemTotal|MemAvailable|Shmem|Cached" /proc/meminfo

실습결과

shared memory가 증가하면서 메모리 사용률, buff/cache도 같이 증가했습니다. 또한, available 메모리도 감소했습니다.

컨테이너 메모리 사용률은 우상향했습니다.

/tmp 디렉터리의 파일을 삭제하면 컨테이너 메모리 사용률이 줄어듭니다.

rm -rf /tmp/*

/tmp 디렉터리를 주기적으로 삭제하는 systemd-tmpfiles-clean.timer 데몬

/tmp 디렉터리에 파일이 계속 남아있으면, 불필요하게 메모리를 많이 사용합니다. 그래서 주기적으로 /tmp 디렉터리를 정리하는 데몬이 있습니다. 데몬 이름은 systemd-tmpfiles-clean.timer입니다.

sudo systemctl status systemd-tmpfiles-clean.timer

데몬 설정은 tmp.conf 파일에 따릅니다. 아래는 AL2023 리눅스의 기본 설정입니다. 이 설정은 /tmp 디렉터리를 10일마다 삭제합니다. 또한, 시스템이 재부팅되면 /tmp 디렉터리 파일을 삭제합니다.

cat /usr/lib/tmpfiles.d/tmp.conf

Claude Code 첫 프로젝트 후기 - SLO 계산기와 배포방법 고민

악분 — Sun, 22 Feb 2026 21:27:51 +0900

들어가며

Claude Code로 코딩을 하나도 하지 않고 간단한 HTML 페이지를 만들었습니다. 정말 드물게 SLO(Service Level Objective) 허용 타임을 확인할 때가 있어서, HTML과 JavaScript 그리고 Claude Code로 SLO 계산기를 만들었습니다.

GitHub PR: https://github.com/choisungwook/portfolio/pull/326
도메인: https://slo.akbun.com/

프로젝트 진행 과정

claude.md 생성
claude.md 파일은 직접 생성하지 않고 Claude Code에게 생성을 부탁했습니다. 원하는 목표만 제시하고 그에 맞는 claude.md 파일을 만들어달라고 했습니다.
HTML 파일 생성
claude.md 파일과 Anthropic의 frontend-design skills를 활용하여 HTML과 SLO를 계산하는 JavaScript를 만들어달라고 했습니다.
디자인 수정
처음에는 디자인이 잘 나오지 않았습니다. 원하는 디자인 스타일을 정확히 몰랐기 때문입니다. 크림배경색을 좋아해서 크림배경색 기준으로 디자인을 부탁했더니 원하는 디자인이 나왔습니다.
도메인 구매
akbun.com 도메인을 구매했습니다. 앞으로 Claude Code로 프로젝트를 많이 만들 것 같아서 AWS Route 53에서 도메인을 구매했습니다. 도메인의 1년 사용료는 $15입니다.
배포
index.html 배포는 AWS S3 웹 호스팅을 사용했습니다. AWS에 친숙했기 때문에 S3를 선택했고, CDN으로 Cloudflare를 사용했습니다. Cloudflare를 사용한 이유는 다음 챕터인 고민했던 내용에서 이야기합니다. AWS S3 배포는 테라폼을 사용했습니다. 향후 AWS S3를 Cloudflare 내부 서비스로 변경할지 고민 중입니다.

[배포 아키텍처]

고민했던 내용

고민했던 내용은 CloudFront를 사용할지입니다. AWS S3로 웹 호스팅을 하고 있고 도메인도 Route 53에서 관리하기 때문에 CloudFront가 가장 이상적입니다. 하지만 Cloudflare로 AWS S3 웹 호스팅을 하려면 Route 53 NS 레코드를 전부 Cloudflare로 이관해야 하고, AWS S3를 public으로 오픈해야 합니다.

그럼에도 불구하고 Cloudflare를 사용한 이유는 보안과 비용입니다. CloudFront 등으로 서비스를 public으로 오픈하면 스캐닝 공격을 포함해서 공격이 엄청 많이 옵니다. 간단한 HTML 페이지여서 공격을 당해도 보안 위험은 없지만, DDoS 공격은 비용 문제가 발생합니다. DDoS 공격을 당하면 요청에 대한 응답을 해야 하기 때문에 CloudFront 비용이 크게 증가합니다. 그래서 AWS WAF를 달아야 하는데 AWS WAF는 무료가 아닙니다.

Cloudflare는 개인 프로젝트에 사용할 충분한 보안 기능을 무료로 제공합니다. 그래서 고민 끝에 DDoS를 방어하기 위해 Cloudflare를 선택했습니다.

Cloudflare가 S3에 접근하려면 AWS S3를 public으로 오픈해야 합니다. 그래서 AWS S3 접근을 Cloudflare만 가능하도록 설정했습니다. 이 접근 규칙은 bucket policy로 설정하는데, Cloudflare IP만 접근하도록 설정하거나 Cloudflare에서 AWS S3를 호출할 때 HTTP 헤더에 나만 아는 secret key를 설정하는 방법이 있습니다.

Cloudflare 설정

Cloudflare에서는 캐시 설정과 HTTPS redirect 설정을 했습니다.

Claude Code 동작 원리 정리 - Harness, Context, Memory까지

악분 — Wed, 18 Feb 2026 23:24:52 +0900

출처: ChatGPT가 만든 썸네일

이 글은 claude code를 몇번 번 사용해 본 유저를 대상으로 작성되었습니다. claude code를 처음 사용하는 사람에게 벅찬 내용일 수 있습니다. 놀랍게도 이 글의 60%이상이 claude code가 작성했습니다.

들어가기 전에

claude code의 내용은 계속 업데이트되니 공식문서를 참조하는게 가장 좋습니다. 이 글은 2026년 2월 기준으로 제 경험을 기준으로 claude code 사용방법이 정리되었습니다.
- 공식문서: https://code.claude.com/docs/en/settings

요약

제 생각엔 Claude Code는 AI 모델을 감싸서 실제로 일할 수 있게 만드는 Agentic Harness입니다
세션마다 고유한 Context를 가지고 있고, Context는 AI 모델에게 보내는 맥락 전체입니다
Context에는 Memory(CLAUDE.md, Auto memory)가 포함되어 있고, Memory는 세션이 바뀌어도 유지됩니다
아쉽게도 이 글에서는 도구(Tools), 샌드박스(Sandbox), 권한(Permission), 확장(MCP, Skills, Hooks)은 다루지 못했습니다. 시간이 된다면 이후에 정리할 예정입니다.

Claude Code는 무엇인가?

본격적으로 Claude Code가 무엇인지 알아봅시다. Claude Code를 이해하려면 세 가지 개념을 알아야 합니다. AI 모델, Harness, AI Agent입니다.

AI 모델: 추론

Claude AI 모델은 LLM(Large Language Model)입니다. LLM은 다음에 올 토큰을 확률적으로 예측해서 가장 높은 확률의 토큰을 선택합니다. 이를 추론이라합니다.

claude code에서는 2026년 2월 기준으로 claude AI모델만 사용할 수 있고, /model 명령어로 AI 모델을 변경할 수 있습니다.

# AI 모델 선택
/model

추론과정에서 토큰(Token)이란 토큰이란 용어가 나옵니다. 토큰은 AI 모델이 텍스트를 처리하는 최소 단위입니다. 헷갈리면 안 되는 점은, 토큰 ≠ 단어입니다. 영어는 대략 1단어 ≈ 1토큰이지만, 한글은 1글자가 여러 토큰으로 쪼개질 수 있습니다.

토큰은 두 종류로 나뉩니다.

Input token	모델이 읽는 모든 것. 사용자 질문, 시스템 프롬프트, 이전 대화 맥락 등
Output token	모델이 생성하는 답변

출처: ChatGPT가 만든 이미지

토큰은 AI 모델의 처리 단위이기 때문에 AI모델 사용량을 측정할 때 사용됩니다. claude code는 /stats 명령어로 사용한 토큰을 확인할 수 있습니다.

# 토큰 사용량 확인
/stats

Harness: AI 모델을 감싸서 일할 수 있게 만드는 시스템

AI 모델은 스스로 파일을 읽거나, 코드를 수정하거나, 명령어를 실행할 수 없습니다. 토큰을 예측해서 텍스트를 생성할 뿐입니다. 따라서, AI 모델을 감싸서 실제로 일할 수 있게 만드는 시스템이 필요합니다. 이 시스템을 Harness라고 부릅니다.

Harness는 원래 “마구”라는 뜻입니다. 말(horse)에 채워서 제어하는 도구입니다. AI에서도 비슷합니다. Harness는 AI 모델(LLM)을 감싸서 도구를 사용하고, 권한을 관리하고, 상태를 유지하는 시스템 전체를 의미합니다. 마치 OS가 시스템을 관리하는 것처럼 Harness는 AI 시스템을 관리합니다.

CLAUDE.md, skills 등이 Harness에 해당합니다.

AI Agent: AI 모델 + Harness

AI Agent는 AI모델을 활용하는 소프트웨어입니다. AI Agent는 AI모델을 사용하여 스스로 판단하고 행동(Act)합니다. 이 때 AI Agent는 AI 시스템을 관리하는 Harness도 활용합니다.

AI 모델	텍스트를 생성. 스스로 행동하지 못함
Harness	도구 실행, 권한 관리, 상태 유지, 컨텍스트 관리
AI Agent	스스로 판단하고 행동함

Claude Code는 Agentic Harness다

그렇다면 Claude Code는 AI 모델, Harness, AI Agent 이 3개 중 어디에 해당할까요? 공식문서를 참조하면, 제 생각엔 Claude Code는 Agentic Harness입니다. Claude AI 모델을 감싸서, 도구 실행/컨텍스트 관리/실행 환경을 제공하는 시스템입니다.

Claude Code serves as the agentic harness around Claude: it provides the tools, context management, and execution environment that turn a language model into a capable coding agent.
출처: https://code.claude.com/docs/en/how-claude-code-works

사용자가 “이 버그를 고쳐줘”라고 하면, Claude AI 모델이 “파일을 읽어야겠다”고 판단하고, Claude Code(Harness)가 실제로 파일을 읽어서 결과를 모델에게 돌려줍니다. 모델이 다시 “이 부분을 수정해야겠다”고 판단하면, Claude Code가 코드를 수정합니다. 이 과정이 반복되면서 버그가 고쳐집니다.

Claude Code는 어떻게 동작하는가? (Agentic Loop)

Claude Code(Harness)는 Agentic Loop라는 반복 작업으로 동작합니다. 세 가지 단계를 반복합니다.

Agentic Loop 설명문서: https://code.claude.com/docs/en/how-claude-code-works

맥락 수집 (Gather Context): 파일을 읽고, 코드를 검색하고, 프로젝트 구조를 파악합니다
행동 (Take Action): 코드를 수정하고, 명령어를 실행합니다
검증 (Verify Results): 테스트를 실행하고, 결과를 확인합니다

출처: https://code.claude.com/docs/en/how-claude-code-works

claude code 동작원리는 Agentic Loop가 핵심입니다. AI 모델이 “다음에 뭘 해야 할지” 판단하면, Claude Code(Harness)가 실제로 도구를 실행하고 결과를 AI 모델에게 전달합니다. 모델은 그 결과를 보고 다음 행동을 결정합니다. 작업이 완료될 때까지 이 과정이 반복됩니다.

사용자인 저희도 이 loop의 일부입니다. 언제든 중간에 개입해서 방향을 바꾸거나, 추가 정보를 제공하거나, 다른 접근 방식을 시도하라고 할 수 있습니다.

Claude Code(Harness)의 구성 요소

Claude Code가 Harness로서 제공하는 기능은 크게 여섯 가지입니다. 이 글에서는 세션과 Context(Memory 포함)만 다룹니다. 나머지는 시간이 된다면 이후에 에서 정리할 예정입니다.

도구 (Tools)	Bash, 파일 읽기/수정, 웹 검색, MCP 서버 등 실제 행동을 실행
권한/안전 (Permission)	도구별 권한 설정, 사용자 승인 게이트
샌드박스 (Sandbox)	도구 실행을 격리된 환경에서 안전하게 수행
세션 (Session)	사용자와의 연결 단위. 세션 저장, 이전 세션 불러오기
Context (Memory 포함)	대화 맥락 유지, CLAUDE.md, Context Window 관리
확장 (Extensibility)	MCP, Skills, Hooks로 기능 확장

세션(Session)

세션이란?

세션(Session)은 Claude Code를 실행한 시점부터 종료할 때까지 유지되는 연결입니다. 사용자는 세션을 통해 claude code에 작업을 요청을 합니다. 터미널에서 claude를 실행하면 새 세션이 시작되고, /exit이나 Ctrl+C로 종료하면 세션이 끝납니다.

웹 브라우저 또는 데스크탑 앱에서는 사용자가 작업을 요청할 때 세션을 생성합니다.

세션이 시작되면,

세션이 생성되면 claude code는 작업을 할 수 있도록 일종의 초기화 작업을 합니다. MCP 불러오기, Skills 불러오기, context 불러오기 등을 수행합니다.

세션은 세션마다 데이터를 가지고 있는 데 이를 context라고 합니다. context는 세션 내에서 메모리에 유지되고, 로컬 파일(JSONL)에 백업됩니다. context에 대한 자세한 내용은 Context 챕터에서 다룹니다.

세션 ID 조회

세션은 세션마다 고유한 ID를 가집니다. /status에서 session ID가 세션ID입니다.

/status

세션의 context는 어디에 저장될까?

세션의 context는 메모리에 유지되고, 로컬 파일(JSONL)에 백업됩니다. 파일은 백업 용도이기 때문에 세션 중에는 사용하지 않습니다. 백업의 의미는 종료된 세션을 다시 불러오기 위한 목적입니다.

파일 저장 경로는 ~/.claude/projects/ 입니다.

~/.claude/projects/{프로젝트경로}/{세션UUID}.jsonl

예를 들어 my-project 디렉토리에서 Claude Code를 실행하면, 세션 파일은 아래 경로에 생성됩니다.

~/.claude/projects/my-project/f41ff972-7bab-4719-8a7a-e564732bdaf0.jsonl

JSONL(JSON Lines)파일은 claude code 세션의 context가 한 줄씩 기록됩니다. 같은 디렉토리에서 claude를 여러 번 실행하면, 그만큼 JSONL 파일이 생깁니다. 예를 들어 제가 claude code에서 세션에 대한 질문을 아래처럼 물어봤습니다.

제가 물어본 내용은 먼저 context에 저장되고, 이후 jsonl파일에 백업됩니다. 참고로 jsonl는 jq명령어로 필터링이 가능합니다.

cat f41ff972-7bab-4719-8a7a-e564732bdaf0.jsonl |  jq -r 'select(.type == "user") | .message.content'

이전 세션 불러오기

세션의 context가 파일에 백업되기 때문에, 세션을 실수로 종료하더라도 다시 이전 세션을 불러올 수 있습니다. 이전 세션을 이어서 하고 싶다면 두 가지 옵션이 있습니다.

–continue: 가장 최근 세션 이어가기

claude –continue는 현재 디렉토리에서 가장 최근에 사용한 세션의 JSONL 파일을 찾아서 대화 맥락을 다시 로드합니다.

claude --continue

가장 최근 세션”은 어떻게 판단할까요? git HEAD 같은 포인터가 있는 것은 아닙니다. JSONL 파일의 수정 시간(mtime)을 기준으로 가장 최근 파일을 선택합니다.

주의할 점이 있습니다. –continue는 현재 디렉토리 기준으로 세션 파일을 찾습니다. 이전에 세션을 실행했던 디렉토리와 다른 디렉토리에서 실행하면 아래와 같은 에러가 발생합니다.

$ claude --continue
No conversation found to continue

–resume: 특정 세션 선택하기

claude –resume은 목록에서 원하는 세션을 선택할 수 있습니다. 세션 ID를 따로 외울 필요 없이, 이 목록에서 골라서 세션을 이어가면 됩니다.

claude --resume

Context

Context란?

AI 모델은 이전 대화를 기억하지 못합니다. 매번 새로운 요청으로 처리합니다. 그래서 Claude Code(Harness)가 매 요청마다 필요한 맥락을 구성해서 AI 모델에게 보냅니다.

Context는 Claude Code(Harness)가 AI 모델에게 요청할 때 함께 보내는 맥락 전체입니다. Harness 챕터에서 설명한 것처럼, context 관리는 Claude code의 핵심 역할 입니다.

Context 종류

대표적인 context의 종류는 아래와 같습니다.

System prompt	Claude Code의 기본 시스템 명령어
System tools	도구 정의 (Read, Edit, Bash 등)
Skills	스킬 메타데이터
Messages	지금까지의 대화 내용 (질문 + 응답 + 도구 결과)
Autocompact buffer	압축한 context

Context Window (크기)

Context Window는 context를 담을 수 있는 최대 크기입니다. Claude 모델의 context window는 200k 토큰입니다.

대화가 쌓이면 context가 커지고, 200k 토큰 한계에 도달하면 관리가 필요합니다. 이 관리 방법은 뒤에서 설명하는 Context 초기화와 Context 압축입니다.

출처: https://platform.claude.com/docs/en/build-with-claude/context-windows

Memory

Context에 로드되는 요소 중에 특별한 것이 있습니다. Memory는 세션이 바뀌어도 유지되는 지시/정보입니다. Context의 다른 내용(대화, 도구 결과)은 세션이 끝나면 사라지지만, Memory는 파일로 영구 저장되어 다음 세션에서도 다시 context에 로드됩니다.

참고자료: https://code.claude.com/docs/en/memory

Claude Code의 Memory는 크게 두 종류입니다.
1. CLAUDE.md 파일: 사용자가 직접 작성하는 지시/규칙
2. Auto memory: Claude가 작업하면서 자동으로 기록하는 학습 내용

CLAUDE.md

CLAUDE.md는 Claude Code에게 주는 지시서입니다. 세션이 시작될 때 자동으로 읽어서 context에 로드합니다. /memory 명령어로 편집할 수 있습니다.

User memory	~/.claude/CLAUDE.md	개인 설정 (모든 프로젝트 공통)	나만 사용
Project memory	./CLAUDE.md	팀 공유 프로젝트 규칙	팀 전체 (git)
Project memory (local)	./CLAUDE.local.md	개인 프로젝트 설정	나만 사용 (자동 gitignore)
Project rules	.claude/rules/*.md	모듈화된 프로젝트 규칙	팀 전체 (git)

Auto Memory

Auto memory는 Claude가 작업하면서 자동으로 기록하는 학습 내용입니다. 프로젝트 패턴, 디버깅 인사이트, 사용자 선호도 등을 자동으로 저장합니다.

Auto Memory는 2026년 2월 기준으로 점진적으로 배포되고 있어서 기본으로 활성화 된 사용자가 있거나 비활성화된 사용자가 있습니다. Auto Memory 활성화 여부는 /memory 명령어로 확인할 수 있습니다.

/memory

Auto Memory를 활성화하려면 환경변수 CLAUDE_CODE_DISABLE_AUTO_MEMORY를 설정하면 됩니다.

CLAUDE_CODE_DISABLE_AUTO_MEMORY=0

저장 위치는 ~/.claude/projects/<project>/memory/ 입니다. MEMORY.md 파일이 인덱스 역할을 하고, 세부 내용은 별도 파일로 관리됩니다.

~/.claude/projects/<project>/memory/
├── MEMORY.md          # 인덱스 (세션 시작 시 처음 200줄 로드)
├── debugging.md       # 디버깅 패턴 메모
├── api-conventions.md # API 설계 결정
└── ...

Context 초기화 (/clear)

/clear는 현재 세션의 context를 초기화하는 명령어입니다. 대화 내용, 읽은 파일 내용 등이 모두 사라지고 세션 시작 상태로 돌아갑니다. Memory(CLAUDE.md, Auto memory)는 파일로 저장되어 있기 때문에 다시 로드됩니다.

/clear

헷갈리면 안 되는 점이 있습니다. /clear는 JSONL 세션 파일을 삭제하지 않습니다. context만 초기화할 뿐, 세션 파일은 그대로 남아 있습니다.

Context 압축 (Compaction)

대화가 길어지면 context가 계속 커집니다. 200k 토큰 한계에 가까워지면 어떻게 될까요? Auto compact 설정이 활성화 되어 있으면 자동 압축을 하고, 비활성화 되어 있으면 Context를 압축하라고 claude code가 사용자에게 알려줍니다.

사용자는 /compact 명령어로 수동으로 context를 압축할 수 있습니다.

/compact

context 압축 이후에는 이전 대화의 세부 내용을 잃어버릴 수 있습니다. 요약은 핵심만 남기기 때문에, “아까 세 번째 파일에서 수정한 부분 다시 보여줘” 같은 세부적인 질문에 답하지 못할 수 있습니다.

참고자료

claude code 작동 방식: https://code.claude.com/docs/en/how-claude-code-works
claude code 설정: https://code.claude.com/docs/en/settings
claude code cli 문서: https://code.claude.com/docs/en/cli-reference
claude code sandbox 릴리즈: https://www.anthropic.com/engineering/claude-code-sandboxing
claude code compaction: https://platform.claude.com/docs/en/build-with-claude/compaction#how-compaction-works
claude code context window: https://platform.claude.com/docs/en/build-with-claude/context-windows

단순한 온프레미스 리다이렉트 서버를, AWS로 옮기는 방법들은 뭐가 있을까?(ALB vs CloudFront)

악분 — Tue, 17 Feb 2026 19:51:33 +0900

이 글은 온프레미스->클라우드 마이그레이션에서 겪을 수 있는 상황을 과제로 재밌게 표현해봤습니다. 이 글에서 나오는 도메인들은 저의 개인 도메인을 사용했고, 상황을 재현하기 위해 사용했습니다.

재현을 위한 테라폼 코드: https://github.com/choisungwook/portfolio/tree/master/aws/redirect_https

과제목표

온프레미스에 있는 서비스를 AWS로 이관하면서 도메인이 변경되었습니다. 하지만, 구 도메인을 사용하는 사용자가 있어 온프레미스에 nginx 리다이렉트 서버를 두고 있습니다. 리다이렉트 서버는 아래처럼 단순히 301 리다이렉트를 합니다.

저희는 이제 Nginx 리다이렉트 서버도 AWS로 옮겨야 합니다.

제약사항

온프레미스 루트도메인과 AWS 루트도메인은 다릅니다. 구 도메인 소유는 온프레미스 DNS 서버에 있습니다.
온프레미스 DNS 변경은 직접 할 수 없고 담당자에게 요청해야 합니다.
서비스 중단 허용 시간은 5분 미만입니다.
리다이렉트 응답은 100ms 안에 받아야 합니다.
한 달 운영비용은 약 $20 정도 사용할 수 있습니다.
리다이렉트 서버는 운영 환경만 있습니다. 개발 환경은 없습니다.

고민사항

제약사항을 보고 사람마다 고민이 다르겠지만, 저는 아래 내용을 고민했습니다.

기술적 고민
1. 온프레미스 DNS 설정을 변경하기 전에 테스트가 가능해야 합니다.
2. 온프레미스 DNS 설정 변경 후 추가 작업이 없어야 합니다. DNS 변경 이후에는 모니터링만 하면 되는 구조여야 합니다.
3. 롤백이 쉬워야 합니다.
4. 운영환경에서 작업할 때 다른 서비스에 영향이 없어야 합니다. 불확실성이 없어야 합니다.

운영 고민
1. 담당자가 바뀌거나 서비스가 다른 팀으로 이관되었을 때 운영하기 쉬워야 합니다.

방법들

1안. ALB redirect

첫번째 방법은 ALB의 리스너 규칙에서 static redirect를 설정하는 방법입니다. 구현 난이도가 낮고 다른 사람이 봐도 이해하기 쉽습니다.

단점은 ALB 사용료가 월 약 $18~22 정도 발생합니다(트래픽/리전에 따라 변동).

2안. CloudFront redirect

2번째 방법은 CloudFront에서 리다이렉트하는 방법입니다. Custom Origin을 사용하거나 CloudFront Function을 사용하여 리다이렉트를 구현할 수 있습니다. 비용은 ALB에 비해 저렴합니다.

1. Custom Origin을 사용한 방법

2. CloudFront Function을 사용한 방법

단점은 ALB에 비해 리다이렉트를 위해 설정이 조금 더 많다는 점이 있습니다.

의사결정 포인트

이 목표 달성을 위해 핵심 의사결정 포인트는 세 개입니다.

1. 온프레미스 DNS 서버에 계속 설정을 할 것인가? 아니면 Route53으로 NS 레코드를 받을 것인가?
온프레미스 DNS 서버에 설정을 한다면 작업 시마다 요청해야 하고, 문제 발생 시 요청밖에 할 수 없습니다. 반면, Route53으로 NS 레코드를 이관받으면 설정도 원할 때 바로 할 수 있고, 문제도 빠르게 확인할 수 있습니다.

2. 서비스 중단이 5분을 넘는 것을 허용할 것인가?
NS 레코드를 이관받는다면, CloudFront 방법은 서비스 중단이 발생할 수밖에 없습니다. CloudFront를 생성하려면 ACM이 필요하고, ACM을 생성하는 데 시간이 몇 분 소요됩니다. 그래서 NS 레코드를 이관받으면 NS 레코드 DNS 전파 시간, ACM 생성 시간, CloudFront 생성 시간, CloudFront 설정 시간이 필요합니다.

3. 비용은 얼마나 사용가능한가?
비용만 보면 CloudFront가 압도적으로 유리합니다. ALB는 유지비용이 있는데 CloudFront는 “Pay-as-you-go”비용을 사용했다면 유지비용이 없고 요청/전송량 기반 비용만 있습니다.

의사결정은 사람마다 어떤 관점을 보냐에 따라다릅니다. DNS 제어권을 직접 하기 위해 NS레코드를 이관받는다면 서비스 중단이 없는 ALB방법를 선택할 수 있습니다. 또한 구현난이도를 쉽게하고 싶다면 ALB방법을 선택할 수 있습니다. 다른 관점에서는 DNS제어권을 직접 안하고 CloudFront를 선택할 수 있습니다.

저는 비용 압박이 없다면 ALB 방법으로 구현하고 NS 레코드를 이관받을 것 같습니다.

내가 사용하는 Ghostty 설정 - 테마, 단축키, 분할화면 (macOS)

악분 — Mon, 16 Feb 2026 14:55:05 +0900

최근 ghostty에서 AI agent를 사용하면 사용 경험이 좋아진다고 들어서 ghostty를 조금씩 사용해 보고 있습니다.

ghostty 장점과 단점

장점

ghostty는 iTerm2보다 cpu,memory를 덜 사용하고 렌더링 속도도 최대 40% 이상 빠르다고 합니다. 그래서 Claude Code처럼 output 결과가 많거나 Claude Code agent를 병렬 실행할 때 ghostty가 iTerm2보다 훨씬 부드럽고 빠르게 느껴집니다.

다르게 말하면, 화면 렌더링이 많이 없거나 병렬 실행이 없다면 굳이 iTerm2을 두고 ghostty를 쓸 이유는 없습니다.

단점

MacOS와 2026년 2월 기준으로, ghostty는 아직 검색 기능(ctrl+f)가 없습니다. 그래서 검색 기능을 많이 사용하시는 분은 ghostty를 추천하지 않습니다.

다행히도 리눅스에서 검색기능이 출시되었고, MacOS도 2026년 상반기에 업데이트 될 것 같습니다.
- 리눅스 ghostty 1.3버전 패치노트: https://github.com/ghostty-org/ghostty/pull/9756

설정파일

MacOS 또는 리눅스를 사용하면 ghostty설정파일은 아래 경로를 사용합니다.

~/.config/ghostty/config

config파일을 재로드하는 방법은 아래와 같습니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

나의 ghostty 설정파일

$ cat ~/.config/ghostty/config
window-theme = dark
theme = dark:Catppuccin Mocha,light:Catppuccin Latte
keybind = super+left=previous_tab
keybind = super+right=next_tab
split-divider-color = #ff6600

$ cat ~/.zshrc
DISABLE_AUTO_TITLE="true"
source $ZSH/oh-my-zsh.sh
precmd() { echo -ne "\033]0;${PWD/#$HOME/~}\007" }
preexec() { echo -ne "\033]0;$1 (${PWD/#$HOME/~})\007" }

단축키 보기

기본 단축키는 ghostty +list-keybinds로 볼 수 있습니다.

ghostty +list-keybinds --default

다크모드

참고자료: https://ghostty.org/docs/config/reference#window-theme

다크모드는 window-theme필드로 설정합니다.

$ vi ~/.config/ghostty/config
window-theme =  dark

config파일을 재로드해야 변경한 window-theme가 적용됩니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

테마 변경

참고자료: https://ghostty.org/docs/features/theme

테마 목록을 먼저 확인합니다.

ghostty +list-themes

그리고 config파일에 고른 theme를 입력합니다. 아래는 dark theme, light theme를 다르게 설정했습니다.

$ vi ~/.config/ghostty/config
theme = dark:Catppuccin Mocha,light:Catppuccin Latte

config파일을 재로드해야 변경한 테마가 적용됩니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

화면 이동

용어정리

Tab(탭): 브라우저 탭처럼 독립된 터미널 화면입니다.

Split(분활화면): 하나의 탭 안에서 화면을 나누어 여러 터미널을 동시에 볼 수 있는 기능입니다.

탭 생성

탭 생성 단축키는 cmd + t 입니다.

탭 이동

탭 이동 단축키는 cmd + 방향키 입니다. 만약 cmd + 방향키로 탭 이동이 안되면 ghostty config에 단축키를 등록하고 설정을 재로드합니다.

$ vi ~/.config/ghostty/config
keybind = super+left=previous_tab
keybind = super+right=next_tab

config파일 재로드 단축키는 아래와 같습니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

탭 삭제

탭 삭제 단축키는 cmd + w 입니다.

탭 이름 변경

탭 이름 변경은 상단에 보여지는 탭 이름을 변경하는 것입니다. 저는 탭 이름에 실행하고 있는 명령어와 현재 경로를 표시하도록 했습니다.

저는 zsh을 사용하고 있어, ghostty 탭 이름을 변경하기 위해 ~/.zshrc파일에 precmd함수와 preexec함수를 정의했습니다.

DISABLE_AUTO_TITLE="true"
source $ZSH/oh-my-zsh.sh
precmd() { echo -ne "\033]0;${PWD/#$HOME/~}\007" }
preexec() { echo -ne "\033]0;$1 (${PWD/#$HOME/~})\007" }

분활화면 생성

분활화면(split) 생성 단축키는 아래와 같습니다.
- 오른쪽 분활: Cmd + D
- 아래쪽 분활: Cmd + Shift + D

만약 단축키가 동작하지 않으면 ghostty config에 단축키를 등록하고 설정을 재로드합니다.

$ vi ~/.config/ghostty/config
keybind = super+d=new_split:right
keybind = super+shift+d=new_split:down

config파일 재로드 단축키는 아래와 같습니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

분활화면 크기 조절

분활화면 크기 조절 단축키는 cmd + ctrl + 방향키 입니다. 만약 cmd + ctrl + 방향키로 크기 조절이 안되면 ghostty config에 단축키를 등록하고 설정을 재로드합니다.

$ vi ~/.config/ghostty/config
keybind = super+ctrl+left=resize_split:left,10
keybind = super+ctrl+right=resize_split:right,10
keybind = super+ctrl+up=resize_split:up,10
keybind = super+ctrl+down=resize_split:down,10

config파일 재로드 단축키는 아래와 같습니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

분활화면 이동

분활화면 이동 단축키는 cmd + option + 방향키 입니다. 만약 cmd + option + 방향키로 분활화면 이동이 안되면 ghostty config에 단축키를 등록하고 설정을 재로드합니다.

$ vi ~/.config/ghostty/config
keybind = super+alt+left=goto_split:left
keybind = super+alt+right=goto_split:right
keybind = super+alt+up=goto_split:top
keybind = super+alt+down=goto_split:bottom

config파일 재로드 단축키는 아래와 같습니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

분활화면 삭제

분활화면 삭제 단축키는 cmd + w 입니다.

분활화면 경계선 색설정

분활화면 경계선 색상은 아래 그림처럼 분활화면 여러개 사용 시 내가 어떤 분활화면을 사용하는지 눈에 띄게 하는 설정입니다.

경계선 색상은 split-divider-color 옵션으로 설정합니다. 설정하지 않으면 터미널 배경색을 기반으로 자동 결정됩니다.

$ vi ~/.config/ghostty/config
split-divider-color = #ff6600

config파일을 재로드해야 변경한 경계선 색이 적용됩니다.
- macOS: Cmd + Shift + ,
- Linux: Ctrl + Shift + ,

참고자료

Claude code에서 Notion MCP 연결하는 방법

악분 — Sun, 15 Feb 2026 16:33:02 +0900

들어가며

Claude Code에서 Notion을 사용하는 방법은 Notion MCP를 사용하는 것입니다. Notion MCP 서버는 OAuth를 지원하기 때문에, Claude Code는 Notion API token없이 인증이 가능합니다.

참고자료: https://developers.notion.com/guides/mcp/mcp

연결방법

1. claude code에서 MCP서버를 추가합니다.

claude mcp add --transport http notion https://mcp.notion.com/mcp

2. MCP 목록에 notion이 있는지 확인합니다. “Needs authentication”은 이 단계에서 무시해도 됩니다.

claude mcp list

3. Claude Code를 실행하고 Notion 인증을 합니다. “/mcp” slash 명령어를 입력한 후 Notion을 선택하면, 웹 브라우저를 통해 인증을 수행합니다.

$ claude
$ /mcp

참고자료

git worktree개념과 사용방법

악분 — Sun, 15 Feb 2026 13:09:59 +0900

git worktree 개념과 사용방법

git worktree를 쉽게 설명하면, git 폴더를 통째로 복사하여 작업 공간을 분리하는 개념입니다. 보통 git 작업공간을 나눌 때 branch로 분리하는데, worktree를 사용하면 작업공간을 폴더로 분리하고 각 폴더 안에서 branch도 분리할 수 있습니다.

git worktree 수도코도는 cp와 유사하게 동작한다고 생각하면 됩니다.

# 비유: 폴더를 복사하고 새 브랜치를 만드는 것과 비슷
cp -r {git 폴더} {새 폴더 위치}   # 단, git worktree명령어는 .git폴더를 다르게 복사함
git branch {새로운 branch}

cp와의 차이점은 git worktree는 소스 파일만 복사하고 .git은 복사하지 않는다는 점입니다(이유는 아래에서 설명). 위 과정을 한 줄로 할 수 있는 명령어가 worktree입니다.

git worktree add -b {new branch} {new path} {fork branch}

아래 예제는 현재 main branch 내용을 “../test”폴더에 복사한 후, feature/test 브랜치를 생성합니다.

git worktree 실행 결과는 아래와 같습니다.

worktree의 목록은 worktree list로 조회할 수 있습니다.

git worktree list

git worktree 특징

worktree의 특징은 원본 “.git”폴더를 같이 사용한다는 점입니다. worktree의 “.git”은 폴더가 아니라 파일로 되어 있고, 파일 내용에는 원본 “.git”의 경로가 적혀 있습니다.

git worktree를 자주 사용하는 곳

모든 worktree가 동일한 “.git”폴더를 사용한다면 왜 굳이 폴더별로 작업공간을 구분했을까요? git 작업상태를 물리적으로 격리하기 위해서라고 생각합니다. 여기서 작업상태란 untracked file, staged area 등을 의미하고 아래 그림처럼 git status에서 확인할 수 있습니다.

폴더로 작업 상태를 물리적으로 격리하는 방법은 branch 관리 방법보다 매우 편합니다. branch로만 관리하면 git stash로 임시 저장하거나 충돌을 수동으로 해결해야 합니다. worktree를 사용하면 작업공간 자체가 분리되어 있으므로 브랜치 전환 없이 여러 작업을 동시에 할 수 있습니다.

Git worktree의 작업 상태 격리 장점 때문에, AI agent가 Git worktree를 사용해서 코드 작성 자동화를 많이 하고 있습니다. Agent가 worktree에서 작업하면 사용자의 메인 작업공간에 영향을 주지 않습니다.

git worktree 자주 사용하는 명령어

worktree 생성

git worktree add -b <new branch> <new path> <fork branch>

worktree 조회

git worktree list

worktree 삭제

# 특정 worktree 삭제
git worktree remove <path>
# 이미 수동으로 폴더를 삭제한 경우, 남은 참조 정리
git worktree prune

카카오 ChatGPT Pro 이용권 사용방법

악분 — Fri, 13 Feb 2026 14:50:48 +0900

배경

2025년 10월쯤에 카카오에서 "ChatGPT for kakao"라는 상품을 출시했습니다.

카카오 ChatGPT Pro 요금제 설명

현재 카카오에서는 “ChatGPT for kakao” Pro 요금제를 29,000원에 판매하고 있습니다. 원래 가격은 290,000원인데 10% 가격으로 팔고 있습니다.

재밌는 건 이 이벤트 이용권이 ChatGPT 요금제와 연동됩니다. 그래서 ChatGPT pro 290,000원짜리 요금제를 29,000원에 한 달 동안 사용할 수 있습니다. 아래 그림은 카카오 이용권 등록 후 ChatGPT에서 확인한 요금제 화면입니다.

(주의: ChatGPT에서 이미 돈을 주고 구독하고 있으면, 연동 과정이 복잡해질 수 있습니다)

개발자는 카카오 chatGPT Pro요금제를 사용하면 좋은점은, 2월에 출시되었던 codex 5.3을 카카오 이용권으로 값싸게 사용할 수 있습니다. codex 5.3은 claude 4.6 Opus 모델과 같이 좋은 평가를 받고 있습니다.

구매방법

카카오톡 선물하기에서 구매할 수 있습니다.

사용방법

1. 카카오 MY구독을 들어갑니다.

URL: https://my.kakao.com

2. 구매 이용권 등록하기를 클릭합니다.

3. ChatGPT Pro 1개월 이용권 번호를 입력합니다. 번호가 올바르면 "이용권을 등록했습니다"라는 문구가 나타납니다. "이용권 사용하기"를 클릭합니다.

4. 약관을 확인하고 "모두 동의하고 사용하기"를 클릭합니다. 나의 무슨 데이터가 kakao에게 제공되는지 약관을 읽어 보는 것을 권장드립니다.

해지방법

전 혹시나 자동결제되는 것을 방지하기 위해, 이용권 등록후에 해지도 추가했습니다.

1. 카카오 MY구독을 들어갑니다. 그리고 ChatGPT Pro 1개월 클릭합니다.

URL: https://my.kakao.com

2. 해지하기를 클릭합니다. “해지 예약”을 클릭해야 기존 이용권을 계속 사용할 수 있습니다.

Claude agent team에게 내 스타일로 글을 쓰도록 하고, notebookLM으로 AWS아키텍처 그려본 과정을 기록

악분 — Sun, 8 Feb 2026 15:19:17 +0900

2026년 2월, Claude Agent Team 기능이 실험 모드로 추가되었습니다. 이 기능은 Claude Agent가 작업을 처리할 때 여러 에이전트로 팀을 구성하고, 에이전트끼리 대화를 주고받으며 작업을 수행합니다.

Agent Team 기능을 보고, 제 글쓰기 스타일로 글을 써 주는 에이전트 팀을 만들어 보면 어떨까 생각했습니다. 제가 작성한 글이 500개 정도 되니, 이를 바탕으로 제 스타일을 표현할 수 있고 이 표현으로 글을 쓸 수 있지 않을까 생각했습니다. 더 나아가 NotebookLM으로 AWS 아키텍처 구성도를 그리는 테스트도 진행해 봤습니다.

Claude Agent Team이 작성한 글은 아래 github PR에서 볼 수 있습니다.

- github PR링크: https://github.com/choisungwook/portfolio/pull/318

아래 그림은 Claude Code가 작성한 글을 바탕으로, notebookLM이 그린 AWS site to site VPN구성도입니다.

notebookLM이 생성한 AWS Site to Site 구성도

워크플로우

Claude skill-creator skills로 내 스타일의 skills 생성
Claude Code로 5개의 agent team을 구성해 글 생성
NotebookLM에 AWS icon pack을 소스로 추가
Claude Code로 AWS 아키텍처 문서를 마크다운으로 생성하고, 이를 NotebookLM에서 시각화 이미지로 변환

준비물

claude max 요금제
내가 작성한 글

1. 내 스타일의 skills생성

제 스타일의 instruction 파일은 skills로 설정했습니다. skills는 agent team의 agent가 모두 참조할 수 있어서 skills가 적합했습니다.

skills 생성을 위해 앤트로픽이 공식적으로 제공하는 skill-create를 사용했습니다. Claude Desktop에서 cowork를 사용해서 skills를 쉽게 생성했습니다.

skills 코드: https://github.com/anthropics/skills/tree/main/skills/skill-creator

2. Claude code agent team으로 글 작성

Claude Code로 5개 agent로 팀을 구성하여 제 스타일로 글을 작성했습니다.

보안 관점에서 리뷰하는 agent
서비스 운영관점에서 리뷰하는 agent
제 스타일로 글을 작성하는 agent
글을 교정하는 agent
SEO, GEO를 검토하는 agent

프롬프트에 명시적으로 agent team을 만드라고 지시했고, Claude Code는 제 의도대로 team을 만들었습니다.

저는 ghostty와 tmux로 Caude Code를 실행했습니다. claude code는 tmux로 여러 agent를 실행했습니다.

agent들이 실행하는 것을 직접 볼 수 있는데, agent끼리 서로 통신하면서 제가 요청한 글을 작성합니다.

약 15분이 지나니 글 작성이 끝났고 agent 또한 종료되었습니다.

3. notebookLM에서 AWS 아키텍처 시각화

notebookLM에서는 Claude Code가 작성한 문서를 기반으로 인포그래픽과 슬라이드로 AWS구조를 시각화 했습니다. notebookLM에는 AWS icon pack을 소스로 추가했습니다.

아래 그림은 notebookLM이 그린 AWS site to site VPN구성도입니다.

notebookLM이 생성한 AWS Site to Site 구성도

터미널에서 마크다운을 예쁘게 보여주는 glow도구

악분 — Sun, 8 Feb 2026 13:16:14 +0900

터미널에서 마크다운 파일을 확인할 때 주로 cat을 사용합니다. 마크다운을 예쁘게 렌더링하거나 more처럼 페이지 단위로 나눠서 읽고 싶다면 cat 대신 glow를 사용하는 것도 나쁘지 않은 것 같습니다.

설치

# MacOS기준
brew install glow

사용 예

# -w는 가로(width)를 자르지 않고 전체 보기
# -p는 more처럼 page단위로 보기
glow [마크다운파일 경로] -w 0 -p

위 똑같은 파일을 cat으로 보면 아래와 같습니다.

glow 설정

glow 전역변수는 glow config로 설정할 수 있습니다. 저는 기본 설정에서 3가지를 수정했습니다.

width: 0 (원본 가로를 자르지 않고 보기)
pager: true (페이지단위로 읽기)
mouse: true (마우스 스크롤 허용)

$ EDITOR=vi glow config
# style name or JSON path (default "auto")
style: "auto"
# mouse support (TUI-mode only)
mouse: true
# use pager to display markdown
pager: true
# word-wrap at width
width: 0
# show all files, including hidden and ignored.
all: false

Gemini의 단점을 보완하는 NotebookLM 기반 지식 베이스 활용 방법

악분 — Sun, 8 Feb 2026 11:03:03 +0900

Gemini가 2025년 12월 이후부터 NotebookLM을 지식 베이스(knowledge base)로 활용할 수 있습니다.

Gemini가 지식 베이스를 사용할 수 있다는 것은, NotebookLM에 등록한 소스를 Gemini가 활용할 수 있다는 뜻입니다. 2026년 2월 기준 Gemini는 ChatGPT나 Claude처럼 프로젝트 기능이 없습니다. 프로젝트의 강력한 기능 중 하나는 AI가 참조할 지식 베이스를 추가할 수 있는데, gemini는 매번 질문할 때마다 문서 등을 업로드했어야 했습니다.

하지만 이제 gemini에 notebooklm을 추가하면 매번 문서 등을 업로드할 필요없습니다.

출처: Gemini 나노바나나가 그린 그림

예를 들어, Kubeflow를 공부할 때 제가 찾은 문서를 NotebookLM에 모두 등록했습니다. 이제 이 자료를 Gemini에서 바로 참조할 수 있습니다.

악분의 블로그

Claude Code + Codex로 티스토리 스킨 제작 후기

UI

어려웠던 점

티스토리 스킨 개발 가이드

배포

소켓 누수는 어떻게 시스템 전체를 불안정하게 만드는가?

공부목표

소켓 누수란

소켓과 fd의 관계

fd 고갈과 시스템 장애

소켓 누수를 방치하면 벌어지는 일

테스트

실습 환경

결과

Access Key 없이 IAM user가 AWS CLI 쓰는 방법(aws login)

해결하려는 문제

준비

사용 방법

로그인

멀티 계정 프로필

로그아웃

웹브라우저를 못쓰는 곳이라면?

기대효과

aws login 원리

참고자료

custom EKS AMI 만들기 - Managed Node Group과 Karpenter 설정 차이

해결하려는 문제

EKS custom AMI설정 요약

AMI를 생성하는 방법

custom AMI로 만든 node가 클러스터에 조인할 수 있을까?

Managed Node Group에서 custom AMI 사용

Karpenter에서 custom AMI 사용

custom AMI를 만들때 주의 사항

cafe24 wordpress를 cloudflare연동할 때 주의할점, ssl 인증서 갱신 오류

만난 오류

오류 원인

오류 해결 방법

1단계. Cloudflare에서 WordPress 호출을 HTTP로 변경

2단계. WordPress의 wp-config.php 설정

3단계. IP 접근 제한

회고: Site to Site VPN을 적용하며 배운 것들

Site to Site VPN을 적용하는 대표적인 2가지 케이스

VPN을 써야 한다면 확인할 것들

1. VPN 물리 장비의 제약사항

2. VPN 유지보수 작업 시간

보안 관점에서 Site to Site VPN 고민

Cache-Control, 브라우저부터 CDN까지

공부 배경

이 글을 읽고 답할 수 있는 질문

CDN이란?

캐시 수명 주기는 누가 정할까?

캐시 레이어와 304 Not Modified의 정체

Cache-Control 지시어(디렉티브)

no-cache vs no-store

public vs private

CDN 캐시에서 헷갈리는 점 정리

실습

결론

참고자료

MacOS에서 압축해제할때 Inappropriate file type or format오류 해결방법

현상

오류가 나는 이유

해결방법

KMS 봉투암호화 쉽게 이해하기 - data key와 root key의 관계(실습, AWS KMS)

요약

KMS란

헷갈리는 점: AWS KMS ARN은 암호화키가 아니다

KMS 원리: HSM

암호화/복호화 원리: 봉투암호화

KMS에서 관리하는 키는 외부에 공개되지 않는다

AWS KMS 암호화/복호화 실습

부록A: AWS KMS를 오프라인에서 실행하는 방법(generate-data-key API)

부록B: 봉투암호화 시연 웹 페이지

참고자료

리눅스에서 tmp 디렉터리가 메모리 사용률을 올리는 이유

들어가며

요약

tmpfs 파일시스템을 사용하는 /tmp는 메모리를 사용한다

실습