커리어··6 min read

백엔드에서 풀스택으로 전환한 이유

3년간 백엔드만 파다가 프론트엔드까지 손대기 시작한 현실적인 이유

프론트엔드 싫어했다

솔직히 고백하면 프론트엔드를 무시하던 시절이 있었다. "CSS 맞추는 게 뭐가 개발이야" 같은 생각. 백엔드 개발자들 사이에서 은근히 퍼져 있는 이 편견을, 나도 가지고 있었다.

3년 동안 Spring Boot와 PostgreSQL만 만졌다. API 설계하고, 쿼리 최적화하고, 서버 아키텍처 고민하는 게 "진짜 개발"이라고 생각했다. (지금 생각하면 좀 부끄럽다.)

전환의 계기는 돈이었다

솔직해지자. 프론트엔드를 배우기 시작한 가장 큰 이유는 돈이다. 2024년 하반기에 이직 시장을 살펴보는데, 풀스택 포지션의 연봉이 백엔드 전문보다 평균 700만 원쯤 높았다. 물론 회사마다 다르지만, 내가 본 공고 47개 기준으로 그랬다.

그리고 풀스택 포지션이 백엔드 전문보다 공고 수 자체가 많았다. 작은 회사일수록 "한 사람이 다 하면 좋겠다"는 수요가 강하다.

처음 3개월은 지옥이었다

React를 처음 만졌을 때, state 관리부터 막혔다. 백엔드에서는 요청이 들어오면 처리하고 응답하면 끝이다. 상태를 계속 추적할 일이 별로 없다. 근데 프론트엔드는 상태가 전부다. 이 버튼을 누르면 저 컴포넌트가 바뀌고, 그게 다른 컴포넌트에도 영향을 미치고.

CSS는 진짜 미치는 줄 알았다. 가운데 정렬이 왜 이렇게 어려운지. display: flex를 쓰면 되는 걸 몰라서 margin: auto로 삽질하던 시절이 있었다. (3일간 하나의 모달 레이아웃을 잡았다. 3일.)

근데 Tailwind CSS를 만나고 나서

Tailwind를 처음 접했을 때는 "이게 뭐야, HTML에 인라인 스타일 쓰는 거랑 뭐가 다른 거지"라고 생각했다. 근데 일주일 쓰다 보니 이해됐다. CSS 파일을 왔다 갔다 하지 않아도 된다는 게 백엔드 출신한테는 엄청난 장점이었다.

Tailwind 덕에 프론트엔드에 대한 거부감이 확 줄었다. 디자인 감각은 여전히 없지만, 최소한 화면을 만들 수는 있게 됐다. 디자인 시스템이 있는 프로젝트에서는 큰 문제가 안 된다.

풀스택이 된 뒤 바뀐 것들

가장 크게 바뀐 건 API를 설계하는 관점이다. 백엔드만 할 때는 "데이터를 이렇게 내려주면 되겠지"였다. 지금은 "프론트엔드에서 이 데이터를 어떻게 쓸 건지"부터 생각한다. 화면에서 필요한 형태로 API를 만들다 보니 오버페칭도 줄고, 프론트엔드 코드도 깔끔해진다.

팀 내 소통도 달라졌다. 예전에는 프론트엔드 개발자가 "이거 이렇게 내려주세요"라고 하면 "그건 프론트에서 처리하세요"라고 핑퐁을 쳤다. 지금은 양쪽 사정을 다 알으니까 "서버에서 가공하는 게 나을지, 클라이언트에서 처리하는 게 나을지" 판단이 바로 선다.

솔직히 후회하는 부분도 있다

백엔드 깊이가 좀 얕아진 느낌이 있다. 양쪽을 다 하다 보니 시스템 설계나 데이터베이스 튜닝 쪽에 쓰는 시간이 줄었다. 예전에는 쿼리 실행 계획 분석에 반나절을 쓸 수 있었는데, 지금은 프론트엔드 작업도 있으니까 "일단 동작하면 넘어가자" 모드가 될 때가 있다.

깊이 vs 넓이의 트레이드오프를 매일 실감한다. 둘 다 잡을 수 있다는 사람은 솔직히 믿지 않는다. (아니면 내가 부족한 건가.)

그래도 돌아가고 싶진 않다

백엔드만 하던 시절로 돌아가고 싶은 마음은 없다. 혼자서 서비스 하나를 처음부터 끝까지 만들 수 있다는 건, 사이드 프로젝트를 할 때든 이직을 준비할 때든 큰 무기가 된다.

근데 "풀스택 개발자"라는 타이틀이 만능은 아니라는 것도 알게 됐다. 면접에서 백엔드 깊이 있는 질문이 나오면 3년 전보다 대답이 좀 흔들린다. 그게 좀 쪽팔린다.

어쨌든 후회는 없다. 내일도 오전에는 API 짜고 오후에는 컴포넌트 만들 거다.

관련 글