[archive 전환] graceful degradation을 어디까지 허용해야 할까요

최근 open_basedir 제한 환경과 restricted runtime 환경을 계속 테스트하면서, graceful degradation 범위를 어디까지 허용해야 하는지 계속 고민 중입니다. 현재는: - filesystem 접근 실패 - system resource probe 실패 - 일부 queue worker 제한 - restricted PHP runtime - disabled shell_exec 같은 상황에서도: - HTTP 서비스 유지 - dashboard 유지 - API response shape 유지 - fallback 상태 유지 방향을 우선적으로 보고 있습니다. 예를 들면: 시스템 리소스를 읽지 못하더라도: { "cpu": null, "memory": null, "disk": null } 또는 fallback 상태를 유지하면서 관리자 기능 자체는 계속 사용 가능하도록 처리하는 방향입니다. 다만 운영 중 계속 고민되는 부분도 있습니다. 예를 들어: - 어디까지 fallback 처리할 것인가 - 어떤 경우에는 hard failure가 필요한가 - queue worker 제한을 어느 수준까지 허용할 것인가 - 관리자에게 어느 수준까지 warning을 노출할 것인가 - runtime restriction을 얼마나 예상 가능한 상태로 간주할 것인가 등입니다. 특히 restricted runtime 환경에서는: - open_basedir - restricted filesystem - shared hosting - hardened PHP-FPM - container/chroot 등이 실제 운영 환경에서 충분히 발생 가능한 조건이라고 보고 있습니다. 현재는: "일부 기능 실패" 와 "서비스 전체 실패" 를 최대한 분리하는 방향을 우선적으로 보고 있지만, 반대로 과도한 fallback이 실제 문제를 숨기는 방향이 될 가능성도 계속 고민 중입니다. 현재 운영 기준에서는: - graceful degradation - runtime-safe 처리 - fallback consistency - response shape 유지 - 관리자 UX 유지 를 우선적으로 정리 중인데, 실제 운영 환경에서는 어느 수준까지 degradation을 허용하는 게 적절할지 계속 고민 중입니다.