대학교 때는 백엔드를 했다. Spring Boot로 API 만드는 게 "진짜 개발"이라고 생각했다. 서버를 띄우고, 데이터베이스를 설계하고, 복잡한 비즈니스 로직을 짜는 게 개발자의 본분이라는 막연한 확신이 있었다.

그때 나한테 프론트엔드란 건 HTML에 CSS 좀 입히고 버튼 달아놓는 수준이었다. 과장이 아니라 진심으로 그렇게 생각했다. 서버 사이드 렌더링이니 상태 관리니 하는 개념 자체가 시야에 없었다. Controller에 @GetMapping 붙이는 게 개발이고, <div>에 onClick 다는 건 그냥 조립이라고 봤다.

우연히 맡게 된 프론트#

3학년 2학기 캡스톤 프로젝트에서 팀이 짜여졌는데, 백엔드를 하겠다는 사람이 나 포함 세 명이었다. 프론트는 아무도 안 하려고 했다. 결국 가위바위보를 했고, 졌다.

React를 처음 만졌을 때의 감각이 아직 기억난다. useState로 카운터를 만들었는데, 버튼을 클릭하면 숫자가 올라갔다. 이게 뭐가 대단하냐고 할 수 있는데, 나한테는 좀 새로운 경험이었다. 백엔드에서는 Postman으로 API를 쏘고, JSON 응답이 제대로 내려오는지 확인하는 게 결과물의 전부였다. 내가 만든 코드의 결과를 "보는" 거랑 "읽는" 건 완전히 다른 감각이었다.

프로젝트 중반쯤 로그인 폼을 만들었다. 이메일 입력하고, 비밀번호 입력하고, 로그인 버튼 누르면 홈 화면으로 넘어가는 평범한 플로우. 근데 여기에 유효성 검사 애니메이션을 넣고, 로딩 스피너를 붙이고, 에러 메시지가 슬라이드로 나타나게 만들었을 때 — 이걸 내가 만들었다는 게 꽤 좋았다. Spring Boot에서 ResponseEntity.badRequest() 리턴할 때는 한 번도 느끼지 못한 감정이었다.

캡스톤 발표날, 교수님이 우리 팀 프로젝트를 시연하면서 "UI가 깔끔하네"라고 했다. 한마디였다. 근데 그 한마디가 묘하게 오래 남았다.

"프론트는 쉬운 거 아냐?"#

프론트엔드에 관심을 갖기 시작한 뒤로, 이 말을 정말 자주 들었다. 주로 백엔드 하는 동기들한테서. 악의는 없었을 거다. 근데 "프론트는 금방 배우잖아", "서버가 진짜 어려운 건데" 같은 말을 반복적으로 들으면 은근히 쌓인다.

동아리 스터디에서도 비슷한 분위기가 있었다. 시스템 디자인을 논의할 때 백엔드 팀원이 데이터베이스 샤딩이나 메시지 큐 아키텍처를 설명하면 다들 진지하게 들었다. 나는 클라이언트 사이드 캐싱 전략이나 렌더링 최적화에 대해 말했는데, 반응이 달랐다. "아 그건 그냥 라이브러리 쓰면 되는 거 아니야?" 이런 식이었다.

한번은 취업 준비 커뮤니티에서 "프론트엔드 개발자는 서버 개발자의 하위 호환"이라는 글을 봤다. 댓글에 동의하는 사람이 많았다. 그걸 읽고 나서 한동안 좀 흔들렸다. 내가 더 어려운 길을 피해서 쉬운 쪽으로 간 건가. 진짜 실력이 있으면 백엔드를 하는 게 맞는 건가.

흔들리다가 멈춘 지점#

첫 회사에서 인턴으로 프론트엔드를 시작했다. 작은 SaaS 회사였고, 사수가 한 명 있었다. 입사 첫 주에 받은 태스크가 대시보드의 차트 컴포넌트를 리팩토링하는 거였다. 기존 코드는 하나의 거대한 컴포넌트에 모든 로직이 들어가 있었고, props가 20개가 넘었다.

그걸 분리하고, 커스텀 훅으로 데이터 로직을 빼고, 재사용 가능한 구조로 바꾸는 데 일주일이 걸렸다. 그 과정에서 깨달은 게 있다. 프론트엔드가 "쉬운" 게 아니라, 프론트엔드의 어려움이 백엔드의 어려움이랑 종류가 다른 거였다. 서버는 정합성과 확장성의 문제를 풀고, 클라이언트는 복잡성과 사용자 경험의 문제를 푼다. 무게가 다른 게 아니라 방향이 다르다.

사수가 코드 리뷰에서 이런 말을 했다. "프론트에서 컴포넌트 구조를 잘 잡는 건 백엔드에서 테이블 설계를 잘 하는 것만큼 중요하다." 당연한 말 같지만, 그때 나한테는 필요한 말이었다. 내가 하는 일이 "진짜 개발"이 아닌 것 같다는 감각을 조금씩 내려놓기 시작했다.

유저와 가장 가까운 곳#

프론트엔드를 계속하게 된 결정적인 이유는 기술적인 게 아니었다.

두 번째 회사에서 결제 플로우를 리뉴얼하는 프로젝트를 맡았다. 기존 결제 페이지는 단계가 5개였고, 이탈률이 높았다. 디자이너와 같이 3단계로 줄이고, 각 단계에서 필요한 정보만 보여주는 방식으로 바꿨다. 로딩 상태도 스켈레톤 UI로 바꾸고, 에러 발생 시 복구 플로우도 추가했다.

배포하고 2주 뒤에 PM이 슬랙에 메시지를 남겼다. "결제 전환율이 12% 올랐어요." 거기에 유저 피드백 캡처가 같이 올라왔는데, "결제가 훨씬 편해졌다"는 내용이었다.

그 순간의 감정을 정확히 설명하기 어렵다. 내가 짠 코드가 누군가의 행동을 바꿨다. 클릭을 더 하게 만들었고, 이탈을 줄였다. 서버 로그에 찍히는 숫자가 아니라, 실제 사람이 화면을 보면서 "이건 괜찮네"라고 느낀 거다. 백엔드에서 API 응답 속도를 200ms 줄였을 때도 뿌듯했지만, 유저의 반응을 직접 볼 수 있다는 건 차원이 다른 보상이었다.

디자이너와의 협업도 좋았다. 처음에는 피그마 시안을 "그대로 구현하는 사람" 정도로 내 역할을 봤는데, 점점 달라졌다. "이 인터랙션은 기술적으로 가능한데, 이렇게 바꾸면 더 자연스러울 것 같아요"라고 제안하기 시작했다. 디자이너가 "오, 그게 더 좋다"고 하면 그때 느끼는 재미가 있다. 순수하게 무언가를 같이 만들고 있다는 느낌. 백엔드 할 때는 디자이너와 대화할 일 자체가 없었다.

시각적 감각이라는 것도 프론트를 하면서 생겼다. 간격이 4px 어긋나면 눈에 거슬리고, 색상 대비가 부족하면 바로 보인다. 2년 전의 나는 margin이랑 padding도 헷갈리던 사람인데, 지금은 디자인 시스템에 의견을 낼 수 있는 정도가 됐다. 이런 성장의 감각이 계속 나를 붙잡아뒀다.

그래도 가끔은#

연봉 얘기가 나올 때마다 한 번씩 생각한다. 백엔드를 했으면 어땠을까.

채용 공고를 보면 백엔드 시니어의 연봉 상한선이 프론트보다 높은 경우가 많다. 인프라 쪽으로 가면 더 그렇다. 개발자 커뮤니티에서 "프론트엔드 시장이 포화됐다"는 글이 올라오면 괜히 불안해진다. 부트캠프 출신 주니어가 대부분 프론트엔드를 선택하면서 경쟁이 치열해진 건 사실이니까.

같은 연차 백엔드 개발자 친구랑 밥을 먹다가 연봉 얘기가 나온 적이 있다. 차이가 크진 않았는데, 약간의 차이가 있었다. 그날 집에 오면서 별 생각이 다 들었다. "지금이라도 백엔드로 전향할까" 같은 생각이 3초 정도 스쳤다.

3초였다. 그 이상은 아니었다.

왜냐면, 그 친구가 밥 먹으면서 이런 말도 했기 때문이다. "나는 요즘 일이 좀 지겹다. 매일 비슷한 API 찍어내는 느낌이야." 연봉이 조금 더 높아도, 매일 하는 일이 지겨우면 그게 무슨 의미인가.

나는 아직 지겹지 않다. 아침에 VSCode를 열 때 "오늘은 뭘 만들지"라는 생각이 먼저 든다. 새로운 CSS 속성이 나오면 바로 써보고 싶고, 브라우저 DevTools에서 레이아웃 디버깅하는 것도 나름의 즐거움이 있다. Next.js가 업데이트되면 changelog를 읽으면서 "이걸로 뭘 할 수 있지" 하고 상상한다. 이런 감각이 살아있는 한, 다른 분야가 연봉이 조금 더 높다고 해서 옮기고 싶진 않다.

맞는 선택이란 건 없다#

가끔 주니어 개발자들한테 "프론트엔드랑 백엔드 중에 뭘 해야 하나요?"라는 질문을 받는다. 예전에는 나름 근거를 대면서 답변하려고 했다. "시각적인 걸 좋아하면 프론트", "논리적 사고가 강하면 백엔드" 같은 식으로. 근데 요즘은 그런 대답이 별로 도움이 안 된다는 걸 안다.

나는 가위바위보에서 져서 프론트를 시작했다. 거기서 예상치 못한 재미를 발견했고, 무시하는 분위기에 흔들렸다가, 유저 반응에서 보람을 찾았고, 연봉 차이에 잠깐 흔들렸다가, 결국 매일 아침의 기분으로 답을 냈다. 이걸 "맞는 선택"이라고 부를 수 있나? 모르겠다. 그냥 하다 보니 여기 있다.

"뭐가 맞는 선택이냐"는 질문에 대한 답은 없다. 있으면 좋겠는데, 없다. 지금 이 순간 코드를 쓰면서 지겹지 않은가. 내일도 이걸 하고 싶은가. 그게 전부인 것 같다. 대단한 확신이 아니라 그냥 오늘의 기분. 그걸로 충분하다.