목차6개 항목
출처와 참고
테오(teo)의 「프론트엔드 역사와 미래, 업무 분야 ... 그리고 잘하는 프론트엔드 개발자란?」(2021.12)과 「풀스택 개발자에 대해서 어떻게 생각하나요?」(2022.01)를 바탕으로 재구성한 노트다. 앞의 글은 요즘IT에 「시니어 개발자가 말하는, 프론트엔드 업무와 잘하는 프론트엔드 개발자란」(2022.01)으로도 실렸다.
프론트엔드는 무엇을 하나
웹 서비스는 사용자의 입력을 받아 더 가치 있는 데이터로 만들고, 그것을 다시 사용자에게 잘 전달하는 일이다. 프론트엔드는 이 과정에서 사용자와 서비스를 잇는 구간 전체를 구현한다. 데이터 흐름으로 보면 일이 여섯 영역으로 나뉜다.
| 영역 | 하는 일 | 필요한 것 |
|---|---|---|
| 1. 데이터를 보여 주기 | 디자인을 HTML·CSS로 옮기고, 재사용할 컴포넌트로 나누고, 기기·브라우저 대응, 시맨틱·접근성·SEO, 초기 로딩 최적화, 서버 데이터를 화면에 연결 | 마크업·CSS 숙련 |
| 2. 화면을 조작하기 | 현재 화면을 데이터로 구성 → 이벤트 감지 → 행동 분류 → Web API 실행 → 새 데이터와 조립 → 다시 출력 | DOM·Web API, 화면을 이루는 데이터에 대한 이해 |
| 3. 서버로 보내기 | API 문서 읽기, 스키마에 맞춘 타입, 전송 전 검증, 화면 데이터를 API 구조로 변환, 중복 요청 방지(디바운스·스로틀) | HTTP·REST 같은 백엔드와 대화할 만큼의 CS |
| 4. 서버 데이터 다루기 | 서버 스키마와 화면 스키마의 불일치 메우기, 비동기 타이밍(로딩·중복) 처리, 문제가 프론트 쪽인지 백엔드 쪽인지 판별 | 비동기 처리, 협업 경험 |
| 5. 환경 관리와 배포 | 기술 스택·개발 환경 설정, 컨벤션 조율, 일정·이슈 분배, 배포와 릴리스 | 프로젝트 리드 역할 |
| 6. 개발자를 위한 개발 | 사내 공통 모듈·디자인 시스템·SDK, git·jira·npm 같은 도구 환경 구축 | 라이브러리 설계 |
2번이 많은 사람이 프론트엔드를 하고 싶어 하는 이유다. 에디터, 스프레드시트 셀, Figma 같은 기능이 여기 속한다. 하지만 이런 일을 하는 회사는 많지 않다. 수요가 많은데도 하고 싶은 일은 적은 이유다.
3번과 4번이 어려운 이유는 코드가 아니라 의존성에 있다. 인증·보안·헤더·CORS는 백엔드가 정한 설정을 따라야 하고, 이건 코딩이 아니라 학습과 협업의 영역이다. 4번의 스키마 불일치와 비동기 타이밍 문제를 줄이려고 나온 도구가 GraphQL, 서버 상태 라이브러리(TanStack Query, SWR)다.
경계는 그라데이션이다
flowchart LR
subgraph fe["프론트엔드 (주력 위치는 사람마다)"]
subgraph pub["퍼블리셔"]
s1["1 보여 주기"] --- s2["2 조작하기"]
end
subgraph be["백엔드"]
s3["3 보내기"] --- s4["4 받기"]
end
s2 --- s3
end- 일반적으로 퍼블리셔는 1
2, 백엔드는 34를 다룬다. 프론트엔드가 1~4를 혼자 다 하는 것은 아니고, 주력 위치가 그 어딘가에 있다. - 퍼블리셔가 데이터 연동까지 하는 회사도 있고, 프론트엔드가 서버리스나 BFF로 백엔드 기능을 맡기도 한다. 빨강과 노랑 사이에 선을 그을 수 없듯 경계는 회사와 역할마다 다르다.
- 퍼블리셔는 국내에만 있는 직군명이다. 로직은 적지만 작업량이 많아 전문가를 따로 둔다. 다만 프레임워크에서 디자인과 CSS를 재사용 가능한 컴포넌트로 만드는 일은 결코 쉽지 않아, 당당한 프론트엔드의 일부가 되고 있다.
풀스택 개발자
풀스택이라는 말은 2014년 무렵부터 널리 쓰였다. React가 나오고 프론트엔드라는 생태계가 생기자, 기존 웹 개발자(이제 "백엔드")에게 새 영역까지 함께 해 달라는 요구가 생겼기 때문이다. 원래 뜻은 단순했다. "혼자서 웹 서비스를 만들 줄 아는가?"
| 관점 | 내용 |
|---|---|
| 왜 웹에서 유독 찾나 | 웹은 브라우저 없이는 볼 수 없고, 브라우저는 보안 정책상 OS 자원을 거의 못 쓴다. 데이터를 보관하려면 반드시 백엔드가 필요하다. 그래서 초창기 웹 개발자는 원래 풀스택이었다 |
| 왜 유니콘이 됐나 | 산업이 커지면서 각 분야의 기준이 그 분야 전문가가 됐다. 할 줄 아는 것과 전문가인 것은 다르다. 유니콘 여럿보다 협업 잘하는 전문가 집단이 낫다 |
| 그래도 찾는 이유(희망편) | 초기 스타트업은 아이디어를 빨리 검증할 제너럴리스트가 필요하다. 협업 파이프라인 전체를 이해해 CTO에 가까운 자리를 맡는다. 비IT 기업에서는 깊이보다 연결이 가치를 만든다 |
| 그래도 찾는 이유(절망편) | 직군 이름을 핑계로 과도한 범위를 요구하거나 인력 부족을 메우는 데 쓴다 |
| 자칭 풀스택을 꺼리는 이유 | "만능형"의 이면은 어중간함이다. 이것저것 해 봤다고 다 적으면 오히려 신뢰를 잃는다 |
결론은 T자형이다. 하나의 전문성을 갖되 관심의 스펙트럼은 넓게 유지한다. 클라우드와 서버리스로 프론트·백 경계는 흐려지고 있고, 웹이라는 생태계 안에서 연결과 협업은 계속해야 한다. 아주 작게라도 혼자 서비스 한 사이클을 완성해 보는 경험은 시야를 크게 넓힌다.
잘하는 프론트엔드 개발자
개발을 잘하는 것과 일을 잘하는 것은 다르다. 조건을 보는 사람별로 묶으면 이렇다. 프론트엔드가 생긴 역사는 프론트엔드의 등장 배경에 있다.
| 누가 보나 | 조건 | 이유 |
|---|---|---|
| 회사 | 일정을 예측하고 조율한다 | 프론트엔드가 핵심 가치인 서비스(Figma 급)가 아니면 기술 수준보다 일정이 중요하다. 야근으로 맞추라는 뜻이 아니라 규모를 보고 스스로 일정을 통제한다는 뜻이다. 주니어를 벗어났는지 가르는 기준이기도 하다 |
| 회사 | 많이 알고 소통한다 | 기획·디자인·백엔드·QA·UX·사업까지 협업 라인이 가장 많은 자리다. 사용자 기준 사고와 데이터 기준 사고의 차이를 조율한다 |
| 회사 | 글로 소통한다 | 말은 남지 않는다. 담당자가 퇴사하면 막막해진다. 문서를 잘 쓰는 능력은 코드만큼 중요하고, 채용에서 블로그를 보는 이유도 글솜씨를 확인하려는 데 있다 |
| 회사 | 함께 일하고 싶은 사람이다 | 회사는 사람이 모인 곳이다. 성실함, 공감, 유머, 주도성 같은 인성이 면접에서 능력보다 먼저 보인다 |
| 회사 | 빨리 만든다 | 아이디어가 굳기 전에 검증해야 매몰 비용이 작다. 구현이 늦으면 몇 번 겪은 팀은 나쁜 아이디어·디자인도 그냥 채택해 버리게 되고, 결국 사업 가치가 떨어진다. 프로토타입에 능해야 한다 |
| 회사 | 주특기가 깊다 | WebRTC 화상, 소켓 실시간 처리, 3D, 브라우저 AI처럼 프론트엔드 기술을 깊이 쓰는 사업에서는 그 전문성 자체가 비즈니스 가치다 |
| 동료 | 트렌드를 파악하고 공유한다 | 베스트 프랙티스가 정립되기도 전에 새것이 나오는 분야다. 다만 검증 안 된 기술을 고르면 인수인계가 끊기고, 레거시만 고수하면 회사가 낡는다. 트렌드와 현실의 균형이 핵심이다 |
| 사용자 | 좋은 서비스를 만든다 | 프론트엔드의 가치는 기술보다 만든 서비스의 가치로 먼저 평가받는다. 구현 실력이 좋아도 디자인·UX가 형편없으면 사람들은 실력이 아니라 별점 테러로 반응한다. 디자인과 UX도 개발자가 얼마나 돕느냐에 따라 좋아진다 |
개발자의 평판은 실력보다 그 사람이 키운 좋은 서비스에서 먼저 나온다. 더 나은 서비스를 위해 내가 만든 것을 갈아엎는 용기도 잘하는 개발자의 조건이다.
2인분 이상 하기
천재라서 2인분을 하는 경우는 드물다. 개인의 일정 조율이 팀과 회사의 일정 조율로, 개인의 기술 스택 선택이 팀과 회사의 기술 스택 결정으로 넓어질 때 여러 사람의 능력을 끌어낼 수 있다. 이것이 PM·CTO 역할로 이어진다. 더 나아가 좋은 철학으로 회사의 문화를 만들고 그 문화에 맞는 사람을 모아 키우는 일이다. 그러려면 베스트 프랙티스를 단련하고, 자신을 알리는 PR과 스토리텔링도 필요하다.
정리
- 프론트엔드의 일은 보여 주기·조작·보내기·받기·환경·도구 여섯 영역이고, 사람마다 주력 위치가 다르다.
- 퍼블리셔·프론트엔드·백엔드의 경계는 선이 아니라 그라데이션이다.
- 풀스택은 원래 "혼자 웹 서비스를 만들 줄 아는가"였다. 지금은 T자형으로 전문성과 넓은 시야를 함께 갖는 것이 현실적이다.
- 잘하는 프론트엔드 개발자는 정해진 일정과 인력 안에서 요구를 구현해 내고, 협업하며, 트렌드와 현실의 균형을 잡고, 좋은 서비스를 만들려고 애쓰는 사람이다.
관련 노트: 프론트엔드의 등장 배경, 프론트엔드 학습 로드맵, 기술 스택 고르기, 제품 중심 개발자, 프론트엔드 엔지니어의 세 가지 성장 트랙, AI 네이티브 프론트엔드 개발