AX에 도전하며 만든 취업 준비 서비스
공고 분석과 면접 준비를 연결한 서비스의 구성과 시행착오를 기록해요.
🚀 AX 공고를 보고 시작한 프로젝트
이번 프로젝트의 시작은 AX 엔지니어 채용공고였어요. AI를 활용해 업무를 개선하고, 여러 도구를 연결해 반복되는 일을 자동화하는 역할에 도전해보고 싶었어요.
프론트엔드 개발을 해왔지만, 공고에 나온 Cloudflare와 n8n을 활용해 하나의 서비스를 운영하는 경험도 만들어보고 싶었어요. 어떤 서비스를 만들면 이 도구들을 자연스럽게 써볼 수 있을지 고민하다가, 제가 하고 있던 취업 준비 과정을 주제로 정했어요.
공고마다 요구하는 경험이 다르다 보니 이력서와 포트폴리오를 다시 읽고, 강조할 경험을 고르고, 예상 질문을 정리하는 일이 반복됐어요. 이 자료들을 한곳에 모아두고 공고와 함께 비교할 수 있으면 저도 계속 사용할 이유가 있겠다고 생각했어요.
그렇게 기존 블로그 안에 개인용 취업 준비 서비스를 만들기 시작했어요. 이번 글에서는 어떤 서비스를 만들었고, 각 도구에 어떤 역할을 맡겼으며, 직접 사용하면서 무엇이 어려웠는지 이야기해보려고 해요.
🎯 어떤 서비스인가요?
이 서비스는 채용공고와 제 자료를 비교하고, 지원과 면접 준비를 이어가는 개인용 관리 도구예요. 블로그의 관리자 화면에 로그인해서 사용해요.
이력서와 포트폴리오 PDF를 등록하고, 관심 있는 원티드 공고를 추가해요. 이후 분석에 사용할 문서 버전을 선택하면 공고 요구사항과 제 경험을 비교한 결과를 볼 수 있어요. 결과에는 요구사항별 판단과 근거, 보완할 부분, 예상 면접 질문과 답변 초안이 포함돼요.
분석 결과를 읽고 끝내는 대신, 제 판단과 메모를 남기고 면접 답변을 작성할 수 있게 했어요. 지원 상태와 면접 일정도 같은 곳에서 관리해요.
예를 들어 공고에 운영 경험이 필요하다고 적혀 있다면, 제 자료에서 관련 경험을 찾고 무엇이 더 필요한지 확인하는 식이에요. 점수는 합격 확률이 아니라 현재 선택한 자료로 요구사항을 얼마나 뒷받침할 수 있는지 살펴보는 참고값이에요.
🧩 어떤 도구를 왜 사용했나요?
처음부터 모든 부분이 익숙했던 건 아니에요. Cloudflare와 n8n은 이번 프로젝트에서 직접 다뤄보고 싶은 기술이었고, 기존 Next.js 블로그와 AWS 사용 경험은 출발점으로 활용했어요. 필요한 역할을 나눈 뒤 각 도구를 배치했어요.
| 도구 | 이 서비스에서 맡은 역할 | 선택한 이유 |
|---|---|---|
| Next.js · Vercel | 블로그와 관리자 화면 제공·배포 | 기존 블로그를 확장하고 Git 연동 배포를 활용하기 위해 |
| Cloudflare Workers | 관리자 요청 확인, 작업 상태 관리, 결과 검증·저장 | 별도의 API 실행 환경을 구성하고 Cloudflare를 직접 익히기 위해 |
| n8n | 공고 수집, 문서 처리, AI 호출과 알림 순서 연결 | 여러 외부 서비스의 처리 순서와 분기를 눈으로 확인하기 위해 |
| Supabase | 로그인, 공고·분석 데이터와 PDF 보관 | 인증·데이터베이스·파일 저장을 한곳에서 관리하기 위해 |
| OpenAI | 문서·공고 해석과 요구사항 비교 | 표현이 서로 다른 공고와 개인 경험을 함께 해석하기 위해 |
| AWS Lightsail · Docker | n8n을 실행하는 서버와 컨테이너 환경 | 서버를 직접 관리하며 실행 환경을 재현하기 위해 |
| GitHub Actions | Worker·n8n 변경 검증과 배포 절차 실행 | 반복하는 배포 과정을 저장소의 설정으로 남기기 위해 |
| Slack | 공고별 진행 상황과 오류 알림 | 관리자 화면을 계속 열어두지 않아도 소식을 확인하기 위해 |
[Career Ops의 Next.js, Cloudflare Workers, n8n, Supabase, 외부 서비스와 배포 흐름을 나타낸 아키텍처]
화면은 Vercel, 요청 관리는 Worker
관리자 화면은 기존 Next.js 블로그에 추가했어요. 화면을 제공하는 곳은 Vercel이고, 사용자가 누른 작업을 접수하고 상태를 관리하는 곳은 Worker예요.
Vercel에는 기존 Git 연동을 유지했어요. Vercel의 Git 연동은 저장소 변경을 빌드와 배포로 연결해주기 때문에, 화면을 수정할 때 사용하는 흐름을 그대로 이어갈 수 있어요.
Cloudflare에서는 Workers를 API 실행 환경으로 사용했어요. 로그인한 관리자의 요청인지 확인하고, 작업을 등록하고, 돌아온 결과를 저장할 수 있는지 판단하는 역할이에요. 운영체제를 직접 관리하는 서버와는 다른 방식으로 API를 배포해보는 경험이기도 했어요.
외부 작업의 순서는 n8n
공고를 읽고, AI에 분석을 요청하고, 결과를 돌려보내는 순서는 n8n의 워크플로우로 구성했어요. 각 작업을 노드로 연결하고 성공과 실패에 따라 다른 경로로 이동하게 할 수 있어요.
Worker가 데이터에 적용할 규칙을 관리한다면, n8n은 외부 작업의 순서를 관리해요. 공고 수집이 끝난 뒤 무엇을 보내야 하는지, AI 요청이 실패하면 어떤 결과를 돌려줘야 하는지를 워크플로우에서 확인할 수 있게 나눈 거예요.
다만 노드와 분기가 많아지면 화면도 복잡해져요. 사용해보니 도구를 선택하는 것만큼 관련 작업을 묶고 흐름을 읽기 좋게 정리하는 일도 필요했어요.
n8n이 돌아갈 자리는 Lightsail과 Docker
n8n은 로컬에서 먼저 Docker로 실행했고, 운영 서버는 AWS Lightsail을 사용하는 구성으로 옮겼어요. Lightsail이 서버를 제공하고 Docker는 그 안에서 n8n과 필요한 서비스를 실행하는 역할이에요.
n8n의 Docker 설치 방식을 사용하면 실행할 이미지와 설정을 정해두고 환경을 다시 구성할 수 있어요. 로컬과 서버의 주소나 비밀값은 다르게 설정하되, 어떤 서비스를 실행해야 하는지는 같은 방식으로 관리하려고 했어요. 컨테이너를 교체하더라도 보관할 데이터는 볼륨으로 분리했어요.
Docker를 쓴다고 서버 관리까지 없어지는 건 아니었어요. 서버를 켜두고, 데이터를 보존하고, 문제가 생기면 복구하는 일은 따로 준비해야 해요.
변경 사항을 전달하는 GitHub Actions
서비스를 사용하다 보면 화면뿐 아니라 Worker 코드와 n8n 워크플로우도 계속 바뀌어요. 변경할 때마다 수동으로 파일을 옮기고 명령을 실행하는 과정을 줄이려고 GitHub Actions에 검증과 배포 절차를 구성했어요.
현재 설정은 master 변경에 따른 배포와, 대상을 선택하는 수동 배포를 지원해요. Vercel은 기존 Git 연동으로 화면을 배포하고, Actions는 Worker와 n8n을 담당하도록 나눴어요.
다만 설정을 작성한 것만으로 배포 자동화가 완성됐다고 보기는 어려워요. 변경 대상을 빠짐없이 감지하는지, 두 서비스의 배포 순서가 맞는지, 실패하면 복구할 수 있는지는 추가 보완과 검증이 남아 있어요.
🔄 실제로는 어떻게 사용하나요?
사용하는 흐름은 자료 등록 → 공고 수집 → 적합도 분석 → 면접 준비로 이어져요.
1. 이력서와 포트폴리오를 등록해요
관리자 화면에서 PDF를 업로드하면 파일은 Supabase Storage에 보관해요. 문서를 수정해서 다시 올릴 때는 새 버전으로 관리하고, 각 분석에서 어떤 버전을 사용했는지 남겨요.
문서의 텍스트를 추출하고 AI가 정리한 정보를 보관하는 흐름도 두었어요. 같은 문서를 공고마다 처음부터 처리하는 부담을 줄이고, 나중에 결과를 확인할 때 사용한 자료를 찾을 수 있게 하려는 목적이에요. 이미지에 담긴 경험을 어떻게 검토하고 반영할지는 계속 보완하고 있어요.
2. 관심 있는 공고를 등록해요
원티드 공고를 추가하면 Worker가 수집 작업을 접수하고 n8n에 요청해요. n8n이 가져온 내용을 Worker가 정리하고 확인한 뒤 Supabase에 저장해요.
공고 원문도 버전으로 남겨요. 나중에 공고가 바뀌거나 다시 수집하더라도, 이전 분석이 어떤 내용을 기준으로 했는지 확인하기 위해서예요. 자동 수집이 안 되는 경우에는 원문을 직접 입력할 수 있게 했어요.
3. 공고와 제 경험을 비교해요
분석할 공고와 문서 버전을 정해 요청하면, n8n이 AI 호출을 진행해요. 공고에서 요구하는 내용과 이력서·포트폴리오의 경험을 비교하고, 요구사항별 판단과 면접 준비에 사용할 내용을 받아요.
이 결과는 Worker를 거쳐 저장해요. 관리자 화면은 저장된 작업 상태를 확인하다가 결과가 준비되면 보여줘요. 사용자는 기다리는 동안 진행 상태를 보고, 완료 후에는 어떤 자료가 근거로 연결됐는지 확인하는 흐름이에요.
4. 결과를 제 준비로 연결해요
분석 결과에서 보완할 부분을 확인하고, 요구사항에 대한 제 판단과 메모를 남겨요. 예상 질문을 펼쳐 질문 의도와 답변 초안을 살펴보고 제 답변을 작성해요.
AI가 작성한 문장을 그대로 제 경험이라고 받아들이지는 않으려고 해요. 문서에 적힌 표현과 실제 제가 설명할 수 있는 경험이 같은지 확인한 뒤 답변을 다듬는 용도로 사용하고 싶어요.
Slack에는 공고별 스레드로 진행 상황을 모으는 구조를 두었어요. 분석 결과를 자세히 읽는 곳은 관리자 화면이고, Slack은 완료나 조치가 필요한 상황을 알려주는 역할이에요.
🛠️ 직접 사용하니 예상과 달랐던 부분
공고를 가져왔다고 전체 본문이 있는 건 아니었어요
실제로 공고를 등록해보니 주요 업무만 가져오거나, 근무지역 아래에 푸터와 추천 공고 문구가 섞이는 경우가 있었어요.   같은 문자가 그대로 나타나거나 고용조건 문장이 중간에서 잘리기도 했어요.
이 상태에서는 AI가 읽을 입력부터 부정확해져요. 그래서 본문을 선택하는 과정, 항목을 나누는 과정, 화면에 표시하는 과정을 나눠 확인했어요. 불필요한 문자는 정리하되 C++처럼 필요한 표현까지 지우지 않도록 하는 것도 필요했어요.
문자와 문장 경계에 대한 처리는 보완했지만, 모든 공고의 전체 본문을 확보한다고 보장할 수는 없어요. 일부만 수집됐을 때 그 사실을 사용자에게 알리는 부분은 더 개선해야 해요.
n8n의 성공 표시만 보고 안심할 수 없었어요
관리자 화면에는 OpenAI 요청을 처리할 수 없습니다가 나오는데 n8n 실행 목록에는 Succeeded가 보인 적이 있어요. 반대로 결과를 돌려보내는 단계가 실패해서 화면에 계속 분석 중으로 남는 경우도 있었어요.
처음에는 둘 중 어느 화면이 잘못된 건지 알기 어려웠어요. 확인하면서 알게 된 것은, n8n이 오류를 처리하는 경로로 정상 종료될 수도 있다는 점이에요. AI의 답변을 받는 일, Worker로 전달하는 일, DB에 저장하는 일도 각각 다른 단계였어요.
그 뒤로는 요청이 들어갔는지뿐 아니라 결과가 저장됐고 화면에서 다시 확인되는지까지 성공 기준에 포함하게 됐어요. 이런 문제를 만나면 어디서 멈췄는지 찾을 수 있도록 단계와 오류를 남기는 일도 필요했어요.
점수보다 근거를 읽을 수 있어야 했어요
초기 화면의 근거에는 API, 자동화처럼 짧은 단어만 표시되는 경우가 있었어요. 어떤 경험이 공고와 연결됐는지 판단하기에는 부족했어요.
그래서 선택한 문서와 인용문을 함께 보여주는 방향으로 바꿨어요. 그래도 인용문이 있다는 사실만으로 AI의 해석까지 맞다고 볼 수는 없어요. 문서에 Docker가 적혀 있다고 장기간 운영 경험이 확인되는 것은 아니니까요.
검증된 근거와 사람이 확인해야 할 부분을 구분하는 것은 이 서비스에서 계속 다듬어야 할 과제예요.
💭 만들고 나서 남은 것
코드와 테스트는 Codex와 함께 작성했어요. 저는 관리자 화면에서 직접 시도하고, 기대와 다른 결과를 캡처해 전달하고, 어떤 흐름으로 바꿀지 정하는 과정을 반복했어요. AI와 함께 해결한 과정과 제가 직접 설명하고 재현할 수 있는 경험은 구분해서 쌓아가려고 해요.
처음 목표는 AX 공고에 나온 기술을 사용해보는 것이었어요. 만들어보니 하나의 분석 결과가 화면에 도착하기까지 자료 수집, 외부 호출, 결과 저장, 배포와 상태 확인이 이어져야 한다는 걸 경험하게 됐어요.
프론트엔드에서 결과를 보여주는 화면을 만들던 경험도 도움이 됐어요. 결과가 있어도 근거를 읽기 어렵거나, 저장하지 않은 입력이 사라지거나, 다음 행동을 알 수 없다면 사용하기 불편하다는 것을 직접 확인할 수 있었거든요.
분석 성공을 확인한 경험은 있지만, 지금은 실패 경로와 입력 보존, 공고 수집 품질, 배포 절차에 보완할 부분이 남아 있어요. 다음에는 실제 지원할 공고로 반복해서 사용하며 결과가 준비에 도움이 되는지 확인하고 싶어요. 작업 시간이 얼마나 줄었는지도 그때부터 측정해보려고 해요.
AX에 도전하고 싶어서 시작한 프로젝트가 제가 취업을 준비하는 방식까지 돌아보게 했어요. 앞으로도 직접 쓰면서 불편한 지점을 찾고, 그 지점을 개선하는 프로젝트로 이어가려고 해요.
