2023 Spring Camp 근데 이제 현업 경험을 곁들인

 

스프링 캠프?

3월에 막 입사하여 신입 개발자로 근근이 살아던 중 인프런에 재직 중인 부스트캠프 동기 김00 군에게 연락이 왔다.

아래 링크를 던져주면서 참가할 생각이 있냐고 물어봤다.

[오프라인] 스프링캠프 2023 - 인프런 | 강의

현재 회사의 핵심 기술스택이 스프링이었음에도 스프링 알못인 나는 스프링에 대해서 하나라도 더 주워들어야 했기 때문에 그 친구와 함께 참가하기로 결정했다.

 

스프링 캠프는 한국 스프링 사용자 모임(KSUG)에서 매년 진행하는 비영리 컨퍼런스이다.

가격은 33,000원이었다.

티켓팅은 선착순이었고 소문에 의하면 10초만에 매진되었다고 한다.

 

 

강연

강연은 아래와 같은 구성으로 진행되었다.

• 어느 #월급쟁이 개발의 스프링 부트 따라잡기 ver.3
• 글로벌 서비스를 위한 Timezone/DST
• 대규모 엔터프라이즈 시스템 개선 경험기 1부 - 달리는 기차의 바퀴 갈아 끼우기
• 대규모 엔터프라이즈 시스템 개선 경험기 2부 - 새 술을 담을 새 부대 마련하기
• 실무에서 적용하는 테스트 코드 작성 방법과 노하우
• 구현부터 테스트까지 - 대용량 트래픽 처리 시스템
• Journey to Modern Spring (클라우드 시대를 맞이하는 스프링의 자세)

 

어느 #월급쟁이 개발의 스프링 부트 따라잡기 ver.3

컬리 개발자이신 김지헌 님의 발표로 스프링가 업데이트됨에 따라 프로젝트에서 스프링을 업그레이드 하는 전략에 대해 설명해주셨다. Gradle과 Maven, Yaml과 Properties를 선택 이유에 대한 내용으로 시작해 업그레이드에 대한 다양한 팁과 스프링부트 3.0, 스프링 6.0으로 업데이트되면서 생긴 변화들을 설명해주셨다.

제일 기억에 남는 것은 주부수이다. 주부수란 버전, {Major}.{Minor}.{Patch}를 의미한다. 예를 들어 스프링부트 3.1.1의 주=3, 부=1, 수=1이 된다. 업데이트 전략은 다음과 같다. Minor 버전 기준으로  최신 패치버전을 적용한다. 그 다음 Minor 버전을 1 올리고, 해당 Minor 기준으로 최신 패치버전으로 변경한다. Minor 버전으로 끝에 도달하면 Major를 바꾸면 되는데 Major를 바꾸는 것은 추천하지 않으셨다. (정신건강에 매우 해롭다고..) 예시는 아래와 같다.

• 2.6.2 -> 2.6.15 -> 2.7.13 -> 3.0.x

최근 우리 회사에서도 스프링 업데이트에 대한 고민이 많았는데 해당 내용이 큰 도움이 될 것 같다. 서버로 스프링부트 2.2 버전을 사용하고 있는데, 최근 ELK 스택을 최신으로 업데이트하면서 스프링부트 버전으로 인한 제약사항이 많이 생겼다. 심지어 지원중단된 지 한참 지난 버전이기 때문에 애플리케이션 기능이나 확장성 면에서도 불리한 위치이다.

Spring Support (출처: https://spring.io/projects/spring-boot#support)

아래 홈페이지에서 스프링에 대한 다양한 소식을 접할 수 있다고 하니 참고하자!

Spring | Blog

 

글로벌 서비스를 위한 Timezone/DST

환화 솔루션의 백엔드 개발자이신 김대겸 님이 발표를 담당했다.

날짜 및 시간 관련 기본 지식이 주요한 내용이었는데, 이번 기회를 통해 써머타임이 정확히 무엇인지 알게 되었다. 그 외에도 Time과 관련된 Java Class인 java.util.date, java.util.Calendar, Joda-Time 라이브러리, java.time, ZonedDateTime, OffsetDateTime에 대해서 배웠다.

회사에서도 동남아, 미국 등에 글로벌 서비스를 해보려고 시도 중이기 때문에 나중에 해당 내용을 적용하게 된다면 도움이 될 것 같다.

 

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

네이버 쇼핑카탈로그를 개발하시는 임형태 님의 발표였다.

Strangler Pattern이 주요 내용이었다. 아래 사진은 Strangler fig라는 나무에 기생하는 나무이다. 이 나무는 숙주의 양분을 빨아먹으며 살다가 결국 속에 있는 나무를 말려죽이게 되는데 이런 과정을 레거시 애플리케이션에서 새로운 시스템(Fig Application)으로 옮겨가는 프로젝트에 비유해 설명해주셨다.

기생하는 나무, 결국엔 기생당하는 나무를 말라죽인다.

마이그레이션부터 Pub-Sub 패턴 적용, CRUD 기능 이관, 마지막으로 레거시 시스템이 말라죽을 때까지 반복하는 것까지 쉽지 않아보였다. 작업을 시작하기 위한 설계 단계의 난이도가 굉장히 높을 것이다. 기존 시스템보다 효율적인 구조를 고민함과 더불어 레거시의 변화를 예상하고 그에 대응할 수 있는 유연한 프로젝트를 설계해야할 것이다.

레거시 시스템을 사용하지 않고 처음부터 다시 만드는 것이 좋을지, 레거시와 공존하는 프로젝트를 만들어 개발해나가는 것이 좋을지 고민해봤다. A to Z를 하면 레거시 서비스에 생기는 변화에 유기적으로 대응하기 쉬울까? 어떤 것이 더 많은 인력과 시간을 필요로 할까? Strangler Pattern을 사용했을 때, 코드에 혁신을 이뤄내는 것이 힘들지 않을까? 오히려 레거시에 잠식되어 이도저도 아닌 코드가 되는 것은 아닐까하는 생각이 들었다. 이것도 프로젝트마다 다를 것 같다. 규모, 서비스 특성 등 여러 조건을 따져봐야할 것이다.

 

대규모 엔터프라이즈 시스템 개선 경험기 2부 - 새 술을 담을 새 부대 마련하기

네이버 쇼핑의 김선철 님이 발표를 맡아 주셨다.

주니어 시절 자신이 실수했던 내용으로 발표를 시작했다. 공통 모듈로 인한 실수에서는 (물론 네이버 쇼핑의 프로젝트가 우리 서비스에 훨씬 복잡하고 크기 때문에 내가 했던 실수와 비교하기에는 민망하지만) 공감이 많이 갔다. 

우리 팀이 작성한 코드로 인해 버그가 발생해 확인해보거나 코드를 리뷰하다보면 객체의 의존성 문제, 모호한 책임과 역할로 인해 생긴 버그를 발견하곤 한다. 예를 들어, 팀동료가 작성한 코드로 인해 전체 코드가 영향을 받는 경우가 생겼었다. 동료는 새로운 기능을 만들기 귀찮았는지(?) 병원 프로필을 조회하기 위해 사용하는 API를 다른 서비스 로직에서 사용하고 있었다. 그러다보니 해당 API에 기능을 추가하게 되었는데, 그것이 병원 프로필 기능에 영향을 주는 문제가 발생했었다.

최근, 내 실수로 인해 Batch Server에서 5일간 안내 문자 약 1200통이 발송되지 않았던 적이 있었다. 선철 님과 마찬가지로 테스트와 검증 절차의 부족으로 인해 생긴 문제였다. 당시가 연휴였기 때문에 CS팀이 확인할 수도 없었고, 그렇다고 테스트 코드나 모니터링이 잘 되어 있는 것도 아니라 문제에 대한 피드백이 바로 되지 않았다. 결국, 연휴가 끝날 때까지 아무도 알아채지 못했었다. 나는 해당 문제가 다시는 발생하지 않도록 일정기간동안 문자메시지가 발송되지 않으면 슬랙 알림을 보내는 코드를 작성하고, Batch-Server에 추가로 모니터링 시스템을 구축했다. 또한, 팀에서 최초로 단위테스트와 통합테스트를 도입한 사람이 되었다.

해당 강연을 통해 내가 그동안 어떤 실수를 겪었고 어떻게 해결해나갔는지 정리해볼 수 있어 좋았다.

 

실무에서 적용하는 테스트 코드 작성 방법과 노하우

카카오페이 개발자 김남윤 님이 발표를 진행했다.

효율적인 Mock Test와 객체의 책임 분리가 테스트 코드에 얼마나 큰 도움이 되는지 설명해주셨다. 

내가 이해하기에는 레벨이 너무 높았다.. 그런고로 딴길로 좀 새보겠다.

현재 회사에서 나 혼자만 테스트 코드를 작성하고 있다. 혼자 작성하면 공부도 되고 좋지만 개발팀의 효율을 극대화하기 위해서라면 팀 전체가 테스트 코드를 작성하는 것이 좋다고 생각했다. 회사가 큰 투자를 받은 것도 아니고, 규모가 큰 것도 아니라 새로운 기능 만드는 것만 해도 바쁜데 개발팀 전체가 테스트 코드를 작성하게 하려면 어떻게 해야할 지 고민이 많았다.

사수와도 논의한 적이 있었는데, 내가 테스트 코드 짜놓은 것을 보니, 난이도가 높아서 다른 팀원들의 진입장벽이 높을 것 같다며 다른 사람들이 테스트를 쉽게 작성할 수 있는 방법을 강구해보라고 조언해주셨다. (예를 들면 쉘 스크립트로 테스트 코드 작성 시작을 자동화) 대체로 동의되는 내용이었지만 몇몇 내용에 대해선 전혀 동의할 수 없었는데, 그 중 하나는  DB에 값을 미리 넣어놓으면 일일이 값을 넣을 필요가 없어 팀원들이 쉽게 접근할 수 있지 않겠느냐는 주장이었다. 테스트 코드마다 DB값을 A to Z로 넣고 @Transactional로 롤백하는 코드를 보더니 너무 난잡해서 팀원들이 사용하기 어려울 것이라는 것이 이유였다. 여기에 대해선 동의할 수 없어 다음날 그렇게 해서는 안되는 이유를 정리해가고 대신 Fixture 라이브러리를 사용해 편리하게 데이터를 넣을 수 있는 방법을 제안한 것으로 마무리됐다.

아무래도 다른 사람들이 테스트코드 짜놓은 것을 볼 기회가 없다보니 어떤 것이 좋은 테스트 코드인지도 모르겠고, 어떻게 해야 남들이 따라하기 쉬운 테스트를 짤 수 있는지도 모르겠다. 해당 강연을 들었을 땐, 테스트 코드를 짜기 위해 많은 분량의 공부를 해야하고 필요해보였다. 이런 내용을 접하니 과연 테스트를 그냥 쉽게 하기 위한 방법만 강구하는 것이 맞나 싶었다.

 

구현부터 테스트까지 - 대용량 트래픽 처리 시스템

네이버 Cell TF에서 근무 중이신 이경일 님의 발표였다.

갑자기 대본을 볼 수 없는 문제가 발생해 프리스타일로 발표를 하셨지만, 언변이 장난 아니셨다. 강연 내용도 좋았다. 캐시에 대해서 설명하실 때에는 여러 방안들을 비교하고 기술 선택의 이유를 명확히 설명해주셔서 좋은 학습이 됐다.

아직 우리 회사의 서비스가 트래픽까지 걱정할 정도로 성장하지는 않았기 때문에 당장의 업무에 큰 도움이 되지는 못할 것 같다. 하지만 언젠가는 꼭 필요할 거라고 생각한다. 해보고 싶다.. 대용량 트래픽..

 

Journey to Modern Spring (클라우드 시대를 맞이하는 스프링의 자세)

박용권님의 발표였다.

클라우드와 스프링에 초점을 맞춰 웹개발의 역사를 훑어주셨다. 2000~2010년에는 클라우드 시스템도 대중화되지 않고 스프링 부트도 없었던 세상이라 사람들이 어떻게 개발을 했을까 싶었다. 직접 서버 컴퓨터 구매해서, 톰캣 서버에 war 파일을 넣어 배포했을텐데 쉽지 않았을 것 같다.

2010년 이후부터 뭔가 본격적인 변화가 시작됐던 것 같다. 2011년에 마이크로서비스라는 키워드가 처음으로 등장했고, 2012년에는 현재는 유료서비스만 하는 헤로쿠에서 클라우드 12 원칙을 발표했다. AWS Lambda(serverless), Kubernetes 공개되었고 그 외에도 많은 발전이 진행되어, 이제는 클라우드 시스템을 사용하지 않고 배포하는 사람을 신기하게 취급하는 시대가 되어버렸다.

유튜브나 강의를 듣다보면 자바를 소위 "틀딱" 언어라고 표현하는 사람들이 있다. 2018년까지만 해도 자바는 컨테이너 환경을 잘 이해하지 못했다고 한다. 하지만 자바와 스프링이 새로운 시대를 맞아 끊임없이 변화해왔다. 스프링은 프레임워크의 사용성을 개선하기 위해 스프링 부트를 개발했고, 약점이라고 평가받던 비동기에 특화된 Spring Webflux도 공개했다. 자바 더 좋은 JVM을 만들기 위해 여러 시도들을 해왔고, 2019년에는 GraalVM을 통해 성능을 10% 이상 개선했다고 한다.

 

 

소소한 재미

스프링캠프는 단순 강연만 진행되지 않고 부스도 운영되었는데, 여러 이벤트와 취업 상담 등 소소하게 즐길 거리들이 많은 행사였다.

부스 운영

스프링 캠프에는 회사 부스가 배치되어있었는데, 인프런과 데보션에서 경품 추천 이벤트를 준비해주셨다. 각 추첨당 200대 10~20의 경쟁률을 자랑했는데 정말 운이 좋게도 두곳에서 모두 경품을 선물을 받았다.

 

인프런에서는 슬리퍼를 선물받았고, 데보션에서는 보조배터리를 선물받았다! 안그래도 사려고 했었는데

그 외에도 기본선물인 손풍기, 스티커와 인프런 설문조사만 진행해도 받을 수 있는 인프런 30% 할인권을 챙겼다.

 

티타임

중간 티타임에는 현대자동차에서 간식도 준비해주셨다. 아주 알찬 구성!