Spring camp 2025

회사 칭구들 덕에 갑자기 취소표를 잡아 참석하게 되었다.

주말이라 아침에 눈떳을 때 잠시 가고 싶지 않았었는데

막상 갔더니 Spring conference라 그런지 업무에 겹치는것도 많고 알아들을 수 있는 것도 많아 재미있었다.

꼭 몇가지 따라해봐야지 야야야

---

최종 후기

- 재밌었다. 

- 이런데선 개념 위주보다는 저 회사에서 어떻게 쓰는 지 왜 그렇게 썼는지 그런 인사이트 얻어오는게 더 좋은 것 같다 

- 아침에 졸려서 오기싫었는데 꽤나 재밌었다. 특히나 회사의 경험 공유 세션들이 

- 모니터링 + 분산 트레이싱 반복적으로 나옴 봐야할 것!

이번에 꼭 해봐야 할 것 해보고 시푼거 

(하고있는거~~)

- 분산트레이싱 + 모니터링

- 아마존 Q Developler

- 어노테이션 (데이터 처리에 있어서)

- 로컬 캐시나 레디스까지 써보기

- 책임연쇄 적용

- jvm 파악

- 도메인 분석을 트리구조로 분석해보기

  - 트리구조 작성 툴이 뭐가 있징

- 멀티모듈 파악해서 어떻게 어떻게 했고 버전관리 어떻게 했다 확실하게 인지해놓기

- 재미있게 개발하고 있다고 말하기

  - 발표를 진행했던 친구가 재미있게 개발을 하고 있다는데 좀 부럽기도 했었고 신기하기도 했었고 나는 과연 어디가서 이렇게 말을 할 수 있는가 생각이 들어서 넣었다. 이렇게 말을 못한다면 그것은 나의 문제인가 외부의 문제인가 하며 생각이 많아져서 넣어봤다. 어차피 노비인거 즐겁게 일하고 싶다~~

 

---

강의 내용 정리

1. Spring ML Serving -> JVM ML 서빙 

기존의 ml이란 
- ml == python == ml
- but production에서 파이썬 제약 많음 
- ml추론 서버 엔진 사용 aws oci nvidia .. etc 도 많지만 어렵 

jvm ml 서빙하기 위한 여러 방법들 
- onnx, djl, tansorflow lib 사용

djl 특징
- djl 상대적으로 고수준의 라이브러리. 추상화 잘 되어있음 -> 일단 얘로 ㄱ
- 다양한 모델 지원

- 몰라도 djl로 서비스 할 수 있게 하는게 얘네 철학임 멋지네
  - 자바개발자의 허들 -> python 모델 아키텍처 이해도 서비스 추론 gpu 환경 등에 대한 이해 
- 넷플릭스에서 활용 중 

djl 활용 예시
- 커머스 : 검색 추천 리뷰 데이터 분석 등 
 - 리뷰 노출, 판매자 패널티
   - 리뷰 -> 리뷰분석 모델 에 넣으면 -> 긍정인지 부정인지

Spring AI
- spring에서 ml serving 할 때 spring ai 도움됨
- 하지만 지원은 많이 느림 
-> jvm에서만 서빙하는게 답은 아님 클라우드 서비스 엔진 파이선 뭐 등등 여러가지 통해서(or 조합해서) 잘 서빙하세용 ..

 

ㅎㅎ 주로 하는 분야가 아니라 어려웠다.

 

2. Amazon Q developer 생성형 ai

현대 소프트웨어 개발의 패러다임
- ai 등장 전 제일 큰 화두 : 컨테이너 (쿠버네티스 eks)
- ai 시대 도입

생성형 AI 킬러앱
- 코드 생성 (code assistant)
- 지원 챗봇 (이전에 많음 지금은 조금 떨어짐)
-> 코드 생성으로 많이 초점이 맞춰지고 있음 

Amazon Q Developer
- 소프트웨어 개발 사이클 전반(SDLC)에 걸쳐서 도움을 주는 aws 서비스임.
- 사용 패턴
  - 인프라(terraform) / 일반 개발자 두 종류로 나뉨
-> 일잘하는 내 비서 너가 일해라 난놀게 처럼 사용 

sw 개발 관점에서 Q
- 작년엔 RAG (llm이 학습하지 못한 우리회사의 데이터를 어떻게 주입시키지)
- 올해는 Agent AI (여기중에 한가지 들어가는게 rag)
- 각각 단계의 agent가 있음 
        - 개발, 분석, 테스트, 리뷰 
        
어떤기능들이 있나요?
- /dev 쓰고 자연어를 추가햐아한다는거 굉장히 자세하고 길게 .. -> 그럼 얘가 계획세워서 동작
- /test 유닛테스트 생성 에이전트 
  - 파일이 있으면 어떤어떤 테스트 코드 만들어야겠다 얘가 생각을 함 
- /review 코드 리뷰 보안관점인듯
  - /doc 문서화 기본적으론 리드미를 만들어줌 주석이나 javadoc, 코드 전반적 설명 다 됨
  - /transform java version transform도 지원함
     - cobol to java
     - vmware to ec2
     - .net to linux

- java version 1.8 to 17 or 21
  - spring boot 기반으로 지원을 함
  - boot version up 도 지원..

cli tool
- gemini cli.. 
- 이제 ide안쓰게 될거야!라는 ...
- cli가 ide보다 지원이 빠르긴함 
- 초기 프로젝트 생성부터 테스트, 문서 다 잘만듦 

mcp
- llm 모델에게 무기를 쥐어줄 수 있는 프로토콜
- 멋지네
- 잘 쓰면 시간 많이 줄여줌 학습 시켜서 얘가 대신 일하게 해주는 것

 

명심사항
- data sharing 해제 하고 쓰기!
- 빌더id != aws account id 계정 필요 없고 빌더id 만들어쓰면됨 -> 횟수제한 외에 큰 다른게 없어서 free tier써도 충분히 쓸 수 있다
- 지시를 명확하게 잘 해야한다 (프롬프트엔지니어링을 잘 해야한다)

 

3. 올리브영 물류시스템 개선기

상품 수급 / 재과 관리 / 발주 - 입고 - 재고 반영 까지의 주문 관리 시스템(OMS)
 
as-is 의 issue
- as-is 주기적으로 데이터를 계속 체크해서 여기저기 옮김 -> 데이터 지연
- enterpase
  - 순차 처리해야함
  - 실시간 보장 못함

to-be
- 메시징 기반의 kafka 준실시간 데이터 연동으로 변경
- 특정 이벤트 기반 (lambda + event bridge)
- 에러 핸들러 dlq (알람 + 백업 for 재처리)

고민과 해결
- 운영 어려움. 배치 시스템이라 첨부터 끝까지 아키텍처를 다 변경해야함. 카프카 아는 사람 잘 업슴 -> aws msk 사용 + 인프라팀의 지원 
- 파티션 순서 보장을 해야함(기존 시스템 연개 부담) -> 단계적 전환. 물류센터와 접목된 데이터 연동 프로세스에 한해 이벤트 구조로 운영
- 순서 보장 꼭 필요 -> 키 기반
- 개발자 및 운영자 학습 곡선 -> poc 많이함

모니터링
as-is
  - 데이터 지연에 의해서 배치가 암것도 처리 안하고 끝나버림. 미리 인지 없이 실제 사용자가 데이터 보고 이상해서 알려줌 
  - 오류가 났으면 왜 오류가 났는지 -> as-is idc 직접
to-be
  - eventbrdge + lambda -> 출고처리 모니터링 99%까지 안가면 -> On call (voice call 같은거)
  - datadog dashboard 사용
  - 실시간성과 확정성을 위한 RDB 중심 구조 탈피

온오프라인 재고 도메인
- 온라인몰에서 구매했지만 특정 서비스 사용 시 오프라인 조회 API 사용.
- 장애 
  - 임계치 도달 오프라인 디비 -> read 읽기 분산 디비 분리 (redis)

oracle to redis 실시간 성 얻고자 마주한 세가지 이슈
1. 동시성 제어 (batch - stock service - redis)
- oracle : 여러 클라이언트 동일 재고 업데이트 시 row-level lock으로 동시성 제어 가능 (어느정도 보장)
- 레디스 : 단일 스레드로 동작해 단일 명령에 충돌 없으나, 재고 조회 하고 증가 처리하고 저장하고 다시 조회하는 이런 복합 명령어 사용시 동시성 이슈 있음 
-> 레디스 분산 락 사용 (redis + redisson + reactive 방식 지원)
- aop내 @Lockable 어노테이션 사용

2. 조회 성능 이슈
- 단건 조회 케이스는 더 빠름 레디스는 메모리 기반이니
- 복수건 조회 -> oracle : 인덱스 사용 / redis : 커서만큼 반복 조회 해야하니 수초에 달하는 반복시간이 필요함
-> 조회용도별로 성능 최적화를 위해 redis 데이터 셋을 3가지로 구성
  - Stock HashKey 특정 매장 코드 + 상품코드 명확한 단건 (상품 상세, 장바구니 등)
  - Store HashKey 특정 매장 코드 기준으로 모든 상품 재고 조회 (매장 해시코드 기준으로 필드 hscan) (전자 라벨 등)
  - Product HashKey 특정 상품코드 기준으로 상품코드 가지고 잇는 모든 매장 조회 (검색엔진 등)
-> 약 10배 성능 향상 
3. 안정성 이슈 
- 디스크 기반(oracle) vs 메모리 기반 (휘발성, 레디스)
- aws에서 하고 있음 
- 서킷 브레이커 패턴 사용 : 시스템 장애 감지 호출 시 기존 호출 차단하고 대체 경로로 흘려보내도록
  - 장애나면 oracle 보도록 서킷브레이커 사용중

cdc (event)
- 배치 이렇게 개선 진행 중이다 

결론
- 남일같지않은데 저 회사는 변했네 우리도 변하려나 ㅎㅎ 또 하필 이타이밍에 문자도옴 거참 ㅋㅋ
- 전자라벨. 전자였음. 매장에 있는 것 들이
- 레디스 잘 써보면 좋겠네. 데이터 셋 잘 설계 하는게 관건 같고 레디스는 도움을 줄 뿐이지 결국은 원 디비도 사용
- 대신 rdb중심보다는 redis 도움 받으며 rdb와 함께 잘 쓰는거겠네 

4. Virtual Thread

Overview
- jdk21 공식 추가 어플리케이션 레벨 쓰레드
- 목표 -> 높은 동시 처리량 필요한 서버를 쉽고 효율적으로 만드는 것 도움
- 높은 Blokcing I/O 처리량

Virtual Thread Scheduling
- 기존 코드 변경 없이 블로킹 io 환경에서 어떻게 높은 처리량 가능한지
- 중단 실행을 위해 두가시 요소 필요 
    - scheduling, conetxt switching
-> 빠른 실행과 중단

Function & Coroutine
- Function : 중간 상태 저장안함
- Coroutine : 여러지점에서 멈췄다가 다시 시작 실행 중단 재개 가능  -> Runnable 실행 중단 재개 하려면 필요 이런 기능

kernel과 virtual thread
-> continuation과 실행할 runnable을 가진 인스턴스이다

Socket I/O
- virtual thread는 contiunonatoin을 통해 Platform Thread의 메모리를 조작하여 자신의 러너블을 실행 & 중단다게 한다. -> Context Switching
- pinning issue는 jdk 24에서 해결이 되었다 예!

오 정말 어렵다. virtual thread... 발표 주제랑 톤 이런거 다 너무 좋았는데 진짜 말 그대로 너무 어려운 영역이라 잘 못받아서 너무 아쉬웠다.

공부 열심히 해서 다시 이해해봐야겠다.

'후기중에 개발자 부부라니 부럽다 너무 어려워서 아쉬웠다'라는 후기가 있었는데 정말 똑같은 흐름대로 생각을 해서 웃겼다 ㅋㅋ

5. 사내 Spring Boot Starter를 활용해 공통 기능 추상화와 개발 생산성 향상

오픈소스 Spring 으로 개발한 펀드 시스템
- 은행 공통 기능 라이브러리화 
- 어떤 기능을 어떻게 추상화 했는지  

모놀리식 단일 시스템의 문제들
- 처음엔 단순하고 빠르게 개발하지만 규모가 커지면..? 많은 이슈 존재 
- 클라우드 환경위에 오픈소스 스프링으로 서버 구축 -> 당연한데 당연하지 않음

전통적인 금융 fw
- 자바기반
- 오픈소스가 아닌 상용 프레임 웍 (빠르게 구성 가능, 신뢰성 높음)
  - 기술이 프레임워크 제공하는 벤더사에 종속되어있음
  - 커스터마이징 유지보수 어려움

각 프로젝트의 핵심 관심사 / 공통 관심사 
- 공통 
  - 데이터 직렬화 / 역직렬화
  - 트레이싱
  - 통신 설정 등
-> 입맛에 맞게 구현해도 되지만 공통기능인데 각각 구현 시 이슈가 많음 
-> 공통 기능을 라이브러리화 + 각 프로젝트는 각자의 관심화

starter 구조
- starter : 여러 의존성 묶어놓은 편의용 의존성 모음
- context : 라이브러리 핵심 기능 
- auto-configure : contextx에 작성된거 빈으로 등록하여 스프링 생태게에서 사용 가능하게 

공통의 문제를 어떻게 해결했는지
1. @FixedLengthCaharacter(10) 어노테이션 생성 역직렬화/직렬화 시 업무 특성 상 커스텀하게 사용할 경우 어노테이션 만들어 잭슨 모델 활용해서 사용
2. 사내 http client api 통신 추상화 제공  
  - 책임 연쇄 패턴을 사용해 구현의 표준 제공 (ClientHandler(interface) : handle메서드..등 - 직원검증ClientHandler / 부서검증_ClientHandler)
  - 자기 역할을 완료하고 다음 핸들러 호출 
  - handler Chain 필요한 일을 한가지 일만하고 체인처럼 다음으로 역할 
-> 확장성, 책임 분리 굿
3. 분산 트레이싱 단위 시스템간의 추적
- 로그만으론 서비스 인과관계 찾기 어려움 
- 이미 잘 구현해둔 시중 분산트레이싱 라이브러리 많음 -> 활용하면 좋지 (데이타 독 등) + 시각화 **
  - 트레이싱 뿐 아니라 서비스에서도 추적해서 확인 할 수 있게 뭔가 더 처리해서 봄 **
  - Baggage 라는걸 씀? 저장해놓고 프로그램 어디서든 사용할 수 있게 해줌

  
- 마스킹 규칙, 엔드투앤드 암호화등 많음 
-> 도메인에 집중할 수 있는 개발 환경 완성 (개발해야할 기능 파악에 집중)

 

도메인이 겹쳐서 그런가 정말 재밌게 들었다. 이미 우리도 하고 있는 것도 있고 배워갈 것도 많았다.

- 어떤걸 어떻게 나누어 줘야할까?
- 우리도 그냥 짤라버릴게 아니라 (엑셀이나 csv같은거 어노테이션 만들어서 좀 지정잘해보기)
- 책임연쇄패턴 적용해보기 

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

정의

- 빅뱅방식 : 처음부터 끝까지 한번에 개발
- 이터레이션 방식 : 단위별로 기능을 쪼개어 개발 

왜 어렵냐 빅뱅
- 기간짦음 양이많음 클라이언트 멍청함 걔들도 모름
- 프로젝트 도메인 구조 목적파악 어려움
- 인원 늘어날수록 문제점 증가 

개발 프로세스 개선

 

트리구조 정리(도메인분석)
- 트리구조로 프로젝트 정리 해보기
- 왼쪽에서 시작해서 오른쪽 방향으로만 진행
- 명시적인 이미지 통해서 구조 파악 쉬워짐

 

도메인 분석
- 최상위 개념 설정
- 어떤 개념이 상위 개념인지 파악하는게 가장 중요! ** 
- 잘못된 위상은 잘못된 설계를 만든다
- 한번에 정확하게 파악한다는 환상은 버려라 
- 논리적 오류가 발견되지 않을 때까지 점검 수정
- 개념에 대한 명확한 정의
- 하위개념 분류 or 조건 or 특성
- depth

 

API 스펙 작성
 - httpMethod 기준 모든 API
- 피그마의 모든 request, response 스펙을 트리 구조로 작성해보기 
  - 파사드 패턴 형대로 필요한 기능 조립

 

라이프사이클 설계
- 생성,조회, 수정, 삭제 등 
- 복잡한 로직의 관계성 파악하기 쉬움
- 명확한 트랜잭션의 범위 지정 가능 

 

멀티모듈
- 구성 : 도메인,  어플리케이션, 컨피크, 인프라
-> 이런식으로 나누어사용
- 규칙
  - 서로 참조하지 않는다.
  - 완전한 격리성 확보
   - 연관관계 금지
- 도메인 분석의 근거한 모듈 설계
  - 엔티티 이넘 작업
    - 격리성 최대화 / 나눠서 작업 가능 등 장점
    - 퍼블릭 인터페이스를 통해 강력한 캡슐화 구현

장점
- 분석 자체가 하나의 문서
- 최소한의 도메인 이해도 보장

도메인 분석 이후 
- erd 작성
- 모듈 및 패키지 생성
- 엔티티 이넘 코드 상수 작성 

- 우린 빅뱅인가 이터레이션인가 . 끊긴하는데 이게 끊는거라고 볼 수 있는가 
- 내 도메인들을 (아직 못해본거) 트리구조로 분석해보자 도메인분석
- 업무를 진행하는데 있어 처음부터 끝까지 분석을 이렇게 열심히 한적이 있던가 반성하자. 이번엔 꼭 제대로 다 파보자 야야야