개발자 머피의 법칙: 백엔드 방어 체크리스트

머피의 법칙과 설계

머피의 법칙은 「잘못될 수 있는 것은 결국 잘못된다」는 경험칙이다. 서비스가 오래 돌고 사용자와 개발자가 많아질수록 「설마」가 일어날 확률은 1에 가까워진다.

설계에 쓰는 기준은 단순하다.

사고가 났을 때의 영향	대응
감당할 수 없다 (돈, 개인정보, 데이터 손실)	이미 일어난 것으로 보고 지금 막는다
감당할 수 있다	서비스 성장 단계에 맞춰 차례로 대비한다

아래는 백엔드에서 반복해서 일어나는 사고를 영역별로 묶은 체크리스트다.

1. 입력은 믿지 않는다

함정	막는 법
UI에 안내 문구가 있으니 이상한 값은 안 온다	클라이언트 검증은 편의용이다. 서버에서 다시 검증한다 (할인율과 할인 금액 혼동, 존재하지 않는 날짜)
클라이언트가 보낸 금액·가격	폼 값은 쉽게 조작된다. 서버에서 다시 계산하고, 외부 결제 시스템에 넘기는 값도 검증한다
동적 쿼리의 조건이 전부 빠짐	조건이 비면 전체 조회가 된다. 배타적 조건 중 하나는 반드시 있는지 서버에서 확인한다
내부 API니까 이상하게 부르지 않는다	내부 개발자도 실수한다. pageSize, 날짜 범위 같은 입력 상한을 둔다

2. 인증과 권한은 따로 본다

함정	막는 법
로그인했으면 됐다	인증(누구인가)과 인가(이 자원에 접근할 수 있나)는 다른 검사다. 본인 데이터인지 매번 확인한다
로그인 실패 횟수를 쿠키에 저장	클라이언트가 바꿀 수 있는 곳에 둔 제한은 무력하다. 서버에서 세고, 캡차·알림도 서버 쪽에서 건다
현금으로 바꿀 수 있는 포인트·상품권	우회 현금화가 되면 결제 수단과 같다. 결제 수준의 추가 인증을 건다

3. 운영 자원에 사람이 닿지 않게 한다

함정	막는 법
ORM의 자동 스키마 생성(ddl-auto 등)이 운영에서 켜짐	운영 DB 계정에서 DDL 권한을 뺀다. 스키마 변경은 마이그레이션 도구로만 한다
로컬 환경이 운영 메시지 큐에 붙음	MQ도 저장소다. 로컬에서 운영 자원으로 가는 경로를 막는다
프로필을 잘못 골라 운영 API를 직접 호출	반복되는 운영 작업은 인증·권한이 걸린 관리자 도구로 옮긴다
사내망이니 서버를 열어 둠	기본은 비공개. 필요한 권한만 주고, 외부 노출은 프록시로 한정한다

4. 데이터 구조는 미래를 고려한다

함정	막는 법
순차 PK를 32비트 정수로	한계에 닿으면 연동된 모든 시스템을 고쳐야 한다. 64비트(Long)로 시작하고 외부 클라이언트의 타입도 확인한다
원격 캐시에 객체를 넣고 필드를 바꿈	배포 중에는 신·구 버전이 섞여 캐시를 읽는다. 캐시 구조 변경은 DB 컬럼 변경처럼 신중히 한다. 캐시는 성능 테스트로 이득을 확인한 뒤 쓴다

5. 운영 신호를 믿을 수 있게 만든다

함정	막는 법
배치가 실패하면 알림이 온다	배치가 아예 실행되지 않으면 내부 알림도 울리지 않는다. 실행 여부를 외부에서 감시한다
에러가 나면 메일을 보낸다	에러가 폭주하면 메일 서버와 네트워크가 같이 죽는다. 로그 전송은 별도 수집기·비동기 appender로 분리하고 알림 빈도를 제한한다
모든 알림을 한 채널에	중요한 알림이 묻힌다. 중요도로 채널을 나누고, 중요 알림은 응답 확인을 필수로 한다

6. 실패를 전제로 한다

• 롤백할 수 있게 배포한다. 웹 애플리케이션뿐 아니라 배치도 되돌릴 수 있어야 한다.
• 단일 장애점(SPOF)을 없앤다. 서버는 언제든 죽는다.
• 외부 시스템 장애를 가정한다. 호출하는 외부 API가 느려지거나 멈출 때 서킷 브레이커·타임아웃으로 전파를 끊는다.

정리

• 클라이언트·내부 개발자·운영자 모두 실수한다. 검증과 권한은 서버와 시스템이 맡는다.
• 인증과 인가는 별개의 검사다.
• 운영 자원은 사람 손이 직접 닿지 않게 권한과 도구로 막는다.
• 「안 돌았다」는 신호는 안에서 나오지 않는다. 외부에서 감시한다.

감당할 수 없는 사고는 확률이 낮아도 이미 일어난 일로 취급한다.

관련 노트: 안전한 시스템 설계, 복원력 패턴, 고가용성과 이중화, 장애 대응과 포스트모템, 개발자가 빠지는 함정 모음