배포는 위험하다. 새 코드를 prod에 올리는 순간 무슨 일이 벌어질지 완전히는 알 수 없고, 문제가 생기면 롤백이라는 또 다른 배포를 해야 한다. 그런데 가만히 들여다보면, 우리가 prod에서 바꾸고 싶은 것의 상당수는 코드 자체가 아니다. "이 신기능을 켤까 끌까", "재시도 횟수를 3으로 할까 5로 할까", "이 프로모션을 사용자의 10%에게만 보여줄까". 이런 것들은 동작(behavior)의 변경이지 로직(logic)의 변경이 아니다. 그런데 전통적으로는 이 작은 동작 변경 하나를 위해서도 전체 코드 재배포를 거쳐야 했다.
AppConfig는 이 매듭을 푼다. 구성을 코드에서 분리해 외부 데이터로 만들고(configuration as data), 그 데이터를 코드 재배포 없이 점진적으로 바꾼다. 피처 플래그를 켜고, 임계값을 조정하고, 프로모션을 일부 사용자에게만 노출하는 일이 git push나 Lambda 재배포 없이 일어난다. 오늘은 이 configuration-as-data가 왜 강력한지, AppConfig의 5요소 구조가 왜 그렇게 나뉘었는지, 배포 전 검증(Validator)과 배포 중 자동 롤백(Monitor)이 어떻게 "구성 변경"을 "코드 배포만큼 안전하게" 만드는지, 그리고 Lambda Extension이 localhost:2772라는 작은 트릭으로 비용과 지연을 어떻게 줄이는지를 본다