에이전시 3곳, 타임존 2개, 고객사 검수 사이클이 도는 프로젝트에서 가장 비싼 모호함은 "상품 페이지"라는 말입니다. 어떤 걸 말하는 걸까요. 리스트인지, 상세인지, 비교 뷰인지, 모바일 변형인지. Screen ID는 이 질문을 영구히 없애 주고, 비용은 스프레드시트 한 열입니다.
Screen ID는 무엇을 위한 것인가
Screen ID는 IA상의 화면 하나를 가리키는 짧고 안정적인 식별자입니다. IA 시트에도, Figma 프레임 이름에도, 개발 티켓에도, QA 테스트 케이스에도, 고객사 피드백 메일에도 같은 문자열이 등장합니다. 모두가 같은 것을 가리키게 됩니다.
프로젝트 규모가 커질수록 효과가 누적됩니다.
- 모호함 제거. "LAF-KR-P-03에 사이즈 선택이 빠졌습니다"에는 부연 설명이 필요 없습니다.
- 추적 가능성. 요건 → 디자인 → 구현 → 테스트 케이스가 같은 키로 연결됩니다.
- 범위 관리. ID 기준으로 화면 수를 세면 "화면 3개가 추가됐다"가 논쟁이 아니라 사실이 됩니다.
- 다국어 관리. 5개 시장의 같은 화면이 시장별 한 행씩, 공통 접미사로 묶입니다.
실무에서 버티는 체계
{BRAND}-{LOCALE}-{GROUP}-{SEQ}
LAF-KR-P-03
| | | └ 그룹 내 순번(0 패딩)
| | └ 기능 그룹
| └ 로케일
└ 브랜드/사이트 코드
브랜드(3자). 대문자, 사이트나 브랜드명에서 파생합니다. LAF, INN, SUL. 프로젝트 기간 내내 고정입니다.
로케일. KR, EN, JP, TW, GLOBAL. 실제 운영 시장을 쓰고, URL 로케일 세그먼트와 일치시켜 ID가 주소로 매핑되게 하세요.
그룹. Depth 0 기능 영역입니다. 대부분의 사이트를 커버하는 간결한 집합입니다.
| 코드 | 그룹 | 대표 화면 |
|---|---|---|
C |
공통 | GNB, Footer, 검색, 전역 모달 |
M |
메인 | 홈, Hero, 메인 섹션 |
P |
제품 | 카테고리, 리스트, 상세 |
B |
브랜드 | 브랜드 스토리, 철학 |
CO |
기업정보 | 회사소개, 연혁, 네트워크 |
S |
고객지원 | FAQ, 문의, 자료실 |
E |
이벤트 | 캠페인, 프로모션 |
CT |
콘텐츠 | 블로그, 아티클, 뉴스 |
A |
계정 | 로그인, 가입, 마이페이지 |
CTT / CHK |
장바구니 / 결제 | 장바구니, 주문, 결제 |
O |
기타 | 실제로 분류 불가한 것 |
순번. 두 자리 0 패딩. IA 시트의 읽기 순서대로 부여하며, 시트는 Depth 0으로 묶은 뒤 클릭 깊이 순으로 정렬합니다.
결과는 한눈에 읽힙니다. SUL-JP-P-07은 설화수 일본 사이트 제품 영역의 7번째 화면입니다.
이 체계를 작동시키는 규칙: ID 불변성
대부분의 네이밍 체계가 무너지는 지점입니다. 한번 발급된 ID는 의미가 바뀌지 않습니다.
- 삭제된 화면의 ID는 회수하되 재사용하지 않습니다.
P-03이 빠져도P-04가P-03이 되지 않습니다. 번호의 빈칸은 결함이 아니라 기록입니다. - 신규 화면은 다음 번호를 받습니다. 개념상 시트 중간에 들어가더라도 그렇습니다. 정렬은 열이고, 정체성은 열이 아닙니다.
- 화면 이름이 바뀌어도 ID는 유지합니다. '상품 상세'가 '아이템 상세'가 되는 건 라벨 변경입니다.
- 그룹 간 이동은 새 ID입니다. 기존 ID는 회수하고 이동 사실을 코멘트로 남깁니다. 유일하게 파괴적인 케이스이므로 그룹 택소노미는 초기에 확정하는 편이 좋습니다.
개정마다 ID가 흔들리면 하위 문서가 조용히 썩고, 결국 아무도 ID를 믿지 않게 됩니다. 그 시점에 우리는 다시 "상품 페이지"로 돌아갑니다.
크롤 결과에서 ID 생성하기
400개 화면에 손으로 ID를 매기면 하루가 걸리고 반드시 불일치가 생깁니다. 사이트 크롤 결과에서 생성하면 몇 분이면 되고 결정적입니다.
DeepAnalyzer는 크롤한 모든 화면에 대해 BRAND-LOCALE-GROUP-SEQ 키를 생성합니다. 브랜드는 호스트명에서, 로케일은 경로나 도메인에서, 그룹은 내비게이션 라벨과 URL 패턴의 택소노미 분류에서, 순번은 정렬된 IA 순서에서 나옵니다. 정렬이 안정적이므로 변경이 없는 사이트를 다시 크롤하면 같은 ID가 나옵니다.
경쟁사나 교체 예정 레거시 사이트의 AS-IS 분석이라면 대개 이것으로 충분합니다. TO-BE 문서라면 생성된 시트를 초안으로 두고, 시트가 승인되는 시점에 ID를 동결한 뒤 위의 불변성 규칙을 적용하세요. 생성 시점보다 동결 시점이 더 중요합니다.
프로젝트 전반에서의 활용
디자인. Figma 프레임명을 LAF-KR-P-03 Product Detail로 둡니다. 리뷰어가 스크린샷 없이 프레임을 지목할 수 있습니다.
개발. 티켓이 ID를 참조하고, 라우트 정의에 주석으로 남깁니다. IA 시트 대조 코드리뷰가 가능해집니다.
QA. 테스트 케이스가 ID와 1:1로 매핑되어 커버리지를 셀 수 있습니다. 화면 112개, 케이스 112개, 미검증 9개.
고객 커뮤니케이션. "연락처 페이지, 지도 있는 그거요, 다른 거 말고요" 대신 "LAF-KR-S-02: 대표번호가 잘못됐습니다"가 옵니다.
다국어. LAF-KR-P-03과 LAF-JP-P-03은 두 시장의 같은 화면이므로, 번역 범위와 시장별 차이가 한눈에 보입니다.
흔한 실수
너무 많은 정보를 담기. LAF-KR-PROD-DETAIL-SIZE-SELECT-01은 식별자가 아니라 설명문입니다. ID는 짧게 두고 설명은 옆 열에 쓰세요.
사이트 전체 통번호. LAF-KR-001 ~ LAF-KR-247 체계는 중간에 화면 하나만 추가해도 이후 전부가 재번호됩니다. 그룹 단위 순번이 영향 범위를 좁혀 줍니다.
URL을 ID에 인코딩하기. URL은 바뀝니다. ID는 바뀌면 안 됩니다.
공통 그룹 누락. GNB, Footer, 전역 검색도 IA 관점에서는 화면입니다. 요건도 디자인도 테스트 케이스도 있습니다. ID를 부여하세요.
에이전시별 다른 규칙. 킥오프에서 합의하세요. 6주차가 아니라.
자주 묻는 질문
그룹은 몇 개가 적당한가요?
8~12개입니다. 더 적으면 그룹이 정보를 주지 못하고, 더 많으면 사람들이 기억하지 못해 작성자마다 분류가 달라집니다.
한 화면이 두 그룹에 걸치면요?
요건을 소유한 쪽, 보통 주 내비게이션에 노출되는 위치를 기준으로 정하고 부차적 관계는 코멘트 열에 남깁니다. 화면 하나에 ID 하나입니다.
모달이나 팝업에도 ID를 주나요?
고유한 요건이 있으면 줍니다. 자체 문구·상태·오류 처리를 가진 확인 다이얼로그는 화면입니다. 툴팁은 아닙니다.
반응형 변형은 어떻게 처리하나요?
브레이크포인트별이 아니라 화면별로 하나의 ID를 두고, 반응형 동작은 같은 행에 기술합니다. 모바일과 데스크톱이 레이아웃이 아니라 플로우 자체가 다를 때만 ID를 분리하세요.
프로젝트 중간에 체계를 바꿔도 되나요?
초기에 한 번, 구↔신 매핑표를 만들어서라면 가능합니다. 그리고 현재 체계가 실제로 오류를 유발하고 있을 때만 그렇습니다. 디자인과 티켓이 ID를 참조하기 시작한 뒤에는 변경 비용이 이득을 거의 항상 넘어섭니다.