SSO를 먼저 깔아야 할까, 서비스부터 안정화할까

SSO 프로젝트를 맡았을 때, 가장 오래 붙잡고 있던 질문이 하나 있었다. 지금 인증을 먼저 통합할 것인가, 각 서비스 안정화를 먼저 할 것인가.

당시 상황

• 레거시 로그인 방식이 서비스마다 달랐다.
• 신규 기능은 빠르게 나가야 했다.
• 인증 실패는 장애로 바로 이어졌다.

그래서 “나중에 하자”가 항상 유혹적이었다.

찬성 쪽 생각

• 인증이 통일되면 이후 연계 개발이 단순해진다.
• 보안 정책을 한곳에서 관리할 수 있다.
• 운영 계정 이슈를 줄일 수 있다.

반대 쪽 생각

• SSO 구축 기간 동안 기능 개발 속도가 떨어질 수 있다.
• 기존 세션/토큰 이슈를 한 번에 건드리면 리스크가 커진다.
• 팀마다 적응 비용이 생긴다.
• 프로젝트 마다 권한과 Rule 이 다르다.
  • AS 사이트의 경우, 본사와 파트너사만 이용 가능하다.

내가 내린 임시 결론 (당시 결론)

결제 서비스가 내재되어 있는 메인 스키마에 완벽한 일괄 전환은 무리라고 봤다. 핵심 서비스부터 단계적으로 묶고, 실패 시 롤백 루트를 먼저 만들자고 정했다.

“이상적인 통합”과 “지금 깨지면 안 되는 운영” 사이에서, 나는 되돌릴 수 있는 작은 전진을 택했다. SSO를 한 번에 다 깔았을 때의 그림은 더 멋졌지만, 그 그림은 실패했을 때의 비용을 숨기고 있었다.

서비스 영향도를 없애기 위해 스키마를 나누거나 이기종 데이터베이스로 나눴다. AS 사이트처럼 본사·파트너만 쓰는 권한 체계가 다른 서비스는 억지로 같은 규칙에 욱여넣지 않았다.

비슷한 경험 — 무중단 배포(blue & green)

순서와 롤백을 두고 했던 고민은 배포 구조에서도 똑같이 나왔다. GitHub Actions와 Jenkins를 엮어 배포 자동화를 만들 때, “빠르게 한 번에 바꾸기”와 “끊김 없이 돌려놓기” 사이에서 또 갈렸다.

• 이유: 결제가 물린 서비스는 배포 중 단 몇 초의 단절도 사고로 이어졌다. 새 버전을 빨리 내고 싶은 마음과, 문제 시 즉시 되돌려야 한다는 요구가 부딪혔다.
• 당시 결론: blue & green 방식으로 새 버전을 띄워 두고, 트래픽만 전환하는 구조를 택했다. SSO 때와 똑같이 “전진보다 후퇴 경로를 먼저” 깔았다.
• 두 경험을 거치며 분명해졌다. 나는 롤백이 보장되지 않는 변화는 신뢰하지 않는다. 새로움은 되돌릴 수 있을 때 비로소 안전한 실험이 된다.

아직 부족한 것 (개선점)

• 단계적 통합이라 과도기 동안 인증 방식이 둘로 공존한다. 그만큼 운영 복잡도와 예외 처리가 늘었다.
• 롤백 루트는 만들었지만, 정기적으로 실제 롤백을 검증하진 못한다. “될 것이다”에 가깝다.
• 서비스별 권한·Rule이 코드 곳곳에 흩어져 있어, 권한 정책의 단일 소스가 아직 없다.

앞으로 나가야 할 방향

1. 인증 공존 기간을 짧게 가져갈 수 있도록 마이그레이션 마감선을 정하고, 구방식 사용량을 측정해 닫는다.
2. 롤백을 문서가 아닌 정기 리허설로 검증해, “실패해도 돌아온다”를 실제로 보장한다.
3. 권한·Rule을 한곳에서 관리하는 정책 레이어로 모아, 서비스마다 다른 규칙을 선언적으로 표현한다.
4. 인증·세션 이슈는 결제/정산 운영 체크리스트의 모니터링 지표와 연결해, 인증 실패 급증을 장애 징후로 일찍 감지한다.

아직 진행 중이지만, 지금은 “순서”보다 “롤백 가능성”을 더 중요하게 보고 있다.
다음 목표는 그 롤백 가능성을 믿음이 아니라 검증된 사실로 바꾸는 것이다.