[Dev Log] 48시간 Vibe Coding - 게임잡스(게임업 신입 채용정보 웹)

 

서버비용 0원으로 구축한 '게임채용 자동화 대시보드' 개발기

 

이번 프로젝트는 “모든 로직을 직접 타이핑한 개발”은 아니다.

Vibe Coding 방식을 택했고, 

1. 문제 정의부터
2. 아키텍처 설계,
3. UX 재설계,
4. 성능 최적화,
5. 그리고 보안 문제까지

프로덕트 개발의 전체 사이클을 압축해서 경험했다.

 

이 글에서 말하고 싶은 핵심은 하나다.

이 프로젝트의 가치는 로직 문법이 아니라, 판단의 방향성에 있다.

---

1. 프로젝트를 시작하며

처음 이 프로젝트를 떠올렸을 때,
이건 기술적으로 어려운 문제는 아니다라고 판단했다.

[ 프로젝트 개요 ]
- 프로젝트명: GameJobs (게임잡스)
- 개발 기간: 2026.01.29 ~ 2026.01.31

> 문제 인식
게임 업계 채용 정보는 공채, 수시, 게임잡, 원티드 등 여러 플랫폼에 흩어져 있다.
특히 신입이나 주니어 개발자는 정보를 놓치기 쉽고, 마감일 관리도 어렵다.
신입 조건으로 필터링을 일일히 하기도 불편한 점이 있다.

> 해결 목표
1. 4개 이상의 채용 소스를 하나로 통합하고,
2. 기술 스택 / 게임 엔진 기준 필터링
3. 마감일 기반 캘린더 뷰
4. 서버 비용 0원(Zero Cost)
5. 자동화(Crawling) + 수동 보정(Admin)을 모두 고려한 실제 운영형 구조
6. 모바일까지 고려한 반응형 대시보드
를 제공하는 실사용 가능한 웹 서비스를 만드는 것!

👉 목표는 기능 구현이 아니라 ‘실제 프로덕트를 만드는 사람의 사고 흐름’을 배우고 드러내는 것이었다.

---

2. 기술 스택 결정의 의도

내가 처음 정의한 문제는 훨씬 단순했다.

• 유저는 읽기(Read)만 한다
• 쓰기는 자동화된 크롤러만 수행한다
• 실시간 트랜잭션, 복잡한 인증 필요 없다

이 판단 하나로 방향이 명확해졌다.

“이건 풀 서버 아키텍처를 설계할 문제가 아니라
데이터 신뢰성과 배포 안정성을 어떻게 확보할지의 문제다.”

 

그래서 선택한 구조가 바로
Supabase + GitHub Pages였다.

구분	기술	선정 이유
Backend / DB	Supabase	- 별도 백엔드 서버 없이 PostgreSQL 관리형 DB 즉시 사용 - CRUD API 자동 생성으로 백엔드 개발 부담 최소화 - 무료 티어에서도 REST API + RLS 제공
Hosting	GitHub Pages	- 정적 웹사이트에 최적화된 무료 호스팅 - 트래픽 증가에도 안정적 - GitHub Actions와 연동한 자동 배포(CD)
Crawler	GitHub Actions + Node.js	- 별도 크롤링 서버를 띄우지 않고, - 정해진 시간에 Actions 컨테이너를 실행하여 자원 절약

---

[ 시스템 아키텍처 ]

[Data Sources]      [Auto Crawler]          [Cloud DB]           [Client / User]
(Nexon/Wanted/...) ---> (GitHub Actions) ---> (Supabase) <-------- (GitHub Pages)
                            |                     ^                    |
                        Daily Schedule       REST API Calls        Static Hosting

• 수집(Collect)
  • 일정 시간에 GitHub Actions가 크롤러 스크립트(crawl.yml) 실행
• 저장(Store)
  • 크롤링 데이터는 무결성 검증 후 Supabase DB에 업데이트
• 배포(Deploy)
  • 프론트엔드 코드가 업데이트되면 GitHub Actions가 자동으로 빌드하여 GitHub Pages로 배포.
• 서비스(Serve)
  • 사용자는 배포된 정적 웹페이지에서 실시간으로 DB API를 호출하여 최신 공고를 확인.

이 모든 과정이 “백엔드를 만들지 않고도 백엔드를 운영하는 경험”이었다.

• 나는 서비스 로직을 고민하고
• DB는 데이터 정합성만 책임지게 만든다

+ 보안 문제
Github 세팅에서 Secret and variables 탭에서 나의 supabase에서 접근할 수 있는 API URL과 Key를 설정해두었다.

---

3. 자동화의 한계 인식과 설계 보완

“크롤링은 완벽하지 않다”

이 프로젝트에서 일부러 중요하게 고려한 전제가 하나 있다.

자동 크롤링 데이터는 언제든지 틀릴 수 있다...

• 회사명이 바뀌거나
• 공고가 수정되거나
• HTML 구조가 변경되는 경우

100% 정확한 크롤링은 매우 어렵다.

그래서 나는 “자동 수집”만 있는 서비스가 아니라

“자동 + 수동 보정이 공존하는 구조”를 설계했다.

---

관리자 전용 수정 기능

문제
잘못된 크롤링된 데이터가 사용자에게 그대로 노출될 경우, 서비스 신뢰도가 급격히 하락한다.

 

해결

• 관리자 전용 탭(Admin Tab) 추가
• 공고 데이터 직접 수정 가능
• 크롤러가 놓친 예외 케이스를 사람이 즉시 보정할 수 있도록 설계

이 방식은:

• 서버 없이도 관리자 권한을 분리할 수 있고
• 불필요한 인증 복잡도를 피하면서
• 프로젝트 규모에 맞는 현실적인 보안 수준을 유지한다

---

4. UX 결정 포인트: “햄버거 메뉴를 버린 이유”

이건 단순한 디자인 취향 문제가 아니었다.

내가 집중한 질문은 이거였다.

“이 서비스에서 사용자가 제일 많이 하는 행동은 뭔가?”

 

답은 명확했다.

• 탭을 자주 바꾼다. 여러 번 반복한다
• 짧은 시간 안에 확인하고 나간다

그래서 UX의 기준을 ‘공간 효율’이 아니라 ‘행동 효율’로 잡았다.

햄버거 메뉴는 화면은 깔끔하지만 탐색 비용이 사용되는 구조다.

Bottom Tab Bar는 결정 속도가 압도적으로 빨라진다.

 

---

5. 크롤러 설계 : “완벽한 수집보다 신뢰 가능한 데이터”

여기서도 핵심은 기술이 아니었다.

내가 가장 먼저 걱정한 건 이거였다.

“이 데이터, 믿어도 되나?”

 

그래서 크롤링 전략을 ‘많이 긁기’가 아니라 ‘헷갈리지 않게 만들기’로 잡았다.

• 회사명 정규화
• 중복 제거 Upsert

이건 크롤링 기술의 문제가 아니라 프로덕트를 대하는 태도의 문제였다.

👉 데이터가 많아도 신뢰할 수 없으면 쓰레기다.

 

문제
1. 게임잡, 원티드, 사람인 등 소스마다 회사명 표기가 다름 (예: (주)넥슨, 넥슨코리아, NEXON).
2. 단순 크롤링 시 동일 공고가 계속 쌓이는 문제 발생.

해결

• 정규화(Normalization) 알고리즘 적용
  • 특수문자, (주) 법인명, 괄호 안 영문명 등을 제거하는 전처리 로직을 구현하여 '진짜 회사 수' 통계를 산출.
• Upsert 전략
  • DB 저장 시 Link와 Title을 복합키로 사용하여, 기존 공고는 업데이트하고 신규 공고만 추가하는 ON CONFLICT 처리로 데이터 무결성 확보.

 

---

회고

이 프로젝트는 AI 어시스턴트와 협업하며
기획 → 설계 → 개발 → 배포 → 운영 관점까지
48시간 안에 완주한 기록이다.

 

이제 중요한 건 “코드를 어떻게 짰는가”가 아니라

고객 경험(UX, NEEDS)을 생각하는 것!

 

그것을 고려한 '의사결정의 방향성'을 잡는 것이 중요하다고 생각한다.

https://raindrovvv.github.io/gamejobs/

게임잡스 | 게임업계 신입/인턴 채용 대시보드

“사람은 판단하고 AI는 구현한다”

저는 AI를 적극적으로 활용하는 개발자입니다.
코드 구현은 AI 도구와 협업하고, 저는 문제 분석, 기술 설계, 트러블슈팅, 최종 검증에 집중합니다.
모든 기술적 의사결정과 트러블슈팅은 제가 직접 수행한 것이며, AI는 그 과정을 가속화하는 도구였습니다.

이 블로그는 그 판단과 사고의 기록입니다.
"어떤 도구를 쓰느냐"보다 "어떤 문제를 해결하느냐"가 진짜 개발자의 가치라고 믿습니다.

I believe a developer's value lies in "what problems they solve," not "what tools they use."