2023 스프링 캠프 0년차 개발자가 느낀 후기

스프링을 사용하는 개발자들을 대상으로 스프링 캠프가 매년 열린다. 올해는 4년만에 오프라인으로 행사가 개최되어서 운좋게 참여할 수 있었다. 

 

Spring Camp 2023

 

몰라서 신청 못한 친구들도 있었는데, 나도 인프런 둘러보다가 알게 되었고 신청은 선착순 마감이었는데 정말 1분 만에 마감되었다고 한다. 체감상 30초 나는 네이버 페이 결제하려고 미리 네이버 로그인까지 다 해뒀었다. (같은 팀 분은 준비 안 하고 있다가 선착순 탈.. 하셨으니 내년에도 꼭 준비해둬야 할 것 같다) 

---

같이 가는 친구를 찾지 못해 혼자 참여하게 되었는데, 기회가 된다면 내년엔 꼭.. 누군가와 같이 가고 싶다. (기왕이면 같은 회사 동료 분과) 강연을 듣는 내내 회사의 서비스에 빗대어 생각하게 되는데 회사 동료와 간다면 그런 고민들을 쉬는 시간마다 공유할 수 있으니 훨씬 효율적일 것 같다. 실제로 같이 참여하신 다른 분들은 회사 동료들과 와서 그런 얘기들을 계속하는 것 같았다. 

 

세션 진행은 아래와 같은 순서였다. 

뭔가 경험 공유 - 지식 공유가 적절히 배치되어서 지루하지 않게 들을 수 있었던 것 같다. 추후에 강연 동영상이 올라온다고 했으니, 자세한 내용은 영상으로 확인하면 될 것 같다. 그래도 간단히 내가 인상 깊게 들었던 세션들을 공유해보고자 한다. 

 

1. 어느 월급쟁이개발자의 스프링 부트 따라잡기

이 세션은 자바, 스프링, 스프링 부트의 변화에 대한 얘기가 주를 이루었다. 사실 배워야 할 게 너무 많다는 핑계로 자바의 업데이트 소식, 스부의 업데이트 소식 등을 좀.. 나태하게 인식하고 있었는데, 이 얘기를 들으면서 과연 이대로 괜찮은가? 하는 생각이 들었다. 

 

강연자 분은 강력하게 스프링부트 2.6까지의 지원이 끝났기 때문에 2.7까지는 올라와야 한다고 말씀하셨다. 2.7까지 올라오는 건 어려운 일이겠지만 2.7에서 3.0까지 올라오기는 또 수월할 거라며. 

 

간략하게 말해 전략은 다음과 같았다. 

0. 자바 버전을 먼저 17로 올린다.

1. minor 버전 기준으로 최신 패치 버전으로 변경한다. 

2. minor 버전을 1 올리고 다시 해당 minor 버전 기준 최신 패치로 변경한다.

3. 문제 없는 지 파악

위의 1-3 과정을.. 2.7이 될 때까지 반복한다. 

 

이 강연을 들으면서 우리 회사에도 자바8을 사용하는 남은.. 프로젝트들이 떠올랐다. (그리고 남은 구조 개선 작업들...) 그러면서 스프링 부트나 자바의 최신 업데이트 소식에 늦어선 안되겠다는 마음을 가졌다. 그래서 앞으로는 종종 spring.io 블로그에 올라오는 최신 소식들을 번역하는 블로그를 좀 써봐야겠다는 생각까지.. 새 릴리즈가 나오면 한 번 도전해봐야겠다. 

---

2. 대규모 엔터프라이즈 시스템 개선 경험기 - 달리는 기차의 바퀴 갈아 끼우기.

사실 스프링캠프를 가기 전부터 이 세션에 대해 가장 기대가 컸다. 세션 이름부터가 너무나도.. 매력적이었다. 우리 팀 팀원분이랑 이 제목 보면서 이거 정말 우리에게 꼭 필요한 얘기 아니냐 할 정도였다. 그리고 예상했던 것보다도 더 이 세션을 위해서 전체 캠프를 갔다 해도 과언이 아닐 정도로 만족스러웠다. 

 

세션은 시니어 개발자분이 진행해주셨고, 시니어 개발자를 대상으로 생각한 세션이라고 하셨다. 그래서인가 내게는 더 큰 그림과 설계의 모습이었다. 이 세션은 네이버 쇼핑에서 어떻게 레거시 시스템에서 리뉴얼된 시스템으로 전환했는지를 전달했다. 

 

먼저 리팩토링이 아닌 리라이팅(rewriting)을 시작한 계기에 대해서 공유했다. 리팩토링을 하다보면 기존 코드에 대한 테스트 작성이 필수지만 실행 비용이나 시간, 범위를 알 수 없다. 그도 그럴 것이 옛날에 작성된 코드들을 보면 종종 파라미터가 10개가 넘는 메서드가 있기도 한데, 그럼 그럴 때마다 각각에 대한 테스트를 만들 수는 없다. 그래서 rewriting을 선택했다고 한다. 

 

기본 전제 조건은 이거였다. 서비스의 요구 사항을 달성하면서 개발자의 니즈(깔끔하고, 유지 보수에 용이한 신시스템 구축)를 포함시켜야 한다. 새로운 시스템으로의 전환을 언제 할지 맨날 미루지 말아야 한다. 실행 가능한 서비스 과제가 시작될 때면 언제든지 '이번 프로젝트에 시작할까?'를 고민해야 한다. 저수준의 소프트웨어로 인한 고통은 결국 개발팀의 몫이니까. 

 

그래서 선택한 것이 strangler fig application 이었다. 어떻게 strangler fig 패턴을 이용해서 새 시스템을 구축하고 기존 레거시 시스템을 점점 말라죽여 나가는지 아주 자세하게 설명해주셔서 좋았다. 해당 내용은 어느 정도 정리해두긴 했지만 빠진 부분들이 있어서 추후 영상이 나오고 나면 다시 정리해서 추가될 예정이다. 우선은 아래 내용에서 확인할 수 있다.  

 

https://www.miricanvas.com/v/11z5efx

제목을 입력해주세요.

4번을 진행하면서 fig와 레거시 간의 상호 참조가 발생하면서 시스템의 복잡도가 높아질 수 있고, fig에 레거시 만을 위한 기능이 필요할 수 있다는 단점이 생기게 되는데, 이를 보완하기 위해서는 pub-sub 패턴이 필요하다. 추가로 어떤 일이 있어도 레거시에 요구사항을 추가해서는 안 된다. 어뎁터를 껴서라도 무조건 요구 사항 해결은 fig 내부에서 해결해야 한다. 위 과정을 끊임없이 반복해서.. 퇴사할 때까지 반복하면 된다.

 

실제 강연자분도 몇 년 간의 결과가 작년 말부터 성과로 보여지기 시작했다고 한다. 그리고 아직도 많은 과제가 남았다고 하셨다. 그만큼 끈기와 팀 내 합의가 필요한 작업이다. 해당 강연 이후에는 실제 해당 팀에 속했던 주니어 개발자 분이 좀 더 주니어 개발자의 입장에서 fig 전환에 주요하게 쓰였던 개념인 Event Driven, DDD, Port & Adaptor 패턴에 대해 설명을 이어가셨다. 

 

팀이 모두 합의해서 이렇게 바꿔나가자 결정한 것도, 전환하는 과정이 쉽지 않았을텐데 신규 개발자가 합류하면 해당 개발자도 설득하여 참여하도록 한 것도, 전부 대단해 보였다. 전에 어떤 개발 서적을 읽으면서 '2.0으로 전환하려고 하다보면 2.0도 레거시가 되어 있고 3.0에 대한 목소리가 나올 수 있다' 라는 우스개소리..를 본 적이 있다. 하지만 명확한 청사진이 없는 2.0을 만들다 보면 그렇게 되기 쉽겠다 라고 동의했던 부분이다. 언젠가 2.0을 도입해야 겠다는 정책이 결정되면, 이 패턴을 꼭 기억해서 적용해보고 싶다는 의지가 드는 세션이었다. 

---

3. 대용량 트래픽 처리 시스템

대용량 트래픽 대응은 언제나 주요 이슈가 된다. 그러나 오버 엔지니어링을 하게 되면 인프라 측을 다시 줄이기는 거의 불가능에 가깝다. (인프라 팀에 항상 높은 성능으로 바꿔달라고 얘기하긴 하지만, 낮은 성능으로 바꾸자는 얘기는.. 절대 하지 않는 법이니까) 따라서 작게 시작해야 한다. 그러려면 효율적인 처리 시스템이 필요하다. 

 

요약하자면 redis와 같은 global cache가 아니라 서버의 local cache에 JSON이나 SSR(Server Side Rendering) 결과인 HTML 을 저장해서 효율성을 높였던 경험이었다. 로컬 캐시를 사용하면 동기화가 문제가 되는데, 동기화를 해결하기 위해서 여기서도 pub-sub 패턴이 등장했다. 그리고 트래픽 테스트 툴로 nGrinder, jmeter나 locust 등을 추천하며 APM(Application Performance Management)의 필요성을 강조하는 내용이었다. 

 

이 작업은 뭔가 당장.. 내가 써먹어야 겠다라는 마음 보다는 (물론 테스트 툴들은 적용해보고 싶어졌지만) '이런 고민 재밌겠다!' 싶어서 인상 깊게 들었던 것 같다. 언젠가는 이런 도전을 회사 서비스에서 해보게 된다면, 그리고 이게 성능 향상에 큰 도움이 된다면 그것만큼 뿌듯한 게 어디있을까 하는 마음이었다.

---

이 외에도 Timezone/DST나 테스트 코드, Spring Cloud 관련 세션들도 기술적으로 배워야 할 많은 지점들을 안겨주었다. 다 같은 일을 하는 사람들이 모여서 고개 끄덕 거리며 듣는 게 재밌기도 했고, 신기하기도 했는데 무엇보다 '다른 사람들은 이런 고민을 하고 이런 일을 하고 있구나' 하는 점을 알게 되어서 좋았던 것 같다. 생각보다.. 다른 개발자들과 소통할 수 있는 시간이나 자리는 없었지만, 그래도 참여한 시간들이 아깝지 않게 배울 수 있었다. 다음 기회가 있다면 개발 컨퍼런스 또 가고 싶다라는 마음이 가득한 채.... 첫 개발 컨퍼런스 후기 끝!