💬 “스프링 배웠는데 왜 서류도 안 통과하죠?”
이 질문을 받을 때마다 같은 답을 합니다.기업은 ‘스프링을 아는 사람’을 뽑는 게 아니라, ‘문제를 맡길 수 있는 사람’을 뽑습니다.
저는 스프링 단기심화 부트캠프 수강생들을 꽤 많이 봐왔습니다.
기술적으로 똑똑한 사람은 넘칩니다.
그런데 취업이 되는 사람과 안 되는 사람 사이에는 기술 실력과 무관한, 명확한 차이가 하나 있었습니다.
이 글에서 그 차이를 정리합니다.
길지만, 끝까지 읽으면 내 포트폴리오를 당장 고칠 수 있는 구체적인 기준을 얻게 됩니다.
1. 채용의 본질: “이 사람에게 무엇을 맡길 수 있는가?”
면접관은 여러분의 Udemy 수료증이나 @RestController 사용 경험에 관심이 없습니다. 그들의 머릿속에는 단 하나의 질문만 있습니다.
“이 사람이 우리 팀에 오면, 어떤 문제를 넘길 수 있을까?”
그런데 대부분의 부트캠프 수강생은 이력서와 포트폴리오에 이렇게 씁니다:
❌ "Spring Boot, JPA, MySQL, Redis를 사용하여 쇼핑몰을 구현했습니다."이건 도구 나열이지, 역할 정의가 아닙니다.
기업이 듣고 싶은 말은 이겁니다:
✅ "주문-결제 흐름에서 동시성 문제가 발생했고,
비관적 락 + 재시도 전략으로 해결해 데이터 정합성을 확보했습니다."차이가 보이시나요?
지금 당장 해야 할 것
내가 가려는 포지션을 먼저 정하세요.
| 목표 포지션 | 자주 나오는 실제 문제 | 증명해야 할 것 |
|---|---|---|
| 커머스 백엔드 | 주문 폭주 시 재고 음수 발생 결제 콜백 지연으로 주문 상태 불일치 | 동시성 제어 방식(DB 락/분산락) 결제 상태 동기화 및 보상 처리 설계 |
| 핀테크 | 거래 정산 금액 불일치, 개인정보 접근 통제 요구 | 데이터 무결성 검증 로직 권한 모델 설계 및 암호화 적용 경험 |
| 백오피스 / SI | 관리자 화면에서 대량 조회 시 타임아웃 발생 외부 시스템 API 응답 불안정 | 조회 성능 개선 경험(페이징/인덱스) 배치 재처리 및 연동 장애 대응 |
| 스타트업 초기 | 장애 발생 시 로그 부족으로 원인 파악 지연 수동 배포로 인한 실수 | 구조화된 로그 설계 모니터링/알림 구축 자동 배포 파이프라인 |
| 플랫폼 | 특정 API 트래픽 집중으로 서비스 지연 고객사별 데이터 격리 요구 | 캐시 계층 설계 메시지 큐 기반 비동기 처리 멀티테넌시 모델링 |
포지션이 정해지면, 그 포지션의 문제를 내 프로젝트에서 한 번이라도 풀어본 흔적을 남기세요.
그게 포트폴리오입니다.
2. “기능은 됩니다”가 취업에서 가장 약한 말인 이유
부트캠프 프로젝트의 치명적 패턴이 있습니다:
기능 구현 → 발표 → 끝
문제는, 기업에서는 “기능이 된다”는 게 시작점이라는 겁니다. 실제 면접에서 받는 질문은 이런 겁니다:
면접관: “이 서비스에서 장애가 나면 어떻게 추적하세요?”
대부분의 수강생: “…로그를 봅니다?”
면접관이 듣고 싶은 답:
“Logback으로 구조화 로그를 남기고, 요청마다 traceId를 발급해서 에러 발생 시 해당 요청의 전체 흐름을 추적할 수 있게 했습니다. 운영 중에는 Prometheus + Grafana로 응답 시간과 에러율을 모니터링하고, 임계치 초과 시 Slack 알림이 가도록 구성했습니다.”
이 차이는 기술 실력의 차이가 아닙니다. “기능 구현자”로 남을 것이냐, “운영 가능한 시스템을 만든 사람”이 될 것이냐의 차이입니다.
포트폴리오를 “운영형”으로 바꾸는 5가지 체크리스트
아래 중 3개 이상을 프로젝트에 녹이면, 서류 통과율이 확연히 달라집니다.
① 장애 추적 — “왜 죽었는지 알 수 있는가?”
- 구조화된 로그 (JSON 포맷, traceId 포함)
- 에러 로그와 정상 로그의 레벨 분리
- 장애 시나리오 재현 → 로그로 원인 추적한 경험을 README에 기록
② 성능 측정 — “어디가 느린지 아는가?”
- 주요 API의 응답 시간 측정 (p50, p95, p99)
- 슬로우 쿼리 탐지 → 인덱스 추가 전후 비교
- JMeter나 k6로 부하 테스트 → 병목 지점 식별
③ 데이터 정합성 — “꼬이면 어떻게 되는가?”
- 동시 요청 시 Race Condition 발생 시나리오 + 해결 방법
- 트랜잭션 경계 설정의 근거
- 분산 환경이라면 Eventual Consistency 전략
④ 보안 — “뚫리면 어떻게 되는가?”
- Spring Security 기반 인증/인가의 설계 의도
- JWT 토큰 관리 전략 (만료, 갱신, 탈취 대응)
- SQL Injection, XSS 등 기본 취약점 대응
⑤ 배포 — “어떻게 나가고, 문제 시 어떻게 돌리는가?”
- CI/CD 파이프라인 (GitHub Actions 등)
- 배포 전략 (Rolling / Blue-Green / Canary 중 택 1)
- 롤백 시나리오와 절차
3. “왜 그렇게 만들었어요?” — 면접에서 갈리는 한 마디
스프링을 얼마나 아느냐는 중요하지 않습니다. 왜 그렇게 설계했느냐를 말할 수 있느냐가 중요합니다.
면접에서 자주 나오는, 그러나 대부분이 막히는 질문들입니다:
“왜 이 패키지 구조로 가셨어요?”
❌ "강의에서 이렇게 했습니다."
✅ "도메인 별로 패키지를 나눠서, 팀원이 서로 다른 도메인을 작업할 때
충돌을 최소화하려고 했습니다.
실제로 주문과 상품 도메인을 동시에 개발할 때 머지 충돌이 줄었습니다."“왜 비관적 락을 쓰셨어요? 낙관적 락은 고려 안 하셨어요?”
❌ "비관적 락이 더 안전하다고 들어서요."
✅ "처음에 낙관적 락으로 시도했는데, 재시도 시 사용자 경험이 나빠지는 문제가 있었습니다.
이 서비스의 동시 요청 패턴을 봤을 때 충돌 빈도가 높아서,
비관적 락 + 타임아웃 조합이 더 적합하다고 판단했습니다."“캐시는 왜 여기에 적용했어요?”
❌ "Redis를 배워서 써봤습니다."
✅ "상품 목록 조회가 전체 트래픽의 70%인데, 데이터 변경은 하루 2~3회였습니다.
Cache-Aside 패턴으로 TTL 5분을 주고, 상품 수정 시 캐시를 무효화하는 방식을 택했습니다.
DB 조회가 약 85% 줄었고, 평균 응답 시간이 120ms에서 8ms로 개선됐습니다."패턴이 보이시나요?
강한 답변에는 항상 이 구조가 있습니다:
상황(Context) → 선택지(Alternatives) → 판단 근거(Reasoning) → 결과(Result)
이걸 모든 기술 결정에 대해 말할 수 있다면, 주니어 면접에서 떨어지기가 어렵습니다.
지금 당장 연습하는 법
프로젝트에서 내가 내린 기술적 결정 5가지를 뽑고, 각각에 대해 이 표를 채워보세요:
| 결정 | 다른 선택지 | 왜 이걸 골랐나 | 결과/수치 |
|---|---|---|---|
| 예: 비관적 락 적용 | 낙관적 락, 분산 락 | 충돌 빈도 높음 + 재시도 UX 문제 | 데이터 정합성 100% 확보 |
이 표가 5개 채워지면, 면접 준비의 절반은 끝난 겁니다.
4. “혼자 만들었습니다”가 오히려 마이너스인 이유
주니어도 혼자 일하지 않습니다. 팀에 합류합니다. 그래서 기업은 **코드 실력만큼이나 “같이 일할 수 있는 사람인가”**를 봅니다.
그런데 부트캠프 프로젝트 GitHub을 열어보면, 대부분 이런 상태입니다:
커밋 히스토리:
- "기능 추가"
- "수정"
- "버그 fix"
- "최종"
- "진짜 최종"이건 협업의 증거가 아니라, 협업 불가능의 증거에 가깝습니다.
기업이 GitHub에서 확인하는 것
① PR(Pull Request) 기반 개발을 했는가?
- feature 브랜치에서 작업 → PR 생성 → 리뷰 → 머지
- PR 제목과 설명에 “무엇을, 왜” 변경했는지 기록
- 혼자 하는 프로젝트라도 PR을 쓰면 됩니다. 습관의 증거니까.
② 코드 리뷰 흔적이 있는가?
- 팀원의 PR에 남긴 리뷰 코멘트
- 리뷰를 반영해서 수정한 이력
- “왜 이렇게 바꿨는지” 설명하는 커밋 메시지
③ 테스트를 작성하는가?
- 핵심 비즈니스 로직의 단위 테스트
- API 통합 테스트
- 테스트 커버리지보다 중요한 건, “무엇을 테스트하기로 결정했고 왜?”
④ 이슈와 문서가 있는가?
- GitHub Issues로 작업을 관리한 흔적
- README에 프로젝트 구조, 실행 방법, 기술 결정 이유 기록
- 트러블슈팅 기록 (겪은 문제 → 원인 → 해결)
한 줄로 요약하면:
프로젝트는 “결과물”이 아니라 “이 사람이 일하는 방식”의 증거여야 합니다.
5. 실전 적용 — 지금 당장 바꿀 수 있는 것들
여기까지 읽었다면, 이론은 충분합니다. 핵심을 하나의 문장으로 압축합니다:
“스프링을 배웠다”가 아니라, “스프링으로 운영 가능한 서비스를 만들고, 문제를 측정-원인분석-개선까지 해봤다”를 증명하세요.
우선순위별 액션 아이템
🔴 필수 (이것 없으면 서류 탈락)
- [ ] 프로젝트 README에 “내가 해결한 문제”를 명확히 서술
- [ ] 최소 1개의 기술 결정에 대해 “왜?” 설명 작성
- [ ] PR 기반 개발 히스토리 확보
- [ ] 핵심 로직 단위 테스트 최소 10개
🟡 가점 (서류에서 눈에 띄는 수준)
- [ ] 성능 측정 + 개선 전후 수치 기록
- [ ] CI/CD 파이프라인 구축
- [ ] 모니터링 대시보드 (Grafana 등) 스크린샷과 설명
- [ ] 트러블슈팅 문서 (문제 → 원인 → 해결 → 배운 점)
🟢 면접용 스토리 (면접에서 합격선을 넘기는 수준)
- [ ] “상황 → 선택지 → 판단 → 결과” 구조의 기술 결정 스토리 5개
- [ ] 장애 시나리오 + 대응 시나리오 1개
- [ ] 팀 협업에서 갈등/의견 충돌 → 해결 경험 1개
마무리
부트캠프 3개월은 짧습니다.
그 안에 시니어가 될 수는 없습니다.
하지만 “이 사람은 기능만 만드는 게 아니라, 운영과 문제 해결까지 생각하는 사람이구나”라는 인상을 줄 수는 있습니다. 그리고 그 인상이 서류 통과와 면접 합격을 가릅니다.
스프링을 얼마나 아느냐가 아닙니다.
스프링으로 무엇을 해결했고, 왜 그렇게 결정했는지를 말할 수 있느냐.
그게 전부입니다.
이 글이 도움이 됐다면, 같은 고민을 하는 동기에게 공유해주세요.
구체적인 포트폴리오 리뷰나 면접 스토리 작성이 필요하면, 댓글로 본인 상황(초보/경력전환, 목표 포지션)을 남겨주세요. 맞춤 조언을 드리겠습니다.
