푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1371편 · 125 / 138 페이지)
-
하드웨어 *10 년 가격 *연대기* (2015 ~ 2025) — *CPU·GPU·DRAM·SSD·HDD* 와 *AI 시대* 의 *NPU·HBM·CPO* 전망
’‘2015 년에 RTX 4090 한 장 사느니 *집을 사라’’ 같은 말이 *없었다. 2025 년 현재 *H100 *한 장 *3,500 만원, 데이터 센터에 *수천 장이 *’‘기본’‘’’ 이다. *10 년이 *이렇게 *반도체의 *가치 *지도를 *근본부터 *재편 했다.
이 글은 2015 ~ 2025 *10 년의 *주요 하드웨어 (CPU / GPU / DRAM / SSD / HDD) *가격 *연대기를 *복기 하고, *그 변화의 *원인 (PC 시장 *축소, *암호화폐, *COVID 공급망, *AI 폭증) 을 연결한 뒤, 2026 ~ 2030 의 *전망 — *특히 *NPU, *HBM, *CPO (Co-Packaged Optics), *AI 가속기 *전문 회사들 — 까지 *종합적으로 본다.
-
코드 리뷰와 애자일은 어디로 가나 — Claude/Codex 가 도래한 시점에 *기존 개발 리드 가치의 하락*, 그리고 AI Agent 오케스트레이션·아키텍처 설계로 옮겨가는 미래
전통적인 개발 리드의 핵심 일과 두 가지:
-
SQL · PL/SQL — *생성형 AI 시대* 의 *시니어 백엔드 개발자가 *진짜 *배워야 할 *3 가지 *층*
’‘ChatGPT 가 SQL 을 *기가 막히게 *써준다. 근데 *왜 *시니어 *DBA / *백엔드 *시니어가 *여전히 *연봉이 *높을까?’‘’‘. 이 질문에 *정직하게 답하지 못하면, ’‘SQL 은 AI 가 *대체할 *분야’’ 라는 반쪽 진실에 *속아 *5 년 뒤 *후회한다.
생성형 AI 는 SQL 의 *어떤 부분은 *완벽히 대체, 어떤 부분은 *전혀 못 함. 그 경계를 *모르고 *’‘나는 SQL 공부 안 해도 *되겠다’’ 라고 결정하면, ’‘production 에서 DB 가 *터지는 순간’’ AI 에게 *’‘살려달라’’* 라고 복사 - 붙여넣기 *돌리다 *시간 *수십 시간 *날린다.
-
Python + Java 폴리그랏 — 부정론자가 얻을 수 있는 것, 그리고 *돈의 관점* 에서 본 두 생태계의 생산성
“한 가지 잘 하라” 는 격언과 “여러 도구를 다루는 사람이 더 멀리 간다” 는 격언이 동시에 회자된다. 백엔드 엔지니어 입장에서 가장 흔히 마주하는 폴리그랏 조합은 Python + Java — 둘 다 15년 넘게 살아남았고, 서로의 약점을 보완 한다.
-
JPA vs MyBatis — 2026 년 5 월 기준, 생성형 AI 시대에 어느 것이 더 유용한가? 그리고 둘 다 쓸 것인가 하나로 통일할 것인가
JPA 와 MyBatis 의 교체할 수 없는 차이 는 두 줄로 요약된다:
-
디자인 패턴과 알고리즘 — 생성형 AI 시대에 *남는 것* 과 *남지 않는 것* (분야·언어별 고찰)
생성형 AI 가 코드를 짜는 단계를 사실상 무료로 만들었다. Spring Boot 의
@Service보일러플레이트 100줄, JPA 엔티티 매핑, REST 컨트롤러 — 클로드/GPT 가 분 단위 로 뱉어준다. 그러면 왜 우리는 여전히 GoF 패턴 책을 읽고, 왜 여전히 시간복잡도 \(O(n \log n)\) 와 \(O(n^2)\) 의 차이를 따지나? -
*핸드폰*, *생성형 AI*, *Spring* — *3 번의 *기술 *대지진* 과 *변하지 않는 개발자의 원칙*, 그리고 *돈*
’‘언어가 바뀌면 산업이 *바뀐다’‘. *Steve Jobs 가 2007 년 *iPhone 을 *손에 들었을 때, 수십만 명의 *C 개발자가 *Java 와 *Objective-C 로 *옮겨 갔다. 2022 년 *OpenAI 가 *ChatGPT 를 *공개했을 때, 수십만 명의 *Java 개발자가 *Python 으로 *눈을 돌렸다. 2003 년 Rod Johnson 이 *Spring 을 발표했을 때, 수십만 명의 *EJB 개발자가 *’‘아 이렇게 가벼울 수 있구나’’ 라고 *깨달았다.
기술은 *3 번의 *대지진 으로 산업을 재배치 했고, 그때마다 *언어 사용자의 *분포가 *극단적으로 *변했다. 하지만 세 번의 진동 사이에서도 *변하지 않은 것 이 있다 — ’‘추상화 * 모듈화 * 비즈니스 가치를 만드는 *능력’‘. 이게 ’‘시니어 개발자가 3 번의 변화를 *살아남는 *이유’’ 다.
-
개발 리드 30 년 변천사 — 최신 기술 추종과 오버엔지니어링의 함정, 그리고 2026 생성형 AI / Agent 시대 백엔드·DevOps 리드의 좌표
개발 리드 (Engineering Lead / Tech Lead) 라는 직책은 지난 30 년간 본질이 한 번도 변하지 않았지만 *그 표면 은 매 5 년마다 완전히 바뀌었다. 1995 년 리드와 2026 년 리드가 *같은 일 (팀이 올바른 시스템 을 지속 가능하게 만들도록 의사결정) 을 하지만, 그 결정의 변수 는 달라졌다.
-
프로그램 · 프로세스 · 스레드 — *OS 의 *3 층 추상* 과 *C → Java → Node* 의 *동시성 진화사*
'’프로그램은 *디스크 에 있고, 프로세스는 메모리 에 있고, 스레드는 CPU 에 있다’‘. *50 년 된 OS 교과서의 한 줄 이지만, 그 한 줄을 *진짜 이해 하면 ’‘왜 Node.js 가 싱글 스레드인데도 빠른가’‘, ’‘왜 Java 가 Virtual Thread 를 21 년 만에 도입했는가’‘, *’‘왜 Go 가 고루틴 으로 모든 걸 바꿨는가’‘’’ 같은 현대 프로그래밍의 *주요 질문들이 *한 줄기로 연결된다.
이 글은 프로그램 / 프로세스 / 스레드 의 기초 부터, OS 가 그것들을 *어떻게 무대 위에 올리는지, 그리고 C (1972) → Java (1995) → Node.js (2009) 의 3 언어가 *동시성에 *서로 다른 방식으로 응답한 *진화의 역사 까지 한 흐름 으로 본다.
-
JVM 의 구조와 Java 버전 변천사 — 8 부터 21 까지의 *진짜 변화* 와 운영 환경에서 JVM 이 프로그램에 미치는 영향
“Java 21 쓰세요” 라는 말, 자주 듣지만 왜 가 잘 안 보인다. 8 → 11 → 17 → 21 의 각 LTS 가 JVM 내부에서 어떤 물리적 변화 를 가져왔고, 서비스 운영 에 어떻게 영향을 주는지 정리한다.