백엔드 개발자 포트폴리오 작성 노하우 — 채용 담당자가 보는 것과 구체적 예시
백엔드 개발자 포트폴리오 작성 노하우 — 채용 담당자가 보는 것과 구체적 예시
백엔드 포트폴리오는 “무슨 기술을 썼다” 가 아니라 “어떤 문제를, 어떤 제약 안에서, 어떻게 풀었고, 그 결과가 무엇이었는지” 가 보여야 합니다. 프론트는 화면 한 장으로 설득할 수 있지만, 백엔드는 코드와 아키텍처·운영 지표가 말해 줘야 합니다.
이 글은 실제로 이력서·GitHub·Notion 포트폴리오를 검토할 때 기준이 되는 항목을 정리하고, 나쁜 예 → 좋은 예 로 바꿔 쓸 수 있는 문장·구조를 그대로 제공합니다.
1. 채용 담당자·면접관이 3분 안에 보는 것
| 순서 | 보는 것 | 왜 중요한가 |
|---|---|---|
| 1 | 한 줄 요약 | “이 사람이 어떤 백엔드 문제를 맡을 수 있는지” 즉시 판단 |
| 2 | 대표 프로젝트 1~2개 | 깊이 있는 사고의 증거 |
| 3 | 숫자·범위 | 과장이 아닌지, 스케일 감각이 있는지 |
| 4 | 본인 기여 | 팀 프로젝트에서 무엇을 책임졌는지 |
| 5 | GitHub / 문서 링크 | 말과 코드가 일치하는지 |
프론트 포트폴리오처럼 스크린샷만 크게 두면 백엔드에서는 “API가 뭐가 있지?”부터 다시 찾게 됩니다. 문제 → 설계 → 구현 포인트 → 결과(지표) 순서가 읽기 가장 빠릅니다.
2. 포트폴리오 한 페이지 구조 (복붙용 템플릿)
# 홍길동 | Backend Developer
## 한 줄 소개
Django/FastAPI 기반 B2B API 설계·운영 경험. 결제·예약 도메인에서 동시성·트랜잭션 이슈를 다룬 경력 3년.
## 대표 프로젝트 (2개만)
### [1] 티켓 예약 API — 동시성 제어
- 문제: 선착순 오픈 시 중복 예약·초과 판매
- 역할: API 설계, DB 락 전략, 부하 테스트
- 결과: 오픈 10분 3,200 req/s, 중복 예약 0건 (2주 운영)
### [2] 주문·결제 마이크로서비스 분리
- 문제: 단일 모놀리스 배포 시 결제 장애가 주문 전체 중단
- 역할: 주문/결제 경계 정의, Outbox 패턴 도입
- 결과: 결제 장애 시 주문 조회는 유지, 장애 복구 시간 40분 → 8분
## 기술 스택 (쓴 것만)
Python, Django, PostgreSQL, Redis, Celery, AWS ECS, GitHub Actions
## 링크
- GitHub: ...
- 기술 블로그: ...
- API 문서(Swagger): ...
핵심: 프로젝트는 최대 2~3개, 나머지는 “기타 프로젝트” 한 줄 링크로 접어두는 편이 낫습니다.
3. 프로젝트 1건을 쓸 때 — STAR + 기술 깊이
면접에서 자주 쓰는 STAR(Situation, Task, Action, Result)에 백엔드만의 Technical Depth 한 줄을 더합니다.
| 블록 | 질문 | 예시 문장 |
|---|---|---|
| S | 어떤 상황이었나 | 사내 B2B SaaS, 월 활성 고객사 120곳, 피크 시간 API p95 2.1초 |
| T | 내가 맡은 과제는 | 예약 슬롯 API 응답 500ms 이하, 중복 예약 0 |
| A | 무엇을 했나 | 비관적 락 → Redis 선점 + DB unique 제약으로 2단계 검증 |
| R | 결과는 | p95 380ms, 오픈 트래픽 2주간 중복 0건 |
| T (기술) | 왜 그 선택인가 | 락만 쓰면 커넥션 풀 고갈 → 선점으로 DB 부하 분산 |
나쁜 예 vs 좋은 예
나쁜 예 (기술 나열형)
Django로 REST API를 만들었습니다. JWT 인증, Celery, Redis를 사용했습니다. 배포는 AWS입니다.
좋은 예 (문제·선택·결과형)
선착순 공연 티켓 오픈에서 동시 요청 3,000건/분 시 중복 예약이 발생했습니다.
SELECT FOR UPDATE만으로는 커넥션 풀이 고갈되어, RedisSETNX로 1차 좌석 선점 후 PostgreSQLUNIQUE(seat_id, show_id)로 최종 확정하도록 설계했습니다.
k6 부하 테스트로 오픈 시나리오를 재현했고, 2주 운영 기간 중복 예약 0건, API p95 420ms → 290ms를 확인했습니다.
차이는 단순합니다. “뭘 썼다” 가 아니라 “왜 그걸 썼고, 무엇이 나아졌는지” 입니다.
4. 숫자 넣는 법 — 과장 없이 설득하기
백엔드는 측정 가능한 것이 강합니다. 없으면 솔직히 “측정 전/후 예정”이라고 쓰는 편이 낫습니다.
| 지표 종류 | 예시 표현 | 주의 |
|---|---|---|
| 트래픽 | 일 50만 요청, 피크 800 RPS | 평균만 쓰지 말고 피크도 |
| 지연 | p95 380ms, p99 720ms | 평균만 쓰면 의심받기 쉬움 |
| 가용성 | 월 가용성 99.9% | SLA 정의를 한 줄로 |
| 데이터 | 일 200만 row 적재, 파티션 12개월 | 보관·쿼리 전략과 연결 |
| 비용/효율 | RDS 비용 30% 절감 (읽기 replica 분리) | Before/After 기간 명시 |
| 팀 | 백엔드 2명, API 40개 엔드포인트 | 규모 감각 |
예시 문장
주문 조회 API가 Black Friday에 p95 3.2초까지 튀어 CS 문의가 늘었습니다.
order_itemsN+1 제거 + 커버링 인덱스 추가 후 p95 480ms, 해당 기간 CS 주문 조회 문의 62% 감소(2주 비교).
숫자가 없을 때:
부하 테스트(k6) 시나리오: 오픈 1분간 가상 사용자 500명, 좌석 1,000석 — 중복 예약 재현 후 수정, 재테스트에서 0건.
“측정은 못 했지만 재현·검증은 했다”도 가치가 있습니다.
5. 아키텍처는 그림 1장 + 본인 담당 범위
텍스트만으로도 ASCII로 충분합니다. 전체 그림과 내가 그린 박스를 구분하세요.
[Client] → [ALB] → [API (Django)] → [PostgreSQL]
↓
[Redis] ← 선점 키 seat:{show}:{seat}
↓
[Celery] → 결제 웹훅 처리
캡션 예시
위 구조에서 API·Redis 선점·DB 제약·Celery 웹훅 idempotency를 설계·구현했습니다. 인프라(Terraform)는 동료가 담당했습니다.
팀 프로젝트에서 “전체를 다 했다” 고 쓰면 면접에서 바로 파고듭니다. 경계를 명시하는 것이 오히려 신뢰를 줍니다.
6. GitHub README — 백엔드용 최소 세트
저장소만 던지면 리뷰어는 views.py부터 뒤집습니다. README에 아래를 넣으세요.
- 프로젝트 한 줄 + 해결한 문제
- 실행 방법 (
docker compose up한 줄이라도) - API 문서 링크 (Swagger/OpenAPI)
- 디렉터리 구조 (domain / infra / tests)
- 의도적 트레이드오프 (“왜 Kafka 안 썼는지”)
README 나쁜 예
# ticket-api
Django project
README 좋은 예
# ticket-api
선착순 공연 좌석 예약 API. 중복 예약 방지를 위해 Redis 선점 + DB UNIQUE 제약을 사용합니다.
## Quick start
docker compose up -d
curl http://localhost:8000/api/docs
## Architecture
- `apps/booking/`: 예약 도메인, 좌석 선점 서비스
- `apps/payment/`: 결제 웹훅 (idempotent by payment_id)
## Load test
k6 run scripts/opening_spike.js
# 시나리오: VU 500, 60s — README에 결과 스크린샷 링크
코드 품질을 보여주는 작은 디테일
tests/에 동시성·웹훅 중복 테스트 1개라도 있으면 차별화됩니다.docs/adr/001-seat-lock-strategy.md처럼 결정 기록(ADR) 이 있으면 시니어 감각으로 읽힙니다.
7. 경력별로 강조할 것
주니어 (0~2년)
- 끝까지 배포·운영해 본 토이/사이드 1개 (도메인은 단순해도 됨)
- CRUD만이 아니라 한 가지 난이도 (인증, 페이지네이션, 트랜잭션, 테스트)
- “혼자 다 했다”보다 학습 과정·실패·수정이 솔직한 글
예시 한 줄
사이드: 알림 서비스 — Celery retry 정책을 3회 exponential backoff로 바꿔 실패 알림 18% → 4% (1주 로그 기준).
미들 (3~5년)
- 장애·성능·리팩토링 스토리 1개
- 다른 팀/프론트와의 API 계약 (버전링, breaking change 대응)
- 관측 (로그 구조, 메트릭, 알람)
예시 한 줄
결제 PG 타임아웃 시 주문 상태
PENDING_PAYMENT고착 — Outbox + 재시도 워커로 24시간 내 자동 복구율 94%.
시니어
- 시스템 경계·조직적 결정 (모놀리스 분리, 팀 구조, SLA)
- 비용·리스크·일정 트레이드오프
- 후배 온보딩·코딩 컨벤션·리뷰 문화 (리더십)
8. 자주 하는 실수 7가지
| 실수 | 왜 안 통하는가 | 대안 |
|---|---|---|
| 기술 스택만 20줄 | 역량이 아니라 키워드 나열로 보임 | 프로젝트당 스택 3~5개만 |
| “팀 프로젝트”만 있고 기여 불명 | 면접에서 바로 질문 | “내가 설계/구현한 모듈” 명시 |
| 데모 URL 없음 | 백엔드는 실행·문서가 신뢰 | Swagger + docker compose |
| 평균 응답시간만 | 피크에서 무너지는 경우 많음 | p95/p99, 피크 RPS |
| 비밀 없는데 코드 비공개 | 검증 불가 | 핵심 로직만 공개 repo 또는 gist |
| AI 생성 README 그대로 | 면접에서 깊이 질문 시 불일치 | 본인 말로 다시 쓰기 |
| 프로젝트 10개 나열 | 깊이 없어 보임 | 대표 2개 + 나머지 링크 |
9. 실전: 포트폴리오 문단 Before / After (3종)
(1) 사내 레거시 API 개선
Before
레거시 API를 리팩토링했습니다. 성능이 좋아졌습니다.
After
주문 목록 API가 N+1 쿼리 47회/요청으로 p95 2.8초였습니다.
prefetch_related+ 목록용 DTO projection 도입 후 쿼리 3회, p95 410ms.
배포 전 staging에서 동일 픽스처 1만 건으로 회귀 테스트 자동화했습니다.
(2) 신규 서비스 0→1
Before
FastAPI로 채팅 서버를 만들었습니다.
After
실시간 상담 동시 접속 200명 요구. WebSocket + Redis Pub/Sub로 인스턴스 2대 수평 확장.
연결 끊김 시 마지막 읽은 message_id 기준 재동기화 API 제공.
4주 파일럿에서 메시지 유실 재현 0건(장애 주입 테스트 포함).
(3) 인프라·배포
Before
Docker, AWS 사용 경험 있음.
After
GitHub Actions로 main 머지 시 ECS 롤링 배포, 헬스체크 실패 시 자동 롤백.
배포 시간 22분 → 9분, 배포 중 5xx 비율 0.3% 이하 유지(CloudWatch 대시보드 캡처 첨부).
10. 제출 전 체크리스트 (30분 점검)
- 상단 한 줄 소개에 도메인·년차·강점 키워드 1개
- 대표 프로젝트 2개에 문제/역할/결과/숫자
- 팀 프로젝트 본인 담당 박스 표시
- GitHub README에 실행 방법 + API 문서
- 과장 없는 지표 (없으면 부하 테스트·재현 시나리오)
- 민감 정보 제거 (키, 내부 URL, 고객사 실명)
- 링크 전부 클릭 테스트 (만료된 Swagger 주의)
마무리
백엔드 포트폴리오의 본질은 “이 사람이 프로덕션에서 무엇을 걱정할 줄 아는가” 입니다. 프레임워크 이름보다 동시성, 일관성, 장애, 관측, API 계약이 문장 속에 드러나야 합니다.
위 템플릿과 Before/After만 프로젝트 2개에 맞게 채워도, 이력서·Notion·GitHub 프로필 중 어디에 두어도 면접 질문이 ‘무슨 기술 썼어요?’가 아니라 ‘왜 그렇게 설계했어요?’로 바뀌는 수준까지는 올라갑니다.
다음 글에서는 “포트폴리오용 사이드 프로젝트 아이디어 5가지 + 2주 MVP 범위” 를 주제로 정리해 볼 예정입니다.