개발자 취업을 준비하는 분들의 포트폴리오를 검토하다 보면 화면은 꽤 깔끔하게 만들어져 있지만, 실제 면접 답변에서는 아쉬움이 남는 경우를 자주 봅니다. 로그인 화면, 상품 목록, 게시판, 예약 페이지, 관리자 대시보드처럼 눈에 보이는 결과물은 정리되어 있는데 사용자가 어떤 흐름으로 화면을 이용하는지, 데이터가 어떤 상태로 관리되는지, API 응답이 화면에 어떻게 반영되는지 설명하지 못하는 경우가 있습니다. 모의면접에서 검색어를 입력하면 내부에서 어떤 일이 일어나나요? API 응답이 늦게 오면 화면은 어떻게 처리되나요? 사용자가 오류 상황을 어떻게 알 수 있나요? 같은 질문을 하면 답변이 짧아지는 준비생도 많습니다. 저는 이 지점이 프런트엔드 개발자 준비에서 가장 먼저 점검해야 할 부분이라고 생각합니다. 화면 구현은 시작점일 뿐이며, UX, 상태관리, API연동을 함께 설명할 수 있어야 실제 직무역량으로 보입니다.
UX를 고려해야 화면 구현이 사용자 흐름으로 바뀝니다
- 화면은 만들었지만 사용 흐름이 부족한 경우
포트폴리오를 처음 보면 가장 먼저 화면 캡처가 눈에 들어옵니다. 버튼이 있고, 카드가 정리되어 있고, 메뉴가 배치되어 있으면 프로젝트가 어느 정도 완성된 것처럼 보입니다. 하지만 화면이 예쁘게 구성되어 있다는 것과 사용자가 편하게 이용할 수 있다는 것은 다릅니다. 실제 서비스에서는 사용자가 어디를 눌러야 하는지, 입력값이 잘못되었을 때 어떤 안내를 받는지, 요청이 처리되는 동안 어떤 상태를 보는지, 결과가 없을 때 무엇을 확인하는지가 중요합니다. 이런 흐름이 빠져 있으면 화면은 만들어졌지만 UX 관점의 고민은 부족해 보일 수 있습니다.
실제 모의면접에서 프로젝트 화면을 보며 질문해 보면 이 차이가 분명하게 드러납니다. 어떤 준비생은 상품 목록 화면을 만들었다고 설명하지만, 검색 결과가 없을 때 어떤 화면이 나오는지 답하지 못합니다. 로그인 실패 시 어떤 메시지를 보여주는지, 필수 입력값이 비어 있을 때 어떻게 안내하는지, 서버 요청이 지연될 때 사용자가 기다리고 있음을 알 수 있는지 설명하지 못하는 경우도 있습니다. 저는 이런 장면을 볼 때 화면 구현 자체보다 사용자 상황을 얼마나 고려했는지가 더 중요하다고 느낍니다.
- 화면 중심 설명은 직무역량을 충분히 보여주기 어렵습니다
프런트엔드 직무는 단순히 화면을 그리는 역할만 하지 않습니다. 사용자가 화면에서 어떤 행동을 하고, 그 행동이 상태 변화와 데이터 요청으로 이어지며, 그 결과가 다시 화면에 어떻게 표현되는지를 다루는 역할입니다. 그래서 포트폴리오에서도 버튼을 만들었다는 설명보다 버튼을 눌렀을 때 어떤 상태가 바뀌고, 어떤 요청이 발생하며, 성공과 실패에 따라 어떤 화면을 보여주었는지를 설명하는 것이 더 중요합니다. 화면 구현만 강조하면 HTML과 CSS 중심의 결과물처럼 보일 수 있지만, UX 흐름까지 설명하면 서비스 개발 관점이 드러납니다.
- UX 설명은 사용자 행동을 기준으로 정리하는 것이 좋습니다. 예를 들어 검색 기능을 만들었다면 검색창을 만들었습니다라고 끝내지 말고, 사용자가 검색어를 입력하고 버튼을 누르면 검색 조건을 기준으로 목록을 다시 불러오며, 결과가 없을 경우 안내 메시지를 보여주도록 구성했다고 설명해야 합니다. 이 문장은 화면 요소보다 사용자 흐름을 보여줍니다. 저는 포트폴리오에서 이런 흐름이 보이면 지원자가 단순히 화면을 만든 것이 아니라 실제 사용 상황을 고민했다고 판단합니다.
- 오류 상황과 빈 상태도 UX의 일부입니다. 정상적으로 데이터가 나오는 화면만 보여주면 프로젝트가 완성되어 보일 수 있습니다. 하지만 실제 서비스에서는 로그인 실패, 검색 결과 없음, 서버 오류, 입력값 누락, 로딩 지연 같은 상황이 자주 발생합니다. 이런 상황을 어떻게 안내했는지 정리하면 포트폴리오의 깊이가 달라집니다. 예를 들어 API 요청 실패 시 다시 시도 안내를 보여주거나, 입력값이 비어 있을 때 버튼을 비활성화하는 방식은 작은 구현처럼 보여도 사용자 경험을 고려한 중요한 작업입니다.
- UX 관점이 강해지는 실제 사례
예를 들어 예약 신청 화면을 만들었다고 해보겠습니다. 약한 설명은 예약 신청 페이지를 구현했습니다입니다. 조금 더 나은 설명은 사용자가 날짜와 시간을 선택해 예약할 수 있는 화면을 만들었습니다입니다. 하지만 취업용 포트폴리오에서는 더 구체적으로 정리해야 합니다. 사용자가 날짜를 선택하면 해당 날짜의 예약 가능 시간만 보여주고, 이미 마감된 시간은 선택할 수 없도록 비활성화했으며, 예약 성공 시 완료 메시지를 보여주고 실패 시 원인을 안내하도록 처리했다고 설명하는 것이 좋습니다.
쇼핑몰 상품 목록 화면도 마찬가지입니다. 상품 카드를 예쁘게 배치했다는 설명만으로는 부족합니다. 사용자가 카테고리를 선택하거나 검색어를 입력했을 때 목록이 어떻게 바뀌는지, 로딩 중에는 어떤 표시가 나오는지, 결과가 없을 때 어떤 문구를 보여주는지, 서버 오류가 발생했을 때 어떻게 안내하는지 정리해야 합니다. 저는 이런 설명이 있는 포트폴리오를 보면 화면 구현을 넘어 실제 사용자 흐름을 고려한 결과물로 보입니다.
- UX를 포트폴리오에 정리하는 방법
포트폴리오에는 모든 UX 요소를 길게 설명할 필요는 없습니다. 핵심 기능별로 사용자 행동, 화면 반응, 예외 상황을 간단히 정리하면 충분합니다. 예를 들어 로그인 기능이라면 사용자가 이메일과 비밀번호를 입력하고, 로그인 버튼을 누르면 서버에 인증 요청을 보내며, 성공 시 메인 화면으로 이동하고, 실패 시 오류 메시지를 보여주었다고 쓸 수 있습니다. 여기에 입력값이 비어 있을 때 버튼 비활성화나 안내 메시지를 추가했다면 더 좋습니다.
저는 준비생들에게 화면 캡처 아래에 기능 설명만 적지 말고 사용자 흐름을 함께 적으라고 권합니다. 화면이 무엇을 보여주는지보다 사용자가 그 화면에서 무엇을 하고, 시스템이 어떻게 반응하는지가 중요합니다. 이렇게 정리하면 면접에서도 답변이 달라집니다. 화면을 만들었습니다가 아니라 사용자가 어떤 행동을 했을 때 어떤 상태와 화면으로 이어지도록 구성했습니다라고 말할 수 있기 때문입니다. UX를 고려한 설명은 화면 구현을 직무역량으로 바꾸는 중요한 기준입니다.
상태관리를 이해해야 화면 변화와 데이터 흐름을 설명할 수 있습니다
- 상태가 바뀌는 흐름을 설명하지 못하는 경우
프런트엔드 포트폴리오에서 자주 보이는 아쉬운 부분 중 하나는 상태관리에 대한 설명이 부족하다는 점입니다. 화면은 정상적으로 동작하지만 내부에서 어떤 값이 바뀌고, 그 값이 어떤 조건으로 화면을 다시 그리게 하는지 설명하지 못하는 경우가 있습니다. 특히 React 프로젝트를 했다고 적었지만 useState를 어디에 사용했는지, 상태가 바뀌면 어떤 컴포넌트가 다시 렌더링 되는지, 검색어나 선택값을 어떻게 관리했는지 답변이 약한 경우가 많습니다. 저는 이 부분이 화면 개발 직무 준비에서 매우 중요한 차이라고 생각합니다.
모의면접에서 검색 기능을 예로 들어 질문해 보면 차이가 잘 드러납니다. 검색창을 만들었다고 말할 수는 있지만 검색어 입력값이 어디에 저장되는지, 버튼을 눌렀을 때 어떤 값으로 API 요청을 보내는지, 응답을 받은 뒤 목록 데이터는 어떤 상태로 관리되는지 설명하지 못하면 구현 이해도가 약해 보입니다. 화면은 결과이고 상태는 그 결과를 바꾸는 기준입니다. 상태 흐름을 설명할 수 있어야 화면이 왜 그렇게 변하는지 말할 수 있습니다.
- 상태관리가 약하면 화면 구현이 우연처럼 보일 수 있습니다
프런트엔드 개발에서 상태는 사용자의 행동과 화면 변화를 연결합니다. 검색어, 선택된 카테고리, 로그인 여부, 장바구니 수량, 모달 열림 여부, 로딩 여부, 오류 메시지, API 응답 데이터는 모두 상태가 될 수 있습니다. 이 값들이 어떻게 바뀌고 어떤 화면에 영향을 주는지 이해해야 합니다. 상태관리를 제대로 설명하지 못하면 프로젝트가 동작하더라도 왜 동작하는지 모르는 것처럼 보일 수 있습니다. 취업 준비에서는 단순히 돌아가는 화면보다 동작 원리를 말하는 능력이 중요합니다.
- 상태관리는 사용자 입력값과 화면 반응을 연결해 설명해야 합니다. 예를 들어 상품 검색 화면에서는 사용자가 입력한 검색어를 상태로 저장하고, 검색 버튼을 누를 때 해당 값을 기준으로 API 요청을 보낸 뒤, 응답 데이터를 목록 상태에 저장해 카드 화면을 다시 렌더링 했다고 설명할 수 있습니다. 이 설명은 검색창, 버튼, 목록 화면을 하나의 흐름으로 연결합니다. 저는 이런 답변이 나오는 지원자를 보면 React를 단순 문법이 아니라 화면 변화의 구조로 이해하려고 했다는 인상을 받습니다.
- 로딩 상태와 오류 상태도 중요한 상태관리 대상입니다. 많은 준비생이 성공 응답 데이터만 상태로 관리합니다. 하지만 실제 서비스에서는 요청 중인지, 실패했는지, 결과가 없는지에 따라 화면이 달라져야 합니다. 예를 들어 데이터를 불러오는 동안 로딩 문구를 보여주고, 실패하면 오류 안내를 보여주며, 결과가 없으면 빈 상태 화면을 보여주는 방식입니다. 이런 상태 구분은 작은 구현처럼 보이지만 사용자 경험과 코드 구조를 함께 보여주는 중요한 요소입니다.
- 상태관리 설명이 강해지는 실제 사례
예를 들어 Todo List 프로젝트를 만들었다고 해보겠습니다. 약한 설명은 할 일 추가와 삭제 기능을 만들었습니다입니다. 조금 더 나은 설명은 React 상태를 사용해 목록을 관리했습니다입니다. 하지만 더 좋은 설명은 사용자가 입력한 할 일 내용을 input 상태로 관리하고, 추가 버튼을 누르면 기존 목록 상태에 새 항목을 추가했으며, 완료 버튼을 누르면 해당 항목의 완료 상태만 변경되도록 처리했습니다. 또한 전체, 진행 중, 완료 필터를 선택하면 필터 상태에 따라 목록을 다르게 보여주도록 구성했습니다라고 정리하는 것입니다.
상품 목록 프로젝트에서도 상태관리 설명은 중요합니다. 검색어 상태, 선택된 카테고리 상태, 상품 목록 상태, 로딩 상태, 오류 상태를 나누어 관리했다고 설명할 수 있습니다. 처음에는 API 응답이 오기 전 빈 목록이 그대로 보여 사용자가 데이터가 없는 것처럼 느낄 수 있었고, 이후 요청 중에는 로딩 상태를 보여주도록 개선했다고 적으면 더 좋습니다. 저는 이런 설명이 들어간 포트폴리오를 보면 화면 변화의 원리를 이해한 준비생으로 보게 됩니다.
- 상태관리를 면접 답변으로 준비하는 방법
상태관리를 정리할 때는 프로젝트의 핵심 화면 하나를 골라 어떤 상태가 필요한지 적어보는 것이 좋습니다. 예를 들어 로그인 화면이라면 이메일 입력값, 비밀번호 입력값, 로그인 요청 중 상태, 오류 메시지, 로그인 성공 여부가 있을 수 있습니다. 상품 목록 화면이라면 검색어, 카테고리, 목록 데이터, 로딩 여부, 오류 여부, 결과 없음 여부가 있을 수 있습니다. 이렇게 상태를 나누어보면 화면이 어떻게 변하는지 설명하기 쉬워집니다.
저는 준비생들에게 상태를 단순 변수로만 보지 말고 화면의 기준으로 보라고 말합니다. 어떤 상태가 바뀌면 어떤 화면이 바뀌는지 연결해야 합니다. 이 연결이 정리되면 면접에서 상태관리를 설명할 때 훨씬 구체적으로 답할 수 있습니다. 특히 React를 사용했다면 어떤 값을 useState로 관리했는지, 상위 컴포넌트와 하위 컴포넌트 사이에 데이터를 어떻게 전달했는지, 상태가 복잡해졌을 때 어떤 점이 어려웠는지 정리해 두는 것이 좋습니다. 상태관리는 화면 구현을 실제 동작 원리로 설명하게 만드는 핵심입니다.
API연동을 설명할 수 있어야 서비스 흐름을 이해한 것으로 보입니다
- API를 연결했다는 말에서 끝나는 경우
프런트엔드 개발자 준비에서 API연동은 매우 중요한 평가 포인트입니다. 하지만 포트폴리오를 보면 API를 연결했습니다, 서버에서 데이터를 받아왔습니다 정도로만 적혀 있는 경우가 많습니다. 이 설명만으로는 충분하지 않습니다. 어떤 시점에 요청을 보냈는지, 어떤 값을 요청에 포함했는지, 응답 데이터 구조는 어떻게 확인했는지, 응답 성공과 실패를 어떻게 처리했는지, 화면에는 어떤 방식으로 반영했는지 설명해야 합니다. API연동은 단순 연결 작업이 아니라 화면과 서버를 이어주는 과정입니다.
실제 모의면접에서 API연동 질문을 하면 준비생들이 가장 많이 막히는 부분이 응답 구조입니다. 서버에서 어떤 형태로 데이터가 내려왔는지 정확히 기억하지 못하거나, 왜 화면에 데이터가 나오지 않았는지 원인을 설명하지 못하는 경우가 있습니다. 프런트엔드 직무에서는 서버를 직접 만들지 않더라도 요청과 응답의 구조를 이해해야 합니다. 사용자가 버튼을 누른 뒤 서버로 어떤 요청이 가고, 서버가 어떤 응답을 주며, 그 결과가 화면에 어떻게 표시되는지 설명할 수 있어야 합니다.
- API연동은 화면과 서버 사이의 약속입니다
API연동은 단순히 주소를 호출하는 일이 아닙니다. 프런트엔드와 백엔드 사이의 약속을 맞추는 작업입니다. 어떤 URL로 요청을 보낼지, 어떤 메서드를 사용할지, 어떤 요청 값을 전달할지, 응답 데이터의 필드명은 무엇인지, 실패 응답은 어떤 형태인지 알아야 합니다. 이 약속이 맞지 않으면 화면에 데이터가 표시되지 않거나, 사용자가 올바른 안내를 받지 못할 수 있습니다. 그래서 API연동 경험은 기술면접에서 자주 확인되는 부분입니다.
- API연동은 요청 조건과 응답 처리로 나누어 설명해야 합니다. 예를 들어 게시글 목록 화면에서는 페이지 번호와 검색어를 요청 파라미터로 보내고, 서버에서 받은 게시글 배열을 목록 상태에 저장한 뒤 카드 형태로 렌더링 했다고 설명할 수 있습니다. 로그인 기능에서는 이메일과 비밀번호를 서버로 보내고, 성공 응답을 받으면 사용자 정보를 저장한 뒤 화면을 이동시켰으며, 실패 응답이 오면 오류 메시지를 보여주었다고 말할 수 있습니다. 이런 설명이 있어야 단순 연결이 아니라 서비스 흐름으로 보입니다.
- API 실패 상황도 반드시 정리해야 합니다. 실제 프로젝트에서는 서버가 항상 정상 응답을 주지 않습니다. 네트워크 오류, 인증 실패, 권한 없음, 입력값 오류, 서버 내부 오류가 발생할 수 있습니다. 프런트엔드에서는 이런 실패 상황을 사용자가 이해할 수 있는 화면으로 바꾸어야 합니다. 저는 실패 응답 처리 경험이 정리된 포트폴리오를 보면 지원자가 실제 서비스 환경을 조금 더 현실적으로 생각했다고 느낍니다.
- API연동 설명이 강해지는 실제 사례
예를 들어 로그인 기능을 구현했다고 해보겠습니다. 약한 설명은 로그인 API를 연결했습니다입니다. 조금 더 나은 설명은 이메일과 비밀번호를 서버에 보내 로그인 결과를 받았습니다입니다. 하지만 더 좋은 설명은 사용자가 이메일과 비밀번호를 입력한 뒤 로그인 버튼을 누르면 해당 값을 서버로 전송하고, 성공 응답을 받으면 사용자 정보를 저장한 뒤 메인 화면으로 이동하도록 처리했습니다. 실패 응답이 오면 서버에서 받은 메시지를 기준으로 이메일 또는 비밀번호 오류 안내를 보여주었습니다라고 정리하는 것입니다.
상품 목록 API도 좋은 사례입니다. 처음에는 상품 목록 요청은 성공했지만 화면에 데이터가 보이지 않았다고 해보겠습니다. 이때 응답 데이터가 배열로 바로 내려오는 줄 알았지만 실제로는 data.items 안에 배열이 들어 있었고, 화면에서는 잘못된 경로를 참조하고 있었다고 설명할 수 있습니다. 네트워크 탭에서 응답 구조를 확인하고 렌더링 코드를 수정했으며, 이후 README에 응답 예시를 남겼다고 정리하면 문제해결 과정까지 포함됩니다. 저는 이런 설명이 있는 지원자를 보면 API연동을 단순 복사 구현이 아니라 실제 흐름으로 이해했다고 봅니다.
- API연동을 포트폴리오와 면접에 연결하는 방법
API연동 경험을 정리할 때는 핵심 기능별로 요청 시점, 요청 값, 응답 구조, 화면 반영, 실패 처리, 어려웠던 점을 나누어 적는 것이 좋습니다. 예를 들어 검색 기능이라면 사용자가 검색 버튼을 누르는 시점에 요청을 보냈는지, 검색어와 카테고리 값을 어떤 방식으로 전달했는지, 응답 목록을 어떤 상태에 저장했는지, 결과 없음 상태는 어떻게 보여주었는지 정리할 수 있습니다. 이 구조는 포트폴리오와 README에도 활용할 수 있고, 면접 답변으로도 바로 연결됩니다.
저는 프런트엔드 준비생들에게 API 명세를 그냥 참고만 하지 말고 자신의 말로 다시 정리하라고 권합니다. 요청 값과 응답 예시를 README에 남기고, 실제 프로젝트에서 어떤 화면과 연결되는지 적어두면 좋습니다. 특히 팀 프로젝트에서는 프런트엔드와 백엔드가 응답 필드명을 다르게 이해해 오류가 생기는 경우가 많기 때문에 API 문서화 경험도 좋은 강점이 될 수 있습니다. API연동을 설명할 수 있어야 화면 뒤에서 데이터가 어떻게 움직이는지 이해한 지원자로 보입니다.
- conclusion
프런트엔드 개발자 준비에서 화면 구현만으로 부족한 이유는 화면이 결과를 보여주기는 하지만, 사용자가 어떻게 이용하는지, 내부 상태가 어떻게 바뀌는지, 서버 데이터가 어떻게 연결되는지는 따로 설명해야 하기 때문입니다. UX는 사용자 흐름과 예외 상황을 보여주고, 상태관리는 화면 변화의 기준을 설명하며, API연동은 화면과 서버가 데이터를 주고받는 과정을 보여줍니다. 지금 포트폴리오를 준비하고 있다면 화면 캡처만 정리하지 말고, 사용자의 행동, 상태 변화, 요청과 응답 흐름, 실패 상황 처리까지 함께 정리해야 합니다. 제가 여러 포트폴리오와 모의면접 답변을 보면서 느낀 것은 화면이 예쁜 지원자보다 화면이 왜 그렇게 동작하는지 설명할 수 있는 지원자가 더 강하게 기억된다는 점입니다. 프런트엔드 취업 준비는 보이는 화면을 만드는 것에서 시작하지만, 실제 평가는 그 화면이 사용자와 데이터 흐름 속에서 어떻게 동작하는지를 설명하는 데서 갈립니다.
