스프링이 가져온 봄
스프링이 등장하기 전, 개발자들은 비즈니스 로직보다 인프라 문제를 해결하는 데 더 많은 시간을 써야 했습니다. 웹 서버 구축, HTTP 통신, 직렬화, DB 접근까지 모두 직접 구현해야 했기 때문입니다.
이를 해결하기 위해 등장한 것이 EJB였습니다. EJB는 이런 인프라 문제를 프레임워크 수준에서 해결해주었지만, 오히려 새로운 부담을 안겨줬습니다. 특정 인터페이스를 강제로 구현해야 했고, 무거운 WAS가 필요했으며, 방대한 XML 설정은 유지보수를 어렵게 만들었습니다.
스프링은 이 반성에서 출발했습니다. 특정 프레임워크에 종속되지 않는 순수한 자바 객체, 즉 POJO만으로 애플리케이션을 구성할 수 있다는 것이 핵심이었고, 개발자들이 다시 비즈니스 문제에 집중할 수 있는 환경을 만들어줬습니다.
봄 이후의 그늘
스프링은 많은 편리함을 가져다줬지만, 개발자들은 곧 새로운 문제를 마주했습니다. 초기 스프링은 높은 자유도가 장점이었지만, 그만큼 표준화된 라이브러리 조합이 없었습니다. 어떤 라이브러리를 어떤 버전으로 조합해야 하는지 개발자가 직접 검증해야 했고, 버전 충돌 문제는 스프링의 진입 장벽을 높이는 주요 원인이 되었습니다.
스프링 팀은 이 문제를 해결하기 위해 Spring Boot 프로젝트를 시작했습니다. 검증된 의존성 조합을 미리 제공하고, 설정을 자동화해 개발자가 프로젝트를 빠르게 시작할 수 있도록 한 것입니다. 동시에 스프링 생태계 전반도 Spring Data, Spring Security, Spring Batch 등으로 표준화되어 일관된 방식으로 사용할 수 있게 정비되었습니다.
만개한 봄 꽃밭
스프링은 객체 지향 프로그래밍을 추구했지만, 데이터베이스 앞에서는 한계가 있었습니다. 객체는 상속과 연관관계로 풍부한 구조를 표현하지만, 관계형 데이터베이스는 테이블과 행으로 데이터를 저장합니다. 이 패러다임의 불일치를 메우기 위해 개발자는 반복적인 SQL과 매핑 코드를 직접 작성해야 했고, 시스템이 복잡해질수록 유지보수 부담도 커졌습니다.
이 문제를 해결하기 위해 ORM이 등장했습니다. 개빈 킹이 만든 Hibernate는 객체와 테이블을 자동으로 매핑해주는 오픈소스로 빠르게 확산됐습니다. 이후 자바 진영은 Hibernate를 비롯한 다양한 ORM 구현체를 표준화하기 위해 JPA 명세를 만들었고, Hibernate가 그 대표 구현체로 자리잡았습니다. 지금의 Spring Data JPA는 이 JPA 위에서 반복적인 코드를 더욱 줄여주는 역할을 하고 있습니다.
디비를 넘어 인프라로
스프링은 여기서 멈추지 않았습니다. 서비스 규모가 커지면서 개발자들이 다뤄야 하는 인프라는 데이터베이스 하나가 아니었습니다. 빠른 조회를 위한 Redis 같은 캐시 서버, 서비스 간 비동기 통신을 위한 Kafka, RabbitMQ 같은 메시지 큐, 그리고 수십 개의 서비스가 분산되어 운영되는 MSA 환경까지, 개발자가 직접 다뤄야 하는 기술 스택이 폭발적으로 늘어났습니다.
스프링 팀은 이 각각의 기술을 개발자가 직접 붙잡고 씨름하는 대신, 일관된 방식으로 다룰 수 있도록 추상화하는 방향을 선택했습니다. 그 결과가 spring-data-* 로 시작하는 라이브러리들입니다. Spring Data JPA, Spring Data Redis, Spring Data MongoDB는 서로 다른 저장소이지만 Repository 인터페이스라는 동일한 방식으로 접근할 수 있습니다. 저장소가 바뀌어도 개발자가 배워야 할 패턴은 같습니다.
분산 환경의 문제는 Spring Cloud가 담당했습니다. 서비스 간 통신, 로드 밸런싱, 서킷 브레이커, 분산 설정 관리까지, MSA 운영에서 반복적으로 등장하는 인프라 문제들을 프레임워크 수준에서 해결할 수 있게 되었습니다.
결국 스프링이 일관되게 추구해온 방향은 하나입니다. 기술이 바뀌어도 개발자는 비즈니스 문제에 집중할 수 있도록, 복잡한 인프라를 프레임워크 안으로 추상화하는 것을 지금까지도 해오고 있습니다.