[프론트엔드] 코딩만 잘하는 프론트엔드? 나는 웹 퍼블리셔인가?

 < 서론 > 

• 코딩만 잘하는 개발자도 물론 팀과 회사에 도움이 된다.
• 하지만 프로젝트의 규모가 커지는 경우 코딩만 잘 해서는 안된다고 생각했다.
• 특히나 지금 내가 하는 일이 웹퍼블리셔와 다를게 없다고 생각했다.
• 그래서 현재의 고민에 대한 해답과 프론트엔드 개발자로서 나가야할 올바른 방향이자 프론트엔드로서 전문성을 가질 방법에 대해 생각해본 결론을 여기에 쓰려고한다.

 < 목차 > 

1. 웹 퍼블리셔란?
2. 프론트엔드 vs 웹 퍼블리셔
3. 앞으로 개발해야 할 부분
4. 왜 이 기술을 쓰셨나요?
5. 결론

---

 1. 웹 퍼블리셔란? 

• 프론트엔드 개발자가 되기 위해서는 HTML, CSS, JavaScript에 대해서 공부하고 잘 다뤄야 한다는 것은 모두가 다 아는 당연한 사실이다.
• 하지만 이들을 다룰 수 있는 직업이 또 있었으니 바로 웹 퍼블리셔다.
• 웹 퍼블리셔는 영어로 "web publisher"라고 하며 뜻은 a person that uploads, creates, or edits content on web pages
  • 웹페이지에 콘텐츠를 업로드, 생성 또는 편집하는 사람
  • 즉, HTML, CSS, JavaScript로 디자인 시안을 웹 표준에 맞게 구현하는 사람을 말한다.
• 이런 일들은 프론트엔드 개발자도 한다는 점이 나의 개발자 정체성?에 혼란을 줬다.

---

 2. 프론트엔드 VS 웹 퍼블리셔 

• 프론트엔드와 웹 퍼블리셔간의 차이를 살펴보자.

항목	프론트엔드 개발자	웹 퍼블리셔
공통점	- HTML, CSS, JavaScript를 사용하여 웹 페이지를 구현 - UI/UX 디자이너와 협업하여 디자인을 구현	- HTML, CSS, JavaScript를 사용하여 웹 페이지를 구현 - UI/UX 디자이너와 협업하여 디자인을 구현
주요 역할	- 웹 애플리케이션의 클라이언트 사이드 기능 개발 - 동적인 인터랙션과 복잡한 로직 구현	- 디자인 시안을 웹 표준에 맞게 마크업 - 정적 페이지의 구조와 스타일링 구현
사용 기술	- HTML, CSS, JavaScript - 프레임워크(React, Vue, Angular 등) - 빌드 도구(Webpack 등)	- HTML, CSS - JavaScript(jQuery 등 간단한 스크립트) - 크로스 브라우징 기술
주요 업무	- API 연동 및 데이터 처리 - 성능 최적화 및 반응형 웹 개발 - 테스트 및 디버깅	- 웹 표준 및 접근성을 고려한 마크업 - 반응형 웹 구현 - 브라우저 호환성 유지
전문성 집중 분야	- 복잡한 기능 구현 및 클라이언트 로직 처리 - 최신 웹 기술 및 프레임워크 숙련도 - 문제 해결 능력	- HTML/CSS 마크업 전문성 - 웹 표준 및 접근성에 대한 깊은 이해 - 디자인 해석 및 구현 능력
협업 대상	- 백엔드 개발자 - UI/UX 디자이너 - QA 엔지니어	- UI/UX 디자이너 - 프론트엔드 개발자
차이점	- 동적인 웹 애플리케이션 개발에 초점을 맞춤 - 복잡한 JavaScript 로직과 프레임워크 사용	- 정적 웹 페이지의 마크업과 스타일링에 집중 - 주로 HTML과 CSS에 전문성 보유
목표	- 사용자에게 기능적이고 인터랙티브한 웹 경험 제공 - 웹 애플리케이션의 성능 및 효율성 향상	- 디자인 의도를 정확하게 반영한 웹 페이지 구현 - 모든 사용자에게 일관된 접근성 제공

• 표를 요약하면
  • 둘 다 HTML, CSS, JavaScript를 사용하여 웹 페이지를 구현하고, UI/UX 디자이너와 협업한다는 공통점이 존재한다.
  • 하지만 프론트엔드 개발자는 동적인 기능과 복잡한 로직 구현에 집중하며, 최신 프레임워크와 기술을 활용한다. 웹 퍼블리셔는 디자인 시안을 정확하게 마크업하고, 웹 표준과 접근성을 준수하는 데 집중한다.
  • 또한 프론트엔드 개발자는 프로그래밍 능력과 최신 기술 습득에 중점을 두고, 웹 퍼블리셔는 마크업 언어의 숙련도와 웹 표준에 대한 이해에 집중한다는 점에서 다르다고 볼 수 있다.
• 확실히 나는 백엔드와 프론트엔드 간에 API를 연결하기도 하고 최신 Next.js에 대해서 공부하기도 한다는 점에서 프론트엔드 개발자가 맞다.

---

 3. 앞으로 개발해야 할 부분 

• 우리(프론트엔드 개발자)는 그럼 어떤 부분을 개발 해야 할까?
• 이에 해당하는 부분이 밑에 존재한다.

1. 사용자에게 기능적이고 인터랙티브한 웹 경험 제공
   • 동적인 버튼 및 인터랙션 구현
     • 버튼을 클릭하면 내용이 동적으로 변경되거나 모달 창이 나타나는 기능을 구현한다. 예를 들어, 쇼핑몰에서 '장바구니에 추가' 버튼을 클릭하면 장바구니 아이콘에 상품 수량이 업데이트되고 애니메이션 효과가 나타난다.
   • 실시간 데이터 처리
     • 채팅 애플리케이션에서 메시지를 실시간으로 주고받을 수 있도록 웹 소켓(WebSocket) 기술을 활용하여 사용자 간의 즉각적인 소통이 가능하게 한다.
   • 드래그 앤 드롭(Drag and Drop)
     • 사용자가 리스트 아이템을 마우스로 드래그하여 순서를 변경하거나 파일을 업로드 영역으로 끌어다 놓으면 업로드가 시작되는 기능을 구현한다.
   • 애니메이션 및 트랜지션 효과
     • 페이지 스크롤 시 요소들이 부드럽게 나타나거나 사라지는 효과를 주어 사용자 경험을 향상시킨다.
   • 싱글 페이지 애플리케이션(SPA) 구현
     • React, Vue.js와 같은 프레임워크를 사용하여 페이지 전환 시 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트하여 부드럽고 빠른 사용자 경험을 제공한다.
2. 웹 애플리케이션의 성능 및 효율성 향상
   • 코드 스플리팅(Code Splitting)
     • 웹팩(Webpack) 등의 빌드 도구를 사용하여 필요할 때만 코드를 로드하도록 하여 초기 로딩 시간을 단축시킨다.
       • 코드 스플리팅은 프론트엔드 개발자가 웹 애플리케이션의 성능을 최적화하는 핵심 기술 중 하나입니다.
       • 사용자에게 필요한 시점에 필요한 코드만 로드하여 효율적인 웹 경험을 제공합니다.
       • Webpack, React.lazy, dynamic import 등 다양한 방법으로 구현할 수 있습니다.
   • 이미지 및 리소스 최적화
     • 이미지의 크기를 압축하고, 불필요한 리소스를 제거하여 페이지 로딩 속도를 향상시킨다.
   • 캐싱(Caching) 및 지연 로딩(Lazy Loading)
     • 자주 변경되지 않는 데이터나 리소스를 캐시에 저장하여 재사용하고, 사용자가 필요로 할 때만 데이터를 로드하여 네트워크 요청을 최소화한다.
   • 반응형 및 적응형 디자인 최적화
     • 다양한 기기에서 최적의 성능을 발휘할 수 있도록 미디어 쿼리와 유연한 레이아웃을 사용하여 페이지를 구성한다.
   • 성능 모니터링 및 튜닝
     • 브라우저의 개발자 도구나 Lighthouse와 같은 성능 측정 도구를 활용하여 애플리케이션의 성능 병목 지점을 파악하고 최적화다.

---

 4. 왜 이 기술을 쓰셨나요? 

• 여러 회사에서 면접을 보면 단골 질문 중 하나이다.
• 나는 이 질문을 면접을 준비할 때나 생각해봤지 개발하는 동안은 생각해보지 못했던 것 같다.
• 하지만 앞으로는 왜 이 기술을 썼는지 고민해 봐야 한다.
• 왜냐하면 이런 부분이 결국 프로와 아마추어의 차이를 만들기 때문이다.
• 즉, 전문성을 보여주는 부분이라고 생각한다.
• 그렇다면 어떤 것들이 있을까? 하나씩 살펴보자.

프론트엔드 기술의 역사와 각 기술이 등장한 이유, 그리고 장단점

기술	등장 연도	등장 배경 및 이유	장점	단점
HTML	1991년	- 웹 페이지의 구조를 정의하기 위해 등장 - 문서의 구조와 콘텐츠를 마크업하기 위한 언어 필요성	- 간단하고 이해하기 쉬움 - 웹의 표준 언어	- 스타일링 및 동적 기능 부족
CSS	1996년	- HTML의 스타일링 한계를 극복하고, 문서의 표현을 분리하기 위해 등장	- 디자인과 레이아웃 제어 가능 - HTML과의 분리로 유지보수성 향상	- 복잡한 레이아웃 구현 시 어려움 - 브라우저 간 호환성 이슈
JavaScript	1995년	- 클라이언트 사이드에서 동적인 기능을 제공하기 위해 등장	- 웹 페이지에 동적인 기능 추가 가능 - 광범위한 활용성	- 초기에는 언어의 한계로 인해 복잡한 애플리케이션 구현이 어려웠음
jQuery	2006년	- 복잡한 JavaScript 코드의 간소화 및 DOM 조작의 편의성 향상을 위해 등장	- 간단한 문법으로 DOM 조작 가능 - 브라우저 호환성 이슈 해결	- 파일 크기가 크고, 최신 프레임워크 대비 성능 저하 - SPA 구현에 한계
AngularJS	2010년	- 대규모 애플리케이션 개발을 위한 구조화된 프레임워크 필요성 대두	- 양방향 데이터 바인딩 - 의존성 주입 등 엔터프라이즈 수준 기능 제공	- 복잡하고 학습 곡선이 높음 - 성능 이슈
TypeScript	2012년	- 대규모 애플리케이션 개발을 위한 JavaScript의 한계를 극복하고자 Microsoft에서 개발 정적 타입 시스템 도입	- 정적 타입으로 코드 품질 향상 - IDE 지원 강화로 개발 생산성 향상 - 최신 ECMAScript 기능 선도적 도입	- 컴파일 단계 필요 - 학습 곡선이 있을 수 있음 - 타입 정의로 인한 초기 설정 부담
React	2013년	- UI의 복잡성을 효율적으로 관리하기 위해 Facebook에서 개발 - 단방향 데이터 흐름과 가상 DOM 도입	- 가상 DOM으로 성능 향상 - 재사용 가능한 컴포넌트 - 커뮤니티와 에코시스템 활발	- JSX 학습 필요 - 상태 관리 등 추가 라이브러리 필요
Vue.js	2014년	- Angular와 React의 장점을 결합하여 더 가벼운 프레임워크 제공	- 가볍고 빠름 - 반응성 시스템으로 데이터 변경 감지 - 학습이 비교적 쉬움	- 대규모 커뮤니티 부족(React 대비) - 플러그인 및 확장성 제한
Angular	2016년	- AngularJS의 한계를 극복하고 모던 웹 표준에 맞게 재작성 - TypeScript 채택	- 모듈 시스템 - TypeScript 사용으로 코드 안정성 향상 - 강력한 도구와 기능 제공	- 복잡한 구조 - 학습 곡선 높음 - 무거운 파일 크기
Next.js	2016년	- React 기반의 서버 사이드 렌더링(SSR) 및 정적 사이트 생성(SSG)을 쉽게 구현하기 위해 등장	- SEO 향상 - 코드 스플리팅 자동화 - 개발자 경험 향상	- React에 의존적 - 구성 복잡성 증가 가능성
Svelte	2016	- 런타임 없는 컴파일러로, 더욱 가벼운 애플리케이션을 만들기 위해 등장	- 작은 번들 크기 - 빠른 성능 - 간결한 코드	- 상대적으로 작은 커뮤니티 - 생태계 미성숙

프론트엔드 상태 관리 도구들의 등장 배경과 장단점

기술	등장 연도	등장 배경 및 이유	장점	단점
React Component State	2013년 (React 출시)	- React의 기본 상태 관리 방식으로, 컴포넌트 내부에서 상태를 관리하고 필요 시 상위 또는 하위 컴포넌트로 전달하기 위해 사용됨	- 간단하고 React에 내장되어 있음 - 작은 규모의 애플리케이션에 적합 - 별도의 라이브러리 없이 사용 가능	- 복잡한 상태 공유가 어려움 - 깊은 컴포넌트 트리에서 prop drilling 발생 - 전역 상태 관리에 비효율적
Flux Architecture	2014년	- Facebook에서 대규모 애플리케이션의 복잡한 상태 관리를 위해 개발한 아키텍처 패턴 - 단방향 데이터 흐름을 통해 상태 변화를 예측 가능하게 함	- 단방향 데이터 흐름으로 상태 관리 용이 - 예측 가능한 상태 변화 - 디버깅이 용이	- 구현이 복잡하고 보일러플레이트 많음 - 공식 구현체가 없어서 여러 버전 존재 - 학습 곡선이 높음
React Context API (구버전)	2015년 (실험적 도입)	- 컴포넌트 트리를 통해 전역적인 데이터 전달을 위해 등장하였으나, 실험적 기능으로 권장되지 않았음	- 컴포넌트 트리를 통해 데이터 전달 가능 - prop drilling 방지	- 불안정하고 문서화 부족 - 성능 이슈 발생 가능 - 사용이 복잡하고 제한적
Redux	2015년	- Flux의 복잡성을 줄이고 단일 상태 저장소와 순수 함수인 Reducer를 통해 예측 가능한 상태 관리를 제공하기 위해 등장	- 단일한 상태 관리로 예측 가능성 향상 - 시간 여행 디버깅 가능 - 미들웨어를 통한 확장성 - 큰 커뮤니티와 풍부한 에코시스템	- 보일러플레이트 코드가 많음 - 학습 곡선이 높음 - 작은 애플리케이션에선 과도한 사용
MobX	2015년	- 상태 관리를 더 단순화하고 반응형 프로그래밍을 도입하여 코드의 간결성과 생산성 향상을 위해 개발	- 간단한 문법과 적은 보일러플레이트 - 자동으로 상태 변경 추적 - 객체 지향 프로그래밍에 익숙한 개발자에게 적합 - 성능이 우수함	- 상태 추적이 자동으로 이루어져 디버깅이 어려울 수 있음 - Redux 대비 작은 커뮤니티 - 여러 출처의 상태로 인해 예측 가능성이 떨어질 수 있음
React Context API (신버전)	2018년 (React 16.3)	- 전역 상태 관리를 위한 안정적이고 공식적인 API로 재도입 - 프로바이더와 컨슈머 패턴을 통해 컴포넌트 간 상태 공유 용이	- 외부 라이브러리 없이 전역 상태 관리 가능 - 간단한 전역 상태 관리에 적합 - prop drilling 문제 해결	- 잦은 상태 업데이트 시 성능 이슈 - 복잡한 상태 관리에는 부적합 - 최적화가 어려울 수 있음
React Hooks	2019년 (React 16.8)	- 함수형 컴포넌트에서 상태와 생명주기 관리가 필요하다는 요구에 따라 도입 - useState, useEffect 등 훅을 통해 상태 관리 및 사이드 이펙트 처리 가능	- 클래스 없이도 상태 관리 가능 - 코드 재사용성과 가독성 향상 - 복잡한 로직을 간결하게 표현	- 훅의 사용 규칙을 지켜야 함 - 복잡한 상태 관리 시 여러 훅을 조합해야 함 - 디버깅이 어려울 수 있음
Zustand	2019년	- 가벼우면서도 유연한 상태 관리 도구를 제공하기 위해 개발 - React의 컨텍스트 API와 훅을 활용	- 매우 가벼움(~1KB) - 간단하고 직관적인 API - 보일러플레이트나 프로바이더 불필요 - TypeScript 지원 우수	- 비교적 작은 커뮤니티 - Redux에 비해 미들웨어 부족 - 대형 애플리케이션에선 기능이 부족할 수 있음
React Query	2019년	- 서버 상태 관리와 데이터 페칭을 간소화하기 위해 개발 - 비동기 작업과 캐싱 관리의 복잡성을 해결	- 데이터 페칭과 캐싱 최적화 - 자동으로 데이터 동기화 및 리패칭 - 적은 보일러플레이트 - 복잡한 비동기 작업 관리에 효과적	- 클라이언트 상태 관리에는 적합하지 않음 - 추가적인 의존성 필요 - 다른 상태 관리 도구와 책임 범위가 겹칠 수 있음
Recoil	2020년	- React 애플리케이션에서 더 나은 상태 관리를 위해 Facebook에서 개발 - Hooks와 함께 사용하여 전역 상태와 파생 상태를 효율적으로 관리	- React와의 긴밀한 통합 - 최소한의 보일러플레이트 - 비동기 상태와 파생 상태 관리 용이 - 간단하고 직관적인 API	- 아직 실험적 단계 - 비교적 작은 커뮤니티 - 프로덕션에서의 안정성 우려

모바일 기술의 역사와 각 기술이 등장한 이유, 그리고 장단점

기술	등장 연도	등장 배경 및 이유	장점	단점
모바일 웹 (Mobile Web)	1990 ~ 2000년대	- 모바일 기기에서 웹 콘텐츠에 접근하기 위해 등장 - 초기에는 제한된 기능과 속도로 인해 제한적으로 사용됨	- 별도 앱 설치 불필요 플랫폼 독립적 - 즉각적인 업데이트 가능	- 제한된 성능과 기능 - 오프라인 접근 불가 - 브라우저 호환성 이슈
네이티브 앱 개발	iOS: 2008년 Android: 2008년	- 모바일 기기의 성능과 기능을 최대한 활용하기 위해 각 플랫폼의 고유 언어로 앱 개발 시작	- 높은 성능 - 기기 기능에 대한 완전한 접근 - 최적화된 사용자 경험 제공	- 플랫폼별로 별도 개발 필요 - 개발 비용과 시간 증가 - 언어와 도구의 학습 곡선
Apache Cordova (PhoneGap)	2009년	- 웹 기술로 모바일 앱을 개발하고 여러 플랫폼에 배포하기 위해 등장	- HTML, CSS, JavaScript 등 웹 기술 사용 가능 다중 플랫폼 지원	- 성능 이슈 - 제한된 네이티브 기능 접근 - 디버깅 및 유지보수 어려움
반응형 웹 디자인 (RWD)	2010년	- 다양한 화면 크기와 해상도를 가진 기기가 등장함에 따라, 하나의 웹사이트로 여러 기기를 지원하기 위해 도입	- 하나의 코드베이스로 다양한 기기 지원 - 유지보수 용이	- 복잡한 디자인 구현 어려움 - 느린 로딩 속도 - 낮은 성능
Kotlin	2011년 (2017년 Android 공식 지원)	- Java의 한계를 극복하고 현대적인 언어 기능 제공을 위해 JetBrains에서 개발 - Android의 공식 언어로 채택	- 간결하고 안전한 문법 Null 안전성 - Java와의 완벽한 상호 운용성 - 코드 가독성 향상	- 학습 곡선 존재 - 일부 라이브러리와 도구의 지원 미흡 - 컴파일 속도 느림
Swift	2014년	- Objective-C의 복잡성과 안전성 문제를 해결하기 위해 Apple에서 개발 - 모던한 문법과 성능 개선	- 간결하고 안전한 문법 빠른 성능 - 오픈 소스화로 커뮤니티 성장	- 새로운 언어로 학습 필요 - 초기 버전 호환성 문제 - Objective-C와의 상호 운용성 제한
Progressive Web Apps (PWA)	2015년	- 웹 앱에 네이티브 앱과 유사한 경험 제공을 위해 등장 - 오프라인 지원, 푸시 알림 등 가능	- 오프라인 지원 - 자동 업데이트 - URL로 접근 가능	- 브라우저 지원 제한 - 기기 기능 접근 제한 - 앱스토어에서 검색되지 않음
React Native	2015년	- React로 네이티브 모바일 앱을 개발하기 위해 Facebook에서 개발 - JavaScript로 네이티브 컴포넌트를 렌더링	- 한 번의 개발로 iOS, Android 지원 - 네이티브 성능 - 활발한 커뮤니티와 에코시스템	- 복잡한 UI 구현 시 한계 - 네이티브 모듈 필요 시 복잡성 증가 - 패키지 호환성 문제 발생 가능
Flutter	2017년	- 고성능 크로스 플랫폼 앱 개발을 위해 Google에서 개발 - 자체 렌더링 엔진과 Dart 언어 사용	- 높은 성능 - 일관된 UI/UX - 한 번의 개발로 여러 플랫폼 지원 - Hot Reload로 빠른 개발 사이클	- Dart 언어 학습 필요 - 패키지 생태계 미성숙 - 앱 크기 증가

• 이와같이 기술이 왜 개발되었고 장단점이 무엇인지 알고 개발에 임해야 한다.
• 또 백엔드 개발자는 자바의 버전에 대해서 민감하게 고민하고 개발에 임하는데 프론트엔드 개발자는 그러지 않는 것 같은 개인적인 생각이다.
• 이를 방지하고 전문성을 보유하고자 다음과 같은 질문들을 생각해봤다.

프론트엔드 전문성을 검증하는 질문 모음

1. React의 버전을 왜 최신 버전을 사용했는가?
2. 이전 버전과의 차이는 무엇인가?
   • 어떤 부분이 추가되고 제거되었는가?
3. 왜 React대신 Next.js를 사용했는가?
4. Redux/Toolkit을 왜 사용했는가?
5. 빌드 도구에는 npm, yarn, pnpm, bun, berry 이 존재하는데 왜 npm을 사용했는가?
6. 프론트엔드 개발 당시 설계는 어떻게 했는가?
7. 디자인 패턴을 사용했는가?
8. 프론트개발 당시 발생한 에러에 대해서 정리하고 있는가?
9. 확장성, 유지보수, 가독성, 의존성, 재사용성에 대해 알고 있는가?
   • 또는 이를 고민하고 개발했는가?
   • 어떻게 개발했는지 구체적으로 설명해보시오.
10. JavaScript와 TypeScript에 대한 차이와 왜 TypeScript를 사용했는가?
11. 비동기와 동기에 대한 차이를 promise와 async/await와 같이 설명하시오.
12. HTTP와 HTTPS에 차이는 무엇인가?
13. 쿠키, 로컬 스토리지, 세션 스토리지의 차이는 무엇인가?
14. 현재 기술 동향은 어떠하고 어떤 기술에 대해 관심이 있는가?
15. 클라우드 컴퓨팅에 대해 자세히 알고 있는가?
    • SaaS, IaaS, PaaS, DaaS
16. CI/CD에 대해 알고 있는가?
    • 젠킨스, 엔진엑스 등
17. 도커, 쿠버네티스의 차이는 무엇인가?

---

 5. 결론 

• 결과적으로 프론트엔드와 웹 퍼블리셔는 HTML, CSS, JavaScript를 가지고 웹을 개발한다는 공통점이 있다.
• 하지만 프론트엔드의 주된 목표는 사용자의 경험(UX)에 초점을 둬야 한다.
• 그러기 위해서는 JavaScript를 능숙하게 다뤄야 하고 인터렉티브한 웹을 만들고 성능을 최적화 하려고 노력해야 한다.
• 또한, 최신 기술에 대해 잘 알아야 하는데 그 이유는 최신 기술의 궁극적 목표가 성능을 향상시켜 사용자에게 최상의 경험을 제공하기 위함이기 때문이다.
• 최신 기술과 이전 기술을 비교해서 알고 있으면 좋다.
• 그리고 이 게시글에 나온 무수한 전문 용어에 대해서 자세하게 다뤄볼 예정이다.
• 또한 협업을 위해서 그리고 풀스택 개발자가 되기 위해서 서버 구축부터 배포까지의 일련의 과정을 경험하기 위해 새로운 프로젝트를 준비중이다.