Copilot이 당신의 AI 페어 프로그래머 (AI pair programmer)가 될 수 있을까?

어제 나의 친애하는 팀원이 흥미로운 질문을 던지며 나의 저녁을 망치기로 결심했습니다. Copilot을 진짜 페어 프로그래머 (pair programmer)로 설정할 수 있을까요? 번갈아 가며 대화하는 채팅창이 아니라, 옆자리에 앉은 사람처럼 당신이 코드를 작성하는 것을 지켜보며 실시간으로 반응하는 무언가 말입니다. 짧은 답변을 드리자면, 현재 설치할 수 있는 그 어떤 것으로도 불가능합니다.

페어링 (Pairing)의 의미

GitHub는 2021년에 Copilot을 "당신의 AI 페어 프로그래머 (AI pair programmer)"로 출시했으며, 동일한 발표에서 당신이 타이핑함에 따라 적응한다고 설명했습니다. 이 제품의 이름은 페어링 (pairing)에서 유래했고 자동 완성 (autocomplete)을 위해 구축되었으므로, 이름에 걸맞은 역할을 수행할 수 있는지 묻는 것은 타당합니다. 다음에 이어지는 내용 중 새로운 정보는 없지만, 이 글의 나머지 부분이 제품을 바로 이러한 조건들에 비추어 평가할 것이기에 명확히 짚고 넘어가고자 합니다.

페어 프로그래밍 (Pair programming)은 익스트림 프로그래밍 (Extreme Programming)의 핵심 관행이며, 그 정의는 Copilot보다 20년 앞서 있습니다. 일반적인 설명에 따르면 두 가지 역할이 주어집니다. 드라이버 (driver)는 타이핑을 하고, 네비게이터 (navigator)는 각 줄이 나타날 때마다 검토하며, 실수가 발생하기 전에 이를 감시하고, 설계에 대해 한 단계 앞서 생각합니다. 네비게이터는 턴이 넘어간 후가 아니라, 드라이버가 코드를 작성하는 도중에 작업합니다. 두 사람은 몇 분마다 역할을 교대하며, 두 사람 모두 내내 몰입 상태를 유지해야 합니다. 집중력을 잃은 네비게이터는 페어링 (pairing)을 하고 있는 것이 아닙니다.

네비게이터는 키보드에 손을 대지 않고 결과물을 만들어냅니다. 검토하고, 지켜보고, 앞서 생각하는 것, 그것이 바로 업무입니다. 이 원칙은 명확합니다. 페어링에 대한 가장 오래된 반론, 즉 한 사람의 타이핑에 두 명의 비용을 지불함으로써 비용이 두 배로 든다는 주장은 명명된 오해입니다. 프로그래밍은 타이핑이 아니기 때문입니다. 따라서 거의 아무것도 쓰지 않는 네비게이터는 자동화하기 더 어려운 절반입니다. 그 업무는 지속적인 실시간 감독이며, 잘못된 것이 나타나는 즉시 포착하여 비용이 발생하기 전에 말해주는 것이기 때문입니다.

해당 제품을 그 정의에 비추어 검토해 보십시오. 당신이 타이핑할 때 코드 라인을 완성해 주는 도구는 드라이버 (driver)의 역할을 더 빠르게 수행하고 있을 뿐입니다. 즉, 방금 정전(canon)이 말했듯 결코 핵심이 아닌 부분인 키보드 입력 채우기에 급급한 것입니다. 이 도구는 당신과 루프 (loop) 안에 함께 있지 않습니다. 그것은 자신의 마지막 제안에 반응하지 않으며, 당신의 입력을 기다리지도 않고, 네비게이터 (navigator)의 자리에 앉지도 않습니다. 당신이 작업하는 것을 지켜보며 말을 꺼내는 것이 아니라, 오직 요청받기를 기다릴 뿐입니다.

왜 안 되는가

외부에서 볼 때, 모델은 하나의 함수 (function)입니다. 당신이 전체 컨텍스트 (context)를 전달하면, 모델은 완전한 답변을 반환합니다. 유일한 스트림 (stream)은 출력이며, 이는 읽기 전용 (read-only)입니다. 당신은 토큰 (token)이 도착하는 것을 지켜보지만, 실행 중인 호출 (call)에 새로운 토큰을 밀어 넣을 수 있는 두 번째 파이프 (pipe)는 존재하지 않습니다. 새로운 무언가에 반응하려면, 당신은 멈추고 새로운 컨텍스트를 포함하여 다시 호출해야 합니다. 모든 반응은 신선한 전체 컨텍스트 요청입니다. "당신이 타이핑하는 동안"이라는 것은 없으며, 오직 다음 턴 (turn)만이 존재합니다. (대화를 "기억"하는 상태 유지형 API (Stateful APIs)도 이 점을 바꾸지는 못합니다. 그것들은 당신이 컨텍스트를 다시 보낼 필요가 없도록 저장해 줄 뿐이며, 모델은 여전히 한 번에 한 턴씩 전체를 소비합니다.)

음성 (Voice)은 그 장벽이 얼마나 견고한지를 보여주는 증거입니다. OpenAI의 Realtime API와 Google의 Gemini Live는 진짜처럼 느껴집니다. 이들은 실시간 양방향 연결을 통해 작동하며, 들으면서 동시에 말하고, 당신이 말을 끊는 즉시 멈춥니다. 하지만 그 이면을 들여다보면, 이들 역시 여전히 턴 기반 (turn-based)입니다. 중단 (interruption)은 모델이 당신의 문장 중간을 듣고 조정하는 것이 아닙니다. 그것은 서버가 당신의 음성을 감지하고, 진행 중인 응답을 취소하며, 당신이 아직 듣지 못한 오디오를 폐기하고, 당신이 말한 내용을 추가한 뒤, 새로운 턴을 시작하는 것입니다. 종종 이 과정이 충분히 빠르게 일어나기 때문에 당신은 정말로 자신의 말을 듣고 있다고 느끼게 됩니다. [1] 업계는 음성을 위해 전이중 (full-duplex) 파이프를 구축하는 데 막대한 돈을 썼지만, 그 결과로 얻은 것은 중간 반응 (mid-stream reaction)의 훌륭한 모사일 뿐, 그 자체는 아니었습니다. 말하자면 일종의 "낙관적 UI (optimistic UI) 방식의 AI"라고 할 수 있습니다.

진정으로 그 역할을 수행하는 아키텍처는 존재합니다. 그것은 풀 듀플렉스 (full duplex)라고 불리며, 가장 명확한 예시는 Moshi라는 연구용 음성 모델입니다. 이 모델은 사용자의 오디오와 자신의 오디오를 두 개의 병렬 스트림 (parallel streams)으로 실행하며, 멈춤이나 재시작 없이 매 순간 사용자의 입력에 따라 조건화 (conditioning)를 수행합니다. [2] 그리고 풀 듀플렉스 모델은 생성을 결코 멈추지 않기 때문에, 사용자가 말을 가로챌 때 모델을 멈추게 하는 것이 더 쉬운 게 아니라 오히려 더 어려운 것으로 보입니다. 이것이 아마도 Moshi가 프랑스의 한 AI 연구소에서 영웅적으로 탈출한 이후 아직 코드 에디터에 도입되지 못한 이유일 것입니다.

텍스트의 경우 풀 듀플렉스가 필요하지 않기 때문에 아무도 텍스트용 풀 듀플렉스를 구축하지 않은 것으로 보입니다. 음성은 자연스러운 끝이 없는 연속적인 신호이므로, 시스템은 사용자가 언제 끝냈는지를 추측해야 합니다. 반면 텍스트는 턴 경계 (turn boundary)가 내장되어 있습니다. 엔터 (Enter) 키를 누르면 턴이 종료됩니다.

에이전트 모드 (Agent mode)는 정말 아쉬운 수준 (near-miss)입니다. 에이전트 모드는 당신의 작업에 대해 추론하고 그에 반응하는데, 이는 자동 완성 (autocomplete) 기능에는 결여된 참여도 (engagement)입니다. 하지만 당신이 직접 턴 (turn)을 넘겨주어야 합니다. 즉, 프롬프트 (prompt)를 작성하여 전송하고, 작업 결과가 돌아올 때까지 기다려야 합니다. 다만, 트리거 (trigger)가 반드시 직접 타이핑하는 프롬프트일 필요는 없습니다. OpenCode는 플러그인을 통해 파일 저장이나 테스트 실패와 같은 외부 이벤트에 트리거를 연결할 수 있게 해줍니다. 이 플러그인은 스스로 턴을 주입 (inject)하여, 에이전트가 명시적인 요청 없이도 당신의 활동에 반응하게 만듭니다.

하네스 (harness)가 이를 수행할 수 있는지 여부는 브랜드가 아닌 메커니즘 (mechanism)의 문제입니다. 거의 모든 괜찮은 하네스에는 훅 (hooks)이 있지만, 훅은 세션 자체의 내부 라이프사이클 (lifecycle) 내에서만 작동합니다. 세션 외부로 확장하려면 턴을 주입할 수 있는 플러그인이나 확장 레이어 (extension layer)가 상단에 필요합니다. OpenCode는 플러그인을 통해 이를 지원하며, Copilot CLI는 별도의 확장 시스템을 통해 지원합니다. Claude Code는 예외입니다. 훅을 가지고는 있지만, 플러그인 레이어가 턴을 주입할 수 없기 때문에 유일한 외부 트리거는 SDK뿐이며, 이는 현재 세션을 이어가는 대신 새로운 세션을 시작합니다.

어떤 방식이든 이는 여전히 간헐적인 작업 (bursts)일 뿐, 완전 자동 (full-auto)은 아닙니다. 이는 마치 당신이 내비게이션을 맡고 AI가 운전석을 차지하는 것처럼 보일 수 있지만, 작업을 넘기고 돌아온 결과를 검토하는 것은 턴 경계 (turn boundary)를 가로지르는 교체일 뿐, 공유 루프 (shared loop)가 필요로 하는 유연한 자리 교대 (fluid trading of seats)가 아닙니다.

그럴 가치가 있는가

만약 당신이 에이전트 루프 (agent loop)를 더 긴밀하게 해킹하여, 매번 저장할 때가 아니라 모든 일시 정지 시점에 에이전트를 실행한다고 가정해 봅시다. 당신은 트리거가 발생할 때마다 전체 컨텍스트 (full context) 비용을 지불해야 하고, 매번 새로운 호출에 따른 지연 시간 (latency)을 감수해야 하며, 요청하지도 않은 제안들에 파묻히게 될 것입니다. 연속성을 매우 나쁘고 소란스럽게 흉내 내는 것에 불과할 것이며, 여전히 간헐적인 작업 (bursts)으로 남을 것입니다. 더 자주 실행한다고 해서 일련의 턴들이 연속적인 스트림 (continuous stream)으로 변하는 것은 아닙니다. 아쉬운 수준 (near-miss)과 진정한 페어 프로그래밍 (real pairing) 사이의 간극은 트리거의 박자 (cadence) 문제가 아니므로, 어떤 설정으로도 그 간극을 메울 수 없습니다.

진정한 페어 프로그래밍 (real pairing)이 코드 에디터에 도달하게 된다면, 그것은 Copilot의 설정 문제로 해결될 것이 아닙니다. 그것은 완전히 다른 종류의 모델이 될 것입니다. 그때까지 솔직한 답변은, 그는 저를 페어링 파트너로 삼아 갇혀 있을 수밖에 없다는 것입니다.

Notes

[1] 해당 중단이 이미 진행 중인 생성물을 모델이 편집하는 방식이 아니라 '취소 후 재시작 (cancel-and-restart)' 방식이라는 점은, 트랜스포머 추론 (transformer inference)이 작동하는 방식으로부터 도출된 추론이며, 확인된 내부 세부 사항은 아닙니다. OpenAI와 Google은 프로토콜 — 음성 활동 감지 (voice activity detection), 응답 취소 (response cancellation), 전사 절단 (transcript truncation) — 에 대해서는 문서화하고 있지만, 디코드 루프 (decode loop) 자체에 대해서는 명시하지 않았습니다. 따라서 "중단 후 재실행 (abort and re-run)"은 명시된 사실이 아니라 논리적인 결론입니다.

[2] Moshi. Défossez et al., Kyutai, 2024. 이 모델은 사용자 스트림과 자체 스트림을 12.5 Hz 프레임 속도(단계당 하나의 80ms 프레임)로 두 개의 자기회귀 토큰 스트림 (autoregressive token streams)으로서 공동으로 처리하며, 사용자 스트림에 대한 예측을 버리고 실제 들어오는 오디오로 대체하며, 이는 다음 단계를 위한 컨텍스트 (context)로 이어집니다. 이것이 진정한 디코드 중간 조건화 (mid-decode conditioning)입니다. 측정된 지연 시간 (latency)은 약 200ms이며, 이는 일반적인 인간의 대화 간격 범위 내에 있습니다. HuggingFace의 참조 구현 (reference implementation)은 단순화되어 있으며 실시간이 아닙니다. 라이브 전이중 (full-duplex) 동작은 Kyutai 자체 구현에 포함되어 있습니다. 이는 오픈 연구 모델 (open research model)입니다.

Sources

• 페어 프로그래밍 (Pair programming), 정의 및 드라이버/네비게이터 (driver/navigator) 역할: Agile Alliance 용어 사전 및 Williams와 Kessler의 "Pair Programming Illuminated" (2002).
  "이중 비용 (doubles cost)"에 대한 반론은 프로그래밍을 타이핑과 동일시하는 오해로 그곳에 기록되어 있습니다; 드라이버/네비게이터 프레임워크는 XP의 원래 관행 이후에 등장했으며 보편적으로 수용되는 것은 아닙니다.
• OpenAI, Realtime API 문서 (음성 활동 감지 (voice activity detection), 응답 취소 (response cancellation), conversation.item.truncate, WebSocket/WebRTC/SIP 전송 프로토콜).
• Google, Gemini Live API 문서, ai.google.dev/api/live (BidiGenerateContent, 중단 및 턴 처리 (interruption and turn handling)).
• OpenAI, 스트리밍 응답 (streaming responses) 문서 (단일 HTTP 요청, 단방향 출력으로서의 서버 전송 이벤트 (server-sent events)).
• Défossez et al., "Moshi: a speech-text foundation model for real-time dialogue," 2024, arXiv:2410.00037.
• GitHub Copilot CLI hooks 참조 및 확장 (extensions) 문서, docs.github.com (라이프사이클 훅 이벤트 (lifecycle hook events); JSON-RPC 기반의 별도 확장 시스템).
• Anthropic, Claude Code 훅 (hooks) 문서 (내부 라이프사이클 이벤트) 및 Agent SDK.

추가 읽을거리

• "From turn-taking to synchronous dialogue: a survey of full-duplex spoken language models," arXiv:2509.14515 — 유사 전이중 (pseudo-full-duplex) 시스템과 진정한 전이중 (genuine full-duplex) 시스템 사이의 경계가 정의된 논문.
• Latent Space, "OpenAI Realtime API: the missing manual" — 이벤트 프로토콜과 입력 토큰 캐싱 (input-token caching)에 대한 실무자 가이드.