우리나라에서도 종종 보안사고가 나곤 합니다. 평소에 그렇게 관심을 많이 받지는 못하지만, 한 번 사고가 나면 개인에게, 기업에게, 그리고 사회적인 측면에서도 큰 불편과 손해를 끼치죠.

‘보안’이라는 게, 여전히 ‘사고가 난 뒤’에 패치하고 복구하는 데 중심을 둬야 하는 일일까요? 그게 아니라면, 이제 AI가 자율적으로 작동하면서 ‘스스로’ 사고를 일으킬 수도 있는 시대가 다가오는 지금, 그 시대의 환경에 맞게, 모든 걸 제로베이스에서 다시 생각하는게 맞을까요?

루브릭(Rubrik)의 CPO(최고제품책임자) 아네카 굽타(Anneka Gupta) 는 “우리는 이제 충돌 이후의 세계가 아니라, 충돌 이전의 세계에 살고 있다”고 말합니다. 이건 아마도, 자율적인 시스템이 스스로 실패를 만들어낼 수 있는 시대 — 이 새로운 현실에서, 보안의 의미가 단순한 사후적 대응이 아니라 예방적 설계와 복원력의 방향으로 무게 중심을 옮겨가고 있다는 뜻일 것 같습니다.

오늘 아네카와의 인터뷰에서는, 아래와 같은 내용을 커버합니다:

이 외에, 아시모프의 로봇에 대한 철학이 아네카의 사고방식에 어떤 영향을 주었는지, 그리고 “텔레포테이션이야말로 모든 SF 기술 중 최고의 발명”이라고 말하는 이유도 함께 이야기합니다.

이 에피소드는 불확실성의 시대를 설계해 나가는 법, 혁신을 멈추지 않으면서도 가드레일을 잘 세우는 법, 그리고 AI가 스스로 규칙을 넘어설 수 있는 시대에 보안의 의미를 탐구합니다.

실용적인 통찰과 현장감 있는 조언이 가득한 이번 대화를 지금 만나보세요 - 인터뷰를 영상으로 보고 싶으신 분은 아래 링크를 참고하시구요:

Q. 안녕하세요 아네카, 인터뷰 시간 내 주셔서 감사합니다. 오늘은 “자율 에이전트 시대의 보안”을 주제로 이야기해 보려고 해요.

불러주셔서 감사합니다.

Q. 오늘 대화의 주제를 ‘불확실성을 위한 설계’로 잡고 싶어요. 이전에는, 보안이란 게, 사고가 벌어진 ‘이후’에 복구하고 패치하고 넘어가는 일이었다고 할 수 있을 텐데요 그런데 지금은 AI 시스템이 스스로 사고를 낼 수 있는, 말하자면 충돌 ‘이전’의 세계에 우리가 살고 있다는 생각이 들어요. 이 세계에서 실패란 건 무엇일까요? 시스템이 스스로 실패를 만들어낼 수 있을 때요.

맞아요. 오늘날 AI만큼 불확실성을 키우는 기술은 드물죠. 사이버 보안 관점에서 AI의 미래가 어떨지, 공격자들은 이미 AI를 어떻게 쓰고 있는지, 궁금한 점들이 많을 수 밖에 없어요. 하지만 조직의 AI 도입이라는 관점에서 핵심 난제는, AI가 ‘비결정적(Non-Deterministic)’이라는 점이에요.

특히 AI 에이전트를 사용한다는 관점에서의 난제는, 에이전트가 “어떤 결과”를 달성하도록 설계되어 있을 뿐이지, 그 결과를 만들어내기 위해서 실제로 “무슨 변화를 일으킬지”에는 대부분 무관심하다는 겁니다. 대규모로 에이전트를 배치할 때 사전에 생각해야 할 부정적 결과와 위험을 말하자면, 핵심 질문은 “내 AI 에이전트가 내 애플리케이션에 의도치 않은 다운타임을 일으키지 않게 하려면 뭘 어떻게 해야 하나?”라는 거예요.

사람이 실수로 다운타임을 일으키는 건 원래 걱정하던 거였죠. AI 에이전트는 그 문제를 ‘매머드급’으로 키우게 되죠. 경우의 수도 훨씬 많아지고, 훨씬 빠르게 행동하기도 하고, 비결정적이고 예측 불가능하게 움직일 테니까요. 예컨대 데이터베이스 테이블을 드롭하는 식의, 되돌리기 어려운 변경을 해 버리면 곧바로 장애로 이어질 수 있는 거예요.

결국 AI 에이전트가 증폭하는 건, 사람에게서도 보였던 예측 불가성 그 자체입니다 — 기존 문제를 더 크게 만드는 거죠.

Q. 이런 불확실성과 실패를 다룰 때, 아네카 당신이 생각을 풀어가는 과정이 궁금하네요. 이 새로운 시대에 ‘통제·오류·복구’라는 개념을 어떻게 정의하세요?

네, 한 번 설명을 해 볼께요.

우선, 첫 단계는 ‘가시성(Visibility)’입니다. 무슨 일이 벌어지는지 모니터링하고 들여다볼 수 있어야 하죠. 어떤 AI 에이전트가 돌아가고 있는지, 무슨 액션을 수행하는지, 어떤 애플리케이션에 접근 권한이 있는지. 가시성이 1단계예요.

그 다음이 ‘거버넌스(Governance)’입니다. 에이전트가 무엇을 하도록 허용할지, 어디까지 접근하게 할지에 대한 가드레일, 그리고 결과와 결과의 품질에 대한 가드레일까지 정의하는 일입니다.

세 번째가 ‘가역성(Reversibility)’이에요. 무슨 일이든 틀어질 수 있다는 걸 전제로 해야 돼요. 가드레일을 완벽하게 세우기도 어렵고, 모든 상황을 사전에 예측할 수도 없거든요. 그래서, 에이전트가 언젠가 실수를 했을 때 뭘 해야 할지, 그 실수를 어떻게 되돌릴지를 준비해야 합니다.

요약하면, 고객들이 찾는 것도 결국 이 세 가지고, 우리도 이 축을 중심으로 ‘AI 도입은 가속화하면서 조직의 복원력은 높이는’ 실전 과제들을 재정의하고 있습니다.

Q. 이 인터뷰를 보시는 분들을 위해서, 아주 실용적으로 가 보죠. 조직에 에이전트를 배포할 때 반드시 생각해야 할 ‘세 가지 혹은 다섯 가지’ 규칙이 있다면, 어떤 걸까요?

네, 이렇게 이야기해 볼께요.

규칙 #1: 결과를 정의하라. 에이전트로 무슨 문제를 풀고 싶은가? 유스케이스는? 기대하는 ROI는? 생산성 증분은?

규칙 #2: 기술 스택을 골라라. 에이전트를 어떻게 구성할 것인가? 어떤 도구·인프라를 쓸 것인가? 엔지니어가 빌드하느냐 기술을 잘 모르는 사용자가 구성하느냐에 따라 옵션이 달라집니다. 조직의 전체 기술 전략과의 정합성을 봐야 해요.

규칙 #3: 관측 가능성(Observability)을 내장하라. 여기서부터가 ‘선제적’인 작업입니다. 어떤 에이전트가 돌아가는지, 시스템에서 무엇을 하는지, 어디에 접근하는지, 조직 내에서 누가 쓰는지에 대한 가시화(Visibility)를 어떻게 만들 것인가? 모니터링이 핵심이에요.

규칙 #4: 지속적으로 관리·업데이트하라. 운영 중인 에이전트를 어떻게 관리할 것인가? 실제 행동을 관찰해 가면서 규칙을 갱신해야 합니다. 허용·비허용 행동에 대한 초기 규칙이 있더라도, 관측 결과를 반영해 가면서 계속 업데이트하세요. 그래야 품질이 좋아지고, 원치 않는 행동을 사전에 막을 수 있습니다.

규칙 #5: 복구를 준비하라. 에이전트가 언젠가 실수할 때의 ‘기술적 플레이북’과 프로세스는 무엇인가? 거기서 어떻게 회복할 것인가?

Q. 관측성·가시성·해석가능성 이야기를 많이 하셨습니다. ML에서 해석가능성은 가장 어려운 문제 중 하나였죠. 이런 불확실성에 지배되는 환경에서 병목(Bottleneck)은 어디에 있나요? 이걸 어떻게 다루나요?

말씀대로, 에이전트 환경은 전통적 ML보다 예측 불가성이 더 큽니다. 실무적으로는, 에이전트가 하는 ‘모든 것’을 로그로 남기는 게 출발점이에요.

1일 차부터 규칙과 설정이 완벽할 수는 없죠. 하지만 전부 로그가 있으면, 결과의 품질을 사후적으로 평가할 수 있습니다 — 기대한 결과가 맞는지, 보안·거버넌스 관점에서 허용하고 싶은 활동인지, 등을요.

결국 중요한 건, 허용·비허용의 한계를 연속적으로 학습시키는 가드레일을 만드는 겁니다. 품질과 ROI를 위해서도 중요하고, 공격자가 침투해서 에이전트를 악용하거나, 의도치 않게 데이터를 노출하는 위험 등 보안 리스크를 키우는 경우를 모니터링하기 위해서도 필수예요.

Q. 이 로깅은 또 다른 ‘감시용 에이전트’가 하는 건가요? 구조를 어떻게 잡나요?

흐름을 생각해 보세요. 에이전트와 모델 사이에 ‘호출’이 일어납니다. 모델 호출 → 응답(다음 단계) → 보통 MCP 서버를 통해 액션 실행, 이런 구조죠. 이 ‘무대 뒤’에서 무슨 일이 일어나는지 이해하는 게 아주 중요해요.

이게 사이클로 반복될 수 있고, 에이전트들끼리 대화하기도 합니다. 하지만 모델 호출(Call)들의 입력 프롬프트와 반환 결과, 특정한 호출(Call)에서 MCP 서버가 실제로 무엇을 했는지까지 엮어서 ‘연결’할 수 있다면, 전체 그림이 보입니다.

물론 말처럼 쉽지는 않아요. 대개 단일 시스템이 아니라 다중 시스템입니다. MCP 서버가 이메일·슬랙·CRM 등 여러 시스템과 연결되어 있죠. 다들 제각기 일을 합니다.

그래서 각 레이어에서 무슨 일이 일어나는지 이해하는 ‘총체적 뷰’를 만들어야 해요. 이걸 하려면 모니터링을 위한 다중 진입점, 각종 API의 로그 호출이 필요하고, 그 다양한 로그로부터 실제로 ‘무엇이 어떤 순서로 일어났는지’ 시간을 재구성해야 합니다.

쉬운 문제는 아닙니다. 시간이 갈수록 서드파티 도구들이 더 나은 가시성(Visibility)을 제공해 줄 테고, 벤더는 이걸 비즈니스/기술 사용자가 ‘실제로 쓸 수 있게’ 엮어야 합니다. 역사적으로 보안이 실패했던 지점이 바로 여기예요 — 너무 많은 신호를 ‘공격 타임라인’으로 상관 분석해 내지 못한다는 점. 에이전트도 같습니다. ‘에이전트 액션 타임라인’을 이해해야 해요.

Q. 그 타임라인을 만드는 에이전트를 만들면 되겠네요.

만들 수 있습니다. 다만 ‘베이스라인 데이터’에 접근할 수 있어야 돼요. 에이전틱 AI 덕에 타임라인 구성 자체는 예전보다 쉬워졌다고 믿지만, 데이터 접근권을 얻고 로그를 ‘의미 있게’ 해석하기까지는 여전히 일이 남아 있습니다. 그냥 범용 에이전트를 로그 위에 얹는다고 ‘정답’이 나오진 않아요. 이건 반복적인 작업이고, 베이스라인 데이터에 대한 충분한 이해가 있어야 퍼즐을 맞출 수 있습니다.

Q. 아네카 당신은 SaaS 시대부터 지금의 자율 에이전트 시대까지 폭넓은 경험을 하신 분인데요. 엔지니어·프로덕트 팀이 이 새로운 AI 문제들을 생각하고 푸는 데 필요한 ‘마인드셋으로 전환’하려면 어떻게 해야 하나요?

네. 많은 경우에 마인드셋 전환이라는 것 그 자체가 가장 큰 장벽이라고 생각해요.

AI는 기술이기는 하지만 과거의 어떤 기술과도 그 작동 방식이 달라요. 우리는 결정론적 코드를 쓰는 데 익숙합니다. “이렇게 하면 저렇게 된다.” 혹은 다섯 단계의 자동화가 매번 똑같이 실행되도록 짭니다.

AI에서는 ‘원하는 결과’를 정의하고 ‘평가 지표(Evals)’를 정하는 것부터 시작합니다. 그 다음은 ‘실험 속도’예요. 데이터 소스를 하나 더 붙인다고 품질이 좋아질지, 툴들을 연결하면 결과가 달라질지, 보고서로는 알 수 없습니다. 그냥 빨리 만들어 보고 검증해야 돼요.

즉, ‘명확한 결과/평가지표’ 위에서 ‘빠른 실험’이 가능하냐가, 유스케이스 확장과 품질·효용을 가르는 결정적 요소입니다. 이건 우리가 평소 기술을 만드는 방식과 꽤 다릅니다. ‘절차·워크플로·툴의 집합’이 아니라 ‘결과와 평가’에서 출발하는 개발이니까요.

Q. 이렇게 확률적일 때, 근본 원인을 분석하는 작업(Root-Cause Analysis)에는 어떻게 접근하죠?

어렵습니다. 완벽한 답은 아직 없다고 생각해요. 뭘 ‘근본 원인’으로 볼지도 모호하죠. 전통적인 버그처럼 딱 잡히지 않습니다. 어떤 출력이 나왔는데, 그게 ‘나쁜’ 출력인지 ‘좋은’ 출력인지부터가 문제예요.

전문가가 사람의 눈으로 보면 판정할 수 있지만, 그 판단 과정을 기계적으로 설명하는 건 훨씬 어렵습니다. 그래서 대기업처럼 복잡한 환경에서 AI 도입이 느린 거죠. 지금 우리는 다 같이 배우는 중입니다.

“이 유스케이스는 문제를 오늘 당장 잘 풀 수 있는가, 아니면 기술적인 성숙도가 올라가기를 기다려야 하는가?”에 대해서도 완벽하게 명확한 답이 없습니다. 게다가 6개월 뒤면 상황이 달라질 수 있어요. 예측이 어렵습니다.

Q. 팀의 마인드셋은 어떻게 바꾸나요?

“늘 실험하자”라고 말합니다. 그리고 제가 먼저 눈에 띄게 그렇게 하려고 해요. 개인 생활에서도 “이건 AI로 먼저 해볼 수 있을까?”를 매번 시험합니다.

어떤 건 전혀 안 먹힐 때가 있고, 어떤 건 놀랍도록 잘 됩니다. 모델에 따라서도, 달마다 바뀌기도 해요.

개인적으로는 다양한 도구를 자유롭게 쓰기 쉽지만, 회사 안에서는 제한이 있죠. 그래도 똑같습니다. 문제를 만나면 “AI가 도울 수 있는 길이 있나?”를 먼저 떠올리고, 바로 시험해 보는 것. 매일 손으로 만져 보는 실험이 직관을 만들어 냅니다. 이 직관이 프로덕트와 에이전트를 잘 만드는 데 정말 중요해요. 하지만 ‘손때 묻은 경험’ 없이 직관력은 쌓이지 않습니다.

Q. 많은 사람들이 AI를 두려워하는 건 써본 적이 없어서라고 생각해요. 직관을 쌓으면 보안도 더 잘 생각할 수 있을 것 같은데, 다만 개인은 실험이 쉽지만, 기업 환경에서는 ‘행동의 자유’와 ‘안전’ 사이의 긴장 관계가 다루기 어려운 문제가 되겠죠. 혁신을 할 수 있게끔 해 주면서 실험을 막지 않는, 그런 ‘디자인의 경계’를 어떻게 만들어 가시나요?

대부분의 대기업은 이름이 뭐든 ‘AI 거버넌스 위원회’에 해당하는 기구가 있습니다. 이런 조직에서 통제 뿐이 아니라 도입을 가속화하는 역할도 하길 바라게 되죠.

여기서 자주 등장하게 되는 병목은 이겁니다. “이런 AI 유스케이스를 생각 중인데, 외부 벤더와 일할지, 내부 에이전트 빌더로 만들지, 아니면 혼합할지?” — 그리고 “이 에이전트들이 뭘 할지, 무엇에 접근하는지, 데이터로 무엇을 할 수 있는지”에 대한 큰 우려가 따라옵니다.

예컨대 “코드에 취약점을 심지 않겠나?”, “고객 신뢰를 해칠 보안 상태의 악화를 일으키지 않겠나?”, “의도치 않은 데이터 노출이 일어나지 않겠나?” 같은 우려죠.

대기업에서는 고객 간의 ‘데이터 구획(Segmentation)’이 필수입니다. 한 고객이 다른 고객의 데이터를 보면 안 되죠. 에이전트를 열어 두면 그 경계가 흐려질 수 있습니다. 내부적으로도 마찬가지예요. 저는 제품 조직에 있다면 타 부서의 HR 데이터에 접근하면 안 되죠. 이런 이슈들이 AI 위원회에서 계속 다뤄집니다.

효능(Efficacy) 문제도 큽니다. 많은 AI 프로젝트가 프로토타이핑에서 멈추고 프로덕션으로 이동하지 못해요. (출처에 따라서) 70~90%가 그렇다고 하죠. 효능이 부족하기 때문인 경우가 많습니다.

따라서 ‘효능’과 ‘리스크 처리’ 둘 다 필요합니다. 데이터 접근·행동 거버넌스 가드레일을 두텁게 하면서도 효능을 내야 혁신 속도를 높일 수 있어요. 결국 포인트는 둘 다예요 — “효능을 어떻게 확보할 것인가?” 그리고 “그 효능을 유지한 채 더 빠르게 움직이게 해 줄 거버넌스 가드레일은 무엇인가?”

Q. 회사의 계획은 얼마나 자주 바뀌나요? 회사의 액션과 그 결과, 그리고 초고속으로 진화하는 모델·기술 때문에요.

대외 고객을 위한 제품 개발 관점에서, AI 관련 계획은 ‘계속’ 바뀝니다. 루브릭에서 우리의 앵커는 분명해요. “대기업, 특히 규제가 강한 기업들의 AI 도입을 어떻게 가속할 것인가?”하는 것이죠.

문제는 아주 명확해요. 하지만 솔루션 공간은 기술 변화의 속도 때문에, 그리고 에이전트 스택의 계층이 아직 표준화되지 않았기 때문에, 숨 가쁠 정도로 바뀌어요.

그래서 고객과 대화할 때, 그리고 베타 버전을 운영하는 사이트에서 보고 듣는 것에 아주 민감하게 반응합니다. “뭐가 먹히고, 뭐가 안 먹히는가? 지형이 어떻게 바뀌는가?”

최상위 전략은 매주 뒤집히지는 않습니다. 해결해야 할 문제가 명확하니까요. 다만 그걸 ‘어떻게’ 풀지에 대해서는 많이 생각도 바뀌고 결정도 뒤집히고는 합니다.

가장 좋은 방법은 ‘도그푸딩(Dogfooding)’이에요. 우리 솔루션을 우리가 먼저 씁니다. 이상적인 고객 프로파일과 100% 일치하지 않아도 상관없어요. 실제로 써 보면 ‘우리 조직과 페르소나’라는 맥락에서라도 정말 많은 걸 배웁니다.

문제에 대한 강한 관점을 유지하되, 해법에는 유연하고, 내부·외부의 실제 시나리오로 빠르게 반복하라 — 불확실성이 큰 이 영역에서 계속 진화하는 최선의 길입니다.

Q. 지금 풀고 있는 문제는 어떤 것들이 있는지 설명해 주실 수 있나요?

루브릭에서 ‘Rubrik Agent Cloud’를 출시했는데, 이 제품이 풀어나가고 있는 문제는 다음과 같습니다.

우리는 이런 프레임웍, 기능의 세트가 ‘대기업의 AI 도입을 가속화’하는 데 필수적인 요소들로 보고 있습니다.

Q. 저는 보통 AI 세상을 만들어가는 빌더들을 만나면 가급적 ‘AGI에 대한 생각’을 물어봅니다. 아네카 당신한테는 질문을 하나 더 붙이고 싶어요: AGI에 대해 어떻게 느끼는지, 그리고 방금 말씀하신 맥락에서 ‘AGI의 되돌리기(Undo) 버튼’이 있다면 어떤 모습일까요?

AGI에 대해선… 저에겐 ‘언제’의 문제지 ‘도래의 여부’의 문제는 아닙니다. 보안이라는 작업의, 산업의 지형도 크게 바뀔 거예요. 이미 공격자들은 AI로 고도화된 소셜 엔지니어링을 하고 있고, AGI는 이를 더 가속할 겁니다. 보안 관련된 침해까지 걸리는 시간과 그 임팩트가 더 커질 거예요.

이건 결국, 사이버 공격이든 원치 않는 에이전트 행동이든 ‘가역성’의 문제로 귀결됩니다. AGI가 문제를 더 ‘급박하게’ 만들겠지만, 해법의 본질은 크게 다르지 않습니다. 앞서 말한 것처럼 에이전트의 전체 타임라인 이해, 가드레일, 그리고 액션의 ‘위험도 랭킹’— AGI는 이 위험에 대한 이해를 더 정교하게 만들어 줄 겁니다. 오탐/미탐을 줄이고, 진짜 위험한 액션을 위로 끌어올리는 데 있어서 말이죠.

다음은 ‘광범위한 통합’입니다. 다양한 시스템에 빠르게 들어가서 “무엇이 바뀌었는지”를 파악하고, 그 시스템 안에서 곧바로 ‘원래 상태로의 복귀’를 수행하는 능력. 이건 루브릭의 핵심 역량이기도 합니다. 우리는 매일 사이버 사건·운영상 실패·이제는 원치 않는 AI 에이전트 행동까지 복구를 돕고 있습니다.

물론 쉽지는 않습니다. 에이전트는 수백—어쩌면 수천—개의 시스템과 디바이스를 건드릴 수 있어요. 그 모든 걸 모니터링하고 추적해 ‘신호’를 뽑아내고, 정말 빠르게 되돌리기까지 — 어렵지만 무척 흥미로운 도전입니다.

Q. AGI가 어떤 의사결정에 닥쳤다고 할 때 스스로 결정을 내리고 움직이는 방향으로 가게 될까요, 아니면 여전히 인간(해커)이 결정할까요?

정답은 모릅니다. 다만 현행의 에이전트가 ‘구체적 결과’를 줘야 한다면, 어떤 형태의 AGI는 ‘아주 넓은 결과’를 줘도 스스로 알아서 실행할 수 있겠죠. 국가안보라는 맥락에서는 더 무서울 수 있습니다. ‘아주 광범위한 목표’를 주고 AGI가 실행하도록 하는 식으로요.

AGI는 기존의 고양이·쥐 게임을 ‘가속화’할 겁니다. 새로운 공격 벡터도, 방어 벡터도 생기겠죠. 사람이 개입하지 않는 형태의 AGI라면… 그건 본격적인 SF의 세계입니다. 가능성은 있겠지만, 그땐 오늘 우리가 논의한 범위를 넘어서는 훨씬 큰 사회적 문제가 뒤따를 겁니다.

Q. 재미있는 점은, 빌더들이 의외로 SF를 많이 이야기하지 않는다는 거예요. 모두가 현장에서 ‘만드는 일’에 몰두하고 있으니까요. 우리는 ‘지각 있는 시스템’을 상상해야 할까요, 아니면 그냥 스케일이 다른 기술로 다루면 될까요?

저는 SF를 사랑합니다. 늘 읽고, 자주 생각해요. 다만 빌더 관점에서는 그런 미래를 정확히 예측하긴 어렵습니다. 사회적 격변이 뒤따를 수 있고, 일상의 많은 것이 흔들릴 수 있으니까요.

Q. 마지막으로, 아네카 당신의 인생에 큰 영향을 준 책을 꼽는다면요? 최근이든 어린 시절이든요.

저는 SF 애독자입니다. 하나만 고르긴 어렵지만, AI와 관련해선 아이작 아시모프의 『아이, 로봇』이 성장기에 큰 영향을 줬어요.

제가 SF를 사랑하는 이유는 무수하게 많은 ‘대안적 현실’을 상상하게 해 주기 때문입니다. 특히 아시모프의 책들은 철학적이에요. 윤리, 그리고 오늘과 전혀 다른 상황에서 ‘어떻게 선택할 것인가’를 끊임없이 생각하게 합니다. 사실 SF를 사랑한 덕분에 빌더가 되기도 했어요. 먼 미래의 일부는 오늘 당장 고민할 것과 거리가 있을지 몰라도, 그 미래를 작은 단위로라도 그려 보고, 최신 기술로 그 ‘새로운 문제’를 푸는 일 — 그게 너무 신나요.

Q. 미래에 실제로 만들어지고 실현되길 바라는 SF 기술이 하나 있다면 뭔가요?

대부분의 SF는 디스토피아가 섞여 있죠. 위대한 기술의 진보 과정, 그 결과에는 부작용이 따르게 됩니다. 그래도 하나만 고르라면 ‘텔레포테이션(순간이동)’이요. 이동 시간을 없애 버릴 수 있다면 최고죠. 다른 행성·다른 항성계로 가는 일까지 가능해진다면, 정말 멋질 겁니다.

Q. 곧 그 순간에 가 닿게 될지도 모르죠 뭐 ^.^ 오늘 대화 고맙습니다.

초대해 주셔서 감사합니다. 즐거운 시간이었습니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!