자동화 코드를 보는 일과 실제 페이지 결과를 보는 일은 오가며 해야 했다. 상태까지 같은 좁은 칸에 섞으면 무엇을 확인 중인지 흐려진다. 북극성에서는 왼쪽 주피터, 가운데 웹과 오른쪽 실행 기록에 자리를 주되 항상 세 칸을 열어 두도록 강제하지 않았다.
세 칸의 역할을 먼저 정한다
왼쪽은 실행할 셀과 출력, 가운데는 실제 사이트, 오른쪽은 실행 기록과 관리 문맥을 읽는 곳이다. 과거에는 오른쪽에 내장 AI 대화가 있었지만 현재 설치판의 내장 CLI·모델 입력은 제거됐다. 과거 작업실 사진의 모든 기능이 지금도 실행된다고 설명하지 않는다.
코드가 실행됐다는 사실과 페이지에 기대한 결과가 나타났다는 사실은 서로 다른 관찰이다. 그래서 둘을 번갈아 새 탭으로 여는 대신 같은 작업실에서 비교할 수 있도록 했다. 화면 배치가 권한을 나누는 보안 경계를 대신하지는 않는다. 실제 실행의 프로젝트·계정 소유권은 별도 계약이고 패널은 그것을 읽기 쉽게 만드는 표현이다.
React와 실제 웹 View가 같은 폭을 계산한다
panelBounds는 왼쪽·오른쪽·가운데 폭을 공통 함수로 계산한다. 접힌 패널은0이고 각 패널은 정해진 폭 범위 안에서 배치한다. 왼쪽을 펼쳤을 때 웹 자리가 너무 좁으면 실제 표시에서는 왼쪽을 숨기는 조건도 있다. 겉의 CSS와 실제 WebContentsView가 서로 다른 계산을 하지 않게 한 것이다.
네이티브 웹 View는 일반 DOM의 자식처럼 CSS만으로 배치되지 않는다. 외형상 경계선과 실제 클릭할 사이트의 영역이 다르면 입력 좌표와 가려짐도 어긋날 수 있다. 계산을 공유하면 수정할 기준이 하나가 된다. 아래 코드는 원래 읽은 배치 함수의 핵심이며 새로운 독립 실행 모듈이나 전 화면 검증으로 표시하지 않는다.
코드와 구현 살펴보기
읽은 원래 배치 함수의 핵심
let left = p.leftCollapsed ? 0 : Math.min(p.notebookWidth || 420, Math.max(320, width - 300));
const right = p.rightCollapsed ? 0 : Math.min(p.panelWidth, Math.max(320, width - 300));
if (left && width - left - right < 260) left = 0;
return { left, right, browser: Math.max(1, width - left - right) };패널을 닫아도 실행을 닫지는 않는다
주피터 열기 버튼과 오른쪽 토글은 layout 설정을 바꾼다. notebookBusy와isRunning 표시도 별도로 있다. 패널의 가시성과 실행기의 수명을 같은 boolean으로 만들지 않는다. 숨겼다가 다시 열어 실행 상태를 볼 수 있는 것과 작업을 중지하는 것은 다른 동작이다.
이 차이는 작은 화면에서 특히 중요하다. 결과를 넓게 보려고 패널을 닫았는데 실행까지 취소되면 사용자는 배치를 바꾸기 어렵다. 반대로 숨긴 패널 안에서 작업이 계속된다면 바깥의 활동 표시가 필요하다. 나는 화면 공간을 정리하는 행동과 업무 효과를 바꾸는 행동이 서로 대체되지 않도록 읽을 수 있는 상태를 남겼다.
너비 조절은 마우스와 키보드 모두에서 읽힌다
현재 주피터 경계는 pointer capture로 드래그를 따라가고 좌우 화살표로20픽셀씩 폭을 바꾸는 경로도 있다. 오른쪽 패널도 포인터 위치와 남은 웹 폭을 함께 제한한다. 저장할 선호 폭과 현재 창에서 실제로 표시할 폭을 공통 계산으로 연결한다.
과거 작업실 문서는 프로젝트·프로필별 접힘과 너비 기억, 좁은 창·실행 중 종료와 출력 복원 등의 검수 범위를 남겼다. 그 기록을 모든 화면 크기나 보조기기 접근성 완료로 넓히지 않는다. 셀 출력의HTML·JS를 실행하지 않고 텍스트로 보존하는 경계도 패널을 풍부한 웹 실행기로 오해하지 않게 한다. 보기 편함과 실행 능력은 다른 선택이다.
기억하는 배치는 다음 작업의 준비 시간을 줄인다
저장된 폭을 그대로 적용할 수 없는 좁은 창에서도 웹 결과를 읽을 자리를 남겨야 한다. 과거 실행의 배치를 기억하는 일과 지금 창에서 가능한 배치를 계산하는 일을 함께 둔 이유다. 기본값 하나로 모든 사람이 항상 세 칸을 써야 한다고 정하지 않았다.
이번에는 코드와 과거 검수를 읽었으며 실제 패널 드래그를 새로 실행하지 않았다. 원래 주피터와 로그인, 다른 프로젝트도 그대로 보존했다. 공유 상태 문구 모듈은 별도 합성 예제다. 내가 만들고 싶었던 작업실은 칸이 많은 화면보다 코드·대상·결과를 비교하는 데 필요한 자리와 맥락을 다시 찾기 쉬운 화면이었다. 화면이 접혀도 업무의 의미는 이어져야 한다.