이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 백엔드 API에 인증·인가 체계를 구현하는 작업을 맡았습니다. JWT 토큰 기반 인증을 처음 구현했는데, 처음에는 만료 시간을 너무 길게 설정해 탈취 시 노출 시간이 길다는 피드백을 받았습니다. refresh token 로테이션 방식으로 개선했고, 민감 엔드포인트에는 권한 검사 미들웨어를 따로 걸어 인증과 인가를 분리했습니다. 보안 요건을 개발 초반에 반영하지 않으면 나중에 구조를 바꾸는 비용이 크다는 걸 이 과정에서 실감했습니다.
코드 리뷰 단계에서 SQL 인젝션 가능성이 있는 쿼리 구성 방식을 지적받고 파라미터 바인딩으로 수정한 경험도 있습니다. 보안을 후반에 붙이는 것보다 설계 단계에서 위협 모델을 가볍게라도 검토하는 것이 비용과 품질 측면에서 훨씬 효율적이라는 걸 배웠습니다.
백엔드 서비스 개발 후반에 보안 요건을 반영하려다 구조 변경 비용이 크게 늘어난 경험이 있습니다. 팀 프로젝트에서 기능 구현을 먼저 완성한 후 마지막에 인증·권한 로직을 추가하려 했는데, 이미 구현된 API 흐름과 충돌이 생겨 여러 엔드포인트를 구조적으로 수정해야 했습니다. 기능과 보안 로직이 처음부터 분리 설계됐다면 훨씬 적은 변경으로 끝났을 것입니다.
보안은 기능 완성 후 추가하는 레이어가 아니라 설계 단계에서 함께 정의하는 요소입니다. 이후로는 기능 설계 시 인증·권한·입력 검증 요건을 API 명세와 함께 작성하는 방식을 택했습니다. 이 실패가 이후 서비스 설계 시 기능 요건과 보안 요건을 동일 단계에서 정의하는 기준이 됐습니다. 백엔드 보안 반영 비용은 설계 단계에서 포함할수록 기하급수적으로 낮아집니다.
백엔드 보안 요건을 외부 공격자 시각에서 생각해본 경험이 있습니다. 웹 보안 수업에서 실제 취약점 케이스를 분석했는데, 공격자가 가장 먼저 시도하는 것은 인증 우회와 권한 상승이라는 것을 알게 됐습니다. 개발자 입장에서 보기에 숨겨져 있는 API 엔드포인트도 공격자 입장에서는 추측 가능한 패턴입니다. 이 시각에서 보면, 백엔드 보안 요건은 내부 로직을 보호하는 것만큼 외부에서 보이는 공격 표면 자체를 줄이는 설계가 중요합니다. 이를 반영해 API 설계 시 공개 불필요한 엔드포인트는 기본적으로 비활성화하고, 내부 전용 경로는 네트워크 레벨 접근 제한을 병행하는 방식을 적용했습니다.
이 관점이 이후 백엔드 서비스를 설계할 때 기능 완성도와 공격 표면 최소화를 동시 기준으로 두는 습관을 만들었습니다. 백엔드 보안 설계의 출발점은 내부에서 지키는 것만큼 외부에서 보이는 것을 줄이는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 그래비티랩스 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.