백오피스에 콘텐츠를 올리기 전: UX 기획자를 위한 HTML 최소 지식

백오피스를 기획하다 보면 반드시 한 번은 이 질문을 마주칩니다. "이 필드에 어떤 형태의 텍스트를 받을 것인가?"

공지사항 제목처럼 한 줄 텍스트는 명확합니다. 그런데 본문이라면? 줄바꿈은? 이미지 삽입은? 링크는? 결정을 미루면 개발자가 임의로 정합니다. 나중에 운영팀이 "글씨가 굵어야 하는데 왜 안 되나요"라고 물어올 때, 또는 마케터가 "UTM 태그를 버튼에 달고 싶은데"라고 요청할 때 플래인 텍스트로 구현되어있다면 난감해질 수 있습니다.

 

입력 방식은 크게 세 가지입니다.

1. 플레인 텍스트(plain text): 서식이 없는 순수 문자열입니다. 저장·표시가 단순하고 XSS 위험이 없지만, 줄바꿈조차 개발자가 \n → <br> 변환 로직을 별도로 넣어야 합니다. 짧은 설명문, 알림 메시지처럼 서식이 필요 없는 필드에 적합합니다.

 

2. HTML 직접 입력(tagged text): <textarea>에 HTML을 직접 씁니다. 자유도가 높지만 입력자가 태그를 알아야 하고, 잘못된 태그가 화면을 깨뜨릴 수 있습니다. 개발자나 퍼블리셔가 직접 등록하는 랜딩페이지 본문 같은 경우에 주로 씁니다.

 

3. 위지위그 에디터(WYSIWYG, Rich Text Editor): 보이는 대로 편집하고, 내부적으로는 HTML을 생성합니다. 비개발자 운영자에게 가장 친숙하지만, 에디터가 만들어내는 HTML의 품질이 제각각입니다. Quill, TipTap, TinyMCE, Froala 등 라이브러리마다 출력 구조가 다르고, 허용 태그를 서버에서 화이트리스트로 제한하지 않으면 보안 구멍이 됩니다.

 

세 방식의 선택은 "누가 등록하는가", "어떤 서식이 필요한가", "보안 정책을 어떻게 가져갈 것인가"로 결정됩니다. 기획서에 이 세 가지를 명시해 두면 개발자가 임의로 판단할 여지가 줄어듭니다.

이 글은 어느 방식을 선택하든 기획자가 알아야 할 HTML 최소 지식을 운영·규제·마케팅 세 관점으로 정리합니다.

 

본론 1: 운영 측면 — 태그 구조·주석·작명

자주 쓰는 태그

실무에서 기획자가 알아야 할 태그는 많지 않으니 알아두는게 좋습니다.

 

1. 본문 태그

<p>내용</p>는 문단입니다. 문단 간격은 이 태그가 만들고, CSS가 조절합니다. 단순히 줄만 바꾸려면 <br>을 씁니다. 

 

2. 제목 테그

<h1>~<h6>는 제목 위계입니다. 시각적으로 크게 보이고 싶어서 <h1>을 쓰면 안 됩니다. 구조적으로 가장 중요한 제목 하나에만 <h1>을 쓰고, 하위 제목은 <h2>, <h3> 순으로 내려가야 합니다. SEO와 접근성 모두에 영향을 주는 태그입니다.

 

3. 링크 태그

<a href="주소" target="_blank" rel="noopener noreferrer">링크 텍스트</a>: 외부 링크를 새 탭에서 열 때 target="_blank"를 씁니다. 

 

4. 이미지 태그

<img src="주소" alt="설명">은 이미지입니다(alt는 다음 섹션에서 따로 다룹니다). 

 

5. 리스트 태그

<ul><li>항목</li></ul>은 순서 없는 목록, <ol>은 순서 있는 목록입니다.

 

6. 주석

<!-- 이 버전은 2025년 5월 이후 노출분 --> 형태의 주석은 브라우저 화면에 표시되지 않지만, 소스 보기로 누구나 볼 수 있습니다. 협업 메모 용도로는 유용하지만 내부 기준가, 정책 예외 사유, 개인정보는 절대 넣지 않습니다. 또한 에디터로 작성된 콘텐츠에 주석이 섞이면 나중에 데이터 마이그레이션 시 노이즈가 될 수 있으므로, 주석 사용 여부를 정책으로 정해두는 것이 좋습니다.

 

id·class 작명 규칙

이름을 잘못지으면 하위 속성 변경 시 의미가 불일치 하게되니 잘 짓는 것이 좋습니다. 물론 기획자가 이름을 직접 지을 일은 없지만

규칙을 명시하여 관리하는 것이 추후 UTM 유지 보수에 도움이 됩니다.

나쁜 예	이유	좋은 예
red-button	색이 바뀌면 이름을 변경해야함	btn-cancel
left-box	레이아웃이 바뀌면 무의미	sidebar-notice
box1, box2	역할을 알 수 없음	card-product-summary

케이스 방식은 팀 안에서 하나로 통일합니다. 가장 흔한 선택지는 kebab-case(단어 사이를 하이픈으로 연결)입니다. CSS와 HTML 속성 모두에서 자연스럽고, JavaScript의 camelCase와 구분도 됩니다. 중요한 것은 선택 자체보다 팀 전체가 같은 규칙을 쓰는 것이며, 이를 스타일 가이드 문서로 남겨두면 인수인계 시 혼란을 줄입니다.

본론 2: 규제 측면 — 접근성·특수문자·보안

alt 텍스트: 잘못된 사례와 올바른 사례

alt가 없는 이미지는 스크린리더가 파일명을 읽어버립니다. 20250501_banner_final_v3.jpg를 시각장애인 사용자에게 읽어주는 상황을 상상해보면 왜 필수인지 바로 이해됩니다. WCAG 2.1과 국내 KWCAG 2.1 모두 비텍스트 콘텐츠에 대체 텍스트를 요구합니다.

 

상황	잘못된 예	올바른 예
제품 이미지	alt="이미지"	alt="에어팟 프로 2세대, 노이즈캔슬링 이어버드"
CTA 버튼 이미지	alt=""	alt="지금 구매하기"
장식용 구분선	alt="선"	alt="" (빈 값이 정답)
아이콘	alt="아이콘"	alt="검색" 또는 alt="" + aria-label

장식용 이미지에 alt=""를 넣는 것은 오류가 아닙니다. 오히려 스크린리더가 해당 이미지를 건너뛰도록 하는 올바른 처리입니다. 빈 alt와 alt 속성 자체를 아예 빠뜨리는 것은 다릅니다. 속성이 없으면 파일명을 읽고, alt=""이면 조용히 넘어갑니다.

운영팀이 이미지를 직접 업로드하는 CMS라면 alt 입력 필드를 필수로 설정할지, 선택으로 둘지를 기획 단계에서 결정해야 합니다. 완전히 비워두면 미입력이 쌓이고, 필수로만 두면 운영자가 "이미지1"처럼 의미 없는 값을 채워 넣습니다. 현실적으로는 필수로 설정하되 가이드 문구("이미지에 담긴 핵심 정보를 한 문장으로 작성해주세요")를 placeholder로 제공하는 것이 효과적입니다.

 

특수문자와 XSS

HTML에서 <, >, &는 태그와 엔티티의 시작 문자입니다. 이 문자를 그대로 저장하면 렌더링할 때 태그로 해석되어 화면이 깨지거나, 악의적인 스크립트가 실행될 수 있습니다.

 

예를 들어 사용자가 이름 필드에 위 내용을 입력했는데 서버가 이스케이프 없이 그대로 출력하면, 해당 페이지를 여는 다른 관리자의 쿠키(세션 토큰 포함)가 외부로 전송됩니다. 이것이 저장형 XSS(Stored XSS)입니다.

 

이스케이프 처리는 개발자 몫이지만, 기획자가 알아야 하는 이유는 두 가지입니다. 첫째, "HTML 직접 입력을 허용하는 필드"를 기획할 때는 반드시 서버 측 화이트리스트 필터링이 필요하다고 명세에 적어야 합니다. 둘째, WYSIWYG 에디터를 도입할 때도 에디터 자체의 XSS 방어 수준을 확인해야 합니다. DOMPurify 같은 라이브러리로 클라이언트에서 1차 정제하고, 서버에서도 2차로 허용 태그를 제한하는 것이 일반적인 방어 전략입니다.

자주 쓰는 HTML 엔티티는 아래와 같습니다.

문자엔티티용도

<	&lt;	태그 오인 방지
>	&gt;	태그 오인 방지
&	&amp;	엔티티 오인 방지
"	&quot;	속성 값 내 따옴표
©	&copy;	저작권 기호

소스에 남기면 안 되는 정보

소스 코드 주석, 숨김 필드, data-* 속성은 화면에 보이지 않지만 브라우저 개발자 도구로 누구나 확인할 수 있습니다. 내부 관리자 이름, 미공개 가격, 테스트 계정 정보, 개인정보를 마크업에 남기는 사례가 실무에서 드물지 않습니다. 코드 리뷰나 배포 전 체크리스트에 "소스 내 민감정보 노출 여부 확인"을 명시적으로 포함해야 합니다.

 

본론 3: 마케팅 측면 — GA4·GTM·SEO·오픈그래프

GA4 이벤트 설계

UA(유니버설 애널리틱스)는 히트 타입(페이지뷰, 이벤트, 트랜잭션)으로 데이터를 분류했지만, GA4는 모든 데이터를 이벤트로 처리합니다. 기획자 관점에서 달라지는 실무는 이벤트 이름과 파라미터를 미리 설계하는 것이 유리하다는 점입니다.

 

javascript

gtag('event', 'signup_newsletter', {
  'method': 'footer_cta',
  'source_page': '/pricing'
});

이벤트명은 소문자 snake_case(signup_newsletter)를 권장합니다. GA4 보고서에서 정렬·필터가 대소문자를 구분하기 때문에 Signup_Newsletter와 signup_newsletter는 다른 이벤트로 집계됩니다. 파라미터 이름과 값도 마찬가지입니다. 이벤트 설계서를 스프레드시트로 만들어 이름, 트리거 조건, 파라미터를 정의해두지 않으면 추적 코드가 파편화됩니다.

 

SEO와 제목 위계

검색엔진은 <h1>~<h6> 태그를 문서 구조 파악에 사용합니다. 실무에서 가장 흔한 실수 두 가지가 있습니다. 첫째, 페이지 안에 <h1>이 여러 개 있는 경우입니다. <h1>은 페이지당 하나가 원칙입니다(HTML5 사양상 복수도 유효하지만 SEO 관점에서는 하나 권장). 둘째, 시각적으로 크게 보이고 싶어서 <h2> 다음 바로 <h4>로 건너뛰는 경우입니다. 접근성 지침은 제목 위계를 순서대로 사용하도록 요구합니다.

시맨틱 태그도 SEO 자산입니다. <article>, <section>, <nav>, <main>, <aside>, <header>, <footer>는 검색엔진과 스크린리더 모두에게 콘텐츠 구조를 명확히 알립니다. 모든 것을 <div>로 처리하는 것보다 시맨틱 태그를 쓰는 것이 동일한 시각 결과에 더 많은 의미를 담습니다.

 

오픈그래프와 SNS 공유

카카오톡, 슬랙, 트위터 등 SNS에서 URL을 공유하면 썸네일 이미지와 제목·설명이 자동으로 붙습니다. 이것이 오픈그래프(OG) 태그입니다.

 

html

<meta property="og:title" content="백오피스 HTML 기초 가이드">
<meta property="og:description" content="UX 기획자가 알아야 할 최소 HTML 지식">
<meta property="og:image" content="https://example.com/og-thumbnail.png">
<meta property="og:url" content="https://example.com/articles/html-basics">

OG 이미지는 1200×630px가 표준입니다. 이미지가 없거나 비율이 맞지 않으면 플랫폼마다 다르게 잘리거나 기본 이미지로 대체됩니다. 콘텐츠 유형별로 OG 이미지 템플릿을 만들어 두는 것이 실무 효율이 높습니다. 백오피스에서 콘텐츠를 등록할 때 OG 이미지를 별도로 업로드하게 할지, 본문 첫 번째 이미지를 자동 사용할지를 기획 단계에서 결정해야 합니다.

---

마무리: 기획서에 남겨야 할 체크리스트

기획 단계에서 이 질문들에 답을 남겨두면 개발·운영 모두 불필요한 왕복 소통이 줄어듭니다.

입력 필드 설계 시

• 이 필드는 플레인 텍스트 / HTML 직접 입력 / WYSIWYG 에디터 중 무엇을 사용하는가?

이미지 업로드 설계 시

• alt 텍스트 입력 필드가 있는가? 필수 또는 선택인가?
• OG 이미지는 어떻게 지정하는가?

---

참고 자료

• Google Analytics, "Set up events"(GA4): https://developers.google.com/analytics/devguides/collection/ga4/events
• MDN Web Docs — 이미지 대체 텍스트, HTML 엔티티, data-* 속성, 오픈그래프
• OWASP, "Cross Site Scripting Prevention Cheat Sheet": https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• 한국형 웹 콘텐츠 접근성 지침(KWCAG) / WCAG 2.1 대체 텍스트 지침
• The Open Graph Protocol: https://ogp.me