프로젝트 오너십 관리로 DevOps 기반 만들기: katalog (SRE 밋업 3회)

이 발표는 같은 밋업의 개요에서 짧게 소개한 카탈로그를 자세히 다룹니다. 전체 흐름은 개발자 플랫폼 지난 2년에서 확인할 수 있습니다.

주요 구간

• 01:23 클라우드 리소스 오너십이 필요한 이유
• 03:10 태그 방식의 불편과 신뢰도 문제
• 07:15 katalog 시작과 오너십 단위 결정
• 10:21 리소스 목록과 오너십 변경 화면
• 14:36 아키텍처와 AWS, GCP API 선택
• 17:43 앞으로의 확장 방향

태그로 담당을 찾기 어려웠던 이유

예를 들어 특정 Redis에 장애가 나면 담당 프로젝트·팀과 호출할 Slack 그룹을 알아야 합니다. 비용이 늘었을 때는 문의할 팀을 찾아야 합니다. 당근은 AWS 태그와 GCP 라벨에 팀 이름이나 프로젝트 정보를 붙여 오너십을 관리했지만, 태그만으로 담당을 파악하기 어려웠습니다.

팀 이름이나 오너십이 바뀔 때마다 Terraform 코드의 태그를 수정해 적용해야 했습니다. 사라진 팀의 리소스는 옛 팀원에게 묻거나 처리를 미루기 일쑤였습니다. AWS Config로 사내 팀 정보와 태그 값을 매일 맞추기도 했지만, 발표자는 이상적인 방식은 아니었다고 설명합니다.

여러 서비스가 올라간 Kontrol에서도 프로젝트 이름만으로 담당을 구분하기 어려웠습니다. 장애가 나면 배포자의 팀과 Slack 그룹을 일일이 찾아야 했습니다.

Kontrol 프로젝트를 오너십 단위로 선택

당근은 기존 Kontrol 프로젝트를 오너십 단위로 삼았습니다. Kontrol 프로젝트는 이미 하나의 MSA 서비스이자 네임스페이스 단위였으며, 딜리버리 파트가 개발자에게 담당 정보를 받아 수동으로 정리하던 대상입니다. 당근은 이 단위를 기준으로 Kubernetes 네임스페이스와 AWS, GCP 리소스를 하나의 오너십 ID로 묶고 팀 정보·Slack 그룹·채널을 연결하는 서비스 katalog를 만들었습니다. 이름은 karrot과 service catalog의 합성어입니다.

Kontrol에서는 프로젝트를 만들 때 담당 팀과 설명을 입력합니다. 팀별 프로젝트 필터와 Slack 그룹 설정도 제공합니다. 클라우드 리소스 화면에서는 AWS와 GCP 리소스를 프로젝트별로 함께 보고, 클릭 몇 번으로 오너십을 다른 프로젝트로 옮길 수 있습니다. 전체 목록에서는 오너십이 없는 리소스도 확인합니다.

팀 정보는 사내 HR API에서 주기적으로 DB에 가져와 팀 코드로 매핑합니다. 팀 이름이나 부서가 바뀌면 자동으로 반영하고, 담당 팀이 사라지면 Kontrol에 부서 변경 안내를 띄워 각 팀이 직접 수정하게 했습니다.

구현 언어는 Golang입니다. 사내에서 Go를 많이 쓰고 있어 직접 배워 보려는 이유도 있었다고 합니다. AWS는 Resource Groups Tag Editor API로 리소스에 katalog ID를 태깅하고 조회합니다. GCP의 Cloud Asset API는 라벨 수정 기능이 없고, 한 번에 조회할 수 있는 리소스가 최대 500개(pageToken 사용)여서 지연이 컸습니다. 그래서 서비스별 API로 라벨을 조회하고 수정하는 방식을 택했습니다.

오너십 관리가 달라진 점

• 팀 이름이나 조직이 바뀔 때 오너십 정보를 수동으로 수정하는 작업이 거의 사라짐
• Kontrol UI 한 곳에서 오너십 변경과 클라우드 리소스 확인을 처리
• 오너십을 활용한 알림 서비스, 비용 대시보드, 클라우드 리소스 셀프 서비스 개발이 가능해짐

적용 범위와 남은 과제

오너십 단위가 배포하는 프로젝트여서 네트워크·보안 리소스처럼 배포하지 않는 영역은 바로 담기 어렵습니다. 당근은 Kontrol에 공용 네트워크 프로젝트를 만들고 리소스를 할당하는 방식으로 프로젝트 개념을 넓힐 계획입니다.

팀 통폐합에 따른 변경은 클라우드 파트가 추적해 대신 처리하지 않고, 각 팀이 직접 수정하도록 했습니다. 앞으로는 사용 언어, 서비스 티어, SLO 등의 메타데이터도 추가할 계획이라고 합니다.