9년간 백엔드 신입 지원서를 수천 장 봤지만, 한 가지는 거의 변하지 않습니다. 백엔드 신입 포트폴리오에 'CRUD 게시판'과 'JWT 로그인 구현'만 적혀 있으면, 평균 1분을 넘기지 못하고 다음 지원서로 넘어갑니다. 기술을 적게 써서 떨어지는 게 아닙니다. 누구나 똑같이 만드는 기능을, 똑같은 방식으로 나열만 해두었기 때문입니다. 오히려 기능 목록이 길수록 더 빨리 넘어가는 경우가 많습니다.
백엔드 신입 채용에서 개발팀이 실제로 확인하는 것과, 취준생이 밤새 공들이는 것 사이에는 생각보다 큰 간극이 있습니다. 9년간 스타트업과 IT 서비스 기업에서 서버 개발자를 뽑으면서 본 합격자들의 공통점은, 화면에 보이지 않는 곳을 얼마나 깊이 고민했는가였습니다. 백엔드는 결국 눈에 띄지 않는 안정성과 구조로 평가받는 직무이기 때문입니다. 채용 담당자가 코드보다 먼저 보는 3가지를 정리합니다.
1. 어떤 기술을 썼는가보다, 왜 그 구조로 설계했는가
백엔드 신입 포트폴리오를 준비하면 대부분 기능부터 채웁니다. 회원가입, 로그인, 게시판, 댓글, 좋아요. 강의를 따라 만든 같은 기능들이 거의 똑같은 순서로 들어 있습니다. 9년간 채용하면서 기능 개수를 이유로 합격시킨 신입은 없었습니다. 같은 강의를 들은 지원자가 수백 명이고, 테이블 구조와 API 형태까지 닮아 있기 때문입니다.
채용 담당자가 보는 것은 그 다음입니다. 같은 게시판을 만들었더라도 왜 그 데이터 구조를 택했는지 설명할 수 있는가입니다. 테이블을 왜 그렇게 나눴는지, 이 컬럼에 왜 인덱스를 걸었는지, 조회가 많은 데이터와 자주 바뀌는 데이터를 어떻게 구분했는지를 말할 수 있는 사람과, "강의에서 그렇게 했어요"에서 멈추는 사람은 완전히 다릅니다. 백엔드는 결국 보이지 않는 데이터의 흐름을 설계하는 직무이기 때문입니다.
이 설명 능력은 거창한 프로젝트가 없어도 보여줄 수 있습니다. 이미 만든 게시판 프로젝트라도, README나 문서에 "처음에는 이렇게 설계했는데 데이터가 늘어날수록 조회가 느려질 것 같아 이렇게 바꿨다"를 한두 줄 적어두는 것만으로 충분합니다. 면접에서 "이 프로젝트에서 가장 고민했던 설계가 뭐였나요"라는 질문에 이렇게 답하는 신입은 바로 눈에 띕니다. 따라 만든 기능 열 개보다, 한 번이라도 스스로 구조를 고민한 흔적이 훨씬 강합니다.
한 가지 더 기억할 것이 있습니다. 설명할 수 있다는 것은 완벽한 설계를 자랑하는 일이 아닙니다. 처음 잡은 구조가 왜 부족했는지, 무엇을 다르게 바꿨는지를 말할 수 있는 사람이 채용 담당자에게는 더 믿음직합니다. 신입에게 처음부터 완벽한 데이터베이스 설계를 기대하는 회사는 없습니다. 막힌 지점을 솔직하게 마주하고 거기서 배운 점을 정리해본 흔적이, 매끈해 보이는 기능 목록 하나보다 신입 단계에서 의외로 더 큰 신뢰를 만듭니다.
2. 기능 개수보다, 실제로 배포되어 돌아가는 서버 하나가 강하다
백엔드 신입 포트폴리오에서 가장 자주 보는 것이 "구현 기능" 목록입니다. 그런데 그 기능들이 실제로 어디에서 어떻게 돌아가는지는 비어 있는 경우가 많습니다. 깃허브에 코드는 있는데, 정작 그 API를 직접 호출해볼 방법이 없는 것입니다. 합격자들의 포트폴리오에는 규모가 작아도 실제로 배포되어 요청을 받을 수 있는 서버 하나가 들어 있었습니다. 코드 저장소뿐 아니라, 호출하면 정상적으로 응답이 돌아오는 API가 있는 것입니다.
배포된 서버가 강한 이유는 기능 목록으로는 증명할 수 없는 것을 보여주기 때문입니다. 끝까지 완성해본 경험, 로컬에서만 되는 코드가 아니라 실제 환경에 올려본 경험, 그리고 데이터베이스 연결과 환경 변수, 배포 과정에서 마주치는 문제들을 한 번이라도 직접 겪어본 흔적이 담깁니다. 코드 캡처 다섯 장보다, 호출하면 응답이 오는 API 문서 한 장이 채용 담당자에게 훨씬 분명한 신호입니다. 로컬에서만 도는 기능이 열 개인 것보다, 끝까지 배포해 돌아가는 작은 서비스 하나가 신입 단계에서는 더 큰 신뢰를 만듭니다.
이것은 다른 직무의 포트폴리오에서도 똑같이 통합니다. 프론트엔드 신입 포트폴리오에서 채용 담당자가 기술 스택보다 먼저 보는 것도 결국 완성도와 끝맺음의 흔적입니다. 아직 배포해본 서버가 없다면 지금이라도 만들 수 있습니다. 이미 만든 프로젝트 중 하나를 골라 무료로 쓸 수 있는 클라우드 환경에 올리고, API 문서를 정리해 외부에서 직접 호출해볼 수 있게 해두는 것입니다. 돌아가는 API 하나가 구현 기능 열 줄을 이깁니다.
3. 정상 동작하는 코드인가보다, 에러와 예외를 어떻게 다뤘는가
백엔드 신입 면접에서 코드를 함께 볼 때 가장 많이 드러나는 차이가 이 지점입니다. 정상적인 입력에는 잘 동작하는데, 잘못된 값이 들어오거나 데이터가 없을 때 어떻게 되는지를 물으면 답이 막힙니다. 저장소를 열어보면 성공하는 경우만 처리되어 있고, 에러가 났을 때 무엇을 돌려주는지, 로그는 어디에 남는지가 비어 있습니다. 혼자 정해진 값으로 돌릴 때는 문제가 없지만, 실제 사용자가 들어오는 순간 무너지는 코드입니다.
합격한 신입들은 달랐습니다. 화려한 기능이 아니라, 실패하는 경우를 먼저 생각한 코드를 썼습니다. 잘못된 요청에는 어떤 응답을 돌려주는지, 데이터베이스 연결이 끊겼을 때는 어떻게 처리하는지, 문제가 생겼을 때 원인을 찾을 수 있도록 로그를 남겨두었는지가 보였습니다. 백엔드는 잘 돌아갈 때보다 문제가 생겼을 때 진가가 드러나는 직무입니다. 신입에게 완벽한 장애 대응을 기대하는 회사는 없지만, 실패를 한 번이라도 고민해봤는지는 분명히 봅니다.
이것은 결국 실무 감각에 대한 신호입니다. 경험이 부족해도 합격하는 신입들의 공통점도, 완벽한 결과물이 아니라 실제 상황을 상상하며 준비한 흔적을 남겼다는 점입니다. 지금 내 프로젝트에 일부러 잘못된 값을 한 번 넣어보세요. 서버가 그냥 죽어버리거나 아무 메시지 없이 멈춘다면, 기능이 아무리 많아도 그 포트폴리오는 실무 감각이라는 신호를 잃고 있는 것입니다.
지금 준비하고 있는 것을 한 번 점검해보세요. 빼곡히 적어둔 구현 기능 목록과 강의를 따라 만든 프로젝트 개수가, 채용 담당자가 검증하는 3가지 — 설계의 근거를 설명하는 능력, 끝까지 배포해 돌아가는 서버, 에러와 예외를 다룬 흔적 — 와 얼마나 연결되어 있는지 확인하는 것이 백엔드 신입 취업 준비의 핵심입니다. 연결되지 않는 준비는 아무리 쌓아도 서류를 통과시키지 못합니다.
백엔드 신입 취업은 기능을 몇 개 구현했느냐의 문제가 아닙니다. 왜 그렇게 설계했는지 설명하는 능력, 작더라도 끝까지 배포해 돌아가는 서버, 에러와 예외를 한 번이라도 고민한 흔적 — 이 3가지가 기능 목록보다 먼저입니다. 합격한 신입들이 특별히 어려운 기술을 다뤘던 게 아닙니다. 자기가 만든 구조를 설명하고, 끝까지 올려보고, 무너질 상황까지 생각했을 뿐입니다. 지금 준비하고 있는 것이 이 방향에 맞는지 점검해보세요.