JAVA/JAVA | Spring 학습기록

[240525] Spring Camp 2024 갔다온 후기

kth990303 2024. 5. 28. 20:09
반응형

스프링캠프 2024에 다녀왔다!

학여울역 근처 SBA 아카데미에서 열렸다.

 

(여담으로, 넥스터즈 23기 때 진행한 장소와 같아서 지리가 굉장히 익숙했다.)

 

2023에 다녀온지 얼마 안된 것 같은데, 2024가 벌써 열리다니.

지난 스프링캠프 2023 후기는 여기서 볼 수 있다.

https://kth990303.tistory.com/440

 

[230422] Spring Camp 2023 갔다온 후기

KSUG에서 주최한 스프링캠프 2023 컨퍼런스에 다녀왔다~ https://springcamp.ksug.org/2023/ Spring Camp 2023 '스프링 캠프'는 애플리케이션 서버 개발자들과 함께 가치있는 기술에 관한 지식과 정보를 '공유'하

kth990303.tistory.com

 

 

이번 스프링캠프 2024도 2023때와 마찬가지로 인프런에서 신청을 받았는데,

다른 점은 가격이다.

올해는 39,000원으로 310명 선착순 접수를 받았다.

신청마감은 스태프 FL님 피셜에 따르면, 결제까지 40초만에 이루어졌다고 한다 ㅎㅎ

 

스프링 캠프 2024 홈페이지는 아래 링크를 클릭하자.

https://springcamp.ksug.org/2024/

 

SpringCamp2024

SpringCamp2024

springcamp.ksug.org

 

작년과 다른 점이 하나 더 있다면, (개인적인 TMI이긴 하지만) 이번 스프링캠프 때에는 지인들이 굉장히 많았다!

같이 가기로 한 지인은 한명이었는데, 컨퍼런스 내에서 10명 정도 만난듯.

 

같은 학교 선배들과 동기들, 우테코 동기(연로그, 더즈 등), 회사사람들 등등.

심지어 어떤 분은 오전에 마라톤을 했는데도 오후에 컨퍼런스에 떡하니 있길래 정말 놀랐다. 체력이 정말 짱짱하신듯하다...

 

아무튼 개발판이 진짜 좁고, 개발경력이 길어지면 길어질수록 많은 지인들을 만나겠구나 싶었다.

 

스프링캠프 굿즈로 키캡, 손선풍기를 받았다.

 

(클라이밍을 해서 그런지, 작년에 비해 손에 상처가 많아졌다 ㅜㅜ)

 

스프링캠프에 입장하면 출석체크 후 바로 키캡, 손선풍기 굿즈를 받는다.

작년 굿즈가 기억이 안나긴 하는데, 작년과 굿즈가 다른건 확실하다.

 

후원사 중에 카카오뱅크가 있었는데 설문조사를 참여하여 스티커와 수건을 받았다.

 

그리고 이번에 진행된 SBA 아카데미에서는 트랙방 안에 커피를 포함한 음료반입이 불가능했다!

따라서 제공받은 물 이외에는 반입하지 않은 상태로 입장했어야 했다. 이 점이 좀 아쉬웠다.

커피 브레이크 타임 때 커피와 다과를 나눠줬는데, 다과가 넘 맛있어서 인상깊었다 ㅎㅎ

 

트랙1

 

트랙2

 

 

내가 들은 세션은 아래와 같다.

 

  • 트랙1 - 켄트 백의 Tidy First?
  • 트랙2 - spring corutine in action 
  • 트랙1 - 왜 나는 테스트를 작성하기 싫을까?
  • 트랙2 - AutoParams 사용한 Spring boot 응용프로그램 테스트 

 

4번째 세션때는 개인적으로 해야될 일 (회사업무는 아님.) 이 있기도 했고 조금 쉬어가는 느낌으로 건너뛰었다.

 

2023년의 나였다면 `테스트 코드는 우테코에서 배웠으니까~ 동시성, MSA, 버추얼 스레드 들어야지~` 라고 생각했을 것 같다.

하지만 2024년의 나는 생각이 달라졌다.

특정 책임이 어디 객체에 위치해야 하는지, 테스트코드 비용이나 관리포인트 등을 익혀서 업무에 잘 적용하는 것의 중요성을 느끼는 참이라, 이번에는 좀 더 아키텍처적인 세션에 참여하였다. (물론 MSA, 버추얼스레드 등의 기술적 세션이 나쁘다는 것이 절대 아니다.)

 

특히, 사내 프로젝트는 Java8을 쓰고 있어서 버추얼스레드(Jdk21 이상)를 쓰고 싶어도 못쓰기 때문에... (그리고 버추얼 스레드 관련 세션 너무 많이 듣기도 했다)

차라리 다른 사람의 아키텍처 설계 및 객체 책임에 대한 생각, 테스트 비용 줄이는 팁을 듣고 업무에 적용해서, 업무시간 줄이고 생산성을 늘리는 것이 좋다고 생각했다. 그래야 칼퇴하고 내가 좋아하는 클라이밍 많이하지!

 

각 세션에 대한 후기를 적어보도록 하겠다.

참고로, 각 세션 영상은 블로그 작성 시점으로부터 2~3개월 후에 유튜브로 공유될 예정이라고 한다.


트랙1 - 켄트 백의 Tidy First?

켄트 백이 최근에 책을 집필했다고 한다. 

바로 Tidy First? 라는 책이다. (아마 국내에는 2024.4.19 에 나온 듯하다.)

(우테코 베루스가 침흘리며 좋아할 거 같은 느낌이다. 켄트백괌과 마틴파울러를 광적으로 좋아하는 형이다;;)

켄트 백이 최근에 집필한 책 Tidy First?의 옮긴이분께서 발표한 세션

 

안영회님께서 해당 책을 번역하며 옮겨주셨는데, 이분께서 해당 세션을 발표해주셨다!

 

사실 난 켄트백 책을 완독한 적은 단 한번도 없다.

리팩토링도 앞부분만 조금 읽었고, 테스트 주도 개발도 중간부분만 조금 읽었다. 

읽다 보니 코드 짜기에 바빠져서 책에 조금 소홀히 돼버린듯하다.

 

Tidy First? 도 책 내용이 궁금하긴 하지만, 내 성격상 뭔가 안읽을 거 같았는데 이번 세션 덕분에 책의 전반적인 흐름 및 내용을 알 수 있게 됐다.

 

코드 정리를 어떻게 할 것인지에 대한 내용이 주를 이루었다.

소프트웨어 설계는 Fractal하게 (작고 빈번하게) 하는 것, 그리고 길을 닦는 일이라고 설명해주신 부분이 특히 인상깊었다.

생각해보면 업무하면서 Merge Request 단위도, 그리고 지라 티켓도 작게 하면 할수록 일이 명확해지고 편했던 것 같다. 티켓 범위가 커지면 작업하는 데에 힘이 들고, 코드리뷰하는 입장도 힘들어지고, 롤백하기에도 겁이 난다. 커밋단위, PR단위, 객체의 책임 등. 웬만해선 작고 빈번하게 가져가는 게 최고인듯.

 

소프트웨어 설계를 유기체를 생각하면서 결합도와 응집도 얘기도 나왔다.

사실 결합도, 응집도 부분은 이론은 쉽지만 막상 개발하면 트레이드오프적인 면도 있고, 막상 개발하고나면 더 좋은 방법이 있었지! 하며 후회하는 경우도 조금 있어서... 어떻게 객체의 책임을 최대한 정답에 가깝게 부여할 수 있을지 궁금했다.

안영회님은 이 부분은 개발업무를 진행하면서, 이에 대한 감각을 기르는 것이라고 얘기해주셨다.


트랙2 - spring corutine in action

우테코 동기 오리가 발표한 코루틴 세션!

내 우테코 동기 오리가 발표한 세션이다!

사실 이 세션 들으러 스프링캠프 2024에 참여한 게 크다.

 

우리팀에서는 코루틴을 쓰지 않는다.

(정확히 말하자면 쓰는 코드가 있긴 하지만, 많이 없다.)

그래서 나는 아직 코루틴에 대한 학습이 덜 되어 있다. 아니, 사실 아예 모른다.

 

그래서 이번 세션을 듣는 목적은 `코루틴, 왜 쓰는걸까? 그냥 @Async랑 뭐가 다른가?`에 대한 해법을 얻어가는 것이었다.

그리고 세션 앞부분에서 해당 질문에 대한 답을 얻었다!

 

Structured Programming(구조적 프로그래밍) 이란, 흐름이 파악하기 쉽고 정해진 룰을 따라 작성되는 구조를 의미한다고 한다.

예를 들어, goto문을 쓴 스파게티 코드는 흐름파악이 어렵고 구조정돈이 1도 안돼있는 코드이므로 structured programming했다고 보기 힘들다.

@Async 역시 Structured Programming이라 보기 어렵다. 아예 새로운 실행흐름으로 넘어가게 돼서, 부모 입장에선 자식의 흐름을 알 수 없기 때문이다. 즉, 자식 실행흐름을 제어할 수 없다. 그렇다고 @Async를 안쓸 수도 없다. 단일 스레드만으로는 수많은 트래픽을 감당하기 힘들기 때문이다.

코루틴은 Structured Programming할 수 있게 작성하면서도, 여러 실행흐름을 챙겨갈 수 있게 하기 위해 태어났다! coroutineScope를 잘 활용하면, 자식의 예외 및 흐름이 부모에게 전파되게 할 수 있기 때문이다.

 

사실 이것만 해도 이번 세션을 들은 목적은 달성한 셈.

 

그 외에도 이것저것 필기를 많이 했는데...

 

코루틴을 잘 몰라서.. 별도로 내가 후기에 기록하기보단, 여기에 내가 필기한 내용을 캡처하는 것이 낫겠다고 생각했다.

(절대 귀찮아서가 아니다.)

 

틀린 내용이 있다면 댓글을 마구마구 남겨주세요! 댓글 환영입니다.

 

흠, 코루틴 좀 더 공부해보고 @Async 대신 coroutine을 적용해보는 것도 고려를 해볼 수 있겠다 싶다 ㅎㅎ


트랙1 - 왜 나는 테스트를 작성하기 싫을까?

테스트 코드 비용을 어떻게 줄일 수 있을지에 대한 내용이었다!

발표자분께서는 fixtureMonkey를 개발하고 공유하셨기 때문에, 테스트 작성 비용보다도 유지보수 비용을 줄이는 데에 굉장한 노력을 하셨다고 한다. 

또한 네이버페이 포인트, 할인, 결제, 환불 관련 종사자이셨는데, 나 역시 쿠폰팀이어서 어떻게 보면 결제 관련 쪽 테스트 작성자라 좀 더 관심있게, 집중적으로 들었던 것 같다.

 

처음에는 아래와 같은 얘기를 해주셨다.

  • 희망편
    • 실제 api 호출하여 검증하는 외부/인수테스트
    • 픽스쳐몽키 사용 -> 엣지케이스 검증
    • DomainFixture MSA 환경 api 모두 모킹 제어
  • 절망편
    • 픽스쳐 계속 추가
    • 기능 추가될때마다 계속 깨지는 비결정적 테스트

 

실제 api를 호출하여 테스트한다는 부분이 신기했다. 보통 우리 팀에서는 api를 테스트에서 직접 호출하기보단 mocking을 많이 하고, 베타환경에서 개발 QA 및 인수 시나리오 작동을 확인하는 편이기 때문이다. 각각 트레이드오프가 있는 듯.

 

절망편은 느낀 점이 같다.

새로운 기능이 개발되면 테스트 픽스쳐를 추가하긴 해야된다. 보통 우린 예를들어 CouponConfig가 추가됐다면 aCouponConfig() 함수를 만들어서 픽스쳐를 추가하는 편이다.

그리고 기능이 추가되면 이미 완성돼있는 다른 테스트코드가 깨질 때도 당연히 있다

그래서 공감이 좀 됐다.

 

 

절망편을 최대한 적게 경험하기 위해, 발표자분께서 비용을 줄이는 방법에 대해서 얘기해주셨다.

그 중 가장 인상깊었던 점은.. 불필요한 given과 then을 줄이라는 것이었다. 특히 불필요한 then이 인상깊었다!

사실 given이야... 오히려 불필요한게 늘어나면 테스트 가독성도 이상해지고, 작성하는 입장에서도 귀찮으므로 불필요한게 더 생길리가 거의 없다. 특히, mock test를 짜는 입장이라면 오히려 불필요한 mocking을 했다고 테스트가 깨질 것이다.

 

하지만 then은 좀 인상깊었던게, 가끔 `검증하는 게 많으면 많을수록 엄격한 테스트를 작성하게 돼서 꼼꼼하게 검증할 수 있다!` 고 생각을 할 때가 있었다. 그렇지만 발표자분께서는 오히려 이러한 걸로 인해 불필요하게 테스트 작성 비용이 증가하게 된다고 한다. 우리가 검증하려는 최소한의 사항만 검증되면 된다고 하셨다.

생각해보니 불필요한 검증이 많을수록 기능 추가로 인해 깨지는 비결정적 테스트도 많아질 수 있고, 테스트 작성 비용도 증가한다. 정말 이 테스트에서 검증하려는 것이 무엇인지만 딱 적는 것이 작성비용도 좋고, 코드리뷰하는 입장에서도 편리할 것 같다.

 

 

test fixture 라이브러리 중 하나인 fixtureMonkey 에 대한 내용에 대해서도 많이 다루었다.

하지만 개인적으로 fixtureMonkey, fixture 라이브러리에 크게 관심이 있진 않아서... 나중에 관심생기면 다시 들어봐야겠다.

(개인적으로 나는 우리 팀에 현재 있는 테스트픽스쳐 정도만으로도 작성비용이 충분히 줄었다고 생각하는 편이다.)


트랙2 - AutoParams 사용한 Spring boot 응용프로그램 테스트 

 

앞 세션과 마찬가지로, test fixture 오픈소스에 대한 세션이었다.

원래는 트랙1의 카카오뱅크의 3000만 트래픽 관련 세션을 들으려다가, 지인들이 테스트 관련 세션 하나 더 들어보자고 해서 듣게 된 세션.

 

@AutoDomainSource, @AutoSource를 이용하여, 형식을 컨트롤하고 싶은 커스텀한 타입의 fixture을 만들 수 있다는 것이 인상적이었다.

@AutoDomainSourceConfiguration와 @Customization를 이용해서 ObjectGeneartor 구현체를 작성하면 커스텀한 형식을 구현할 수 있는데, 한번 로직을 작성해두면 커스텀Fixture를 만드는 데 편할 수도 있겠다고 생각이 들었다.

 

 

아쉬운 점은, 내부 아키텍처 설명이 좀 길었다는 점?

사용자 입장에서는 사실 내부 아키텍처보다는 해당 라이브러리를 어떻게 이용할 수 있을지, 어떻게 하면 기존에 비해 편리해질지 듣는 것이 좀 더 매력적이었을 것 같다.

물론 커스텀 구현체 등 다양한 기능들을 설명하는 데에  어느정도 해당 부분은 설명이 필요하지만..

AutoParams를 모르는 내 입장에서, 내부 아키텍처까지 전부 알기엔 내용이 좀 어려웠다. 

 

앞 세션 후기에서도 언급했다시피, 내가 test fixture 라이브러리에 크게 관심이 없어서 위와 같이 느낀 것일 수도 있다. 


마치고 나서

처음에는 언제 4개 세션 다 듣지... 걱정했는데,

막상 듣고나니 괜찮다!

 

2023년 때는 아예 체력걱정을 안했던 거 같은데, 2024년에는 5시간동안 세션 들을 수 있을지에 대한 체력걱정을 하는 내 자신을 보고 놀랐다. 체력관리를 열심히 해야겠다.

 

고로 운동을 가야겠지?

설숲잠실에서 클라이밍 중~

 

그래서 갔다! 클라이밍.

스캠 같이 간 지인이랑 함께 서울숲클라이밍 잠실점을 향해 달려갔다.

 

저 문제가 해당 섹터 보라난이도 중 꿀난이도인데, 덕분에 2트만에 했다. 후후후

하지만 다른 보라문제들은 못했다.

인스타 맞팔분이자, 스태프분께서는 핀치문제 보라도 슉슉 해내셨더라. 대단하시다.

 

요즘 클라이밍에 푹 빠져서, 개발이 약간 뒷전이 됐다.

그럼 클라이밍한 걸 후회하는가? 전혀 아니다! 이거에 대해선 나중에 7~8월쯤에 포스팅할 예정이다. (아마 만 1년 개발자 후기글 관련 포스팅할 때 얘기할 듯하다.)

 

같이 간 지인과 함께 방문한 위스키바!

 

클라이밍하러 잠실까지 간 이유가 뭐냐! 라고 한다면 여길 가기 위해서였다.

사실 요즘은 술을 잘 마시진 않지만, 지인이 위스키바 한번 가보고 싶다고 해서 방문했다! 

 

다양한 위스키들이 있어서 좋음.

상호명 말하면 광고 같을테니 패스. (궁금하면 댓글 달면 비밀댓으로 코멘트 남겨드립니다)

 

사실 얻어간 지식도 지식이지만, 하루 놀러온 느낌도 어느정도 있었다 🤣

오랜만에 우테코 동기들도 보고, 못본 얼굴도 보고 너무 좋았음.

 

반응형