AI-NATIVE 시리즈 · 플레이-엔지니어링, 에피소드 3/4

SF 공상과학 산물 플레이-엔지니어링: 이야기에서 출발해 12살 아이도 30일 안에 실험할 수 있는 프로토타입까지

글쓴이Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-09-25 · 소요 시간 14분

숫자를 해석하는 방법 g와 d는 차이의 크기를 나타낸다. 약 0.2는 작고, 0.5는 중간, 0.8은 크다. "SD"(표준편차)도 같은 종류의 단위다.

이번 화가 답하는 핵심 질문아이도 30일 만에 SF 산물을 직접 만들고 실험하려면 어떻게 해야 할까?

이 글에서는 다루지 않는다 — 놀이가 어떻게 기술이 되는지는 1화에서, 계속 몰입하게 만드는 힘은 2화에서, 복원된 세계를 목표로 삼는 법은 4화.

이 에피소드에서 다루는 것과 대상

이 글은 과학 소설을 좋아하고 실제로 무언가를 만들어보고 싶은 아이들, 그리고 실험실 없이도 그 과정을 도와주고 싶은 어른들을 위한 것이다. 여기서는 과학 소설이 실제로 발명에 영감을 준 경우와 그렇지 않은 경우, 이야기를 프로토타입으로 바꾸는 다섯 단계, 그리고 주방 테이블에서 할 수 있는 세 가지 제작법을 다룬다. 앞선 두 편과도 연결된다. 좋은 이야기가 주는 것은 '매혹'(2화)이고, '메커니즘과 두 번째 사례'(1화)가 바로 그것을 엔지니어링으로 바꾸는 방법이다.

쿵푸 영화에서 동작을 익히는 장면을 떠올려보자.

나는 대학생 때 브루스 리 영화를 보며 무술을 익혔다. 영화 속 동작은 SF 기기와 닮았다. 짜릿하고, 불가능해 보이며, 오직 카메라를 위해 만들어진다. 어떤 동작은 실제로 가능하다. 어떤 것은 스턴트 대역이 아니면 불가능하다. 그 차이를 알 수 있는 유일한 방법은 동작을 분해해서 직접 시도해보는 것이다.

실제 사례 네 가지와, 검증이 필요한 신화 두 가지

고다드의 체리나무.1898년, 매사추세츠의 한 십대가 신문 연재소설에서 화성인이 보스턴을 침공하는 이야기를 읽었다. 이 소설은 H. G. Wells의 The War of the Worlds를 모방한 작품이었고, 원작은 아니었다 (American Heritage). 1899년 10월 19일, 17세였던 그는 체리나무에 올라가 가지치기를 하다가, 화성으로 날아갈 수 있는 기계를 상상했다. 그는 훗날 자신이 "전혀 다른 아이가 되어 나무에서 내려왔다"고 썼고, 그날을 수년간 "Anniversary Day"로 기념했다 (Clark University). 그리고 27년 뒤인 1926년 3월 16일, 그의 첫 액체연료 로켓이 비행했다. 2.5초 동안 41피트 상공을 날아 184피트 떨어진 양배추밭에 착지했다 (NASA). 단 2.5초. 20세기 최대의 아이디어가 처음 실제로 시험된 시간은 재채기보다 짧았다. 이것이 바로 첫 실험의 본모습이다.

트라이코더.Star Trek의 휴대용 의료 스캐너는 실제 대회, Qualcomm Tricorder XPRIZE의 탄생을 이끌었다. 참가팀들은 13가지 건강 상태를 진단하고 다섯 가지 주요 생체 신호를 측정할 수 있는 소비자용 기기를 만들어야 했다. 응급의학 의사와 엔지니어 형제가 이끄는 가족팀이 2017년 4월 우승했다 (XPRIZE). 이야기가 꿈에 이름을 붙였고, 상금이 그 꿈에 수치를 요구했다.

유니버설 트랜슬레이터.수십 년간 과학소설은 즉각 번역 장치를 상상해왔다. 2026년 6월, Google은 실시간 음성 번역 기술을 소개했다. 이 기술은 70+개의 언어를 감지하고, 화자보다 몇 초 늦게 따라간다 (Google). Google의 공식 페이지에는 Star Trek 언급이 없다. 즉, 이야기와의 연결고리는 우리가 만든 것이지, 그들의 것이 아니다. 어떤 연결을 주장하는지 반드시 밝히는 습관을 들여야 한다.

소년, 도서관 책, 그리고 풍차. 말라위에서 14 William Kamkwamba는 도서관에서 빌린 책 Using Energy (TED)에 실린 거친 설계도를 참고해, 고철과 남은 부품으로 전기를 만드는 풍차를 만들었다. 설계도가 조악했기에, 그는 가진 부품에 맞게 설계를 바꿨다. 바로 그 '바꾸기'가 엔지니어링이다. 그리고 16에서 Boyan Slat은 다이빙을 하다가 물고기보다 플라스틱이 더 많은 바다를 보고, 이를 학교 과학 프로젝트로 발전시켜 The Ocean Cleanup이 되었다(The Ocean Cleanup).

신화 검증 1. 스타트렉의 커뮤니케이터가 휴대전화를 낳았다는 이야기를 흔히 볼 수 있다. 1973년 세계 최초로 휴대용 휴대전화 통화를 한 Martin Cooper는 한 번 카메라 앞에서 그 이야기에 동의했지만, 이후 수년간 이를 바로잡아 왔다. 그의 말을 직접 들어보자: "It wasn't Star Trek, it was Dick Tracy."(번역: '스타트렉이 아니라 딕 트레이시였다.') (Good Times, 2021) 만화 속 탐정의 손목 라디오가 진짜 영감의 원천이었다.

신화 검증 2. Leo Szilard는 1933년 런던에서 핵 연쇄반응 개념을 떠올렸고, 흔히 H. G. 웰스의 소설에서 영감을 얻었다고들 한다. 그는 그 소설을 읽었지만, 미국 원자력학회에 따르면 그 이야기를 자신의 영감의 일부로 여기지 않았다(ANS). 젊은 엔지니어라면 기억해야 할 점이 있다. 발명가가 직접 들려주는 이야기와, 남들이 그에 대해 전하는 이야기는 서로 다른 종류의 증거다.

그리고 경계해야 할 사례: 두 번째 사례가 없는 경우. 한 15세 소년이 암 진단 아이디어로 주요 과학 경진대회에서 우승해 유명해졌지만, 2014년 기준 그 결과는 동료평가 저널에 실리지 않았고 전문가들도 의문을 제기했다(Scholarly Kitchen). 경진대회 우승은 한 번의 첫 번째 테스트일 뿐이다. 두 번째 사례는 아니다.

로봇이 프로젝트를 고르는 방식이 왜 우리에게도 맞는가

AI 연구자들은 호기심 많은 로봇을 위해 만든 규칙을, 호기심 많은 아이들에게도 적용한다. Pierre-Yves Oudeyer의 로봇들은 learning progress에 대해 보상을 받았다. 즉, 가장 빠르게 실력이 늘어나는 상황—너무 예측 가능하지도, 너무 예측 불가능하지도 않은 상황—으로 스스로를 밀어넣었다(Oudeyer, Kaplan & Hafner, 2007, described). 너무 쉬운 프로젝트는 아무것도 가르쳐주지 않고, 불가능한 프로젝트 역시 마찬가지다. 고다드의 2.5초 비행은 바로 그 경계에 있었다. 아래에서 만들기를 고를 때, 정말로 성공할지 모르는 것을 선택하라.

다섯 번의 '왜': 왜 대부분의 SF에서 영감을 받은 아이들 프로젝트는 '멋지다'에서 멈추는가?

1. 왜 멈출까? 프로젝트가 기기의 겉모습만을 흉내 내기 때문이다. 즉, 소품을 만드는 데 그치고 실제로 작동하게 하는 원리에는 손대지 않는다. 작동 원리. 증거: 위의 모든 실제 사례에서 '이야기'에서 '메커니즘'으로 넘어가는 단계가 있었다. Kamkwamba는 대충 그려진 설계도를 실제 부품에 맞게 바꿨다 (TED).
2. 왜 겉모습만 따라 할까? 메커니즘이 이름 붙여지지 않으니, 시험해볼 것도 없기 때문이다. 증거: XPRIZE에서는 '트라이코더'라는 이름을 13 진단해야 할 조건들—즉, 명확히 이름 붙이고 시험 가능한 목표—로 바꿨다.
3. 왜 이름 붙이기가 그렇게 중요한가? 명명된 메커니즘만이 두 번째 사례에서 시험될 수 있고, 전이란 결국 공유된 메커니즘을 통해서만 일어난다.증거: 그런 메커니즘 없이 먼 전이를 시도하면 효과 크기가 약 0.03 SD (Sala & Gobet)에 그친다(출처: episode 1.
4. 왜 한 번의 좋은 실험으로는 충분하지 않은가? 한 번의 사례는 단순한 운이거나, 잘못된 이유 때문일 수 있기 때문이다.증거: 복제가 되지 않은 과학 경진대회 사례 (Scholarly Kitchen).
5. 그렇다면, 무엇이 이야기를 엔지니어링으로 바꾸는가? 본질은 이렇다. 어떤 공상과학적 산물도, 그 작동 원리가 명확히 이름 붙여지고 두 번째 사례에서 시험될 때 비로소 엔지니어링이 된다. 그리고 첫 실험은 아주 작아도 상관없다. 증거: 2.5 1926년에 단 NASA).

Operate — 실제로 작동하는 것

한 문장으로 말하자면, 이 페이지의 모든 숫자는 페이지가 공개되기 전에 로봇이 검증한다. 좀 더 자세히 설명하자면, 이 페이지의 각 사례별 숫자는 content/series/play-engineering/evidence.yml 그 출처와 함께 표의 한 행에 기록된다. 게이트 scripts/check-play-engineering.mjs 페이지와 파일의 숫자가 다르면 빌드는 통과하지 않는다. 그리고 Martin Cooper의 인용문은 별도 표시된다.data-verbatim 따라서 이 페이지의 번역에서는 해당 문장을 임의로 바꿀 수 없다.

피드백: 좋은 결과란 무엇이고, 그 결과가 감추는 것은 무엇인가

좋은 결과란 두 숫자가 대략 비슷하게 나오는 것이다. 예를 들어, 청진기로 잰 맥박수가 두 사람 모두에서 시계와 거의 일치하거나, 로켓이 한 가지만 바꾼 뒤에도 다시 날아오고 그 시간 변화의 이유를 설명할 수 있을 때다. 결과가 감추는 것은 바로 장비의 상태다. 소리가 새는 관이나 밀봉이 약한 병은, 아무리 훌륭한 메커니즘도 나쁘게 보이게 만든다. 그래서 두 번째 사례에서는 오직 한 가지만 바꾼다. 그래야 차이가 무엇 때문인지 정확히 알 수 있다.

피드포워드: 결과가 나오기 전에 미리 정하는 규칙

• 만약 독자들의 두 번째 사례 숫자가 첫 번째와 대부분 다르다면, 미션에는 세 번째 단계—‘첫 번째 사례를 한 번 더 반복하기’—가 추가된다. 이 경우 문제는 방법이 아니라 노이즈 때문이다.
• 어떤 독자의 빌드가 예상외로 잘 작동하면, 본인의 동의를 받아 다음 업데이트에서 이 페이지 맨 위의 대표 사례로 올라간다.
• 만약 번역기 트랙을 아무도 선택하지 않으면, 앱이 필요 없는 트랙으로 교체된다.

이 에피소드가 시리즈에서 차지하는 자리

같은 이야기, 다섯 가지 출구

30분 안에 직접 만들어보기

• 입력 이야기에서 가져온 공상과학적 산물 하나
• 출력 메커니즘을 한 문장으로 설명, 장난감 수준의 프로토타입, 그리고 두 개의 수치
• 불변 조건 두 번째 사례에서는 오직 한 가지만 바꾼다.
• 중단 규칙 만약 메커니즘을 한 문장으로 못 쓰겠다면 아직 1단계다. 더 읽거나 더 찾아보라.
• 최소 기록 artifact, mechanism, case_1_number, change, case_2_number.
• 의도적으로 생략 병보다 큰 실험에는 반드시 안전 엔지니어링이 필요하다. 어른에게 꼭 물어볼 것 — Goddard의 일기에도 첫 로켓의 노즐 하단이 타버렸다고 적혀 있다 (American Heritage).

5S 자기평가와 그 근거

참고문헌

1. Clark University — Goddard의 Anniversary Day;NASA (2026) — 최초의 액체연료 비행.
2. XPRIZE (2017) — Tricorder XPRIZE 결과.
3. Google (2026) — 실시간 음성 번역.
4. TED 연사 약력; The Ocean Cleanup.
5. Martin Cooper 인터뷰: Good Times, 2021.
6. Leo Szilard와 연쇄 반응: American Nuclear Society.
7. Oudeyer, Kaplan & Hafner (2007), "Intrinsic Motivation Systems for Autonomous Mental Development", IEEE Transactions on Evolutionary Computation — 해당 논문에서 설명.

관련 에피소드

• 에피소드 1 — 플레이-엔지니어링이란 무엇이며, 반복 훈련이 할 수 없는 것을 놀이는 어떻게 해내는가?
• 에피소드 2 — 12살 아이가 어려운 일에 수년간 몰입하게 만드는 힘은 무엇인가?
• 에피소드 4 — 아이들과 어른들이 복원이라는 비전을 실제 실행·측정 가능한 계획으로 바꾸려면 어떻게 해야 할까?