SRE 업무에 AI 녹여내기 — 1편: Smart RI Calc로 인프라 비용 산정 자동화

2026년 8월 24일

SRE 업무에 AI 녹여내기 --- 1편: Smart RI Calc로 인프라 비용 산정 자동화

글. 구혜준(Hazel) / SRE팀 이 글은 2부작입니다.

(1/2) AI는 읽고, 코드는 계산합니다 --- Smart RI Calc (현재 글) (2/2) 틀린 걸 없애기보다, 틀린 게 보이게 --- Alert Adviser

안녕하세요, 여기어때컴퍼니 SRE팀에서 클라우드 엔지니어링 업무를 담당하고 있는 헤이즐입니다.

SRE팀은 반복되는 수작업을 줄이고 운영 생산성을 높이기 위해 AI와 코드 자동화를 실무에 다각도로 적용해 보고 있습니다. 이번 글은 그 첫 번째 결과물로, 인프라 비용 산정과 EKS 노드 증설 예측을 자동화한 Smart RI Calc 이야기입니다.

1. 왜 필요했을까?

여기어때컴퍼니에서는 개발팀의 프로젝트 설계가 끝나면 SRE팀 리뷰 와 기술총괄 리뷰, 이렇게 두 차례의 아키텍처 리뷰를 진행합니다. SRE팀은 1차 리뷰 이후 인프라 비용을 산정해 2차 리뷰에서 Tech 리더분들께 보고합니다.

기존 비용 산정 과정은 손이 많이 갔습니다.

**EC2 / RDS / ElastiCache ---**환경별·개수별 단가를 계산하기 위해 매번 RI(Reserved Instance) 엑셀 가격표를 열고 계산기로 직접 합산했습니다.
EKS 노드 증설 예측 --- SSH로 각 환경 서버와 매니지먼트 노드에 접속해 CPU/Memory 잔존량을 조회한 뒤, 새로 추가될 Pod를 손으로 끼워 맞춰가며 예측했습니다.

한 프로젝트당 20분 정도가 소요됐습니다. 그런데 더 큰 문제는 시간이 아니었습니다.같은 프로젝트를 다른 엔지니어가 산정하면 결과가 달라졌습니다.

특히 EKS의 서버 증설을 담당하는 Karpenter는 수식 하나로 스케줄링을 예측하기 어렵습니다. AZ(Availability Zone) 분산과 HA(고가용성) 요소를 엔지니어마다 조금씩 다르게 고려하다 보니, 계산 방식도 산출 결과도 사람마다 달라졌습니다.

Karpenter란?

EKS의 노드 오토스케일러입니다.
자원이 부족해 어떤 노드에도 배치되지 못한 Pod(Pending 상태)가 생기면,
그 Pod가 들어갈 수 있는 인스턴스 타입을 그때그때 골라 노드를 새로 띄웁니다.
노드 그룹을 미리 정의해두는 Cluster Autoscaler와 달리 필요한 스펙을 계산해서 띄우기 때문에,
어떤 노드가 몇 대 뜰지 미리 알기 어렵습니다.

그래서 목표를 두 가지로 잡았습니다.

자동화 --- 반복되는 수작업을 없애 산정 시간 줄이기
일관성 --- 담당자가 누구든 같은 로직으로 같은 결과가 나오게 하기

2. 무엇을 AI에게 맡기지 않을 것인가

AI를 실무에 적용하며 가장 먼저 세운 기준은 코드가 다룰 영역과 AI가 판단할 영역을 나누는 것이었습니다.

"비용 연산이나 노드 증설 예측까지 AI에게 전부 맡겨도 될까?"

결론은 아니다였습니다. 판단과 계산을 통째로 맡기면 중간 연산을 건너뛰거나 존재하지 않는 단가를 만들어냅니다. 오차가 0이어야 하는 영역에서는 AI의 유연함보다 코드의 정밀함이 앞섭니다.

반대로 컨플루언스 회의록에서 리소스 정보를 뽑아내는 일은 LLM이 가장 잘합니다. 팀마다 형식이 제각각이라 정규식이나 파서로는 다룰 수 없는 비정형 텍스트이기 때문입니다.

그래서 '읽는 일은 AI, 계산하는 일은 코드, 검토하는 일은 사람' 으로 경계를 그었습니다**.** Smart RI Calc 서비스 플로우

입력은 두 갈래입니다. 이미 정리된 회의록을 바로 받거나, 개발팀 원본 문서를 AI가 표준 서식으로 정제한 뒤 처리합니다.

AI가 뽑아낸 결과는 곧바로 계산으로 넘어가지 않습니다. 화면에 먼저 표시되고, 사람이 확인하고 고친 뒤에 계산을 시작합니다. AI를 쓰되 마지막 관문은 사람이 쥐는 구조입니다(Human-in-the-loop).

3. 전체 구조

Smart RI Calc 아키텍처 다이어그램

프론트엔드는 조건 입력과 AI 추출 결과 검토·수정 화면을, 백엔드는 Confluence 연동과 가격 매칭, EKS 시뮬레이션을 맡습니다. 외부로는 Confluence, AWS Pricing API, 그리고 CloudWatch Container Insights 기반의 SRE 내부 API와 연결됩니다.

이 중 특히 고민이 많았던 세 가지를 풀어보겠습니다. AI가 회의록을 읽는 방식, 오차 없는 가격 계산, 그리고 Karpenter 예측입니다.

4. AI는 회의록을 어떻게 읽는가

(※ 본문의 모든 화면 스크린샷은 보안을 고려해 임의로 만든 Mock 데이터를 적용했습니다.)

1) 리소스 정보 자동 추출

Confluence Page ID를 넣으면 문서 안의 리소스 스펙과 개수를 뽑아냅니다. 결과는 화면 테이블에서 바로 고칠 수 있고, 타입이나 카테고리를 수정하면 단가를 자동으로 다시 매칭합니다. 컨플루언스 회의록에서 추출된 리소스

2) Multi-step AI 파이프라인 (회의록 정규화)

개발팀 원본 문서를 표준 서식으로 정제할 때는 단일 프롬프트에 모든 역할을 맡기지 않았습니다. 한 프롬프트에 "구조도 파악하고, 정규화도 하고, 검증도 하라"고 시키면 정밀도가 떨어집니다. 그래서 구조 분석 → 정규화 → 자가 검증, 3단계로 쪼개 각 단계를 따로 돌렸습니다. 마지막 자가 검증에서는 "인스턴스 타입이 실제 존재하는가", "CPU가 m 단위인가"를 원본과 교차 대조하게 했습니다.

손으로 정리하면 3분 걸리던 회의록이 이 파이프라인을 거치면 1분 만에 나옵니다. 회의록 변환 탭

3) 리포트 자동 코멘트 게시

최종 리포트는 Publish 한 번으로 Confluence Storage Format으로 바뀌어 해당 회의록 댓글에 올라갑니다. 컨플루언스 comment로 달린 리포트

5. 코드는 무엇을 계산하는가

1) 일반 리소스 (EC2, RDS, ElastiCache)

AWS Pricing API에서 사내 구매 규격(서울 리전, 1년 All Upfront)의 RI 단가를 받아 24시간 주기로 캐싱합니다. 백엔드 코드가 카테고리, 인스턴스 타입, 엔진 기준으로 캐시된 단가를 매칭해 계산합니다. AI는 여기에 개입하지 않습니다. 규칙이 명확하고 정답이 하나뿐인 작업에 추론을 끼워 넣을 이유가 없습니다.

2) EKS 노드 증설 예측 로직

Karpenter는 Pending 상태인 Pod의 자원 요청과 nodeSelector, Affinity, Taints·Tolerations, TopologySpreadConstraints 같은 제약, 그리고 현재 노드 현황을 실시간으로 종합해 노드를 띄웁니다.

그런데 아키텍처 리뷰 시점에 우리가 아는 건 앱별 Pod 개수와 CPU·Memory 요청량뿐입니다. 어떤 제약이 붙을지, 배포 시점에 클러스터가 어떤 상태일지는 아직 정해지지 않았습니다. 스케줄러를 똑같이 구현해도 넣을 값의 절반이 비어 있는 셈입니다.

그래서 목표를 스케줄러 복제가 아니라 배포 전 필요 노드 수 추정으로 잡고, 세 곳에서 규칙을 모았습니다.

Karpenter 공식 문서 --- Best-fit bin-packing, AZ 분산 배치
실제 배치 결과 관찰 --- 문서만으로는 설명되지 않던 동작
사내 인프라 제약 --- A/C 2개 존 구성, RI는 최소 가용분만 구매하는 비용 정책

시뮬레이션은 대상 팀을 입력으로 받아 그 팀 노드의 잔여 자원 스냅샷을 기준으로 돌립니다. 증설여부 판정 결과 상세 판정 표

판정 표에는 어떤 Pod가 어떤 노드에 어떤 순서로 배치되었는지, 어떤 제약이 걸려 증설로 판정되었는지가 그대로 보입니다. 도구가 계산 과정을 감추면 결국 사람이 다시 검산하게 되고, 그러면 자동화의 의미가 사라지기 때문입니다.

6. 예측이 어긋난 네 번

초기 시뮬레이션은 실제 Karpenter의 증설 결과와 자주 어긋났습니다. 원인을 추적하며 로직을 다듬은 사례 네 가지를 공유합니다.

① 과잉 견적 --- RI 확보 기준을 최소 가용분으로

초기 로직은 요청된 Pod 전체 수량이 A존과 C존 양쪽에 모두 배포되는 상황을 다 받아주도록 계산했습니다. 그 결과 실제 필요량보다 노드가 과하게 증설된다는 예측이 나왔습니다. 정확도 문제가 아니라 견적 기준 문제였습니다. RI는 1년 약정 구매라 과잉 견적은 곧 비용 낭비입니다.

그래서 최소 가용분을 기준으로 삼는 보정 수식을 넣었습니다.

targetCount = (replica >= 2) ? Math.ceil(replica / 2) : replica

동일 앱의 Pod가 2개 이상이면 절반(올림)만 기존 노드 여유 자원에 들어가는지 판정합니다. 한 존 전체가 중단되어도 남은 절반으로 서비스가 돌아가기 때문입니다. RI는 1년 선결제라 되돌릴 수 없으므로 여기까지만 미리 확보합니다. 나머지 절반은 기존 노드에 여유가 있으면 그곳에 배치되고, 없으면 On-Demand로 띄웁니다.

② 자원은 남았는데 새 노드가 떴다 --- 과반수 점유 금지

수량 보정을 마쳤는데도 어긋나는 케이스가 남았습니다. 자원 계산이 틀린 게 아니었습니다. 자원 계산상으로는 기존 노드에 충분히 들어가야 할 Pod가 실제로는 신규 노드에 배치됐습니다.

원인을 알 수 없어 Karpenter가 Pod를 배치하는 과정과 결과를 반복해서 지켜봤습니다. 그러다 노드 한 대가 해당 앱 전체 Replica의 50%를 초과하여 받지 않는다는 걸 발견했습니다. 예를 들어 특정 애플리케이션의 Pod가 4개이고 노드가 2대일 때, 한 노드에는 그 앱의 Pod가 2개까지만 들어갔습니다. 자원이 남아 있어도 그 이상은 들어가지 않았습니다.

원인은 Karpenter의 bin-packing 로직이 아니라 워크로드에 걸린 topologySpreadConstraints였습니다. 같은 앱의 Pod를 대상으로 두 존에 배치되는 수 차이를 1개 이내로 유지하는 설정이라, 존이 둘뿐인 환경에서는 한 존이 그 앱 Replica의 절반까지만 받습니다. 노드는 반드시 하나의 존에 속하므로, 존당 노드가 몇 대든 어떤 노드도 그 몫을 넘길 수 없습니다. Karpenter와 kube-scheduler가 둘 다 이 제약을 준수한 결과였습니다.

이 제약을 시뮬레이터에도 반영해, 앱별로 존별 Pod 수를 세어 존 간 차이가 1을 넘지 않도록 했습니다.

같은 맥락에서 Single Node 배치 금지 규칙도 넣었습니다. 동일 앱의 Pod가 2개 이상인데 노드가 1대뿐이면, 자원 여유와 무관하게 2대 이상 확보하도록 강제합니다. 노드가 하나면 Pod가 한 AZ에 몰리고, 그 존이 죽으면 애플리케이션도 함께 죽기 때문입니다.

두 규칙 모두 "자원이 남으면 들어간다"는 가정만으로는 HA 환경의 배치를 예측할 수 없다는 걸 보여줬고, 이 둘을 반영한 뒤부터 예측이 실제 배치와 맞아떨어지기 시작했습니다.

③ 노드 가용량은 100%가 아니다 --- 실가용량 95% 보정

예측상 기존 노드 여유 공간에 들어가야 할 Pod가 실제로는 증설로 이어졌습니다. 노드의 전체 CPU/Mem 스펙을 100% 쓸 수 있다고 계산한 게 원인이었습니다. 실제 Worker Node에는 Kubelet, OS 커널, 각종 DaemonSet이 상주하며 기본 자원을 점유합니다.

기존 노드는 CloudWatch Container Insights를 받아오는 SRE 내부 API의 remainRequest(예약 자원이 이미 차감된 순수 여유 용량)를 쓰고, 신규 노드 계산에는 오버헤드 5%를 가정해 95%만 실가용량으로 산정하도록 보정했습니다.

④ 스냅샷과 현실의 시차 --- 갱신 시각 고정

저활용 노드를 재배치하고 빈 노드를 정리하는 Consolidation이 돌면 노드 잔여 자원 현황이 크게 변합니다. 낮에 수집한 스냅샷과 실제 아침의 노드 현황 사이에 차이가 생기는 문제가 있었습니다.

사내 Consolidation이 매일 새벽 4~6시에 집중 수행되는 것을 확인한 뒤, 노드 스냅샷 갱신 시각을 종료 직후인 아침 7시로 고정했습니다. 하루 중 가장 안정적으로 정리된 상태를 기준으로 시뮬레이션하게 되면서 예측 정확도가 크게 올랐습니다. 조회 시점마다 값이 달라지면 목표로 삼았던 "누구든 같은 결과"가 깨지기 때문에, 낮 시간대 변동을 반영하지 않는 쪽을 택했습니다.

마치며

Smart RI Calc는 현재 SRE팀의 실제 아키텍처 리뷰 과정에 지속적으로 쓰이고 있습니다. 비용 산정 작업 시간은 20분에서 2분으로 90% 줄었고, 담당자가 누구든 같은 로직으로 같은 결과를 냅니다.

돌아보면 이 글에는 AI다운 이야기가 거의 없습니다. 더 좋은 모델을 붙이거나 프롬프트를 정교하게 다듬은 대목이 나오지 않습니다. 지면의 절반이 Karpenter의 배치를 잘못 예측한 기록입니다. 거기에 시간을 가장 많이 썼기 때문입니다.

AI가 회의록을 읽어주는 부분은 생각보다 빨리 완성됐습니다. 오래 걸린 건 코드가 계산해야 할 규칙을 알아내는 일이었습니다. AI가 파싱할 영역, 코드가 연산할 영역, 사람이 검토할 영역을 나누고 나니, 남은 일은 결국 우리가 규칙을 정확히 아는 것이었습니다.

다음 2편에서는 실시간 장애 알림을 AI가 직접 분석해 대응 가이드를 제공하는 Alert Adviser 이야기로 돌아오겠습니다. 긴 글 읽어주셔서 감사합니다.

SRE 업무에 AI 녹여내기 --- 1편: Smart RI Calc로 인프라 비용 산정 자동화 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.