스터디 진행 일시
날짜 : 10월 02일 (목요일) 시간 : 오후 7시 ~ 9시 (2시간) 장소 : 강남 (오프라인)
🔧 금주 스터디 일정
- 아이스 브레이킹
- API 버전 관리를 왜 해야하는걸까?
- user principal 이란 무엇일까?
- 사일로 현상은 무엇일까?
API 버전 관리를 왜 해야할까?
서비스를 운영하다보면 API를 변경하거나 업그레이드를 해야 하는 순간이 온다. 예를 들어, 유저 정보를 제공하는 API에 새로운 필드를 추가하거나 응답 구조를 바꿔야 할 수도 있다. 이때 기존 API를 완전히 대체해버리면, 아직 앱을 업데이트하지 않은 사용자나 이전 버전에 의존하는 서비스가 모두 영향을 받게 된다.
그래서 API에 대해 버전 관리(versioning)을 하는 것이 좋다.
- api/v1/user/….
- api/v2/user/….
이렇게 하면 기존 클라이언트는 v1을 사용할 수도 있고, 새로운 기능이 필요한 클라이언트는 v2로도 전환할 수도 있다. 또한 문제가 생겼을 때는 롤백(rollback)용도로도 이전 버전을 유지할 수 있고 안정적인 운영이 가능하다.
그럼 버전 종료는 언제할까? (Fade-out)
API 버전은 무작정 삭제하지 않고, 사용량을 모니터링해서 호출이 거의 없거나 일정 기간 동안 사용하지 않을 때 제거하는 방식으로 관리할 수 있다. 이렇게 관리하면 예기치 못한 서비스 장애를 줄이고, 클라이언트가 자연스럽게 새 버전으로 이동할 시간을 줄 수 있다.
User Principal 이란 무엇일까?
Principal은 보안 컨텍스트(Security Context)에서 현재 인증된 사용자(identity)를 나타내는 객체를 말한다. 쉽게 말해, 로그인에 성공해서 검증된 유저 정보가 서버에 저장된 상태를 말한다.
Spring Security에서 Authentication 객체 안에 Principal이 들어 있고, 여기에는 사용자 이름, 권한(role), 추가적인 프로필 정보 등이 포함될 수 있다.
정리하면 “지금 이 API를 호출한 사람이 누구인가?”를 나타내는 핵심 정보가 Principal이다.
왜 User Principal을 사용할까?
-
Spring Security를 거쳐 들어온 요청이라면, 이미 인증 과정에서 해당 유저에 대한 쿼리가 한 번 수행되어 검증이 끝난 상태다. 따라서 서비스 로직 내부에서 또다시 데이터베이스를 조회해 유저 정보를 가져오는 것은 불필요한 중복 작업이 될 수 있다.
-
User Principal을 사용하면, 인증 단계에서 확보한 유저 정보를 Security Context에 저장해두고 서비스 도메인 로직까지 그대로 전달할 수 있다. 성능적으로 효율적일 뿐 아니라, 인증과 인가 로직의 일관성을 유지하기에도 유리하다.
사일로 현상은 무엇일까?
사일로 현상(Silo Effect)은 회사나 조직 문화 이야기에서 정말 자주 나오는 개념이고, 개발 조직(백엔드/프론트/AI팀 등)이 협업할 때 문제로 자주 언급된다.
원래 사일로(Silo)는 곡물을 저장하는 “독립된 저장탑”이라는 뜻인데, 이 개념을 조직 문화에 쓰이게 되면 한 부서나 팀이 자기들만의 벽을 쌓고 다른 팀과 단절된 상태를 말한다.
각 팀이 자기 일만 하고, 서로의 정보나 목표를 공유하지 않으면서 조직 전체의 방향성보다 자신들의 효율/성과/방식을 우선시하는 현상을 사일로 현상이라고 한다.
사일로 현상은 어떻게 해결할 수 있을까?
사일로 현상은 조직이 커질수록, 반드시 한번은 마주할 수 있는 문제다. 단순히 “회의 자주 하자”로는 해결할 수 없다.
- 목표를 “팀별”이 아닌 “조직 전체”로 정하기
- 대부분 사일로는 “우리 팀 성과”만 보려는 구조에서 시작되기 때문에 모든 팀이 같은 북극성(North Star Metric)을 향하도록 만들어야 한다.
- 예를 들어 AI팀 : 모델 정확도 98% 달성이 아니라 전체 서비스 사용자 만족도 90% 달성 (AI 개선 포함) 이런식으로 조직 전체가 가지는 목표가 좋다.
- 대부분 사일로는 “우리 팀 성과”만 보려는 구조에서 시작되기 때문에 모든 팀이 같은 북극성(North Star Metric)을 향하도록 만들어야 한다.