운이 좋게 되는 것이 옳은 것보다 낫다: 코드에 ‘겉보기에 무의미한’ Catch-Alls가 필요한 이유

Source: Dev.to

소개

C# 백엔드, SQL 데이터베이스, JavaScript 프론트엔드 사이를 오가며 소프트웨어 엔지니어로 일한 모든 시간 동안 나는 부정할 수 없는 진실을 배웠다: 얼마나 많은 엣지 케이스를 계획하든, 사용자는 결국 당신을 놀라게 할 무언가를 할 것이다. 가장 견고한 아키텍처를 설계할 수는 있지만, 때때로 시스템을 구해주는 것은 잘 배치된 전역 예외 처리나 추가적인 null 체크일 뿐이다.

전역 예외 처리가 중요한 이유

그 상황을 기억한다: 동료가 PR 리뷰에서 “이 검사는 무슨 의미가 있나요? 여기서는 데이터가 절대 null이 될 수 없어요.”라고 지적한 정확한 검사. 당신은 그 검사가 필요 없다고 생각하고 PR을 승인했지만, 일주일 뒤에 사용자가 폼의 Step 3을 우회해 예상 모델 데이터의 절반이 누락된 상황을 발견하고 그 코드 한 줄이 대규모 충돌을 방지한다는 사실을 알게 된다.

“운은 준비된 자를 돕는다, 자기야.” – 에드나 모드

항상 누군가가 애플리케이션을 깨뜨릴 수 있는 터무니없는 각도를 모두 고려하려고 노력해야 한다. 사용자는 당신이 예상하지 못한 방식을 창의적으로 찾아낸다.

실제 사례

• 과도한 입력 – 사용자가 PlaceName 필드에 50자 주소를 붙여넣어 데이터베이스가 이를 조용히 잘라내고 실제 위치 정보를 잃어버린 경우.
• 검증 우회 – 사용자가 프론트엔드 검증 규칙을 무시하고 페이로드를 제출해 숨겨진 버그를 드러내는 경우.

AI는 “행복한 경로”만 가정한다

Copilot이든 로컬 Ollama 모델이든 다른 어시스턴트이든, AI는 당신이 요청한 대로 정확히 제공하는 데는 뛰어나다. “행복한 경로” 코드를 아름답게 작성하지만, 혼돈스러운 인간의 엣지 케이스는 거의 고려하지 않는다.

AI는 사용자가 규칙을 따를 것이라고 가정한다. 엔지니어로서 우리는 그들이 절대 따르지 않는다는 것을 안다. 데이터 처리나 API 로직을 AI에 의존한다면, 모델이 놓친 예측 불가능한 시나리오를 준비하는 책임은 당신에게 있다.

결론

시스템이 깨질 수 있는 방법은 무수히 많다. 우리 모두 코드와 로직에서 완벽히 “옳은” 사람이 되고 싶어도 100 % 정확할 수는 없다. 때때로 엔지니어링 직관이 필요하다. 추가 검증 단계, 중복 폴백, 혹은 겉보기에 의미 없어 보이는 전역 예외 처리를 추가하고 싶을 때, 그냥 해라. 지금은 불필요해 보일지 모르지만, 금요일 오후에 시스템을 구해줄 바로 그 요소가 될 수도 있다.