[IT 칼럼] 보안 결함, 언제까지 '인력거'식으로 노가다 할 것인가?

 

1. 프로젝트 말기의 불청객, Veracode

금융권이나 이커머스 대형 프로젝트의 막바지, 오픈을 코앞에 둔 시점에 어김없이 찾아오는 불청객이 있다. 바로 Veracode 정적 분석 결과 보고서다. 수천 건의 Log Forging, SQL Injection 결함이 찍힌 보고서를 마주하면 프로젝트 룸은 순식간에 활력을 잃고 '수정 노가다'의 늪으로 빠져든다.

하지만 생각해보자. 수만 라인의 코드를 일일이 뒤져가며 replace()를 박는 것이 과연 17년 차 AA가 주도하는 프로젝트의 모습이어야 할까? 진정한 아키텍처의 가치는 개별 코드를 고치는 '수선공'이 아니라, 결함이 발생할 수 없는 '시스템'을 구축하는 데 있다.

2. 설계를 통한 근본적 해결: 3대 핵심 결함 대응

① Log Forging: 로그의 오염을 입구에서 차단하라

로그에 외부 입력값이 섞여 들어오는 건 보안상 치명적이다. 그렇다고 모든 log.info() 호출부에 이스케이프 로직을 태우는 건 미련한 짓이다.

• Expert's Insight: Logback의 MessageConverter를 활용하라. 로그가 출력되는 최종 단계에서 개행 문자(\r, \n)를 일괄 필터링하는 컨버터를 구현하고 이를 logback-spring.xml에 전역 설정으로 박아넣는 것이다. 이렇게 하면 개발자는 평소처럼 로그를 찍어도, 시스템이 보안 가이드라인을 완벽히 준수하게 된다.

② SQL Injection: MyBatis Interceptor라는 안전장치

성능이나 동적 테이블 참조를 위해 ${}를 써야만 하는 상황은 분명 존재한다. 하지만 이는 곧 보안의 구멍이다.

• Expert's Insight: MyBatis Interceptor를 통해 쿼리 실행 직전의 파라미터를 가로채라. 특정 화이트리스트 검증을 거치지 않은 ${} 사용을 엔진 레벨에서 감지하고 차단하는 구조다. 개발자의 부주의가 보안 사고로 이어지지 않도록 아키텍처가 '가드레일' 역할을 해줘야 한다.

③ Path Traversal: 파일 시스템 접근의 표준화

../와 같은 경로 조작은 시스템 권한 탈취로 이어질 수 있는 위험한 결함이다.

• Expert's Insight: 파일 입출력을 개별 비즈니스 로직에 맡기지 마라. 별도의 File Service Layer를 강제하고, 내부적으로 java.nio.file.Path.normalize()를 통해 경로를 정규화해야 한다. 사전에 정의된 Base Directory를 벗어나는 모든 접근을 원천 차단하는 공통 유틸리티는 AA가 제공해야 할 최소한의 인프라다.

3. '규제'가 아닌 '구조'로 말하라

이러한 설계 중심의 접근은 두 가지 확실한 보상을 준다. 첫째, 신입부터 베테랑까지 누가 코드를 짜든 일관된 보안 수준이 유지된다. 둘째, 수천 건의 결함을 단 몇 줄의 설정과 공통 클래스로 해결함으로써 얻는 압도적인 리소스 절감이다.

4. 결론: AA의 본질은 '도구'를 설계하는 것이다

보안 가이드라인 문서를 백날 배포하고 교육해봤자 현장에서는 지켜지지 않는다. 개발자가 **"의식하지 않아도 저절로 지켜질 수밖에 없는 구조(Guardrail)"**를 만드는 것, 그것이 프로젝트를 성공으로 이끄는 17년 차 아키텍트의 진짜 실력이다.

#AA #보안 #Veracode #Java #Spring #아키텍처