로또 사이트 프론트엔드와 봇의 프로젝트 뼈대 구축

새 프로젝트의 첫 scaffold를 올렸다. lotto.hedvion.com 이라는 서브도메인 기반 프로젝트의 뼈대 작업.

무엇을 만들기 시작했나

이번 커밋은 말 그대로 "빈 집 짓기"다. 실제 기능이 들어가기 전에 프로젝트가 돌아갈 수 있는 최소한의 구조를 잡는 작업이었음. 변경된 파일 목록을 보면 명확하게 드러난다.

구조적으로 흥미로운 점은 프론트엔드(Astro) 와 봇(Python) 이 같은 레포에 공존하는 형태라는 것. bot/ 디렉터리 아래 별도 .env.example 이 있다는 게 그걸 말해준다. 모노레포까지는 아니더라도, 웹과 봇 두 레이어가 하나의 저장소 안에서 시작점을 공유하는 구조다.

scaffold 커밋이 왜 중요한가

팀을 이끌다 보면 "scaffold 커밋은 빨리 올리고 나중에 정리하자"는 유혹이 있다. 근데 이게 나중에 진짜 비용으로 돌아온다. 초기 구조가 흐릿하면 두 번째, 세 번째 기여자가 합류할 때 "이 파일이 왜 여기 있지?", "환경변수는 어디서 보지?" 같은 질문이 슬랙을 채운다.

그래서 scaffold 단계에서 내가 신경 쓰는 것들:

• .env.example 은 실제 키 이름까지 다 담는다. 값은 비워도 되지만 키 구조는 완성형으로. 나중에 온보딩할 사람이 이 파일 하나만 보고 환경을 셋업할 수 있어야 한다.
• .gitignore 는 프레임워크 기본 템플릿에 프로젝트 특성을 더한다. Astro 기본 + Python 가상환경 + 봇 로컬 캐시 같은 것들. 나중에 .gitignore 에 없어서 실수로 시크릿이 커밋되는 사고는 초기에 방어해야 한다.
• README.md 는 진짜 내용이 없어도 '어떤 프로젝트인지 한 줄'은 있어야 한다. 빈 README 는 사실상 없는 것과 같음.

이번 커밋은 그 원칙들을 그대로 따랐다.

Astro + Python bot 조합에 대해

astro.config.mjs 와 bot/generate.py 가 함께 올라온 것 자체가 이 프로젝트의 성격을 암시한다. 정적 또는 서버사이드 렌더링 기반의 프론트엔드와, 무언가를 생성(generate)하는 Python 봇이 맞물리는 구조. 아직 초기라 내부 구현이 채워지지 않았지만, 이 두 레이어가 어떻게 데이터를 주고받을지가 이 프로젝트의 핵심 설계 포인트가 될 것 같다.

Astro는 정적 사이트 생성(SSG) 쪽으로 활용도가 높은 프레임워크라, 봇이 데이터를 생성 → 파일이나 API 형태로 노출 → Astro가 빌드타임 혹은 런타임에 소비하는 흐름을 예상해볼 수 있다. generate.py 라는 이름이 그 방향을 더 강하게 암시한다.

# bot/generate.py - 초기 scaffold 단계
# 아직 내용은 비어있지만, 이 파일이 봇의 진입점이 될 것

// astro.config.mjs - Astro 설정 진입점
// 프론트엔드 빌드/서버 전략이 여기서 결정된다

초기 scaffold 단계에서 이미 두 컴포넌트의 경계가 파일 구조로 명시됐다는 게 중요하다. 나중에 "이 코드 어디 넣지?" 하는 혼란을 줄여주는 것이 결국 초기 구조 설계의 역할이니까.

다음 커밋들이 이 뼈대를 어떻게 채워나가는지가 기대된다. 끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.