Notice
Recent Posts
Recent Comments
Link
«   2026/05   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Tags
more
Archives
Today
Total
관리 메뉴

yesolje

SpringCamp 2025 세션 요약 본문

카테고리 없음

SpringCamp 2025 세션 요약

yesolje 2025. 6. 30. 01:12

 

🌿난 스프링에서 ml 서빙을 해봤어요

 
ML 서빙이란 무엇이고, 기존 방식의 한계는 무엇일까?
머신러닝(ML) 서빙이란, 학습된 모델을 실제 서비스 환경에 배포해 실시간 혹은 배치 방식으로 예측 결과를 제공하는 것을 의미한다. 예를 들어 사용자가 웹 서비스에서 상품 리뷰를 입력하면, 이를 실시간으로 분석하여 긍정/부정을 판단해주는 기능이 바로 ML 서빙의 대표적인 예다. 현재 대부분의 ML 서빙은 파이썬 기반으로 진행된다. 파이썬은 머신러닝 생태계에서 가장 널리 사용되는 언어이며, TensorFlow, PyTorch 등 풍부한 라이브러리와 프레임워크를 통해 빠르게 모델을 개발하고 실험할 수 있다.
하지만 개발을 넘어 ‘서빙’의 단계로 진입하게 되면 상황은 달라진다. 파이썬은 인터프리터 언어이고, 대규모 트래픽이나 병렬 처리, 안정적인 배포 환경에서는 여러 제약이 발생한다. 특히 파이썬 기반의 서빙 엔진들은 대부분 네이티브 레벨에서 최적화되어야 하고, 장애 대응이나 성능 튜닝 시 고도의 전문성이 요구되며, 기술 지원이나 운영 비용 또한 부담이 된다. 이러한 이유로 ML을 서비스에 적용해보고 싶은 개발자들, 특히 백엔드 중심의 자바 개발자들에게는 파이썬 기반의 ML 서빙 환경은 높은 진입장벽으로 느껴질 수 있다.
JVM 기반 ML 서빙, 자바 개발자를 위한 대안
이러한 문제의식 속에서 JVM 기반의 ML 서빙이 하나의 대안으로 제시되고 있다. 스프링 캠프 세션에서는 DJL(Deep Java Library)을 중심으로 자바 개발자가 기존 생태계를 활용해 머신러닝 모델을 서빙할 수 있는 방법이 소개되었다. DJL은 PyTorch, TensorFlow, ONNX 등 다양한 백엔드를 추상화하여 자바 코드로 쉽게 모델을 로딩하고 추론할 수 있게 해주는 라이브러리다. 이를 통해 자바 개발자는 익숙한 언어와 프레임워크 환경 내에서 ML 모델을 운영에 적용할 수 있으며, JVM 기반의 높은 안정성과 성능도 함께 누릴 수 있다.
세션에서는 실제 리뷰 분석 모델을 예로 들어, 텍스트 리뷰 데이터를 입력받아 긍정/부정을 분류하는 과정을 DJL 기반으로 구현한 사례를 소개했다. 또한 GPU 자원 사용량 최적화, 배치 처리 설정, 병렬 추론 처리 등 고성능 서빙에 필요한 세부 조정도 자바 환경에서 충분히 가능하다는 점이 강조되었다. 단순히 ‘자바에서도 할 수 있다’는 수준이 아니라, 실제 서비스에 적용 가능한 수준의 실용성과 성능을 보여준 셈이다.
이처럼 JVM 기반 ML 서빙은 파이썬 중심의 한계를 보완하면서, 기존 백엔드 개발자의 역량을 최대한 활용할 수 있게 해준다. ML이 더 이상 특정 언어나 전문가의 영역에만 국한되지 않고, 다양한 서비스 맥락에 융합될 수 있도록 돕는 현실적인 대안으로 떠오르고 있다.
 

🌿Amazone Q developer 와 함께하는 생성형 AI 시대 헤쳐나가기

 
Amazon Q Developer: 안전한 생성형 AI 기반 개발 도우미
Amazon Q Developer는 AWS가 제공하는 안전한 생성형 AI 기반 개발 지원 도구다. 이 툴의 핵심 목적은 개발자들이 더 빠르고 효율적으로 소프트웨어를 개발하고 유지보수할 수 있도록 돕는 데 있다. 특히 코드 작성뿐만 아니라, 리팩토링, 테스트, 버전 업그레이드, 문서화 등 실무에서 자주 마주치는 반복적이고 번거로운 작업들을 AI가 자동으로 수행해준다. 단순한 코드 보완을 넘어, 실제 운영 환경에서 발생하는 문제들을 AI가 이해하고 조치할 수 있도록 설계된 것이 특징이다.
Amazon Q Developer는 AWS 환경에 최적화되어 있으며 정확한 코딩 가이드와 추천을 제공하여 운영 안정성과 보안성을 동시에 확보할 수 있도록 돕는다. 일반 개발자뿐 아니라 인프라 개발자, 레거시 시스템 유지관리자들에게도 특히 유용하다. 예를 들어, 레거시 시스템의 자바 버전이나 스프링 부트 프레임워크를 최신으로 업그레이드하는 작업도 간단한 명령어 한 줄로 수행할 수 있으며, 기존 문서를 기반으로 LLM의 한계를 보완한 ‘에이전틱 AI’ 구조를 통해 문맥 기반 대응력도 갖췄다.
에이전트 기반 구조와 유연한 도구 지원
Amazon Q Developer의 가장 큰 장점 중 하나는 목적별로 세분화된 에이전트를 제공한다는 점이다. 예를 들어 개발자 요구사항에 따라 코드 작성은 /dev, 테스트 자동화는 /test, 보안 점검은 /review, 문서 자동화는 /doc, 버전 업그레이드는 /transform 명령어로 각각 수행할 수 있다. 이처럼 각 기능에 특화된 에이전트들이 존재하며, 이들은 단순 실행에 그치지 않고 스스로 계획을 수립하고 반복 수행하는 ‘자율 행동형 AI’로 작동한다.
또한 다양한 환경에서 유연하게 사용할 수 있다는 것도 강점이다. 명령형 CLI 툴로 제공되기 때문에 단순 채팅 방식으로 명령을 입력하는 것만으로 기능을 수행할 수 있으며, IDE에 종속되지 않고 보다 빠르고 정확한 코드 생성을 기대할 수 있다. 지원하는 개발 환경도 폭넓다. Eclipse, IntelliJ, VS Code 등 주요 IDE에서 플러그인 또는 확장 프로그램을 통해 연동이 가능하며, 개발자는 본인의 스타일에 맞는 환경에서 Amazon Q Developer의 모든 기능을 누릴 수 있다. 시스템 프롬프트나 동작 룰도 사용자 정의가 가능하여, 팀이나 조직의 코드 규칙에 맞춘 설정도 할 수 있다.
실제 사용성과 비용 측면의 경쟁력
최근 많은 개발자들이 활용하는 AI 코딩 툴 중 하나인 Cursor와 비교해보더라도, Amazon Q Developer는 기능적 측면에서 전혀 밀리지 않는다. 특히 무료 티어에서도 제공되는 기능들이 매우 강력하며, 소규모 프로젝트나 개인 개발자 수준에서는 비용 부담 없이도 충분한 생산성 향상을 체감할 수 있다. 예를 들어 코드 자동 완성, 테스트 코드 생성, 보안 취약점 진단, 문서 생성 등 대부분의 작업을 프리 티어에서도 빠르게 수행할 수 있으며, 기업용 유료 플랜은 월 $19 정도로 합리적인 가격에 제공된다.
또한 AWS 인프라에 최적화되어 있다는 점은 단순한 AI 도우미를 넘어 실질적인 DevOps 및 클라우드 통합 작업에 강점을 제공한다. 다양한 언어와 프레임워크를 지원하고, CLI 기반 툴로 IDE와 독립적으로 작동하기 때문에, 특정 개발 도구에 종속되지 않고 더 빠르고 정확한 대응이 가능하다. 이러한 점에서 Amazon Q Developer는 단순한 편의성 이상의 가치를 지니며, 특히 Cursor를 이미 써본 사용자라면 그 효율성과 통합성 측면에서 확실한 차이를 체감할 수 있을 것이다.
 

🌿Talk Session - 함께 성장하기

 
함께 성장하는 개발 문화, 신뢰와 피드백에서 시작된다
이번 토크 세션은 도메인 지식의 공유, 팀 내 신뢰 구축, 심리적 안정감, 그리고 진정성 있는 피드백의 중요성에 대한 깊이 있는 이야기로 채워졌다. 단순히 기술 역량을 넘어서, 함께 성장하는 조직을 만들기 위해 우리가 무엇을 해야 하는지를 다뤘다.
먼저, 주니어든 시니어든 함께 일하기 위해서는 조직만의 도메인 지식을 잘 전파하는 것이 중요하다는 이야기가 나왔다. 새로운 동료가 합류했을 때, 서비스를 이해하고 빠르게 적응할 수 있도록 돕는 것은 팀 전체의 성장 기반이 된다.
또한 팀 분위기 속에서 공유와 피드백이 얼마나 자연스럽게 이루어지는지가 개발 문화의 핵심이라는 점도 강조되었다. 문화가 없는 조직일수록, 외부 커뮤니티 활동이나 소규모의 변화 시도부터 시작해보는 것이 좋은 방법이 될 수 있다는 제안도 있었다.
변화를 만들기 위해선 먼저 신뢰를 쌓아야 하며, 그 과정에서 작은 성공 경험이 큰 자신감으로 이어질 수 있다. 특히 심리적 안정감이 높은 조직일수록 생산성이 높아지는데, 이는 리더의 역할이 크다는 점도 짚어주었다.
피드백에 있어서도 진심 어린 태도와 상대방에 대한 존중이 중요하다. 부정적인 피드백이라도 상대방의 성장을 진심으로 바란다는 마음이 바탕이 되면, 그 피드백은 관계를 해치기보다 오히려 신뢰를 높이는 계기가 될 수 있다. 칭찬과 긍정적인 말로 시작하는 습관도 피드백을 부드럽게 만든다.
결국 좋은 개발 문화는 "기술만이 아니라 사람을 향한 관심"에서 출발한다는 메시지가 전해졌다. 실력이 부족해도 괜찮다. 중요한 건 함께 나아가려는 태도와, 그 안에서 조금씩 시도해보는 용기다.

 

🌿실전 MSA 트랜잭션 개발 가이드

 
 
마이크로서비스에서의 트랜잭션 처리와 데이터 책임 설계
마이크로서비스 아키텍처(MSA)는 시스템을 서비스 단위로 나누어 각 팀이 자율적으로 개발하고 운영할 수 있도록 돕는 구조다. 이를 실현하려면 서비스 간 경계가 명확해야 하며, 그중에서도 데이터 오너십이 핵심 원칙 중 하나로 꼽힌다. 각 서비스는 자신이 소유한 데이터만 수정할 수 있고, 다른 서비스의 데이터는 조회(read)만 가능해야 한다. 예를 들어 고객 정보를 담당하는 서비스만 고객 테이블을 수정할 수 있고, 나머지 서비스는 복제하거나 조회만 허용하는 방식이다.
하지만 이렇게 DB를 분리하면, 여러 서비스에 걸쳐 데이터를 수정해야 할 경우 트랜잭션 일관성을 보장하기 어려워진다. 전통적인 2PC(2-Phase Commit) 기반의 분산 트랜잭션은 운영 복잡성과 성능 저하 문제 때문에 권장되지 않는다. 그래서 이 세션에서는 '피벗 트랜잭션(Pivot Transaction)’이라는 현실적인 대안이 소개되었다. 이는 논리적인 트랜잭션의 기준점을 두고, 그 이전까지는 트랜잭션을 커밋하고 이후는 이벤트 기반으로 처리하는 방식이다. 예를 들어 수강신청 → 커뮤니티 등록 → 실습 등록 순서에서 실습 등록만 실패해도 앞선 작업은 롤백하지 않고 유지한 채, 나머지는 보상 처리나 재시도로 해결한다.
트랜잭션 충돌이나 데이터 경쟁 상태를 막기 위해 SELECT FOR UPDATE와 같은 DB 락, 시멘틱 락(의미 기반 중간 상태 설정), TCC 패턴(Try-Confirm-Cancel) 등 다양한 전략이 활용된다. 특히 MSA 환경에서는 격리 수준이 낮기 때문에 이런 조치들이 중요하다.
또한 신뢰할 수 있는 트랜잭션 처리를 위해서는 멱등성(idempotency)도 중요하다. 동일한 요청이 중복으로 들어왔을 때도 결과가 일관되게 나와야 하며, 실패한 요청이 재시도되더라도 시스템이 이상 없이 동작해야 한다. 이를 위해 요청 전에 상태를 기록하고, 결과를 받아서 갱신하는 방식으로 트랜잭션 흐름을 설계하는 것이 권장된다. 또한 이벤트에 버전 정보를 포함하면 처리 순서를 통제할 수 있어 충돌 방지에 유용하다.
결국 마이크로서비스에서 중요한 건 단순히 나누는 것이 아니라, 분리된 시스템 간에도 신뢰성과 일관성을 어떻게 유지할 것인가에 대한 설계와 운영 전략이다. 이번 세션은 실무에서 마주하는 다양한 트랜잭션 문제에 대한 구체적 대응법을 제시하며, MSA를 안전하게 도입하고 운영하기 위한 기반을 정리하는 데 큰 도움이 되었다.
 

🌿레일웨이 지향 프로그래밍과 스프링

 
이 세션에서는 소프트웨어 로직을 마치 선로처럼 설계해, 성공과 실패의 경로를 명확히 분리해 다루는 Railway Oriented Programming 기법을 소개했다. 핵심은 "예외를 값처럼 다루자"는 함수형 프로그래밍 철학과, 타입 시스템을 활용한 안전한 예외처리 방식이다.
기존의 예외 처리 방식은 throw, try-catch로 흐름을 중단시키는 구조였다면, ROP는 Success와 Failure라는 두 개의 선로를 정의하고, 예외를 값으로 처리해 흐름을 분기시키되 끊지 않는 방식을 사용한다. 이때 중요한 개념이 모나드(Monad)이며, 이는 값과 그 처리 과정을 감싼 컨테이너로, flatMap 같은 함수로 합성 가능하다. 예를 들어 .recover, .fold, .ignore 같은 패턴을 사용하면 복구하거나 무시하면서 로직을 계속 이어갈 수 있다.
ROP의 설계 방식은 계약에 의한 설계(Design by Contract) 개념과도 맞닿아 있다. 입력값의 유효성 검증을 ‘전제조건’, 출력값의 검증을 ‘사후조건’이라 보고, 타입 수준에서 이 계약을 명시함으로써 컴파일 타임부터 오류 가능성을 줄일 수 있다. 이는 @Validated, Optional, Result 등의 개념과도 잘 어울린다.
다만, ROP에도 제약이 있다. 예외를 값으로 처리하는 구조는 Spring의 @Transactional 같은 트랜잭션 처리에서는 문제가 될 수 있다. 이유는 예외가 실제로 throw되지 않으면 rollback이 발생하지 않기 때문. 이 경우에는 실제 예외를 던지는 방식이 필요하다.
자바에서도 함수형 예외처리를 위해 Vavr 같은 라이브러리를 사용할 수 있다. 이 라이브러리는 Try, Either, Option 등 모나드 유틸리티를 제공하며, 자바에서도 불변성과 함수형 흐름을 구현할 수 있게 해준다.
결국 이 세션의 메시지는 명확하다:

  • 예외도 값처럼 다루자
  • 흐름은 끊지 말고 분기하자
  • 타입 시스템과 계약 기반 설계를 적극 활용하자

ROP는 모든 상황에 적합하지는 않지만, 명확한 분기 처리, 예측 가능한 흐름, 테스트 용이성이 중요한 도메인에서는 강력한 설계 방식이 될 수 있다.

 

🌿후기

 

처음 가보는 컨퍼런스였는데 참가비가 아깝지 않은 알차고 빡빡한(?) 시간이라 좋았다. 강연자가 참가자를 가르친다는 느낌보다는 본인들이 직면했던 문제들과 해결방법을 수평적으로 공유하는 느낌이 들었다.

특히 amazone q developer 와 talk session 을 인상깊게 들었다. 바이브 코딩이 들어올 수 없는 성역(?) 같은 이클립스에도 생성형 ai 의 도움을 받을 수 있게 되어 내 업무에도 활용할 수 있는 포인트가 되겠다 싶었다.

또, Talk Session에서는 시니어 개발자들도 소통과 협업을 매우 중요하게 생각한다는 인상을 받았다. 그만큼 기존 방식을 바꾸는 일은 신중하게 접근해야 한다는 메시지도 강하게 와 닿았고, 나 역시 함께 일하는 동료에게 신뢰를 줄 수 있는 개발자가 되어야겠다고 다짐했다.