개발자 취업 상담에서 프런트엔드와 백엔드 중 어느 쪽을 준비하는지 물으면 아직 결정하지 못했다는 답변을 자주 듣습니다. 화면을 꾸미는 일은 디자인 감각이 있어야 할 것 같고, 서버 개발은 어려운 알고리즘과 데이터베이스를 완벽하게 알아야 할 것 같아 선택을 미루기도 합니다. 하지만 두 분야의 차이는 단순히 보이는 화면과 보이지 않는 서버로만 나뉘지 않습니다.
같은 회원가입 기능을 만들더라도 클라이언트 영역에서는 입력 과정과 화면 상태를 중심으로 보고, 서버 영역에서는 검증과 인증, 데이터 저장과 오류 응답을 다룹니다. 사용하는 기술스택도 다르지만 더 중요한 차이는 어떤 문제를 반복해서 해결하는가에 있습니다. 실제 업무 흐름과 프로젝트 경험을 비교해야 자신에게 맞는 직무를 현실적으로 선택할 수 있습니다.
직무비교는 하나의 요청이 처리되는 흐름에서 시작해야 합니다
- 화면과 서버는 같은 기능을 서로 다른 위치에서 완성합니다
온라인 쇼핑몰에서 사용자가 상품을 검색하고 주문하는 상황을 생각해 보겠습니다. 사용자가 검색어를 입력하면 입력값이 화면 상태에 반영되고 서버로 요청이 전달됩니다. 검색 결과를 기다리는 동안 로딩 상태를 보여주고, 결과가 없거나 요청에 실패했을 때 적절한 안내를 표시하는 일은 화면 개발과 가깝습니다.
서버에서는 전달받은 검색어가 올바른지 확인하고 데이터베이스에서 조건에 맞는 상품을 조회합니다. 주문 요청에서는 로그인한 사용자인지 확인하고 재고가 충분한지 검사한 뒤 주문 정보를 저장합니다. 처리에 실패하면 원인에 맞는 상태 코드와 오류 메시지를 반환해야 합니다.
- 클라이언트 개발자는 사용자가 서비스를 이용하는 과정을 구현합니다. 입력, 클릭, 화면 전환, 로딩, 성공과 실패 상태를 연결하고 다양한 화면 크기와 브라우저에서도 기능이 자연스럽게 작동하는지 확인합니다.
- 서버 개발자는 사용자의 요청을 받아 업무 규칙에 따라 데이터를 처리합니다. 인증과 권한, 데이터 조회와 저장, 트랜잭션, 예외 응답을 설계하고 여러 요청이 동시에 들어오는 상황도 고려해야 합니다.
- 두 역할은 분리되어 있지만 독립적으로만 일하지는 않습니다. API의 요청값과 응답 형식, 오류 코드, 인증 방식이 서로 합의되어야 화면과 서버가 정상적으로 연결됩니다.
- 검색 결과가 뒤바뀐 화면 개발 사례
디자인을 전공한 한 준비생은 상품 검색 화면을 구현하고 API를 연동했습니다. 검색어를 입력하면 관련 상품이 표시됐기 때문에 기능이 완성됐다고 생각했습니다. 하지만 사용자가 검색어를 빠르게 바꾸면 이전 요청의 결과가 뒤늦게 도착해 현재 입력한 검색어와 다른 상품이 나타나는 문제가 발생했습니다.
처음에는 네트워크 속도가 느려서 생긴 현상이라고 판단했습니다. 코드를 다시 확인해 보니 검색어가 바뀔 때마다 요청이 발생했고, 먼저 보낸 요청이 나중에 도착하면 해당 결과가 현재 화면을 덮어쓰고 있었습니다. 새로운 라이브러리를 바로 추가하지 않고 검색어가 변경된 시각과 요청 및 응답 순서를 기록했습니다.
이후 연속된 입력이 발생할 때 요청 횟수를 조절하고, 현재 검색어와 일치하는 결과만 화면에 반영하도록 수정했습니다. 검색 결과가 없는 상황과 서버 요청이 실패한 경우도 별도의 상태로 구분했습니다. 빠른 입력과 느린 응답, 빈 검색어, 결과 없음 상황을 나누어 다시 테스트했습니다.
- 기능 중심 설명: 상품명으로 검색할 수 있는 화면과 API 연동 기능을 구현했습니다.
- 처리 과정이 보이는 설명: 검색어에 따라 API를 호출하고 로딩, 검색 결과 없음, 요청 실패 상태를 구분해 표시했습니다.
- 문제해결이 담긴 설명: 이전 검색 요청이 나중에 도착해 현재 결과를 덮어쓰는 문제를 발견했습니다. 요청과 응답 순서를 확인해 현재 검색어와 일치하는 결과만 반영하고, 연속 입력과 응답 지연 상황을 다시 검증했습니다.
이 경험은 화면을 완성했다는 결과보다 사용자 행동과 비동기 요청, 상태 변화를 연결해 이해했다는 근거가 됩니다. 프런트엔드 직무에서는 화면이 정상적으로 보이는 순간뿐 아니라 사용자가 예상과 다른 방식으로 행동했을 때의 처리도 중요합니다.
- 주문이 중복 저장된 서버 개발 사례
백엔드를 준비한 지원자는 상품 주문 API를 구현했습니다. 정상적으로 한 번 요청했을 때는 주문과 재고 감소가 문제없이 처리됐습니다. 하지만 주문 버튼을 연속으로 누르거나 네트워크 지연으로 같은 요청이 다시 전달되면 동일한 주문이 두 건 저장되는 현상이 발생했습니다.
처음에는 화면에서 주문 버튼을 비활성화하면 해결될 것이라고 생각했습니다. 그러나 사용자가 다시 누르지 않아도 네트워크 상황에 따라 요청이 반복될 수 있었고, 서버에서도 이미 처리한 주문인지 판단할 기준이 필요했습니다. 요청 로그와 데이터베이스 저장 시간을 비교하면서 같은 사용자와 상품의 요청이 짧은 간격으로 반복되는 조건을 확인했습니다.
이후 주문 요청에 식별값을 포함하고, 이미 처리한 식별값이 다시 들어오면 새로운 주문을 생성하지 않도록 수정했습니다. 클라이언트에서는 요청 중 버튼을 비활성화하되 서버에서도 반복 요청을 방어하도록 역할을 나눴습니다. 정상 주문과 연속 클릭, 응답 지연 후 재전송 상황을 각각 테스트했습니다.
- 결과 중심 설명: 주문 등록과 재고 감소 기능을 구현했습니다.
- 서버 역할이 보이는 설명: 주문 요청을 검증하고 데이터베이스 저장과 재고 처리, 오류 응답을 담당했습니다.
- 판단 과정이 담긴 설명: 화면에서 버튼을 막는 것만으로는 네트워크 재전송까지 방지하기 어렵다고 판단했습니다. 서버에서 요청 식별값을 확인해 중복 주문을 막고 정상 요청과 반복 요청을 나누어 테스트했습니다.
같은 주문 기능이라도 처리 위치에 따라 확인하는 문제가 달라집니다. 화면에서는 사용자의 반복 클릭을 제어하고 진행 상태를 안내하며, 서버에서는 같은 요청이 다시 들어오더라도 데이터가 중복 저장되지 않도록 보호해야 합니다.
- 협업에서는 API 기준을 함께 이해해야 합니다
프런트엔드와 백엔드는 API를 기준으로 자주 협업합니다. 화면 담당자는 어떤 값을 보내야 하는지와 성공 및 실패 시 어떤 응답이 오는지 알아야 합니다. 서버 담당자는 화면에서 필요한 데이터가 무엇인지 이해하고 일관된 형식으로 결과를 반환해야 합니다.
팀 프로젝트에서 존재하지 않는 게시글을 조회했을 때 서버에서는 오류를 반환했지만 화면에서는 모든 실패를 같은 문구로 안내한 사례가 있었습니다. 삭제된 게시글인지, 로그인이 필요한지, 서버가 응답하지 않는지 사용자가 구분할 수 없었습니다.
두 담당자는 실제 응답을 비교해 데이터 없음, 인증 실패, 권한 부족, 서버 오류를 나누었습니다. 공통된 오류 형식과 상태 코드를 정리하고 화면에서는 각 상황에 맞는 안내를 연결했습니다. 변경한 내용은 API 문서에 반영하고 실패 상황을 함께 테스트했습니다.
- 화면 담당자는 오류 메시지를 그대로 출력하는 데서 끝내지 않고 사용자가 다음에 무엇을 해야 하는지 판단할 수 있도록 안내해야 합니다. 로그인 화면으로 이동하거나 다시 시도할 수 있는 행동까지 고려할 필요가 있습니다.
- 서버 담당자는 같은 원인에 서로 다른 응답 형식을 사용하지 않도록 기준을 정해야 합니다. 오류 코드와 메시지, 필요한 추가 정보를 문서로 공유하면 연동 과정의 혼란을 줄일 수 있습니다.
- 협업 경험을 정리할 때는 원활하게 소통했다는 표현보다 서로 다르게 이해한 기준을 어떻게 발견하고 조정했는지를 설명하는 것이 좋습니다.
기술스택은 도구 목록보다 어떤 문제에 사용하는지 이해해야 합니다
- 화면 개발은 HTML과 CSS와 자바스크립트에서 시작합니다
프런트엔드 기술스택을 살펴보면 HTML과 CSS, 자바스크립트, 타입스크립트, 리액트, 뷰처럼 다양한 이름이 등장합니다. 처음 준비하는 사람은 어떤 프레임워크를 먼저 선택해야 하는지 고민하지만 기본은 화면의 구조와 스타일, 동작을 이해하는 것입니다.
HTML은 화면의 의미와 구조를 만들고 CSS는 배치와 크기, 색상, 반응형 화면을 담당합니다. 자바스크립트는 사용자 입력과 이벤트, 데이터 요청, 상태 변화를 처리합니다. 리액트나 뷰 같은 도구는 복잡한 화면을 구성 요소로 나누고 상태를 관리하는 데 도움을 줍니다.
- 리액트를 배웠더라도 자바스크립트의 비동기 처리와 배열 및 객체 조작을 이해하지 못하면 API 연동 오류를 추적하기 어렵습니다. 프레임워크 문법과 언어 기초를 함께 확인해야 합니다.
- CSS는 디자인을 꾸미는 용도에만 머물지 않습니다. 다양한 화면 크기와 콘텐츠 길이, 사용자 접근성을 고려해 정보가 자연스럽게 배치되도록 만들어야 합니다.
- 타입스크립트는 모든 오류를 자동으로 해결하는 도구가 아닙니다. 데이터 형식을 명확하게 표현하고 개발 과정에서 예상하지 못한 값의 사용을 줄이는 목적으로 이해하는 것이 좋습니다.
- 서버 영역은 언어와 프레임워크 외에도 데이터 흐름이 필요합니다
백엔드 기술스택에는 자바와 스프링, 자바스크립트와 Node.js, 파이썬과 Django 또는 FastAPI처럼 여러 조합이 있습니다. 어떤 조합이 무조건 취업에 유리하다고 단정하기보다 목표 공고에서 반복적으로 사용하는 환경과 학습 자료, 프로젝트 목적을 고려해야 합니다.
서버 개발은 언어와 프레임워크만으로 끝나지 않습니다. HTTP 요청과 응답, REST API, 데이터베이스, 인증과 권한, 테스트, 배포 환경을 함께 이해해야 합니다. 데이터가 어디에서 들어와 어떤 검증을 거치고 어떻게 저장되는지를 연결할 수 있어야 합니다.
- 자바와 스프링을 선택했다면 어노테이션을 외우는 데서 멈추지 말고 요청이 컨트롤러와 서비스, 데이터 접근 계층을 거쳐 처리되는 흐름을 추적해야 합니다.
- 데이터베이스는 SQL 문법만 공부하지 않고 테이블의 관계와 제약조건, 트랜잭션을 함께 살펴봐야 합니다. 잘못된 데이터가 저장되지 않도록 어느 단계에서 검증할지도 고민해야 합니다.
- 인증은 로그인 기능을 만들었다는 결과만으로 설명하기 어렵습니다. 사용자를 확인하는 과정과 권한에 따라 접근할 수 있는 기능이 달라지는 이유를 구분해야 합니다.
- 상태관리 도구부터 선택해 프로젝트가 복잡해진 사례
프런트엔드를 준비한 한 지원자는 기술스택이 많을수록 포트폴리오가 좋아 보일 것이라고 생각했습니다. 규모가 작은 일정 관리 서비스에 여러 상태관리 도구와 UI 라이브러리를 동시에 적용했습니다. 하지만 일정 목록과 선택한 일정, 입력창의 값이 서로 다른 위치에서 관리되면서 수정한 내용이 화면에 바로 반영되지 않는 문제가 생겼습니다.
처음에는 새로운 도구의 기능을 더 사용하면 해결될 것이라고 판단했습니다. 그러나 상태가 어디에서 생성되고 어떤 화면이 해당 값을 사용하는지 표시해 보니 같은 데이터가 여러 위치에 중복 저장되어 있었습니다. 서비스 규모에 비해 전역으로 관리하는 값이 지나치게 많았고, 입력 화면 안에서만 사용하는 값도 외부 저장소에 들어가 있었습니다.
이후 여러 화면이 함께 사용하는 로그인 정보와 일정 목록만 공통으로 관리하고, 입력창과 선택 상태는 해당 화면 안에서 처리했습니다. 데이터가 변경되는 경로를 단순화한 뒤 일정 등록과 수정, 화면 이동 상황을 다시 확인했습니다.
- 도구 나열형 설명: 리액트와 타입스크립트, 상태관리 라이브러리를 활용해 서비스를 제작했습니다.
- 사용 목적이 보이는 설명: 여러 화면에서 함께 사용하는 로그인 정보와 일정 목록을 공통 상태로 관리했습니다.
- 선택 근거가 담긴 설명: 화면 안에서만 사용하는 입력값까지 전역으로 관리해 상태가 중복되는 문제를 발견했습니다. 공유가 필요한 데이터와 지역 상태를 구분해 구조를 단순화하고 일정 수정과 화면 이동 상황을 다시 테스트했습니다.
기술을 많이 사용했다는 사실보다 어떤 문제를 해결하기 위해 선택했고, 사용 범위를 어떻게 조정했는지가 더 중요합니다. 포트폴리오에서도 도구의 로고를 나열하기보다 적용 위치와 선택 이유를 설명해야 합니다.
- 데이터베이스 저장 오류에서 서버 구조를 다시 본 사례
서버 개발을 준비한 지원자는 회원가입 API를 만들면서 입력값을 받은 뒤 바로 데이터베이스에 저장했습니다. 화면에서 이메일 형식을 확인하고 있었기 때문에 서버에서 같은 검증을 다시 할 필요가 없다고 생각했습니다. 그러나 API 테스트 도구로 직접 요청하면 이메일 형식이 잘못되거나 필수값이 비어 있어도 데이터가 저장됐습니다.
지원자는 처음에 화면에서 입력을 막았으니 실제 서비스에서는 문제가 발생하지 않을 것이라고 판단했습니다. 하지만 API는 화면 외의 다른 클라이언트에서도 호출할 수 있고 요청값이 항상 정상이라고 가정할 수 없었습니다. 데이터베이스에 이미 저장된 중복 이메일도 애플리케이션 조회만으로 확인하면 동시에 요청이 들어오는 상황에서 문제가 생길 수 있었습니다.
서버에서 필수값과 형식을 다시 검증하고 데이터베이스에는 이메일 중복을 막는 제약조건을 추가했습니다. 잘못된 입력, 중복 이메일, 정상 가입, 동시에 전달되는 가입 요청을 나누어 테스트했습니다. 오류 원인에 따라 응답 메시지도 다르게 반환했습니다.
- 기존 설명에서는 스프링과 데이터베이스를 사용해 회원가입 기능을 만들었다는 내용만 보였습니다. 각 기술이 데이터의 정상 상태를 어떻게 지키는지는 확인하기 어려웠습니다.
- 보완 후에는 화면 검증과 서버 검증의 역할, 애플리케이션 조회와 데이터베이스 제약조건의 차이가 나타났습니다. 하나의 방어 방법에만 의존하지 않은 이유도 설명할 수 있었습니다.
- 기술스택은 자바와 스프링, 데이터베이스라는 목록에서 요청 검증과 중복 방지, 예외 응답을 구현한 근거로 바뀌었습니다.
- 공통으로 필요한 기초도 서로 다른 위치에서 사용됩니다
두 분야 모두 자바스크립트나 HTTP, API, Git, 테스트, 배포에 대한 이해가 필요할 수 있습니다. 하지만 같은 개념을 업무에서 사용하는 위치는 다릅니다. 화면 담당자는 API를 호출하고 응답에 따라 상태를 바꾸며, 서버 담당자는 요청을 받아 처리하고 결과를 반환합니다.
Git을 사용하더라도 단순히 코드를 저장하는 도구로만 보지 말고 브랜치와 변경 이력, 충돌 해결, 코드 검토 과정을 경험해야 합니다. 테스트 역시 화면에서는 사용자 행동과 렌더링 결과를 확인하고, 서버에서는 비즈니스 로직과 API 응답, 데이터 상태를 검증하는 방식으로 달라질 수 있습니다.
처음부터 모든 기술을 완벽하게 공부할 필요는 없습니다. 목표 역할에서 자주 사용하는 기본 기술을 선택하고 작은 기능에서 적용해 본 뒤 부족한 개념으로 돌아가는 방식이 효과적입니다. 기술스택은 공부할 목록이 아니라 문제를 해결한 근거로 남아야 합니다.
직무선택은 작은 실습과 채용공고를 함께 비교해야 합니다
- 흥미보다 반복해서 개선할 수 있는 업무를 살펴봐야 합니다
화면이 바로 보인다는 이유로 프런트엔드를 선택하거나 눈에 보이지 않는 서버가 전문적으로 느껴진다는 이유로 백엔드를 고르면 실제 준비 과정에서 예상과 다른 점을 만날 수 있습니다. 직무선택은 첫인상보다 반복 업무가 자신에게 맞는지를 기준으로 해야 합니다.
화면 개발자는 디자인된 결과물을 코드로 옮기는 것뿐 아니라 입력 오류와 화면 상태, 브라우저 차이, 접근성 문제를 계속 수정합니다. 서버 개발자는 새로운 API를 만드는 것 외에도 기존 로직과 데이터 구조를 읽고 오류 로그를 확인하며 예외 상황을 처리합니다.
- 사용자 행동을 관찰하고 화면에서 바로 나타나는 변화를 조정하는 과정이 흥미롭다면 클라이언트 영역이 맞을 가능성이 있습니다. 작은 차이를 반복해서 수정하는 작업도 함께 경험해야 합니다.
- 데이터의 저장 구조와 요청 처리 순서, 인증과 권한을 설계하는 과정에 관심이 있다면 서버 영역을 검토할 수 있습니다. 화면에 보이지 않는 문제를 로그와 데이터로 추적하는 작업이 포함됩니다.
- 두 분야 모두 문제해결과 협업이 필요합니다. 디자인 감각이나 수학 실력 같은 한 가지 조건만으로 판단하기보다 실제 기능을 양쪽에서 구현해 보는 것이 좋습니다.
- 하나의 회원가입 기능으로 두 역할을 비교할 수 있습니다
직무를 결정하지 못한 준비생은 서로 다른 프로젝트를 여러 개 만들기보다 하나의 기능을 화면과 서버에서 모두 구현해 볼 수 있습니다. 회원가입 기능은 입력값과 화면 상태, API 요청, 검증, 데이터 저장, 오류 응답을 함께 경험하기에 적합합니다.
화면에서는 이름과 이메일, 비밀번호를 입력받고 잘못된 형식과 필수값 누락을 안내합니다. 요청 중에는 버튼을 비활성화하고 성공하면 다음 화면으로 이동하며 실패하면 원인에 맞는 메시지를 보여줍니다.
서버에서는 같은 입력값을 다시 검증하고 이메일 중복을 확인합니다. 비밀번호를 안전한 형태로 변환해 저장하며 정상 가입과 입력 오류, 중복 가입을 구분해 응답합니다. 데이터베이스 제약조건과 예외 처리도 확인할 수 있습니다.
- 화면 작업에서 사용자 입력과 상태 변화를 다듬는 과정에 더 몰입했다면 프런트엔드 프로젝트를 확장해 볼 수 있습니다. API 실패와 다양한 화면 크기, 접근성까지 확인하면 업무 적합성을 더 현실적으로 판단할 수 있습니다.
- 서버 작업에서 요청 흐름과 데이터 저장, 오류 응답을 설계하는 과정이 흥미로웠다면 백엔드 방향을 검토할 수 있습니다. 인증과 권한, 동시 요청, 트랜잭션으로 실습 범위를 넓힐 수 있습니다.
- 양쪽 모두 흥미롭더라도 취업 자료에서는 더 깊게 다룬 영역을 정해야 합니다. 모든 기능을 했다는 표현보다 대표적으로 해결한 문제와 검증 결과가 있는 역할을 앞에 배치하는 편이 좋습니다.
- 채용공고는 기술 이름보다 실제 업무를 먼저 확인해야 합니다
같은 프런트엔드 공고라도 기업에 따라 웹 화면 개발, 디자인 시스템, 데이터 시각화, 모바일 웹 최적화처럼 업무 비중이 달라질 수 있습니다. 백엔드 역시 API 개발, 배치 처리, 데이터 플랫폼, 사내 시스템 운영 등 주요 역할이 다를 수 있습니다.
여러 공고에서 반복되는 업무와 필수 기술을 비교하면 공부 우선순위를 정하기 쉬워집니다. 프레임워크 이름만 확인하지 말고 어떤 서비스를 만들고 누구와 협업하며 어떤 문제를 해결하는지 살펴봐야 합니다.
채용공고에서 리액트를 요구한다고 해서 프로젝트에 리액트가 포함된 것만으로 충분하지는 않습니다. 화면을 구성 요소로 나눈 기준과 상태관리, API 연동, 사용자 오류 처리를 보여줘야 합니다. 스프링을 요구하는 서버 공고도 어노테이션 사용 여부보다 요청과 비즈니스 로직, 데이터 저장과 테스트 경험이 중요합니다.
- 포트폴리오는 선택한 역할이 선명하게 보여야 합니다
팀 프로젝트에서 화면과 서버 작업을 모두 경험했더라도 지원 분야에 따라 강조점을 달리해야 합니다. 프런트엔드 지원 자료에서는 사용자 흐름과 상태 변화, API 실패 처리, 반응형 화면을 앞에 배치할 수 있습니다. 백엔드 지원 자료에는 데이터 처리와 인증, 예외 응답, 테스트 결과가 먼저 보여야 합니다.
두 분야에 같은 자료를 그대로 제출하면 자신이 어떤 역할을 희망하는지 명확해질 수 있습니다. 프로젝트를 새로 만들 필요는 없지만 대표 경험과 설명 순서를 바꿔야 합니다.
- 화면 지원용 정리: 일정 등록 과정에서 입력 검증과 로딩 상태, 중복 요청 방지, 오류 안내를 구현하고 사용자 행동별 결과를 테스트했습니다.
- 서버 지원용 정리: 일정 등록 API에서 인증과 데이터 검증, 중복 요청 방지, 데이터베이스 저장, 예외 응답을 구현하고 반복 요청을 검증했습니다.
같은 기능도 어느 문제를 깊게 다뤘는지에 따라 다른 취업 자료가 됩니다. 직무선택이 끝났다면 포트폴리오와 README, 면접 답변에서도 해당 방향이 일관되게 나타나는지 확인해야 합니다.
- conclusion
프런트엔드 백엔드 차이는 화면을 만드는 사람과 서버를 관리하는 사람이라는 구분만으로 충분히 설명되지 않습니다. 한쪽은 사용자의 입력과 화면 상태, 서비스 이용 흐름을 중심으로 기능을 구현하고, 다른 쪽은 요청 검증과 비즈니스 로직, 인증, 데이터 저장, 오류 응답을 담당합니다.
현재 자신의 선택과 준비 상태는 다음 내용을 중심으로 점검할 수 있습니다.
- 프런트엔드에 관심이 있다면 완성 화면만 만들지 말고 입력 오류, 로딩, 결과 없음, API 실패를 처리해 봐야 합니다. 사용자 행동에 따라 화면이 어떻게 달라지는지 조정하는 과정이 자신에게 맞는지도 확인해야 합니다.
- 백엔드를 희망한다면 API 목록을 늘리기보다 요청이 검증과 데이터 처리를 거쳐 저장되는 흐름을 설명할 수 있어야 합니다. 인증과 권한, 중복 요청, 예외 응답을 직접 구현하고 수정 후 결과를 검증하는 경험이 필요합니다.
- 아직 선택하지 못했다면 회원가입이나 일정 등록 같은 작은 기능을 양쪽에서 구현해 보는 것이 좋습니다. 어느 작업에서 더 집중했고, 오류가 생겼을 때 어느 영역을 계속 파고들고 싶었는지를 기록하면 판단 근거가 생깁니다.
실제 포트폴리오를 검토하면 프런트엔드 지원자가 정상 화면만 보여주거나 백엔드 지원자가 기술 이름과 API 목록만 나열해 역할이 선명하지 않은 경우가 많습니다. 기술스택보다 중요한 것은 해당 도구를 어디에 사용했고 어떤 문제를 해결했는지 보여주는 것입니다.
화면의 상태 변화와 사용자 흐름을 개선한 기록은 프런트엔드 취업 자료가 되고, 요청 처리와 데이터 일관성, 예외 대응을 검증한 기록은 백엔드 경험으로 바뀝니다. 직무는 유행하는 기술 이름으로 정하는 것이 아니라 자신이 반복해서 해결하고 싶은 문제와 프로젝트에서 확인한 행동을 기준으로 선택해야 합니다.
