합격하는 영문 레주메 작성법

레주메·커버레터 템플릿: resume_cover_letter_template.docx (Word)

국문 이력서와 가장 큰 차이는 직무 설명과 성과를 함께 써야 한다는 점이다. "무슨 일을 했다"에서 끝내지 않고 "그래서 어떤 결과가 나왔다"까지 쓴다.

무조건 한 장으로 끝낸다

• 인사 담당자는 이력서 한 장을 몇 초 안에 훑고 판단한다(레주메는 7초 안에 분류된다).
• Experience에는 인턴십, 교내 활동, 봉사, 리서치까지 적는다. 재학생·최근 졸업생은 교내 활동도 괜찮고, 리더십 포지션이었다면 더 좋다.
• 하단 Skills에는 지원 포지션이 요구하는 스킬 중 이미 가진 것만 넣는다.
• 포맷과 디테일은 지원하는 포지션과 업계 관행에 맞춘다.
• 적을수록 낫다. 평범한 성과 여러 개보다 가장 좋은 성과 몇 개가 강하다. 양을 보여 주려고 걸러지지 않은 성과를 모두 넣지 않는다.

ATS가 읽을 수 있는 서식

큰 회사는 레주메를 사람이 보기 전에 ATS(지원자 추적 시스템)로 파싱한다. 파싱이 깨지면 내용이 아무리 좋아도 읽히지 않는다. ATS가 하는 일은 미국 개발자 채용 프로세스: ATS에 있다.

일반 텍스트 테스트: 레주메 내용을 전부 복사해 메모장 같은 일반 텍스트 파일에 붙여 본다. 빠진 줄, 깨진 글자, 뒤섞인 섹션이 있으면 ATS도 그렇게 읽는다.

Summary는 간략하게

레주메가 이력을 한 장으로 요약한 서류라면, Summary는 그 한 장을 2~3문장으로 요약한 것이다. 과거(경험) → 현재(강점) → 미래(커리어 목표) 를 한 번에 보여 준다. 바쁜 면접관은 세부를 다 읽지 않으므로, 왜 이 자리에 맞는 사람인지에 바로 답하는 Summary가 눈길을 잡는다.

1. 먼저 지원하는 공고(JD)의 요구에 맞는 경험과 기술을 셀링 포인트로 뽑는다.
2. 그것을 50단어 이내로 줄인다. 직무명 명사(Software Engineer, Front End Engineer)로 시작하고, 능동태와 액션 동사를 쓴다.
3. 섹션 제목을 Professional Summary 대신 10단어 이내의 헤드라인으로 단다. LinkedIn 헤드라인을 조금 늘린 꼴이다. 예: Senior Software Engineer at Google with over 5 years of experience leading teams

Frontend engineer with 3 years of experience building React and TypeScript web apps
for 1M+ monthly users. Strong in performance tuning and design-system collaboration.
Aiming to grow into a product engineer on a global team.

미국 레주메 섹션별 요령

미국 레주메는 Name → Contact Info → Summary(선택) → Work Experience → Skills(선택) → Education → Projects 순서가 흔하다. 기술 스택을 먼저 보여 주려면 Summary(헤드라인) → Contact Info → Skills → Work Experience → Education → Projects → Awards/Certifications처럼 Skills를 앞으로 올리기도 한다. 이름은 First Last 순서로 쓰고, 비자 스폰서십이 필요 없으면 Contact Info에 Visa Status를 적기도 한다. 평가자가 레주메를 어떻게 훑는지는 미국 개발자 채용 프로세스와 ATS에 정리했다.

Contact Info와 Skills

항목 사이 구분은 |나 탭으로 한다. Skills는 분류별 한 줄로 쓴다.

Languages: TypeScript | JavaScript | Python
Frameworks: React | Next.js | Node.js
Databases: PostgreSQL | Redis

날짜는 월 + 연도(Mar 2022, Jan 2025 – Dec 2027)로 쓴다. 5년 이상이면 2020 – 2025도 된다. 09/10은 연·월이 헷갈린다. 학교·회사 이름 옆에는 도시를 적는다.

Work Experience: 액션 동사와 XYZ 공식

경력은 최신순으로, 경력마다 첫 줄에 회사, 위치 | 직함 | 기간을 쓴다(예: Meta, Singapore | Front End Engineering Lead | Aug 2018 – Present). 그 아래에 불릿(•)으로 2~4줄씩, 액션 동사 + 한 일 + 결과(숫자) 순서로 쓴다. 국문 이력서와 달리 직무 설명에서 끝내지 않고 성과까지 쓴다.

• Reduced checkout page load time by 40% by code-splitting routes and lazy-loading
  images, raising conversion by 5%

• 시제: 끝난 경험은 과거형(managed), 진행 중인 경험은 현재형(manage)으로 쓴다.
• 문장은 동사로 시작한다. 주어 I는 생략한다.
• 같은 동사를 반복하지 않도록 액션 동사 목록(Action Verbs for Resumes) 을 참고한다.

이 구조를 더 다듬은 것이 XYZ 공식이다. 불릿 하나를 「Accomplished [X] as measured by [Y], by doing [Z]」 로 짠다. X는 성과, Y는 숫자, Z는 구체적인 기여다.

Before: Built a pub-sub message brokering system for news content delivery.
After:  Led development of a pub-sub message brokering system for reliable news delivery,
        reducing message loss rate from 8% to 0% by introducing AmazonMQ virtual topics.

면접에서 같은 경험을 말할 때는 XYZ 대신 STAR(Situation, Task, Action, Result)로 풀어 말한다(STAR(R)). XYZ는 글에는 간결하지만 말로 하면 어색하다.

Education

학교 정보에는 학교명, 재학 기간, 전공, 학위명이 필수다. 장학금, 교내 수상, 관련 수강 과목(Course Highlights)은 선택이다. GPA는 높을 때만(4.0 만점에 3.5 이상, 4.3 만점이면 그에 준하는 수준), TA 경험은 CS·공학 수업일 때만 넣는다. 재학 중이면 졸업 예정일 뒤에 (Expected)를 붙인다.

EDUCATION   Seoul National University, Seoul, Korea      Mar 2022 – Feb 2026 (Expected)
            Bachelor of Science in Computer Science      GPA: 3.50/4.00

위치는 기본이 Work Experience 다음이고, 아래 경우에 앞뒤가 바뀐다.

• 신입은 인턴 경험과 CS 전공 여부가 가장 중요하다.
• 경력 5년 이상이면 필수 네 항목만 남긴다. Summa cum laude 같은 특별한 성과는 둬도 된다.
• 학위명은 정확히 쓴다. 최종 합격 뒤 백그라운드 체크에서 한국 학교에까지 직접 확인한다(레퍼런스 체크와 백그라운드 체크).

Projects

• 2~3개를 쓴다. 경력자는 3개를 넘기지 않는다. 지원 직무와 관련이 깊거나, 지원 포지션의 기술 스택을 썼거나, 사용자가 많은 오픈소스에 기여했거나, 직무를 전환하려 할 때 넣는다.
• 인턴 경험도 없는 신입은 Projects를 Work Experience처럼 쓴다.
• 짧은 설명, 맡은 역할, 주요 기술 스택, 서비스·저장소 링크를 넣는다. 프로젝트 이름 자체에 GitHub·서비스 링크를 걸고, 사용 규모를 숫자로 붙인다(예: 「Docusaurus v2 메인테이너. 7.6k개 이상의 GitHub 프로젝트가 사용」). 평가자는 코드보다 README를 본다.
• 비공개 저장소는 NDA 제약이 없으면 GitFront 같은 링크 공유 서비스로 보여 준다.
• 답이 정해진 학교 과제는 넣지 않는다. 자유 주제 과제나 학교의 불편을 푼 실제 서비스는 좋은 재료다.

Awards & Certifications

채용 공고 키워드 반영

채용 담당자와 하이어링 매니저는 레주메를 꼼꼼히 읽기 전에 자기가 찾는 기술·경험 키워드부터 훑는다. 리크루터의 검색과 ATS 필터는 JD를 기준으로 짜인다. 그래서 JD에 맞춘 키워드가 레주메에 있어야 한다.

지원마다 고치기 어렵다면 직무 유형별 레주메를 만든다. 같은 직무의 JD 3~5개를 모아 단어 빈도를 세 보고, 자주 나오는 기술과 경험 중 내가 가진 것을 반영한다.

커버레터

커버레터는 레주메 속 직업인을 소개하는 악수다. 레주메를 되풀이하지 않고 부각한다. 어떤 경우에는 커버레터가 담당자가 처음, 또는 유일하게 읽는 문서다.

• 맞춤이 핵심이다. 회사 이름만 바꾼 범용 커버레터는 바로 티가 난다. 회사의 미션, 업계, 그 자리를 조사했다는 것과 내가 그 미션에 어떻게 기여할지가 보여야 한다.
• 첫 문단에서 내가 이 자리에 맞는 핵심 이유를 짧게 던지고, 내가 회사 목표에 보탤 가치를 말하고, 짧고 관련 있는 이야기 하나로 기억에 남긴다. 레주메처럼 한 장을 넘기지 않는다.

템플릿의 커버레터는 한 장, 네 덩어리로 되어 있다.

1. 머리글: 내 이름·주소·연락처 → 날짜 → 회사 이름·주소 → Dear Hiring Manager:
2. 자기소개 + 지원 포지션: "[근무 회사]에서 [직책]을 맡고 있는 / [대학]에서 [전공]을 전공한 [이름]입니다. [지원 회사]의 [포지션]에 필요한 역량을 갖췄다고 확신해 지원했습니다."
3. 지원 동기 + 성과 사례
   • 회사의 미션과 나의 커리어 목표가 어떻게 맞닿는지 구체적으로 쓴다.
   • 성과를 낸 경험 하나를 기승전결로 풀어 쓴다.
   • Job Description에 적힌 요구 조건을 내 경험·능력과 하나씩 연결한다.
   • 성과는 수치화한다.
4. 마무리: 내 경험이 회사에 자산이 될 것이라는 말, 인터뷰에서 더 이야기 나누고 싶다는 요청, 감사 인사 → Best Regards, + 이름

본문을 이야기형 네 문단으로 짤 수도 있다. 경제 위기가 일상인 나라에서 자라 경제학과 데이터에 끌린 사람이 핀테크에 지원하는 예라면 이렇다.

리크루터에게 먼저 보내는 메일

공고를 보고 리크루터나 하이어링 매니저에게 먼저 연락하는 메일은 커버레터를 세 문단으로 줄인 것이다. 지원 경로로서의 의미는 지원 경로 네 가지에 있다.

Subject: [Job Title] Application – [Your Name]
 
Dear [Name],
 
I am reaching out because I noticed that [Company] is hiring for [Job Title],
and I would like to express my interest in joining your team.
 
I have [X years] of experience in [skills]. Recently, I [one concrete result with a number].
I was especially drawn to [a specific product, feature, or engineering blog post].
 
If you have a moment, I would love to chat further about how I could contribute.
Thank you for your time, and I look forward to hearing from you.
 
Best regards,
[Your Name] · Resume (PDF) · LinkedIn · GitHub

• 모바일 화면 한 번에 읽히는 150~200단어가 적당하다.
• 답이 없으면 1주쯤 뒤 한 번만 짧게 후속 메일을 보낸다(I wanted to follow up on my previous email regarding the [Job Title] role.).

개발자 이력서에 공통으로 통하는 원칙

영문·국문을 가리지 않고 개발 직군 이력서에 통하는 원칙이다. 기준은 하나다. 채용 담당자의 시간과 수고를 줄여 주는가.

신입 이력서에 빈칸이 많은 것은 당연하다. 억지로 채우지 말고 1페이지 안에서 지원 직무에 맞는 강점만 추린다.

개발 환경·생산성 경험을 쓰는 법

DX/플랫폼 성격의 프론트엔드 포지션 공고가 자주 묻는 경험이다. 경험을 나열하는 데서 멈추지 않고, 각각에서 만든 영향과 배운 점을 함께 쓴다.

수치가 있으면 쓰되, 없는 숫자를 만들지 않는다. 전후 차이를 설명할 수 있으면 충분하다.

제출 전 감점 체크

지원자가 많으면 서류 검토는 「안 될 이유」부터 찾아 걸러 내는 방식이 된다. 실력과 무관한 사소한 흠이 그 이유가 되지 않게 한다.

지원할 때

• 지원 양식을 가볍게 넘기지 않는다. 회사가 자체 양식에 경력·학력을 다시 입력하게 하면, 그 양식이 지원자를 거르는 데 쓰인다. 레주메는 보지도 않고 양식 내용만 볼 수도 있다.
• 한 회사의 여러 자리에 한꺼번에 지원하지 않는다. 리크루터는 ATS에서 한 사람의 지원 내역을 모두 본다. 소프트웨어 엔지니어와 데이터 사이언티스트에 동시에 지원하면 무엇을 원하는지, 자기 역량을 아는지 의심받는다.

체크리스트

• 한 장인가?
• Word·Google Docs로 만든 PDF이고, 일반 텍스트로 붙여도 깨지지 않는가?
• JD의 핵심 키워드가 Skills와 Work Experience에 모두 들어 있는가?
• 경력마다 숫자로 된 성과가 있는가?
• 모든 불릿이 액션 동사로 시작하는가? 시제가 맞는가?
• 날짜와 장소 표기가 통일되어 있는가?
• Skills는 지원 포지션과 관련된 것만 남겼는가?
• 직함이 연차 직역이 아니라 실제 역할을 나타내는가?
• Summary가 2~3문장 안에 과거·현재·미래를 담고 있는가?
• 기술 이름 표기가 공식 표기로 통일됐는가?
• 모든 링크를 제출 직전에 열어 봤는가?
• 링크한 저장소의 커밋 메시지가 변경 의도를 설명하는가?
• 경력 공백에 한 줄 설명이 있는가?

관련 노트: 미국 개발자 채용 프로세스와 ATS, 비즈니스 미팅 쿠션 표현, 면접 잘 보는 법, 인성 면접 준비, 자기소개서와 포트폴리오 쓰는 법