인프콘2023

20년 전 스프링을 처음 쓰던 시절은 EJB 가 대세였고 오픈소스를 엔터프라이즈에 쓰는 것을 꺼리던 분위기였다. 스프링 MVC의 점유율은 1~2%에 불과했고 책도 강의도 없었다. 발표자는 어떤 기술을 실전에 적용하려면 최소한의 고민이 필요하다며 세 가지를 든다. 첫째는 기술의 등장 배경 살피기다. 스프링은 로드 존슨 이 2002년에 낸 책(대규모 금융 시스템 개발 경험을 담아 예제 코드가 3만 라인이 넘었다)에서 비롯됐고, 독자들이 "이 예제를 오픈소스로 발전시키자"며 저자를 설득해 만들어졌기에 책을 읽으면 "왜 이렇게 만들어졌는가"를 알 수 있었다. 둘째는 신뢰할 수 있는 개발자의 추천 이다. 아틀라시안 공동 창업자 마이크 캐논 부스가 컨플루언스를 알파 버전 스프링으로 만들며 극찬한 글, 그리고 7~8년 전 후배가 "스프링부트가 너무 좋다"고 극찬해 곧장 스프링부트 로 전환한 사례를 든다. 셋째는 직접 탐구 하는 것으로, 자료가 부족하던 시절 PetClinic 같은 튜토리얼을 수없이 따라 만들고 결국 소스 코드 와 정교한 자바독을 읽으며 "스프링으로 개발하는 느낌"을 익혔다. 그렇게 기술을 선택한 뒤 매출 1천억대 회사의 1년짜리 전사 ERP 개발에 적용한다. 익숙한 EJB를 버리고 스프링을 택했으니 "무슨 일이 있어도 개발한다"는 마음가짐이 중요했다고 한다. 흥미롭게도 그를 괴롭힌 것은 버그가 아니라 "왜 이렇게 개발해야 하지", 무엇보다 "왜 개발이 이렇게 잘 되지?"라는 의문이었다. 1년간 요구사항이 계속 바뀌어도 수정 지점이 명확했고 EJB 시절보다 생산성이 크게 올랐으며, 어느 순간 기술이 아니라 비즈니스·도메인 로직에만 집중하고 있는 자신을 발견했다.

성공적인 ERP 런칭 이후 발표자는 같은 일의 반복으로는 부족하다며 두 번째 주제 질문과 탐구 로 넘어간다. "내가 쓰는 기술은 왜 이렇게 만들어졌고, 내 코드는 왜 이렇게 설계해야 하는가"를 글·책·세미나로 파고든 것이다. 가장 큰 질문은 모든 스프링 문서가 강조하는 IoC/DI 가 무엇이고 코드에 어떤 도움이 되는가였다. 미국 스프링 컨퍼런스의 "스프링의 철학" 세션에서 실마리를 얻어 2007년 코엑스에서 같은 주제로 발표한 것이 이해의 출발점이 됐다. 스프링의 목표는 POJO 만으로 과거 복잡한 기술로만 가능했던 엔터프라이즈 서비스를 누리게 하는 것이며 그 핵심이 의존관계 주입(DI) 임을 "스프링 트라이앵글"로 설명한다. 그는 IoC/DI가 객체지향 설계 원리 에서 나왔다고 보고, 마틴 파울러가 DI 용어를 제안한 글에서 랄프 존슨의 "Designing Reusable Classes"(1988)와 GoF 디자인 패턴 책까지 거슬러 올라간다. 특히 전략 패턴(Strategy) 의 전략 오브젝트를 컨텍스트 생성자에 넣는 코드가 곧 우리가 쓰는 생성자 주입 임을 발견하고 "전율을 느꼈다"고 표현한다. 템플릿 콜백 패턴, DispatcherServlet의 핸들러 전략들, 데코레이터·프록시로 구현된 AOP, 템플릿 메서드 패턴까지 스프링이 디자인 패턴의 "변화를 위한 설계"(OCP)를 그대로 추구함을 확인하고, 이 원리를 자신의 애플리케이션 코드에도 적용할 수 있다 는 결론에 이른다. 노드JS의 비동기 논블로킹 우위 주장에 "정말 스프링은 안 되는가"를 탐구해 서블릿 3.0 비동기부터 WebFlux·코루틴·버추얼 스레드까지의 흐름을 정리한 것도 같은 탐구의 산물이다.

세 번째 주제는 훈련과 개선 이다. 발표자는 튜토리얼 예제를 30번씩 반복해 만들며 제작자가 담아 둔 핵심을 체득하고, 거기에 새 기능을 더하거나 설계를 바꾸는(예: 마이바티스 대신 JPA) 트레이닝용 애플리케이션 으로 연습했다고 한다. 스프링 기원 책이 한 챕터를 테스트 에 할애한 데 자극받아 스프링 소스의 방대한 테스트 코드를 보며 JUnit과 목(mock)을 배웠고, 2004년 스프링 1.1.1의 컨텍스트·트랜잭셔널 테스트 지원이 오늘날 @SpringBootTest·@Transactional 의 기원이며 컨텍스트 캐싱과 롤백 클린업으로 빠르고 안전한 통합 테스트가 가능해졌다고 설명한다. 리팩토링과 TDD에 빠져 한때 "전도사"처럼 굴기도 했다고 고백하며, 남의 기술 사용법을 익히거나 버전업 시 기존 동작을 검증하는 학습 테스트(러닝 테스트) 의 유용함을 강조한다. 실전만으로는 부족하니 목표와 의도를 가진 자기만의 코딩 시간 이 필요하고, 모든 선택에 이유를 댈 수 있어야 하며, 연습할 때 반드시 테스트를 작성하라(부담되면 코드 직후 작성하는 TLP도 효과적)고 권한다. 신규 프로젝트마다 기술을 조합해 나만의 프레임워크(스프링부트의 간단한 버전 격)를 만든 것도 중요한 훈련이었으며, 2005년 만든 프레임워크를 지금까지 발전시키고 백기선과 "스프라우트 애플리케이션 프레임워크"를 오픈소스로 공개한 일화도 전한다.

마지막 주제는 공유와 논쟁 이다. 고민과 경험을 글로 정리하는 것이 성장의 지름길인데, 책을 그대로 옮기는 식의 정리는 지루해 대부분 2~3장에서 그친다고 지적한다. 대신 다시 봤을 때 기억하고 싶은 핵심만 나의 언어로 정리하고(그는 구글 독스에 주제별 문서를 누적), 무엇보다 나만의 정의와 설명 을 만들어야 한다고 강조한다. "DI가 무엇입니까"에 한 문장으로 정의하고 한 문단으로 설명할 수 있어야 하며, 5분이면 핵심을, 1시간이면 예제와 함께, 하루면 교육을 구성할 수 있어야 한다는 것이다. 공유 수단으로 블로그·커뮤니티, 큰 도약을 주는 세미나·컨퍼런스 발표, 커뮤니티 활동을 들며, 2007년 KSUG(한국 스프링 사용자 모임)를 만들고 "끝판왕"으로 책을 쓰며 자신의 언어로 설명하는 법을 다듬었다고 한다. 2008년 연변과기대에서 IT 초보 학생들을 가르친 경험이 "토비의 스프링" 1~5장의 뼈대가 됐고, 스프링에는 논쟁이 많으니 두려워 말고 참여하라고 권한다. 끝으로 "많은 개발자가 성장을 원하지만 다수는 성장이 필요 없는 안락한 환경을 선택한다"는 선배의 말을 인용하며, 핵심은 성장을 위해 노력하는 시기를 반드시 거친 뒤 자연스럽게 성장하고 교류할 수 있는 환경에 들어가는 것이고 나아가 청중이 그런 환경을 만드는 사람이 되기를 바란다는 당부로 마친다.