프론트엔드 개발자

웹이 문서에 가깝던 시절에는 이 자리가 따로 없었습니다. 서버가 화면 전체를 만들어 통째로 내려보내면 브라우저는 그것을 그대로 펼쳐 보여 줬고, 무엇을 누르든 화면이 하얘졌다가 새로 그려졌습니다. 그래서 서버를 만드는 사람이 화면까지 함께 맡았고, 화면 일은 남는 시간에 하는 일로 여겨졌습니다.

브라우저 안에서 도는 코드가 늘면서 사정이 달라졌습니다. 새로고침 없이 목록이 채워지고, 저장 버튼을 누르면 그 자리에서 표시가 바뀌고, 한 화면 안에서 여러 일이 동시에 진행됩니다. 여기에 화면 크기가 휴대폰부터 큰 모니터까지 갈라지고 브라우저마다 동작이 조금씩 다르다는 조건이 겹치면서, 화면 쪽에만 매달려도 하루가 모자라는 상태가 됐습니다.

이 무렵 팀마다 비슷한 장면이 반복됐습니다. 서버 담당자가 자기 일을 끝내 놓고, 특정 브라우저에서만 깨지는 레이아웃과 두 번 누르면 두 번 저장되는 버튼을 붙들고 밤을 새웠습니다. 서버 일과 화면 일은 같은 제품을 만들지만 매일 부딪히는 문제의 종류가 달랐고, 그래서 자리가 갈라졌습니다. 갈라진 뒤 화면 쪽을 맡은 사람이 프론트엔드 개발자입니다.

하루의 대부분은 디자인 시안 한 장을 브라우저에서 실제로 도는 화면으로 옮기는 데 씁니다. 옮기는 일은 다섯 갈래로 나뉩니다.

1. 시안을 조각으로 나눕니다. 버튼 하나, 입력 칸 하나, 목록의 한 줄처럼 다시 쓸 수 있는 단위를 컴포넌트라고 부르고, 화면은 이 조각을 쌓아 만듭니다. 팀이 색과 간격과 부품을 한 기준으로 묶어 둔 디자인 시스템이 있으면 새로 만들지 않고 가져다 씁니다.
2. 데이터를 붙입니다. 화면에 채울 내용은 서버에 있고, 프로그램끼리 주고받기로 약속한 창구인 API를 통해 받아 옵니다.
3. 상태를 전부 만듭니다. 같은 화면이라도 불러오는 중, 내용이 하나도 없을 때, 요청이 실패했을 때, 권한이 없을 때의 모습이 각각 다른데 이것을 UI 상태라고 합니다. 시안에는 대개 잘 풀린 경우 한 장만 있어서, 나머지를 찾아 채우는 일이 작업 시간의 절반 가까이를 차지합니다.
4. 여러 환경에서 같게 보이도록 맞춥니다. 폭 360픽셀 휴대폰에서 배치가 무너지지 않게 하고, 키보드만으로도 모든 버튼에 닿을 수 있게 하고, 화면을 읽어 주는 보조 기기가 무엇을 읽어야 할지 코드에 적어 둡니다.
5. 빠르기를 지킵니다. 화면이 뜨는 데 걸리는 시간을 다루는 일을 웹 성능이라고 합니다. 첫 화면이 1초에서 3초로 밀리면 그사이에 나가는 사람이 눈에 띄게 늘어서, 이미지 하나를 더 넣을 때도 몇 밀리초가 붙는지를 봅니다.

다 만들면 바로 합치지 않고 동료에게 보여 줍니다. 합치기 전에 동료가 변경 내용을 읽고 의견을 다는 절차를 코드 리뷰라고 하고, 여기서 놓친 상태나 성능 문제를 잡습니다.

양옆이 모두 다른 직군이라 하루에 세 방향으로 말을 겁니다.

앞쪽은 디자인입니다. 문제 정의부터 화면까지 제품 디자인 전반을 맡는 프로덕트 디자이너에게서 시안을 받고, 시안에 없는 경우를 묻습니다. 목록이 100줄을 넘으면 어떻게 할지, 제목이 두 줄이 되면 어디가 밀리는지 같은 것들입니다. 이 대화를 미루면 혼자 판단하게 되고, 나중에 화면마다 다른 규칙이 생깁니다.

뒤쪽은 서버입니다. 화면 뒤에서 데이터와 규칙을 처리하는 쪽을 맡은 백엔드 개발자와 주고받을 데이터의 모양을 먼저 맞춥니다. 모양만 정해 두면 서버가 아직 없어도 가짜 데이터로 화면을 먼저 만들 수 있어서, 두 사람이 서로를 기다리지 않고 동시에 일합니다.

옆쪽은 제품과 품질입니다. 무엇을 왜 만들지 정하는 프로덕트 매니저와는 범위를 놓고 이야기합니다. 이번 주에 못 넣을 것을 미리 말하는 자리이기도 합니다. 품질을 검증하는 QA 엔지니어는 기기와 브라우저를 바꿔 가며 같은 화면을 확인하고, 이 과정에서 개발자 컴퓨터에서는 멀쩡하던 문제가 나옵니다.

"이 목록이 비었을 때 화면은 어떻게 보여 드릴까요? 시안에 빈 상태가 없어서요."

시안에 없는 경우를 채우려고 디자이너에게 묻는 말입니다.

"응답 형태만 먼저 정해 주시면 가짜 데이터로 화면부터 만들어 둘게요."

서버가 완성될 때까지 기다리지 않겠다는 뜻입니다.

"이 애니메이션을 넣으면 첫 화면 뜨는 시간이 0.4초 늘어납니다."

보기 좋음과 빠르기 가운데 무엇을 고를지 결정해 달라는 요청입니다.

페이지덱에서 문서 목록 화면을 새로 만들던 주에 태오가 민서에게 물은 것은 세 가지였습니다. 문서가 하나도 없는 새 계정은 무엇을 보게 되는지, 제목이 긴 문서는 줄여서 보여 줄지 두 줄로 내릴지, 목록을 불러오는 동안 빈 화면을 둘지 회색 뼈대를 둘지였습니다.

셋 다 시안에는 없던 화면이었습니다. 민서가 그 자리에서 셋을 그려 줬고, 태오는 그 주에 화면 네 벌을 만들었습니다. 잘 풀린 경우 한 벌과 나머지 세 벌입니다. 지현이 일정을 잡을 때 이 화면을 하루로 잡았다가 사흘로 고친 것도 이때였습니다.

프론트엔드 개발자를 화면을 예쁘게 만드는 사람으로 보는 경우가 가장 많습니다. 하는 일의 결과가 눈에 보이니 그렇게 읽힙니다. 하지만 보기 좋은 배치를 정하는 것은 디자이너 쪽 일이고, 이 자리의 일은 정해진 화면을 여러 조건에서 틀리지 않게 도는 코드로 만드는 것입니다. 이 차이를 모르면 일정이 어긋납니다. 버튼 하나 추가는 30분이라고 생각하기 쉽지만, 누르는 중과 실패했을 때와 권한이 없을 때를 다 만들고 휴대폰 화면까지 확인하면 이틀이 되는 일이 흔합니다.

서버 쪽보다 쉬운 일로 보는 오해도 함께 다닙니다. 새로 고치면 결과가 바로 보이니 간단해 보입니다. 실제로 어려운 쪽은 입력이 예측되지 않는다는 점입니다. 서버는 정해진 형식의 요청을 받지만 화면은 사람이 버튼을 두 번 누르고, 인터넷이 끊긴 채로 저장을 누르고, 뒤로 가기를 눌러 이전 화면으로 돌아옵니다. 이 점을 가볍게 보면 인원과 일정이 한쪽으로 쏠리고, 기능은 다 됐는데 실제로 쓰면 어딘가 어긋나는 제품이 나옵니다.