개념
프로세스(Process) — 실행 중인 프로그램
프로그램을 실행하면 OS가 그 프로그램을 위한 프로세스를 만든다. 서버 애플리케이션이 "멈췄다", "재시작됐다", "메모리를 너무 많이 쓴다" 같은 현상은 전부 프로세스 수준의 이야기다.
- 프로세스가 죽는다(Crash) — 예상치 못한 오류로 프로세스 자체가 종료된다. 서버 로그에 "프로세스가 재시작됨" 기록이 남는다
- 메모리 누수(Memory Leak) — 프로세스가 시간이 지날수록 메모리를 계속 더 쓰다가, 결국 느려지거나 죽는다. "서버를 오래 켜두면 느려진다"는 버그의 흔한 원인
파일시스템(File System)
프로그램은 로그, 설정, 업로드된 파일 등을 디스크에 저장한다. 로그 파일이 어디에 저장되는지 아는 것만으로도, 개발자에게 "그 현상 재현될 때 로그 좀 보여주세요"라고 요청하는 대신 QA가 직접 로그를 열어 확인할 수 있다.
/var/log/app/error.log — 흔히 쓰이는 리눅스 서버의 로그 경로 예시권한(Permissions)
파일이나 리소스에 대해 "읽기(Read)", "쓰기(Write)", "실행(Execute)" 권한이 사용자/그룹별로 따로 설정된다. "이 파일에 접근할 수 없습니다" 같은 오류가 실제로는 애플리케이션 버그가 아니라, 서버의 파일 권한 설정 문제인 경우가 있다.
웹 서버가 업로드된 이미지를 저장하려는데, 그 폴더에 쓰기 권한이 없다면 "이미지 업로드가 계속 실패한다"는 버그로 나타난다 — 코드 로직 문제가 아니라 서버 환경(모듈 7 레슨 3)의 권한 설정 문제다.
환경변수(Environment Variables)
프로그램 실행 시 OS가 제공하는, 코드 밖에서 설정하는 값이다. API 키, 데이터베이스 접속 정보, 환경별(개발/스테이징/운영) 설정값을 여기 담는 경우가 많다. "스테이징에서는 되는데 운영에서는 안 된다"는 버그의 원인이 종종 환경변수 설정 차이다.
프로세스·파일시스템·권한을 연결해서 보기
버그를 진단할 때 "이게 코드 로직 문제인가, 아니면 OS/환경 수준의 문제인가"를 먼저 나눠보는 습관이 유용하다. 코드는 멀쩡한데 서버 환경(권한, 디스크 공간, 프로세스 메모리)이 문제인 경우, 아무리 코드를 들여다봐도 원인을 못 찾는다.
실무에서 왜 필요한가
"서버가 이상해요"라는 모호한 증상을 받았을 때, 프로세스가 죽었는지 (재시작 로그 확인), 디스크 공간이 부족한지, 특정 폴더 권한이 잘못됐는지를 스스로 1차 진단할 수 있으면 개발자에게 전달하는 정보의 질이 완전히 달라진다. 이건 모듈 6(레슨 2)에서 배운 "환경" 정보를 훨씬 구체적으로 채울 수 있게 해준다.