이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 서버 설정을 한 명이 콘솔에서 직접 만들었는데, 나중에 다른 팀원이 같은 환경을 다시 만들 때 설정이 달랐습니다. 어디서 차이가 생겼는지 알 수 없었습니다.
Terraform을 처음 사용하기로 했습니다. 인프라 설정을 코드 파일로 정의해두면 같은 환경을 그대로 재현할 수 있다는 개념이 마음에 들었기 때문입니다. 처음에는 상태 파일 관리 방식을 이해하지 못해서 팀원이 각자 apply하다가 상태가 꼬이는 실수가 있었지만, 원격 상태 저장소를 공유하도록 바꾸니 해결되었습니다.
코드로 인프라를 관리하면 변경 이력이 남고, 잘못됐을 때 되돌릴 수 있다는 점이 가장 좋았습니다. 코드 리뷰할 때 인프라 변경도 함께 리뷰할 수 있게 되었고요. 처음 설정이 익숙해지면 반복 환경 구성이 빠르다는 것을 직접 경험했습니다. 그 경험이 인프라를 코드로 다루는 방식의 가치를 알게 해주었습니다.
팀원이 새로 합류할 때마다 개발 환경 세팅 가이드가 있어도 '이게 안 된다', '저게 안 된다'는 문제가 반복됐어요. 가이드가 오래된 것도 있었고, OS에 따라 다른 부분도 있었습니다.
셸 스크립트로 필요한 의존성 설치, 환경 변수 설정, 초기 데이터 세팅을 자동화했어요. 새 팀원이 오면 스크립트 하나 실행하면 30분 안에 개발 환경이 완성되는 구조였습니다. 처음엔 다양한 환경 예외가 있어서 스크립트를 여러 번 수정했는데, 5명이 써보고 나서 안정됐어요.
그 이후로 새 팀원 온보딩 시간이 반나절에서 30분으로 줄었어요. 자동화가 단순히 일을 줄이는 것 이상으로 팀 전체에 일관성을 준다는 걸 느꼈습니다. 환경 차이에서 오는 문제가 사라지니 개발 속도도 올라갔어요. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
인턴 때 개발 서버와 스테이징 서버의 설정이 달라서 개발에서 되던 게 스테이징에서 안 되는 상황이 반복됐어요. 두 서버의 패키지 버전이 달랐던 게 원인이었습니다.
앤서블을 처음 써봤어요. 플레이북으로 두 서버에 같은 패키지와 설정을 적용하는 구조를 만들었고, 이후로는 설정을 바꿀 때 플레이북만 수정하면 두 서버에 동시 적용됐습니다. 처음엔 SSH 키 설정이 안 돼서 연결 자체가 안 됐는데, 기본 설정부터 차근차근 따라가니 해결됐어요.
한 서버만 다르게 설정되는 상황이 사라지니까 '왜 여기서만 안 되지?'를 디버깅하는 시간이 줄었어요. 설정을 코드로 관리하면 변경 내역도 남아서 언제 무엇이 바뀌었는지 파악하기 쉬웠습니다. 그 경험이 인프라 관리를 체계적으로 보는 계기가 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.