[인프라를 소프트웨어처럼 2/5] 코드가 모르는 그 '환경'은 누가 만드는가

flex의 인프라 연재 2편으로, 코드가 '무엇을'만 정의하고 '어디서·언제·어떤 환경'은 바깥에서 주입한다는 원칙이 남긴 빈칸을 들여다본다. 밀어낸 책임은 사라지는 게 아니라 어딘가로 옮겨간다. values 파일이 가리키는 그 클러스터는 누가 띄웠고 Cloud Adapter가 호출하는 계정은 누가 만들었는지, 코드가 모른 척한 모든 '어디서'는 결국 플랫폼팀의 책상 위에 쌓인다.

핵심 포인트

같은 '환경'이라는 단어를 개발자는 계약으로 보고 플랫폼팀은 그 계약을 떠받치는 실체로 본다.
헥사고날의 언어로 환경은 약속된 모양의 구멍이고, 코드는 그 뒤가 무엇이든 알 필요가 없고 알아서도 안 된다.
플랫폼팀에게 같은 환경은 계약의 반대편이다. 클러스터·데이터베이스·네트워크·권한·비밀번호처럼 구멍 뒤에 들어가 진짜로 응답을 만드는 쪽이다.
계약의 반대편을 만드는 이 일이 오랫동안 "코드처럼 보이는 설정"에 머물러 있었다.
첫 번째 규율은 환경을 만드는 일을 "요청"이 아니라 "선언"으로 바꾸는 것이다.

상세 정리

다섯 축의 약속: 앞 화에서 코드는 무엇을만 정의하고 어디서·언제·어떤 환경은 바깥에서 주입한다는 원칙을 세웠고, 거기에 조용한 빈칸이 하나 있다고 예고했다.
그 빈칸의 정체: 다섯 축이 깔끔하게 밀어낸 모든 '바깥'이 플랫폼팀에게는 손으로 만들어야 하는 '안쪽'이라는 것이다.
개발자 관점의 환경: "이런 DB가 있고 이런 토픽이 있고 이 주소로 부르면 응답한다"는 계약이다. 그 모양만 알면 된다.
플랫폼팀 관점의 환경: 그 계약서의 빈 구멍 뒤를 전부 책임진다. 한쪽은 모양만, 다른 쪽은 속을 전부 다룬다.
같은 함정: 다섯 축이 코드 쪽에서 넘은 경계를 플랫폼팀은 실체 쪽에서 한 번 더 넘어야 했다.
설정의 한계: plan이 보여주는 건 이 설정이 바뀐다는 것이지 이 환경이 동작한다는 것이 아니다. 선언 파일이 수백, 수천 개로 늘어나도 서로 모순되지 않는다는 보장은 여전히 사람의 머릿속에만 있다.
적용 방식: 백엔드 연재가 코드에 적용한 원리를 환경에 그대로 적용해, 계약은 불변으로 두고 그 계약을 충족시키는 접점만 교체한다. 환경의 실체를 만든다는 건 배포의 values 파일과 클라우드의 Cloud Adapter처럼 교체되는 쪽을 손으로 채우는 일이다.
선언으로 바꾸는 이유: 사람이 콘솔을 클릭하거나 슬랙으로 부탁하는 대신 코드 한 조각을 선언하면 환경의 한 조각이 생기게 한다. 요청은 사람의 기억에 남고 선언은 git에 남으며, 이 차이가 생각보다 멀리 간다고 정리한다.

왜 읽나개발자가 환경을 추상화해 밀어낸 뒤 그 실체를 떠안게 된 플랫폼 팀에게, 같은 단어를 두 관점으로 나눠 보는 틀과 요청을 선언으로 바꾸는 첫 규율을 제시한다.

flex 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

[인프라를 소프트웨어처럼 2/5] 코드가 모르는 그 '환경'은 누가 만드는가

이 글과 비슷한

엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례