사이드 프로젝트 주제를 정할 때 "이걸 만들면 취업에 도움이 될까?"를 고민해 본 적이 있다면, 이 글이 그 고민에서 출발한 이야기다.
원티드 AI Championship 2026에서 5명이 4주 동안 만들어 TOP 20에 선정된 Refactor.me의 기획부터 데모데이까지를 5편으로 정리했다.
기획 — 무엇을, 왜 만들기로 했나
구현 ① — 기술 블로그와 채용 공고 데이터 파이프라인
구현 ② — 화면, 그리고 GitHub 저장소에서 경험 찾기
검증 — AI가 만든 제안의 근거를 어떻게 믿을 것인가
데모데이 후기와 회고
회사 기술 블로그에서 그 회사가 반복해서 다루는 문제를 뽑아, 취업 준비생이 다음에 만들 프로젝트를 근거 글과 함께 제안하는 서비스를 만들었다.
대회: 원티드 AI Championship 2026
일정: 9월 12일 개발 시작 → 9월 20일 과제 제출 → 10월 7일 TOP 20 발표 → 10월 17일 데모데이
팀: 5명
개발자 취업을 준비하면서 가장 오래 고민한 질문은 "다음에 무슨 프로젝트를 만들어야 하지?"였다.
나는 금융 회사 백엔드 개발자로 취업하는 방향을 알아보고 있었는데, 어떤 방향으로 준비해야 할지 감이 오지 않았다. 내가 가진 경험을 가장 잘 살릴 수 있는 회사가 어디인지도 찾지 못했다.
채용 공고에는 "대용량 트래픽 경험 우대" 같은 문장이 있지만, 그 회사가 실제로 어떤 문제를 어떻게 풀고 있는지까지는 알려 주지 않는다. 그래서 준비하는 사람은 회사와 상관없는 프로젝트를 만들거나, 감으로 주제를 고르게 된다.
회사 기술 블로그에는 그 조직이 반복해서 다루는 일이 쌓여 있다. 같은 주제의 글이 여러 번 올라온다면, 그건 그 회사가 실제로 오래 붙잡고 있는 문제라는 뜻이다.
그래서 이렇게 정했다.
회사 기술 블로그 글을 모아 그 회사가 반복해서 다루는 영역을 뽑는다.
그 영역을 바탕으로 취업 준비생이 직접 만들어 볼 수 있는 프로젝트를 제안한다.
제안마다 근거가 된 블로그 글을 붙인다.
GitHub 저장소를 넣으면 이미 해 본 경험을 찾아서, 회사가 하는 일과 내 경험이 얼마나 먼지 보여 준다.
서비스에 들어오는 길은 두 갈래로 나눴다.
회사부터: 회사와 직무를 고르면 그 회사가 반복해서 다루는 일과 프로젝트 제안이 나온다.
경험부터: 직무를 고르고 내 경험(또는 GitHub 저장소)을 넣으면, 회사를 "잘 맞아요 / 한 걸음 필요해요 / 지금은 거리가 있어요"로 나눠 보여 준다.
모든 회사를 다룰 수는 없었다. 그래서 먼저 111개 회사의 기술 블로그를 가볍게 전수 조사했다. 기준은 단순했다.
RSS나 sitemap으로 글 목록을 가져올 수 있는가
직무별로 기술 글이 8개 이상 있는가
여기서 34곳이 통과했고, 최종적으로 33개 회사를 대상으로 정했다. 직무는 서버·백엔드, 웹 프론트엔드, 데이터·AI, 모바일 4개로 묶었다.
회사 × 직무 조합 중에서도 근거가 충분히 모인 것만 서비스에 올렸다. 새 프로젝트 제안이 하나 이상 있고, 근거가 된 블로그 글이 2편 이상인 조합만 게시했다. 이 기준을 왜 2편으로 정했는지는 4편에서 다룬다. 마지막에 게시된 조합은 79개다.
처음부터 정한 원칙이다.
단계 | 방식 |
|---|---|
글 수집, 기술 글 여부·직무 분류 | 규칙 기반 코드 |
글 한 편 요약, 영역 이름 짓기, 프로젝트 제안 생성 | LLM |
제안의 근거가 실제로 있는지 확인 | 결정적 코드 (LLM 아님) |
LLM은 그럴듯한 문장을 잘 만들지만, 그 문장이 사실인지는 보장하지 않는다. 그래서 만드는 일은 LLM에게, 확인하는 일은 코드에게 맡기기로 했다. 이 검증 이야기는 4편에서 자세히 다룬다.
처음에는 채용 공고 데이터도 가져와서 기술 블로그를 보조하는 데이터로 쓰려고 했다. 그런데 채용 사이트의 공고는 실시간으로 올라오고 내려가서, 한 번 모아 둔 데이터에는 유효기간이 있었다. 4주 안에 둘 다 안정적으로 챙기기는 어렵다고 판단했고, 기술 블로그 데이터를 더 안정적으로 수집하는 데 시간을 쓰기로 했다.
같은 이유로 회사 블로그 글을 시간순으로 보여 주는 타임라인 화면도 뺐다. 핵심인 "제안과 근거"를 제대로 만드는 데 집중하고, 근거 글 데이터는 제안 화면을 받치는 데 쓰기로 범위를 바꿨다.
5명이 데이터 수집, 화면, 저장소 분석을 나눠 맡았다. 나는 주로 데이터와 검증 쪽을 맡았다.
채용 공고 수집기와 기술 블로그 111곳 전수 조사
AI가 만든 제안의 근거 검증과 게시 기준 설계
110개 조합의 제안 대량 생성을 5명이 나눠 돌리는 절차 운영
저장소 분석 품질 측정과 모델 비교
내 경험 기준으로 결과를 다시 보는 화면(/me)
가장 어려웠던 건 두 가지였다.
첫째는 데이터를 어떻게 확보할지였다. 아이디어가 아무리 좋아도 회사마다 블로그 구조가 다르고, 글을 안정적으로 모을 방법이 없으면 서비스가 성립하지 않았다.
둘째는 우리 서비스만의 차별점을 정하는 일이었다. 비슷한 서비스의 레퍼런스를 찾아볼수록 "그럼 우리는 뭐가 다르지?"라는 질문이 계속 남았다. 결국 "회사가 실제로 다루는 문제를 근거와 함께 보여 주고, 내 경험을 기반으로 유의미한 프로젝트를 제안한다"는 점을 차별점으로 잡았다.
사이드 프로젝트를 기획하는 분들께 하나만 남기자면, 만들 기능보다 확보할 수 있는 데이터부터 확인하는 것이다. 이번 기획에서 가장 먼저 한 일도 111개 회사 블로그를 실제로 긁어 볼 수 있는지 확인하는 것이었다.
다음 글에서는 33개 회사의 기술 블로그와 채용 공고를 어떻게 모으고, 회사가 반복해서 다루는 영역을 어떻게 뽑았는지 정리한다.
이 글은 벨로그에 연재한 Refactor.me 해커톤 회고 시리즈의 1편입니다. 원문: [벨로그 링크]
