신입 백엔드 지원자는 어떤 점검 리포트를 받나

프로젝트마다 배경, 기능, 사용 기술 순서로 일관되게 정리돼 읽기는 편하다. 문제는 순서 자체가 결론을 뒤로 미룬다는 점이다. 읽는 사람은 배경 세 문단을 지나야 무엇을 해결했는지 알게 된다.

정산 프로젝트가 '공동구매는 참여자가 많아질수록 정산이 복잡해집니다'라는 일반론 두 문단으로 시작한다.

상위 20% 신입 포트폴리오는 프로젝트 첫 줄에 결과를 먼저 놓는다. 이 문서는 평균 구간이다.

각 프로젝트 맨 위에 '무슨 문제 · 어떤 결정 · 무엇이 달라졌나' 세 줄을 굵게 넣고, 지금의 배경 문단은 그 아래로 내려라.

가장 약한 축이다. '안정적으로 처리했다', '성능을 개선했다' 같은 서술은 있는데 무엇을 어떻게 쟀는지가 없다. 신입에게 대단한 숫자를 기대하는 게 아니라, 직접 만든 테스트에서 나온 값이면 충분하다.

좌석 예약 API 항목의 결과가 '중복 예약 없이 안정적으로 동작하도록 개선'으로 끝난다. 몇 명이 동시에 눌렀을 때인지, 개선 전에는 몇 건이 겹쳤는지가 없다.

같은 신입 구간에서 전후 수치를 붙인 포트폴리오는 대략 셋 중 하나다. 붙이면 바로 위 구간으로 올라간다.

부하 테스트 도구로 동시 요청을 걸어 개선 전후 실패 건수를 재고, 그 두 값을 그대로 적어라. 하루면 된다.

이 문서에서 가장 좋은 축이다. 락을 왜 낙관적이 아니라 비관적으로 골랐는지, 트랜잭션 경계를 어디에 뒀는지가 문장으로 설명돼 있다. 신입 포트폴리오에서 '무엇을 썼다'가 아니라 '왜 그걸 골랐다'가 나오는 경우는 흔하지 않다.

'참여자 수가 적고 충돌 확률이 높다고 판단해 재시도 비용이 큰 낙관적 락 대신 비관적 락을 선택했다'는 서술.

상위 20~30% 구간이다. 다만 그 선택의 대가(처리량 감소)까지 적으면 상위 10%의 서술이 된다.

고른 이유 옆에 '대신 무엇을 포기했는가'를 한 줄씩 붙여라. 트레이드오프를 아는 사람이라는 신호가 가장 싸게 전달된다.

문장은 깔끔하고 오탈자도 거의 없다. 다만 코드 블록이 화면 절반을 차지하는 구간이 두 곳 있어 스크롤이 끊긴다. 서류 단계에서 코드를 정독하는 사람은 드물다.

정산 로직 부분에 40줄짜리 서비스 클래스가 통째로 붙어 있다.

평균 이상. 긴 코드를 저장소 링크로 넘기기만 해도 상위 구간으로 간다.

코드는 핵심 5~10줄만 남기고 나머지는 저장소 특정 줄 링크로 대체하라.

두 프로젝트 모두 강의와 클론 과제에서 자주 보는 구성이라, 심사자가 이미 여러 번 본 문서로 읽힐 위험이 있다. 기술이 겹치는 건 문제가 아니고, 겹칠 때 무엇을 다르게 했는지가 안 보이는 게 문제다.

좌석 예약 API의 기능 목록이 일반적인 예약 시스템 튜토리얼 구성과 거의 같다.

하위 구간. 이 축은 주제를 바꾸지 않고도 올릴 수 있다.

튜토리얼과 다르게 간 지점 하나만 골라 그 결정만 따로 서술하라. 예를 들어 좌석 상태를 어떻게 표현했고 왜 그 방식이 아니었는지.