플랫폼 엔지니어링을 위한 인공지능의 인간화: 내부 개발자 플랫폼(IDP)의 사용 편의성 개선

단지 서비스를 배포하고 싶었을 뿐인 개발자

지난주 우리 팀의 한 백엔드 개발자가 저에게 메시지를 보냈습니다. 그녀는 작은 Go 서비스를 구축했고, 로컬 테스트를 통과했으며, 이를 우리의 스테이징 클러스터(staging cluster)에서 실행하고 싶어 했습니다. 간단한 요청이었죠. 그러다 그녀는 플랫폼 위키(wiki)를 열었습니다.

40페이지 분량의 문서. 명명 규칙(naming conventions)에 관한 섹션. Postgres 인스턴스에 어떤 Terraform 모듈을 사용할지에 대한 페이지와 하단에 해당 페이지가 "대체로 최신 상태"라고 적힌 메모. Helm values 참조. 누군가 삭제하는 것을 잊어버린, 더 이상 사용되지 않는(deprecated) 런북(runbook) 링크. 그녀가 올바른 골든 패스(golden-path) 템플릿을 찾아냈을 때쯤에는, 반나절을 허비했고 Slack에서 세 명에게 메시지를 보낸 상태였습니다. 그녀에게 필요했던 것은 우리 플랫폼에 대한 튜토리얼이 아니었습니다. 그녀에게 필요했던 것은 누군가 그녀를 올바른 문 앞까지 안내해 주는 것이었습니다.

그 간극이 바로 대부분의 내부 개발자 플랫폼(Internal Developer Platforms, IDP)이 가진 실제 문제입니다. 포장된 도로(paved road)는 존재합니다. 템플릿도 존재합니다. 정책도 건전합니다. 하지만 그 포장된 도로를 찾는 데 드는 인지 부하(cognitive load)가 너무 높아서, 개발자들은 그 길을 우회하고, 다른 팀의 YAML 파일을 복사해 오며, 우리의 표준 중 네 가지를 위반하는 무언가를 배포해 버립니다. 플랫폼은 기능(capability) 측면에서 실패하고 있는 것이 아닙니다. 사용성(usability) 측면에서 실패하고 있는 것입니다.

이 지점이 바로 제가 플랫폼 엔지니어링에서 AI가 제 역할을 할 수 있다고 생각하는 부분이며, 이는 과장된 홍보(hype)보다 훨씬 좁은 범위의 주장입니다. 여기서 "AI의 인간화(Humanizing AI)"란 플랫폼 팀을 대체하는 챗봇을 의미하는 것이 아닙니다. 이는 AI를 IDP의 친절한 정문으로 사용하는 것을 의미합니다. 즉, 평범한 영어 요청을 올바른 골든 패스(golden-path) 템플릿으로 변환하고, 승인된 템플릿을 바탕으로 보일러플레이트(boilerplate)를 구성하며, 난해한 플랫폼 에러를 설명하여 개발자가 임시방편(hacking around it)으로 해결하는 대신 올바르게 수정할 수 있도록 돕는 것입니다. 가드레일(guardrails), 템플릿, 승인 절차, 그리고 이를 관리하는 사람들은 모두 그대로 유지됩니다. AI는 셀프 서비스(self-service)의 마찰을 줄여줄 뿐입니다. 포장된 도로를 우회하게 만드는 것이 아닙니다.

사람들이 찾을 수 있어야 진정한 셀프 서비스입니다

IDP(Internal Developer Platform)의 약속은 개발자가 티켓을 제출하고 이틀을 기다릴 필요 없이 필요한 것을 직접 프로비저닝(provision)할 수 있다는 것입니다. 하지만 제가 본 대부분의 플랫폼에서 마주한 현실은, 개발자가 이미 플랫폼의 용어를 알고 있다고 가정하는 셀프 서비스 포털이었습니다. 어떤 모듈을 사용해야 하는지? 어떤 환경 계층(environment tier)을 선택해야 하는지? 개인정보(PII)를 다루는 서비스에는 어떤 승인 게이트(approval gate)가 적용되는지 말입니다.

"Postgres를 사용하는 새로운 Go 서비스를 만들어 주세요"라고 요청하는 개발자는 인간의 언어로 매우 합리적인 질문을 던지는 것입니다. 하지만 플랫폼은 기계의 언어로 대답합니다. 템플릿 ID를 선택하고, 14개의 변수를 채우고, 그중 무엇이 필수인지 미리 알고 있어야 합니다. 이 두 언어 사이의 번역 계층이야말로 AI 어시스턴트가 가장 잘할 수 있는 영역이며, 동시에 대부분의 팀이 Slack에서 수없이, 영원히 수동으로 번역 작업을 반복해 온 바로 그 지점입니다.

핵심은 그라운딩(grounding, 근거 제시)입니다. 그라운딩되지 않은 AI는 2021년 블로그에서 본 Terraform 코드를 개발자에게 아무렇지 않게 제안할 것입니다. 이는 위키(wiki)보다 더 나쁩니다. 확신에 차서 틀린 정보를 제공하기 때문입니다. 반면, 여러분의 템플릿 카탈로그, 여러분의 골든 패스(golden paths), 그리고 검색(retrieval)을 통해 연결된 여러분의 최신 문서와 연결된 그라운딩된 어시스턴트는, 자신의 컨텍스트 내에 존재하는 유일한 선택지인 포장된 도로(paved road)를 추천합니다.

전문가 팁: 플랫폼 모델을 파인튜닝(fine-tune)하고 끝났다고 생각하지 마세요. 여러분의 라이브 템플릿 저장소, Backstage 소프트웨어 카탈로그, 그리고 최신 런북(runbook)에 대해 검색(retrieval) 방식으로 그라운딩하세요. 템플릿은 매주 변경되지만, 파인튜닝된 모델은 스냅샷을 동결시킵니다. 검색(retrieval)을 사용한다는 것은 어시스턴트가 누군가 모델을 학습시켰던 날에 승인된 것이 아니라, 오늘 실제로 승인된 것을 추천한다는 의미입니다.

문장에서 스캐폴드(Scaffold)로

여기에 구체적인 결과물이 있습니다. 개발자가 플랫폼 어시스턴트에 다음과 같이 입력합니다:

billing-events라는 이름의 새로운 Go 서비스가 필요합니다. Postgres 데이터베이스와 스테이징(staging) 및 운영(prod) 환경이 필요하며, 우리 Kafka 토픽으로 메시지를 발행해야 합니다.

근거가 확실한 어시스턴트(grounded assistant)는 자유분방하게 인프라를 생성하지 않습니다. 대신 해당 요청을 카탈로그에 있는 승인된 go-service-pg 골든 패스 (golden-path) 템플릿에 매핑하고, 플랫폼 팀이 이미 승인한 스캐폴딩 (scaffold)을 생성합니다.

billing-events/
  catalog-info.yaml        # Backstage 엔티티, 소유 팀 정보 사전 입력됨
  cmd/main.go              # 서비스 스켈레톤 (skeleton), 당사의 로깅 + 상태 확인 (health) 엔드포인트
...

생성된 Terraform은 임의로 만들어진 것이 아닙니다. 템플릿이 요구하는 변수들과 함께, 고정된 버전(pinned version)으로 당사의 내부 모듈 레지스트리 (module registry)를 호출합니다.

module "billing_events_db" {
  source         = "registry.internal/our-org/rds/aws"
  version        = "4.2.1"
...

AI가 수행한 일과 수행하지 않은 일에 주목하십시오. AI는 상용구 코드 (boilerplate)를 채워 넣고, 당사의 티어 프리셋 (tier presets)에서 합리적인 기본값 (sane defaults)을 선택했으며, 정책 엔진 (policy engine)이 판단할 수 있도록 리소스에 태그를 달았습니다. AI는 모듈 버전을 선택하거나, 새로운 인스턴스 클래스 (instance class)를 만들어내거나, multi_az 설정을 건너뛰지 않았습니다. 이러한 요소들은 템플릿에 내장된 제약 사항이며, 어시스턴트는 템플릿을 우회하는 것이 아니라 템플릿 '내부로' 생성하고 있기 때문입니다. 만약 개발자가 템플릿으로 표현할 수 없는 것—우리가 지원하지 않는 데이터베이스 클래스나 우리가 운영하지 않는 리전(region)—을 요청한다면, 어시스턴트의 올바른 답변은 창의적인 우회책을 제시하는 것이 아니라 "그것은 포장된 도로 (paved road) 위에 있지 않습니다. 누구와 상의해야 하는지 알려드리겠습니다"가 되어야 합니다.

이러한 컨테이너에서 클러스터로 이어지는 흐름에 AI를 연결하는 것이 처음이라면, from Dockerfile to first Kubernetes deployment with AI의 가이드가 "검증된 형태 (known-good shape)에 맞춰 생성하기"가 실제 환경에서 어떻게 구현되는지 이해할 수 있는 좋은 기초 단계가 될 것입니다.

골든 패스에는 지도뿐만 아니라 가이드가 필요합니다

골든 패스 (Golden path)는 개발자들이 그 경로를 유지할 때만 비로소 '골든'이 됩니다. 제가 끊임없이 목격하는 실패 사례는 이렇습니다. 플랫폼 팀이 훌륭한 포장도로를 구축하고 아름답게 문서화해 두었지만, 정작 팀들이 그 경로를 벗어나는 것을 지켜보게 됩니다. 왜냐하면 결정을 내려야 하는 순간 — 예를 들어 내일 스탠드업 미팅 전에 배포를 마치려고 애쓰는 오후 4시 —에는 아무도 문서를 읽지 않기 때문입니다. 그들은 그저 가장 가까이 있는 무엇이든 집어 듭니다.

여러분의 골든 패스에 기반을 둔 AI 어시스턴트 (AI assistant)는 그러한 결정의 경제성을 변화시킵니다. 어시스턴트가 대신 조회와 스캐폴딩 (scaffolding)을 수행해주기 때문에, 포장된 도로를 유지하는 것이 '노력이 적게 드는 (low-effort)' 옵션이 됩니다. 반대로 경로를 벗어나는 것은 테라폼 (Terraform)을 직접 손으로 작성해야 하므로 '노력이 많이 드는 (high-effort)' 옵션이 됩니다. 이것이 바로 여러분이 원하는 역전입니다. 수년 동안 우리는 플랫폼을 준수하기 위해 개발자들에게 추가적인 작업을 요구해 왔습니다. 제대로 구현된다면, AI는 준수(compliance)를 가장 저항이 적은 경로로 만들어 줍니다.

이는 논리적으로 이해하기 정말 어려운 워크플로우 (workflows)에서 가장 중요합니다. GitOps가 좋은 예시입니다. "Git이 신뢰할 수 있는 단일 원천 (source of truth)이며, 컨트롤러 (controller)가 클러스터를 이에 맞춰 조정(reconcile)한다"는 모델은 강력하지만, 첫 서비스를 배포하는 사람에게는 직관적이지 않습니다. 변경 사항이 왜 아직 반영되지 않았는지 설명할 수 있는 어시스턴트 — "매니페스트 (manifest)는 머지(merge)되었지만, Argo CD가 아직 동기화(sync)되지 않았습니다. 여기 동기화 상태와 해당 앱 정보가 있습니다"라고 말해주는 어시스턴트 — 는 진정한 개발자 지원을 수행하고 있는 것입니다. 만약 여러분의 플랫폼이 이러한 패턴을 실행하고 있다면, 사람들에게 GitOps for infrastructure explained의 개념적 토대와 실습용 practical starting guide for Argo CD를 안내하고, 어시스턴트가 여러분의 실제 설정에 기반하여 "그런데 왜 내 것이 배포되지 않죠?"라는 질문에 답하게 하십시오.

프로 팁(Pro Tip): 어시스턴트가 출처를 인용하게 만드세요. 모든 권장 사항은 그것이 가져온 템플릿(template), 런북(runbook), 또는 카탈로그 항목(catalog entry)으로 다시 연결되어야 합니다. 이는 두 가지 효과를 가집니다. 개발자가 스스로 '포장된 도로(paved road)'를 검증할 수 있게 해주며, 플랫폼 팀에게는 신호를 줍니다. 어시스턴트가 계속해서 오래된 문서를 인용한다면, 그것은 문서를 수정해야 한다는 신호입니다. AI가 여러분의 문서 사용 추적기(usage tracker)가 되는 것입니다.

편법(Hack)을 유도하는 대신 난해한 에러를 설명하기

IDP(내부 개발자 플랫폼)에서 AI를 활용할 수 있는 가장 레버리지가 높은 지점은 개발자가 이해할 수 없는 플랫폼 에러를 마주하는 순간입니다. 바로 이 지점에서 사람들은 편법(hack)을 사용합니다. 파이프라인이 불투명한 이유로 실패하고, 개발자는 그것이 무엇을 의미하는지 알지 못할 때, 가장 빠른 탈출구는 체크를 비활성화하거나, || true를 추가하거나, 여러분의 플랫폼과는 아무런 관련이 없는 Stack Overflow 답변에서 임시방편(workaround)을 복사해 오는 것입니다.

훌륭한 어시스턴트는 그 순간을 가로챕니다. 우리의 정책 게이트(policy gate)에서 배포가 실패했을 때 제가 보고 싶은 출력 결과는 다음과 같습니다:

prod로의 배포가 require-resource-limits 정책에 의해 차단되었습니다.

귀하의 helm/values.yaml은 CPU 요청(request)은 설정되어 있지만 CPU 제한(limit)은 설정되어 있지 않습니다. 우리의 운영(prod) 승인 정책(admission policy)은 노드 하나가 고갈되는 것을 방지하기 위해 두 가지 모두를 요구합니다. 체크를 비활성화할 필요는 없습니다.

go-service-pg 골든 패스(golden path)는 이미 규정을 준수하는 제한 사항이 포함된 "small" 티어 프리셋(preset)이 적용된 values-prod.yaml을 제공합니다. 이 서비스가 해당 프리셋이 존재하기 전에 스캐폴딩(scaffolded)되었기 때문에 이를 놓치신 것입니다. 템플릿에서 resources: 블록을 여기로 복사하세요: [템플릿 링크]. 그 후 배포를 다시 실행하십시오. 오버라이드(override)는 필요하지 않습니다.

만약 프리셋이 허용하는 것보다 실제로 더 높은 제한이 필요하다면, 그것은 정책 우회(policy bypass)가 아니라 플랫폼 팀과 용량(capacity)에 대해 논의해야 할 문제입니다. 여기서 요청을 생성하세요: [링크].

그 출력물은 가드레일 (guardrail)을 준수합니다. 정책이 왜 존재하는지 설명하고, 골든 패스 (golden-path) 해결책을 제시하며, 편법 (hack)에 대해서는 명시적으로 차단합니다. 동시에 실제 예외 상황을 위한 정당한 인간 개입 (human-in-the-loop) 에스컬레이션 경로를 남겨둡니다. 빨간색 경고 문구를 없애줄 플래그 (flag)를 찾는 것이 개발자의 기본 대응 방식이라는 점과 비교해 보십시오. AI는 정책을 약화시키지 않았습니다. AI는 정책을 이해 가능하게 만들었으며, 이는 정책이 마감 기한이라는 현실과 맞닥뜨렸을 때 살아남을 수 있게 하는 유일한 방법입니다.

여기에는 고된 노동 (toil)에 관한 더 깊은 논점이 있습니다.

AI가 절대 해서는 안 될 일은 인프라를 적용하거나 릴리스를 승인하기 위한 자격 증명 (credentials)을 스스로 보유하는 것입니다. 승인 게이트 (approval gates)는 가드레일 역할을 합니다. 머지 (merge)는 사람이 소유합니다. 운영 환경 (prod) 승인 또한 사람이 소유합니다. AI는 제어판 옆에 서서 각 버튼이 무엇을 하는지 설명하는 어시스턴트여야 하며, 제어판에 손을 올리고 있는 운영자가 되어서는 안 됩니다. 만약 AI가 개발자의 운영을 돕는 플랫폼 자동화를 구축하고자 한다면, Kubernetes operator pattern guide를 읽어볼 가치가 있습니다. 이를 통해 클러스터 상태를 실제로 변경하는 부분인 조정 로직 (reconciliation logic)을 확률론적 모델 (probabilistic model)이 아닌, 결정론적이고 감사 가능한 컨트롤러 (deterministic, audited controllers) 내에 유지하는 방법을 배울 수 있습니다.

프로 팁 (Pro Tip): AI 어시스턴트의 출력을 기존의 리뷰 및 정책 게이트로 흘러 들어가는 제안으로 취급해야 하며, 이를 건너뛰는 사이드 채널 (side channel)로 절대 취급해서는 안 됩니다. AI가 생성한 스캐폴딩 (scaffold)은 사람이 리뷰하는 풀 리퀘스트 (pull request) 형태로 전달되어야 합니다. AI가 작성한 Terraform은 여전히 plan, 정책 코드화 (policy-as-code), 그리고 승인 과정을 거쳐야 합니다. 만약 당신의 어시스턴트가 일반적인 파이프라인이 할 수 없는 변경을 수행할 수 있다면, 당신은 정문 (front door)이 아닌 백도어 (backdoor)를 만든 것입니다.

핵심은 인간 플랫폼 팀이다

이 모든 내용을