금융 IT 기술 스택 — DB, 웹, 인프라 비교

✅ MySQL vs MariaDB vs Oracle DB

개념	오픈소스 관계형 DB	MySQL에서 갈라진 오픈소스 DB	상용 엔터프라이즈급 DB
라이선스	부분 상용 (오라클 소유)	완전 오픈소스	상용 (유료)
기업 사용	중소규모 서비스, 스타트업	오픈소스 선호 기업, 클라우드 환경	금융, 공공, 대기업 미션크리티컬 시스템
성능	일반적인 CRUD 성능은 우수	MySQL 대비 복제 성능 개선, 더 빠름	대규모 트랜잭션, 병렬처리, 안정성 최강
장점	접근 쉬움, 커뮤니티 많음	속도 빠름, 클러스터링 강함	장애 복구, 데이터 일관성, 안정성 최고
단점	대용량 처리 및 동시성 약함	대형 트랜잭션에는 상대적 약세	비용 높음, 설정 복잡
금융권 채택 이유	잘 안씀 (비용 이슈 X)	일부 내부 시스템	법적 요구, 고가용성, 안정성 → 표준
주의사항	장애 복구 어렵고, 복제 이슈 있음	복제는 좋지만 대형 트랜잭션 약점	설정, 라이선스, 인프라 복잡

 

“금융권에서는 트랜잭션의 안정성, 장애 복구, 동시성 처리 등에서 강력한 Oracle DB를 많이 사용합니다. 반면 MySQL과 MariaDB는 비교적 단순한 내부 시스템이나 로그 저장 등에 활용됩니다. 데이터 정합성이 생명인 금융에서는 Oracle의 Redo 로그, RAC(Real Application Cluster) 같은 기능들이 매우 중요한 이유입니다.”

 

✅ EDB

• EDB = EnterpriseDB의 약자.
• PostgreSQL을 상용화한 데이터베이스.
• 오픈소스인 PostgreSQL에 기업용 기능(보안, 고가용성, 성능 강화 등)을 추가한 상용 버전.
• PostgreSQL과 거의 동일한 엔진을 사용하지만, 기업 환경에 적합하도록 강화됨.

👉 "EDB = PostgreSQL + 기업용 기능 추가" 라고 보면 됨.

---

✅ PostgreSQL vs EDB (EnterpriseDB) 

라이선스	오픈소스 (무료)	상용 (유료)
출시 목적	커뮤니티 중심 개발	기업용 강화 (PostgreSQL 상용화)
지원	커뮤니티 지원	공식 기업 지원 (24/7 기술 지원)
기능 차이	표준 SQL + 커뮤니티 기능	Oracle 호환 기능, 보안 강화, 장애 복구 강화
고가용성 (HA)	커뮤니티 솔루션 사용 (Patroni 등)	EDB 자체 HA 솔루션 (EDB Failover Manager)
보안 기능	기본적인 인증/권한	감사 로그, 암호화, 권한 강화, 보안 레벨 향상
운영 편의성	수동 구성 많음	GUI 기반 툴 제공 (EDB PEM)
금융권 적용	작은 규모나 내부 시스템에서 사용	대형 금융, 공공기관에서 Oracle 대체로 도입
장점	무료, 커스터마이징 자유	엔터프라이즈 지원, 고가용성, 안정성
단점	장애 대응 수동, 기술지원 불가	라이선스 비용 있음
Oracle 호환성	없음	있음 (Oracle PL/SQL 문법, 함수 호환)

 

---

✅ MySQL / MariaDB / Oracle / PostgreSQL / EDB 비교

라이선스	오픈소스 (오라클 소유)	오픈소스 (커뮤니티)	상용	오픈소스	상용 (Postgres 기반)
성능 특성	경량, 빠름	MySQL과 유사	대규모 트랜잭션 최강	관계형 + 객체지향 지원	PostgreSQL + 엔터프라이즈
금융권 사용	거의 없음	일부 내부 시스템	대형 금융 메인 (은행, 카드)	최근 금융권에서 증가	PostgreSQL의 Oracle 대체용
장점	쉬움, 빠름	무료, MySQL보다 개방적	신뢰성, 대용량, 안정성	커뮤니티 활발	보안, HA, 장애 복구 강력
단점	대형 시스템 부적합	대규모에서 한계	비싸다 (억 단위)	상용 대비 안정성 부족	상용비용 있음
Oracle 호환성	일부	일부	O	X	O (Oracle 문법, 함수 지원)

 

---

✅ 금융권에서 EDB를 쓰는 이유

• 기존에는 대부분 Oracle을 사용했음 → 이유: 안정성, 장애 복구, 보안, 트랜잭션 신뢰성.
• BUT Oracle은 라이선스 비용이 너무 비쌈 (수억 ~ 수십억).
• 그래서 최근 금융권은 비용 절감을 위해 Oracle 탈피 시도 → PostgreSQL 계열로 전환 중.
• 단, PostgreSQL는 장애 대응, 보안, 복구, 기술지원이 약함.
• 그래서 PostgreSQL의 상용 버전인 EDB가 선택됨.
• 즉, “PostgreSQL의 오픈소스 한계는 넘어서고, Oracle만큼 안정성을 갖추자” → 이게 EDB 도입 이유.

---

✅ EDB 사용할 때 주의할 점

1. 비용: 오라클보단 싸지만, PostgreSQL보단 비쌈.
2. 벤더 Lock-in: 오픈소스 PostgreSQL과는 달리 벤더 의존성이 생김.
3. 장애 대응: 확실히 강하지만, PostgreSQL과 완전히 같진 않음 → 마이그레이션 시 이슈 발생 가능.
4. Oracle에서 완전히 100% 대체는 어려움. → SQL 호환성은 높지만 PL/SQL 복잡한 로직은 이슈 가능.

 

 

“PostgreSQL는 오픈소스라 비용 효율성이 있지만, 금융권처럼 장애 대응, 보안, 고가용성이 중요한 환경에서는 단독으로 쓰기엔 리스크가 있습니다. 그래서 EDB 같은 상용 PostgreSQL 버전이 등장했고, 기존 Oracle을 대체하는 흐름이 금융권에서 확대되고 있습니다.”

 

 

---

✅ C vs Java

개념	절차지향 언어	객체지향 언어
컴파일 방식	컴파일 → 바이너리 실행 (OS 종속)	컴파일 → 바이트코드 → JVM 실행 (OS 독립)
실행 속도	빠름 (하드웨어 직접 접근)	상대적으로 느림 (JVM 통해 실행)
메모리 관리	직접 (malloc/free 수동)	자동 (Garbage Collection)
용도	시스템 프로그래밍 (OS, 드라이버, IoT)	기업용 서버, 금융, 웹 서비스 백엔드
금융권 채택 이유	거의 안 씀 (시스템 개발 제외)	금융 서버 개발 표준 (안정성 + 생산성)
장점	성능 우수, 하드웨어 제어	생산성 우수, 안정적, 유지보수 편리
단점	메모리 누수 위험, 생산성 낮음	속도는 네이티브 언어보다 느림
주의사항	포인터 오염, 버퍼 오버플로우	메모리 릭은 적지만 GC 튜닝 필요

 

“금융권은 절대적인 안정성과 유지보수가 중요합니다. Java는 메모리 관리와 예외 처리, JVM 기반의 멀티 OS 지원 덕분에 금융 백엔드 시스템에서 사실상 표준입니다. 반면 C는 하드웨어나 성능이 중요한 시스템 프로그램에서 주로 사용되지만, 메모리 관리 부담으로 금융 비즈니스 로직에는 적합하지 않습니다.”

---

✅ JSP vs JS vs jQuery

개념	서버 사이드 동적 웹 페이지 생성 (HTML + Java)	클라이언트 사이드 스크립트	JS 라이브러리 (DOM 조작, Ajax 쉽게)
실행 위치	서버	브라우저	브라우저
주요 역할	화면 HTML 생성, 서버 데이터 바인딩	이벤트 처리, 동적 UI, API 호출	DOM 조작, 브라우저 호환성 처리
현업 쓰임	레거시 금융 시스템 (JSP + Servlet)	프론트엔드 주력 (React, Vue, Vanilla JS)	구레거시 웹 유지보수
금융권 사용 이유	과거 금융 시스템 전통 (JSP 기반)	현대 금융 시스템은 JS SPA로 전환 중	과거 호환성 유지 목적
장점	Java와 연동 쉬움	유연성, 확장성 매우 높음	DOM 조작 편리, 학습 난이도 낮음
단점	프론트엔드 한계 (화면 갱신 불편)	복잡성 높음 (규모 커지면 관리 어려움)	무거움, 현대 JS 프레임워크에 비해 구식
주의사항	서버 부하 많음, UI 동적 변경 어려움	모듈화, 비동기 처리 구조화 필요	대규모 시스템에선 성능/확장성 한계

 

“JSP는 서버에서 화면을 그려주는 전통적인 방식으로, 금융권의 레거시 시스템에서 여전히 존재합니다. 하지만 현대 웹은 React 같은 클라이언트 사이드 렌더링으로 전환되었고, JavaScript가 중심이 되었습니다. jQuery는 과거 DOM 조작을 쉽게 하기 위해 쓰였지만, 현재는 Vanilla JS나 프레임워크가 더 강력해서 점차 사용 빈도가 줄고 있습니다.”

---

✅ JavaScript vs TypeScript

개념	동적 타입 언어	정적 타입을 추가한 JavaScript 상위 언어
컴파일 여부	없음 (런타임 오류)	있음 (코드 작성 시 타입 검사, 컴파일)
에러 발견 시점	실행 중 발견	코드 작성 시점에 발견
현업 사용	소규모, 프로토타입, 빠른 개발	대규모 시스템, 금융권, 기업용 프론트엔드
금융권 사용 이유	단기성, 간단한 UI	코드 안정성, 오류 방지, 대규모 유지보수 적합
장점	유연함, 빠른 개발	타입 안정성, 유지보수 용이
단점	런타임 오류 위험	러닝커브 있음, 초기 설정 복잡
주의사항	변수 오타, 데이터 타입 오류 발견 늦음	타입 설계 복잡, 타입 정의가 과도해질 수 있음

 

“금융권은 코드의 안정성이 곧 서비스의 신뢰성과 직결됩니다. JavaScript는 빠르게 개발 가능하지만, 런타임 오류가 잦아 대규모 시스템에는 위험합니다. TypeScript는 정적 타입 언어로 컴파일 시점에 오류를 막아주어, 복잡한 금융 서비스의 유지보수성과 안전성을 확보하는 데 매우 효과적입니다.”

 

 

 

---

✅ Linux vs Unix 차이

개념	1960~70년대 탄생, 상용 OS, 유닉스 철학 기반	오픈소스 유닉스 클론, 리눅스 커널 기반
라이선스	상용 (HP-UX, AIX, Solaris 등)	오픈소스 (GPL)
배포판	없음 (벤더 제품)	Ubuntu, CentOS, RHEL, Debian, Rocky 등
시장 사용처	주로 메인프레임, 오래된 금융권	현재 대부분의 서버, 클라우드 인프라
금융권 사용 이유	초창기 메인프레임 기반 시스템 유지보수용	신규 서버, 클라우드, Kubernetes 기반 운영
장점	안정성 극강, 검증된 운영체제	오픈소스, 커뮤니티 활발, 유연성, 비용 절감
단점	라이선스 비용, 업데이트 어려움	설정 복잡, 디스트로 간 호환성 이슈 가끔
주의사항	유지보수 인력 부족, 현대화 어려움	보안 패치 수동 필요, 초기 세팅 복잡

 

“금융권은 과거 Unix 계열 메인프레임 시스템에서 시작했지만, 현재는 Linux가 서버의 표준입니다. 클라우드, 컨테이너, 마이크로서비스 같은 현대적인 인프라가 모두 Linux 기반에서 동작합니다.”

 

 

---

✅ React (MUI) vs Vue vs Angular

개념	컴포넌트 기반 UI 라이브러리	MVVM 패턴 기반 프레임워크	대규모 SPA 프레임워크
UI 라이브러리	MUI(Material UI), AntD, Chakra 등	Vuetify, Quasar	Angular Material
언어 기반	JavaScript, TypeScript	JavaScript, TypeScript	TypeScript 강제
학습 난이도	쉬움 + 점진적 학습 가능	매우 쉬움	가장 어려움 (구조 강함)
유연성	매우 높음 (필요한 것만 선택 가능)	높음	프레임워크 규칙 강제
금융권 사용 이유	높은 자유도, 대기업/금융권 선호	중소 규모 서비스, 빠른 개발에 적합	대규모 조직형 개발, 규칙적인 코드베이스 필요
장점	커뮤니티 최대, 기업 채택률 최고	배우기 쉬움, 빠른 개발	안정성 최고, 구조화 강력
단점	구조화 부족 시 스파게티 코드 위험	대규모 프로젝트 시 관리 어려움	러닝커브 심각, 무거움
MUI 특징	Google Material Design 기반 UI 컴포넌트 제공	없음	없음
주의사항	자유도가 높아서 코드 규칙 관리 필요	라이브러리 선택 과다	버전 업그레이드 어려움, 무거운 런타임

 

“금융권에서 React는 유지보수성과 생산성 모두를 만족시키는 프론트엔드 표준입니다. 특히 MUI를 사용하면 일관된 디자인 시스템을 빠르게 적용할 수 있습니다. Angular는 대규모 팀에서 선호되지만 진입 장벽이 크고, Vue는 소규모 프로젝트에 강점이 있습니다.”

 

 

🚩 MUI가 무엇인가? (추가 설명)

• Material UI의 약자.
• React용 UI 컴포넌트 라이브러리.
• Google의 Material Design 가이드라인을 기반으로 설계.
• 버튼, 테이블, 모달, 입력창 등 모든 UI 요소를 컴포넌트화 → 생산성 극대화.
• 금융권에서 React + MUI 조합은 화면 일관성 + 생산성을 동시에 해결.