홈페이지의 언어를 정할 때 방문자만 생각하면 운영자가 매일 해야 할 판단을 놓칠 수 있다. K-POP PULSE의 초기 구조는 공개 사이트를 영어 중심으로, 뉴스룸 관리를 한국어 중심으로 나누었다. 나는 이를 번역할 페이지의 수보다 서로 다른 일을 하는 두 사람의 화면으로 읽는다.

당시 관리자 템플릿에는 이슈 인박스·기사·이벤트 같은 한국어 메뉴와 확정 이벤트 관리라는 제목이 실제로 들어 있다. 공개 홈의 영어 메뉴도 확인했다. 여기서는 이 초기 선택과 기록을 설명한다. 지금 원본 사이트의 모든 관리자 화면을 새로 로그인해 검수한 이야기는 아니다.

독자는 정보를 읽고 운영자는 공개할 것을 결정한다

공개 독자는 새 소식과 일정, 낯선 표기의 뜻을 찾는다. 운영자는 원문이 맞는지, 일정이 확정됐는지, 어떤 상태의 글을 공개할지 판단한다. 같은 자료를 보더라도 화면이 안내해야 할 행동은 다르다. 공개 메뉴를 그대로 관리자 메뉴에 복제할 필요는 없었다.

나는 관리 화면의 말이 사용자의 다음 행동을 설명해야 한다고 본다. 기사와 이슈가 다른 저장 단위라면 그 구분을 운영자가 읽을 수 있어야 하고, 확정이라는 표시는 어떤 근거를 요구하는지 연결되어야 한다. 기술 용어를 줄이는 일과 데이터의 구분을 없애는 일은 같지 않다.

한국어 화면에서도 데이터의 식별자는 유지한다

초기 이벤트 화면에서는 한국어로 아티스트·제목·시작 시각·국가·장소를 안내하면서 이벤트 유형에는 프로그램의 값을 사용했다. 화면의 설명을 바꾸더라도 저장되는 값과 연결이 제각각 달라지면 다른 도구가 같은 자료를 읽기 어려워진다.

내가 가져갈 기준은 사용자가 읽는 이름과 프로그램이 사용하는 식별자를 구별하는 것이다. 라벨은 바꿀 수 있지만 어떤 값이 무엇을 뜻하는지는 계약으로 남긴다. 코드에 익숙하지 않은 운영자가 선택해도 공개 화면과 API가 같은 의미를 읽어야 한다.

라벨을 번역해도 시각과 상태까지 자동으로 맞지는 않는다

관리 템플릿의 KST 표시는 입력자가 어떤 시간으로 적어야 하는지 알려 준다. 하지만 글자가 한국어이고 시간대 이름이 표시되었다는 사실만으로 저장과 공개 출력의 환산이 맞다고 확인할 수는 없다. 이 조건은 별도의 데이터와 코드 검사가 필요하다.

나는 언어 검수와 의미 검수를 나누려 한다. 입력 라벨이 이해되는지 보고, 실제 저장한 날짜와 상태를 읽고, 공개 독자에게 같은 뜻으로 전달되는지 대조한다. 번역한 버튼 하나에도 어떤 상태 전이가 일어나는지 설명해야 하는 이유다.

운영자의 언어가 공개 원고의 언어를 대신하지 않는다

이 프로젝트의 운영 기록에서는 한국어로 초안의 범위와 금지 조건을 전달하고 영어 원고를 작성하게 하는 장면이 있다. 작업 요청의 언어와 최종 문서의 언어를 구별한 것이다. 한국어 안내가 편하다고 공개 영어 글의 표현과 사실 검사가 생략되는 것은 아니다.

다른 홈페이지에도 적용할 수 있다. 관리자가 편한 언어로 작업 기준을 읽고, 고객이 읽는 언어의 원고를 별도로 검토한다. 번역이 필요한 내용과 그대로 유지해야 하는 이름·날짜·수치·상태를 처음부터 정하면 설명과 데이터가 서로 어긋나는 일을 찾기 쉬워진다.

같은 뜻을 지키면서 화면의 말은 바꿀 수 있다

아래는 이 선택을 설명하기 위한 새 데이터 예시다. 날짜와 상태의 원본 값에 한국어·영어 표시를 연결한다. 당시 시스템의 실제 저장 형식을 복원한 것은 아니며, 시간 변환이나 전체 번역 기능도 포함하지 않는다. 표시와 뜻을 구별하는 출발점이다.

실제 적용에서는 운영자가 읽는 상태 설명과 공개 독자가 읽는 설명을 각각 작성한다. 임시 저장과 발행, 취소와 중복 정리처럼 의미가 다른 상태를 번역 때문에 같은 단어로 합치지 않는다. 사용하는 사람이 바뀌어도 데이터의 뜻을 다시 확인할 수 있게 한다.

코드와 구현 살펴보기

새 설명용 표시 모델. 날짜 환산·실제 CMS 저장 형식을 구현한 코드가 아니다.

{
  "state": "confirmed",
  "date": "2026-11-12",
  "labels": {
    "ko": "확정 일정",
    "en": "Confirmed date"
  }
}

실제 적용에서는 두 사람의 작업을 각각 따라가 본다

내가 읽은 초기 코드와 구조 문서는 두 화면의 언어와 역할을 나눈 근거다. 현재 공개 영어 홈은 확인했지만 현재 원본 CMS의 전체 번역이나 권한·입력 흐름까지 새로 검증한 것은 아니다. 초기 설계와 지금 확인한 범위를 섞어 하나의 완료 보고로 만들지 않는다.

다른 사이트에 이 선택을 적용한다면 관리자는 원문 확인부터 저장·미리보기·발행까지, 독자는 소식 찾기부터 일정 이해와 문의까지 실제로 따라가 본다. 읽는 말이 다르더라도 같은 자료의 날짜·상태·근거가 유지되는지 확인하는 것이 두 언어를 나눈 이유와 맞는 검사다.