Immutable Infrastructure란 무엇인가?

Immutable Infrastructure(불변 인프라스트럭처)는 시스템 구성 변경 없이 새 이미지를 배포하는 방식으로, 운영 중 오류와 설정 누락을 방지하고 안정성을 극대화합니다.

2025년 05월 07일

Immutable Infrastructure란 무엇인가?

IT 인프라를 관리하고 운영하는 방식에 대한 고민은 기술의 발전과 함께 끊임없이 진화해 왔습니다. 특히 동적으로 변화하는 클라우드 환경과 마이크로서비스 아키텍처(MSA)가 보편화되면서, 기존의 방식으로는 해결하기 어려운 문제들에 직면하게 되었죠. Immutable Infrastructure(불변 인프라)는 이러한 현대적인 IT 환경의 요구에 부응하기 위해 등장한 강력하고 효과적인 패러다임입니다.

Immutable이란 단어는 ‘변경 불가능하다’는 의미를 가지는 형용사로, Mutable(변경 가능)과 반대되는 단어입니다.

Immutable Infrastructure란, 한 번 배포된 인프라 구성 요소(서버, 컨테이너 등)는 운영 중에 절대로 변경되지 않는다는 원칙에 기반한 인프라 관리 방식을 의미합니다. 마치 컴파일된 소프트웨어 바이너리처럼, 일단 생성되고 나면 그 상태를 수정하지 않는다는 개념입니다. 만약 시스템 업데이트, 설정 변경, 또는 애플리케이션의 새 버전 배포가 필요하다면 어떻게 할까요? 기존 인프라를 직접 수정하는 대신, 변경 사항이 적용된 새로운 버전의 인프라 구성 요소를 완전히 새로 생성하여 기존 버전을 대체합니다.

이해를 돕기 위해 예를 들어 보겠습니다. 전통적인 방식(Mutable Infrastructure)에서는 웹 서버의 설정을 변경해야 할 때, 운영 중인 서버에 직접 접속하여 설정 파일을 수정하고 서비스를 재시작하는 방식을 사용했습니다. 하지만 Immutable Infrastructure에서는, 변경된 설정이 포함된 새로운 서버 이미지(예: 가상 머신 템플릿, 컨테이너 이미지)를 만듭니다. 그리고 이 새로운 이미지로부터 새로운 서버 인스턴스들을 생성하여 트래픽을 전환한 뒤, 기존의 구버전 인스턴스들은 폐기(destroy)합니다.

이러한 접근 방식의 핵심은 ‘변경’ 대신 ‘대체’를 사용한다는 점입니다. 이를 통해 인프라의 상태를 예측 가능하고 일관성 있게 유지할 수 있으며, 배포 과정에서 발생할 수 있는 수많은 잠재적 오류와 복잡성을 근본적으로 제거할 수 있습니다. 마치 버전 관리 시스템(Git 등)에서 코드 변경 이력을 관리하듯, 인프라의 각 상태를 명확한 버전(이미지)으로 관리하게 되는 셈입니다. 따라서 Immutable Infrastructure는 단순히 기술적인 구현 방식을 넘어, 인프라를 바라보는 철학의 전환이라고 할 수 있습니다.

Immutable Infrastructure라는 용어는 누가 언제 왜 사용했는가?

Immutable Infrastructure라는 개념 자체는 특정 인물이 단독으로 발명했다기보다는, 클라우드 컴퓨팅과 자동화 기술의 발전 과정에서 자연스럽게 부상한 아이디어에 가깝습니다. 하지만 이 용어를 대중화하고 그 중요성을 강조하는 데 결정적인 역할을 한 인물과 시점이 있습니다.

Chad Fowler는 2013년에 열린 ‘Flowcon’ 컨퍼런스에서 “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components”라는 제목의 강연을 통해 이 개념을 널리 알린 것으로 평가받습니다. 그는 이 강연에서 기존의 서버 관리 방식, 즉 운영 중인 서버에 접속하여 패치를 적용하고 설정을 변경하는 방식(Mutable Infrastructure)이 얼마나 많은 문제를 야기하는지를 지적했습니다. 서버마다 미묘하게 다른 설정이 적용되는 ‘설정 드리프트(Configuration Drift)’ 현상, 예측 불가능한 오류, 복잡한 롤백 절차 등이 대표적이었죠.

Fowler는 이러한 문제들의 근본적인 해결책으로, 한 번 배포된 서버는 절대 수정하지 않고, 변경이 필요할 때는 완전히 새로운 서버로 교체하는 ‘Immutable’ 접근 방식을 제안했습니다. 마치 가축(Pets)처럼 애지중지 관리하던 서버를, 필요에 따라 쉽게 교체할 수 있는 가축 떼(Cattle)처럼 취급하자는 비유를 들기도 했습니다. 이는 특히 대규모 인프라를 운영해야 하는 웹 스케일 기업들에게 큰 공감을 얻었습니다.

이 개념이 주목받게 된 이유는 명확합니다.

클라우드 컴퓨팅의 성숙: AWS, Azure, GCP와 같은 퍼블릭 클라우드는 API를 통해 인프라 자원을 프로그래밍 방식으로 생성하고 파괴하는 것을 매우 용이하게 만들었습니다. 이는 인프라를 ‘대체’하는 비용을 획기적으로 낮추어 Immutable 패턴을 실현 가능한 옵션으로 만들었습니다.
자동화 도구의 발전: Chef, Puppet, Ansible과 같은 구성 관리 도구들이 등장했지만, 이를 Mutable 방식으로 사용할 경우 여전히 설정 드리프트의 위험이 존재했습니다. 이후 Packer와 같은 이미지 생성 도구, Terraform, CloudFormation과 같은 Infrastructure as Code(IaC) 도구, 그리고 Docker와 Kubernetes와 같은 컨테이너 기술의 등장은 Immutable 패턴을 구현하는 강력한 기술적 기반을 제공했습니다.
분산 시스템 및 MSA의 복잡성 증가: 수많은 서비스가 서로 통신하는 MSA 환경에서는 각 서비스 인스턴스의 일관성을 보장하는 것이 매우 중요해졌습니다. Immutable Infrastructure는 모든 인스턴스가 동일한 이미지로부터 생성되도록 보장함으로써 이러한 일관성을 달성하는 가장 확실한 방법 중 하나였습니다.

결론적으로, Immutable Infrastructure라는 용어는 Chad Fowler 등에 의해 2010년대 초반에 널리 알려지기 시작했으며, 이는 클라우드 기술의 발전과 대규모 분산 시스템 운영의 복잡성 증가라는 시대적 요구에 부응하여 등장한 필연적인 패러다임이라고 할 수 있습니다.

Phoenix Server vs. Snowflake Server 비교

사실 Immutable Infrastructure 라는 용어가 등장하기 전부터도 업계에는 비슷한 아이디어가 논의되고 있었습니다. 마틴 파울러(Martin Fowler)는 2012년 블로그 글 “Phoenix Server”에서“서버를 불사조처럼 주기적으로 태워 없애고 새로 띄우는 것이 구성 드리프트를 막는 좋은 방법”이라고 언급했습니다.

Phoenix Server란 무엇인가?

이 개념은 서버를 불사조(Phoenix)처럼 다루자는 비유에서 비롯되었습니다.

서버를 정기적으로 파괴하고 동일한 상태로 재생성함으로써 구성 드리프트(configuration drift)를 방지하고, 서버의 상태를 항상 예측 가능하고 일관되게 유지하자는 철학입니다. 이는 특히 클라우드 환경에서 자동화된 인프라 관리와 배포를 가능하게 하며, 시스템의 안정성과 보안성을 높이는 데 기여합니다.

여기서 말하는 구성 드리프트(configuration drift)란 시간이 지나면서 여기저기 적용된 사소한 변경들이 축적되어, 결국 서버 설정이 처음 의도와 달라지는 현상을 의미합니다. 파울러는 서버를 주기적으로 처음부터 다시 구축함으로써 이러한 드리프트를 방지하고, 일관된 상태를 유지할 수 있다고 강조했습니다.

이러한 접근 방식은 이후 불변 인프라(Immutable Infrastructure) 개념의 발전에도 큰 영향을 미쳤으며, 현대의 DevOps 및 클라우드 네이티브 환경에서 널리 채택되고 있습니다.

Snowflake Server란 무엇인가?

“Snowflake Server”는 서버 관리 및 운영 분야에서 사용되는 용어로, 각 서버가 독특하게 구성되어 동일한 설정을 가진 서버를 재현하거나 복제하기 어려운 상태를 의미합니다. 이는 마치 눈송이(snowflake)처럼 각각의 서버가 고유한 특성을 지니고 있어, 일관된 관리와 자동화에 어려움을 초래하는 상황을 비유적으로 표현한 것입니다.

“Snowflake Server”라는 용어는 2004년에 발간된 『The Visible Ops Handbook』에서 처음 사용된 것으로 알려져 있습니다. 이 책은 IT 운영에서의 모범 사례와 효율적인 변경 관리를 다루며, 일관되지 않은 서버 구성이 운영 효율성을 저해할 수 있음을 강조합니다. (자료출처 : Misman – 네이버 블로그)

Snowflake Server의 정의와 문제점

“Snowflake Server”는 서버의 구성이나 설정이 수동으로 변경되거나 문서화되지 않아, 동일한 환경을 다시 구축하거나 다른 서버에 동일한 구성을 적용하기 어려운 상태를 말합니다. 이러한 서버는 다음과 같은 문제점을 야기할 수 있습니다: (자료출처 : Misman – 네이버 블로그)

재현성 부족: 동일한 서버 환경을 다시 만들기 어려워 테스트나 복구가 복잡해집니다.
유지보수 어려움: 구성이 문서화되지 않아 문제 발생 시 원인 파악과 수정이 어렵습니다.
확장성 제한: 동일한 구성을 가진 서버를 추가하기 어려워 시스템 확장이 제한됩니다.

Martin Fowler는 이러한 서버를 “스키 리조트에는 좋지만 데이터 센터에는 나쁜” 존재로 비유하며, 재현이 어렵고 변경에 취약하다고 설명합니다.

요약하면, Snowflake Server는 일관되지 않은 수동 구성으로 인해 관리와 확장이 어려운 서버를 의미하며, 이를 방지하기 위해 구성 관리 도구와 IaC 접근 방식을 활용한 자동화와 표준화가 중요합니다.

Immutable Infrastructure vs. Mutable Infrastructure 비교

Immutable Infrastructure의 장점을 더 명확히 이해하기 위해서는 전통적인 방식인 Mutable Infrastructure와 비교해 보는 것이 효과적입니다. 두 방식은 인프라 변경을 처리하는 근본적인 철학에서 차이를 보이며, 이는 운영 방식, 도구, 장단점 등 여러 측면에서 뚜렷한 대비를 이룹니다.

아래는 Immutable Infrastructure와 Mutable Infrastructure의 주요 차이점을 비교한 표입니다. 실무자와 IT 의사결정자가 빠르게 이해할 수 있도록 운영 방식, 재현성, 변경 처리, 보안, 유지보수 등 핵심 항목 중심으로 정리하였습니다.

구분	Immutable Infrastructure (불변 인프라)	Mutable Infrastructure (가변 인프라)
정의	배포 후 변경 없이 새로 생성하여 교체하는 방식	기존 인프라에 직접 패치 및 설정 변경을 적용하는 방식
변경 방식	변경 발생 시 새 이미지/컨테이너로 교체	운영 중인 서버에 직접 변경 적용 (SSH, 수동 작업 등)
CI/CD 연계	자동화된 파이프라인 중심, 빌드 → 테스트 → 배포 → 폐기 순환 구조	수동 배포 또는 구성관리 도구(Chef, Ansible)로 변경 적용
재현 가능성	항상 동일한 이미지로부터 생성되어 환경 일관성 보장	시간에 따라 상태가 달라져 동일 환경 재현 어려움
구성 드리프트 위험	없음 (이미지로부터 항상 동일하게 생성됨)	높음 (시간 경과에 따라 서버마다 설정 차이 발생 가능)
보안	패치나 설정 변경 시 전체 인프라를 재생성하므로 패치 누락 없음	일부 서버만 누락될 가능성, 핫픽스 누적 등으로 보안 취약점 잔존 가능
운영 복구	문제가 생기면 새 이미지로 즉시 교체 가능	문제 서버를 수동으로 디버깅하거나 수리해야 함
롤백 처리	이전 이미지로 신속하게 롤백 가능	롤백 위해 수동 복구 또는 스냅샷 복원이 필요
자동화 수준	이미지 생성 및 배포 자동화가 기본 전제	자동화 도구가 있더라도 수동 개입이 많고 예외 상황 대응 어려움
운영 효율성	운영 일관성 확보, 대규모 인프라에도 동일한 방식 적용 가능	운영 환경이 다양해질수록 관리 복잡도 증가
학습 곡선 및 초기 진입 장벽	CI/CD, IaC, 이미지 빌드 등 초기 설정 필요	초기에는 진입 장벽 낮지만 장기적 운영비용 및 리스크 증가
대표 기술	Packer, Docker, Kubernetes, Terraform, Argo CD	Ansible, Chef, Puppet, 수동 SSH 작업 등
적합한 환경	클라우드 네이티브, MSA, 빠른 배포/복구가 중요한 환경	레거시 시스템, 변경이 적고 안정성이 중요한 환경

Mutable Infrastructure는 오랫동안 사용되어 온 익숙한 방식이지만, 시스템 규모가 커지고 변화의 속도가 빨라지면서 그 한계가 명확해졌습니다. 특히, ‘Configuration Drift’는 눈에 보이지 않게 시스템의 안정성을 저해하는 주범이 되곤 했습니다. 서버마다 적용된 패치나 설정이 미묘하게 달라지면서 예측 불가능한 장애로 이어지는 경우가 많았죠. 배포나 롤백 과정 역시 운영 중인 시스템을 직접 건드려야 하므로 상당한 부담과 위험을 동반했습니다.

반면, Immutable Infrastructure는 이러한 문제들을 근본적으로 해결하기 위한 접근법입니다. 모든 변경이 이미지 빌드라는 통제된 프로세스를 통해 이루어지고, 배포는 단순히 검증된 이미지를 기반으로 한 인스턴스 교체 작업이 됩니다. 이는 마치 소프트웨어 개발에서 버전 관리를 통해 코드의 안정성과 추적성을 확보하는 것과 유사한 이점을 인프라 영역에 가져다줍니다.

물론 Immutable Infrastructure에도 고려해야 할 점은 있습니다. 모든 변경마다 새로운 이미지를 빌드해야 하므로, 아주 작은 변경이라도 이미지 생성 및 배포 시간이 소요될 수 있습니다. 또한, 데이터베이스와 같이 상태를 지속적으로 유지해야 하는 구성 요소에 대해서는 별도의 관리 전략(예: 외부 볼륨 사용, 관리형 서비스 활용)이 필요합니다. 하지만 이러한 고려 사항들은 현대적인 클라우드 환경과 자동화 도구를 통해 충분히 관리 가능하며, Immutable Infrastructure가 제공하는 안정성, 일관성, 예측 가능성이라는 막대한 이점에 비하면 충분히 감수할 만한 부분입니다.

클라우드 네이티브 환경에서의 Immutable Infrastructure와 자동화·효율성

클라우드 네이티브 환경에서 불변 인프라는 자동화된 운영의 핵심 원리로 자리매김하고 있습니다. 이는 CI/CD 파이프라인, 배포 자동화, 운영 단순화, 보안 강화 측면에서 크게 기여하여 현대적인 IT 인프라 운영을 가능하게 합니다. 특히 Kubernetes 및 마이크로서비스 아키텍처(MSA)와도 깊은 관련이 있어, 클라우드 네이티브의 기본 철학을 구현하는 기반이 됩니다. 아래에서는 각 측면 별로 불변 인프라의 기여를 살펴보겠습니다.

지속적 통합/배포(CI/CD)와 일관성: 불변 인프라는 코드와 이미지를 통해 시스템 환경을 구성하므로, CI/CD 파이프라인과 긴밀하게 연계됩니다. 애플리케이션 코드가 변경되면 자동으로 새로운 서버 이미지 또는 컨테이너를 빌드하고 테스트한 뒤 배포하는 지속적 배포가 가능한데, 이러한 자동화 파이프라인 덕분에 배포가 일상적이고 안정적으로 이루어지며 운영 환경에서 실패가 줄어듭니다. 모든 변경 사항은 소스 코드 레포지토리와 CI/CD 시스템에서 버전으로 관리되기 때문에, 누가 언제 어떤 변경을 배포했는지 추적이 용이합니다. 예를 들어 개발팀은 새로운 코드를 커밋하면 CI 서버가 애플리케이션을 포함한 이미지를 빌드하고, 검증을 거친 후 프로덕션에 배포까지 자동 수행하게 설정할 수 있습니다. 결과적으로 사람의 개입 없이도 신속한 일관된 배포가 가능해져 DevOps의 “짧은 릴리스 주기”를 구현할 수 있습니다.

배포 자동화와 운영 단순화: 불변 인프라에서는 “수정하지 말고 교체하라”는 원칙에 따라 모든 배포가 자동화되어 진행됩니다. 새로운 버전의 애플리케이션을 배포할 때, 기존 서버를 수동으로 업그레이드하는 대신 사전에 빌드된 표준 이미지를 사용하여 새로운 인스턴스를 생성하고 애플리케이션을 구동한 뒤, 일정 시간이 지나거나 트래픽을 새 인스턴스로 전환하면 이전 인스턴스를 제거합니다. 이러한 과정은 Terraform 등의 Infrastructure as Code 도구와 연계되어 스크립트로 실행되거나, 컨테이너 환경에서는 쿠버네티스가 자동으로 관리합니다. 예를 들어 쿠버네티스에서는 새로운 애플리케이션 버전을 배포하면 기존 컨테이너와 병행하여 새 컨테이너를 기동하고, 서비스 트래픽을 점진적으로 새 컨테이너로 넘긴 뒤 이전 컨테이너를 종료하는 방식을 취합니다. 이처럼 인간의 개입 없이 표준화된 절차에 따라 배포되므로 오류 발생 가능성이 크게 줄고, 운영자가 일일이 서버 상태를 추적하거나 수동으로 수정할 필요가 없습니다. 결과적으로 수십~수백 대 이상의 대규모 서버 플릿(fleet)도 소수의 스크립트와 도구로 관리되어 운영이 단순화됩니다. 관리자 입장에서는 개별 서버보다 템플릿(이미지)과 배포 파이프라인 관리에 집중하면 되므로, 표준화된 운영이 가능해집니다.

운영 효율과 확장성: 불변 인프라는 클라우드 환경의 탄력적 확장성(Scalability)을 최대한 활용할 수 있게 합니다. 미리 준비된 이미지로부터 신규 인스턴스를 언제든 똑같이 복제하여 만들 수 있으므로, 트래픽 증가 시 동일한 서버를 다수 빠르게 증설하는 것이 쉽습니다. 이를 통해 자동 확장(auto-scaling) 시에도 각 인스턴스의 환경 차이 없이 균일한 성능과 동작을 기대할 수 있습니다. 반면 전통적 방식에서 수십 대의 서버를 수동으로 일일이 설정했을 때 발생할 수 있는 사소한 설정 차이, 누락 등을 불변 인프라에서는 걱정하지 않아도 됩니다. 또한 새로운 인스턴스를 생성하고 이전 것을 버리는 작업을 반복하는 자동화 루틴을 구축하면, 클라우드 사업자의 인프라 유지보수(예: 호스트 서버 재부팅)나 장애 상황에서도 서비스를 구성하는 VM/컨테이너가 자동 치유(self-healing)되어 운영 연속성을 높입니다. 이러한 자동 복구 메커니즘은 특히 마이크로서비스처럼 구성 요소가 많은 시스템에서 부분 장애에 대한 회복력(resilience)을 높여줍니다.

보안성 강화: 보안 측면에서 불변 인프라는 매우 큰 장점을 제공합니다. 변경 불가능한 서버는 운영 중 수동으로 패치를 적용하거나 설정을 바꾸는 일이 없으므로, 시간이 지나면서 환경이 틀어지는 구성 편차(configuration drift)가 발생하지 않습니다. 이는 곧 모든 서버가 동일한 보안 설정과 패치 수준을 유지한다는 뜻이며, 보안 취약점의 주요 원인인 “설정 불일치”를 줄여줍니다. 만약 새로운 취약점이나 보안 업데이트가 나오면, 운영 중인 서버를 하나씩 로그인하여 패치하는 대신 기본 이미지를 업데이트한 후 해당 이미지로 모든 인스턴스를 새로 교체합니다. 이렇게 하면 패치 누락 없이 전체 시스템을 최신 상태로 일괄 개선할 수 있고, 오래된 취약 이미지가 남아있지 않게 됩니다. 또한 인스턴스의 수명 주기가 짧고 주기적으로 재구축되다 보니, 공격자가 특정 서버를 장악해도 그 서버는 곧 교체되어 악성 침투 지속 시간이 제한되는 효과가 있습니다. 예컨대 넷플릭스와 같은 환경에서는 하루에도 여러 번 각 서버를 재생성하기 때문에, 공격자가 백도어를 심어도 몇 시간 이상 유지되기 어렵습니다. 더욱이 불변 인프라에서는 모든 변경이 중앙에서 통제되고 로그로 남기 때문에 이상 징후에 대한 모니터링이나 포렌식 분석도 용이합니다. 단, 불변 인프라라고 해서 보안을 완전히 신경 쓰지 않아도 되는 것은 아닙니다. 기본 이미지 자체에 대한 보안 강화와 안전한 CI/CD 파이프라인 운영은 필수적입니다. 하지만 전체적으로 볼 때 사람 손으로 각 서버를 관리하는 전통적 방식에 비해, 불변 인프라는 보다 표준화되고 통제된 방식으로 시스템 보안 상태를 유지할 수 있게 해줍니다.

쿠버네티스 및 MSA와의 연관성: 쿠버네티스(Kubernetes)는 불변 인프라 개념을 가장 잘 구현한 플랫폼으로 꼽힙니다. 실제로 “쿠버네티스 구현의 핵심 개념이 바로 Immutable Infrastructure”라는 말이 있을 정도로, 쿠버네티스는 컨테이너를 생성한 이후 그 컨테이너의 내부 상태를 변경하지 않는 철학을 따릅니다. 앞서 설명한 대로 쿠버네티스는 새로운 버전의 컨테이너를 배포하고 나면 기존 컨테이너를 건드리지 않고 그대로 두었다가 트래픽만 새 버전으로 돌린 후, 안정이 확인되면 이전 것을 폐기하는 롤링 업데이트 방식을 취합니다. 이를 통해 운영 중인 컨테이너를 직접 업데이트하는 일이 없으므로, 항상 깨끗한(new) 상태의 컨테이너만 실행되게 됩니다. 이러한 불변 인프라 기반의 운영 방식 덕분에, 마이크로서비스 아키텍처처럼 수많은 서비스 인스턴스가 수시로 업데이트되고 확장/축소되는 환경에서도 일관성과 안정성을 유지할 수 있습니다. 각 마이크로서비스를 하나의 이미지를 통해 독립적으로 배포하고 관리함으로써 서비스 간 간섭 없이 빠른 배포가 가능해지고, 이는 MSA의 민첩성(Agility과 격리성(Isolation) 요구사항을 충족시킵니다. 정리하면, 클라우드 네이티브 기술 스택 전반(예: 컨테이너, 오케스트레이션, 서비스 메ESH 등)에 불변 인프라 개념이 흐르고 있으며, 이것이 현대 대규모 시스템 자동화를 실현하는 원동력이 되고 있습니다.

마무리

불변 인프라는 오늘날 클라우드 네이티브, DevOps 환경의 필수 요소로 자리잡았습니다. 초기에는 새로운 도구 학습과 조직 문화의 변화가 필요하지만, 일단 정착하면 코드형 인프라와 CI/CD 자동화와 맞물려 개발부터 운영까지의 흐름을 혁신적으로 개선합니다. 특히 일관된 환경 보장, 자동화된 빠른 배포, 낮은 운영 리스크, 높은 보안 수준이라는 이점 덕분에, 현대의 IT 조직이 서비스 출시 속도를 높이면서도 안정성과 보안을 확보하는 데 큰 기여를 하고 있습니다. 요약하자면, Immutable Infrastructure로의 전환은 과거 수작업에 의존하던 인프라 운영 방식을 근본적으로 재고(rethink)하여 “변경은 코드로 관리하고, 운영 중인 시스템은 건드리지 않는다”는 철학으로의 변화를 의미합니다. 이러한 철학은 DevOps의 궁극적인 지향점과도 일치하며, 이미 많은 성공 사례를 통해 그 유효성이 입증되고 있습니다. 조직의 규모가 커질수록, 그리고 클라우드 상에서 민첩한 혁신을 추구할수록 불변 인프라는 더 이상 선택이 아닌 필수인 시대가 되고 있습니다.