<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://kkamji.net/</id><title>KKamJi</title><subtitle>Cloud &amp; DevOps 공부 기록</subtitle> <updated>2026-06-09T22:51:48+09:00</updated> <author> <name>Tae Ji Kim</name> <uri>https://kkamji.net/</uri> </author><link rel="self" type="application/atom+xml" href="https://kkamji.net/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://kkamji.net/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Tae Ji Kim </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>GCP IAM 알아보기 - Principal, Role, Policy, Service Account</title><link href="https://kkamji.net/posts/gcp-iam/" rel="alternate" type="text/html" title="GCP IAM 알아보기 - Principal, Role, Policy, Service Account" /><published>2026-03-03T09:00:00+09:00</published> <updated>2026-03-03T09:00:00+09:00</updated> <id>https://kkamji.net/posts/gcp-iam/</id> <content type="text/html" src="https://kkamji.net/posts/gcp-iam/" /> <author> <name>kkamji</name> </author> <category term="Cloud" /> <category term="GCP" /> <summary>앞선 리소스 계층 글에서 Organization -&amp;gt; Folder -&amp;gt; Project로 이어지는 리소스 계층과, 권한/정책이 위에서 아래로 상속된다는 점을 알아보았습니다. 이번에는 그 권한 체계의 핵심인 GCP IAM(Identity and Access Management)에 대해 알아보겠습니다. GCP IAM은 결국 “누가(Principal) 무엇을(Role) 어디에(Resource) 할 수 있는가” 를 정의하는 체계입니다. 이 세 가지와 그것을 묶는 정책(Policy)의 구조만 이해하면, 콘솔이든 gcloud든 Terraform이든 권한 설정이 한결 수월해집니다. 이번 글에서는 IAM의 핵심 구성요소와 Service Account, 그리고 gcloud로 권한을 부여하는 실습까지 정리합니다...</summary> </entry> <entry><title>GCP 리소스 계층 알아보기 - Organization, Folder, Project</title><link href="https://kkamji.net/posts/gcp-resource-hierarchy/" rel="alternate" type="text/html" title="GCP 리소스 계층 알아보기 - Organization, Folder, Project" /><published>2026-02-24T12:00:00+09:00</published> <updated>2026-02-24T12:00:00+09:00</updated> <id>https://kkamji.net/posts/gcp-resource-hierarchy/</id> <content type="text/html" src="https://kkamji.net/posts/gcp-resource-hierarchy/" /> <author> <name>kkamji</name> </author> <category term="Cloud" /> <category term="GCP" /> <summary>GCP를 처음 공부하기 시작하면서 가장 먼저 마주친 개념이 리소스 계층(Resource Hierarchy)이었습니다. 클라우드 콘솔에 들어가 프로젝트를 만들려는 순간부터 Organization, Folder, Project라는 단어가 등장하는데, 이 구조를 이해하지 못하면 IAM 권한이나 결제(Billing), 조직 정책이 어디에 어떻게 적용되는지 감을 잡기 어렵습니다. GCP에서는 거의 모든 리소스와 권한이 이 계층에 상속(Inheritance) 형태로 붙기 때문에, 이 골격을 먼저 정리하는 것이 GCP 학습의 출발점이라고 생각합니다. 이번 포스트에서는 GCP 리소스 계층의 4단계 구조와 각 단계의 역할, 권한이 상속되는 방식을 정리하고, gcloud로 프로젝트를 다뤄보는 것까지 알아보겠습니다. ...</summary> </entry> <entry><title>GCP (Google Cloud Platform) 이란?</title><link href="https://kkamji.net/posts/what-is-gcp/" rel="alternate" type="text/html" title="GCP (Google Cloud Platform) 이란?" /><published>2026-02-17T09:00:00+09:00</published> <updated>2026-02-17T09:00:00+09:00</updated> <id>https://kkamji.net/posts/what-is-gcp/</id> <content type="text/html" src="https://kkamji.net/posts/what-is-gcp/" /> <author> <name>kkamji</name> </author> <category term="Cloud" /> <category term="GCP" /> <summary>GCP를 처음부터 공부해 보기로 마음먹고 가장 먼저 정리한 것은 “GCP가 도대체 무엇인가”였습니다. 개별 서비스나 명령어를 외우기 전에, 이 플랫폼이 어떤 성격을 가졌고 무엇을 잘하는지 큰 그림을 그려두면 이후 학습이 훨씬 수월하기 때문입니다. 이번 포스트는 GCP 학습 시리즈의 출발점으로, GCP가 무엇이고 어떤 특징이 있으며 어떤 서비스들로 구성되는지, 그리고 GCP를 다루는 방법에는 무엇이 있는지를 개요 수준에서 정리합니다. TL;DR GCP(Google Cloud Platform)는 Google이 제공하는 퍼블릭 클라우드로, Google 서비스가 동작하는 동일한 글로벌 인프라 위에서 실행됩니다. 데이터 분석/AI(BigQuery, Vertex AI)와 Kubernet...</summary> </entry> <entry><title>Amazon CloudFront VPC Origins 알아보기</title><link href="https://kkamji.net/posts/cloudfront-vpc-origins/" rel="alternate" type="text/html" title="Amazon CloudFront VPC Origins 알아보기" /><published>2026-02-04T18:00:00+09:00</published> <updated>2026-02-04T18:00:00+09:00</updated> <id>https://kkamji.net/posts/cloudfront-vpc-origins/</id> <content type="text/html" src="https://kkamji.net/posts/cloudfront-vpc-origins/" /> <author> <name>kkamji</name> </author> <category term="Cloud" /> <category term="AWS" /> <summary>CloudFront를 ALB나 EC2 앞단에 두려고 하면, 정작 오리진(origin)은 퍼블릭 서브넷에 두고 퍼블릭 IP를 부여해야 했습니다. 그러면서도 “CloudFront만 들어오게” 하려고 Security Group에 CloudFront managed prefix list를 걸거나, 커스텀 헤더를 검증하는 등 추가 작업이 필요했고, 결국 오리진이 인터넷에 노출되는 구조 자체는 그대로 남았습니다. Amazon CloudFront VPC Origins는 이 문제를 정면으로 해결합니다. 프라이빗 서브넷에 있는 ALB/NLB/EC2를 CloudFront 오리진으로 직접 연결해, 오리진을 인터넷에 노출하지 않고도 CloudFront를 유일한 진입점으로 만들 수 있습니다. 이번 포스트에서는 VPC Origi...</summary> </entry> <entry><title>EKS kubectl 토큰 캐싱으로 응답 속도 개선하기</title><link href="https://kkamji.net/posts/eks-token-cache/" rel="alternate" type="text/html" title="EKS kubectl 토큰 캐싱으로 응답 속도 개선하기" /><published>2026-01-30T12:00:00+09:00</published> <updated>2026-02-01T00:19:15+09:00</updated> <id>https://kkamji.net/posts/eks-token-cache/</id> <content type="text/html" src="https://kkamji.net/posts/eks-token-cache/" /> <author> <name>kkamji</name> </author> <category term="Kubernetes" /> <summary>On-Premise와 연결된 Kubernetes Cluster를 사용하는 것과 EKS 환경에서 kubectl 명령어를 실행할 때 체감되는 지연 시간에 차이가 있어, aws eks update-kubeconfig로 가져온 클러스터 인증 정보를 통해 kubectl에 EKS Cluster에 접근하는 방법에 대해 알아봤습니다. 해당 지연 문제는 여러 클러스터를 오가며 작업하거나, 스크립트에서 kubectl을 반복 호출할 때 더욱 두드러지게 되며 이로 인해 소중한 시간을 빼앗기게 됩니다. 이번 포스트에서는 이 문제의 원인을 파악하고, 토큰 캐싱 스크립트를 통해 해결하는 방법을 다뤄보겠습니다. 1. 문제 상황 1.1. kubeconfig exec 인증 방식 EKS 클러스터에 접근하기 위해 aws eks ...</summary> </entry> </feed>
