이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
주니어 1년차 때 사내 시스템의 접근 허용 규칙을 손보는 일을 도왔습니다. 처음에는 '위험해 보이면 막자'는 식으로 단순하게 짰는데, 막상 적용하니 정상적으로 일하던 사람까지 막혀 문의가 쏟아졌습니다. 그래서 저는 규칙을 다시 보며 무엇을 기준으로 허용할지를 또렷이 정해야 한다는 걸 알았습니다. 저는 접속한 위치와 기기, 그리고 요청하는 자원의 민감도 세 가지를 놓고, 민감한 자원일수록 조건을 더 보게 했습니다. 처음에 막연한 느낌으로 규칙을 짠 게 문제였고, 판단 기준을 눈에 보이게 적어두는 일이 먼저라는 걸 배웠습니다. 지금도 저는 규칙을 만들 때 무엇을 보고 정하는지부터 글로 적습니다.
인턴 때 보안 솔루션이 제공하는 API를 이용해 접근 허용 여부를 자동으로 확인하는 작은 기능을 만들어본 경험이 있습니다. 사용자가 어떤 자원을 요청하면, 그 API에 정보를 보내 허용인지 거절인지 답을 받아오는 구조였습니다. 처음에는 API 답을 그대로 믿고 처리했는데, 가끔 API가 느리게 응답하거나 답이 안 올 때 화면 전체가 멈추는 문제가 있었습니다. 그래서 저는 일정 시간 안에 답이 안 오면 일단 거절로 처리하고 다시 시도하게 바꿨습니다. 처음에 외부 API가 항상 빠르게 답할 거라 여긴 게 오해였습니다.
답이 늦거나 없을 때를 미리 정해두는 일이 연동에서 중요하다는 걸 그때 배웠습니다.
주니어 2년차 때 새 접근 허용 규칙을 적용한 뒤, 그게 잘 돌아가는지 한동안 지켜본 경험이 있습니다. 적용 직후에는 문제가 없어 보였지만, 사수님이 '정말 의도대로 막고 허용하는지 확인했냐'고 물었습니다. 그래서 저는 2주간 규칙이 거절한 요청을 모아, 그중 정상 업무인데 막힌 경우가 있는지 살폈습니다. 살펴보니 외근 중인 직원의 접속이 위치 때문에 자주 막혀 열 건 넘게 문의가 있었습니다. 그래서 외근 신청을 한 경우는 예외로 두도록 규칙을 다듬었습니다. 규칙을 적용했다고 끝이 아니라, 실제로 누가 막혔는지를 들여다봐야 진짜 쓸 만해진다는 걸 배웠습니다. 지금도 저는 규칙을 적용하면 한동안 거절된 사례를 되짚습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.