"비용적으로 특이한 사항 없습니다"라고 말하기까지 걸리는 것들

들어가며

안녕하세요, 노머스에서 인프라를 담당하고 있는 박지영입니다.

저는 매주 클라우드 비용을 집계하여 공유합니다.
그리고 공유의 끝에는 늘 약속된 질문이 하나 돌아옵니다.

“이번 주에 비용적으로 특이한 사항이 있을까요?”

사실 대답은 대부분 비슷합니다.

“특이 사항 없습니다.”

하지만 이 짧은 한마디를 내뱉기 위해 인프라 담당자는 생각보다 많은 증거를 수집해야 합니다.
‘특이함’ 이 없다고 하려면 무엇이 ‘평이함’ 인지를 정의해야 하기 때문입니다.

FinOps Foundation의 “Understand Usage & Cost”에 따르면,
비용 가시성 확보에는 명확한 순서가 있습니다.

1. Data Ingestion: 클라우드 제공자로부터 사용 데이터를 수집하고 정규화하며
2. Allocation: 수집된 비용을 서비스와 팀에 맞게 할당하고
3. Reporting & Analysis: 일관된 기준으로 보고하며
4. Anomaly Management: 이상 징후를 감지하는 것

앞 단계가 단단하게 받쳐주어야 다음 단계로 나아갈 수 있는 구조입니다.

저 역시 이 로드맵을 따라가며 많은 고민을 거쳤고,
그 과정에서 겪은 시행착오와 인사이트를 가장 복잡했던 AWS를 중심으로 풀어보려 합니다.

자동화할 수 없는 것들

저희는 AWS를 MSP(Managed Service Provider)를 통해 이용하고 있습니다.
따라서 비용 데이터의 1차 출처는 AWS Cost Explorer가 아닌, MSP에서 제공하는 별도의 콘솔입니다.

해당 콘솔에서는 비용 명세를 CSV로 내려받을 수 있고,
청구서가 확정되는 시점에는 적용 환율이 포함된 PDF 명세서도 함께 제공됩니다.

이 데이터를 가져오는 것 자체는 어렵지 않았습니다.
문제는 그 다음이었습니다.

다운로드한 파일을 가공하는 모든 과정을
매주 혼자 처리해야 한다는 것이 점점 큰 부담으로 느껴졌습니다.

자동화를 검토했지만, MSP 측으로부터 “공개 API를 제공하지 않으며, 정확한 계획이 없다”는 답변을 받았습니다.

수기 다운로드는 피할 수 없으니,
다운로드 이후의 가공과 집계 과정만이라도 코드로 자동화하는 방향을 택했습니다.

팀이 읽을 수 있는 코드

저는 쉘이 편합니다. 인프라 담당자로서 자연스럽게 손에 익은 언어이기도 합니다.
그래서 처음에는 쉘 스크립트로 짰습니다.

계속해서 스크립트는 커졌고, 어느새 9,000줄이 넘어갔습니다.
실행 시간도 길었고, 월말이 되면 중간에 멈추는 일도 잦았습니다.

그리고 다른 문제도 보였습니다.

저는 백엔드 팀에 소속된 인프라 담당자입니다.
제가 만든 코드는 언젠가 다른 동료가 유지보수해야 할 수도 있는데,
이대로라면 갈라파고스가 되겠다 싶었습니다.

팀은 TypeScript를 씁니다.
그렇다면 선택지는 하나였습니다.

문제는 제가 쓸 줄 모른다는 것이었습니다.
읽으면 맥락은 파악할 수 있지만, 직접 작성하는 건 다른 이야기였습니다.

그래서 코드 작성은 Claude에게 맡기기로 했습니다.
방향을 잡고 지시하는 건 제가, 코드를 쓰는 건 Claude가 담당하는 방식으로 협업했습니다.

보고서가 원하는 숫자

AWS 비용 데이터는 기본적으로 달러($) 기준이지만,
실제 사내 보고와 비용 정산은 원화(₩)로 이루어집니다.

따라서 환율 변환이 필수적인데, 여기서 생각보다 까다로운 문제가 있었습니다.

바로 MSP가 매월 청구서를 발행할 때 적용하는 확정 환율입니다.

MSP는 청구서를 발행하는 시점의 환율을 확정해서 적용하는데, 이 확정 환율은 청구서가 나오기 전까지는 알 수 없습니다.

그런데 저는 매주 비용을 집계해야 했습니다.
환율 처리를 제대로 하지 못하면, 마지막 주 보고 금액과 실제 청구 금액 사이에 큰 오차가 생겼습니다.

그래서 이를 해결하기 위해,
저는 시점에 따라 환율 소스를 이원화하는 방식을 택했습니다.

청구가 확정된 달이면 PDF 명세서에서 환율을 파싱합니다.

const match = result.text.match(/적용 환율\s*:\s*([\d.]+)/);
if (!match) throw new Error('PDF에서 환율을 찾을 수 없습니다.');
return Number(match[1]);

확정 전이라면 ExchangeRate API를 사용합니다.

const res = await fetch('https://api.exchangerate-api.com/v4/latest/USD');
const data = await res.json() as { rates: { KRW: number } };
return data.rates.KRW;

환율을 보고에 포함해 추적하게 되면서,
달러 기준으로는 변화가 없는데 원화로는 크게 차이 나 보이는 상황도 수치로 설명할 수 있게 되었습니다.

생각보다 지저분한 데이터

데이터 자체에도 문제가 있었습니다.

첫 번째로 인코딩 문제를 발견했습니다.

MSP의 CSV는 EUC-KR로 인코딩되어 있었습니다.
그대로 처리하려고 하면 한글이 깨져서, UTF-8로 변환해야 했습니다.

const buffer = Buffer.from(await res.arrayBuffer());
const utf8 = iconv.decode(buffer, 'EUC-KR');
fs.writeFileSync(filePath, utf8, 'utf8');

두 번째로 월 단위 과금 데이터가 왜곡을 만들었습니다.

월 단위로 과금되는 항목은 월초에 해당 월 전체 날짜에 금액이 미리 분산되어 찍힙니다.

월 중간에 집계하면 아직 지나지 않은 날짜의 데이터까지 합산되거나,
반대로 아직 찍히지 않은 항목이 빠져 비이상적인 수치가 나왔습니다.

그래서 모든 데이터는 오늘 기준 이틀 전까지만 포함하고,
월말이 지나면 해당 월 전체를 쓰도록 처리했습니다.

const cutoff = monthEnd < todayMinus2Str ? monthEnd : todayMinus2Str;

세 번째로 노이즈가 많았습니다.

처리 시간이 예상보다 오래 걸려 원인을 파악하던 중,
전체 데이터의 약 40%가 $0 행이라는 사실을 알게 되었습니다.

애초에 AWS CUR 데이터는 추정치이기 때문에 완벽한 정확도를 기대하기 어렵습니다.

정확한 수치보다 추이를 파악하는 것이 목적이었기에,
$0 행은 과감히 노이즈로 판단하고 제외했습니다.

if (isNaN(usd) || usd <= 0) continue;

보이는데 모르겠다

정규화가 끝나면 데이터는 다음과 같은 모습입니다.

…	ResourceId	ProductName	…	금액(USD)
…	arn:aws:ec2:…/natgateway/nat-021bcd03d05c7abed	Amazon Elastic Compute Cloud	…	0.248
…	i-0f59d872251530953	Amazon Elastic Compute Cloud	…	0.1073
…	arn:aws:rds:…/db:dev-writer	Amazon Relational Database Service	…	0.339

보시는 것처럼 ResourceId 컬럼에는 한눈에 파악하기 어려운 식별자들만 가득합니다.
이대로 공유하면 “이 EC2 인스턴스가 어떤 서비스용인가요?”라는 질문이 쏟아질 수밖에 없습니다.

근본적인 해결책은 모든 리소스에 엄격한 태깅 규칙을 적용하는 것입니다.

하지만 전사적인 네이밍 컨벤션을 새로 정립하고,
테라폼 코드를 수정해 전체 리소스를 재배포해야 했습니다.

당장 실행하기엔 리스크와 공수가 너무 큰 일이었습니다.

그래서 현재 달려 있는 태그 값이라도 최대한 활용하는 방향으로 접근했습니다.
AWS API를 직접 조회해 Name 태그를 가져온 뒤,
ResourceId와 매칭해 사람이 읽기 쉬운 이름으로 치환했습니다.

또한 API 호출 부하를 줄이기 위해 배치 방식을 적용했습니다.

CSV 전체를 먼저 스캔해 필요한 ID 목록을 추출하고,
리전별로 분류한 뒤 리전당 한 번씩만 조회했습니다.

for (const row of rows) {
  const name = extractResourceName(row.resourceId);
  const region = getArnRegion(row.resourceId) ?? PREFIX_TO_REGION[usageTypePrefix] ?? 'ap-northeast-2';
  if (/^i-[0-9a-f]+$/.test(name))        regionInstanceMap.get(region)?.add(name);
  else if (/^nat-[0-9a-f]+$/.test(name)) regionNatMap.get(region)?.add(name);
  else if (/^vol-[0-9a-f]+$/.test(name)) regionVolumeMap.get(region)?.add(name);
}

for (const [region, ids] of regionInstanceMap) {
  const res = await ec2.send(new DescribeInstancesCommand({
    Filters: [{ Name: 'instance-id', Values: [...ids] }],
  }));
  for (const instance of res.Reservations?.flatMap(r => r.Instances ?? []) ?? []) {
    const name = instance.Tags?.find(t => t.Key === 'Name')?.Value;
    if (instance.InstanceId && name) nameMap.set(instance.InstanceId, name);
  }
}

EBS 볼륨은 볼륨 자체에 Name 태그가 없는 경우가 많았습니다.
볼륨에 붙어있는 EC2 인스턴스를 한 번 더 조회해서 인스턴스 이름을 대신 사용했습니다.

for (const vol of res.Volumes ?? []) {
  const instanceId = vol.Attachments?.[0]?.InstanceId;
  if (vol.VolumeId && instanceId) volumeToInstance.set(vol.VolumeId, instanceId);
}
if (name) nameMap.set(volId, `${name} (volume)`);

리소스 거버넌스가 잘 잡혀있다면 이 과정이 필요 없겠지만,
태그가 없거나 제각각인 환경에서는 이 방식이 현실적인 대안이었습니다.

우리가 원하는 대로

MSP 콘솔에서도 서비스별 비용은 확인할 수 있었습니다.
하지만 저는 그 데이터를 우리 보고 방식에 맞게 다시 가공해야 했습니다.

AWS 서비스 → SKU(usageType) → 리소스 순으로 계층을 잡아 합산하고,
금액 기준으로 내림차순 정렬해 한눈에 파악할 수 있도록 했습니다.

또한 핵심 추이를 보는 것이 목적이었기에,
$5 미만 항목은 우선순위가 낮다고 판단해 제외했습니다.

const svc = services.get(row.productName)!;
svc.usd += row.usd;

const sku = svc.skus.get(usageTypeParsed)!;
sku.usd += row.usd;

// ...

const sortedServices = [...services.values()].sort((a, b) => b.usd - a.usd);
for (const svc of sortedServices) {
  if (svc.usd < 5) continue;
  // ...
}

정확한 추이를 위해

숫자만 보면 이게 많은 건지 적은 건지 알기 어렵습니다.
의미 있는 판단을 하려면 전월이나 최근 몇 달과 비교해야 합니다.

여기서 두 가지 문제가 있었습니다.

첫 번째로 월마다 날짜 수가 다릅니다.
단순히 이번 달 합계와 지난 달 합계를 비교하면 날짜 차이만큼 왜곡이 생깁니다.

두 번째로 저는 월 중간에도 집계합니다.
이달 1일부터 15일을 집계했다면,
전월도 1일부터 15일까지만 잘라서 비교해야 공정한 비교가 됩니다.

이 두 문제를 해결하려면 이전 달 데이터를 날짜 단위로 보관해두어야 했습니다.
그래서 실행할 때마다 집계 결과를 data.json으로 저장해두고,
다음 달 실행 시 불러와서 같은 일자까지만 잘라 비교하는 방식으로 처리했습니다.

const prevAccDataPath = path.join(OUTPUT_PATH, prevYearMonth, 'aws', account.slug, 'data.json');
const prevAccData = fs.existsSync(prevAccDataPath)
  ? JSON.parse(fs.readFileSync(prevAccDataPath, 'utf8'))
  : null;

// ...

fs.writeFileSync(path.join(accOutDir, 'data.json'), JSON.stringify(accDataJson, null, 2) + '\n', 'utf8');

서비스별, SKU별, 리소스별로 전월 값이 있으면 차이를 함께 표시합니다.
그래프도 당월과 전월을 겹쳐서 한눈에 추이를 볼 수 있도록 생성합니다.

마치며

이 모든 과정이 끝나면 서비스별 차트와 계정별 보고서가 생성됩니다.
저는 그 과정에서 전월 대비 크게 오른 서비스나 리소스가 있는지 확인하면 됩니다.

단순히 수작업이 귀찮아서 시작한 자동화였지만,
결과적으로는 데이터에 기반하여 자신 있게 말할 수 있는 근거가 생겼습니다.

TypeScript를 쓸 줄 몰랐던 저 혼자였다면 여기까지 오지 못했을 겁니다.
Claude와 함께였기에 가능한 일이었습니다.

그렇게 오늘도 저는 대답합니다.

“네, 이번 주도 특이 사항 없습니다.”