Blog · Indie Dev

개인 개발자가 웹 서비스 만들 때 놓치기 쉬운 인프라 5가지

Codebutter Partners · 2026년 7월 3일

개인 개발 스튜디오가 웹 서비스를 만들 때 뒤늦게 필요성을 깨닫는 인프라 항목 다섯 가지. 오늘어디를 만들면서 실제로 겪은 것들을 정리했습니다.

1. 배포 자동화

로컬에서 잘 되던 코드도 배포 과정에서 사고가 납니다. 파일 하나 빼먹고 업로드, 캐시 이슈, 빌드 스크립트가 로컬 노드 버전에 의존하는 등 온갖 이유로. 최소 규칙:

Vercel, Firebase Hosting, Netlify 같은 SaaS 호스팅은 이 부분을 잘 해결해줍니다. "시간 아낀다"고 로컬 빌드 후 파일 업로드 방식으로 가면, 사이트가 커질수록 배포가 지옥이 됩니다.

"SEO는 나중에"로 미루면 6개월 지나도 유입 0인 사이트가 됩니다. 처음부터 챙길 최소 항목:

이건 하루면 세팅됩니다. 처음부터 하면 안 하는 것과 결과가 완전히 다릅니다. 특히 한국에선 네이버 유입이 큰데, 네이버는 자체 서치어드바이저 등록 없이는 인덱싱이 느립니다.

크론잡·스케줄러가 있는 서비스는 반드시 실패 알림을 이메일이나 슬랙으로 받아야 합니다. Cloud Monitoring, GitHub Actions notification, PagerDuty, 뭐든 좋습니다.

알림이 없으면 스케줄러가 3일째 죽어있는데 사이트는 오래된 데이터를 계속 보여주는 상황이 조용히 생깁니다. 우연히 발견할 때쯤엔 이미 유저 신뢰가 상해있을 수도 있습니다. 우리도 초기에 하루 놓친 적이 있어서, 그 후 알림 정책을 넣었습니다.

외부 API에서 데이터를 가져오는 서비스는 "결손이 있을 것"을 전제로 설계해야 합니다. "이 필드는 무조건 있겠지"라고 가정한 순간 프로덕션 크래시가 시작됩니다.

특히 마지막 항목은 실전에서 자주 겪습니다. API가 "배열이거나 단일 값"을 반환하는 경우, ...spread가 TypeError로 폭발합니다.

수익화를 위한 광고는 자연스러운 선택이지만, 초기부터 위치를 잘못 잡으면 이탈률만 올라갑니다. 원칙:

Google AdSense와 Kakao AdFit 같은 자동 광고는 기본 설정만 잘 잡아도 무리 없이 돌아갑니다. AdSense는 심사가 까다로우니 통과 후에 활성화하는 게 안전하고, AdFit은 상대적으로 승인 문턱이 낮아서 초기 수익화에 유용합니다.

이 5가지는 사이트 만들기 전엔 다 "나중에 하면 되지" 싶은 것들입니다. 근데 나중에 하면 이미 사이트가 자라서 손대기 어려워집니다. 처음부터 챙기는 게 결국 가장 빠른 길입니다. 1인 개발 스튜디오에겐 이런 "복리 이자"가 큽니다.

이런 원칙들이 실제로 적용된 서비스 — Codebutter의 오늘어디를 둘러보세요.