많은 사람들이 이력서의 프로젝트 경험을 단순한 작업 목록처럼 씁니다.
예를 들면 이런 식입니다.
주문 시스템 개발에 참여했고, 캐시 최적화, API 성능 튜닝, 장애 대응을 맡았다.
겉보기엔 무난하지만, 면접관이 알고 싶은 세 가지가 빠져 있습니다.
- 어떤 문제가 있었는가
- 무엇을 했는가
- 어떤 결과가 나왔는가
이걸 정리해 주는 것이 STAR 원칙입니다.
STAR란 무엇인가
STAR는 다음 네 요소의 약자입니다.
- S = Situation: 상황, 배경
- T = Task: 과제, 역할
- A = Action: 실제 행동
- R = Result: 결과, 성과
이력서에서는 네 개를 그대로 제목처럼 쓰는 것이 아니라, 배경 → 행동 → 결과 흐름이 보이도록 만드는 것이 핵심입니다.
가장 중요한 것은 배경이 아니라, 문제를 어떻게 해결했는지 보여주는 증거입니다.
STAR를 이력서 문장으로 줄이는 방법
가장 기본적인 공식은 다음과 같습니다.
어떤 상황에서, 무엇을 담당했고, 어떻게 실행했으며, 어떤 결과를 냈는가.
하지만 이력서에서는 조금 더 압축하는 편이 좋습니다.
배경 + 행동 + 결과
예를 들면:
대규모 프로모션의 고트래픽 환경에서 주문 조회 경로를 최적화해 P95 응답 시간을 900ms에서 180ms로 단축.
이 문장은 단순 업무 설명이 아니라, 실제 성과를 보여줍니다.
사례 1: 백엔드 엔지니어
개선 전:
주문 시스템 개발에 참여해 캐시 개선과 API 성능 향상을 담당.
이 표현은 안전하지만, 기여의 깊이가 보이지 않습니다.
개선 후:
프로모션 피크 트래픽에서 주문 조회 경로를 주도적으로 개선. 느린 쿼리의 병목을 파악하고 Redis 캐시 전략을 재설계했으며 로컬 캐시 fallback도 추가했다. 주문 상세 API의 P95 지연 시간을 820ms에서 140ms로 줄였고, 피크 QPS를 3배로 높였다.
이 버전은 상황, 행동, 결과가 모두 드러납니다.
사례 2: PM
개선 전:
CRM 견적 모듈 개편을 담당했고, 업무 흐름을 최적화해 영업 경험을 개선.
이 문장만으로는 무엇이 얼마나 바뀌었는지 알기 어렵습니다.
개선 후:
영업 견적 작성 시간이 길다는 문제를 해결하기 위해 CRM 견적 모듈 개편을 주도. 영업 12명 인터뷰와 분석 데이터를 통해 중복 입력과 다단계 승인 흐름이 핵심 병목임을 확인하고, 견적 과정을 11단계에서 4단계로 줄였다. 1건당 작성 시간을 8분에서 3분으로 단축했고, 영업팀 주간 활성 사용률은 85%까지 상승했다.
PM 이력서에서는 문제 정의와 숫자로 증명되는 성과가 특히 중요합니다.
사례 3: 신입
신입은 수업 프로젝트를 단순한 결과 보고처럼 쓰기 쉽습니다.
개선 전:
학내 중고 거래 플랫폼을 혼자 구현했고, 상품 등록, 검색, 주문 관리 기능을 만들었다.
개선 후:
학내 중고 거래 상황을 기준으로 학생용 거래 플랫폼을 독립 개발. 상품 등록, 키워드 검색, 주문 매칭, 알림 기능을 구현했고, 검색 속도 문제를 해결하기 위해 카테고리 인덱스와 키워드 추천을 설계했다. 검색 응답 시간을 200ms 이내로 유지했으며, 공개 후 300명 이상의 학내 사용자가 이용했다.
신입도 공정한 성과와 고민이 있으면 충분히 강한 문장이 됩니다.
사례 4: 그로스/마케팅
STAR는 엔지니어만을 위한 방식이 아닙니다. 오히려 그로스, 마케팅, 운영 업무에서 더 잘 맞습니다.
개선 전:
SNS 콘텐츠 운영과 캠페인 진행을 맡아 브랜드 인지도를 높였다.
개선 후:
신규 사용자의 첫 주 유지율이 낮은 문제를 해결하기 위해 SNS 콘텐츠 운영과 유입 캠페인을 기획. 채널별 CTR을 보며 콘텐츠 주제를 조정하고, 광고 문안 6종을 A/B 테스트해 전환율이 가장 높은 버전을 적용했다. 월 신규 가입자는 42% 증가했고, 랜딩페이지 CVR은 3.1%에서 5.4%로 개선됐다.
단순 활동이 아니라, 수치로 성과를 보여주는 것이 핵심입니다.
자주 보이는 4가지 비교
1. 직무 설명에서 성과로
나쁜 예:
API 개발과 장애 대응을 담당.
좋은 예:
핵심 API 재설계를 주도해 오류율을 2.3%에서 0.4%로 개선.
2. 참여에서 주도로
나쁜 예:
프로젝트 개발에 참여.
좋은 예:
로그인 흐름 재설계를 주도하고 인증 모듈을 독립 구현.
3. 모호함에서 구체성으로
나쁜 예:
사용자 경험을 개선.
좋은 예:
회원가입 단계를 5단계에서 3단계로 줄이고 중복 입력 항목 7개를 제거.
4. 느낌에서 증거로
나쁜 예:
프로젝트는 잘 진행됐다.
좋은 예:
배포 후 2주 내 API 평균 응답 시간이 61% 개선되고, 고객 문의가 28% 감소.
STAR로 다시 쓰는 템플릿
다음 형식으로 쓰면 정리가 쉽습니다.
[상황]에서 [과제]를 맡아, [행동]을 통해, [결과]를 만들었다.
예시:
대규모 프로모션의 고트래픽 환경에서 주문 경로 최적화를 맡아, 캐시 재설계·API 분리·느린 쿼리 제거를 통해 P95 지연 시간을 820ms에서 140ms로 개선했다.
여기에 비즈니스 효과를 한 줄 더 추가하면 더 강해집니다.
동시에 피크 QPS는 3배 증가했고, 타임아웃 경고도 2종류 줄었다.
피해야 할 3가지 실수
1. Situation을 너무 길게 쓰기
배경은 짧으면 충분합니다. 이력서는 보고서가 아닙니다.
2. 도구 이름만 나열하기
기술 이름만 적는다고 기여가 증명되지는 않습니다. 그 기술로 무엇을 달성했는지 써야 합니다.
3. 결과를 “출시했다”로 끝내기
출시는 결과가 아닙니다. 숫자나 개선 폭이 필요합니다.
바로 쓸 수 있는 체크리스트
- 프로젝트 배경이 한눈에 보이는가
- 내 역할이 명확한가
- 행동이 구체적인가
- 결과가 측정 가능한가
- 단순 작업 기록이 아니라 기여가 보이는가
이 5개를 모두 만족하면, 프로젝트 설명은 훨씬 강해집니다.
마무리
STAR는 이력서를 보기 좋게 만드는 장식이 아닙니다. 프로젝트 경험을 증거로 바꾸는 틀입니다.
좋은 프로젝트 문장은 다음 3가지를 바로 답할 수 있어야 합니다.
- 어떤 문제가 있었는가
- 내가 무엇을 했는가
- 어떤 결과를 만들었는가
만약 아직도 문장이 모호하다면, 경험이 부족한 게 아니라 정보 정리가 부족한 것일 수 있습니다.
빠르게 점검하고 싶다면 DeepResume에 이력서를 업로드해 무료 진단을 받아보세요. 시스템이 성과 정량화, 키워드 커버리지, ATS 호환성을 기준으로 프로젝트 설명의 보완점을 구체적으로 확인해 줍니다.