DevOps

eBPF는 "extended Berkeley Packet Filter"의 약자입니다. 공식 사이트 ebpf.io는 eBPF를 다음과 같이 정의합니다. "eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in a privileged

terraform.tfstate 는 Terraform이 관리하는 리소스의 현재 상태를 기록한 JSON 파일입니다. Terraform은 이 파일을 기준으로 실제 인프라와의 차이를 계산합니다. 상태 파일의 구조를 이해하면 왜 이것이 민감한 데이터인지 알 수 있습니다.

GitOps는 인프라와 애플리케이션의 바람직한 상태(desired state)를 Git 저장소에 선언적으로 정의하고, 자동화된 프로세스가 그 상태를 클러스터에 지속적으로 일치시키는 방식을 의미합니다. OpenGitOps에서 정의한 네 가지 원칙은 다음과 같습니다.

Helm을 처음 소개할 때 "Kubernetes의 apt/yum"이라고 부르는 경우가 많습니다. 패키지 설치·업그레이드·제거라는 인터페이스가 apt와 닮아있기 때문입니다. 하지만 이 비유는 Helm의 실제 동작 방식을 숨깁니다. apt는 바이너리 패키지를 배포하고, 패키지 내용은 변경 없이 그대로 설치됩니다.

Dockerfile이 동작한다고 해서 운영에 안전한 이미지는 아닙니다. 빌드 도구, 패키지 매니저, shell, curl, 테스트 파일, 캐시, 심지어 빌드 시 사용한 token이 runtime image에 남는 경우가 많습니다. 이미지는 한 번 registry에 올라가면 여러 환경으로 복제되고, 취약점 스캐너와 감사 대상이 됩니다.

데이터베이스 비밀번호, API token, OAuth client secret, webhook signing key, cloud access key는 모두 서비스의 혈관입니다. 그런데 많은 팀에서 시크릿 관리는 배포 설정의 부속품처럼 다뤄집니다. .env 파일을 만들고, CI 변수에 넣고, Kubernetes Secret으로 배포하면 끝이라고 생각합니다.

Kubernetes를 쓰면 트래픽이 늘어날 때 Pod가 자동으로 늘어나고, 노드가 부족하면 클러스터도 알아서 커질 것처럼 느껴집니다. 실제로 HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler), Cluster Autoscaler, KEDA 같은 도구는 훌륭합니다.

운영 장애를 처음 겪는 팀은 대부분 로그부터 찾습니다. 에러 로그가 있으면 원인이 보일 것이라고 기대합니다. 하지만 실제 장애는 그렇게 친절하지 않습니다. 결제 API의 p95 지연 시간이 300ms에서 3초로 튀었는데 애플리케이션 로그에는 에러가 없습니다.

2024년 말, 필자의 경험으로는 B2B SaaS 플랫폼의 API 레이어 앞단을 대대적으로 정비했습니다. 당시 Rate Limiting 구현체는 Redis를 중앙 카운터 저장소로 쓰는 전형적인 구조였습니다. 애플리케이션이 요청을 받을 때마다 Redis에 INCR 을 치고, TTL을 확인하고, 한도 초과 여부를 판단했습니다.

"프록시"라는 단어는 두 개의 완전히 다른 장치를 가리킵니다. 같은 이름을 쓰지만 트래픽 흐름이 정반대이고, 설정 주체도 다릅니다. 포워드 프록시(Forward Proxy) 는 클라이언트 측 대리인입니다. 기업 내부망에서 외부 인터넷으로 나가는 요청을 대신 처리합니다.

리버스 프록시 도구를 처음 고를 때 가장 많이 듣는 말은 "그냥 Nginx 쓰면 되잖아요"입니다. 틀린 말은 아닙니다. 하지만 팀의 규모, 트래픽 패턴, 인프라 환경에 따라 최선의 선택이 달라집니다. 2026년 현재 주요 4개 도구의 포지셔닝은 다음과 같습니다.

GitHub Actions의 구조를 이해하는 것은 레고 블록을 조립하는 것과 같습니다. 네 가지 핵심 개념의 계층 구조를 이해해야 합니다. 1. Workflow (워크플로우) : 전체 자동화 프로세스의 최상위 개념입니다. .github/workflows/main.yml 처럼 YAML 파일로 정의되며, "언제 이 파이프라인이 실행될 것인가(Event)"를 결

1.1 Git Flow vs GitHub Flow Git Flow는 Vincent Driessen이 제안한 전통적인 브랜치 전략입니다. main(또는 master), develop, feature, release, hotfix 브랜치를 사용하여 체계적인 릴리스 관리를 합니다.

서비스 장애가 발생하면 팀은 복구에 집중합니다. 알림이 울리고, 대시보드를 열고, 로그를 뒤지고, 임시 조치를 적용합니다. 하지만 진짜 중요한 일은 장애가 끝난 뒤 시작됩니다. 왜 같은 종류의 장애가 다시 발생하는지, 왜 알림은 많았는데 원인 파악은 늦었는지, 왜 대응자가 매번 같은 명령을 검색해야 했는지 돌아봐야 합니다.

장애가 나면 가장 먼저 로그를 봅니다. 하지만 많은 서비스의 로그는 정작 장애 순간에 도움이 되지 않습니다. "error occurred" 같은 메시지만 남아 있고, 어떤 사용자 요청인지, 어떤 주문인지, 어떤 외부 API 호출과 연결되는지 알 수 없습니다.