Spring Camp (2025) 후기

작년에 이어 올해도 Spring Camp에 다녀왔습니다. 컨퍼런스 당첨운은 없는 편인데 스프링캠프는 운 좋게 2년 연속 선정되었네요. (내년에도 잘 부탁드립니다.)

Java + Spring 개발자로서 스프링캠프는 매번 새로운 기술과 현업에서 공감할 만한 경험을 접할 수 있는 자리라 기대가 컸습니다. 좋은 키워들이 많아 기억이 사라지기전에 늦게나마 일부 세션 내용을 기록해봅니다.

---

Amazon Q Developer와 함께 하는 생성형 AI 시대 헤쳐나가기

AWS의 개발자인 이상현님께서 자사의 생성형 AI인 Amazon Q Developer에 관해 소개해 주셨습니다.

현대 소프트웨어 개발 패러다임이 AI 시대의 개발 패러다임 변화하며 AI 시대가 도래하였습니다. 컨테이너와 쿠버네티스가 한창일 때를 지나, 이제는 생성형 AI와 LLM(대형언어모델)을 활용한 프로그래밍이 대세인 것은 누구나 아는 사실입니다.

 

조사에 따르면 생산형 AI 킬러앱은 코드 생성이라고 합니다.

Amazon Q Developer는 개발 생명주기 전반에 걸쳐 개발속도를 향상 시켜주는 도움을 주는 툴이라고 합니다. 에이전트가 자율적으로 기능구현을 도와주며 현재 4가지의 에이전트로 구분할 수 있습니다.

• 코드개발을 위한 에이전트 (/dev)
• 유닛 테스트 코드 생성 에이전트 (/test)
• 보안 취약점 및 코드리뷰 에이전트 (/reivew)
• 문서 작성 에이전트 (/docs)

Q Developer는 CLI 툴을 지원하는데, idle에서 AI를 사용하는 것보다 속도가 확실히 빠르며 idle에 종속되지 않아 코드를 더 잘 짤 수 있다고 합니다. 팀에서도 현재 밀고 있는 기능이며 추후에는 CLI 개발이 더 편해져 개발자들이 idel을 사용하지 않는 그림까지 그리고 계셨습니다.

(최근 커서와 코파일럿에서도 CLI 툴을 공개한 것으로 알고 있습니다. AI 발전 속도가 눈에 띄게 빨라지는 것 같아요.)

 

그 외 주요 현대화 시나리오로 AI를 통한 Java 버전 업그레이드를 이야기 하셨고, MCP를 함께 사용하면 확장성이 매우 좋으니 보안상 문제가 없다면 적극 사용해 보기를 권장하셨습니다.

 

Q Developer는 프리티어 기능을 확장하고 있다고 하시니 한번 써 보면 좋을 것 같습니다.

노련하게 발표하시는 모습이 인상적인 세션이였습니다.

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

해당 세션은 두 분의 발표자가 물류 시스템을 어떻게 개선 했는지 파트를 나눠 순차적으로 진행해 주셨습니다.

다양한 판매 방식(배송, 바로드림, 오프라인 판매)을 제공하는 올리브영에서 물류시스템은 단순한 배송을 넘어 고객의 경험을 좌우하는 핵심 요소라고 합니다.

 

1. Batch 중심에서 이벤트 기반 구조로의 전환

 

올리브영 물류시스템은 크게 협력사 발주를 통한 입고와 주문 관리 시스템을 통한 재고로 구성되며 기존에는 다음과 같이 Batch와 EAI에 의해 여러 단계의 스케줄로 이어지는 구조였습니다.

발주/주문 테이블 -> 인터페이스 테이블 -> EAI -> 물류센터 인터페이스 테이블 -> 입고예정 테이블

 

다단계 스케줄 구조로 이뤄지다보니 최대 1시간 데이터 지연이 발생했다고 합니다. 그로인해 실물 재고와 시차가 발생하면 협력사가 입고를 포기하여 회송하는 케이스까지 발생했다고 합니다. 또한 Batch 특성상 축적된 데이터를 한번에 처리해 시스템 부화가 발생하기도 하고 장애 발생시 복잡한 단계적 복구가 요구되어 비효율적이었습니다.

 

이를 해결하기 위해 올리브영은 Batch 시스템을 걷어내고 Apache Kafka 기반 이벤트 처리 구조로 점진적 전환을 진행했습니다.

• 이벤트 처리로 물류센터까지 준실시간 데이터 연동 가능
• Consumer에 오류 핸들러를 추가하여 장애를 즉시 감지
• 실시간 처리로 인한 순서 보장 문제를 해결하기 위해 파티셔닝을 사용. 주문번호/상품ID 기반 동일 파티션으로 라우팅
• 비즈니스 로직에서 중복 방지 처리 추가. 메세지 ID 기반 멱등성 보장

 

2. 실시간 모니터링 체계 구축

 

Batch 구조의 또다른 문제점은 데이터가 지연 혹은 누락된 상태에서 Batch가 실행되더라도 실패(FAIL)로 인식되지 않아 문제를 즉각적으로 인지할 수 없다는 것입니다.

이벤트 기반 전환으로 문제의 상당 부분 해소되었지만, 그럼에도 출고 처리가 정상적으로 이뤄ㅓㅓ지고 있는지 가시적으로 확인할 수 있는 체계가 필요했습니다.

• 이상 징후를 조기 감지할 수 있도록 실시간 모니터링 도입
• 처리율이 기준치(99%)이하로 떨어질 경우 온콜 시스템으로 알람 자동 발송
  • 오류는 S3 버킷에 저장 → Lambda를 통해 알람 전달
• Datadog 기반 대시보드를 구축하여 서버 접속 없이도 빠르게 상태 파악
  • 처리 데이터 개수, 서버 메모리 사용량 등 시각화

 

 

3. Redis 기반 오프라인 재고 구조 개선

 

올리브영은 재고를 온라인 재고(물류센터)와 오프라인 재고(매장)로 구분하여 관리하는데 오프라인 재고의 경우 온라인 재고보다 500배 많은 데이터를 다룬다고 합니다.

‘오늘드림’ 서비스의 경우 온라인으로 주문을 하지만 오프라인 매장에서 출고되기 때문에 오프라인 재고를 사용합니다. 그러다보니 대규모 이벤트가 있을때 마다 Read/Write 작업이 많은 오프라인 재고 API 부화가 직접적인 병목의 원인이 되었습니다.

 

이러한 문제를 해결하기 위해 Redis 기반 Read 구조를 도입하였다고 합니다. 오프라인 재고 변경이 발생하면 Oracle에 Write한 뒤 Redis로 메세지를 발행해 캐시를 갱신하는 구조입니다.

 

Redis를 도입하면서 고려하였던 3가지 핵심 문제는 다음과 같습니다.

• 동시성 제어 문제
  • Redis는 row-lock이 없기때문에 복합 연산 시 정합성이 깨질 수 있음
  • Redisson 기반 분산락을 커스텀 어노테이션 형태로 구현
• 조회 성능 문제
  • 메모리기반 db인 Redis는 단건 조회에서 Oracle보다 확실히 성능이 좋다.
  • 하지만 ‘특정 매장의 전체 매장 재고 조회’와 같이 다건 조회 요청에서는 인덱스를 활용하는 Oracle보다 성능 저하 발생ㅇ
  • 조회 목적에 맞춘 3가지 형태의 데이터셋 구성
  • 개선 후 조회 API 약 10배 성능 향상
• 안전성 문제
  • 메모리 기반 + 클라우드 환경 특성상 장애 가능성이 높음
  • 장애 시 Oracle로 즉시 fallback하는 Circuit Breaker 패턴 적용
  • try-catch 기반 복구보다 훨씬 빠르고 안정적으로 전환 가능

 

향후 남아있는 과제인 Redis–Oracle 간 Batch 기반 싱크는 이벤트 기반 또는 CDC(Change Data Capture) 방식으로 개선할 예정이라고 합니다.

 

올리브영 물류 시스템은 현재까지도 점진적인 개선을 진행하고 있으며 단순한 구조 개선이 아닌, 현장의 경험과 고객 만족도를 높이기 위한 지속적인 개선의 여정이라고 설명해주셨습니다.

이번 캠프에 올리브영이 골드 후원자기이기도 하고 가장 인기가 많았던 세션이 아니였을까 하네요. 저희 팀에서도 Batch 기반 구조를 사용하기때문에 좋은 인사이트를 얻을 수 있었던 시간이였습니다. (인프라 지원이 잘 된다는 것은 정말 부럽네요ㅎㅎ)

 

올리브영 테크 블로그에 관련 글이 있는 것 같아 링크 남기겠습니다.

https://oliveyoung.tech/2024-10-17/oy-delivery-mq

올리브영 물류시스템에서는 데이터를 어떻게 주고 받을까? | 올리브영 테크블로그

 

 

카카오뱅크 펀드시스템에 날개를 달아준, 사내 Spring Boot Starter 라이브러리 이야기

해당 세션은 카카오뱅크의 단일 은행 시스템에서 펀드시스템을 분리 구축해내며, 그 과정에서 만들어진 사내 Spring Boot Starter 라이브러리에 대해 공유해 주셨습니다.

 

카카오뱅크에서도 기존에 모놀리식 아키텍처를 사용했었었는데 장애 확산, 빌드 속도 저하, 코드 파악의 어려움 문제점들을 직면하며 점진적으로 MSA로 전환 중이라 하였습니다.

하지만 금융권 특성상 규제가 많아, 단순히 클라우드 환경 위에 오픈소스 Spring으로 서버를 올리는 것이 쉽지 않았습니다. 상용 프레임워크를 사용하자니 커스텀이 힘들고 깊은 종속성으로 유지보수가 힘들다는 문제가 있었기 때문에 여러 문제들을 고려해, 은행 구조를 “코어 뱅킹/ 채널계(고객 접점)/ 운영 업무 툴”로 분리하게 되었다고 합니다.

 

그러한 과정에서 프로젝트를 신규 구축하며 반복되는 Spring 프로젝트 세팅 작업과 그 외 공통 관심사들을 분리하게 되었고 그것이 사내 라이브러리인 Spring Boot Starter 입니다. Spring Boot Starter의 주요 구현 기능으로는 다음과 같은 것 들이 있습니다.

• 직렬화/역직렬화(FixedLength Module)
  • 기존 JSON 라이브러리를 커스터마이징하고, 직접 만든 시리얼라이즈/디시리얼라이즈 기능을 추상화
  • 금융 데이터 특화 형식(FixedLength) 처리를 지원
• 사내 HTTP Client
  • 사내 시스템 간 안전한 통신을 위해 공통 규격화
  • RestClient, WebClient, RestTemplate 등 클라이언트 종류 통일
  • 요청 전/후 공통 로직 추가 포인트 제공 → 프로젝트별 자유로운 확장 가능
  • 책임 연쇄 패턴(Chain of Responsibility) 활용으로 유연성 확보
• 분산 트레이싱(Opentelemetry 기반)
  • 단위 시스템 간 요청 추적 및 에러 원인 파악 어려움 해결
  • Trace Id, Span Id 기반으로 요청 계측
  • Context 전파(Baggage) 개념을 활용, 어디서든 쉽게 접근 가능
  • 기존 라이브러리를 활용하면서도, 사내 편의 기능을 추상화하여 사용성 강화

라이브러리를 통해 개발자들은 도메인에 집중하여 개발 생산성을 높일 수 있었다고 합니다.

 

서비스가 커져가면서 꼭 한번은 고민하게 되는 부분인것 같다. 금융권 도메인의 제한된 환경에서의 고군분투가 공감이 되었고 내용 중에 직렬화, 역직렬화를 담당하는 유틸은 다양한 포맷의 전문을 다루는 저희 팀에서도 유용하게 사용할 수 있을 것 같다는 생각이 들었습니다.

 

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

SI 업체에서 근무하시는 근수님께서 빅뱅방식의 개발환경에서 최선의 개발을 하기 위해 실행하였던 노력들에 대해 발표해주셨습니다.

 

빅뱅방식은 오래된 개발론으로 단위별로 기능을 쪼개어 개발하는 방식과 달리 처음부터 끝까지 한번에 개발하는 방식을 말합니다. SI 특성상 짧은 기간에 많은 양의 개발을 해야하며, 클라아언트도 요구사항을 잘 모르거나 설명하지 못하는 경우가 많다고 합니다.

이러한 환경에서 효율적으로 개발하기 위해서 트리구조로 요구사항 분석, API 명세 작성하기, 멀티모듈 도입 등의 방법을 말씀해주셨습니다.

 

 

트리 구조 도메인 분석에 관한 예시입니다.

• 프로젝트를 트리 형태로 정리. 왼쪽에서 시작하여 오른쪽으로 뻗어나가는 트리 형태입니다.
• 최상위 개념을 설정하고 개념에 대한 명확한 정의를 합니다
• 이때 무엇이 상위 개념인지 파악하는 것이 중요합니다.
• 잘못된 위상은 잘못된 설계를 의미하며 모든 기획에 논리적인 오류 발생하지 않을 때까지 지속적인 수정과 검증을 진행

정리가 굉장히 깔끔하죠? 근수님께서 사용하시는 앱은 유료로 구독중인 Edrawmind라고 합니다.

 

트리구조 정리 방식이 인상적으로 다가왔습니다. 현재 저희 팀의 주요 업무는 기존의 레거시한 서비스들을 하나의 통합시스템으로 내재화하는 것 입니다. 방대한하고 복잡한 시스템에서 도메인을 파악하는데 어려움을 겪고 있었는데 저희 팀에도 트리식 정리 방식이 도메인을 이해하는데 효율적이겠다는 생각이 들었습니다.

 

주어진 환경에서 개발문화를 구축해나아가기 위해 노력하신 모습이 인상적인 세션이였습니다.

 

왜 나는 테스트를 작성하기 싫을까?(2024)

해당 세션은 작년 Spring Camp(2024)에서 가장 인상 깊게 들었던 발표라 이번 포스팅에 함께 기록합니다. 저 역시 테스트 코드와 TDD를 좋아하는 개발자로서, 테스트에 대한 초심을 다시 떠올릴 수 있는 시간이었습니다.

 

네이버페이의 조성아님은 본인의 경험을 바탕으로, 개발자들이 테스트 코드를 작성하기 싫어지는 이유와 이를 극복하기 위한 방법을 이야기해주셨습니다. 네이버페이는 확장성과 유지보수성이 중요한 서비스로 초기부터 테스트 문화가 잘 자리 잡은 팀이었다고 합니다. 자연스럽게 테스트 코드 작성에 몰입하게 되었고, 테스트 객체를 자동으로 생성해주는 JVM 기반 라이브러리인 픽처스 몽키(Pictures Monkey)를 개발하게 되었다고 합니다.

 

픽처스 몽키를 활용하면서 다양한 엣지 케이스를 발견할 수 있었고, DomainFixture를 통해 MSA 환경의 API를 모킹, 제어하면서 기능 확장에 대한 기대도 커졌다고 합니다. 그러나 시간이 흐르며 피할 수 없는 유지보수의 벽을 마주하게 됩니다.

테스트가 자주 깨지며 신뢰성을 잃게 되었고 비결정 테스트(Non-deterministic Test) 문제로 팀 내 공유와 유지보수가 어려워졌으며 테스트 레벨을 올려주던 DomainFixture는 스펙이 늘어날 때마다 관리 포인트가 증가하는 문제가 있었습니다.

이러한 과정 속에서 테스트 작성에 대한 열정이 사그라들었고 테스트의 이득과 비용에 대해 진지하게 고민하게 되는 계기가 되었다고 합니다.

 

조성아님께서 발표해주신 테스트를 작성하기 싫어지는 이유와 극복 방법은 다음과 같습니다.

• 테스트 작성이 싫어지는 이유
  • 라이브러리 사용으로 작성 비용이 낮아졌지만 그로인해 넓어진 테스트 범위
  • 도메인 특성상 모든 코드를 테스트 해야한다는 강박
  • DomainFixture 유지보수 비용

사람들이 테스트 작성을 힘들어하는 근본적인 이유는 테스트가 제공하는 이득보다 비용이 많이 들기때문입니다.

작성 비용 + 유지보수 비용 > 테스트가 제공하는 이득

 

• 테스트 프라미드 기준 비용 구분
  • E2E : 리얼 환경에서 이상이 없는가 → 비용이 가장 큼
  • Integration : 기능이 의도대로 협력하는가. 다양한 시나리오 테스트
  • Unit : 기능이 의도 되로 동작하는가.

테스트 단위가 작아잘 수록 비용이 줄기때문에 단위 테스트로 최대한 많은 경우의 수를 테스트 해볼 수 있습니다. 조성아님은 특히 비용이 많이드는 인수 테스트는 분리하여 따로 관리하고 로컬 보다는 CI에서만 실행하도록 하여 생산성을 향상 시켰다고 합니다.

 

• 불필요한 비용 제거하기
  • Given 단계가 복잡한 테스트 → 작성 비용 증가
  • Then 단계에서 너무 많은 검증 수행 → 유지보수 비용 증가
  • 대표적인 사례:
    • 필요하지 않은 리스트 요소를 테스트를 위해 여러 개 넣기
    • 하나의 테스트에서 입출금 검증 + 계좌 검증까지 모두 처리하기

 

테스트코드를 작성하다보면 assert문을 자꾸 추가하고 싶은 욕구가 생기는데 그것은 유지보수의 늪에 빠지는 지름길 입니다. 핵심 원칙은 Less Is More! 필요한 테스트만 최소한으로 작성하는것입니다. 컴팩트한 테스트를 작성은 작성과 유지보수 비용을 줄이며 가독성을 크게 향상시킵니다.

 

테스트 권태기는 누구에게나 올 수 있습니다. 해당 세션은 올바른 접근법과 도구를 통해서 그러한 문제를 충분히 극복할 수 있다는 메세지를 전해주었습니다.

 

참고로 픽처스 몽키는 오픈소스 라이브러리입니다. 저도 세션 이후 실제 사이드 프로젝트를 진행하면서 픽처스 몽키(MonkeyFixture)를 유용하게 사용했습니다. 내부적으로 Reflection을 사용하여서 인지 대량의 테스트 데이터를 생성하는데는 속도 측면에서 한계가 있지만 커스텀이 쉽고 랜덤한 데이터를 손쉽게 만들 수 있다는 점에서 앞으로도 종종 사용하게 될 것 같습니다. 좋은 오픈소스를 제공해주셔서 감사할따름입니다.

픽처스 몽키(MonkeyFixture) 오픈소스 : https://github.com/naver/fixture-monkey

GitHub - naver/fixture-monkey: Let Fixture Monkey generates fully-customizable, randomly populated instance. Focus on the proper

 

---

스프링캠프는 기술 스택이 정해져있으며 주니어 개발자 분들도 발표를 많이 하기때문에 저같은 주니어 개발자도 강연이 보는데 어려움이 없었습니다.

아무래도 현업에서 겪고 있는 문제들을 다루는 세션들에 유독 주목이 갔었는데, 동일한 문제를 겪고 있는 입장에서 격하게 공감이 가기도 했고 다른 회사에서는 어떤식으로 그러한 문제를 개선하였는지 보면서 적용할 수 있는 점을 계속해서 생각하게 되었습니다.

올해도 역시나 재미있게 들은 컨퍼런스였고 내년에도 꼭 참가할 수 있었으면 좋겠네요!