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

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

회의실 백화판에는 두 그림이 동시에 그려져 있었다. 하나는 ‘통합된 미래’, 하나는 ‘지금 돌아가는 운영’. 나는 둘 다 원했고, 둘 다 무서웠다.

당시 상황 — 왜 고민이 길었는가 (이유)

그래서 ‘나중에 하자’가 항상 유혹적이었다. 하지만 나중은 영원히 오지 않는다는 것도 알고 있었다.

찬성 쪽도 맞았다. 통일되면 이후 연계가 단순해지고, 보안 정책을 한곳에서 관리할 수 있다.
반대 쪽도 맞았다. 한 번에 건드리면 리스크가 크고, AS 사이트처럼 본사·파트너만 쓰는 권한 체계는 억지로 같은 규칙에 넣기 어렵다.

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

SSO를 한 번에 다 깔았을 때의 그림은 더 멋졌다. 하지만 그 그림은 실패했을 때의 비용을 숨기고 있었다. 회복탄력성 글에서도 적었지만, 나는 되돌릴 수 있는 작은 전진을 택하는 편이 됐다.

스키마를 나누거나 이기종 DB로 나눴다. 권한 체계가 다른 서비스는 억지로 욱여넣지 않았다. ‘통합’보다 ‘깨지지 않게’가 먼저였다.

GitHub Actions와 Jenkins로 배포 자동화를 만들 때도 똑같이 갈렸다.

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

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