이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 환경은 아니었지만, 학부 캡스톤 프로젝트에서 소규모 서비스 보안 아키텍처를 설계했습니다. 인증 서버 분리, API 게이트웨이에 Rate Limiting 적용, 로그 수집 구조 설계를 맡았습니다. 팀원들이 기능 구현에 집중하는 동안 보안 요구사항을 정의하고 각 컴포넌트에 적용하는 역할을 주도했습니다. 어려웠던 건 보안과 성능 사이의 트레이드오프를 설명하는 것이었는데, 모든 요청에 암호화를 적용하면 응답 시간이 늘어났습니다. 결국 민감도 높은 요청에만 적용하는 방식으로 합의했고, 이 경험에서 보안 결정은 기술보다 팀 합의가 중요하다는 걸 배웠습니다.
보안 결정은 기술보다 팀 합의가 먼저라는 걸 이 경험에서 배웠고, 실무에서도 그 원칙으로 보안 아키텍처를 설계하겠습니다.
직접 인프라를 구축하는 것을 주도했다기보다는, 팀 내에서 보안 취약점을 발굴하고 우선순위를 정하는 역할을 맡은 경험이 있습니다.
웹 서비스 사이드 프로젝트를 진행하던 중, 배포 전 보안 점검 리스트를 작성하고 팀원들과 함께 검토하는 과정을 제안했습니다. OWASP Top 10을 기준으로 항목을 나열하고, 각 항목이 우리 서비스 구조에서 어디에 해당하는지 매핑하는 방식으로 진행했습니다.
가장 까다로웠던 부분은 세션 관리와 인증 토큰 저장 방식을 결정하는 것이었습니다. localStorage에 JWT를 저장하는 방법이 구현이 쉬웠지만, XSS 공격에 취약하다는 점을 확인한 뒤 httpOnly 쿠키로 전환하는 방향으로 합의했습니다. 기능 구현 속도가 늦어졌지만, 배포 이후 문제가 없었습니다.
이 경험에서 보안 결정은 단독으로 내리기보다 팀 전체의 이해를 함께 끌어올리는 과정이 필요하다고 느꼈습니다. 혼자 알고 혼자 막는 구조는 팀원이 바뀌면 그대로 무너지는 구조이기 때문입니다.
인프라를 처음부터 설계하는 경험은 없었지만, 기존에 운영 중인 서비스의 보안 상태를 점검하고 개선 우선순위를 정하는 과정에 참여한 적이 있습니다.
오픈소스 취약점 스캐닝 도구(OWASP ZAP)를 활용해 팀 프로젝트의 보안 점검을 진행했는데, 예상보다 훨씬 많은 항목이 취약점으로 분류되었습니다. 모든 항목을 한꺼번에 수정하는 것은 현실적으로 불가능했기 때문에, 심각도와 공격 가능성을 기준으로 우선순위를 정하는 방식을 선택했습니다.
그 과정에서 배운 점은 보안 작업은 완료 상태가 없다는 것입니다. 하나를 수정하면 연결된 다른 부분에 영향이 생기는 경우가 있었고, 패치 이후 회귀 테스트가 반드시 필요하다는 걸 직접 경험했습니다.
또 하나는 스캐너가 탐지한 것이 전부가 아니라는 점입니다. 자동화 도구가 잡지 못하는 로직 취약점(인가 우회, 과도한 데이터 노출)은 직접 요청을 만들어 확인해봐야 했습니다. 이 경험 이후 보안을 점검할 때 도구와 수동 검토를 함께 사용하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.