저는 지난 몇 달 동안 실제 Swift 및 Xcode 작업에 AI 코딩 에이전트(AI coding agents)를 투입하며 이들이 어디에서 무너지는지 지켜보았습니다. 단순히 "로그인 화면을 만들어줘"와 같은 데모 수준이 아닙니다. 빌드(build), 테스트 타겟(test target), 그리고 에이전트가 스스로 도달해야 하는 결승선이 있는 작업들을 대상으로 했습니다.

저를 놀라게 했던 부분부터 시작하겠습니다. 첫 번째 초안은 보통 괜찮습니다.

유능한 모델에 합리적인 Swift 작업을 맡기면, 첫 번째 패스(pass)에서 작성된 코드는 종종 정확하거나 그에 가깝습니다. 뷰(view)는 합리적이고, 타입(types)도 일치합니다. 만약 Swift를 작성하는 것 자체가 병목 현상(bottleneck)이라면, 이 도구들은 이미 완성되었을 것입니다.

특정 종류의 게시물들은 모델이 Swift를 작성할 수 없다고 주장하곤 합니다. 하지만 작성할 수 있습니다. 그들은 Swift를 잘 다루며 점점 더 나아지고 있습니다. 따라서 흥미로운 질문은 그 첫 번째 초안 이후, 즉 "완성된 것처럼 보이는 것"과 "실제로 올바른 것" 사이의 간극에서 어떤 일이 발생하는가 하는 점입니다.

빌드 루프(build-loop)에 대한 불만 중 목소리가 큰 버전도 한 가지 잘못 알고 있는 것이 있습니다. 현대적인 하네스(harness) 환경에서는 순수하게 "컴파일되지 않는" 루프는 대부분 처리됩니다. Claude Code와 Codex는 빌드가 빨간색(red, 오류 상태)인 동안에는 자신의 작업물을 수용하지 않습니다. 이들은 컴파일 에러(compile error)를 조용히 처리하며 빌드가 되는 결과물을 전달합니다. 만약 당신의 에이전트가 여전히 빌드 오류(red builds)를 전달한다면, 그것은 이미 알려진 해결책이 있는 하네스(harness)의 문제입니다.

살아남는 실패 사례들은 컴파일러가 볼 수 없는 것들입니다. 바로 그것들이 저의 시간을 낭비하게 만드는 것들입니다.

빌드는 잘 되지만 제가 요청한 것이 아닌 경우. 현재 가장 흔한 사례입니다. 코드는 컴파일되고, 에이전트가 작성한 테스트는 통과하지만, 동작이 제가 실제로 원했던 것과 미묘하게 또는 완전히 다릅니다. 에이전트는 의도(intent)를 확인할 방법이 없습니다. 테스트 통과(Green)가 곧 정답(correct)은 아니며, 에이전트가 쫓을 줄 아는 유일한 지표는 오직 테스트 통과(Green)뿐입니다.

컴파일은 되지만 경합(race)이 발생합니다. 동시성(Concurrency)은 이 문제의 날카로운 버전입니다. Swift의 컴파일러는 많은 것을 잡아내지만, 빌드는 깨끗하게 성공하면서 특정 타이밍에서만 나타나는 데이터 경합(data race)을 가진 코드가 여전히 발생할 수 있습니다. 에이전트는 빌드 성공(Green)을 성공으로 읽고 다음 단계로 넘어갑니다. 실패가 표면화되었을 때, 에이전트는 대개 한 줄짜리 수정보다는 소규모 재설계(redesign)를 시도하려 하며, 이 재설계야말로 에이전트가 도달하지 못하는 바로 그 방식입니다.

한 가지를 고치면 조용히 다른 것을 망가뜨리고, 다시 반복합니다. 이것은 제 오후 시간을 가장 많이 잡아먹는 문제입니다. 에이전트가 실제 수정 사항을 적용하면 다른 문제에 부딪히고, 두 번째 문제를 쫓는 동안 첫 번째 수정을 되돌려 버립니다. 몇 차례의 턴이 지나면 이미 해결했던 상태로 되돌아갑니다. 충분히 오래 실행해 두면, 두 가지 고장 난 상태 사이를 진동하는 것을 목격하곤 합니다. A가 B를 망가뜨리면, B를 위한 수정이 다시 A를 불러오는 식의 무한 반복입니다. 에이전트에게는 "이걸 시도해 봤는데 안 됐어"라는 지속적인 감각이 없습니다.

제가 배포하지 않을 코드를 작성합니다. 컴파일되고 실행은 되지만, 여전히 형태가 잘못되어 있습니다. 프레임워크와 충돌하는 패턴, 앱의 나머지 부분이 어떻게 구축되었는지 무시하는 구조를 만듭니다. 한 번 쓰고 버릴 용도라면 괜찮습니다. 하지만 제가 계속 유지하며 살아가야 하는 코드라면 괜찮지 않습니다.

이 중 어느 것도 언어의 문제는 아닙니다. 모델은 Swift를 알고 있습니다. 모델에게 부족한 것은 컴파일러가 알려줄 수 없는 모든 것입니다. 즉, 결과가 제가 의도한 것과 일치하는지, 런타임(runtime)에서 잘 버티는지, 그리고 숙련된 개발자가 유지할 만한 종류의 코드인지에 대한 부분입니다.

마지막의 그 간극이 진짜 비용이 발생하는 지점이며, 이는 사람들이 가장 먼저 고려하는 비용이 아닙니다. 대화는 보통 토큰 비용(token cost)에 대해 이루어집니다. 하지만 제가 실제로 느끼는 것은 주의력(attention)입니다. 좋은 Swift 코드를 작성하지만, 에이전트가 헛돌지 않도록 몇 번의 턴마다 제가 개입하여 지켜봐야 한다면, 그것은 저의 업무를 줄여준 것이 아닙니다. 그것은 코딩을 감독(supervising)으로 전환했을 뿐입니다. 어떤 날은 그 정도의 거래도 괜찮습니다. 하지만 많은 날, 그것은 제가 옆에 앉아 있을 때만 비로소 제대로 작동한다는 것을 의미합니다.

저는 이 문제를 아직 해결하지 못했습니다. 제가 말할 수 있는 것은, 실패 모드 (failure modes)가 이름을 붙일 수 있을 정도로 충분히 일관적이라는 것이며, 이는 제가 이를 측정하기 시작했을 때 예상했던 것보다 더 나은 결과입니다. 제가 이룬 진전은 더 똑똑한 모델로 교체하는 것보다, 모델 주변의 루프 (loop), 즉 모델이 무엇을 확인하고 턴 (turns) 사이에 무엇을 기억하는지를 변경하는 것에서 비롯되었습니다.

그래서 이것이 여러분의 경험과 일치하는지 알고 싶습니다. 실제 Apple 업무에 에이전트 (agents)를 실행하고 있는 분들에게 묻고 싶습니다. 빌드 (build) 과정이 대부분 스스로 처리되는 현 상황에서, 실제로 어디에서 문제가 발생하나요? 의도 불일치 (intent mismatches), 컴파일은 되지만 발생하는 레이스 컨디션 (races), 아니면 제가 아직 관찰하지 못하고 있는 다른 무엇인가요?