작년에 친구 한 명의 이력서를 봐준 적이 있어요. 중견 IT 회사에서 2년 정도 백엔드 개발을 했고, 한 달 넘게 이직 지원을 했는데 면접이 거의 안 잡혔대요. 이력서를 받아서 경력사항 부분을 보니 이렇게 쓰여 있었어요.
주문 시스템의 일상적인 개발과 유지보수를 담당했으며, 요구사항 검토, API 개발, 버그 수정에 참여하고 테스트 지원과 버전 배포를 진행했습니다.
그래서 제가 말했어요. 이건 경력이 아니라 출근 기록이라고. 이 직무를 하는 사람이라면 누구든 시스템 이름만 바꿔서 자기 이력서에 똑같이 쓸 수 있는 문장이잖아요.
사실 이게 대부분 사람들의 문제예요. 쓸 내용이 없어서가 아니라, 2년 동안 한 일을 누구나 쓸 수 있는 한 줄로 만들어 버렸다는 점이요.
면접관이 경력사항에서 진짜 보는 것
관점을 한번 바꿔볼까요. HR이나 실무 면접관이 이력서를 볼 때, 한 장당 평균 10~20초밖에 들이지 않아요. 경력사항은 그중에서도 가장 오래 보는 부분인데, 진짜 찾는 건 '무엇을 했는지'가 아니라 다음 세 가지 정보예요.
- 어떤 환경에서 일했는지 — 대기업인지 작은 팀인지? 성숙한 비즈니스인지 처음부터 시작한 건지?
- 어떤 역할이었는지 — 책임자였는지, 아니면 계속 업무를 받기만 한 사람인지?
- 떠날 때 무엇을 남겼는지 — 시스템을 정상적으로 운영한 건지, 아니면 어떤 지표에 실질적인 변화를 만들었는지?
세 번째 질문이 특히 중요해요. 많은 사람들이 '재직 중에 무엇을 했는지'만 설명하는데, 면접관이 진짜 궁금한 건 '당신이 했기 때문에 상황이 이전과 어떻게 달라졌는지'예요. 비슷해 보이지만 글로 쓰면 완전히 달라져요.
비유를 하나 들어볼게요. 식당에 요리사로 지원한다고 생각해 보세요. 이력서에 '매일 채소 썰고, 요리하고, 설거지했습니다'라고 쓰지 않잖아요. 대신 '후라이 파트 담당, 피크 시간대 회전율 80접시, 입사 3개월 만에 시그니처 메뉴 반품률 6%→1.5%로 개선'이라고 쓰겠죠. 기업도 마찬가지예요.
원리는 간단한데, 막상 이력서 앞에 앉으면 다들 잊어버려요. 실제로 제가 만났던 5가지 사례를 하나씩 뜯어볼게요. 업계도, 상황도 다 다르지만 근본적인 문제는 놀라울 정도로 똑같아요.
사례 1: 경력은 있는데 '뭐든 했다'로 써버린 경우
배경: A 씨, 프론트엔드 개발 2년 반 차. 시리즈 B 스타트업에서 2년 근무, 프론트엔드 팀은 겨우 3명이라 온갖 일을 다 했어요. 이력서에는 이렇게 썼더군요.
회사의 여러 제품군 웹 프론트엔드 개발을 담당했습니다. 관리자 백오피스, H5 이벤트 페이지, 미니프로그램 등을 포함합니다. React와 Vue 기술 스택을 사용했고, 제품 팀 및 백엔드 팀과 협력해 요구사항을 구현했습니다. 컴포넌트 라이브러리 구축과 유지보수에도 참여했습니다.
첫인상은 나쁘지 않은데, 자세히 읽으면 문제가 보여요. 말은 많지만 실체가 없어요. '여러 제품군'이 몇 개인지? '컴포넌트 라이브러리 구축'을 본인이 주도했는지 남이 만든 걸 가져다 썼는지? '제품 팀 및 백엔드와 협력' — 프론트엔드 개발자라면 당연히 하는 일이잖아요. 이건 정보가 아니에요.
실제로 A 씨의 진짜 이력은 꽤 괜찮았어요. 관리자 백오피스를 혼자서 처음부터 구축했고, H5 이벤트 페이지는 가장 큰 캠페인이 PV 100만을 넘겼으며, 컴포넌트 라이브러리도 본인이 주도해서 만들고 다른 두 명의 프론트엔드 개발자가 모두 사용 중이었거든요.
그런데 이런 내용이 이력서에는 단 한 글자도 안 담겨 있었어요. 포장을 못한 게 아니라, 이 정보들이 값어치가 있다는 걸 전혀 몰랐던 거예요.
수정 후:
사내 관리자 백오피스의 프론트엔드 아키텍처를 독자적으로 구축(React + TypeScript), 프로젝트 초기화부터 배포까지 전 과정을 주도했으며 운영, CS, 데이터 세 개 부서의 일상 업무를 지원했습니다.
팀 내부 컴포넌트 라이브러리 구축을 주도, 폼·테이블·모달 등 비즈니스 공통 컴포넌트 30종 이상을 축적했으며 팀원 전원이 도입해 신규 기능 개발 효율이 크게 향상되었습니다.
마케팅 H5 이벤트 페이지 개발 담당(Vue), 단일 캠페인 최대 PV 120만+ 달성, 캠페인 기간 중 무중단 운영.
이 버전은 '무엇을 했는지'가 아니라 '어느 수준까지 해냈는지'를 보여줘요. 면접관은 이 한 줄에서 기술 스택, 독립 실행 능력, 팀 영향력까지 단번에 읽을 수 있어요. A 씨는 이 버전으로 2주 만에 면접 제의가 거의 세 배로 늘었어요.
사례 2: 잦은 이직, 불안정해 보일까 봐 애매하게 쓴 경우
배경: B 씨, 3년 동안 세 곳을 옮겼고, 그중 한 곳은 7개월밖에 안 다녔어요. 이직이 너무 잦아 보여서 걸러질까 걱정된 나머지, 각 회사 경력을 엄청 짧고 모호하게 썼어요. '조용히' 넘어가면 티가 안 날 거라고 생각한 거죠.
결과는 정반대였어요. 애매하게 쓸수록 면접관은 그 부분만 더 들여다봐요. 긍정적인 정보가 전혀 안 보이니까 더 안 좋은 쪽으로 상상하게 되는 거예요.
7개월짜리 경력을 이렇게 써놨더라고요.
전자상거래 플랫폼 프로모션 모듈 개발에 참여, 타임딜과 공동구매 기능의 API를 구현했습니다.
그래서 물어봤어요. 이 경력, 도대체 무슨 일이었냐고. 알고 보니 그 회사는 7개월밖에 안 다녔지만 프로젝트 단위로 따라간 거였어요. 입사했을 때 프로젝트가 막 시작됐고, 타임딜 모듈의 설계부터 배포까지 전 과정을 혼자 맡았대요. 프로젝트가 끝난 후 회사의 사업 방향이 바뀌면서 HR과 합의하에 퇴사한 거고요. 오히려 이 기간이 3년 중 기술적으로 가장 많이 성장한 시기였대요.
수정 후:
입사 직후 타임딜 모듈의 설계 및 개발을 독자적으로 맡아, 재고 선차감·트래픽 제한 및 서킷브레이커·비동기 주문 등의 핵심 로직을 구현했습니다. 배포 후 12월 대규모 프로모션에서 피크 QPS 4500+를 처리하며, 초과 판매 사고 제로를 기록했습니다.
공동구매 모듈 API 개발도 동시에 진행, 그룹 개설·참여·완료 콜백까지 전체 플로우를 커버했으며, 배포 첫 달 공동구매 주문 비중이 15%에 도달했습니다.
보이시죠? 숨기려 하지 말고 제대로 설명하는 게 훨씬 낫다는 걸. 특히 단기 경력일수록 더 그래요. 애매하게 쓰면 면접관은 계속 의심하고, 구체적으로 쓰면 오히려 이해해 줘요. 진짜 그 일을 한 사람만이 이 정도 디테일을 쓸 수 있으니까요.
참고로 하나 덧붙이자면: 이직이 잦다는 것 자체는 치명적이지 않아요. 진짜 치명적인 건 '잦은 이직 + 이력서에서 매번 어떤 걸 쌓았는지 전혀 보이지 않는 것'이에요. 각 경력마다 뚜렷한 역량 성장 궤적이 보이면, 면접관들은 이직 횟수만으로 걸러내지 않아요.
사례 3: 같은 회사에서 5년 이상 근무한 경우
배경: C 씨, 전통적인 소프트웨어 회사에서 6년간 Java 개발을 했어요. 이력서에 경력사항은 딱 한 줄이고, bullet point가 7~8개 정도 나열되어 있었어요. 대략 이런 식이었죠.
- XXX 관리 시스템 개발에 참여
- YYY 모듈 유지보수 담당
- 요구사항 담당자와 협력하여 ZZZ 기능 개선
- ……
6년을 이렇게 써놓으면 큰일 나요. 한 곳에 오래 있었을수록 '계속 같은 일만 한 것처럼' 보이면 절대 안 돼요. 면접관이 6년짜리 경력 하나에 직급 변화도, 업무 깊이도 전혀 안 보이면 가장 먼저 드는 생각은: '이 사람, 6년 동안 제자리걸음이었나?'예요.
하지만 C 씨의 진짜 상황은 전혀 달랐어요. 6년 동안 처음 2년은 비즈니스 개발, 중간 2년은 인프라팀으로 이동해서 미들웨어 작업, 마지막 2년은 다시 비즈니스 라인으로 돌아와 3명 규모의 작은 팀을 이끌며 신규 사업 방향을 탐색했거든요.
수정 후, 세 단계로 분리:
시니어 Java 개발 엔지니어 (최근 2년)
3인 팀을 이끌며 신규 비즈니스 라인을 0에서 1까지 구축, 시스템 아키텍처 선정, 핵심 모듈 개발, 팀 기술 표준 수립을 주도했으며, 비즈니스 런칭 후 현재까지 안정적으로 운영 중입니다.Java 개발 엔지니어 / 인프라 (중간 2년)
인프라팀으로 이동, 전사 메시지 미들웨어의 2차 개발 및 유지보수를 담당했습니다. 클러스터 메시지 적체 문제와 소비 지연을 해결하여, 일 평균 수천만 건의 메시지 전송을 안정적으로 지원하게 되었습니다.Java 개발 엔지니어 / 비즈니스 라인 (초기 2년)
회사의 핵심 비즈니스 시스템 개발에 참여, 주문·재고 등 모듈의 설계와 구현을 독자적으로 맡았으며, 요구사항 분석부터 배포까지 전 과정을 담당했습니다.
같은 회사, 같은 사람인데 세 단계로 나누니까 면접관이 보는 그림이 완전히 달라져요. '기술 깊이가 꾸준히 성장하고 있고, 책임 범위도 점점 넓어지고 있는 사람'으로 보이게 되는 거예요. 한 회사에 오래 있었던 지원자에게 이게 바로 가장 중요한 시그널이에요.
비슷한 상황이라면, 한 회사라도 여러 단계로 나눠서 역할 변화를 통해 성장을 보여주는 걸 추천해요. 꼭 정식 승진이 아니어도 괜찮아요. 하는 일이 바뀌었거나, 책임 범위가 달라졌다면 그걸 기준으로 나누면 됩니다.
사례 4: 전직 — 이전 경력이 지금 지원하는 분야와 무관한 경우
배경: D 씨, 3년 동안 오프라인 행사 기획을 했고, 인터넷 업계의 유저 오퍼레이션(사용자 운영)으로 전직을 희망했어요. 처음에는 '행사 기획' 경력을 최대한 오퍼레이션 쪽으로 끼워 맞추려고 했어요. '유입', '활성화', '리텐션' 같은 용어를 잔뜩 썼지만 전부 겉도는 느낌, 억지로 맞춘 듯한 인상이었죠.
그런데 대화를 나누다 보니, 오퍼레이션 관점에서 충분히 풀어낼 수 있는 경험이 하나 있었어요. 다만 본인은 그걸 '행사 기획의 일부'라고만 생각해서 전혀 의식하지 못했던 거예요.
오프라인 세미나 행사의 전체 총괄을 담당했습니다. 장소 섭외, 물품 준비, 현장 진행 및 사후 리뷰 보고를 포함합니다.
이 문장과 인터넷 오퍼레이션의 연결고리를 본인은 전혀 못 찾았어요. 그래서 제가 몇 가지 질문을 했어요. 행사 참여자는 어떻게 모았는지? (답: 온라인 커뮤니티에서 모집했어요.) 몇 명 정도 왔는지? (평균 회당 80~120명이요.) 행사 끝나고 후속 조치는? (커뮤니티로 유입시켰고, 전환율은 30% 정도예요.) 콘텐츠 산출물은 있었는지? (매회 게스트 발표가 있었고, 이미지와 숏폼 영상으로 만들었어요.)
수정 후:
오프라인 세미나를 20회 이상 기획·운영, 누적 참여자 2,000명+ 달성: 온라인 커뮤니티에서 사용자 모집 및 선별을 진행했으며, 회당 실제 참석률 85% 이상을 안정적으로 유지했습니다. 행사 후 커뮤니티를 통한 참여자 관리 및 콘텐츠 배포를 통해, 참석자의 커뮤니티 사용자 전환율 30%를 기록했습니다.
게스트 발표 콘텐츠를 이미지 및 숏폼 영상으로 재가공, 공식 계정과 영상 채널에 동시 배포했으며, 누적 콘텐츠 60건 이상, 평균 조회 수 3,000+를 달성했습니다.
이 버전이 통하는 이유는 오퍼레이션 용어를 억지로 넣어서가 아니에요. '모집 → 참석 → 유입 → 전환 → 콘텐츠 배포'라는 흐름 자체가 유저 오퍼레이션의 핵심 사이클과 일치하기 때문이에요. 전직을 하는 분들이 가장 조심해야 할 것은 용어를 억지로 갖다 붙이는 거예요. 오히려 해야 할 일은, 지금까지 해온 일을 목표 직무의 언어로 다시 번역하는 것 — 그 전에 먼저, 내 경험과 그 직무가 진짜로 겹치는 지점을 찾아내는 게 먼저예요.
사례 5: 경력사항에 기간을 안 쓰거나 연도만 쓰는 경우
이건 짧지만 꼭 짚고 넘어가야 할 부분이에요. '2019 - 2021'처럼 월을 빼고 연도만 쓴다거나, 아예 기간 자체를 안 쓰는 분들을 꽤 많이 봤어요. 이유를 물어보면 보통 이런 답변이 돌아와요.
한 군데 너무 짧게 다녀서 보기 안 좋아서요.
한두 달 공백기를 어떻게 설명해야 할지 몰라서요.
근무 기간을 계산해 보면 경력이 짧아 보일까 봐요.
솔직히 이런 걱정은 이해가 돼요. 하지만 기간을 안 쓰는 게 쓰는 것보다 훨씬 더 위험해요. 면접관은 기간 정보가 빠져 있으면 '뭔가 숨기고 싶은 게 있구나'라고 생각하지, '아, 깜빡했나 보네'라고 생각하지 않아요. 이 가정이 한 번 생기면, 나머지 모든 경력 정보에 대한 신뢰도까지 같이 깎여요.
정말 짧은 경력이나 공백기가 있다면, 더 나은 방법은 이거예요: 기간은 그대로 쓰고, 그 기간에 무엇을 했는지도 이력서에 써넣는 거예요. 비정규직이나 개인 활동이라도 괜찮아요.
예를 들어 2개월짜리 공백기가 있다면 이렇게 쓸 수 있어요.
2023.04 - 2023.06 | 개인 학습 기간: 분산 시스템 강의를 체계적으로 수강하고, 관련 프로젝트 실습 2건을 완료했습니다.
이게 빈칸으로 남겨두는 것보다 훨씬 낫다는 건 말 안 해도 아시겠죠. 면접관은 공백 자체를 두려워하지 않아요. 두려워하는 건 공백기에 아무것도 안 했거나, 더 안 좋은 건 — 숨기려고 하는 태도예요.
지금 바로 적용할 수 있는 6가지 재작성 원칙
내 경력을 사례 하나하나 대조해 보기 어렵다면, 이 6가지 원칙만 기억하고 경력사항 전체를 한 번 훑어보세요.
1. 직무 설명서 말고, 개인 성과를 써라
나쁨: 백오피스 관리 시스템의 개발과 유지보수를 담당.
좋음: 백오피스 관리 시스템의 프론트엔드 아키텍처를 독자적으로 맡아, 제로 베이스에서 구축부터 납품까지 완료했으며 운영·CS 두 부서의 일상 업무를 지원.
2. '참여'라고 쓰지 말고, 구체적으로 무엇을 했는지 써라
나쁨: 주문 시스템 최적화에 참여.
좋음: 주문 조회 체인 최적화를 주도, 핵심 API의 P95 응답 시간을 820ms에서 140ms로 단축.
3. 경력 하나당 최소 하나 이상의 숫자를 넣어라
숫자가 꼭 '몇 % 개선'일 필요는 없어요. 담당 시스템의 사용자 수, 처리한 데이터량, 작성한 API 개수, 지원한 사업 부서 개수, 협업한 부서 수, 이끈 팀 규모도 모두 좋은 숫자예요.
도저히 숫자를 찾을 수 없다면, 최소한 범위라도 써보세요. 예를 들어 '주문·결제·환불 세 가지 핵심 프로세스를 커버'라고 쓰면 '백엔드 개발에 참여'보다 훨씬 구체적이잖아요.
4. 같은 회사에 오래 있었다면, 단계별로 나눠서 써라
꼭 직함 변화가 있어야만 나눌 수 있는 게 아니에요. 맡은 업무가 바뀌었거나, 책임 범위가 달라졌거나, 기술 스택이 변경되었다면 그걸 기준으로 나누면 됩니다.
5. 단기 경력을 숨기지 마라
그 기간에 무엇을 했고 무엇을 배웠는지 구체적으로 쓰는 편이, 빈칸보다 훨씬 안전해요. 면접관은 모르는 걸 무서워하지, 아는 건 무서워하지 않아요.
6. 경력의 디테일 수준은 연차에 맞춰라
신입: 구체적인 업무와 기술 스택을 써도 괜찮아요.
3년 차 이상: 독립성과 비즈니스 임팩트가 드러나야 해요.
5년 차 이상: '내가 한 일이 팀이나 조직에 어떤 영향을 줬는지'를 보여주는 게 가장 좋아요.
수정 후 자가 체크리스트, 이 5개면 충분합니다
- 각 경력마다 최소 하나 이상, '내' 개인 기여가 보이는 항목이 있는가 (팀 전체가 같이 한 일이 아니라)
- 숫자를 넣을 수 있는 곳에는 숫자를 넣고, 없다면 구체적인 범위라도 썼는가
- '참여', '지원', '협력'이라는 단어가 나올 때마다, 이걸 바꿀 수 있을지 스스로 물어봤는가
- 같은 회사에서 3년 이상 근무했다면, 단계별로 나눠서 썼는가
- 3개월 이상의 시간 공백이 있다면, 그 이유나 무엇을 했는지 설명했는가
여기까지 읽었는데도 여전히 내 이력서가 괜찮은지 자신이 안 든다면, DeepResume에 업로드해서 진단을 받아보세요. 성과 정량화, 키워드 커버리지, ATS 호환성 세 가지 차원에서 각 경력의 보완이 필요한 부분을 분석해 주고 구체적인 수정 방향까지 제시해 드려요.