기술 아키텍처 관점의 보안 설계 능력을 확인합니다. 보안을 단순 기능이 아닌 설계 원칙으로 반영하는지 평가합니다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
TA 관점에서 보안을 고려한다는 건 기능을 넣기 전에 '이 데이터가 누구에게 어디서 어떻게 보여야 하는가'를 먼저 따지는 것이라고 이해하고 있다. 예를 들어 사용자 인증 시스템을 설계할 때, 기능 명세만 보면 로그인·로그아웃 정도지만 TA 입장에서는 세션 토큰 만료 정책, 권한 범위 정의(RBAC), 민감 필드 마스킹, 감사 로그 보존 기간까지 함께 설계해야 한다고 생각한다. 외부 API를 연동할 때 인증 키를 환경변수가 아닌 시크릿 관리 도구에 분리하고, 내부 서비스 간 통신에도 최소 권한 원칙을 적용하는 것이 기본이다. 잠재적 위험 요소로는 설계 시점에 놓치기 쉬운 과도한 권한 부여가 있는데, 개발 편의를 위해 임시로 열어둔 권한이 프로덕션까지 올라가는 경우가 실제로 자주 보였다.
체크포인트를 설계 단계와 배포 전 두 곳에 두는 이중 확인 구조가 이 위험을 줄이는 데 효과적이라고 본다.
TA 관점에서 자주 놓치는 보안 영역 중 하나는 API 설계에서 에러 응답이 너무 많은 정보를 노출하는 것입니다. 예를 들어 로그인 실패 시 '이메일이 존재하지 않습니다'와 '비밀번호가 틀렸습니다'를 구분해 응답하면, 공격자가 유효한 이메일 주소를 열거할 수 있는 정보를 제공하게 됩니다. 올바른 설계는 두 경우 모두 '이메일 또는 비밀번호가 잘못됐습니다'로 동일하게 응답하는 것입니다. 또한 입력 검증을 클라이언트 단에서만 하는 경우도 보안 결함이 됩니다. TA 입장에서는 서버 단에서 독립적인 검증이 반드시 필요하다는 것을 설계 명세에 명시합니다. 이 원칙들이 중요한 이유는 보안 취약점의 상당수가 기능 자체보다 에러 처리나 예외 처리에서 발생하기 때문입니다.
보안 설계는 정상 흐름보다 예외 흐름을 먼저 생각하는 것에서 강해집니다.
TA 관점에서 보안을 설계에 녹이는 방법으로 STRIDE 위협 모델링을 배웠습니다. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege 각 항목을 기능별로 검토하면 기능 명세 단계에서 놓칠 수 있는 위협을 미리 발견할 수 있습니다. 수업 프로젝트에서 간단한 주문 시스템을 설계할 때 이 방법을 적용했는데, 주문 취소 기능에서 권한 확인 없이 다른 사용자 주문을 취소할 수 있는 취약점을 명세 단계에서 발견했습니다. 코드 단계가 아닌 설계 단계에서 발견하면 수정 비용이 훨씬 작다는 것이 위협 모델링의 핵심 가치입니다. TA가 이 과정을 주도하면 개발팀이 보안을 사후 검토가 아닌 설계의 일부로 인식하게 되는 효과도 있습니다.
보안을 나중에 덧붙이는 것보다 처음부터 설계에 포함하는 것이 더 낮은 비용으로 더 높은 안전성을 만듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신한카드 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.