H100에 파일 하나 올리는 데 이틀 걸린 이야기¶
연구실 H100 사용 매뉴얼의 파일 전송 챕터를 쓰려고 SFTP 업로드를 검증하다가, 파일 하나 올리는 데 이틀이 걸렸다. 결과만 보면 원인은 한 줄인데, 그 한 줄에 도달하는 과정에서 네트워크 계층과 권한 계층을 한 바퀴 돌았다. 당시 기록에 "나는 몽총 관리자이다"라고 적어놨을 정도로 자책했지만, 지나고 보니 이 삽질이 매뉴얼에서 제일 가치 있는 챕터가 됐다.
배경: 내 키로는 접속할 수 없는 구조¶
연구실은 학내 쿠버네티스 기반 GPU 클라우드에서 H100 워크스페이스 하나를 계정 하나로 전원이 공유한다. 워크스페이스에는 생성 시점에 SSH 공개키가 하나만 등록되고 이후 추가할 방법이 없다. 워크스페이스를 만든 건 내가 아니었으므로, 내 개인키로는 인증 자체가 불가능했다.
처음엔 등록된 개인키를 공유받는 방법까지 검토했는데, 웹 콘솔을 뒤지다가 워크스페이스와 별개로 SFTP 서버를 따로 만들 수 있는 메뉴를 찾았다. 볼륨을 지정하고 본인 공개키를 등록하면 그 볼륨으로 통하는 전송 전용 입구가 생기는 구조다. 키 공유 문제가 깔끔하게 사라졌고, 여기까지는 순조로웠다.
Operation timed out¶
서버를 만들고 접속한 첫 시도의 결과:
교내망에서 시도한 거라 당황했지만, 에러 문구가 이미 원인의 범위를 좁혀주고
있었다. 키가 틀리면 Permission denied, 서버가 죽어 있으면 Connection
refused가 뜬다. Operation timed out은 인증 단계까지 가지도 못하고 패킷이
목적지에 닿지 않았다는 뜻이다. 즉 이 시점에 키와 설정을 의심하는 건 시간
낭비고, 봐야 할 것은 네트워크 경로다.
경로를 확인했다. nc로 포트를 찔러도 동일하게 timeout. traceroute를
돌리니 패킷이 교내망 코어 대역까지는 정상적으로 들어가다가 마지막 구간에서
* * *로 끊겼다. 내 노트북이나 명령어 문제가 아니라, 어딘가의 경계에서
막히고 있다는 뜻이었다.
첫 가설은 포트 범위였다. SFTP 서버 목록을 보니 정상적으로 쓰이고 있는 서버들의 포트가 46771, 47728, 57284로 전부 4만번대 이상인데 내 서버만 11339였다. 방화벽이 특정 고포트 대역만 열어둔 것이라면 모든 증상이 설명된다. 포트는 자동 할당이라 지정할 수 없었지만, 서버가 내 소유라 지웠다 다시 만드는 데 부담이 없었다. 몇 번의 재생성 끝에 5만번대 포트를 받았다.
결과는 그대로 timed out. 가설 기각이다.
진범은 접속하는 쪽 네트워크였다¶
포트가 아니라면 남는 변수는 내가 접속하는 망이다. 나는 연구실 개인 공유기 뒤(이중 NAT)에서 무선으로 붙어 있었다. 같은 "교내망"이라도 무선·개인 공유기 대역에서는 GPU 노드로 가는 라우팅이 막혀 있었던 것이다. 그동안 웹 콘솔이 잘 열려서 망은 문제없다고 단정했는데, 웹은 도메인과 프록시를 경유하는 전혀 다른 경로였다. "웹이 된다"는 "노드 IP에 닿는다"의 근거가 되지 못한다.
그래서 유선으로 옮겼는데, 여기서 예상 못 한 단계가 하나 더 있었다. 캠퍼스 유선 포트는 망 사용 등록을 해야 활성화되는 정책이라, 케이블을 꽂아도 IP만 할당받고 라우팅이 되지 않았다. 등록을 마치고 나니 이번엔 브라우저가 안 열렸다. 확인해 보니 DNS가 내려오지 않은 것인데, SFTP 목적지는 도메인이 아니라 IP 직결이라 DNS와 무관하다. 인터넷이 안 되는 회선에서 그대로 포트를 찔렀다.
이틀 만에 처음 보는 succeeded였다.
마지막 관문: 같은 볼륨, 다른 신분¶
연결이 됐다고 끝은 아니었다. put으로 파일을 올리자 Permission denied.
이번엔 진짜 권한 문제였고, 원인은 명확했다. Web Terminal은 root로 컨테이너에
들어가지만 SFTP 서버는 aipub이라는 별도 사용자로 볼륨에 접근한다. root
소유로 만들어진 폴더에 aipub은 쓰기 권한이 없다. 같은 볼륨에 입구가 두 개인데
신분이 다른 구조라, 업로드 대상 폴더의 권한을 열어주는 것으로 해결됐다.
업로드된 파일이 워크스페이스 터미널의 /lab 경로에서 보이는 것까지 확인하고
나서야 검증이 끝났다.
남은 것¶
이틀짜리 미스터리의 답은 "어느 망에서 접속하느냐" 한 줄이었다. 키도 서버도 명령어도 처음부터 전부 맞았다. 대신 이 과정에서 남은 것들이 있다.
증상 분류가 디버깅의 절반이다. timeout / refused / denied는 각각 네트워크 경로, 서버 상태, 인증·권한이라는 다른 계층을 가리킨다. 처음에 이 구분을 잡은 덕에 키를 붙잡고 헤매는 최악의 경로는 피했다.
기각된 가설도 수확이다. 포트 범위 가설은 틀렸지만, 검증하는 과정에서 재생성 시 포트가 바뀐다는 사실과 노드 앞 방화벽의 존재를 확인했고, 이건 전부 매뉴얼의 트러블슈팅 항목이 됐다.
삽질은 문서 한 줄로 압축된다. "업로드는 유선 교내망에서만 — 무선·개인 공유기 망은 차단됨"이라는 한 줄이면 동료들은 이 이틀을 건너뛴다. 운영 정책도 이때 정리했다. SFTP 서버는 필요할 때 본인 키로 만들고 쓰고 나면 지운다. 절대 지우면 안 되는 공유 워크스페이스와 수명 정책이 정반대라, 이 대비를 명시하는 게 사고 방지의 핵심이었다.
이 내용을 포함해 온보딩 매뉴얼을 v1부터 v2.2까지 개선했고, 직접 검증한 절차만 싣는다는 원칙으로 썼다. 마스킹판을 문서 페이지에 올려뒀다. 그리고 GPU 인프라를 사용자가 아니라 운영자 입장에서 겪은 이 경험이, 지금 이 사이트가 돌아가는 홈 클라우드를 만드는 바탕이 됐다.
이 워크스페이스에서 겪은 다른 이야기도 이어진다: GPU 쿼터 미스터리 · 알고 보니 쿠버네티스 위였다