자소서 초안의 뜻을 유지하며 문항에 맞게 다듬고 싶다면 자소서 도우미(ja-so-seo-do-u-mi)의 보존형 첨삭 설계를, 기업분석·경험 정리·이력서·면접 준비까지 함께 살펴보려면 jobstack의 통합 흐름을 비교할 수 있습니다. 두 저장소 모두 실제 경험을 대신 만들어 주는 도구로 읽어서는 안 됩니다.
선택하기 전에 할 일이 있습니다. ‘채용공고’, ‘자소서 문항’, ‘분량 기준’, ‘초안’이 각각 있는지 나눠보세요. 공고를 주지 않은 채 ‘회사에 맞춰줘’라고 하거나 문항 없이 ‘좋은 자소서로 고쳐줘’라고 하면, 무엇에 답해야 하는지부터 불분명해집니다.
‘700자로 고쳐줘’에서 빠진 정보 찾기
아래 입력은 설명용 가정입니다. 실제 지원자의 경험이나 두 도구를 실행해 얻은 결과가 아닙니다.
목표 직무: 서비스 운영
공고: 일정 조율과 운영 문서 관리 업무를 요구한다고 가정
문항: 미제공
분량: 700자, 공백 포함 여부 미확인
초안: 팀 활동에서 업무 누락을 확인하고 체크 항목을 정리한 경험
확인된 결과: 팀이 마감 전에 결과물을 제출함
미확인 항목: 개인의 정확한 담당 범위, 누락 감소 수치
이 상태에서 문장부터 완성하면 ‘협업 경험’을 써야 할지 ‘지원동기’를 써야 할지부터 어긋날 수 있습니다. 같은 경험이라도 문항이 묻는 일이 다르기 때문입니다. 분량 역시 700자라는 숫자만으로는 부족합니다. 공백 포함·제외, byte 제한 중 적용 기준을 알아야 합니다.
우선 물을 질문은 ‘이 경험을 더 멋지게 표현할까요?’가 아닙니다. 정확한 문항이 무엇인지, 내가 직접 한 일이 어디까지인지를 확인하는 편이 먼저입니다. 감소율을 측정하지 않았다면 ‘업무 누락을 50% 줄였다’는 문장은 만들 수 없습니다. 팀이 기한을 지켰다는 결과를 개인 혼자 달성한 것처럼 바꾸는 것도 안 됩니다.
이 입력을 고치는 일 자체는 특정 스킬 설치 없이 할 수 있습니다. 실제 공고에서 주요업무를 가져오고, 문항을 원문대로 분리하고, 글자수 기준을 붙인 다음, 초안 옆에 개인 행동과 확인 가능한 결과를 표시하면 됩니다. 이것은 도구 사용 절차를 시험한 안내가 아니라, 첨삭에 필요한 자료를 구분하는 방법입니다.
초안의 강점을 남기려는 설계: 자소서 도우미
ja-so-seo-do-u-mi의 SKILL.md는 JD, 문항, 글자수 규칙, 초안을 함께 읽도록 작성돼 있습니다. 조회한 본문 버전은 0.3.0입니다. README는 Codex CLI를 전제로 소개합니다.
스킬 본문이 지정한 기본 모드는 ‘보존형 첨삭’입니다. 먼저 사용자가 강조하려는 경험과 강점을 잡아두고, 의미를 유지한 채 문장과 구조를 고치도록 설계했습니다. 문장만 다듬어 달라는 요청을 전체 이야기 교체의 허락으로 해석하지 않도록 나눈 것입니다.
모드는 세 갈래입니다. 진단 전용은 문제와 근거, 개선 방향을 내고 대체 자소서를 쓰지 않습니다. 보존형 첨삭은 핵심 경험을 유지하며 필요한 만큼 손봅니다. 구조를 새로 짜는 재작성은 사용자가 명시적으로 요청한 경우로 제한합니다. 이 구분은 초안이 거칠다는 이유로 작성자의 의도를 지워버리는 일을 막기 위한 장치입니다.
가정 입력에서 문항과 분량 기준을 확인한 뒤 문장 수정만 원한다면, 보존형 경로를 비교 대상으로 삼을 수 있습니다. 이때 살려야 할 내용은 ‘누락을 발견하고 체크 항목을 정리한 개인 행동’입니다. 공고의 운영 업무와 연결하더라도 해보지 않은 고객관리 시스템 경험이나 개선 수치를 새로 넣으면 안 됩니다.
스킬 본문은 최종 문안 옆에 글자수, 살린 핵심, 수정 요약을 남기도록 정합니다. 크게 줄이거나 뺀 내용과 남은 확인 사항도 필요할 때 남기게 돼 있습니다. 결과를 검토할 때는 자연스러운 문장만 읽지 말고, 내가 살리려던 경험이 무엇으로 남았는지를 먼저 대조하는 편이 좋습니다. 이는 소스에 적힌 출력 설계이며, 이번에 실제 Codex에서 재현한 결과는 아닙니다.
글자수 숫자도 실제 제출창과 같다고 단정하지 않기
글자수 보조 스크립트는 파일이나 표준입력의 텍스트를 읽어 공백 포함·제외, UTF-8 byte, EUC-KR byte 등을 계산합니다. Python 표준 라이브러리를 사용하며, 조회한 코드에는 네트워크 전송 동작이 없습니다.
다만 앞뒤 공백을 제거하고 줄바꿈을 정규화한 뒤 계산합니다. EUC-KR로 표현할 수 없는 문자는 대체 처리합니다. 따라서 이 숫자를 모든 채용 사이트의 카운터와 같다고 보장할 수 없습니다. 최종 분량 기준은 실제 공고와 제출창입니다. 보조 스크립트에 네트워크 코드가 없다는 사실도, 자소서를 읽는 모델까지 완전 로컬이라는 뜻은 아닙니다.
문장보다 준비 흐름이 비어 있다면: jobstack
jobstack README는 Claude Code용 한국 취업 준비 시스템을 소개합니다. 16개 스킬에 기업분석, 자소서·이력서·경력기술서, 경험 소재, 면접, 지원 현황 관리 등을 나눠 담았습니다. 초안 한 편의 어투만 바꾸는 도구보다 범위가 넓습니다.
앞의 가정 입력에서 ‘어떤 경험을 직무와 연결할지 모르겠고, 회사가 하는 일도 덜 파악했다’면 필요한 산출물은 바로 최종 자소서가 아닐 수 있습니다. 공고의 요구사항과 보유 경험을 연결한 메모, 기업분석 자료, 경험 기록부터 검토해야 할 상황입니다. jobstack은 이런 준비 단계를 나눠둔 설계가 비교 포인트입니다.
반대로 문항과 경험이 이미 명확하고 표현만 고치려는 독자에게는 전체 시스템이 필요 이상으로 넓을 수 있습니다. 이때는 기능 개수보다 필요한 결과물을 먼저 적어보면 됩니다. ‘초안 의미를 유지한 수정 문안’인지, ‘기업과 경험을 연결할 준비 자료’인지 먼저 적어두면 선택지가 줄어듭니다.
jobstack의 자소서 스킬은 숫자가 없으면 범위·빈도·전후 비교·담당 규모처럼 답할 수 있는 근거를 먼저 묻도록 적습니다. 추정은 마지막 수단이며 사용자 확인과 [추정] 표기를 요구하고, 제공되지 않은 수치의 창작을 금지합니다.
README의 ‘수치가 없으면 성과가 아니다’라는 표현이나 별도 예시의 개선율을 그대로 따라 할 필요는 없습니다. 실제 근거가 없다면 정성 결과와 개인 행동을 남기는 편이 맞습니다. 추정이라는 꼬리표도 허위 성과를 허용하는 면허가 아닙니다. 제출문에는 측정값인지 계산값인지 설명할 수 있는 근거가 필요합니다.
ATS 80점은 ‘서류 통과 확률 80%’가 아닙니다
jobstack-ats-match 코드가 계산하는 것은 키워드 목록 중 문서에 포함된 항목의 비율입니다. 키워드 목록 추출은 모델이 맡고, 계산은 스크립트가 합니다. 계산한 비율을 반올림한 점수로 등급을 정하며, A는 80% 이상, B는 60% 이상, 그 미만은 C로 구분합니다.
가령 설명용으로 정한 키워드 5개 중 4개가 문서에 있다면 포함 비율은 80%입니다. 이는 계산 개념을 보여주는 가정 예시이며 실행 결과가 아닙니다. 그 문서가 실제 경험을 정확히 적었는지, 문항에 답했는지, 채용담당자가 어떤 평가를 할지는 별도 문제입니다.
점수를 올리려고 해보지 않은 기술을 넣으면 비율은 좋아져도 지원서는 부정확해집니다. 도구의 점수는 빠진 연결을 살필 참고값으로만 다뤄야 합니다. README의 샘플 페르소나나 자체 E2E 평가도 실제 지원자의 합격 결과, 독립적인 채용 효과 측정과는 다릅니다.
기능 설명 뒤에 있는 실행 조건까지 읽기
jobstack의 안내 환경은 Claude Code이며 플러그인 설치 경로는 2.1 이상을 전제로 합니다. 수집 관련 패키지는 Node 22 이상을 요구합니다. 문서 결과는 기본적으로 Markdown이며 DOCX 내보내기에는 pandoc 또는 Node의 docx 패키지 경로가 있습니다. 뷰어에서 PDF를 저장하는 설명은 브라우저 인쇄 방식입니다.
설치 스크립트에는 사용자 홈의 .claude/skills 아래 설치 대상과 이름이 같은 기존 스킬 디렉터리를 삭제하고 심링크로 바꾸는 경로가 있습니다. 컴퓨터의 모든 스킬을 삭제한다는 뜻은 아니지만, 같은 이름의 기존 자료가 있다면 무시할 부작용도 아닙니다. job-search 첫 실행 프리앰블에는 기본적으로 npm 의존성을 자동 설치하는 경로도 있습니다. 이번 글에서는 어느 경로도 실행하지 않았으며 설치 명령을 제공하지 않습니다.
프로필·경험·지원 현황은 .jobstack 폴더의 YAML·JSONL 등에 저장하는 설계입니다. 로컬 사용 이벤트 로그의 네트워크 미전송 설명을 이력서 전체가 모델 제공자에게 전송되지 않는다는 뜻으로 넓히면 안 됩니다. 연결 모델의 데이터 처리 정책, 업로드 파일과 실제 도구 권한은 별도로 확인해야 합니다. 소스 사용료와 모델 구독·API 비용 역시 다른 문제입니다.
권리 조건도 다릅니다. jobstack은 MIT 라이선스지만 자소서 도우미는 조회한 트리에서 별도 라이선스를 확인하지 못했습니다. 공개돼 있다는 이유만으로 후자를 자유롭게 재배포할 수 있는 오픈소스라고 단정하지 않습니다. 사내 배포나 변형본 공유를 계획한다면 권한을 먼저 확인해야 합니다.
2026년 10월 18일 01:11 KST 관측한 GitHub 별 수는 자소서 도우미 42개, jobstack 167개였습니다. 두 저장소 모두 보관 처리되지 않은 상태였습니다. 이 수치는 관심 지표일 뿐 첨삭 품질이나 취업 효과를 입증하지 않습니다. 이번 조사에서는 두 저장소의 독립적인 실행 후기나 채용 성과도 확인하지 못했습니다.
남는 판단은 간단합니다. 문항·초안이 준비돼 있고 어필 의도를 지키는 수정이 필요하면 보존형 첨삭의 규칙을, 경험과 기업을 연결할 자료부터 부족하면 준비 단계별 산출물을 살펴보면 됩니다. 어느 쪽이든 지원기관의 AI 사용·블라인드 규정이 우선입니다. AI 사용이 금지된 작업을 ‘참고용 수정안’이라고 이름만 바꿔 맡길 수는 없습니다.
작업 지침인 스킬과 외부 연결 통로를 혼동하고 있다면 Claude Skills와 MCP의 역할 구분에서 개념을 나눠 볼 수 있습니다.
출처 및 확인일
확인일은 2026년 10월 18일 KST입니다. 아래는 운영자 원문과 코드이며 기능 실행·취업 효과의 독립 검증 자료가 아닙니다. 개별 README·SKILL의 게시일은 미표기입니다. 날짜는 조회한 기본 브랜치 최신 커밋의 committer 일시를 KST로 옮긴 날짜입니다.
'💻IT' 카테고리의 다른 글
| 수량 0 대신 10이 나온 이유: JavaScript ||와 ?? (0) | 2026.10.24 |
|---|---|
| fetch()에 404가 왔는데 catch가 안 돈다면? (0) | 2026.10.22 |
| 개발자 이력서를 AI에 맡기기 전, 양식·경력기술서·포트폴리오부터 구분하세요 (0) | 2026.10.21 |
| 투명 영상은 BackgroundRemover, 더빙 입모양은 LatentSync (0) | 2026.10.20 |
| 자막 파일이 필요한가, 쓸 장면을 찾을 것인가: AutoSubs와 StoryToolkitAI (0) | 2026.10.20 |
