이력서 자료를 고를 때는 별 수보다 어떤 문서를 만들 것인지부터 정하는 편이 낫습니다. 직접 고칠 양식이 필요하면 Awesome_Resume_Portfolio, 경력을 Markdown으로 정리하려면 writing-career-resume-skill, 이력서 검토나 HTML 포트폴리오 구성을 살펴보려면 Career-Skills가 서로 다른 후보입니다. 양식을 고르는 일과 경력을 정리하는 일, 포트폴리오를 구성하는 일은 구분해야 합니다.
먼저 메모장에 프로젝트 하나를 적어보세요. ‘팀이 만든 결과’, ‘내가 맡은 일’, ‘그 말을 확인할 자료’를 나눠 적을 수 있다면 양식이나 스킬을 고를 기준이 생깁니다. 반대로 기간과 역할부터 불분명하다면 출력 형식을 바꿔도 그 빈칸은 해결되지 않습니다.
문서 모양보다 먼저, 경력 기록 한 건을 나눠보기
아래는 설명을 위한 가정 기록입니다. 실제 사용자 이력이나 AI 도구의 실행 결과가 아닙니다. 숫자 성과를 그럴듯하게 채우는 예시도 아닙니다.
프로젝트: 팀 공동 일정 관리 도구
팀 결과: 일정 등록과 담당자 지정 기능을 포함한 데모 제작
개인 역할: 담당자 변경 이력 API 구현과 관련 테스트 작성
근거: 해당 변경의 PR, 테스트 파일, 데모 설명 문서
기간: [기간 확인 필요]
사용자 수·시간 절감·매출 효과: 측정 자료 없음
이 기록을 경력기술서에 옮긴다면 ‘팀 전체 도구를 단독 개발했다’고 바꿀 수 없습니다. PR이 개인 작업 범위를 보여주더라도 서비스 전체의 성과까지 증명하지는 않기 때문입니다. 테스트가 있다는 사실과 충분한 테스트 품질을 갖췄다는 평가도 다릅니다.
따라서 참고 자료 옆에는 그 자료로 확인할 수 있는 범위를 적어두는 게 좋습니다. PR은 담당 변경, 설계 문서는 판단 이유, 측정 로그는 조건이 있는 성능 수치의 근거가 됩니다. 공개할 수 없는 사내 자료는 원본을 외부 모델에 넣는 대신, 허용 범위에서 익명화한 설명으로 바꿔야 합니다.
여기서는 이런 메모를 ‘근거 원장’이라고 부르겠습니다. 거창한 관리 시스템이 아니라, 문장을 고칠 때 사실이 함께 바뀌지 않도록 옆에 두는 메모에 가깝습니다. 도구가 문장을 줄이거나 순서를 바꾸더라도 개인 역할과 확인되지 않은 항목은 그대로 남겨야 합니다.
양식만 필요하다면: Awesome_Resume_Portfolio
Awesome_Resume_Portfolio의 README는 개발자 이력서 포맷과 예시를 모아둔 자료입니다. 조회한 저장소 트리에는 README만 있으며, 설치할 SKILL.md나 실행 프로그램은 없습니다. 이름이 GitHub 저장소라고 해서 모두 AI 스킬인 것은 아닙니다.
문서에 적힌 방식은 연결된 Google Docs 양식의 사본을 만들어 직접 수정한 뒤, PDF로 내보내거나 링크로 제출하는 것입니다. 사본을 Drive에 저장하는 경로라면 Google 계정이 필요합니다. 이 글에서는 연결 문서에 접속하거나 사본을 만들지는 않았습니다.
작성자는 사진·주소보다 기술 역량과 경험 요약을 앞세우며, 자신의 경험에 따른 주관적인 형식이라고 밝힙니다. 정해진 지원서 양식이 없는 개발자 이력서의 구성을 생각할 때 참고할 만한 관점입니다. 회사가 요구하는 서식이나 공공기관의 블라인드 기준을 대신하는 규칙은 아닙니다.
앞의 가정 기록을 이 양식에 넣는다면 팀 프로젝트의 설명은 짧게 두고, 개인 API 구현과 테스트를 역할 항목에 풀어 쓸 수 있습니다. 다만 이것은 편집 방향의 예시입니다. 양식을 쓰면 서류 합격률이 오른다는 결과를 확인한 것은 아닙니다. 저장소에 소개된 현직자 사례 역시 이 양식으로 합격했다는 증거로 읽어서는 안 됩니다.
경력을 표 형태로 정리하려면: writing-career-resume-skill
yscho03의 스킬 본문은 사용자 경력 정보를 정해진 Markdown 형식으로 정리하도록 작성돼 있습니다. README가 안내하는 환경은 Claude Code와 Claude Agent Skill이며, 설치 예시는 macOS·Linux의 사용자 스킬 폴더 또는 프로젝트 스킬 폴더입니다.
핵심은 최신순 경력 배열, 기간 표기, 기술 스택 정리입니다. 특히 성과는 팀 전체 결과, 역할은 개인의 구체적인 기여로 나누는 규칙은 앞의 근거 원장과 잘 맞습니다. 채용공고의 자격요건과 우대사항을 제공하면 관련 경험을 강조하도록 적혀 있습니다.
출력 목표는 Markdown 경력기술서입니다. 이 저장소를 PDF 편집기나 DOCX 자동 생성기로 소개할 근거는 없습니다. 개조식 문체를 요구하므로, 서술형 자기소개서 문항의 답을 그대로 맡기는 용도와도 구분해야 합니다. 에이전트가 스킬을 읽는 환경과 모델 접근권이 필요하며, 별도 실행 스크립트는 조회한 트리에 없습니다.
그런데 그대로 받아들이면 안 되는 규칙이 하나 있습니다. 본문은 기간을 주지 않으면 ‘최대 1년 내 적정 기간’을 산정하라고 적습니다. 이 지시는 거부해야 합니다. 프로젝트 기간은 짧아 보이거나 길어 보이는 인상을 조정할 재료가 아니라 확인할 사실입니다.
앞의 기록에는 날짜가 없으므로 결과에도 [기간 확인 필요]가 남아야 합니다. 기억이나 문서로 시작월과 종료월을 확인한 뒤 총기간을 계산하는 것은 가능하지만, 보기 좋은 기간을 먼저 정하면 안 됩니다. 스킬에 나오는 ‘CS 30% 감소’ 같은 숫자도 서술 형식을 보여주는 예시일 뿐, 자신의 성과에 붙일 기본값이 아닙니다.
검토 보고서와 포트폴리오는 별개: Career-Skills
Career-Skills README는 Codex/OMX, Claude Code, Cursor 등의 코딩 에이전트에서 쓰는 채용 준비 스킬 모음을 소개합니다. 이력서 리뷰, 면접 준비, 코딩테스트, 포트폴리오처럼 범위가 넓습니다. 모든 기능이 같은 입력을 받아 같은 파일을 만드는 구조는 아닙니다.
이력서 관련 공통 입력 안내는 PDF·Markdown·텍스트를 다루며, DOCX와 Notion URL은 직접 파싱할 수 없어 변환을 요청하도록 돼 있습니다. ‘내 자료가 어디에 있나’와 ‘이 스킬이 읽는 형식인가’를 먼저 구분해야 합니다. 저장소에 파일이 있다는 이유로 모든 에이전트에서 같은 도구와 결과가 보장되지는 않습니다.
그중 portfolio-build의 명시된 결과물은 자기완결형 HTML 슬라이드 포트폴리오입니다. 이력서, 기존 PDF·HTML 포트폴리오, 이미지, GitHub 자료에서 내용과 그림을 가져와 구성하는 설계입니다. PDF를 입력받는 것과 완성 PDF를 직접 생성하는 것은 다릅니다.
이 단계에서도 앞의 근거 원장을 옆에 두면 됩니다. 개인 API 구현을 설명할 슬라이드에는 관련 설계나 실제 구현 근거를 붙이고, 없는 사용자 증가 그래프는 만들지 않는 방식입니다. 스킬 본문도 근거 없는 수치와 미사용 기술을 금지하고 팀 프로젝트에서는 본인 기여만 적도록 요구합니다. 다만 이런 규칙이 있다는 사실과 모델이 실제로 지켰다는 실행 검증은 별개입니다.
리뷰의 점수도 같은 구분이 필요합니다. 자체 평가 프레임워크의 ATS 통과선이나 PASS·REJECT를 실제 회사의 서류 결과처럼 해석하면 안 됩니다. 이력서 문장과 근거를 다시 살필 단서일 뿐입니다. README에 소개된 자기소개서 작성 스킬 중 이번 트리에서 실제 파일을 찾지 못한 항목은 이 글의 선택지에 포함하지 않았습니다.
설치 여부를 정하기 전에 남는 조건
Career-Skills의 전용 설치 스크립트는 Bash 기반입니다. 선택 사항인 스킬 주입 훅은 Node로 로컬 스킬 본문을 읽어 에이전트 문맥에 넣으며, PDF 이미지 추출 보조 스크립트는 Python과 PyMuPDF가 필요합니다. 네이티브 Windows에서 같은 경로가 작동하는지는 이번에 검증하지 않았습니다. 이 글은 설치 명령을 따라 하는 안내가 아니라 소스에 적힌 역할을 비교한 글입니다.
Career-Skills와 yscho 스킬에는 MIT 라이선스가 있습니다. 복제·배포할 때 저작권과 허가문을 보존해야 하며, MIT라는 이유로 연결된 외부 이미지나 예시 이력서까지 같은 권리라고 볼 수는 없습니다. Awesome_Resume_Portfolio에는 별도 라이선스 파일이 없었습니다. 본인에게 맞게 수정해 사용하라는 README 안내와 자유로운 재배포를 허용하는 오픈소스 라이선스는 구분해야 합니다.
비용도 소스와 실행을 나눠 봐야 합니다. 공개 코드를 읽는 것과 에이전트 모델을 사용하는 비용은 별개입니다. 모델 구독·API 비용은 환경마다 다르므로 ‘무료 이력서 완성 도구’라고 묶지 않았습니다. 클라우드 모델에 이력서를 넣는다면 연락처·주소·동료 개인정보·사내기밀을 줄이고 실제 제공자의 처리·보관 정책을 확인해야 합니다.
관측 시점인 2026년 10월 18일 01:11 KST, GitHub REST 응답의 별 수는 Career-Skills 94개, writing-career-resume-skill 64개, Awesome_Resume_Portfolio 2,576개였습니다. 세 저장소 모두 보관 처리되지 않은 상태였습니다. 별은 관심 지표이며 이용자 수나 결과물 품질, 채용 효과를 증명하지 않습니다.
지금 할 일은 세 도구를 한꺼번에 설치하는 것이 아닙니다. 프로젝트 하나의 팀 결과와 개인 역할을 분리하고, 날짜와 성과의 근거를 붙인 뒤 필요한 문서 형식을 고르면 됩니다. 양식은 사람이 직접 채우고, 경력기술서 스킬은 기록을 정리하며, 리뷰와 포트폴리오 스킬은 다른 관점의 검토·구성을 목표로 합니다. 어느 경로를 택해도 사실의 빈칸을 도구가 대신 채우게 해서는 안 됩니다.
스킬이라는 작업 지침과 외부 도구를 연결하는 통로를 구별하는 개념은 Claude Skills와 MCP의 역할 구분에 따로 정리했습니다.
출처 및 확인일
모두 저장소 운영자가 공개한 원문이며, 설치·실행 또는 독립적인 취업 효과를 검증한 자료는 아닙니다. 확인일은 2026년 10월 18일 KST입니다. README·SKILL 본문에 별도 게시일은 미표기돼 있어 아래 날짜는 조회한 기본 브랜치 최신 커밋의 committer 일시를 KST로 옮긴 날짜입니다.
'💻IT' 카테고리의 다른 글
| fetch()에 404가 왔는데 catch가 안 돈다면? (0) | 2026.10.22 |
|---|---|
| 자소서 AI 첨삭 전, 입력 빈칸을 찾고 필요한 결과물 고르기 (0) | 2026.10.21 |
| 투명 영상은 BackgroundRemover, 더빙 입모양은 LatentSync (0) | 2026.10.20 |
| 자막 파일이 필요한가, 쓸 장면을 찾을 것인가: AutoSubs와 StoryToolkitAI (0) | 2026.10.20 |
| 하이라이트·문장 컷·새 해설: AutoClip·FunClip·NarratoAI의 다른 결과물 (0) | 2026.10.19 |
