VS Code 1.144, 노트북을 닫아도 이어지는 AI 코딩 작업

책상에서 코딩 작업을 시작하고 다른 기기로 상황을 확인한 뒤 나중에 돌아와 변경 사항을 검토합니다. 유용한 경험은 같은 지시와 확인 가능한 결정을 유지하는 하나의 이어지는 작업입니다. 기기를 바꿀 때마다 대화를 다시 구성해야 한다면 그것도 또 하나의 개발 업무입니다.

VS Code 1.144는 2026년 10월 28일 Stable로 정식 출시됐습니다. 릴리스 노트는 에이전트 세션 연속성과 원격 관리뿐 아니라 개별적으로 Preview나 Experimental 표시가 붙은 기능도 소개합니다. 클라우드 세션은 GitHub 인프라에서 실행되므로 개발 노트북이 오프라인이어도 계속 작업할 수 있습니다. 공식 릴리스 노트.

이 글에서는 클라이언트와 실제 작업 실행 장소의 차이, Agent Host Protocol의 역할, 실제 코드 검토와 인계를 통해 이어지는 세션을 평가하는 방법을 살펴봅니다.

Visual Studio Code 1.144의 공식 원격 환경 스크린샷. Used with permission from Microsoft. 이미지 출처 · 라이선스·이미지 설명.

창을 닫는 것과 실행 프로세스를 멈추는 것은 다른 일이다

코딩 화면에는 메시지, 파일, 승인 요청이 보입니다. 실제 작업 프로세스는 다른 곳에 있을 수 있습니다. 두 역할이 나뉘면 호스트와 환경을 계속 사용할 수 있는 한 화면을 닫아도 작업을 버릴 필요는 없습니다.

Microsoft의 10월 28일 유니버스 개요는 Agent Host를 세션·하네스·모델·파일·터미널을 관리하는 독립 프로세스로 설명합니다. Agent Host Protocol이 1.0에 도달했고 클라이언트가 진행 중인 세션 상태에 연결되도록 한다고 밝힙니다. ‘작업을 계속한다’의 의미를 평가하는 데 유용한 구조적 구분입니다.

로컬 호스트는 여전히 로컬 기기에 의존합니다. 원격 호스트는 해당 원격 기기와 연결 구성에 의존합니다. 클라우드 세션에는 별도로 호스팅되는 환경이 있습니다. 클라이언트를 떠났을 때 무엇이 계속 이용 가능해야 하는지에 따라 실행 위치를 선택하세요.

클라이언트를 제어실 창이라고 생각해 보세요. 다른 창에서도 같은 작업을 볼 수 있지만 밑의 실행 장비가 이동하지는 않습니다. 휴대전화에서 세션을 본다고 절전 중인 로컬 컴퓨터가 상시 서버로 바뀌지는 않습니다.

저희가 보기에 지속 실행은 작업의 맥락과 정체성까지 함께 유지될 때 유용합니다. 이어지는 세션에서는 어떤 저장소를 사용하고 어떤 변경을 만들었으며 어떤 결정을 기다리는지 명확해야 합니다. 프로세스가 살아 있는 것은 그보다 작은 성과입니다.

클라이언트와 호스트의 책임을 구분하는 자체 제작 설명 도표입니다. 참고한 자료는 VS Code 유니버스 개요입니다. 네트워크 토폴로지가 아닌 단순화된 계획 모델입니다.

AHP는 여러 인터페이스가 보는 세션을 동기화한다

11월 2일 확인한 공식 Agent Host Protocol 사이트는 AHP를 양방향 상태 기반 표시 프로토콜로 설명합니다. 클라이언트는 공유 세션 상태를 대상으로 작동하고, 호스트는 동작을 전파하며 충돌을 조정합니다. 다시 연결하면 놓친 동작이나 현재 상태의 스냅샷을 받아 화면을 최신 상태로 맞출 수 있습니다.

에이전트 세션에는 대화 기록 이상의 내용이 있으므로 중요합니다. 승인을 기다리는 작업, 실행 중인 터미널, 변경된 파일이 포함될 수 있습니다. 두 인터페이스에서 이 사실들이 다르게 보이면 코드 생성 자체가 좋아도 세션 운영자가 잘못된 결정을 내릴 수 있습니다.

프로토콜의 재연결 예시는 대기 중인 클라이언트 조치가 호스트 상태와 조정되는 모습을 보여 줍니다. 실무 의미는 단순합니다. 다시 연결하면 이전 요청의 결과까지 포함한 현재 작업 상황이 복구되어야 합니다. 네트워크가 끊기기 전에 승인이 도착했는지 추측할 필요가 없어야 합니다.

공유 프로토콜은 클라이언트 상호운용의 경계도 정합니다. 클라이언트는 세션 상태와 노출된 조치를 이해해야 합니다. 프로토콜이 있다고 모든 도구가 모든 제공자에 이미 연결되거나 모든 기능을 똑같이 보여 준다는 뜻은 아닙니다.

인터페이스를 비교한다면 업무의 중요한 결정을 살피세요. 다른 클라이언트에서도 승인 대기를 볼 수 있나요? 바뀐 파일과 현재 작업 상태가 보이나요? 편집기로 돌아오면 새 대화가 아니라 같은 작업이 유지되나요?

정식 출시와 개별 기능의 프리뷰 표시는 별개다

VS Code 1.144 페이지는 릴리스를 Stable로 표시하지만 Cloud Automations, 이미지 생성, Copilot connectors는 Preview로 남아 있습니다. 컴퓨터 사용과 working set 기능은 Experimental로 표시합니다. 클라우드 세션에는 유료 Copilot 요금제가 필요하며 조직 정책이 적용됩니다. 출시 및 기능 현황, 10월 28일 발표, 11월 2일 확인.

확장 가능한 편집기에서는 자연스러운 구성입니다. 정식 버전의 앱에도 성숙도가 다른 개별 기능이 포함될 수 있습니다. 도입 판단은 버전 번호만이 아니라 해당 기능과 작업 흐름을 기준으로 해야 합니다.

표는 운영 비교이며 모든 환경에서 같은 동작을 약속하지 않습니다. 특정 확장, 모델, 하네스의 요구 사항도 중요합니다. 팀이 실제로 쓸 조합으로 시험하세요.

실험 기능은 별도의 되돌릴 수 있는 작업으로 시험하세요. 핵심적인 세션 연속성을 평가할 때는 인계 과정을 입증할 최소 작업부터 시작합니다. 새로운 기능을 여러 개 결합하면 예상과 다른 결과가 어느 부분에서 생겼는지 파악하기 어렵습니다.

연속성이 도움이 되는 세 가지 작업 예시

개발자는 범위를 좁힌 수정을 맡기고 나중에 검토할 수 있다

저장소의 실패한 파서 테스트를 고치도록 클라우드 세션에 맡기는 개발자를 가정해 보겠습니다. 지시에는 실패, 관련 동작, 기대 검증을 적습니다. 개발자는 지원되는 다른 클라이언트로 진행 상황을 확인한 뒤 편집기로 돌아와 검토합니다.

합격 기준은 다른 코드 변경과 같아야 합니다. 문제가 된 동작이 고쳐졌고 관련 검사를 통과하며 변경 내역이 적절해야 합니다. 노트북을 닫아도 계속되는 기능은 작업 가능한 시간을 바꾼다는 점에서 유용합니다. 그 자체가 병합 준비 완료를 입증하지는 않습니다.

인계를 위해 정확한 테스트 명령과 결과를 남기도록 요청하세요. ‘테스트 통과’라는 메시지보다 특정 버전에 연결된 이름 있는 검사를 평가하기 쉽습니다. 검토자가 전체 대화를 재구성하지 않아도 이해할 충분한 증거가 필요합니다.

승인이나 필요한 서비스가 없어 진행이 막히면 세션에서 그 상태를 보여줘야 합니다. 활성 상태여도 진척이 없는 작업과 실제로 유용한 일을 하는 작업은 다릅니다. 상태가 보여야 개발자가 개입할지, 범위를 바꿀지, 대기시킬지 판단할 수 있습니다.

유지관리자는 파일을 섞지 않고 별개의 문제를 조사할 수 있다

유지관리자가 한 세션에는 버그 재현을, 다른 세션에는 문서 검사를 맡기는 예를 생각해 보겠습니다. 경계가 분명하면 대기 시간을 잘 활용할 수 있습니다. 동시에 각 결과를 해당 작업 공간과 검토 맥락에 연결해야 합니다.

시작 전에 담당 범위를 정의하세요. 파일이나 하위 시스템, 브랜치나 작업 공간, 각 세션이 내놓아야 할 결과를 정합니다. 두 작업이 같은 인터페이스 요건을 건드려야 한다면 양쪽 변경을 적용하기 전에 발견 사항을 어떻게 조율할지 결정하세요.

알고 있는 저장소 상태를 기준으로 결과 하나씩 검토하세요. 그렇지 않으면 통과한 테스트가 다른 세션의 미검토 수정에 의존할 수 있습니다. 작업 공간 경계가 있으면 무엇을 기반으로 검사가 통과했는지 밝히기 쉽습니다.

목표는 단순히 동시 에이전트 수를 늘리는 것이 아니라 검토 대기열을 명확히 하는 것입니다. 범위가 분명한 조사 두 개는 불확실성을 줄일 수 있지만 겹치는 수정 여러 개는 오히려 늘릴 수 있습니다. Agents 인터페이스는 유지관리자가 어느 상황인지 알아보게 할 때 유용합니다.

팀은 반복 클라우드 작업을 예약하기 전에 시험할 수 있다

자동화 파일럿의 예로 손볼 문서 링크를 주기적으로 찾는 작업을 생각해 보세요. 읽기 전용 보고서와 구체적인 출력부터 시작합니다. 변경 생성까지 넓히기 전에 사람이 결과를 검토하도록 합니다.

반복 작업에는 운영 책임이 추가되므로 Cloud Automations가 Preview라는 점이 중요합니다. 한 번 잘 작동한 작업도 예약 실행 전에 호출 빈도 제어와 책임자, 명확한 실패 대응이 필요할 수 있습니다. 언어 출력의 품질과는 별도로 이런 요건을 시험하세요.

팀은 각 실행의 저장소 버전, 결과, 외부 요청을 어디에 기록하는지 알아야 합니다. 끝내지 못하면 무엇이 미해결인지 기록에 드러나야 합니다. 변화가 없는 상황과 검증 실패를 책임자가 구분할 수 있어야 반복 작업이 유용합니다.

저장소 하나와 작은 범위에서 시작하세요. 정상 실행, 의도적으로 막은 실행, 남긴 산출물을 팀이 검토한 뒤에 확대합니다. 제안하는 파일럿 단계이며 이번 버전을 직접 시험했다는 주장은 아닙니다.

미커밋 작업은 명시적으로 인계해야 한다

1.144 릴리스 노트는 클라우드 세션이 별도 작업 공간을 사용하며 로컬의 미커밋 변경을 자동 복사하지 않는다고 명시합니다. Chat 또는 Agents 창에서 Cloud와 GitHub 저장소를 선택해 작업을 시작하고, 후속 지시와 승인 응답, 변경 검토를 할 수 있습니다. 세션 목록에서 기존 세션을 다시 열 수도 있습니다. 클라우드 세션 지침.

별도 작업 공간이라는 점은 수정이 진행 중인 체크아웃에서 일하는 사람에게 중요합니다. 클라우드 세션이 보는 저장소 상태에는 없어도 필수인 로컬 파일이 있을 수 있습니다. 인계 전에 사용할 원본 리비전과 추가 자료를 전달할 승인된 방법을 확인하세요.

인터페이스 전환과 파일 전송을 혼동하지 마세요. 같은 대화를 이어 간다고 로컬 파일이나 실행 서비스가 모두 이동했다는 뜻은 아닙니다. 의도를 유지하는 세션이라도 실행 자료에 접근할 명시적인 경로는 필요합니다.

버그 보고 예시라면 실패를 일으키는 입력을 승인된 재현 가능한 형태로 포함하세요. 에이전트가 커밋된 테스트 픽스처를 쓸지 새로 제공한 자료를 쓸지 명시합니다. 그러면 구체적인 출발점이 생겨 애초에 문제가 담기지 않은 저장소 상태를 오래 조사하는 일을 피할 수 있습니다.

최종 검토에서는 같은 경계를 반대 방향으로 확인해야 합니다. 변경을 어디에 적용하고 작업 브랜치로 어떻게 가져올지 정하세요. 결과를 검토·적용하는 동안 진행 중인 로컬 편집을 보존합니다. 원격 공간의 이점을 얻으려고 불확실한 로컬 작업을 희생해서는 안 됩니다.

지속되는 코딩 작업을 위한 자체 제작 합격 기준 흐름입니다. 문서화된 클라우드 작업 공간 경계와 일반 엔지니어링 검토를 결합하며 독립 시험 결과가 아닙니다.

10분 둘러보기보다 작업 하나의 완주가 더 많은 것을 입증한다

연속성의 겉모습은 확인하기 쉽습니다. 세션이 목록에 보이고 클라이언트가 다시 연결되며 메시지가 도착합니다. 유용한 검사이지만 개발자의 목표는 인계 뒤에도 유지되는 완료 작업입니다.

확인 가능한 산출물로 끝낼 작은 과제를 고르세요. 저장소에 명확한 검사가 있다면 테스트 픽스처, 문서 수정, 격리된 동작 수정이 적합할 수 있습니다. 첫 시도를 너무 넓히지 않으면서도 작업 공간 상태와 권한을 드러낼 만큼 의미 있어야 합니다.

1. 설치 버전을 업데이트하고 확인하세요. VS Code의 Check for Updates로 버전을 확인합니다. 공식 노트에서 기능별 상태 표시를 읽어보세요.
2. 허용된 실행 환경을 고르세요. 저장소 접근, 요금제 이용 자격, 조직 정책을 확인하고 로컬·원격·클라우드 중 어디서 실행할지 정합니다.
3. 시작 상태를 기록하세요. 저장소와 리비전을 적고 로컬 변경을 보존합니다. 선택한 작업 공간에 필요한 입력도 확인하세요.
4. 범위가 분명한 지시를 주세요. 원하는 동작과 범위, 검증 명령을 명시하고 검토할 결과물을 정합니다.
5. 인계 과정을 시험하세요. 클라이언트를 떠났다가 사용 가능한 지원 인터페이스로 다시 연결합니다. 같은 세션의 상태와 승인 대기, 새 작업을 확인하세요.
6. 코드로 돌아오세요. 변경 내역과 검증 근거를 살펴보고, 검사가 검토 중인 리비전에 적용되는지 확인합니다.
7. 결과와 남은 한계를 기록하세요. 재연결 성공과 작업 완료, 변경 수용을 구분합니다. 서로 연결되지만 각기 다른 근거가 필요한 단계입니다.

실패했다면 어느 경계에서 문제가 생겼는지 진단하세요. 저장소의 테스트 픽스처가 없으면 작업 공간을 고쳐야 하고, 도구 호출이 막히면 권한 판단이 필요합니다. 호스트를 사용할 수 없다면 실행 환경을 결정해야 합니다. 프롬프트 밖의 문제를 같은 프롬프트 반복으로 해결하기는 어렵습니다.

첫 결론도 구체적으로 남기세요. ‘이 환경에서 이 작업이 계속됐고 검토 가능한 변경을 만들었다’는 유용한 운영 결론입니다. 동료에게 무엇을 반복할 수 있고 어떤 조건이 중요한지 알려 줍니다.

이어지는 세션은 책임 소재를 더 쉽게 따라가게 해야 한다

VS Code 1.144는 지시가 작업이 되고 작업이 검토 가능한 변경이 되는 지속적인 공간으로 더 많은 에이전트 흐름을 가져옵니다. AHP는 클라이언트에 공유 상태의 틀을 제공하고, 실행 위치는 기기 연결이 끊긴 뒤에도 무엇을 계속할 수 있는지 정합니다.

의미 있는 발전은 자리를 떠났다가 돌아와도 이해할 수 있는 작업입니다. 세션이 원본 상태와 결정, 검증을 보존한다면 노트북을 닫는 일은 작업의 경계가 아니라 일정상의 작은 문제가 됩니다.

출처

• Visual Studio Code 1.144 릴리스 노트, 2026년 10월 28일 정식 릴리스; 2026년 11월 2일 확인.
• VS Code Wrapped: GitHub Universe 2026, 2026년 10월 28일.
• Microsoft Agent Host Protocol, 사양 v1.0.0 및 공유 상태 개요, 2026년 11월 2일 확인.

결정의 근거 자료를 보관한다

Telli.sh는 검토한 메모와 이용 권한이 있는 원자료를 함께 보관할 수 있는 선택지입니다. 노트 작업 공간 만들기.