클라우드 엔지니어 취업을 준비하는 분의 프로젝트 설명을 점검하면서 AWS EC2에 웹 서비스를 올린 경험을 물어본 적이 있습니다. 이 준비생은 EC2 인스턴스를 생성하고 데이터베이스를 연결했으며, 도메인과 HTTPS까지 설정했다고 자신 있게 말했습니다. 그런데 처음 서버에 접속하지 못했을 때 무엇을 확인했는지 묻자 보안그룹을 수정해서 해결했다는 답변에서 설명이 멈췄습니다. 어떤 포트가 닫혀 있었는지, SSH 키 권한은 정상적이었는지, 애플리케이션은 어느 포트에서 실행되고 있었는지에 대한 기록이 없었기 때문입니다. 서비스가 접속되지 않았던 원인을 구분하기보다 설정을 여러 번 바꾸다가 우연히 해결된 상태에 가까웠습니다.
비용에 관한 질문에서도 비슷한 문제가 나타났습니다. 무료 사용 범위 안에서 실습했다고 생각했지만, 사용하지 않는 인스턴스와 스토리지 볼륨을 남겨두어 예상하지 못한 금액이 청구되었습니다. 처음에는 금액이 크지 않아 경험으로 정리할 필요가 없다고 생각했지만, 비용 탐색 화면에서 서비스별 사용량을 확인하고 중지된 인스턴스에 연결된 볼륨과 스냅숏을 정리한 과정까지 복기하자 좋은 면접 소재가 되었습니다. 이후에는 예산 알림을 설정하고 실습 종료 체크리스트를 만들어 같은 문제가 반복되지 않도록 했습니다.
클라우드 실습은 서비스를 한 번 배포했다는 결과만으로 평가되지 않습니다. 서버에 접속하고 애플리케이션을 실행한 과정, 자원 사용량과 비용을 확인한 기준, 장애가 발생했을 때 원인을 좁힌 순서가 함께 보여야 합니다. 완성된 구성도보다 직접 판단하고 수정한 경험이 구체적일수록 신입 지원자의 실무 가능성도 선명해집니다. 따라서 면접을 준비할 때는 사용한 서비스 목록을 외우기보다 서버배포, 비용관리, 장애대응 과정에서 무엇을 확인하고 어떤 기준으로 결정했는지부터 정리해야 합니다.
클라우드 서버배포 경험은 설정 순서와 판단 기준으로 설명합니다
- 배포 완료보다 구성한 이유가 먼저 보여야 합니다
클라우드 실습을 설명할 때 EC2, RDS, S3, Nginx를 사용했다고 말하는 경우가 많습니다. 이 설명은 사용한 서비스를 알려주지만, 지원자가 전체 구성을 이해하고 있는지는 보여주지 못합니다. 면접관은 각 서비스를 왜 선택했는지, 요청이 어떤 경로를 거쳐 처리되는지, 직접 담당한 범위가 어디까지인지 확인하려 합니다. 브라우저에서 들어온 요청이 웹 서버를 거쳐 애플리케이션으로 전달되고 데이터베이스 조회 결과가 다시 응답되는 흐름을 자신의 말로 설명할 수 있어야 합니다.
예를 들어 팀 프로젝트에서 다른 팀원이 클라우드 설정을 담당했다면 모든 인프라를 자신이 구축했다고 표현해서는 안 됩니다. 자신이 담당한 애플리케이션 배포, 환경변수 설정, 데이터베이스 연결 확인, 로그 점검 범위를 구분해 말하는 편이 오히려 신뢰를 높입니다. 협업 과정에서 인프라 담당자에게 어떤 정보를 요청했고, 배포 후 어떤 기능을 검증했는지도 충분한 경험이 될 수 있습니다.
- 서버를 선택한 기준은 프로젝트 규모와 연결해서 설명해야 합니다. 소규모 실습이어서 단일 인스턴스로 시작했는지, 데이터 유실을 줄이기 위해 데이터베이스를 분리했는지, 정적 파일을 별도 저장소에 둔 이유가 무엇인지 정리하면 단순한 서비스 나열을 피할 수 있습니다.
- 배포 순서는 명령어 목록보다 확인 과정이 중요합니다. 애플리케이션 실행 여부, 내부 포트 응답, 웹 서버 연결, 외부 접속 순서로 점검했다면 각 단계에서 사용한 확인 방법과 정상 기준을 함께 남겨야 합니다.
- 접속 실패를 해결한 경험은 구간별로 나눠야 합니다
한 준비생은 EC2 인스턴스를 만든 뒤 SSH 접속이 되지 않아 인스턴스를 여러 번 삭제하고 다시 생성했습니다. 처음에는 클라우드 환경이 불안정해서 생긴 문제라고 생각했지만, 화면을 함께 점검하니 접속에 사용한 개인 키 파일의 권한이 지나치게 열려 있었습니다. 운영체제에서 키 파일 권한을 수정한 뒤에는 접속할 수 있었지만, 브라우저에서 웹 서비스가 열리지 않는 문제가 다시 발생했습니다.
두 번째 문제는 SSH 접속과 다른 원인이었습니다. 애플리케이션은 8080 포트에서 정상적으로 실행되고 있었지만 보안그룹에는 80 포트만 열려 있었고, Nginx의 전달 설정도 적용되지 않은 상태였습니다. 그는 서버 내부에서 애플리케이션 응답을 먼저 확인하고, Nginx 설정 파일과 외부 허용 포트를 순서대로 살펴본 뒤 문제를 해결했습니다. 이 경험을 정리하면서 접속 실패라는 하나의 현상 안에도 키 권한, 네트워크 설정, 프로세스 실행, 포트 연결처럼 서로 다른 원인이 있을 수 있다는 점을 이해하게 되었습니다.
- 결과만 말한 답변: EC2에 서버를 배포하고 보안그룹을 설정했습니다.
- 과정이 드러나는 답변: SSH 접속 오류가 발생해 키 파일 권한과 보안그룹의 22번 포트를 확인했고, 웹 접속 문제는 애플리케이션 실행 포트와 외부 허용 포트가 다르다는 점을 찾아 수정했습니다.
- 판단과 검증이 담긴 답변: 먼저 SSH 접속 여부를 확인해 서버 접근 문제와 애플리케이션 문제를 분리했습니다. 서버 내부에서는 8080 포트 응답이 정상이라는 사실을 확인했고, 이후 Nginx 설정과 보안그룹의 80번 포트를 점검해 외부 요청이 전달되지 않는 원인을 해결했습니다. 수정 후에는 브라우저 요청과 서버 로그를 함께 확인하고 배포 절차를 README에 기록했습니다.
- 배포 이후 확인한 내용까지 경험에 포함해야 합니다
서비스 화면이 한 번 열렸다고 배포가 끝난 것은 아닙니다. 서버를 재시작했을 때 애플리케이션이 다시 실행되는지, 환경변수에 민감한 정보가 노출되지 않는지, 데이터베이스 연결이 끊겼을 때 어떤 응답이 반환되는지도 확인해야 합니다. 처음부터 복잡한 자동화를 구현하지 못했더라도 재시작 이후의 상태를 점검하고 수동 배포 과정의 한계를 발견했다면 의미 있는 학습 경험이 됩니다.
실제로 한 프로젝트에서는 터미널을 종료하자 실행 중이던 애플리케이션도 함께 종료되는 문제가 발생했습니다. 준비생은 처음에는 서버 자체가 중지된 것으로 판단했지만, 인스턴스 상태와 네트워크 연결은 정상이었습니다. 프로세스 목록과 실행 로그를 확인한 뒤 세션 종료에 영향을 받는 방식으로 실행했다는 원인을 찾았고, 프로세스 관리 도구를 적용해 재시작 후에도 서비스가 유지되도록 바꿨습니다. 면접에서는 도구 이름보다 문제를 서버, 네트워크, 프로세스 영역으로 나누어 확인한 순서를 설명하는 것이 중요합니다.
예상 금액과 실제 사용량을 비교한 비용관리 과정이 필요합니다
- 무료 사용이라는 생각이 비용 확인을 늦추기도 합니다
처음 실습하는 준비생은 무료 사용 범위가 있다는 이유로 비용을 별도로 확인하지 않는 경우가 많습니다. 그러나 인스턴스를 중지해도 연결된 스토리지에 요금이 발생할 수 있고, 사용하지 않는 공인 IP나 스냅숏, 데이터 전송량에서도 예상하지 못한 금액이 생길 수 있습니다. 면접에서 비용을 고려했다는 말만 하기보다 어떤 항목을 확인했고, 어느 시점에 알림을 설정했는지를 설명해야 실제 경험으로 들립니다.
한 준비생은 여러 운영체제를 비교하기 위해 인스턴스를 반복해서 만들고 삭제했습니다. 인스턴스는 모두 제거했다고 생각했지만 별도로 생성된 볼륨과 스냅숏 일부가 남아 있었습니다. 월말 청구 금액을 확인한 뒤 비용 탐색 화면에서 서비스별 사용량을 비교했고, 컴퓨팅 비용보다 저장 자원에서 계속 금액이 발생한다는 사실을 발견했습니다. 사용하지 않는 자원을 정리한 뒤에는 실습을 시작하기 전에 예산 한도를 설정하고, 종료할 때 인스턴스뿐 아니라 연결된 자원까지 확인하는 목록을 만들었습니다.
- 예상 비용은 배포 전에 기록하는 것이 좋습니다. 인스턴스 사양, 실행 시간, 스토리지 용량, 데이터 전송 가능성을 간단히 계산해 두면 실제 청구 금액과 차이가 생겼을 때 원인을 더 빠르게 찾을 수 있습니다.
- 실습 종료 기준도 필요합니다. 단순히 서버를 중지하는 데서 끝내지 않고 볼륨, 스냅숏, 공인 IP, 로드밸런서, 데이터베이스처럼 연결된 자원이 남아 있는지 확인해야 합니다. 이 과정은 비용 절감뿐 아니라 자원 구조를 이해하는 데도 도움이 됩니다.
- 사양을 낮추는 것만이 비용 절감은 아닙니다
비용을 줄였다는 설명에서 가장 자주 등장하는 방법은 인스턴스 사양을 낮췄다는 내용입니다. 하지만 실제 사용량을 확인하지 않고 사양부터 낮추면 응답 지연이나 메모리 부족이 발생할 수 있습니다. CPU와 메모리 사용량, 요청 수, 운영 시간을 살펴본 뒤 현재 구성에 불필요한 자원이 있는지 판단해야 합니다.
예를 들어 개인 프로젝트를 하루 종일 실행해 두던 준비생이 있었습니다. 접속 기록을 확인하니 실제로 서비스를 사용하는 시간은 면접 준비와 기능 테스트를 진행하는 저녁 시간대에 집중되어 있었습니다. 그는 서버를 무조건 더 작은 사양으로 변경하는 대신 사용하지 않는 시간에 중지하고, 다시 시작할 때 필요한 절차를 문서화했습니다. 데이터베이스는 보존해야 했기 때문에 종료 대상에서 제외하고 백업 상태를 별도로 확인했습니다. 이 경험은 단순한 절약이 아니라 사용 패턴과 서비스 특성을 고려해 자원을 운영한 사례가 되었습니다.
- 비용만 강조한 설명: 사용하지 않는 서버를 꺼서 비용을 줄였습니다.
- 근거가 추가된 설명: 비용 내역을 확인해 실행 시간이 예상보다 길었다는 사실을 발견하고, 실습하지 않는 시간에는 인스턴스를 중지했습니다.
- 운영 관점이 보이는 설명: 서비스별 청구 내역과 접속 시간을 비교하니 컴퓨팅 자원이 실제 사용 시간보다 오래 실행되고 있었습니다. 데이터베이스 보존 여부를 먼저 확인한 뒤 애플리케이션 서버만 중지하는 기준을 만들었고, 예산 알림과 종료 점검표를 설정해 같은 상황이 반복되지 않도록 했습니다.
- 비용 실수도 숨기지 않으면 좋은 답변이 됩니다
면접에서는 처음부터 비용을 완벽하게 예측한 경험만 말해야 한다고 생각하기 쉽습니다. 하지만 예상하지 못한 청구가 발생했더라도 원인을 확인하고 관리 방식을 바꿨다면 충분한 문제해결 사례가 됩니다. 중요한 것은 실수한 금액이 아니라 어떤 정보를 확인했고, 같은 문제가 다시 발생하지 않도록 무엇을 적용했는지입니다.
실제 자료를 검토해 보면 비용을 줄였다는 한 줄만 적고 절감 전후의 기준을 남기지 않은 경우가 많습니다. 월별 금액을 과도하게 강조할 필요는 없지만, 어떤 자원이 비용을 발생시켰는지와 조치 후 변화는 기록하는 것이 좋습니다. 비용 알림을 설정한 화면만 첨부하기보다 알림 기준을 정한 이유, 초과 알림을 받았을 때 확인할 순서까지 정리하면 운영 경험으로 발전합니다.
로그와 확인 순서가 있는 장애대응 경험은 면접 답변이 됩니다
- 장애 현상과 원인을 구분해서 말해야 합니다
서비스가 열리지 않았다는 것은 현상이지 원인이 아닙니다. 서버가 중지되었을 수도 있고, 애플리케이션 프로세스가 종료되었거나 데이터베이스 연결이 끊겼을 수도 있습니다. 보안그룹, 방화벽, 도메인 설정, 인증서 만료처럼 외부 접근 경로에 문제가 생겼을 가능성도 있습니다. 따라서 장애 경험을 설명할 때는 처음 확인한 현상과 최종적으로 발견한 원인을 구분해야 합니다.
한 팀 프로젝트에서는 배포 후 회원가입 요청만 500 오류를 반환하고 조회 기능은 정상적으로 동작했습니다. 팀원들은 서버 전체에 문제가 있다고 생각해 인스턴스를 재시작했지만 현상은 달라지지 않았습니다. 준비생은 모든 기능이 멈춘 것이 아니라 데이터 저장이 필요한 요청에서만 오류가 발생한다는 점을 확인했습니다. 애플리케이션 로그를 살펴보니 운영 환경의 데이터베이스 테이블 구조가 최신 코드와 맞지 않았고, 배포 과정에서 변경된 스키마가 적용되지 않은 것이 원인이었습니다.
수정 후에는 회원가입 성공 여부만 확인하지 않았습니다. 중복 이메일, 빈 입력값, 데이터베이스 연결 실패 상황에서도 의도한 오류 응답이 나오는지 다시 검증했습니다. 이후 배포 절차에 스키마 변경 확인과 핵심 API 점검을 추가했습니다. 이 사례는 단순히 서버를 재시작해 해결한 경험보다 장애 범위를 좁히고 재발 방지 절차까지 만든 과정으로 설명할 수 있습니다.
- 장애가 발생하면 영향을 받는 기능부터 구분해야 합니다. 전체 접속이 불가능한지, 특정 요청만 실패하는지, 일부 사용자나 특정 시간대에서만 나타나는지를 정리하면 확인해야 할 범위를 줄일 수 있습니다.
- 로그는 많이 보는 것이 아니라 필요한 위치를 선택하는 것이 중요합니다. 웹 서버의 접근 기록, 애플리케이션 오류 내용, 데이터베이스 연결 상태를 요청 흐름에 따라 비교해야 어느 구간에서 실패했는지 판단할 수 있습니다.
- 원인을 찾는 순서는 면접관이 확인하는 핵심입니다
장애를 해결했다는 결과만 말하면 우연히 설정을 바꾸다가 정상화된 것인지, 근거를 가지고 접근한 것인지 알기 어렵습니다. 현상을 재현하고 최근 변경 사항을 확인한 뒤 서버 상태, 네트워크, 애플리케이션, 데이터베이스 순서로 범위를 좁혔다면 그 흐름을 그대로 설명하는 것이 좋습니다.
또 다른 실습에서는 이미지 업로드 기능을 추가한 뒤 서버 응답이 급격히 느려졌습니다. 준비생은 처음에 인스턴스 성능이 부족하다고 판단해 사양을 높이려 했지만, 모니터링 지표에서는 CPU 사용량이 크게 증가하지 않았습니다. 애플리케이션 로그와 파일 크기를 비교한 결과 원본 이미지를 압축하지 않고 서버 내부에 저장하면서 디스크 사용량과 처리 시간이 늘어난 문제가 확인되었습니다. 이미지 크기를 제한하고 별도 저장소로 분리한 뒤 응답 시간을 다시 측정해 개선 여부를 확인했습니다.
- 현상 중심 답변: 이미지 업로드가 느려져 서버 설정을 수정했습니다.
- 확인 과정이 담긴 답변: CPU 사용량이 높을 것으로 예상했지만 모니터링 결과가 달라 로그와 저장 공간을 추가로 확인했습니다.
- 면접에서 강점이 되는 답변: 이미지 업로드 이후 응답 시간이 늘어나 인스턴스 성능 문제를 먼저 의심했습니다. 그러나 CPU 사용량에는 큰 변화가 없어 요청별 로그와 파일 용량을 비교했고, 대용량 원본 파일을 서버 내부에 저장하는 과정이 지연의 원인임을 확인했습니다. 업로드 크기를 제한하고 저장 위치를 분리한 뒤 같은 조건으로 다시 측정했으며, 배포 전 파일 처리 기준을 점검 항목에 추가했습니다.
- 복구 이후의 기록이 성장 경험을 완성합니다
장애가 해결되면 바로 다음 기능 개발로 넘어가기 쉽지만, 면접 자료는 복구 이후에 만들어집니다. 발생 시간, 사용자에게 나타난 현상, 영향을 받은 기능, 확인한 순서, 최종 원인, 수정 내용, 재검증 결과를 남겨야 합니다. 여기에 다시 발생했을 때 먼저 볼 로그와 재발 방지 방법을 추가하면 개인 실습도 운영 경험처럼 정리할 수 있습니다.
모든 장애에 복잡한 자동 복구 체계를 적용할 필요는 없습니다. 신입 단계에서는 동일한 상황을 재현할 수 있는지, 변경 전후를 비교했는지, 수정으로 다른 기능이 영향을 받지 않았는지 확인하는 태도가 더 중요합니다. 실제 면접 답변을 점검하면 실패한 경험이 없어서 할 말이 없는 것이 아니라, 오류가 해결된 직후 과정을 기록하지 않아 설명할 근거가 사라진 경우가 많습니다. 간단한 접속 실패라도 당시의 가설과 확인 결과를 남기면 기술 이해와 문제해결 방식을 보여주는 사례가 됩니다.
- conclusion
클라우드 실습을 면접에서 설명할 때는 사용한 서비스의 수보다 자신의 판단이 들어간 장면을 찾아야 합니다. 서버를 생성하고 웹 화면을 띄운 결과만으로는 지원자가 구조를 이해했는지 확인하기 어렵습니다. 반면 접속이 되지 않았을 때 키 권한과 보안그룹, 실행 포트를 어떤 순서로 확인했는지 설명하면 문제를 나누어 접근한 방식이 보입니다. 예상하지 못한 비용이 발생했을 때 서비스별 청구 내역을 확인하고 남은 자원을 정리한 경험도 실제 운영 감각을 보여주는 자료가 됩니다.
지금 자신의 프로젝트를 다시 살펴본다면 구성도와 완료 화면만 확인하지 말고 실습 도중 막혔던 장면을 먼저 찾아보는 것이 좋습니다. 당시 어떤 현상이 나타났는지, 처음에는 무엇을 원인으로 예상했는지, 실제 로그와 설정을 확인한 뒤 판단이 어떻게 달라졌는지를 순서대로 적어보세요. 처음 예상이 틀렸더라도 근거를 확인해 방향을 수정했다면 오히려 답변의 깊이를 높일 수 있습니다.
- 서버배포 과정에서는 인스턴스 생성부터 외부 접속까지의 흐름을 자신의 말로 설명할 수 있어야 합니다. 사용한 서비스마다 선택 이유를 붙이고, 본인이 직접 설정하거나 검증한 범위를 구분하면 협업 프로젝트에서도 역할이 선명해집니다.
- 비용을 점검할 때는 무료 사용 여부만 확인하지 말고 실제 사용량과 연결된 자원을 함께 살펴봐야 합니다. 예상 금액과 청구 내역의 차이, 불필요한 자원을 발견한 과정, 예산 알림과 종료 기준까지 정리하면 관리 경험으로 활용할 수 있습니다.
- 장애 경험은 해결했다는 결론보다 현상, 가설, 확인, 수정, 재검증의 흐름으로 남겨야 합니다. 서버 로그와 애플리케이션 상태를 비교하고 재발 방지 항목을 추가했다면 작은 오류도 충분한 면접 사례가 됩니다.
실제 클라우드 포트폴리오를 검토하면 아키텍처 그림은 잘 만들어져 있지만 배포 중 발생한 문제와 비용을 확인한 기록은 빠져 있는 경우가 많습니다. 이런 자료는 무엇을 사용했는지는 보여주지만 지원자가 어떻게 일하는지는 보여주지 못합니다. 면접관이 궁금해하는 것은 완벽한 환경을 한 번에 구축했는지가 아니라 예상과 다른 상황에서 정보를 확인하고 다음 행동을 결정할 수 있는지입니다.
배포 명령어, 설정 변경 이유, 비용 내역을 확인한 기준, 장애를 좁힌 순서를 프로젝트 문서에 남겨보세요. 이 기록은 이력서에서는 문제해결 성과로 압축할 수 있고, 포트폴리오에서는 개선 과정으로 보여줄 수 있으며, 면접에서는 후속 질문에 답하는 근거가 됩니다. 결국 클라우드 실습이 취업 자료로 바뀌는 시점은 서버가 처음 실행된 순간이 아니라, 그 환경을 구성하고 관리하며 복구한 과정을 자신의 언어로 설명할 수 있게 되었을 때입니다.
