가야태자의 IT이야기

[먹스팀] 충정로 수제 버거 맛집 - 버거운 녀석들 중림점

가야태자 — Sat, 1 Aug 2026 09:29:48 +0900

안녕하세요 가야태자 @talkit 입니다.

오늘도 먹스팀 입니다. ^^

AA 관련글도 주말에 준비해서 적을 겁니다. ㅎㅎ

하지만 조금 바쁘다는 핑계로 먹스팀을 적고 있습니다.

일단 우치는 중정로역 4번 출구에서 가깝습니다. ^^

간판은 이렇게 생겼습니다.

오늘은 가계가 거의 끝나는 시간이라 포장 해왔는데

지난번에 먹었던 버거 입니다. ^^

수제 버거 집이구요.

제가 햄버거를 좋아하는데 원래 가게 이름이 ^^ 버거를 만드는데 버겁다니 하면서 안들어 가려고 했지만,

근처에 버거집이 여기밖에 없어서 ㅠ.ㅠ

일단 들어 갔는데 맛집이네요 ㅎㅎㅎ

메뉴판은 저저렇게 생겼고

저는 6번과 음료 세트를 시켰습니다. ^^

https://naver.me/x9BxNTKP

끝으로 네이버 지도 입니다.

감사합니다.

[개발/IT] 디컴파일러(Decompiler)란 무엇일까? 언어별 주요 디컴파일러 총정리

가야태자 — Fri, 31 Jul 2026 09:27:18 +0900

안녕하세요 가야태자 @talkit 입니다.

오늘도 블로그를 분석하다 보니 C# 디컴파일러인 ILSpy라는 디컴파일러를 소개한 글이 요즘 계속 조회되고 있는 것을 확인했습니다.

그래서 디컴파일러의 개념이 무엇이고, 어떤 종류들이 있는지 궁금해졌습니다.

개발을 하다 보면 오픈소스 라이브러리의 내부 동작이 궁금하거나, 원본 소스가 없는 상용 DLL/JAR 파일의 버그를 추적해야 하는 순간이 오곤 합니다. 이럴 때 개발자들의 구세주가 되어주는 것이 바로 '디컴파일러(Decompiler)'인데요. 오늘은 디컴파일러의 기본 개념부터 주요 프로그래밍 언어별 대표 도구들까지 한눈에 보기 쉽게 정리해 보겠습니다.

1. 디컴파일러(Decompiler)의 개념

디컴파일러를 이해하려면 먼저 컴파일(Compile)의 개념부터 떠올리면 쉽습니다.

컴파일 (Compile): 사람이 작성한 고수준 소스 코드(C#, Java, C++ 등)를 컴퓨터가 이해할 수 있는 바이너리/바이트코드(EXE, DLL, CLASS 등)로 변환하는 과정
디컴파일 (Decompile): 이 과정을 역으로 수행하여, 이미 빌드된 파일로부터 사람이 읽을 수 있는 소스 코드를 추출해 내는 과정

[개발자가 작성한 소스 코드]  ── (컴파일) ──> [컴파일된 바이너리/바이트코드]
[사람이 읽을 수 있는 소스]  <── (디컴파일) ── [컴파일된 바이너리/바이트코드]

완벽히 복원될까요?

컴파일 과정에서 주석(Comment)이나 일부 지역 변수명 등은 제거되기 때문에 100% 원본과 동일하게 복원되지는 않습니다.하지만 전체적인 로직 structure와 알고리즘을 파악하는 데는 전혀 무리가 없는 수준으로 복원해 줍니다.

2. 언어별 대표 디컴파일러 모음

디컴파일러는 언어의 특성(중간 언어 사용 여부)에 따라 복원율과 사용되는 도구가 다릅니다. 각 생태계별로 가장 인기 있는 도구들을 소개합니다.

① C# / .NET 생태계

.NET 언어들은 컴파일 시 IL(Intermediate Language)이라는 중간 언어를 생성하기 때문에 디컴파일 복원율이 매우 뛰어납니다.

ILSpy (오픈소스): .NET 생태계에서 가장 유명한 무료 오픈소스 디컴파일러입니다. C# 코드를 아주 깔끔하게 복원해 주며, 최근에는 VS Code 확장으로도 잘 제공되어 필수 도구로 자리 잡았습니다.
JetBrains dotPeek (무료): 유명 개발 툴 사 제품답게 강력한 검색 기능과 PDB 파일 생성 기능 등을 제공하는 C# 디컴파일러입니다.
dnSpy (오픈소스): 디컴파일뿐만 아니라, 실행 중인 .NET 어셈블리를 실시간으로 수정하고 디버깅(Patching)까지 할 수 있어 역공학(Reverse Engineering) 분석가들에게 사랑받는 도구입니다.

② Java 생태계

Java 역시 JVM 바이트코드(.class) 특성상 구조화가 잘 되어 있어 원본에 가까운 소스 코드를 추출할 수 있습니다.

Fernflower: IntelliJ IDEA에 기본 탑재되어 있는 공식 디컴파일러 엔진입니다. 별도 설치 없이 .class 파일만 열어도 깔끔한 소스 코드를 보여줍니다.
CFR (Class File Reader): 최신 Java 버전(Java 17, 21+)의 람다, 패턴 매칭 등 최신 문법 대응력이 매우 뛰어난 CLI 전용 디컴파일러입니다.
Jadx: 안드로이드 APK 파일 및 .dex 분석에 최적화된 GUI/CLI 도구로, 일반 Java .jar 파일 분석에도 아주 뛰어납니다.

③ C / C++ 및 네이티브 기계어 (보안/리버스 엔지니어링)

네이티브 기계어는 중간 언어가 없고 컴파일 시 심볼 정보가 사라지기 때문에, 어셈블리어를 추론하여 C 언어 스타일의 의도 코드로 재구성하는 하이엔드 분석 도구들이 사용됩니다.

Ghidra (NSA 개발 / 오픈소스): 미국 국가안보국(NSA)에서 공개한 무료 리버스 엔지니어링 프레임워크입니다. 강력한 Decompiler 기능이 내장되어 있습니다.
IDA Pro (유료): 보안 업계의 표준으로 불리는 가장 강력한 바이너리 분석 및 디컴파일 도구입니다 (Hex-Rays 디컴파일 엔진 탑재).

3. 마무리하며

디컴파일러는 타사의 라이브러리 분석, 레거시 시스템 유지보수, 그리고 보안 점검까지 다방면에서 활용되는 개발자의 강력한 무기입니다.

자신이 주력으로 사용하는 언어에 맞는 디컴파일러 하나쯤은 가볍게 다룰 줄 안다면, 답답한 문제에 봉착했을 때 코드 내부를 직접 들여다보며 빠르게 해결책을 찾으실 수 있을 것입니다.

참고 글

[talkit의 블로그] C# C# 디컴파일러 ILSpy 소개 및 사용법

[먹스팀] 가산디지털단지역 간짜장 맛집 - 자금성

가야태자 — Thu, 30 Jul 2026 09:22:48 +0900

안녕하세요 가야태자 @talkit 입니다.

어제에 이어서 오늘도 먹스팀입니다.

외부는 이렇게 생겼습니다.

실내는 못 찍었습니다.

오늘은 음식 사진을 찍었습니다.

여기가 간짜장 맛집인데 저는 쟁반짜장을 시켰습니다.

지난 번에 간짜장을 먹어 봤는데 맛있습니다. ^^

오늘은데 제가 평소때 잘 먹는 쟁반짜장을 먹었습니다 .

맛있네요.

오시는 길은 위와 같습니다.

https://naver.me/GzEDnKjW

그리고 지도 링크 입니다.

혹시나 가산 디지털 단지 역에 오실일 있으면

한번 들려 보시기를

감사합니다.

[먹스팀] 충정로 베트남 쌀 국수 집 앤디스포

가야태자 — Wed, 29 Jul 2026 09:16:57 +0900

안녕하세요 가야태자 @talkit 입니다.

오늘은 낮에 사진을 못 찍었습니다. ㅠ.ㅠ

음 오늘 두번째 먹었는데 계속 맛이 있더라구요

그래서 블로그에 게시해야지 하고 사진을 찍는다는걸 깜빡했습니다. ㅎㅎㅎ

다음에 다시 가면 사진은 수정 하겠습니다.

충정로역 4번 출구에서 오시면 됩니다. ^^

네이버 지도를 공유 드립니다.

https://naver.me/FLE1lhIA

위 링크 누르시면 됩니다.

다음에 가면 꼭 사진을 찍어야겠습니다.

감사합니다.

[DevOps] 시스템 모니터링(System Monitoring)의 개념 및 오픈소스 솔루션 비교 (nmon / Zabbix / Prometheus)

가야태자 — Tue, 28 Jul 2026 09:15:21 +0900

[DevOps] 시스템 모니터링(System Monitoring)의 개념 및 오픈소스 솔루션 비교 (nmon / Zabbix / Prometheus)

안녕하세요 가야태자 @talkit 입니다.

요즘 저와 함께 APM, CI/CD 등을 다루고 있는데요. 여기서 또 중요한 부분이 시스템 모니터링 입니다.

그래서 이번에는 시스템 모니터링의 개념과 대표적인 오픈소스 시스템 모니터링 툴들을 알아보겠습니다.

1. 시스템 모니터링(System Monitoring)이란 무엇인가요?

앞서 다룬 APM(Application Performance Monitoring)이 '애플리케이션 내부의 코드나 DB 쿼리' 같은 소프트웨어 관점의 건강을 체크했다면, 시스템 모니터링은 그 기반이 되는 '하드웨어와 OS(운영체제) 인프라의 건강 상태'를 감시하는 것입니다.

쉽게 비유하자면 APM이 자동차 엔진 내부의 연료 연비와 부품 마찰을 체크하는 것이라면, 시스템 모니터링은 자동차의 남은 연료량, 냉각수 온도, 타이어 마모 상태 등 차량 자체의 뼈대를 확인하는 것과 같습니다. 아무리 소프트웨어가 완벽해도 하드웨어가 멈추면 소용이 없기 때문입니다.

시스템 모니터링의 핵심 4대 메트릭

CPU 사용량 (CPU Usage): 연산 장치에 과부하가 걸리지 않았는가?
메모리 사용량 (Memory Usage): OOM(Out of Memory)으로 서버가 다운될 위험은 없는가?
디스크 I/O 및 잔여 용량 (Disk Storage): 로그 파일이 꽉 차서 시스템이 멈추지 않는가?
네트워크 트래픽 (Network Traffic): 대역폭을 초과하는 급격한 트래픽 유입이나 이상 징후가 있는가?

2. 대표적인 오픈소스 시스템 모니터링 툴 상세 분석

시스템 모니터링 환경과 운영 목적에 따라 선택할 수 있는 대표적인 오픈소스 도구 3가지를 자세히 알아보겠습니다.

① nmon (Nigel's Monitor)

설명: 원래 IBM AIX용으로 개발되었다가 리눅스로 확장된, 엔지니어들에게 오랜 시간 사랑받은 전통의 경량 툴입니다. 별도의 무거운 모니터링 서버를 구축할 필요 없이, 바이너리 하나만 실행하면 터미널 화면에서 즉시 시스템 상태를 확인할 수 있는 단독 실행형 도구입니다.
장점:
- CPU 소모량이 1~2% 미만으로 극도로 가볍습니다.
- 터미널 창에서 단축키(c: CPU, m: 메모리, d: 디스크)로 실시간 조회가 가능합니다.
- 수집한 데이터를 파일(.nmon)로 백업한 뒤, nmon Analyser(엑셀 매크로)를 활용하면 전문적인 그래프 보고서(Excel)를 무료로 쉽게 만들어낼 수 있습니다.
단점:
- 실시간으로 여러 대의 서버를 동시에 모니터링하는 중앙 집중형 화면이 없습니다.
- 장애 발생 시 이메일이나 슬랙 등으로 경고를 보내주는 알림(Alert) 기능이 기본적으로 없습니다.

② Zabbix (자빅스)

설명: 대규모 엔터프라이즈 환경을 타깃으로 하는 통합 인프라 모니터링 솔루션입니다. 중앙에 Zabbix 서버와 데이터베이스를 두고, 감시 대상 서버들에 에이전트(Agent)를 설치하여 데이터를 모으는 전통적인 중앙 집중식 구조입니다.
장점:
- 서버뿐만 아니라 네트워크 장비(스위치, 라우터), 스토리지, 가상화 환경까지 IT 인프라 전체를 하나의 툴로 커버합니다.
- 수많은 OS와 하드웨어 장비용 템플릿을 기본 제공하여 초기 연동이 체계적입니다.
- 자체 웹 콘솔에서 강력한 대시보드와 정교한 알림(Alert) 발송 규칙을 설정할 수 있습니다.
단점:
- 모니터링 시스템을 유지하기 위한 전용 서버 및 DB(MySQL, PostgreSQL 등)를 구축해야 하므로 초기 설치와 관리 오버헤드가 있습니다.

③ Prometheus + Grafana (프로메테우스 + 그라파나)

설명: 도커, 쿠버네티스 환경이 대세가 되면서 현재 클라우드 네이티브 진영의 사실상 업계 표준(De-facto)으로 자리 잡은 모니터링 조합입니다. 메트릭 데이터를 Pull(당겨오기) 방식으로 수집·저장하는 시계열 데이터베이스 Prometheus와, 이를 시각화하는 Grafana가 짝을 이룹니다.
장점:
- 쿠버네티스 등 동적으로 서버(컨테이너)가 생성되고 소멸하는 환경에 완벽하게 최적화되어 있습니다.
- 그라파나(Grafana)의 대시보드 UI가 매우 현대적이고 아름다우며, 전 세계 사용자들이 만든 템플릿을 쉽게 가져다 쓸 수 있습니다.
- 강력한 쿼리 언어(PromQL)를 지원하여 고차원적인 데이터 분석이 가능합니다.
단점:
- 기존 레거시 장비(SNMP 기반 네트워크 장비 등)를 모니터링하려면 별도의 익스포터(Exporter)를 일일이 세팅해야 해서 설정 난이도가 높은 편입니다.

3. 한눈에 보는 시스템 모니터링 툴 비교 표

앞서 살펴본 3가지 툴의 특징을 다음 챕터로 넘어가기 전, 한눈에 볼 수 있도록 요약 정리했습니다.

비교 항목	nmon	Zabbix	Prometheus + Grafana
적합한 환경	개별 서버 / 온프레미스 단독 분석	대규모 IDC 인프라 / 네트워크 장비 통합	클라우드 / 도커 및 쿠버네티스 (MSA)
아키텍처	단독 실행형 (Agentless)	중앙 서버 + 에이전트 구조	Pull 방식 수집기 + 시각화 서버 조합
리소스 오버헤드	극도로 낮음 (CPU 1~2% 미만)	중간 (자체 서버 및 DB 운영 필요)	중간 (시계열 DB 및 컨테이너 리소스 필요)
기본 인터페이스	터미널 UI (Curses 기반)	웹 기반 전용 GUI 콘솔	화려하고 유연한 Grafana 웹 대시보드
알림(Alert) 시스템	없음 (순수 로깅 및 조회 목적)	매우 강력 (이메일, 슬랙 등 기본 제공)	Alertmanager 패키지를 연동하여 강력하게 제어
주요 활용 팁	엑셀 보고서 추출용 가성비 분석	전통적인 기업형 인프라 중앙 관리	현대적인 데브옵스 파이프라인 연동

4. 소프트웨어 공식 다운로드 링크 안내

블로그 독자들이 필요한 툴을 바로 내려받아 테스트해 볼 수 있도록 공식 다운로드 페이지 링크를 공유합니다.

nmon 공식 다운로드 (SourceForge)
- nmon for Linux Download
- _Tip: 리눅스 터미널에서 sudo apt install nmon 이나 yum install nmon으로도 쉽게 설치 가능합니다._sudo apt install nmon``yum install nmon
Zabbix 공식 다운로드
- Zabbix Download Page
Prometheus 공식 다운로드
- Prometheus Download Page
Grafana 공식 다운로드
- Grafana Download Page

시스템 모니터링 깊이 있게 공부하기 (추천 학습 링크)

시스템 모니터링과 인프라 관리에 대해 더 깊이 공부하고 싶으신 분들을 위해 신뢰할 수 있는 학습 가이드를 추천합니다.

구글 SRE Book (Site Reliability Engineering) - 한국어판
- Google SRE 구글 엔지니어링 실무: 모니터링 시스템 구축하기
- 설명: 시스템 모니터링의 철학을 배울 수 있는 업계 바이블입니다. 4대 황금 신호(Latency, Traffic, Errors, Saturation)의 개념을 정립하는 데 큰 도움이 됩니다.
Prometheus 공식 학습 가이드
- Prometheus Getting Started
- 설명: 최신 모니터링의 대세인 시계열 데이터 수집과 PromQL(쿼리 언어)의 기초를 단계별로 실습할 수 있습니다.
IBM nmon Analyser 활용 가이드
- IBM Developer: nmon analyser
- 설명: nmon으로 수집한 데이터를 가져와 멋진 엑셀 차트 보고서로 만드는 프로세스를 완벽하게 익힐 수 있는 가이드입니다.

[DevOps] CI/CD의 핵심 엔진, CI(지속적 통합) 깊이 파헤치기 (Feat. DevSecOps)

가야태자 — Mon, 27 Jul 2026 09:14:46 +0900

[DevOps] CI/CD의 핵심 엔진, CI(지속적 통합) 깊이 파헤치기 (Feat. DevSecOps)

안녕하세요, 가야태자 @talkit 입니다.

우리가 아무리 좋은 배포 도구(CD)를 가지고 있더라도, 파이프라인으로 유입되는 코드(CI)의 품질이 낮거나 버그투성이라면 결국 깨진 소프트웨어를 고객에게 전달하게 됩니다. 그만큼 CI(지속적 통합, Continuous Integration)는 전체 빌드/배포 프로세스의 뼈대이자 첫 단추 역할을 하는데요.

오늘은 이 CI(지속적 통합)의 구체적인 작동 방식과 필수 도구(다운로드 링크 포함), CI의 시작점인 버전 관리의 역사, 그리고 한 단계 더 나아간 안전망인 DevSecOps와의 차이점까지 깊이 있게 파헤쳐 보겠습니다.

1. CI(지속적 통합)의 시작이자 심장: 버전 관리(VCS)

CI(지속적 통합)를 논할 때 절대 빼놓을 수 없는, 아니 CI의 존재 이유 그 자체라고 할 수 있는 핵심 요소가 바로 버전 관리 시스템(Version Control System, VCS)입니다.

CI 파이프라인의 모든 자동화 여정은 개발자가 코드를 수정하고 "버전 관리 저장소에 코드를 밀어 넣는(Push) 행위"에서 출발합니다. 즉, 버전 관리가 제대로 이루어지지 않는 환경에서는 애초에 지속적 통합(CI)이라는 개념 자체가 성립할 수 없습니다.

재미로 보는 버전 관리 역사와 CI의 탄생

버전 관리의 역사를 거슬러 올라가면 우리에게 익숙한 이름들이 등장합니다.

1세대 고대 유물 (CVS): 파일 잠금 방식 기반의 초창기 시스템으로, 네트워크 속도가 느리고 동시 작업 시 충돌 지옥을 맛보게 해주던 추억의 도구입니다.
2세대 과도기 (SVN - Subversion): 중앙 집중식 관리의 표준으로 자리 잡았으나, 브랜치(Branch)를 하나 따고 합치는 병합(Merge) 과정이 너무 고통스러워 개발자들의 한숨을 자아냈습니다. 이 시절에는 코드를 합치는 것 자체가 대공사였기에 '지속적인 통합'은 꿈도 꾸기 힘들었습니다.
3세대 현대 표준 (Git): 분산 버전 관리의 시대를 열며 가볍고 빠른 브랜칭과 병합을 가능하게 했습니다. Git의 등장 덕분에 개발자들은 하루에도 수십 번씩 브랜치를 만들고 합칠 수 있게 되었고, 비로소 진정한 의미의 CI(지속적 통합) 문화가 꽃피우게 되었습니다.

더 읽어보기 (추천 글): 아직 제 블로그에 공개하진 않았지만, 이 흥미진진한 버전 관리의 역사와 현대 Git 저장소 3대장(GitHub, GitLab, Bitbucket)의 차이점이 궁금하시다면 아래 글을 참고해 보세요!

CVS, SVN 기억하시나요? 재미로 보는 버전 관리 역사와 현대 Git 저장소 3대장 비교

2. CI(지속적 통합)의 본질: 단순 기술이 아닌 '개발 문화'

일반적으로 "코드를 합치고 빌드한다"고 가볍게 설명하지만, 실무적인 관점에서의 지속적 통합은 기술적 자동화를 넘어선 '협업의 규칙'에 가깝습니다.

개발자들이 각자 독립된 브랜치에서 작업한 코드는 시간이 흐를수록 메인 소스코드와 간극이 점점 더 벌어집니다. CI는 "모든 개발자가 하루에도 최소 몇 번씩, 공유하는 메인 저장소(Main Branch)에 코드를 수시로 병합하고, 그때마다 자동화된 빌드와 테스트를 구동하여 코드의 안전성을 실시간으로 검증하는 일련의 과정"을 뜻합니다.

만약 수십 명의 개발자가 한 달 동안 각자 코드를 짜고 한꺼번에 합치려고 한다면 어떨까요? 코드 간 충돌(Conflict)을 해결하느라 며칠 밤을 새워야 할 것입니다. CI는 이 고통스러운 병합 작업을 매일 조금씩 자동으로 쪼개서 처리하여 '통합의 지옥(Integration Hell)'을 원천적으로 예방해 줍니다.

3. 지속적 통합(CI)을 진행하는 구체적인 프로세스 (Workflow)

실무에서 CI가 동작하는 구체적인 시나리오는 다음과 같은 단계로 흘러갑니다.

[개발자의 코드 수정] ➡️ [Git Push 및 PR 요청] ➡️ [CI 서버 감지 및 파이프라인 가동]
         ⬇️
[의존성 설치 및 자동 빌드] ➡️ [자동화 테스트 실행 (Unit/Integration)] ➡️ [코드 정적 분석]
         ⬇️
[결과 피드백 (성공 시 Merge 허용 / 실패 시 차단 및 수정 요청)]

코드 변경 및 푸시 (Push): 개발자가 로컬에서 작업 후 원격 공유 저장소(GitHub, GitLab 등)에 코드를 업로드하고, 메인 브랜치로 합쳐달라는 Pull Request(PR) 요청을 보냅니다.
CI 트리거 (Trigger): 저장소가 이 이벤트를 감지하여 지정된 CI 서버(GitHub Actions, Jenkins 등)에 신호를 보냅니다.
의존성 라이브러리 설치 및 자동 빌드 (Build): CI 서버가 격리된 가상 환경(Docker Container 등)을 생성하고 필요한 패키지들을 내려받아 소스코드를 컴파일 및 빌드합니다. (컴파일 에러가 있다면 여기서 즉시 중단 및 실패 처리됩니다.)
자동화 테스트 실행 (Test): 빌드가 완료되면 작성되어 있는 단위 테스트(Unit Test)와 통합 테스트(Integration Test)를 전부 자동으로 구동합니다.
코드 품질 및 보안 정적 분석 (Lint & Scan): 코드 스타일 가이드를 준수했는지(Linter), 사용 중인 라이브러리에 보안 취약점이 없는지 정적 도구를 실행해 검사합니다.
피드백 및 병합 (Merge): 이 모든 단계가 Green(통합 성공)이 되면 비로소 메인 브랜치로의 코드 합병이 승인됩니다. 만약 단 하나라도 실패하면 Red(실패)가 뜨고 메인에 합치지 못하도록 강제 차단됩니다.

4. 지속적 통합(CI)에 필요한 핵심 기술과 툴 (참조 및 다운로드 URL)

전체 통합 프로세스를 제어하는 파이프라인 안에서 코드를 실질적으로 가공하고 검증하는 구체적인 세부 도구들입니다.

컴파일 & 빌드 도구:
- Java (Maven): 오랜 역사와 함께 XML 기반의 명확한 프로젝트 관리 표준을 제시하는 Java 진영의 대표 빌드 도구입니다.
  - Maven 공식 다운로드 및 설치 가이드
- Java (Gradle): 가독성 높은 DSL(Groovy/Kotlin)을 지원하며 대규모 빌드에 최적화된 초고속 빌드 도구입니다.
  - Gradle 공식 다운로드 및 문서
- C/C++ (CMake): 크로스 플랫폼 빌드 시스템 구성을 위한 사실상의 업계 표준입니다.
  - CMake 공식 다운로드 페이지
- JavaScript/Node.js (Vite): 현대 웹 프론트엔드 개발에서 가장 각광받는 초고속 빌드 도구입니다.
  - Vite 공식 가이드 바로가기
자동 테스트 프레임워크:
- Java (JUnit): 자바 개발자라면 무조건 사용하는 단위 테스트 표준 프레임워크입니다.
  - JUnit 공식 가이드 바로가기
- C++ (Google Test): C++ 환경에서 구글이 제공하는 강력하고 안정적인 테스트 라이브러리입니다.
  - Google Test GitHub 저장소
코드 품질 및 보안 분석 도구 (Static Analysis):
- SonarQube (소나큐브): 전반적인 소스코드 품질, 버그 가능성, 스멜 코드, 코드 중복률 등을 시각적인 대시보드로 리포팅해 주는 최고의 정적 분석 도구입니다.
  - SonarQube 공식 다운로드 및 설치 가이드
- Snyk (스니크): 프로젝트에 포함된 오픈소스 의존성 패키지 중에서 이미 알려진 취약점(CVE)이 있는지 자동으로 감지하고 패치 방안을 제시합니다.
  - Snyk 공식 웹사이트 바로가기
- Trivy (트리비): 컨테이너 이미지, 파일시스템, Git 저장소 등의 보안 취약점을 매우 가볍고 빠르게 스캔해 주는 오픈소스 도구입니다.
  - Trivy GitHub 저장소 및 가이드

5. 알아두면 유용한 CI 핵심 용어 정리

CI 관련 개발 문서나 세미나에서 단골로 등장하는 중요 용어들입니다.

파이프라인 (Pipeline): 코드가 빌드, 테스트, 검사 등 여러 단계를 거쳐 최종 결과물로 만들어지는 자동화 프로세스의 전체 연결 흐름을 의미합니다.
러너 / 에이전트 (Runner / Agent): 실제로 CI 명령어(컴파일, 테스트 구동 등)를 직접 수행하는 물리적 혹은 가상의 하드웨어 머신입니다. CI 서버의 명령을 받아 실제로 발로 뛰는 일꾼입니다.
트렁크 기반 개발 (Trunk-Based Development): 여러 개발자가 오랫동안 별도의 거대한 브랜치를 유지하는 대신, 하나의 메인 브랜치('Trunk')에 하루에도 몇 번씩 작고 잦은 커밋을 밀어 넣는 브랜치 관리 전략입니다. CI 문화가 올바르게 작동하기 위한 핵심 윤활유 역할을 합니다.
테스트 커버리지 (Test Coverage): 작성된 테스트 코드가 전체 프로덕션 소스코드 중에서 얼마만큼의 비율을 실제로 실행하고 검증했는지를 보여주는 백분율 지표입니다. 보통 안정적인 서비스를 위해 70~80% 이상 유지를 권장합니다.
빌드 아티팩트 (Build Artifacts): 빌드 파이프라인의 결과로 최종 산출되는 컴파일된 바이너리 파일, JAR/WAR 파일, 혹은 Docker 이미지 같은 배포 가능한 결과물을 지칭합니다.

6. 한 단계 더 나아간 개념: DevOps vs DevSecOps

최근 트렌드는 단순히 코드를 빠르게 합치고 배포하는 DevOps를 넘어, 그 과정에 '보안'을 기본으로 내장하는 DevSecOps(데브섹옵스)로 진화하고 있습니다.

어떤 차이점이 있는지 직관적으로 이해할 수 있도록 쉽게 비교해 보겠습니다.

자동차 공장에 비유하자면?

DevOps: "어떻게 하면 자동차를 더 안전하고 압도적으로 빠르게 조립해서 출고(배포)할 수 있을까?"에 집중하는 고성능 자동화 공장 라인입니다.
DevSecOps: "아무리 빨라도 브레이크가 안 듣는 차를 내보내면 대형 사고가 난다! 조립 단계(계획, 코딩, 빌드)마다 센서와 브레이크 검사(보안)를 내장해서 애초에 불량 차가 나가지 않게 하자!"는 안전 최우선 공장 라인입니다.

한눈에 보는 핵심 차이점 비교

구분	DevOps (데브옵스)	DevSecOps (데브섹옵스)
핵심 가치	속도와 효율성 (신속한 개발과 배포)	보안성과 안전성 (속도를 유지하되 빈틈없는 방어)
보안의 위치	주로 개발의 마지막 단계 혹은 배포 후에 수동 검사	개발 시작 단계(계획/코딩)부터 전 과정에 자동화 내장
접근 방식	개발(Dev)과 운영(Ops)의 경계를 허묾	개발(Dev) + 운영(Ops) + 보안(Sec)을 하나의 문화로 통합
주요 활동	자동 빌드, 자동 배포 파이프라인 구축	코드 정적 분석, 라이브러리 취약점 및 컨테이너 보안 스캔 자동화

과거에는 배포가 모두 끝난 뒤 마지막에 보안 부서가 코드를 수동 검사하여 "취약점이 있으니 배포를 보류하세요!"라고 반려해 롤백하는 비효율이 잦았습니다. DevSecOps는 이를 보완하여 CI 파이프라인 내부에 보안 스캔 단계를 녹여내고, 개발자와 운영자 모두가 보안을 일상적인 책임으로 받아들이게 하는 성숙한 개발 문화입니다.

7. CI/CD 및 CI를 깊이 있게 공부할 수 있는 추천 한국어 가이드

CI의 기초 개념부터 실무 적용, 그리고 DevOps/DevSecOps 문화를 더 깊이 이해하고 공부할 수 있는 훌륭한 한글 리소스들을 선별하여 소개합니다.

레드햇(Red Hat) 코리아 - CI/CD 가이드: 글로벌 오픈소스 기업 레드햇이 초보자를 위해 용어와 필요성을 매우 친절하게 정리해 둔 교과서 같은 아티클입니다.
- 레드햇 공식: CI/CD란 무엇인가요?
삼성SDS 기술 블로그 - DevSecOps 구현: 실무 엔터프라이즈 환경에서 실제로 DevSecOps 파이프라인을 어떻게 구성하고 어떤 효과를 얻는지 자세하게 설명해 줍니다.
- 삼성SDS 공식: DevSecOps로 구현하는 소프트웨어 보안
우아한형제들 기술블로그: 배달의민족 개발팀이 실제 서비스 배포 시에 발생하는 수많은 병목 현상을 CI/CD 자동화로 어떻게 개선했는지 실무 생태계를 엿볼 수 있습니다.
- 우아한형제들 기술블로그 바로가기
Subicura(수비쿠라) 기술블로그: 쿠버네티스 및 DevOps 분야의 최고 권위자 중 한 분인 개발자님이 운영하시는 블로그입니다. CI/CD 파이프라인 구축을 막 시작하려는 초보자에게 빛과 소금 같은 가이드를 제공합니다.
- Subicura 블로그 (DevOps & CI/CD)
요즘IT (yozm.it) - DevOps 이야기: IT 트렌드 미디어 '요즘IT'에서 주니어 개발자들이 쉽게 접근할 수 있도록 일상어로 풀어쓴 다양한 DevOps 관련 연재 글들을 만나볼 수 있습니다.
- 요즘IT: DevOps 및 빌드 자동화 관련 콘텐츠 검색 결과

마치며

결국 CI(지속적 통합)는 수많은 시행착오와 수동 확인 프로세스를 자동화된 파이프라인 속에 녹여내어 개발 문화를 깔끔하게 가꾸는 핵심 원동력입니다. 그리고 그 밑바탕에는 탄탄한 버전 관리 시스템(VCS)이 버티고 있다는 점을 잊지 말아야 합니다.

기존 프로젝트에 빌드 자동화와 단위 테스트부터 차근차근 도입해 보면서 DevOps, 그리고 나아가 DevSecOps의 장점을 온전히 느껴보시는 것을 권장합니다.

궁금하신 점이나 실무에서 사용 중인 본인만의 테스트 꿀팁이 있다면 댓글로 언제든지 편하게 질문과 의견을 나누어 주세요!

감사합니다. 가야태자 @talkit 이었습니다!

[DevOps] CI/CD란 무엇일까? 개념, 필요성, 그리고 대표적인 CI/CD 툴 비교 분석

가야태자 — Fri, 24 Jul 2026 09:54:17 +0900

안녕하세요, 가야태자 @talkit 입니다.

오늘날 소프트웨어 개발 속도는 그 어느 때보다 빨라졌습니다. 하루에도 수십 번씩 코드가 수정되고 배포되는 현대의 개발 환경에서 개발자와 운영자 모두에게 필수적인 개념이 바로 CI/CD입니다.

이번 포스팅에서는 CI/CD가 정확히 무엇인지, 왜 필요한지 알아보고, 개발 현장에서 자주 쓰이는 대표적인 오픈소스, 무료, 유료 CI/CD 툴들과 함께 공부에 도움 되는 관련 가이드 링크를 소개해 드리겠습니다.

1. CI/CD란 무엇인가요?

CI/CD는 애플리케이션 개발 단계부터 배포 단계까지의 과정을 자동화하여 고객에게 더 빠르고 안정적으로 서비스를 제공하는 방법론입니다.

CI (Continuous Integration - 지속적 통합):
- 개발자들이 변경한 코드가 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되는 것을 의미합니다.
- 여러 개발자가 동시에 작업하더라도 코드 충돌이나 버그를 빠르게 감지할 수 있습니다.
CD (Continuous Delivery / Deployment - 지속적 제공 및 배포):
- 지속적 제공(Delivery): 빌드/테스트된 코드를 프로덕션(실서비스) 환경에 배포하기 직전 단계까지 수동 혹은 자동으로 준비해 두는 상태를 의미합니다.
- 지속적 배포(Deployment): 준비된 코드를 실제 사용자에게 자동으로 배포하는 마지막 단계까지 자동화하는 것을 뜻합니다.

한 줄 요약: 개발자가 코드를 작성하여 업로드(Push)하면, 시스템이 알아서 [빌드 ➡️ 테스트 ➡️ 배포] 과정을 자동으로 처리해 주는 마법 같은 프로세스입니다.

2. CI/CD는 왜 필요할까요?

CI/CD를 도입하지 않은 과거에는 개발자가 코드를 모아서 수동으로 빌드하고, 테스트를 거쳐, 서버에 직접 접속해 파일을 업로드해야 했습니다. 이 과정에서 많은 시간과 실수가 발생하곤 했습니다.

휴먼 에러(Human Error) 방지: 사람이 수동으로 배포하면서 발생할 수 있는 명령어 오타, 파일 누락 등의 실수를 원천 차단합니다.
빠른 피드백과 버그 수정: 코드를 병합할 때마다 자동으로 테스트가 수행되므로, 버그를 조기에 발견하고 즉시 해결할 수 있습니다.
개발 생산성 향상: 반복적인 빌드 및 배포 작업을 로봇(CI/CD 툴)이 대신 수행하므로, 개발자는 핵심 비즈니스 로직 구현에만 집중할 수 있습니다.
배포 주기 단축: 고객의 피드백을 빠르게 서비스에 반영하여 시장 경쟁력을 높일 수 있습니다.

3. 대표적인 CI/CD 툴 소개 (오픈소스 다운로드 & 제공사 URL)

CI/CD 시장에는 오픈소스 기반의 강력한 무료 도구부터 대기업을 위한 체계적인 유료 도구까지 다양하게 존재합니다. 대표적인 툴들의 유형과 바로 방문하실 수 있는 링크를 정리해 드립니다.

① 오픈소스 및 무료 설치형 (Self-Hosted)

서버를 직접 구축하고 유지보수할 수 있는 능력이 있고, 비용을 아끼고 싶을 때 가장 먼저 고려하는 옵션입니다.

Jenkins (젠킨스)
- 특징: CI/CD 계의 살아있는 전설이자 가장 널리 쓰이는 오픈소스 툴입니다. 수천 개의 커뮤니티 플러그인을 지원합니다.
- 다운로드 바로가기: Jenkins 공식 다운로드 페이지
Argo CD (아르고 CD)
- 특징: 최근 클라우드 네이티브 환경(Kubernetes)에서 사실상 표준으로 자리 잡은 오픈소스 GitOps 도구입니다.
- 오픈소스 소스코드 및 정보: Argo CD GitHub 저장소 / Argo CD 공식 문서

② 무료/유료 하이브리드 SaaS형 (Cloud-Native)

소프트웨어 설치 없이 클라우드 서비스로 즉시 이용할 수 있으며, 일정 사용량까지는 무료(Free tier)이고 필요에 따라 요금을 지불하는 형태입니다.

GitHub Actions (깃허브 액션즈)
- 특징: GitHub에서 기본 제공하는 매우 강력한 통합형 CI/CD 서비스입니다. 퍼블릭 저장소는 평생 무료입니다.
- 공식 사이트 바로가기: GitHub Actions 공식 소개 및 가이드
GitLab CI/CD (깃랩)
- 특징: 코드 관리부터 이슈 트래커, CI/CD까지 모든 기능을 하나로 통합해 제공하는 올인원 DevOps 플랫폼입니다.
- 공식 사이트 바로가기: GitLab 공식 홈페이지

③ 유료 중심의 전문 엔터프라이즈형

대규모 비즈니스나 높은 보안 수준, 강력한 기술 지원이 필요한 기업용 툴입니다.

Bamboo (뱀부)
- 특징: 협업 도구의 명가 Atlassian사에서 개발한 기업용 상용 CI/CD 서버 솔루션입니다.
- 장점: Jira, Confluence, Bitbucket 등 Atlassian 제품군과 완벽하게 유기적으로 연동됩니다. 배포 이력과 이슈 트래킹을 한눈에 관리하기 매우 편리합니다.
- 단점: 오픈소스 빌드 툴에 비해 라이선스 비용이 고가이며, Atlassian 생태계를 쓰지 않는 환경이라면 메리트가 반감됩니다.
- 제공사 바로가기: Atlassian Bamboo 공식 홈페이지
CircleCI (써클 CI)
- 특징: 클라우드 기반 CI/CD 분야의 개척자 중 하나로, 빠른 빌드 속도를 자랑하는 유료 도구입니다.
- 제공사 바로가기: CircleCI 공식 홈페이지
TeamCity (팀시티)
- 특징: 개발 도구 전문 기업인 JetBrains사에서 개발한 고성능 빌드 관리 및 CI/CD 도구입니다.
- 제공사 바로가기: JetBrains TeamCity 공식 홈페이지

4. 나에게 맞는 CI/CD 툴을 고르는 기준

비교 기준	추천 툴	한 줄 평
"서버 비용 없이 빠르고 가볍게 시작하고 싶다"	GitHub Actions	깃허브를 쓰고 있다면 고민 없이 선택하세요.
"인프라를 직접 통제하고 완전 무료로 무제한 쓰고 싶다"	Jenkins	서버 구축 및 플러그인 관리를 즐긴다면 최고의 선택입니다.
"이미 Jira나 Bitbucket 같은 아틀라시안 도구를 쓰고 있다"	Bamboo	아틀라시안 생태계와의 끝판왕급 연동성과 편의성을 자랑합니다.
"보안이 중요해서 사내망에 별도로 구축해야 한다"	GitLab / Jenkins	자체 호스팅 환경에 최적화된 올인원 도구들입니다.
"쿠버네티스를 이용한 현대적인 배포가 타겟이다"	Argo CD	최근 핫한 GitOps 기반 배포의 최강자입니다.

5. CI/CD를 깊이 있게 공부할 수 있는 추천 관련 글 & 가이드

CI/CD의 기초 개념부터 실제 구축하는 방법까지 체계적으로 공부할 수 있는 유익한 리소스를 소개합니다. 블로그 방문자분들도 이 링크를 통해 실무 지식을 쌓는 데 큰 도움을 얻으실 수 있습니다.

레드햇(Red Hat) - CI/CD 가이드: 대기업 레드햇이 초보자를 위해 매우 이해하기 쉽게 정리해 둔 교과서 같은 글입니다.
- 레드햇 공식: CI/CD란 무엇인가요?
우아한형제들 기술블로그: 실무에서 대규모 트래픽을 처리하는 배포 시스템을 어떻게 다루는지 개발자들의 생생한 후기가 담겨 있습니다.
- 우아한형제들 기술블로그 바로가기
Subicura(수비쿠라) 기술블로그: 초보 개발자들에게 아주 친절한 설명으로 유명한 DevOps 관련 필수 방문 블로그입니다.
- Subicura 블로그 (DevOps & CI/CD)

마치며

현대 개발에서 CI/CD는 단순한 "선택"이 아니라 안정적이고 빠른 서비스를 위한 "필수" 요건입니다. 각자 개발 중인 프로젝트 규모와 팀의 인프라 환경에 맞는 최적의 툴을 선택해 보세요!

궁금한 점이나 본인만의 추천 툴이 있다면 아래 댓글로 함께 나누어 주시기 바랍니다.

감사합니다. 가야태자 @talkit 이었습니다!

PHP에서 Java로, 다시 Python으로 — 하나의 언어를 완벽히 숙지하면 벌어지는 일

가야태자 — Thu, 23 Jul 2026 09:12:07 +0900

안녕하세요, 가야태자 @talkit 입니다.

처음 프로그래밍을 시작할 때, 혹은 한창 공부 중일 때 주변에서 이런 말 한 번쯤 들어보셨을 겁니다.

"언어는 도구일 뿐이다. 하나만 완벽하게 하면 다른 언어는 금방 배운다." — 컴퓨터 과학의 거장들 (MIT 할 에이벌슨 교수, 하버드 CS50 데이비드 말란 교수 등)

혹시 이 말을 들으면서 '말은 쉽지, 문법이 아예 다른데 그게 어떻게 가능해?'라며 속으로 의구심을 품은 적 없으신가요? 오늘은 제가 주니어 프로그래머 시절부터 시니어가 된 지금까지, 이 격언을 몸소 체험했던 실제 경험담을 공유해보려고 합니다. 결론부터 말씀드리면, 그 석학들의 말은 진짜였습니다.

1막. 나의 주니어 시절: C, Perl, 그리고 인생 언어 'PHP'

저 역시 주니어 시절에는 개발 생태계에서 살아남기 위해 다양한 언어를 기웃거렸습니다. C 언어도 보고, Perl도 만져보고, PHP도 공부했죠. 그중에서 제가 가장 깊게 파고들고, 스스로 '완벽하게 익혔다'고 느꼈던 인생 첫 언어는 바로 PHP였습니다.

PHP로 웹 서비스를 직접 만들고 데이터베이스를 만지면서, 단순히 문법을 외우는 게 아니라 프로그래밍의 핵심 메커니즘을 온몸으로 깨우쳤습니다.

변수에 값이 어떤 흐름으로 담기는지
조건문과 반복문이 어떻게 제어 흐름을 만드는지
함수를 어떻게 쪼개고 재사용해야 코드가 깔끔해지는지

언어의 껍데기를 넘어 '컴퓨터에게 일을 시키는 구조(Logic)'를 PHP라는 도구를 통해 완전히 마스터한 것이죠.

"PHP의 echo가 Java에서는 뭐였더라?"

시간이 흘러 기술 트렌드와 프로젝트 환경에 따라 Java와 C#으로 언어를 전환해야 하는 시기가 왔습니다. 완전히 새로운 환경이었죠.

그때 제가 구글 검색창에 무엇을 쳤는지 아시나요? 아직도 기억이 나네요. ^^

"PHP echo Java 구현" "Java에서 print는 어떻게 하나요?"

주니어 시절 PHP에서 화면에 텍스트를 출력할 때 늘 쓰던 echo 명령어가 Java에서는 도대체 무엇인지 1:1로 매칭하는 검색이었습니다. 결과는 다들 아시다시피 System.out.println();이었죠. C#으로 넘어갈 때도 마찬가지로 "PHP의 이 기능은 C#에서 어떻게 쓰지?"라며 Console.WriteLine();을 찾아냈습니다.

이 소소한 검색 경험은 제게 아주 큰 깨달음을 주었습니다. 만약 제가 PHP를 대충 수박 겉핥기식으로 배웠다면, Java나 C# 책의 첫 페이지부터 다시 펴고 "변수란 무엇인가..."부터 머리를 싸매고 공부했을 겁니다.

하지만 저는 이미 '화면에 문자열을 출력해야 하는 타이밍과 프로그래밍적 이유'를 완벽히 알고 있었습니다. 단지 Java라는 나라에서는 그걸 어떤 '문법(단어)'으로 표현하는지만 알면 되는 상태였던 것이죠.

2막. 세월이 흘러 Java 전문가가 된 나, Python을 만나다

그로부터 많은 시간이 흘렀습니다. 저는 부단한 노력 끝에 Java 전문가 소리를 들을 만큼 연차가 쌓였고, 시스템의 아키텍처를 고민하는 시니어가 되었습니다.

그런 제게 최근 또 한 번의 변화가 찾아왔습니다. 바로 요즘 가장 핫한 언어 중 하나인 Python을 다루게 된 것입니다. 놀랍게도, 전문가가 된 상태에서도 주니어 시절 PHP에서 Java로 넘어갈 때와 똑같은 메커니즘이 제 머릿속에서 작동하기 시작했습니다. 역사는 반복되더군요.

아무리 경험이 많은 전문가라도 새로운 언어의 구체적인 '문법 단어'까지 태어날 때부터 알 수는 없는 법입니다. 데이터 문자열을 특정 기호 기준으로 쪼개야 하는 상황이 왔을 때, 제 손가락은 자연스럽게 다시 구글로 향했습니다.

"Java split Python 어떻게" "Python string split syntax"

Java 개발자라면 입에 달고 사는 str.split(",")이 Python 나라에서는 어떻게 쓰이는지 매칭하는 작업이었습니다.

// Java의 방식 (엄격한 타입 지정과 배열 반환)
String str = "apple,banana,cherry";
String[] fruits = str.split(",");

# Python의 방식 (직관적인 문법과 리스트 반환)
str = "apple,banana,cherry"
fruits = str.split(",")

검색 결과, 두 언어 모두 문자열을 쪼개는 내부적인 개념은 완벽히 같았습니다. 단지 Java는 엄격하게 타입이 지정된 배열(String[])을 반환하고, Python은 더 직관적인 리스트(List)를 반환하는 등의 언어적 개성만 다를 뿐이었습니다.

주니어와 시니어의 차이: "무엇을 검색해야 하는지 안다"

주니어 시절 echo를 검색할 때와, 시니어가 되어 split을 검색할 때의 결정적인 차이는 "검색의 속도와 정확도"였습니다.

초보자 시절에는 "문자열 쪼개기", "글자 나누는 법"처럼 기능 중심으로 모호하게 검색하느라 시간을 썼다면, 지금은 split이라는 명확한 컴퓨터 과학적 용어(Terminology)를 알고 검색합니다.

내가 구현하고자 하는 로직의 정확한 개념 이름을 아니까, 새로운 언어의 문법을 찾아내는 데 단 3초도 걸리지 않는 것이죠. 하버드나 MIT 교수님들이 말씀하신 "하나의 언어를 완벽히 숙지하라"는 조언의 진짜 가치는 바로 여기에 있습니다.

하나의 언어를 마스터하며 얻은 '개념의 이름표'들이 머릿속에 꽉 차 있으면, 새로운 언어를 배울 때는 그 이름표에 대응하는 그 나라의 단어만 1:1로 매칭하면 끝납니다.

글을 마치며: 지금 흔들리는 모든 개발자들에게

컴퓨터 과학에서는 이를 '튜링 완전성(Turing Completeness)'이라고 합니다. 쉽게 말해, PHP나 Java로 구현할 수 있는 알고리즘은 Python이나 C#으로도 다 구현할 수 있다는 뜻입니다. 알맹이(로직)는 같고 껍데기(문법)만 다를 뿐이죠.

지금 공부하고 있는 언어가 트렌드에서 뒤처지는 것 같아 불안하신가요? 옆자리 동료가 새로운 신생 언어를 공부한다고 해서 조급해하실 필요 전혀 없습니다.

지금 잡고 있는 그 언어로 원하는 기능을 막힘없이 구현할 수 있을 때까지, 내부 구조를 완전히 이해할 때까지 깊게 파보세요. 그 언어 하나를 완벽하게 숙지하고 나면, 훗날 어떤 거대한 새로운 언어를 만나더라도 구글 검색창에 저처럼 유쾌한 질문을 던지며 순식간에 적응하는 여러분을 발견하게 될 것입니다.

생각하는 힘(로직)은 변하지 않으며, 언어는 그것을 표현하는 비서일 뿐이니까요.

가야태자 @talkit 이었습니다. 감사합니다!

CVS, SVN 기억하시나요? 재미로 보는 버전 관리 역사와 현대 Git 저장소 3대장 비교

가야태자 — Wed, 22 Jul 2026 09:40:56 +0900

CVS, SVN 기억하시나요? 재미로 보는 버전 관리 역사와 현대 Git 저장소 3대장 비교

안녕하세요, 가야태자 @talkit 입니다.

저는 요즘 AA(Application Architect)로서 정리해 두어야 할 문서들을 하나씩 정리해 나가고 있습니다. 아무래도 제가 주로 Java 베이스로 아키텍처를 설계하고, 최근에는 효율적인 CI/CD 파이프라인 구축 관련 일들을 많이 다루다 보니 자연스럽게 '버전 관리 저장소'와 그 생태계에 관심이 머물게 되더군요.

그래서 오늘은 우리가 매일 공기처럼 쓰고 있는 버전 관리의 간략한 역사와 현대적 버전 관리 시스템의 상징인 Git, 그리고 협업의 중심이 되는 온라인 저장소(GitHub, GitLab, Bitbucket)에 대한 이야기를 가볍지만 깊이 있게 풀어보려고 합니다.

1. 버전 관리 시스템(VCS)의 발전 흐름

우리가 지금 쓰고 있는 Git이 대세가 되기까지, 버전 관리 시스템은 기술의 발전과 협업 규모의 확장에 따라 크게 4가지 세대를 거치며 진화해 왔습니다.

[1세대: 로컬/초기] RCS (파일 단위 Lock)
       ▼
[2세대: 중앙 집중형] CVS ──> SVN (서버 중심, 네트워크 필수)
       ▼
[3세대: 분산형] Git, Mercurial (로컬 저장소, 독립적 브랜치)
       ▼
[4세대: 차세대 (현재 진행형)] Jujutsu(jj), Sapling 등 (Git 호환 및 사용성 극대화)

1세대 (로컬 형): 네트워크 개념이 없던 초기에는 RCS 같은 도구를 사용해 내 컴퓨터 안에서만 버전을 관리했습니다. 동시 수정을 막기 위해 한 사람이 파일을 고치면 다른 사람은 손대지 못하게 잠그는 'Lock' 방식을 썼기 때문에 협업이 매우 답답했던 시절이었습니다.
2세대 (중앙 집중형): CVS와 SVN(Subversion)이 대표적입니다. 하나의 원격 중앙 서버에 코드를 두고 여러 사람이 동시에 수정 후 병합(Merge)할 수 있게 되면서 본격적인 팀 협업이 가능해졌습니다. 다만, 모든 작업에 네트워크 연결이 필수였고, 중앙 서버가 다운되면 전체 개발 팀의 손이 묶이는 치명적인 단점이 있었습니다.
3세대 (분산형): 리눅스 커널의 창시자 리누스 토르발스가 만든 Git이 대표 주자입니다. 중앙 서버에만 의존하지 않고 개발자 개개인의 PC에 전체 코드 히스토리를 통째로 복제(Clone)해 옵니다. 덕분에 오프라인에서도 커밋과 브랜치 생성이 가능하며 속도가 압도적으로 빨라 현재 글로벌 표준으로 자리 잡았습니다.
4세대 (차세대): 최근에는 Git의 복잡한 명령어 체계를 혁신하고, 수천 명의 개발자가 하나의 거대한 저장소를 공유하는 거대 기업(구글, 메타 등)의 환경에 맞춰 성능을 극대화한 Jujutsu(jj)나 Sapling 같은 Git 호환 시스템들이 등장하여 미래를 준비하고 있습니다.

2. 현대 개발의 허브, 온라인 Git 저장소의 개념

로컬 PC에서 Git으로 소스 코드를 아무리 잘 관리하더라도, 이를 안전하게 백업하고 팀원들과 공유하려면 원격 서버가 필요합니다. 이를 클라우드나 가상 서버 형태로 편리하게 제공해 주는 서비스가 바로 온라인 Git 저장소(Hosted Git Repository)입니다.

단순히 파일만 올려두는 백업 공간을 넘어, 현대 소프트웨어 엔지니어링의 핵심인 DevOps(개발 및 운영)의 중심 허브 역할을 수행하며 다음과 같은 핵심 가치를 제공합니다.

코드 백업 및 원격 동기화: 로컬의 변경 이력을 원격 서버에 안전하게 보관합니다.
협업 및 코드 리뷰: 변경된 코드를 비교(Diff)하고 의견을 나누는 Pull Request(또는 Merge Request) 시스템으로 코드 퀄리티를 유지합니다.
CI/CD 파이프라인 내장: AA인 제가 가장 집중하고 있는 부분이기도 합니다. 코드가 원격지에 푸시되는 순간 자동으로 빌드, 테스트를 수행하고 운영 서버에 배포하는 자동화 엔진을 자체적으로 탑재하고 있습니다.
이슈 트래킹 및 프로젝트 관리: 버그 추적(Issue), 기능 요구사항 관리, 칸반 보드 등을 한 곳에서 연동할 수 있습니다.

3. 주요 온라인 저장소 서비스 3대장 소개

현재 시장을 리드하고 있는 대표적인 3대 플랫폼입니다. 각 서비스는 지향점과 강점이 명확히 갈립니다.

GitHub (깃허브)

공식 사이트: https://github.com
한 줄 소개: 전 세계 오픈소스 생태계의 성지이자 사실상의 글로벌 표준.
특징: 개발자들의 포트폴리오로 가장 널리 활용됩니다. 풍부한 서드파티 플러그인 생태계(Marketplace)를 자랑하며, 무엇보다 강력한 AI 개발 도구인 GitHub Copilot과의 연계성이 독보적입니다.

GitLab (깃랩)

공식 사이트: https://about.gitlab.com
한 줄 소개: 기획부터 보안, 모니터링까지 하나의 도구로 끝내는 '올인원 DevOps' 플랫폼.
특징: 플랫폼 내부에 고도화된 자체 CI/CD 엔진이 내장되어 있어 별도의 툴(Jenkins 등)을 연동하지 않고도 강력한 파이프라인을 구축할 수 있습니다. DevSecOps(보안이 내장된 개발 프로세스)를 지향하는 기업들에게 인기가 높습니다.

Bitbucket (비트버킷)

공식 사이트: https://bitbucket.org
한 줄 소개: 협업 툴의 명가 아틀라시안(Atlassian) 생태계의 핵심 Git 저장소.
특징: 업무 관리 도구의 표준인 Jira(지라), 문서 협업 도구인 Confluence(컨플루언스)와 완벽하게 유기적으로 연동됩니다. 기존에 아틀라시안 제품군을 베이스로 업무 프로세스를 짜둔 기업 환경에서 최고의 시너지를 냅니다.

4. 한눈에 보는 저장소별 기능 및 정책 비교

프로젝트의 규모나 예산, 그리고 사내 보안 인프라 환경에 따라 어떤 저장소를 선택해야 할지 고민이 되실 텐데요. 각 플랫폼의 주요 특징을 표로 비교해 보았습니다.

항목	GitHub	GitLab	Bitbucket
대표 주소	github.com	about.gitlab.com	bitbucket.org
무료 플랜	제공 (개인/팀) • 사용자 무제한 • 공개/비공개 저장소 무제한	제공 (개인/팀) • 사용자 무제한 • 공개/비공개 저장소 무제한	제공 (소규모) • 최대 5인까지 무료 • 비공개 저장소 무제한
기본 스토리지	매우 넉넉함 • 저장소당 권장 1~5GB 제한 • 대용량 파일(LFS) 지원	네임스페이스당 10GB • 초과 시 추가 구매 가능	워크스페이스 전체 총 1GB • 초과 시 GB당 추가 비용
CI/CD 무료 제공	월 2,000 빌드 분량	월 400 빌드 분량	월 50 빌드 분량
유료 플랜 가격 (사용자당/월)	• Team: $4 • Enterprise: $21	• Premium: $29 • Ultimate: $99	• Standard: $3.65 • Premium: $7.25
사내 내부 설치 가능 여부 (On-Premise / Self-Hosted)	가능 (Enterprise Server) • 가상화 환경 및 자체 클라우드 내부 구축 가능	가능 (GitLab Self-Managed) • 오픈소스 기반으로 시작되어 사내 폐쇄망 구축에 매우 강력함	가능 (Bitbucket Data Center) • 대규모 클러스터링 및 고가용성(HA) 환경 사내 구축 지원

AA의 시선: 엔터프라이즈 환경에서의 내부 설치(On-Premise) 고려사항

보안이 엄격한 금융권이나 대기업, 공공기관 프로젝트를 리드하는 AA의 관점에서는 소스 코드를 외부 클라우드(SaaS)에 두는 것이 불가능한 경우가 많습니다. 이때는 사내 폐쇄망 인프라에 Git 서버를 직접 설치해야 하는데, 세 플랫폼 모두 이를 지원합니다. 다만 아키텍처 설계 시 다음과 같은 기준으로 접근하는 것을 추천합니다.

보안 제어와 인프라 통제가 완벽해야 한다면 ➡️ GitLab Self-Managed 태생부터 사내 독립 구축 시장을 타깃으로 성장했기에, 외부망이 차단된 폐쇄망 안에서도 취약점 스캔(SAST/DAST)이나 모니터링 툴을 올인원으로 가장 매끄럽게 구동할 수 있습니다.
기존 사내 업무 프로세스와의 결합이 우선이라면 ➡️ Bitbucket Data Center 이미 사내에 Jira 서버나 Confluence 서버를 구축하여 전사 표준으로 사용 중인 조직이라면, Bitbucket을 결합했을 때 티켓-커밋-브랜치 추적성이 가장 뛰어납니다.
글로벌 표준 환경과 AI 어시스턴트 도입이 목표라면 ➡️ GitHub Enterprise Server 가장 대중적이고 개발자들에게 익숙한 UI를 사내망에 그대로 복제해 올 수 있으며, 최근 사내망용 AI 개발 비서(SaaS 연계형 혹은 독립형 Copilot)를 결합하려는 엔터프라이즈 트렌드에 힘입어 도입 비중이 늘고 있습니다.

블로그에 방문해 주신 분들은 현재 어떤 버전 관리 저장소를 주력으로 사용하고 계시나요? 조직의 성격과 인프라 환경에 맞춰 최적의 솔루션을 선택하는 데 이 글이 작은 도움이 되었으면 좋겠습니다.

다음에도 Java 아키텍처 설계나 CI/CD 파이프라인을 구축하면서 느낀 실무적인 인사이트를 담은 문서들로 찾아뵙겠습니다. 감사합니다!

[윈도우즈용 터미널 비교] 나에게 맞는 최적의 툴은?

가야태자 — Tue, 21 Jul 2026 09:48:53 +0900

안녕하세요 가야태자 @talkit 입니다.

지난번 맥북 터미널 비교에 이어, 이번엔 윈도우즈 환경에서 개발과 서버 관리를 위한 터미널 프로그램들을 비교해 보겠습니다. 윈도우즈는 맥에 비해 다양한 터미널 프로그램이 존재하며, 각 프로그램마다 특징과 장단점이 명확하기 때문에 사용 목적과 환경에 맞게 선택하는 것이 중요합니다.

이번 비교에서는 터미우스 (Termius), 모바엑스텀 (MobaXterm), 푸티 (PuTTY), CRT (SecureCRT), Xshell (엑스쉘) 이렇게 5가지 대표적인 윈도우즈 터미널 프로그램을 소개하고, 각 프로그램의 특징, 라이선스, 그리고 어떤 환경에 어떤 클라이언트를 사용하는 것이 좋은지 정리해 드립니다.

1. 터미우스 (Termius) — 크로스플랫폼 기반의 스마트 원격 관리자

맥 환경에서도 인기가 높았던 Termius는 윈도우즈에서도 강력한 성능과 편리함을 제공합니다. 세련된 UI와 클라우드 동기화 기능이 특징입니다.

공식 사이트 주소: https://termius.com
라이선스:
- 무료 (Starter 플랜): 개인 및 상업적 이용 가능. 기본 SSH 접속 및 서버 관리 가능. 기기 간 동기화 불가.
- 유료 (Pro/Team 플랜): 기기 간 동기화, SFTP, 포트 포워딩, 팀 협업 기능 등 제공.
작동 방식: GUI 기반 서버 관리 및 접속. 터미널 내에서 명령어를 직접 입력하여 작업.
주요 특징:
- 세련된 UI: 현대적이고 미니멀한 디자인으로 시각적으로 보기 좋고 사용하기 편리합니다.
- 클라우드 동기화: (유료 플랜) PC, 모바일, 웹 등 다양한 기기에서 서버 리스트와 세팅을 동기화하여 사용할 수 있습니다.
- 간편한 서버 관리: GUI 메뉴에 서버 정보를 등록하고 클릭 한 번으로 간편하게 접속할 수 있습니다.
- 다양한 기능: SSH, SFTP, Telnet, Serial 등 다양한 프로토콜 지원. SFTP 클라이언트 내장.

가야태자의 요약: Termius 무료 버전은 기기 간 동기화가 불가능하지만, 개인 PC 한 곳에서 사용하기에는 충분합니다. 깔끔한 UI와 직관적인 서버 관리를 선호하는 분들에게 추천합니다.

2. 모바엑스텀 (MobaXterm) — 다양한 기능을 갖춘 올인원 터미널

MobaXterm은 터미널, SFTP, X11 서버 등 서버 관리에 필요한 다양한 도구들을 하나로 묶은 올인원 터미널 프로그램입니다.

공식 사이트 주소: https://mobaxterm.mobatek.net
라이선스:
- 무료 (Home Edition): 개인 및 상업적 이용 가능. 세션 개수 제한 (12개). 매크로 개수 제한.
- 유료 (Professional Edition): 세션 및 매크로 개수 제한 해제, 추가 기능 제공.
작동 방식: GUI 기반 서버 관리 및 접속. 터미널 내에서 명령어를 직접 입력하여 작업.
주요 특징:
- 올인원 툴: 터미널, SFTP, X11 서버, SSH 터널링 등 다양한 기능을 하나의 프로그램에서 제공합니다.
- 편리한 SFTP: 터미널 왼쪽 창에 SFTP 클라이언트가 내장되어 있어 편리하게 파일을 전송할 수 있습니다.
- X11 서버 지원: GUI 기반 리눅스 애플리케이션을 윈도우즈 화면에 띄울 수 있습니다.
- 다양한 프로토콜 지원: SSH, Telnet, RDP, VNC, FTP 등 다양한 프로토콜 지원.

가야태자의 요약: MobaXterm 무료 버전은 세션 개수 제한이 있지만, 다양한 기능을 갖춘 올인원 툴로서 매력적입니다. SFTP 전송 및 X11 서버 기능이 필요한 분들에게 강력히 추천합니다.

3. 푸티 (PuTTY) — 심플하고 가벼운 오픈소스 SSH 클라이언트

PuTTY는 윈도우즈 SSH 클라이언트의 대명사로, 심플하고 가벼우며 완전 무료인 오픈소스 프로그램입니다.

공식 사이트 주소: https://www.putty.org
라이선스: 완전한 오픈소스 (MIT 라이선스). 기업/개인/상업적 이용 모두 아무런 조건 없이 100% 무료.
작동 방식: 명령어를 직접 입력하여 SSH 접속 및 작업.
주요 특징:
- 심플하고 가벼움: 프로그램 용량이 작고 설치가 간편하며 실행 속도가 빠릅니다.
- 오픈소스: 누구나 무료로 사용할 수 있고 코드를 확인 및 수정할 수 있습니다.
- 안정성: 오랜 기간 사용되어 검증된 안정성을 제공합니다.
단점:
- 부족한 기능: 서버 목록 관리, 화면 분할 등 다양한 편의 기능이 부족합니다.
- 구식 UI: 현대적인 UI에 비해 시각적으로 다소 오래된 느낌을 줍니다.

가야태자의 요약: PuTTY는 심플하고 가벼운 SSH 클라이언트가 필요한 분들에게 최적입니다. 고급 기능보다는 기본에 충실한 툴을 선호하는 분들에게 추천합니다.

4. CRT (SecureCRT) — 상업용 고성능 SSH 클라이언트

SecureCRT는 상업용 고성능 SSH 클라이언트로, 강력한 보안 기능과 다양한 편의 기능을 제공합니다.

공식 사이트 주소: https://www.vandyke.com
라이선스: 기업 유료 (라이선스 비용 발생). 무료 체험판 제공.
작동 방식: GUI 기반 서버 관리 및 접속. 터미널 내에서 명령어를 직접 입력하여 작업.
주요 특징:
- 강력한 보안: SSH1, SSH2 프로토콜 지원, 강력한 암호화 및 인증 기능 제공.
- 다양한 편의 기능: 서버 목록 관리, 화면 분할, 매크로, 세션 동기화 등 다양한 편의 기능 제공.
- 고성능: 빠르고 안정적인 연결 성능을 제공합니다.
- 다양한 프로토콜 지원: SSH, Telnet, RDP, VNC, FTP 등 다양한 프로토콜 지원.

가야태자의 요약: SecureCRT는 강력한 보안 기능과 고성능 SSH 클라이언트가 필요한 기업 사용자에게 적합합니다. 유료 라이선스 비용이 발생하므로 신중하게 선택해야 합니다.

5. Xshell (엑스쉘) — 윈도우즈 전용 강력한 SSH 클라이언트

Xshell은 윈도우즈 전용 강력한 SSH 클라이언트로, 기업용 표준 툴로 널리 사용됩니다.

공식 사이트 주소: https://www.netsarang.com/ko/xshell/
라이선스: 기업 유료 (라이선스 비용 발생). 무료 체험판 제공.
작동 방식: GUI 기반 서버 관리 및 접속. 터미널 내에서 명령어를 직접 입력하여 작업.
주요 특징:
- 강력한 기능: 서버 목록 관리, 화면 분할, 매크로, 세션 동기화 등 다양한 편의 기능 제공.
- 고성능: 빠르고 안정적인 연결 성능을 제공합니다.
- 다양한 프로토콜 지원: SSH, Telnet, RDP, VNC, FTP 등 다양한 프로토콜 지원.
- 기업용 표준 툴: 많은 기업에서 표준 툴로 사용하여 안정성과 신뢰성이 높습니다.

가야태자의 요약: Xshell은 강력한 기능과 고성능 SSH 클라이언트가 필요한 기업 사용자에게 최적입니다. 유료 라이선스 비용이 발생하므로 신중하게 선택해야 합니다.

윈도우즈 터미널 비교 요약

비교 항목	Termius (터미우스)	MobaXterm (모바엑스텀)	PuTTY (푸티)	CRT (SecureCRT)	Xshell (엑스쉘)
비용 / 라이선스	무료 (Starter 플랜) / 유료	무료 (Home Edition) / 유료	완전 무료 오픈소스	유료 (상업용)	유료 (상업용)
작동 방식	GUI 기반 서버 관리 및 접속	GUI 기반 서버 관리 및 접속	명령어를 직접 입력	GUI 기반 서버 관리 및 접속	GUI 기반 서버 관리 및 접속
주요 특징	세련된 UI, 클라우드 동기화	올인원 툴, SFTP, X11 서버 지원	심플하고 가벼움, 오픈소스	강력한 보안, 고성능	강력한 기능, 고성능
추천 대상	깔끔한 UI와 직관적인 서버 관리를 선호하는 분	다양한 기능을 갖춘 올인원 툴이 필요한 분	심플하고 가벼운 SSH 클라이언트가 필요한 분	강력한 보안과 고성능 SSH 클라이언트가 필요한 기업 사용자	강력한 기능과 고성능 SSH 클라이언트가 필요한 기업 사용자

가야태자의 최종 결론: 어떤 걸 선택해야 할까요?

"깔끔한 UI와 직관적인 서버 관리를 선호한다!" Termius를 추천합니다. 무료 버전도 충분히 사용 가능하며, 유료 플랜을 사용하면 기기 간 동기화 기능도 이용할 수 있습니다.
"다양한 기능을 갖춘 올인원 툴이 필요하다!" MobaXterm을 추천합니다. 터미널, SFTP, X11 서버 등 서버 관리에 필요한 다양한 도구들을 하나의 프로그램에서 제공합니다. 무료 버전도 충분히 사용 가능합니다.
"심플하고 가벼운 SSH 클라이언트가 필요하다!" PuTTY를 추천합니다. 완전 무료이고 가벼우며 설치가 간편합니다. 기본에 충실한 툴을 선호하는 분들에게 최적입니다.
"강력한 보안과 고성능 SSH 클라이언트가 필요한 기업 사용자이다!" SecureCRT 또는 Xshell을 추천합니다. 강력한 보안 기능과 다양한 편의 기능을 제공하며, 많은 기업에서 표준 툴로 사용하여 안정성과 신뢰성이 높습니다. 다만, 유료 라이선스 비용이 발생하므로 신중하게 선택해야 합니다.

가야태자의 선택

저는 Putty 를 주로 사용하고 있습니다. 다양한 툴들이 편하긴 하지만, Putty에 너무 익숙해져 있어서, 하지만, 앞으로 다양한 툴을 사용해봐야겠습니다.

윈도우즈용 터미널은 다양한 선택지가 존재하므로, 사용 목적과 환경에 맞게 선택하는 것이 중요합니다. 이번 비교 글이 도움이 되었기를 바랍니다. 오늘도 생산성 높은 하루 되세요! 감사합니다.

[꿀팁] 회사에서 MobaXterm과 Termius 무료로 써도 될까? 라이선스 및 특징 비교

[맥용 터미널 비교] iTerm2 vs Termius: 나에게 맞는 최적의 툴은? (Xshell 비교 포함)

리눅스/Linux PuTTY로 SSH를 통해서 VMWARE Linux에 접속해보자. How to connect to Linux on VMWARE via SSH with PuTTY

무료 보안쉘 클라이언트 PuTTY 최신 버전 다운로드 및 설치하기. How to Install the latest version PuTTY that is free Secure Shell Client.

오늘의 작은 행복, 우연히 만난 수국

가야태자 — Mon, 20 Jul 2026 22:38:42 +0900

![8E9753D2-7972-4E2A-A5B0-C32C41B1DAF2.png](https://cdn.steemitimages.com/DQmR4wkcjPkrz2AyL7HT4J6YfhzwqUtx9EMQWSnW3eWc6n2/8E9753D2-7972-4E2A-A5B0-C32C41B1DAF2.png)

안녕하세요 가야태자 @talkit 입니다.

오늘은 AA관련글은 조금 쉽니다. ^^

오늘 광화문에서 충정로로 걸어서 이동을 했습니다.

근무지가 여러곳이라 ^^

가면서 수국이 보여서 사진을 찍고

집으로 돌아오는 길에 내려서 안양천을 지나가는데 또 수국이 보여서 찍었습니다.

다들 새로운 한주도 즐거운 한주 되십시오.

감사합니다.

[성능 개선 이야기] APM이란 무엇인가? 사상, 기능, 그리고 언어별 작동 원리

가야태자 — Mon, 20 Jul 2026 09:00:43 +0900

안녕하세요, 가야태자 @talkit 입니다.

저는 요즘 성능 개선 관련 업무를 진행하고 있는데, 최근 방문한 고객사 시스템에 APM이 없는 것을 확인하고 오픈소스 APM인 Scouter(스카우터)를 도입해서 유용하게 사용하고 있습니다.

해당 제품을 사용하면서 문득 늘 당연하게 쓰던 APM은 과연 '어떤 사상에서 출발했고, 어떤 기능을 하며, 우리가 쓰는 프로그래밍 언어의 어떤 특징을 이용해서 모니터링을 수행하는지' 깊게 궁금해졌습니다.

해서 오늘은 APM의 핵심 개념과 언어별 모니터링 작동 원리에 대해서 깊이 있게 알아보고, 다음 글에서 구체적인 제품들에 대해 알아보는 시간을 가지도록 하겠습니다.

[성능 개선 이야기] APM이란 무엇인가? 사상, 기능, 그리고 언어별 작동 원리 (Java, C++, Python, Node.js)

1. APM은 어떤 사상에서 출발했을까?

과거의 모니터링은 주로 인프라(System) 중심이었습니다. "서버의 CPU 사용량은 얼마인가?", "메모리가 꽉 차지 않았나?", "네트워크 인/아웃 트래픽은 어떤가?" 등 서버 장비 자체의 건강 상태를 체크하는 데 집중했죠.

하지만 웹 서버(WAS), 데이터베이스, 외부 API 등이 유기적으로 얽힌 현대의 아키텍처에서는 이상한 일이 벌어지기 시작했습니다. 인프라 모니터링 상으로는 서버가 아주 멀쩡하고 평온한데, 정작 "사용자는 서비스가 너무 느려서 터지려고 한다"고 불평하는 현상이 발생한 것입니다.

여기서 APM(Application Performance Monitoring)의 핵심 사상이 탄생합니다. 바로 "사용자 경험(UX)과 비즈니스 트랜잭션 중심의 모니터링"입니다. 인프라 장비가 아니라, 사용자의 요청(Request)이 시스템 내부에 들어온 순간부터 나갈 때까지의 '애플리케이션 내부 흐름'을 낱낱이 파헤쳐보자는 아이디어에서 출발한 것입니다.

2. APM의 핵심 기능은 무엇일까?

APM은 서비스라는 환자의 몸속을 들여다보는 X-ray나 MRI와 같은 역할을 합니다. 대표적인 핵심 기능은 다음과 같습니다.

트랜잭션 추적 (Transaction Tracing): 사용자가 버튼을 클릭한 순간부터 어떤 클래스와 메서드를 거쳐 결과가 반환되었는지 그 전체 경로를 추적합니다.
병목 구간 탐지: 전체 응답 시간이 3초라면, 그중 DB 쿼리를 실행하는 데 2.5초가 걸렸는지, 외부 API를 호출하는 데 지연이 있었는지 정확한 원인 지점을 짚어냅니다.
실시간 가시성 (Topology & Dashboard): 복잡하게 얽힌 서비스 간의 호출 관계를 시각적인 맵으로 그려주고, 현재 활성화된 요청 수(Active Service)나 에러율을 실시간 대시보드로 보여줍니다.
코드 레벨의 프로파일링: 문제가 되는 로직을 소스 코드의 특정 메서드나 SQL 쿼리 단위까지 파고들어 내려가서 확인할 수 있게 해줍니다.

3. 언어별 어떤 특징을 이용해 모니터링을 진행할까?

개발자가 모니터링을 하겠다고 소스 코드 사이사이에 일일이 시간 측정용 코드를 심는 것은 불가능에 가깝습니다. 그래서 APM은 우리가 사용하는 프로그래밍 언어와 런타임의 고유한 특성을 활용해, 소스 코드를 한 줄도 수정하지 않고도 마법처럼 모니터링을 수행합니다.

짚고 넘어가는 핵심 요약

Java: 컴파일 시점(정확히는 클래스가 로딩되는 찰나)에 바이트코드를 조작하여 코드를 주입합니다.

C++: 런타임 조작이 어려워 컴파일 타임 훅(Hook)이나 OS 레벨의 시스템 콜 추적을 활용합니다.

Python / Node.js: 극도의 유연성을 가진 인터프리터 및 이벤트 루프 특성을 살려, 실행 시점(런타임)에 함수를 통째로 감싸거나 바꿔치기(Wrapping)합니다.

① Java 환경: 바이트코드 조작 (Bytecode Instrumentation)

Java 애플리케이션이 실행될 때 -javaagent라는 JVM 옵션을 주어 APM 에이전트를 함께 띄웁니다. JVM의 클래스 로더(Class Loader)가 컴파일된 클래스 파일(.class)을 읽어와 메모리에 올리는 바로 그 찰나의 순간에, APM 에이전트가 이 바이트코드를 가로챕니다. 그리고 메서드의 시작과 끝부분에 모니터링을 위한 시간 측정용 코드를 동적으로 '끼워 넣고(Weaving)' 메모리에 적재합니다. 덕분에 개발자는 원본 소스 코드를 전혀 건드리지 않고도 완벽한 프로파일링 데이터를 얻을 수 있습니다.

② C++ 환경: 컴파일 타임 훅 및 OS 커널 추적

C++ 같은 네이티브 컴파일 언어는 가상 머신(VM)이 없기 때문에 런타임에 코드를 동적으로 조작하기가 매우 까다롭습니다. 따라서 컴파일할 때 프로파일링용 훅(Hook) 코드를 함께 빌드하거나, 애플리케이션 외부에서 OS 레벨의 기술(예: 리눅스의 eBPF, ptrace 등)을 활용해 시스템 콜(System Call)을 추적하고 성능을 측정하는 방식을 사용합니다.

③ Python 환경: 몽키 패칭 (Monkey Patching)

Python은 모든 것이 객체로 취급되고 런타임 구조를 동적으로 변경할 수 있는 극도의 유연성을 가지고 있습니다. Python APM 에이전트는 애플리케이션이 시작될 때 가장 먼저 로드되어, Django, FastAPI 같은 웹 프레임워크나 SQLAlchemy 같은 DB 라이브러리의 핵심 함수를 런타임에 동적으로 가짜 함수(Wrapper)로 가로채 교체해 버립니다. 또한 인터프리터 자체 내장 함수인 sys.setprofile() 등을 활용해 함수 호출 시점을 정밀하게 모니터링합니다.

④ Node.js 환경: 모듈 래핑 및 Async Hooks

Node.js는 단일 스레드 기반의 비동기 이벤트 루프 아키텍처를 가집니다. Node.js APM 에이전트는 require()나 import 시스템을 가로채서 http나 mysql 같은 핵심 모듈이 로드될 때 프록시(Proxy) 객체로 감싸서 내보내는 모듈 래핑(Shimming) 기술을 씁니다. 수많은 비동기 콜백들이 뒤섞이는 환경에서 요청의 맥락(Context)을 잃지 않기 위해, Node.js 내부의 async_hooks API를 사용하여 비동기 자원의 생명주기를 유기적으로 추적하고 연결합니다.

마치며

결과적으로 APM은 '시스템이 살아있는지'를 넘어 '애플리케이션이 얼마나 효율적으로 일하고 있는지'를 언어적, 런타임적 특성을 극한으로 활용해 추적하는 예술적인 도구라고 할 수 있습니다. 현재 저희가 도입한 오픈소스 Scouter 역시 이러한 기술들을 바탕으로 Java, Python, Node.js 에이전트를 각각 제공하며 데이터를 훌륭하게 수집해 주고 있습니다.

오늘은 이렇게 APM의 출발 사상과 작동 원리라는 이론적 토대를 다져보았습니다. 다음 글에서는 시장을 이끌고 있는 대표적인 APM 제품들의 종류와 상용 솔루션 및 오픈소스의 장단점을 비교해 보는 시간을 가지도록 하겠습니다. 감사합니다!

더 깊이 알아보기: APM 기술 기반 학습 링크

오늘 다룬 내용들을 더욱 심도 있게 공부하고 싶으신 분들을 위해, 각 언어별 핵심 기술과 Scouter에 대한 유용한 링크들을 공유합니다.

APM 전반 및 사상 (Observability)
• Google SRE Book - Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/ • 설명: 구글의 SRE(Site Reliability Engineering) 관점에서 바라보는 분산 시스템 모니터링의 철학을 배울 수 있는 교과서적인 자료입니다.
• What is Observability? (by Honeycomb): https://www.honeycomb.io/observability/ • 설명: 단순한 모니터링을 넘어, 현대 APM이 추구하는 '관측 가능성(Observability)'의 개념을 명확히 이해할 수 있습니다.
Java 환경: 바이트코드 조작
• Java Agents & Instrumentation API (Oracle Official): https://docs.oracle.com/en/java/javase/11/docs/api/java.instrument/java/lang/instrument/package-summary.html • 설명: JVM 레벨에서 코드를 동적으로 조작하기 위한 핵심 API인 java.lang.instrument 패키지의 공식 문서입니다.
• Introduction to ASM (Java Bytecode Manipulation Framework): https://asm.ow2.io/ • 설명: Scouter를 포함한 많은 Java APM들이 내부적으로 사용하는 가장 강력하고 빠른 바이트코드 조작 프레임워크인 ASM의 공식 사이트입니다.
C++ 환경: OS 및 커널 추적
• eBPF (Extended Berkeley Packet Filter) 공식 사이트: https://ebpf.io/ • 설명: 최신 C++ 및 리눅스 기반 시스템 모니터링의 핵심 기술로 떠오른 eBPF의 개념과 활용 사례를 배울 수 있습니다.
Python & Node.js 환경: 런타임 조작 및 비동기 추적
• Python sys.settrace() 공식 문서: https://docs.python.org/3/library/sys.html#sys.settrace • 설명: Python APM 에이전트가 코드 레벨 프로파일링을 수행할 때 사용하는 핵심 내장 함수의 상세 사양입니다.
• Node.js async_hooks 공식 문서: https://nodejs.org/api/async_hooks.html • 설명: Node.js의 복잡한 비동기 흐름을 추적하기 위해 APM 에이전트들이 필수적으로 사용하는 API 문서입니다.
우리가 쓰는 도구: Scouter (스카우터)
• Scouter 공식 깃허브 위키 (Korean): https://github.com/scouter-project/scouter/wiki • 설명: 아키텍처, 설치 방법, Java/Python/Node.js 에이전트 설정 등 실무에 바로 적용할 수 있는 가장 정확한 정보가 담긴 곳입니다. 가야태자님도 이 문서를 가장 많이 참고하셨을 것입니다.
• Naver Engineering - Scouter 오픈소스化 이야기: https://d2.naver.com/helloworld/903673 • 설명: Scouter가 탄생하게 된 배경과 초기 개발팀의 고민을 엿볼 수 있는 흥미로운 블로그 글입니다.

[맥용 터미널 비교] iTerm2 vs Termius: 나에게 맞는 최적의 툴은? (Xshell 비교 포함)

가야태자 — Fri, 17 Jul 2026 09:37:12 +0900

안녕하세요, 가야태자 @talkit 입니다.

맥(macOS) 환경에서 개발과 서버 관리를 주로 하신다면, 터미널 프로그램 선택은 작업 생산성과 직결되는 아주 중요한 문제죠. 시중에 수많은 프로그램이 나와 있지만, 요즘 맥 유저들 사이에서 가장 핫한 툴을 꼽으라면 단연 오픈소스의 자존심 iTerm2와 스마트한 크로스플랫폼 클라이언트인 Termius(터미우스)가 아닐까 싶습니다.

특히 윈도우 환경에서 서버 관리를 오래 하셨던 분들이라면 마음속에 항상 기준점으로 남아 있는 상용 프로그램이 하나 있으실 겁니다. 바로 넷사랑컴퓨터의 Xshell(엑스쉘)입니다. Xshell은 윈도우 진영의 절대 강자이자 기업용 상용 툴의 표준과도 같은 프로그램인데요.

맥으로 환경을 바꾸거나 회사에서 새로운 툴을 세팅할 때 요금제를 보면 한 가지 의문이 생기곤 합니다.

‘Starter 플랜이라는 명칭이 붙어 있고 유료 버전이 따로 공존하는 프로그램인데, 어떻게 기업에서도 무료로 쓸 수 있다는 거지? 혹시 나중에 라이선스 위반으로 공문이 날아오는 건 아닐까?’

저 역시 이 부분이 무척 궁금했었는데요, 공식 라이선스 규정을 꼼꼼히 확인해 본 결과 특정 조건만 만족하면 기업(회사) 환경에서도 법적 문제없이 무료로 사용 가능하다는 점을 확인했습니다.

회사에서 눈치 보지 않고 당당하게 쓸 수 있도록 두 프로그램의 기업 사용 가이드와 특징, 그리고 Xshell과의 비교 분석까지 한눈에 보기 좋게 총정리해 드립니다!

[맥용 터미널 비교] iTerm2 vs Termius: 나에게 맞는 최적의 툴은? (Xshell 비교 포함)

1. iTerm2 (아이터름2) — 맥 개발자의 순정 표준

맥 환경에서 기본 터미널의 아쉬움을 달래기 위해 가장 먼저 설치하는 완전 무료 오픈소스 프로그램입니다.

공식 사이트 주소: https://iterm2.com
라이선스: 완전한 오픈소스(GPL v2)로, 기업/개인/상업적 이용 모두 아무런 조건 없이 100% 무료입니다. 라이선스 공문 걱정 자체가 없는 가장 안전한 선택지입니다.
작동 방식: 기본적으로 내 맥(로컬)의 쉘(Zsh, Bash 등)을 구동하는 터미널입니다. 원격 서버(SSH)에 접속하려면 터미널 창에 ssh user@ip 명령어를 직접 입력하여 진입하는 방식입니다.
주요 특징:
- 압도적인 커스텀: 테마, 폰트, 투명도, 배경화면은 물론 단축키까지 사용자의 입맛대로 완벽하게 제어할 수 있습니다.
- 강력한 화면 분할: Cmd + D(수직 분할), Cmd + Shift + D(수평 분할)를 통해 한 화면에서 여러 터미널을 직관적으로 띄워놓고 작업하기 좋습니다.
- 다양한 고급 기능: 텍스트 검색(Cmd + F), 타임머신 기능(이전 출력 화면 복구), 자동 완성 및 마우스 클릭 링크 이동 등 맥 친화적인 유틸리티가 탄탄합니다.

2. Termius (터미우스) — 크로스플랫폼 기반의 스마트 원격 관리자

세련된 UI와 강력한 서버 호스트 관리 기능을 앞세운 구독형 프리미엄 프로그램입니다.

공식 사이트 주소: https://termius.com
라이선스 (기업 사용): 무료 등급인 Starter 플랜(무료)은 공식 홈페이지에 "Available for commercial usage(상업적 이용 가능)"라고 명확히 명시되어 있습니다. 기업 내에서 개인이 무료 계정을 생성해 사용하는 것은 아무런 법적 문제가 없습니다. 단, 개인이 각자 홈페이지에서 가입 및 다운로드하여 사용해야 합니다.
작동 방식: 로컬 터미널 기능도 제공하지만, 본질은 '원격 서버(SSH/SFTP) 관리 및 접속'에 특화된 클라이언트입니다. GUI 메뉴에 서버 IP와 키 파일을 미리 등록해 두고 클릭 한 번으로 접속하는 방식입니다.
주요 특징:
- 현대적이고 세련된 UI: 맥의 미니멀한 감성과 잘 어울리는 다크 모드와 직관적인 대시보드를 제공합니다.
- 서버(호스트) 관리 특화: 수십, 수백 개의 서버 접속 정보를 그룹별로 깔끔하게 저장하고 관리할 수 있어 SSH 클라이언트로서는 iTerm2보다 편리합니다.
- 모바일 연동 (유료 플랜): 유료로 업그레이드하면 맥에서 등록한 서버 리스트가 아이패드, 아이폰, 윈도우 PC와 실시간으로 동기화되어 이동 중에도 서버를 점검할 수 있습니다.

가야태자의 요약: 터미우스 무료 버전은 서버 등록 개수 제한은 없지만, ‘기기 간 동기화’가 안 된다는 단점이 있습니다. 회사 PC 한 곳에만 세팅해 두고 깔끔한 UI로 서버 관리를 하실 분들에게 최적입니다.

상용 툴의 기준, Xshell(엑스쉘)과 비교한다면?

많은 엔지니어와 개발자분들이 현업에서 Xshell을 표준처럼 사용해 오셨을 겁니다. 탭 기반의 깔끔한 세션 관리, 강력한 문자열 송수신 제어, 그리고 안정적인 다중 서버 동기화 입력(Send Input to All Sessions) 등은 Xshell을 포기하지 못하게 만드는 핵심 기능들이죠.

하지만 맥(macOS) 환경으로 전환하게 되면 완전히 새로운 선택지를 마주하게 됩니다. Xshell의 핵심 특징을 기준으로 비교해 보면 다음과 같습니다.

1️⃣ 플랫폼 지원의 한계 (Xshell vs Termius): Xshell은 기본적으로 윈도우 전용 프로그램입니다. 맥에서 Xshell을 쓰려면 와인(Wine) 같은 가상화 레이어를 쓰거나 패러렐즈를 켜야 하므로 맥 환경에 유기적으로 녹아들지 못합니다. 반면 Termius는 완벽한 크로스플랫폼(Mac, Windows, Linux, iOS, Android)을 지원하며 맥북 프로의 네이티브 실리콘 아키텍처에서 부드럽고 가볍게 구동됩니다.
2️⃣ 서버(호스트) 관리 방식 (Xshell vs iTerm2): Xshell은 좌측 창에 트리 구조로 수십 개의 서버 세션을 저장해 두고 더블 클릭으로 빠르게 넘나드는 방식이 매우 직관적입니다. 반면 iTerm2는 본질이 '로컬 터미널'이기 때문에 서버 목록을 트리형 GUI로 띄워주는 기능이 기본적으로 없습니다. '프로파일(Profile)' 기능을 수동으로 세팅해야 해서 Xshell 방식에 익숙한 분들에게는 처음에 다소 불편할 수 있습니다. 만약 Xshell처럼 직관적인 GUI 기반 호스트 관리를 원하신다면 Termius가 훨씬 좋은 대안이 됩니다.
3️⃣ 다중 서버 동기화 및 고급 기능 (Xshell vs iTerm2): 여러 서버 창에 동시에 같은 명령어를 입력하는 Xshell의 '동기화 송신' 기능은 맥의 iTerm2에서도 강력하게 구현됩니다. 화면을 분할(Cmd + D)한 상태에서 Cmd + Alt + ICmd + Alt + I 단축키를 누르면 현재 띄워진 모든 터미널 창에 명령어를 동시에 입력할 수 있어, 대량의 서버를 제어할 때 Xshell 못지않은 효율을 냅니다. (Termius 무료 버전에서는 이와 같은 다중 창 동기화 명령 기능이 제한되거나 유료 플랜을 요구하므로 아쉬울 수 있습니다.)

Xshell을 기준으로 본 한눈에 보는 3파전 비교

비교 항목	Xshell (상용 툴)	iTerm2 (맥 순정 오픈소스)	Termius (스마트 클라이언트)
비용 / 라이선스	기업 유료 (라이선스 비용 발생)	100% 무료 (기업/개인 무제한)	기본 무료 (Starter 상업적 이용 가능)
맥(macOS) 지원	공식 지원 안 함 (윈도우 전용)	맥 전용 (최적화 완벽)	크로스플랫폼 (맥/윈도우/모바일)
서버(비전) 관리	매우 강력 (트리형 GUI 구조)	미흡 (프로파일 설정 필요)	매우 강력 (현대적인 대시보드)
다중 창 동기화 입력	기본 지원	기본 지원 (Cmd + Alt + I)`Cmd + Alt + I`	유료 플랜 필요
최적의 추천 대상	기존 윈도우 인프라 엔지니어	맥 로컬 개발 + 파워 유저	맥북 유저 + 클라우드 원격 관리

가야태자의 최종 결론: 어떤 걸 선택해야 할까요?

"나는 내 맥북 안에서 코드 컴파일(C++, Java 등), CMake 빌드, Git 관리 등 로컬 개발 업무와 다중 창 동기화 작업이 메인이다!" 고민할 필요 없이 iTerm2를 커스텀해서 쓰시는 것이 정답입니다. 속도가 빠르고 맥 환경에 가장 잘 녹아듭니다.
"나는 윈도우에서 Xshell의 '서버 목록 관리 기능'을 가장 애용했으며, 클라우드(AWS 등)나 외부에 있는 리눅스 서버에 원격 접속해서 관리하는 업무가 메인이다!" GUI로 호스트 관리가 명확하고 UI가 깔끔한 Termius Starter를 회사 PC에 깔아서 시작해 보시는 것을 적극 추천합니다. UI와 세션 관리 직관성이 Xshell과 가장 유사하기 때문입니다.

가야태자의 선택

저는 참고로 맥에서 iTerm을 사용하고 있습니다. iPad에서는 Termius를 사용하고 있는데 맥북과 윈도우에 Termius도 설치 봐야겠습니다.
일단 기업용으로도 무료여서 좋은 것 같습니다. iTerm은 제가 좋아하는 오픈 소스이기는 하지만 맥북만 지원해서 아쉽네요.
윈도우즈용 터미널이 살짝 아쉬운데 윈도우즈용으로도 출시 해주면 좋을 것 같습니다.

블로그 이웃분들 중에서 윈도우에서 맥으로 넘어오며 터미널 유목민이 되신 분들에게 이 비교가 아주 속 시원한 가이드가 되길 바랍니다. 오늘 글이 도움 되셨다면 공감과 댓글 부탁드립니다. 오늘도 생산성 높은 하루 되세요! 감사합니다.

리눅스/Linux PuTTY로 SSH를 통해서 VMWARE Linux에 접속해보자. How to connect to Linux on VMWARE via SSH with PuTTY

무료 보안쉘 클라이언트 PuTTY 최신 버전 다운로드 및 설치하기. How to Install the latest version PuTTY that is free Secure Shell Client.

[꿀팁] 회사에서 MobaXterm과 Termius 무료로 써도 될까? 라이선스 및 특징 비교

가야태자 — Thu, 16 Jul 2026 09:10:21 +0900

안녕하세요, 가야태자 @talkit 입니다.

개발이나 서버 관리를 하다 보면 SSH, SFTP, Telnet 등을 지원하는 터미널 클라이언트 프로그램을 필수적으로 사용하게 됩니다. 시중에 수많은 프로그램이 나와 있지만, 요즘 가장 핫한 툴을 꼽으라면 단연 MobaXterm과 Termius가 아닐까 싶습니다.

두 프로그램 모두 매우 강력하고 편리한 기능을 제공하지만, 요금제를 보면 한 가지 의문이 생기곤 합니다.

‘Home 에디션이라는 명칭과 엄연히 유료 버전이 공존하는 프로그램인데, 어떻게 기업에서도 무료로 쓸 수 있다는 거지? 혹시 나중에 라이선스 위반으로 공문이 날아오는 건 아닐까?’

회사에서 눈치 보지 않고 당당하게 쓸 수 있도록 두 프로그램의 기업 사용 가이드와 공식 사이트, 버전별 특징을 깔끔하게 정리해 드립니다!

[꿀팁] MobaXterm vs Termius: 회사에서 무료로 쓰는 법과 특징 총정리

1. MobaXterm (모바엑스텀) 기업 사용 가이드

윈도우 환경에서 ‘끝판왕 올인원 터미널’로 불리는 MobaXterm은 회사에서도 무료로 사용할 수 있습니다. 단, 아래의 규정을 정확히 지켜야 합니다.

공식 사이트 주소: https://mobaxterm.mobatek.net

⚠️ 기업 내 무료 사용 조건 (핵심)

개별 직접 다운로드: 반드시 사용자 본인이 공식 홈페이지에서 무료 버전(Home Edition)을 직접 다운로드하여 설치해야 합니다.
사내 재배포 금지: 회사의 IT 관리자나 특정 직원이 설치 파일(.exe 또는 .msi)을 미리 다운로드해 사내 서버, 공유 폴더, 인트라넷에 올린 뒤 직원들에게 일괄 배포하는 행위는 라이선스 위반이 됩니다. 각자 알아서 받아 쓰게 해야 안전합니다.

버전별 특징 비교

기능 / 특징	Home Edition (무료)	Professional Edition (유료)
가격	무료 (상업적 이용 가능)	사용자당 약 $69 (영구 라이선스)
저장 가능 세션	최대 12개 제한	제한 없음
SSH 터널 개수	최대 2개 제한	제한 없음
매크로 저장	최대 4개 제한	제한 없음
네트워크 데몬	예외적 제한 (기본 기능만)	전 기능 개방 (TFTP, FTP 등 내장 서버)

가야태자의 요약: 관리하는 서버가 12개 이하인 개발자나 엔지니어라면 회사 PC에서 직접 다운로드해 홈 에디션을 쓰셔도 라이선스 공문 걱정이 전혀 없습니다.

2. Termius (터미우스) 기업 사용 가이드

맥(macOS), 윈도우, 모바일(iOS/Android)을 넘나드는 트렌디하고 깔끔한 UI의 터미우스 역시 기업에서 무료로 쓸 수 있는 플랜을 제공합니다.

공식 사이트 주소: https://termius.com

⚠️ 기업 내 무료 사용 조건 (핵심)

터미우스의 기본 등급인 Starter 플랜(무료)은 공식 홈페이지에 "Available for commercial usage(상업적 이용 가능)"라고 명확히 명시되어 있습니다. 기업 내에서 개인이 무료 계정을 생성해 사용하는 것은 아무런 법적 문제가 없습니다.

버전별 특징 비교

기능 / 특징	Starter (무료)	Pro / Premium (유료)
가격	무료 (상업적 이용 가능)	월 $10 ~ $30 선 (구독형)
기기 간 데이터 동기화	불가능 (로컬 저장만 가능)	가능 (PC, 맥, 스마트폰 간 실시간 동기화)
세션(서버) 저장 제한	제한 없음	제한 없음
SFTP / 파일 전송	기본 터미널 내 지원	그래픽 기반 드래그 앤 드롭 내장 SFTP 지원
스니펫 및 AI 기능	불가능	자주 쓰는 명령어(Snippet) 저장 및 AI 자동완성 제공

가야태자의 요약: 터미우스 무료 버전은 서버 등록 개수 제한은 없지만, ‘기기 간 동기화’가 안 된다는 단점이 있습니다. 회사 PC 한 곳에만 세팅해 두고 깔끔한 UI로 서버 관리를 하실 분들에게 최적입니다.

가야태자의 최종 결론: 나에게 맞는 툴은?

두 프로그램 모두 기업에서 합법적으로 무료 사용이 가능하므로, 본인의 작업 환경과 스타일에 따라 선택하시면 됩니다.

"나는 주로 윈도우를 쓰고, 관리할 서버가 12개 이하이며, 터미널 옆에 SFTP 폴더 트리가 바로 보이는 올인원 스타일이 좋다!" MobaXterm Home Edition 추천
"나는 맥(macOS)이나 리눅스를 혼용하고, UI가 스마트폰 앱처럼 깔끔하고 세련된 게 좋으며, 관리할 서버 개수가 많다!" Termius Starter 플랜 추천

내일부터 회사 PC 세팅하실 때 라이선스 눈치 보지 마시고, 공식 홈페이지에서 당당하게 무료 버전을 다운로드해 생산성을 높여보세요! 오늘 글이 도움 되셨다면 공감과 댓글 부탁드립니다. 감사합니다.

[추천] 비용은 줄이고 효율은 높이는 분야별 상용 프로그램 대체 무료 소프트웨어 가이드

가야태자 — Wed, 15 Jul 2026 09:20:12 +0900

안녕하세요, 가야태자 @talkit 입니다.

정말 오랜만에 인사드리는 것 같습니다. 2010년에 상용 프로그램을 대체할 수 있는 무료 소프트웨어 리스트를 정리해서 공유해 드린 적이 있었는데요. 세월이 흐른 만큼 IT 환경도 정말 많이 바뀌었습니다.

당시 제가 추천해 드렸던 빵집, 압축시대, 오픈오피스 같은 추억의 프로그램들은 이제 대부분 개발이 중단되거나 새로운 강자들에게 자리를 내어주게 되었습니다. 반면, 기술이 발전하면서 요즘 나오는 무료·오픈소스 프로그램들은 굳이 비싼 돈을 주고 상용 프로그램을 사지 않아도 될 만큼 엄청난 완성도를 자랑합니다.

그래서 현재를 기준으로, 라이선스 걱정 없이 안심하고 사용할 수 있는 ‘최신 버전 무료 대체 소프트웨어 리스트’를 공식 다운로드 링크와 함께 새롭게 업데이트해 보았습니다.

혹시 예전에 제가 작성했던 원글이 궁금하시다면 [이전 글] 상용프로그램을 대체할 무료 프로그램 정리에서 확인하실 수 있으며, 이 외에도 제 블로그의 [무료소프트웨어 카테고리]를 방문하시면 더 다양하고 많은 무료 소프트웨어 정보를 참고하실 수 있으니 많은 방문 부탁드립니다.

개인 PC는 물론이고 기업 환경에서 세팅하실 때도 큰 도움이 되기를 바랍니다.

[추천] 비용은 줄이고 효율은 높이는 분야별 상용 프로그램 대체 무료 소프트웨어 가이드

종류	상용 프로그램	무료/오픈소스 대체 프로그램 (공식 다운로드 링크)	비고 (최신 트렌드 및 팁)
압축 프로그램	WinZip, WinRAR, 알집(기업 유료)	반디집 (개인 무료) 7-Zip (오픈소스)	과거 쓰이던 '빵집', '압축시대'는 개발이 중단되었습니다. 현재는 깔끔하고 빠른 반디집과 멀티코어를 잘 활용하는 고성능 오픈소스인 7-Zip이 표준입니다.
이미지 뷰어	알씨(기업 유료), ACDSee	꿀뷰 (무료) FastStone Image Viewer (개인 무료)	꿀뷰는 여전히 가볍고 만화/이미지 보기에 최고의 성능을 자랑합니다. 리스트나 디렉터리 기반 미리보기가 필요하다면 FastStone도 좋은 대안입니다.
FTP 프로그램	WS_FTP, 알FTP	FileZilla (오픈소스) WinSCP (오픈소스/윈도우 전용)	알FTP는 단종되었으며 현재는 FileZilla(크로스플랫폼)와 WinSCP(윈도우 전용, 안정적인 SFTP/SCP 지원)가 전 세계 표준으로 자리 잡았습니다.
Telnet / SSH Client	Xshell, SecureCRT	PuTTY (오픈소스) MobaXterm (Home 에디션 무료) Termius (기본 무료)	과거의 Putty+PuttyCM 조합보다는, 현대적인 탭 기능과 SFTP 브라우저를 내장한 올인원 터미널 MobaXterm을 강력히 추천합니다. macOS/Linux라면 기본 터미널을 써도 무방합니다.
CD 버닝 프로그램	Nero Burning ROM	CDBurnerXP (무료) Rufus (USB 부팅 디스크 제작)	최근 하드웨어에는 ODD(CD/DVD 드라이브)가 장착되지 않아 수요가 급감했습니다. 굳이 필요하다면 CDBurnerXP가 아직 유지되고 있습니다. USB 부팅 디스크 제작용으로는 Rufus를 많이 씁니다.
비트맵 이미지 처리	Adobe Photoshop	GIMP (오픈소스) Paint.NET (무료) Photopea (웹 기반 무료)	GIMP와 Paint.NET은 여전히 건재합니다. 최근에는 설치 없이 웹 브라우저에서 포토샵 UI 그대로 사용할 수 있는 Photopea가 가볍게 편집할 때 각광받고 있습니다.
오피스 (문서, 스프레드시트)	MS Office, 한컴오피스	LibreOffice (오픈소스) Google 문서/스프레드시트 (웹 기반)	기존 'OpenOffice'는 개발이 정체되어 현재는 그 후속 격인 LibreOffice가 오픈소스 진영을 이끌고 있습니다. 설치가 필요 없고 협업이 강력한 Google 오피스 계열이 가장 대중적으로 쓰입니다.

최근 IT 트렌드를 반영한 추가 대체 프로그램

예전 글에는 없었지만, 요즘 PC 환경에서 빼놓을 수 없는 필수 카테고리도 함께 추가합니다.

벡터 그래픽 (Adobe Illustrator 대체): Figma (웹 기반, 개인 무료) / Inkscape (오픈소스)
동영상 편집 (Premiere Pro 대체): DaVinci Resolve (전문가급 무료 버전 제공)
텍스트/코드 에디터 (UltraEdit 대체): VS Code (전 세계 개발자 표준 에디터)

[개발/생산성] 마크다운(Markdown) 문법 총정리: 기본부터 GitHub·옵시디안 확장 문법까지

가야태자 — Tue, 14 Jul 2026 09:40:13 +0900

[개발/생산성] 마크다운(Markdown) 문법 총정리: 기본부터 GitHub·옵시디안 확장 문법까지

안녕하세요 가야태자 @talkit 입니다. ^^

오랜만에 블로그 분석을 해보니 마크다운 관련 글이 여전히 인기 순위 1위를 달리고 있네요. 많은 분이 마크다운에 관심을 두시는 모습을 보며, '도대체 마크다운 문법의 끝은 어디일까? 기본 문법부터 깃허브나 옵시디안 같은 플랫폼 전용 확장 문법까지 한눈에 정리해 두면 어떨까?' 하는 궁금증과 욕심이 생겼습니다.

마크다운(Markdown)이란?

마크다운은 텍스트 기반의 경량 마크업 언어입니다. 복잡한 HTML 태그를 쓰지 않고도 #, * 같은 단순한 기호 몇 개로 글을 보기 좋게 꾸밀 수 있어, 개발자 문서 문서화부터 블로그 포스팅, 개인 메모까지 폭넓게 사랑받고 있습니다. 무엇보다 텍스트 그대로 읽어도 가독성이 좋고, 플랫폼에 종속되지 않는다는 강력한 장점이 있습니다.

1. 마크다운 기본 문법 (Standard Markdown)

가장 기초가 되며 대부분의 편집기에서 호환되는 필수 문법입니다.

제목 (Headers): #의 개수로 크기를 조절합니다 (1~6단계).
```
  # 제목 1 (가장 큼)
  ## 제목 2
  ### 제목 3
```

강조 (Emphasis): 텍스트를 굵게 하거나 기울입니다.

  *기울임* 또는 _기울임_
  **굵게** 또는 __굵게__

목록 (Lists): 순서가 있는 목록และ 없는 목록을 만듭니다.

  1. 첫 번째
  2. 두 번째

  * 순서 없는 목록
  - 대시도 가능합니다

구분선 (Horizontal Rule): 하이픈 세 개(---) 혹은 별표 세 개(***)를 연속으로 입력하면 글의 섹션을 나누는 깔끔한 가로줄(구분선)이 생성됩니다.
```
  ---
```

링크 & 이미지 (Links & Images): URL과 이미지를 삽입합니다.

  [구글 링크](https://google.com)
  ![이미지 설명](이미지_경로.png)

인용구 (Blockquotes): > 기호를 사용합니다.
```
  > 이것은 인용문입니다.
```

2. GitHub 확장 문법 (GFM: GitHub Flavored Markdown)

개발자들의 성지인 GitHub에서 코드와 협업 관리를 편리하게 하기 위해 확장한 문법입니다.

코드 블록 (Code Blocks) & 언어 강조: 백틱( ` ) 3개로 코드를 감싸고 언어 이름을 적으면 문법 하이라이팅이 적용됩니다.
```
  ```java
  public class HelloWorld {
      public static void main(String[] args) {
          System.out.println("Hello, World!");
      }
  }
```
```
체크박스 / 작업 목록 (Task Lists): 대괄호 안에 공백이나 x를 넣어 만듭니다.
```
  - [ ] 해야 할 일
  - [x] 완료된 일
```
취소선 (Strikethrough): 물결표( ~ ) 2개로 텍스트를 감싸줍니다.
```
  ~~이 내용은 취소되었습니다.~~
```

표 (Tables): 파이프( | )와 대시( - )를 이용해 깔끔한 표를 그립니다.

  | 제목 | 내용 | 비고 |
  | :--- | :---: | ---: |
  | 왼쪽 정렬 | 중앙 정렬 | 오른쪽 정렬 |

3. 옵시디안 확장 문법 (Obsidian Markdown)

두번째 뇌로 불리는 지식 관리 도구, 옵시디안(Obsidian)에서 주로 쓰이는 강력한 연결 문법입니다.

위키 링크 / 내부 문서 연결 (Wiki Links): 대괄호 2개 [[ ]]를 사용해 노트와 노트를 번개처럼 연결합니다.

  [[마크다운 편집기 사용법]] -> 해당 이름의 내부 노트로 링크 생성
  [[마크다운 편집기 사용법|여기]] -> '여기'라는 이름으로 별칭 링크 생성

텍스트 하이라이트 (Highlight): 등호( = ) 2개로 형광펜 효과를 줍니다.
```
  ==이 부분은 중요해서 형광펜을 칠합니다.==
```
태그 (Tags): # 뒤에 띄어쓰기 없이 단어를 적어 분류 태그를 만듭니다. (일반 제목 문법과 달리 본문 중간에 배치)
```
  #마크다운 #블로그분석 #옵시디안
```

각주 (Footnotes): 본문 중간에 보충 설명 링크를 달고 하단에 내용을 적습니다.

  이 문장 뒤에 추가 설명이 필요합니다[^1].

  [^1]: 여기에 각주 내용을 작성합니다.

4. 내 블로그 참고글 목록

그동안 제가 블로그에 차곡차곡 정리해 두었던 마크다운의 역사, 개념, 편집기 추천 및 활용 플랫폼에 관한 연재 글입니다. 함께 읽어보시면 마크다운을 마스터하는 데 큰 도움이 됩니다!

[가야태자의 맥북 사용기] 맥북에 팀뷰어 설치하기

가야태자 — Mon, 13 Jul 2026 09:26:13 +0900

안녕하세요 가야태자 @talkit 입니다.

오늘에야 맥오에스 카테고리를 블로그에 만들었습니다. ^^

오늘은 원격에서 출장가서 일할일이 있어서 팀뷰어를 설치 해보겠습니다.

https://www.teamviewer.com/ko/download/macos/

위 사이트에서 맥용으로 다운 받으시면 됩니다.

저는 맥용이고 필요하시면 다른 OS 용 윈도우/리눅스 용도 있으니 다운 받으시면 됩니다.

지난번에 한 것 처럼 다운로드 클릭하고 teamviewer.dmg 파일을 클릭 하시면 됩니다.

이경우는 처음 보네요.

여튼 크릭하고 더블 클릭 했습니다.

그랬더니 위와 같이 인터넷 경고가 뜹니다. ^^

열기를 클릭 해주겠습니다.

위와 같이 뜨면 체크하시고 계속 누르시면 됩니다.

이제 패키지 타입의 인스톨러와 동일한 화면이 뜨네요.

처음부터 pkg 타입으로 제공 했으면 앞에 과정은 필요 없을텐데 ㅠ.ㅠ

아무래도 용량을 줄이려고 한 것 같습니다.

저는 맥북을 제어 할께 아니어서 필요한 켜는걸로 하고 Start로 시작하는 아이는 그대로 두었습니다.

계속 누르시면 됩니다.

설치에 어느정도 공간이 필요한지 이야기 해주네요.

설치 버튼 누르시면 됩니다.

암호를 넣으시거나 지문을 인식하시면 됩니다.

설치가 완료 되었습니다.

닫기 누르시면 설치 파일을 휴지통으로 보낼까요가 나오는데 저는 보내는 편입니다.

지원을 받으실 경우 제가 파란색 네모로 가려 놓은 것을 지원하시는 쪽에 불러 드리면 됩니다.

설치는 여기까지 하고 마치겠습니다.

감사합니다.

[원론 이야기] 왜 모든 개발 언어는 "Hello, World!"부터 시작할까? (환경 구축과 예제 포함)

가야태자 — Fri, 10 Jul 2026 09:48:57 +0900

[원론 이야기] 왜 모든 개발 언어는 "Hello, World!"부터 시작할까? (환경 구축과 예제 포함)

안녕하세요, 가야태자 @talkit 입니다.

오늘은 실습보다는 다시 원론적인 이야기를 조금 해보려고 합니다.

새로운 프로그래밍 언어를 배울 때, 우리가 가장 먼저 화면에 띄우는 문장은 백이면 백 모두 "Hello, World!"입니다. 문득 '왜 개발 언어에서는 이걸 제일 처음에 가르칠까?'라는 의문이 들었습니다.

단순히 오래된 전통이라서, 혹은 귀여운 인사말이라서 따라 하는 걸까요? 제 생각과 AI의 생각을 같이 정리해 보니, 여기에는 개발 환경을 구축하는 과정에서 가장 핵심적인 '엔지니어링적 이유'가 숨어 있었습니다.

이번 글에서는 그 이유와 함께, 끝부분에 간단한 개발 환경 구축 방법과 주요 언어의 Hello World 예제도 만들어 두었으니 참고 부탁드립니다.

1. "Hello, World!"에 숨겨진 진짜 이유

생각해 보면 "Hello, World!"를 출력하는 것은 단순히 글자 몇 개를 화면에 보여주는 일이 아닙니다. 이 짧은 한 줄이 성공적으로 실행되었다는 것은, 내 컴퓨터 안에서 다음과 같은 복잡한 과정이 완벽하게 작동했다는 방증입니다.

컴파일러/인터프리터 설치: 언어를 해석하는 엔진이 컴퓨터에 올바르게 깔렸는가?
환경 변수(PATH) 설정: 터미널이나 IDE가 해당 언어의 실행 파일 위치를 정확히 인식하고 있는가?
구문 분석(Syntax Parsing): 가장 기본적인 문법 구조를 도구가 이해하고 있는가?
출력 스트림(I/O) 연결: 프로그램이 OS의 표준 출력 시스템과 제대로 상호작용하고 있는가?

즉, "내 컴퓨터에 이 언어를 위한 기초적인 개발 환경이 완벽하게 세팅되었다"라는 것을 검증하는 가장 완벽하고 최소한의 단위 테스트(Minimum Viable Test)인 셈입니다.

만약 첫 시간부터 복잡한 알고리즘 코드를 짰다가 에러가 나면, 우리는 '문법이 틀린 건지', '논리가 틀린 건지', '애초에 설치가 잘못된 건지' 원인을 찾기 힘듭니다. 하지만 문법이 틀릴 리 없는 "Hello, World!"에서 에러가 난다면 100% '개발 환경 세팅의 문제'로 원인을 좁힐 수 있습니다. 복잡한 변수를 제거하고, 오직 '환경 구축'이라는 첫 번째 관문에만 집중할 수 있도록 도와주는 마법 같은 코드인 것이죠.

2. 주요 언어별 환경 구축 및 예제 살펴보기

언어마다 개발 환경을 만들고 실행하는 방식(컴파일 vs 인터프리터)이 조금씩 다릅니다. 대표적인 4가지 언어의 핵심 요약을 정리해 두었으니 참고해 보세요.

① C 언어 (컴파일러 방식)

C 언어는 기계어로 직접 변환되는 컴파일 언어입니다. 코드를 작성한 후 실행 파일을 만드는 변환 과정이 필요합니다.

환경 구축 핵심: * Windows: GCC 컴파일러(MinGW) 설치 및 시스템 환경 변수(PATH) 등록
- macOS: 터미널에서 xcode-select --install 명령어로 Command Line Tools 설치

Hello, World! 코드:

  #include <stdio.h>

  int main() {
      printf("Hello, C World!\n");
      return 0;
  }

실행 방법: 터미널에서 gcc main.c -o main으로 빌드 후, ./main으로 실행

② Java (가상 머신 방식)

Java는 OS에 종속되지 않고 JVM(자바 가상 머신) 위에서 돌아갑니다.

환경 구축 핵심: * JDK(Java Development Kit) 설치 (OpenJDK 등)
- 시스템 환경 변수에 JAVA_HOME 등록 및 PATH에 bin 디렉토리 추가

Hello, World! 코드:

  public class Main {
      public static void main(String[] args) {
          System.out.println("Hello, Java World!");
      }
  }

실행 방법: 터미널에서 javac Main.java로 컴파일 후 java Main으로 실행

③ Python (인터프리터 방식)

파이썬은 컴파일 없이 코드를 한 줄씩 읽어가며 바로 실행하는 대표적인 언어입니다.

환경 구축 핵심: * Python 공식 홈페이지에서 인스톨러 다운로드 및 설치
- [중요] 설치 화면에서 "Add python.exe to PATH" 체크박스 반드시 선택
Hello, World! 코드:
```
  print("Hello, Python World!")
```
실행 방법: 터미널에서 python main.py 입력 시 즉시 실행

④ Node.js (JavaScript 런타임)

웹 브라우저 밖(로컬 컴퓨터)에서 자바스크립트를 실행할 수 있게 해주는 환경입니다.

환경 구축 핵심: * Node.js 공식 홈페이지에서 LTS(안정화) 버전 설치
- 설치 시 node 환경 변수와 패키지 매니저인 npm이 자동으로 함께 세팅됨
Hello, World! 코드:
```
  console.log("Hello, Node.js World!");
```
실행 방법: 터미널에서 node app.js 입력 시 즉시 실행

글을 마치며

언어별 예제를 보면 아시겠지만, 파이썬이나 Node.js는 단 한 줄이면 끝나는 반면, C나 Java는 무언가 감싸고 있는 뼈대(구조)가 많습니다. "Hello, World!"를 직접 실행해 보면 '아, 이 언어는 기본적으로 이런 구조를 갖추고 시작해야 하는구나'라는 언어별 스타일을 첫눈에 파악할 수 있다는 장점도 있습니다.

"Hello, World!"는 단순한 인사가 아니라, 새로운 언어의 세계로 들어가기 전 컴퓨터와 개발자가 나누는 첫 번째 악수와 같습니다. 화면에 이 문구가 무사히 떴다면, 여러분은 이미 가장 어렵고 중요한 첫 번째 베이스캠프인 '환경 구축'을 정복하신 겁니다.

오늘도 즐거운 개발 되시기 바랍니다. 감사합니다!

[가야태자의 Spring Boot 교실] 레거시 Spring MVC vs Spring Boot, 그리고 클라우드 이야기

가야태자 — Thu, 9 Jul 2026 09:28:13 +0900

안녕하세요! 가야태자 @talkit 입니다.

지난 글까지 우리는 MacOS 환경에서 우여곡절 끝에 Java 1.8 엔진을 얹고, STS4 설치에 이어 감격의 스프링 부트(Spring Boot) Hello World 웹 서버를 구동하는 데 성공했습니다! 매번 익숙한 윈도우 환경에서만 개발 설정을 하다가, 맥북 터미널을 두들기며 실습해 보니 사소한 에러를 잡는 것도 아주 색다르고 재미있네요. ^^

단순히 화면에 글자 하나를 띄우는 HelloWorld 단계를 넘어서니, 이제 실무에서 사용하는 진짜 비즈니스 로직(데이터베이스 연동, 아키텍처 설계 등)을 추가하고 싶어지더군요. 그래서 본격적인 코드 작성에 앞서, 머릿속을 맴돌던 몇 가지 근본적인 궁금증들을 정리해 보았습니다.

전통적인 Spring MVC와 순수 Spring Boot 설정은 구체적으로 무엇이 다른가? (그 많던 XML들은 다 어디로 갔나?)
사람들은 왜 유독 Spring Boot를 두고 '클라우드 친화적(Cloud-Friendly)'이라고 부르는가?
그렇다면 기존 Spring MVC는 도커(Docker)나 쿠버네티스(Kubernetes) 같은 현대적인 클라우드 환경으로 전환이 불가능한가?

오늘은 본격적인 아키텍처 설계에 들어가기 전, 이 궁금증들을 아주 명쾌하고 쉽게 풀어보는 시간을 가져보겠습니다!

1. Spring MVC vs Spring Boot 설정의 차이: "설정 지옥의 해방"

전통적인 Spring MVC(예: 전자정부프레임워크 등)로 비즈니스 프로젝트를 시작하려면, 코드를 짜기도 전에 엄청난 양의 환경 설정에 지치곤 했습니다.

applicationContext.xml, spring-mvc.xml, context-datasource.xml 등 거대하고 복잡한 XML 파일들을 매번 복사해 와서 데이터베이스 커넥션 풀(DBCP)을 셋팅하고, 컴포넌트 스캔 범위를 지정해야 했죠. 오타라도 하나 나면 컴파일 시점엔 알 수도 없고 런타임 에러를 뿜어내기 일쑤였습니다.

하지만 Spring Boot는 이 패러다임을 완전히 바꿨습니다. 부트에는 스프링 관련 설정을 위한 XML 파일이 단 하나도 필요 없습니다!

스프링 부트는 "설정보다는 관례(Convention over Configuration)"를 내세웁니다.

자동 설정(Auto Configuration): spring-boot-starter-web 라이브러리를 추가하는 순간, 부트가 내부적으로 "아, 이 개발자가 웹 서버를 만드는구나!" 하고 내장 톰캣 서버, JSON 변환기, 문자 필터 등을 알아서 자바 코드로 셋팅해 줍니다.
프로퍼티 중심 제어: 과거 복잡했던 데이터소스(DB 접속) 설정은 이제 application.properties 파일에 딱 세 줄, 드라이버 이름과 URL, 계정 정보만 적어주면 끝납니다.
개발자는 인프라 설정에 힘을 뺄 필요 없이 오직 비즈니스 로직(Controller - Service - DTO - Mapper)에만 100% 집중할 수 있게 된 것이죠.

2. Spring Boot는 왜 '클라우드 친화적'일까?

최근 실무 백엔드 인프라의 대세는 AWS 같은 클라우드 환경입니다. 그리고 클라우드 세상에서 스프링 부트는 독보적인 위치를 차지하고 있습니다. 왜 그럴까요?

① 내장 WAS를 품은 '독립 실행형 JAR' (이식성)

레거시 Spring MVC는 빌드하면 WAR 파일이 나옵니다. 이 파일은 혼자서 실행할 수 없고, 클라우드 서버마다 외부 웹 서버(Tomcat)를 따로 설치하고 설정을 맞춘 뒤에 그 안에 '주입(Deploy)'해야 구동됩니다.
반면, Spring Boot는 웹 서버(Tomcat)를 자바 패키지 내부에 아예 내장하고 있습니다. 빌드하면 웹 서버가 포함된 단 하나의 JAR 파일이 툭 떨어집니다. 클라우드 서버에 자바만 깔려 있다면 java -jar app.jar 명령어 한 줄로 즉시 어디서든 똑같이 구동됩니다. 인프라 의존성이 사라진 것입니다.

② 압도적인 구동 속도와 가벼움 (오토스케일링 최적화)

클라우드의 핵심은 사용자가 몰릴 때 서버를 순식간에 수십 대로 늘리는 오토스케일링(Auto Scaling)입니다. 레거시 시스템은 톰캣을 켜고 WAR 압축을 풀고 비대한 XML을 읽느라 서버가 준비되는 데 수십 초에서 수분이 걸렸습니다.
하지만 스프링 부트는 불필요한 인프라 구조를 걷어내고 자바 코드로 즉시 기동하므로 구동 속도가 극도로 빠릅니다. 클라우드가 명령하는 즉시 트래픽을 받아낼 준비를 마칩니다.

③ 모니터링 기능(Actuator) 기본 내장

수많은 서버가 분산되어 있는 클라우드 환경에서는 서버 상태 감시가 필수입니다. 스프링 부트는 Actuator 라이브러리를 통해 현재 서버의 메모리 상태, DB 커넥션 풀 상태 등을 확인할 수 있는 모니터링 창구를 코딩 한 줄 없이 기본으로 제공해 줍니다.

3. 그럼 Spring MVC는 도커나 쿠버네티스를 사용하지 못하나요?

결론부터 말씀드리면, 당연히 사용할 수 있습니다! 꼭 스프링 부트만 써야 도커/쿠버네티스를 쓸 수 있는 것은 아닙니다.

도커(Docker)와 쿠버네티스(Kubernetes) 입장에서는 컨테이너 안에 담긴 프로그램이 옛날 스프링인지 최신 스프링 부트인지 상관하지 않습니다. 표준 규격만 맞추면 어떤 프로그램이든 다 담아서 굴려줍니다. 실제로 수많은 기업들이 기존에 운영하던 거대한 레거시 Spring MVC 시스템을 그대로 도커 이미지로 패키징하여 쿠버네티스 환경으로 이주(Migration)시켜 운영하고 있습니다.

다만, 장점을 활용하는 효율성의 차이가 존재합니다.

Spring MVC를 도커에 올릴 때: 도커 이미지 안에 우분투 OS를 깔고, 외부 톰캣 서버를 설치하는 스크립트를 짜고, 거기에 WAR 파일을 복사해 넣어야 하므로 도커파일(Dockerfile)이 복잡해지고 이미지의 크기가 무거워집니다. 쿠버네티스가 컨테이너를 복제하거나 자가 치유(Heal)를 할 때도 구동 속도가 느려 굼뜨게 반응합니다.
Spring Boot를 도커에 올릴 때: 순수한 자바 환경 이미지에 JAR 파일 하나만 복사해 넣으면 끝납니다. 이미지 크기가 매우 가볍고, 쿠버네티스의 헬스 체크(Liveness/Readiness Probe)와 부트의 Actuator 기능이 찰떡처럼 연동되어 시스템 자가 치유 능력이 극대화됩니다.

즉, "도커와 쿠버네티스는 Spring MVC라는 옛날 자동차도 트레일러에 실어서 얼마든지 움직여줄 수 있다. 다만, 처음부터 컨테이너 비행기에 쏙 들어가도록 규격화되어 설계된 Spring Boot를 태웠을 때 훨씬 더 가볍고 안전하게 날아갈 수 있다"고 이해하시면 좋습니다!

가야태자의 요약 및 예고

결과적으로, 기존의 복잡한 인프라 환경을 다루어보신 분들이라면 스프링 부트가 제공하는 이 간결함과 클라우드 네이티브(Cloud Native)적인 특성에 감탄할 수밖에 없습니다. 과거의 자동차 조립 단계 같은 설정을 뒤에서 부트가 다 알아서 해주니까요.

궁금증이 시원하게 해결되었으니, 다음 글에서는 진짜 실무 아키텍처의 뼈대를 세워보겠습니다!
우리가 설치한 자바 1.8 환경에 딱 맞춰서 Controller - Service - DTO - Mapper - MyBatis - DB까지 이어지는 표준 5계층 아키텍처의 패키지를 쪼개고 실제 소스 코드를 채워 컴파일하는 실전 과정으로 찾아오겠습니다.

환경 설정을 진행하시면서 궁금한 점이나 의견이 있으시면 언제든 댓글로 편하게 소통해 주세요. 감사합니다! bananas

[가야태자의 SpringBoot 실습] SpringTools(STS)로 SpringBoot Hello World 만들기

가야태자 — Wed, 8 Jul 2026 09:25:00 +0900

안녕하세요 가야태자 @talkit 입니다.

Spring Boot 시작 방법
https://www.steemit.com/kr/@talkit/spring-boot-java-18-sts-4-helloworld--f7k0ki

위글의 실습으로

Java 1.8 설치
https://www.steemit.com/kr/@talkit/springboot-macos-openjdk-18--z3k1wk

SpringTools(STS)
https://www.steemit.com/kr/@talkit/springboot-macos-spring-toolssts--9kq2xf

자바 설치하고, STS를 설치를 진행 해서 제 맥북에는 두가지 프로그램이 잘 설치 되어 있는 상태 입니다.

이제 본격적으로 SpringBoot Hello World를 만들어 보겠습니다.

저는 주소 Spring MVC 방식으로 프로젝트를 많이 해서 SpringBoot는 주변을 서치하면서 진행하고 있습니다.

스프링부트 전체 흐름 글에서는 일단 파일을 만들고, 파일을 Import 하는 방식으로 진행을 하라고

제미나이가 이야기 해주었습니다.

그래서 우선 그렇게 진행 해보겠습니다.

지난번 글에서 저하고 동일한 STS를 설치하셨다면,

조금 메뉴가 다른 것 같습니다. 아니면 MacOS라서 다를수도 있을 것 같습니다

JDK를 설정 해주어야 합니다.

Window > Preferences > Java

로 되어 있는데

맥에서는 Spring Tools for Eclipse 프로그램 메뉴를 클릭하시고

Settings를 클릭하신 다음에

Java >> Installed JREs 에 접근하면 위와 같이

JDK가 21도 있고, 1.8.0도 있습니다.

이중에 저희는 1.8을 선택 합니다.

그리고, Apply and Close 버튼을 클릭해 주시면 됩니다.

그러면 일단 JDK는 Java 1.8을 사용하는 것으로 변경 되었습니다.

스프링 부트를 돌릴 서버를 설정 하기 위해서

해당 메뉴로 다시 접근 해서

Server > Runtime Environments > Add

를 클릭해서 Apache Tomcat 8.5 또는 9.0을 선택 합니다.

저는 앞에 글에서 선택한대로 8.5를 선택 하겠습니다.

Download and Install ...

을 클릭하십시오.

GPL 동의 하시고 Finish 누르시면 됩니다.

설치할 폴더를 선택해달라고 합니다.

저는 계정 폴더내에 dev로 하겠습니다.

/Users/kjh0523/dev/apache-tomcat-8.5.99

없으면 폴더는 만드시면 되고 위와 비슷하게 설치가 됩니다.

조금 기다리시면, Finish가 활성화 됩니다.

Finish를 누르시면 됩니다.

Apply and Close 누르십시오.

일단 톰켓 서버 설치까지 끝났습니다.

https://start.spring.io/

위 사이트에 접속 합니다.

사이트에 적당하게 적습니다.

도메인을 가지고 계시면 해당 도메인을 꺼꾸로 하시면 됩니다. ^^

저는 티스토리 도메인으로 했습니다.

그리고 아티펙트는 프로젝트 명이어서 적당하게 영어로 만들어 줍니다.

나중에 Jar나 War파일명이 되므로 적당한 명칭을 하면 됩니다.

저는 이번에 HelloWorld여서 HelloWolrd로 했습니다.

그리고 저희는 2.7x를 사용할 예정이어서 일단 3.5를 선택 합니다.

현재 상태로요 ^^

그리고 Jar나 War는 설정으로 변경할 수 있어서 일단 Jar로 했습니다.

저는 Maven이 편해서 Maven으로 했습니다.

그리고 자바는 어쩔수 없이 17로 했습니다.

사이트에서 제일 낮은 버전이 17이어서요.

그리고 하단의 GENERATE 버튼을 클릭하시면 파일이 하나 다운로드 됩니다.

해당 파일을 임포트 해보도록 하겠습니다.

File >> Import 를 선택 합니다.

Project from Folder or Archive 를 선택 하시고

Next를 클릭 합니다.

압축 파일로 다운로드 되어서 Archive를 선택 합니다.

아까 다운로드 받은 zip파일을 선택 합니다.

Finish를 클릭하십시오.

그러면, 메이븐이 여러가지 일들을 해줍니다.

왼쪽의 Project Explore 에서 pom.xml을 찾습니다.

저희는 아까 말씀 드린대로,

JDK 1.8

SpringBoot는 2.7.x를 사용합니다.

그래서 수정 해주어야 합니다.

수정하고 저장하면 2.7.18로 잘 변경 됩니다.

그런데 몇몇 오류가 발생하는데

우선 Spring Tools for Eclipse >> XML

Download external resources like referenced DTD, XSD에 체크합니다. 저는 체크가 되어 있지만 처음에는 체크가 풀려 있습니다.

그리고, Apply and Close

그러면 Pom.xml은 정상적으로 돌아왔을 겁니다.

워닝이 조금 있기는 하겠지만 무시 합니다. ^^

그리고 이제 웹 화면을 보기 위해서 pom.xml과 Java 소스를 약간 수정하고 추가해 보겠습니다.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.18</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.tistory.talkit</groupId>
    <artifactId>HelloWorldProject</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name/>
    <description/>
    <url/>
    <licenses>
        <license/>
    </licenses>
    <developers>
        <developer/>
    </developers>
    <scm>
        <connection/>
        <developerConnection/>
        <tag/>
        <url/>
    </scm>
    <properties>
        <java.version>8</java.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

pom.xml을 위와 같이수정 합니다.
spring-boot-starter => spring-boot-starter-web

starter 가 -web으로 되어 있어야 합니다.

그리고 이제 접속하면 브라우저에 HelloWorld가 보이도록 하기 위해서 Java 파일을 하나 만듭니다.

/HelloWorldProject/src/main/java/com/tistory/talkit/HelloWorldProject/HelloWorldController.java

프로젝트내에 위와 같이 작성하시면 됩니다.

package com.tistory.talkit.HelloWorldProject;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

//   [핵심 수정] 이 클래스가 웹 컨트롤러임을 스프링에게 알려주는 스위치입니다!
@RestController
public class HelloWorldController {

    // [핵심] 사용자가 웹 브라우저에서 "/" (기본 경로)로 접속하면 이 메서드를 연결합니다.
    @GetMapping("/")
    public String helloBanana() {
        return "  가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7!  ";
    }

}

위와 같이 생성 합니다.

저기 글자는 여러분들이 원하는 글자로 변경 하시면 됩니다.

그리고, HelloWorldProject 프로젝트 명 누르고 오른쪽 마우스로 Run As >> SpringBoot App

하시면 스프링 부트 프로그램이 시작 합니다.

이때 오류나면 댓글 주세요.

도와 드리겠습니다.

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 [32m :: Spring Boot ::  [39m              [2m (v2.7.18) [0;39m

 [2m2026-07-04 12:43:34.846 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mc.t.t.H.HelloWorldProjectApplication     [0;39m  [2m: [0;39m Starting HelloWorldProjectApplication using Java 1.8.0_492 on kjh0523ui-MacBookPro.local with PID 10718 (/Users/kjh0523/Documents/workspace-spring-tools-for-eclipse-4.32.2.RELEASE/HelloWorldProject.zip_expanded/HelloWorldProject/target/classes started by kjh0523 in /Users/kjh0523/Documents/workspace-spring-tools-for-eclipse-4.32.2.RELEASE/HelloWorldProject.zip_expanded/HelloWorldProject)
 [2m2026-07-04 12:43:34.847 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mc.t.t.H.HelloWorldProjectApplication     [0;39m  [2m: [0;39m No active profile set, falling back to 1 default profile: "default"
 [2m2026-07-04 12:43:35.434 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mo.s.b.w.embedded.tomcat.TomcatWebServer  [0;39m  [2m: [0;39m Tomcat initialized with port(s): 8080 (http)
 [2m2026-07-04 12:43:35.439 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mo.apache.catalina.core.StandardService   [0;39m  [2m: [0;39m Starting service [Tomcat]
 [2m2026-07-04 12:43:35.439 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36morg.apache.catalina.core.StandardEngine  [0;39m  [2m: [0;39m Starting Servlet engine: [Apache Tomcat/9.0.83]
 [2m2026-07-04 12:43:35.506 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mo.a.c.c.C.[Tomcat].[localhost].[/]       [0;39m  [2m: [0;39m Initializing Spring embedded WebApplicationContext
 [2m2026-07-04 12:43:35.506 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mw.s.c.ServletWebServerApplicationContext [0;39m  [2m: [0;39m Root WebApplicationContext: initialization completed in 629 ms
 [2m2026-07-04 12:43:35.767 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mo.s.b.w.embedded.tomcat.TomcatWebServer  [0;39m  [2m: [0;39m Tomcat started on port(s): 8080 (http) with context path ''
 [2m2026-07-04 12:43:35.775 [0;39m  [32m INFO [0;39m  [35m10718 [0;39m  [2m--- [0;39m  [2m[           main] [0;39m  [36mc.t.t.H.HelloWorldProjectApplication     [0;39m  [2m: [0;39m Started HelloWorldProjectApplication in 1.187 seconds (JVM running for 1.557)

위와 같이 되어 있으면 이제 접속이 가능하다는 소리 입니다.

저희는 / 만 만들어두었기 때문에 ^^

http://localhost:8080 으로 접근 하시면 됩니다.

  가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7!

기능적으로 아무것도 없이 해당 메시지를 출력하는 프로그램이지만,

일단 스프링 부트의 기초를 느낄 수있는 프로젝트입니다.

이번에는 여기까지 진행 합니다.

다음에는 디비도 붙여 보고 여러가지 작업을 진행 해보겠습니다.

감사합니다.

[가야태자의 SpringBoot 실습] MacOS에 Spring Tools(STS) 설치하기

가야태자 — Tue, 7 Jul 2026 09:59:24 +0900

안녕하세요 가야태자 @talkit 입니다.

Spring Boot 시작 방법
https://www.steemit.com/kr/@talkit/spring-boot-java-18-sts-4-helloworld--f7k0ki

위글의 실습으로

Java 1.8 설치
https://www.steemit.com/kr/@talkit/springboot-macos-openjdk-18--z3k1wk

어제 글에 이어서

Spring Tools를 설치하려고 합니다.

Spring Tools는

이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 본격적으로 개발 환경을 꾸려볼까 합니다. 이때 사용할 수 있는 개발 환경(IDE)이 여러가지가 있는데, 오늘부터는 무료이면서도 강력한 스프링 공식 지원 도구인 STS(Spring Tools 4)를 활용하여 환경을 구성하는 이야기를 해보고자 합니다.

지난번 제글에서 인용하면 위와 같습니다.

즉 통합 개발 환경입니다.

메모장 + JDK + Maven 등을 이용해서 단순하게 진행할수도 있겠지만 저렇게 진행하면 ^^

개발자가 해야할일이 너무 많습니다.

그래서 개발자들을 편안하게 해주는 IDE중에서 오늘은 Spring Tools(STS)를 설치해보겠습니다.

우선 첫번째 문서의 공식 사이트에서는 STS의 최신 버전만 받을 수 있네요.

https://spring.io/tools

사이트는 위와 같이 되어 있습니다. 최신 버전을 다운 받을 때는 위 프로그램을 다운로드 하시면 됩니다.

저기서 최신 맥이시면 MacOS ARM 64 버튼을 클릭히시면 됩니다.

하지만, 저희는 java 1.8에 대응하는 STS4를 다운로드해야 합니다.

보통은 친절하게 기록물 저장소(archive)를 친절하게 표시해 두는데 여기는 최신 버전만 쓰라고 없네요.

https://github.com/spring-projects/spring-tools/wiki/Previous-Versions

위 사이트에서 과거 버전을 찾을 수 있습니다.

대충 위와 같이 생겼습니다.

일단 배포된 버전중에 가장 최신 버전을 받으시면 됩니다.

인텔 맥이신 분들은 x86_64를 최신 맥이신 분들은 aarch64로 끝나는 dmg 파일을 받으시면 됩니다 .

저는 최신 맥이라서 aarch64를 받아 보겠습니다.

용량이 약 700메가 정도 됩니다.

어제 처럼 다운로드 위치에 있는 dmg 파일을 더블 클릭 합니다.

어제와는 조금 다르게 나옵니다.

pkg는 윈도우의 msi와 비슷하다고 생각하시면 되고,

오늘은 왼쪽에 있는 SpringToolsForEclipse를 Applications 폴더로 끌어다 놓으시면 됩니다.

dmg가 압축 포맷이어서 가져다 놓으면서 압축을 풀고 설치가 됩니다.

dmg로 설치한 경우 삭제는 Finder에서 응용프로그램(또는 Applications)에가서 해당 프로그램을 지워버리시면 모두 지워집니다.

끌어다 놓고 조금 있으면 뭔가 살짝 지나가고 끝입니다.

Finder(맥용 탐색기)를 켜고 응용프로그램으로 가셔서 SpringToolsForEclipse 를 찾아서 더블클릭 하시면 됩니다.

위와 같이 보이면 더블 클릭 하시면 됩니다.

인터넷에서 다운로드 한 앱이라고 경고가 뜹니다.

그러면 열기를 클릭하시면 됩니다. ^^

매번 윈도우 매뉴얼만 쓰다가 Mac용 매뉴얼 쓰니까 좋네요 ^^

일단 이번 글에서는 설치만 할꺼라서 Launch를 클릭하시면 됩니다.

다음에는 저기 있는 workspace 폴더를 변경할 껍니다. 이번에는 저대로 진행 하겠습니다.

저건 허용 안함으로 해도 될 것 같은데 저는 일반적으로 허용 합니다.

다음에 또 경고창이 하나 더 뜨네요 문서 폴더에 접근할 수 있게 해달라고 저건 허용 하셔야 합니다.

음 위와 같이 나오시면 잘 설치가 된겁니다.

이번 글에서는 여기까지만 하고 다음글에서 컴파일러 설정, Hello World 작성등을 이어서 진행 하겠습니다.

감사합니다.

[가야태자의 SpringBoot 실습] MacOS에 OpenJDK 1.8 설치하기

가야태자 — Mon, 6 Jul 2026 09:01:20 +0900

안녕하세요 가야태자 @talkit 입니다.

https://www.steemit.com/kr/@talkit/spring-boot-java-18-sts-4-helloworld--f7k0ki

오늘은 어제글의 실습 버전입니다.

저네 과정은 위 글에서 일단 개요를 적어 두었습니다.

Java 1.8을 MacOS에 설치 해보겠습니다.

일단 보안 패치가 길게 가고 있는 이클립스 재단에서 운영하는 OpenJDK를 설치 하겠습니다.

어제 글에 있는대로

https://adoptium.net/temurin/releases/?version=8

위 사이트에 접속 합니다.

각 OS 별로 개발 환경이 존재 합니다.

그러면 MacOS용을 다운로드 받겠습니다.

확장자는 pkg 파일로 되어 있습니다.

맥오른쪽 하단에 파란색 다운로드 폴더가 보이면 그걸 클릭하면 여러가지 다운로드 파일이 보입니다.

저걸 실행 하겠습니다.

아이콘이나 파일명을 더블 클릭하시면 열립니다.

JDK를 맥에서 설치 해보는 것은 처음이라서 기대되네요.

약관을 보여주고 약관에 동의 할꺼냐고 묻습니다. 저거 동의 안하면 설치가 안되니까 동의 하겠습니다. ^^

설치 버튼을 누릅니다.

암호나 터치아이디를 누르라고 해서 저는 지문인식으로 처리 했습니다.

그러면 이제 설치를 시작 합니다.

엥 중간에 설치 과정좀 캡처 하려고 했더니 이미 설치가 다 되어 버렸네요.

이제 닫기를 누르시면 설치는 다 된 상태 입니다.

설치가 잘 되었는지 확인하기 위해서 터미널을 열겠습니다.

(base) kjh0523@kjh0523ui-MacBookPro ~ % ls -al $(/usr/libexec/java_home -v 1.8) 
total 103312
drwxr-xr-x  15 root  wheel       480  4월 26 21:04 .
drwxr-xr-x   6 root  wheel       192  4월 26 21:04 ..
-r--r--r--   1 root  wheel      1522  4월 26 21:04 ASSEMBLY_EXCEPTION
drwxr-xr-x  45 root  wheel      1440  4월 26 21:04 bin
drwxr-xr-x   3 root  wheel        96  4월 26 21:04 bundle
drwxr-xr-x   9 root  wheel       288  4월 26 21:04 include
drwxr-xr-x   7 root  wheel       224  4월 26 21:04 jre
drwxr-xr-x   9 root  wheel       288  4월 26 21:04 lib
-r--r--r--   1 root  wheel     19274  4월 26 21:04 LICENSE
drwxr-xr-x   5 root  wheel       160  4월 26 21:04 man
-rw-r--r--   1 root  wheel      2400  4월 26 21:04 NOTICE
-rw-r--r--   1 root  wheel       480  4월 26 21:04 release
drwxr-xr-x  12 root  wheel       384  4월 26 21:04 sample
-rw-r--r--   1 root  wheel  52669599  4월 26 21:04 src.zip
-r--r--r--   1 root  wheel    191545  4월 26 21:04 THIRD_PARTY_README
(base) kjh0523@kjh0523ui-MacBookPro ~ % date
2026년  7월  3일 금요일 22시 42분 43초 KST
(base) kjh0523@kjh0523ui-MacBookPro ~ % $(/usr/libexec/java_home -v 1.8)/bin/java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)
(base) kjh0523@kjh0523ui-MacBookPro ~ % java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)
(base) kjh0523@kjh0523ui-MacBookPro ~ %

기존에 자바가 있는 것인지 일단 자바의 버전은 1.8로 확인되었습니다.

패키지의 날짜 때문인지 왜 4월 26일에 설치 된걸로 나오죠?

오늘 설치 했는데 말이죠.

그래도 패스는 지정 해야해서.

패스와 JAVA_HOME을 지정해 보겠습니다.


vi ~/.zshrc

# 파일이 열리면 맨 아래로 이동해서 i 키를 클리하고 

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
export PATH=$JAVA_HOME/bin:$PATH

#  위 두줄을 복사해서 넣습니다. 

# Esc 키를 클릭하고 
:wq 

# 를 입력후 엔터를 칩니다.

 # 위 환경을 적용하기 위해서 source 명령어를 입력 합니다. 

source ~/.zshrc

(base) kjh0523@kjh0523ui-MacBookPro ~ % java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)

위와 같이 아까와 동일하게 패스가 잘 동작 합니다.

이제 개발을 위한 Java 컴파일러가 준비 되었습니다.

내일은 개발 환경을 설치 해보겠습니다.

감사합니다.

[가야태자의 Spring Boot 교실] Java 1.8 & STS 4 개발 환경 완벽 구축부터 HelloWorld 구동까지

가야태자 — Fri, 3 Jul 2026 09:57:03 +0900

[가야태자의 Spring Boot 교실] Java 1.8 & STS 4 개발 환경 완벽 구축부터 HelloWorld 구동까지

안녕하세요! 가야태자 @talkit 입니다.

이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 본격적으로 개발 환경을 꾸려볼까 합니다. 이때 사용할 수 있는 개발 환경(IDE)이 여러가지가 있는데, 오늘부터는 무료이면서도 강력한 스프링 공식 지원 도구인 STS(Spring Tools 4)를 활용하여 환경을 구성하는 이야기를 해보고자 합니다.

"선생님, 지금 Java 21이 나오는 시대에 왜 굳이 Java 1.8인가요?"라고 물으실 수 있습니다. 하지만 실무에 나가보면 수많은 기존 시스템(Legacy)들이 여전히 Java 1.8 위에서 굳건히 돌아가고 있습니다. 이 환경에서 개발 환경을 완벽히 세팅하고, 프로젝트의 뼈대를 잡아 HelloWorld를 띄울 수 있다는 것은 백엔드 개발자로서 아주 강력한 무기가 됩니다.

자, 그럼 내 컴퓨터를 완벽한 스프링 부트 개발 기지로 만드는 환경 설정부터 실전 코드 구동까지 단번에 나아가 봅시다!

오늘은 일단 실습을 위한 준비 정도를 하고 실제 코딩은 주말에 해볼 계획입니다.

실제 코딩을 하면서 본 문서의 잘못된 점이나 코드 등은 바로 잡겠습니다.

1단계: Java 1.8이 품을 수 있는 스프링 부트 버전은?

가장 중요한 첫걸음은 엔진(Java)과 차체(Spring Boot)의 호환성을 맞추는 것입니다.

Java 1.8에서 사용 가능한 마지막 스프링 부트 버전은 2.x 대역입니다. 그중에서도 가장 안정적이고 최신 기능(Java 1.8 기준)을 담고 있는 2.7.x 버전을 선택해야 합니다.

참고 사항: 스프링 부트 3.0부터는 Java 17이 최소 요구 사항입니다. Java 1.8로는 절대로 구동할 수 없습니다. 따라서 과거 레거시 시스템을 다루거나 Java 8 환경을 고수해야 한다면 반드시 2.7.x 대역 버전을 선택해야 합니다.
참조 가이드: 스프링 부트 2.7.x 공식 시스템 요구사항 문서

2단계: OpenJDK 및 통합 개발 환경(IDE) 공식 다운로드

우리의 실제 '엔진'이 될 자바와, 우리의 '작업 공간'이 될 통합 개발 환경(IDE)인 STS 4를 공식 사이트에서 안전하게 다운로드해 줍니다.

도구	다운로드 사이트 (URL)	다운로드 및 설치 방법
OpenJDK 1.8	Adoptium 공식 홈페이지	1. 사이트 접속 후, 본인의 OS(Win/Mac/Linux)와 아키텍처(x64/aarch64 등)에 맞는 JDK 다운로드. 2. 설치 파일(Win: `.msi`, Mac: `.pkg`) 실행 후 안내에 따라 설치.
STS 4 (IDE)	Spring Tools 공식 홈페이지	1. 사이트 접속 후, 본인의 OS에 맞는 Spring Tools 4 for Eclipse 다운로드. 2. 다운로드된 파일(Win/Linux: `.tar.gz`, Mac: `.dmg`)의 압축을 사용하기 편한 폴더에 풉니다.

3단계: OS별 환경 변수 (`JAVA_HOME` & `PATH`) 완벽 설정

엔진(Java)을 컴퓨터에 깔았다면, 시스템이 어디서든 이 엔진을 찾아서 사용할 수 있도록 가리키는 이정표(환경 변수)를 세워야 합니다. 본인의 OS에 맞는 설정을 적용해 보세요.

① WINDOWS (윈도우)

시작 버튼 우클릭 -> 시스템 -> 고급 시스템 설정 -> 환경 변수를 클릭합니다.
시스템 변수에서 새로 만들기 클릭:
- 변수 이름: JAVA_HOME
- 변수 값: JDK 1.8이 설치된 폴더 경로 (예: C:\Program Files\Eclipse Adoptium\jdk-8.x.x.x-hotspot)
시스템 변수 목록에서 Path를 찾아 선택 후 편집 -> 새로 만들기 클릭:
- %JAVA_HOME%\bin 입력 후 확인.
확인: 명령 프롬프트(cmd)에서 java -version과 javac 명령어가 정상적으로 버전 정보를 출력하는지 확인합니다.

② MACOS (맥킨토시 - zsh 기준)

터미널을 엽니다.
vi ~/.zshrc 명령어로 설정 파일을 엽니다.
파일 맨 아래에 다음 내용을 추가합니다:
- export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
- export PATH=$JAVA_HOME/bin:$PATH
저장 후(:wq), 터미널에서 source ~/.zshrc를 입력하여 설정을 즉시 적용합니다.
확인: 터미널에서 java -version과 javac 명령어가 자바 1.8 버전을 잘 가리키는지 확인합니다.

③ LINUX (리눅스 - bash 기준)

터미널을 엽니다.
vi ~/.bashrc 명령어로 파일을 엽니다.
파일 맨 아래에 다음 내용을 추가합니다 (JDK 실제 설치 경로 입력):
- export JAVA_HOME=/usr/lib/jvm/jdk-8-oracle (예시 경로)
- export PATH=$JAVA_HOME/bin:$PATH
저장 후, 터미널에서 source ~/.bashrc를 입력하여 설정을 적용합니다.
확인: 터미널에서 java -version과 javac 명령어를 확인합니다.

4단계: OS별 IDE (STS 4) 실행 방법

환경 변수까지 세팅을 끝마쳤다면, 이제 우리가 코딩할 무대인 STS 4를 켜볼 차례입니다.

WINDOWS: STS 압축을 푼 폴더에서 SpringToolSuite4.exe 파일을 더블 클릭하여 실행합니다.
MACOS: STS 압축을 풀고 애플리케이션(Applications) 폴더로 이동시킨 후, SpringToolSuite4.app 아이콘을 클릭하여 실행합니다.
LINUX: 터미널에서 STS 압축을 푼 폴더로 이동한 후, ./SpringToolSuite4 커맨드를 입력하여 실행합니다.

5단계: HelloWorld를 위한 스프링 부트 파일 구조

스프링 부트는 규격화된 완성차와 같아서 정해진 위치에 파일이 들어가야 똑똑하게 작동합니다. 우리는 가장 대중적인 빌드 도구인 Maven을 기준으로 프로젝트의 뼈대를 잡겠습니다. 프로젝트를 생성하거나 불러오면 아래와 같은 핵심 구조를 보게 됩니다.

  banana-helloworld (프로젝트 루트 폴더)
├──   pom.xml                    <-- [핵심] 프로젝트의 설계도. 스프링 부트 버전, 라이브러리를 정의합니다.
└──   src
    └──   main
        ├──   java               <-- [핵심] 실제 자바 소스 코드가 들어가는 청정 구역입니다.
        │   └──   com
        │       └──   talkit
        │           └──   banana   <-- 우리의 '패키지' 이름입니다.
        │               ├──   BananaApplication.java  <-- [핵심] 프로그램의 시작점. 스프링 부트를 켜는 스위치입니다.
        │               └──   HelloController.java   <-- [핵심] 웹 요청을 받아 "HelloWorld"를 돌려주는 컨트롤러입니다.
        └──   resources          <-- [핵심] 설정 파일이나 이미지 등이 들어갑니다.
            └──   application.properties <-- 스프링 부트의 상세 설정을 적는 곳입니다. (이번엔 비워둡니다.)

6단계: 구조에 따른 핵심 소스 코드 작성

이제 정해진 파일 위치에 실제 생명력(코드)을 불어넣어 줄 차례입니다. 총 3개의 핵심 파일을 작성합니다.
① pom.xml: 프로젝트의 설계도 (Java 1.8 & Boot 2.7 설정)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="[http://maven.apache.org/POM/4.0.0](http://maven.apache.org/POM/4.0.0)" xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance](http://www.w3.org/2001/XMLSchema-instance)"
    xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0](http://maven.apache.org/POM/4.0.0) [https://maven.apache.org/xsd/maven-maven-4.0.0.xsd](https://maven.apache.org/xsd/maven-maven-4.0.0.xsd)">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.18</version> 
        <relativePath/> 
    </parent>

    <groupId>com.talkit</groupId>
    <artifactId>banana-helloworld</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>banana-helloworld</name>
    <description>Banana Hello World for Java 1.8</description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

② BananaApplication.java: 프로그램의 시작점 (메인 스위치)

package com.talkit.banana;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

// [핵심] 이 클래스가 스프링 부트의 구성이자 시작점임을 알리는 마법의 어노테이션입니다.
@SpringBootApplication
public class BananaApplication {
    public static void main(String[] args) {
        // [핵심] 실제 내장 서버를 올리고 스프링 부트를 가동하는 메인 코드입니다.
        SpringApplication.run(BananaApplication.java, args);
    }
}

③ HelloController.java: 웹 요청을 처리하는 컨트롤러

package com.talkit.banana;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

// [핵심] 이 클래스가 웹 요청을 받아 문자열 데이터를 브라우저에 전송하는 컨트롤러임을 명시합니다.
@RestController
public class HelloController {

    // [핵심] 사용자가 웹 브라우저에서 "/" (기본 경로)로 접속하면 이 메서드를 연결합니다.
    @GetMapping("/")
    public String helloBanana() {
        return "  가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7!  ";
    }
}

7단계: STS 4에서 대시보드로 프로젝트 구동하기

이제 모든 코드가 준비되었습니다! 우리가 장착한 STS 4의 가장 큰 무기인 '부트 대시보드'를 활용하여 아주 편안하게 시동을 걸어보겠습니다.
① 프로젝트 불러오기 (Import)
1. STS 4를 실행하고 상단 메뉴에서 File -> Import...를 클릭합니다.
2. Maven 폴더 아래의 Existing Maven Projects를 선택하고 Next를 누릅니다.
3. Root Directory 옆의 Browse... 버튼을 눌러 우리가 코드를 작성해 둔 banana-helloworld 폴더를 선택합니다.
4. 중간 목록에 pom.xml 파일이 잘 체크되었는지 확인하고 Finish를 누릅니다.
5. STS 우측 하단에 인터넷에서 필요한 메이븐 빌드 라이브러리를 다운로드하는 게이지가 지나갑니다. 다운로드가 끝날 때까지 잠시만 기다려 주세요.
② 대시보드로 시동 걸기 (Run)
1. 프로젝트 빌드가 완료되면 STS 화면의 Boot Dashboard 탭을 클릭합니다.
2. local 항목을 펼쳐보면 방금 불러온 우리의 banana-helloworld 프로젝트가 예쁘게 떠 있을 것입니다.
3. 프로젝트 이름을 마우스 우클릭한 뒤, (Re)start (또는 상단의 초록색 재생 버튼 아이콘)를 클릭합니다.
③ 브라우저에서 감격의 결과 확인하기
1. STS 중앙 하단의 Console 탭에 로그가 시원하게 올라갑니다. 마지막 행에 "Started BananaApplication in X.XXX seconds"라는 문구가 나타나면 서버 구동 성공입니다!
2. 크롬 등 사용하시는 웹 브라우저를 엽니다.
3. 주소창에 http://localhost:8080을 정확히 입력하고 엔터를 탁! 칩니다.
4. 화면에 우리가 컨트롤러에 적어두었던 바나나 환영 인사가 멋지게 출력되는 것을 볼 수 있습니다!

  가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7!

가야태자의 정리 및 복습 팁

드디어 우리는 Java 1.8이라는 전통적인 환경 위에서 스프링 부트 2.7 완성차를 조립하고 첫 주행(HelloWorld)까지 훌륭하게 마쳤습니다!
스프링 부트 개발을 배울 때 가장 좋은 복습 방법은 각 파일이 왜 이 자리에 있어야 하고, 어노테이션(@)이 무슨 역할을 하는지 구조와 코드를 매칭하며 눈으로 짚어보는 것입니다. 이 기초 체력이 굳건해야 복잡한 비즈니스 로직을 짤 때 흔들리지 않습니다.
다음 시간에는 이 띄워놓은 HelloWorld 웹 페이지 위에 실제 데이터를 예쁘게 주고받는 더 흥미진진한 백엔드 이야기로 찾아오겠습니다.
실습 도중 에러가 나거나 막히는 점이 있다면 언제든 댓글 창에 질문을 남겨주세요. 같이 해결해 봅시다!

실제로 실습을 진행하고 싶습 파트는 또 글을 적어 보겠습니다.

[테크/개발] 자바 백엔드의 날개, Spring Boot 개발 환경(IDE) 완벽 가이드: 나에게 맞는 도구는?

가야태자 — Thu, 2 Jul 2026 09:06:48 +0900

[테크/개발] 자바 백엔드의 날개, Spring Boot 개발 환경(IDE) 완벽 가이드: 나에게 맞는 도구는?

안녕하세요 가야태자 @talkit 입니다.

이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 개발 환경을 꾸려볼려고 합니다. 이때 사용할 수 있는 개발 환경이 여러가지가 있는데 이 개발 환경들을 어떻게 구성할지에 대한 이야기를 해보고자 합니다.

스프링 부트(Spring Boot)는 과거의 복잡한 설정을 자동화해 주어 개발 생산성을 극대화해 주지만, 우리가 어떤 도구(IDE)를 손에 쥐느냐에 따라 그 개발의 '편안함'과 '작업 속도'는 천차만별로 달라집니다. 현재 자바 생태계에서 선택할 수 있는 대표적인 개발 환경들의 특징, 지원 OS, 그리고 가장 중요한 유료/무료 여부와 공식 참조 링크를 낱낱이 비교해 드리겠습니다.

[특화 섹션] 인텔리제이 커뮤니티(무료) vs 얼티밋(유료) 집중 비교

많은 초보 개발자분들이 *"인텔리제이가 대세라고 해서 다운받으려고 보니 얼티밋 버전은 너무 비싸요. 무료인 커뮤니티 버전으로 스프링 부트 개발해도 괜찮을까요?"*라는 질문을 던지십니다.

결론부터 말씀드리면 "개발은 가능하지만, 얼티밋에 비해 많은 수고로움(수동 작업)이 필요하다"입니다. 두 버전이 스프링 부트 개발 환경에서 어떤 차이를 보이는지 핵심만 비교해 드립니다.

1) 프로젝트 생성 방식의 차이

Ultimate (유료): IDE 내부에서 Spring Initializr를 곧바로 호출하여 몇 번의 클릭만으로 스프링 부트 프로젝트를 뚝딱 생성할 수 있습니다.
Community (무료): 내장 프로젝트 생성기에서 스프링 부트를 공식 지원하지 않습니다. 따라서 웹 브라우저를 켜고 스프링 공식 스타터 웹사이트(start.spring.io)에 접속하여 프로젝트를 생성한 뒤, 압축을 풀고 커뮤니티 버전에서 Import(열기)하는 번거로운 과정을 거쳐야 합니다.

2) 애플리케이션 구동 및 모니터링 (부트 대시보드)

Ultimate (유료): 전용 'Run Dashboard(Services)'가 존재하여 내장 톰캣 서버 제어, 액추에이터(Actuator) 연동 데이터 분석, 현재 활성화된 프로필(Profile) 변경 등을 GUI 환경에서 직관적으로 관리합니다.
Community (무료): 스프링 부트 전용 대시보드가 없습니다. 일반 자바 메인 클래스를 실행하듯 Application.java 파일을 직접 찾아 우클릭 후 Run을 실행해야 합니다. 여러 서버를 동시에 띄우거나 관리할 때 다소 직관성이 떨어집니다.

3) 코드 어시스트 및 설정 파일(Application.properties / yaml) 자동 완성

Ultimate (유료): 스프링 부트의 설정 파일들을 완벽하게 인식합니다. 예를 들어 server.port나 데이터베이스 연결 설정을 타이핑할 때 지능적인 자동 완성을 제공하고, 오타가 나면 경고해 줍니다. 또한 컨트롤러와 매핑된 URL 엔드포인트를 모아서 보는 전용 도구도 제공합니다.
Community (무료): 텍스트 기반의 단순 자동 완성만 지원하거나 아예 지원하지 않는 경우가 많아, 설정 파일의 키값을 개발자가 직접 공식 문서를 보며 타이핑해야 하므로 오타로 인한 삽질(?) 가능성이 커집니다.

가야태자의 커뮤니티 버전 활용 팁: > 비용 부담 때문에 반드시 인텔리제이 커뮤니티 버전을 써야 한다면, 마켓플레이스에서 'Spring Boot Helper' 같은 서드파티 플러그인을 찾아서 수동으로 설치해 보세요. 완벽하진 않지만 얼티밋 버전의 갈증을 조금이나마 해소할 수 있습니다. 다만, 무료 환경에서 편안한 스프링 부트 개발을 원하신다면 커뮤니티 버전보다는 차라리 아래의 STS 4나 VS Code가 기능적으로 더 쾌적할 수 있습니다.

참조 가이드: IntelliJ IDEA 통합 가이드 및 공식 비교 차트 (JetBrains)

1. 실무 트렌드의 절대 강자: IntelliJ IDEA (JetBrains)

현재 전 세계 자바 및 스프링 부트 개발자들이 가장 사랑하고, 실무 표준으로 자리 잡은 통합개발환경입니다.

지원 OS: Windows, macOS, Linux
비용 (유료/무료): 하이브리드 (Community 버전: 무료 / Ultimate 버전: 유료)
- 개인 및 기업에서 무료로 쓸 수 있는 커뮤니티 버전이 있지만, 스프링 부트 전용 핵심 편의 기능들은 연간 구독 형태의 Ultimate(유료) 버전에 집중되어 있습니다.
Spring Boot 개발 편안함: * Ultimate 버전: ⭐⭐⭐⭐⭐ (최상 - 돈값을 톡톡히 하는 완벽한 빌트인 인프라)
- Community 버전: ⭐⭐⭐☆☆ (보통 - 자바 코딩은 훌륭하나 스프링 특화 기능이 빠져 수동 작업 필요)

2. 스프링 공식 전용 도구: STS (Spring Tools 4)

스프링의 친정인 VMware(Tanzu)에서 전통의 이클립스(Eclipse)를 기반으로 스프링 개발에 딱 맞게 최적화하여 내놓은 공식 전용 IDE입니다.

지원 OS: Windows, macOS, Linux
비용 (유료/무료): 100% 무료 (오픈소스)
Spring Boot 개발 편안함: ⭐⭐⭐⭐☆ (우수)
- 오직 '스프링 및 스프링 부트 개발'만을 타깃으로 커스텀 되었기 때문에, 무료 도구 중에서는 최고의 안정성과 편의성을 자랑합니다.
- 화면 우측 하단의 '부트 대시보드(Boot Dashboard)'를 통해 여러 개의 스프링 부트 애플리케이션을 직관적으로 켜고 끌 수 있으며, 런타임 상태를 쉽게 모니터링할 수 있습니다. IntelliJ Ultimate의 유료 기능 중 상당수를 무료로 누릴 수 있는 훌륭한 대안입니다.
공식 다운로드 및 사용법 링크: Spring Tools 4 공식 홈페이지 및 에코시스템 가이드

3. 초경량과 커스텀의 매력: VS Code (Visual Studio Code)

마이크로소프트에서 개발한 초경량 소스코드 에디터로, 웹 프론트엔드를 넘어 백엔드 영역까지 생태계를 급격히 확장하고 있습니다.

지원 OS: Windows, macOS, Linux, Web(웹 브라우저)
비용 (유료/무료): 100% 무료 (오픈소스)
Spring Boot 개발 편안함: ⭐⭐⭐⭐☆ (양호)
- 마켓플레이스에서 'Spring Boot Extension Pack' 확장 플러그인을 설치하면 프로젝트 생성부터 구동까지 놀라울 정도로 유려하게 지원합니다.
- IntelliJ나 Eclipse 계열에 비해 압도적으로 가볍고 실행 속도가 빠릅니다. 메모리를 적게 차지하므로, 사양이 다소 낮은 노트북 환경이나 가벼운 코딩 환경을 선호하는 개발자들에게 최고의 편안함을 선호하는 대안으로 각광받고 있습니다.
공식 확장팩 안내 링크: VS Code 공식 가이드 - Spring Boot 개발 환경 구축 및 확장팩 안내

4. 전통의 아키텍처: Eclipse (이클립스)

자바의 역사와 함께 숨 쉬어 온 전통의 오픈소스 대형 IDE입니다.

지원 OS: Windows, macOS, Linux
비용 (유료/무료): 100% 무료 (오픈소스)
Spring Boot 개발 편안함: ⭐⭐⭐☆☆ (보통)
- 순수 이클립스에 STS 플러그인을 수동으로 설치하여 스프링 부트를 개발할 수 있습니다.
- 하지만 플러그인 간의 버전 충돌 가능성이 있고, 과거 무거운 XML 방식의 잔재가 남아있어 초기 세팅이 다소 번거롭습니다. 만약 이클립스 기반의 개발 환경을 선호하신다면, 순수 이클립스보다는 앞서 소개해 드린 STS(Spring Tools 4)를 다운로드하여 곧바로 사용하시는 것이 정신 건강에 훨씬 이롭습니다.

5. 그 외의 틈새 선택지들

NetBeans (Apache): Windows/Mac/Linux 지원, 무료. 자바 표준 스펙(Jakarta EE)엔 강하나 스프링 부트 전용 플러그인 생태계가 빈약하여 추천도가 떨어집니다. (편안함: ⭐⭐☆☆☆)
Fleet (JetBrains): Windows/Mac/Linux 지원, 현재 프리뷰(무료) 진행 중. VS Code처럼 가벼우면서도 IntelliJ의 스마트 코드 분석 엔진을 가져와 쓸 수 있는 젯브레인의 차세대 경량 에디터입니다. (편안함: ⭐⭐⭐☆☆)
클라우드 IDE (구름IDE, GitHub Codespaces 등): OS 무관, 기본 무료+유료 요금제. 웹 브라우저만 있으면 가상 컨테이너에서 스프링 부트를 띄울 수 있어 태블릿(아이패드 등) 코딩이나 외부 강의·실습용 환경 구성에 매우 편안합니다. (편안함: ⭐⭐⭐☆☆)

한눈에 보는 요약 및 추천 가이드

IDE 명	주요 추천 대상	비용 (개인/기업)	Spring Boot 개발 편안함 정도
IntelliJ (Ultimate)	실무/상용 서비스 개발, 최고의 생산성을 위해 돈을 지불할 용의가 있는 분	유료 (구독제)	최상 (가장 스마트하고 편리함)
STS 4	비용 부담 없이 스프링 공식 전용 도구의 안정적인 기능을 쓰고 싶을 때	무료 (오픈소스)	우수 (무료 도구 중 가장 직관적)
VS Code	사양이 낮은 PC, 가볍고 빠른 기동성과 스타일리시한 코딩 환경 선호	무료 (오픈소스)	양호 (쾌적하고 가벼운 확장성)
IntelliJ (Community)	인텔리제이의 단축키와 코드 분석 엔진을 무료로 부드럽게 쓰고 싶을 때	무료 (오픈소스)	양호 (자바 코딩은 좋으나 스프링 수동 세팅 필요)
Eclipse	기존 금융권/공공기관의 오래된 레거시 시스템 유지보수 환경	무료 (오픈소스)	⚪ 보통 (직접 수동 플러그인 세팅 필요)

가야태자의 결론: 나에게 맞는 환경 구성은?

스프링 부트 개발 환경을 구성할 때의 핵심은 "자신의 장비 사양"과 "비용 투자 여부"입니다.

만약 장비가 훌륭하고 생산성을 위해 비용을 투자할 의향이 있다면 IntelliJ Ultimate(유료) 환경이 최고의 정답입니다.
인텔리제이 특유의 UI와 코드 리팩토링 능력을 사랑하지만 비용이 부담된다면 조금 번거롭더라도 IntelliJ Community(무료) 버전에 수동 플러그인을 세팅해 볼 수 있습니다.
완전히 무료이면서도 장황한 수동 세팅 없이 스프링 부트 전용 기능을 안정적으로 쓰고 싶다면 STS 4가 가장 합리적인 선택입니다.
마지막으로, 컴퓨터 사양이 아쉽거나 경량화된 환경을 원한다면 VS Code 조합을 추천해 드립니다.

여러분은 어떤 IDE로 스프링 부트의 첫 발을 내딛고 싶으신가요? 여러분의 PC 환경과 목적에 맞는 최적의 환경을 꾸리시길 바라며, 다음에는 실제 프로젝트를 생성하고 구동하는 이야기로 찾아오겠습니다.

궁금한 점이나 의견이 있으시다면 언제든 댓글로 소통해 주세요!

[테크/회고] 자바 웹 프레임워크 연대기: 스트럿츠(Struts)의 왕좌와 스프링(Spring)의 대혁명

가야태자 — Wed, 1 Jul 2026 09:43:01 +0900

[테크/회고] 자바 웹 프레임워크 연대기: 스트럿츠(Struts)의 왕좌와 스프링(Spring)의 대혁명

자바(Java) 백엔드 생태계를 주도해 온 프레임워크의 역사를 되짚어보면, 이는 단순히 기술의 변화가 아니라 "복잡성과의 처절한 사투", 그리고 "개발자 중심의 생산성 향상"이라는 거대한 흐름의 연속이었습니다.

오늘날 자바 개발자들에게 공기처럼 당연한 존재가 된 Spring Boot와 Spring MVC가 있기까지, 자바 웹 생태계의 패러다임을 바꾸었던 두 주인공 '스트럿츠(Struts)'와 '스프링(Spring)'의 흥망성쇠, 그리고 자바의 표준이 된 스프링 생태계의 거대한 진화 과정을 한눈에 정리해 봅니다.

1. 태동기: EJB의 독점과 스파게티 코드의 어둠 (2000년대 초)

초기 대규모 자바 엔터프라이즈 환경은 썬 마이크로시스템즈(Sun Microsystems)가 주도한 J2EE 규격과 EJB(Enterprise JavaBeans)가 지배하고 있었습니다. 분산 환경과 트랜잭션을 컨테이너가 알아서 제어해 준다는 거창한 명분이 있었지만, 현실은 처참했습니다. 코드 한 줄을 고치거나 테스트하려면 수많은 인터페이스를 상속받아야 했고, 무거운 WAS(웹 애플리케이션 서버)를 매번 재부팅해야 했습니다. "자바의 본질인 객체지향(POJO)을 잃어버렸다"는 혹평이 쏟아졌습니다.

덮친 데 덮친 격으로 당시 웹 화면을 담당하던 JSP 영역은 HTML, 자바스크립트, 비즈니스 로직, 데이터베이스 쿼리까지 한 파일에 뒤섞여 있는 이른바 '모델 1' 방식이 흔했습니다. 조금만 프로젝트가 커져도 유지보수가 불가능한 스파게티 코드가 되기 일쑤였습니다.

2. 스트럿츠(Struts)의 등장: 최초의 웹 MVC 표준과 황금기 (2000년대 초중반)

이 어둠 속에서 자바 웹 구원의 투수로 등판한 것이 바로 아파치 재단의 스트럿츠(Struts)였습니다. 2001년 출시된 스트럿츠는 스파게티 코드처럼 엉켜있던 웹 개발 프로세스에 '모델 2 MVC(Model-View-Controller) 패러다임'을 확고하게 심어주었습니다.

화면(View), 비즈니스 로직(Model), 제어 흐름(Controller)을 명확하게 분리.
개발자들이 역할 분담을 할 수 있는 구조적 명확성 제공.

스트럿츠는 출시 직후 폭발적인 인기를 끌며 2003년부터 2007년 무렵까지 전 세계 자바 웹 시장을 사실상 지배했습니다. 당시 한국의 초기 대형 공공기관 프로젝트나 대기업 시스템 역시 대부분 스트럿츠를 뼈대로 구축되었습니다. 자바 웹 개발자들에게 "웹 앱은 무조건 MVC로 짜야 한다"는 공식을 각인시킨 주역이 바로 스트럿츠입니다.

3. 스프링(Spring)의 탄생: 오픈소스 혁명과 '공존'의 시대 (2000년대 중반)

스트럿츠가 앞단(웹 화면 제어)을 평정하고 있을 때, 뒤 영역(비즈니스 로직 및 객체 관리)에서는 또 다른 혁명이 시작되고 있었습니다. 2004년, EJB의 지독한 복잡성에 분노한 로드 존슨(Rod Johnson)을 필두로 스프링 프레임워크(Spring Framework) 1.0이 세상에 나왔습니다.

스프링은 무거운 컨테이너 없이도 엔터프라이즈 기능을 수행할 수 있도록 IoC/DI(의존성 주입)와 AOP(관점 지향 프로그래밍)를 전면에 내세웠습니다. 기술 인프라와 비즈니스 로직을 완벽히 분리하여 "다시 순수한 자바(POJO)로 돌아가자"고 외친 것입니다.

재미있는 점은, 초기 스프링은 스트럿츠의 경쟁자가 아니라 '가장 완벽한 파트너'였다는 사실입니다. 2000년대 중반 자바 웹 진영의 가장 트렌디하고 강력한 '꿀조합' 스택은 다음과 같았습니다.

웹 화면 및 요청 제어(MVC): Struts
비즈니스 로직 및 트랜잭션 관리(DI/AOP): Spring
데이터베이스 매핑(SQL 매퍼): iBATIS (현 MyBatis)

웹 요청을 받는 앞문(Controller)은 스트럿츠가 열고, 문을 열고 들어온 데이터를 처리하는 알맹이 객체 관리는 스프링이 맡는 식으로 두 프레임워크는 아름답게 공존했습니다.

4. 세대교체: '공존'에서 '대체'로, 스프링의 왕좌 장악 (2000년대 후반)

영원할 것 같았던 스트럿츠와 스프링의 동맹은 2000년대 후반으로 넘어가며 균열이 가기 시작했고, 결국 완전한 세대교체로 이어지게 됩니다. 여기에는 몇 가지 결정적인 이유가 있었습니다.

Spring MVC의 대두: 스프링 진영에서 자체 웹 프레임워크인 Spring MVC를 고도화(Spring 2.5 ~ 3.0)하면서 굳이 앞단에 스트럿츠를 따로 연동할 필요가 없어졌습니다. 스프링 컨테이너와 완벽하게 네이티브로 결합하는 Spring MVC는 스트럿츠보다 훨씬 유연하고 강력했습니다.
설정 지옥(XML)의 한계: 스트럿츠는 화면 하나나 액션 하나를 추가할 때마다 거대한 struts-config.xml 설정을 매번 장황하게 수정해야 하는 번거로움이 있었습니다.
결정타가 된 보안 취약점 사태: 스트럿츠가 스트럿츠2(Struts2)로 버전 업을 치는 과정에서, 원격으로 코드를 실행할 수 있는 치명적인 보안 취약점(CVE)이 주기적으로 발생했습니다. 금융권과 대기업 시스템이 해커들의 표적이 되자, 안정성이 최우선인 기업들은 대대적으로 스트럿츠를 버리고 스프링 생태계로 탈출하기 시작했습니다.
- 관련 기사 참고: 안전성 경고등 켜진 '아파치 스트럿츠2' 보안 취약점 주의보 (보안뉴스)

5. 스프링 생태계의 거대한 양대 축: Spring Framework vs Spring Boot

스트럿츠를 흡수하고 자바 생태계를 통일한 스프링은 거대해진 몸집만큼 강력한 진화를 거듭했습니다. 현대 자바 백엔드는 크게 인프라와 기술 표준을 정의하는 'Spring Framework'와, 이를 기반으로 빠른 생산성을 제공하는 'Spring Boot'의 두 축으로 움직입니다. 각 프레임워크가 걸어온 핵심 버전을 브리핑합니다.

Spring Framework의 진화 (1.0에서 6.0까지)

1.0 (2004): 순수 자바 객체(POJO) 기반의 DI/AOP 개념 증명. 무거운 XML 설정 중심.
2.0 ~ 3.0 (2006~2009): 웹 계층을 위한 Spring MVC의 본격적인 강화. 점차 XML을 벗어나 @Component, @Autowired 같은 자바 어노테이션(Annotation) 기반 설정의 표준 도입.
4.0 (2013): 자바 8(Java 8) 지원 개시. 람다식과 새로운 날짜 API 등을 수용하며 현대적 자바 문법과의 정합성 확보.
5.0 (2017): 대규모 트래픽 처리를 위한 비동기·논블로킹 리액티브 프로그래밍 스택인 Spring WebFlux 탑재.
6.0 (2022~현재): 자바 17을 최소 요구 버전으로 지정하여 구조적 최적화 단행. 가상 스레드(Project Loom) 연동 및 클라우드 환경을 위한 GraalVM 네이티브 이미지 빌드 공식 지원.
- 공식 발표 참고: Spring Framework 6.0 정식 버전(GA) 출시 안내 (스프링 공식 블로그)

Spring Boot의 진화 (1.0에서 4.5까지)

1.0 (2014): 수많은 XML/자바 설정에 지친 개발자들을 구원하기 위해 등장. "설정보다는 관례(Convention over Configuration)"를 모토로 내장 톰캣(Tomcat)과 자동 설정(starter) 개념 최초 도입.
2.0 (2018): Spring Framework 5.0 기반으로 업그레이드되면서, 리액티브 웹 스택과 새로운 모니터링 툴(Actuator) 기능 대폭 강화.
3.0 (2022): 자바 17 표준 탑재 및 Spring 6 기반 리프레시. 빌드 타임에 C/C++ 프로그램처럼 바이너리를 뽑아내어 구동 속도를 밀리초(ms) 단위로 줄이는 GraalVM 네이티브 컴파일 전면 수용. 클라우드 네이티브(MSA/Serverless)의 최적화 달성.
- 공식 발표 참고: Spring Boot 3.0 정식 버전(GA) 출시 안내 (스프링 공식 블로그)
4.0 ~ 4.5 (현재): 더 고도화된 자바 최신 스펙 완벽 튜닝. 대규모 언어 모델(LLM) 연동을 위한 Spring AI 프레임워크 인프라가 코어 단에 밀접하게 내장되었으며, 가상 스레드(Virtual Thread) 최적화를 통해 리액티브 코딩 없이도 초고효율 멀티스레딩을 가볍게 구동하는 완성형 아키텍처 구축.

6. 두 프레임워크의 상관관계: 엔진과 자동차

종종 신입 개발자들이 "스프링 프레임워크와 스프링 부트 중 무엇을 공부해야 하나요?" 혹은 "부트가 나왔으니 스프링 프레임워크는 끝난 건가요?"라는 질문을 하곤 합니다. 하지만 두 기술은 대체 관계가 아닌 완벽한 상호보완적 결합 관계입니다.

쉽게 비유하자면, 스프링 프레임워크는 '고성능 자동차 엔진'이고, 스프링 부트는 그 엔진을 얹고 바퀴, 시트, 내비게이션까지 완벽하게 조립해 둔 '완성차'입니다.

Spring Boot: 편리한 완성차 (내장 톰캣, 자동 설정, 자동 버전 관리)
Spring Framework: 핵심 심장 엔진 (DI/AOP Core, Spring MVC, WebFlux 테크놀로지)

스프링 부트는 독자적인 프레임워크가 아닙니다. 내부를 뜯어보면 결국 스프링 프레임워크가 핵심 심장(Core)으로 돌고 있습니다. 과거에는 엔진(Spring Framework)만 덜렁 주어졌기 때문에 개발자가 직접 차체(Tomcat 서버)를 구해서 용접하고, 연료 공급 장치(XML 파일 수백 줄)를 직접 커스텀 조립해야 했습니다.

반면, 스프링 부트는 개발자가 Boot를 실행하는 순간, 뒤편에서 스프링 프레임워크의 DI/AOP 엔진을 깨우고 필요한 라이브러리들을 관례에 맞게 알아서 조립해 줍니다. 결국 부트를 깊고 단단하게 쓴다는 것은 그 내부에서 돌아가는 스프링 프레임워크의 사상을 완벽히 이해하는 것과 같습니다.

마치며

스트럿츠(Struts)는 무질서하던 자바 웹 개발에 최초로 MVC 패턴의 규격을 제시하며 웹 제어의 대중화를 이끈 선구자였습니다.
스프링(Spring Framework)은 EJB의 무거움에 반대하며 순수 자바(POJO) 정신을 깨웠고, 기술을 유연하게 통합하는 포용력으로 시작해 웹 영역(Spring MVC)까지 완벽히 흡수하며 생태계를 통일했습니다.
스프링 부트(Spring Boot)는 거대해진 스프링 엔진을 개발자들이 단 몇 초 만에 도로 위로 끌고 나갈 수 있게 완성차 형태로 포장해 준 혁신이었습니다.

현재 스트럿츠는 오래된 레거시 시스템의 유지보수 단계에서나 볼 수 있는 '살아있는 화석'이 되었지만, 그가 남긴 MVC 패러다임은 여전히 스프링의 심장 속에 살아 숨 쉬고 있습니다. 세월을 관통하며 다듬어진 이 견고한 생태계 덕분에, 현대의 우리는 인프라 설정에 고통받지 않고 오롯이 비즈니스 로직에만 집중할 수 있는 최고의 개발 풍요를 누리고 있습니다.

[Java 보안] 오픈 JDK 벤더별 EOS 비교 및 자바 보안 패치의 중요성 / https://www.steemit.com/kr/@talkit/java-jdk-eos--xz1g03

[Java와 AI] 자바가 AI 시대의 주역이 되지 못한 이유와 새로운 반격 / https://www.steemit.com/java/@talkit/java-ai-ai--tfzrzd

[개발 상식] 1960년대 기계어부터 현대 AI 기반 코드 최적화까지 한눈에 보기 / https://www.steemit.com/kr/@talkit/ai--px1egt

[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화 / https://www.steemit.com/kr/@talkit/java-se-eejakarta-ee--p5j85z

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

[Java 보안] 오픈 JDK 벤더별 EOS 비교 및 자바 보안 패치의 중요성

가야태자 — Tue, 30 Jun 2026 09:51:43 +0900

[Java 보안] Log4j 사태로 보는 패치의 중요성, 오픈 JDK 벤더별 EOS 비교 및 오라클의 상용화 비화

안녕하세요 가야태자 @talkit 입니다.

최근 자바를 다시 복습하면서, 시스템의 안정성을 책임지는 '보안 업데이트'의 중요성을 격하게 절감하고 있습니다. 전 세계 웹과 대규모 기업용 엔터프라이즈 시스템의 뼈대를 이루는 Java 환경에서 보안 패치는 단순한 버전 업그레이드가 아닌, 서비스의 생명줄과 같습니다.

오늘 포스팅에서는 전 세계 IT 백엔드를 뒤흔들었던 Log4j 사태를 통해 왜 우리가 보안 업데이트에 민감해야 하는지 알아보고, Oracle의 공식 JDK와 Eclipse 재단, Red Hat, Azul Systems 등 다양한 진영의 오픈 JDK가 제공하는 보안 업데이트 종료(EOS) 일자를 명확하게 비교해 보겠습니다. 더불어 오라클이 자바 업데이트를 상용(구독 모델)으로 전환한 배경과 비화까지 함께 정리해 드립니다.

1. Java 보안 업데이트가 왜 중요한가: Log4j 사태의 교훈

Java 환경에서 보안 업데이트가 기업의 생존과 직결된다는 것을 증명한 가장 대표적인 사건이 바로 2021년 말 발생한 Log4j 취약점 사태(Log4Shell)입니다. Log4j는 거의 모든 Java 기반 애플리케이션과 대형 기업 웹 서버에서 로그를 기록하기 위해 공통으로 사용하는 핵심 라이브러리였습니다.

이 라이브러리에서 발견된 취약점은 공격자가 서버에 원격으로 접속해 악성 코드를 무조건 실행할 수 있는 원격 코드 실행(RCE) 취약점이었습니다. 해커가 마음만 먹으면 기업의 핵심 DB를 탈취하거나 시스템을 마비시킬 수 있는, 보안 등급 최악의 치명적인 약점이었습니다.

당시 전 세계 수많은 대기업과 금융권의 개발자들이 이 약점을 막기 위해 최신 보안 버전으로 긴급 업데이트 패치를 적용하느라 사상 초유의 비상사태를 겪었습니다. 만약 사용 중인 JDK나 라이브러리의 보안 업데이트 지원이 이미 종료된 상태였다면, 기업들은 이 무시무시한 취약점을 알고도 방어막을 치지 못해 고스란히 무방비로 당했을 것입니다.

이처럼 알려진 보안 취약점(CVE)을 빠르게 봉쇄하고 시스템의 대외 신뢰도를 유지하기 위해서, 기업이 어떤 JDK를 사용하든 공식적인 보안 업데이트 지원 기간(LTS)을 명확히 확인하고 추적하는 것은 필수적입니다.

2. 주요 진영별 Java LTS 버전 보안 업데이트 종료(EOS) 비교

오라클이 제공하는 무료 OpenJDK 빌드는 새로운 메이저 버전이 출시되면 이전 버전의 무료 지원을 몇 개월 내로 빠르게 중단합니다. 반면 기업용 시스템의 장기 안정성을 위해 오픈소스 커뮤니티와 다른 전문 벤더사들은 자체적인 LTS(Long-Term Support) 일정을 길게 확보해 두고 있습니다.

각 진영의 공식 가이드라인을 기반으로 정리한 버전별 최소 지원 종료(End of Support) 마일스톤입니다.

Java LTS 버전	Oracle OpenJDK (무료 빌드)	Eclipse Adoptium (Temurin) [1]	Red Hat OpenJDK [2]	Azul Zulu (Core 기준) [3]
Java 8	지원 종료	최소 2030년 12월까지	완전지원 종료: 2026년 11월 30일 ELS-1 종료: 2030년 12월 31일	2030년 12월까지
Java 11	지원 종료	최소 2027년 10월까지	완전지원 종료 (2024년 10월 31일) ELS-1 종료: 2027년 10월 31일	2032년 1월까지
Java 17	지원 종료	최소 2027년 10월까지	완전지원 종료: 2027년 12월 31일	2029년 9월까지
Java 21	2026년 9월까지 (예정)	최소 2029년 12월까지	완전지원 종료: 2029년 12월 31일	2031년 9월까지

3. 오라클은 왜 자바 업데이트를 상용(유료)으로 전환했는가?

자바의 소스 코드 자체는 오픈소스(OpenJDK) 프로토콜로 풀려있지만, 오라클은 기업들이 실제 운영 서버에서 가장 신뢰하며 사용하는 자사 브랜드의 Oracle JDK 기술 지원을 유료화(상용 전환)했습니다. 여기에는 오라클의 철저한 비즈니스 수익 모델 체질 개선 전략이 숨어 있습니다.

① 상표권의 독점과 기술 지원의 자산화

오라클은 과거 선 마이크로시스템즈를 인수하면서 자바의 소스 코드는 커뮤니티에 기증(Jakarta EE 등)했으나, 'Java'라는 브랜드 상표권과 독점 기술 스펙은 끝까지 유지했습니다. 즉, '가장 순수하고 최적화된 오라클의 자바 기술 지원과 긴급 패치를 받고 싶다면 정당한 비용을 지불하라'는 비즈니스적 판단입니다.

② 라이선스에서 구독(Subscription) 모델로의 체질 개선

오라클은 과거 일회성으로 소프트웨어 라이선스를 판매하던 방식에서 완전히 탈피하여, 매달 서버 혹은 프로세서 수(또는 전사 직원 수) 기준으로 비용을 청구하는 'Java SE Subscription' 모델을 정착시켰습니다. 클라우드 시대에 인프라의 핵심인 자바 보안 패치를 정기적으로 공급하는 행위 자체를 거대한 고정 구독 수익원(Cash Cow)으로 만든 것입니다.

결국 장기적인 보안 거버넌스와 면책 조항이 필수적인 글로벌 대기업이나 대형 금융권들이 비용을 지불하더라도 오라클의 밀착 기술 지원을 선택할 수밖에 없도록 비즈니스 환경을 설계한 결과입니다.

4. 요약 및 시사점

자바 생태계에서 보안 업데이트는 인프라의 생명줄과 같습니다. 오라클이 자사 공식 JDK를 상용 구독 모델로 전환하며 장벽을 세우자, 시장은 오히려 Eclipse Adoptium이나 Red Hat, Azul 같은 대체 오픈 JDK 진영의 무상 장기 지원(LTS)을 적극적으로 수용하는 방향으로 건강하게 파편화되었습니다.

따라서 개발자와 아키텍트는 서비스의 특성에 맞춰 오라클의 유료 구독 모델을 선택할지, 혹은 무료로 장기 지원을 제공하는 타 진영의 오픈 JDK로 마이그레이션할지 명확한 EOS 로드맵을 바탕으로 인프라 이주 전략을 세워야 할 것입니다.

각주: Red Hat의 Full Support와 ELS-1 안내

완전지원 종료(End of Full Support): 레드햇의 일반 서브스크립션(구독) 고객 모두에게 무상으로 정기적인 보안 패치와 버그 수정 업데이트를 제공하는 마감일입니다. 만약 이 기간이 종료되면 일반 RHEL 가입자 대상의 무상 패치 배포가 중단됩니다. (예: OpenJDK 11은 2024년 10월 31일부로 완전지원이 종료되었습니다.)
ELS-1 종료(End of Extended Life Cycle Support Phase 1): 완전지원이 끝난 후, 마이그레이션 시간을 벌어야 하는 기업들을 위해 운영되는 유료 연장 보안 지원 단계입니다. 별도의 'OpenJDK ELS 서브스크립션'을 구매한 고객에 한해, 새로운 기능 추가 없이 시스템에 치명적인 영향을 미치는 핵심 보안 취약점(Critical/Important CVE) 패치만 제한적으로 백포팅하여 제공합니다.

[Java와 AI] 자바가 AI 시대의 주역이 되지 못한 이유와 새로운 반격 / https://www.steemit.com/java/@talkit/java-ai-ai--tfzrzd

[개발 상식] 1960년대 기계어부터 현대 AI 기반 코드 최적화까지 한눈에 보기 / https://www.steemit.com/kr/@talkit/ai--px1egt

[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화 / https://www.steemit.com/kr/@talkit/java-se-eejakarta-ee--p5j85z

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

공식 홈페이지 출처 및 EOS 확인 링크

[1] [Eclipse Adoptium (Temurin) 공식 지원 로드맵]

이클립스 재단의 버전별 End of Availability 일정 안내
URL: https://adoptium.net/support

[2] [Red Hat 고객 포털 OpenJDK 라이프 사이클 및 지원 정책]

레드햇 오픈 JDK의 RHEL 및 윈도우 지원 라이프사이클 및 ELS-1 단계 표준 가이드라인
URL: https://access.redhat.com/articles/1299013

[3] [Azul Systems Java Support Roadmap]

Azul Zulu 공급사가 보장하는 LTS 버전별 Production Support 및 Extended Support 상세 타임라인
URL: https://www.azul.com/products/azul-support-roadmap/

감사합니다.

[Java와 AI] 자바가 AI 시대의 주역이 되지 못한 이유와 새로운 반격

가야태자 — Mon, 29 Jun 2026 09:10:40 +0900

[Java와 AI] 자바가 AI 시대의 주역이 되지 못한 이유와 새로운 반격

안녕하세요 가야태자 @talkit 입니다.

요즘 Java를 다시 정리 겸 공부하고 있는데, 문득 한 가지 깊은 의문이 생겼습니다. "Java는 명실상부 웹과 기업용 시스템 시대를 지배한 대표 언어인데, 왜 정작 지금의 AI(인공지능) 시대에서는 주인공이 되지 못했을까?" 여러분도 'AI 시대의 언어'라고 하면 자바보다는 파이썬(Python)이 가장 먼저 떠오르실 텐데, 대체 어떤 기술적·인간적 배경이 이런 차이를 만들었는지 무척 궁금해졌습니다.

그래서 오늘 포스팅에서는 자바가 왜 AI의 주역 자리를 내주어야 했는지 그 이유를 날카롭게 파헤쳐 보고, 반대로 자바 진영이 AI 시대를 집어삼키기 위해 뒤에서 칼을 갈며 준비해 온 놀라운 최신 기술들과 미래 비전까지 함께 자세히 알아보겠습니다.

1. 웹/기업 시대의 절대 강자, Java

자바(Java)는 1990년대 후반 웹의 폭발적인 성장과 함께 기업용 시스템(Enterprise) 시장의 절대 강자로 자리매김했습니다. 거대하고 복잡한 금융권 인프라나 대기업의 백엔드 시스템에서 자바가 표준으로 선택된 이유는 타의 추종을 불허하는 '안정성'과 '확장성' 덕분이었습니다.

자바는 컴파일 시점에 타입을 엄격하게 검사하는 강력한 타입 시스템을 갖추고 있어, 대규모 협업 시 발생할 수 있는 휴먼 에러를 사전에 차단합니다. 또한 가상 머신(JVM) 아키텍처를 기반으로 하여 "한 번 작성하면 어디서나 실행된다"는 이식성을 보장했고, 가비지 컬렉터(GC)가 메모리를 자동으로 관리해 주어 개발자가 비즈니스 로직에만 집중할 수 있게 했습니다. 여기에 대용량 트랜잭션 처리에 특화된 Java EE(현 Jakarta EE) 스펙과 스프링(Spring) 프레임워크 생태계가 결합하면서, 자바는 수십 년간 엔터프라이즈 아키텍처의 견고한 뼈대로 군림해 왔습니다.

2. Java가 AI 시대의 주 언어가 되지 못한 이유

반면 AI와 머신러닝 시대의 주도권은 자바가 아닌 파이썬(Python)이 가져갔습니다. 여기에는 AI 학계의 독특한 인적 구성과 언어의 '타입(Type) 선언 방식'이 자아낸 결정적인 차이가 있었습니다.

초기 AI 및 데이터 과학 생태계를 구축한 주역들은 전통적인 컴퓨터공학과나 전산학과 출신의 소프트웨어 엔지니어보다는 수학, 통계학, 물리학, 뇌과학 등을 전공한 데이터 과학자 및 연구원(Researcher)들이 주류를 이뤘습니다. 이들의 주 목적은 완벽한 소프트웨어를 빌드하는 것이 아니라, 가설을 세우고 수식을 코드로 구현해 빠르게 데이터를 검증(Prototyping)하는 것이었습니다.

이 지점에서 자바와 파이썬의 생산성 격차가 벌어졌습니다. 물론 파이썬 역시 들여쓰기(Indentation) 규칙 등 문법적 엄격함이 존재하지만, 자바에 비하면 변수와 함수의 '형 선언(Type Declaration)'이 완전히 자유로운 동적 타입(Dynamic Typing) 언어입니다.

자바에서는 데이터 하나를 다루려 해도 데이터의 형태(int, String 등)를 엄격하게 미리 정의해야 하고, 클래스와 메서드를 장황하게 감싸는 보일러플레이트 코드를 작성해야 합니다. 반면 파이썬은 형 선언 없이 x = 10처럼 변수를 바로 만들어 쓰고, 함수도 유연하게 주고받을 수 있어 수학적 아이디어를 즉석에서 코드로 실험하기에 최적의 자유도를 제공했습니다.

또한, AI 연산의 핵심은 C/C++로 작성된 하드웨어 가속 라이브러리를 얼마나 매끄럽게 연결하느냐에 있었습니다. 파이썬은 이른바 '글루(Glue) 언어'로서 외부 로우레벨 라이브러리와의 결합이 매우 쉬웠고, 이를 바탕으로 연구원들이 넘파이(NumPy), 판다스(Pandas), 텐서플로우, 파이토치 등 독점적인 AI 생태계를 빠르게 선점해 나갔습니다. 반면 자바는 복잡한 JNI 아키텍처 한계와 장황한 문법 탓에, 속도가 생명이었던 초기 AI 연구원들의 선택을 받지 못하며 트렌드에서 뒤처지게 되었습니다.

3. Java가 AI 시대의 언어로 변신하기 위해 준비하는 기술들

현재 자바 진영의 AI 전략은 파이썬처럼 거대 언어 모델(LLM)을 바닥부터 직접 학습시키는 스크립트를 짜는 것이 아닙니다. 자바의 진정한 강점은 전 세계 기업들이 이미 구축해 놓은 거대한 엔터프라이즈 인프라 위에서, 오픈AI나 구글 제미나이(Gemini) 같은 외부 LLM을 가장 안정적으로 연결, 제어, 오케스트레이션하는 인터페이스 표준을 확립하는 것에 있습니다.

이 중심에 있는 기술이 바로 '스프링 AI(Spring AI)'와 'LangChain4j' 같은 엔터프라이즈급 AI 프레임워크입니다. 이들은 타사 LLM과의 연동 인터페이스를 고도로 추상화하여, 개발자가 코드 한 줄만 바꾸면 다양한 진영의 AI 모델을 스왑(Swap)할 수 있도록 돕습니다. 또한, 기업 내부 데이터를 안전하게 결합하는 RAG(검색 증강 생성) 아키텍처와 벡터 데이터베이스 연동을 자바 특유의 유연한 인터페이스 구조로 표준화했습니다.

여기에 하드웨어 레벨의 성능을 내기 위한 오라클 주도의 로우레벨 혁신이 뒷받침되고 있습니다. '프로젝트 파나마(Project Panama)'는 기존의 무거웠던 JNI를 완전히 대체하여, C/C++ 기반의 고성능 외래 AI 엔진(예: llama.cpp 등)과 메모리에 직접 접근할 수 있는 표준 API를 제공합니다. 또한 '벡터 API(Vector API)'는 최신 CPU의 SIMD(단일 명령 다중 데이터) 아키텍처를 활용해 행렬 연산 속도를 네이티브급으로 끌어올렸습니다.

더불어 자바는 로봇, 가전, 팩토리 자동화 등 하드웨어와 결합하는 피지컬 AI(Physical AI)와 IoT 생태계에서도 강력한 미래를 준비하고 있습니다. 당초 가전제품 제어를 위해 탄생했던 자바의 모태(Oak)답게, 기기 독립적인 가상 머신 환경은 피지컬 에이전트를 구동하기에 최적입니다. 최근 자바는 메모리를 극도로 아끼면서 수만 개의 동시 대량 요청을 처리할 수 있는 가상 스레드(Virtual Threads) 기술을 도입했습니다. 이를 통해 수많은 센서와 액추에이터가 실시간으로 통신하는 피지컬 AI 환경에서 자바는 고성능 프레임워크와 결합해 강력한 실시간 제어 능력을 발휘하고 있습니다. 자바는 단순한 언어적 변신을 넘어, 엔터프라이즈 안정성과 최신 자율형 AI 에이전트 아키텍처를 아우르는 견고한 통합 AI 플랫폼으로 진화하는 중입니다.

4. 요약: 엔터프라이즈의 무기를 쥔 자바의 AI 역습

요약하자면 자바가 초기 AI 시대의 주역이 되지 못한 것은, 완벽함보다는 빠른 실험과 유연성이 중요했던 수학·통계학 기반 연구원들의 니즈와 자바의 엄격한 정적 타입 문법이 맞지 않았기 때문입니다.

하지만 AI 기술이 연구실을 넘어 '실제 기업 서비스(Production)' 단계로 진화하면서 판도가 바뀌고 있습니다. 자바 진영은 직접 모델을 만드는 대신, 프로젝트 파나마와 벡터 API를 통해 로우레벨 연산 속도를 확보하고, 스프링 AI를 앞세워 다양한 외부 LLM을 안전하게 통제·결합하는 최강의 인터페이스 전략을 취하고 있습니다. 여기에 가상 스레드를 무기로 하드웨어를 직접 제어하는 피지컬 AI 영역까지 영토를 확장하고 있습니다.

Java를 다시 복습하며 느낀 점은, 자바는 결코 낡은 언어가 아니라 시대의 요구에 맞춰 자신의 가장 강력한 무기인 '신뢰성과 구조화'를 바탕으로 AI를 흡수하고 있다는 점입니다. 기업용 대형 시스템에 AI를 이식해야 하는 순간이 오면, 결국 다시 자바가 주인공이 될 날이 머지않은 것 같습니다.

[개발 상식] 1960년대 기계어부터 현대 AI 기반 코드 최적화까지 한눈에 보기 / https://www.steemit.com/kr/@talkit/ai--px1egt

[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화 / https://www.steemit.com/kr/@talkit/java-se-eejakarta-ee--p5j85z

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

[Java] JDK 버전별 AES 256 암호화 적용 방법과 "Illegal key size" 에러 해결책

가야태자 — Fri, 26 Jun 2026 09:18:11 +0900

[Java] JDK 버전별 AES 256 암호화 적용 방법과 "Illegal key size" 에러 해결책

안녕하세요 가야태자 @talkit 입니다. Java관련된 글을 계속 적고 있는데, 해당글들에 이어서 그리고, 제가 이번 프로젝트를 를 진행하면서 겪었던 Java 1.7에서 AES256 암호화 시에 여러분은 오류가 발생하지 않았으면 하는 바램에 이글을 적습니다. 해당 글은 1.6, 1.7에서 AES 256 암호화시 겪게 되는 오류와 해결책, 그리고 JDK 각 버전별 예제를 담고 있습니다.

Java로 보안 관련 기능을 개발하다 보면 가장 흔하게 접하는 암호화 알고리즘이 바로 AES 256입니다. 하지만 분명 로컬(최신 JDK)에서는 잘 돌아가던 코드가 운영 서버(구버전 JDK)에만 올라가면 마법처럼 에러를 뿜어내는 경우가 있습니다.

오늘 그 원인과 JDK 버전별 차이점, 그리고 레거시 환경에서의 해결책까지 완벽하게 정리해 보겠습니다.

왜 구버전 Java에서는 AES 256이 실패할까?

AES 256 암호화를 적용하고 구버전 자바 환경에서 구동하면 높은 확률로 아래와 같은 치명적인 예외를 만나게 됩니다.

java.security.InvalidKeyException: Illegal key size

이 에러가 발생하는 이유는 과거 미국의 암호화 기술 수출 통제법 때문입니다. 미국은 강력한 암호화 기술이 해외로 유출되는 것을 막기 위해, 기본적으로 Java에 128비트(16바이트)를 초과하는 키를 사용할 수 없도록 제한을 걸어두었습니다. AES 256은 256비트(32바이트) 키를 사용하기 때문에 "키 사이즈가 불법(Illegal)"이라며 거부하는 것입니다.

JDK 버전별 AES 256 지원 차이점

자바가 발전하면서 이 규제와 내부 정책도 많이 변했습니다. 내가 쓰는 JDK 버전이 어디에 속하는지 확인해 보세요.

JDK 버전	AES 256 지원 상태	특징
JDK 1.6 / 1.7	❌ 기본 차단	기본 128비트 제한. AES 256 사용 시 수동 패치 필수.
JDK 1.8	⚠️ 버전별 상이	- 8u151 미만: 수동 패치 필요 - 8u151 이상: 설정 파일로 활성화 가능 - 8u161 이상: 기본 활성화
JDK 11 / 17 / 21	⭕ 기본 활성화	제약 없음. 성능 최적화 및 최신 암호화 모드(GCM) 권장.

⚠️ Java 1.6 & 1.7 환경에서의 핵심 주의사항 및 해결책

제가 이번에 Java 1.7 프로젝트를 진행하며 깊게 겪었던 부분입니다. 구버전 환경에서 이 에러를 해결하려면 반드시 아래 사항을 숙지하고 조치해야 합니다.

1. 무제한 강도 정책(JCE) 파일 수동 패치 (올바른 해결책)

Oracle 공식 홈페이지에서 버전에 맞는 'Unlimited Strength Jurisdiction Policy Files'를 직접 다운로드받아 서버의 Java 경로에 덮어씌워야 합니다.

Oracle 공식 다운로드 링크 검색 키워드: Java Cryptography Extension (JCE) Unlimited Strength
파일을 덮어쓸 경로: ${JAVA_HOME}/jre/lib/security/
교체할 파일: local_policy.jar, US_export_policy.jar

Tip: 만약 운영 환경이 Oracle JDK가 아닌 OpenJDK라면, 오픈소스 특성상 이 수출 규제 파일이 적용되지 않아 수동 패치 없이도 바로 AES 256이 작동할 수 있습니다. 서버의 Java 벤더사를 먼저 확인해 보세요!

2. 리플렉션(Reflection) 우회 꼼수 코드는 금물!

인터넷을 찾아보면 JCE 다운로드가 귀찮아서 Java 내부의 isRestricted 필드를 리플렉션 코드로 강제로 false로 바꾸는 팁이 공유되곤 합니다.
하지만 실무 운영 환경에서는 절대 사용하시면 안 됩니다. JVM 내부 보안 구조를 강제로 비트는 행위라, 자바 마이너 업데이트나 환경 변화에 따라 갑자기 애플리케이션이 뻗어버릴 수 있는 시한폭탄 같은 코드입니다. 반드시 위의 1번 방법(JCE 패치)으로 해결하셔야 합니다.

3. 가장 중요한 보안 규칙: 암호화 키 관리 (필독!)

코드 구현보다 더 중요한 것은 암호화 키를 안전하게 다루는 것입니다. 실무에 적용하실 때 다음 규칙을 반드시 지켜주세요.

예제 키 사용 금지: 암호화키는 여러분의 키를 직접 만들어서 쓰셔야 합니다. 제가 아래 예제 코드에서 사용한 키나, 다른 인터넷 블로그 등에서 샘플로 받은 키를 그대로 사용하시면 심각한 보안상 문제가 발생합니다. 예제 키는 누구나 알 수 있기 때문에 암호화의 의미가 완전히 사라집니다.
소스코드와 키 분리 보관: 암호화 키는 절대 소스코드 내에 하드코딩하면 안 됩니다. 해당 키는 소스와 완전히 분리되어 OS 환경 변수(Environment Variable), 외부 설정 파일(Properties, YAML), 혹은 AWS Secrets Manager나 HashiCorp Vault 같은 전문 키 관리 시스템(KMS)에 보관되어야 합니다.
외부 노출 절대 금지: 키가 담긴 설정 파일을 실수로 GitHub 같은 공용 저장소에 업로드하는 일이 없도록 .gitignore 설정을 철저히 하셔야 합니다. 절대로 키를 외부에 공개하시면 안 됩니다.

JDK 버전별 AES 256 구현 예제

1️⃣ JDK 1.6, 1.7, 1.8 (레거시 환경 - AES/CBC/PKCS5Padding)

구버전 환경에서 가장 범용적으로 쓰이는 CBC 모드 예제입니다. (※ 1.6, 1.7은 위에 설명한 JCE 패치가 완료된 상태여야 작동합니다.)

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.util.Base64; // JDK 1.8 미만은 별도의 Base64 라이브러리(Apache Commons 등) 필요

public class Aes256Legacy {
    // ⚠️ 주의: 아래 키와 IV는 예시일 뿐입니다. 실무에서는 소스코드와 분리하여 고유한 키를 사용하세요!
    private static final String KEY = "abcdefghijklmnopqrstuvwxyz123456"; // 32바이트 키 (256비트)
    private static final String IV = "1234567890123456"; // 16바이트 IV (CBC 모드 필수)

    public static String encrypt(String text) throws Exception {
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        SecretKeySpec keySpec = new SecretKeySpec(KEY.getBytes("UTF-8"), "AES");
        IvParameterSpec ivSpec = new IvParameterSpec(IV.getBytes("UTF-8"));

        cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
        byte[] encrypted = cipher.doFinal(text.getBytes("UTF-8"));

        // JDK 1.8 기준 Base64Encoder 사용 (1.7 이하는 외부 라이브러리 활용)
        return Base64.getEncoder().encodeToString(encrypted);
    }
}

2️⃣ JDK 11, 17, 21 (최신 환경 - AES/GCM/NoPadding)

최신 자바 버전에서는 단순 CBC 모드보다 무결성 검증까지 함께 수행하여 보안성이 훨씬 강력한 GCM 모드 사용을 강력히 권장합니다. 별도의 JCE 설정 없이 즉시 실행됩니다.

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;

public class Aes256Modern {
    // ⚠️ 주의: 아래 키는 예시일 뿐입니다. 실무에서는 소스코드와 분리하여 고유한 키를 사용하세요!
    private static final String KEY = "abcdefghijklmnopqrstuvwxyz123456"; // 32바이트
    private static final int GCM_IV_LENGTH = 128; // IV bits
    private static final int GCM_TAG_LENGTH = 16; // Tag bytes (128 bits)

    public static String encrypt(String text) throws Exception {
        // GCM 모드는 매번 새로운 IV 사용을 강력히 권장
        byte[] iv = new byte[GCM_IV_LENGTH / 8];
        new SecureRandom().nextBytes(iv);

        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        SecretKeySpec keySpec = new SecretKeySpec(KEY.getBytes("UTF-8"), "AES");
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH * 8, iv);

        cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec);
        byte[] ciphertext = cipher.doFinal(text.getBytes("UTF-8"));

        // IV와 암호문을 함께 저장/전송해야 복호화가 가능합니다.
        byte[] cipherWithIv = new byte[iv.length + ciphertext.length];
        System.arraycopy(iv, 0, cipherWithIv, 0, iv.length);
        System.arraycopy(ciphertext, 0, cipherWithIv, iv.length, ciphertext.length);

        return Base64.getEncoder().encodeToString(cipherWithIv);
    }
}

마치며

오래된 시스템을 유지보수하거나 레거시 환경으로 마이그레이션할 때, 자바의 버전별 보안 정책 차이를 모르면 뜬금없는 에러에 며칠을 허비하게 됩니다.
특히 Java 1.6이나 1.7 환경에서 AES 256을 구현하실 때는 서버의 JCE 정책 파일 확인 단계를 거치셔서, 저처럼 삽질(?)하지 않고 한 번에 성공하시길 바라는 마음입니다. 아울러 아무리 코드가 완벽해도 암호화 키가 노출되면 무용지물이 되니 키 관리도 꼭 신경 써주세요!
궁금한 점이 있으시다면 언제든 댓글로 남겨주세요. 감사합니다!

[개발 상식] 1960년대 기계어부터 현대 AI 기반 코드 최적화까지 한눈에 보기

가야태자 — Thu, 25 Jun 2026 09:50:06 +0900

[프로그래밍 역사] 천공카드부터 AI까지, 컴퓨터 언어의 위대한 연대기

안녕하세요 가야태자 @talkit 입니다.

요즘 Java를 다시 정리겸 공부하고있는데, Java의 역사를 공부하다 보니 다른 언어의 역사와 프로그래밍의 발전이 궁금 해졌습니다. 기계어와 천공카드라는 거친 환경에서 출발해, 현대의 자바와 AI 협업 코딩에 이르기까지 우리가 사용하는 컴퓨터 언어들이 어떻게 발전해 왔는지 각 연대 별로 정리하면 아래와 같습니다.

1. 1950년대 이전~1960년대: 프로그래밍의 새벽과 하드웨어 제어

초기의 컴퓨터 프로그래밍은 인간의 언어와는 거리가 먼, 철저히 기계 중심적인 작업이었습니다. 1940년대 코딩은 전선을 직접 꽂고 뽑는 하드웨어 재배치나 0과 1로 구성된 정교한 기계어를 직접 입력하는 방식이었습니다. 이 지독한 복잡함을 개선하기 위해 기계어와 일대일 대응하는 어셈블리어가 등장했고, 데이터를 입력하기 위해 종이에 구멍을 뚫어 표현하는 천공카드(Punch Card) 시스템이 널리 활용되었습니다.

1950년대 후반을 지나 1960년대에 접어들면서 비로소 인간이 이해할 수 있는 '고급 언어'의 기틀이 마련됩니다. 수학적 계산을 위해 설계된 최초의 고급 언어 포트란(Fortran), 대규모 기업 비즈니스 데이터 처리를 위해 탄생하여 미 국방부 표준으로 자리 잡은 코볼(COBOL)이 이 시기를 지배했습니다. 당시 프로그래머들은 천공카드 한 장에 코드 한 줄을 정성껏 컴퓨터에 입력하며, 기계 제어 중심에서 인류의 비즈니스 문제를 소프트웨어로 해결하는 첫 패러다임의 전환을 맞이했습니다.

2. 1970년대: 구조적 프로그래밍과 C언어의 탄생

1970년대는 전산학 역사상 가장 위대한 유산이 탄생한 시기입니다. 60년대까지의 고급 언어들은 코드의 실행 흐름이 중구난방으로 튀는 'GOTO' 문을 남발하여 시스템이 거대해질수록 유지보수가 불가능한 '스파게티 코드' 양산이라는 고질적인 문제를 안고 있었습니다. 이를 해결하기 위해 프로그램을 순차, 선택, 반복이라는 명확한 구조로 나누어 작성하는 구조적 프로그래밍(Structured Programming) 패러다임이 확립되었습니다.

이 철학의 정점에서 탄생한 것이 바로 1972년 데니스 리치와 켄 톰슨이 개발한 C언어입니다. C언어는 하드웨어를 직접 제어할 수 있는 강력한 로우레벨(Low-level) 제어 능력을 갖추면서도, 인간이 읽기 쉬운 하이레벨(High-level) 언어의 이점을 완벽하게 결합한 혁명적인 언어였습니다. UNIX 운영체제 개발과 맞물려 C언어는 폭발적인 인기를 얻었고, 소프트웨어의 이식성(Portability)을 극적으로 끌어올리며 현대 운영체제와 시스템 프로그래밍의 굳건한 표준으로 자리 잡았습니다.

3. 1980년대: 복잡성과의 전쟁, 객체 지향 프로그래밍(OOP)의 부상

1980년대는 개인용 컴퓨터(PC)의 보급과 함께 소프트웨어의 규모와 복잡도가 상상할 수 없을 정도로 거대해진 시기입니다. 기존의 구조적 프로그래밍과 데이터 중심의 접근 방식으로는 대규모 시스템을 안정적으로 구축하는 데 한계가 찾아왔고, 이를 타개하기 위해 객체 지향 프로그래밍(OOP)이 핵심 패러다임으로 부상했습니다.

현실 세계의 개념을 데이터와 기능이 묶인 '객체(Object)'로 모델링하여 재사용성과 유지보수성을 극대화하자는 이 철학은 시장을 완전히 바꾸어 놓았습니다. 1983년 비아네 스트롭스트룹은 C언어에 객체 지향 개념을 얹은 C++을 발표하며 고성능 시스템과 대규모 애플리케이션 개발의 지배자로 우뚝 섰습니다. 또한, 애플 매킨토시의 기반이 된 Objective-C가 주목받기 시작했고, 소프트웨어를 컴포넌트 조립식으로 개발하는 시대가 본격적으로 열렸습니다.

4. 1990년대: 인터넷의 폭발과 Java의 등장

1990년대는 월드 와이드 웹(WWW)의 보급과 함께 '네트워크 분산 환경'이 소프트웨어 개발의 핵심 화두로 떠오른 격동의 시기였습니다. 기존의 C/C++은 운영체제와 하드웨어 아키텍처가 바뀌면 프로그램을 매번 다시 컴파일해야 하는 심각한 파편화 문제를 겪고 있었습니다. 이러한 시대적 한계를 해결하기 위해 1995년 선 마이크로시스템즈는 "Write Once, Run Anywhere"를 슬로건으로 내건 Java(자바)를 출시합니다.

자바는 가상 머신(JVM)을 도입하여 하드웨어 종속성을 완벽히 극복했고, 메모리를 자동으로 관리해 주는 가비지 컬렉터 덕분에 안정적인 대형 웹 서버 구축의 독점적인 표준이 되었습니다. 한편, 웹 브라우저 안에서 역동적인 화면을 구현하기 위해 탄생한 JavaScript(자바스크립트)가 급부상했으며, 쉬운 문법과 빠른 개발 속도를 무기로 삼은 인터프리터 언어 Python(파이썬)과 웹 전용 언어인 PHP 등이 등장하여 웹 생태계의 대폭발을 이끌었습니다.

5. 2000년대: 엔터프라이즈의 다각화와 웹 생태계의 정착

2000년대는 90년대에 구축된 웹 기술이 고도화되고, 대규모 기업용 시스템(Enterprise) 시장이 성숙기에 접어든 시기입니다. 마이크로소프트는 자바의 독주를 견제하고 윈도우 생태계를 공고히 하기 위해 2000년 넷(.NET) 프레임워크와 함께 C# 언어를 발표했습니다. 이로 인해 시장은 자바 기반의 진영과 윈도우 기반의 C# 진영으로 양분되며 대형 아키텍처 경쟁이 심화되었습니다.

동시에 웹 표준과 비동기 통신 기술(AJAX)의 발전으로 단순한 문서 전달자에 불과했던 웹 페이지가 '웹 애플리케이션'의 형태로 진화하기 시작했습니다. 브라우저의 한계를 극복하려는 자바스크립트의 고도화가 진행되었고, 루비 온 레일즈(Ruby on Rails) 프레임워크의 성공과 함께 Ruby 같은 생산성 중심의 다이나믹 언어들이 주목받았습니다.

6. 2010년대: 모바일 혁명과 모던 언어의 세대교체

2010년대는 스마트폰의 폭발적인 보급으로 인한 모바일 혁명과 클라우드 컴퓨팅, 그리고 빅데이터/인공지능의 급부상이 프로그래밍 언어의 판도를 완전히 바꾸어 놓은 시기입니다. 스마트폰 앱 개발을 위해 구글의 안드로이드는 자바를, 애플의 iOS는 Objective-C를 채택하며 자바의 위상은 한층 더 공고해졌습니다. 하지만 기존의 오랜 언어들이 가진 무겁고 복잡한 문법을 탈피하기 위해 대기업 주도의 신생 '모던 프로그래밍 언어'들이 대거 등장했습니다.

애플은 iOS 개발을 위해 안전하고 직관적인 Swift를, 구글은 안드로이드 공식 언어로 Kotlin(코틀린)을 채택했으며, 사내 인프라 고도화를 위해 동시성 처리가 강력한 Go(고랭) 언어를 발표했습니다. 또한, 웹 생태계에서는 자바스크립트에 타입 시스템을 도입해 안정성을 높인 TypeScript(타입스크립트)가 대세로 부상했습니다. 한편, 방대한 데이터 처리와 머신러닝 생태계를 독점한 파이썬은 단숨에 전 세계에서 가장 인기 있는 언어의 자리에 올랐습니다.

7. 2020년대: 클라우드 네이티브와 에이전틱 AI(Agentic AI), 그리고 MCP의 시대

현재 2020년대의 프로그래밍 세계는 클라우드 네이티브(Cloud-Native) 인프라의 완전한 정착과 더불어, 단순한 코드 추천을 넘어 개발의 전 과정을 스스로 수행하는 자율형 AI 에이전트(Agentic AI)의 등장으로 유례없는 대격변을 맞이하고 있습니다. 마이크로서비스 아키텍처(MSA) 환경에 맞춰 메모리 안정성과 가공할 성능을 지닌 Rust(러스트)가 핵심 인프라 언어로 급부상했고, 자바 역시 가상 스레드(Virtual Threads)를 도입하며 클라우드 최적화 혁신을 이어가고 있습니다.

그러나 가장 파괴적인 변화는 '개발 패러다임' 그 자체에 있습니다. 초기의 단순 텍스트 완성형 어시스턴트를 넘어, 스스로 판단하고 코드를 작성 및 디버깅하는 에이전틱 AI(Agentic AI)가 개발 프로세스의 중심에 섰습니다. 특히 다양한 인공지능 모델들이 개발자의 로컬 개발 환경, 소스 코드 저장소, 개발 도구(IDE)의 컨텍스트를 안전하고 표준화된 방식으로 연결할 수 있도록 돕는 MCP (Model Context Protocol, 모델 컨텍스트 프로토콜)가 핵심 기술 표준으로 정착했습니다.

이제 프로그래머는 고립된 환경에서 타이핑하는 것을 넘어, MCP를 통해 프로젝트 전체의 맥락을 완벽히 이해하고 있는 AI 에이전트(예: 제미나이 기반 도구)에게 복잡한 설계와 아키텍처 리팩토링 작업을 지시하고 오케스트레이션(통제 및 조율)하는 고차원적 아키텍트의 역할을 수행하고 있습니다.

8. 요약: 프로그래밍 언어 발전을 돌아보며

돌아보면 컴퓨터 프로그래밍의 역사는 '인간 중심의 추상화'와 '생산성 극대화'를 향한 끊임없는 여정이었습니다.

0과 1의 기계어와 천공카드라는 투박한 물리적 제약에서 출발한 언어는, 하드웨어를 지배한 C언어의 구조적 패러다임을 거쳐, 거대한 시스템을 조립식으로 만드는 C++의 객체 지향 세계로 발전했습니다. 인터넷의 폭발과 함께 등장한 Java는 가상 머신(JVM)을 통해 하드웨어의 종속성을 무너뜨렸고, 2020년대에 이르러서는 MCP(Model Context Protocol)와 에이전틱 AI(Agentic AI) 생태계가 결합하면서 개발자가 반복적인 코드 구현에서 벗어나 오직 '비즈니스 논리와 고도화된 아키텍처 설계'에만 집중할 수 있는 진정한 추상화의 정점에 도달했습니다.

Java를 다시 공부하며 시작된 이 역사 탐구를 통해, 우리가 지금 당연하게 사용하는 문법과 도구들 속에 수많은 선배 개발자들의 치열한 고민과 격변의 비화가 녹아있음을 다시금 느끼게 됩니다. 앞으로 자바 공부를 이어가면서 마주할 다양한 기술적 아키텍처들도 이 거대한 역사의 흐름 속에서 한층 더 깊이 있게 이해할 수 있을 것 같습니다.

[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화

가야태자 — Wed, 24 Jun 2026 09:44:57 +0900

저도 정리도 할겸 해서 Java에 대해서 글을 써보고 있습니다.

재미가 있으실지는 모르겠지만, 읽으시는 분들이 재미가 있어야 할텐데요 ^^

저는 정리하면서 오 그랬지를 외치고 있습니다.

그럼 본격적으로 글을 시작합니다.

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

1. 서론: 가전제품 제어에서 전 세계 웹의 표준이 되기까지

오늘날 자바(Java)는 단순한 프로그래밍 언어를 넘어 전 세계 거대한 IT 인프라를 지탱하는 거대한 플랫폼입니다. "한 번 작성하면, 어디서나 실행된다(Write Once, Run Anywhere)"라는 강력한 철학을 바탕으로 지난 30년간 수많은 격변을 겪으며 발전해 왔습니다.

자바의 역사를 이해하는 것은 단순히 과거의 기록을 보는 것을 넘어, 현대 엔터프라이즈 소프트웨어 아키텍처가 왜 지금과 같은 모습으로 자리 잡았는지 이해하는 핵심 열쇠입니다. 개인용 개발을 위한 표준 에디션(Java SE)과 대규모 기업 시스템을 위한 에디션(Java EE)이라는 두 축이 시대의 흐름에 따라 어떻게 발맞추어 성장하고 변천해 왔는지, 그 흥미진진한 역사의 타임라인과 숨겨진 비화를 정리해 드립니다.

2. 본론

① Java SE & Java EE 통합 연혁 타임라인

자바의 표준 스펙(SE)과 기업용 분산 환경 스펙(EE)은 기술의 발전과 패러다임의 변화에 맞춰 유기적으로 결합하며 진화해 왔습니다. 최초의 버전부터 현재에 이르기까지의 핵심 마일스톤입니다.

JDK 1.0 (1996): 최초의 공식 버전, 제임스 고슬링의 '오크(Oak)' 프로젝트에서 시작된 자바 언어의 탄생
JDK 1.1 (1997): 내부 클래스, 데이터베이스 연동을 위한 JDBC, 컴포넌트 모델인 JavaBeans 도입
J2SE 1.2 / J2EE 1.2 (1998~1999): 스윙(Swing) GUI 및 컬렉션 프레임워크 추가 / 최초의 기업용 스펙(Servlet, JSP 1.1) 표준화
J2SE 1.4 / J2EE 1.4 (2002~2003): 정규표현식 및 비동기 NIO 지원 / 웹 서비스(Web Services) 기본 프로필 지원
Java SE 5 / Java EE 5 (2004~2006): 제네릭, 열거형(Enum), 어노테이션 도입 / EJB 3.0 도입으로 기업용 개발의 복잡성 대폭 완화
Java SE 6 / Java EE 6 (2006~2009): JVM 가비지 컬렉션 성능 향상 및 스크립트 지원 / 웹 프로필(Web Profile) 개념 및 CDI(의존성 주입) 최초 도입
Java SE 7 / Java EE 7 (2011~2013): 다이아몬드 연산자 및 try-with-resources 추가 / HTML5 지원 파이프라인 구축 및 WebSocket 표준 채택
Java SE 8 / Java EE 8 (2014~2017): 람다식, 스트림(Stream) API 혁신 / 오라클 주도의 마지막 기업용 버전, HTTP/2 지원 및 JSON-B 추가
Java SE 11 / Jakarta EE 8 (2018~2019): 6개월 정기 출시 주기 정착 / 이클립스 재단으로 이관 후 첫 버전 (기능은 Java EE 8과 동일)
Java SE 17 / Jakarta EE 9 (2021~2020): 봉인된 클래스 정식 추가 / 패키지 명칭 대전환 (javax.* -> jakarta.* 변경)
Java SE 21 / Jakarta EE 10 (2023~2022): 가상 스레드(Virtual Threads) 도입으로 동시성 혁신 / 클라우드 네이티브 아키텍처 공식 지원
Java SE 25 / Jakarta EE 11 (2025~2024): 최신 장기 지원(LTS) 버전으로 안정성 확보 / 가상 스레드 기술을 기업용 스펙에 본격 통합
Java SE 26 (2026): 최신 버전, HTTP/3 지원 및 런타임 성능의 지속적인 개선

② Java EE에서 Jakarta EE로의 대전환과 상표권 분쟁 비화

자바가 전 세계 금융권과 대기업 시스템의 백엔드를 독점할 수 있었던 원동력은 Java EE였습니다. 하지만 2010년 오라클(Oracle)이 선 마이크로시스템즈를 인수하면서 자바 생태계에는 거대한 제약과 격변이 일어납니다. 오라클 체제 하에서 기업용 자바 표준의 발전이 정체되자, 오픈소스 커뮤니티는 더 개방적인 혁신을 요구했습니다. 결국 2017년, 오라클은 Java EE의 소스 코드와 운영 권한을 오픈소스 재단인 이클립스 재단(Eclipse Foundation)에 완전히 넘겨주기로 결정합니다.

그러나 이 아름다운 이관 과정 뒤에는 거대한 상표권 갈등이 숨어 있었습니다. 오라클이 소스 코드는 넘겼지만, 'Java'라는 브랜드 상표권만큼은 자신들의 소유라며 양도하지 않은 것입니다. 이로 인해 이클립스 재단은 기존의 명칭인 'Java EE'를 더 이상 사용할 수 없게 되었고, 소스 코드 내부에서 수십 년간 표준으로 사용되던 핵심 패키지 명칭인 java.*와 javax.* 역시 새로 업데이트하는 코드에 사용할 수 없게 되는 사상 초유의 제약을 받게 됩니다.

결국 이클립스 재단은 커뮤니티 투표를 거쳐 Java EE의 새 이름으로 Jakarta EE(자카르타 EE)를 공표합니다. 그리고 명칭만 바꾼 것에 그치지 않고, Jakarta EE 9에 이르러 소스 코드 내부의 핵심 API 경로를 javax.servlet.*에서 jakarta.servlet.* 형태로 통째로 바꾸는 대대적인 이주(Migration) 작업을 단행합니다.

이 변화는 초기에 전 세계 수많은 라이브러리와 프레임워크(대표적으로 스프링 부트 3.0 이상 버전)가 코드를 완전히 리팩토링해야 하는 극심한 호환성 진통을 유발했습니다. 하지만 결과적으로 오라클이라는 단일 기업의 독점적 제약에서 완전히 벗어나, 전 세계 개발자와 기업들이 함께 주도하는 진정한 의미의 '개방형 클라우드 네이티브 기업용 자바 표준'으로 완벽하게 재탄생하는 위대한 계기가 되었습니다.

3. 요약: 독점에서 개방으로, 쉼 없이 진화하는 자바 생태계

자바의 역사는 단순히 소프트웨어 버전 업그레이드의 기록이 아니라, 하드웨어의 한계와 기업의 독점 시도를 기술적 아키텍처와 커뮤니티의 힘으로 우아하게 해결해 온 투쟁의 역사입니다.

C/C++의 메모리 관리 한계를 극복하기 위해 가전제품 제어용 '오크' 언어로 출발한 자바는 웹의 폭발적인 성장과 함께 표준 스펙(SE)을 다져왔으며, 대규모 기업 환경을 겨냥한 EE 스펙을 통해 시장의 절대 강자로 군림했습니다. 비록 오라클 인수 이후 상표권 분쟁이라는 초유의 진통을 겪으며 javax 패키지를 jakarta로 통째로 바꾸는 아픔을 겪었지만, 이 계기를 통해 자바는 특정 기업의 전유물이 아닌 진정한 오픈소스 커뮤니티 중심의 '개방형 표준'으로 거듭날 수 있었습니다.

탄생한 지 30년이 넘은 지금도 최신 가상 스레드 기술(Virtual Threads)과 클라우드 네이티브 아키텍처를 적극 흡수하며 진화하고 있는 자바는, 앞으로도 오랫동안 전 세계 백엔드 생태계의 견고한 표준으로 자리를 지킬 것입니다.

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

가야태자의 IT이야기

[먹스팀] 충정로 수제 버거 맛집 - 버거운 녀석들 중림점

[개발/IT] 디컴파일러(Decompiler)란 무엇일까? 언어별 주요 디컴파일러 총정리

1. 디컴파일러(Decompiler)의 개념

2. 언어별 대표 디컴파일러 모음

① C# / .NET 생태계

② Java 생태계

③ C / C++ 및 네이티브 기계어 (보안/리버스 엔지니어링)

3. 마무리하며

참고 글

[먹스팀] 가산디지털단지역 간짜장 맛집 - 자금성

[먹스팀] 충정로 베트남 쌀 국수 집 앤디스포

[DevOps] 시스템 모니터링(System Monitoring)의 개념 및 오픈소스 솔루션 비교 (nmon / Zabbix / Prometheus)

1. 시스템 모니터링(System Monitoring)이란 무엇인가요?

시스템 모니터링의 핵심 4대 메트릭

2. 대표적인 오픈소스 시스템 모니터링 툴 상세 분석

① nmon (Nigel's Monitor)

② Zabbix (자빅스)

③ Prometheus + Grafana (프로메테우스 + 그라파나)

3. 한눈에 보는 시스템 모니터링 툴 비교 표

4. 소프트웨어 공식 다운로드 링크 안내

시스템 모니터링 깊이 있게 공부하기 (추천 학습 링크)

[DevOps] CI/CD의 핵심 엔진, CI(지속적 통합) 깊이 파헤치기 (Feat. DevSecOps)

[DevOps] CI/CD의 핵심 엔진, CI(지속적 통합) 깊이 파헤치기 (Feat. DevSecOps)

1. CI(지속적 통합)의 시작이자 심장: 버전 관리(VCS)

재미로 보는 버전 관리 역사와 CI의 탄생

2. CI(지속적 통합)의 본질: 단순 기술이 아닌 '개발 문화'

3. 지속적 통합(CI)을 진행하는 구체적인 프로세스 (Workflow)

4. 지속적 통합(CI)에 필요한 핵심 기술과 툴 (참조 및 다운로드 URL)

5. 알아두면 유용한 CI 핵심 용어 정리

6. 한 단계 더 나아간 개념: DevOps vs DevSecOps

자동차 공장에 비유하자면?

한눈에 보는 핵심 차이점 비교

7. CI/CD 및 CI를 깊이 있게 공부할 수 있는 추천 한국어 가이드

마치며

[DevOps] CI/CD란 무엇일까? 개념, 필요성, 그리고 대표적인 CI/CD 툴 비교 분석

1. CI/CD란 무엇인가요?

2. CI/CD는 왜 필요할까요?

3. 대표적인 CI/CD 툴 소개 (오픈소스 다운로드 & 제공사 URL)

① 오픈소스 및 무료 설치형 (Self-Hosted)

② 무료/유료 하이브리드 SaaS형 (Cloud-Native)

③ 유료 중심의 전문 엔터프라이즈형

4. 나에게 맞는 CI/CD 툴을 고르는 기준

5. CI/CD를 깊이 있게 공부할 수 있는 추천 관련 글 & 가이드

마치며

PHP에서 Java로, 다시 Python으로 — 하나의 언어를 완벽히 숙지하면 벌어지는 일

1막. 나의 주니어 시절: C, Perl, 그리고 인생 언어 'PHP'

"PHP의 echo가 Java에서는 뭐였더라?"

2막. 세월이 흘러 Java 전문가가 된 나, Python을 만나다

주니어와 시니어의 차이: "무엇을 검색해야 하는지 안다"

글을 마치며: 지금 흔들리는 모든 개발자들에게

함께 보면 좋은 추천 학습 링크

CVS, SVN 기억하시나요? 재미로 보는 버전 관리 역사와 현대 Git 저장소 3대장 비교

CVS, SVN 기억하시나요? 재미로 보는 버전 관리 역사와 현대 Git 저장소 3대장 비교

1. 버전 관리 시스템(VCS)의 발전 흐름

2. 현대 개발의 허브, 온라인 Git 저장소의 개념

3. 주요 온라인 저장소 서비스 3대장 소개

GitHub (깃허브)

GitLab (깃랩)

Bitbucket (비트버킷)

4. 한눈에 보는 저장소별 기능 및 정책 비교

AA의 시선: 엔터프라이즈 환경에서의 내부 설치(On-Premise) 고려사항

[윈도우즈용 터미널 비교] 나에게 맞는 최적의 툴은?

1. 터미우스 (Termius) — 크로스플랫폼 기반의 스마트 원격 관리자

2. 모바엑스텀 (MobaXterm) — 다양한 기능을 갖춘 올인원 터미널

3. 푸티 (PuTTY) — 심플하고 가벼운 오픈소스 SSH 클라이언트

4. CRT (SecureCRT) — 상업용 고성능 SSH 클라이언트

5. Xshell (엑스쉘) — 윈도우즈 전용 강력한 SSH 클라이언트

윈도우즈 터미널 비교 요약

가야태자의 최종 결론: 어떤 걸 선택해야 할까요?

가야태자의 선택

관련글

오늘의 작은 행복, 우연히 만난 수국

[성능 개선 이야기] APM이란 무엇인가? 사상, 기능, 그리고 언어별 작동 원리

[성능 개선 이야기] APM이란 무엇인가? 사상, 기능, 그리고 언어별 작동 원리 (Java, C++, Python, Node.js)

1. APM은 어떤 사상에서 출발했을까?

2. APM의 핵심 기능은 무엇일까?

3. 언어별 어떤 특징을 이용해 모니터링을 진행할까?

짚고 넘어가는 핵심 요약

① Java 환경: 바이트코드 조작 (Bytecode Instrumentation)

3단계: OS별 환경 변수 (`JAVA_HOME` & `PATH`) 완벽 설정