그누보드5 미드레벨 트러블슈팅 면접

먼저 data/session 디렉토리의 세션 파일 생성 및 삭제 로그를 확인하고, 서버의 cron 작업 스케줄을 점검합니다. 오전 9시경 실행되는 세션 정리 스크립트나 tmp 파일 삭제 작업이 과도하게 세션을 삭제하고 있을 가능성이 높습니다. php.ini의 session.gc_probability, session.gc_maxlifetime 설정을 확인하고, 필요시 세션 저장 방식을 파일 기반에서 DB 기반(session_set_save_handler)으로 변경합니다. 또한 config.php의 G5_SESSION_TIME 설정과 실제 사용자 활동 패턴이 맞는지 검토하고, 로드밸런서 환경이라면 세션 공유 설정이 올바른지 확인합니다. 재발 방지를 위해 세션 모니터링 로그를 추가하고, cron 작업 시간을 사용자 접속이 적은 새벽 시간대로 조정합니다.

먼저 EXPLAIN 명령으로 문제 쿼리의 실행 계획을 분석하여 Full Table Scan이 발생하는지 확인합니다. SHOW INDEX FROM 테이블명으로 인덱스 상태를 점검하고, Cardinality 값이 NULL이거나 비정상적으로 낮다면 인덱스 통계가 깨진 것이므로 ANALYZE TABLE 명령으로 재구성합니다. 즉각적인 조치로는 문제 게시판에 임시로 페이지당 게시글 수를 줄이고, 쿼리 캐시를 활성화합니다. 근본 원인으로는 wr_option 같은 TEXT 필드를 WHERE 절에서 사용하거나, 복합 검색 조건에 적절한 복합 인덱스가 없는 경우가 많습니다. 장기적으로는 게시판 테이블에 wr_num, wr_reply 등 정렬 조건에 맞는 복합 인덱스를 추가하고, 오래된 게시글은 아카이브 테이블로 분리하는 파티셔닝 전략을 수립합니다. 또한 adm/board_list.php에서 게시판별 인덱스 힌트를 추가하여 옵티마이저가 올바른 인덱스를 선택하도록 유도합니다.

첫 번째로 phpinfo()를 통해 upload_max_filesize, post_max_size, memory_limit, max_execution_time 값을 확인하고 충분한지 점검합니다. 두 번째로 웹서버(Apache/Nginx) 설정에서 client_max_body_size나 LimitRequestBody 값을 확인합니다. 세 번째로 data/file, data/cache, data/session 디렉토리의 권한이 707 또는 755이고 소유자가 올바른지 확인합니다. 네 번째로 df -h 명령으로 디스크 사용량을 점검하여 여유 공간이 충분한지 확인합니다. 간헐적 발생은 디스크 용량이 임계치 근처에 있거나, tmp 디렉토리의 inode가 부족한 경우가 많습니다. 해결책으로는 PHP 설정값을 적절히 상향 조정하고, 오래된 임시 파일과 썸네일 캐시를 정리하는 스크립트를 cron으로 등록합니다. 재발 방지를 위해 디스크 사용량 모니터링 알림을 설정하고, 파일 업로드 전 용량 체크 로직을 강화합니다.