in-labs 아키텍처: 무과금 지향 블로그·데이터 설계 가이드라인

테스트넷·스마트 컨트랙트·S3(JSON)·Next.js(SSR/ISR)·Vercel을 묶어 거의 무과금으로 운영하는 in-labs의 구조와 데이터 흐름, 캐시·보안·비용 전략을 한눈에 정리합니다.

핵심 전제: 블로그는 읽기(Read) 비중이 높고, 쓰기(Write) 는 상대적으로 드뭅니다.
그래서 “읽기는 빠르게, 쓰기는 안전하게”를 목표로 설계합니다.

TL;DR

• DB를 상시 과금형으로 두지 않는다. 읽기 중심 데이터는 S3(JSON) + Next.js ISR로 처리한다.
• 온체인은 ‘증명/무결성 앵커’ 역할에 집중한다. (CID/해시, 최소 인덱스)
• 쓰기 경로는 느려도 안전, 읽기 경로는 캐시/프리렌더로 빠르게 만든다.
• 성장해도 전체 교체가 아니라 부분 교체가 가능하도록 “경계(경로/책임)”를 명확히 둔다.

목표: “거의 0원” 운영

• 상시 과금되는 관리형 DB 대신 체인(테스트넷) + S3(JSON) 로 읽기 중심 워크로드를 처리합니다.
• 검색 노출을 위해 SSR/ISR을 활용해 초기 응답 속도와 크롤러 친화성을 확보합니다.
• 도메인은 구매하되, 배포·호스팅·데이터 계층은 무료·저가 옵션을 우선합니다.

선택의 이유

• Next.js(App Router): SSR/ISR 혼합으로 SEO와 속도의 균형.
• 스마트 컨트랙트(테스트넷): 포스트 무결성 앵커(CID/해시)와 최소 메타 인덱스를 온체인에 기록.
• AWS S3(JSON): 삭제되면 안 되는 스냅샷/원본을 저렴하게 저장.
• Vercel(무료 플랜): 빌드·프리뷰·엣지 캐시와 쉬운 커스텀 도메인 연결.

주의: 테스트넷은 합의 지연·리오그가 있을 수 있습니다.
읽기·쓰기 경로에 재시도와 임시 캐시를 넣어야 합니다.

전체 아키텍처(큰 그림)

• Write Path(발행/수정): Admin → Contract(해시/CID) → S3(index.json 갱신)
• Read Path(렌더/조회): Vercel Edge Cache → ISR(목록/홈) + SSR(신규/미생성) → S3 원본/인덱스

읽기는 빠르게, 쓰기는 안전하게

1) 게시/수정(Write Path)

1. 관리자 도구에서 작성/수정
2. 컨트랙트에 포스트 CID/해시 기록 (무결성 앵커)
3. S3에 index.json 업데이트 (목록/태그/정렬의 기준)

2) 페이지 요청(Read Path)

• 인기 글·목록: ISR로 사전 생성 → Vercel 에지에서 빠르게 제공
• 신규/미생성: SSR로 즉시 렌더 → 이후 짧은 주기로 재검증/재생성

3) 검증(선택 적용)

• 렌더 시 컨트랙트에서 해시를 조회해 S3 원본과 일치성 확인
• 모든 페이지에 100% 적용하지 않고, “관리자/중요 포스트/신규 발행 직후”처럼 선별 적용

팁: 내부 링크를 촘촘히 연결하면 크롤러가 더 많은 페이지를 탐색합니다.
(시리즈 글/연관 글/태그 페이지를 적극 활용)

캐시·SEO 전략: ISR 우선, SSR 보완

페이지 유형별 권장 전략

페이지 타입	권장	이유	운영 팁
홈/목록/태그	ISR	변동이 느림 + 캐시 효율 최고	revalidate 길게(비용 절감)
상세 페이지(포스트)	SSR → ISR	발행 직후 신선도 + 이후 캐시	신규 포스트만 SSR, 나머진 ISR
동적 데이터	클라 캐시	체인/RPC 호출 비용 제어	React Query 등으로 캐시/리트라이

revalidate 기준(예시)

• 홈/목록/태그: 10~60분 (쓰기 빈도에 따라)
• 상세 페이지: 1~10분 (발행 직후는 짧게, 안정되면 길게)

핵심 전제: 읽기 비중이 높고 쓰기 빈도는 낮다.
그래서 ISR을 기본으로 두면 비용/응답 속도가 안정된다.

무엇을 아끼고 어디에 쓰나 (비용 상한 관점)

항목	선택	과금 특성	운영 메모
데이터베이스	미사용	0원	체인 + S3로 대체
블록체인	테스트넷	무료(가스/쿼터 주의)	RPC 쿼터/속도 확인
스토리지	S3(JSON)	저가/버저닝	index.json 단일화로 단순 운영
호스팅	Vercel 무료	무료(제한 존재)	트래픽/빌드 제한 모니터링
도메인	구매	연 단위	최소 1개 유지

팁: 이미지 다량 트래픽은 초기엔 Vercel 이미지 최적화를 이용하고,
성장 시 전용 CDN을 검토합니다.

(보강) 실패 시나리오와 복구 전략

무과금 아키텍처는 “단순”한 대신, 실패 지점을 미리 정리해야 운영이 편합니다.

1) RPC 지연/쿼터 초과

• 증상: 페이지 로딩 지연, 해시 검증 실패, 간헐적 5xx
• 대응:
  • 읽기 경로에서 체인 호출은 “필요할 때만”
  • 캐시(클라/서버) + 백오프 재시도
  • RPC 제공자 교체가 가능한 인터페이스 유지

2) 테스트넷 리오그/지연

• 증상: “방금 발행한 글”이 목록에 늦게 반영되거나 일시 불일치
• 대응:
  • 발행 직후는 SSR로 제공 + “검증 중” 배지
  • 최종 확정(컨펌 N회) 이후에만 강한 일치성 보장

3) S3 index.json 갱신 실패

• 증상: 목록/태그 페이지가 최신 글을 못 봄
• 대응:
  • index.json 버저닝 + 롤백 준비
  • 업로드 실패 시 재시도/알림
  • “최신 글”은 SSR fallback 경로로 보완

4) Vercel 캐시/ISR 갱신 지연

• 증상: 갱신했는데 화면이 늦게 바뀜
• 대응:
  • “발행 후 강제 재검증(온디맨드 리밸리데이트)” 경로 준비
  • 캐시 무효화 정책 문서화(운영자 체크리스트)

단순하지만 견고하게 (보안 경계)

• 권한 경계: 컨트랙트 쓰기는 소유자/역할 기반으로 제한, 이벤트 로그로 변경 이력 확보
• S3 최소 권한: 리스트/읽기, 필요한 경로만 쓰기 허용. 민감 키는 서버 전용 환경변수로
• 환경변수: Preview/Production 분리, 클라이언트 번들로 노출 금지
• 헬스체크: RPC 상태, S3 접근, Vercel 응답을 주기적으로 점검하고 장애 지점을 구분
• 롤백: index.json 버저닝으로 빠른 과거 상태 복구

적용 순서 (최소 구현 루트)

1. S3 버킷과 폴더 구조 확정 (posts/, index.json)
2. 테스트넷에 컨트랙트 배포 (읽기 메서드부터 고정)
3. Next.js 라우팅 구성 후 ISR/SSR 기준 수립
4. Vercel 연결 + 환경변수/도메인 설정
5. sitemap/robots 제출로 검색 노출 최적화

성장 단계에서의 “부분 교체” 로드맵

무과금으로 시작해도, 성장하면 일부만 교체하면 됩니다.

• 조회/검색이 필요해지면 → 인덱서(이벤트 기반) + 경량 DB만 추가
• 발행 빈도가 늘면 → index.json을 분할(태그별 인덱스, 페이지네이션)
• 트래픽이 커지면 → 이미지/정적 리소스만 CDN 분리
• 메인넷/정합성 요구가 커지면 → 체인/컨펌 정책 강화(또는 L2 이동)