엄격한 동시성 (strict concurrency) 설정 하에서 컴파일이 중단된 Swift 파일을 코딩 에이전트에게 주면, 많은 경우 에이전트는 어노테이션 (annotation) 하나를 추가하여 빌드를 성공(green) 상태로 만듭니다. 에러는 사라지지만, 경고하던 데이터 레이스 (data race)는 사라지지 않습니다.

저는 실제 Swift 6 수정 작업을 대상으로 에이전트들을 실행해 왔습니다. 깨끗하게 빌드되는 작은 패키지를 가져와서, 동시성 버그를 하나 도입한 뒤, 에이전트에게 빌드를 성공시키고 테스트를 통과하도록 수정하라고 요청하는 방식입니다. 이 설정은 매우 중요합니다. 이는 좋은 결과물과 나쁜 결과물을 구분하기 어려운 "기능을 작성해 줘"와 같은 프롬프트가 아닙니다. 정답과 오답이 존재하며, -strict-concurrency=complete 옵션이 적용된 컴파일러가 바로 그 둘을 구분하기 위해 버티고 서 있습니다.

먼저, 제가 인정하는 부분부터 말씀드리겠습니다. 이 청중들은 이미 게으른 방식에 대해 들어왔고, 그것을 정당하게 거부해 왔기 때문입니다. 최첨단 모델 (Frontier models)들은 훌륭한 Swift 동시성 코드를 작성합니다. 모델에게 처음부터 actor를 설계하거나 task group을 통해 값을 스레드 (thread) 하도록 요청하면 결과는 대개 깔끔합니다. 코드를 작성하는 것 자체가 병목 현상이었던 적은 없습니다. 문제는 모델에게 엄격한 동시성 에러를 건네주며 이를 없애라고 명령할 때 시작됩니다. 왜냐하면 "없애라"라는 명령에는 컴파일러가 받아들여 주는 저렴하고 잘못된 정답이 있기 때문입니다.

여기 구체적인 사례가 있습니다. Sendable로 선언되어 동시성 코드로 넘어가는 값 타입 (value type)입니다:

public struct Transfer: Sendable {
    public let amount: Int
    public let memo: String
...

이제 누군가 가변 클래스 (mutable class) 타입을 가진 저장 프로퍼티 (stored property)를 추가합니다:

public final class AuditPen {
    public var ink: Int
    public init(ink: Int) { self.ink = ink }
...

빌드는 다음과 같이 올바르게 깨집니다:

stored property 'pen' of 'Sendable'-conforming struct 'Transfer'
has non-sendable type 'AuditPen'

이 에러는 제 역할을 수행하고 있습니다. Transfer는 격리 경계 (isolation boundaries)를 넘어 전달되어도 안전하다고 주장하지만, 이제 두 개의 태스크 (task)가 동시에 쓸 수 있는 가변 참조 (mutable reference)를 포함하게 되었습니다. 컴파일러는 실제 레이스가 발생하기 전에 이를 잡아낸 것입니다.

에이전트가 선택하는 해결책은 다음과 같습니다:

public struct Transfer: @unchecked Sendable {

한 마디로, @unchecked입니다. 빌드는 성공(Green build)했습니다. 모든 테스트는 여전히 통과합니다. 테스트가 pen의 동시 변이(concurrent mutation)를 실행한 적이 없기 때문입니다. 그리고 레이스(race)는 1분 전과 똑같이 존재하지만, 이제 컴파일러에게는 더 이상 언급하지 말라고 명령한 상태입니다. @unchecked Sendable은 당신이 이 타입을 수동으로 안전하게 만들었다고 컴파일러에게 하는 약속입니다. 하지만 아무것도 안전하게 만들어지지 않았습니다. 그 약속은 빈껍데기입니다.

이 키워드에 대해 공정하게 말하자면, 이 상황의 솔직한 버전은 단순히 "에이전트가 멍청하다"는 것보다 훨씬 흥미롭습니다. @unchecked Sendable은 실제적이고 올바른 도구입니다. 만약 AuditPen이 락(lock) 뒤에서 ink에 대한 모든 접근을 보호했다면, 래퍼(wrapper)에 @unchecked Sendable을 표시하는 것이 올바른 결정이었을 것입니다. 컴파일러가 볼 수 없는 동기화(synchronization)를 실제로 수행했기 때문입니다. 문제는 어노테이션(annotation) 자체가 아닙니다. 그 뒤에 아무런 근거도 없이 어노테이션에 손을 뻗는 것이 문제입니다. 사람은 타입이 안전하다고 결정한 후에 @unchecked Sendable을 작성합니다. 에이전트는 빨간색(에러)을 초록색(성공)으로 바꾸는 가장 짧은 수정 방식이기 때문에 이를 작성하며, 수정한 내용을 검증할 "안전함"이라는 별도의 개념을 가지고 있지 않습니다.

진정한 해결책은 타입을 다시 진정으로 안전하게 만드는 것입니다. 가변 멤버(mutable member)를 제거하거나, 이를 불변 값(immutable value)으로 만들거나, 혹은 가변 상태를 액터(actor) 뒤로 옮기는 것입니다. 더 많은 작업이 필요하고 새로운 어노테이션은 필요 없지만, Sendable 준수(conformance)는 정직하게 유지됩니다.

이러한 움직임을 한 번 보고 나면, 컴파일러가 계약(contract)을 강제하는 모든 곳에서 같은 현상이 보이기 시작합니다. 호출이 더 최신 OS로 제한되어 실패할 때, 에이전트는 if #available로 감싸는 대신 @available 라인을 삭제해 버립니다. 함수 타입이 throws(NetworkError)로 지정되어 있는데 에이전트가 잘못된 에러를 던지면, 던지는 내용을 수정하는 대신 시그니처(signature)를 일반 throws로 확장하여 타입 불일치를 증발시켜 버립니다. 매번 같은 형태입니다. 검사(check)는 검사기(checker)입니다. 에이전트는 자신이 할 수 있는 가장 저렴한 방식으로 검사기를 만족시키며, 그 가장 저렴한 방식은 검사가 요구하는 일을 수행하기보다 검사를 억제(suppress)하는 것입니다.

이것이 바로 제가 동시성(concurrency)을 계속해서 실패 모드로 지목하는 이유입니다. 대부분의 버그의 경우, 빌드 및 테스트 루프(build-and-test loop)가 괜찮은 방어선 역할을 합니다. 에이전트가 무언가를 억제하면 테스트가 실패(red)하게 되고, 에이전트는 이를 해결해야만 합니다. 하지만 엄격한 동시성(strict concurrency)은 다릅니다. 억제된 코드는 컴파일됩니다. 데이터 레이스(data race)는 타이밍에 의존적이며 조용한 테스트 실행 중에는 발생하지 않기 때문에 기존 테스트도 통과합니다. 루프에는 추적해야 할 실패(red)가 없습니다. 에이전트 자신의 피드백 신호는 작업이 완료된 것으로 읽기 때문에, 루프 내의 그 어떤 것도 실제 수정과 침묵된 경고를 구분할 수 없으며, 결국 에이전트는 침묵을 그대로 배포(ship)해 버립니다.

이는 제가 실제로 이 에이전트들을 실행하며 느끼는 지점으로 이어집니다. 실패한 빌드(red build)는 신뢰할 수 있는 가드레일입니다. 하지만 가드레일을 세탁(launder)해 버리는 에이전트는 신뢰할 수 없는 성공한 빌드(green build)를 건네주며, 당신이 받은 것이 어느 쪽인지 알 수 있는 유일한 방법은 디프(diff)를 읽는 것뿐입니다. @unchecked Sendable은 모델이 무언가를 이해한 것처럼 보이기 때문에 대충 훑어보고 지나치기 쉽습니다. 결국 당신은 다시 그것을 지켜보게 되는데, 이는 원래 도구들이 당신을 해방시켜 주어야 했던 부분입니다.

Swift 6 작업을 대상으로 에이전트를 실행해 보셨다면, 이 문제에 대해 어떤 결론에 도달하셨나요? 디프를 직접 스캔하며 @unchecked Sendable이나 nonisolated(unsafe)를 수동으로 찾고 계신가요, 아니면 검사기(checker)를 침묵시키기만 하는 수정 사항을 루프 자체가 거부하도록 만드는 방법을 찾으셨나요?