
1. 서론: 왜 프로그램에는 '선택'이 필요한가?
여러분이 매일 마주하는 자판기를 떠올려 보세요. 돈을 충분히 넣었을 때는 음료가 나오고, 그렇지 않으면 돈을 돌려줍니다. 만약 자판기가 돈의 액수와 상관없이 무조건 음료를 내뱉거나, 돈을 넣어도 아무 반응이 없다면 어떨까요? 그건 제대로 된 기계라고 할 수 없겠죠.
프로그래밍도 마찬가지입니다. 기본적으로 코드는 위에서 아래로 순서대로 실행되는 순차문의 성격을 갖습니다. 하지만 우리 삶이 수많은 선택과 반복으로 이루어져 있듯, 프로그램 역시 상황에 따라 경로를 바꾸는 제어문이 반드시 필요합니다. 조건문은 프로그램이 "만약 ~라면(if)"이라는 판단을 내리게 하여, 단순한 명령의 나열을 넘어 지능적으로 동작하게 만드는 핵심 로직입니다.
--------------------------------------------------------------------------------
2. if...else 기초: 스마트한 코드의 첫걸음
기본 문법: if 문
조건문의 가장 기본은 if 문입니다. 괄호 안의 조건식이 참(true)일 때만 중괄호({}) 안의 코드가 실행됩니다.
if (조건식) {
// 조건식이 참(true)일 때 실행할 코드
}
두 방향 분기: else 문
조건이 거짓(false)일 때 실행할 다른 경로가 필요하다면 else 문을 사용합니다. 이를 통해 프로그램은 '두 방향 분기' 구조를 갖추게 됩니다.
코드 예시: 합격 판단과 양수/음수 판별
제공된 소스의 '합격 판단'과 '양수/음수 판별' 로직을 JavaScript로 구현하면 다음과 같습니다.
// 예시 1: 합격/불합격 판단 (60점 기준)
let score = 60;
if (score >= 60) {
console.log("합격");
} else {
console.log("불합격");
}
// 예시 2: 양수/음수 판단
let number = -10;
if (number > 0) {
console.log("양수입니다.");
} else if (number < 0) {
console.log("음수입니다.");
} else {
console.log("0입니다.");
}
[시니어의 팁] 실행할 코드가 한 줄인 경우 중괄호를 생략할 수 있지만(단문), 저는 항상 중괄호를 사용하는 복문 형태를 강력히 권장합니다. 과거 유명했던 보안 사고 중 하나인 'goto fail' 버그처럼, 중괄호가 없으면 나중에 코드를 한 줄 추가했을 때 그 코드가 조건문에 포함되지 않아 치명적인 논리 오류를 야기할 수 있기 때문입니다.
--------------------------------------------------------------------------------
3. 다중 조건 처리: else if와 논리 연산자
else if를 활용한 다중 분기
처리해야 할 선택지가 여러 개일 때(예: 성적 학점 계산)는 else if를 사용하여 검사 항목을 늘릴 수 있습니다.
let score = 85;
if (score >= 90) {
console.log("A학점");
} else if (score >= 80) {
console.log("B학점"); // 85점이므로 여기서 실행됨
} else if (score >= 70) {
console.log("C학점");
} else {
console.log("F학점");
}
논리 연산자 결합
&&(AND), ||(OR), !(NOT) 연산자를 사용하면 더욱 복합적인 조건을 스마트하게 처리할 수 있습니다.
// 숫자 범위 체크 및 문자열 비교
let age = 13;
let name = "JavaScript";
// 14세 미만 체크 (Source Context 기준)
if (name === "JavaScript" && age < 14) {
console.log("만 14세 미만 어린이는 부모님의 동의가 필요합니다.");
}
--------------------------------------------------------------------------------
4. 클린 코드 리팩토링: '조건문 지옥(If-Hell)' 탈출하기
코드가 복잡해지면 가독성을 해치는 두 주범이 등장합니다. 바로 한 번에 너무 많은 요소를 비교하는 것과 **과도한 중첩(Nesting)**입니다. 선배 개발자들은 이를 '계단식 코드'라고 부르며 경계합니다.
해결책 1: 배열과 includes() 활용
여러 값을 동일한 변수와 비교할 때 || 연산자를 남발하는 대신 배열을 사용해 보세요.
• Before (가독성 저하)
• After (깔끔하고 확장성 있음)
이 방식은 코드가 짧아질 뿐만 아니라, 나중에 새로운 음식을 추가할 때 배열만 업데이트하면 되므로 유지보수와 확장성 면에서 훨씬 유리합니다.
해결책 2: 가드 클로즈(Guard Clause) 패턴
"No more nesting!"을 실천하는 가장 세련된 방법입니다. 함수 상단에서 예외 조건을 먼저 체크하고 바로 return 해버리는 기법입니다. 이를 통해 실제 핵심 로직인 **'해피 패스(Happy Path)'**를 들여쓰기 없이 가장 왼쪽에 정렬할 수 있습니다.
// 가드 클로즈 적용 예시
function registerUser(user) {
// 1. 예외 조건부터 처리하여 함수를 보호 (가드)
if (!user) return;
// 2. 메인 로직 진행 (불필요한 중첩 제거)
console.log("Registering...");
executeRegistration(user);
}
가드 클로즈를 사용하면 개발자가 로직의 흐름을 선형적으로 따라갈 수 있어 인지적 부하가 크게 줄어듭니다.
--------------------------------------------------------------------------------
5. 전문가의 조언: 안전한 조건문 작성을 위한 시큐어 코딩
조건문은 보안의 핵심인 입력 데이터 검증의 최전선입니다. 잘못 작성된 조건문은 시스템 전체를 위험에 빠뜨릴 수 있습니다.
화이트리스트 기반 검증 (Whitelist-based Validation)
입력값을 검증할 때는 허용되지 않는 것을 막는 것이 아니라, 허용된 목록(Whitelist)만 통과시키는 방식이 가장 안전하고 구현하기 쉽습니다.
SQL 삽입 공격 방어
사용자 입력값을 검증 없이 쿼리문에 직접 합치는 동적 쿼리는 'SQL 인젝션'의 원인이 됩니다. 공격자가 입력창에 SQL 문을 직접 삽입하여 DB를 조작할 수 있기 때문입니다. 이를 방어하기 위해 반드시 **인자화된 쿼리(Parameterized Query)**를 사용해야 합니다.
• 위험한 코드 (템플릿 리터럴 직접 사용)
• 안전한 코드 (인자 바인딩)
[시니어의 팁] 실무에서는 가급적 Sequelize 같은 ORM을 사용하는 것이 기본적으로 SQL 인젝션을 방어해 주어 안전합니다. 하지만 성능 등의 이유로 원시 쿼리(Raw Query)를 써야 할 때는 반드시 위 예시처럼 $1 지시어와 bind 속성을 사용하는 원칙을 지키세요.
--------------------------------------------------------------------------------
6. 결론: 좋은 코드의 기준은 '가독성'과 '안전'
우리가 조건문을 배우는 이유는 단순히 프로그램을 돌아가게 만들기 위해서가 아닙니다. 진정으로 스마트한 코드는 동료가 읽기 쉬운 가독성과 외부 공격으로부터 튼튼한 안전성을 동시에 갖춘 코드입니다.
오늘부터 조건문을 작성할 때 다음 두 가지만은 꼭 기억하세요.
1. 가드 클로즈를 사용하여 코드의 깊이(Nesting)를 줄이고 메인 로직을 선명하게 드러낼 것.
2. 사용자 입력값은 반드시 화이트리스트 기반으로 검증하고, DB 연동 시 인자화된 쿼리를 습관화할 것.
'Backend > Php' 카테고리의 다른 글
| PHP 반복문의 정석: for 문으로 규칙적인 작업 자동화하기 (0) | 2026.02.17 |
|---|---|
| 복잡한 조건문은 이제 그만! PHP switch-case로 깔끔하게 분기하기 (0) | 2026.02.17 |
| 데이터 꾸러미, PHP 배열(Array) 기초: 인덱스 배열과 연관 배열 (0) | 2026.02.17 |
| 산술부터 논리까지: PHP 연산자로 코드에 계산 능력 부여하기 (0) | 2026.02.17 |
| 문자열의 마술: PHP에서 큰따옴표와 작은따옴표의 결정적 차이 (0) | 2026.02.16 |
