1. 프로젝트 요약
 |  |
|---|
Notion 데이터베이스와 연동하여 내용을 수정할 수 있는 이력서 웹사이트 템플릿입니다.
컴팩트한 2열 포맷으로 이력서를 PDF 출력할 수 있습니다.
개발에 Cursor를 적극 활용했습니다.
주요 기능
- Notion 연동: Notion DB 수정 → 재배포하면 업데이트 완료
- PDF 출력: 컴팩트한 2열 포맷의 PDF 출력 가능
- 모바일 최적화: 채용담당자들의 모바일 확인을 고려한 반응형 디자인
- 무료 호스팅: GitHub Pages + Vercel로 유지비용 없이 운영
관련 링크
2. 프로젝트 구성
아키텍처
- Notion 데이터베이스: 이력서 내용 저장
- GitHub Pages: 공개 이력서 페이지 호스팅
- Vercel: PDF 출력 기능을 담당하는 별도 페이지
기술스택
- Frontend: React, Next.js, TypeScript
- Styling: Tailwind CSS
- API: Notion API
- PDF 생성: Puppeteer-core + @sparticuz/chromium
- 배포: GitHub Actions (GitHub Pages) + Vercel
이력서 디자인
개발자 현섭님과 유용우님의 이력서 사이트를 참고하였습니다.
3. 프로젝트 배경
구직 과정에서 발견한 이력서의 한계
이력서 작성의 첫 시작은 사람인, 잡코리아, 원티드 등의 잡사이트 이력서를 완성하는 것이었습니다. 경력(회사 경험)과 경력기술서 섹션으로 구성된 양식에 따라 채워나가면 나름 깔끔한 결과물을 얻을 수 있었습니다. 디자인에 자신이 없다면 잡사이트 이력서 포맷을 사용하고 PDF 출력 기능을 쓰라는 조언도 있었습니다.
원티드, 잡코리아의 즉시지원 기능으로 여기저기 지원하기 시작했습니다. 지원할 때마다 회사에 맞는 이력만 들어가도록 적절히 수정했습니다. 하지만 10군데 가량 서류 탈락했습니다.
헤드헌터를 통한 피드백: '핵심 역량'의 발견
이력서를 열심히 수정하기 시작했습니다. 잡사이트 이력서도 구직중으로 변경했습니다. 조금씩 헤드헌터에게 연락이 오기 시작했고, 이들을 통한 구직의 장점은 구체적인 피드백을 받을 수 있다는 것이었습니다. 에이전시에서 만든 이력서 양식과 함께 각 항목을 어떻게 써야 하는지 세세한 가이드라인을 제공했습니다.
여러 헤드헌터들의 피드백과 양식을 분석하며 공통점을 발견했습니다. 잡사이트 이력서의 일반적인 구성인 경력, 경력기술서 섹션 외에 '핵심 역량' 섹션이 있었습니다. 이것이 이력서의 핵심이라는 생각이 들었습니다. 특히 저에게는 더욱 중요했습니다.
SI 개발자, 다양한 스택, 명확하지 않은 강점
저는 임베디드 개발로 경력을 시작했습니다. 하지만 최근 2년은 앱, 웹, 머신러닝 등 다양한 기술스택의 외주 개발을 했습니다. 하나의 기술스택으로 어필하기 어려운 상황이었습니다. 업무경험과 프로젝트를 단순 나열하는 방식으로는 제가 가진 강점이 명확하게 드러나지 않았습니다.
이력서 앞부분에 '핵심 역량' 섹션을 따로 만들어야겠다고 판단했습니다. 제가 자신 있고 어필하고 싶은 기술과 역량을 중심축으로 이력을 재구성할 필요가 있었습니다. 나만의 이력서를 만들어야 할 때였습니다.
자유양식 이력서 제작의 막막함
자유양식 이력서를 만드는 게 생각보다 막막했습니다. Figma로 만들어볼까 했지만, 내용이 수정될 때마다 디자인까지 조정해야 한다는 점이 비효율적이었습니다. Figma, Canva의 이력서 템플릿들도 마음에 들지 않았고, 제 상황에 맞춰 커스터마이징하는 것도 상당한 작업이었습니다.
Notion 시도와 한계 발견
일단 Notion으로 시도했습니다. 작성은 정말 편했습니다. 텍스트 위계를 자유롭게 표현할 수 있어 업무경험과 프로젝트 부분의 가독성이 잡사이트 이력서보다 훨씬 좋았습니다. 그러나 몇 가지 문제가 있었습니다.
도메인 문제
도메인이 깔끔하지 않았습니다. 예를 들면 https://fluorescent-airplane-153.notion.site/Jaeik-Lee-Resume-Database-278b61feddfe80628aadf4982bcb492a 와 같은 식으로 나오는데, 공개용 이력서 사이트로 쓰기에는 적합하지 않습니다. 커스텀 도메인을 쓰려면 별도 구매가 필요했습니다.
PDF 출력 품질
가장 치명적인 문제였습니다. 자유양식 이력서를 요구하는 경우 PDF 제출을 요구하는 경우가 많은데, Notion 페이지를 PDF로 출력한 결과물은 Notion 상에서 보던 것과 차이가 조금 있습니다.
 |  |
|---|
스케일도 다르고(export시 조절 가능하긴 합니다만) 줄 간격 등 디자인 시스템에도 약간의 차이가 있어보입니다. 전반적으로 깔끔하고 가독성 높은 결과물이 나오지 않아 아쉬웠습니다.
비효율적인 레이아웃
인쇄용 양식으로 쓰기에는 낭비되는 지면이 너무 많았습니다. 1열 배치 방식이라 한 페이지에 들어오는 양이 적었습니다. Scale 조정 기능이 있었지만 근본적인 해결책은 아니었습니다. 헤드헌터들이 제공한 양식들은 모두 웹사이트같은 양식보다는 인쇄에 적합한 구조로 컴팩트하게 정보를 담고 있었습니다.
직접 만들어보자!
이런 과정을 거치며 직접 이력서 시스템을 만들기로 결정했습니다. 핵심 역량을 효과적으로 어필하고, 인쇄에 적합한 레이아웃의 PDF 출력이 가능한 시스템을 만들어 보기로 했습니다. 또한 저와 비슷한 고충을 가지신 분들이 있을 거라 생각하여, 누구나 사용가능한 템플릿 형태로 완성해보기로 했습니다.
목표
- 공개 이력서 사이트: 깔끔한 도메인으로 접근 가능
- 디자인 자동화: 내용 수정에만 집중할 수 있도록
- 편리한 업데이트: 주기적 업데이트가 쉬운 형태
- PDF 출력: 인쇄에 적합하도록 컴팩트한 포맷
- 무료 운영: 유지비용 없이 운영
4. 이력서 기능 소개
14개 섹션
이력서는 총 14개의 섹션으로 구성되어 있습니다:
- 개인 정보 (Personal Info)
- 기술 스택 (Skill)
- 핵심 역량 (Core Competency)
- 업무 경험 (Work Summary, Work Achievement)
- 프로젝트 경험 (Project)
- 포트폴리오 (Portfolio)
- 수상 (Award)
- 활동 (Activity)
- 기타 경험 (Other Experience)
- 가치관 (Value)
- 개발 외 툴 활용 역량 (Other Tool)
- 학력 (Education)
- 자격증 (Certification)
- 병역 (Military Service)
Notion API를 사용하여 14개 섹션을 15개의 Notion DB와 연동했습니다.
Notion DB 입력 방식
Notion DB의 각 프로퍼티는 이력서 화면에 매핑됩니다. skills 프로퍼티(Multi-select 타입)는 기술 스택 칩(Tech Chip) 형태로 표현되고, details 프로퍼티는 - 로 시작하는 텍스트를 자동으로 bullet point로 변환합니다. Skill 섹션의 경우 같은 카테고리(title)끼리 그룹핑하여 표현됩니다.
 |  |
|---|
DB가 비어있으면 해당 섹션이 자동으로 숨겨지고, 입력하지 않은 프로퍼티는 표시되지 않습니다. 지원하는 포지션에 따라 특정 내용을 선택적으로 표시할 수 있도록 show 프로퍼티로 개별 항목을 ON/OFF할 수 있으며, order 프로퍼티로 순서를 설정할 수 있습니다.
 |  |
|---|
모바일 최적화
 |  |
|---|
채용담당자들이 모바일로 이력서를 확인하는 경우가 많다는 점을 고려하여 반응형 디자인을 구현했습니다. 2열 레이아웃(프로필 사진+연락처, 업무경험 부분)을 1열로 변경하고, 모바일 화면에 맞춰 글씨 크기와 타이포그래피 위계 대비를 조정했습니다.
PDF 출력
인쇄에 적합한 컴팩트한 PDF 출력 기능을 구현했습니다. CSS column-count를 사용하여 2열로 배치함으로써 페이지 공간을 효율적으로 활용하고, 인쇄에 맞춰 글씨 크기와 타이포그래피 위계 대비를 조정했습니다. 공개 이력서 페이지 하단의 'PDF로 출력하기' 버튼을 클릭하면 Vercel 페이지로 이동하여 PDF를 다운로드할 수 있습니다.
이력서 업데이트 방법
코드를 로컬 환경에서 실행할 필요 없이 GitHub 웹에서 업데이트할 수 있습니다. Notion DB에서 이력서 내용을 수정한 후, GitHub Actions workflow를 실행하면 공개 이력서 페이지가 자동으로 업데이트됩니다. PDF 출력 페이지 업데이트가 필요한 경우 Vercel에서 redeploy를 실행하면 됩니다.
5. GitHub Pages + Vercel 구조
구조 선택의 배경
처음에는 이력서에 어울리는 도메인(username.github.io)을 제공하는 GitHub Pages를 사용해 구현하려 했습니다. 하지만 GitHub Pages는 정적 사이트 호스팅만 지원하기 때문에, PDF 출력 기능 구현에 제약이 있었습니다.
GitHub Pages에서 사용 가능한 PDF 출력 방식은 jsPDF 같은 클라이언트 사이드 라이브러리입니다. 이는 Canvas 기반으로 화면을 이미지화하여 PDF로 변환하는 방식이라 텍스트 선택이 불가능하고 링크도 사라지는 문제가 있었습니다. 일반적으로 사용하는 PDF 출력 라이브러리(Puppeteer, Playwright 등)는 서버사이드에서 실행되는 백엔드가 필요했습니다.
서버리스 함수를 지원하는 Vercel로 마이그레이션을 시도했습니다. PDF 출력 기능은 구현할 수 있었지만, 또 다른 문제를 마주했습니다. Vercel의 기본 도메인(projectname.vercel.app)은 이력서 사이트로 사용하기에는 신뢰감이 떨어졌습니다. 커스텀 도메인을 사용하려면 별도 구매가 필요했습니다.
최종 구조 결정
두 플랫폼의 장점을 모두 활용하는 하이브리드 구조를 선택했습니다. 공개 이력서 페이지는 GitHub Pages에 호스팅하여 깔끔한 도메인을 확보하고, PDF 출력 기능을 위한 별도 페이지는 Vercel에 호스팅했습니다. 공개 이력서 페이지에서 'PDF로 출력하기' 버튼을 통해 Vercel 페이지로 이동할 수 있도록 구성했습니다. 이 구조를 통해 신뢰감 있는 도메인과 강력한 PDF 출력 기능을 모두 확보하면서, 유지비용은 전혀 들지 않게 됩니다.
플랫폼별 역할
GitHub Pages
- 역할: 공개 이력서 페이지 호스팅
- 장점: 깔끔하고 이력서용으로 적합한 도메인
- 한계: 정적 컨텐츠 호스팅만 가능, 원하는 방식의 PDF 출력 기능 구현 불가
Vercel
- 역할: PDF 출력 기능을 담당하는 별도 페이지
- 특징: 서버리스 웹서버로 정적 파일은 CDN에서 빠르게 서빙하고, 웹 애플리케이션은 필요할 때만 서버리스 함수 실행
- 장점: 서버 설정, 확장, 보안 등 자동 관리
- 한계: 도메인이 임시 사이트 같음 (도메인 구매 가능하지만 유지비용 발생)
6. PDF 출력 기능 구현: 기술 선택 과정
Vercel의 서버리스 환경에서 PDF 출력 기능을 구현하는 과정에서 여러 시행착오를 겪었습니다.
Puppeteer & Playwright 시도
Puppeteer(Google)와 Playwright(Microsoft)는 브라우저 자동화 분야에서 널리 사용되는 라이브러리입니다. 웹 페이지를 실제 브라우저로 렌더링하여 PDF로 변환하기 때문에, 텍스트 선택과 링크 기능이 모두 유지됩니다.
하지만 두 라이브러리 모두 Chromium 바이너리를 포함하고 있어 번들 크기가 매우 컸습니다. Puppeteer (full version)는 약 282MB, Playwright는 약 300MB(Chromium, Firefox, WebKit 모두 포함)로 Vercel의 서버리스 함수 번들 크기 제한을 초과하여 배포할 수 없었습니다.
Puppeteer-core + @sparticuz/chromium
Vercel 공식 문서에서 권장하는 서버리스 환경 솔루션입니다. Puppeteer-core는 브라우저 바이너리를 포함하지 않는 경량 버전이고, @sparticuz/chromium은 서버리스 환경에 최적화된 경량 Chromium 바이너리(약 35MB)를 별도로 제공합니다.
핵심은 바이너리 분리였습니다. Puppeteer-core는 브라우저 제어 API만 제공하고, @sparticuz/chromium이 서버리스 환경용 경량 Chromium 바이너리를 제공합니다. Puppeteer의 executablePath 옵션으로 @sparticuz/chromium 바이너리를 지정하는 방식으로, 함수 번들 크기를 약 35MB로 줄여 Vercel의 제한을 통과할 수 있었습니다.
| 구분 | Puppeteer & Playwright | Puppeteer-core + @sparticuz/chromium |
|---|---|---|
| 크롬 바이너리 | 라이브러리에 포함 | 외부 바이너리 사용 |
| 함수 번들 크기 | 제한 초과 (282-300MB) | 제한 내 (35MB) |
| 결과 | Vercel 배포 실패 | Vercel 배포 성공 |
7. Notion API 이미지 URL 만료 문제
개발 중에는 문제가 없었는데, 시간이 지난 후 다시 확인했을 때 프로필 이미지가 깨져있는 현상이 반복적으로 발생했습니다. 원인을 찾아보니 Notion API의 특성 때문이었습니다.
처음에는 Notion 데이터베이스에서 제공하는 이미지 URL을 통해 이미지를 가져와 보여주는 방식을 사용했습니다. 알고보니 Notion API가 제공하는 이미지 URL은 1시간의 유효시간을 가지고 있었습니다(Notion API 문서). 지속적으로 이미지를 표시하려면 1시간마다 API를 호출하여 새로운 URL을 받아와야 했습니다. 정적 사이트 특성상 이는 현실적이지 않은 방법이었습니다.
최종적으로 GitHub 저장소의 public/images/ 디렉토리에 이미지를 직접 포함시키는 방식을 선택했습니다. 다행히 GitHub 웹 인터페이스를 통해 코드를 로컬 환경에 받지 않고도 이미지를 관리할 수 있었습니다. URL 만료 문제는 완전히 해결되었지만, Notion에서 직접 이미지를 관리할 수 없어 편의성 측면에서는 개선이 필요한 부분입니다.
8. 한계점과 개선 방향
현재 템플릿은 fork하여 사용할 수 있을 정도의 안정성과 템플릿 이용 가이드 문서를 갖추고 있습니다. 하지만 보다 편리한 이용을 위해 몇몇 아쉬운 부분들을 개선해나가려 합니다.
PDF 출력 포맷 및 미리보기
PDF 출력 결과물은 2열인데 웹페이지에는 1열 화면이 보여져 괴리감이 있습니다. 또한 사용자에 따라 페이지 수가 늘어나더라도 큰 글자로 쾌적하게 보길 선호할 수 있습니다. 추후 1열, 2열 포맷 선택 기능과 실시간 미리보기 UI를 제공하는 방식으로 개선해보려 합니다.
관리 편의성
Notion Integration, GitHub Actions, Vercel을 각각 연동해야 하는 초기 세팅 과정이 복잡합니다. 이력서 내용 업데이트 시에도 GitHub Actions workflow 실행과 Vercel redeploy를 수동으로 진행해야 하는 점이 사용자 입장에서 직관적이지 않습니다.
필요한 작업들을 추상화하여 Notion Token, DB ID, 프로필, 파비콘만 입력하면 자동으로 모든 것이 세팅되는 통합 관리 플랫폼으로 개선해보고자 합니다.
실시간 연동
Notion 데이터베이스를 수정했을 때 자동으로, 또는 주기적으로 재배포를 하면 편하지 않을까 생각했었습니다. 한편으로는 Notion에서 이력서를 수정하는 과정이 일일이 실시간으로 업데이트되는 것은 썩 좋지 않겠다는 생각도 듭니다. 공개 이력서는 불특정 다수가 보는 것입니다. 오히려 충분히 수정 작업이 완료되었을 때, 사용자가 원할 때만 업데이트를 하는 것이 더 적절할 수도 있을 것 같습니다. 어떤 방식으로 연동 편의성을 높일 수 있을지 더 고민이 필요할 것 같습니다.
