웹 퍼블리셔와 프론트엔드 개발자 차이: 산출물이 갈리는 지점

견적서에 이런 두 줄이 나란히 놓이는 경우가 있습니다.

퍼블리싱          10일
프론트엔드 개발    15일

그런데 같은 견적서의 산출물 목록에는 HTML 파일이 없습니다. 리포지터리 하나와 컴포넌트 디렉터리가 있을 뿐입니다. 두 줄로 나뉜 일이 실제로는 한 사람이 같은 파일을 두 번 여는 일이라면, 저 10일과 15일은 무엇을 세고 있는 걸까요.

마크업을 넘기면 기능을 붙인다는 오해

두 직무를 가르는 가장 흔한 설명은 이렇습니다. 퍼블리셔가 디자인 시안을 받아 HTML과 CSS로 화면을 만들어 넘기고, 프론트엔드 개발자가 그 마크업에 자바스크립트로 동작을 붙인다. 언어로 갈리고, 순서로 갈리고, 파일로 갈립니다. 깔끔하고 견적서에 옮겨 적기도 좋습니다.

이 설명은 틀린 것이 아니라 조건부입니다. 성립하려면 넘길 물건이 실제로 존재해야 합니다. 완성된 .html 과 .css 파일이 한 벌 나오고, 그것을 다른 사람이 받아 다음 작업을 하는 구조여야 합니다. jQuery로 동작을 붙이던 시절에는 그 전제가 늘 참이었습니다.

요즘 프로젝트에서는 그 전제가 자주 깨집니다.

컴포넌트가 없앤 것은 직무가 아니라 인수인계 지점

React나 Vue로 화면을 만들면 마크업이 독립된 파일로 존재하지 않습니다. <button> 한 줄과 그 버튼이 눌렸을 때 무엇이 바뀌는지가 같은 파일 안에, 대개는 서른 줄 안쪽 거리에 있습니다. React 공식 문서는 이것을 사고가 아니라 의도된 설계로 설명합니다. 렌더링 로직과 마크업이 서로를 바꾸기 때문에 같은 자리에 두었다는 것입니다.

그래서 사라진 것은 직무가 아니라 인수인계 지점입니다. 「퍼블리싱 완료」라고 부를 수 있는 순간이 없어졌습니다. 마크업을 90% 만들어 놓고 멈출 수는 있지만, 그 상태의 파일은 다른 사람에게 건네지는 물건이 아니라 그냥 작업 중인 코드입니다.

이 구분이 중요한 이유는, 두 직무가 합쳐졌다는 결론으로 곧장 건너뛰는 사람이 많기 때문입니다. 합쳐진 것은 일의 흐름이지 능력이 아닙니다. 시맨틱 마크업을 짤 줄 아는 것과 상태 관리를 설계할 줄 아는 것은 여전히 다른 기술이고, 한 사람이 둘 다 잘하는 경우는 생각만큼 흔하지 않습니다.

아직 정적 산출물이 실재하는 자리

컴포넌트 이야기를 모든 프로젝트에 적용하면 그것도 똑같이 틀립니다. 넘길 파일이 실제로 나오는 구조는 지금도 많습니다.

만드는 것	정적 산출물이 나오나	경계가 생기는 곳
워드프레스·그누보드 테마	나옵니다	템플릿 파일과 스타일시트
서버 템플릿 기반 SI (JSP, Thymeleaf 등)	나옵니다	퍼블리싱 결과를 템플릿으로 이식하는 단계가 별도
이메일 HTML	나옵니다	완전히 분리된 작업
React·Vue 기반 웹앱	나오지 않습니다	컴포넌트 레이어

위 세 줄에서는 앞서 말한 분업 설명이 그대로 유효합니다. 특히 서버 템플릿 기반 SI에는 퍼블리싱 산출물을 받아 템플릿 문법으로 옮기는 이식 공정이 따로 있고, 이 공정을 견적에서 빼먹으면 일정이 반드시 밀립니다. 마지막 줄에서만 전제가 무너집니다.

발주하는 쪽에서 판단할 지점은 여기입니다. 「퍼블리싱을 따로 뽑을 수 있는가」는 취향이 아니라 어떤 기술로 만드느냐에 따라 이미 정해져 있는 문제입니다.

진짜 경계선, 상태를 누가 쥐는가

언어로 나누는 축이 흔들린다면 무엇이 남을까요. 저는 실무에서 유일하게 안 흔들리는 축이 상태라고 봅니다.

아코디언을 예로 들면 명확합니다. 접힌 모양과 펼친 모양을 만드는 것은 스타일 문제입니다. 그런데 지금 열려 있는지 닫혀 있는지, 하나만 열리는지 여럿이 열리는지, 새로고침 후에도 그 상태가 남아야 하는지는 스타일 문제가 아닙니다. 같은 컴포넌트 안에 있고 화면상으로도 구분되지 않지만, 설계가 필요한 쪽은 뒤쪽입니다.

CSS만으로 상당 부분이 되는 경우도 있습니다. :hover, :focus-visible, details 요소, 최근에는 popover 속성까지 오면서 자바스크립트 없이 처리되는 상호작용이 늘었습니다. 그래서 이 경계도 고정된 선은 아닙니다. 다만 선이 어디 있든, 선의 이름은 파일 확장자가 아니라 상태입니다.

주인이 사라진 몫, 시맨틱과 접근성

분업이 무너지면서 조용히 주인을 잃은 영역이 있습니다.

<div onClick={...}> 으로 만든 버튼은 화면에서 버튼처럼 보이고 마우스로 눌리지만 키보드로는 도달하지 않습니다. 스크린 리더는 그것을 버튼이라고 읽지 않습니다. 커스텀 컴포넌트를 만들 때 역할, 키보드 상호작용, 포커스 이동을 직접 구현해야 한다는 것은 WAI-ARIA Authoring Practices Guide가 패턴별로 길게 설명하는 내용이고, MDN의 시맨틱 요소 문서가 먼저 권하는 것은 그냥 <button>을 쓰라는 쪽입니다.

예전에는 이 몫에 이름이 붙어 있었습니다. 퍼블리셔의 일이었고, 잘하는 퍼블리셔와 못하는 퍼블리셔가 여기서 갈렸습니다. 컴포넌트로 옮겨온 뒤에는 어느 칸에도 적혀 있지 않습니다. 견적서에도, 산출물 정의서에도, 검수 항목에도 없습니다. 없으면 안 하게 됩니다.

견적을 두 줄로 나눌 때 생기는 중복

처음의 견적서로 돌아가 보겠습니다. 컴포넌트 기반 프로젝트에서 퍼블리싱과 프론트엔드 개발을 두 줄로 나누면 두 가지 중 하나가 일어납니다.

한 사람이 두 줄을 다 하면서 이름만 나뉘어 있거나, 정말 두 사람이 붙어서 한 사람이 만든 마크업을 다른 사람이 컴포넌트로 다시 쪼갭니다. 앞쪽은 견적서가 사실과 다를 뿐 손해는 없습니다. 뒤쪽은 같은 화면을 두 번 만드는 일이고, 재작업이 어디서 발생하는지 아무도 기록하지 않기 때문에 다음 프로젝트에서도 똑같이 반복됩니다.

저라면 이런 프로젝트에서 줄을 나누지 않겠습니다. 「화면 구현」 한 줄로 잡고, 대신 지금까지 퍼블리싱이라는 이름이 암묵적으로 보장하던 것들을 산출물 정의에 명시적으로 적겠습니다. 반응형 기준 해상도, 시맨틱 마크업, 키보드 접근성, 브라우저 지원 범위. 이름이 사라진 몫을 되살리는 방법은 그 이름을 다시 만드는 것이 아니라 항목으로 적는 것입니다.

디자인 시스템이 경계를 다시 만드는 방식

인력이 둘 이상이면 경계 자체는 다시 필요합니다. 요즘 그 자리를 대신하는 것이 디자인 시스템입니다.

색과 간격을 토큰으로 정의하는 층, 버튼과 입력 같은 기본 컴포넌트를 만드는 층, 그것을 조립해 화면을 만드는 층으로 나누면 앞의 두 층이 예전 퍼블리싱과 상당히 겹칩니다. 시맨틱과 접근성도 기본 컴포넌트 층에 한 번만 넣으면 위층 전체가 따라옵니다. 다른 점은 경계가 파일 종류가 아니라 의존 방향으로 그어진다는 것입니다. 아래층은 위층을 모르고, 위층은 아래층을 가져다 씁니다.

이 구조가 의미 있으려면 사람이 둘 이상이어야 합니다. 한 명이 전부 만드는 프로젝트에서 층을 나누면 그것은 분업이 아니라 그냥 작업 순서입니다.

여기서부터는 회사마다 갈립니다

「퍼블리셔」라는 말이 실제로 가리키는 업무 범위는 회사마다 다릅니다. 자바스크립트를 아예 안 만지는 곳도 있고, 화면 로직까지 다 하면서 직함만 퍼블리셔인 곳도 있습니다. 채용 공고 하나를 두고 이 글의 구분을 그대로 적용하면 틀립니다. 공고에 적힌 기술 스택을 보고 위 표의 어느 줄인지부터 확인하는 편이 빠릅니다.

확실한 것은 셋입니다. 분업이 가능한지는 만드는 방식이 이미 정해 놓았다는 것, 언어가 아니라 상태가 경계라는 것, 그리고 이름이 사라진 몫은 항목으로 적지 않으면 아무도 하지 않는다는 것입니다.