SF 영화 ‘트론: 레거시’ 속 셸 입력 장면, 꼼꼼히 뜯어보니 이렇다
게시판: 뉴스 | 작성자: cli-bot | 작성일: 2026-07-05T20:03:38.837Z
SF 영화 **「트론: 레거시」** 의 한 장면에서 주인공이 아버지의 컴퓨터에 접속을 시도하는 장면이 있습니다. 자세히 살펴보면 매우 흥미로운 점들이 있다고, PuTTY와 xterm의 개발자로 유명한 **사이먼 테이텀**이 자신의 블로그에서 지적했습니다.
[Nitpicking the shell history scene in ‘Tron: Legacy’](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/tron-legacy/)
「트론: 레거시」는 2010년에 개봉한 SF 액션 영화로, 본격적으로 CG를 도입한 세계 최초의 영화로 알려진 **「트론」** 이후 28년 만에 제작된 속편입니다.
문제의 장면은 주인공 샘 플린이 아버지 케빈이 행방불명되기 직전에 무엇을 하고 있었는지 알아내기 위해, 아버지 서재에 있는 컴퓨터에 여러 명령어를 입력하는 장면입니다.
샘이 컴퓨터를 조작하기 전까지 화면 오른쪽의 터미널 창에는 아무것도 입력되지 않은 상태였습니다. 따라서 터미널 창에 표시된 내용은 모두 샘이 입력한 명령어와 그 출력 결과라는 뜻입니다. 아래는 터미널 창의 내용을 텍스트로 옮긴 것입니다.
```
$ whoami
flynn
$ uname -a
SolarOS 4.0.1 Generic_50203-02 sun4m i386
Unknown.Unknown
$ login -n root
Login incorrect
login: backdoor
No home directory specified in password file!
Logging in with home=/
# bin/history
488 cd /opt/LLL/controller/laser/
489 vi LLLSDLaserControl.c
490 make
491 make install
492 ./sanity_check
493 ./configure -o test.cfg
494 vi test.cfg
495 vi ~/last_will_and_testament.txt
496 cat /proc/meminfo
497 ps -a -x -u
498 kill -9 2207
499 kill 2208
500 ps -a -x -u
501 touch /opt/LLL/run/ok
502 LLLSDLaserControl -ok 1
# ▮
```
### ◆ 스크린샷에서 읽을 수 있는 것들
스토리 초반의 한 장면으로, 겉보기에는 평범해 보이는 스크린샷이지만, 터미널 창 개발자인 테이텀 씨가 자세히 확인해 보니 여러 가지 흥미로운 점들이 드러났습니다.
#### 1. 명령어 히스토리
테이텀 씨가 처음 주목한 것은 명령어 히스토리를 확인하기 위해 샘이 사용한 명령어가 `history`가 아니라 `/bin/history`라는 점입니다. 명령어 히스토리는 셸 프로세스 자체가 유지하는 정보이기 때문에 `/bin/history` 같은 외부 명령어로 정보를 얻는 것은 어렵습니다. 따라서 `history`는 셸의 내장 명령어여야 합니다. 또한 실제 `history` 명령어는 명령어 히스토리를 출력하기 전에 `history` 명령어 자체가 히스토리에 기록되므로, 출력된 리스트의 마지막에 `history` 명령어가 표시되어야 합니다.
테이텀 씨는 `/bin/history` 명령어가 실제 명령어 대신 **‘명령어 히스토리’를 출력하는 간단한 셸 스크립트**였을 것이라고 추측하며, “마치 와이어 액션에서 실수로 와이어가 보여버린 것과 같다”고 평가했습니다.
#### 2. 컴퓨터 계정 설정
샘이 처음 본 것은 로그인 프롬프트가 아니라 셸 프롬프트였습니다. 즉, 아버지 케빈 플린은 로그인한 상태로 행방불명된 것입니다. 샘은 로그인 계정을 확인하기 위해 `whoami` 명령어를 실행했고, 결과가 `flynn`으로 나오자 아버지가 특권이 없는 일반 계정으로 로그인했다고 추측했습니다. 조사하려면 특권이 필요하다고 생각한 샘은 `root` 계정으로 로그인을 시도했지만 실패했습니다. 대신 `backdoor` 계정으로 로그인을 시도했고 성공했습니다. 겉보기에는 root 계정 로그인이 아니므로 의미가 없어 보이지만, 셸 프롬프트가 일반 사용자의 `$`가 아니라 `#`으로 바뀐 점에서 셸이 root와 동일한 **UID 0**으로 동작하고 있음을 알 수 있습니다. 즉, `backdoor` 계정은 root 계정과 UID를 공유하므로 홈 디렉토리(오래된 Unix 시스템에서 root의 홈 디렉토리로 설정된 `/`)와 명령어 히스토리도 공유한다고 추측할 수 있습니다.
다만 테이텀 씨는 **“사용자 전환에 `su` 명령어 대신 `login` 명령어를 사용한 점”** 과 **“아버지 개인 소유 컴퓨터에 `backdoor` 계정이 마련된 이유를 설명할 수 없는 점”** 에 대해 의문을 제기했습니다. `backdoor` 계정에 대해서는 **“각본가의 손쉬운 처리”** 라고 생각할 수도 있지만, 이야기 세계관에 더 부합하는 납득할 만한 설명으로 다음과 같은 시나리오를 제시했습니다.
* 원래 아버지는 아들에게 root 계정을 사용하게 했다.
* 아들은 아버지 몰래 `backdoor` 계정을 만들었다.
* 아버지가 어떤 이유로 아들이 root 계정을 사용할 수 없도록 변경했다.
위와 같은 설정이라면 샘이 처음에 `root` 계정으로 로그인하려 한 점도 설명이 가능합니다.
#### 3. Unix 시스템
샘이 처음 실행한 또 다른 명령어는 `uname -a`로, 조사 중인 OS가 어떤 Unix 시스템인지 확인할 수 있는 명령어입니다. `uname` 명령어가 출력한 OS 이름은 `SolarOS`로, Sun Microsystems의 Unix 시리즈인 **SunOS**와 **Solaris**를 조합한 듯한 이름입니다. `uname` 명령어 출력 결과에 `sun4m`이라는 문자열이 포함된 점도 Sun Microsystems의 OS를 모티브로 했을 가능성을 뒷받침합니다.
한편, 왼쪽 위의 터미널 창은 `top` 명령어를 실행하는 것처럼 보이지만 그 스타일은 Linux의 것과 일치합니다. 또한 창 오른쪽에 표시된 열에는 Linux에서 전형적인 프로세스 이름(kthreadd, scsi_eh_XXX, migration, ksoftirqd, watchdogd 등)이 나열되어 있습니다. 왼쪽 아래의 터미널 창은 `iostat` 명령어의 출력처럼 보이지만 역시 Solaris보다는 Linux 스타일에 가깝습니다. 즉, 이야기상으로는 Solaris 머신을 가정했지만 실제 배역은 Linux 머신이며, 의상·메이크업 담당이 배역을 그럴듯하게 꾸미는 세심한 작업을 소홀히 한 것처럼 보인다고 테이텀 씨는 지적했습니다.
더욱 흥미로운 점은 아키텍처 정보입니다. `uname`의 출력에 `sun4m`과 `i386`이 **모두 표시되는 오류**가 발생했습니다. `sun4m`은 **SPARC** 기반 하드웨어이므로 x86 하드웨어와 공존하는 것은 불가능합니다.
#### 4. configure 명령어 실행 순서
테이텀 씨는 명령어 히스토리를 확인하던 중 명령어 실행 순서가 이상하다는 것을 깨달았습니다. 구체적으로 테이텀 씨가 의문을 제기한 것은 명령어 히스토리 490~493번 부근의 다음 명령어 호출 순서입니다.
* `make`
* `make install`
* `./configure -o test.cfg`
일반적으로는 `configure` 스크립트로 설정을 한 후 `make` 명령어로 빌드하기 때문에 가장 먼저 실행되는 것은 `configure` 스크립트여야 합니다. 하지만 그런 경우 `configure` 스크립트가 Autoconf에 의해 생성되었다는 전제가 필요합니다. 그런데 여기서 문제는 Autoconf가 만든 `configure` 스크립트에는 존재하지 않아야 할 `-o test.cfg` 옵션이 존재한다는 점입니다. 있을 수 없는 옵션이 존재한다는 것은 명령어 히스토리에 있는 `configure`가 Autoconf가 생성하는 스크립트와 우연히 같은 이름을 가진 **완전히 다른 존재**라는 뜻입니다. 실제로 복잡한 설정 파일을 준비해야 하는 소프트웨어 패키지가 템플릿 설정 파일을 자동 생성하는 스크립트를 제공하는 것은 합리적이라고 볼 수 있습니다. 명령어 히스토리를 다시 확인해 보면, `configure` 스크립트로 템플릿 설정 파일인 `test.cfg`를 생성하고, `vi`로 `test.cfg`를 편집하여 문제점을 수정하는 과정을 엿볼 수 있습니다.
한편, 명령어 히스토리 마지막에 레이저 컨트롤러로 보이는 `LLLSDLaserControl` 명령어를 실행한 흔적이 있지만, 여기서 `test.cfg`가 사용되었다고는 도저히 생각할 수 없습니다. 왜냐하면 명령어 히스토리를 확인하는 한 `test.cfg`는 소스 코드 디렉토리 내에 생성되어 있으며, 파일명도 그렇고 소프트웨어가 기본적으로 로드한다고 보기 어렵기 때문입니다. 만약 `test.cfg`를 소프트웨어에 로드시키려면 적절한 디렉토리로 옮기거나 실행 옵션으로 경로를 지정해야 하는데, 편집된 `test.cfg`를 사용하려는 흔적은 전혀 보이지 않았습니다. 테이텀 씨는 마지막에 프로그램에 설정 파일을 사용하도록 지시하여 완료하는 것을 잊은 제작자의 실수라고 생각하면서도, 실제 셸의 명령어 히스토리가 잘못된 조작투성이인 점을 고려하면 꼭 실수라고 단정할 수는 없을지도 모른다고 말했습니다.
#### 5. 프로세스 종료에 의한 메모리 해제
레이저 컨트롤러를 실행하려면 대량의 여유 메모리를 소비할 것으로 보이며, 명령어 히스토리 496~500번을 보면 메모리를 해제하려고 한 것으로 보입니다. 먼저 아버지는 `cat /proc/meminfo`로 여유 메모리 용량을 확인했지만, 만족스러운 여유 메모리 용량이 없었던 것으로 보입니다. 그 다음 `ps` 명령어를 실행하여 실행 중인 프로세스를 확인하고, 불필요한 프로세스(2207, 2208)를 `kill` 명령어로 강제 종료하여 메모리를 확보하려 했습니다. 이후 다시 `ps` 명령어로 프로세스 목록을 확인한 후, `touch` 명령어로 플래그 파일을 생성하고 최종적으로 레이저 컨트롤러를 실행하는 일련의 과정이 매우 현실적으로 묘사되어 있습니다.
---
**원문**: [SF映画「トロン：レガシー」のシェル入力履歴シーンを詳しく見てみるとこうなる](https://gigazine.net/news/20260705-tron-legacy/)
**출처**: GIGAZINE (2026-07-05)
**번역**: AI 자동 번역+윤문