개발자 플랫폼 Kontrol: 지난 2년간 무엇을 만들었는가 (SRE 밋업 3회)

주요 구간

• 04:49 설계 원칙: 문턱은 낮추고 천장은 높이고 벽은 넓힌다
• 06:52 Kontrol 소개와 배포 데모
• 12:00 승인, 모니터링 연결, IAM 파일 배포
• 18:06 아키텍처 변화: DB 추가, 글로벌 배포, 배포 엔진 교체
• 20:08 오너십 카탈로그, 비용 시각화, 리소스 생성
• 27:44 효과와 ArgoCD를 경쟁 제품으로 남겨 두는 이유

티켓 자동화로 풀지 못한 불편

당근에서는 개발자가 티켓으로 인프라를 요청하면 SRE 팀이 만들어 전달했습니다. 개발자는 빠른 변경과 다양한 시도를 원했지만, SRE 팀에는 안정적인 운영과 정책 적용, 일관된 형태, 승인 절차가 필요했습니다. 사람이 요청을 처리하다 보니 지연이나 급한 오픈 직전의 요청 집중이 생겼고, 스크립트와 IaC로 자동화해도 양쪽의 불편은 남았습니다.

조직도 커져 엔지니어가 200명을 넘었고, 서비스 클러스터는 4개 리전에 8개가 있으며, 가장 큰 한국 클러스터에는 프로젝트 단위 네임스페이스가 200개 넘게 있습니다.

배포 UI에서 사내 플랫폼으로

당근이 2021년 7월 사내에 공개한 플랫폼이 Kontrol입니다. 슬라이드에 인용된 설계 원칙은 “Low Threshold, High Ceiling, and Wide Walls"로, 발표자는 아직 초기 단계라 진입 장벽을 낮추는 데 집중한다고 설명합니다. 인프라에 익숙하지 않은 개발자의 수준을 끌어올려 실수와 예외를 줄이되, 숙련된 개발자의 자유도는 일부 줄어든다는 점도 인정합니다.

Kontrol은 처음에는 배포 백엔드인 GoCD의 데이터를 보여 주는 UI에 가까웠고, 한국 클러스터에만 배포할 수 있었습니다. 기능을 늘리면서 DB를 추가하고 글로벌 배포를 구현했으며, 배포 엔진도 GoCD에서 Argo Workflows로 교체했습니다.

개발자는 쿠버네티스를 추상화한 간단한 YAML 매니페스트를 저장소에 두고, 화면에서 프로젝트를 등록한 뒤 배포 버튼을 누릅니다. 빌드 준비가 끝나면 알파 배포가 자동으로 이어지고 마지막 단계에서 승인을 받는 흐름입니다. 매니페스트 옆에 IAM 정책 JSON을 두면 배포 시 서버에 권한이 연결되며, 허용 목록 패턴 안에서는 SRE 티켓 없이 변경할 수 있습니다. 환경변수는 AWS 시크릿 매니저로 통합해 관리 화면을 제공하고, 크론잡 화면에서는 스케줄·수동 실행·일시 중지·로그를 함께 확인합니다. 배포 정보를 바탕으로 Loki와 Prometheus 쿼리를 담은 링크를 제공해 로그와 메트릭으로 바로 이동할 수 있습니다.

배포 이후에는 오너십 카탈로그, 프로젝트별 비용 시각화, 클라우드 리소스 생성 프로젝트를 같은 UI에 연결했습니다. 카탈로그는 프로젝트 담당 팀과 구성원을 조직도에 연결하고, 클라우드 리소스가 어느 프로젝트 소유인지 매핑합니다. 서비스 간 의존성을 관리하는 기능은 아닙니다.

도입 후 달라진 점

당근에서는 인프라 작업 요청이 체감할 만큼 줄어 그 시간을 플랫폼 개발에 쓸 수 있게 됐습니다. 프로그램이 매니페스트를 생성하면서 같은 형태의 설정이 늘고, 설정 오타를 디버깅하는 일도 사라졌습니다. 설정을 바꿀 때는 Kontrol 내부 소스만 수정하면 다음 배포부터 일괄 적용됩니다.

ArgoCD에서 Kontrol로의 이전은 권장하되 의무로 두지 않았습니다.

ArgoCD를 선택지로 남긴 이유

발표자는 쿠버네티스를 깊이 아는 팀에는 Kontrol의 추상화가 자유를 제한해 불편할 수 있다고 말합니다. 경쟁 제품이 없는 사내 플랫폼을 강제하면 좋은 제품인지 판단하기 어렵다는 설명입니다. 그래서 ArgoCD를 경쟁 제품처럼 남겨 두고, 사용자가 ArgoCD를 택하면 Kontrol을 더 개선해야 한다는 신호로 받아들입니다.

크론잡 화면은 아직 개선을 고민하는 단계라고 밝혔습니다. 세부 주제는 같은 밋업의 다음 발표들에서 이어집니다.