세미나 참석

스프링캠프 2025 후기

sendkite 2025. 6. 28. 19:08

2023년, 2024년에 이어 2025년에도 스프링캠프에 다녀왔다.

3년 연속으로 참석하게 된 셈이다. (발표 자료 -> https://github.com/springcamp/presentations/tree/main/SpringCamp-2025-Presentations)

 

2023년에는 첫 개발 오프라인 컨퍼런스라는 설레임으로,

2024년에는 기술적인 갈증으로,

그리고 2025년에는 오로지 ‘동기부여’를 위해 참석했다.

0. 현장 분위기

  • 올해 스프링캠프는 10주년을 맞은 만큼 뜻깊은 행사였다.
  • 그래서였을까, 무려 13명이 내가 평소에 링크드인이나 트위터로 팔로우하던 분들이었고, 덕분에 마치 팬사인회에 가는 마음으로 행사장을 찾게 되었다.

3월 스프링캠프 모집 공고

  • 올해는 예년과 달리 인프런에서 선착순이 아닌 추첨 방식으로 참가자를 모집했다. (비용은 4만원으로 비싸졌다.)
  • 인프런에서 연차나 성비 등을 고려해 추첨한 덕분인지, 여자 개발자나 시니어로 보이시는 분들의 비율이 늘었다. 그래도 압도적으로 주니어가 많았다.
  • KSUG 가을 세미나 또는 김영한의 50만 기념 세미나와 같은 패널 토크 형태의 발표가 3시간이나 생겼다.
    • 미리 시전 질문을 받아서 해당 주제로 토론하는 형태 (팟캐스트 처럼)
    • 취지는 참 좋았지만, 아쉬운 점도 있었다. 참가자 대부분이 주니어 개발자였던 탓인지, 질문의 깊이가 주니어에 맞춰진 느낌이 강해서 아쉬웠다.
  • 채용부스가 전멸했다. 항상 채용 상담과 같은 부스가 있었는데 올해는 찾아 볼 수 없었다. 경제가 진짜 힘든것 같다.
    • 올리브영, Flex, 카카오뱅크, AWS가 있었으나 채용보다는 회사 홍보만 진행
  • 코틀린 코너가 없어졌다. 대신 발표 내용 예제 코드가 다 코틀린이었다. (내가 들었던 세션은 그랬다)

 

드디어 이상한 손선풍기 대신에 힙한 굿즈를 나눠주는구나..
flex 부스에서 나눠준 아메리카노.. 센스

 

본론으로 발표 내용 정리해본다.

 

1. 난 spring에서 ml 서빙을 해봤어요 (김수원 님 / Sionic ai)

  • 네이버 ML, 토스 ML 엔지니어 출신, ML 전문 회사 CTO의 JVM 환경에서 ML 서빙 경험 공유
  • 이미 Spring으로 ML 서빙하며 백엔드 서비스 운영 중
  • ML을 JVM에서 서빙하는 이유, 어떻게 할 수 있는지를 공유
  • Python이 중심인 ML 서빙 환경
    • Python을 빼놓고 ML을 이야기 할 수 없다.
    • 모델을 만드는 도구가 python 베이스이기 때문이다. e.g) LangChain, PyTorch, TensorFlow, Llamalndex . . .
    • 그러나 Python으로 대규모 프로덕션 운영 하는데 어려움이 있다.
      • python은 GIL(Global Interpreter Lock) 영향으로 성능, 병렬처리 한계가 있다.
      • 패키지 및 환경 관리가 복잡하다. (라이브러리 업데이트 직접 관리)
      • 운영 한계 (타입 안정성 문제)
      • 물론 Python으로 운영 가능은 하지만, 난이도가 높다.
  • Python 말고 다른 대안은 없을까?
    • ML 추론 서버/엔진 사용 방법이 있다.
      • 엔진종류
        • 엔비디아 트라이톤
        • vLLM
        • AWS
        • OCI
      • 그러나 구축 및 운영 복잡성, 벤터 종속성 및 기술 지원 한계가 분명하다. 
      • 리소스 및 비용 부담, 문제가 생겼을때 Rust, Go를 뜯어 고쳐야하는 비용
    • JVM 기반으로 ML 서빙하는 방법
      • JVM에서 ML 서빙 지원하는 라이브러리
        • ONNX (저수준 - 최적화 필요)
        • TensorFlow (저수준 - 최적화 필요)
        • DJL (고수준 - 추상화 잘되서 최적화 필요 없음)
      • DJL
        • Java 개발자들의 ML 진입 장벽은 Python, AI을 모른다는 것이다.
          • Python 언어, 아키텍처, 라이브러리, 추론/서빙, GPU/환경에 대한 이해 선행되어야 한다. 
        • 그러나 DJL은 "Python, AI/ML을 몰라도 ML 서빙을 할 수 있게 만든다"는 슬로건으로 Java만 알아도 사용 가능하다. 
        • 다양한 모델 지원함
          • 자체 모델 지원
          • Hugging Face(전세계 모델러들의 오픈소스 허브)와 연결 되어 오픈소스 모델 부분적으로 사용 가능
        • 예시 (리뷰 노출, 판매자 패널티)
        • DJL은 Netflex에서도 활용하고 있다. (https://aws.amazon.com/blogs/opensource/how-netflix-uses-deep-java-library-djl-for-distributed-deep-learning-inference-in-real-time/)

  • JVM에서 ML 서빙의 한계도 분명하다.
    • CPU 48코어 사용
    • 메모리 몇 백기가 할당하기도 함
    • 하드웨어 성능을 0.000001%까지 쥐어짜야한다.
    • DJL은 저수준 제어가 어렵다.
  • ONNX, TensorFlow를 사용하면 하드웨어 극한으로 쓸 수 있다.
    • GPU 설정
    • GPU 병렬처리 직접 설정
    • 동적 배치처리
    • Zero-copy 메모리 최적화
    • 모델 안 최적화
      • 모델 튜닝, 코사인 유사도 빠르게 동작하게 튜닝 가능
      • 1000만개 문서 1s 이하

 

끝내며,, JVM 서빙하는 것이 정답일까?

  • 단점도 많다.
    • (모델 구조 직접 만들어야하고, 추론 코드 직접 짜야하는 것)
    • 하드웨어 튜닝
    • Spring AI 라이브러리의 미성숙도 (이제 1.0이 출시한 것이 지난달)
  • 각자의 환경, 해야하는 테스크에 맞게 환경 구성하고 서빙하면 좋을 것 같다.
  • 반드시 python을 사용하는 경우가 있으며 python 사용은 필수 불가결하다.
    • ML 테스크 중 라이브러리를 써야하는데, python에만 있을 경우, 최신성을 반영 해야하는 경우 (java는 업데이트가 느리다.)

 

2. Talk 1 - 개발자 커뮤니티 (패널 토크)

(박용권 님 (당근), 김지헌 님(컬리), 이상훈 님(야놀자))

아래와 같은 주제로 50분간 토론했다.

  • 홀로 선 개발자의 고민, 커뮤니티의 필요성
  • 커뮤니티에 발을 들이고 인연을 연결하는 방법
  • 커뮤니티 속에서 무엇을 얻을 수 있을까
  • 커뮤니티를 만들어가는 입장에서 지속가능한 커뮤니티는 뭐가 있을까

결론은, 개인이 뚜렷한 목적을 가지고 스터디나 커뮤니티 활동을 하고,

커뮤니티를 통해 다른 회사 분위기 파악, 본인 PR이 가능하며, 일단 용기내서 말을 걸어보자

 

3. Talk 2 - 함께 성장하기 (패널 토크)

(박재성(우아한형제들, Nextstep 캡틴), 변정훈(당근), 이경일(네이버))

 

  • 함께 성장 한다는 것은 무엇일까?
    • 구성원의 성과 == 나의 성과 인 것
    • 그 조직이 가지고 있는 Domain Knowlege 전파 (조직만의 도메인 지식의 전파)
    • 과거 개발자는 탁월한 기술적으로 신기술 빠르게 적용하는 사람이었는데, AI가 등장하고 도메인의 시대가 온 것 같다. AI가 대체 할 수 없는 Domain쪽에 관심을 가지고 성장해보자.
  • 좋은 개발 문화란? 
    • 문제 없는 조직은 이 세상에 존재하지 않는다. 빅테크 여러곳 다녀봐도 실망스러운 팀, 조직이 많았다. 
      • 나 조직 분위기 탓하지 말고, 좋지 않다면 바꾸면서 성장할 기회다.
      • 바꾸고, 기여하면서 성장할 수 있다. 도망가려하지 말고 변화 시켜보려는 마인드가 필요하다. 
      • 예를 들어 IT 개발자는 staff 직군인 회사에 있으며 해볼 수 있는 것 찾아서 해결 해보았다.
        • 배포 - FTP로 배포하던 것 배포 시스템 작성
        • 캐싱 시스템 제작
        • 관리자 배포 시스템 작성
  • 좋은 문화를 만들기 위해서는? 
    • 변화를 만들고 도입하기 위해서는 신뢰 자산이 필요하다.
      • 빠른 도입은 불가하다.
      • 6개월 이상 팀원 신뢰를 만들고, 천천히 작은 성공을 반복한다.
      • 조직 상황, 서비스 특성을 고려해야한다.
    • 좋은 문화, 변화는 반드시 회사 성과로 이어져야한다.
  • 심리적 안정감이 있는 조직 이란?
    • 심리적 안정감이 있는 조직은 전적으로 리더에게 달렸다.
      • 비난 받지 않는 환경, 의견 개진 쉬운 환경 조성
      • 보통 리더가 되고, 리더가 되는 준비를 하는데 그러지 마라
      • 주니어 한계를 두지 말아라 코딩 외에 소프트 스킬, 코칭 역량 쌓아가는 노력을 해야한다. 
      • 스터디가 활발하고 지식 공유가 잘되는 조직 왜 안될까?
      • 그런 팀/문화 만드는 것은 엄청 힘들다. 리더가 문화를 만들고, 동기부여, 변화를 만들어야한다.
      • 문화, 동기부여, 지식 전파와 같은 일은 AI 시대에 더욱 중요하다. (대체 될 수 없다)
    • 심리적 안정감이 없는 조직
      • 항상 노트북을 들고 다녀야한다.
      • 휴가만 가면 3년간 쓰지 않았던 api가 호출된다.
      • ‘나’ 말고는 대응할 수 있는 사람이 없는 것
        • 공유가 이루어지지 않는 것
    • 심리적으로 안정감이 있는 조직
      • 노트북을 안들고 다녀도 된다.
      • 장애가 나도 ‘아 이거 다음에 할께요. 천천히 하면 되요’가 되는 환경
  • 동료 피드백하는 좋은 방법이 있다면? 
    • 피드백을 팀원들과 원온원, 회고 문화를 가진다.
      • 개선점을 찾고 액션 플랜을 만드는 것 외로 일하면서 느낀 감정적 피드백 교류 환경이 필요하다.
    • 재택으로 온라인상 커멘트로만 피드백이 이루어지니, 감정이 전달되지 않아서 아쉬웠다.
    • 코드 리뷰가 힘들 정도로 규모가 크다면 설계도를 만들고, 대면으로 공유/피드백 한다.
      • tip )Code Rabbit
        • 다이어그램, 호출 관계 그려줌
    • 코드 리뷰에서 부정적인 내용 피드백 하는 방법은?
      • 코드상의 리뷰 : (쿠션어 사용하기) 꼭 수정하지 않아도 되는데요, 꼭 바꾸지지 않아도 되는데요..
        • 최종 결정은 구현자가 한다.
      • 대면 리뷰 - 칭찬으로 시작해서, 다 좋은데 이것만 좀 바꿔볼 수 없을까요?
      • 많은 개발자가 내가 짠 코드와 나를 일치화 하는 경향이 있다. 그러면 안된다.
        • "널 비난 하는 것은 아니고, 나는 옛날에 이런식으로 해보니까 좋았다." 같이 존중하는 감정이 전달되야한다.

 

4. 실전! MSA 트랜잭션 개발 가이드 (김용욱 님 / 삼성 SDS)

미리 설계를 해보는 것이 좋다. 트랜잭션 가이드를 소개하고 우리 상황에 필요한 것들을 찾아보자.

실무에 필요한 것은 모든 것이 아닌 일부다.

 

  • 트랜잭션 개발 가이드
    • 데이터 오너십 원칙 (서비스 간 쓰기 - 이 데이터는 저만 변경합니다! 를 정한다. - 속성별로 나눌수도 있다)
    • 실패한 트랜잭션 처리
      • 취소/재시도
      • privot transaction (from SAGA)
      • saga transaction
    • 트랜잭션 격리성 보완
      • Eventual Consistency
      • Semantic Lock (업무적인 의미의 중간 상태 값 추가)
      • TCC (Try, Confirm, Cancel) 커밋의 단계를 나눠서 try commit, confirm commit, try에 실패하면 cancel
      • Offline Lock
    • 신뢰할 수 있는 트랜잭션 구현
      • API/Event
      • 진짜 실패와, 가짜 실패 구분
      • 중복 실행, 순서 꼬임 처리

 

Talk 3 - 기술 Talk (설계)

(향로님, 조영호님, 안영회님)

  • 객체에게 책임을 부여한다는 것은?
    • 객체를 지우고 Context 부터 생각해야한다.
    • 요구사항이 주어지면 연극 시나리오를 작성하는 것 처럼, 필요한 행동, 상호작용을 떠올리고 동적인 관점에서 설계한다.
    • 행동부터 생각하고 객체를 식별하자.
  • JPA Entity vs Domain 나눠야할까?
    • 모든 경우에 좋은 것은 없다. trade off만 있을 뿐이다.
    • JPA Entity는 데이터를 처리하고, Domain은 비즈니스 로직을 처리한다.
    • 데이터 변경 속도와 도메인 변경 속도가 동일하다면 두개를 나눌 필요가 없다.
      • ex) shared DB가 존재하고 우리팀이 컨트롤 하지 못하는 상황과 같이 데이터 변경 속도와 비즈니스 변경 속도가 다를때 분리하면 좋다.
    • 변경 속도를 알 수 없다면 합쳐서 개발하고, 나중에 나눠도 늦지 않다.
    • 나누는 것이 초반 결정이 아니었으면 좋겠다. (효율 떨어짐)
  • OOP(객체지향), FP(함수형프로그래밍) Next는 무엇일가요?
    • Agentic AI 라고 생각한다. 미국 IT 투자금 절반이 흘러들어가고 있다.
    • Agentic AI 또한 modularity 분할하며 합치는 것이 핵심
  • 확장성 vs 오버엔지니어링
    • 사업적으로 10%만 성공한다. 너무 큰 확장성은 좋지 않다.
    • 문제의 복잡도에서 가장 단순한 전략을 선택한다. (나중에 이해하기 쉽게)
    • 변경이 진짜 이루어지는지 알수가 없다. 지금 가지고 있는 지식에서 가장 단순한 해결책을 선택한다.
  • 빠르게 만들어야한다, 성과 내야한다는 논리로, 레거시 코드를 반복하는 상황에서 설득하는 방법이 있다면?
    • 설득하지 않고 바꾸고 성과를 만들면 알아서 느끼더라, 가장 좋은 설득 방법은 보여주는 것이다.
  • 설계 철학 vs 조직의 제약
    • 이분법은 존재하지 않는다. 회사 돈을 받고 일하는 이상 회사가 옳다.
    • 설계는 팀의 결정이다. 팀의 전체 퍼포먼스가 좋아지면 정답이다.
    • 좋은 설계는 협업하기 좋은 코드다.
    • 남 탓하면 안된다. 당신은 뭐든 할 수 있다. 당신의 코드가 훨씬 많아져서 기존 코드를 잠식하면 된다. (XP)
    • 설계는 나를 위한 것이 아니다. 다른 사람이 내가 짠 코드를 고칠때, 사전 지식이 없을때 읽기 좋은 코드를 위한 것이다.

 

레일웨이 지향 프로그래밍과 스프링 (이선협 / 마플코퍼레이션)

  • 레일웨이지향 프로그래밍 2014년 등장
  • 개발 방법론은 사고와 기술로 바라볼 수 있다.
    • 사고 : 어떻게 소프트웨어를 바라볼지
    • 기술 : 실천 방법
  • 레일웨이지향의 사고는 소프트웨어를 성공과 실패로 바라보는 것이다. 

  • 성공과 실패(예외)에 대한 처리 중심으로 코드를 작성한다.
  • 기술 : Monad라는 개념과 함수형 프로그래밍을 통해 코드를 작성한다. 

 

 

 

반응형
저작자표시 (새창열림)