runtime-safe filesystem helper 정리

최근 open_basedir 제한 환경에서 dashboard API가 HTTP 500으로 중단되는 문제를 확인한 뒤, filesystem 접근 자체를 runtime-safe 방향으로 다시 정리하고 있습니다. 특히 운영 환경에서는: - open_basedir - restricted filesystem - shared hosting - hardened PHP-FPM - container/chroot - disabled shell_exec 등 다양한 제한 조건이 존재할 수 있기 때문에, filesystem probe 실패를 예외 상황이 아니라: "예상 가능한 runtime condition" 으로 다루는 방향을 중요하게 보고 있습니다. 현재 정리 중인 filesystem helper 방향은 다음과 같습니다. 1. 직접 filesystem 접근 최소화 다음 함수들은 운영 환경에 따라 실패 가능성이 있기 때문에: - file_exists() - is_readable() - file_get_contents() - disk_total_space() - disk_free_space() - shell_exec() 직접 호출보다는 wrapper/helper 형태로 보호하는 방향을 우선 검토 중입니다. 2. warning → ErrorException 전파 차단 현재 PHP warning이 Laravel ErrorException으로 전환되면서 API 전체 실패로 이어질 가능성이 있었습니다. 특히: - /proc 접근 제한 - restricted filesystem - open_basedir 환경에서는 warning 자체가 충분히 발생 가능한 상태라고 판단했습니다. 현재는: filesystem probe 실패 ≠ application failure 형태로 분리하는 방향을 계속 정리 중입니다. 3. fallback 우선 유지 현재는 일부 시스템 정보를 읽지 못하더라도: - HTTP 200 유지 - response shape 유지 - dashboard UI 유지 방향을 더 중요하게 보고 있습니다. 예: { "cpu": { "percentage": 0 }, "memory": { "percentage": 0, "used": "0 B", "total": "0 B" }, "disk": { "percentage": 0, "used": "0 B", "total": "0 B" } } 또는 unknown 상태 반환. 특히: "측정 실패" 와 "서비스 실패" 를 분리하는 방향을 중요하게 보고 있습니다. 4. writable path 명확화 runtime-safe 구조에서는: - storage - cache - session - log - upload temp 등 writable path를 명확하게 분리하는 것도 계속 정리 중입니다. 특히: - open_basedir - deploy bundle - symbolic link - restricted runtime 환경에서는 path consistency가 중요하다고 판단했습니다. 5. graceful degradation 우선 현재는 특정 기능 일부가 제한되더라도: - 관리자 기능 유지 - API 유지 - UI 유지 - queue 흐름 유지 를 우선하는 방향으로 구조를 계속 정리 중입니다. 특히 운영 환경 차이를: "특수 케이스" 가 아니라, "실제 운영에서 충분히 발생 가능한 runtime state" 로 다루는 방향을 중요하게 보고 있습니다. 추가로 현재 계속 확인 중인 항목: - queue worker runtime 제한 - WAN 분리 환경 - restricted PHP runtime - filesystem permission 제한 - disabled shell_exec - fallback serialization consistency 현재는 runtime-safe filesystem 접근과 graceful degradation 방향을 중심으로 계속 구조를 다듬고 있습니다.