일정 관리 서비스를 만든 프런트엔드 취업 준비생의 포트폴리오를 검토한 적이 있습니다. 결과물에는 로그인, 일정 등록, 달력 조회, 마이페이지 화면이 정돈돼 있었고 React와 상태관리 도구를 사용했다는 설명도 포함돼 있었습니다. 하지만 사용자가 로그인을 하지 않은 채 일정 페이지 주소로 바로 접속하면 어떻게 되는지, 저장 요청 중 버튼을 다시 누르면 어떤 일이 발생하는지, 서버 오류가 발생하면 입력한 내용이 유지되는지는 알기 어려웠습니다. 화면은 완성돼 있었지만 실제 사용 과정과 실패 상황이 자료에서 보이지 않았습니다.
코드를 다시 확인하자 일정 저장 버튼을 빠르게 누르면 동일한 요청이 두 번 전달됐고, API가 실패하면 사용자가 입력한 제목과 날짜가 모두 초기화되는 문제가 있었습니다. 요청 중에는 버튼을 비활성화하고 처리 상태를 표시했으며, 실패한 경우 입력값을 유지한 채 다시 시도할 수 있도록 수정했습니다. 로그인하지 않은 사용자가 보호된 주소로 접근하면 로그인 후 원래 화면으로 돌아오도록 이동 과정도 정리했습니다. 같은 프로젝트였지만 화면 목록 중심의 설명이 사용자 행동과 상태 변화, API 처리 경험을 보여주는 취업 자료로 바뀌었습니다. 프런트엔드 프로젝트는 예쁜 화면을 보여주는 데서 끝나지 않고 사용자가 서비스를 이용하는 전체 과정과 그 과정에서 내린 판단을 전달해야 합니다.
화면흐름은 페이지 목록보다 사용자의 이동 과정으로 보여줘야 합니다
- 핵심 사용자가 어디에서 시작하고 끝나는지 정해야 합니다
포트폴리오에 로그인 화면, 목록 화면, 상세 화면, 마이페이지를 각각 캡처하면 제작한 페이지 수는 알 수 있습니다. 그러나 사용자가 어떤 목적을 가지고 들어와 어느 순서로 이동하며 최종 행동을 완료하는지는 확인하기 어렵습니다. 핵심 흐름을 하나 정하고 시작부터 완료까지 연결해서 보여줘야 합니다.
채용공고 저장 서비스를 예로 들면 사용자는 로그인한 뒤 공고를 검색하고 상세 내용을 확인하며 관심 목록에 저장할 수 있습니다. 이후 마이페이지에서 저장한 공고를 다시 보고 지원 상태를 변경합니다. 이 과정에서 검색 결과가 없을 때, 저장 요청이 실패했을 때, 로그인 정보가 만료됐을 때의 이동도 함께 고려해야 합니다.
- 페이지 중심 설명: 로그인, 공고 검색, 상세 조회와 마이페이지를 구현했습니다.
- 사용 과정이 보이는 설명: 사용자가 조건에 맞는 채용공고를 검색하고 상세 화면에서 관심 공고로 저장한 뒤 마이페이지에서 지원 상태를 관리하도록 흐름을 구성했습니다. 검색 결과가 없거나 저장 요청이 실패한 경우에도 현재 검색 조건과 입력 상태가 유지되도록 처리했습니다.
두 번째 설명에는 화면 개수보다 사용자의 목적과 상태 변화가 담겨 있습니다. 면접에서는 이 흐름을 기준으로 라우팅, 전역 상태, API 요청과 오류 대응을 이어서 설명할 수 있습니다.
- 정상 화면 사이에 로딩과 빈 결과가 포함돼야 합니다
프런트엔드 작업을 정리할 때 데이터가 이미 준비된 화면만 캡처하는 경우가 많습니다. 실제 사용자는 API 응답을 기다리거나 검색 결과가 없고, 네트워크 오류가 발생하는 상황도 경험합니다. 이러한 중간 상태를 어떻게 설계했는지가 사용자 관점과 비동기 처리 역량을 보여줍니다.
상품 목록 화면을 만든 지원자는 데이터를 불러오는 동안 빈 화면을 표시했습니다. 사용자는 상품이 없는 것인지 아직 요청이 처리 중인지 알 수 없었습니다. 지원자는 로딩 상태에는 화면 구조를 예상할 수 있는 표시를 보여주고, 정상적으로 요청했지만 결과가 없을 때는 검색 조건을 바꿀 수 있는 안내를 제공했습니다. 서버 오류에는 다시 시도하는 동작을 추가했습니다.
- 로딩 상태는 단순한 회전 아이콘보다 사용자가 무엇을 기다리는지 알 수 있도록 구성할 수 있습니다. 목록 구조를 미리 보여주거나 요청 중인 버튼의 상태를 바꾸는 방법을 고려합니다.
- 빈 결과는 오류와 구분해야 합니다. 정상 응답이지만 데이터가 없는 경우에는 조건을 변경하거나 첫 데이터를 등록할 수 있는 다음 행동을 안내합니다.
- 오류 상태에는 실패했다는 문구만 보여주지 말고 사용자가 다시 시도하거나 이전 화면으로 이동할 수 있는 선택을 제공하는 것이 좋습니다.
이 세 상태를 구분하면 데이터를 화면에 출력했다는 설명에서 사용 과정 전체를 설계했다는 경험으로 발전합니다.
- 직접 주소로 접근하는 상황도 확인해야 합니다
사용자는 개발자가 예상한 버튼 순서로만 이동하지 않습니다. 즐겨찾기 한 주소로 바로 들어가거나 로그인하지 않은 상태에서 보호된 페이지를 열 수 있습니다. 새로고침 하면 메모리에 있던 상태가 사라질 수도 있습니다.
한 지원자의 마이페이지는 목록 화면을 거쳐야만 정상적으로 열렸습니다. 목록에서 선택한 사용자 정보가 메모리에 있을 때만 화면을 구성했기 때문에 새로고침하거나 주소를 직접 입력하면 오류가 발생했습니다. URL에서 필요한 식별자를 확인하고 API로 데이터를 다시 가져오도록 수정했으며, 권한이 없는 요청에는 안내 화면을 표시했습니다.
이 사례는 라우팅 라이브러리를 사용했다는 정보보다 URL과 화면 상태, 인증 정보가 어떻게 연결되는지 이해한 근거가 됩니다. 뒤로 가기와 새로고침, 직접 접근을 테스트한 결과를 함께 정리하면 후속 질문에도 대응하기 쉽습니다.
- 반응형 화면은 크기 조정 이상의 경험입니다
모바일 화면을 만들었다는 설명도 단순히 요소의 폭을 줄였다는 의미로 끝날 수 있습니다. 작은 화면에서 정보의 우선순위가 어떻게 달라지는지, 터치 영역과 키보드가 입력을 방해하지 않는지 확인해야 합니다.
예약 화면에서 날짜와 시간 선택 영역이 모바일 키보드에 가려져 저장 버튼을 누르기 어려운 문제가 있었습니다. 지원자는 입력 영역의 배치와 스크롤 위치를 조정하고 주요 동작 버튼이 화면 아래에서 접근 가능하도록 수정했습니다. 긴 오류 메시지가 레이아웃을 밀어내는 상황도 함께 점검했습니다.
화면 크기를 여러 단계로 줄여 보는 것뿐 아니라 실제 모바일 기기에서 입력, 스크롤, 뒤로 가기와 회전을 확인해야 합니다. 반응형 결과는 데스크톱 화면의 축소판이 아니라 다른 사용 환경에 맞춘 흐름으로 설명할 수 있습니다.
사용자경험은 디자인 취향보다 불편을 발견하고 개선한 근거입니다
- 입력 검증은 오류가 난 뒤보다 행동 중에 필요합니다
회원가입이나 결제 화면에서 저장 버튼을 누른 뒤 모든 오류를 한꺼번에 보여주면 사용자는 어느 항목부터 수정해야 하는지 혼란을 느낄 수 있습니다. 반대로 입력할 때마다 지나치게 빠르게 오류를 표시하면 아직 작성 중인 사용자에게 불필요한 경고를 줄 수 있습니다.
한 프런트엔드 지원자는 비밀번호 입력을 시작하자마자 조건을 충족하지 않았다는 붉은 문구를 표시했습니다. 사용자 테스트에서 아직 입력 중인데 실패로 보인다는 의견이 나왔습니다. 이후 입력창을 벗어났을 때 조건을 확인하고, 제출 시에는 누락된 항목으로 이동하도록 방식을 조정했습니다.
- 초기 설명: 회원가입 화면에 입력값 검증을 적용했습니다.
- 개선 근거가 보이는 설명: 비밀번호를 입력하는 순간부터 오류가 표시돼 사용자가 실패로 인식하는 문제를 확인했습니다. 입력창을 벗어나거나 제출할 때 검증하도록 시점을 조정하고 조건별 안내 문구를 나누어 다시 테스트했습니다.
검증 로직의 존재보다 사용자가 언제 어떤 안내를 받는지 고민한 과정이 더 중요한 취업 사례가 됩니다.
- 실패 후 사용자의 작업을 보존해야 합니다
긴 글이나 여러 입력값을 작성한 뒤 요청에 실패했는데 내용이 모두 사라지면 사용자는 같은 작업을 반복해야 합니다. 서버 오류를 막을 수 없더라도 클라이언트에서 작성 상태를 유지하고 재시도할 수 있도록 설계할 수 있습니다.
커뮤니티 게시글 작성 화면을 만든 지원자는 저장 요청이 실패하면 목록으로 이동하도록 구현했습니다. 사용자는 작성한 제목과 내용이 모두 사라졌고 실패 이유도 알 수 없었습니다. 지원자는 성공 응답을 받은 경우에만 목록으로 이동하고, 실패하면 입력값을 유지하며 다시 시도할 수 있도록 수정했습니다.
- 요청이 성공하기 전에 입력 상태를 초기화하지 않아야 합니다. 서버 응답과 화면 이동의 순서를 확인하면 작성 내용이 사라지는 문제를 줄일 수 있습니다.
- 중복 제출을 막기 위해 요청 중 버튼을 비활성화할 수 있지만 네트워크가 오래 지연될 때의 안내와 다시 시도할 조건도 필요합니다.
- 실패 메시지는 서버 문구를 그대로 노출하기보다 사용자가 할 수 있는 다음 행동을 안내해야 합니다. 입력 수정, 재시도, 로그인과 문의 가운데 상황에 맞는 동작을 제시합니다.
이러한 처리는 화려한 화면 효과보다 서비스 사용을 계속할 수 있게 만드는 실질적인 경험입니다.
- 접근성은 별도의 기능이 아니라 사용 범위를 넓히는 기준입니다
버튼과 입력창이 화면에 보인다고 모든 사용자가 같은 방식으로 이용할 수 있는 것은 아닙니다. 키보드만 사용하는 사람, 화면 읽기 도구를 사용하는 사람, 색상 차이를 구분하기 어려운 사람도 고려해야 합니다.
모달 창을 구현한 지원자는 마우스로는 정상적으로 닫을 수 있었지만 키보드로 이동하면 모달 뒤의 버튼까지 선택되는 문제가 있었습니다. 모달이 열릴 때 초점을 내부로 이동하고 닫은 뒤에는 원래 버튼으로 돌아가도록 수정했습니다. 키보드의 Esc 키로 닫을 수 있는 동작도 추가했습니다.
입력 오류를 붉은 테두리만으로 표시했던 화면에는 문구와 관련 입력을 연결했습니다. 이미지에는 의미에 맞는 대체 설명을 넣고 장식용 이미지는 읽기 대상에서 제외했습니다. 접근성 관련 도구를 사용했다는 사실보다 어떤 사용 장벽을 발견하고 수정했는지를 보여주는 것이 중요합니다.
- 사용자 피드백은 관찰한 행동을 기준으로 정리해야 합니다
친구에게 사용해 달라고 요청하고 괜찮다는 말을 들었다는 정도로는 개선 근거가 부족합니다. 사용자가 어느 단계에서 멈췄는지, 버튼의 의미를 잘못 이해했는지, 예상과 다른 경로로 이동했는지를 관찰해야 합니다.
할 일 관리 서비스에서 원형 체크 버튼을 삭제 기능으로 오해한 사용자가 있었습니다. 제작자는 완료 표시라고 생각했지만 아이콘만으로 의미가 전달되지 않았습니다. 버튼에 명확한 설명을 추가하고 완료된 항목이 다른 영역으로 이동하도록 변경했습니다. 실수로 완료한 항목을 되돌릴 수 있는 동작도 제공했습니다.
사용자 한 명의 의견을 무조건 정답으로 반영할 필요는 없습니다. 같은 혼란이 반복되는지 확인하고 서비스의 목적과 구현 비용을 함께 고려해야 합니다. 포트폴리오에는 피드백 수보다 관찰한 문제와 채택한 이유, 수정 결과를 중심으로 정리하는 편이 좋습니다.
API연동은 데이터 출력보다 요청 상태와 협업 구조를 설명해야 합니다
- 요청과 응답의 계약을 이해해야 합니다
외부 또는 백엔드 API를 호출해 데이터를 화면에 표시했다는 설명은 기본적인 결과만 보여줍니다. 어떤 요청값을 보냈고 응답 데이터를 화면 상태로 어떻게 변환했는지, 실패 상태를 어떤 기준으로 구분했는지를 설명해야 합니다.
주문 화면에서 프런트엔드는 상품 ID와 수량을 전달했지만 백엔드는 사용자 ID도 요청 본문에 포함하기를 요구한 사례가 있었습니다. 지원자는 로그인한 사용자 정보에서 ID를 가져와 전달했지만, 클라이언트가 보낸 사용자 ID를 서버가 그대로 신뢰하면 다른 사용자로 요청할 가능성이 있다는 문제가 있었습니다.
팀은 인증 정보에서 사용자를 확인하고 클라이언트는 상품과 수량만 전달하도록 요청 구조를 조정했습니다. 프런트엔드 지원자는 서버 보안 전체를 구현한 것은 아니지만 API 계약의 문제를 발견하고 백엔드 담당자와 수정한 협업 경험을 설명할 수 있었습니다.
- 비동기 응답의 순서가 화면 결과에 영향을 줍니다
검색어가 바뀔 때마다 요청을 보내는 화면에서는 먼저 보낸 요청의 응답이 나중에 도착할 수 있습니다. 응답 순서를 고려하지 않으면 사용자가 마지막에 입력한 검색어와 다른 결과가 표시됩니다.
채용공고 검색 화면에서 개발자가 서울을 입력한 뒤 빠르게 부산으로 바꾸자 서울 요청이 늦게 도착해 부산 결과를 덮어쓰는 현상이 발생했습니다. 처음에는 상태관리 도구의 문제라고 예상했지만 네트워크 탭에서 요청과 응답 시간을 비교해 순서가 바뀌는 것을 확인했습니다.
이전 요청을 취소하거나 최신 요청에 해당하는 응답만 반영하도록 수정한 뒤 응답 지연 시간을 다르게 설정해 재검증했습니다.
- 결과만 말한 설명: 검색 API를 연동하고 지역별 결과를 화면에 표시했습니다.
- 원인 추적이 담긴 설명: 검색어를 빠르게 바꾸면 이전 요청의 늦은 응답이 최신 결과를 덮는 현상을 재현했습니다. 네트워크 탭에서 응답 순서를 확인하고 최신 요청만 화면에 반영한 뒤 지연 조건을 바꾸어 다시 테스트했습니다.
이 사례는 API 호출 횟수보다 비동기 흐름을 이해하고 화면 상태를 보호한 능력을 보여줍니다.
- 상태 코드와 업무 오류를 화면 행동으로 바꿔야 합니다
모든 실패를 같은 알림으로 처리하면 사용자가 무엇을 해야 하는지 알기 어렵습니다. 인증이 만료된 경우에는 다시 로그인해야 하고, 입력값이 잘못됐다면 해당 항목을 수정해야 합니다. 서버의 일시적인 문제라면 현재 내용을 유지하고 재시도할 수 있어야 합니다.
한 지원자의 마이페이지에서는 인증 만료와 서버 오류가 모두 데이터를 불러올 수 없다는 문구로 표시됐습니다. 이후 인증 실패에는 로그인 화면으로 이동하되 현재 주소를 보존했고, 서버 오류에는 현재 화면에서 다시 요청할 수 있는 버튼을 제공했습니다. 데이터가 없는 정상 응답은 첫 항목을 등록하도록 안내했습니다.
- 상태 코드를 그대로 사용자에게 보여주기보다 화면에서 필요한 행동으로 변환해야 합니다. 로그인, 입력 수정, 재시도와 빈 결과 안내를 상황에 맞게 구분합니다.
- 서버의 오류 메시지가 화면 요구와 맞지 않는다면 백엔드 개발자와 공통 코드를 논의할 수 있습니다. 클라이언트에서 문구만 임의로 비교하면 응답이 바뀔 때 쉽게 깨질 수 있습니다.
- 오류 처리 기준은 여러 화면에서 일관돼야 합니다. 회원가입, 로그인, 마이페이지가 서로 다른 방식으로 같은 실패를 처리한다면 공통 로직을 검토할 수 있습니다.
- 중복 요청은 화면 제어와 서버 처리를 함께 봐야 합니다
결제나 예약 버튼을 여러 번 누르는 문제는 프런트엔드에서 요청 중 버튼을 비활성화해 줄일 수 있습니다. 그러나 네트워크 재전송이나 직접적인 API 호출까지 완전히 막는 것은 아닙니다. 화면 처리의 목적과 서버가 보장해야 할 범위를 구분해야 합니다.
예약 서비스에서 지원자는 버튼을 비활성화하고 로딩 문구를 표시했습니다. 백엔드 담당자는 동일한 사용자와 시간의 예약이 중복되지 않도록 서버 검증과 데이터베이스 제약을 적용했습니다. 두 역할을 함께 논의하면서 클라이언트는 반복 행동을 줄이고 서버는 데이터 일관성을 지키도록 범위를 나눴습니다.
면접에서는 중복 요청을 막았다고 단정하기보다 자신이 담당한 화면 제어와 서버 측에서 추가로 필요한 처리를 구분해 설명하는 편이 정확합니다. 이러한 태도는 전체 서비스 흐름을 이해하고 있다는 근거가 됩니다.
- API 문서와 테스트 기록도 포트폴리오 자료가 됩니다
요청 방식이 바뀌었는데 프런트엔드와 백엔드가 서로 다른 문서를 보고 있으면 연동 오류가 반복됩니다. 요청 필드와 응답 예시, 상태별 오류 코드를 함께 관리해야 합니다.
팀 프로젝트에서 날짜 값이 화면에서는 지역 시간으로 표시됐지만 서버에는 다른 기준으로 저장돼 예약 시간이 어긋난 사례가 있었습니다. 양쪽 개발자가 저장 기준과 표시 기준을 합의하고 API 문서를 수정했습니다. 다른 날짜와 시간대에서도 같은 결과가 나오는지 테스트했습니다.
포트폴리오에는 문서 전체를 넣기보다 협업 과정에서 변경한 계약과 그 이유, 적용 후 확인한 결과를 요약할 수 있습니다. API를 호출했다는 설명이 팀 사이의 기준을 조정하고 사용자 화면에 안정적으로 반영한 경험으로 확장됩니다.
- conclusion
프런트엔드 프로젝트를 취업 자료로 정리할 때 화면 캡처와 기술 스택만으로는 충분하지 않습니다. 사용자가 어떤 목적을 가지고 이동하며 로딩, 빈 결과, 오류와 성공 상태를 어떻게 경험하는지 보여줘야 합니다. 여기에 입력과 접근성, 실패 후 복구를 개선한 근거와 API 응답을 안정적인 화면 상태로 바꾼 과정이 포함돼야 합니다.
- 핵심 사용자 한 명을 정하고 시작 화면부터 목표 행동을 완료하는 지점까지 직접 이동해 보세요. 새로고침, 뒤로 가기, 직접 주소 접근과 로그인 만료 상황에서도 흐름이 이어지는지 확인해야 합니다.
- 정상 화면 외에 로딩, 빈 결과, 입력 오류, 네트워크 실패를 각각 만들어 보세요. 사용자가 현재 상태를 이해하고 다음 행동을 선택할 수 있는지 점검하면 사용자경험 사례로 정리할 수 있습니다.
- 대표 API 하나를 선택해 요청값, 응답 데이터, 상태 변화와 오류 처리를 순서대로 적어 보세요. 네트워크 탭과 테스트 결과, 백엔드 담당자와 조정한 내용을 함께 남기면 연동 경험의 신뢰도가 높아집니다.
실제 포트폴리오를 검토하면 화면 디자인은 잘 정리돼 있지만 요청 중 상태와 실패 흐름이 빠진 경우가 많았습니다. 반대로 화면 수가 적더라도 오래된 검색 응답을 차단하고 입력 내용을 보존하며 키보드 접근을 개선한 과정이 있다면 구체적인 직무 경험이 됩니다. 결과 화면은 사용자가 최종적으로 보는 한 장면일 뿐이며, 프런트엔드 개발자의 판단은 그 장면에 도달하기까지의 상태와 행동에서 드러납니다. 이 과정을 README와 수정 전후 화면, Git 기록에 남기면 이력서의 프로젝트 문장과 기술면접 답변으로 연결할 수 있습니다.
