이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 보안 수업과 사이드 프로젝트를 하면서 웹 보안 취약점을 처음 체계적으로 공부했습니다. 직접 만든 로그인 페이지에서 SQL 인젝션이 가능하다는 걸 테스트 중에 발견했고, 파라미터화 쿼리로 바꿔서 막았습니다. 세션 관리 쪽에서는 HttpOnly와 Secure 플래그를 쿠키에 추가하고, 세션 고정 공격을 막기 위해 로그인 성공 시 세션 ID를 갱신하는 방식을 적용했습니다. 입력 검증은 프런트엔드와 백엔드 양쪽에서 모두 처리해야 한다는 걸 배웠는데, 클라이언트 검증만 믿으면 우회가 가능합니다. 전송 구간에서는 HTTPS와 HSTS 헤더를 적용해 중간자 공격을 방어하는 구성을 익혔습니다.
보안은 기능을 다 만든 뒤 추가하는 게 아니라 처음 설계할 때부터 고려하는 자리라는 걸 그때부터 생각합니다.
보안 점검을 배포 전에 한 번 하는 것으로 충분하다고 생각했는데, 코드가 계속 변하면 새로운 취약점이 언제든 생길 수 있다는 것을 배웠습니다. SAST 도구를 CI 파이프라인에 연결해 PR이 올라올 때마다 정적 분석이 자동으로 돌도록 설정했습니다. 취약한 라이브러리 버전 사용이나 하드코딩된 인증 정보 같은 문제를 코드 리뷰 전에 자동으로 감지하니, 코드 리뷰에서 보안 이슈를 일일이 확인하는 부담이 줄었습니다. 처음에는 오탐이 많아서 규칙을 조정하는 데 시간이 걸렸지만, 안정화되고 나니 보안 점검이 개발 흐름에 자연스럽게 녹아들었습니다.
보안은 릴리즈 전 게이트가 아니라 개발 과정 전체에 녹아있어야 하는 결이라는 것을 이 경험에서 배웠습니다.
코드 리뷰에서 보안 관련 항목을 놓치는 경우가 있었습니다. 기능이 맞는지 확인하는 데 집중하다 보면 SQL 인젝션 방어나 XSS 필터링이 제대로 됐는지 체계적으로 확인하기 어려웠습니다. 팀과 함께 보안 코드 리뷰 체크리스트를 만들었습니다. 입력 검증·인증 로직·세션 관리·외부 의존성 보안 버전 — 이 네 가지를 기본으로 정해 PR 리뷰 시 체크하도록 했습니다. 체크리스트가 생기니 놓치는 항목이 줄었고, 리뷰어도 어떤 항목을 봐야 하는지 명확해졌습니다.
보안은 개인 역량이 아니라 팀이 공유하는 프로세스로 만들어야 지속 가능한 결이라는 것을 이 경험에서 배웠습니다. 체크리스트 한 장이 숙련도 차이를 어느 정도 메워주는 결이 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.