Linux 개념 | 파일 디스크립터(File Descriptor, FD)란?

서버 튜닝하다 보면 꼭 나오는 단어가 있어요. 바로 파일 디스크립터(File Descriptor, FD).
근데 이름부터 살짝 딱딱하죠? 감으로만 “뭔가 자원 숫자겠지…” 하면서 넘어가기 쉽습니다.

이 글에서는 파일 디스크립터를 “서버가 들고 있는 번호표” 정도로 귀엽게 이해해볼게요.

---

1. 파일 디스크립터 = 열려 있는 것들의 번호표

리눅스 세계관에는 이런 말이 있어요. “Everything is a file”.
진짜로, 아래 것들이 다 파일처럼 취급됩니다.

• 로그 파일
• 사용자와의 네트워크 연결(소켓)
• 프로세스끼리 주고받는 파이프
• 디바이스(예: /dev/…)

그리고 이런 것 하나하나에 “번호표”를 붙여서 관리하는데,
그 번호표가 바로 파일 디스크립터(FD)입니다.

# 예를 들어,
# - 파일 하나 열면: FD 하나 사용
# - 소켓 하나 열면: FD 하나 사용
# - 연결 1만 개 열면: FD 1만 개 사용

 

그래서 접속자 수, 열려 있는 파일 수, 연결 수가 많아질수록 FD도 같이 늘어나요.

---

2. FD가 부족하면 무슨 일이 생길까?

서버 기본 설정은 보통 1024 같은 낮은 값으로 시작합니다.
개발 서버나 테스트 환경에서는 별 문제 없는데, 실서비스에서 트래픽이 몰리면…?

• 웹 서버: 새로운 연결을 못 받아서 502 / 504 에러
• DB나 메시지 브로커: Too many open files 에러
• 로그/수집 시스템: 새 파일·소켓을 못 열어서 수집 지연 또는 실패

즉, FD가 부족하면 서버가 “숨이 차서 더 못 뛰겠어…” 상태가 됩니다.

# 대표적인 에러 메시지
Too many open files
  

 

이 말을 인간 언어로 번역하면:
“더 이상 번호표를 줄 수가 없어, 그만 열어!” 정도라고 보면 됩니다.

---

3. 그래서 ulimit랑 무슨 사이냐?

ulimit는 “한 프로세스(또는 사용자)가 사용할 수 있는 번호표(FD)의 최대 개수”를 정하는 스위치입니다.

• fs.file-max : 서버 전체가 가질 수 있는 총 번호표 상한 (커널 전체 한도)
• ulimit -n : 로그인한 사용자/프로세스가 쓸 수 있는 번호표 상한

서버가 많은 연결을 받아야 하는데 ulimit -n이 1024로 묶여 있으면,
뒤에서 커널이 아무리 도와주고 싶어도 앞에서 문이 막혀 있는 것과 똑같아요.

그래서 운영할 때는 보통 이런 식으로 올립니다:

# 예시: limits.conf (사용자별 상한)
splunk soft nofile 100000
splunk hard nofile 100000
  

 

이런 설정을 해두면, 해당 사용자가 돌리는 프로세스들은
최대 10만 개까지 FD를 사용할 수 있는 여유로운 체력을 갖게 됩니다.

---

4. 보안 관점에서의 파일 디스크립터

“그럼 그냥 무한대로 열 수 있게 해두면 좋지 않을까?” 라는 생각이 슬쩍 들 수 있지만, 보안 쪽에서는 이렇게 생각합니다.

• 너무 낮으면: 정상 사용자도 금방 한도에 걸려서 서비스 장애 → 가용성(Availability) 문제
• 너무 높으면: 악의적인 사용자가 연결 폭탄을 터뜨려도 계속 받아줌 → DoS 공격에 취약

그래서 “실제 트래픽/서비스 특성에 맞춘 적당한 상한”을 잡는 게 중요합니다.
운영자 입장에서는 이게 일종의 보안·안정성 튜닝 레버가 되는 셈이죠.

---

5. 한 줄로 정리

파일 디스크립터는 “서버가 파일과 연결에 붙이는 번호표”이고,
ulimit는 “그 번호표를 한 프로세스가 몇 개까지 쓸 수 있는지 정하는 상한선”입니다.
서버가 숨 안 막히고, 또 공격에도 너무 쉽게 안 쓰러지게 하려면
이 번호표 개수를 “현실적인 여유 + 적당한 방어선” 수준으로 잘 맞춰주는 게 포인트입니다.