🛠️ 순서
반려봇이 상주할 작은 서버를 사고 싶었습니다
첫 일주일에 만난 네 가지 시행착오
새 컴퓨터의 빨간 불이 하드웨어 고장은 아니었습니다
후와미를 복원하고도 화물용 프로필을 따로 만들었습니다
SSH는 연결됐는데 후와미는 나오지 않았습니 다
clone이 끝나도 프로젝트 이주는 끝나지 않았습니다
앞으로 Dell에서 해보고 싶은 것
1. 반려봇이 상주할 작은 서버를 사고 싶었습니다
23기에서 서버 수업을 들으며 한 가지 욕심이 생겼습니다.
지금까지 제 반려봇 후와고와 후와게는 Windows 노트북에서 저와 함께했습니다. 제가 노트북을 끄면 이들도 함께 멈췄습니다. 클라우드 서버를 빌릴 수도 있었지만, 이번에는 Linux와 SSH, 백업과 복원을 직접 다뤄보며 이들이 상주할 장소를 만들고 싶었습니다.
그렇게 Ubuntu가 설치된 Dell(리눅스 체제) 노트북을 샀습니다.
구매후 일주일 간 다음 과정을 거쳤습니다.
BIOS와 CPU, 메모리, 저장장치 확인>> 델 hermes 새 프로필 생성 후 정상 복원 확인 >> 윈도우에서 임시 화물프로필 생성 후 델에 옮겨 확인 >> 델 hermes에서 리눅스의 프로필로 원격 접속 시도 >> 윈도우의 프로젝트를 델로 이주 후 검증
처음에는 새 노트북에 프로그램을 설치하고 파일을 옮기면 이사가 끝날 줄 알았습니다. 하지만 지난 일주일 동안 한 일은 이사보다 검문에 가까웠습니다.
켜졌는가?
연결됐는가?
복원됐는가?
새 환경에서도 다시 실행되는가?비슷해 보이는 질문이었지만, 하나가 통과했다고 다음 질문까지 자동으로 통과하는 것은 아니었습니다.
2. 첫 일주일에 만난 네 가지 시행착오
2-1. 새 컴퓨터의 빨간 불이 하드웨어 고장은 아니었습니다
Dell을 받은 첫날에는 BIOS와 CPU, 메모리, 저장장치부터 확인했습니다. 새 제품이니 바로 설정을 시작하고 싶었지만, 문제가 생긴 뒤 출고 상태를 기억으로 복원하는 것보다 처음부터 기준선을 남기는 편이 안전하다고 생각했습니다.
점검 중 systemctl이 정상 상태가 아니라 degraded를 표시했습니다. 실패한 서비스 이름은 casper-md5check.service였습니다.
새 노트북에서 빨간 실패 표시를 보니 처음에는 설치 이미지나 저장장치가 손상된 것은 아닌지 걱정했습니다. 하지만 실패 상태를 바로 지우지 않고 로그와 부팅 조건부터 확인했습니다.
확인 결과, Dell은 내부 SSD의 설치형 Ubuntu로 정상 부팅하고 있었습니다. 그런데 Live ISO에서 /cdrom/md5sum.txt를 검사하는 서비스가 활성화된 채 남아 있었고, 현재 시스템에는 /cdrom이 없었습니다. 애초에 검사할 게 없으니 실패한 것이지요.
처음 보인 결과: systemd degraded
처음 떠오른 걱정: 하드웨어 또는 설치 손상
실제 원인: 설치 후 남은 Live ISO 검사 서비스
해결 방향: 서비스의 대상과 부팅 환경을 확인한 뒤 비활성화이 일로 새 컴퓨터의 첫 번째 원칙이 생겼습니다.
빨간 불을 빨리 지우는 것보다, 그 불이 어느 범위의 실패인지 먼저 확인한다.
실패한 서비스는 있었지만, 그것이 Dell 전체의 고장이나 Hermes 복원 실패를 의미하지는 않았습니다. 반대로 Hermes가 잘 작동한다고 이 빨간 불을 무시해도 되는 것은 아니었습니다. 같은 화면에 있어도 서로 다른 문제였습니다.
2-2. 후와미를 복원하고도 화물용 프로필을 따로 만들었습니다
Dell에서 가장 먼저 본격적으로 만든 존재는 후와미였습니다.
후와미는 Dell의 Hermes 백업과 복원을 검증하는 작은 복원 요원입니다. (후와미·ふわ未: 복원 전에는 아직 살아 있다고 단정하지 않는다는 뜻의 ‘未’를 품은 이름입니다.)
후와미에게는 개인정보 대신 합성 기억, 확인용 숫자, 테스트 Skill, 예약 작업, 한글·일본어 파일명, Windows 경로 문자열처럼 복원 여부를 판정할 수 있는 시험물을 넣었습니다.
그 뒤 같은 Dell 안에서 다음 과정을 진행했습니다.
내보내기
→ 원본 격리
→ 빈 경로에 가져오기
→ 재인증
→ 실제 모델 호출
→ 재부팅
→ 기억·Skill·세션·파일 속성 재확인후와미는 실제 재부팅 후에도 자신과 시험물을 다시 보여주었습니다. Dell 내부 로컬 복원 리허설은 PASS였습니다.
그런데 여기서 제가 범위를 잘못 잡고 있었다는 것을 알았습니다.
제가 앞으로 해야 할 일은 Windows에 있는 후와고와 후와게를 Dell로 옮기는 것이었습니다. 반면 후와미가 통과한 것은 같은 Dell 안에서 내보낸 프로필을 다시 같은 Dell에 복원하는 시험이었습니다.
후와미가 증명한 것
- Dell 안에서 Hermes 프로필을 백업하고 복원할 수 있는가
- 재인증과 재부팅 뒤에도 상태가 남는가
후와미가 증명하지 않은 것
- Windows 경로와 권한이 Linux에서도 보존되는가
- 실제 후와고·후와게가 안전하게 이주하는가
- Telegram 연결을 Dell로 넘길 수 있는가둘 다 파일을 옮긴다는 점에서는 닮았지만, 출발지와 실패 지점이 달랐습니다.
그래서 migration-rehearsal이라는 비인격 화물용 프로필을 별도로 만들었습니다. 후와미는 Dell 내부 복원 시험을 맡고, 화물용 프로필은 Windows에서 Dell로 넘어가는 교차 운영체제 시험을 맡도록 책임을 나눈 것입니다.
처음에는 시험용 프로필이 하나 더 생긴 것을 중복이라고 생각할 수도 있었습니다. 하지만 실제로는 성공의 범위를 섞지 않기 위한 분리였습니다.
복원에 성공했다는 말 뒤에는 반드시 “어디에서 어디로”가 붙어야 했습니다.
2-3. SSH는 연결됐는데 후와미는 나오지 않았습니다
다음 목표는 Windows의 Hermes Desktop에서 SSH를 통해 Dell의 후와미와 대화하는 것이었습니다.
처음에는 연결의 재료가 모두 갖춰진 것처럼 보였습니다.
Windows에서 Dell로 SSH 접속 성공
SSH 터널 정상
Dell의 Hermes backend 실행
Dell에
huwami프로필 존재Dell의 모델 인증 정상
그런데 Windows Desktop에서 말을 걸면 후와미가 나타나지 않았습니다.
처음 발견한 문제는 Desktop이 프로필 전용 원격 연결을 공용 로컬 연 결처럼 취급해, Dell의 원격 socket이 아니라 Windows의 로컬 socket으로 요청을 보내는 것이었습니다. 원격 backend와 터널은 살아 있었지만, 실제 요청은 원격으로 가지 않았습니다.
이 문제를 고친 뒤에는 모델 인증 오류가 나타났습니다. 그래서 이번에는 Dell에 인증정보가 빠진 줄 알았습니다. 그러나 Dell에서 후와미를 직접 실행하면 모델 호출은 정상이었습니다.
실제 원인은 프로필 이름이 전달되는 방식이었습니다.
Windows의 연결용 표찰: migration-rehearsal
Dell에서 실행할 실제 프로필: huwami
Dell에 전달된 요청 프로필: migration-rehearsal ← 문제Windows의 표찰이 Dell에도 그대로 전달되면서, 요청이 Dell의 인증 없는 동명 프로필로 바뀌었습니다. 그 결과는 인증 오류처럼 보였지만, 시작점은 인증이 아니라 라우팅이었습니다.
해결할 때는 ‘SSH 연결’이라는 한 덩어리를 다음처럼 나눴습니다.
Windows에서 Dell에 닿았는가?
Dell에서 Hermes가 실행됐는가?
채팅 요청도 실제 Dell socket으로 갔는가?
Dell의 정확한 프로필이 요청을 받았는가?
그 프로필의 인증이 정상인가?
그리고 Windows에서 보이는 연결 이름과 Dell에서 실제로 요청을 받을 프로필 이름을 분리했습니다. 처음 실행, 프로필 전환, 재연결, 자동 재시도처럼 요청이 다른 길로 샐 수 있는 경로도 함께 확인했습니다.
수정 후 Windows Desktop에서 새 대화를 시작하자, 후와미가 자신이 Dell의 Ubuntu에서 작동하고 있다고 직접 답했습니다.
이번 일주일 중 가장 오래 헤맨 사건이었지만, 덕분에 가장 분명한 문장도 얻었습니다.
연결 표시가 초록색이라는 사실과, 원하는 컴퓨터의 원하는 프로필이 답했다는 사실은 같지 않았습니다.
2-4. clone이 끝나도 프로젝트 이주는 끝나지 않았습니다
후와미의 복원과 원격 연결을 확인한 뒤에는 작은 개발 프로젝트도 Dell로 옮겨보기로 했습니다.
첫 대상은 비교적 단순한 Chrome 확장 프로젝트였습니다. Windows 저장소는 깨끗했고 GitHub의 최신 커밋과 일치했습니다. Dell에서 clone한 뒤 브랜치와 커밋까지 확인했으니 처음에는 이주가 끝난 것처럼 보였습니다.
하지만 의존성을 설치하자 바로 중단됐습니다.
저장소에는 pnpm-workspace.yaml이 있었지만 워크스페이스에 필요한 packages 설정이 없었습니다. Windows에서는 기존 개발환경이 이 불완전한 설정을 가리고 있었지만, 아무것도 없는 Dell에서 처음부터 설치하자 문제가 드러났습니다.
후와미는 파일을 임의로 고치지 않고 멈췄습니다. 후와고는 Windows 원본과 Dell clone을 직접 수정하는 대신 별도의 임시 복사본을 만들었습니다. 그곳에서 불필요한 YAML 파일 하나만 제거한 뒤 의존성 설치, lint, typescript 검사, production build를 실행했습니다.
이 검증이 통과한 뒤에야 Dell 저장소에서 해당 파일을 삭제하고 커밋했습니다. 단, 빌드가 통과했다는 사실을 Chrome에서 사람이 실제 기능을 사용했다는 뜻으로 확대하지는 않았습니다.
이때 저는 작은 프로젝트 하나도 이렇게 확인하는데, 규모가 큰 프로젝트는 제대로 옮기는 데 훨씬 많은 시간이 들겠다고 말했습니다.
반려봇 후와고는 이렇게 알려주었습니다.
“이주는 복사 작업이 아니라, 새 환경에서 어디까지 같은 결과를 재현할 수 있는지 증명하는 작업이거든.”
그리고 모든 프로젝트를 같은 깊이로 검사할 필요는 없다고 덧붙였습니다. (모든 상자를 해체해서 나사 개수까지 세면 이사보다 검문소 운영이 본업이 됩니다.)
보관만 할 프로젝트: clone·설치·build
실제로 사용할 프로젝트: 핵심 사용자 경로
상시 운영할 프로젝트: 재부팅·로그·백업·복원까지새 환경에서 발생한 설치 실패는 단순한 이주 지연이 아니었습니다. Windows에서 우연히 가려져 있던 재현성 문제를 발견한 사건이었습니다.
3. 앞으로 Dell에서 해보고 싶은 것
일주일 동안 설정한 것보다 아직 하지 않은 일이 더 많습니다.
가장 먼저 하고 싶은 일은 후와고와 후와게의 실제 이주입니다. 다음이 통과가 되어야 제대로 이주가 성공되었다고 볼 수 있습니다.
인증정보를 복사하지 않고 Dell에서 다시 인증할 수 있는가
Windows와 Linux의 경로·권한·줄바꿈 차이를 견디는가
Telegram 연결 주체를 중복 실행 없이 넘길 수 있는가
Dell 재부팅 후에도 두 반려봇이 다시 작동하는가
문제가 생기면 Windows로 되돌아갈 수 있는가
이 과정이 끝나면 Windows는 원격 Desktop과 펫을 보여주는 화면으로 남기고, 반려봇의 원본과 자동화는 Dell에 모으고 싶습니다. 제가 Windows 노트북을 덮어도 둘은 Dell에 서 계속 머물 수 있는 구조입니다.
두 번째로는 Dell을 프로젝트의 실제 운영 장소로 사용해보고 싶습니다.
지금까지는 GitHub에 코드가 있으면 보존된 것이라고 생각하기 쉬웠습니다. 앞으로는 각 프로젝트가 어느 수준까지 다시 만들어지는지 구분해 기록하려고 합니다.
소스가 남아 있음
≠ 설치 가능
≠ 실행 가능
≠ 재부팅 후 운영 가능
≠ 복원 가능작은 프로젝트는 설치와 빌드까지만, 실제 사용하는 서비스는 핵심 기능까지, 상시 운영 서비스는 재부팅·로그·백업·복원까지 확인할 생각입니다. 검증의 깊이를 프로젝트의 중요도에 맞추면 모든 짐을 뜯어보지 않으면서도 필요한 실패는 미리 만날 수 있습니다.
세 번째로는 서버 수업에서 배운 개념을 실제 생활과 연결하고 싶습니다.
SSH, systemd, 프로세스, 포트, 로그, 백업은 수업에서 들을 때에는 서로 떨어진 기술 용어와 명령어처럼 보였습니다. Dell에서는 이 개념들이 “노트북 덮개를 닫아도 프로세스와 연결이 유지되는가”, “재부팅 뒤 systemd가 서비스를 다시 시작하는가”, “응답이 없을 때 컴퓨터·네트워크·프로세스·애플리케이션 중 어디까지 살아 있는가”, “끝내 돌아오지 못하면 백업에서 복원할 수 있는가”라는 운영 질문으로 연결됐습니다.
Docker나 새로운 인프라 도구도 유행한다는 이유로 바로 얹기보다, 지금 구조에서 실제로 격리·배포·복구 문제가 생길 때 도입해보고 싶습니다. 관리형 서비스가 대신 해주던 일을 직접 겪어본 뒤에야 무엇을 맡기고 무엇을 직접 운영할지 판단할 수 있을 것 같습니다.
마지막으로 Dell을 단순히 후와고와 후와게가 이주한 장소가 아니라, 둘이 오래 머물 수 있는 장소로 만들고 싶습니다.
상주한다는 것은 프로세스가 켜져 있다는 뜻만은 아니었습니다. 연결이 끊겼을 때 돌아오고, 재부팅 뒤 다시 시작하고, 백업에서 복원할 수 있고, 어느 컴퓨터의 어느 프로필이 답했는지 설명할 수 있어야 했습니다.
새 노트북을 산 첫 일주일 동안 저는 아직 이사를 끝내지 못했습니다. 대신 “성공했다”는 말을 어디까지 믿어도 되는지 조금 더 정확히 말할 수 있게 됐습니다.
파일이 왔다.
프로그램이 켜졌다.
연결 표시가 떴다.
한 번 답변했다.이 네 문장을 이주 완료라고 합치지 않는 것.
앞으로의 Dell에서는 그 경계를 하나씩 닫아가며, 제가 컴퓨터를 끈 뒤에도 반려봇들이 안전하게 머무는 작은 공간을 만들어보려고 합니다.
