공개된 블로그나 웹 데이터를 긁어서 사이드 프로젝트를 만들어 본 적이 있다면, "긁어 온 데이터를 그대로 믿어도 되나?"에서 한 번쯤 막혀 봤을 것이다.
원티드 AI Championship 2026에서 5명이 만들어 TOP 20에 선정된 Refactor.me의 기획부터 데모데이까지를 5편으로 정리했다.
기획 — 무엇을, 왜 만들기로 했나
구현 ① — 기술 블로그와 채용 공고 데이터 파이프라인
구현 ② — 화면, 그리고 GitHub 저장소에서 경험 찾기
검증 — AI가 만든 제안의 근거를 어떻게 믿을 것인가
데모데이 후기와 회고
111개 회사 기술 블로그를 모아 보니 글 날짜, 글 개수, 심지어 원문까지 그대로 믿을 수 없었다. 회사마다 예외를 두는 대신 모든 회사에 같은 확인 규칙을 걸어 데이터를 다시 모았고, 최종적으로 79개 회사 × 직무 조합을 게시했다.
1편에서는 기획을 정리했다. 이번 글은 데이터를 실제로 어떻게 모으고 가공했는지에 대한 이야기다.
LLM(대규모 언어 모델)이 들어가는 곳은 "글마다 한 줄 요약", "영역 이름 짓기", "프로젝트 제안 생성" 세 군데뿐이다. 나머지는 전부 코드로 처리했다.
처음 맡은 일은 채용 공고 수집기였다. 회사마다 채용 페이지가 달라서 플랫폼별로 수집기를 따로 만들었다.
그리팅, 나인하이어 같은 채용 플랫폼
SK 그룹 채용 API
리크루터 ATS(채용 관리 시스템) 공통 모듈 (GS리테일, 컴투스 등)
회사가 직접 만든 채용 사이트
수집한 공고는 LLM 없이 키워드 규칙으로 4개 직무에 분류했다. 목적은 "우리가 정한 직무 4개가 실제 채용 시장에 충분히 있는가"를 확인하는 것이었다. 직무마다 3개 회사 이상이 있으면 통과로 봤다.
직무 | 분류된 회사 수 |
|---|---|
서버·백엔드 | 14곳 |
웹 프론트엔드 | 9곳 |
모바일 | 4곳 |
데이터·AI | 18곳 |
네 직무 모두 기준을 넘었다.
그런데 1편에서 쓴 것처럼, 채용 공고는 실시간으로 올라오고 내려간다. 데이터를 주기적으로 업데이트해야 했다. 수집 닷새 만에, 마감일을 판정할 수 있었던 공고 57건 중 5건이 이미 마감이었고 나머지 310건은 마감일 자체가 없었다. 이후 영역별 공고 건수와 공고 제목을 근거로 화면에 올려 보기도 했지만, 숫자가 실제와 어긋날 위험이 커서 결국 화면에서 뺐다.
내가 맡아서 구현한 기능이라 빼는 게 아쉬웠지만, 제출 마감까지는 MVP(핵심 기능만 담은 첫 버전)를 먼저 완성하기로 했다. 채용 데이터를 주기적으로 업데이트하는 작업은 마감 뒤 서비스를 다듬을 때 자동화하기로 계획했다.
서비스의 주인공은 기술 블로그였다. 111개 회사를 대상으로 RSS(사이트가 새 글 목록을 내보내는 피드)나 sitemap(사이트의 페이지 목록 파일)으로 글 목록을 가져올 수 있는지, 직무별 기술 글이 8개 이상인지 가볍게 확인했고, 34곳이 통과했다.
본격적으로 12개월치 글을 모으자 예상하지 못한 문제가 나왔다.
sitemap 날짜를 믿을 수 없었다. 어떤 사이트는 sitemap의 lastmod(마지막 수정일)가 글을 쓴 날이 아니라 sitemap을 만든 날이었다. 삼성반도체는 383건이 전부 수집 당일 날짜로 찍혀 있었다.
12개월을 다 모으지 못한 회사가 많았다. 27개 회사를 검증해 보니 10곳은 사실상 최근 1~2개월치 글만으로 기준을 통과한 상태였다. RSS가 최근 글 몇 건만 주기 때문이다. 토스는 RSS가 20건, 가비아는 10건까지만 나왔다.
그래서 두 가지 규칙을 모든 회사에 똑같이 적용했다.
날짜는 검증하고 쓴다.
12개월에 못 미치면 Wayback Machine(인터넷 아카이브가 옛 웹 페이지를 저장해 둔 서비스)이나 블로그 API로 이전 글을 보강한다.
회사별 예외 처리로 하나씩 막는 대신 모든 회사에 같은 규칙을 거는 쪽을 택했다. 이렇게 보강하자 토스는 20건에서 93건, 가비아는 10건에서 70건으로 늘었다.
영역을 미리 정해 둔 목록에 끼워 맞추지 않고, 글에서 직접 뽑는 방식을 택했다. 이 파이프라인은 팀원 C가 설계했고, 회사를 그룹으로 나눠 함께 돌렸다.
글마다 한 줄 요약: LLM으로 그 글이 다루는 엔지니어링 주제를 한 문장으로 뽑는다.
임베딩: 요약 문장을 multilingual-e5-small 모델로 숫자 벡터로 바꾼다. 뜻이 비슷한 문장은 가까운 벡터가 된다.
클러스터링: 가까운 것끼리 차례로 합쳐 나가는 방식(Agglomerative 클러스터링)으로 비슷한 글끼리 묶는다.
영역 확정: 묶음을 LLM이 3~5개 영역으로 합치고 이름을 붙인다. 글을 영역에 다시 배정하는 건 코드로 한다.
나는 그룹 2·4에 해당하는 16개 회사를 맡았다. 처음에는 491건으로 돌렸는데, RSS 상한에 걸린 회사들을 Wayback과 블로그 API로 메운 뒤 573건 기준으로 영역을 다시 확정했다.
영역이 정해지면, 회사 × 직무 조합마다 프로젝트 제안을 만든다. 제안은 두 종류다.
직접 풀어 볼 문제: 회사가 겪은 문제로 새 프로젝트를 만든다.
따라 해 볼 사례: 회사가 문제를 푼 방법을 내 프로젝트에 적용한다.
대상은 33개 회사, 110개 조합이었다. 나는 조합마다 프롬프트를 파일로 뽑고(export) 응답을 다시 가져와(import) 형식을 검사하는 스크립트를 만들었고, 5명이 회사 단위로 나눠 돌리는 실행 가이드를 썼다.
이후 팀원 A가 이 절차를 담당자별 Claude Code 스킬로 옮겼고, 나는 스킬이 조합 4개씩을 서브에이전트(작업을 나눠 맡는 보조 AI)로 동시에 돌리도록 바꿔 팀원들 스킬에도 반영했다.
제안 품질을 맞추려고 프롬프트 규칙을 13개로 정리했다. 몇 가지를 옮기면 이렇다.
회사가 부딪힌 문제에서 출발한다.
어느 단계부터 시작해도 노트북 하나로 시작할 수 있어야 한다.
개수를 채우려고 억지로 만들지 않는다. 안 나오면 적게 낸다.
그 회사 밖에서는 쓰지 않는 업계 전용 표준은 제안하지 않는다.
생성 도중 큰 문제가 하나 터졌다. 근거 검증은 "AI가 인용한 문장이 원문에 실제로 있는가"를 확인하는데, 일부 회사의 "원문" 캐시가 실제 글이 아니라 AI가 요약한 문장으로 채워져 있었다. 원문 자리에 요약이 들어가 있으니, 검증이 통과해도 실제 근거는 원문에 없는 상황이었다.
팀원이 원본 HTML을 직접 다시 받아 대조하다가 발견했다. 첫 문장이 "~을 다룬다", "~사례다" 같은 요약체로 끝나는 비율을 회사별로 세어 보니 kt cloud는 113건 중 102건(90%), 라인플러스는 70건 중 59건(84%)이었다.
오염된 6개 회사는 원문을 다시 모으고 영역과 제안을 새로 만들었다. 이 6개 회사의 재생성분이 내 담당으로 넘어오면서 내 담당은 40개 조합으로 늘었다.
최종적으로 근거 기준을 통과한 79개 조합이 게시됐다.
데이터 파이프라인에서 시간이 가장 많이 든 곳은 코드가 아니라 데이터를 믿을 수 있는지 확인하는 일이었다. 회사마다 예외를 만들지 않고 같은 규칙을 거는 게 빨랐고, 검증이 통과했다고 끝이 아니라 검증이 대조하는 기준 자체가 맞는지도 봐야 했다.
사이드 프로젝트에서 데이터를 긁어 쓴다면, 기능을 붙이기 전에 그 데이터의 날짜와 개수, 그리고 원문이 정말 원문인지부터 확인해 보길 권한다.
다음 글에서는 이 데이터를 사용자가 보는 화면으로 옮기고, GitHub 저장소에서 경험을 찾아내는 기능을 어떻게 만들었는지 정리한다.
이 글은 벨로그에 연재한 Refactor.me 해커톤 회고 시리즈의 2편입니다. 원문: [벨로그 링크]
