이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 AWS에 서비스를 올릴 때 처음에는 루트 계정을 직접 사용하여 배포하였습니다. 보안 관련 글을 읽다가 루트 계정 사용이 위험하다는 것을 알게 되었습니다. 이후 IAM 사용자를 만들고, 서비스별로 최소 권한만 부여하는 방식으로 다시 설정하였습니다. Lambda에는 S3 읽기 권한만, EC2에는 RDS 접근 권한만 부여하는 식이었습니다. 처음에는 너무 좁게 권한을 설정하여 Lambda 실행이 실패했는데, CloudWatch 로그에서 AccessDenied를 확인하고 필요한 권한을 추가하였습니다. 권한을 넓게 주고 나중에 줄이는 것보다 좁게 시작하여 필요할 때 여는 방식이 더 안전하다는 것을 배웠습니다. 경험을 통해 배운 내용을 바탕으로 앞으로도 이 방향으로 성장하겠습니다.
동아리 프로젝트에서 팀원 6명이 같은 서버에 접근해야 했어요. 처음엔 비밀번호를 다 같이 공유했는데, 팀원이 바뀌어도 비밀번호가 그대로라 나중엔 누가 접근할 수 있는지 알 수 없었어요. SSH 키 기반 인증으로 바꾸고 각자 공개키를 등록하는 방식으로 바꿨어요. 탈퇴한 팀원은 키를 삭제하면 됐어요. 이 경험으로 인증은 공유 자격증명보다 개인별 자격증명이 관리 가능하다는 걸 배웠어요. 회사에서 IAM 계정을 개인별로 만드는 이유가 감사 로그와 권한 회수 때문이라는 것도 이때 이해했어요.
경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다. 그 과정이 값진 배움이었습니다.
인턴 때 테스트 환경 설정을 맡았는데 편의상 광범위한 권한을 부여했어요. 팀원 한 명이 실수로 운영 DB를 테스트 환경에서 조회하는 쿼리를 날린 일이 있었어요. 다행히 읽기 전용이라 데이터 손실은 없었지만 운영 데이터가 노출됐다는 건 문제였어요. 멘토에게 보고했고, 테스트 환경과 운영 환경을 엄격하게 분리하는 작업을 하게 됐어요. 이 경험으로 환경별 권한 분리가 왜 중요한지 직접 느꼈어요. 테스트 환경이라도 운영 리소스 접근은 별도로 막아야 한다는 원칙이 생겼어요.
이 과정에서 얻은 인사이트는 지금도 제 업무 방식에 영향을 주고 있습니다. 꼼꼼하게 확인하는 습관이 결국 품질을 만든다고 믿습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.