문제점
채용 지원(Job applications)은 그 어느 때보다 까다로워졌습니다. 긴 직무 기술서(JD), 좁은 요구사항, 그리고 역할별 스크리닝은 더 이상 '일률적인(one-size-fits-all)' 이력서가 통하지 않음을 의미합니다. 즉, 모든 역할에 맞춰 이력서를 맞춤화(tailor)해야 합니다. 게다가 다음과 같은 문제들이 있습니다:

• Easy Apply 및 ATS(채용 관리 시스템) 양식은 시간을 잡아먹는 평가 질문들을 추가합니다.
• 일부 역할은 자기소개서(cover letters), 포트폴리오 또는 추가 서류를 요구합니다.
• 단 한 번의 지원에 1~2시간이 쉽게 소요될 수 있지만, 1차 스크리닝을 통과한다는 보장도 없습니다.

대량으로 지원할 때 이러한 마찰(friction)은 빠르게 누적됩니다.

내가 시도한 것
저 또한 똑같은 벽에 부딪혔습니다. 그래서 Cursor의 Agent를 사용하여 수동 루프(manual loop)를 반자동화된 워크스페이스(semi-automated workspace)로 전환했습니다. 그 결과: 하나의 역할에 대부분의 시간을 소비하는 대신, 약 한 시간 만에 약 10개의 지원 건을 검색, 평가, 맞춤화 및 준비할 수 있게 되었습니다.

차이를 만든 요소:

• 멀티태스킹(Multi-tasking) — Agent가 탐색(discovery)을 처리하는 동안 이력서 맞춤화를 병렬로 진행합니다.
• Ask + 프로젝트 워크스페이스 — 기본 이력서, JD, 적합성 분석(fit analysis), PDF 및 로그를 위한 하나의 리포지토리(repo)를 사용합니다.
• IDE 내 브라우저 자동화(In-IDE browser automation) — Agent가 LinkedIn을 탐색하면, 저는 여러 채용 페이지의 요약본을 한눈에 확인하고 지원하기 전에 어디에 노력을 투자할지 결정합니다.

저는 여전히 '제출(Submit)' 버튼은 직접 클릭합니다. Agent는 체크포인트에서 멈춥니다. 이를 통해 자동화가 반복적인 준비 작업을 수행하는 동안, 품질과 판단력은 제 손에 유지됩니다.

설정 방법
모든 것은 작은 프로젝트에 문서화되어 있습니다:

• RUNBOOK.md — 일일 채용 지원 배치(batch) (탐색 → JD → 맞춤화 → PDF → 지원 준비)
• /multitask — 하나씩 하는 대신 여러 개의 이력서를 병렬로 맞춤화합니다.

채팅에서 사용하는 간단한 명령어:

• Run today's job application batch per RUNBOOK.md (RUNBOOK.md에 따라 오늘의 채용 지원 배치를 실행합니다)
• applied <slug> 또는 skipped <slug> (실제로 제출한 내용을 기록합니다)
• continue batch (중단된 지점부터 배치를 계속합니다)

엄격한 순차적 루프 대신

만약 당신이 2026년에 구직 활동을 하고 있다면, 런북 (runbook) + 에이전트 (agent) + 브라우저 MCP (browser MCP) + 하나의 워크스페이스 (one workspace) 조합은 번아웃 (burnout) 없이 애플리케이션 (applications)을 확장할 수 있는 실질적인 방법입니다.