방치해둔 2024년형 이미지보드 소프트웨어를 투표 시스템, 광고, 연령 인증이 없는 현대적인 4chan/reddit 하이브리드로 '바이브코딩'했습니다. 이용자는 거의 없습니다.
I vibecoded my abandoned 2024 imageboard software into a modern 4chan/reddit hybrid with no voting system, 0 ads, 0 age verification, and (close to) 0 users.
핵심 요약
AI를 활용해 방치된 이미지보드 프로젝트를 현대적인 모듈형 모놀리스 구조로 재구축한 개발기입니다.
- 기술 스택 — Go, HTMX, PostgreSQL, Docker를 활용한 단순한 구조로 구성됨
- AI 개발 환경 — Cloudflare MCP와 자동화 파이프라인을 통해 AI가 직접 배포 및 관리함
- 아키텍처 설계 — 모듈형 모놀리스와 결정론적 가드레일을 통해 AI의 코드 품질을 유지함
- 운영 전략 — 캐싱과 R2를 활용해 VPS 부하를 최소화하고 비용 효율성을 극대화함
everiot.org
원문 사이트로 이동
2024년부터 손대다 만 이미지보드 프로젝트가 하나 있었거든. 요즘 AI 코딩 성능이 워낙 좋아져서, 이거 다시 살려서 제대로 된 사이트로 만들어보기로 했다. 이름은 Everiot. 작업은 대부분 GPT-5.4, GPT-5.5, 그리고 최근엔 GPT-5.6 sol-medium으로 돌렸어. 난 sol medium만 쓴다.
스택은 간단해:
-
백엔드는 Go, 템플릿은 Templ 라이브러리 써서 서버 사이드 렌더링함. SPA는 딱 질색이고, LLM이 Go 코드는 기가 막히게 짜거든.
-
동적 상호작용은 HTMX.
-
데이터베이스는 PostgreSQL.
-
TypeScript는 진짜 꼭 필요한 곳에만 조금 씀.
-
Docker.
-
10달러짜리 VPS.
-
앞단에 Cloudflare 둬서 캐싱이랑 보안 챙김. Cloudflare 무료 캐싱 최대한 활용하려고 애쓰는 중이야. 목표는 눈팅하는 익명 유저들은 VPS가 일할 필요 없이 Cloudflare 엣지에서 바로 캐시된 페이지랑 미디어를 받아가게 만드는 거임.
-
이미지 저장소는 R2.
이런 워크플로우에는 Cloudflare가 진짜 최고더라. 문서도 깔끔하고, 무료 티어도 혜자고, 툴 자체가 AI 보조 개발이랑 궁합이 잘 맞아. Cloudflare MCP랑 스킬을 워크플로우에 넣어서 코딩 에이전트한테 플랫폼이랑 API 관련 맥락을 계속 주입하고 있어. 새로운 기능 추가할 때 Cloudflare 사이트에서 뭘 건드려야 하면, Codex가 알아서 하거나 나한테 정확히 뭘 해야 할지 알려줌. 메뉴 여기저기 클릭하면서 돌아다니는 거 진짜 싫거든.
기능 하나 요청해서 완성되면, Codex가 GitHub Actions를 통해 스테이징 환경에 자동으로 배포함. 첫 주에 GitHub Actions 무료 시간 다 까먹기 싫어서 파이프라인 최적화하느라 몇 시간 고생 좀 했다. 내가 직접 하는 건 프로덕션 배포 버튼 누르는 게 전부임.
개발 툴링
기능 구현만큼이나 결정론적 가드레일이랑 개발 툴링 만드는 데도 시간 엄청 썼어. 탄탄한 테스트 스위트도 갖췄고, 파이프라인에 golangci-lint도 박아놨고, 일반적인 Go 툴로는 못 잡는 Everiot 전용 아키텍처 규칙을 위한 커스텀 린터도 만들었지.
중요한 건 이 체크들이 '결정론적'이라는 거야. AI 리뷰어한테 "제발 나쁜 패턴 좀 잡아줘"라고 비는 게 아니라, 리포지토리 수준에서 금지된 의존성, 아키텍처 경계 위반, 필수 로직 누락, 테스트로 커버되는 회귀 버그 같은 걸 매번 확실하게 컷해버림. AI랑 빠르게 작업할 때 이게 진짜 중요하거든. 모델이 코드를 엄청나게 찍어내고 리팩토링해도, 가드레일이 있으니까 아키텍처랑 컨벤션이 무너질 일이 없음. 스테이징 배포 전에 테스트, 린터, CI 체크가 다 돌아가니까, 빠른 반복 주기를 돌려도 믿을 구석이 있는 거지. 물론 git hook도 가드레일 1차 방어선으로 쓰고 있고. 코드베이스가 튕겨내 줄 때 '바이브 코딩'이 제일 잘 되는 법임.
아키텍처
그래서 Everiot은 아키텍처상 모듈형 헥사고날 모놀리스야. 배포 가능한 Go 애플리케이션 하나인데, 도메인 로직이랑 인프라 어댑터를 분리해서 모듈별로 깔끔하게 쪼개놨음.
LLM 보조 개발에는 수직적 슬라이스로 나뉜 모듈형 모놀리스가 최고인 것 같아. 각 기능이 자기만의 영역을 확실하게 가지고 있거든. 핸들러, 애플리케이션 로직, 도메인 규칙, 영속성, 테스트, UI까지 전부 한 리포지토리, 하나의 배포 시스템 안에 있으면서도 모듈별로 딱딱 나뉘어 있으니까. 모델 입장에서도 작업할 범위가 좁고 명확해서 훨씬 보기 편하지. 기능 하나 추가하려고 폴더 미로를 헤맬 필요가 없잖아. 아까 말한 개발 툴링 덕분에 모듈 경계나 가드레일이 아키텍처를 가로지르는 꼼수를 못 쓰게 막아주기도 하고.


