SpringCamp 2025 다녀온 기록

처음으로 참석하게 된 스프링 캠프 컨퍼런스.

2023년, 2024년에 탈락으로 가고 싶어도 가지 못했지만, 2025년에는 운이 좋게 참석했다.

주말 오전 삼성역에서 진행하는 컨퍼런스라 일찍이 광역 버스에 탑승했다.

 

추첨으로 담청된건 살면서 처음

 

 

1. 컨퍼런스 진행 방식

(1) 세션 진행 방식

이번 컨퍼런스는 동 시간에 두 세션을 동시에 진행하는 방식이었다.

(사실 이번에 처음 와봐서 잘 모르겠다.)

 

오후 2시에 진행하는 MSA 와 트랜잭션 개발 가이드, Virtual Thread 세션 모두 듣고 싶었지만,

Virtual Thread 세션은 3개월 뒤에 업로드 되는 유튜브 영상으로 대체하기로 했다.

 

딱 하루만 운영하는 컨퍼런스여서 불가피하게 선택과 집중을 해야 하는 구조가 되었는지 아닌가 싶다.

 

(2) 굿즈

이번 컨퍼런스에서는 입장 팔찌와 함께 컨퍼런스 굿즈를 받았다.

 

스프링 캠프인 만큼 모두 스프링 로고가 박혀있는 굿즈가 제공 되었다.

스티커 / 펜 / 키캡 / 키링이 제공되었는데 전체적으로 퀄리티가 좋아 만족스러웠다.

 

그 외에도 각 기업들 부스에서도 굿즈를 제공해주었다.

AWS 부스에서 파우치를 받았는데, 충전기와 충전선 보관용으로 잘 사용하고 있다. 👍

스프링 캠프 2025 굿즈

 

 

2. 세션 내용

(1) 통합의 근본! 인가 플랫폼 - HR SaaS는 왜 복잡할까?

i. HR 도메인 복잡한 권한, 인가 구조

이번 세션은 flex 기업에서 HR 도메인 문제에서 발생한 권한와 인가에 관한 문제 해결 과정을 설명하는 세션이었다.

 

HR 영역의 인증/인가 도메인은 높은 수준의 비즈니스 요구사항과 문제를 해결해야 했다.

조직 구조, 역할, 상황에 따라 달라지는 복잡한 접근 요구를 동시에 만족하며 권한과 인가를 제공해야 하는 복잡한 문제를 다루기 때문이다.

 

그룹이나 조직의 경우 트리 구조(Tree) 를 기반으로 인가 문제를 접근한다.

해당 케이스만 봐도 고려해야할 케이스가 다양하다. 조직 관점에서만 봐도 고려사항이 이렇게 많다.

1. 요청자는 권한을 부여 받은 임직원인가?
2. 요청자는 권한을 부여 받은 대상과 연결된 임직원인가?
3. 요청자는 권한을 부여 받은 조직의 상위 조직장으로 연결된 임직원인가?
4. 요청자는 최상위 리소스에 접근이 가능한가?
5. N 개의 접근 가능한 데이터 세트의 검색 /정렬/ 필터/ 그룹 / 집계할 수 있는가?

 

트리 구조 (Tree)
그래프의 일종으로 한 노드에서 시작해 다른 정점들을 순회하며 자기 자신에게 돌아오는 순환이 없는 연결 그래프

 

 

ii. 복잡한 권한, 인가 구조 해결을 위한 패턴

복잡한 권한과 인가를 다루기 위해서 3가지 방식으로 인증/인가 문제를 고려한다.

• RBAC(Role Based Access Control - 역할 중심)
• ReBAC(Relationship-Based Access Control, 관계 중심)
• ABAC(Attribute-Based Access Control, 속성 중심)

케이스에 따라 역할(Role), 관계(Relation), 속성(Attribute) 을 기반으로  인증/인가 문제를 접근하며,

흔히 spring security 에서 사용하는 ROLE_ADMIN 과 같이 사용자에게 역할을 부여하여 인가를 제공하는 방식이 RBAC 이다.

 

ABAC 은 장소, 시간, IP 에 관한 인가 문제를 해결하기 위한 접근 방식이다.

 

 

iii. OpenFGA 도입을 통한 MSA 수준에서 다양한 관계 인가 문제 해결

플렉스는 MSA 수준의 HR 도메인이 확장하면서 ReBAC(다양한 관계 중심의 인가 문제)를 해결하기 위해

Golang 기반의 OpenFGA(Open Fined-Grained Authorization) 도입을 통해 문제를 접근했다.

 

그 외에서 SSE 도입 과정, 임직원 서비스 양방향 의존 관계에 관한 문제 해결 과정에 관한 내용 또한 다뤘다.

최근에 사이드 프로젝트를 진행하며 SSE 를 도입한 경험이 생각나며 반가웠다.

생소한 개념들이 많이 나와 이해하지 못한 내용이 많았는데 영상이 업로드 되면 다시 한번 살펴봐야 겠다.

 

 

(2) 실전! MSA 트랜잭션 개발 가이드

i. 데이터 오너십 원칙 + 피벗 트랜잭션

 이 세션은 MSA 환경에서 트랜잭션을 처리해야 할 케이스와 접근 방법에 관한 실용적인 기준에 관한 내용이었다.

 

가장 인상 깊었던 키워드 중 하나는 데이터 오너십 원칙이었다.

데이터는 오직 오너십을 가진 서비스만 데이터에 접근할 수 있고,

다른 서비스의 데이터는 오너십을 가진 서비스 호출을 통해서만 사용해야 한다.

 

그러므로 오너십이 없는 서비스의 테이블은 JOIN, Repository, Service 호출을 통한 접근을 지양해야 한다.

이와 같은 구조는 느슨한 결합도를 유지하기 때문에 모듈화하기 용이하고 로직을 분리하기 위한 비용이 줄어든다.

 

만약 서비스 규모 확장으로 인한 데이터를 분리를 검토해보아야 한다.

대표적인 예시로 서비스 역할에 맞는 컬럼과 레코드를 나누는 방법이 있다.

 

 

피벗 트랜잭션(pivot transaction) 은 트랜잭션 중 에러가 발생했을 때 재시도 또는 취소를 결정하는 기준을 말한다.

피벗 트랜잭션은 업무적으로 성공하는 지점 여부를 결정하는 지점이 된다.

이를 기준으로 트랜잭션을 분리를 검토해야 한다.

 

ii. 원자성 보장

트랜잭션 원자성은 트랜잭션에 포함된 모든 연산이 전부 수행되거나 전혀 수행되지 않아야 하는 성질이다.

트랜잭션이 실패하면 이전과 동일한 상태가 되어야 한다.

 

미처 생각치 못했던 내용 중 접근법 모놀로식 트랜잭션 실패 케이스에서도 실행 시간이 길어지는 경우가 있다.

이와 같은 경우 여러 개의 트랜잭션으로 분리해 업무적으로 실패했을 경우에 대한 보상 트랜잭션을 검토해야 한다.

 

iii. 격리성 보장

격리성은 동시에 실행되는 트랜잭션들이 서로의 중간 결과에 간섭하지 않고 독립적인 수행을 보장하는 성질이다.

 

단일 트랜잭션인 경우 격리 레벨(Isolation Level) 로 변경 중인 데이터의 다른 트랜잭션이 접근 여부를 설정할 수 있다.

 

하지만 트랜잭션이 분리가 되면 격리 레벨 만으로 해결되지 않는 문제가 발생한다.

이는 변경 중인 데이터를 다른 트랜잭션이 덮어쓸 수 있는 위험이 있다. (이와 같은 상황을 lost update problem 라 부른다.)

 

이를 해결하기 위해서는

Sementic Lock, TCC(Try, Confirm, Cancel), Offline Lock 과 같은 접근 방법을 검토해야 한다.

 

iv. 두 저장소에 쓰기의 어려움

두 저장소에 동시에 데이터를 쓰기를 하는 경우 Network I/O 문제로 실패가 발생할 수 있으며,

이벤트에 관한 재처리가 필요하다.

 

이를 위해 신뢰할 수 있는 이벤트 전송을 보장하는 트랜잭션 아웃박스 패턴을 적용해볼 수 있다.

 

또한 실패한 작업을 다시 시도하는 과정에 성공한 작업을 중복 실행하는 문제가 발생할 수 있다.

따라서 같은 작업을 여러 번 실행해도 결과가 변하지 않는 멱등성(Idempotency) 보장이 중요하다.

 

v. 불안정한 네트워크 통신

트랜잭션이 내부적으로는 성공했지만, 통신 단계에서 에러가 발생하면 전체적으로는 실패처럼 보일 수 있다.

이때 상대에게 에러 여부를 명확히 전달하는 것은 큰 장점이 된다.

 

그러나 실제로는 성공했음에도 실패처럼 보이는 가짜 실패를 전달하는 케이스가 존재할 수 있다.

ConnectionException 을 제외하면 대부분 가짜 실패일 가능성이 있다.

이런 경우를 대비해 API 재호출이나 멱등성 구현을 통해 안전하게 재처리할 수 있도록 하는 것이 중요하다.

 

 

멱등성을 구현하면 동일한 요청이 여러 번 실행되더라도 결과가 변하지 않는 특성이 있어

실패 상황에서도 안전하게 재처리가 가능하다.

 

이를 위해 요청마다 고유한 식별자(Unique ID) 를 부여해서 문제를 해결할 수 있다.

해당 키값을 통해 사전에 중복 여부를 확인하거나 사후에 오류를 무시하는 방식이 쓰인다.

 

또한 같은 데이터를 여러 번 수정하는 경우에 순서가 꼬여 문제가 되지 않도록 처리해야 한다.

이렇게 하면 네트워크 오류나 재시도 상황에서도 안정성을 보장할 수 있다.

 

 

3. 후기

이번 기술 발표들에서 다양한 키워드, 실무적인 접근과 실용적인 내용들이 많아 유익한 시간이었다.

많은 개발자들이 사용자에게 가치를 전달하기 위해 다양한 기술과 접근 방법으로 노력하는 모습을 보며 긍정적인 자극을 받았다.

 

매번 컨퍼런스 갈 때마다

어떤 서비스를 제공할 것인가에 관한 부분이 우선시하고, 기술은 이를 위한 선택사항이라는 부분을 다시 한번 상기시키게 된다.

개발자는 고객의 문제를 기술적인 접근을 통해 해결하는 사람이라는 것을 잊지 말 것.

 

3개월 뒤에 영상이 업로드 될 예정이니 못 들었던 세션을 들어봐야겠다.

• 발표자료  : https://github.com/springcamp/presentations/tree/main/SpringCamp-2025-Presentations