[심층분석] "혹시 모르니까" — 방어적 프로그래밍 문화의 빛과 그림자

도입: 개발자라면 누구나 공감하는 그 한마디

"혹시 모르니까(Just in case)." 개발자라면 이 말을 하루에도 수십 번 되뇌인다. 삭제해도 될 코드를 주석 처리만 해두고, 발생할 리 없는 예외를 잡기 위해 try-catch를 감싸고, 이미 deprecated된 API 호환 코드를 "혹시 모르니까" 남겨둔다. 최근 Reddit 프로그래밍 커뮤니티에서 이 주제를 다룬 게시물이 2,200점 이상의 공감을 얻으며 화제가 됐다. 단순한 밈처럼 보이지만, 그 안에는 소프트웨어 엔지니어링의 근본적인 딜레마가 담겨 있다.

기술 분석: 방어적 프로그래밍이란 무엇인가

방어적 프로그래밍(Defensive Programming)은 예상치 못한 입력이나 상태에 대비하여 코드를 작성하는 기법이다. 핵심 패턴들을 살펴보면:

• Null/Undefined 검사: 모든 변수 참조 전에 존재 여부를 확인
• Try-Catch 남용: 비즈니스 로직 전체를 예외 처리로 감싸기
• 주석 처리된 코드 보존: git이 있음에도 "혹시 모르니까" 옛 코드를 주석으로 남기기
• 과도한 타입 가드: TypeScript에서 런타임에 불가능한 타입까지 체크
• Dead Code 유지: 호출되지 않는 함수나 사용되지 않는 import를 삭제하지 않기

이러한 패턴이 쌓이면 코드베이스의 신호 대 잡음비(Signal-to-Noise Ratio)가 급격히 떨어진다. 실제로 중요한 비즈니스 로직이 방어 코드 사이에 묻혀 가독성이 저하되고, 새로운 팀원의 온보딩 시간이 늘어나며, 리팩터링이 점점 어려워진다.

반면 적절한 방어적 프로그래밍은 필수적이다. 시스템 경계(System Boundary) — 사용자 입력, 외부 API 응답, 파일 I/O 등 — 에서는 엄격한 검증이 프로덕션 장애를 예방하는 핵심 방어선이 된다.

업계 맥락: "혹시 모르니까" vs. YAGNI

이 논쟁은 소프트웨어 공학의 오래된 원칙 충돌과 맞닿아 있다.

| 원칙 | 입장 | 대표 진영 |
|------|------|-----------|
| 방어적 프로그래밍 | 모든 가능성에 대비하라 | 항공·의료·금융 시스템 |
| YAGNI (You Aren't Gonna Need It) | 필요할 때 만들어라 | 애자일·XP 진영 |
| Fail Fast | 문제를 숨기지 말고 즉시 드러내라 | Erlang/Elixir 커뮤니티 |

Rust의 Option/Result 타입 시스템이나 Go의 명시적 에러 반환은 컴파일 타임에 방어를 강제하는 접근이다. "혹시 모르니까" 런타임에 코드를 덧대는 것이 아니라, 타입 시스템이 빈틈을 원천 차단하는 방식이다. 최근 TypeScript의 strict mode 채택률 증가, Kotlin의 null safety 설계 등도 같은 흐름이다.

한편 AI 코드 어시스턴트(Copilot, Cursor 등)가 생성하는 코드에서도 과도한 방어 패턴이 빈번하게 관찰된다. AI가 "안전한" 코드를 지향하다 보니, 불필요한 null 체크와 try-catch가 자동 생성되는 것이다. 이는 새로운 형태의 기술 부채로 부상하고 있다.

한국 개발자에게 미치는 영향

한국 개발 현장에서 이 문제는 특히 두드러진다.

• 빠른 개발 사이클: 스타트업 중심의 "빨리빨리" 문화에서 "혹시 모르니까" 코드는 일단 넣고 보는 경향이 강하다
• 코드 리뷰 문화: "왜 이 방어 코드가 필요한가?"라는 질문이 리뷰에서 자주 등장하지만, "안전하니까"라는 답변 앞에서 논의가 멈추는 경우가 많다
• 레거시 시스템: 10년 이상 운영되는 금융·공공 시스템에서 "혹시 모르니까" 남겨진 코드가 유지보수의 최대 장벽이 되고 있다

1. 시스템 경계에서는 철저하게 검증하되, 내부 코드 간 호출에서는 타입 시스템을 신뢰하라
2. 주석 처리 대신 Git 히스토리를 활용하라 — git log, git blame이 당신의 "혹시 모르니까"다
3. 방어 코드를 추가할 때는 반드시 "어떤 시나리오에서 이게 실행되는가"를 주석으로 명시하라
4. AI가 생성한 코드의 불필요한 방어 패턴을 식별하고 정리하는 습관을 들여라

마무리

"혹시 모르니까"는 개발자의 본능이지만, 무분별한 방어는 오히려 코드의 명확성을 해치고 진짜 위험을 가린다. 좋은 방어적 프로그래밍은 "모든 곳에 그물을 치는 것"이 아니라, "정확히 어디서 물이 새는지 아는 것"이다. 타입 시스템, 테스트, 그리고 코드 리뷰가 "혹시 모르니까"를 대체할 수 있는 더 나은 도구다.

💬 토론 질문: 여러분의 팀에서 "혹시 모르니까" 남겨둔 코드가 나중에 실제로 문제를 일으킨 경험이 있나요? 반대로 "혹시 모르니까" 넣어둔 방어 코드가 장애를 막아준 경험은요?