발표하는 동안 회의 참석자들의 모습을 어떻게 보시나요?

화면을 공유하는 순간, 공유 대상인 사람들을 더 이상 볼 수 없게 됩니다. 얼굴이 사라지고, 채팅이 사라지고, 회의에서 가장 시급한 신호인 손들기도 사라집니다.

이것은 주요 플랫폼 지원 포럼마다 꾸준히 올라오는 불만이며, 사람들이 이를 표현하는 방식도 한결같습니다. Microsoft에 이 기능을 요청한 한 발표자는 이렇게 썼습니다. "발표자에게는 청중의 반응을 읽는 것이 매우 중요합니다." Zoom 포럼의 한 교사는 이렇게 말했습니다. "특정 학생과 소통하고 싶어도 누가 거기 있는지 전혀 알 수 없습니다." 또 다른 사용자는 잃게 되는 것을 이렇게 표현했습니다. "직접 만나서 할 수 있었을 모든 것들."

문제는 패널이 없다는 것이 아닙니다. 온라인 발표가 사람을 오프라인 회의에서라면 아무도 받아들이지 않을 처지에 놓는다는 점입니다. 벽을 보고 이야기하면서, 누가 따라오고 있는지 짐작해야 하는 처지입니다.

어떤 해결책이든 하나를 잃고 다른 하나를 얻을 뿐입니다

이 문제가 끈질긴 이유는, 지금 쓸 수 있는 해법들이 문제를 없애는 것이 아니라 옮기는 데 그치기 때문입니다.

오버레이는 보여 주려는 내용을 가립니다. 참가자 갤러리를 콘텐츠 위에 올리면 참석자들을 다시 볼 수 있지만, 발표 중인 내용을 가리는 대가를 치릅니다. Zoom 포럼의 한 호스트는 이렇게 말했습니다. "제가 찾은 유일한 방법은 갤러리를 PP 위에 겹쳐 놓는 것인데, 그러면 이미지 일부가 가려집니다." 같은 딜레마를 양쪽에서 설명한 다른 사용자도 있습니다. "전체 화면에서는 화면을 가리고, 그렇지 않을 때는 필요 이상으로 공간을 차지합니다." 가려지거나 보이지 않거나, 둘 중 하나를 골라야 합니다.

두 번째 모니터도 확실한 해결책은 아닙니다. 이것이 표준적인 조언이지만, 그 한계는 정확히 짚어 둘 필요가 있습니다. 우선 두 번째 디스플레이가 있어야 하므로 노트북만 쓰는 환경이나 출장 환경은 제외됩니다. 모니터가 두 대여도, 슬라이드가 전체 화면이 되는 순간 참가자 목록을 잃는다는 보고가 있습니다. "PPT를 발표 모드로 놓을 때마다 참가자 갤러리가 사라집니다. 공유 화면을 한쪽 모니터에, 발표자 대시보드를 다른 쪽에 두거나, 두 화면을 미러링해서 둘 다 공유 화면을 보이게 하는 방법밖에 없습니다. 수업이든 회의든 전혀 받아들일 수 없습니다."

실제로 사람들이 하는 일은 창 돌려막기입니다. 현실의 임시방편은 수동 안무에 가깝습니다. 창을 줄이고, 끌어다 놓고, 다시 여는 식입니다. 한 Teams 사용자는 이렇게 썼습니다. "임시방편으로 Teams 화면을 열어 왼쪽으로 옮기고, 공유 화면을 줄여서 참가자 목록만 보이게 했습니다."

이 중 어느 것도 문제를 끝내지 못하는 이유는 구조에 있습니다. 회의는 하나의 창입니다. 발표하는 내용도 하나의 창입니다. 한 화면에서 창들은 공간과 포커스를 두고 경쟁합니다.

가장 아픈 경우: 공유 중인 것을 편집해야 할 때

이 절충이 편의의 문제를 넘어 작업 자체를 막기 시작하는 경우가 있습니다.

화면 공유에 관한 조언 대부분은 완성된 것을 발표한다고 가정합니다. 슬라이드 덱, 대시보드, 녹화된 플로우 같은 것입니다. 하지만 업무 회의에서는 바꾸고 있는 것을 공유하는 경우가 많습니다. 새 문단이 들어가는 명세서, 수정된 숫자를 받는 시트, 모두가 방금 옮기기로 합의한 카드를 받는 프로젝트 보드 같은 것들입니다. 참가자를 계속 보는 방법을 묻던 한 사람의 말처럼, "PowerPoint나 Excel만이 아니라 무엇이든" 해당됩니다.

이제 충돌은 더 날카로워집니다. 문서를 편집하려면 문서가 포커스를 가져야 하고, 지금 입력 중인 창이어야 합니다. 그러면 회의는 그 뒤로 밀려납니다. 누군가 써야 할 정확한 문구를 붙여 넣고 있는 채팅도, 어느 행을 말하는지 보여 주던 포인터도 함께 사라집니다.

회의를 앞에 두면 변경을 만드는 대신 변경에 대해 이야기만 하게 됩니다. 변경을 하면 앞을 못 보고 작업하는 셈입니다. 결국 작업은 "통화가 끝난 뒤"로 밀려나고, 방금 그 내용에 합의한 자리에서 멀어집니다.

각 플랫폼이 실제로 문서화한 내용

벤더들은 세 가지 서로 다른 해법을 문서화하고 있습니다. 그중 하나는 다른 것보다 해법에 가깝고, 그것은 사람들이 짐작하는 것이 아닙니다. 그래서 정확히 읽어 볼 가치가 있습니다.

Google은 Meet의 picture-in-picture 모드를 문서화하며, "picture-in-picture 모드를 사용하면 발표하면서 동시에 청중을 찾을 수 있다"고 설명하고, 발표 고정을 해제하면 "발표하는 동안 더 많은 참가자를 찾을 수 있다"고 밝힙니다(2026년 8월 확인). 두 가지 모두 참가자를 보는 문제를 다룹니다. Google의 발표 안내 페이지에는 단일 화면에서 발표하면서 채팅을 계속 보이게 하는 방법이 문서화되어 있지 않습니다.

Zoom은 듀얼 모니터 모드를 문서화합니다. "갤러리 또는 발표자 보기를 한 모니터에 표시하고 다른 모니터에는 공유 콘텐츠를 표시할 수 있다"고 하며, 데스크톱 앱과 i5 이상 4코어 이상의 CPU 하한 등을 전제 조건으로 명시합니다(2026년 8월 확인). 두 번째 모니터라는 답을 기능으로 명문화한 것입니다.

Microsoft가 가장 멀리 나아갑니다. Teams는 "발표하는 사람에게만 보이는" 발표자 도구 모음을 문서화하며 이렇게 밝힙니다. "Chat을 선택하면 콘텐츠를 발표하는 동안 회의 채팅을 간략한 보기로 보고 참여할 수 있습니다. 청중은 공유 화면에서 채팅 창을 볼 수 없습니다"(2026년 8월 확인).

마지막 항목은 선택지를 비교하는 사람에게 중요합니다. 발표자 전용의, 캡처되지 않는 비공개 채팅 패널은 시장의 빈틈이 아닙니다. Teams가 이미 문서화하고 있습니다. 남아 있는 차이는 발표자의 다른 창이 무엇을 하고 있느냐입니다. Meet과 Teams의 발표자용 화면은 회의 앱 자체 창의 일부입니다. 편집 중인 문서는 여전히 별도의 창이며, 그 창과 포커스를 두고 경쟁합니다.

회의가 더 이상 창이 아닐 때 달라지는 것

브라우저에는 페이지와 포커스를 다투지 않는 화면 요소가 하나 있습니다. 바로 브라우저 자체의 사이드 패널입니다.

Chrome은 Side Panel API를 확장 프로그램이 "웹페이지의 메인 콘텐츠 옆, 브라우저의 사이드 패널에 콘텐츠를 호스팅하는" 방법으로 문서화합니다(2026년 8월 확인). 여기서 중요한 속성은 구조적인 것입니다. 패널은 탭이 아니라 브라우저 프레임의 일부입니다. 활성화된 탭이 무엇이든 그 옆에 놓이고, 탭을 전환해도 그대로 유지되며, 페이지에 입력해도 패널이 어디 뒤로 밀리지 않습니다. 패널은 애초에 페이지가 속한 스택 안에 있지 않기 때문입니다.

여기에는 두 번째 결과가 있는데, 문서화된 것과 우리가 측정한 것을 구분해서 말씀드리겠습니다. Chrome의 화면 캡처 문서는 탭 캡처를 탭의 보이는 영역을 캡처하는 것으로 설명하고, W3C 화면 캡처 사양은 브라우저 UI의 정확한 경계를 구현에 따라 달라지는 것으로 남겨 둡니다. 어느 쪽도 사이드 패널이 어떻게 되는지는 밝히지 않습니다. 그래서 직접 테스트했습니다. 탭을 공유할 때 사이드 패널은 캡처된 스트림에 나타나지 않습니다. 참가자들은 선택한 탭을 볼 뿐, 그 옆의 패널은 보지 못합니다.

이 결과는 공유 방식에 따라 달라지며, 이 구분이 핵심입니다. 전체 화면을 공유하면 그 화면의 모든 것이 캡처되고 패널도 포함됩니다. 우리가 의존하는 속성은 탭 공유에서 성립하며, 이 워크플로가 쓰는 방식이 바로 탭 공유입니다.

이 두 속성을 합치면 절충은 관리되는 것이 아니라 해소됩니다.

문서가 활성 탭입니다. 포커스를 가지고 있고, 그 안에서 입력하며, 화면 전체 폭을 쓰고, 그 위에 덮이는 것도 없습니다. 반쪽 폭이 아닙니다.
회의는 그 옆 패널에서, 앱의 좁은 레이아웃으로 진행됩니다. 통화, 채팅, 참가자, 포인터 컨트롤이 거기 있습니다.
참가자들은 문서를 봅니다. 통화 창이나 내가 읽고 있는 채팅이 아니라, 선택한 탭과 그 위에서 쓰는 포인터를 봅니다.

이것이 InterMIND Chrome 확장 프로그램을 만든 이유이며, 지금은 Chrome 웹 스토어에 게시되어 있습니다. 공지를 참고하세요. 통화는 사이드 패널에서 진행되고, 공유하는 탭은 계속 내가 편집할 수 있는 상태로 남습니다. 프로젝트 보드로 진행하는 작업 세션이라면, 보드는 전체 폭으로 열려 편집되고, 포인터는 참석자들에게 어디를 봐야 할지 계속 보여 주며, 채팅도 그 옆에서 계속 읽을 수 있습니다. 모두 한 화면에서 동시에 이루어지며, 두 번째 모니터도, 콘텐츠를 가리는 것도 없습니다.

이것이 해결한다고 주장하지 않는 것도 짚어 두겠습니다. 패널은 좁기 때문에 얼굴이 많이 나오는 큰 갤러리는 들어가지 않습니다. 이것이 답하는 것은 "작업하는 동안 참석자들과 채팅을 손 닿는 곳에 두고 싶다"이지, "비디오 타일 서른 개를 한꺼번에 보여 달라"가 아닙니다.

솔직한 한계

기대치를 정확히 맞추기 위해 세 가지를 분명히 말씀드립니다.

공유는 여전히 일반 선택 창에서 시작됩니다. 공유를 클릭하면 Chrome이 어떤 화면을 공유할지 묻고, 그중 탭을 선택합니다. 사이드 패널에서 "지금 보고 있는 탭을 공유"하는 원클릭 기능은 없습니다. Chrome은 패널 컨텍스트에서 확장 프로그램에 탭 캡처 권한을 부여하지 않으며, 이 기능을 추가해 달라는 요청은 Chromium 팀이 won't-fix로 종료했습니다(2026년 8월 확인). 선택 창은 한 번의 클릭입니다. 임시방편이 아니라 작동 방식입니다.

브라우저에 따라 다릅니다. 사이드 패널은 Chromium 기능입니다. 여기서 설명한 시나리오는 Chrome과 Edge 시나리오이며, 다른 브라우저에서는 다시 창을 배치해야 합니다.

하나의 문제만 해결합니다. 탭을 편집하면서 공유하되 통화 UI를 잃지 않는 것입니다. 작은 노트북 화면을 크게 만들어 주지는 않으며, 공유해야 하는 것이 브라우저 탭이 아니라 데스크톱 애플리케이션이라면 탭 캡처 속성은 적용되지 않습니다.

특히 도움이 되는 경우

결과물이 완성된 것이 아니라 살아 있는 상태일 때마다 이 패턴이 나타납니다.

문서나 명세서 작업 세션 — 참석자들의 반응을 보며 문구를 고치고, 나중에 반영하려고 피드백을 적어 두는 일을 하지 않습니다.
스프레드시트와 계획 모델 — 입력값을 바꾸고 모두가 숫자가 움직이는 것을 지켜봅니다. 시트를 화면에 띄우는 이유가 바로 이것입니다.
프로젝트 보드와 백로그 — 우리가 내부에서 이 문제를 알게 된 계기입니다. 계획 회의 중에 카드를 옮기고 티켓을 편집하면서, 그에 대해 사람들이 입력하는 내용도 계속 읽습니다.
디자인 및 코드 리뷰 — 통화 중에 작은 수정을 하고, 포인터로 논의 중인 부분을 표시합니다.

이들의 공통점은 회의의 가치가 결과물의 변경에 있다는 것입니다. 편집을 "통화가 끝난 뒤"로 미루는 워크플로는 합의가 이루어진 회의 밖으로 작업을 밀어냅니다.

FAQ

발표하는 동안 참가자를 어떻게 볼 수 있나요?

플랫폼마다 문서화한 부분적인 답이 다릅니다. Google은 picture-in-picture와 "더 많은 참가자를 찾기" 위한 발표 고정 해제를 문서화합니다. Zoom은 두 번째 디스플레이가 필요한 듀얼 모니터 모드를 문서화합니다. Microsoft는 발표자에게만 보이는 발표자 도구 모음을 문서화합니다(모두 2026년 8월 확인). 공통된 한계는 이런 화면 요소가 회의 앱 자체 창 안에 있어서, 다른 작업과 경쟁한다는 점입니다. 그래서 모니터가 두 대여도 슬라이드가 전체 화면이 되는 순간 참가자 목록을 잃는다는 보고가 나옵니다.

PowerPoint가 발표 모드로 들어가면 왜 참가자 갤러리가 사라지나요?

발표 모드는 자신이 놓인 디스플레이를 통째로 차지하고, 회의 창은 별도의 창이라 그 뒤로 밀리기 때문입니다. 그래서 두 번째 모니터가 문제를 자동으로 해결하지 못합니다. 디스플레이가 둘인 사용자도 같은 문제를 겪는데, 슬라이드쇼가 어느 디스플레이를 차지하느냐의 문제가 되기 때문입니다. 사람들이 대안으로 택하는 것은 콘텐츠 위에 갤러리를 겹쳐 놓거나 창 크기를 수동으로 조절하는 것입니다.

모니터 하나로 화면을 공유하는 동안 채팅은 어떻게 볼 수 있나요?

플랫폼에 따라 다릅니다. Microsoft는 Teams에서 발표자를 위한 간략한 회의 채팅 보기를 문서화하며, 청중은 공유 화면에서 그 채팅 창을 볼 수 없다고 밝힙니다(2026년 8월 확인). Zoom이 문서화한 답은 두 번째 디스플레이가 필요한 듀얼 모니터 모드입니다(2026년 8월 확인). Google의 발표 문서는 picture-in-picture를 통해 참가자를 보는 방법을 다루며 채팅은 다루지 않습니다(2026년 8월 확인). 어느 쪽도 바꾸지 못하는 점은 발표자용 화면이 회의 앱의 창에 속한다는 것입니다. 따라서 공유 중인 문서를 편집해야 한다면, 그 문서와 회의는 여전히 하나의 포커스를 두고 다투는 두 개의 창입니다.

화면을 공유하면서 문서를 편집할 수 있나요?

네. 제한은 편집에 있는 것이 아니라, 편집하는 동안 무엇을 볼 수 있느냐에 있습니다. 문서에 입력하려면 문서가 포커스를 가져야 하고, 단일 화면에서는 그 때문에 회의 인터페이스가 뒤로 밀립니다. 문서는 그동안 계속 공유되며, 그 안에서 작업하는 동안 채팅, 참가자, 포인터를 볼 수 없게 될 뿐입니다.

발표와 작업을 동시에 하려면 모니터가 두 대 필요한가요?

모니터 두 대는 표준적인 답이며 효과가 있습니다. 하지만 유일한 답은 아닙니다. 브라우저 사이드 패널은 단일 화면에서 두 번째 화면 요소를 제공합니다. 패널이 페이지와 포커스를 다투지 않고 브라우저 프레임에서 페이지 옆에 자리하기 때문입니다.

사이드 패널이 화면 공유에 나타나나요?

탭을 공유할 때는 나타나지 않습니다. 직접 테스트했고, 패널은 캡처된 스트림에 나타나지 않았습니다. Chrome 문서와 W3C 화면 캡처 사양은 이 동작을 어느 쪽으로도 명시하지 않으므로(사양은 브라우저 UI 경계를 구현에 따라 달라지는 것으로 남겨 둡니다), 문서로 보장된 사항이 아니라 측정된 결과로 받아들여 주세요. 대신 전체 화면을 공유하면 그 화면에 보이는 모든 것이 패널을 포함해 캡처됩니다.

선택 창 없이 현재 탭을 한 번의 클릭으로 공유하는 방법이 있나요?

사이드 패널에서는 없습니다. Chrome은 패널 컨텍스트에서 확장 프로그램에 탭 캡처 권한을 부여하지 않으며, 이를 허용해 달라는 요청은 Chromium 팀이 won't-fix로 종료했습니다(2026년 8월 확인). 공유는 표준 Chrome 선택 창에서 시작하며, 거기서 탭을 선택합니다.

어떤 브라우저에서 작동하나요?

사이드 패널은 Chromium 기능이므로 Chrome과 Edge에 적용됩니다. 다른 브라우저에는 이에 상응하는 화면 요소가 없으며, 위에서 설명한 창 간 절충이 그대로 적용됩니다.

이것이 두 번째 모니터를 대체하나요?

브라우저 탭을 편집하면서 공유하고 통화 UI도 계속 보이게 한다는 이 특정한 경우에는, 두 번째 모니터가 필요했던 이유를 없애 줍니다. 하지만 두 번째 모니터가 유용한 다른 모든 용도를 대체하지는 않습니다.

직접 해 보기

Chrome 확장 프로그램 받기 — 무엇이 설치되는지, 어떤 권한을 요청하는지, 무엇을 하지 않는지 설명합니다.
화상 회의에서 화면을 공유하는 방법 — 화면, 창, 탭 공유, 휴대폰에서의 공유, 레이저 포인터, 그리고 Meet과 Teams가 멈추는 지점을 다룹니다.
라이브 데모 체험하기 — 아무것도 설치하기 전에 번역된 통화가 어떻게 동작하는지 확인해 보세요.
회의에 공유한 파일이 어떻게 되는지 확인하기 — 누가 읽을 수 있는지, 어떤 언어로 읽는지, 요약 속 주장을 어떻게 검증하는지 설명합니다.
번역 벤치마크 읽기 — 언어 쌍별 전체 분포와 측정 방법을 함께 담은 품질 수치입니다.