📖 지식을 쌓아보자
블로그 이미지
스프링캠프 2026 참석 후기: 변화하는 스프링과 AI, 그리고 6개 세션에 대한 정리

 

짠~!

오늘은 스프링캠프 2026에 왔다.

작년에는 되게 알차고 재밌었다는 (지인의)후기가 있길래 나름 기대하며 강남역에 도착

 

세션과 연사분들은 이렇게 입구부터 정보를 볼 수 있었다.

 

그리고 들어가면서 굿즈도 챙겨가기!

 

이미 앞자리는 어느정도 차있어서 애매한 자리에 착석....

여기 대여한 장소가 아주 큰 단점...........

잘 안보이고 책상도 없고^^... 발표 장표를 차라리 미리 나눠줬다면 보면서라도 할텐데 앞 사람한테 가려서 잘 보이지도 않고..후..

 

 

부스는 크게 총 두개였는데(일단 내가 메인홀에서만 들었기 때문에..)

카카오뱅크와 AWS였다.

 

카카오뱅크에서는 QR코드를 이용해서 사이트에 접속하고,

응답을 적으면 투자 성향에 맞는 포토카드 같은걸 나눠준다.

 

사이트 되게 잘 만들었다!

나는 일단 우상향 카드~

 

AWS의  경우에는 커뮤니티에 가입을 하면 자켓 뽑기 기회가 주어지는데

 

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ오와!!!!!!!

에어컨을 너무 빵빵하게 틀어주셔서 추웠는데 완전 럭키

 

세션 정리를 들어가며

컨퍼런스를 가기 전엔 늘 비슷한 마음이다. "또 신기능 자랑 + AI 얘기 한 바가지겠지~" 하는 약간의 시큰둥함ㅎ..

그리고... 솔직히 말하면 이번 스프링캠프 2026은 그 예상이 절반쯤은 맞았다.

물론 배운 게 많았지만, 세션을 듣다 보니 크게 두 부류로 갈렸다.

  • 상용 도구에 대한 홍보색이 있던 쪽: AWS Kiro IDE(2번), Claude Code 하네스(3번), 왓탭 APM(6번). 내용은 유용한데 "결국 이거(우리 제품) 쓰라는 건가..?" 싶은 순간이 종종 있었다
  • 개념·정보·의견 위주로 깔끔했던 쪽 — Spring I/O 리캡(1번), Temporal(4번), Is Java Alive(5번). 특정 상용 제품을 파는 느낌이 거의 없어서 듣기 편했다.

1번은 "스프링 부트 4로 올려라" 같은 업그레이드 권유는 있었지만,
그건 상업 홍보라기보단 오픈소스 생태계 소식+프레임워크 가이드에 가까웠다!

 

그중에서도 더 빛났던 건 Temporal 세션이었다.

특정 벤더 색 거의 없이, 의사코드처럼 깔끔한 Java 코드로 "왜 복잡한가 → 어떻게 단순해지는가"만 우직하게 보여줬다고 생각한다.

개인적으로 이번 캠프 최고의 세션은 단연 4번(Temporal) 이었다. (뒤에서 자세히 풀 예정👇)

 

아무튼, 세션 순서 자체는 신기능 → AI로 개발하기 → 워크플로우 → 언어론 → 운영/관측으로 하나의 이야기처럼 이어져서 흐름은 좋았다.
한 줄 요약하자면 이거다.

스프링은 계속 진화하고 그 중심엔 AI가 있다.
그래서 우리는 그걸 어떻게 만들고, 또 어떻게 운영할 것인가?

 

참고로 메모한 내용이 완벽하진 않을 수 있어서, 일부는 공유받은 발표 장표 슬라이드를 같이 보면서 메모를 채웠다.
아무튼 들었던 순서대로 정리 시작~!

 

 

세션 1. Spring I/O 2026 — 변화하는 스프링, 떠오르는 AI, 그리고 우리의 준비

 

해외 컨퍼런스(Spring I/O) 다녀온 내용을 공유하는 리캡 세션.
카카오뱅크 관점으로 풀어줘서 "아 우리 회사도 비슷하려나...?" 하면서 들었다.
앞서 말했듯 이건 오픈소스 스프링 생태계 소식 공유라, 상용 제품 파는 느낌 없이 깔끔하게 정보만 챙길 수 있어서 좋았다ㅠ.

 

가장 크게 와닿은 건 스프링이 그동안 여기저기 흩어져 있던 회복 탄력성(Resilience) 기능을

Spring Framework 모듈로 통합했다는 것이었다.

@Retryable, @ConcurrencyLimit 같은 어노테이션으로 지수 백오프 재시도나 동시 접근 제한을 선언적으로 걸 수 있게 됐다!

 

근데 이게 왜 지금 부각됐냐?

바로 버추얼 스레드(Virtual Thread) 때문이다.

예전엔 스레드 풀 크기로 외부 자원 접근을 알아서 제한했는데, 버추얼 스레드는 거의 무제한으로 생성이 가능하다.

 

문제는... DB나 외부 API는 무한이 아니라는 것!

그래서 외부 자원에 대한 동시 접근 상한을 선언적으로 거는 기능이 다시 중요해졌다는 설명이 진짜 깔끔했다.

 

시큐리티 파트도 꽤 비중 있게 다뤄졌는데, 재밌는 한마디를 하셨다.

 

"90일마다 비밀번호 바꾸는 건 아무 의미 없어요. 정책이 바뀌어도 우리 습관은 안 바뀌니까."

 

(그 예시로, spring1234! 에서 비밀번호 변경하라고 하면 다들 spring1234@처럼 바꾼다는 예시를 들어주었다ㅋㅋㅋㅋㅋ 난가...)

 

그러면서 패스키 · OTT(매직 링크) · MFA 같은 다양한 인증 수단과,

그리고 MCP 서버를 OAuth 2.1로 보호하는 흐름을 라이브러리로 간소화한 얘기가 나왔다.
카카오뱅크는 사내 공통 IDP(Keycloak 기반)로 여러 팀이 MCP 서버 만들 때 인증 로직을 중복 구현하지 않게 통합 중이라고 한다.

AI 쪽에서 메모해둔 건 두 가지였다.

  1. Dynamic Tool Discovery
    • 안 쓰는 툴 50개를 LLM에 계속 떠먹여주면 질문하기도 전에 토큰을 날린다.
    • 검색 기반 search tool 하나만 등록하면 질문에 따라 필요한 도구만 골라준다.
    • 발표에서 언급된 컨텍스트 절약률이 무려 63%라고 한다!
  2. Spec-Driven Development(SDD)
    • "AI는 컴파일러가 아니라 비결정적이고, 결과물 책임은 우리에게 있다."
    • 사람이 읽을 수 있는 스펙 문서를 단일 진실로 삼아 일관되게 협업하자는 방법론.

 

그리고 진짜 강조하신 결론ㅎ;

JDK 17은 이미 "올드 베이스라인"이다. 스프링 팀은 JDK 25를 권장하고, 스프링 부트 4를 써야 Spring AI 2.0을 쓸 수 있으니 버전 업은 선택이 아니라 필수라는 것.

패치업을 미루면 1~2년 쌓여서 JDK 8 + 스프링 1.x 레거시가 되고, 결국 "차세대 시스템 작업"이라는 거대한 빅점프 비용으로 돌아온다는 얘기에 공감하긴 했지만................................ 사실 운영중인 서비스 업그레이드는 진짜 쉽지 않다.

"호미로 막을 거 가래로 막지 말자" 라는 표현은 그래도 담아두자!
(근데 카뱅도 JDK 8인 서비스가 있다고...........?)

 

세션 2. 자율 에이전트를 활용한 AI 네이티브 자바 개발

개인 생산성을 넘어서 조직 차원에서 AI를 어떻게 도입할까가 핵심이었던 세션.

 

먼저 솔직한 감상부터!

내용의 큰 줄기(트렌드 정리·조직 도입 통찰)는 좋았는데,

중반부터는 AWS Kiro IDE 기능 투어 + AWS AI-DLC 소개에 시간이 꽤 쏠렸다.

 

유용하긴 한데 "이건 좀 AWS 제품 설명회 같은데?" 싶은 구간이 있었다는 건 적어둔다.

(참고로.. 우리 회사는 Kiro를 사용하므로 악감정은 없다!)

 

그래도 챙길 건 챙겼다.

트렌드 흐름(2024 챗GPT → 어시스턴트 → 2025 에이전트 → 2026 자율성)도 깔끔했고,

특히 아래의 수치가 인상 깊었다.

 

"AI로 코딩해도 실질 생산성은 10~15% 밖에 안오릅니다."

 

왜일까?

  1. 실제 코딩으로 도구 쓰는 영역이 전체의 20% 뿐이고(나머지는 설계·분석·테스트·소통)
  2. 개인-조직 간 활용 편차로 병목이 생기기 때문

그래서 업무 프로세스 자체를 AI 환경에 맞춰 바꿔야 비로소 "아하 모먼트"가 온다는 것이다.

 

그리고 "AI를 얼마나 맡길까"를 두 극단으로 보여줬는데 새삼스럽게 다시 인지를 하고 간다ㅠ.

(이직한지 얼마 안된 내게 염증같은 내용..)

 

AI에 전부 맡기기(프로덕션 불가) vs 보조로만 쓰기(생산성 미미 + 기술 부채).

 

사실 둘 다 별로다. 그러니까 (목표·검증은 사람, 실행은 AI)를 잡자는 거다. 

그 방법론이 요즘 키워드인 하네스 엔지니어링과 AWS의 AI-DLC이다.

⚠️ 혹시 모를 분들을 위해..!

여기서 '하네스(harness)'가 뭐냐면, AI한테 씌우는 가드레일이다. (말을 제어하는 마구처럼)
구체적으로는 "이렇게 작업해라" 라는 지침을 적어둔 파일인데(Claude는 CLAUDE.md, Codex는 AGENTS.md),
AI가 작업 전에 이걸 읽고 → 진행 → 결과를 정해둔 기준으로 검증 → 미달이면 다시 → 실패하면 그 기록을 사람이 분석해서 지침을 보강한다.이 지침을 계속 다듬는 일 이 곧 하네스 엔지니어링이다.

 

AI-DLC도 결은 같다.

AI가 잘하는 것(생성·제안)과 사람이 해야 하는 것(의사결정·책임)을 나눠서,

애매한 지점에선 AI가 사람에게 묻고 → 사람이 답하고 → 사람이 최종 리뷰하는 흐름.

한 줄로는 "각자 잘하는 것에 집중하고 워크플로우로 연결한다."

 

(그리고 이 하네스를 실제로 어떻게 굴리는지 는 바로 다음 3번 세션에서 데모로 보여준다!)

세션 3. Spring AI 개발, Harness로 10배 빠르게

앞 세션의 하네스 개념을 Spring AI 개발에 실제로 적용한 라이브 데모 세션.

 

발표가 Claude Code를 예시로 썼을 뿐, "특정 도구를 잘 쓰면 이렇게 된다"가 아니라 "어떤 AI를 쓰든 이렇게 구조를 짜면 된다"는 얘기에 가까웠다. (그래서 오히려 좋았음)

 

핵심은 역할 나누기 · 스킬화 · 오케스트레이션 이라는 에이전트 설계 방법론이다.

그래서 이건 Claude Code든 Codex(AGENTS.md)든 Gemini CLI든 어떤 에이전트에도 그대로 옮겨 쓸 수 있다!

 

Spring AI는 "코드 한 줄 안 바꾸고 application.yml만 고치면 모델 교체" 같은 약속을 하지만..

현실은?

  • 모델 버전 바뀌는 순간 Tool Calling이 소리 소문 없이 실패
  • 간단한 RAG 하나 붙이는데도 클래스·설정이 우수수 쏟아질 때가 있고
  • 응답이 매번 달라지니 테스트를 어떻게 짜야 할지 막막하고...

그리고 모든 문제의 기저엔 결국 "혼자 다 떠안는 1인 개발자 구조" 때문이라고 했다.

나도 혼자 삽질하다가 하루 다 날린 적이 한 두번이 아니다. 으악!!!

 

그래서 내놓은 해법은 "혼자 고군분투하지 말고 나만의 AI 개발 팀을 꾸리자." 였다.

스프링 쓰던 사람 입장에서 바로 이해가 되도록 비유를 하셨다. 

 

한 마디로 역할(Agent)을 나누고 반복은 재사용(Skill) 전체를 조율(Orchestrator)한다는 것.

  • @Component → Agent
  • @Configuration + @Bean → Skill
  • @SpringBootApplication → Orchestrator.

데모로 보여준 사례가 꽤 설득력 잇었다. (수치는 발표 기준이라 참고만!)

  • RAG 파이프라인 수동 구축 → 팀이 병렬로 처리해서 75% 단축
  • 멀티모델 전환 및 호환성 차이를 에이전트가 알아서 검증 → 70% 단축
  • 복잡한 워크플로우 충돌 예방
  • AI 테스트 자동화(Mock Shield) → 70% 단축

 

발표 중에  아래와 같은 말이 나왔다.

앱 구조랑 개발 팀 구조가 닮아간다는 얘긴데, 듣고 보니 그럴듯했다.

 

"Agentic 앱은 Agentic한 방식으로 개발해야 한다."

 

Q&A에서 질문 퀄리티는 좀...ㅎ...아쉬웠지만..

그래도 응답에서 건진 디테일도 좋았다. (도구에 종속된 얘기가 아니라 에이전트 일반화 가능한 것들)

  • 에이전트가 4개 → 10개로 늘면 컨텍스트 분리 덕에 오히려 성능이 좋아진는 점(소위 컨텍스트 락/오염 회피)
  • 오케스트레이터(메인)에게 직접 일 시키지 말 것 — 마이크로매니징 꼴 나니까..
  • 그리고 하네스를 쓴 쪽이 안 쓴 쪽보다 결과 품질이 한참 좋았다는 벤치마킹(다만 에이전트끼리 통신 켜면 토큰값이 꽤 더 나간다고)

도구 이름을 싹 지우고 봐도 결국 하고 싶은 말은 하나였다.

실행은 에이전트한테 맡기고, 사람은 목표 잡고 맥락 판단하고 품질이랑 책임을 챙기는 쪽으로 옮겨가자는 것.



세션 4. ⭐워크플로우 코드 왜 항상 복잡할까? — Temporal이 보여준 다른 방법

 

 

개인적으로 이번 캠프 최고의 세션

 

왜 좋았냐고? 일단 홍보가 없었다.
"이런거(우리 제품) 써보세요"가 아니라, 의사코드처럼 군더더기 다 걷어낸 깔끔한 의사코드(Java 형태)로 "왜 복잡한가 → 어떻게 단순해지는가"만 우직하게 보여줬다.

 

제목 그대로, 워크플로우 코드가 왜 늘 복잡해지는지를 "고객 보상" 시나리오로 직접 만들어 보이며 풀어냈다.

플로우 자체는 단순하다. ① 분석 → ② 매니저 검토(7일 SLA) → ③ Credit 지급

근데 막상 짜기 시작하면 비즈니스 외에 군더더기가 계속 붙는다.

  • 분석: 서비스별 다른 재시도, timeout, 비싼 작업 결과 영속화
  • 승인: 함수에서 7일 대기 못 하니 타이머/만료, 매니저 승인 신호(Signal) 처리
  • 지급: All-or-Nothing, 실패 시 보상(compensation) 으로 원복

결국 비즈니스 외에 7가지 기능이 필요해지고, 코드엔 Saga, DistributionLock, SignalAcceptor... 가 잔뜩 생긴다.

정작 하고 싶던 건 "수집 → 평가 → 승인 → 지급" 한 줄인데...😭

 

여기서 Temporal은 한 마디를 날린다!

"Write code as if failure doesn't exist."

(실패가 없는 것처럼 코드를 짜라)

"You code your business logic. We handle the rest."

 

그러면 7일 대기가 이 한 줄이 된다 👇

void process(MyCommand command) {
    var data   = collectData();                       // 데이터 수집
    var credit = evaluateCredit(data);                // 금액 평가
    Workflow.await(Duration.ofDays(7), () -> approve); // 7일 대기 (이게 끝)
    executeTransaction();                             // 장부 기록 & 지급
}


이게 핵심이다.

코드가 비즈니스 프로세스랑 거의 1:1로 읽힌다.

 

비결은 Event History · Replay · Proxy(Event Sourcing)이다.

함수가 7일을 멈춰 있을 순 없으니(JVM 스택 영속화 불가), 진행 상황을 전부 Event History에 기록해둔다.

함수가 종료돼도 Replay로 처음부터 다시 돌리되, 이미 결과가 있는 단계는 Proxy가 즉시 반환하고(있음→반환) 없는 단계만 실제 실행한다(없음→요청).

그래서 "멈췄다 그 자리에서 이어지는 것처럼" 동작되는 것이다!

다른 엔진이 DB에 current_step을 두고 상태를 관리한다면, Temporal은 실행 그 자체가 상태가 된다는 게 포인트이다.

 

결국 우리 코드엔 비즈니스 시맨틱만 남는다.

본질적 복잡도(산정·승인·지급)는 남고, 우발적 복잡도(재시도·체크포인트·재개 분기)는 코드에서 사라진다.

 

물론 공짜는 아니라는 것도 솔직하게 짚어줬다.

(Temporal Server 운영/클라우드 비용, 결정성·Replay 멘탈 모델 학습, 워크플로우 버저닝 등)

 

복잡한 코드가 사라진 게 아니라 런타임으로 이동한 거고,

"마법이 아니라 우리가 이미 아는 것들(Proxy·Event Sourcing)의 조합" 이라는 마무리였다.


세션 5. Is Java Alive and Kicking?

Netty와 Armeria 만드신 이희승 님 세션.

자바를 진짜 솔직하고 냉정하게 까서(?) 재밌었다ㅋㅋㅋㅋㅋㅋㅋ

결론부터 = "네, 자바 아직 팔팔합니다!"

6개월 릴리즈 주기로 Amber·Loom·Panama·Leyden·Valhalla 등 현대화가 활발하다.

근데 "그러나" 로 시작하는 세 가지 이슈가 본론이었다. 

기술지형, 거버넌스, 마인드셰어

 

1. 기술지형의 변화부터

요지는 "자바가 최적화되도록 만들어진 환경 자체가 바뀌어서, 예전의 강점이 지금은 짐이 됐다" 는 거다.

옛날 Single-tenancy 시절엔 좋은 서버 한 대에 서비스 몇 개를 오래 띄워 썼다. JVM이 오래 돌수록 똑똑하게 최적화해주고, 기동이 좀 느려도, 메모리를 좀 많이 먹어도 괜찮았다. "그땐 그게 맞았다."

근데 지금은 Multitenancy — 컨테이너에 여러 서비스가 자원을 나눠 쓰고, 트래픽 따라 수시로 떴다 죽었다 한다. 이러면 강점이 그대로 약점으로 뒤집힌다.

  • 느린 기동 + JIT 워밍업 → 새로 켜질 때마다 손해
  • 높은 메모리 사용량 → 옆 서비스까지 굶기는 민폐

여기에 발표자가 덧붙인 변화 셋. 다 "자바만의 강점이던 게 이제 딴 데서도 된다"는 얘기다.

  • 관측성: 예전엔 JVM 자체 프로파일링(JFR 등)이 독보적이었는데, 요즘은 perf·eBPF 같은 OS 레벨 도구가 언어 안 가리고 들여다봐 준다
  • 빌드 타임으로 이동: JIT 워밍업처럼 런타임에 하던 일을 빌드 시점에 미리 하자는 흐름(AOT·GraalVM·Leyden). "굳이 매번 런타임에 할 일이었나?"
  • 통합 툴링: 요즘 언어는 포매터·테스트·의존성·빌드를 공식으로 한 묶음 주는데, 자바는 여전히 Maven이냐 Gradle이냐부터 따로 배워야 함

대응은 두 갈래지만, 같은 벽에 부딪힌다.

  • 자바를 고친다(현대화)
    • Amber·Loom·Valhalla 같은 프로젝트. 문제는 하위 호환성을 절대 못 깨다 보니 변화가 너무 느리다는 거다.
    • value type을 넣겠다는 Valhalla가 2014년에 시작했는데 2026년에도 미리보기...ㅎ..
근데 올해는 진짜라고 하더라....
....근데이거 스팀 게임 발매일 느낌이 나는데..?
  • 자바를 떠난다(Kotlin·Scala)
    • 언어 문법은 확실히 편해졌다. 근데 결국 같은 JVM 위에서 돈다. 즉 느린 기동·높은 메모리 같은 런타임의 짐은 그대로다.
    • 자바랑 섞을 때 마찰도 있음 (예: Kotlin에서 자바 값을 받을 때 null인지 아닌지 모호한 String! 타입)
    • records·패턴 매칭처럼 "남이 먼저 잘한 것"을 자바가 계속 따라 흡수 → 차별점도 줄어듦
그래서 세션 표현으로는 "탈출구라기보단 우회로, 독이 든 성배" 다.

 

2. 거버넌스
요점은 "오라클을 비롯한 주인들이 자바를 '함께 가꿀 공유재'가 아니라 '통제하고 돈 벌 자산'으로 다뤄왔다" 는 비판이다.

그 결과가 이렇게 나타난다.

  • JDK 배포판이 하나가 아니라 여러 개로 쪼개짐 (Temurin? Adoptium? OpenJDK? Oracle JDK?)
  • 라이선스는 갈수록 헷갈리게 바뀜
  • 심지어 종업원 수에 비례한 구독 과금까지 등장

입문자 입장에선 "자바 깔려면 뭘 받아야 되는데?"부터 막힌다. 새 언어들이 "그냥 이거 받으세요" 하는 것과 대조적.

발표 에선이걸 두고 언어를 공유재가 아니라 수익 자산으로 본 게 쇠퇴의 시작점이라고 짚었다.



3. 마인드셰어는...

새 프로젝트를 자바로 시작하는 신규 개발자가 거의 없다는건데, 이걸 대한민국 합계출산율에 빗댄 슬라이드를 보았다ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

출산율이 바닥이면 새로 태어나는 사람이 없어서 인구가 늙어가듯, 자바도 새로 유입되는 사람이 안 들어와서 생태계가 늙어간다는 비유이다.

실제로 요즘 스타트업·신규 프로젝트에서 자바를 고르는 비율은 한 자릿수대고,

성장 기대 언어 상위권은 TypeScript·Rust·Go라는 설문도 함께 나왔다.

 

그래서 결론은?

상황에 맞는 기술을 선택·조합하자. "모든 백엔드에 자바를 쓸 필요는 없다."

세션 6. 배포 후 1시간, 당신은 무엇을 보고 있나요?

발표 장표에 보인 건 왓탭(WhaTap) APM UI였다. 다만 "무엇을 어떤 순서로 봐야 하는가" 라는 진단 프레임워크 자체는 툴과 무관하게 쓸모 있었지만...... 주니어 레벨에게 좀 더 유용한 세션이지 않았을까 싶다.

 

관통하는 메시지는 좋았다. (이제는 기본이겠지만)

"코드 잘 짜는 건 기본, 그 기본을 넘어 뭐가 문제인지 찾고 개선할 줄 아는 백엔드 개발자가 되자."

 

배포 직후 히트맵 패턴 읽기부터 시작했다.

  • 타임아웃형: 다 같은 시간에 종료 → 외부 API 지연/타임아웃 값 점검
  • 플라잉(파도)형: 응답 시간이 출렁 → 같은 주기로 도는 무언가(스케줄러·GC)가 자원 잡는지 의심
  • 과부하형: 분포가 전 구간으로 번지며 에러 → 트래픽 폭증/쏠림
  • 누적형: 시간 지나도 악화 → 처리보다 유입이 많은 상태, 긴급 조치

그다음 실제 요청 하나로 드릴다운, 핵심은 APM 트레이스 + 서버 메트릭을 같이 봐야 한다는 것이다.

  • 개발할 땐 빠른데 배포하면 느려지는 쿼리(N+1)는 데이터 쌓여야 드러남
  • GC/메모리는 트레이스만으론 안 보인다(GC는 메서드 사이에서 발생). 메모리 릭은 클래스 히스토그램 → 힙덤프로 진단
  • 끝나지 않아 트레이스에 안 잡히는 문제는 진행 중에 인지(Active Transaction)

DB 모니터링은 느린 쿼리 하나가 아니라 같은 시간대의 세션·락·SQL·실행 계획을 함께 본다.

가장 흔한 건 데이터 증가 → 통계 변경 → 플랜이 바뀌어 Full Scan 타는 경우이다.

외부 API·MSA·간헐적 문제에는 트레이스 관계와 로그 컨텍스트(사용자 ID·등급)가 핵심.

 

결국 발표가 하고 싶은 말은 "도구가 아니라 보는 순서가 중요하다" 였다.

  1. 시간을 고정해 배포 전후(혹은 정상-비정상)를 비교
  2. 히트맵으로 분포를 보며 의심 구간 잡기
  3. 의심 가는 요청 하나를 골라 트레이스·메트릭·DB로 드릴다운
  4. 그래도 안 잡히면 로그 맥락으로 "누가 언제 무엇을"까지 좁히기

히트맵 / APM 트레이스 / DB / 인프라 메트릭 / 로그 — 이 다섯 갈래를 상황 봐가며 조합하는 거다.


마지막 한마디는 공감됐다.

"애플리케이션 모니터링을 한 번이라도 제대로 보면, 그거 없이 개발하던 시절로는 다시 못 돌아간다."

사실 APM이야 나는 원래 쓰고 있어서 "와 신세계다" 같은 느낌은 아니었다.

요즘은 Grafana 쪽으로 많이들 보기도 하고..

그래서 툴 자체보다는, 위에 정리한 히트맵 패턴 읽기 → 드릴다운 → 로그 맥락 이라는 보는 순서 가 더 챙길 만했다. (이건 어떤 모니터링 툴을 쓰든 똑같이 적용되니까)

 



마무리

 

배운 건 분명히 있었다. 근데 솔직한 총평을 적자면 이렇다.

올해 캠프는 " 적당한 내용 + 적잖은 제품/도구 홍보" 의 조합

 

그래도 모든 세션에서 관통하는 흐름은..

- 스프링은 계속 진화 중 → 버전 업은 미루면 빅점프 비용

- AI로 개발하는 방법은 여전함 → "전부 맡기기"도 "보조로만"도 아닌, 가드레일 씌우고 역할 나누기

- 복잡도는 사라지지 않고 이동한다

- 언어 선택은 더 이상 당연하지 않다

- 결국 만든 건 운영·관측할 수 있어야 한다


당장 적용해볼 것도 챙겼다.
우선 버추얼 스레드 + 동시성 상한부터, 그리고 시간 나면 Temporal 한번 제대로 파볼 생각이다.

 

그리고.. 케이터링은 좀 아쉬웠..

 

마지막 퀴즈는 재밌었다.

보상은 되게 기능 좋은 티셔츠랑 스프링 관련? 개발 서적!

- 코틀린&스프링 부트로 개발은 처음인데요

- 스프링 부트 개발자 온보딩 가이드

- 스프링 6 레시피

ㅋㅋㅋㅋ 진짜 잘 만드심

'📖 지식을 쌓아보자' 카테고리의 다른 글

넓고 얕은 운영체제  (7) 2025.08.16

카테고리의 다른 글

넓고 얕은 운영체제

티스토리툴바