현실적인 프로젝트 구조 설계 고민

현실적인 프로젝트 구조 설계 고민

— 온프레미스 전환을 가정한 두 가지 시나리오 정리

1. 정리 배경

클라우드(AWS) 기반 시스템을 운영하다 보면,
비용·보안·운영 복잡도 문제로 인해 한 번쯤은 이런 질문을 하게 된다.

• “이 구조를 온프레미스로도 운영할 수 있을까?”
• “클라우드를 걷어내면 실제로 어디까지 감당 가능한가?”
• “비용을 줄이기 위해 감수해야 하는 리스크는 무엇인가?”

이 글은
AWS 의존 구조를 온프레미스 환경으로 옮긴다고 가정했을 때의
현실적인 프로젝트 구조 시나리오와 그 한계를 정리한 기록이다.

실제 특정 회사나 고객사 환경이 아니라,
일반화된 시스템 구조를 기반으로 한 사고 실험에 가깝다.

---

2. 전제 조건

• PDA / Mobile / Admin 성격의 서버가 분리되어 있음
• 각 서버는 HTTP API 기반으로 통신
• 인증 서버(Auth), 파일 서버(FS), Redis, DB 존재
• 무중단 배포 및 CI/CD 필요
• 트래픽은 대규모는 아님

---

3. 시나리오 1

“단일 Linux 서버에 모든 역할을 수용하는 구조”

3.1 기본 개념

• 하나의 Linux PC
• nginx를 다중 인스턴스로 구성
• 서비스별로 포트를 분리하여 로드 밸런싱
• 애플리케이션은 Docker 또는 Docker Compose 기반

구성 개요(개념적):

• nginx (auth / admin / mobile / pda / fs 등)
• PDA 서버, Mobile 서버
• PostgreSQL
• Redis (Local)
• Jenkins 기반 CI/CD
• 파일 저장소는 로컬 파일 시스템(S3 대체 개념)

---

3.2 장점

• 초기 비용 최소화
• 인프라 구성 단순
• 네트워크 구성 부담 적음
• 소규모 팀에서도 관리 가능

---

3.3 문제점

단일 장애점(SPOF)

• PC 종료 또는 장애 발생 시 전체 서비스 중단
• 복구 시 모든 컴포넌트를 함께 복구해야 함

리소스 한계

• CPU / 메모리 / 디스크 I/O가 한 서버에 집중
• 특정 서비스 부하가 전체 시스템에 영향

운영 리스크

• 장애 원인 분리가 어려움
• 복구 시간이 길어질 가능성
• 로그·모니터링 체계 없을 경우 운영 난이도 급증

---

3.4 결론 (시나리오 1)

“기술적으로는 가능하지만,
운영 안정성은 상당 부분 포기하는 구조”

• 테스트/개발/파일럿 환경에는 적합
• 상용 서비스 장기 운영에는 리스크 큼

---

4. 시나리오 2

“서버 역할을 물리적으로 분리한 구조”

4.1 기본 개념

• PC 1: 애플리케이션 서버 영역
• PC 2: DB / Redis / 스토리지 영역
• 서버 간 네트워크 통신

구성 개요(개념적):

PC 1 (Windows or Linux)

• nginx 다중 인스턴스
• PDA / Mobile / Admin 서버
• 파일 접근 API

PC 2 (Linux)

• PostgreSQL
• Redis
• 파일 저장소

---

4.2 장점

• DB/캐시 장애가 앱 서버와 분리
• 리소스 분산으로 안정성 향상
• 일부 장애 발생 시 전체 장애로 확산될 가능성 감소

---

4.3 문제점

네트워크 병목

• 서버 간 통신 증가
• 네트워크 대역폭이 낮으면 성능 저하

운영 복잡성 증가

• 서버 수 증가 → 관리 포인트 증가
• 장애 대응 시 고려 요소 증가

보안 이슈

• 내부 통신 암호화 필요
• 접근 제어 및 인증 설정 필수

비용 문제

• 하드웨어 비용 증가
• 유지보수 부담 증가

---

4.4 결론 (시나리오 2)

“현실적인 온프레미스 운영의 최소선”

• 소규모 상용 서비스까지는 가능
• 클러스터링·이중화 없이는 여전히 한계 존재

---

5. 온프레미스 전환 시 공통적으로 고려해야 할 요소

5.1 CI/CD

• Jenkins
• GitLab CI/CD
• TeamCity 등

클라우드 CI/CD 대비:

• 직접 관리 부담 증가
• 장애 시 복구 책임도 내부에 있음

---

5.2 로드 밸런서

• NGINX
• HAProxy
• Traefik

엔터프라이즈급 환경이 아니라면
소프트웨어 로드 밸런서가 현실적인 선택

---

5.3 애플리케이션 구동 방식

• Docker / Docker Compose
• VM 기반
• 경량 Kubernetes(K3s)
• Bare Metal

👉 팀 역량과 운영 인력을 기준으로 선택해야 함

---

5.4 모니터링·로깅

• Prometheus + Grafana
• Netdata
• 로그 수집/알림 체계 필수

온프레미스에서는
문제가 나면 클라우드처럼 자동으로 알려주지 않는다.

---

6. 핵심 정리

온프레미스 전환은 단순히:

“AWS를 빼면 비용이 줄어든다”

의 문제가 아니다.

대신 다음을 감수해야 한다.

• 장애 대응 책임 100% 내부 부담
• 보안 설정 직접 관리
• 하드웨어 장애 리스크
• 운영 자동화 부족

즉,

비용을 아끼는 대신
운영 난이도와 책임을 가져오는 선택

이다.

---

7. 마무리

이 글에서 정리한 구조들은
“정답”이 아니라 사고를 정리하기 위한 시나리오다.

중요한 것은:

• 우리 서비스의 트래픽 규모
• 장애 허용 범위
• 운영 인력과 역량
• 비용 민감도

이 네 가지를 기준으로
클라우드와 온프레미스 사이에서 균형점을 찾는 것이다.