내가 올리고 싶은대로 올리는 개발 블로그

GPU 노드 운영의 기본부터 모델 서빙 아키텍처까지서버가 느려졌다는 연락을 받으면 CPU 사용률, 메모리 사용량, 디스크 사용량 같은 인프라 지표를 확인하는 게 일반적인 운영의 시작이다. 하지만 2026년 현재, 인프라 엔지니어가 마주하는 문제는 조금 달라졌다. GPU 활용도, 모델 서빙 지연 시간, 토큰당 비용 같은 새로운 지표들이 일상적으로 등장한다.생성형 AI가 프로덕션에 진입하면서 인프라 설계의 기본 가정 자체가 바뀌고 있다. GPU는 CPU와 근본적으로 다르고, 모델 서빙은 REST API와 다르며, 토큰 기반 과금은 요청 수 기반 과금과 완전히 다른 경제학을 만든다. 웹 서비스를 운영하던 방식을 그대로 AI에 적용하면 실패한다.이 글에서는 AI 워크로드를 위한 인프라 설계의 기본을 다룬다. G..

장애가 발생했을 때 무엇을 먼저 봐야 할까서버가 느려졌다는 연락을 받으면 많은 사람이 먼저 CPU 사용률, 메모리 사용량, 디스크 사용량 같은 인프라 지표를 확인한다. 물론 틀린 접근은 아니다. 하지만 현대 시스템에서는 인프라가 정상이라도 서비스가 느릴 수 있고, 반대로 인프라 지표는 나쁘지만 사용자는 전혀 문제를 느끼지 못할 수도 있다.이런 환경에서 필요한 것이 관측 가능성이다. 단순히 모니터링 도구를 여러 개 설치하는 것이 아니라, 시스템의 내부 상태를 외부에서 추론할 수 있는 신호를 체계적으로 설계하는 것이다.대표적인 신호는 세 가지다.로그메트릭트레이스이 세 가지를 어떻게 조합하고, 어떤 질문을 위해 어떤 신호를 먼저 볼지 설계하지 않으면 관측 파이프라인은 금방 비용 폭탄과 노이즈의 집합소가 된다...

우리가 보통 GitOps를 접하면 다음과 같이 처음엔 이해한다.Kubernetes YAML 파일을 Git에 저장하고 Argo CD나 Flux로 배포하는 방식완전히 틀린 설명은 아니다.하지만 이 정도로 이해하면 실제 환경에서 곧바로 문제가 생긴다. 애플리케이션 소스 코드는 어디에 저장할 것인가?Docker 이미지가 빌드된 뒤 Git에는 무엇을 변경할 것인가?개발·스테이징·운영 환경은 어떻게 분리할 것인가?운영 환경 배포는 자동으로 할 것인가?Secret은 어느 저장소에 둘 것인가?긴급 변경은 어떻게 처리할 것인가?여러 클러스터를 하나의 구조로 관리할 것인가즉, GitOps의 핵심은 YAML 파일을 Git에 넣는 것 자체가 아니고 운영 환경의 원하는 상태를 어떤 저장소 구조와 변경 절차로 관리할 것인지 설계..

연결을 보는 로드밸런서와 요청을 이해하는 로드밸런서로드밸런서는 여러 서버에 들어오는 트래픽을 분산해 특정 서버에 부하가 몰리지 않도록 하는 장치다.하지만 모든 로드밸런서가 같은 방식으로 동작하는 것은 아니다.대표적으로 L4 로드밸런서와 L7 로드밸런서가 있다.둘 다 트래픽을 여러 서버로 나눈다는 목적은 같지만, 어디까지 트래픽을 이해하고 판단하는가에서 차이가 난다.간단히 말하면 다음과 같다.L4 로드밸런서는 IP와 포트, TCP·UDP 연결 정보를 보고 트래픽을 전달한다.L7 로드밸런서는 HTTP 요청의 URL, Host, Header, Cookie 같은 애플리케이션 내용을 보고 트래픽을 전달한다.L4는 단순하고 범용적인 연결 처리에 적합하고, L7은 웹 요청을 세밀하게 분기하거나 TLS 종료, 보안 정..

CPU, 메모리, 디스크, 네트워크로 원인 좁히기“서버가 느려졌습니다.”인프라 엔지니어라면 한 번쯤 반드시 듣게 되는 말이다. 문제는 이 한마디만으로는 아무것도 알 수 없다는 점이다. SSH 접속이 느린 것인지, 특정 API만 느린 것인지, 서버에서 실행하는 명령어 자체가 느린 것인지에 따라 확인해야 할 지점이 완전히 달라진다.많은 사람이 서버가 느리다는 말을 들으면 바로 top부터 실행하고 CPU 사용률을 확인한다. CPU가 높으면 CPU 문제, 메모리가 높으면 메모리 문제라고 판단하는 식이다. 하지만 실제 장애는 그렇게 단순하지 않다. CPU 사용률은 낮은데 디스크 I/O를 기다리느라 서버가 느릴 수 있고, 메모리가 충분해 보여도 애플리케이션이 파일 디스크립터나 네트워크 연결을 기다리고 있을 수 있다..

리눅스 부팅 과정과 systemd 쉽게 이해하기전원 버튼을 누른 뒤 로그인 화면이 뜰 때까지 무슨 일이 일어날까리눅스를 처음 접하면 서버가 켜지는 장면이 너무 당연하게 느껴진다. 전원을 넣으면 몇 초 뒤 로그인 프롬프트가 뜨고, 서비스를 실행하면 되고, 문제가 생기면 재부팅하면 된다고 생각하기 쉽다. 하지만 운영 관점에서는 이 “몇 초” 동안 무슨 일이 벌어지는지를 모르면 장애 원인을 좁히기가 어렵다. 서버가 아예 안 올라오는 문제, 커널은 떴는데 서비스가 안 뜨는 문제, 특정 장치가 인식되지 않는 문제는 모두 부팅 과정의 서로 다른 단계에서 발생한다.쉽게 말해 리눅스 부팅은 공장 라인이 돌아가는 과정과 비슷하다. 공장을 열기 전에 건물 전기를 켜고, 출입문을 열고, 기계를 점검하고, 작업자를 배치하고,..

쿠버네티스 네트워킹 정리: Service부터 Gateway API까지쿠버네티스 네트워킹은 쿠버네티스를 공부할 때 가장 헷갈리기 쉬운 영역 중 하나입니다. Pod, Service, Ingress, NetworkPolicy, CoreDNS, Gateway API까지 등장하는 개념이 많다 보니, 각각을 따로 외우면 금방 흐름을 놓치게 됩니다. 이 주제는 개별 리소스의 문법이 아니라, 누가 어떤 문제를 해결하기 위해 존재하는가를 축으로 이해해야 합니다. Pod 간 통신, 클러스터 내부 노출, 클러스터 외부 노출, 트래픽 제어, 이름 해석이라는 다섯 가지 문제를 각 기능이 어떻게 나눠서 해결하는지 보면 훨씬 명확해집니다.이 글에서는 Pod 네트워킹의 기본 원리부터 시작해서 Service, Ingress, Netw..

Spring Boot를 쓰다가 FastAPI를 처음 보면 이런 의문이 든다.“@Service도 없고 @Autowired도 없는데, 의존성 주입은 어디서 일어나는 거지?” FastAPI에도 의존성 주입(Dependency Injection, DI)이 있다. 다만 Spring처럼 애플리케이션 전체의 Bean을 관리하는 컨테이너를 중심에 두기보다는, 각 API 요청을 처리하는 과정에서 필요한 값과 공통 로직을 해결하는 구조에 가깝다.FastAPI에서는 Depends()가 이 역할의 출발점이다.이 글에서는 Spring의 DI 흐름을 기준점으로 삼아 FastAPI의 Depends()가 언제 실행되고, 어떤 순서로 의존성을 해결하며, 실무에서는 어디까지 사용하면 좋은지 살펴본다.먼저, Spring의 DISpring..

쿠버네티스 스케줄링 원리에 대해 공부한 내용을 정리했습니다. 들어가며쿠버네티스를 공부할 때 많은 사람이 스케줄링을 단순히 “Pod를 어느 노드에 올릴지 정하는 기능” 정도로 이해합니다. 물론 틀린 말은 아닙니다. 하지만 실무에서는 그 정도 이해로는 금방 한계가 옵니다. 왜 어떤 Pod는 특정 노드에 올라가지 못하는지, 왜 우선순위가 높은 Pod가 먼저 살아남는지, 왜 어떤 요청은 스케줄러까지 가지도 못하고 중간에서 거절되는지 설명할 수 있어야 비로소 운영 관점의 이해라고 할 수 있습니다.냉정하게 말하면, scheduler, taint/toleration, node affinity, PriorityClass, pod admission은 따로 외워서는 안 됩니다. 이 다섯 개는 모두 “Pod가 생성 요청을 ..

로드밸런서에 대한 개념과 구현을 어떻게 하는지 학습한 내용을 정리했습니다.로드밸런서(Load Balancer)?로드밸런서(Load Balancer)는 클라이언트로부터 들어오는 네트워크 트래픽을 여러 백엔드 서버로 분산시키는 장치 또는 소프트웨어다. 교통경찰처럼 수많은 요청(차량)을 각 서버(도로)로 적절히 흘려보내, 특정 서버에 트래픽이 몰려 죽는 일을 방지한다. 현대 서비스에서 고가용성(HA), 수평 확장(Scale-out), 무중단 배포는 로드밸런서 없이는 불가능하다. 핵심 이점은 다음과 같다: 가용성(Availability): 특정 서버 장애 시 나머지 서버로 즉시 트래픽 전환확장성(Scalability): 서버를 추가하는 것만으로 처리 용량 증가보안(Security): DDoS 방어, SSL 터미..