`2025 스프링 캠프(Spring Camp)`참여 후기

 

입장

컨퍼런스는 처음이라 뭔가 OO콘 같은 느낌일 줄 알았는데 생각보다 아기자기(?)해서 놀랐다.

입장하니 팔찌랑 굿즈를 주셨당

그리고 FLEX 부스에서 커피도 주셔서 09:30~17:00까지 버텼다눙(귀찮아서 점심 안 먹음)

 

세션

스프링 캠프는 리젠시 홀/갤럭시 홀 중 듣고 싶은 세션이 진행되는 홀로 이동하는 구조였다.

처음에는 2개 왔다 갔다 해야지~했는데 중간중간 계속 고민하다가 리젠시 홀에 계속 있게 됐다(?)

이럴 거면 처음부터 앞자리 갈 걸 

 

세션 들으며 기록한 걸 간단하게 써보자면...!

 

1.  JVM에서 ML 서빙을 해봤어요

머신러닝 분야는 생소한 영역이지만, 이 세션을 통해 ML 모델을 실제 서비스에 반영하는 '서빙'이라는 개념을 처음으로 이해하게 되었다.

 

대부분의 라이브러리가 파이썬 기반인 만큼, ML에서 파이썬을 빼놓을 수 없지만 프로덕션 환경에서는 GIL(Global Interpreter Lock) 문제, 패키지 의존성, 배포 난이도 등 여러 현실적인 제약이 존재한다고 한다.

이런 문제를 해결하기 위해 JVM 기반에서도 ONNX(오닉스), 텐서플로우, DJL(Deep Java Library)가 있는데,

그중 하나인 DJL은 나머지에 비해 고수준 라이브러리라고 한다.

 

수원님은 DJL을 사용한 사례를 소개하셨는데, 실제로 수백만 건의 문서가 1초 이내로 처리된다고 하셨다. 😲

물론 하드웨어 성능을 쩔게 쥐어짜내야 하는 저수준 제어가 단점 이긴 하지만, 이때는 오닉스와 텐서플로우를 사용할 수 있다고 한다.

실제 코드를 공유해 주셨었는데 예상보다 간단해 인상 깊었다.(물론 그 외에 복잡한 것들이 있겠지만)

JVM이 반드시 정답은 아니지만, 운영과 성능 사이에서 현실적인 선택지로 충분히 고려할 수 있다는 점이 흥미로웠다.

 

 

2.  함께 성장하기

내가 좋아하는 포비님을 또 봬서 좋았던 세션...ㅎㅎ

좋은 개발 문화는 성과로 증명되어야 한다

이 세션에서는 '좋은 개발 문화는 성과로 증명되어야 한다'는 메시지가 제일 기억에 남는다.

 

이전 회사에서 스터디를 지원해 준다고 할 때, 바로 동기들 모아서 JPA 스터디를 했었는데 계획서에 '성과'를 적는 파트가 있길래,

"아니 무슨 스터디 계획서에 성과를 정량적으로 어떻게 적으라는 거야?" 하면서 궁시렁 댔었다.

당시에는 너무 모든 거에 진입 장벽을 두니까 사람들이 이런 걸 더 안 하려고 하지 않을까? 생각했기 때문이다.

회사 입장에서는 이것도 하나의 투자니까 이해는 하지만, 그때 생각이 나면서 조금 반성했다.

 

또, 단순히 좋은 말을 반복하거나 슬로건을 외치는 것만으로는 문화가 바뀌지 않는다는 점을 짚어주었고, 실제로 변화가 필요한 시점에 시니어가 바뀌지 않으면 주니어의 작은 시도만으로는 한계가 있다고 했다.

실제로 이전회사에서 나도 노력을 적잖이 했었지만, 결국 그 문화가 정착되고 다들 적극적이기 위해서는 리더가 움직여야 한다고 느꼈다.

무엇보다 리더는 내 생각보다 정말 바쁘기 때문에 그 부분에 관심을 쏟는 분이 아니라면 어렵다.

 

네이버에서는 주기적으로 스터디를 하고, 발표자분은 재택 때문에 딱딱한 커뮤니케이션이 될 수 있기에 깃허브 PR에 감정을 담아 표현할 수 있도록 시각적인 다이어그램 툴을 사용한다고 하셨는데, 참 부러운 리더분과 문화라고 생각했다. 😭

 

도망가기보다는 작은 시도부터 문화를 바꿔보자는 말씀도 있었는데, 이 부분도 참 공감한다.

“어차피 안 바뀔 거잖아” 하고 아무것도 하지 않는 것과,
“그래도 뭔가 해보고, 아 진짜 안 되는구나”라고 체감하는 것은 완전히 다른 문제이기 때문이다.

물론 여기서 후자를 느끼고 나왔지만..ㅋㅋㅋ

그래도 작은 시도들을 해본 경험은 절대! 헛되지 않았다고 생각한다.

 

3.  실전! MSA 트랜잭션 개발 가이드

이 세션은 마이크로서비스 환경에서의 트랜잭션 처리 방식에 대해 가장 실용적인 인사이트를 줬다.

 

단일 트랜잭션이 불가능한 환경에서 ‘보상 트랜잭션’과 ‘피봇 트랜잭션’이라는 개념을 어떻게 설계에 녹여야 하는지,

실패했을 때 어떤 책임 단위로 롤백하거나 재처리해야 하는지를 실제 예제를 통해 설명해 주었다.

예를 들어 수강신청 서비스에서 핵심 로직을 피봇 트랜잭션으로 설정하고, 그 이후 부수적인 작업은 이벤트 기반으로 처리하는 구조는 좀 센세이션이었다. (물론 바로 이해하긴 너무 어려웠다)

 

이 외에도 TCC(Try-Confirm-Cancel), Semantic Lock, Transactional Outbox, 멱등성 처리 등 각종 트랜잭션 안정성 확보 기술들이 실제로 어떤 문제를 해결해 주는지 실제 사례로 설명해 주셔서 유익했다.

 

4.  기술 Talk 

연예인 본 것 같아서 찍었던 사진(다들 말을 너무 잘하신다)

객체지향 설계에 대한 철학적인 생각들이 중심이었던 세션이었다. 

미리 선정된 질문들을 위주로 답변하면서 진행됐는데, 정말 재밌었고 유익했다.

1. 객체에게 역할과 책임을 부여한다는 게 무슨 의미일까요?

어떤 객체가 있으니까 이 객체가 역할과 책임을 한다가 아니라 어떤 콘텐츠에서 어떤 등장인물들이 어떤 식으로 상호작용하는 게 좋은지를 생각하신 다음에 거기서 객체랑 역할 책임을 뽑아주시는 게 가장 좋으실 거예요.

우연히도 '객체지향의 사실과 오해'책을 직전에 막 완독했어서, 만약에 내가 이 질문을 받았더라면 이렇게 대답했을 것 같다

"어떤 상황을 위해 필요한 행동들을 정리하고, 그 행동들을 할 수 있는 객체들을 만든다면,

그 객체는 그 행동들에 대한 책임을 갖게 되고, 그것이 곧 그 객체의 역할이 된다."

 

그리고 전체적으로 '상호작용'이라는 말을 많이 하셨다.

 

2. JPA 엔티티와 도메인 객체를 나누는 구체적인 예시

엔티티가 바뀌는 방향과 도메인이 바뀌는 방향이 다른 경우를 고려하라. 
정확히 모르겠다면 일단 합치라

 

나누는 게 좋다고 하니까 보통 나누는데, 그럴 경우에는 둘 다 변경해야 하는 리소스를 생각해야 한다.

일단 합치고 사이드 이펙트가 생겼을 때 나눠도 된다고 하셨다.

 

3. 확장성과 오버엔지니어링 '그땐 맞고 지금은 틀린 상태'를 어떻게 판단하는지

“현재 문제에 집중해 개선하고, 미래를 너무 예측해서 설계하지 마라.
‘그런 게 들어올 거야’보다는 ‘안 들어올 거야’라는 가정을 해라.”

나도 사이드 프로젝트하면서 뭔가 객체지향을 나름 이해한 채로 개발하다 보니,

자꾸 아 이렇게 하면 더 좋을 거 같은데?를 고민하다가 시간이 많이 지체됐었다.

이 부분은 나도 아직 많이 어렵지만, 일단 현재 상황만 해결하고 빠르게 다음 태스크로 넘어가는 연습을 해야 할 것 같다.

 

4. 내 설계 철학 vs 조직의 제약 균형

두 가지를 이분법적으로 생각하지 말자.
어쨌든 코드를 빨리 짜는 게 중요한 게 아니라 오랜 기간 수정하면서 유지 보수하는 게 중요하기 때문에 , 조직의 설계 철학을 여기에 포커스를 맞추는 게 설계 철학이다.

 

5. AI가 코드를 작성하게 되는 시점에는 사람 대 사람의 협업을 위한 코드는 무의미해질까요?

“AI는 우리가 길들여야 할 대상일 뿐이다. 생산성만이 베스트는 아니다.”

나도 요즘 "밥줄 끊기는 소리 여기까지 들리네요"라는 말을 자주 할 만큼, AI에 대해 위기감도 느끼고 두렵다.

하지만 결국 AI는 방법을 제안할 뿐이지, 선택하는 건 개발자이기 때문에 결국 개발을 잘하는 사람이 좋은 코드를 선택할 수 있다고 생각한다.

 

그리고 만약 사람이 하는 코드가 의미가 없어진다고 해도, 그건 진짜 그 상황이 닥쳐오고 있을 때 할 생각이지

지금 내가 저 상황이 올 것 같으니 이제 의미 없어라고 생각하는 건 시간 아깝다고 생각한다...

 

5.  빅뱅 방식으로 최선의 개발하기

까먹고 녹음을 안 해서 정리를 많이 못했다.. 바보바보 ㅠ.ㅠ

 

트리 구조로 도메인 분석하시고, 각 API에 대해 화면을 다 그리시는 게 정말 센세이션이었다.

처음에는 “이건 너무 큰 비용 아닌가?” 싶었지만, 백엔드 개발자 1명이 하루 만에 끝낼 수 있다고 하셔서 또 한 번 놀랐다.

하지만 조금 시간이 든다고 해도, 유지보수 관점에서 진짜 좋겠다고 생각했다.

 

처음에 도메인 분석의 중요성을 소개하셨다. 기획이 자주 바뀌더라도 도메인 구조 자체는 잘 바뀌지 않기 때문에, 초기에 도메인을 제대로 분석해 두면 코드는 훨씬 간단하게 대응할 수 있다고 하셨다.

분석 그 자체가 하나의 문서 역할을 하면서 팀 전체가 최소한의 도메인 이해를 공유할 수 있고, 기획 단계에서 발생할 수 있는 오류들을 사전에 걸러낼 수 있다고 한다.

 

마지막으로

듣고 싶은 다른 세션들도 많았는데, 양자택일을 해야 한다는 게 참 아쉬웠다.

2~3개월 뒤에 녹화본이 올라온다고 하니 그때 또 정리해야겠다.

겟한 굿즈들

내가 서울에 미리 올라온 이유 중에 이런 행사들 접근성을 줄이기 위함도 있었는데, 역시나 이번에도 고민 없이 행사에 참여하는 서울개발러(?)분들이 참 부러웠고, 네트워킹 하면서 뵀던 분들도 마주쳐서 인사 나눠가지고 신기했다!

뭔가 행사 다니면 눈에 익는 분들이 많아질 것 같기도 하다