로그인 전 데이터 마스킹을 프레젠테이션 계층에 두는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

로그인하지 않은 사용자에게 일부 정보만 가려 보여줘야 한다면 서버 응답에서 원문을 제거하거나 대체해야 한다. 브라우저의 블러 효과만으로는 보호할 수 없다. 스타일을 지우면 이미 내려받은 원문이 그대로 보이기 때문이다. 게스트 화면을 위한 마스킹이라면 응답을 만드는 프레젠테이션 경계가 대체로 가장 자연스러운 위치다.

판단 기준은 그 규칙의 주인이다. 비즈니스 개념 자체의 규칙인지, 특정 화면이 특정 사용자에게 개념을 보여주는 방식인지 구분해야 한다.

블러 처리할 비밀 대신 안전한 응답을 보낸다

애플리케이션 안에서 경력 정보는 온전하게 유지한다. 게스트가 요청하면 프레젠테이션 계층이 UI에 필요한 대체 문자열을 담은 응답을 만든다. 로그인한 사용자에게는 원래 값을 내려준다. 게스트의 브라우저에는 그 원문이 처음부터 도착하지 않는다.

이렇게 하면 안쪽 객체가 반복된 X 같은 가짜 값을 품을 필요가 없다. 경력 정보를 읽는 서비스마다 현재 사용자를 넘겨 마스킹 분기를 만들 이유도 줄어든다. UI 요구가 사라지면 응답 매핑에서만 제거할 수 있다.

작성자 표식도 같은 경계에서 계산한다

댓글 작성자가 게시글 작성자와 같을 때 ‘작성자’ 배지를 보여주는 목록을 생각해 보자. 게시글 서비스는 게시글을, 댓글 서비스는 댓글 목록을 가져오면 된다. isAuthor를 댓글의 본질적인 속성으로 만들 필요는 없다. 두 정보를 모두 가진 바깥 경계에서 비교한 뒤 화면용 플래그를 만들 수 있다.

이 구분은 일시적인 UI 요구가 영구적인 도메인 필드가 되는 일을 막는다. 배지가 사라지면 응답 조립만 바뀌고 댓글의 핵심 동작은 그대로 남는다.

사용자에 따라 달라진다고 모두 프레젠테이션 규칙은 아니다

이 경계가 모든 경우에 맞는 것은 아니다. 마스킹이나 표식이 UI 때문에 생겼다면 응답을 조립하는 곳에 둔다. 반대로 비즈니스 개념 자체에 중요한 규칙이라면 관련 비즈니스 로직에 둘 수 있다. 위치는 상황에 따라 달라진다.

이 글의 게스트 마스킹과 작성자 표식은 프레젠테이션 쪽에 속한다. 그 경계를 지키면 클라이언트에는 보여도 되는 데이터만 보내면서도 안쪽 모델에는 화면의 임시 언어를 섞지 않을 수 있다.