중급 엔지니어라면 어디까지 설명할 수 있어야 할까

· LinuxLFCS회고

최근 중급 엔지니어는 어느 정도 수준이어야 할까 생각해볼 일이 있었다.

서버와 네트워크를 운영하면서 익숙하게 사용해온 것들은 많았다. 하지만 왜 그렇게 구성되는지 짧게 설명하거나, 정해진 결과를 처음부터 다시 만드는 문제는 생각보다 어려웠다. 평소에는 필요한 설정을 찾아 적용하고 문제를 해결해왔지만, 이해한 내용을 바로 설명하는 능력과 제한된 시간 안에 안전하게 재현하는 능력은 또 다른 문제였다.

그래서 Linux 기초부터 다시 확인해보기로 했다. 목표는 명령어를 많이 외우는 것이 아니라, 익숙하게 사용해온 기능의 원리를 설명하고 직접 설정한 뒤 정상 동작까지 검증할 수 있는지를 점검하는 것이다. 그 기준으로 LFCS 시험을 준비하고, Linux Foundation의 LFS207 과정도 함께 보기 시작했다.

시험 범위 전체는 Blog에 길게 옮기지 않고 LFCS 시험 개요와 학습 순서와 시험 범위 체크리스트에서 개념편과 실습편으로 나눠 정리했다. 이 글에는 실제로 환경을 만들고 첫 문제를 풀면서 막혔던 지점과 판단만 남긴다.

실습 환경부터 다시 만들었다

실습 환경은 Hyper-V에 Rocky Linux 10.2 VM을 설치해 구성했다. SSH로 접속할 수 있게 설정했고, 스토리지 실습을 위해 5GB 디스크 두 개도 추가했다. SELinux는 Enforcing, 방화벽은 실행 상태를 유지했다.

처음에는 시험에 사용되는 배포판과 버전을 똑같이 맞추는 것이 중요하다고 생각했다. 하지만 현재 LFCS 공식 안내는 시험 과제가 배포판별 작업에 의존하지 않으며, 준비 체크리스트에서도 플랫폼을 선택할 필요가 없다고 설명한다. 시험 환경을 그대로 복제하려 하기보다 특정 배포판의 절차만 외우지 않고, 요구된 최종 상태를 만들고 검증하는 연습이 더 중요하다고 판단했다.

첫 실습은 사용자·그룹·SGID였다

공개된 시험문항이 아니라 LFCS 시험 영역을 바탕으로 만든 첫 번째 연습 과제였다.

최종 결과는 요구사항에 맞게 만들었다. 하지만 이번 연습에서 정한 목표 시간은 6~7분이었고 실제로는 약 15분이 걸렸다. history에는 41개의 명령이 남았다. 결과만 보면 성공이었지만 수행 과정까지 포함하면 좋은 점수를 주기 어려웠다.

결과는 맞았지만 과정은 5점이었다

기존 사용자를 그룹에 추가하는 명령이 바로 떠오르지 않아 groupadd와 useradd의 옵션을 여러 번 잘못 시도했다. 결국 usermod를 찾아냈지만, 처음에는 -G만 사용했다.

usermod -G devops lfcsuser

usermod(8) 설명대로 -G는 보조 그룹 목록을 새로 지정한다. 따라서 명시하지 않은 기존 보조 그룹에서는 사용자가 제거된다. 기존 그룹을 유지하면서 새 그룹을 추가하려면 -aG를 사용해야 했다.

usermod -aG devops lfcsuser

공유 디렉터리에는 다음 권한을 설정했다.

chown root:devops /srv/project
chmod 2770 /srv/project

2770의 앞자리 2가 SGID라는 것은 찾아냈지만, 디렉터리에 설정했을 때의 동작을 문서에서 빠르게 찾지 못했다. Linux의 inode(7) 설명에 따르면 그 안에서 새로 생성된 파일과 하위 디렉터리는 부모 디렉터리의 그룹 ID를 따르고, 하위 디렉터리에는 SGID 비트도 설정된다. 파일의 접근 권한 자체가 상속되는 것은 아니며 생성 모드와 umask 등의 영향을 받는다. 명령의 옵션을 아는 것과 그 권한 비트가 실제로 어떤 동작을 만드는지 이해하는 것은 달랐다.

마지막에는 다음 명령으로 설정 상태를 확인했다.

id lfcsuser
getent group devops
ls -ld /srv/project

출력에서 lfcsuser가 devops 그룹에 포함된 것과 /srv/project가 drwxrws--- 상태인 것을 확인했다. 다만 디렉터리 정보만 보는 것보다 실제 사용자 권한으로 파일과 하위 디렉터리를 생성해 접근 가능 여부, 그룹 소유권, SGID를 확인하는 편이 더 확실하다. 이미 로그인 중인 사용자의 셸에는 바뀐 보조 그룹이 자동으로 반영되지 않으므로, 동작을 시험할 때는 새 로그인 세션을 사용해야 한다는 점도 다음 검증 항목에 넣었다.

파일시스템 트리부터 다시 보는 이유

systemd 실습으로 넘어가려 했지만 unit 파일을 처음부터 작성하는 단계에서 감이 잘 잡히지 않았다. 모르는 상태에서 명령을 추측하기보다 LFS207의 관련 내용을 먼저 보기로 했다.

강의는 Linux 파일시스템 트리와 FHS부터 설명했다. 여러 파일시스템을 하나의 디렉터리 트리에 연결하는 방식과, 그 트리 안에서 파일과 디렉터리를 어디에 둘지 정한 FHS는 구분해서 이해할 필요가 있었다.

/etc, /var, /usr, /home 같은 경로는 계속 사용해왔지만, 부팅과 복구를 위해 루트 파일시스템에 무엇이 필요하고 어떤 경로는 별도 파일시스템에 둘 수 있는지 설명하려니 막막했다. FHS 3.0은 루트 파일시스템이 부팅·복구·수리에 필요한 내용을 갖춰야 하며 /usr, /opt, /var는 다른 파일시스템에 둘 수 있도록 설계됐다고 설명한다.

FHS의 디렉터리 목록을 전부 외우거나 그대로 옮겨 적는 것이 목표는 아니다. 설정은 왜 /etc에 있고, 계속 변하는 데이터는 왜 /var에 있는지, /proc과 /sys는 디스크에 저장된 일반 파일이 아니라 커널 정보를 제공하는 가상 파일시스템이라는 점을 설명할 수 있을 정도로 다시 이해해보려 한다.

지금 생각하는 중급 엔지니어의 기준

아직 중급 엔지니어의 기준을 한 문장으로 정리하기는 어렵다. 다만 이번 실습을 통해 단순히 명령을 사용해본 경험만으로는 부족하다고 느꼈다.

현재 생각하는 기준은 다음에 가깝다.

모든 명령을 외우는 사람보다는, 모르는 상황에서도 근거를 찾아 안전하게 결과를 만들고 확인할 수 있는 사람이 중급 엔지니어에 더 가깝지 않을까 생각한다.

기록과 참고 자료를 분리했다

이 글을 처음 정리할 때까지 실제로 완료한 것은 실습 환경 구성과 사용자·그룹·SGID 실습이었다. systemd 서비스 생성은 개념을 다시 확인하는 단계였으므로 성공한 실습처럼 덧붙이지 않았다.

대신 반복해서 참고할 개념과 명령, 확인 절차는 Docs로 분리했다. 각 도메인은 핵심 정리와 시나리오 실습을 한 쌍으로 구성했고, 마지막에는 120분 종합 모의 실습으로 연결했다. 실습 문제는 공개 시험문항을 옮긴 것이 아니라 공식 competency를 직접 재현하기 위해 만든 개인 연습 과제다.

앞으로도 결과만 맞히는 데서 끝내지 않고 다음 기준으로 기록하려 한다.

맞게 만들기 → 제한시간 안에 만들기 → 다른 상태를 망가뜨리지 않기 → 정상 동작을 검증하기

← Blog 목록