질문에 대한 답변.

이 메커니즘의 역사는 Swift 5.0과 SE-0228까지 거슬러 올라가며, 간단한 문법 설탕에서 강력하고 확장 가능한 프로토콜 지향 시스템으로 문자열 보간을 재구상했습니다. 이러한 재설계 이전에는 보간이 제한적이고 효율성이 떨어졌습니다. 새로운 아키텍처는 Swift를 런타임 형식 지정자와 가변 인자에 의존하는 C 스타일의 printf 함수에서 벗어나게 하여, 형식 불일치 충돌 및 보안 취약점의 전체 클래스를 제거했습니다.

문제는 C의 가변 함수의 근본적인 안전하지 않음에 있습니다. 이 함수에서는 "%s %d"와 같은 형식 문자열이 런타임에 구문 분석되고 인수와 매칭되지만 컴파일 타임 검증이 이루어지지 않습니다. Swift는 컴파일 시에 형식 정확성을 보장하고, 사용자 정의 타입을 자연스럽게 지원하며, 런타임 구문 분석이나 박스를 사용하지 않으면서 읽기 쉬운 구문을 유지하는 값을 문자열에 내장하는 메커니즘이 필요했습니다.

해결책은 ExpressibleByStringInterpolation 프로토콜과 StringInterpolationProtocol을 함께 사용하는 것입니다. 컴파일러가 "(value)"와 같은 보간 구문을 만나면, 이는 전용 버퍼 객체에 대한 일련의 메서드 호출로 해석됩니다. 컴파일러는 먼저 init(literalCapacity:interpolationCount:)를 호출하여 저장소를 미리 할당하고, static 텍스트 세그먼트에 대해 appendLiteral(:)를 호출하며, 중요하게도 각 보간된 값에 대해 타입 특화된 appendInterpolation 오버로드(예: appendInterpolation(: Int) 또는 appendInterpolation(_: CustomStringConvertible))를 호출합니다. 이러한 것은 모두 컴파일 타임에 해결되는 프로토콜 메서드 호출이기 때문에, 타입 검사기는 모든 세그먼트를 검증하여 불일치를 방지합니다. 사용자 정의 타입은 StringInterpolationProtocol에 따를 수 있어 SQL 매개변수화와 같은 도메인별 검증을 이러한 append 메소드 내에서 직접 구현할 수 있어, 문자열 생성 중 주입 공격이 구조적으로 불가능하다는 것을 보장합니다.

struct SQLQuery: ExpressibleByStringInterpolation {
    var sql: String = ""
    var parameters: [String] = []
    
    init(stringLiteral value: String) {
        self.sql = value
    }
    
    init(stringInterpolation: SQLInterpolation) {
        self.sql = stringInterpolation.sql
        self.parameters = stringInterpolation.parameters
    }
}

struct SQLInterpolation: StringInterpolationProtocol {
    var sql = ""
    var parameters: [String] = []
    
    init(literalCapacity: Int, interpolationCount: Int) {
        self.sql.reserveCapacity(literalCapacity)
        self.parameters.reserveCapacity(interpolationCount)
    }
    
    mutating func appendLiteral(_ literal: String) {
        sql += literal
    }
    
    mutating func appendInterpolation<T: CustomStringConvertible>(_ parameter: T) {
        sql += "?"
        parameters.append(String(describing: parameter))
    }
}

let maliciousInput = "'; DROP TABLE users; --"
let query: SQLQuery = "SELECT * FROM users WHERE id = \(maliciousInput)"
// query.sql == "SELECT * FROM users WHERE id = ?"
// query.parameters == ["'; DROP TABLE users; --"]

실생활 상황

개발 팀은 HIPAA 준수를 위해 모든 데이터베이스 쿼리에 대한 포괄적인 감사 로그를 요구하는 의료 기록 애플리케이션을 구축하고 있었습니다. 중요한 요구 사항은 사용자 제공 검색 매개변수를 포함하여 실행된 대로 쿼리를 정확하게 로그하는 것이었으며, SQL 주입 취약점을 절대적으로 방지해야 했습니다. 초기 구현은 로그를 작성하기 위해 간단한 문자열 연결을 사용했으며, 이는 보안 검토 병목 현상을 일으키고 모든 로그 문을 수동으로 확인해야 했습니다.

첫 번째로 고려한 솔루션은 런타임 검증이 있는 수동 문자열 연결이었습니다. 이 접근 방식은 단일 인용 부호를 이스케이프하고 로그를 기록하기 전에 의심스러운 패턴을 감지하기 위해 정규 표현식을 사용하는 유틸리티 함수를 만드는 것을 포함했습니다. 장점은 아키텍처 변경 없이 즉각적인 구현과 기존 코드와의 호환성이었습니다. 단점은 치명적이었습니다: 검증 로직은 오류가 발생하기 쉬웠고, 예기치 않은 유니코드 시퀀스로 우회하기 쉬웠으며, 측정 가능한 런타임 오버헤드를 추가했으며, 개발자가 매번 유틸리티를 호출해야 한다는 점에서 인적 요인 보안 위험을 초래했습니다.

두 번째 솔루션은 애플리케이션 코드에서 모든 SQL 생성을 추상화하는 대규모 ORM 프레임워크를 채택하는 것이었습니다. 장점은 포괄적인 안전 보장과 내장된 감사 기능이 있었습니다. 단점은 기존의 원시 SQL 쿼리에 대한 대규모 리팩토링, 정밀 SQL 최적화가 필요한 복잡한 분석 쿼리의 성능 저하, 특수한 ORM 구문에 대한 가파른 학습 곡선, 전체 ORM 도입 없이 감사 로그라는 특정 요구 사항에 과도한 설계를 초래했습니다.

세 번째 솔루션은 SQL 안전 감사 문자열 타입을 생성하기 위해 사용자 정의 ExpressibleByStringInterpolation 준수를 구현했습니다. 이 접근 방식은 모든 보간된 값을 자동으로 매개변수화하는 사용자 정의 보간 버퍼가 있는 SQLAuditEntry 타입을 정의하여 문자열 생성 단계에서 SQL 템플릿과 데이터를 분리했습니다. 이 솔루션의 장점은 안전성의 컴파일 타임 강제 집행(비위생 값이 우연히 연결되는 것이 불가능), 제로 런타임 파싱 오버헤드, 개발자가 익숙한 표준 Swift 문자열과 동일한 구문, 그리고 자동적 관심사의 분리입니다. 단점은 성능을 위해 Swift의 보간 프로토콜을 이해하고 버퍼의 용량 예약을 신중하게 구현하는 데 초기 투자가 필요하다는 점입니다.

팀은 세 번째 솔루션을 선택했습니다. 이로 인해 개발자들이 원하는 정확한 구문을 제공하면서 Swift의 타입 시스템을 통해 컴파일 타임에 안전성을 보장할 수 있었습니다. 사용자 정의 보간을 통해 모든 연결 지점의 코드 검토 없이 매개변수를 자동으로 강제할 수 있었습니다.

그 결과 감사 로그 레이어에서 SQL 주입 취약점이 완전히 제거되었습니다. 코드 검토 속도는 검토자가 문자열 연결 안전성을 수동으로 확인할 필요가 없게 됨에 따라 40% 증가했습니다. 보간 구문은 다른 언어로 이전하는 개발자에게 즉시 가독성이 있었지만, 이제는 엄격한 보안 감사 요구 사항을 충족하는 내재적이고 컴파일러 검증 안전 보장이 포함되어 있었습니다.

후보자들이 종종 놓치는 점

컴파일러는 비속어 세그먼트와 보간 값을 해제하는 과정에서 어떻게 구분하며, 버퍼 할당을 최적화하기 위해 어떤 특정 초기화 매개변수를 제공합니까?

후보자들은 컴파일러가 문자열 리터럴을 모든 보간 경계에서 분할하고 각 세그먼트에 대해 별도의 메서드 호출을 생성한다는 점을 자주 간과합니다. "Hello (name)!"와 같은 표현에 대해 컴파일러는 appendLiteral("Hello "), appendInterpolation(name), appendLiteral("!")라는 세 가지 호출을 생성합니다. 많은 이들은 init(literalCapacity:interpolationCount:)가 모든 리터럴 세그먼트의 총 바이트 수와 정확한 보간 수를 받으며, 이를 통해 버퍼가 정밀 용량을 예약하고 추가 작업 중의 기하급수적 성장 재할당을 피할 수 있도록 한다는 것을 놓치고 있습니다. 또한 빈 문자열에 대해서도 appendLiteral이 호출되어 가장자리를 일관되게 처리한다는 점을 종종 인식하지 못합니다.

** 왜 사용자 정의 문자열 보간이 추가적인 타입 시스템 지원 없이 SQL 식별자 (테이블 이름, 열 이름)에서 자동으로 주입 공격을 방지할 수 없으며, 이 한계를 해결하는 아키텍처 패턴은 무엇입니까?**

appendInterpolation은 값을 안전하게 처리하지만 appendLiteral로 전달된 리터럴 세그먼트는 검증 없이 직접 삽입되며, 보간 메커니즘은 SQL 값(매개변수화되어야 함)과 SQL 식별자(테이블 이름, 열 이름)가 쿼리 인수로서 매개변수화될 수 없다는 것을 구별할 수 없습니다. 후보자들은 보간이 구문적 위치에 기반하여 리터럴 또는 값으로 둘 다를 인식할 뿐, 의미론적 SQL 역할에 따라 구별하지 않는다는 점을 놓칩니다. 안전하게 식별자를 처리하기 위해 개발자는 별도의 래퍼 타입(예: struct TableName { let name: String })을 생성해야 하며, 그들만의 appendInterpolation 오버로드를 사용하여 엄격한 화이트리스트나 데이터베이스 스키마에 대한 검증을 수행하고, Swift의 타입 시스템을 사용하여 컴파일 타임에 의미론적으로 다른 문자열 범주를 구별해야 합니다.

** 복잡한 문자열을 밀집 루프에서 구성할 때 DefaultStringInterpolation 버퍼에서 발생하는 특정 성능 영향은 무엇이며, 초기화 중 제공된 용량 힌트가 String 타입의 기본 저장 최적화와 어떻게 상호 작용합니까?**

DefaultStringInterpolation은 내부 버퍼로 String을 사용합니다. 이 버퍼는 작은 문자열 최적화(SSO)를 위한 인라인 저장소를 사용하지만, 더 큰 콘텐츠에 대해 힙 할당을 할 수 있습니다. 후보자들은 init(literalCapacity:interpolationCount:)가 정확한 용량 요구 사항을 제공하지만, DefaultStringInterpolation은 여전히 작은 문자열 인라인 버퍼 크기(일반적으로 64비트 시스템에서 15바이트)를 초과할 경우 여러 버퍼 재할당을 촉발할 수 있다는 점을 놓칩니다. 확정적인 할당이 필요한 높은 성능 시나리오의 경우, 사용자 정의 보간 유형은 UnsafeMutablePointer 또는 String.UnicodeScalarView를 수동 용량 관리와 함께 활용해야 하며, 표준 라이브러리의 기본 구현은 절대적인 할당 제어보다 일반 케이스의 유연성을 우선시합니다.