웹 자동화 3가지 방식을 비교해보고, 채용에 '내부 API'를 고른 이유

📝 한줄 요약

채용 플랫폼에서 후보자 이력을 검토하고 DM을 보내는 작업을, 화면을 클릭하는 방식이 아니라 플랫폼 내부 API를 직접 조사해서 자동화해봤습니다. 똑같은 일을 하는 두 가지 스킬을 만들어 나란히 비교했고, 중간에 막혔던 401 인증 오류의 원인까지 끝까지 추적해 후보 20명 검토 자동화에 성공했습니다.

🎯 이런 분들께 도움돼요

• 소규모 팀에서 직접 채용하며 후보 검토·DM에 시간을 많이 쓰는 창업가/리더

• Codex·Claude Code 같은 AI 코딩 도구로 반복 업무를 자동화하고 싶은 비개발자

• 웹 자동화를 어떤 방식으로 해야 할지(클릭 자동화 vs API) 고민하는 분

😫 문제 상황 (Before)

저는 채용 직무 문서(JD, 평가 기준표, 커피챗/면접 질문지)를 만드는 일은 이미 AI로 자동화해두었습니다. 그런데 그 다음 단계가 문제였어요.

채용은 보통 이런 흐름으로 흘러갑니다.

1. 직무를 정의하고 (JD 생성)

2. 채용 공고에 올릴 내용과 커피챗에서 나눌 이야기를 확정한 뒤

3. 이 문서를 기준으로 채용 플랫폼에서 후보자 이력을 하나하나 검토하고

4. 괜찮은 사람에게 DM을 보내는 것

3번과 4번이 진짜 노동이었습니다. 플랫폼에서 후보를 한 명씩 열어 이력을 읽고, 우리 직무에 맞는지 판단하고, 맞으면 DM을 쓰는 일을 반복해야 하니까요.

그래서 이걸 자동화하기로 했는데, 막상 시작하니 더 근본적인 질문이 생겼습니다. "웹 자동화를 대체 어떤 방식으로 해야 하지?" 사실상 선택지는 세 가지였습니다.

• ① Computer Use에 전적으로 의존 — AI가 사람처럼 화면을 보고 마우스/키보드를 움직이는 방식

• ② Playwright 같은 브라우저 스크립트 — 버튼·입력창을 코드로 지정해 조작하는 방식

• ③ 플랫폼 내부 API를 조사해서 사용 — 화면 뒤에서 실제로 오가는 데이터 통신을 직접 호출하는 방식

사실 ③번에 눈길이 간 데는 계기가 있었습니다. 사내에서 공유 오피스 회의실 예약을 자동화한 사례가 있었는데, 공유 오피스 운영 회사 웹사이트의 내부 API로 회의실 예약을 Claude Code 같은 에이전트가 직접 하게 한 방식이었어요. 이게 Playwright나 Computer Use를 쓰는 것보다 훨씬 안정적으로 보였고, "채용 아웃바운드 활동에도 적용할 수 있지 않을까?" 하는 생각이 들었습니다. 그러던 중 Computer Use 자동화를 다룬 x.com 해외 게시물에서, LinkedIn 자동화도 이런 플랫폼 내부 API를 활용하는 방식으로 할 수 있다는 글을 보고 용기를 얻어 시도해보게 됐습니다.

그래서 이번에는 ③번, 내부 API 방식이 이력 검토 자동화까지 실제로 쓸 만한지 직접 검증해보고 싶었습니다. 그래서 비교 실험을 시작했습니다.

🛠️ 사용한 도구

• 도구명: Codex CLI (주력)

• 보조: Rona 스킬 프레임워크 (스킬 제작용)

• 특이사항: 로그인된 Chrome 브라우저 세션을 그대로 활용 (별도 API 키 없이, 쿠키는 저장소에 저장하지 않음)

🔧 작업 과정

1. "내부 API로 후보 검토하는 스킬을 만들어줘" — 출발점

저는 이미 화면을 클릭해서 후보를 검토하는 스킬(wanted-dm)을 갖고 있었습니다. 이걸 그대로 두고, 내부 API를 쓰는 새 버전을 따로 만들어 비교하기로 했어요. Codex에 이렇게 요청했습니다.

기존 wanted-dm 스킬은 유지하고, Wanted Matchup 내부 API 조회 방식으로 새 산출물을 wanted-dm-api로 만들어라. 외부 추적/로그 전송은 내가 명시적으로 허락하기 전에는 하지 마라.

Codex는 미리 조사해둔 내부 API 문서를 바탕으로, 어떤 데이터 통신으로 후보 목록과 이력 미리보기를 가져올 수 있는지 정리하고, 그걸 호출하는 새 스킬을 만들었습니다. 핵심은 별도의 API 키 없이, 제가 기업회원으로 이미 로그인해둔 브라우저의 세션을 그대로 빌려 쓴다는 점이었습니다.

이때 한 가지 안전장치를 분명히 했어요. 기본 동작은 읽기 전용(read-only), 즉 정보만 가져오고 아무것도 바꾸지 않게 했습니다.

2. "발송까지 구현하되, 함부로 보내지 않게" — 승인 게이트 설계

이력만 읽는 걸로는 절반이죠. DM 발송까지 가야 했습니다. 다만 자동으로 메시지가 나가는 건 위험하니, 단계마다 사람이 확인하는 장치를 넣었습니다.

POST/proposal 기능도 구현해줘. 약관/계약 확인이 끝났고 후보별 승인 방식으로 실제 발송까지 구현해도 된다.

Codex는 발송 기능을 만들되, 약관 확인 + 후보별 '승인' 표시가 있어야만 메시지가 나가도록 잠금을 걸었습니다. 게다가 첫 발송은 무조건 1명으로 제한했어요. 한 명 보내보고 결과를 확인한 뒤에 이어가는 구조입니다.

여기서 한 가지 더 챙긴 건 상대 서버에 대한 예의였습니다. 정보를 읽을 때는 2초, 메시지를 보낼 때는 10초 간격을 두도록 했고, 이게 적절한지 Codex에게 따로 리서치까지 시켰습니다. (결론: 소규모 수동 보조 작업엔 보수적인 출발점이고, 서버가 "너무 빠르다"는 신호를 주면 그 지시를 우선한다.)

3. 두 스킬을 나란히 돌려보기 — 그리고 막힘

이제 본 게임. 똑같은 채용 공고, 똑같은 직무 문서, 똑같은 메시지 템플릿으로 **화면 기반(기존)**과 API 기반(신규) 두 스킬을 같은 조건에서 돌려 비교했습니다.

화면 기반 스킬은 무난히 후보 20명 화면을 확인하고 검토까지 해냈습니다. 그런데 API 기반 스킬이 계속 막혔습니다.

• 처음엔 필요한 라이브러리가 없어서 멈추고

• 설치하고 다시 했더니 기본 브라우저에서 로그인 쿠키를 못 찾고

• 권한을 올려 재시도하니 이번엔 비밀번호 조회 단계에서 90초 넘게 멈춰 수동 중단

여기서 한 번 UX를 개선했습니다. "쿠키가 없으면 그냥 멈추지 말고, 브라우저를 띄워서 나한테 로그인하라고 해줘"라고요.

브라우저 쿠키가 없을 때 Headed browser 띄워서 나한테 로그인하라고 하는 건 어때? 지금처럼 중단되면 안 되거든. 그리고 timeout 말고, 내가 '로그인 완료' 입력을 하면 그 뒤에 작업을 진행하는 걸로 해줘.

이걸 반영하니 로그인 안내는 깔끔하게 동작했는데, 여전히 API가 401 인증 오류를 뱉었습니다. 로그인은 됐는데 권한이 없다니, 답답한 순간이었죠.

4. 401의 진짜 범인 — "쿠키"였다 (이번 작업의 하이라이트)

여기서 Codex에게 끝까지 파보라고 했습니다.

API preflight를 디버깅해서, 실제 Read까지 되는 것까지 확인해줘. 그리고 이전에 실패한 이유와 이번에 성공한 이유를 쉽고 간결하게 설명해줘.

추적 방법이 영리했습니다. 화면 기반 스킬이 성공적으로 쓰고 있던 바로 그 로그인된 브라우저 안에서, 같은 API를 직접 불러본 거예요. 그랬더니 전부 정상(200) 응답이 왔습니다.

원인이 드러났습니다. 문제는 "권한"이 아니라 **"쿠키의 출처"**였어요.

• API 스킬은 기본 Chrome 프로필에서 쿠키를 긁어왔는데

• 실제로 로그인된 채용 화면은 다른 브라우저 세션이었던 겁니다

• 그래서 긁어온 쿠키로는 인증이 안 됐던 것 (= 401)

해결책은 명확했습니다. 쿠키를 따로 긁어오지 말고, 이미 로그인되어 살아있는 브라우저 세션에 직접 올라타서 API를 부르게 했습니다. 수정 후 다시 돌리니—

• 후보 20명 정보 가져오기 성공

• 직무 문서 기준으로 자동 평가 완료: 추천 1명 / 보류 6명 / 제외 13명

• 발송은 0건 (read-only 검증이라 의도된 결과)

비개발자에게 가장 와닿을 교훈이 여기 있었습니다. "로그인이 됐는데도 안 되면, AI가 보고 있는 창과 내가 로그인한 창이 같은 창인지부터 의심하라."

✅ 결과 (After)

Before vs After

결과물

• 동일 조건에서 화면 기반 vs API 기반 스킬을 비교한 실행 리포트

• API 기반 스킬로 후보 20명 검토 자동화 성공 (추천 1 / 보류 6 / 제외 13)

• 두 스킬이 후보·검토 이력을 공유하는 공통 로컬 저장소

결론: 가끔 진행하는 채용이라면, 내부 API 방식은 충분히 쓸 만한 선택지였습니다. (LinkedIn에서도 비슷하게 하는 사람들을 본 적이 있어, 일반적으로 통하는 접근이라고 봤습니다.)

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 똑같은 일을 하는 두 버전을 만들어 비교 — "어떤 방식이 나은가"를 말로 토론하는 대신, 둘 다 만들어 같은 조건에서 돌려보니 답이 명확해졌습니다.

2. "실패 이유와 성공 이유를 쉽게 설명해줘"라는 요청 — 단순히 고쳐달라가 아니라 원인을 설명하게 시키니, 401의 진짜 범인(쿠키 출처)을 제가 이해할 수 있었습니다.

3. 위험한 동작엔 게이트를 명시 — "기본은 읽기 전용", "발송 첫 1명 제한", "승인 표시 없으면 발송 금지"를 처음부터 못 박아 사고를 예방.

이렇게 하면 안 돼요

1. timeout에 기대지 마세요 — "몇 초 기다렸다 진행"은 로그인처럼 사람이 개입하는 단계에서 잘 깨집니다. "사용자가 완료 입력하면 진행"이 훨씬 안정적이었습니다.

2. 쿠키를 긁어오는 방식을 맹신하지 마세요 — 내가 로그인한 창과 자동화가 쓰는 창이 다르면 조용히 401이 납니다. 살아있는 세션에 직접 올라타는 편이 안정적입니다.

3. 상대 서버를 두드릴 땐 간격을 두세요 — 빠르게 많이 부르면 차단됩니다. 보수적으로 시작하고 서버가 거절 신호를 주면 즉시 늦추세요.

🌍 다른 업무에 적용한다면?

이 "내부 API를 조사해서 자동화"하는 접근은 채용 말고도, 로그인이 필요한 웹 서비스에서 반복적으로 같은 화면을 열어 데이터를 확인·정리하는 모든 업무에 응용할 수 있습니다. 단, 자동화하기 전에 꼭 거쳐야 하는 수동 단계들이 있다는 걸 인정하는 게 중요합니다. 이번 경험상 손이 필요한 부분은 이랬어요.

1. 로그인 — 사람이 직접 해야 안전합니다.

2. 플랫폼별 후보 최소 목록 만들기 — 원하는 인원보다 10~20배 많은 풀을, 플랫폼 자체 필터/검색으로 최대한 줄여둡니다.

3. 기준 자체를 다듬는 일 — JD와 질문지를 만든 뒤에도, 실제 커피챗/면접을 거치며 우리 팀에 필요한 스킬셋과 조건을 계속 수정해야 합니다.

🚀 앞으로의 계획

가장 이상적인 그림은 이렇습니다.

1. Computer Use로 사이트를 분석해서 화면 구조를 파악하고

2. 그 과정에서 내부 API를 알아낸 뒤

3. 로그인된 브라우저(Headed Browser)를 띄워 로그인만 사람이 하고, 그 세션 위에서 API를 호출하는 방식

이렇게 가면 이번에 겪은 401 같은 인증 문제도 자연스럽게 피할 수 있습니다. 다만 이런 흐름을 (헤르메스 같은) 에이전트에 심으려면, 매번 브라우저를 띄워 로그인하는 게 꽤 번거로운 지점이라, 그걸 더 매끄럽게 만들 방법은 계속 찾아볼 생각입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 같은 작업의 두 가지 방식을 비교 검증하기

기존 [방식 A] 스킬은 그대로 두고, [방식 B] 방식으로 같은 일을 하는 새 버전을 만들어줘. 그런 다음 동일한 입력 조건에서 두 방식을 나란히 실행해서 결과를 비교 정리해줘. 위험한 동작(발송/삭제 등)은 기본적으로 막아두고, 사람이 승인했을 때만 실행되게 해줘. [방식 A], [방식 B], [입력 조건]은 본인 상황에 맞게 변경하세요.

프롬프트 2: 막힌 원인을 '이해 가능하게' 디버깅시키기

[기능]이 [에러]로 막혔어. 디버깅해서 실제로 동작하는 것까지 확인해줘. 그리고 이전에 실패한 이유와 이번에 성공한 이유를 비개발자도 이해할 수 있게 쉽고 간결하게 설명해줘. [기능], [에러]는 본인 상황에 맞게 변경하세요.

프롬프트 3: 사람 개입 단계를 timeout 대신 '입력 대기'로 바꾸기

[로그인 같은 사람 개입 단계]에서 정해진 시간만 기다렸다 진행하지 말고, 필요한 창을 띄워준 다음 내가 '완료'라고 입력하면 그때 다음 작업을 이어서 진행하도록 바꿔줘.