원문은 AIdeazz에 게시되었으며, 정식 링크(canonical link)와 함께 이곳에 교차 게시되었습니다.

나의 첫 번째 프로덕션 AI 에이전트인 VibeJobHunter는 나에게 일자리를 찾아주는 데 실패했습니다. 일자리를 찾지 못해서가 아니라, 내가 그 에이전트의 가장 "강력한" 기능인 자동 지원 (Auto-apply) 기능을 의도적으로 무력화했기 때문입니다. 완전히 자율적인 구직 봇을 만들고 싶은 유혹은 엄청났습니다. 특히 새로운 나라에서 새벽 2시에 채용 공고를 뒤지며 고군분투하는 싱글맘으로서 더욱 그랬습니다. 만들 수도 있었습니다. 기술적인 요소들은 모두 갖춰져 있었습니다. 멀티 에이전트 오케스트레이션 (Multi-agent orchestration), 동적 이력서 생성 (Dynamic resume generation), 심지어 어조와 기업 가치에 맞게 조정할 수 있는 LLM 기반의 자기소개서 작성기까지 말이죠. 하지만 나는 그렇게 하지 않았습니다. 나는 명확한 선을 그었고, 그 결정으로 인해 시간은 더 걸렸지만, 나의 진정성을 지킬 수 있었으며, 진정으로 중요한 부분에서 인간적인 요소를 보존할 수 있었다고 믿습니다.

새벽 2시의 고군분투와 완전 자동화의 유혹

파나마로 이주한다는 것은 커리어를 처음부터 다시 시작해야 함을 의미했습니다. 미국 기반 직무들과의 시차 때문에 현지 시간으로 새벽 2시에 지원해야 하는 경우가 많았습니다. 이는 지속 가능하지 않았습니다. VibeJobHunter를 위한 나의 초기 목표는 간단했습니다. 수동적인 번거로움을 없애는 것이었습니다. 나는 다음과 같은 시스템을 구상했습니다:

1. 채용 공고 스캔: 크론 잡 (Cron jobs)에 의해 트리거되는 Oracle Cloud Functions를 사용하여 LinkedIn, Indeed, 그리고 기업 채용 페이지를 스크래핑합니다.
2. 필터링 및 순위 지정: 초기 키워드 매칭을 위한 Groq 기반 에이전트와 내 프로필과의 의미론적 적합성 (Semantic fit)을 판단하여 관련성에 따라 직무 순위를 매기는 Claude 3.5 Sonnet 에이전트를 활용합니다.
3. 지원 자료 맞춤화: 내 경력에 대한 구조화된 지식 베이스 (Knowledge base)에서 정보를 가져와, 각 직무에 맞는 이력서 변형본과 자기소개서를 동적으로 생성합니다.
4. 자동 지원 (Auto-apply): 꿈의 기능입니다. 채용 포털을 통해 직접 지원서를 제출합니다.

1~3단계는 구현되었고 정상적으로 작동했습니다. 저의 Oracle Autonomous Database는 저의 경험, 기술, 프로젝트 세부 정보를 구조화된 형식으로 저장했습니다. OCI VM에서 실행되는 Python 에이전트가 채용 공고(job descriptions)를 가져와 Groq로 전달하여 신속한 초기 스크리닝을 수행하고(비용: 1k 토큰당 $0.0001), 그 다음 Claude 3.5 Sonnet으로 전달하여 심층 분석 및 이력서 맞춤화 지침을 생성했습니다(비용: 1k 토큰당 $0.003). 이 시스템은 이전에 지원서 하나당 20분이 걸리던 작업을 30초 이내에 매우 맞춤화된 이력서와 자기소개서로 생성할 수 있었습니다. 이는 40배의 속도 향상이었습니다.

자동 지원(Auto-Apply)이 기술적 결정이 아닌 제품 결정이었던 이유

자동 지원(auto-apply) 구성 요소는 기술적으로 가능했습니다. 저는 Selenium과 Playwright를 사용하여 브라우저 상호작용을 시뮬레이션하고, 양식을 채우고 제출 버튼을 클릭하는 프로토타입을 제작했습니다. 이는 채용 포털의 약 70%에서 작동했습니다. 나머지 30%는 복잡한 CAPTCHA, 커스텀 JavaScript, 또는 지속적인 유지보수 없이는 안정적으로 자동화하기에 너무 취약한 특정 로그인 흐름을 가지고 있었습니다.

하지만 진짜 장애물은 기술적인 것이 아니었습니다. 그것은 윤리적인 문제였습니다. 저는 지원 프로세스를 완전히 자동화하는 것이 구직 활동과 저의 관계를 근본적으로 변화시킬 것이라는 점을 깨달았습니다. 그것은 저를 바로 '나'를 나타내기 위한 그 과정으로부터 분리된, 수동적인 관찰자로 만들어 버릴 것이었습니다.

자동 지원 단계에서 멈춘 핵심적인 이유는 다음과 같습니다:

1. 의도성의 상실 (Loss of Intentionality): "제출" 버튼을 클릭하는 것은 하나의 약속입니다. 그것은 "네, 저는 이 특정 직무를 원합니다"라고 말하는 순간입니다. 이를 자동화하는 것은 그러한 의식적인 결정을 제거합니다. 이는 단순히 광범위한 기준에 부합한다는 이유만으로, 제가 진심으로 원하지 않을 수도 있는 역할에 지원하게 될 위험을 초래합니다. 이는 저의 시간을 낭비할 뿐만 아니라, 더 중요한 것은 채용 담당자(Recruiter)의 시간을 낭비하게 만듭니다.
2. 피드백 루프의 저하 (Feedback Loop Degradation): 지원서를 보내기 전에 수동으로 검토할 때, 저는 배움을 얻습니다. 직무 기술서(Job Description)에서 패턴을 발견하고, 이력서의 초점을 다듬으며, 자기소개서(Cover Letter)의 어조를 개선합니다. 자동 지원 시스템은 강력한 로깅(Logging) 기능이 있더라도 이러한 학습 과정을 추상화하여 없애버립니다. 피드백 루프는 인간 중심적(예: "이 회사의 미션에 강한 유대감을 느꼈다")이 아니라 순수하게 데이터 중심적(예: "이러한 유형의 지원은 X%의 응답률을 보인다")으로 변질됩니다.
3. 채용 담당자와의 윤리적 경계 (Ethical Boundary with Recruiters): 채용을 해본 사람으로서, 저는 지원서를 검토하는 데 들어가는 노력을 알고 있습니다. 제가 직접 검토하지 않은 지원서를 보내는 것은 무례하게 느껴집니다. 이는 제가 진정한 관심보다 자동화를 더 가치 있게 여긴다는 신호입니다. 이것은 단순히 "들키느냐 마느냐"의 문제가 아니라, 지원자와 고용주 사이의 암묵적인 계약에 관한 문제입니다.
4. 취약한 자동화 대 인간의 적응력 (Brittle Automation vs. Human Adaptability): 저의 에이전트(Agent)들이 이력서와 자기소개서를 수정할 수는 있겠지만, 저 자신을 수정할 수는 없었습니다. 직무 기술서를 검토하는 인간은 LLM이 놓치거나 잘못 해석할 수 있는 미묘한 문화적 적합성, 특정 프로젝트와의 정렬, 또는 회사의 "회사 소개" 페이지에 담긴 뉘앙스를 알아차릴 수 있습니다. 이러한 인간의 통찰력은 단순히 통계적으로 최적화된 지원이 아닌, 진정으로 맞춤화된(Bespoke) 지원을 가능하게 합니다.

이제 저의 VibeJobHunter 시스템은 맞춤형 자료를 생성하고 이를 Telegram 봇을 통해 저에게 제시하는 단계에서 멈춥니다. 저는 채용 공고(Job Description), 생성된 이력서(Resume), 그리고 자기소개서(Cover Letter)를 검토합니다. 내용이 적절하다면 Telegram에서 버튼을 클릭하고, 시스템은 맞춤형 문서들이 업로드될 준비가 된 상태로 브라우저의 지원 페이지를 엽니다. 그런 다음 제가 수동으로 "제출(Submit)"을 클릭합니다. 이러한 하이브리드(Hybrid) 접근 방식은 저의 의도성(Intentionality)을 보존하면서도 효율성을 유지합니다.

구직 활동에서 AI의 경계: 어디에서 멈춰야 하는가

AI는 패턴 인식(Pattern Recognition), 데이터 합성(Data Synthesis), 그리고 반복적인 작업에 탁월합니다. AI는 다음과 같은 용도로 사용되어야 합니다:

• 탐색 및 필터링 (Discovery and Filtering): 수백만 개의 채용 공고를 훑어 관련 있는 공고를 찾아내는 것.
• 정보 합성 (Information Synthesis): 핵심 요구 사항, 기업 가치, 그리고 연락처 정보를 추출하는 것.
• 콘텐츠 생성 (초안 작성) (Content Generation (Drafting)): 이력서, 자기소개서, 심지어 면접 준비 질문의 초기 초안을 작성하는 것.
• 일정 관리 (Scheduling): 인간의 관심이 확인된 후 면접 일정을 조정하는 것.

AI가 선을 넘지 말아야 할 부분:

• 최종 제출 (Final Submission): 궁극적인 "전송(Send)" 버튼은 반드시 인간에 의해 작동되어야 합니다.
• 대인 커뮤니케이션 (초기 단계) (Interpersonal Communication (Initial Stages)): AI가 이메일 초안을 작성할 수는 있지만, 채용 담당자(Recruiter)나 채용 매니저(Hiring Manager)에게 보내는 첫 연락은 인간의 검토를 거쳐 발송되어야 합니다. 이는 개인적인 유대감을 형성합니다.
• 적합성에 대한 의사결정 (Decision-Making on Fit): AI는 적합성을 "제안"할 수는 있지만, 특정 역할이 개인의 커리어 목표, 가치관, 그리고 원하는 근무 환경과 일치하는지에 대한 최종 결정은 인간의 영역으로 남아야 합니다.
• 면접 수행 (Interview Performance): 면접 중에 실시간으로 답변을 생성하기 위해 AI를 사용하는 것은 비윤리적일 뿐만 아니라, 스스로를 망치는 행위입니다. 이는 진정한 상호작용을 방해하며, 지원자의 실제 능력에 대해 아무것도 보여주지 못합니다.

Oracle Cloud Infrastructure (OCI)에서 실행되는 저의 VibeJobHunter 시스템은 멀티 에이전트 아키텍처 (multi-agent architecture)를 사용합니다. "Scout" 에이전트 (OCI VM 상의 Python 스크립트)는 채용 게시판을 스크래핑 (scraping)합니다. "Filter" 에이전트 (Groq + Claude)는 채용 공고를 처리하고 순위를 매깁니다. "Tailor" 에이전트 (Claude)는 서류를 맞춤화합니다. "Notifier" 에이전트 (Python + Telegram API)는 최종 패키지를 저에게 전송합니다. 이러한 모듈성 (modularity) 덕분에 저는 "인간 참여 (human in the loop)" 지점을 정밀하게 제어할 수 있습니다. 매일 수백 개의 채용 공고를 처리하는 이 전체 파이프라인 (pipeline)의 비용은 LLM 토큰 및 OCI 컴퓨팅 비용을 포함하여 일반적으로 월 10달러 미만이며, 이는 제가 절약한 시간의 가치보다 훨씬 적습니다.

AI 주도 채용의 윤리적 함의

이 논의는 지원자에게만 국한된 것이 아닙니다. 기업들도 이력서 스크리닝 (resume screening)부터 인터뷰 분석에 이르기까지 채용 과정에서 AI를 점점 더 많이 사용하고 있습니다. 윤리적 경계는 그곳에도 적용됩니다.

• 편향 증폭 (Bias Amplification): 과거의 채용 데이터로 학습된 AI 모델은 기존의 편향을 영속화하거나 심지어 증폭시킬 수 있습니다. 만약 어떤 기업이 역사적으로 기술직군에서 여성 채용을 적게 했다면, 해당 데이터로 학습된 AI는 의도치 않게 여성 후보자의 우선순위를 낮출 수 있습니다. 저의 시스템은 인구통계학적 추론 (demographic inference)이 아닌 기술 및 경력 추출에 집중함으로써 이를 완화합니다.
• 투명성 (Transparency): 지원자와 고용주 모두 투명성을 가질 권리가 있습니다. 만약 이력서 스크리닝에 AI가 사용된다면 지원자는 이를 알아야 합니다. 만약 AI가 지원서의 일부를 생성한다면, 지원자는 이를 인지하고 출력물에 대해 완전한 통제권을 가져야 합니다.
• 인간의 감독 (Human Oversight): 제가 제 지원 과정에서 인간의 감독을 유지하는 것처럼, 채용에 AI를 사용하는 기업들도 반드시 인간의 감독을 유지해야 합니다. AI는 인간의 의사결정을 보조해야 하며, 대체해서는 안 됩니다. 누가 인터뷰를 보거나 채용 제안을 받을지에 대한 최종 결정은 항상 인간 채용 담당자가 내려야 합니다.

채용에서 AI의 목표는 양측 모두에게 마찰을 줄이고 매칭(Matching)을 개선하는 것이어야 하며, 인간적인 요소를 완전히 제거하는 것이 아닙니다. VibeJobHunter를 구축하고 사용하며 얻은 경험은 이러한 신념을 더욱 공고히 해주었습니다. 가장 효과적인 AI 시스템은 인간을 대체하려는 시스템이 아니라, 인간에게 권한을 부여하는 시스템입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 이미 존재하는 수많은 기성 자동 지원(Auto-apply) 도구를 그냥 사용하면 안 되나요?
A: 기성 도구들은 종종 AI 모델의 투명성이 부족하여, 편향성(Bias)을 감사하거나 의사 결정 과정을 이해하는 것이 불가능합니다. 또한 특정 이력서 버전에 필요한 수준의 맞춤화(Customization)나, 비용 효율적인 확장(Scaling)을 위해 기존의 Oracle Cloud 인프라와 통합할 수 있는 기능도 거의 제공하지 않습니다.

Q: 채용 게시판에서 스크래핑(Scraping)이나 자동 지원을 명시적으로 금지하고 있다면 어떻게 하나요?
A: 저의 "Scout" 에이전트는 robots.txt 지침을 준수하도록 설정되어 있습니다. 명시적인 자동화 방지 조치(예: 복잡한 CAPTCHA, IP 차단)가 있는 채용 게시판의 경우, 시스템이 이를 수동 검토 대상으로 표시하거나 완전히 건너뜁니다. 목표는 효율성이지, 서비스 약관을 우회하는 것이 아닙니다.

Q: 빈번하게 변경되는 동적인 직무 기술서(Job Description)는 어떻게 처리하나요?
A: "Scout" 에이전트는 새로운 공고를 확인하고 기존 공고를 업데이트하기 위해 매일 점검을 수행합니다. 직무 기술서가 크게 변경되면, 시스템은 이를 "Filter" 및 "Tailor" 에이전트를 통해 다시 처리하며, 저는 검토를 위한 업데이트된 지원 패키지를 받게 됩니다. 이를 통해 제 지원서가 항상 최신 정보에 기반하도록 보장합니다.

Q: VibeJobHunter를 구축하며 직면한 가장 큰 기술적 과제는 무엇이었나요?
A: 서로 다른 LLM 제공업체(속도를 위한 Groq, 품질을 위한 Claude) 간에 멀티 에이전트 워크플로(Multi-agent workflow)를 안정적으로 오케스트레이션(Orchestrating)하고, Oracle Autonomous Database와 다양한 Python 에이전트 간의 데이터 일관성을 보장하는 것이었습니다. 시스템 가동 시간(Uptime)과 데이터 무결성(Data integrity)을 유지하기 위해 API 호출에 대한 오류 처리(Error handling) 및 재시도 메커니즘(Retry mechanisms)이 매우 중요했습니다.

— Elena Revicheva · AIdeazz · Portfolio