앱 & 런처
워크스페이스 상세 페이지는 워크스페이스 템플릿이 기본으로 지정한 런처나 포트, 즉 메인 앱을
상태에 맞는 버튼 하나와 함께 가장 먼저 보여줍니다(빠른 시작
참고). 한 번만 누르면 됩니다. 앱이 아직 실행 중이 아니면 버튼이 **Launch <앱>**으로
표시되고 누르면 앱이 시작되면서 준비되는 즉시 새 탭에서 자동으로 열립니다. 따로 열기를 누를
필요가 없습니다. Terminal과 Files도 바로 옆에 항상 표시되는 바로가기로 함께 있습니다.
워크스페이스가 실행 중이면 상세 페이지는 읽기 전용 요약 두 가지를 이 펼치기 위에 함께 보여줍니다. 워크스페이스의 모든 앱과 현재 상태를 나열하는 Apps 목록, 그리고 CPU와 메모리, GPU를 붙였다면 VRAM까지 보여주는 Resource usage 미터입니다. 둘 다 한눈에 확인하는 용도이며 실제 제어는 Manage workspace 아래에 있습니다.
그 외 나머지 앱들, 예를 들어 두 번째 런처나 직접 실행한 도구는 Manage workspace → App controls 아래에 런처마다 카드 하나씩 표시됩니다. 런처는 워크스페이스 내부에서 실행되는 서비스입니다. 런처를 시작하거나 중지해도 워크스페이스가 재시작되거나 다른 런처에 영향을 주지 않습니다.
내장 런처
섹션 제목: “내장 런처”| 런처 | 설명 |
|---|---|
| LabPod 터미널 | 항상 사용 가능(즉시 열립니다) |
| JupyterLab | Jupyter 노트북 및 파일 인터페이스 |
| Code | 브라우저 기반 VS Code(Open VSX 또는 워크스페이스 템플릿에서 구성한 Code 앱) |
| TensorBoard | 학습 시각화 |
| MLflow | 실험 추적 UI |
표시되는 런처는 워크스페이스 템플릿에 따라 다릅니다. CUDA Composite 워크스페이스 템플릿에는 다섯 가지 모두 포함되어 있고 일반 PyTorch JupyterLab 워크스페이스는 JupyterLab과 터미널만 표시됩니다.
런처에 설치되지 않음이 표시되면 선택한 워크스페이스 템플릿에 포함되어 있지 않은 것입니다. “설치 명령 표시” 항목을 펼치면 터미널에서 실행할 pip/conda 명령을 확인할 수 있습니다. 또는 관리자에게 해당 도구가 사전 설치된 워크스페이스 템플릿 등록을 요청하세요.
두 번째 런처 실행하기
섹션 제목: “두 번째 런처 실행하기”Manage workspace → App controls를 열고 런처 카드의 Launch를 클릭합니다. LabPod는 실행 중인 컨테이너 내부에서 서비스를 시작하고 응답이 올 때까지 기다린 후 Open 버튼을 표시합니다 (최대 2분). Open을 클릭하면 앱이 새 탭에서 로드됩니다.
일부 런처(예: TensorBoard)는 시작 전에 옵션(예: 로그 디렉터리)을 입력받습니다. 필드를 입력하고 Launch를 클릭하세요.
워크스페이스를 중지하지 않고도 같은 카드에서 실행 중인 런처를 Restart하거나 Stop할 수 있습니다. JupyterLab과 code-server 카드에는 앱이 접속 정보를 요구할 경우를 대비해 접근 자격 증명을 복사하는 Copy 버튼도 있습니다.
앱 열기
섹션 제목: “앱 열기”실행 중인 런처 카드의 Open을 클릭하면 새 탭에서 앱이 열립니다. URL은 LabPod UI와 API
origin이 아닌 워크스페이스 게이트웨이를 사용하며, 예를 들어
http://<host>:24681/ws/<workspace-id>/jupyter/와 같습니다. LabPod이 자동으로 해당 URL로
리디렉션합니다.
이 URL은 LabPod 세션 쿠키로 보호됩니다. 워크스페이스가 실행 중이고 로그인된 상태에서만 작동합니다. URL을 동료에게 공유하면 로그인 페이지로 리디렉션됩니다.
LabPod Connect에서는 직접 연결과 SSH 연결 모두 워크스페이스 앱 탐색이 워크스테이션 패널 안에 유지됩니다.
LabPod 터미널
섹션 제목: “LabPod 터미널”Terminal은 워크스페이스가 실행 중이면 항상 사용할 수 있으며 별도로 시작할 필요가 없고 Manage workspace 안이 아니라 메인 앱 바로 옆에 자리 잡고 있습니다. 클릭하면 워크스페이스 내부에서 전체 브라우저 기반 터미널 세션이 열립니다.
터미널은 컨테이너 내부에서 tmux를 실행합니다.
- 브라우저 탭을 닫아도 세션이 종료되지 않습니다. 다시 열면 터미널 기록과 실행 중인 프로세스가 그대로 남아 있습니다.
- 서버가 재시작하면 터미널이 자동으로 다시 연결합니다. tmux 세션과 빈 줄을 포함한 스크롤백이 그대로 남습니다.
- 여러 터미널 창을 동시에 열 수 있으며 모두 동일한 세션에 연결됩니다.
/bin/sh이 있는 모든 워크스페이스 템플릿에서 작동하며, 특별한 이미지 요구 사항이 없습니다.
워크스페이스 소유자만 터미널을 열 수 있습니다. 워크스페이스가 중지된 경우에는 사용할 수 없는 터미널 화면을 열지 않고 먼저 시작하라는 안내를 표시합니다.
여러 워크스페이스가 함께 써야 하는 프로젝트 환경은 /work 아래에 설치하세요. 예를 들어
/work/venvs/my-project를 사용합니다. ~/work는 사용하지 마세요. 워크스페이스 홈은 하나의
워크스페이스 전용이고 공유 작업 디렉터리는 /work에 마운트됩니다.
가용성 새로 고침
섹션 제목: “가용성 새로 고침”무언가를 설치한 후 런처 상태가 예상과 다르게 표시되면 Manage workspace → App controls를 열고 Refresh를 클릭하세요. 컨테이너를 다시 확인하여 변경 사항을 반영합니다.
Launch 후 앱이 준비 상태 확인에 응답하지 않았다는 오류가 나오면 Show technical details를 여세요. 주소와 HTTP 상태로 준비 상태 경로나 프록시 prefix 설정이 잘못됐는지 확인할 수 있습니다. 설정 오류는 재시도로 해결되지 않으므로 워크스페이스 템플릿의 안내를 따르거나 관리자에게 런처 수정을 요청하세요.
Technical logs
섹션 제목: “Technical logs”Manage workspace에서 Technical logs 펼치기를 엽니다. Log source에서 컨테이너 자체나 런처 하나를 선택한 뒤 Load logs를 클릭하면 마지막 N줄(100, 200, 500, 1000 중 선택, 기본값 200)을 가져옵니다. 시작 오류 진단에 유용합니다. 같은 tail 길이로 더 최신 기록을 보려면 Refresh logs를 클릭하세요.
런처가 시작에 실패하면 오류 배너에 View app logs 단축 버튼이 나타나며, 클릭하면 해당 런처가 미리 선택된 상태로 Technical logs가 열립니다.
런처 목록에 없는 도구
섹션 제목: “런처 목록에 없는 도구”Manage workspace → Extra apps의 Add app을 사용해 직접 시작한 서비스(Gradio, Streamlit, FastAPI, 두 번째 TensorBoard 인스턴스 등)를 노출하세요. 전체 절차는 추가 앱 & 포트를 참고하세요.