컨테이너는 "내 노트북에서는 되는데 서버에서는 안 된다"는 오래된 고통을 끝내려고 등장했다. 애플리케이션과 그것이 의존하는 라이브러리, 런타임, 환경 변수를 하나의 이미지로 봉인해서, 어디서 실행하든 똑같이 동작하게 만든다. 그런데 컨테이너 하나를 만드는 것과 수백 개의 컨테이너를 여러 서버에 걸쳐 띄우고, 죽으면 다시 살리고, 트래픽에 맞춰 늘렸다 줄이는 것은 완전히 다른 문제다. 이 "여러 컨테이너를 조율하는 일"이 컨테이너 오케스트레이션(container orchestration)이고, Amazon ECS는 AWS가 내놓은 답이다. Fargate는 거기서 한 걸음 더 나아가 "그 컨테이너를 올릴 서버조차 네가 관리하지 마라"는 서버리스 컨테이너 모델이다.
DVA-C02에서 ECS/Fargate/ECR은 배포(Deployment) 도메인의 핵심이다. 단순 암기(awsvpc 모드, executionRole vs taskRole)도 나오지만, 그보다 "왜 Fargate가 awsvpc만 강제하는가", "executionRole과 taskRole을 헷갈리면 어떤 에러가 나는가", "ECR pull이 실패하는 근본 원인" 같은 동작 원리를 묻는 시나리오가 더 자주 나온다. 이번 글은 컨테이너 격리가 리눅스 커널의 어떤 기능에서 나왔는지, ECS의 제어 평면과 데이터 평면이 어떻게 분리되는지, Fargate가 어떤 격리 기술로 "서버리스"를 실현하는지, 그리고 두 IAM 역할이 갈라지는 근본 이유를 깊이 파고든다.