이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
IAM 플랫폼 개발에서 가장 중요한 것은 최소 권한 원칙(Principle of Least Privilege)입니다. 사용자가 필요한 것만 접근할 수 있도록 권한을 세밀하게 설계해야 하는데, 처음부터 넓게 열어두면 나중에 줄이기가 어려워집니다. 또한 인증과 인가를 분리해서 설계하는 것도 중요합니다. 인증은 '누구인지 확인', 인가는 '무엇을 할 수 있는지 결정'이라는 두 단계가 명확히 분리되어야 확장성과 감사 가능성이 보장됩니다.
RBAC이나 ABAC 모델 중 어느 것을 사용할지도 서비스 구조에 따라 신중하게 선택해야 합니다. 확장성과 감사 가능성을 동시에 확보하는 설계가 좋은 IAM의 기준이라고 생각합니다.
IAM 설계에서 제가 중요하게 생각하는 건 운영 편의성과 보안 강도의 균형이에요. 보안만 강조하면 사용자 경험이 나빠지고, 편의성만 추구하면 권한 관리가 허술해져요. 실제로 프로젝트에서 JWT 기반 인증을 구현할 때 토큰 만료 시간을 짧게 하면 재인증이 잦고, 길게 하면 탈취 시 리스크가 커지는 문제를 겪었어요. 그래서 리프레시 토큰 구조를 함께 설계하게 됐고, 보안 요구사항과 UX를 동시에 만족시키는 설계를 고민하는 습관이 생겼어요. 그 경험으로 보안 설계는 사용자 경험을 항상 함께 고려해야 한다는 걸 알았어요.
보안과 UX의 균형이 좋은 IAM 설계의 척도예요.
IAM 플랫폼에서 간과하기 쉬운 게 감사 로그(Audit Log) 설계예요. 누가 언제 어떤 권한으로 무엇을 했는지를 추적할 수 있어야, 보안 사고가 났을 때 원인 분석과 범위 파악이 가능해요. 권한 설계만큼 로그 설계가 먼저 이뤄져야 이후 운영이 가능해요. 저는 개인 프로젝트에서 로그인 이력과 권한 변경 이력을 별도 테이블로 분리해 관리한 적이 있는데, 나중에 이슈가 생겼을 때 빠르게 추적할 수 있었어요. 그 경험으로 IAM 플랫폼에서 로그가 기능만큼 중요하다는 걸 알았어요.
로그 설계가 기능 설계만큼 중요하다는 걸 그 경험으로 알았어요. 로그 설계가 기능 설계만큼 중요하다는 걸 그 경험으로 확인했어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.