이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 작품으로 소규모 프라이빗 클라우드 환경을 구성할 때 OpenStack을 처음 써봤습니다. 인스턴스를 생성하면 외부에서 접근이 안 되는 문제가 반복됐는데, 원인을 찾는 데 이틀이 걸렸습니다.
Neutron 보안 그룹 기본 정책이 인바운드 트래픽을 전부 차단하도록 설정돼 있었고, Floating IP 할당 후에도 라우터의 외부 게이트웨이 설정이 누락된 상태였습니다. Neutron 공식 문서와 로그를 번갈아 보면서 네트워크 토폴로지 다이어그램을 직접 그려가며 설정을 하나씩 검증했습니다.
그 경험에서 OpenStack은 컴포넌트가 많아서 문제가 어디서 왔는지 좁혀가는 것이 핵심이라는 걸 배웠습니다. 계층별로 작동 여부를 확인하는 순서를 정하면 훨씬 빠르게 원인을 찾을 수 있다는 것이 지금도 제 디버깅 방식입니다.
팀 프로젝트에서 OpenStack Nova로 VM을 띄워 배치 작업을 돌렸는데, 같은 설정인데도 인스턴스마다 처리 속도가 2배 이상 차이나는 현상이 있었습니다.
하이퍼바이저 노드가 과부하 상태에서 CPU를 여러 VM이 나눠 쓰는 문제였습니다. Nova 대시보드에서 각 노드의 vCPU 할당량을 확인하니 특정 노드에만 VM이 몰려 있었습니다. 오버커밋 비율을 조정하고 VM을 여러 노드에 분산하도록 설정을 변경했습니다.
처음엔 VM 성능 문제가 코드에 있다고 생각해 한참 코드를 봤는데 인프라 설정 문제였습니다. 성능 문제는 코드뿐 아니라 인프라 계층도 함께 확인해야 한다는 걸 그때 배웠습니다.
졸업 작품에서 여러 프로젝트가 공존하는 OpenStack 환경을 구성할 때, 특정 사용자가 자신이 속하지 않은 프로젝트의 리소스에 접근하는 문제가 있었습니다.
Keystone의 Role 기반 접근 제어 설정이 테스트 환경에서 너무 느슨하게 구성돼 있었습니다. admin 역할이 모든 프로젝트에 적용되는 구조를 이해하지 못한 채 사용자에게 과도한 권한을 준 것이었습니다. 각 프로젝트에 필요한 최소 권한만 부여하는 방식으로 다시 설계했습니다.
인증 설정은 나중에 바꾸면 기존 리소스 접근이 한꺼번에 영향받는다는 걸 그때 배웠습니다. 처음부터 최소 권한 원칙으로 설계하고 필요할 때 확장하는 방향이 맞는다는 것이 지금도 제 접근 방식입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.