이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
분산 시스템 보안에서 가장 중요하게 생각하는 원칙은 최소 권한(Least Privilege)입니다. 각 서비스가 자신의 기능에 꼭 필요한 권한만 가져야 침해 발생 시 피해 범위를 줄일 수 있습니다. 사이드 프로젝트에서 마이크로서비스를 처음 설계했을 때, 처음에는 편의상 모든 서비스에 동일한 DB 권한을 줬습니다. 이후 보안 스터디에서 이게 얼마나 위험한지 배우고 서비스별로 읽기 전용·쓰기 권한을 분리했습니다. 또 서비스 간 통신에 인증 토큰 없이 내부망이라 안전하다고 생각했는데, mTLS 개념을 배우고 내부 통신도 인증이 필요하다는 걸 알았습니다. 아직 프로덕션 수준 보안을 직접 설계한 경험은 없어서 현장에서 배워야 할 부분이 훨씬 많습니다. 다만 위협 모델링을 설계 초반에 함께 하는 것과, 보안을 나중에 덧붙이는 게 아니라 처음부터 고려하는 것이 중요하다는 방향은 이해하고 있습니다.
분산 시스템 보안에서 위험 요소를 관리하는 접근으로 Zero Trust 개념이 인상적이었습니다. "내부망이라 안전하다"는 가정을 버리고, 모든 요청을 검증이 필요한 것으로 보는 원칙입니다. 사이드 프로젝트에서 mTLS를 적용하면서 실제로 서비스 간 통신에도 인증이 들어가야 한다는 걸 직접 경험했습니다.
침해가 발생했을 때 피해 범위를 어떻게 줄이느냐가 위험 관리의 핵심이라는 걸 공부하면서 배웠습니다. 공격을 완전히 막는 것은 불가능하다는 전제 아래, 탐지와 격리 능력을 설계 단계부터 반영하는 것이 현실적인 접근이라는 것도 이해했습니다. 아직 프로덕션 보안 경험은 없어서 현장에서 배울 부분이 많겠지만, 이 방향은 현장에서도 유효한 원칙이라고 생각합니다.
"안전하다고 가정하지 않는 것"이 보안 설계의 시작이라고 생각합니다. Zero Trust 원칙이 위험 관리의 기반입니다.
보안을 처음부터 고려한 설계가 나중에 수정 비용을 줄인 경험을 했습니다. 사이드 프로젝트에서 초기에 권한을 서비스별로 분리해두지 않고 나중에 고치려다 서비스 간 의존 구조를 전부 다시 봐야 하는 상황이 됐습니다. 그 경험 이후로 설계 단계에서 보안 체크리스트를 미리 넣는 방식을 쓰게 됐습니다.
보안은 개발이 끝난 뒤에 붙이는 것이 아니라 설계와 함께 가야 한다는 원칙이 그때 생겼습니다. 위협 모델링을 처음 배웠을 때 이론처럼 보였는데, 실제로 해보니 어디서 어떤 방식으로 공격이 들어올 수 있는지를 시각화하는 것이 설계 결정에 영향을 준다는 걸 확인했습니다.
좋은 설계는 기능만 담는 것이 아니라 위협도 함께 보는 것이라는 관점이 생겼습니다. 설계 단계 보안 통합이 비용과 위험을 같이 줄이는 방법입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.