이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 관리자 전용 API를 설계하면서 보안 관련 엔드포인트의 특수성을 처음 체감했습니다. 일반 사용자 API와 달리 권한 범위와 감사 로그 요구가 훨씬 엄격했는데, 모든 관리자 액션에 누가 언제 무엇을 했는지를 기록하는 Audit Log 테이블을 별도로 설계했습니다. 자산 관리 기능에서는 리소스 상태 변경 API에 낙관적 잠금을 적용해 동시 수정 충돌을 방지했습니다.
관리자 콘솔 API에서 가장 중요한 건 되돌릴 수 없는 작업에 대한 확인 단계인데, 삭제 요청에 소프트 딜리트와 확인 코드를 요구하는 방식을 추가했습니다. 지금도 권한이 높은 API를 설계할 때는 감사 가능성을 설계 단계에서 먼저 고려하는 습관을 유지하고 있습니다.
관리자 콘솔 API를 만들면서 권한 검증 로직이 생각보다 복잡하다는 것을 경험했습니다. 인증 토큰으로 로그인 여부를 확인하는 것은 쉬웠는데, 특정 리소스에 접근할 때 그 리소스가 요청자의 것이 맞는지 확인하는 부분에서 놓친 경우가 있었습니다. 자산 목록을 조회하는 API에서 관리자 A가 관리자 B의 자산 ID를 직접 입력해 조회할 수 있는 취약점이 코드 리뷰에서 지적됐습니다. 리소스 접근 시 요청자가 해당 리소스의 소유자이거나 권한이 있는지 확인하는 검증을 각 엔드포인트마다 추가했는데, 이 로직이 중복됐습니다. 미들웨어에서 한 번에 처리하는 방식으로 리팩토링하니 누락 없이 일관되게 적용됐습니다. 보안 검증을 개별 엔드포인트에 분산시키면 실수로 빠뜨리는 경우가 생기는 반면, 미들웨어에서 강제하면 구조상 우회가 어려워진다는 것을 이 경험에서 배웠습니다.
관리자 콘솔 API에서 보안 관련 버그를 한 번 발견하면 유사한 패턴의 취약점이 다른 곳에도 있는지 전수 확인하는 습관이 생겼습니다. IDOR 취약점이 한 엔드포인트에서 발견되면, 리소스 접근이 있는 모든 엔드포인트를 같은 기준으로 검토했습니다. 감사 로그도 엔드포인트마다 다른 형식으로 남기다 보니 나중에 특정 관리자의 행위를 조회하는 것이 어려웠습니다. 로그 구조를 표준화해서 누가, 언제, 어떤 리소스에, 어떤 작업을 했는지가 일관된 형식으로 남도록 바꿨습니다. 보안 체크리스트를 만들어서 새 관리자 API를 PR에 올릴 때 감사 로그가 있는지, 소유자 검증이 있는지, 요청 속도 제한이 있는지를 확인하도록 했습니다. 이 체크리스트가 코드 리뷰에서 보안 항목을 빠뜨리지 않는 구조를 만들어줬습니다. 보안은 개인의 주의보다 구조적으로 빠뜨리기 어렵게 만드는 것이 재발 방지에 더 효과적이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.