리눅스 면접 질문: 답변과 함께 보는 24가지 질문

리눅스 질문은 DevOps 엔지니어, 시스템 관리자, SRE, 백엔드 개발자의 면접에서 자주 나옵니다. 면접관은 옵션을 외우기를 기대하지 않습니다. 시스템을 이해하고 있는지, 문제의 원인을 찾을 수 있는지를 보고 싶어 합니다. 아래는 기초부터 진단까지 리눅스 면접에서 가장 자주 나오는 질문을 명령어와 함께 정리한 것입니다.

팁: 답할 때는 주장을 확인할 명령도 함께 말하세요. «ss -tlnp로 확인하겠습니다»라고 말하는 것이 막연한 설명보다 훨씬 설득력이 있습니다.

파일 시스템

1. FHS가 무엇이며 주요 디렉터리에는 무엇이 있나요?

FHS(Filesystem Hierarchy Standard)는 디렉터리의 위치를 정한 표준입니다. 전체 트리는 루트 /에서 시작하며, 드라이브 문자는 없습니다. 다른 파일 시스템은 트리의 디렉터리에 마운트됩니다.

• /etc — 시스템과 서비스의 설정;
• /var — 변하는 데이터: 로그(/var/log), 캐시, 큐, 데이터베이스;
• /home — 사용자 홈 디렉터리, /root — root의 홈 디렉터리;
• /usr — 프로그램과 라이브러리; 최신 배포판에서 /bin과 /sbin은 보통 /usr/bin, /usr/sbin으로 연결됩니다;
• /tmp — 임시 파일, /boot — 커널과 부트로더;
• /proc와 /sys — 프로세스와 커널 정보를 담은 가상 파일 시스템, /dev — 장치 파일.

2. inode란 무엇인가요?

inode는 파일의 메타데이터를 담는 파일 시스템 구조입니다: 종류, 권한, 소유자, 크기, 시간 정보, 하드 링크 수, 데이터 블록을 가리키는 포인터. inode에는 파일 이름이 없습니다. 이름은 디렉터리에 «이름 → inode 번호» 항목으로 저장됩니다.

inode 번호는 ls -i로, 자세한 정보는 stat file로 봅니다. 파일 시스템의 inode 개수는 제한되어 있고, df -i는 얼마나 쓰였는지 보여 줍니다. 그래서 전형적인 상황이 생깁니다: «디스크는 여유가 많은데 파일을 만들 수 없다» — 수백만 개의 작은 파일이 inode를 다 써 버린 것입니다.

3. 하드 링크와 심볼릭 링크는 어떻게 다른가요?

하드 링크(ln file link)는 같은 inode에 붙은 또 하나의 이름입니다. 두 이름은 동등하며, 데이터는 링크 수가 0이 될 때만 지워집니다. 제약: 디렉터리에는 하드 링크를 만들 수 없고, 같은 파일 시스템을 벗어날 수 없습니다.

심볼릭 링크(ln -s target link)는 자기 inode를 가진 별도의 파일이며, 그 안에 대상의 경로가 적혀 있습니다. 디렉터리나 다른 파일 시스템을 가리킬 수 있지만, 대상을 지우거나 옮기면 «깨집니다».

4. 디스크는 꽉 찼는데 du는 df보다 적게 나옵니다. 왜인가요?

가장 흔한 원인은 파일이 삭제되었지만 어떤 프로세스가 아직 열어 두고 있는 경우입니다. 예를 들어 실행 중인 서비스의 큰 로그를 지운 경우입니다. 이름이 이미 없으므로 du는 보지 못하지만, 블록은 여전히 점유되어 있고 df는 이를 셉니다.

이런 파일을 찾으려면 lsof +L1 또는 lsof | grep deleted를 씁니다. 해결: 프로세스를 다시 시작하거나, 파일 디스크립터를 통해 파일을 잘라 냅니다: : > /proc/PID/fd/N. 앞으로는 로그를 rm이 아니라 truncate나 logrotate로 정리하세요.

5. 리눅스는 어떻게 부팅되나요?

펌웨어(BIOS 또는 UEFI)가 하드웨어를 초기화하고 보통 GRUB인 부트로더에 제어를 넘깁니다. 부트로더는 설정을 읽고 커널과 initramfs를 메모리에 올립니다. initramfs는 진짜 루트에 접근하기 위한 드라이버를 담은 임시 루트 파일 시스템입니다.

커널은 장치를 초기화하고, 루트 파일 시스템을 마운트하고, PID 1 사용자 공간 프로세스를 실행합니다. 대부분의 배포판에서 이것은 systemd입니다. systemd는 서비스를 기본 target(예: multi-user.target)까지 올립니다. 단계별 소요 시간은 systemd-analyze로 확인합니다.

6. mount 명령은 무엇을 하며, 자동 마운트는 어디에 설정하나요?

mount는 장치의 파일 시스템을 디렉터리(마운트 포인트)에 연결합니다: mount /dev/sdb1 /mnt/data. 현재 마운트 상태는 findmnt나 인자 없는 mount로 봅니다.

부팅 시 마운트는 /etc/fstab에 설정합니다. 장치는 /dev/sdb1 같은 이름보다 UUID로 적는 것이 좋습니다(blkid로 확인). 이름은 바뀔 수 있기 때문입니다. 재부팅 전에 mount -a로 변경 사항을 확인하세요. fstab의 오류는 부팅을 멈추게 할 수 있습니다.

사용자와 권한

7. 리눅스 파일 권한은 어떻게 동작하나요?

모든 파일에는 소유자, 그룹, 그리고 세 벌의 권한이 있습니다: 소유자, 그룹, 그 밖의 사용자용. 각 묶음은 r(읽기), w(쓰기), x(실행)로 이루어집니다. 숫자로는 r=4, w=2, x=1이므로 chmod 640 file은 소유자에게 읽기와 쓰기, 그룹에 읽기, 나머지에게는 아무 권한도 주지 않습니다.

$ ls -l app.conf
-rw-r----- 1 deploy www-data 512 Oct 12 10:03 app.conf

소유자는 chown user:group file로, 권한은 chmod로 바꿉니다.

8. 디렉터리에서 r, w, x는 무엇을 뜻하나요?

디렉터리에서는 의미가 다릅니다. r은 이름 목록을 얻을 수 있다는 뜻이고, w는 안에서 파일을 만들고 삭제하고 이름을 바꿀 수 있다는 뜻이며, x는 디렉터리에 들어가 이름으로 파일에 접근할 수 있다는 뜻입니다.

그래서 중요한 결과가 있습니다: 파일을 삭제하려면 디렉터리에 쓰기 권한만 있으면 됩니다. 파일이 본인 것이 아니어도 됩니다. 디렉터리에 x가 없으면 r이 있어도 소용없습니다. 이름은 보이지만 파일은 열 수 없습니다.

9. SUID, SGID, sticky bit는 무엇인가요?

실행 파일의 SUID는 프로그램을 실행한 사용자가 아니라 파일 소유자의 권한으로 실행되게 합니다. 대표적인 예는 /usr/bin/passwd입니다. root 소유이며 /etc/shadow를 수정할 수 있습니다. 파일에 대한 SGID는 같은 일을 그룹에 대해 하고, 디렉터리에 대한 SGID는 새 파일이 디렉터리의 그룹을 물려받게 합니다. 공유 폴더에 편리합니다.

디렉터리의 sticky bit는 디렉터리가 모두에게 쓰기 가능하더라도, 파일을 소유자만 삭제할 수 있게 합니다. /tmp가 이렇습니다. ls -ld /tmp에서 drwxrwxrwt를 볼 수 있습니다. 감사용으로 모든 SUID 파일을 찾으려면 find / -perm -4000 -type f 2>/dev/null을 씁니다.

10. umask란 무엇인가요?

umask는 새 파일과 디렉터리에서 권한을 빼는 마스크입니다. 기본 권한은 파일 666, 디렉터리 777이며, umask는 여기서 비트를 뺍니다. 일반적인 umask 022에서는 파일이 644, 디렉터리가 755로 만들어집니다. 현재 값은 umask 명령으로 봅니다.

11. 사용자와 비밀번호는 어디에 저장되나요?

계정은 /etc/passwd에 있습니다: 이름, UID, 기본 그룹의 GID, 홈 디렉터리, 셸. 비밀번호 해시는 별도의 /etc/shadow에 있으며 root만 읽을 수 있어서, 일반 사용자가 해시를 무작위 대입으로 공격할 수 없습니다. 그룹은 /etc/group에 있습니다.

사용자 정보는 id user와 getent passwd user로 봅니다. 후자는 LDAP 같은 외부 소스도 포함합니다.

12. sudo는 어떻게 동작하며, root로 로그인하는 것보다 왜 나은가요?

sudo는 /etc/sudoers와 /etc/sudoers.d/ 파일의 규칙에 따라 명령을 다른 사용자(기본값 root)의 이름으로 실행합니다. 사용자는 root의 비밀번호가 아니라 자신의 비밀번호를 입력하며, 모든 작업은 누가 했는지 기록되는 로그에 남습니다.

규칙은 모든 것을 허용할 수도(alena ALL=(ALL:ALL) ALL), 특정 명령만 허용할 수도 있습니다. sudoers는 visudo로 편집하세요. 저장 전에 문법을 검사하므로, 실수로 sudo를 망가뜨리지 않습니다. Ubuntu에서는 sudo 그룹 소속으로, RHEL 계열에서는 wheel 그룹 소속으로 관리자 권한을 얻습니다.

13. 사용자를 그룹에 추가했는데 적용되지 않는 이유는?

usermod -aG docker alena는 사용자를 추가 그룹에 넣습니다. -a 옵션은 필수입니다. 없으면 -G가 그룹 목록 전체를 대체합니다.

변경 사항은 새로 로그인해야 적용됩니다. 현재 세션은 이전 그룹 목록을 가지고 있기 때문입니다. 다시 로그인하거나 newgrp docker로 새 그룹을 가진 셸을 여세요. 확인은 id로 합니다.

프로세스

14. 프로세스와 PID란 무엇이며, 프로세스는 어떻게 보나요?

프로세스는 실행 중인 프로그램으로, 자신의 주소 공간, 열린 파일, PID라는 식별자를 가집니다. 모든 프로세스에는 부모(PPID)가 있으며, 공통 조상은 PID 1입니다. 프로세스 목록은 ps aux와 ps -ef, 트리는 pstree 또는 ps -ef --forest, 실시간 보기는 top과 htop으로 봅니다.

15. SIGTERM과 SIGKILL은 어떻게 다른가요?

kill PID는 기본적으로 SIGTERM(15)을 보냅니다. 정중하게 종료를 요청하는 신호입니다. 프로세스는 이를 잡아서 연결을 닫고, 데이터를 저장한 뒤 종료할 수 있습니다. SIGKILL(9, kill -9)은 잡을 수 없습니다. 커널이 프로세스를 즉시, 정리 없이 끝냅니다.

올바른 순서는 먼저 SIGTERM, 프로세스가 반응하지 않을 때만 SIGKILL입니다. 또 하나 자주 쓰는 신호는 SIGHUP입니다. 많은 데몬이 이 신호를 받으면 설정을 다시 읽습니다.

16. 좀비 프로세스란 무엇인가요?

좀비는 이미 끝났지만, 부모가 아직 wait()로 종료 코드를 읽지 않은 프로세스입니다. 자원은 거의 쓰지 않지만 프로세스 테이블에 항목이 남습니다. ps에서 상태 Z로 보입니다.

좀비는 죽일 수 없습니다. 이미 죽어 있기 때문입니다. 부모가 그것을 «묻어야» 합니다. 부모 프로그램을 고치거나, 부모를 종료하면 좀비는 PID 1에게 넘어가고, PID 1이 정리합니다.

17. load average는 무엇을 보여 주나요?

uptime과 top의 세 숫자는 최근 1, 5, 15분 동안 실행 대기 중이던 프로세스의 평균 개수입니다. 리눅스에서는 중단할 수 없는 대기 상태(D 상태, 보통 디스크 대기)의 프로세스도 여기에 포함됩니다.

이 값은 CPU 코어 수(nproc)와 비교합니다. 4코어에서 load 4는 완전한 부하이고, 16코어에서는 4분의 1입니다. CPU 사용률이 낮은데 load가 높다면 입출력 문제를 의심하세요. iostat나 top의 wa 필드로 확인합니다.

네트워크

18. IP 주소, 라우트, 열린 포트는 어떻게 확인하나요?

인터페이스 주소는 ip a, 라우팅 테이블은 ip r로 봅니다. 예전의 ifconfig와 net-tools의 netstat은 많은 배포판에서 기본으로 설치되어 있지 않습니다.

대기 중인 포트와 그것을 연 프로세스는 ss -tlnp로 보여 줍니다: t — TCP, l — 대기 중인 것만, n — 이름으로 바꾸지 않음, p — 프로세스 정보 포함. UDP는 ss -ulnp입니다.

$ sudo ss -tlnp
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*     users:(("nginx",pid=812,fd=6))
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*     users:(("sshd",pid=640,fd=3))

19. 서비스가 127.0.0.1:8080에서 대기 중입니다. 밖에서 접속할 수 있나요?

아니요. 127.0.0.1은 루프백 인터페이스로, 같은 머신에서만 접근할 수 있습니다. 외부 연결을 받으려면 서비스가 외부 인터페이스의 주소나 0.0.0.0(모든 IPv4 주소)에서 대기해야 합니다. «포트는 열려 있는데 밖에서는 안 된다»는 흔한 원인이며, 방화벽도 이유가 될 수 있습니다.

20. 리눅스는 호스트 이름을 IP 주소로 어떻게 바꾸나요?

출처의 순서는 /etc/nsswitch.conf의 hosts: 줄이 정합니다. 보통 먼저 /etc/hosts 파일을, 그다음 DNS를 봅니다. DNS 서버 주소는 /etc/resolv.conf에서 가져옵니다. systemd-resolved를 쓰는 시스템에서는 거기에 로컬 주소 127.0.0.53이 있고, 실제 서버는 resolvectl status로 봅니다.

확인에는 dig example.com이나 특정 서버를 지정한 dig @1.1.1.1 example.com을 씁니다. 주의할 점: dig와 nslookup은 DNS에 직접 묻고 /etc/hosts는 읽지 않습니다. 반면 getent hosts example.com은 애플리케이션이 따르는 것과 같은 경로로 조회합니다.

21. TCP와 UDP는 어떻게 다른가요?

TCP는 연결을 먼저 세웁니다(SYN, SYN-ACK, ACK의 3단계 핸드셰이크). 전달과 순서를 보장하고, 유실된 패킷을 다시 보냅니다. HTTP, SSH, 대부분의 데이터베이스가 TCP를 씁니다. UDP는 연결 없이, 보장 없이 데이터그램을 보내지만 지연이 적습니다. DNS 질의, 화상 통화, 게임이 UDP를 씁니다.

22. 사이트가 열리지 않습니다. 원인을 어떻게 찾을 건가요?

이름에서 애플리케이션까지, 계층별로 확인합니다:

1. 이름이 해석되는가: dig site.example, 주소가 예상과 같은가.
2. 호스트에 닿는가: ping(막혀 있을 수 있음), traceroute나 mtr.
3. 포트가 열려 있는가: nc -zv host 443 또는 curl -v https://site.example.
4. 서버에서: 서비스가 실행 중인가(systemctl status nginx), 포트를 듣고 있는가(ss -tlnp), 방화벽이 막고 있는가(sudo nft list ruleset, sudo ufw status).
5. 애플리케이션 로그와 서비스의 journalctl -u.

면접관에게 중요한 것은 특정 도구 목록이 아니라 체계적인 순서입니다.

23. TIME_WAIT 상태란 무엇인가요?

TCP 연결이 닫힌 뒤, 먼저 닫은 쪽은 소켓을 일정 시간 TIME_WAIT 상태로 둡니다. 이전 연결의 늦은 패킷이 같은 주소와 포트를 쓰는 새 연결에 섞이지 않게 하기 위해서입니다. 부하가 큰 서버나 짧은 연결을 많이 만드는 클라이언트에서 TIME_WAIT가 많은 것은 정상입니다. 개수는 ss -tan state time-wait | wc -l로 셉니다.

24. /etc/hosts와 DNS의 차이는 무엇이며, 언제 /etc/hosts가 필요한가요?

/etc/hosts는 한 머신에 있는 정적인 «주소 — 이름» 표입니다. 표준 nsswitch 설정에서는 DNS보다 먼저 확인되며, 테스트에 편리합니다. 예를 들어 DNS 레코드를 바꾸기 전에 도메인을 새 서버로 보내 볼 수 있습니다. DNS는 분산 시스템이며, 응답은 모든 클라이언트가 봅니다. /etc/hosts의 잘못된 항목은 «내 컴퓨터에서는 사이트가 열리는데 다른 사람들은 못 연다»는 상황의 흔한 원인입니다.

마무리

리눅스 면접 질문은 세 가지를 확인합니다. 시스템의 모델(inode, 권한, 프로세스, 부팅)을 이해하는지, 진단 도구(ss, dig, journalctl, lsof)를 아는지, 그리고 원인을 단계별로 찾을 수 있는지입니다. 답변에 명령어와 실제 경험을 함께 담으세요. 파일 시스템, 권한, 네트워크는 강의에서 실습과 함께 자세히 다룹니다.