웹호스팅 inode란 무엇? 2M 제한이 Node.js에 중요한 이유

웹호스팅 사양을 보다가 “2M inode”라는 표기를 보셨나요? 아니면 서버에서 “용량은 남는데 파일이 안 만들어진다”는 에러를 만나셨나요? 그렇다면 이 글이 정확히 당신이 찾던 답입니다.

많은 분들이 웹호스팅을 선택할 때 용량(GB)만 봅니다. 하지만 실무에서는 용량만큼이나 inode 수가 중요합니다. 특히 Node.js를 사용하거나 자동화 블로그를 운영하는 경우 더욱 그렇습니다.

이 글에서는 inode가 정확히 무엇인지, 왜 2M이 의미있는 수치인지, 그리고 당신의 서버가 안전한지 확인하는 방법까지 쉽게 설명해드리겠습니다.

inode가 정확히 뭔가요? (도서관 비유로 쉽게 설명)

inode(Index Node)는 리눅스/유닉스 기반 시스템에서 파일의 정보를 저장하는 데이터 구조입니다. 좀 더 쉽게 말하면, 도서관의 도서 카드(카탈로그)라고 생각하면 됩니다.

당신이 도서관에 방문한다고 생각해봅시다. 책의 실제 내용은 책장에 있지만, 책을 찾기 위해서는 먼저 도서 카드를 봐야 합니다. 카드에는 책 제목, 저자, 출판일, 책장 위치 같은 정보가 적혀 있습니다.

inode도 정확히 같은 역할을 합니다.

• 파일의 실제 내용(데이터) = 책 자체의 글귀
• inode = 책의 제목, 저자, 출판일, 위치 정보가 담긴 카드
• 파일 이름 = 도서 카드의 ID 번호

inode에 담기는 정보들

파일을 생성할 때마다 다음 정보들이 inode에 저장됩니다.

중요한 점: 파일이 실제로 1MB, 100MB 크기든 관계없이 모든 파일마다 무조건 1개의 inode가 소비됩니다.

파일 개수와 용량은 왜 다를까?

이것이 사람들이 가장 헷갈리는 부분입니다.

당신의 서버 알림이 이런 식으로 나타난다고 해봅시다:

용량은 절반밖에 안 썼는데 inode는 거의 다 찼습니다!

왜 이런 일이 발생할까요?

대답은 간단합니다. 파일이 아주 많기 때문입니다.

예를 들어, WordPress 설치 = 약 1,472개 파일 (용량 약 100MB)
반면, React 프로젝트의 node_modules = 약 43,545개 파일 (용량 약 300MB)

똑같이 300MB 정도의 용량이지만, 파일 개수는 30배 차이입니다!

실제 비교해보면 이렇습니다

결론: 용량이 충분해도 파일이 너무 많으면 inode 부족으로 서버가 멈춥니다.

node_modules가 inode를 왜 이렇게 많이 써요?

Node.js 개발자라면 피할 수 없는 문제입니다. npm install을 한 번만 해도 수만 개의 파일이 생깁니다.

왜 그럴까요?

1. 패키지 간의 의존성
A라는 라이브러리가 필요해서 설치했는데, A가 B, C, D에 의존하고 있습니다. B는 또 E, F, G에 의존합니다. 이렇게 의존성 체인이 길어지면서 수천 개의 패키지가 설치됩니다.

2. 각 패키지마다 개별 폴더 생성
단순히 코드 파일만 있는 게 아닙니다. package.json (메타데이터), README (설명 문서), LICENSE (라이선스), .git 관련 파일들 (버전 관리) 등이 각각 따로따로 inode를 소비합니다.

실제 숫자로 보면

만약 동시에 5개 프로젝트를 운영한다면?

135,000 × 5 = 675,000개 inode 소비

이제 2M inode의 의미가 보이나요?

2M inode 제한은 어느 정도 수준인가?

2M = 2,000,000개의 파일을 최대 생성할 수 있다는 뜻입니다.

이게 충분한가요? 부족한가요?

실제 시나리오로 계산해봅시다

시나리오 1: 블로그 운영자

• WordPress 설치: 1,500개
• 플러그인 20개: 50,000개
• 캐시 파일: 100,000개
• 이미지/미디어: 50,000개
• 총: 약 201,500개 (2M 중 10%)

✓ 여유 있음! 안심하고 운영 가능

시나리오 2: Node.js 자동화 서버

• n8n 설치: 50,000개
• 기본 모듈: 100,000개
• 프로젝트별 node_modules (5개): 500,000개
• 로그 파일들: 200,000개
• 총: 약 850,000개 (2M 중 42.5%)

✓ 여전히 여유 있음! 안심하고 사용 가능

시나리오 3: 대규모 자동화 크롤링 서버

• 기본 설정: 150,000개
• 복잡한 자동화 프로젝트 (10개): 1,200,000개
• 임시 캐시/로그: 500,000개
• 총: 약 1,850,000개 (2M 중 92.5%)

⚠ 위험 신호! 용량 정리 필요

결론: 2M inode는 개인용, 중소규모 자동화 운영자에게는 매우 넉넉한 수준입니다. 파일 개수 걱정 없이 복잡한 라이브러리를 마음껏 설치해도 된다는 신호입니다.

서버에서 inode 사용량 확인하는 법 (명령어 포함)

이론은 충분합니다. 이제 실제로 당신의 서버가 어떤 상태인지 확인해봅시다.

방법 1: cPanel 대시보드에서 확인 (가장 쉬움)

웹호스팅 제공사(카페24, 가비아, 호스팅어 등)의 cPanel에 로그인하면 대부분 다음 정보가 표시됩니다.

그냥 이 화면만 봐도 충분합니다.

방법 2: SSH로 직접 확인 (더 정확함)

SSH 접속 후 터미널에서 다음 명령어를 입력하세요.

결과는 이런 식으로 나타납니다.

각 항목의 의미:

• Inodes: 전체 inode 수 (보통 2,000,000)
• IUsed: 현재 사용 중인 inode (201,500)
• IFree: 남은 inode (1,798,500)
• IUse%: 사용률 (10%)

위험 신호:

• IUse%가 70% 이상: 주의 필요
• IUse%가 90% 이상: 긴급 조치 필요
• IUse%가 100%: 파일 생성 완전 불가

방법 3: 디렉토리별로 파일 개수 확인

어느 폴더가 inode를 가장 많이 쓰는지 알고 싶다면?

이 명령어는 현재 디렉토리에서 파일이 가장 많은 폴더 10개를 보여줍니다.

결과 예시:

inode 부족 시 해결 방법 5가지

만약 IUse%가 85% 이상이라면 지금 바로 조치해야 합니다.

방법 1: 불필요한 파일 정리 (가장 효과적)

node_modules 재설치

가장 간단하고 효과적입니다.

이렇게 하면 불필요한 중복 파일들이 제거되고 30~40% 정도 inode를 줄일 수 있습니다.

방법 2: 캐시 파일 삭제

방법 3: 오래된 이미지/미디어 삭제

방법 4: Yarn Berry로 마이그레이션

Yarn Berry는 node_modules를 Zip 파일로 압축해서 관리합니다.

일반 node_modules: 135,000개 파일 (1.2GB)
Yarn PnP: 2,000개 파일 (139MB)

파일 개수를 98% 줄일 수 있습니다!

방법 5: 웹호스팅 업그레이드

위 방법들로도 부족하다면 더 높은 사양의 호스팅으로 옮겨야 합니다.

일반적으로:

• 기본형: 2M inode
• 프리미엄형: 5M~10M inode
• 엔터프라이즈형: 무제한 또는 매우 높음

자동화 블로그 운영자라면 2M inode가 왜 좋을까?

이제 여기가 중요합니다.

혹시 당신이 Make, n8n, Zapier 같은 자동화 도구를 사용해서 블로그를 운영하고 있다면? 또는 웹 크롤러를 실행해서 매분, 매시간 데이터를 수집하고 있다면?

2M inode가 왜 중요한지 알 수 있습니다.

실제 상황: 자동화 블로그 운영

당신의 n8n 워크플로우가 다음과 같이 동작한다고 가정합시다.

문제: 크롤링된 데이터와 로그 파일이 엄청나게 쌓입니다.

• 매시간 크롤링 로그: 100개 파일 (1시간마다)
• 이미지 캐시: 10개 (매번 생성)
• 임시 JSON 파일: 50개 (처리 중간에 생성)
• 재시도 로그: 20개

하루에만: 100 × 24 + (10 × 24) + (50 × 24) + (20 × 24) = 약 5,280개 파일

일 주일: 36,960개
한 달: 158,400개
일 년: 1,927,200개

일반적인 웹호스팅이라면? inode 부족으로 서버가 주기적으로 멈춥니다.

하지만 2M inode가 충분히 확보되어 있다면? 1,927,200 / 2,000,000 = 96.4% 사용 → 여전히 안전 범위 내입니다!

게다가 주기적으로 오래된 로그를 삭제하면 더욱 안정적으로 운영할 수 있습니다.

역으로 생각해보면

일반 웹호스팅 (500K~1M inode)에서는 자동화 크롤러를 장기간 운영하기가 매우 어렵습니다.

2~3개월 정도만 지나면 inode가 꽉 차서 자동화가 멈추기 일쑤입니다.

하지만 2M inode 호스팅을 선택하면?

이제 이해가 되나요? 자동화 블로그 운영자에게 2M inode는 필수사항입니다.

최종 정리: 당신의 서버는 안전한가?

지금까지 배운 내용을 정리하면:

다음 단계:

1. 지금 바로 확인해보세요. df -i 명령어로 IUse% 확인
2. 70% 이상이라면 조치하세요. node_modules 재설치 또는 캐시 삭제
3. 자동화를 계획 중이라면 2M 이상 inode 호스팅을 선택하세요

이제 당신은 inode의 정체를 완벽히 이해했습니다!