이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
클라우드 환경에서 보안 아키텍처를 설계했던 경험에 대해 말씀드리겠습니다.
사이드 프로젝트로 AWS에 간단한 웹 서비스를 배포했는데, 처음에는 IAM 사용자에게 AdministratorAccess를 주고 시작했습니다. 편하게 사용하다가 보안 관련 글을 읽고 나서야 이게 잘못됐다는 것을 깨달았습니다. 최소 권한 원칙이라는 개념을 처음 접하고, 서비스에 필요한 권한만 선별하여 커스텀 IAM 정책을 만들었습니다. 처음에는 너무 좁게 권한을 설정하여 함수 실행이 안 되는 오류가 3번 발생했습니다. 로그에서 AccessDenied 에러를 확인하고 하나씩 권한을 추가했습니다.
전체 권한은 편리하지만 나중에 문제가 발생했을 때 피해 범위를 줄이기 어렵다는 것을 배웠습니다. 회사 환경에서도 권한을 좁게 시작하고 필요할 때 열어주는 방향이 맞다고 생각합니다.
클라우드에 배포한 개인 프로젝트에서 DB 비밀번호를 환경 변수 파일에 평문으로 저장하고 있었어요. 그게 문제인 건 알았는데 따로 관리하는 방법을 몰랐어요. AWS Secrets Manager를 처음 써봤는데 비용이 시크릿 하나당 월 0.4달러여서 개인 프로젝트엔 부담됐어요. 무료 대안으로 Parameter Store를 썼어요. 코드에서 직접 읽어오는 코드를 짜는 데 반나절 걸렸는데, 이후론 환경 변수 파일이 깃에 올라갈 일이 없어졌어요. 이 경험으로 시크릿 관리는 서비스 크기와 무관하게 처음부터 올바르게 하는 게 중요하다는 걸 배웠어요.
작은 프로젝트에서 나쁜 습관이 생기면 큰 프로젝트에서도 반복된다고 생각해요.
포트폴리오 프로젝트를 처음 배포할 때 HTTP만 설정하고 링크를 공유했어요. 피드백을 받는데 '브라우저에서 보안 경고가 뜬다'는 말을 들었어요. 그때 처음 HTTPS 설정을 직접 해봤는데, Let's Encrypt로 인증서를 발급받는 과정에서 도메인 인증이 실패해서 원인 파악하는 데 두 시간이 걸렸어요. DNS 설정이 전파되기 전에 인증을 시도한 게 원인이었어요. 인증서 갱신을 자동화하는 certbot renew cron도 설정했어요.
외부에 공개되는 서비스라면 HTTPS는 선택이 아니라는 걸 배웠어요. 이 경험 이후로 배포 체크리스트에 HTTPS 설정을 첫 항목으로 넣고 있어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.