로그인 시스템 Java/Spring 전환

만든 것

• 장애 분석DB 연결 실패가 어느 단계에서 났는지 확인
• 제약 검토런타임 버전 고정이 유지보수와 연동에 주는 영향
• 전환 설계로그인 · 회원 기능의 Java/Spring 전환
• 조회 캐시회원정보 조회에 Caffeine 로컬 캐시

재기동으로 끝내지 않았다

DB 연결을 맺는 단계에서 문제가 생겨 전체 로그인이 불가능한 장애가 있었습니다. 서버와 DB를 재기동해서 복구했지만, 재기동은 증상을 없앤 것이지 원인을 없앤 것은 아니었습니다.

살펴보니 당시 사내 보안 라이브러리 지원 문제로 기존 .NET 런타임 버전이 고정되어 있었고, 이 제약 때문에 Redis Cluster나 MongoDB 같은 연동 기술을 붙이기도 어려운 상태였습니다. 이 제약이 곧 장애의 직접 원인이라고 말할 수는 없지만, 같은 문제를 다시 마주했을 때 손쓸 수 있는 폭을 좁히고 있는 건 분명했습니다.

언어를 바꾼 게 아니라 제약을 푼 것

그래서 재발 방지 패치가 아니라 로그인 · 회원 기능을 Java/Spring으로 옮기는 방향으로 설계에 참여했습니다. .NET이 나빠서가 아니라, 조직이 지원할 수 있는 런타임과 라이브러리 조건에서 유지보수와 연동이 가능한 쪽으로 옮긴 것입니다.

전환 과정에서 자주 조회되는 회원정보에 Caffeine 로컬 캐시를 두는 팀 작업에도 참여했습니다. 인스턴스별 캐시는 갱신이 늦을 수 있어서, 차단이나 탈퇴처럼 즉시 반영되어야 하는 상태는 캐시 대상과 만료 정책을 따로 봐야 합니다.

내 역할의 범위

복구와 전체 전환은 팀 작업이고, 제 역할은 원인 분석과 전환 설계에 기여한 범위입니다. 팀이 함께 운영하는 로그인 서비스의 규모를 제가 혼자 감당했다거나 성능을 끌어올렸다고 말하지 않습니다.

돌아보면

장애 대응에서 무엇이 증상을 없앴는지와 무엇이 원인인지를 구분하게 됐습니다. 그리고 언어 자체보다, 조직이 지원할 수 있는 런타임과 라이브러리 조건이 유지보수 가능성을 좌우한다는 것도요.