백엔드 개발자의 경력기술서는 기술 스택 목록이 아니라 문제를 풀어 낸 기록입니다. 프로젝트마다 어떤 병목이 있었고, 어떤 설계를 선택했으며, 응답 시간·장애 건수·비용이 얼마나 달라졌는지를 보여 주세요. 이력서에 한 줄로 적은 회사 경력을 여기서 프로젝트 단위로 풀어 쓰면 됩니다.
이런 분께: 3년차 이상 백엔드 개발자로 이직을 준비하며 프로젝트 단위 성과를 정리해야 하는 분
이 예시로 시작하기 ↗예시 속 인물·회사·수치는 모두 가상입니다. 내 경력으로 바꿔 쓰세요.
박준영
백엔드 개발자 · 7년차
junyoung.park@example.com
핵심 역량
• 주문·결제 API p95 응답 시간 1.8초→420ms 단축
• 결제 모듈 서비스 분리로 배포 주기 주 1회→하루 3회
• 장애 런북 12종 작성, 월 장애 9건→2건
• Kafka 기반 이벤트 처리 설계, 일 1,200만 건 안정 처리
경력 상세
예시 커머스 · 플랫폼개발팀 시니어 백엔드 개발자
2022-04 ~ 현재
담당 업무 주문·결제 도메인 API 설계와 운영을 맡고, 서비스 분리와 성능 개선 과제를 리드합니다.
주문 조회 API 성능 개선
2025-02 ~ 2025-07
역할 백엔드 리드 · 팀 규모 4명 · 기여도 리드
사용 기술 Java · Spring Boot · MySQL · Redis
• 슬로 쿼리 상위 20개를 분석해 복합 인덱스를 재설계하고 p95 응답 시간을 1.8초에서 420ms로 줄였습니다.
• 조회 빈도가 높은 주문 요약에 Redis 캐시를 적용해 DB 읽기 부하를 62% 낮췄습니다.
• 부하 테스트 시나리오 8종을 만들어 최대 처리량을 초당 1,500건에서 4,200건으로 검증했습니다.
결제 모듈 서비스 분리
2023-05 ~ 2024-06
역할 결제 서비스 설계·구현 · 팀 규모 6명 · 기여도 45%
사용 기술 Kotlin · Spring Boot · Kafka · Kubernetes
• 모놀리식 결제 로직을 독립 서비스로 분리하고 배포 주기를 주 1회에서 하루 3회로 늘렸습니다.
• 결제 이벤트를 Kafka로 비동기 처리해 일 1,200만 건을 유실 없이 처리했습니다.
• 결제 실패 재시도 로직을 정비해 결제 실패율을 1.4%에서 0.3%로 낮췄습니다.
장애 대응 체계 정비
2022-09 ~ 2023-03
역할 모니터링·런북 담당 · 팀 규모 3명 · 기여도 60%
사용 기술 Prometheus · Grafana · PagerDuty
• 알림 기준 40여 개를 재정의해 불필요한 야간 알림을 월 150건에서 30건으로 줄였습니다.
• 장애 유형별 런북 12종을 작성해 월평균 장애 건수를 9건에서 2건으로 낮췄습니다.
예시 모빌리티 · 서버개발팀 백엔드 개발자
2019-03 ~ 2022-03
담당 업무 차량 예약·정산 서버를 개발하고 운영했습니다.
예약 정산 배치 개편
2020-08 ~ 2021-05
역할 배치 설계·구현 · 팀 규모 4명 · 기여도 50%
사용 기술 Java · Spring Batch · PostgreSQL
• 일 정산 배치를 청크 단위 병렬 처리로 바꿔 실행 시간을 3시간에서 35분으로 줄였습니다.
• 정산 오차 검증 쿼리를 추가해 월 수작업 보정 건수를 80건에서 5건 이하로 낮췄습니다.
예약 API 신규 개발
2019-06 ~ 2020-06
역할 API 개발 · 팀 규모 5명 · 기여도 30%
사용 기술 Java · Spring Boot · AWS
• 예약 생성·변경·취소 API 14종을 개발해 출시 후 6개월간 누적 예약 80만 건을 처리했습니다.
• 중복 예약 방지를 위해 분산 락을 적용해 중복 예약 문의를 월 0건으로 유지했습니다.
퇴사 사유 대규모 트래픽 환경으로의 커리어 확장
기술스택
언어·프레임워크 Java · Kotlin · Spring Boot · Spring Batch
백엔드 성과는 응답 시간, 처리량, 오류율, 장애 건수처럼 측정할 수 있는 값으로 드러납니다. '성능을 개선했다'보다 'p95 응답 시간 1.8초→420ms'처럼 변화 전후를 함께 적으면 면접관이 규모와 난이도를 바로 가늠합니다. 측정 기준(p95, 월평균 등)도 짧게 밝혀 두세요.
02
설계 판단의 이유를 한 줄 남기세요
캐시를 도입했는지, 큐로 분리했는지보다 왜 그 방법을 골랐는지가 경력자의 차이를 만듭니다. 프로젝트 첫 줄에 문제 상황을, 다음 줄에 선택한 설계와 대안을 짧게 적으면 기술 면접에서 이어질 질문을 미리 준비하는 효과도 있습니다.
03
팀 규모와 기여도로 범위를 분명히 하세요
대규모 시스템일수록 혼자 한 일과 팀이 한 일이 섞이기 쉽습니다. 팀 규모와 기여도를 따로 적고, 불릿에는 본인이 직접 설계·구현한 부분만 남기세요. 리드였다면 코드 리뷰, 일정 관리처럼 리드로서 한 일을 별도 줄로 분리하는 편이 좋습니다.
성과 줄은 이렇게 바꿔 보세요
고치기 전주문 API 성능 개선 작업을 진행했습니다.
고친 후주문 조회 쿼리에 복합 인덱스와 Redis 캐시를 적용해 p95 응답 시간을 1.8초에서 420ms로 줄였습니다.
무엇을 바꿨는지(인덱스·캐시)와 전후 수치를 함께 쓰면 '진행했다'는 모호한 표현이 구체적인 성과로 바뀝니다.
고치기 전MSA 전환 프로젝트에 참여했습니다.
고친 후모놀리식 결제 모듈을 독립 서비스로 분리하는 작업을 맡아 배포 주기를 주 1회에서 하루 3회로 늘렸습니다.
'참여'만으로는 역할을 알 수 없습니다. 맡은 범위와 그 결과로 달라진 운영 지표를 적어야 기여가 보입니다.
고치기 전장애 대응 및 모니터링 업무를 담당했습니다.
고친 후알림 기준을 재설계하고 장애 대응 런북 12종을 작성해 월평균 장애 건수를 9건에서 2건으로 줄였습니다.
담당 업무 나열 대신 직접 만든 산출물(런북 12종)과 결과 수치를 연결하면 운영 역량이 드러납니다.
자주 하는 실수
Java, Spring, Kafka 같은 기술 이름만 길게 나열하고 그 기술로 해결한 문제는 적지 않는 경우
'대용량 트래픽 처리'처럼 규모를 짐작할 수 없는 표현만 쓰고 TPS나 일 사용자 수를 밝히지 않는 경우
팀 전체가 만든 시스템을 '우리 팀이 구축했다'고 적어 본인이 맡은 부분이 드러나지 않는 경우
사내 서비스 이름과 내부 약어를 설명 없이 그대로 써서 외부 면접관이 맥락을 이해하지 못하는 경우
자주 묻는 질문
GitHub 링크가 있으면 경력기술서는 짧게 써도 되나요?
링크는 보조 자료일 뿐, 서류 검토자가 모두 열어 보지는 않습니다. 경력기술서만 읽어도 프로젝트의 문제, 본인 역할, 수치 성과가 이해되도록 쓰고, 링크는 확인용으로 덧붙이세요.
회사 트래픽 수치를 공개해도 되나요?
비공개 수치라면 원래 값 대신 비율이나 배수로 바꿔 적는 편이 안전합니다. '처리량 3배 증가', '응답 시간 76% 단축'처럼 쓰면 기밀을 지키면서도 성과의 크기는 전달됩니다.
사이드 프로젝트도 경력기술서에 넣어도 되나요?
지원 직무와 직접 관련이 있고 실제 사용자나 운영 기록이 있다면 회사 경력 뒤에 별도 항목으로 넣을 수 있습니다. 다만 회사 프로젝트보다 앞에 두거나 분량을 더 크게 잡지는 마세요.
이 예시로 내 경력기술서 만들기
버튼을 누르면 이 예시가 채워진 경력기술서가 편집기에서 열립니다. 로그인이 필요하며, 내용과 디자인은 자유롭게 바꿀 수 있습니다. 편집기의 점검 패널이 숫자 없는 성과 줄과 분량을 알려줘요.