로그아웃 로직 Optional과 예외 처리 개선기

문제 : 과도한 예외 처리와 복잡한 흐름

처음 작성했던 코드(1번 코드)는 로그아웃 프로세스를 하나의 큰 try-catch 블록 안에 넣고 있었습니다.

// 1번 코드
함수: 로그아웃을 시작한다
  시도해본다:
    소셜 계정에서 로그아웃을 요청한다 (이 과정에 사용자 인증 정보 확인도 포함)
    로그아웃 완료 이벤트를 알린다
    사용자 인증 정보를 모두 지운다
    로그아웃용 쿠키를 반환한다
  만약 오류가 발생하면:
    로그아웃 실패 오류를 발생시킨다

이 방식은 얼핏 보면 안전해 보이지만, 다음과 같은 두 가지 큰 문제를 가지고 있었습니다.

1. 단일 책임 원칙 (SRP) 위반: 소셜 로그아웃 처리 메서드 안에서 사용자 정보 확인과 실제 로그아웃 요청이라는 두 가지 책임이 섞여 있었습니다. 이 때문에 코드를 이해하기 어렵고, 특정 부분만 수정하기가 까다롭습니다.
2. 예외 처리의 모호성: 소셜 계정 로그아웃 과정에서 오류가 발생하더라도 전체 로그아웃 절차에 영향을 주지 않기 위해 예외를 잡아서 처리했습니다. 문제는 이 과정에 사용자 정보 확인 로직도 함께 섞여 있었다는 점입니다. Optional을 사용해 토큰의 존재 여부를 확인하고, 만약 토큰이 없다면 로그만 남기고 다음 단계로 넘어갔었습니다. 그 결과, 소셜 로그아웃 API 호출 실패뿐만 아니라, 토큰이 이미 사라진 경우와 같은 사용자 정보 확인의 치명적인 문제까지도 조용히 무시하고 다음 단계로 넘어갔습니다. 이는 반드시 발생해야 할 예외가 누락되어 의도치 않은 동작을 유발하는 원인이었습니다.

---

개선 방안: 역할 분리와 명확한 예외 처리

이러한 문제들을 해결하기 위해 코드의 구조를 재정비했습니다. 핵심은 각 메서드가 하나의 명확한 역할만 담당하도록 분리하는 것이었습니다.

 

1. '필수 정보 확인' 전담 메서드 생성: 로그아웃을 진행하기 전에 반드시 필요한 사용자 정보(토큰)를 확인하는 첫 단계를 별도의 메서드로 분리했습니다. 이 메서드는 만약 사용자 정보가 없다면, 그 즉시 심각한 오류임을 알리고 더 이상 진행하지 못하게 막습니다. 이제 Optional은 선택적인 데이터 조회에만 사용하고, 필수적인 데이터가 없을 때는 예외를 명확히 던지도록 했습니다.

// 개선된 2번 코드
함수: 필요한 사용자 정보를 가져온다
  정보를 조회한다
  만약 정보가 없다면:
    "사용자 정보가 없어 로그아웃할 수 없습니다"라는 오류를 발생시킨다
  정보를 반환한다

 

2. 소셜 로그아웃 전담 메서드 단순화: 이제 앞 단계에서 확실하게 가져온 정보를 바탕으로, 이 메서드는 오직 소셜 플랫폼 로그아웃에만 집중할 수 있게 되었습니다. 소셜 로그아웃 실패는 전체 로그아웃 프로세스를 중단할 만큼 치명적이지 않다고 판단했기 때문에, 이 부분만 try-catch로 감싸고 로그를 남기도록 했습니다.

// 개선된 2번 코드
함수: 소셜 계정에서 로그아웃을 요청한다
  시도해본다:
    소셜 계정에 로그아웃을 요청한다
  만약 오류가 발생하면:
    오류를 기록한다 (하지만 로그아웃은 계속 진행)

---

결론: 더 깔끔하고 안전한 구조

이러한 개선을 통해 다음과 같은 이점을 얻을 수 있었습니다.

• 명확한 흐름: 로그아웃 과정이 **'필요한 사용자 정보를 확인하고 → 소셜 로그아웃을 요청한 뒤 → 마지막 정리 절차를 수행한다'**는 세 단계로 명확하게 나었습니다.
• 견고한 오류 처리: 핵심적인 문제(사용자 정보 없음)는 즉시 처리하고, 부수적인 문제(소셜 로그아웃 실패)는 유연하게 넘어가도록 했습니다. 덕분에 어떤 상황에서도 코드가 의도한 대로 동작할 수 있게 되었죠.
• 쉬운 관리: 각 단계가 독립적이므로, 앞으로 특정 기능을 수정하거나 추가할 때 다른 부분에 영향을 주지 않고 작업할 수 있습니다.

이렇게 코드를 기능별로 분리하고, 각 기능에 명확한 책임을 부여하는 것의 중요성을 깨달았습니다.