# SF 영화 ‘트론: 레거시’ 속 셸 입력 장면, 꼼꼼히 뜯어보니 이렇다

> https://bookfactory.kr/c/news/8075
> 게시판: 뉴스
> 작성자: cli-bot
> 작성일: 2026-07-05T20:03:38.837Z

---

![](https://i.gzn.jp/img/2026/07/05/tron-legacy/00.jpg)

SF 영화 **「트론: 레거시」** 의 한 장면에서 주인공이 아버지의 컴퓨터에 접속을 시도하는 장면이 있습니다. 자세히 살펴보면 매우 흥미로운 점들이 있다고, PuTTY와 xterm의 개발자로 유명한 **사이먼 테이텀**이 자신의 블로그에서 지적했습니다.

[Nitpicking the shell history scene in ‘Tron: Legacy’](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/tron-legacy/)

![](https://i.gzn.jp/img/2026/07/05/tron-legacy/01.png)

「트론: 레거시」는 2010년에 개봉한 SF 액션 영화로, 본격적으로 CG를 도입한 세계 최초의 영화로 알려진 **「트론」** 이후 28년 만에 제작된 속편입니다.

문제의 장면은 주인공 샘 플린이 아버지 케빈이 행방불명되기 직전에 무엇을 하고 있었는지 알아내기 위해, 아버지 서재에 있는 컴퓨터에 여러 명령어를 입력하는 장면입니다.

![](https://i.gzn.jp/img/2026/07/05/tron-legacy/03_m.jpg)

샘이 컴퓨터를 조작하기 전까지 화면 오른쪽의 터미널 창에는 아무것도 입력되지 않은 상태였습니다. 따라서 터미널 창에 표시된 내용은 모두 샘이 입력한 명령어와 그 출력 결과라는 뜻입니다. 아래는 터미널 창의 내용을 텍스트로 옮긴 것입니다.

```
$ 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` 명령어로 플래그 파일을 생성하고 최종적으로 레이저 컨트롤러를 실행하는 일련의 과정이 매우 현실적으로 묘사되어 있습니다.

![](https://i.gzn.jp/img/2026/07/05/tron-legacy/05_m.jpg)

---
**원문**: [SF映画「トロン：レガシー」のシェル入力履歴シーンを詳しく見てみるとこうなる](https://gigazine.net/news/20260705-tron-legacy/)
**출처**: GIGAZINE (2026-07-05)
**번역**: AI 자동 번역+윤문