조건문이 너무 길어졌을 때 읽기 좋게 바꾸는 법: 초보 코드 리뷰 Before & After
1. 주제 소개
초보 코드 리뷰를 하다 보면 가장 자주 만나는 장면이 긴 조건문입니다. `if` 안에 `if`가 들어가고, `else if`가 계속 이어지며, 논리연산자까지 섞이면 코드가 동작하더라도 읽기가 매우 어려워집니다. 특히 로그인, 결제, 권한 체크 같은 분기 많은 기능에서 이런 문제가 자주 나타납니다. 문제는 단순히 코드가 길다는 것이 아니라, 어떤 케이스가 먼저 처리되고 어떤 케이스가 누락됐는지 파악하기 어렵다는 점입니다. 이 상태에서는 수정할 때마다 예상치 못한 회귀 버그가 생기기 쉽습니다.
이번 글에서는 길어진 조건문을 읽기 좋게 바꾸는 기본 기준을 Before & After 관점으로 정리합니다. 핵심은 분기 자체를 없애는 것이 아니라, 조건의 의도를 이름으로 드러내고, 실패 케이스를 먼저 반환하며, 분기 구조를 단순화하는 것입니다. 이 원칙만 적용해도 코드 독해 속도와 디버깅 안정성이 크게 좋아집니다.
2. 핵심 내용
첫 번째 기준은 조건식을 변수나 함수로 추출하는 것입니다. `if (user && user.role === 'admin' && !user.isBlocked && token && token.length > 10)` 같은 식은 한 번에 이해하기 어렵습니다. 이를 `const isValidAdminSession = ...`처럼 이름 붙여 분리하면 의도가 즉시 보입니다. 두 번째 기준은 가드 클로즈(early return)입니다. 정상 흐름을 깊은 중첩 안에 넣기보다 실패 조건을 먼저 반환하면 들여쓰기 깊이가 줄고 핵심 로직이 위로 올라옵니다.
세 번째는 분기 기준을 한 축으로 정리하는 것입니다. 상태값이 명확하다면 긴 `if/else if` 체인보다 `switch` 또는 매핑 객체가 더 읽기 쉽습니다. 예를 들어 주문 상태 처리에서 `PENDING`, `PAID`, `CANCELLED` 같은 값이 있다면 상태별 핸들러 매핑 구조로 바꾸는 것이 유지보수에 유리합니다. 네 번째는 중복 조건 제거입니다. 여러 분기에서 같은 검사를 반복하면 읽기 난이도가 올라가므로 선행 검증 단계에서 한 번만 처리하는 편이 좋습니다.
마지막으로 "부정 조건 남발"을 줄여야 합니다. `if (!isNotAllowed)` 같은 이중 부정은 실수를 유발합니다. 가능하면 긍정형 이름으로 바꾸고, 조건을 단순하게 유지하면 팀 전체의 이해도가 올라갑니다.
3. 적용 방법
실무에서는 먼저 긴 조건문을 복사해 줄 단위로 분해합니다. 다음으로 각 조건이 무엇을 검사하는지 주석이 아니라 변수명으로 표현합니다. 이후 실패 조건부터 early return으로 배치해 중첩을 줄입니다. 상태값 기반 분기라면 `switch`나 객체 매핑으로 전환하고, 마지막으로 중복 검사를 앞단으로 끌어올립니다. 변경 후에는 최소한 경계 케이스를 포함해 3~5개 시나리오를 수동 테스트하면 안정적으로 리팩터링할 수 있습니다.
| 개선 포인트 | Before | After |
|---|---|---|
| 조건 가독성 | 긴 조건식이 한 줄에 밀집 | 의미 있는 불리언 변수/함수로 추출 |
| 중첩 깊이 | if 안에 if가 반복됨 | early return으로 평탄화 |
| 상태 분기 | 긴 else-if 체인 | switch 또는 매핑 객체 사용 |
| 조건 중복 | 여러 분기에서 동일 검사 반복 | 선행 검증 단계로 통합 |
Before 코드에서는 "어떤 조건이 우선인지"를 이해하려고 위아래를 계속 왕복하게 됩니다. After 구조에서는 조건 이름이 문장처럼 읽히고, 실패 경로가 먼저 정리되어 핵심 로직을 빠르게 파악할 수 있습니다. 특히 신규 팀원이 코드를 인수받을 때 조건 해석 시간이 줄어들어 기능 확장 속도가 빨라집니다. 조건문 정리는 화려해 보이지 않지만 실제 생산성을 크게 끌어올리는 기초 작업입니다.
4. 정리
긴 조건문을 읽기 좋게 바꾸는 핵심은 "로직을 숨기지 않고 드러내는 것"입니다. 조건을 이름으로 분리하고, early return으로 중첩을 줄이고, 상태 분기를 구조화하면 코드가 짧아지지 않아도 훨씬 명확해집니다. 초보 단계에서는 분기 추가가 곧 복잡도 증가로 이어지기 쉬우므로, 새 조건을 넣기 전에 기존 구조를 먼저 정리하는 습관이 중요합니다. 결국 좋은 조건문은 똑똑한 트릭이 많은 코드가 아니라, 실수 없이 빠르게 읽히는 코드입니다.
5. 자주 묻는 질문
Q1. early return을 쓰면 반환이 많아져서 불편하지 않나요?
반환 지점이 늘어도 중첩이 줄어 읽기가 쉬워지는 장점이 큽니다. 특히 예외 케이스를 먼저 처리할 때 효과가 좋습니다.
Q2. if/else와 switch 중 무엇이 더 좋은가요?
상태값이 명확하고 경우의 수가 고정되어 있으면 switch가 유리합니다. 복합 조건이 많다면 불리언 추출 + early return 조합이 더 읽기 좋습니다.
Q3. 조건 함수로 분리하면 성능에 영향이 있나요?
대부분의 일반적인 UI 로직에서는 체감 성능 차이가 거의 없습니다. 유지보수성과 버그 감소 효과가 훨씬 큽니다.