공개 데이터와 내부 데이터를 분리하는 법

자동화 워크플로우 시리즈 7/8

운영 자동화에서 자주 놓치는 지점이 있다.

내부에서 보는 데이터와 외부에 보여줄 데이터는 같지 않다.

같은 원천에서 만들어졌더라도 공개 화면에 나가는 데이터는 반드시 별도로 가공해야 한다.

화면에서 숨기는 것만으로는 충분하지 않다. API 응답이나 JSON 파일에 포함된 정보는 사용자가 개발자 도구로 볼 수 있다.

문제 상황

운영자는 신청 데이터를 자세히 봐야 한다.

신청자 정보, 내부 상태, 검토 메모, 처리 결과, 예외 여부 같은 정보가 필요하다.

하지만 외부 사용자에게 공개해야 하는 정보는 훨씬 제한적이다.

예를 들어 공개 페이지에는 일정, 신청 가능 여부, 집계 결과, 가격 범위, 상태 정도만 보여주면 될 수 있다.

이때 내부 데이터를 그대로 내려주고 화면에서 일부 필드를 숨기면 위험하다.

데이터는 이미 브라우저에 도착했기 때문이다.

공개용 데이터는 따로 만든다

공개 화면이 있다면 공개용 데이터 파일이나 API 응답을 별도로 만들어야 한다.

구조는 이렇게 나눌 수 있다.

internal/latest-data.json
public/public-calendar.json

또는 S3 경로 기준으로 나눌 수 있다.

console-data-bucket/
├── latest/data.json
└── public/calendar-YYYY-MM.json

핵심은 public 경로에는 공개 가능한 필드만 들어가야 한다는 것이다.

필드 제거는 서버 또는 생성 단계에서 한다

민감한 필드는 프론트엔드에서 제거하면 안 된다.

나쁜 방식:

const publicData = data.map(item => {
  delete item.phoneNumber;
  return item;
});

이 방식은 이미 전체 데이터가 브라우저에 내려온 뒤 제거한다.

좋은 방식은 데이터 생성 단계에서 제거하는 것이다.

const publicData = sourceData.map(item => ({
  date: item.date,
  status: item.publicStatus,
  count: item.applicationCount
}));

브라우저는 처음부터 공개 가능한 데이터만 받는다.

내부 데이터에 들어갈 수 있는 것

내부 운영자용 데이터에는 더 많은 정보가 필요할 수 있다.

• 신청자 식별 정보
• 연락처
• 내부 상태값
• 검토 메모
• 담당자 판단
• 원본 입력값
• 수정 이력
• 오류 사유

이 정보는 운영에는 필요하지만 공개하면 안 된다.

내부 데이터는 인증된 운영자 화면에서만 접근해야 한다.

공개 데이터에 들어갈 수 있는 것

공개 데이터는 최소화한다.

예를 들어 다음 정도로 제한할 수 있다.

• 날짜
• 공개 상태
• 공개 가능한 이름 또는 익명화된 라벨
• 집계 수치
• 가격 또는 범위
• 안내 문구

공개 데이터는 "보여줘도 되는 정보"가 아니라 "보여줘야 하는 정보"만 포함하는 것이 좋다.

접근 경로도 분리한다

데이터만 나누는 것으로 끝나지 않는다.

접근 경로도 분리해야 한다.

예시:

영역	경로	접근
내부 운영자	/admin/*	인증 필요
공개 사용자	/public/*	공개 접근
내부 API	/api/internal/*	인증 필요
공개 API	/api/public/*	민감 정보 제거

CloudFront나 API Gateway를 쓴다면 경로별 캐시 정책과 보안 정책도 다르게 둘 수 있다.

공개 경로는 캐시를 허용할 수 있지만, 내부 경로는 더 짧은 TTL이나 인증 정책이 필요할 수 있다.

공개 데이터 생성 체크리스트

공개용 JSON이나 API를 만들 때는 다음을 확인한다.

• 개인정보가 포함되어 있지 않은가
• 내부 상태값이 그대로 노출되지 않는가
• 운영자 메모가 제거되었는가
• 원본 row id나 내부 식별자가 필요 이상 노출되지 않는가
• 에러 메시지가 내부 구조를 드러내지 않는가
• 캐시되어도 괜찮은 데이터인가
• 공개 기간이 끝난 뒤 접근 가능해도 되는가

특히 내부 상태값은 조심해야 한다.

운영자는 PENDING_REVIEW, MANUAL_HOLD, INTERNAL_REJECTED 같은 상태를 볼 수 있지만, 공개 사용자에게는 단순히 접수, 마감, 확정 정도만 보여주는 것이 좋다.

공개용 데이터는 테스트해야 한다

공개 데이터 생성 로직은 테스트 대상이다.

다음 테스트가 필요하다.

• 민감 필드가 포함되지 않는지
• 빈 데이터일 때 정상 응답하는지
• 잘못된 원본 값이 들어와도 공개 JSON이 깨지지 않는지
• 날짜나 상태 필터가 올바른지
• 공개 기간이 지난 데이터가 노출되지 않는지

작은 자동화라도 공개 데이터는 신뢰와 연결된다.

내부 화면보다 더 보수적으로 봐야 한다.

공개 데이터와 캐시

공개 데이터는 캐시하기 쉽다.

대부분 읽기 전용이고, 많은 사용자가 같은 데이터를 본다.

하지만 캐시를 오래 두면 변경 반영이 늦을 수 있다.

그래서 공개 데이터는 다음 기준을 정해야 한다.

• 얼마나 자주 바뀌는가
• 사용자가 몇 분 정도 지연을 받아들일 수 있는가
• 중요한 변경 시 수동 invalidation을 할 것인가
• 파일명에 월이나 버전을 포함할 것인가
• 공개 종료 후 파일을 보관할 것인가

공개 데이터 분리는 보안뿐 아니라 캐시 전략에도 영향을 준다.

정리

내부 데이터와 공개 데이터는 같은 원천에서 만들어질 수 있다.

하지만 같은 형태로 제공되어서는 안 된다.

공개 데이터는 별도로 생성하고, 민감 정보는 서버 또는 생성 단계에서 제거해야 한다.

핵심 원칙은 단순하다.

• 브라우저에 내려간 데이터는 공개된 데이터로 본다.
• 화면에서 숨기는 것은 보안이 아니다.
• 공개 API와 내부 API는 응답 구조부터 달라야 한다.
• 공개 데이터에는 필요한 정보만 포함한다.

운영 자동화에서 데이터 분리는 기능이 아니라 신뢰의 문제다.

함께 볼 GitHub 저장소

• workflow-automation-samples