프론트엔드

웹이 처음부터 화면 쪽을 따로 두지는 않았습니다. 초기의 웹은 서버가 완성된 문서를 통째로 만들어 내려보내면 브라우저가 그것을 그대로 펼쳐 보여 주는 구조였습니다. 브라우저가 하는 일은 받은 것을 표시하는 데서 끝났고, 사람이 무엇을 누르면 그 신호가 서버로 가서 새 문서를 받아 오는 식으로 돌았습니다. 읽기만 하는 문서에는 이 구조가 잘 맞았습니다.

웹이 읽는 곳에서 조작하는 곳으로 바뀌면서 이 방식이 막혔습니다. 클릭 한 번마다 페이지 전체를 다시 받아야 했기 때문입니다. 페이지덱 초기 버전에서 민서가 문서에 댓글을 하나 달면 화면이 하얗게 깜빡였다가 처음부터 다시 그려졌고, 읽던 자리가 아니라 문서 맨 위로 튀었습니다. 댓글 다섯 개를 달면 다섯 번 튀었습니다. 문의가 들어왔을 때 팀이 바로 손을 대지 못한 이유는 고칠 방법을 몰라서가 아니라, 그 부분이 서버가 문서를 찍어 내는 코드 안에 섞여 있었기 때문입니다. 화면에서 난 일인데 화면만 따로 손댈 자리가 없었습니다.

그래서 만든 것을 사용자 기기에서 도는 쪽과 회사 서버에서 도는 쪽으로 갈랐습니다. 뒤쪽이 백엔드로, 데이터를 저장하고 꺼내며 업무 규칙을 따지는 영역입니다. 앞쪽이 프론트엔드입니다. 선을 한 번 긋고 나면 저장 버튼 하나에도 두 층이 같이 걸린다는 것이 분명해집니다. 누르는 순간 버튼이 회색으로 바뀌고 옆에서 작은 원이 도는 것은 앞쪽 몫이고, 그 내용이 진짜로 남아 다음 날 다른 노트북에서도 열리는 것은 뒤쪽 몫입니다.

둘을 잇는 창구는 API입니다. 프로그램끼리 무엇을 어떤 모양으로 주고받을지 미리 맞춰 둔 약속으로, 화면 쪽은 이 약속만 보고 일하면 되고 서버 안에서 벌어지는 일은 알 필요가 없습니다. 약속이 문서로 먼저 나와 있으면 서버가 아직 비어 있어도 화면을 만들 수 있습니다. 약속된 모양대로 가짜 값을 채워 놓고 화면을 완성해 둔 뒤, 서버가 준비되면 주소만 바꿔 끼웁니다.

갈라 놓은 뒤에 앞쪽이 따로 다룰 만큼 커진 이유는 무대가 남의 것이기 때문입니다. 서버는 회사가 고른 기계에서 회사가 정한 조건으로 돌지만, 화면은 사용자가 가진 기기에서 사용자가 쓰는 브라우저로 돕니다. 3년 된 안드로이드 폰에서, 지하철에서 끊기는 회선으로, 글자 크기를 150퍼센트로 키워 둔 설정에서 같은 화면이 돌아가야 합니다. 여기서 생기는 일은 서버를 아무리 손봐도 없어지지 않습니다.

프론트엔드 아래 묶인 용어는 코드 한 줄이 화면의 한 점이 되기까지의 길을 따라 놓여 있습니다. 무엇으로 화면을 적느냐가 기반 기술이고, 그 화면을 언제 어디서 그리느냐가 렌더링이고, 커진 화면을 어떻게 쪼개 다루느냐가 구성이고, 쪼갠 것을 어떤 모양으로 묶어 내보내느냐가 빌드입니다. 여기에 웹을 앱처럼 쓰게 만드는 형태와 제각각인 브라우저를 맞추는 호환이 붙어 여섯 갈래가 됩니다.

기반 기술은 화면을 적는 언어들입니다. 다섯 가지가 있고 서로 역할이 겹치지 않습니다.

1. HTML — 화면에 무엇이 있는지를 적는 마크업 언어입니다. 여기는 제목이고 여기는 문단이고 여기는 누를 수 있는 버튼이라는 식으로 구조를 나타냅니다. 모양을 정하는 언어가 아니라 정체를 밝히는 언어입니다.
2. CSS — 그것들이 어떻게 보일지를 지정하는 스타일 언어입니다. 글자 크기와 여백과 색은 물론이고, 화면이 좁아졌을 때 나란히 놓였던 항목을 세로로 다시 세우는 규칙까지 여기서 씁니다.
3. 자바스크립트 — 브라우저에서 동작을 만드는 언어입니다. 버튼을 누르면 무엇이 열리게 하고, 입력한 값이 규칙에 맞는지 그 자리에서 확인하고, 서버에 요청을 보내 받아 온 값으로 화면을 갈아 끼우는 일을 맡습니다.
4. 타입스크립트 — 자바스크립트에 값의 종류를 미리 적어 두는 문법을 더한 언어입니다. 숫자가 와야 할 자리에 글자가 들어오면 실행하기 전에 걸립니다. 사람이 늘고 화면이 늘수록 미리 걸러 내는 값이 커져서, 어느 규모부터는 기본값처럼 씁니다.
5. DOM — 브라우저가 읽어 들인 문서를 코드에서 다룰 수 있는 객체 덩어리로 바꿔 놓은 것입니다. 자바스크립트가 화면을 바꾼다는 말은 실제로는 이 덩어리를 고친다는 뜻입니다.

렌더링은 그 화면을 언제 어디서 그릴지 가르는 갈래입니다. SPA는 문서 하나를 받아 두고 그 안에서 화면만 갈아 끼우는 방식입니다. 이동할 때마다 전체를 다시 받지 않으니 앞 장면의 깜빡임이 사라집니다. 클라이언트 렌더링은 그리는 일을 전부 브라우저에 맡기는 쪽이라 첫 화면이 뜨기까지 빈 자리가 길고, 서버 렌더링은 서버가 미리 그려 내려보내 첫 화면을 빨리 띄웁니다. 정적 생성은 아예 배포 전에 모든 페이지를 만들어 두는 방식이고, 증분 정적 생성은 그렇게 만들어 둔 페이지 중 내용이 바뀐 것만 골라 다시 굽습니다. 하이드레이션은 서버가 그려 보낸 화면에 뒤늦게 동작을 입히는 과정인데, 그 사이에 화면은 떠 있는데 눌러도 아무 반응이 없는 몇백 밀리초가 생깁니다.

구성은 커진 화면을 쪼개 다루는 갈래입니다. 컴포넌트는 화면을 이루는 재사용 가능한 코드 단위로, 버튼 하나나 댓글 한 줄 같은 조각을 구조와 스타일과 동작까지 한 덩어리로 묶어 둡니다. 같은 버튼이 열 화면에 나와도 정의는 한 곳에만 있습니다. 상태 관리는 화면이 기억해야 하는 값을 어디에 두고 누가 바꿀지 정하는 일입니다. 로그인한 사람이 누구인지, 지금 어느 문서를 열어 뒀는지, 저장이 진행 중인지 같은 값이고, 이 값이 바뀌면 그것을 쓰는 화면이 함께 바뀌어야 합니다. 프롭 드릴링은 그 값을 위에서 아래로 한 단계씩 손으로 내려 주다 생기는 문제입니다. 일곱 단계 아래의 조각에 값 하나를 주려고 중간의 여섯 개가 쓰지도 않는 값을 받아 넘기게 됩니다.

빌드는 쪼갠 것을 내보낼 모양으로 묶는 갈래입니다. 번들러는 수백 개로 나뉜 파일을 브라우저가 받기 좋은 몇 개로 묶어 주는 도구입니다. 나머지 셋은 그 묶음을 줄이는 방법입니다. 트리 셰이킹은 불러오기는 했지만 실제로 쓰이지 않는 코드를 결과물에서 걷어 내고, 코드 스플리팅은 전부를 처음에 주는 대신 해당 화면에 들어갈 때 나눠 받게 하고, 지연 로딩은 화면 아래쪽 이미지처럼 아직 보이지도 않는 자원을 나중으로 미룹니다. 이 셋이 없으면 설정 화면에 한 번도 들어가지 않는 사용자까지 설정 화면 코드를 첫 로딩에 함께 받습니다.

형태와 호환은 만든 것을 실제 환경에 맞추는 갈래입니다. PWA 는 웹을 홈 화면에 설치하고 알림까지 받을 수 있게 만든 형태로, 앱 스토어를 거치지 않고 앱에 가까운 경험을 주려 할 때 씁니다. 크로스 브라우저는 크롬·사파리·파이어폭스처럼 서로 다른 브라우저에서 같은 화면이 같게 동작하도록 맞추는 일이고, 폴리필은 옛 브라우저에 없는 기능을 대신 흉내 내는 코드를 끼워 넣어 그 맞춤을 돕습니다.

여섯 갈래는 한 줄로 이어진 단계가 아니라 서로를 당깁니다. 조각으로 잘게 쪼개면 파일 수가 늘어 묶어 줄 도구가 필요해지고, 묶음이 커지면 첫 화면이 늦어져 서버 렌더링과 코드 스플리팅을 꺼내게 되고, 서버 렌더링을 택하면 하이드레이션이라는 새 문제가 따라옵니다.

"이건 프론트엔드에서 막을 수 있어요. 서버까지 다녀오지 않고 화면에서 바로 안내하면 됩니다."

빈 칸이나 형식이 틀린 입력처럼 굳이 서버에 물어보지 않아도 아는 것은 그 자리에서 알려 주자는 제안입니다.

"이번 주는 프론트엔드만 먼저 붙입니다. 데이터는 아직 가짜 값이라 화면만 보시면 돼요."

약속된 모양대로 채운 임시 값으로 화면을 완성해 두고 서버는 나중에 연결하겠다는 뜻이고, 지금 보이는 숫자를 진짜로 읽지 말라는 단서이기도 합니다.

"이 화면은 프론트엔드가 무거워요. 첫 로딩에 받는 파일이 3메가라 밖에서는 8초씩 걸립니다."

기능이 부족한 게 아니라 받아야 할 코드와 이미지의 양이 문제라는 지적이고, 빌드 쪽을 손볼 때가 됐다는 신호입니다.

페이지덱에서 이 영역은 태오와 민서가 맞물려 일하는 자리입니다. 민서가 화면을 그려 넘기면 태오가 그것을 코드로 옮기는데, 넘어가는 순간 늘 같은 질문이 남습니다. 제목이 예상보다 길어 두 줄이 되면 어떻게 되는지, 목록이 비어 있을 때는 무엇을 보여 주는지, 불러오는 동안에는 무엇이 뜨는지. 그림 한 장에는 잘 풀린 경우 하나만 그려져 있지만 코드는 나머지 경우까지 전부 정해 줘야 합니다. 그래서 둘은 화면을 넘길 때 비었을 때·불러오는 중·실패했을 때 세 가지를 같이 정해 둡니다.

지현이 이 영역에 대해 가장 자주 묻는 것은 언제 보여 줄 수 있느냐입니다. 서버 작업이 밀린 주에도 화면은 가짜 값으로 돌려 볼 수 있어서, 사용자 테스트나 투자자 시연은 앞쪽만으로 먼저 잡습니다. 대신 그 화면으로는 실제로 저장이 되는지 알 수 없어서, 시연에서 멀쩡하던 기능이 연결한 다음 주에 어긋나는 일이 생깁니다.

프론트엔드를 디자인을 옮겨 그리는 일로 보는 오해가 가장 흔합니다. 결과물이 눈에 보이는 화면이고 그 화면의 모양을 디자이너가 먼저 정하니 그렇게 보일 만합니다. 하지만 그림에 없는 것이 코드에는 전부 있어야 합니다. 목록이 비었을 때, 불러오다 실패했을 때, 권한이 없을 때, 두 사람이 같은 문서를 동시에 고칠 때 화면이 각각 무엇을 보여 줄지가 다 정해져야 하고, 이 경우의 수가 잘 풀린 화면 한 장보다 훨씬 많습니다. 이 오해를 그대로 두면 일정이 같은 방식으로 계속 어긋납니다. 그림 열 장을 받아 열흘로 잡았는데 실제로는 삼 주가 걸리고, 늘어난 시간은 그림에 없던 화면들을 정하고 만드는 데 들어갑니다.

화면은 눈에 보이니 문제도 금방 드러난다고 여기는 오해도 자주 나옵니다. 서버 쪽 고장은 기록을 뒤져야 보이지만 화면이 깨지면 누구나 알아본다는 점에서 맞는 말처럼 들립니다. 다만 그 말은 내 기기에서 볼 때만 참입니다. 같은 코드가 사파리에서만 버튼이 밀리고, 안드로이드 저가 단말에서만 스크롤이 끊기고, 글자 크기를 키워 둔 사람에게만 글자가 잘립니다. 만드는 사람은 대개 최신 노트북에 크롬을 쓰고 회사 와이파이에 붙어 있어서 그중 어느 것도 겪지 않습니다. 이 오해를 붙들고 있으면 문의가 들어와도 재현이 안 된다는 이유로 접수되지 않고, 몇 달 뒤 특정 브라우저 사용자만 조용히 빠져나간 뒤에야 드러납니다.