← SW 개발 커리어 로드맵 예시

백엔드 개발자 커리어 로드맵 예시

장애는 가장 먼저 받고 트래픽은 가장 늦게까지 지켜보는데, 정작 그 시스템을 어떤 구조로 갈지는 다른 자리에서 정해지곤 합니다. 대응 이력은 두꺼워져도 설계를 주도한 근거는 남지 않아 다음 단계에서 내밀 것이 마땅치 않습니다. 그동안의 장애 대응 이력과 설계 논의 기록, 목표 직무를 나란히 놓으면 테크리드까지 무엇이 비는지가 드러납니다. 리포트는 지금 팀에서 설계 결정에 들어가는 경로(A), 개인 작업으로 도메인 깊이를 증명하는 경로(B), 이직으로 자리를 바꾸는 경로(C)를 나눠 짚습니다. 아래는 백엔드 개발자 6년차가 결제 플랫폼 테크리드를 목표로 받은 실제 리포트 예시입니다.

내 커리어 로드맵은 어떤 모습일까요?

가상 예시가 아니라 직접 쌓아온 커리어 데이터와 기록으로 내 리포트를 받아보세요.

내 로드맵 만들기 →

이 예시의 입력: 백엔드 개발자 6년차

커리어 로드맵은 아래처럼 입력한 커리어 데이터·기록·목표를 근거로 만들어져요. 내 데이터를 넣으면 내 리포트를 받습니다.

목표 직무
결제 플랫폼 테크리드
커리어 지향
스페셜리스트 (전문성 심화)
입력한 재료
경력 2건 · 사이드 프로젝트 1건 · 커리어 기록 12
현재 회사 상황 (본인 서술)
현재 회사(간편결제 서비스, 서버 팀 7명)에서 결제·정산 API를 담당. 장애 대응과 트래픽 대응은 도맡지만 설계 결정은 팀장이 내림.
기타 희망사항
대응만 반복하는 느낌이라 결제 도메인 설계를 주도하는 자리로 옮기고 싶음.

리포트 예시: 백엔드 개발자 6년차 결제 플랫폼 테크리드

🧾 총평

현재 경력은 결제·정산 도메인에서 개선과 운영 설계를 반복해 온 백엔드 미들급 후반부에 가깝습니다. 정산 배치 병렬화, 결제 API p99 개선, 멱등 처리, 읽기 부하 분리처럼 수치가 남는 문제 해결 신호는 충분하지만, 결제 플랫폼 테크리드에 필요한 시스템 방향 결정과 여러 이해관계자를 움직인 설계 오너십은 아직 기록이 얇습니다. 핵심 격차는 기술 실력보다 팀장이 설계 결정을 맡고 있는 구조에서 본인이 경계를 정하고 리뷰를 이끈 증거가 부족하다는 점입니다. 따라서 주력은 현 직장에서 결제 플랫폼 설계 의사결정권을 확보하는 경로로 두고, 개인 프로젝트는 이를 보강하는 설계 문서와 운영 실험에 제한하는 편이 맞습니다. 신규 설계 기회와 리뷰 권한이 계속 막히면 그때 실트래픽 결제 조직으로 이직을 검토합니다.

🔍 커리어 돌아보기

세움페이

  • 정산 배치 재설계와 결제 API 개선은 운영을 넘어 개선 단계로 판정됩니다. 일 정산 배치를 기간 분할과 병렬 처리로 바꿔 4시간 20분을 1시간 20분으로 줄였고, 느린 조인 쿼리 두 건을 실행계획으로 좁혀 p99를 1.9초에서 0.8초로 낮췄습니다.
  • 난이도는 결제 승인, 정산, PG 원장처럼 실패 비용이 큰 영역을 다뤘다는 점에서 중간 이상입니다. 다만 처리량, 트래픽 규모, 장애 빈도와 변경 전후 오류율이 모두 기록된 것은 아니어서 시스템 전체 설계 난이도까지는 판정할 수 없습니다.
  • 멱등키 처리, 읽기 전용 복제본 분리, 공통 PG 인터페이스 정의는 동시대 백엔드 시장이 보는 DB·신뢰성·확장성 신호에 해당합니다. 특히 중복 승인 신고를 월 21건에서 0건으로 만든 기록은 결제 도메인에서 재현 가능한 문제 해결 근거입니다.

온새로시스템

  • 주문 생성·취소 상태 전이를 명시하고 저장 프로시저 로직을 애플리케이션 코드로 옮긴 일은 개선 단계로 볼 수 있습니다. 재고 동기화를 큐 기반 처리로 바꿔 불일치 신고를 주 12건에서 2건으로 줄였고, 배치 실패 재처리 큐도 만들었습니다.
  • 외부 창고 시스템과 주문 상태를 맞춰야 했으므로 단순 CRUD보다 상태 정합성 난도가 높았습니다. 다만 당시 트래픽, 메시지 보장 방식, 장애 재처리 정책은 기록에 없어 설계 레벨의 깊이는 일부 판정 불가입니다.
  • 모니터링 대시보드와 오류 알림을 도입한 경험은 현재의 런북·대사 자동화로 이어지는 운영 기반입니다. 큐와 애플리케이션 코드 이관은 현재 시장과 맞지만, 클라우드 운영·배포 자동화·SLO 기록은 커리어 데이터에서 확인되지 않습니다.

정산 규칙 시뮬레이터

  • 가맹점 수수료와 정산 주기 조합으로 예상 정산액을 계산하는 도구를 직접 설계·구현했으므로 개인 프로젝트 안에서는 설계 단계에 해당합니다. 정책 변경 논의에서 계산 결과를 먼저 제시했다는 점은 도메인 규칙을 코드와 의사결정 자료로 연결한 사례입니다.
  • 결제·정산 규칙을 실제 서비스의 입력 경계와 연결할 가능성은 높지만, 현재 기록에는 배포 방식, 테스트 수, 규칙 버전 관리, 사용자 수가 없습니다. 따라서 운영 난이도와 확장성은 아직 판정 불가이며 다음 기록에서 산출물 범위를 남겨야 합니다.
  • 승인·취소·부분취소·망취소 경계를 사례별로 정리해 팀 위키에 올린 것은 도메인 지식의 문서화 신호입니다. 다만 개인 프로젝트 자체만으로 실서비스 장애 대응이나 대규모 결제 트래픽 운영을 증명할 수는 없습니다.

📍 현재 위치

백엔드 성장 사다리에서 티켓 구현 단계는 이미 지났고, 결제·정산 도메인의 미들 후반부인 개선 및 일부 설계 단계에 있습니다. 정산 배치, p99, 멱등성, 읽기 부하를 수치로 진단하고 구조를 바꾼 기록은 연차에 맞는 실질을 보여줍니다. 다만 현재 서버 팀 7명에서 설계 결정은 팀장이 맡고 있어 테크리드의 핵심인 시스템 경계 결정과 설계 리뷰 주도는 아직 현재 직함보다 뒤에 있습니다.

강점

  • 최근 기록에서 p99를 일주일간 수집한 뒤 실행계획을 분석하고 인덱스와 조회 기간을 바꿔 1.9초에서 0.8초로 낮췄습니다. 시장에서는 감으로 성능을 다루지 않고 분포와 병목을 찾아 조치하는 백엔드 신호로 읽힙니다. 목표 직무에서는 결제 플랫폼의 성능 기준을 정하는 기반으로 쓸 수 있습니다.
  • 멱등키 적용으로 두 달간 중복 승인 신고 0건을 남겼고, 재시도와 타임아웃이 겹치는 원인을 로그에서 특정했습니다. 이는 결제 도메인의 실패 모델을 요청 처리 구조로 바꿀 수 있다는 뜻입니다. 테크리드 역할에서 승인·취소·재시도 정책의 설계 근거가 됩니다.
  • 신규 PG 두 번째 연동을 공통 인터페이스 위에 붙여 3주를 9일로 줄였고, 장애 런북 9개 시나리오와 PG 모의 서버 40여 개 시나리오를 기록했습니다. 시장에서는 반복 연동과 장애 대응을 개인 감각이 아니라 재사용 가능한 경계와 문서로 바꾸는 신호입니다. 목표 대비로는 플랫폼화의 출발점이 있지만, 아직 최종 설계권과 리뷰 운영까지 확장해야 합니다.

공백

  • 현재 기록에는 본인이 최종 승인한 아키텍처 결정과 반대 의견을 조정한 과정이 없습니다. 테크리드는 구현 결과보다 DB·캐시·비동기·정합성의 trade-off를 정하고 팀의 선택을 남기는 역할이므로 이 공백이 가장 큽니다. 팀장 설계 아래의 실행 성과만으로는 목표 직무의 오너십을 완전히 증명하기 어렵습니다.
  • 장애 런북과 성능 개선 기록은 있으나 SLO, error budget, 부하 테스트, 장애 포스트모템의 반복 운영 기록은 없습니다. 플랫폼 테크리드는 개별 장애를 고치는 데서 끝나지 않고 신뢰성 기준과 우선순위를 정해야 합니다. 현재 회사에서 결제 흐름 하나의 SLO와 설계 리뷰를 직접 맡아야 이 공백이 줄어듭니다.

🧭 목표 대비 격차

이미 준비된 것

  • 결제 승인, 정산 배치, PG 연동, 원장 대사까지 핵심 결제 흐름을 실제 운영 환경에서 다뤘습니다. 목표 가이드가 요구하는 도메인 하나의 오너십으로 가는 재료가 있으며, 현 직장에서 승인·정산 경계를 묶은 설계 문서로 확장할 수 있습니다.
  • 병렬 배치로 69% 단축, p99 58% 단축, 대사 시간 89% 단축, 쓰기 노드 CPU 평균 78%에서 50%대로 감소한 수치가 있습니다. 문제 발견과 전후 측정 능력은 이미 시장에 전달할 수 있으므로 A에서 설계 의사결정 기록을 붙이고 B에서 공개 가능한 축약 사례를 정리하면 됩니다.

비어 있는 것

  • 시스템 경계와 데이터 정합성 정책을 본인이 결정한 증거가 비어 있습니다. 테크리드는 기능 구현이 아니라 승인·취소·대사·재처리의 책임 경계를 정하고 trade-off를 설명해야 하므로 핵심 격차입니다. 현 직장에서 결제 상태 모델과 재처리 정책의 설계 문서 오너를 맡는 A가 우선이고, B는 문서와 시뮬레이터로 보강합니다.
  • 팀 단위 설계 리뷰와 기술 방향 합의 기록이 부족합니다. 현재 회사에서는 설계 결정을 팀장이 내린다고 했으므로, 리뷰 참석자가 누구였고 어떤 의견이 반영됐는지 남기는 경험이 목표 직무의 주도 신호가 됩니다. A에서 리뷰를 자원하고, 권한이 없으면 B에서 ADR과 리뷰 요청 흐름을 공개 가능한 형태로 만듭니다.
  • 서비스 신뢰성 지표의 소유 경험이 비어 있습니다. 런북 9개 시나리오는 운영 기준의 시작이지만 SLO, 오류 예산, 포스트모템까지 있어야 플랫폼 수준의 판단으로 읽힙니다. A에서 승인 API와 정산 배치의 지표를 정하고, B에서는 부하·장애 실험으로 실서비스 규모를 과장하지 않은 보조 증거를 만듭니다.
  • 대규모 트래픽과 여러 개발자 조직의 조정 경험은 개인 프로젝트로 증명할 수 없습니다. 현재 데이터에는 팀장이 설계를 맡는 구조만 확인되므로 먼저 현 직장에서 권한을 요청하고, 신규 설계가 구조적으로 계속 차단되면 C의 실트래픽 결제 플랫폼 회사에서 메워야 합니다.

🔀 경로 선택

주력경로 A · 현 직장

현 직장에서 결제 상태 경계, SLO, 설계 리뷰를 맡는 데 주당 업무 시간의 일부를 우선 배분하세요. 가장 빠르게 부족한 최종 결정권과 팀 합의 기록을 만들 수 있습니다.

병행경로 B · 개인 프로젝트

개인 프로젝트는 주 3시간 이내로 제한하고 상태머신 실험 또는 PG 모의 서버 설계 문서 하나만 90일 안에 완성하세요. 현업 권한을 대체하지 않고 설계 사고를 보여주는 보조 증거로 사용합니다.

보류경로 C · 이직

즉시 이직은 보류하고 1~2분기 동안 ADR·리뷰·SLO 역할 부여 여부를 확인하세요. 설계권 거절이 반복되거나 신규 설계 과제가 계속 배정되지 않으면 그 시점에 이직 탐색을 시작합니다.

🏢 경로 A · 현 직장 안에서

결제 경계 설계 오너십

다음 결제 변경 과제에서 승인·취소·부분취소·망취소·대사의 책임 경계를 정하는 ADR 작성을 먼저 자원하세요. 현재는 멱등키와 PG 공통 인터페이스를 구현했지만 최종 설계 결정은 팀장이 맡고 있어, 이 일을 해야 실행 경험이 설계 오너십으로 바뀝니다. ADR 원문, 대안 2개 이상, 정합성·재처리 trade-off, 리뷰어 의견과 채택 이유를 저장하세요.

SLO 기준선 제안

결제 승인 API와 정산 배치에 대해 성공률, p99, 처리 완료 시각, 재처리 건수를 포함한 SLO 초안을 제안하세요. p99를 1.9초에서 0.8초로 낮춘 기록과 배치 시간을 4시간 20분에서 1시간 20분으로 줄인 기록이 있으므로 다음 단계는 개선 전후 수치가 아니라 운영 기준의 소유입니다. 대시보드 캡처, 기준선, 월별 위반 횟수, 대응 기록과 포스트모템 1건을 남기세요.

설계 리뷰 진행권

서버 팀 7명 중 관련 개발자와 함께 PG 연동 또는 재처리 설계 리뷰를 직접 진행하고 회의 전 초안과 회의 후 결정본을 배포하세요. 두 번째 PG 연동을 공통 인터페이스로 3주에서 9일로 줄였지만, 목표 직무에는 다른 개발자의 설계 선택을 조정한 기록이 추가로 필요합니다. 리뷰 참석자, 쟁점, 반대 의견, 결정 변경, 후속 작업의 담당자와 기한을 기록하세요.

장애 복구 훈련 운영

기존 런북 9개 시나리오 중 중복 승인, PG 지연, 대사 불일치 시나리오를 골라 분기별 모의 장애 훈련을 제안하세요. 이미 야간 1차 판단 절차와 PG 모의 서버 40여 개 시나리오가 있으므로 훈련 결과까지 남기면 문서 작성에서 복구 체계 설계로 올라갈 수 있습니다. 탐지 시간, 판단 시간, 차단 여부, 복구 시간, 런북 수정 내역을 매회 저장하세요.

🧪 경로 B · 개인 프로젝트로

결제 상태머신 실험

승인·취소·부분취소·망취소·망취소 재처리의 상태 전이를 입력받고 중복 요청과 지연 응답을 검증하는 작은 시뮬레이터를 완성하세요. 상태 다이어그램, 불변조건, 실패 시나리오 테스트와 규칙 버전 이력이 있어야 시장에서 도메인 설계 신호로 읽히며, 단순 계산 화면만 있으면 부족합니다. 4주 안에 실행 가능한 저장소, 설계 문서, 테스트 결과와 사례별 출력물을 남기세요.

정산 부하 실험장

현재 정산 규칙 시뮬레이터에 기간 분할, 병렬 처리, 실패 구간 재시도 모델을 추가하고 입력 규모별 처리 시간과 실패율을 비교하세요. 실제 세움페이 배치가 4시간 20분에서 1시간 20분으로 줄어든 경험을 일반화하되, 개인 실험 결과를 실서비스 트래픽으로 포장하지 않고 부하 조건과 한계를 명시해야 합니다. 5주 안에 부하 시나리오, 전후 결과 그래프, 병목 분석, 설계 선택 기록을 산출물로 만드세요.

PG 연동 설계 공개본

두 PG의 승인·취소·타임아웃·재시도 차이를 가정한 어댑터 구조와 모의 서버를 만들어 공통 인터페이스의 장단점을 기술 글과 저장소로 정리하세요. 응답 코드, 지연, 중복 요청을 재현하고 인터페이스가 깨지는 경우까지 설명해야 하며 코드만 올리면 테크리드 신호가 약합니다. 3주 안에 아키텍처 그림, ADR 2건, 모의 시나리오 목록과 테스트 실행 결과를 남기세요.

개인 프로젝트로는 안 되는 것

개인 프로젝트로는 실서비스의 대규모 트래픽, 실제 온콜 판단, 장애 복구 책임, 여러 개발자 조직의 합의 조정을 증명할 수 없습니다. 이 격차는 현 직장에서 SLO와 장애 훈련을 맡거나, 그 기회가 구조적으로 없으면 실트래픽 결제 플랫폼의 서버 팀으로 이직해 메워야 합니다.

🧳 경로 C · 이직 관점

현 시점에 즉시 이직이 필요하다고 보기는 어렵습니다. 세움페이에서 결제·정산 도메인을 맡고 있고 현재 성과도 수치화되어 있어, 먼저 설계 리뷰와 SLO 오너십을 1~2분기 요청하는 편이 비용이 낮습니다. 그 기간에도 팀장 승인 아래 구현만 반복되고 ADR·리뷰·운영 기준을 맡지 못하면 이직 필요성이 커집니다.

성장 중 결제 플랫폼

결제 승인과 정산 트래픽이 커지는 중간 규모 커머스·핀테크·결제 플랫폼 회사를 우선 보세요. 현 직장에서 ADR 2건, 설계 리뷰 2회, SLO 기준선과 장애 훈련 기록을 만든 뒤 지원해야 실무 신호가 선임 개발자 타이틀보다 앞섭니다. 현재는 결제·정산 개선과 운영 수치는 통하지만, 최종 아키텍처 결정의 범위는 아직 확인이 필요합니다.

플랫폼 전담 서버팀

서버 팀과 플랫폼 또는 신뢰성 역할이 분리되어 개발자 경험과 결제 공통 계층을 설계하는 회사가 적합합니다. 현 회사에서 설계권 요청이 두 차례 거절되거나 90일 동안 리뷰 오너 역할이 부여되지 않을 때, 문서와 수치 증거를 갖춰 탐색을 시작하세요. 멱등성·PG 추상화·DB 읽기 분리는 강점이지만, 팀 간 표준을 정한 경험은 아직 통하지 않습니다.

고신뢰 금융 도메인

거래 정합성과 장애 복구를 핵심으로 두는 핀테크 또는 금융 인프라 회사도 후보입니다. 결제 상태 모델, 대사 자동화, 재처리 정책을 하나의 포트폴리오로 정리하고 SLO 위반 및 복구 기록을 확보한 뒤 검토하세요. 현재 경험은 금융성 도메인과 가깝지만 회사 외부 규모와 규제 환경 경험은 커리어 데이터에 없어 지원 전 확인이 필요합니다.

🎯 단기 목표 (분기)

  • 결제 상태 경계 설계경로 A · 현 직장

    달성 판정: 승인·취소·부분취소·망취소·대사 책임 경계를 담은 ADR 1건과 리뷰 결과, 채택된 결정 및 후속 작업을 기록하면 달성입니다.

  • 결제 SLO 기준선 수립경로 A · 현 직장

    달성 판정: 승인 p99와 성공률, 정산 완료 시각과 재처리 건수의 기준선 및 대시보드 1개를 만들고 한 차례 이상 위반 대응 기록을 남기면 달성입니다.

  • 상태머신 검증 도구 완성경로 B · 개인 프로젝트

    달성 판정: 상태 전이 다이어그램, 실패 시나리오 테스트 10건 이상, 실행 결과와 설계 문서를 개인 저장소에 남기면 달성입니다.

내 목표로 만들어보기 →달성 판정에 적힌 것을 남기면, 다음 리포트가 그 진척을 반영해요.

⚠️ 리스크·막힘 지점

  • 서버 팀 7명에서 팀장이 모든 설계 결정을 계속 맡아 ADR 오너와 리뷰 진행권을 주지 않을 수 있습니다.

    대안결제 상태 경계와 PG 연동 ADR 초안을 먼저 작성해 리뷰를 요청하고, 90일 동안 권한이 없으면 실트래픽 결제 플랫폼 채용 탐색으로 전환합니다.

  • 장애 대응과 운영 업무가 몰려 주당 개인 프로젝트 시간을 확보하지 못할 수 있습니다.

    대안개인 프로젝트 범위를 상태머신 검증 1개로 줄이고 주 3시간만 배정하며, 실제 회사의 모의 서버 시나리오와 설계 문서 기록을 우선합니다.

자주 묻는 질문

개발자 커리어 로드맵은 어떻게 세우나요?
이력서 한 장이 아니라 그동안의 프로젝트 경험과 커리어 기록(Work Log)에 남은 문제 해결 사례, 목표로 하는 직무를 함께 읽어 현재 실력 수준과 목표 사이의 격차를 짚고, 그 격차를 좁히는 구체적 경로를 제시해요.
이미 회사에서 리드 역할을 하고 있는데도 로드맵이 필요한가요?
네. 암묵적으로 맡고 있는 역할이 공식 직함이나 이력서로 증명되지 않으면 이직·승진 시장에서는 보이지 않는 경험이 됩니다. 로드맵은 그 역할을 어떤 기록으로 드러내야 하는지, 현 직장에서 공식화할지 이직으로 전환할지까지 짚어줘요.

이력서 자체가 고민이라면 백엔드 개발자 이력서 피드백·진단 예시도 함께 보세요.

내 커리어 로드맵은 어떤 모습일까요?

가상 예시가 아니라 직접 쌓아온 커리어 데이터와 기록으로 내 리포트를 받아보세요.

내 로드맵 만들기 →