리눅스 서버에 늘 있는 그 폴더, lost+found는 대체 뭘 하는 곳일까

그 폴더, 본 적 있으시죠?

리눅스 서버를 만지다 보면 루트 디렉토리(/)나 디스크를 마운트한 곳에 lost+found라는 폴더가 떡하니 있는 걸 보게 돼요. 분명 내가 만든 적도 없고, 평소엔 텅 비어 있고, 지우려고 하면 왠지 찜찜하고. '이거 뭐지?' 하고 그냥 넘어간 분들 많을 거예요.

오늘은 이 미스터리한 폴더의 정체를 제대로 풀어볼게요. 알고 나면 '아, 이래서 있었구나' 싶을 거예요.

이게 뭐냐면, 파일들의 응급실이에요

결론부터 말하면, lost+found는 파일시스템이 망가졌을 때 주인을 잃은 파일 조각을 모아두는 응급실 같은 곳이에요.

조금 더 풀어볼게요. 리눅스에서 파일은 두 부분으로 나뉘어 저장돼요. 하나는 실제 데이터(파일 내용), 다른 하나는 inode(아이노드)라는 거예요. inode가 뭐냐면, '이 파일은 크기가 얼마고, 누가 주인이고, 실제 데이터는 디스크 어디에 있다'는 정보를 담은 명찰 같은 거예요. 그리고 우리가 보는 파일 이름은 디렉토리가 'OO이라는 이름은 몇 번 inode를 가리킨다'고 연결해주는 식으로 동작해요.

자, 그런데 서버가 갑자기 정전으로 꺼졌다고 해봐요. 파일을 쓰던 도중에 전원이 나가면, 데이터와 inode는 디스크에 남아 있는데 '이름표'와의 연결이 끊겨버리는 일이 생겨요. 명찰은 있는데 어느 디렉토리에도 소속되지 않은, 길 잃은 파일이 되는 거죠.

fsck가 길 잃은 파일을 데려와요

이때 등장하는 게 fsck(파일시스템 체크)예요. 부팅할 때 시스템이 디스크에 이상이 있다고 판단하면 fsck가 돌면서 파일시스템을 검사하고 복구해요. 이 과정에서 '주인은 없는데 데이터는 멀쩡한' inode들을 발견하면, 그냥 버리는 게 아니라 lost+found 폴더 안에 넣어둬요.

이때 원래 파일 이름은 알 수가 없어요(이름표와의 연결이 끊겼으니까요). 그래서 inode 번호를 그대로 파일 이름으로 붙여요. #1234 같은 식으로요. 그래서 복구된 파일은 이름만 봐서는 뭔지 모르고, 직접 열어봐서 '아 이게 그 설정파일이었네' 하고 알아내야 해요.

직접 만들면 안 돼요

재밌는 점이 하나 있어요. 이 폴더는 fsck가 복구할 때 즉석에서 만들 수가 없어요. 왜냐면 파일시스템이 망가진 상태에선 새 디렉토리를 만드는 것 자체가 위험하거든요. 그래서 ext 계열 파일시스템은 처음 포맷할 때부터 lost+found를 미리 만들어두고, 심지어 빈 공간을 미리 확보해둬요. 응급 상황에 쓸 자리를 미리 비워두는 거죠.

그래서 실수로 지웠다면 mklost+found라는 명령어로 다시 만들 수 있어요. 평소에 비어 있다고 지우지 마세요. 진짜 디스크 사고가 났을 때 여러분의 소중한 데이터를 건져줄 마지막 보루거든요.

참고로 이건 ext2/3/4 파일시스템의 특징이에요. 요즘 많이 쓰는 XFS나 Btrfs, ZFS 같은 최신 파일시스템은 복구 방식이 달라서 이 폴더를 같은 방식으로 쓰진 않아요. 그래도 여전히 많은 리눅스 서버가 ext4를 쓰니, 알아두면 두고두고 도움 돼요.

한국 개발자에게는

클라우드와 컨테이너 시대라 직접 디스크를 만질 일이 줄긴 했지만, 온프레미스 서버나 NAS, 라즈베리파이를 운영한다면 언젠가 마주칠 일이에요. 특히 갑자기 꺼진 서버를 부팅했더니 lost+found에 파일이 잔뜩 쌓여 있다면, 그건 '최근에 파일시스템이 손상됐고 복구가 일어났다'는 신호예요. 그냥 넘기지 말고 디스크 상태(SMART 정보)를 점검해보는 게 좋아요. 디스크 수명이 다 되어가는 전조일 수 있거든요.

마무리

한 줄로 정리하면, lost+found는 파일시스템이 깨졌을 때 주인 잃은 파일을 모아두는 안전망이에요. 평소엔 비어 있는 게 정상이고, 비어 있다고 절대 지우면 안 돼요. 여러분은 운영 중인 서버에서 갑작스러운 정전이나 강제 종료에 대한 대비를 어떻게 하고 계세요? 정기 백업 말고 파일시스템 차원의 대비도 한번 점검해보면 어떨까요?