이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트 초반에 팀원이 코드를 바꿀 때마다 제가 수동으로 서버에 배포했는데, 하루에 세 번씩 배포하다 보니 실수가 생겼습니다. 한번은 이전 버전 코드를 실수로 다시 배포해서 새 기능이 사라지는 문제가 생겼고, 원인을 파악하는 데 30분이 걸렸습니다. 이후 깃허브 액션으로 배포를 자동화했더니 이런 실수가 없어졌습니다. OpenStack 자동화 배포는 직접 해본 적이 없지만, 자동화가 없을 때 생기는 문제를 몸으로 겪어봤습니다. 업그레이드도 수동으로 하면 단계를 빠뜨리거나 버전 불일치가 생길 수 있어서 자동화가 안전망이 된다고 생각합니다.
앤서블 스터디에서 같은 플레이북으로 여러 번 실행해도 동일한 결과가 나오는 걸(멱등성) 처음 경험했습니다. 수동 배포는 설치 순서를 헷갈리면 결과가 달라지는데, 자동화된 배포는 이 문제가 없다는 걸 그때 실감했습니다. OpenStack처럼 서비스가 많고 의존성이 복잡한 시스템일수록 수동 업그레이드는 한 단계 실수가 전체에 영향을 주기 쉬울 것 같습니다. 자동화 배포는 재현 가능하고 롤백도 예측 가능하다는 점에서 중요하다고 생각합니다. OpenStack을 직접 다뤄본 건 아니지만, 자동화의 가치를 작은 프로젝트에서 체감했습니다.
스터디에서 테라폼으로 클라우드 리소스를 코드로 관리하는 실습을 했는데, 설정이 코드로 남아있으니 누가 언제 무엇을 바꿨는지 기록이 되는 점이 인상 깊었습니다. 수동 배포는 누가 어떤 명령어를 쳤는지 기록이 없으면 나중에 재현하기 어렵습니다. 업그레이드도 코드로 관리하면 어떤 버전에서 어디로 바꿨는지 추적이 가능하다는 게 장점이라고 생각합니다. OpenStack 환경을 직접 다뤄본 경험은 없지만, 자동화와 코드 기반 관리가 왜 중요한지는 이 실습으로 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.