iOS Development Guide

guard와 if let의 사용 기준

둘 다 optional binding이지만, 코드의 의도를 표현하는 방식이 다르다. 이 문서는 "어느 문법이 맞냐"보다 "어떤 흐름에서 어떤 문법이 읽기 쉬운가"를 기준으로 정리한다.

Swift control flow Practical readability first Knowledge item #6

학습 날짜

2026-04-17

핵심 한 줄

`guard let`: 실패 조건을 먼저 걸러내고, 성공 경로를 계속 이어갈 때 사용한다.
`if let`: 값이 있을 때만 짧은 분기 로직을 실행할 때 사용한다.
중요한 기준은 문법 취향이 아니라 "이후 코드의 가독성"이다.

왜 구분이 필요한가

optional을 해제하는 시점이 많아질수록 함수가 분기문으로 뒤엉키기 쉽다. 이때 `guard let`으로 선조건을 정리하면 주 로직이 왼쪽 정렬로 남고, `if let`은 필요한 구간에서만 국소적으로 쓰게 되어 코드 의도가 명확해진다.

비교 예시

func loadProfile(userID: String?) {
    guard let userID else {
        logger.warn("missing user id")
        return
    }

    // 여기부터는 userID가 반드시 존재한다고 가정 가능
    requestProfile(userID: userID)
}

func renderNickname(_ nickname: String?) {
    if let nickname {
        nameLabel.text = nickname
    } else {
        nameLabel.text = "-"
    }
}

판단 기준

함수의 "계속 진행 조건"을 확정해야 하면 `guard let`, "특정 블록에서만" 값이 필요하면 `if let`이 더 자연스럽다.

guard let이 특히 좋은 경우

입력 검증 실패 시 즉시 return/throw 해야 하는 함수 시작부
네트워크 요청 전 필수 파라미터 확인
UIViewController에서 의존성 주입 누락 방어

if let이 특히 좋은 경우

라벨, 뱃지, 섹션 같은 선택적 UI 표시
값이 있을 때만 추가 동작을 붙이는 작은 분기
값이 없어도 함수 전체 흐름은 유지되는 경우

실수하기 쉬운 패턴

여러 단계의 `if let` 중첩으로 들여쓰기가 과도하게 깊어지는 패턴
필수 조건인데도 `if let`으로 감싸고 else에서 아무 처리 없이 통과하는 패턴
`guard let`에서 실패 처리 없이 단순 return만 남겨 원인 추적이 어려워지는 패턴

가능하면 실패 사유를 로깅하거나, 호출자에 전달 가능한 에러로 변환해 추적 가능성을 남긴다.

Then 1

둘 중 하나만 팀 규칙으로 강제하면 안 되나요?

권장 규칙은 만들 수 있지만, 둘의 쓰임새가 다르기 때문에 단일 문법 강제는 오히려 가독성을 해칠 수 있다. 핵심은 "주 흐름 보존"과 "분기 범위 최소화"다.

Then 2

`guard let`을 쓰면 무조건 좋은 건가요?

아니다. 아주 짧은 UI 분기에도 `guard`를 남용하면 함수가 조기 종료 포인트로 흩어져 오히려 읽기 어려워질 수 있다. 조건의 성격에 맞춰 선택해야 한다.