온프레미스 아키텍처 - 소프트웨어 구성도 [KT 에이블스쿨] 2025.05.20(화)

2025.05.20 (화)

 

 

 

길고 길었던 하드웨어 리뷰가 끝나고 

이제 온프레미스 소프트웨어 구성도 리뷰 시작합니다 ! 

 

오늘도 내용이 많을거 같기 때문에..

바로 시작하겠습니다 ! 

 

 

---

[온프레미스 아키텍처 - 소프트웨어 구성도]

 

1. 소프트웨어 개발 과정

○ 소프트웨어 개발 방법론

① 절차지향형 개발 방법론

  : 문제를 해결하기 위한 절차(Flow)를 중심으로 구성하는 방식

  → (입력 - 처리 - 출력) 구조

 

② 객체지향형 개발 방법론 

  : 데이터와 기능을 하나의 단위로 묶어 설계하는 방식

  → 객체(Object) : 속성(데이터)과 메서드(기능)을 포함한 독립적 단위 

  → 주요 개념

 - 클래스(Class) : 객체를 생성하기 위한 설계도

 - 인스턴스(Instance) : 클래스에서 생성된 실제 객체

 - 캡슐화(Encapsulation) : 데이터 보호를 위한 구조

 - 상속(Inheritance) : 기존 객체의 구조 및 기능을 확장

 - 다형성(Polymorphism) : 동일한 메세지레 대해 다양한 반응 구현

 

③ 함수형 개발 방법론

  : 프로그램에 상태 변화 없이 순수 함수의 조합으로 구성하는 방식

  → 주요 개념

 - 불변성(Immutable) : 변수 상태 변경 없이 새로운 값 반환

 - 일급 함수(First-class function) : 함수 자체를 값처럼 전달 가능

 - 고차 함수(Higher-order function) : 함수를 인자로 받거나 반환 가능

 - 재귀(Recursion) : 반복 대신 함수의 자기 호출 사용

 

○ 개발 프로세스 모델

① 폭포수 모델(Waterfall Model)

  : 소프트웨어 개발 단계를 선형적으로 순차 진행하는 전통적 개발 방법론 (앞 단계의 결과물이 후단에 입력됌)

  → 순서 : 요구사항 - 설계 - 구현 - 테스트 - 유지보수

  → 단점 : 요구사항 변경에 취약, 오류 발견 시점 지연, 피드백 반영 어려움, 결과물 확인 시점 지연

 

② 애자일(Agile) 개발 방법론

  : 변화에 유연하게 대응하는 반복적/점진적 개발 방식

  → 빠른 개발 주기, 반복 반영 가능한 피드백, 팀 간 협업 중심

  → 프로젝트 성공 기준이 완성된 문서 보다 작동하는 기능에 초점

  → 유형 1) 스크럼(Scrum) 

     : 짧은 반복 주기(Sprint)를 기반으로 기능 단위 개발과 피드백을 반복 수행

  → 유형 2) 익스트림 프로그래밍(XP, eXtreme Programming)

     : 소규모 팀이 요구사항 변화에 유연하게 대응하며 고품질 S/W를 빠르게 개발하기 위한 실천 중심 방법론 

 

○ 소프트웨어 구성도 - UML(Unified Modeling Langauge) Diagram

  : 소프트웨어 시스템을 시각적으로 모델링하기 위한 표준 표현 방식

  → 복잡한 소프트웨어를 도식화하여 직관적으로 이해 가능

 

○ 클래스 다이어그램(Class Diagram)

  : 현실 세계의 대상을 프로그래밍적으로 표현한 설계도, 객체를 생성하기 위한 템플릿

  → 클래스 단위 설계를 통해 역할 분리, 책임 명확화, 관계 정리 가능

  → UML에서 정적인 행위를 표현하는 도구

 

○ 시퀀스 다이어그램(Sequence Diagram)

  : 객체 간 상호작용(메시지 교환) 순서를 시간 흐름에 따라 시각화한 다이어그램

  → UML에서 동적인 행위를 표현하는 도구

 

○ 액티비티 다이어그램(Activity Diagram)

  : 기능이 수행되는 과정을 작업(액션) 단위로 순차적/조건적 흐름을 표현하는 다이어그램

  → 작업/데이터 흐름을 설계하는 데에 사용

 

2. 소프트웨어 스택

○ 소트프웨어 선택 기준

① Web Server (웹 서버)

  : 사용자의 HTTP 요청을 가장 먼저 받는 진입 지점

  → 정적 파일 제공(HTML, CSS, JS, 이미지 등)

  → API 요청을 WAS에 전달

  → 사용 소프트웨어(Web Server Software) : Nginx, Apache HTTP Server

 

② WAS (Web Application Server, 웹 애플리케이션 서버)

  : 비지니스 로직을 실행하는 핵심 처리 서버

  → DB와 직접 연동하여 데이터 저장/조회 및 트랜젝션 관리 수행

  → 사용 소프트웨어(백엔드/웹 애플리케이션 프레임워크) : Spring Boot (Java), Express (Node.js), Django (Python)

 

③ DB Server (데이터베이스 서버)

  : 서비스 데이터를 저장/관리하고, 무결성/일관성을 보장

  → 데이터 상태 관리, 트랜젝션 관리, 동시성 제어, 백업/복구 기능 제공

  → 데이터 구조화가 필요하다면 RDBMS

  → 사용 소프트웨어(DBMS) : MySQL, MariaDB, PostgreSQL

 

④ Monitoring Server (모니터링 서버)

  : 서버와 서비스 상태를 실시간으로 수집/시각화하여 장애 감지

  → 자원 사용량(CPU, Memory, Disk, Network 등) 및 서비스 지표 확인

  → 장애 대응, 성능 병목 파악, SLA 준수를 위한 필수 구성요소

  → 사용 소프트웨어(Monitoring Tool) : Prometheus, Grafana, Zabbix 

 

⑤ Media Server (미디어 서버)

  : 동영상 등 미디어 콘텐츠를 사용자에게 제공

  → 미디어 제공 전용 서버로 WAS/DB와 트래픽을 분리(부하 분산 확보)

  → 저장보다는 제공(Serving)에 집중 (다운로드, 스트리밍 등)

  → 사용 소프트웨어(Media Serving Software) : Nginx(파일 제공), Nginx-rtmp(스트리밍 지원)

 

⑥ Cache Server (캐시 서버)

  : 자주 조회되는 데이터와 세션 정보를 메모리에 저장하여 빠르게 응답

  → DB 접근 최소화를 통해 , 성능 향상 및 부하 감소

  → 사용 소프트웨어(In-Memory Data Store) : Redis, Memcached

 

○ 백엔드 애플리케이션

  : 클라이언트(Web/앱)의 요청을 수신하고 로직 처리를 통해 결과를 반환

  → 고려 사항 : 비진니스 로직 복잡도, 개발 속도 or 안정성, 동시 처리량, 사용 경험, 생태계 구성

 

① Spring Boot (Java 기반)

  : Java 언어 기반 안정적 백엔드 애플리케이션 개발용 프레임워크

  → 복잡한 비즈니스 로직 처리에 적합, 대규모 자용자 처리, 트랜젝션 관리 강점

  → 적합 상황 : 복잡한 처리 절차, 장기적/안정적 운영, 대규모 사용자/데이터 처리, Jave 기반 설계

 

② FastAPI (Python 기반 경량 API 서버 프레임워크)

  : Python 언어로 작성된 가볍고 빠른 API 서버 개발용 프레임워크

  → 적합 상황 : 단순 조회/경량 API 서버, Python 사용 경험, 초기 테스트/실험적 기능 개발 시

 

③ Apache Tomcat (Java 기반 WAS)

  : Java 기반 WAS를 실제로 구동해주는 서버 엔진 (Sping Boot에 기본 내장)

  → 적합 상황 : Java 기반 백엔드 구성 시, 독립적 WAS 필요 시

 

④ Node.js 기반 (Express/NestJS)

  : JavaScript 기반 서버 환경, 비동기 처리가 많은 요청 처리에 효율적

  → Express.js는 경량 API 서버, NestJS는 타입스크립트 기반 대규모 설계에 적합

  → 적합 상황 : 간단한 조회 API, 비동기 중심 서비스, 빠른 프로토타입 제작, 동시 접속 많은 실시간 서비스

 

○ 프론트엔드 애플리케이션

  : 사용자 화면(UI)을 구성하고, 사용자 입력에 따라 동작을 처리하는 애플리케이션

  → 고려 사항 : 서비스 복잡도, 개발자 경험 및 기술 스택, 확장성, 개발 속도

 

① React 

  : Meta에서 개발한 컴포넌트 기반 프론트엔드 프레임워크

  → 복잡한 화면 구성을 체계적 구현, SPA(Single Page Application) 형태 페이지 전환

  → 적합 상황 : 기능 다양/상태 변화가 복잡한 서비스, 장기적 유지보수와 기능 확장 필요 시

 

② Vue.js 

  : 직관적인 문법과 빠른 초기 개발이 가능한 경량 프론트엔드 프레임워크

  → 학습이 쉽고, 소규모 프로젝트

  → 적합 상황 : 단순한 웹 서비스 구성, 빠른 초기 개발, 소규모 프로젝트

 

○ Web Server(웹 서버) 

① Nginx 

  : 가벼운 구조와 높은 성능을 가진 HTTP 웹 서버 

  → 정적 파일(HTML, JS, CSS 등) 제공 + API 서버로의 Reverse Proxy 기능 지원

  → 적합 상황 : SPA(Single Page Application) 배포 시 정적 파일 제공, 다수 사용자 동시 접속, 빠른 응답 필요

 

② Apache HTTP Server - HTTPD(Daemon)

  : 전통적인 HTTP 웹 서버 (LAMP구성)

  → 적합 상황 : 레거시 시스템 구성, 정적 파일, 동시 접속 제어 사용

 

※ LAMP 구성 

  : 호환이 잘되는 소프트웨어 셋으로 (Linux, Apache, MySQL, PHP)로 구성

 

○ Database Management System(DBMS, 데이터베이스 관리 시스템)

  : 데이터를 저장하고 관리하는 시스템 (테이블 형태로 구조화하여 저장)

  → 일관성 유지, 무결성 제약, 트랜젝션 관리 기능

 

① PostgreSQL

  : 오픈소스 기반 관계형 데이터베이스 관리 시스템(RDBMS)

  → 적합 상황 : 승인/검증 절차 필요 서비스, 전체 작업 취소가 필요한 경우, 데이터 구조가 복잡, 다양한 타입, 안정성

 

② MySQL / MariaDB

  : 오픈소스 기반 대표적 관계형 데이터베이스 관리 시스템(RDBMS)

  → 적합 상황 : 구조 단순 서비스, CRUD 위주 시스템, 빠른 조회와 간편 관리 서비스, 중소규모

 

③ SQLite 

  : 단일 파일 형태로 동작하는 경량 관계형 데이터베이스

  → 적합 상황 : 테스트, 포로토타입, 소규모, 서버 미구성, 소규모, 초기 설계 단계

 

○ Monitoring Tool (모니터링 도구)

  : 서버, 네트워크, 애플리케이션 등 상태를 실시간 수집하고 확인하는 도구

  → 장애 발생 시 즉시 알람을 받아 대응할 수 있도록 설정 가능

 

① Zabbix (시스템/네트워크 모니터링 도구)

  : 서버, 네트워크, 애플리케이션 상태를 실시간으로 수집하고 알람을 설정할 수 있는 종합 모니터링 도구

  → 하드웨어 자원 사용량, 서비스 동작 여부 등 확인

  → 적합 상황 : 통합적 관리 필요, 사전 관리 및 알람 설정 필요, 인프라가 단순, 온프레미스 환경 사용 시

 

② Prometheus + Grafana (지표 수집 및 시각화 도구)

  - Prometheus : 서버, 애플리케이션 지표를 시계열 데이터 형태로 수집/저장

  - Grafana : Prometheus가 수집한 데이터를 대시보드 형태로 시각화 

  → 일반적으로 두 가지 툴이 함께 쓰임

  → 적합 상황 : 클라우드/컨테이너 환경, 대시보드 중심 직관적 관리, 서비스 지표/동작 상태 함께 관리, 시각화 통합 운영

 

③ Nagios (서버/서비스 상태 확인 도구)

  : 오래된 인프라 환경에 주로 사용되는 서버/서비스 상태 확인 중심의 모니터링 도구

  → 적합 상황 : 레거시 인프라, 물리 서버 중심 환경, 간단한 서버/서비스 상태 확인, 정상 동작 여부 우선 시

 

○ Cache Server (캐시 서버)

  : 자주 조회되는 데이터나 계산 결과를 메모리(RAM)에 저장해 빠르게 제공하는 시스템

  → DB 접근을 줄이고 응답 속도를 빠르게 함

 

① Redis (인메모리 데이터 저장소)

  : 메모리에 데이터를 저장하는 Key-Value 기반 캐시 서버

  → 적합 상황 : 로그인 세션/조회 결과 캐시 필요 시, 자주 조회되는 데이터를 빠르게 응답이 필요한 경우

 

② Memcached (경량 Key-Value 캐시 서버)

  : 메모리에 데이터를 저장하는 단순 Key-Value 기반 캐시 서버

  → Redis와 유사하지만 구조가 더 단순하고 가벼움

  → 적합 상황 : 간단한 조회 결과, 복잡한 데이터 구조가 아닐 때, 경량 캐시만 필요한 경우

 

○ Media Serving Software (미디어 파일 제공 소프트웨어)

  : 미디어 콘텐츠를 저장하고 사용자에게 전송하는 소프트웨어 

 

① Nginx (미디어 파일 제공 용도)

  : 대용량 미디어 콘텐츠 제공 구성에도 Nginx 이용가능

  → 적합 상황 : 미디어 콘텐츠 제공 필요 시, 부분 다운로드가 필요한 경우, 대용량 파일 제공, 캐시/스트리밍 대응

 

② Flask (간단한 미디어 파일 제공용 API 서버)

  : Python 기반의 경량 웹 프레임워크인 Flask 사용, 소규모 미디어 제공에 적합

  → 적합 상황 : 간단한 파일 응답, 백엔드 API와 미디어 파일 제공을 함께 구성한 경우, 경량화된 파일 제공

 

○ 프로그래밍 언어 선택 

  → 각 서버 역할에 맞는 언어 선택 필요 (개발 생산성, 트랜젝션 관리, 비동기 처리, 시스템 연동)ㄴ

언어 특징 적합한 상황

 

  → 언어별 특징과 적합한 상황

언어	특징	적합한 상황
Java	안정성 높고 트랜잭션 관리 강점, 기업 서비스에서 검증 완료	검증 많은 복잡한 로직 처리, 트랜잭션 중심 서비스
Python	간결한 문법, 빠른 개발 속도, 비동기 처리 지원	경량 API, 빠른 초기 개발, 조회 중심 기능
JavaScript / TypeScript	비동기 처리 강점, 프론트·백엔드 통합 가능	조회 중심 API, 빠른 프로토타입, SPA 연동
C	빠른 실행 속도, 시스템 수준 접근, 모니터링 Agent 개발에 사용	시스템 연동, 자원 감시, 모니터링 구성

 

3. 소프트웨어 구성도 작성 실습 (네이버 카페)

소프트웨어 구성도 실습 자료 (네이버 카페)

 

  → 다양한 미디어 자료를 송수신할 것이라 예상해 미디어 서버를 따로 구축

  → RDB 외에도 다양한 형태의 자료를 저장/관리 예정이라 DB 서버에 SQLite도 추가

  → 응답 속도 개선을 위해 캐시 서버도 사용

  → 데이터 백업을 위해 NAS 스토리지 사용

 

 

---

 

 

어렵게 어렵게 소프트웨어 구성도 리뷰를 마무리했습니다 ! 

배울 당시에는 많은 개념들이 헷갈렸는데,

이렇게 천천히 복습하니까 훨씬 이해가 많이 되었습니다 ! 

 

하지만 여전히 어려운 건 사실이고,

내용을 열심히 복습해서 인프라 전문가가 되어보겠습니다..! 

 

복습이 많이 밀렸기 때문에 다음 복습으로

얼른 넘어가 보겠습니다 ! 

 

오늘도 고생하셨습니다 :D