[인프라를 소프트웨어처럼 5/5] 다섯 축의 운영 총합, 그리고 AI 시대의 플랫폼팀

모든 이야기가 가리키는 한 가지

지난 화에서 우리는 plan과 apply 사이를 테스트 가능성과 재현 가능성으로 건넜습니다. 그 앞으로는 배포·클라우드·시간·공간·테스트, 그리고 환경까지 차례로 지나왔습니다. 각 화는 저마다 다른 통증에서 출발했지만, 끝에 와서 보면 모두 같은 자리를 가리킵니다.

이 마지막 화가 할 일은 새 기술을 하나 더 꺼내는 것이 아닙니다. 지나온 여섯 줄을 한 장의 표 위에 다시 세워 두고, 그 표가 말하는 한 문장을 또렷하게 만드는 것입니다. 그리고 그 문장이 왜 사람의 변경뿐 아니라 AI 에이전트의 변경에도 그대로 작동하는지를 보이는 것입니다.

한 장의 표로 돌아와서

이 연재가 한 일은 결국 표 하나에 새 줄을 더한 것입니다. 이전 <코드가 환경을 모르는 구조> 시리즈가 정리해 둔 다섯 축에, 플랫폼팀이 운영하는 환경이라는 한 줄을 더 붙였습니다.

여섯 줄은 모두 같은 한 문장을 말합니다. "코드는 무엇을, 환경은 어디서." 가운데 열은 어느 줄에서나 그대로 두는 불변의 계약이고, 오른쪽 열은 그 계약을 건드리지 않은 채 갈아 끼우는 접점입니다. 다른 점은 누가 일하느냐뿐입니다. 앞의 다섯은 개발자가 코드에서 환경을 밀어내는 이야기였고, 여섯 번째는 플랫폼팀이 그 환경을 코드로 만들어 되돌려주는 이야기입니다. 여기서 environment variant는 7화의 그 variant, 즉 테스트 컨테이너 계열을 식별하던 값 객체가 아니라, 브랜치로 만드는 격리 실행 환경을 가리킵니다. 이름은 같지만 다른 것입니다.

교체가 쉬워지면 실험이 빨라진다

왜 이렇게까지 경계를 분리할까요. 경계를 분리하면 접점을 교체할 수 있게 되고, 교체가 쉬워질수록 하루에 시도할 수 있는 실험이 늘어나기 때문입니다. 오른쪽 접점을 갈아 끼우는 비용이 0에 가까워질수록 한 번의 시도에 드는 시간이 줄고, 같은 하루에 더 많은 가설을 검증하게 됩니다.

환경에서 이 효과는 가장 극적으로 나타납니다. 환경을 받아 오는 데 며칠이 걸리던 시절에는 실험이 곧 신청서였습니다. 환경을 브랜치 하나로 만들 수 있게 되자, 실험은 브랜치를 push하는 순간이 됩니다. 테스트·재현이 받쳐 주면 그 실험을 두려움 없이 버릴 수도 있습니다. 망가진 환경은 브랜치를 지우면 사라지니까요. 안전하게 버릴 수 있다는 것이 곧 자주 시도할 수 있다는 것입니다.

여섯 축은 한 문화에서 나왔다

한 가지 덧붙이면, 이 여섯 축은 서로 다른 팀이 따로 만든 게 아닙니다. "경계를 선언만 하지 말고 실제로 나누자"는 같은 코드리뷰 문화가 여섯 층을 모두 관통합니다.

코드에서 환경을 분리하는 규율을 세웠을 때, 그 환경 자체에 같은 규율을 적용하는 건 자연스러운 다음 수였습니다. 인프라를 헥사고날 구조로 짜고, 변경을 apply 전에 띄워 보고, PR로 리뷰받고, 머지되면 환경에 반영되는 흐름 — 이건 새 규칙이 아니라 이미 쓰던 규칙을 인프라로 옮긴 것입니다. 같은 문화가 여섯 축을 다 만들었습니다. 그래서 한 축을 다루던 사람이 다른 축으로 옮겨가도, "무엇을 고정하고 무엇을 갈아 끼울지"를 나누는 방식은 똑같이 통합니다.

AI가 스스로 테스트하고, 사람과 AI가 확인한다

"사람을 위해 만든 규율이 AI 에이전트에게도 작동한다"는 것. 플랫폼 운영의 자리에서 보면, 이건 예고가 아니라 이미 우리가 기대고 있는 전제입니다.

AI는 인프라의 진입장벽을 빠르게 낮추고 있습니다. 명령어를 외우고 콘솔을 더듬는 일은 점점 AI가 대신하고, 우리는 변경의 상당 부분을 이미 AI에게 맡기기 시작했습니다. 그럴수록 플랫폼팀이 붙잡아야 할 것은 "누가 바꾸느냐"가 아니라, AI가 그 변경을 안전하게, 스스로 테스트해 볼 수 있는가입니다.

우리가 깎아 둔 여섯 축이 바로 그 판을 깔아 줍니다. 환경이 브랜치로 표현되니, AI는 격리된 환경을 스스로 하나 띄워 그 안에서 변경을 돌려 봅니다. 인프라가 테스트·재현 가능하니, 그 변경은 운영이 아니라 로컬(kind·vcluster)과 격리 환경에서 먼저 실행되어 결과가 남습니다. 경계가 코드로 선언되어 있으니, 그 결과가 동작했는지·선언대로 반영됐는지를 사람과 AI가 같은 방식으로 확인합니다. 무엇보다 변경이 잘못돼도 그 파장은 격리된 환경 안에 갇히고, 되돌리기는 브랜치를 지우는 일입니다.

그래서 AI에게 실행을 맡기는 시대에 플랫폼팀이 파는 것은 이 한 묶음입니다. AI가 능동적으로 시도하되, 그 결과가 격리되고, 사람과 AI가 함께 확인하고, 언제든 되돌릴 수 있는 피드백 루프. 이 판 위에서 AI의 변경은 사람의 변경과 같은 안전망에 놓입니다.

실제로 우리가 "dev 브랜치를 없애고 values.{dev,qa,prod}.yaml 분기로 가자"고 결정한 명분 중 하나도 여기에 있었습니다. 환경을 별도 브랜치로 나누면 사람도 가끔 브랜치를 헷갈리지만, 에이전트는 그 실수를 훨씬 조용히, 훨씬 자주 저지를 수 있습니다. 환경을 main 위의 values 분기로 표현하면, "어느 브랜치냐"라는 선택 자체가 사라지고 "어느 values 파일이냐"라는 선언만 남습니다. 에이전트가 브랜치를 잘못 골라 실수할 여지를 설계에서 지운 것입니다.

플랫폼팀이 파는 것

여기서 매듭을 짓습니다. flex 플랫폼팀에게 인프라는 apply해 봐야 되는지 아는 위험이 아니라, 손대기 전에 테스트하고 재현하고 리팩터링하는 소프트웨어입니다. 그래서 우리는 인프라를 헥사고날 구조로 짜고, 환경을 브랜치로 만들고, 변경을 apply 전에 띄워 봅니다.

그 모든 것이 가리키는 한 가지 가치가 있습니다 — 안전하고 빠른 변경의 피드백 루프. 플랫폼팀이 파는 것은 서버도, 클러스터도, 파이프라인도 아닙니다. 그것들 위에서 누구든 — 사람이든 에이전트든 — 두려움 없이 자주 바꾸고 빠르게 되돌릴 수 있는 그 루프입니다. 여섯 축을 깎아 온 이유도, 앞으로 깎을 이유도 거기에 있습니다. 인프라를 소프트웨어처럼 다룬다는 말의 끝은, 결국 이 한 줄로 모입니다.

경계를 깎는 여정, flex 클라우드플랫폼팀에 합류하세요.
인프라를 소프트웨어처럼 다루며 안전하고 빠른 변경의 피드백 루프를 함께 만들 분을 찾습니다.