1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함) | 사이드 프로젝트 성공 전략

1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함): 왜 혼자서도 체계가 필요한가?

퇴근 후 사이드 프로젝트를 시작할 때마다 똑같은 실수를 반복하셨나요? 처음엔 신나게 코딩하다가 2주 뒤 내가 짠 코드를 이해 못하고, 기능 하나 추가하려면 전체를 다시 뜯어고쳐야 하는 상황. 저도 수없이 겪었습니다. 그래서 깨달았죠. 1인 개발자야말로 아키텍처 설계가 절실하다는 것을요.

2026년 현재, AI 코딩 도구들이 넘쳐나지만 제대로 된 설계 없이는 결국 스파게티 코드만 양산하게 됩니다. 이 글에서는 제가 시행착오 끝에 정리한 1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)를 단계별로 공유하겠습니다.

왜 1인 개발자에게 아키텍처 설계가 필요한가?

체계적 설계 없이 개발할 때 겪는 문제들

제 첫 사이드 프로젝트는 완전한 재앙이었습니다. “일단 만들고 보자” 마인드로 시작했다가 3개월 뒤 코드를 열어보니 무슨 기능인지 하나도 기억나지 않더군요. 데이터베이스 스키마는 정규화 없이 마구잡이였고, API 엔드포인트는 일관성 없이 난립했습니다.

더 심각한 건 유지보수였습니다. 사용자 인증 방식을 바꾸려고 했는데, 인증 로직이 컨트롤러, 서비스, 심지어 뷰 레이어까지 흩어져 있어서 어디서부터 손대야 할지 막막했죠. 결국 그 프로젝트는 폐기하고 처음부터 다시 시작했습니다.

아키텍처 설계로 얻을 수 있는 3가지 이점

체계적인 설계를 도입한 후 제 개발 생산성은 확실히 달라졌습니다.

• 의사결정 속도 향상: 새 기능을 어디에 구현해야 할지 고민하는 시간이 90% 줄었습니다. 각 컴포넌트의 책임이 명확하니 자연스럽게 위치가 정해지더군요.
• 리팩토링 부담 감소: 설계 문서가 있으니 6개월 뒤에 다시 봐도 전체 구조를 30분 안에 파악할 수 있습니다. 코드를 하나하나 읽을 필요가 없어요.
• 확장 가능성 확보: 초기에 의존성을 제대로 설계해두니, 나중에 결제 시스템을 교체하거나 데이터베이스를 변경할 때도 핵심 비즈니스 로직은 건드리지 않아도 됩니다.

1인 개발 환경에서의 아키텍처 설계 범위

여기서 중요한 건 “적당히” 하는 겁니다. 대기업 SI 프로젝트처럼 수백 페이지 설계서를 만들 필요는 없어요. 1인 개발자가 챙겨야 할 최소한의 설계 범위는 이렇습니다.

저는 처음엔 욕심내서 다 만들려다가 설계만 한 달 하고 지쳐서 포기한 적도 있습니다. 지금은 핵심 3가지(컴포넌트, 데이터, 배치)만 A4 용지 3장 분량으로 정리하고 시작합니다.

시스템 아키텍처 설계의 핵심 개념

아키텍처란 무엇인가? (구성요소, 관계, 동작 원리)

아키텍처를 처음 공부할 때 가장 혼란스러웠던 건 “정확히 뭘 그려야 하는가”였습니다. 수많은 다이어그램과 용어들 사이에서 길을 잃었죠. 간단하게 정리하면 이렇습니다.

시스템 아키텍처는 3가지 질문에 답하는 청사진입니다:

• 무엇으로 구성되어 있는가? (구성요소: 프론트엔드, API 서버, 데이터베이스, 외부 서비스 등)
• 서로 어떻게 연결되는가? (관계: API 호출, 메시지 큐, 이벤트 발행/구독 등)
• 데이터와 제어 흐름은? (동작 원리: 사용자 요청이 들어오면 어떤 경로로 처리되는가)

제 할 일 관리 앱을 예로 들면, 구성요소는 React 프론트엔드, Node.js API 서버, PostgreSQL 데이터베이스, Redis 캐시입니다. 관계는 프론트가 REST API로 서버를 호출하고, 서버는 DB와 캐시에 접근합니다. 동작 원리는 “할 일 조회 시 먼저 Redis를 확인하고, 없으면 DB에서 가져와 캐싱한다”는 식이죠.

품질속성 우선순위 정하기 (성능, 보안, 확장성)

1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)에서 제일 먼저 해야 할 일은 “무엇이 중요한가”를 정하는 겁니다. 모든 품질속성을 완벽하게 만족시킬 순 없으니까요.

제가 만든 서비스별 우선순위는 이랬습니다:

블로그는 Vercel + CDN으로 가용성을 확보하고, 금융 앱은 HTTPS + 암호화 + 입력 검증에 집중했습니다. 이미지 도구는 Web Worker로 병렬 처리를 구현했고요. 처음엔 다 잘하려다가 오히려 아무것도 제대로 못했던 경험이 있어서, 지금은 반드시 우선순위를 정합니다.

아키텍처 4가지 뷰 이해하기 (컴포넌트, 배치, 데이터, 프로세스)

아키텍처를 한 장의 그림으로 표현하려다가 실패했던 경험 있으신가요? 저도 그랬습니다. 알고 보니 하나의 시스템을 여러 관점(뷰)에서 봐야 했더군요.

• 컴포넌트 뷰: 소프트웨어를 구성하는 모듈과 그 관계. 예: “인증 모듈은 사용자 모듈에 의존한다”
• 배치 뷰: 물리적 인프라 구성. 예: “Next.js 앱은 Vercel에, API는 AWS Lambda에, DB는 Supabase에”
• 데이터 뷰: 데이터베이스 스키마와 데이터 흐름. 예: “사용자 테이블과 할 일 테이블은 1:N 관계”
• 프로세스 뷰: 런타임 동작과 상호작용. 예: “로그인 시 JWT 토큰 발급 → 쿠키 저장 → 후속 요청에 포함”

저는 프로젝트 초기에 컴포넌트, 배치, 데이터 뷰 3개만 간단히 그립니다. 프로세스 뷰는 복잡한 비즈니스 로직이 있을 때만 추가하고요. Excalidraw나 draw.io 같은 무료 툴로 30분이면 충분합니다.

1인 개발자를 위한 실전 설계 프로세스

1단계: 모듈/컴포넌트 정의와 책임 분리

설계의 첫 단계는 “이 시스템을 어떻게 쪼갤 것인가”입니다. 저는 보통 기능 중심으로 나눕니다.

할 일 관리 앱 예시:

• 인증 컴포넌트: 회원가입, 로그인, 토큰 관리 (책임: 사용자 신원 확인)
• 할 일 컴포넌트: CRUD 작업, 정렬, 필터링 (책임: 할 일 데이터 관리)
• 알림 컴포넌트: 이메일/푸시 알림 (책임: 외부 통신)
• UI 컴포넌트: 리액트 페이지와 공통 컴포넌트 (책임: 사용자 인터페이스)

핵심은 각 컴포넌트가 “단일 책임”을 갖는 것입니다. 처음엔 할 일 컴포넌트 안에 이메일 전송 로직까지 넣었다가, 나중에 Slack 알림을 추가하려니 할 일 로직까지 건드려야 하는 문제가 생겼죠. 그때부터 알림은 무조건 별도 컴포넌트로 분리합니다.

2단계: 의존성 설계와 아키텍처 패턴 선택

컴포넌트를 정의했으면 이제 서로 어떻게 연결할지 정해야 합니다. 여기서 1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)의 핵심이 등장합니다: 의존성 방향을 명확히 하는 것.

제가 자주 쓰는 원칙:

• 단방향 의존성: UI → 비즈니스 로직 → 데이터 접근. 역방향은 금지 (데이터 레이어가 UI를 직접 호출하면 안 됨)
• 인터페이스로 결합도 낮추기: 알림 컴포넌트는 INotificationService 인터페이스에 의존하고, 실제 구현체(EmailService, SlackService)는 런타임에 주입
• 레이어드 아키텍처 선호: Presentation – Business – Data Access 3계층. 간단하고 이해하기 쉬워서 1인 개발에 적합합니다

마이크로서비스나 이벤트 드리븐 같은 복잡한 패턴은 1인 개발엔 오버엔지니어링입니다. 저도 한때 “있어 보이는” 아키텍처를 쓰려다가 배보다 배꼽이 더 커진 적 있어요. 지금은 레이어드 아키텍처로 시작해서, 정말 필요할 때만 부분적으로 마이크로서비스를 떼어냅니다.

3단계: 프로토타입 검증과 설계 조정

설계서를 완벽하게 만들었다고 끝이 아닙니다. 실제로 코드를 짜보면 설계가 현실과 안 맞는 부분이 꼭 나오거든요.

저는 설계 후 바로 “워킹 스켈레톤(Walking Skeleton)”을 만듭니다. 모든 레이어를 관통하는 가장 간단한 기능 하나를 end-to-end로 구현하는 거죠. 예를 들어 “할 일 1개 조회” 기능을 프론트엔드부터 데이터베이스까지 완성합니다.

이 과정에서 발견한 문제들:

• 설계에서는 Redis 캐시를 쓰기로 했는데, 트래픽이 적어서 당장은 불필요함 → 일단 제거하고 나중에 추가
• API Gateway를 따로 두려 했는데, Next.js API Routes로 충분함 → 단순화
• 상태 관리를 Redux로 계획했지만, React Query가 서버 상태 관리에 더 적합함 → 변경

설계는 “살아있는 문서”입니다. 프로토타입 결과에 따라 과감히 수정하세요. 완벽한 초기 설계보다 빠른 검증과 조정이 더 중요합니다.

각 단계별 필수 산출물 체크리스트

1인 개발자가 꼭 만들어야 할 최소 산출물 목록입니다. 저는 이걸 Notion 템플릿으로 만들어서 프로젝트마다 복사해 씁니다.

전체 설계 프로세스에 보통 2~3일 투자합니다. 개발 기간이 1개월 이상이면 이 정도 시간은 나중에 몇 배로 회수됩니다.

WBS 작성으로 일정 관리하기

개발방법론과 WBS의 관계

WBS(Work Breakdown Structure)를 처음 접했을 때 “이게 폭포수 방법론 아닌가?” 싶어서 거부감이 들었습니다. 애자일 시대에 무슨 WBS냐고요. 하지만 1인 개발자에게 WBS는 생존 도구입니다.

개발방법론(폭포수든 애자일이든)은 “무슨 작업을 어떤 순서로 할 것인가”를 정의합니다. WBS는 그 작업들을 계층적으로 쪼개고 일정을 붙인 겁니다. 애자일 스프린트에도 WBS는 필요해요. 다만 2주 단위로 짧게 만들 뿐이죠.

1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)에서 WBS가 중요한 이유는, 혼자 일하면 일정 관리가 완전히 무너지기 쉽기 때문입니다. “대충 이번 주에 끝내야지” 하다가 한 달이 지나간 경험, 다들 있으시죠?

분석-설계-구축-테스트 단계별 작업 분류

WBS의 첫 레벨은 보통 개발 단계로 나눕니다. 저는 이렇게 분류합니다:

• 분석 단계: 요구사항 정리, 사용자 스토리 작성, 우선순위 결정
• 설계 단계: 아키텍처 설계, 데이터 모델링, API 설계, UI/UX 와이어프레임
• 구축 단계: 개발 환경 구성, 기능 구현, 통합, 코드 리뷰(셀프)
• 테스트 단계: 단위 테스트, 통합 테스트, 사용자 테스트
• 배포 단계: CI/CD 설정, 프로덕션 배포, 모니터링 설정

각 단계를 더 세부 작업으로 쪼갭니다. 예를 들어 “구축 단계 → 할 일 기능 구현 → 할 일 추가 API → 컨트롤러 작성, 서비스 로직 구현, 데이터 검증, 에러 핸들링” 이런 식으로요.

핵심은 작업을 4~8시간 단위로 쪼개는 것입니다. 그래야 진행 상황을 정확히 파악할 수 있어요. “프론트엔드 개발: 2주”는 WBS가 아니라 그냥 희망사항입니다.

1인 개발자용 실전 WBS 템플릿과 작성 예시

제가 실제로 사용하는 간소화된 WBS 템플릿입니다. 스프레드시트나 Notion으로 관리합니다.

할 일 관리 앱 WBS 예시:

• 1. 프로젝트 준비 (2일)
  • 1.1 요구사항 정리 (4h)
  • 1.2 기술 스택 선정 (2h)
  • 1.3 개발 환경 구성 (4h)
  • 1.4 Git 저장소 생성, 브랜치 전략 (1h)
• 2. 설계 (3일)
  • 2.1 아키텍처 설계 (4h)
  • 2.2 데이터베이스 스키마 설계 (3h)
  • 2.3 API 엔드포인트 설계 (2h)
  • 2.4 UI 와이어프레임 (3h)
  • 2.5 WBS 작성 (2h)
• 3. 인증 기능 (5일)
  • 3.1 회원가입 API (6h)
  • 3.2 로그인 API, JWT 발급 (4h)
  • 3.3 인증 미들웨어 (3h)
  • 3.4 회원가입/로그인 UI (6h)
  • 3.5 테스트 작성 (4h)
• 4. 할 일 CRUD (7일)
  • 4.1 할 일 생성 API (4h)
  • 4.2 할 일 조회 API (3h)
  • 4.3 할 일 수정 API (3h)
  • 4.4 할 일 삭제 API (2h)
  • 4.5 할 일 목록 UI (8h)
  • 4.6 할 일 상세/편집 UI (6h)
  • 4.7 테스트 작성 (4h)
• 5. 배포 및 마무리 (3일)
  • 5.1 CI/CD 파이프라인 (6h)
  • 5.2 프로덕션 배포 (3h)
  • 5.3 모니터링 설정 (2h)
  • 5.4 문서 정리 (3h)

총 20일 예상입니다. 실제로는 버퍼를 30% 정도 더해서 26일로 잡습니다. 1인 개발은 예상치 못한 이슈가 항상 터지거든요.

일정 추정과 리스크 대응 방법

일정 추정은 1인 개발자의 영원한 숙제입니다. 저는 수없이 일정을 빗나갔고, 지금도 완벽하진 않습니다. 그래도 나아진 방법들을 공유합니다.

추정 기법:

• 과거 데이터 활용: 이전 프로젝트에서 비슷한 기능을 만드는 데 걸린 시간을 기록해둡니다. 저는 “간단한 CRUD API: 3~4시간, 복잡한 인증 로직: 6~8시간” 같은 참고치를 가지고 있어요.
• 3점 추정: 낙관(최선의 경우), 정상(보통), 비관(최악의 경우) 세 가지 시나리오를 생각합니다. 평균을 내되 비관 쪽에 조금 더 무게를 둡니다.
• 버퍼 시간: 전체 일정의 20~30%를 버퍼로 잡습니다. 1인 개발은 회의나 인수인계는 없지만, 버그 수정과 학습 시간이 예상보다 많이 듭니다.

리스크 대응 전략:

• 기술 리스크: 새로운 라이브러리나 프레임워크를 쓸 때는 반드시 프로토타입으로 검증합니다. 본격 개발 들어가서 “이거 안 되네?” 발견하면 일정이 폭발해요.
• 범위 리스크: 개발 중 “이것도 추가하면 좋겠는데?” 유혹이 옵니다. MVP에 필수가 아니면 백로그에 넣고 일단 넘어갑니다. 저는 “출시 후 추가” 리스트를 따로 관리합니다.
• 개인 리스크: 갑자기 야근이 늘거나 몸이 아플 수 있습니다. 주말에만 작업한다면 한 주 통째로 날아갈 수도 있어요. 그래서 여유 있는 일정이 중요합니다.

제 경험상 처음 세운 일정의 1.5배가 실제 소요 시간입니다. 2주 계획이면 3주로 잡는 게 현실적이에요.

아키텍처 문서화 실전 가이드

꼭 필요한 문서 vs 생략 가능한 문서

문서화에 대한 제 솔직한 심정: 귀찮습니다. 코딩하고 싶지 문서 쓰고 싶지 않아요. 그래서 정말 필요한 것만 남기는 전략을 택했습니다.

꼭 만들어야 할 문서:

• README.md: 프로젝트 개요, 실행 방법, 기술 스택. 6개월 뒤 내가 볼 문서입니다.
• 아키텍처 다이어그램: 컴포넌트 구조, 데이터 흐름, 배치 구조 3개. 각각 1페이지면 충분합니다.
• 환경 설정 가이드: 환경 변수, 외부 서비스 연동 방법. 배포할 때마다 찾게 되는 정보입니다.
• API 문서: Swagger나 Postman Collection으로 자동 생성합니다. 직접 쓰지 않습니다.

생략해도 되는 문서:

• 상세 설계서 (코드가 곧 설계입니다)
• 회의록 (혼자 하는데 회의가 없잖아요)
• 변경 이력 (Git commit이 이미 기록합니다)
• 테스트 계획서 (테스트 코드가 문서 역할을 합니다)

문서는 유지보수 비용이 듭니다. 코드가 바뀌면 문서도 업데이트해야 하는데, 1인 개발자는 그럴 시간이 없어요. 자동 생성되거나 최소한의 수작업으로 유지 가능한 것만 만듭니다.

다이어그램 도구 추천과 활용법

1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)를 실천하면서 제가 써본 도구들입니다.

• Excalidraw (제일 애용): 손그림 스타일, 빠르게 스케치 가능. 무료고 웹 브라우저에서 바로 씁니다. 형식에 얽매이지 않아 좋아요.
• draw.io / diagrams.net: 좀 더 정갈한 다이어그램이 필요할 때. AWS, GCP 아이콘 라이브러리가 있어 인프라 구성도 그리기 좋습니다.
• Mermaid: 코드로 다이어그램을 그립니다. Markdown에 임베드 가능해서 README에 바로 넣을 수 있어요. 간단한 플로우차트나 시퀀스 다이어그램용으로 씁니다.
• Figma: UI/UX 설계할 때만. 아키텍처 다이어그램에는 과합니다.

저는 초기 스케치는 Excalidraw, 최종 문서는 draw.io로 정리합니다. 5분 안에 그릴 수 없으면 너무 복잡한 거예요. 단순하게 유지하세요.

유지보수를 위한 문서 관리 전략

문서를 만들고 나면 관리가 문제입니다. 코드는 계속 바뀌는데 문서는 2개월 전 버전 그대로인 경우가 많죠.

제 관리 원칙:

• 코드와 함께 두기: 문서를 별도 wiki에 두지 말고 Git 저장소의 `/docs` 폴더에 넣습니다. 코드 변경과 함께 문서도 커밋하도록 강제합니다.
• 정기 리뷰: 월 1회 “문서의 날”을 정해서 outdated된 부분을 업데이트합니다. 30분이면 충분해요.
• 자동화 우선: API 문서는 코드에서 자동 생성, ERD는 DB 스키마에서 자동 생성. 수동으로 만드는 문서는 최소화합니다.
• 단순하게: 복잡한 문서는 관리하기 싫어집니다. A4 1장으로 표현 못하면 나눠서 여러 문서로 만듭니다.

솔직히 1인 개발에서 문서 관리는 완벽할 수 없습니다. 대신 “3개월 뒤 내가 봐도 이해할 수 있는 수준”만 유지하면 됩니다. 너무 스트레스 받지 마세요.

자주 묻는 질문 (FAQ)

Q. 처음부터 완벽한 아키텍처를 설계해야 하나요?

아니요, 절대 아닙니다. 완벽한 초기 아키텍처는 환상입니다. 저도 처음엔 모든 경우의 수를 고려하려다가 설계만 한 달 하고 지쳐서 포기했어요.

대신 “진화하는 아키텍처”를 목표로 하세요. 초기에는 MVP에 필요한 최소한의 구조만 설계하고, 기능이 추가되면서 리팩토링으로 개선합니다. 예를 들어 처음엔 모놀리식으로 시작했다가, 특정 기능의 트래픽이 많아지면 그때 마이크로서비스로 분리해도 늦지 않습니다.

중요한 건 “확장 가능한 기반”을 마련하는 것입니다. 모듈 간 의존성을 느슨하게 하고, 인터페이스를 통해 결합도를 낮추면 나중에 구조를 바꾸기 쉽습니다.

Q. 어떤 아키텍처 패턴을 선택해야 할까요?

1인 개발자라면 대부분의 경우 레이어드 아키텍처(계층형)로 시작하길 권합니다. Presentation – Business Logic – Data Access 3계층 구조는 직관적이고 구현하기 쉽습니다.

클린 아키텍처나 헥사고날 아키텍처도 좋지만, 1인 개발에는 과할 수 있어요. 저는 한때 클린 아키텍처를 적용하려다가 보일러플레이트 코드만 엄청 늘어나서 포기했습니다. 팀이 있고 장기 프로젝트라면 고려할 만하지만, 빠른 MVP 출시가 목표라면 단순한 구조가 낫습니다.

다만 프론트엔드가 복잡하다면 상태 관리 패턴(Flux, Redux 등)을, API가 많다면 API Gateway 패턴을 부분적으로 도입하는 것도 좋습니다. 중요한 건 패턴 자체가 아니라 “내 문제를 해결하는가”입니다.

Q. 아키텍처 설계에 얼마나 시간을 투자해야 하나요?

전체 개발 기간의 10~15%를 권장합니다. 2개월 프로젝트라면 1주일 정도요. 하지만 프로젝트 규모와 복잡도에 따라 유연하게 조정해야 합니다.

간단한 CRUD 앱이라면 2~3일이면 충분하고, 실시간 처리나 복잡한 비즈니스 로직이 있다면 1주일 이상 투자할 가치가 있습니다. 제 경험상 설계에 투자한 시간은 구현과 디버깅 단계에서 몇 배로 절약됩니다.

다만 설계에만 빠져서 실제 코딩을 미루지 마세요. 2주 이상 설계만 하고 있다면 과도한 겁니다. 빠르게 프로토타입을 만들어서 설계를 검증하는 게 더 중요합니다.

Q. 기존 프로젝트에 아키�ecktur를 적용할 수 있나요?

가능합니다. 오히려 스파게티 코드로 고생하고 있다면 지금이 아키텍처를 도입할 최적의 시기일 수 있어요. 저도 몇 번 그런 경험을 했습니다.

단계적 접근을 추천합니다. 한 번에 전체를 뜯어고치려 하지 말고, 먼저 현재 구조를 다이어그램으로 그려보세요. 의존성이 엉킨 부분, 책임이 불명확한 컴포넌트를 찾습니다. 그 다음 가장 문제가 심각한 부분부터 리팩토링합니다.

예를 들어 비즈니스 로직이 컨트롤러에 산재해 있다면, 서비스 레이어를 만들어서 로직을 옮깁니다. 데이터 접근이 여기저기 흩어져 있다면, Repository 패턴을 도입합니다. 한 번에 하나씩, 테스트를 통과하는지 확인하면서 진행하세요.

주의할 점: 아키텍처 개선은 새 기능 개발보다 시간이 더 걸립니다. 일정에 여유를 두고 진행하세요. 저는 보통 “기능 2개 추가, 리팩토링 1개” 비율로 스프린트를 구성합니다.

결론: 지속 가능한 1인 개발을 위한 첫걸음

1인 개발 시스템 아키텍처 설계 가이드 (WBS 포함)를 처음부터 끝까지 읽어주셔서 감사합니다. 이 글을 쓰면서 제 지난 시행착오들을 다시 떠올렸습니다. 설계 없이 덤벼들었다가 프로젝트를 폐기했던 기억, 완벽한 설계에 집착하다 지쳐버렸던 경험, WBS 없이 일정 관리 실패했던 순간들.

결국 깨달은 건 이겁니다: 1인 개발자에게 아키텍처 설계는 사치가 아니라 생존 도구입니다. 하지만 대기업 방식을 그대로 따라할 필요는 없어요. 우리에겐 우리만의 “적당히 체계적인” 방식이 필요합니다.

핵심만 정리하면:

• 컴포넌트, 데이터, 배치 3가지 뷰만 그려도 80%는 커버됩니다
• 설계는 진화합니다. 완벽보다 빠른 검증과 조정이 중요합니다
• WBS는 작업을 4~8시간 단위로 쪼개고, 30% 버퍼를 두세요
• 문서는 최소한만. 자동 생성 가능한 건 자동화하세요
• 레이어드 아키텍처로 시작하고, 필요할 때 복잡한 패턴 도

  함께 읽으면 좋은 글

  • Hetzner VPS vs AWS 가격 비교 2026년 – 최대 7배 저렴한 가성비 분석