직무별 가이드 / 백엔드 개발자 이력서 작성법

백엔드 개발자 이력서 작성법

백엔드 이력서는 기능 목록이 아니라 '어떤 부하와 데이터 위에서, 무엇을 지키려고 무엇을 포기했는지'를 보여주는 문서예요. 같은 API 개발이라도 처리 규모, 데이터 정합성, 장애 대응을 함께 적은 이력서에서는 설계 판단력이 드러나요. 눈에 보이는 화면이 없는 일이라, 숫자와 구조 설명이 결과물 역할을 대신해요.

백엔드 면접관이 먼저 찾는 신호

  1. 1

    트래픽·데이터 규모와 그 기준

    TPS, 일 요청 수, 테이블 크기, 동시 접속을 숫자로 적되 평시인지 피크인지 밝혀요. 규모가 작아도 괜찮아요. 규모에 맞는 설계를 했다는 게 보이면 돼요.

  2. 2

    장애 대응과 운영 경험

    온콜을 섰는지, 장애 회고(포스트모템)를 써 봤는지, 모니터링 지표와 알림을 직접 붙여 봤는지가 '만들고 끝낸 사람'과 '운영해 본 사람'을 가르는 기준이에요.

  3. 3

    설계 트레이드오프

    RDB와 NoSQL, 동기와 비동기, 모놀리스 유지와 분리 중 무엇을 골랐고 그 대가로 무엇을 포기했는지가 보이면 시니어 면접관이 반가워해요.

  4. 4

    데이터 정합성을 지키는 감각

    트랜잭션 경계, 동시성 제어, 멱등성, 무중단 스키마 변경을 다뤄 본 경험은 문장 하나로도 깊이를 보여줘요.

'MSA 전환', 'Redis 도입' 같은 기술 이름은 결론이 아니라 선택지예요. 그 선택이 왜 필요했는지 한 구절만 붙여도 설계 경험으로 읽혀요.

도입은 했는데 판단이 안 보이는 문장들

기술 도입을 성과처럼 쓴 경우
Before

Redis 캐시 도입 및 Kafka 기반 메시징 구축

After

상품 조회 트래픽이 DB 커넥션을 고갈시키던 문제를 Redis 캐시(TTL 60초, 상품 변경 시 무효화)로 풀어 피크 시간 DB CPU 85% → 40%

💡 '도입했다'는 행동이고, 성과는 그 도입이 해결한 문제예요. 캐시라면 무효화 전략까지 적어 두면 꼬리 질문에 미리 답하는 셈이에요.

운영 경험을 뭉뚱그린 경우
Before

서비스 운영 및 유지보수, 장애 대응

After

주 1회 온콜 순번을 맡아 장애 12건 1차 대응, 그중 커넥션 풀 누수 건은 회고 후 알림 기준을 바꿔 같은 유형 재발 0건

💡 '유지보수'는 범위가 너무 넓어요. 몇 번, 어떤 역할로, 무엇을 바꿔 재발을 막았는지가 운영 역량이에요.

신입 vs 경력: 백엔드에서 증명할 것이 달라져요

항목신입경력
대표 경험직접 설계한 API와 DB 스키마, 배포와 로그 확인까지 해 본 프로젝트운영 중 시스템의 병목·장애를 고치고 재발을 막은 경험
설계 설명ERD와 API 명세, 인덱스를 왜 그렇게 걸었는지검토한 대안과 포기한 것, 마이그레이션·롤백 계획
운영 감각k6·JMeter 같은 부하 테스트로 한계를 직접 재 본 경험온콜·포스트모템·SLO 설정처럼 운영 체계에 기여한 경험
숫자의 종류부하 테스트 결과, 쿼리 실행 계획 전후 비교p99 지연, 에러율, 처리량, 인프라 비용 같은 운영 지표

설계 실력을 보여주는 첨부 자료

보여줄 것과 뺄 것
  • 아키텍처 다이어그램 한 장 — 요청 흐름, 데이터 저장소, 비동기 구간이 한눈에 보이게
  • GitHub 저장소 — 테스트 코드와 마이그레이션 파일이 있는지가 README보다 많은 걸 말해줘요
  • 부하 테스트 결과 — 도구, 시나리오, 한계점에서 어떤 병목이 먼저 터졌는지까지
  • 장애 회고 글 — 개인 블로그에 쓴다면 회사·서비스를 특정할 수 있는 정보는 지우고 원인과 조치만
  • API 문서 링크(Swagger, Postman 등) — 개인 프로젝트라면 공개해 두세요
  • 빼야 할 것: 실제 서버 주소·접속 정보, 사내 장애 보고서 원문, 운영 데이터가 찍힌 쿼리 결과 캡처

이 이력서에서 이어질 면접 질문

면접 장면

면접관: 멱등 키로 중복 결제를 막았다고 하셨는데, 키는 누가 만들고 어디에 저장했나요?

지원자: 클라이언트가 결제 시도마다 UUID를 만들어 헤더로 보내고, 서버는 키와 처리 결과를 24시간 저장했어요. 같은 키로 다시 오면 저장된 응답을 그대로 돌려줘요.

면접관: 첫 요청이 아직 처리 중일 때 같은 키로 두 번째 요청이 오면요?

지원자: 키를 저장할 때 '처리 중' 상태로 먼저 선점하고, 그 사이 들어온 요청에는 409를 돌려줘서 클라이언트가 잠시 뒤 결과를 조회하게 했어요.

필수 항목 체크리스트

  • 서버/API 개발 경험
  • 데이터베이스 경험
  • 성과 수치 포함
  • 클라우드/인프라(권장)
  • 보안/인증 경험(권장)
  • 대용량 트래픽 처리(권장)

강조 키워드

API 설계데이터베이스마이크로서비스RedisDockerAWS

좋은 성과 문장 예시

  • ✦주문 테이블 파티셔닝과 인덱스 재설계로 월 3억 건 데이터 조회 p99 지연 1.8초 → 210ms
  • ✦결제 승인 API에 멱등 키와 재시도 큐를 도입해 중복 결제 문의를 월 수십 건 → 0건으로 줄임
  • ✦야간 정산 배치를 이벤트 기반 처리로 바꿔 전용 서버 4대를 없애고 클라우드 비용 월 약 300만 원 절감

바로 백엔드 개발자 이력서를 만들어 보세요

무료 · 경력 몇 줄이면 시작

지금 무료로 이력서 만들기 →