GitHub Codespaces를 iPad로 6개월 굴려봤다 — 되는 일과 여전히 걸리는 것

출장 갈 때 노트북을 안 챙긴 지 6개월이 넘었다. 아이패드 11에 블루투스 키보드를 물리고, 코드는 전부 GitHub Codespaces에서 돌린다. 처음엔 "브라우저에서 코딩이 되겠어?" 하는 반신반의였는데, 지금은 코드 리뷰와 간단한 기능 수정 정도는 이 조합으로 그냥 처리한다. 이 글은 단계별 따라하기 가이드가 아니다. 이 조합을 반년 굴리면서 뭐가 잘 됐고, 어디서 걸렸는지의 기록이다.

iPad에서 왜 로컬이 아니라 GitHub Codespaces인가

답은 간단하다. iPadOS에는 쓸 만한 로컬 개발 런타임이 없어서, 연산을 통째로 클라우드에 넘기는 GitHub Codespaces가 사실상 유일한 현실적 선택이었다.

iPad에는 Xcode를 못 깔고, 네이티브 터미널도 제한적이고, Node.js나 Python을 로컬에서 직접 돌릴 방법이 사실상 없다. Mac이라면 nvm으로 Node.js 버전을 관리하는 식으로 풀면 되지만, iPad에서는 그 선택지 자체가 존재하지 않는다. Codespaces는 이 문제를 구조적으로 우회한다. Azure 위의 컨테이너에서 VS Code Server가 돌고, iPad는 화면과 키보드 역할만 한다. 무거운 건 전부 저쪽 몫이다.

여기서 하나 구분할 게 있다. 레포지토리에서 . 키를 누르면 열리는 github.dev는 에디터만 제공하고 터미널이 없다. 코드 구경이나 오타 수정은 거기서도 되지만, 빌드하고 서버 띄우는 건 완전한 컴퓨팅 인스턴스를 할당받는 Codespaces에서만 가능하다. 이 차이를 모르면 "터미널이 왜 없지"부터 헤매게 된다.

6개월 루틴 — 접속 방식과 브라우저 정착기

브라우저는 결론부터 말하면 Safari다.

Chrome for iPad도 동작은 한다. 근데 외장 키보드 단축키가 브라우저 단축키와 충돌하는 빈도가 Safari보다 높았고, 특히 Cmd+W가 에디터 탭이 아니라 브라우저 탭 닫기로 먹혔다. 솔직히 이것 때문에 작업 중이던 탭을 날린 게 두세 번이라, 결국 Safari로 정착했다.

Safari 쪽도 그냥 쓰면 안 되고, 설정에서 미리 만져둔 게 세 가지 있다.

데스크탑 웹 사이트 요청 켜기 — 모바일 레이아웃으로 열리면 에디터가 제대로 안 나온다.
팝업 차단 끄기 — Codespaces 인증 리다이렉트가 팝업 차단에 걸리는 걸 방지한다.
탭 자동 닫기를 "수동"으로 — 오래 띄워두는 Codespaces 탭이 Safari에 의해 정리되는 사고를 막는다.

접속 자체는 어려울 게 없다. 레포의 Code 버튼에서 Codespaces 탭을 열어 만들거나, github.com/codespaces 대시보드에서 관리하거나, codespaces.new/<owner>/<repo>로 바로 생성하는 세 가지 경로가 있다. 6개월 쓰다 보면 새로 만드는 일보다 기존 것에 재접속하는 일이 압도적으로 많아서, 나는 대시보드를 즐겨찾기에 박아두고 거기서 시작한다. 처음 만들 때는 컨테이너를 빌드하느라 몇 분 기다리게 되고, devcontainer 설정이 없는 레포는 GitHub 기본 이미지(Ubuntu 기반 + 기본 개발 도구)로 뜬다.

무료 티어로 6개월 버틴 운용법

2코어 머신에 idle timeout 15분 조합이면 무료 티어로 충분하다. 나는 6개월 동안 무료 범위를 넘긴 적이 한 번도 없다.

GitHub Free 플랜은 매월 120 코어시간을 준다. 가장 작은 2코어 머신 기준으로 월 60시간이고, 4코어를 고르면 그대로 반토막 난다. 스토리지는 월 15GB까지 무료다. 코드 리뷰와 가벼운 수정이 주 용도라면 2코어로 부족한 걸 못 느꼈고, 머신을 키우고 싶은 유혹보다 시간이 깎이는 속도가 더 무섭다. 정확한 요금 기준은 수시로 바뀌니 GitHub Codespaces 공식 문서에서 확인하는 게 맞다.

진짜 함정은 머신 스펙이 아니라 방치다. Codespace를 켜두고 잊으면 사용 시간이 계속 카운트된다. 그래서 idle timeout을 기본 30분에서 15분으로 줄여뒀다. 그리고 iPad에서 특히 주의할 것 — 브라우저 탭을 닫는 건 Codespace 중지가 아니다. timeout이 지날 때까지 계속 돌아간다. 확실하게 끄고 싶으면 CLI가 편하다.

# 실행 중인 Codespace 확인 (탭 닫기만으로는 즉시 안 꺼진다)
gh codespace list

# 골라서 중지
gh codespace stop

# 안 쓰는 것 삭제 — 스토리지 과금 대상에서 제외
gh codespace delete

사용량은 GitHub Settings의 Billing 메뉴에서 확인할 수 있다. 비활성 Codespace의 자동 삭제 기간(retention)도 기본 30일인데, 나는 스토리지 아끼려고 줄여서 쓴다. 커밋 안 한 작업이 그 안에 있으면 같이 사라지니 이건 각자 습관에 맞춰 정할 문제다.

devcontainer.json 하나가 만족도를 갈랐다

6개월 중 만족도가 눈에 띄게 올라간 계기는 devcontainer.json을 세팅한 시점이었다.

이 파일이 없던 초반에는 Codespace를 새로 만들 때마다 확장 프로그램 깔고, 에디터 설정 맞추고, 의존성 설치하는 걸 반복했다. 레포에 .devcontainer/devcontainer.json을 넣어두면 생성 시점에 이게 전부 자동으로 구성된다. 뼈대는 이 정도면 충분하다.

// .devcontainer/devcontainer.json — 최소 뼈대 예시
{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:20",
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
      ],
      "settings": {
        "files.autoSave": "afterDelay",
        "files.autoSaveDelay": 500
      }
    }
  },
  "postCreateCommand": "npm install",
  "forwardPorts": [3000]
}

프로젝트 성격에 따라 이미지와 확장 목록만 갈아 끼우면 된다. 팀 프로젝트라면 전원이 동일한 환경을 즉시 받는다는 것도 덤이다.

주의할 건 API 키 같은 민감한 값이다. devcontainer.json은 레포에 커밋되는 파일이라 여기 넣으면 안 되고, GitHub Settings의 Codespaces Secrets에 등록한다. CLI로는 gh secret set 이름 --app codespaces 한 줄이다. 등록해두면 Codespace 안에서 환경변수로 자동 주입된다. 다만 화면 공유나 캡처 중에 printenv류 명령을 치면 시크릿이 그대로 노출되니, iPad로 밖에서 작업할 일이 많다면 이건 진짜 조심해야 한다.

여전히 걸리는 지점 4가지

6개월을 썼는데도 매끈해지지 않는 부분들이 있다. 이 조합을 고민 중이라면 장점보다 이쪽을 먼저 봐야 한다.

1. 키보드 단축키 충돌

외장 키보드는 사실상 필수다. 화면 키보드로는 코딩이 거의 불가능하다. 블루투스 키보드를 물리면 명령 팔레트, 터미널 토글(Ctrl+`), 멀티커서까지 대부분의 VS Code 단축키가 동작하는데, 딱 두 개가 끝까지 말썽이었다. Cmd+W는 브라우저 탭을 닫아버리고, Cmd+,는 VS Code 설정 대신 iPad 설정 화면을 띄운다. 해법은 하나로 수렴한다 — 충돌하는 동작은 전부 명령 팔레트(Cmd+Shift+P)에서 이름으로 검색해 실행하는 것. 손에 익으면 오히려 이쪽이 빠를 때도 있다.

2. 네트워크가 끊기면 불안하다

iPad는 이동 중이나 불안정한 Wi-Fi에서 쓰는 일이 많다. 연결이 끊기면 VS Code가 재연결을 시도하긴 하는데, 저장 안 된 편집 내용이 걸린다. 그래서 자동 저장을 짧게 잡아두는 게 보험이 된다.

// VS Code settings — 끊기기 전에 저장되도록
{
  "files.autoSave": "afterDelay",
  "files.autoSaveDelay": 500
}

그래도 근본 대책은 수시로 커밋하는 습관이다. 네트워크가 끊긴 사이 idle timeout이 지나 Codespace가 중지돼도 변경사항은 재시작 때 복원되지만, Codespace 자체가 삭제되면 커밋 안 한 건 복구할 방법이 없다.

3. 파일 업로드/다운로드가 번거롭다

iPad 로컬 파일을 Codespace에 올리는 건 Files 앱에서 드래그앤드롭으로 되긴 하는데, Safari에서 간헐적으로 안 먹는다. 내려받기는 파일 탐색기에서 우클릭 후 Download를 쓴다. 이것저것 겪어본 결론은 시시하게도, 파일을 git에 커밋해서 주고받는 게 제일 안정적이라는 것이다. 웹에 있는 파일이면 터미널에서 curl로 바로 받는 게 낫고.

4. 결국 내 Mac이 필요한 일이 있다

클라우드 컨테이너가 아니라 내 컴퓨터 자체가 필요한 작업 — 로컬 전용 앱, GUI 프로그램, 대용량 파일 — 은 Codespaces로 안 풀린다. 나는 이런 건 iPad에서 Mac에 원격 접속하는 쪽으로 분리해서 처리한다. Docker는 devcontainer의 docker-in-docker feature로 Codespaces 안에서도 돌릴 수 있지만, 2코어 무료 머신에서는 오버헤드를 각오해야 한다.

그래서 누구한테 맞는 조합인가

코드 리뷰, 문서 작업, 작은 기능 수정이 이동 중 업무의 대부분이라면 iPad와 GitHub Codespaces 조합으로 충분하다. 반대로 하루 종일 붙어 있는 메인 개발 머신을 대체하려는 거라면 아직 아니다.

6개월을 써보고 남은 감각은 "노트북의 대체"가 아니라 "노트북을 안 들고 나가도 되는 날의 확장"이다. 무료 티어 안에서 굴러가고, 세팅은 devcontainer가 기억해주고, 걸리는 지점은 위 네 가지 정도로 예측 가능하다. 그 선을 알고 쓰면 꽤 괜찮은 조합이고, 모르고 시작하면 단축키 충돌에서부터 짜증이 쌓일 거다.