flex의 "인프라를 소프트웨어처럼" 연재 마지막 편으로, 앞선 화들이 다룬 배포·클라우드·시간·공간·테스트에 환경까지 여섯 축을 한 표 위에 다시 세우고 그것이 AI 시대의 플랫폼팀에 무엇을 뜻하는지 정리한다. 새 기술을 꺼내는 대신, 여섯 축 모두가 가운데의 불변 계약은 그대로 두고 오른쪽 접점만 갈아 끼우는 같은 모양이라는 점을 드러낸다. 앞의 다섯은 개발자가 코드에서 환경을 밀어내는 이야기였고 여섯 번째는 플랫폼팀이 그 환경을 코드로 만들어 되돌려주는 이야기다.
핵심 포인트- 경계를 분리하면 접점을 교체할 수 있게 되고, 교체가 쉬워질수록 하루에 시도할 수 있는 실험이 늘어난다.
- 환경 축에서 그 효과가 가장 극적이다. 환경을 받는 데 며칠이 걸리던 시절에는 실험이 곧 신청서였는데, 브랜치 하나로 환경을 만들 수 있게 되자 실험이 push가 됐다.
- 안전하게 버릴 수 있다는 것이 곧 자주 시도할 수 있다는 것이다. 망가진 환경은 브랜치를 지우면 사라진다.
- 여섯 축은 서로 다른 팀이 따로 만든 것이 아니라 "경계를 선언만 하지 말고 실제로 나누자"는 같은 코드리뷰 문화가 관통한다.
- AI에게 실행을 맡기는 시대에 플랫폼팀이 파는 것은 AI가 능동적으로 시도하되 결과가 격리되고 사람과 AI가 함께 확인하고 언제든 되돌릴 수 있는 피드백 루프다.
상세 정리- 표의 구조: 가운데 열은 어느 줄에서나 그대로 두는 불변의 계약이고 오른쪽 열은 그 계약을 건드리지 않은 채 갈아 끼우는 접점이다. 마지막 줄인 환경은 플랫폼팀이 더한 것으로 접점이 곧 브랜치다.
- 용어 구분: 여기서 말하는 environment variant는 앞선 화에서 테스트 컨테이너 계열을 식별하던 값 객체가 아니라 브랜치로 만드는 격리 실행 환경을 가리킨다. 이름은 같지만 다른 것이라고 못박는다.
- 실험 빈도의 논리: 오른쪽 접점을 갈아 끼우는 비용이 0에 가까워질수록 한 번의 시도에 드는 시간이 줄고 같은 하루에 더 많은 가설을 검증하게 된다.
- 테스트와 재현이 받쳐 주면 그 실험을 두려움 없이 버릴 수 있다는 점을 강조한다.
- 문화의 연속성: 인프라를 헥사고날 구조로 짜고, 변경을 apply 전에 띄워 보고, PR로 리뷰받고, 머지되면 환경에 반영되는 흐름은 새 규칙이 아니라 이미 쓰던 규칙을 인프라로 옮긴 것이다.
- 그래서 한 축을 다루던 사람이 다른 축으로 옮겨가도 무엇을 고정하고 무엇을 갈아 끼울지 나누는 방식이 똑같이 통한다.
- AI 전제: AI는 인프라의 진입장벽을 빠르게 낮추고 있고 명령어를 외우고 콘솔을 더듬는 일을 점점 대신하고 있어, 변경의 상당 부분을 이미 AI에게 맡기기 시작했다.
- 그럴수록 플랫폼팀이 붙잡아야 할 질문은 누가 바꾸느냐가 아니라 AI가 그 변경을 안전하게 스스로 테스트해 볼 수 있는가로 바뀐다.
- 여섯 축이 깔아 주는 판: 환경이 브랜치로 표현되니 AI가 격리된 환경을 스스로 띄워 그 안에서 변경을 돌려 보고, 인프라가 테스트 가능하니 그 변경이 운영이 아니라 로컬과 격리 환경에서 먼저 실행되어 결과가 남으며, 경계가 선언적이니 동작 여부와 선언대로 반영됐는지를 사람과 AI가 같은 방식으로 확인한다.
- 무엇보다 변경이 잘못돼도 파장이 격리된 범위에 머물러, AI의 변경이 사람의 변경과 같은 안전망에 놓인다.
- dev 브랜치 폐지의 근거: 환경을 별도 브랜치로 나누면 사람도 가끔 브랜치를 헷갈리는데 에이전트는 그 실수를 훨씬 조용히, 훨씬 자주 저지를 수 있다. 브랜치 선택 자체를 없애고 어느 values 파일이냐는 선언만 남겨 에이전트가 실수할 여지를 설계에서 지웠다.
왜 읽나인프라를 코드로 다루는 규율을 세운 뒤 그 위에 AI 에이전트의 변경까지 얹으려는 플랫폼 엔지니어에게, 경계 분리가 실험 빈도와 안전망으로 이어지는 논리를 정리해 준다.
flex·
AWS Korea Tech·
GitLab Blog·