BIOS Finder 개발일지 - BIOS 하나 찾기 귀찮아서 만들기 시작했다

회사에서 PC A/S 업무를 하다 보면 메인보드 BIOS를 찾아야 할 일이 자주 있다.

Google에 모델명을 검색하면 제조사 제품 페이지까지는 금방 나온다. 문제는 그다음이다.

ASUS, MSI, GIGABYTE, ASRock처럼 제조사마다 홈페이지 구성이 다르고 Support나 Download 메뉴의 위치도 제각각이다. 제품 페이지에 들어가 BIOS 메뉴를 찾고, 버전과 날짜를 확인한 다음 필요한 파일을 내려받아야 한다.

한두 번이면 별일 아닌데 A/S하면서 계속 반복하니 여기에 쓰는 시간이 아깝고 귀찮았다.

기존에는 대략 이런 식이었다.

Google에서 모델 검색
→ 제조사 제품 페이지
→ Support / Download
→ BIOS
→ 버전 확인
→ 다운로드

그래서 그냥 모델명만 입력하면 여러 제조사의 BIOS를 한곳에서 찾을 수 있는 페이지를 만들기로 했다.

BIOS Finder는 여기서 시작했다.

웹페이지보다 스크래퍼부터 만들었다

처음부터 복잡한 서비스를 만들 생각은 없었다.

필요했던 기능도 몇 가지뿐이었다.

• 메인보드 모델 검색
• BIOS 버전과 배포 날짜 확인
• BIOS 다운로드
• 나중에는 BIOS 설명과 칩셋 정보도 같이 표시

검색 화면을 만드는 것보다 먼저 해야 할 일이 있었다.

제조사 사이트에서 BIOS 데이터를 실제로 가져올 수 있어야 했다.

그래서 Python으로 스크래퍼부터 만들기 시작했다.

나는 코딩을 잘 아는 편은 아니라서 BIOS Finder의 코드는 대부분 AI 도움을 받아 작성했다. 처음에는 간단한 부분을 직접 건드려보기도 했지만, 제조사마다 예외가 생기기 시작하면서 ChatGPT Codex나 Claude Code에 구현을 맡기는 일이 많아졌다.

지금은 내가 필요한 기능이나 조건을 정리해서 프롬프트를 만들고, AI가 작성한 코드를 실제로 돌려보면서 결과를 확인하는 식으로 작업한다. 한쪽 답만 믿기보다는 ChatGPT, Claude, DeepSeek, Kimi 등에 같은 문제를 물어보고 비교해보기도 했다.

코드 자체는 AI가 대부분 작성했지만, 어떤 데이터를 가져올지, 제조사별로 어디서 문제가 생기는지, 실제 수집 결과가 맞는지는 계속 직접 확인하고 있다.

BIOS Finder도 한 번에 만들어진 게 아니라 이런 식으로 기능을 하나씩 붙이고 문제 생길 때마다 다시 고쳐가며 만들었다.

제조사마다 수집 방법이 제각각이었다

처음 지원 대상으로 잡은 제조사는 국내에서 접할 가능성이 높은 8곳이었다.

• ASUS
• MSI
• GIGABYTE
• ASRock
• MAXSUN
• BIOSTAR
• ECS
• Colorful

Colorful도 국내에 유통되는 제품이 있어 처음부터 포함했다.

이후에는 AliExpress에서 자주 보이고 한국에서도 직구해서 사용하는 HUANANZHI를 추가했다.

현재는 총 9개 제조사를 대상으로 한다.

처음에는 웹사이트니까 HTML 구조만 조금씩 다를 거라고 생각했다.

실제로 만들어보니 그렇지 않았다.

ASUS처럼 API에서 데이터를 가져올 수 있는 제조사가 있는 반면, 브라우저를 실제로 띄우는 방식이 필요한 곳도 있었다.

GIGABYTE 스크래퍼의 모델 목록 수집 부분도 현재는 Browser Context를 먼저 열고 그 안에서 JSON 데이터를 가져온다.

bootstrap = browser_client.navigate(BASE_URL)
if not bootstrap.ok:
    raise RuntimeError(
        f"Gigabyte browser bootstrap 실패: "
        f"{bootstrap.status}: {bootstrap.error}"
    )

chipsets_payload = _browser_json(
    browser_client.fetch_json(
        CHIPSET_API,
        headers=BROWSER_API_HEADERS,
    ),
    "칩셋 리스트 API",
)

같은 BIOS 정보 수집인데 제조사 이름만 바꿔서 쓸 수 있는 공통 스크래퍼는 만들기 어려웠다.

결국 제조사마다 따로 상대해야 했다. 😵‍💫

사이트에서 HTTP 200 OK가 나온다고 끝나는 것도 아니었다.

날짜 형식이 이상하게 들어오기도 했고, 페이지에서 가져온 모델명이 예상과 다르거나 정상 페이지인데 BIOS 데이터가 없는 경우도 있었다.

그래서 지금은 페이지가 열렸는지만 보는 게 아니라 실제 필요한 데이터가 정상적으로 들어왔는지도 같이 확인한다.

HUANANZHI를 추가한 이유도 비슷하다.

AliExpress에서 자주 보이는 중국 메인보드 브랜드 중 하나이고 한국에서도 직구해서 사용하는 경우가 있는데, 생각보다 공식 BIOS 페이지가 잘 마련되어 있었다.

반대로 AliExpress에서 많이 판매된다는 이유만으로 다른 브랜드까지 전부 추가하지는 않았다. 공식 BIOS 지원이 불분명하거나 사이트 상태가 좋지 않은 곳은 현재 지원 대상에서 뺐다.

매일 모든 BIOS를 긁어봤다가 포기했다

처음 수집 방식은 아주 단순했다.

하루에 한 번 모든 제조사의 모든 메인보드를 처음부터 다시 수집했다.

최신 상태를 유지하기에는 이게 가장 확실해 보였다.

문제는 모델 수가 많아지면서 나타났다.

수집 시간이 계속 길어졌고, 다음 날이 됐는데 전날 시작한 스크래퍼가 아직 돌아가고 있는 경우도 있었다.

요청량이 많아지니 제조사 사이트의 접근 제한도 신경 써야 했다.

그래서 매일 돌리던 것을 3일에 한 번으로 바꿔봤고, 다시 일주일에 한 번으로 늘려보기도 했다.

하지만 수집 주기만 늘리는 것으로는 해결되지 않았다.

생각해보면 몇 년째 BIOS가 바뀌지 않은 오래된 메인보드까지 매번 상세 페이지를 처음부터 다시 읽고 있었다.

처음

모든 제조사
    ↓
모든 모델
    ↓
모든 BIOS 재수집


현재

제조사 모델 목록 확인
    ↓
기존 DB와 비교
    ↓
신규 모델 / 다시 확인할 모델 선택
    ↓
필요한 BIOS만 확인

그래서 기존 DB를 기준으로 새로 추가된 모델이나 다시 확인할 필요가 있는 모델을 골라 수집하는 쪽으로 바꿨다.

현재 코드에서도 확인할 시점이 된 모델만 다시 선택한다.

SELECT vendor, source_key, model_name,
       tier, next_check_at
FROM model_state
WHERE tier IN (...)
  AND next_check_at <= ?
  AND lifecycle_status != 'DELISTED'
ORDER BY next_check_at
LIMIT ?

최근 BIOS 업데이트가 있었던 모델은 비교적 자주 확인하고, 오래된 모델은 확인 간격을 늘리는 방식이다.

새 모델이 발견되면 다시 상세 정보를 수집한다.

제조사 사이트가 일시적으로 이상하거나 수집에 실패했다고 기존에 정상적으로 가지고 있던 BIOS 데이터를 바로 지우지도 않는다.

처음의 모든 걸 매번 다시 가져오기에서 확인할 필요가 있는 것만 다시 보기로 바뀐 셈이다.

이건 처음부터 이렇게 만들었으면 좋았겠지만, 스크래퍼가 다음 날까지 돌아가는 걸 보고 나서야 구조를 제대로 바꾸게 됐다.

403 때문에 유료 프록시까지 결제했다

수집 시간이 긴 것 외에도 다른 문제가 있었다.

MSI와 GIGABYTE를 VPS에서 수집할 때 HTTP 403이 발생했다.

처음에는 VPS의 IP가 제조사 사이트에서 차단된 것이라고 생각했다.

그래서 IP를 바꿔 테스트해보려고 IPRoyal 프록시를 실제로 한 달 결제했다.

그런데 프록시를 사용해도 문제가 깔끔하게 해결되지는 않았다.

테스트를 계속하다 보니 같은 URL도 요청 방법에 따라 결과가 달랐다.

requests / curl
→ 403

프록시를 통한 일반 HTTP 요청
→ 여전히 403이 발생하는 경우 있음

실제 Chrome Browser Context
→ 정상 응답

처음 생각했던 것처럼 단순히 VPS IP만 차단된 문제로 보기는 어려웠다.

TLS fingerprint나 봇 탐지 방식 차이 때문일 수도 있겠다 싶었다.

결국 IP만 바꿔서는 해결되지 않았고, 일반 HTTP 요청과 실제 브라우저 요청의 결과가 달랐다.

그래서 현재 MSI와 GIGABYTE는 실제 Chrome Browser Context를 이용해서 데이터를 가져온다.

필요한 경우 프록시를 사용할 수 있는 구조도 남아 있지만 일반적인 수집에서는 Browser Context를 우선 사용한다.

IPRoyal 한 달치는 수업료가 됐다. 🥲

홈서버 대신 VPS에서 돌린 이유

BIOS 스크래퍼를 내 홈서버에서 돌리는 방법도 있었다.

하지만 일부러 VPS에 분리했다.

가장 먼저 신경 쓰인 건 IP였다.

홈서버는 내 집 공유기와 같은 인터넷 회선을 사용한다.

스크래핑 때문에 제조사 사이트에서 집 공인 IP가 차단되면 스크래퍼만 문제가 생기는 게 아니다. 내 개인 PC에서 평범하게 해당 제조사 사이트에 들어가려고 할 때도 영향을 받을 수 있다.

홈서버의 자원도 이유였다.

내 서버에는 BIOS Finder만 있는 게 아니라 여러 Docker 서비스가 같이 돌아간다.

스크래퍼가 오랫동안 CPU나 RAM, 네트워크를 사용한다고 다른 서비스까지 영향을 받을 필요는 없었다.

그래서 BIOS 수집 작업은 VPS로 따로 분리했다.

제조사 사이트
      ↓
VPS
Python Scraper
      ↓
SQLite
      ↓
Rust / Axum API
      ↓
BIOS Finder Web

수집한 BIOS 정보는 SQLite에 저장한다.

웹 UI가 SQLite 파일에 직접 접근하는 구조는 아니고 Rust/Axum API가 rusqlite를 통해 조회한 결과를 전달한다.

처음 DB를 정할 때 SQLite를 후보로 생각했고 ChatGPT와 Claude에도 구조를 물어봤다. BIOS Finder처럼 수집한 데이터를 검색해서 읽는 일이 대부분인 구조라 현재 규모에서는 SQLite로 충분하다고 판단했다.

그래서 지금도 PostgreSQL이나 MySQL로 바꾸지 않고 SQLite를 사용하고 있다.

지금은 실제 A/S할 때 사용한다

처음 BIOS Finder를 만들었던 이유는 결국 내가 업무 중 쓰기 위해서였다.

지금도 BIOS를 찾을 일이 생기면 실제로 사용한다.

예전에는:

Google에서 모델 검색
→ 제조사 제품 페이지
→ Support / Download
→ BIOS
→ 버전 확인
→ 다운로드

였다면 지금은:

BIOS Finder
→ 모델 검색
→ BIOS 버전 / 날짜 확인
→ 다운로드

정도로 줄었다.

현재 BIOS Finder에서는 9개 제조사의 메인보드를 통합 검색하고 다음 정보를 확인할 수 있다.

• BIOS 버전
• 배포 날짜
• BIOS 다운로드
• 칩셋과 모델 정보
• BIOS 설명 한국어 번역
• Beta·RC·Preview BIOS 구분

물론 실제 A/S에서 BIOS를 올릴 때는 여기서 버전과 파일만 먼저 찾는다.

업데이트 직전에는 제조사 공식 페이지에서 메인보드 모델과 리비전, 주의사항을 한 번 더 확인한다.

제조사 홈페이지를 일일이 뒤지는 시간을 줄이고 필요한 BIOS를 빠르게 찾고 버전을 확인하기 위한 도구로 사용하고 있다.

처음에는 제조사 사이트를 매번 돌아다니는 게 귀찮아서 만들기 시작했다.

그런데 하나씩 만들다 보니 제조사마다 다른 스크래퍼를 만들고, 모든 모델을 매일 긁어보고, 403 때문에 유료 프록시까지 결제하고, 결국 VPS도 따로 사용하게 됐다.

지금은 처음 생각했던 대로 A/S하면서 실제로 쓰고 있다.

다만 제조사 사이트 구조가 또 크게 바뀐다면?

그때는 해당 스크래퍼도 또 고쳐야 한다. 😇