[iOS/Trouble Shooting] 에러처리 잘못해서 DB 날린 썰

안녕하세요 제인입니다 :)

개인 프로젝트를 진행하며 기존에 공부했던 기술들을 하나씩 적용해보고 추가로 공부하고 있는데요!

이번 게시글에서는 프로젝트를 진행하며 겪은 문제를 하나 공유해보려고 합니다.

 

시작하기 전, 해당 문제는 휴먼에러에 의해 발생한 문제였기 때문에 해결 과정에서 어떤 대단한 기술을 공부하고 적용한 경험을 공유하기 위한 게시글이 아닙니다. 하지만, 실수로 잘못 적은 코드 한줄이 얼마나 큰 결과를 불러일으킬 수 있는지를 깨달았던 경험이었기 때문에 이를 공유하고 또 해결 과정에서 어떻게 문제 부분을 찾아냈는지 디버깅 방법을 공유해보려고 합니다! 

코드 한 줄 잘못적었다가 DB를 날려버렸다..!

굉장히 자극적인 타이틀.. 하지만 실화입니다💥

사건의 발단은 클린 아키텍처 기반의 프로젝트에서 각 레이어의 역할을 명확히 하고 객체의 책임을 분리하여 장기적인 관점에서 코드 유지보수성을 높이기 위해 시작한 네트워킹 코드 전체 리팩토링이었습니다.

기존 네트워킹 코드 전체를 리팩토링하는 나름 대규모 공사였기 때문에 코드 수정이 생기는 파일이 많고, 비슷한 구조의 메서드도 많았어요.

그래서 코드 한 줄을 잘못 적게 됩니다.. 문제가 된 코드와 해결 후의 코드를 함께 보시져..

문제의 코드

   // UserRepositoryImpl
   func fetchUserData(userId: String) -> AnyPublisher<UserEntity, NetworkError> {
        service.fetch(key: dbKey, path: userId)
            .mapError { _ in NetworkError.serverError}
            .flatMap { value in
                if let value {
                    return Just(value)
                        .tryMap { try JSONSerialization.data(withJSONObject: $0) }
                        .decode(type: UserDTO.self, decoder: JSONDecoder())
                        .map { $0.toEntity() }
                        .mapError { _ in NetworkError.serverError }
                        .eraseToAnyPublisher()
                } else {
                    return Empty().eraseToAnyPublisher()
                }
            }
            .eraseToAnyPublisher()
    }

수정 후 코드

   // UserRepositoryImpl
   func fetchUserData(userId: String) -> AnyPublisher<UserEntity, NetworkError> {
        service.fetch(key: dbKey, path: userId)
            .mapError { _ in NetworkError.serverError}
            .flatMap { value in
                if let value {
                    return Just(value)
                        .tryMap { try JSONSerialization.data(withJSONObject: $0) }
                        .decode(type: UserDTO.self, decoder: JSONDecoder())
                        .map { $0.toEntity() }
                        .mapError { _ in NetworkError.serverError }
                        .eraseToAnyPublisher()
                } else {
                    return Fail(error: NetworkError.invalidURL).eraseToAnyPublisher()
                }
            }
            .eraseToAnyPublisher()
    }

 

수정 전후 코드의 차이는 사실 한줄 밖에 되지 않는데요,

코드를 간단하게 설명해보자면, 실제 네트워킹을 수행하는 객체인 service의 fetch 메서드를 이용해 DB의 유저데이터를 가져오는 코드입니다. fetch에 success하게 되면 받아오는 데이터 타입은 DTO?(옵셔널) 타입이지만 Entity로 매핑을 하기 위해서 if let을 통해서 옵셔널 바인딩을 하게 됩니다. 이 때 값이 있다면 Entity로 매핑해 Publish 하고, 값이 nil이라면 fetch error와 같이 간주하여 Fail을 방출해줍니다.

 

원래의 의도는 위와 같았으나, 수정 전 코드를 보면 if let else 구문에서 Fail이 아닌 Empty Publisher를 방출해주고 있죠.. 예예.. 실수를 해버렸습니다.. 

문제 상황

코드 한줄의 실수가 불러온 문제는 회원 탈퇴 기능 테스트 과정에서 발생했습니다.

위의 코드 실행 결과에 영향을 받게 되는 코드를 먼저 보여드리겠습니다.

final class DeleteAccountUseCaseImpl: DeleteAccountUseCase {
    private let userRepository: UserRepository
    
    init(userRepository: UserRepository) {
        self.userRepository = userRepository
    }
    
    func execute() -> AnyPublisher<Void, NetworkError> {
        userRepository.deleteUserData(userId: UserDefaults.userId)
            .mapError{ _ in
                return .serverError
            }
            .eraseToAnyPublisher()
    }
}

 

유저가 계정을 삭제하게 될 경우, DB의 유저 데이터 또한 안전하게 삭제해주고 있습니다.

이 때, 삭제할 정보의 경로는 https://luckyvicky어쩌구저쩌구/Users/유저아이디 의 형태입니다.

유저가 탈퇴하기 버튼을 누르면 deleteAccount 로직을 실행하게 되고, UserDefaults에 저장되어있는 유저아이디 값을 찾아서 해당 경로 하위에 있는 유저정보를 삭제하는 방식으로 DB의 정보가 삭제됩니다.

그런데, UserDefaults의 값은 위의 fetchData의 결과 값에 따라 변경됩니다.

extension LoginViewModel {
    
    private func login(_ result: Result<ASAuthorization, Error>) {
        ...
        useCase.executeSignIn(authorization, nonce: nonce)
            .sink { [weak self] completion in
                if case .failure(_) = completion {
                    self?.state.hasErrorOccurred = true
                }
                self?.state.isLoading = false
            } receiveValue: { [weak self] user in
                UserDefaults.userId = user.id
                UserDefaults.usedCount = user.usedCount
                UserDefaults.isFirstLaunch = false
                self?.coordinator.present(sheet: .selectCharacter)
            }.store(in: &cancellables)
        ...
    }
}

 

위의 코드는 로그인 로직의 일부입니다. executeSignIn을 호출하면 authentication 상태에 따라 로그인 또는 회원가입을 시키고,

위에서 봤던 fetchUserData 메서드를 통해 초기 유저정보를 UserDefaults에 저장합니다. (로그인 성공 시)

즉, 로그인 로직에 fetchUserData 메서드 호출이 사용되는 것이죠.

 

위의 코드에서 receiveValue 구문에서만 UserDefaults에 값을 세팅해주고 있습니다.

이는 로그인에 성공 할 경우만 데이터를 저장하고 이후 로직을 실행한다는 의미입니다.

로그인 과정(authentication 체크 - 애플에서 권한 위임 - idToken발급 - 회원가입/로그인 - DB데이터 fetch) 중 하나라도 실패할 경우, 데이터를 저장하는 대신, 유저가 로그인을 재시도 할 수 있도록 안내를 해야겠죠.

   // UserRepositoryImpl
   func fetchUserData(userId: String) -> AnyPublisher<UserEntity, NetworkError> {
        service.fetch(key: dbKey, path: userId)
            .mapError { _ in NetworkError.serverError}
            .flatMap { value in
                if let value {
                    return Just(value)
                        .tryMap { try JSONSerialization.data(withJSONObject: $0) }
                        .decode(type: UserDTO.self, decoder: JSONDecoder())
                        .map { $0.toEntity() }
                        .mapError { _ in NetworkError.serverError }
                        .eraseToAnyPublisher()
                } else {
                    return Empty().eraseToAnyPublisher()
                }
            }
            .eraseToAnyPublisher()
    }

 

위에서 실수한 코드를 다시 가져와볼게요.

저는 로그인 과정 중 하나인 fetchUserData에 실패할 경우 Error 를 방출하는 것이 아닌 Empty라는 빈 값을 방출해 성공 케이스로 넘겨버린 것입니다. 

이렇게 되면, UserDefaults에 UserId 값이 "" 이런식으로 빈 값이 저장되고, 이 후 계정 삭제를 하게 되면 https://luckyvicky어쩌구저쩌구/Users/"" 이렇게 유저아이디 값이 들어가야 할 자리에 빈 값이 들어가게 되어 Users 하위의 모든 데이터를 삭제해줘! 하고 요청하는 큰 문제가 발생하게 되는 것이죠..

 

DB 싹 잃은 나.. 막이래..

디버깅 방법

일단 디버깅 이후 찾은 문제 원인부터 설명드렸는데요, 그러면 이 부분이 문제라는 것을 어떻게 찾았냐?

바로바로 lldb를 이용한 빈틈없는 디버깅.. 이라고 할 수 있겠습니다.

 

먼저, 이렇게 예상 실행 순서대로 Breakpoint를 찍어줍니다.

 

그러면, 이런 식으로 실제로 실행되는 순서대로 breakpoint에 걸리게 됩니다.

만약, 찍어놓은 breakpoint에 모두 걸리지 않고 종료되면, 중간에 호출이 끊긴 것이니, 끊긴 지점을 찾아서 코드를 확인해보면 됩니다.

중간중간 실제로 어떤 데이터가 담기나? 확인해보고 싶다면 lldb의 po 명령어를 사용할 수 있습니다.

po 명령어를 활용한 데이터 확인

이렇게 breakpoint가 걸리는 라인에서 path에 담긴 데이터를 확인하기 위해 po path를 입력하게 되면 값이 디버깅 창에 나오게 됩니다.

저의 경우, 이 과정에서 path의 결과가 Users/ 로 나오게 되어서 예상 값이 안나오네? UserId 값이 UserDefaults에 저장되는 과정을 디버깅해봐야지! 의 흐름으로 디버깅을 해서 문제 원인을 찾을 수 있었습니다.

DB 복구 방법

그렇다면.. DB 복구는 어떻게 하셨어요?? 

에 대한 대답은.. 수동으로 하긴 했습니다.. ㅎㅎ

하지만..! Json 형식으로 빠르게 작성해서 DB에 반영해주긴 했습니다 ..

저는 Firebase의 Realtime Database를 사용하고 있는데요(데이터가 id값, 유저별 하루 사용횟수로 간단하기 때문에),

소셜로그인도 FirebaseAuth를 이용하고 있기 때문에 가장 중요한 정보인 UserId값을 찾아서 복구 할 수 있었습니다.

 

Firebase의 Authentication 탭으로 가면 이렇게 가입한 유저의 사용자 UID를 확인할 수 있습니다.

이를 이용해서 DB를 복구했습니다. 저의 서비스의 경우 하루가 지나면 어차피 초기화되는 데이터를 저장하고 있었기 때문에 큰 문제없이 복구할 수 있긴 했습니다.. 하지만.. 중요한 데이터였다면.. 매우 아찔- 하네요.

느낀점

먼저, 한 줄 잘못 쓴 코드가 이렇게 큰 결과를 가져올 수 있다는 것을 뼈저리게 느꼈습니다..

또 중요한 것은 debug모드, release모드를 분리해서 실제 db는 테스트 환경에서 독립될 수 있도록 하는 것이 필요하겠구나를 느꼈습니다.

(+ 혹시나 모를 상황에 DB 백업도 주기적으로 해야겠습니다. )

 

오늘도 긴 글 읽어주셔서 감사합니다🍀

트러블슈팅의 주인공 럭키비키 서비스도 다운받아주세요~ㅎ

‎럭키비키 - 기분 좋은 오늘을 위한 사고 변환기