본문 바로가기

직접 만든 소프트웨어, 두 가지 개발 기록

구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다.

소프트웨어개발

VS Code 원격 에이전트가 띄운 앱, 포트 전달 없이 확인하려면

by 아빠띠띠뽀 2026. 11. 9.

VS Code의 원격 에이전트가 개발 서버를 띄웠는데 내 컴퓨터 브라우저에서는 페이지가 열리지 않나요? 1.145의 Agents 창 통합 브라우저 미리보기를 쓸 수 있는 환경이라면, 먼저 원격 세션에서 앱이 실제로 실행 중인지 확인한 뒤 그 앱의 원래 localhost 주소를 통합 브라우저에 열어 보세요. 해당 미리보기에서는 이 확인을 위해 개발 서버 포트를 내 컴퓨터로 전달할 필요가 없습니다.

VS Code는 2026년 11월 4일 안정판 1.145 릴리스 노트에 이 기능을 소개했습니다. 안정판에 안내됐지만 원격 에이전트 호스트를 통한 브라우징 자체는 미리보기입니다. 아래 설명은 11월 8일 확인한 공식 문서 기준입니다. 실제 원격 호스트 연결, 배포, 브라우저 실행은 하지 않았고, 주소와 화면 동작의 예는 문서 내용을 이해하기 위한 가상 상황입니다.

똑같은 localhost인데 왜 다른 결과가 나올까요?

노트북 앞에서 작업 중인 지수 씨를 생각해 볼게요. 지수 씨는 Agents 창으로 다른 컴퓨터의 에이전트 세션에 연결했습니다. 에이전트는 그 컴퓨터에서 개발 서버를 시작하고 주소를 알려 줍니다. 그런데 지수 씨가 노트북의 일반 브라우저에 같은 주소를 입력하니 연결 오류가 납니다. 그 주소에 서버가 없다는 결론부터 내리면 문제의 방향을 놓치기 쉽습니다.

localhost는 요청이 어디에서 나가느냐에 따라 다른 컴퓨터를 가리킬 수 있습니다. 일반 브라우저에서 노트북의 주소로 해석된 결과와, VS Code의 지원되는 원격 프록시를 거쳐 세션 호스트로 요청한 결과를 같은 시험으로 보지 마세요. 릴리스 노트는 새 흐름에서 Agents 창의 통합 브라우저가 원격 에이전트 호스트를 통해 페이지를 불러온다고 설명합니다. 덕분에 세션에서 만든 앱 화면을 같은 작업 흐름 안에서 확인할 수 있습니다.

여기서 에디터의 기존 원격 작업 영역과 Agents 창에서 연결한 원격 세션을 구분해 두면 문서도 빨리 찾을 수 있습니다. 기존 원격 작업 영역에서도 통합 브라우저의 원격 연결 기능을 설명해 왔습니다. 11월 4일 릴리스에서 다루는 변경은 Agents 창의 원격 에이전트 세션을 통한 브라우징입니다. 예전에 원격 개발 창에서 동작했다고 해서 지금 보고 있는 창이 같은 종류라고 가정할 필요는 없습니다.

지금 보고 있는 곳 먼저 확인할 질문
내 컴퓨터의 일반 브라우저 이 주소가 내 컴퓨터의 서버를 가리키나요?
원격 세션의 Agents 창 해당 세션 호스트에서 앱이 실제로 실행 중인가요?
Agents 창의 통합 브라우저 원격 프록시가 적용되는 미리보기 환경인가요?
운영 주소나 외부 테스트 환경 배포와 다른 사용자 접근은 별도로 확인했나요?

포트를 열기 전에 확인하는 세 가지

첫째, 어떤 세션과 호스트에 연결했는지 확인합니다. 원격 세션 공식 문서는 연결 방법의 예로 SSH, 개발 터널, 미리보기인 GitHub Environments를 소개하고 연결 방법과 클라이언트에 따라 가능한 작업이 달라질 수 있다고 설명합니다. 이 목록이 모든 연결에서 같은 미리보기 동작을 보장하는 것은 아닙니다. 자신이 쓰는 연결의 지원 안내를 먼저 확인하고, 회사의 승인된 접속 경로를 유지하세요.

둘째, 공식 원격 세션 가이드가 제시하는 설정 전제를 확인합니다. workbench.browser.enableRemoteProxy를 켜고 workbench.browser.dataStorage는 기본값에 둡니다. 팀 설정을 바꿀 수 있는지와 조직 정책도 따로 봐야 합니다. 정책 때문에 브라우저 도구나 접근 도메인이 제한된 경우에는 개인 설정을 여러 번 바꾸거나 우회하기보다 승인된 테스트 방법을 확인하는 편이 맞습니다.

셋째, 에이전트의 설명에 나온 주소와 실제 실행 정보를 대조합니다. 서버가 시작됐다는 문장만으로 끝내지 말고 어느 호스트에서 어떤 포트와 경로를 쓰는지 확인하세요. 가령 실제 앱의 예시 주소가 http://localhost:4173/settings라면 통합 브라우저에서는 그 원래 주소와 경로를 기준으로 확인합니다. 4173은 설명을 위해 고른 숫자입니다. 내 앱의 포트가 이것과 같거나 미리보기에서 항상 지원된다는 뜻은 아닙니다.

예를 들어 /settings에서 화면이 보이지 않는데 기본 경로만 열어 본 결과를 ‘확인 완료’로 적으면, 다음 사람이 같은 문제를 또 만나게 됩니다. 시작한 앱과 기대하는 화면을 한 쌍으로 적고, 주소가 실제로 바뀌었는지까지 보세요. 화면이 전혀 없을 때와 화면은 열리지만 로그인으로 이동할 때의 원인도 다릅니다. 후자는 응답을 받은 상태에서 앱 흐름을 살펴볼 문제일 수 있습니다.

내가 화면을 보는 것과 에이전트가 보는 것은 따로입니다

미리보기에서 사람에게 페이지가 보인다고 에이전트에도 자동으로 그 탭이 공유되는 것은 아닙니다. 공식 문서에서 사용자가 연 통합 브라우저 탭을 에이전트에게 보여 주는 기능은 Share with Agent입니다. 도구 모음에서 탭을 공유하고 확인하면 에이전트가 해당 페이지를 읽고 상호작용할 수 있습니다. 같은 항목을 다시 선택해 공유를 철회할 수 있다고 안내합니다.

반면 에이전트가 직접 연 브라우저 탭에는 격리된 임시 저장소를 쓴다고 문서가 설명합니다. 사람이 보던 로그인 화면과 에이전트가 연 화면의 상태가 달라도, 곧바로 앱이 고장 났다고 단정하지 마세요. 어느 탭이 열렸고 누가 연 탭인지 먼저 확인합니다. 공식 문서에서는 관리자가 BrowserChatTools 정책으로 브라우저 도구를 끄거나 에이전트의 네트워크 접근 범위를 제한할 수 있다고도 안내합니다.

처음 사용해 본다면 실제 회원 정보가 있는 관리자 화면 대신 직접 만든 시험 페이지를 준비해도 충분합니다. ‘설정에서 색상 선택이 바뀌는지 본다’처럼 한 가지 흐름만 정하고, 공유할 필요가 없는 탭은 그대로 둡니다. 사람이 화면을 한 번 보는 일에는 공유가 필요하지 않습니다. 에이전트에게 추가로 맡길 때도 확인할 경로와 종료 조건을 먼저 정하는 편이 편합니다.

목표 확인 범위를 적는 예
화면 도착 확인 원래 주소, 화면 제목, 나타난 경로
버튼 동작 확인 시험 페이지에서 할 행동 하나와 기대 결과
수정 후 확인 같은 주소와 시작 상태에서 다시 관찰한 결과
에이전트 공유 공유한 시험 탭과 공유를 철회했는지

시험 페이지에서 오류가 보이면 에이전트에게 전체 화면을 넘기기 전에, 어떤 버튼을 눌렀고 무엇이 나와야 했는지부터 적어도 됩니다. 공식 브라우저 도구 안내는 Add to Chat으로 선택한 페이지 요소나 화면 정보를 첨부하는 방법도 소개합니다. 화면 자료에도 사용자 이름이나 내부 주소가 포함될 수 있으니 공유할 범위를 직접 고르세요. 특정 요소 하나를 전달하는 것과, 에이전트가 탭을 직접 조작하도록 공유하는 것은 맡기는 일이 다릅니다.

성공 화면 하나로 배포까지 판단하지 않기

작업을 마무리할 때 ‘원격 서버 정상’이라고만 적어 두면 다음 사람이 어디까지 확인했는지 모릅니다. 가령 ‘시험 앱의 설정 페이지를 원격 세션의 통합 브라우저에서 열었고, 토글을 눌렀을 때 화면이 갱신됐다’는 기록이라면 확인 범위가 드러납니다. 그 기록만으로 운영 주소나 다른 사용자의 로그인, 모바일 크기에서의 동작을 증명할 수는 없습니다. 확인한 경로와 아직 보지 않은 경로를 함께 써 두면 다음 테스트가 쉬워집니다.

같은 이유로 ‘열기 실패’도 관찰한 모습대로 기록하는 편이 유용합니다. 연결 오류가 났는지, 다른 페이지가 떴는지, 제목은 보이는데 필요한 데이터가 비어 있는지 각각 다릅니다. 첫째는 서버 위치나 연결 상태를, 둘째는 경로와 앱의 이동 흐름을, 셋째는 앱 내부 조건을 볼 단서입니다. 실패했다는 말만 붙이고 포트를 더 열면 원인을 확인할 기회를 놓칠 수 있습니다.

특히 컨테이너로 개발 서버를 띄운 경우에는 컨테이너 안의 서버와 세션 호스트에서 실제 닿을 수 있는 주소를 구분해 보세요. 세션 호스트를 경유한다는 설명만으로 컨테이너 안의 모든 포트에 접근된다는 뜻은 아닙니다. 앱이 실행된 위치를 정리할 때 Docker Compose의 실제 호스트 포트 확인 글을 참고할 수 있습니다. 컨테이너의 매핑과 여기서 다루는 Agents 창 미리보기는 다른 층의 문제입니다.

기능을 시험하고 원래 방식으로 돌아갈 계획이라면, 본인이 바꾼 편집기 설정의 이전 값과 시험 범위를 메모해 두세요. 시험 탭의 공유를 종료하고, 변경했던 설정은 조직 정책과 기존 작업의 필요에 맞춰 되돌릴 수 있습니다. 변경 전 값이 무엇인지 확인하기 어렵다면 기존 프로젝트 설정을 덮어쓰기보다 별도 시험 환경에서 진행하는 편이 안전합니다. 이 안내는 조직 설정이나 접근 권한을 변경하라는 뜻이 아닙니다.

이런 경우에는 무엇부터 볼까요?

노트북 브라우저가 안 열리는데 서버부터 다시 띄울까요? 먼저 브라우저와 앱이 서로 다른 컴퓨터를 기준으로 주소를 해석하는지 살펴보세요. 해당 원격 세션에서 서버 시작이 확인되고 미리보기 요건을 만족한다면 통합 브라우저에 원래 주소를 넣는 순서가 자연스럽습니다. 이미 실행 중인 앱에 불필요하게 두 번째 프로세스를 띄울 필요는 없습니다.

팀원에게 같은 주소를 보내면 볼 수 있나요? 이 기능은 현재 원격 세션에서 화면을 확인하는 경로를 설명합니다. 팀원 일반 브라우저에서 같은 localhost를 쓰면 같은 호스트를 가리킨다고 할 수 없습니다. 다른 사람과 결과를 확인하려면 테스트 환경의 승인된 주소와 접근 범위를 별도로 정하세요.

내 화면이 정상인데 에이전트가 다르게 설명해요. 에이전트와 내가 동일한 시험 탭과 시작 상태를 보고 있는지 확인해 보세요. 서로 다른 로그인 상태나 경로라면 먼저 관찰 조건을 맞춰야 합니다. 실제 고객 계정이나 업무 화면을 공유할 필요는 없습니다. 같은 현상을 재현하는 작은 시험 화면으로 충분한지부터 보세요.

여전히 옵션이 보이지 않으면요? 사용 중인 버전과 창 종류, 원격 연결 지원 여부, 조직 정책을 구분해서 확인하세요. 미리보기라 제공 상태가 다르거나 기능이 바뀔 수 있습니다. 한 항목이 확인되지 않으면 그 범위를 기록하고 기존에 승인된 방법으로 화면을 확인하는 편이 낫습니다.

확인한 공식 자료

2026년 11월 8일 VS Code 1.145 릴리스 노트, 원격 에이전트 세션 공식 안내, 브라우저 도구와 탭 공유 안내를 확인했습니다. 릴리스 노트는 도입과 미리보기 상태를, 가이드는 설정과 공유 전제를 설명합니다. 실제 팀 환경의 연결 여부와 테스트 결과는 이 글에 포함되지 않습니다.

원격 앱 미리보기의 내 브라우저, Agents 창, 원격 호스트, 시험 탭 공유를 나눈 개념도
주소가 닿는 곳과 시험 탭을 공유하는 범위를 구분한 자체 개념도입니다.