템플릿화 시스템의 구조
템플릿화 시스템을 이해하려면 먼저 서비스가 세 가지 축으로 나뉜다는 것을 이해해야 합니다.
- Admin Side
- Data Side
- User Side
이 세 영역이 유기적으로 연결되어 하나의 자동화된 구조를 만듭니다.
Admin Side – 입력과 통제의 영역
Admin Side는 이벤트나 콘텐츠 운영에 필요한 정보를 입력하고 관리하는 백오피스 영역입니다. 운영자는 여기에서 이벤트 제목, 기간, 노출 여부, 당첨자 정보, 특정 유저 노출 조건 등을 설정합니다. 중요한 점은, 이 영역은 단순 입력 화면이 아니라 "어떤 데이터를 어떻게 저장할 것인가를 결정하는 통제 영역”이라는 점입니다. 운영자가 입력한 값은 데이터베이스에 저장되고, 이후 조회 기능을 통해 언제든지 다시 확인하거나 수정할 수 있어야 합니다. 즉, 백오피스는 단순 작성 도구가 아니라 시스템의 시작점입니다.
Data Side – 저장과 로직의 중심
Data Side는 데이터베이스(DB) 영역입니다. Admin에서 입력된 정보가 저장되고, 필요한 시점에 호출됩니다. 이 영역의 핵심은 “어떤 구조로 저장되었는가”입니다. 이벤트 정보와 신청 정보가 분리되어 있는지, 상태값이 코드로 관리되는지, 유형 구분이 존재하는지에 따라 확장성과 유지보수 난이도가 달라집니다. Data Side는 눈에 보이지 않지만, 템플릿 시스템의 실질적인 중심축입니다.
User Side – 출력과 경험의 영역
User Side는 최종적으로 사용자가 보는 화면입니다. 이 영역에서는 Data Side에서 불러온 데이터를 템플릿에 끼워 넣어 보여줍니다.
여기서 중요한 개념이 바로 FO 템플릿(Front Office Template)입니다. 템플릿은 하나일 수도 있고, 유형 1·2·3처럼 여러 개일 수도 있습니다. 이때 두 가지 설계 방식이 존재합니다.
- 하나의 구조 안에서 분기 처리하여 다양한 형태로 노출
- 유형별로 완전히 분리된 템플릿을 별도로 운영
이 선택은 기획과 개발의 자유도, 운영 복잡성, 확장 계획에 따라 달라집니다.
템플릿 시스템의 작동 원리
작동 구조는 단순합니다.
- 어드민에서 이벤트 정보를 입력한다.
- 데이터베이스에 저장된다.
- 프론트 템플릿이 해당 데이터를 불러온다.
- 템플릿 유형에 따라 로직이 분기된다.
- 최종 화면이 노출된다.
여기서 핵심은 “로직화”입니다. 어떤 유형일 때 어떤 항목을 노출할지, 특정 값이 있을 때만 보여줄지, 없으면 숨길지 등을 미리 설계해 두어야 합니다. 기획자가 로직을 정의하지 않으면 개발자는 화면을 고정 구조로 만들 수밖에 없습니다.
기획 시 반드시 병행되어야 할 세 가지 설계
템플릿 시스템을 설계할 때는 세 가지 기획이 동시에 이루어져야 합니다.
1. 프론트 기획
어떤 UI가 고정 영역이고, 어떤 영역이 데이터 교체 영역인지 구분해야 합니다. 고정 구조와 가변 데이터를 명확히 나누는 것이 핵심입니다.
2. 데이터 기획
프론트가 필요로 하는 데이터를 정의해야 합니다. 예를 들어 템플릿에서 “혜택 배너”를 노출하려면, DB에 혜택 배너 관련 필드가 존재해야 합니다.
3. 백오피스 기획
운영자가 어떤 값을 입력해야 하는지, 어떤 값을 선택하도록 할지 설계해야 합니다. 입력 구조가 불명확하면 프론트 로직도 불안정해집니다.
템플릿과 URL 구조 이해
템플릿 시스템을 이해하는 가장 좋은 방법은 URL을 분석하는 것입니다. 예를 들어 다음과 같은 URL이 있다고 가정해 보겠습니다.
template_id=001
content_id=202411030001
category=politics
utm_source=google
utm_medium=search
utm_campaign=fall_promo
각 항목은 명확한 역할을 가집니다.
- template_id는 어떤 화면 템플릿을 사용할지 지정합니다.
- content_id는 어떤 데이터를 불러올지 결정합니다.
- category는 분류값입니다.
- utm_* 값은 마케팅 분석용 파라미터입니다.
여기서 중요한 점은, 템플릿과 데이터가 분리되어 있다는 사실입니다. content_id만 바꾸면 동일한 구조 안에서 다른 콘텐츠가 노출됩니다. 이것이 바로 템플릿화의 본질입니다.
예시 1 – 일반적인 기사 페이지 구조
기사 페이지는 구조가 항상 동일합니다. 상단 제목, 작성일, 본문, 하단 추천 기사. URL에서 시퀀스 번호만 바꾸면 다른 기사로 바뀝니다.
- ex: 48011 → 48012 → 48013
- UI 구조는 동일하고 데이터만 교체됩니다. 이것이 로직화된 템플릿입니다.
예시 2 – 네이버 블로그
네이버 블로그 URL은 다음과 같은 구조를 가집니다.
blog.naver.com/techknockknock/32451
- techknockknock은 블로그 ID
- 32451은 게시글 시퀀스 번호
네이버 블로그는 명시적 템플릿 ID가 보이지 않습니다. 하지만 블로그 ID에 따라 레이아웃 설정이 달라집니다. 즉, ID 자체가 템플릿 역할을 합니다. ID별로 레이아웃 설정이 다르고, 시퀀스 번호로 글 데이터를 호출합니다.
예시 3 – 브런치 구조
브런치 URL은 다음과 같습니다. brunch.co.kr/@exampleuser/164
- @exampleuser는 사용자 ID
- 164는 해당 사용자의 글 번호
브런치는 모든 콘텐츠가 동일한 템플릿을 사용합니다. 따라서 별도의 템플릿 ID가 없습니다. 사용자 ID와 시퀀스 번호를 통해 데이터를 불러와 동일한 구조에 끼워 넣습니다.
네이버 블로그 vs 브런치 – 구조적 차이
네이버 블로그
- 전체 글이 하나의 유니크 시퀀스를 가짐
- 검색과 정렬, 데이터 확장에 유리
- 플랫폼 단위 데이터 관리에 적합
브런치
- 사용자별 독립 시퀀스
- 구조가 단순
- 확장 시 복잡성 증가 가능
네이버는 검색 기반 플랫폼에 적합한 구조이고, 브런치는 사용자 중심 단순 플랫폼에 적합한 구조입니다.
기획자가 반드시 고민해야 할 것
템플릿 구조는 단순히 화면 설계 문제가 아닙니다.
- 전체 데이터가 유니크해야 하는가?
- 사용자별 독립 구조가 필요한가?
- 검색과 확장이 중요한가?
- 운영 효율이 중요한가?
이 질문에 따라 데이터 구조와 템플릿 설계 방식이 달라집니다.
정리
템플릿화 시스템은 다음 세 축으로 구성됩니다. Admin → Data → User
그 핵심은 다음과 같습니다.
- 템플릿은 구조다.
- 데이터는 콘텐츠다.
- URL은 데이터를 호출하는 열쇠다.
- 로직은 구조와 데이터를 연결하는 장치다.
하드코딩은 화면 중심 사고이고, 템플릿화는 데이터 중심 사고입니다.