추상 아키텍처를 매니지드 서비스로 — 1인 개발자의 백엔드 빌딩블록

백엔드 아키텍처 글을 읽다 보면 "오브젝트 스토리지", "메시지 브로커", "엣지 게이트웨이" 같은 추상 개념이 자주 나와요. 개념은 알겠는데, 1인 개발자 입장에선 "그래서 나는 무엇을 써야 하지?"가 매번 다시 고민이 돼요. 그래서 추상 개념을 실제 매니지드 서비스에 한 번 매핑해두기로 했어요.

단계적으로 진화시켜요

먼저 전제 하나. 처음부터 마이크로서비스로 쪼개지 않아요. 조기에 서비스를 나누는 건 1인 개발자가 가장 자주 빠지는 함정이에요. 도메인별로 별도 팀이 필요하거나, 특정 엔드포인트만 따로 확장해야 하거나, 배포가 서로 발목을 잡을 때 — 이런 조건이 분명할 때만 나눠요. 그 전까지는 하나의 잘 정리된 단위로 두는 게 빨라요.

개념 → 실제 서비스

제가 쓰는 매핑은 이래요.

• 앱 서버: 컨테이너로 배포(Railway).
• 데이터베이스: Postgres 매니지드(Supabase). 앱과 분리해서 둬요.
• 캐시: Redis 매니지드(Upstash).
• CDN / 엣지: Cloudflare. 정적 자산과 엣지 게이트웨이를 여기서.
• 오브젝트 스토리지: Supabase Storage. 큰 파일은 DB에 넣지 않고 여기에.

핵심은 "상태를 머신에 묶지 않는다"예요. 세션이나 캐시, 업로드 파일을 앱 서버 안에 두면 확장도 복구도 어려워져요. 그래서 상태는 전부 바깥(스토리지·캐시)으로 빼요.

파일 업로드는 특히 조심해요

이미지 같은 큰 파일은 흔한 실수가 나와요. 파일을 서버로 직접 받아 스트리밍하면, 용량이 커질 때 요청이 너무 크다거나 시간 초과로 막히고, 공격 표면도 넓어져요. 대신 데이터베이스에는 메타데이터(파일명·크기·타입·소유자)만 두고, 실제 파일은 만료 시간이 짧은 서명 URL로 클라이언트가 스토리지에 직접 올리게 해요. 서버는 파일 바이트를 거치지 않아요.

이렇게 "개념 → 내가 쓰는 서비스" 표를 한 장 만들어두면, 새 기능을 붙일 때마다 바퀴를 다시 발명하지 않아도 돼요. 매니지드 서비스를 적극적으로 쓰는 1인 운영이라면 이런 매핑이 시간을 꽤 아껴줘요.