Garu's

[취업 준비] 기능 목록을 문제 해결 경험으로 바꾸는 방법

들어가며

2026년 5월에는 개발 공부만큼이나 이력서와 포트폴리오 정리에 시간을 많이 썼다.

처음에는 내가 구현한 기능을 최대한 많이 적으려고 했다.
하지만 적다 보니 글이 길어질수록 오히려 내가 어떤 개발자인지 흐려졌다.

그래서 방향을 바꿨다.

1

기능 목록을 나열하지 말고, 문제 해결 경험으로 바꾸자.

이번 글은 Java 백엔드 취업 준비를 하면서 프로젝트 경험을 어떻게 정리하려고 했는지 기록한 글이다.

기능 목록의 한계

처음 포트폴리오에는 이런 식의 내용이 많았다.

  • 로그인 기능 구현
  • 게시글 CRUD 구현
  • 댓글 기능 구현
  • 알림 기능 구현
  • AWS 배포
  • Docker 사용

물론 틀린 말은 아니다.
하지만 이런 문장은 비슷한 프로젝트를 한 사람이라면 누구나 쓸 수 있다.

채용 담당자나 면접관이 궁금한 것은 단순히 기능을 만들었는지가 아니라, 그 과정에서 어떤 문제를 어떻게 해결했는지일 것이다.

그래서 프로젝트 설명을 다음 구조로 바꾸려고 했다.

1

문제 상황 -> 원인 분석 -> 해결 방법 -> 결과

예약 시스템을 설명하는 방법

펜션 예약 프로젝트에서는 예약 중복 방지와 결제 데이터 무결성이 중요했다.

단순히 이렇게 쓰면 약하다.

1

예약 기능과 결제 기능을 구현했습니다.

대신 문제 중심으로 바꾸면 더 분명해진다.

1
2

동시 예약 요청 시 같은 객실이 중복 예약될 수 있는 문제를 확인하고,
트랜잭션과 비관적 락을 적용해 하나의 예약만 성공하도록 처리했습니다.

이렇게 쓰면 어떤 도메인 문제를 다뤘는지, 어떤 기술을 사용했는지, 결과가 무엇인지 드러난다.

성능 개선을 설명하는 방법

7STARBALL 프로젝트에서는 Meeting 목록 조회에서 N+1 문제를 해결했다.

이 경험도 단순히 “성능 최적화”라고 쓰면 부족하다.

더 좋은 표현은 수치를 함께 쓰는 것이다.

1
2
3

모임 목록 조회 시 정규화된 테이블 구조로 인해 다수의 추가 쿼리가 발생했고,
Map Batch 방식으로 호스트, 장소, 태그, 참여자 수를 일괄 조회하도록 개선했습니다.
그 결과 SQL 호출 수와 응답 시간을 크게 줄일 수 있었습니다.

포트폴리오에서는 가능하면 다음 요소를 넣으려고 했다.

  • 개선 전 문제
  • 개선 방식
  • 개선 후 수치
  • 왜 그 방식을 선택했는지

성능 개선은 숫자가 있으면 설득력이 훨씬 커진다.

JWT와 인증 경험 표현하기

인증 기능은 많은 프로젝트에서 사용한다.

그래서 “JWT 로그인 구현”이라고만 쓰면 흔해 보일 수 있다.

내가 강조하려고 한 부분은 다음이었다.

  • AccessToken과 RefreshToken의 역할 분리
  • HttpOnly Cookie 기반 RefreshToken 관리
  • 로그아웃 시 RefreshToken 삭제
  • 인증 실패와 권한 실패 응답 구분
  • 프론트엔드와 Cookie 정책을 맞추며 트러블슈팅한 경험

즉, 로그인 기능을 만들었다는 것보다 인증 흐름의 생명주기를 고민했다는 점을 보여주고 싶었다.

React 경험은 어떻게 쓸까

백엔드 이력서에 React 경험을 얼마나 넣을지도 고민했다.

프론트엔드 개발자로 지원하는 것이 아니라면 React를 크게 강조할 필요는 없다고 생각했다.
하지만 백엔드 API를 프론트 화면과 직접 연결해봤다는 경험은 의미가 있다.

그래서 React 경험은 다음 방향으로 정리했다.

1

프론트엔드 구현 경험을 통해 API 응답 구조와 사용자 흐름을 함께 고려할 수 있었다.

즉, React 자체보다 백엔드 API를 사용하는 클라이언트 입장을 이해했다는 근거로 활용했다.

AI 활용 경험 표현하기

AI 도구 사용 경험도 어떻게 표현할지 고민했다.

단순히 “AI로 코드를 작성했다”라고 쓰면 오히려 좋지 않게 보일 수 있다.
그래서 AI를 개발 보조 도구로 어떻게 사용했는지 구체화하려고 했다.

예를 들어 다음처럼 정리했다.

  • 오류 로그 원인 후보 정리
  • 코드 리팩토링 방향 비교
  • 테스트 케이스 아이디어 도출
  • 포트폴리오 문장 압축
  • 공식 문서 기반 개념 정리
  • 블로그 글 초안 작성과 구조화

AI가 대신 개발했다는 표현보다, 내가 문제를 더 잘 이해하고 정리하기 위해 AI를 활용했다는 방향이 더 적절하다고 생각했다.

마무리

5월에 이력서와 포트폴리오를 정리하면서, 좋은 프로젝트 설명은 기능이 많은 설명이 아니라 문제 해결 과정이 보이는 설명이라는 것을 느꼈다.

앞으로 프로젝트를 할 때도 단순히 기능을 완료하는 데서 멈추지 않고, 어떤 문제가 있었고 왜 그 해결 방법을 선택했는지 기록해두려고 한다.

결국 포트폴리오는 프로젝트 결과물이 아니라, 내가 문제를 바라보고 해결한 방식의 기록이라고 생각한다.

Leave a comment

You may also enjoy