신입 백엔드 포트폴리오, 면접관이 진짜 보는 3가지

by 그릿 | GROWTH_ESSAY | 2026-07-27

신입 백엔드 포트폴리오는 얼마나 많은 기술을 다뤄봤는지가 아니라, 하나의 문제를 얼마나 깊게 파고들었는지로 평가받습니다. 면접관은 수십 개의 라이브러리 목록이 아니라 기술 선택의 이유와 트러블슈팅의 구체적 과정을 봅니다. 포트폴리오의 서류 통과율을 높이려면 화려한 아키텍처 다이어그램 대신 깊이 있는 구현 기록 3가지를 증명해야 합니다.

기술 스택 나열보다 선택의 기준이 있는가?

멘토링 과정에서 접한 3년 이하 주니어들의 포트폴리오 10개 중 8개는 기술 스택란이 빼곡합니다. Spring Boot, Redis, Kafka, Docker, Kubernetes까지 적어두지만 정작 "왜 Redis를 캐시로 썼나요?"라고 물으면 "다들 써서"라고 답합니다.

면접관은 기술 스택의 가짓수에 감탄하지 않습니다. 10개 기술을 겉핥기로 적은 이력서보다, "동시 접속 100건 요청 시 DB 락 병목을 확인하고 Redis 분산 락을 도입해 응답 시간을 450ms에서 80ms로 줄인 경험" 1건이 훨씬 강렬합니다. 내가 이 도구를 왜 선택했는지 명확한 근거가 적혀 있어야 읽힙니다.

예쁜 다이어그램보다 진짜 트러블슈팅이 있는가?

많은 주니어들이 포트폴리오를 만들 때 아키텍처 다이어그램 그리기에 3주 이상을 씁니다. 하지만 막상 본문에는 "성능 개선을 수행함"이라는 한 문장만 남깁니다. 면접관이 궁금한 부분은 결과가 아닌 과정입니다.

실제 멘토링을 진행했던 한 취준생은 N+1 문제 해결 과정을 쿼리 실행 계획(EXPLAIN) 캡처와 함께 3단계로 정리했습니다. 100건 데이터 조회 시 발생한 101번의 쿼리가 Fetch Join 적용 후 1번으로 줄어드는 과정을 재현 코드와 함께 기술했습니다. 이 포트폴리오 하나로 그는 5개 회사의 서류 전형을 연속으로 합격했습니다. 실패한 시도와 이를 극복한 디버깅 기록이야말로 가장 강력한 무기입니다.

코드 설명보다 비즈니스 맥락 이해가 있는가?

주니어 개발자가 자주 범하는 실수는 코드 문법과 API 명세서만 나열하는 것입니다. CRUD 기능 5개를 완성했다는 소식은 면접관에게 아무런 감흥을 주지 못합니다.

서류를 통과하는 포트폴리오는 비즈니스 문제에서 출발합니다. "주문 결제 실패율을 낮추기 위해 어떤 예외 처리를 설계했는가", "재고 차감 시 동시성 문제를 어떻게 방지했는가"처럼 현실의 문제를 기술로 풀어낸 흔적이 필요합니다. 개발은 문법을 자랑하는 자리가 아니라 요구사항을 코드로 변환하는 작업이기 때문입니다.

지금 내 백엔드 포트폴리오의 방향과 서류 통과 가능성을 객관적으로 점검하고 싶다면 그릿 커리어 방향 진단에서 확인해 보세요.