<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Spring on philipjkim</title><link>https://philipjkim.cc/tags/spring/</link><description>Recent content in Spring on philipjkim</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 04 Mar 2026 16:20:43 +0900</lastBuildDate><atom:link href="https://philipjkim.cc/tags/spring/index.xml" rel="self" type="application/rss+xml"/><item><title>AI 시대의 Spring 기술 스택 재정비: 명시성을 되찾기 위한 선택들</title><link>https://philipjkim.cc/posts/20260304-spring-stack-for-ai-era/</link><pubDate>Wed, 04 Mar 2026 16:20:43 +0900</pubDate><guid>https://philipjkim.cc/posts/20260304-spring-stack-for-ai-era/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;Claude Code 같은 AI 코딩 도구를 본격적으로 활용하기 시작하면서, 그동안 당연하게 쓰던 기술 스택에 대해 다시 생각하게 되었습니다. JPA의 dirty checking이 정말 편한 건지, Lombok 없이는 못 사는 건지, RestTemplate과 Retrofit이 뒤섞인 코드베이스가 과연 합리적인 건지.&lt;/p&gt;
&lt;p&gt;결론부터 말하면, &lt;strong&gt;AI가 생성한 코드를 사람이 빠르게 읽고 검증하려면 &amp;ldquo;마법(magic)&amp;ldquo;보다 &amp;ldquo;명시성(explicitness)&amp;ldquo;이 훨씬 중요하다&lt;/strong&gt;는 생각에 도달했습니다. 이 글에서는 그 관점에서 기존 Java/Spring 기술 스택의 각 영역을 하나씩 짚어봅니다.&lt;/p&gt;</description></item></channel></rss>