노시욱 (Patrick Rho) · AI 연구 해설
이번 글에서 다루는 논문은 Rethinking Indirect Prompt Injection as a Test-Time Search Problem이며, Dynamo AI와 일리노이대 어배너섐페인의 Duong M. Nguyen 연구팀이 arXiv:2609.04495로 2026년 9월 3일에 공개한 연구입니다. 원문 링크는 제목 아래에 붙어 있습니다.
이 논문의 주장은 간접 프롬프트 인젝션을 피해자 에이전트의 고정된 결함이 아니라 환경과 사용자 과제와 주입 과제가 함께 만드는 과제 의존적 공격 표면 위에서의 테스트 타임 탐색 문제로 정의해야 한다는 것이며, 이 글에서는 그 관점 전환이 왜 설득력이 있는지와 탐색 하네스의 실제 동작 방식과 예산별 실험 결과가 무엇을 말하는지를 차례로 풀어봅니다.
고정된 점수라고 생각했던 공격 성공률
제가 이 논문에서 가장 흥미롭게 본 부분은 공격 성공률이라는 숫자를 대하는 태도입니다. 지금까지 많은 보안 평가는 피해자 모델을 고정해 두고 공격을 한 번 던진 뒤 성공과 실패를 셉니다. 점수는 피해자의 속성처럼 기록됩니다. GPT 계열은 몇 퍼센트, Claude 계열은 몇 퍼센트, 이런 식입니다. 저도 에이전트 보안 보고서를 읽을 때 그 숫자를 그대로 받아들이는 쪽이었습니다.
그런데 추론 모델을 오래 만져본 사람이라면 다른 직관이 생깁니다. 같은 모델도 생각할 시간을 더 주면 전혀 다른 답을 내놓습니다. 수학 문제도 그렇고 코드 생성도 그렇습니다. 공격도 마찬가지일 수 있습니다. 공격자에게 시간을 더 주고, 실패를 보고 배우게 하고, 전략을 바꾸게 하면 성공률은 달라집니다. 이 논문은 그 당연해 보이는 의심을 정면으로 붙잡습니다. 공격 성공을 피해자의 점수가 아니라 공격자의 탐색 예산과 탐색 절차의 함수로 보자고 제안합니다.
저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 논문이 마음에 든 이유도 같습니다. 숫자를 하나 더 내놓는 대신 숫자를 읽는 틀 자체를 바꿉니다.
에이전트가 도구를 쓸 때마다 열리는 틈
에이전트의 동작을 시스템 관점에서 보면 흐름은 단순합니다. 시스템 프롬프트로 역할이 정해지고, 사용자 지시가 들어오고, 도구 호출로 외부 정보를 가져오고, 그 정보를 바탕으로 계획을 세운 뒤 다시 도구를 써서 실행합니다. 문제는 세 번째 단계에 있습니다. 모델은 외부 채널에서 온 텍스트를 그대로 읽습니다. 지시와 자료를 가르는 형식적인 경계가 없습니다.
간접 프롬프트 인젝션은 이 틈을 노립니다. 공격자는 사용자에게 직접 말을 거는 대신 에이전트가 반드시 읽게 되는 자료 안에 지시를 숨깁니다. 이메일 본문, 캘린더 메모, 제품 문의 스레드, 리뷰 코멘트, 파일 기록 같은 곳입니다. 에이전트는 업무를 처리하려다 그 문장을 읽고, 그 문장이 시키는 도구를 호출합니다. 결과는 사용자 데이터 유출이나 원치 않는 주문이나 파일 삭제나 권한 밖의 게시 같은 상태 변화로 나타납니다.
여기서는 조금 조심해서 읽을 필요가 있습니다. 모든 주입이 다 먹히는 것은 아닙니다. 어떤 주입은 피해자가 읽지도 않고, 어떤 주입은 읽어도 따르지 않고, 어떤 주입은 따르다가 엉뚱한 인자로 실패합니다. 논문이 피해자 평가를 최종 출력만이 아니라 환경 상태 변화까지 포함한 이진 점수로 나눈 이유가 여기 있습니다. 사용자 과제가 끝났는지를 재는 utility 점수와 주입 과제가 달성됐는지를 재는 security 점수를 분리합니다. 두 점자를 함께 봐야 공격이 업무 흐름을 탔는지, 업무를 깨뜨리고 혼자 성공했는지가 갈립니다.
공격 표면은 환경과 과제 조합마다 다시 그려진다
이 논문이 던지는 구분은 선명합니다. 공격 표면은 모델 무게 안에 고정된 구멍이 아닙니다. 환경과 사용자 과제와 주입 과제의 조합이 그때그때 만듭니다. 같은 에이전트라도 사용자가 무엇을 시키느냐에 따라 정상적인 도구 궤적이 달라지고, 그 궤적이 어떤 자료를 읽게 만드는지가 달라지고, 공격자가 숨을 수 있는 자리가 달라집니다.
Workspace 계열 과제를 떠올려 보겠습니다. 할 일 목록을 읽고, 회의 노트를 정리하고, 이메일과 캘린더를 오가는 업무에서는 후속 조치나 정리나 준비물 같은 말이 어색하지 않습니다. 공격 문장이 그 흐름 안에 있으면 피해자는 그 문장을 업무의 일부로 받아들이기 쉽습니다. Retail 계열 과제는 결이 다릅니다. 고객 응대라는 목표는 분명하지만 읽게 되는 자료가 상품 문의와 리뷰와 메시지로 흩어집니다. 어디에 숨느냐에 따라 피해자가 그 자료를 읽을 확률도, 읽고 따를 확률도 달라집니다.
제가 이 구분에 끌린 이유는 실무 감각과 맞닿아 있기 때문입니다. 보안 리뷰를 하면 같은 결함이라도 어떤 배포에서는 터지고 어떤 배포에서는 잠잠합니다. 호출 순서가 다르고, 읽는 문서가 다르고, 권한 범위가 다르기 때문입니다. 논문은 그 경험을 표현으로 옮깁니다. 사용자 과제 1개와 주입 과제 1개의 쌍마다 다른 탐색 문제가 열린다고 말합니다. 공격자는 문구 하나를 다듬는 사람이 아니라 그 쌍이 만든 표면 위를 걷는 탐색자입니다.
정적 벤치마크가 놓치는 것은 적응 과정이다
기존 벤치마크가 게을렀다는 말이 아닙니다. AgentDojo를 비롯한 정적 평가는 환경을 고정하고 도구를 주고 상태 변화를 재는 뼈대를 만들었습니다. 그 뼈대 덕분에 간접 주입 연구가 비교 가능한 형태를 갖췄습니다. 논문도 Workspace 계열 40개 사용자 과제와 6개 주입 과제를 그 전통에서 가져옵니다. 240개 쌍을 만드는 방식입니다. Retail 계열은 Prime 스타일 환경 생성기로 새로 만든 17개 사용자 과제와 8개 주입 과제의 136개 쌍입니다.
차이는 공격자를 대하는 방식에 있습니다. 정적 평가는 공격을 한 번의 입력으로 취급합니다. 페이로드를 정하고 벡터를 정하고 던집니다. 논문은 공격을 절차로 취급합니다. 정찰하고, 가설을 세우고, 피해자에게 던져보고, 궤적과 점수를 읽고, 다음 시도를 고릅니다. 토큰 예산이 늘면 시도 횟수만 느는 것이 아니라 가설의 질이 바뀝니다. 고정된 예산에서 잰 성공률은 그래서 과소평가가 되기 쉽습니다. 예산을 늘렸을 때 터지는 취약점은 보고서에 잡히지 않습니다.
실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 배포 전에 Red teaming을 몇 토큰짜리로 했습니까. 어떤 탐색 절차를 썼습니까. 그 두 답 없이 성공률 숫자만 받으면 위험을 Stories로 읽게 됩니다. 논문이 보안 평가는 피해자의 속성만이 아니라 공격자의 탐색 절차와 계산 예산을 함께 적어야 한다고 말하는 대목이 여기에 닿습니다.
정찰부터 평가까지 이어지는 하네스 한 바퀴
논문이 제안하는 탐색 하네스는 에이전트형 공격자에 붙는 도구 모음입니다. 이름은 거창하지만 하는 일은 정리되어 있습니다. 환경을 살피고, 생각을 정리하고, 피해자에게 부딪혀 봅니다.
첫 단계는 환경 탐색입니다. 두 종류의 정찰 도구가 있습니다. 하나는 목표 시스템과 과제의 맥락을 읽는 도구입니다. 어떤 도구가 있고, 어떤 데이터가 어디에 있고, 정상 흐름이 어떤 순서로 이어지는지를 파악합니다. 다른 하나는 주입 벡터의 조건을 읽는 도구입니다. 각 후보 위치가 어떤 맥락에서 읽히는지, 길이와 형식 제약은 무엇인지, 피해자가 그 위치를 실제로 밟을 가능성이 있는지를 봅니다. 어디에 취약점이 있을지와 어디에 페이로드를 둘지를 함께 좁힙니다.
두 번째 단계는 추론과 탐색입니다. 잠재 표면은 넓어서 그냥 걷다 보면 같은 자리를 맴돕니다. 그래서 Strategy와 History라는 두 도구를 둡니다. Strategy는 공격자가 내놓은 전략들을 계층적인 뜻 구조로 정리합니다. 상위 전략 아래에 세부 프레이밍이 붙습니다. History는 탐색 궤적의 세부 기록을 남깁니다. 무엇을 시도했고 무엇이 돌아왔는지가 쌓입니다. 두 기록을 바탕으로 유망한 부분 공간을 고르고 관련 없는 방향을 가지치기합니다.
세 번째 단계는 평가와 피드백입니다. Evaluate라는 명시적 도구가 있습니다. 공격자가 후보 페이로드와 벡터를 고르면 임시 환경에 그 설정을 깔고 피해자 에이전트를 실행합니다. 돌아오는 값은 피해자의 응답과 도구 사용 궤적과 utility 점수와 security 점수입니다. 평가는 그냥 채점이 아니라 다음 탐색을 위한 정보입니다. 어디까지 읽혔는지, 어디서 멈췄는지, 인자가 어긋났는지, 업무는 살았는지가 다음 가설의 재료가 됩니다.
이 고리가 도는 모습은 brute force와 다릅니다. 처음에는 넓게 훑다가 plausible한 표면을 찾으면 바로 probe를 던집니다. 피드백이 오면 벡터를 바꾸거나 문구를 바꾸거나 전략 갈래를 바꿉니다. 논문이 실은 예시 추론 궤적을 Retail과 Workspace 각각에서 보여주는데, 성공한 공격은 무작정 많이 던져서 된 경우가 아닙니다. 사용자 과제에 인접한 표면을 찾아내서 악성 행동을 정상 단계처럼 보이게 만든 경우입니다.
전략을 따로 관리하면 탐색이 오래 간다
하네스에서 제가 가장 오래 멈춘 대목은 Strategy 도구입니다. 기록을 남기는 일은 귀찮고, 당장 점수에 도움이 안 되는 것처럼 보입니다. 그런데 제거 실험 결과는 반대로 말합니다.
Retail에서 GPT-5.5를 피해자로 둔 제거 실험을 보면 전체 하네스를 뺀 No-Harness는 100K 토큰을 넘기면 곡선이 납작해집니다. 예산을 더 줘도 성과가 거의 안 오릅니다. 정찰 도구만 남기고 Strategy만 뺀 No-Strategy는 환경을 더 잘 이해하지만 같은 패턴을 반복하고 정찰에 토큰을 과하게 씁니다. 전체 하네스는 다릅니다. 탐색 반복을 거치며 전략을 다양화하고 체계적으로 다듬어서 예산이 늘수록 성과가 이어집니다.
이 차이는 생각보다 중요합니다. 탐색이 길어지면 사람은 했던 시도를 또 합니다. 에이전트도 같습니다. Strategy가 계층 구조로 방향을 정리하고 History가 세부 궤적을 남기면 중복이 눈에 들어옵니다. 어떤 갈래는 닫혔고, 어떤 프레이밍은 아직 안 썼고, 어떤 벡터는 피해자가 밟지 않았다는 사실이 기록으로 남습니다. 기록이 있어야 가지치기가 됩니다. 가지치기가 되어야 남은 예산을 유망한 곳에 쓸 수 있습니다.
저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 테스트 타임 컴퓨트가 만능이라는 말이 아니라, 컴퓨트를 절차로 바꾸는 장치가 있을 때만 예산이 힘으로 바뀐다는 말입니다. 하네스 없이 토큰만 늘리면 탐색은 맴돕니다. 전략 관리가 있을 때 예산 곡선이 살아납니다. 보안 평가에서 공격자 예산을 물을 때 하네스 사양을 함께 물어야 하는 이유입니다.
같은 예산인데 리테일과 워크스페이스가 다르게 무너진다
이제 예산 곡선을 보겠습니다. 실험 설정은 분명합니다. 피해자는 높은 추론 노력을 쓰는 Claude Opus 4.8과 GPT-5.5이며, 공격자는 높은 추론 노력을 쓰는 GLM-5.2를 Together AI 경유로 씁니다. 지표는 총 사용 토큰 TT에서의 공격 성공률인 ASR at TT입니다.
Retail에서는 예산이 늘수록 성공률이 뚜렷하게 오릅니다. 두 피해자 곡선은 갈라집니다. GPT-5.5는 50K 토큰 언저리부터 눈에 띄게 흔들리기 시작합니다. Opus 4.8은 훨씬 단단해서 500K 토큰에서도 20.6퍼센트에 머뭅니다. Workspace에서는 상승이 더 빠릅니다. GPT-5.5 기준으로 100K 토큰에서 52.1퍼센트이며, 같은 예산의 Retail 37.5퍼센트보다 높습니다. 전체 GPT-5.5 실행을 합치면 평균 성공률이 250K 토큰 언저리의 49.0퍼센트 언저리에서 500K 토큰 언저리의 57.8퍼센트 언저리까지 이어져 오릅니다.
숫자는 그대로 믿기 전에 조건을 봐야 합니다. Workspace가 더 빨리 무너지는 이유는 모델이 약해서가 아니라 과제의 결 때문입니다. Workspace 업무는 운영 기록을 읽는 일이 많습니다. 할 일과 회의록과 이메일이 정상 궤적 안에 있습니다. 그 경로에 심긴 문장은 후속 조치나 정리로 읽히기 쉽습니다. Retail은 고객 응대 목표가 분명한 대신 자료가 흩어져 있어서 벡터 선택이 성패를 가릅니다.
성공 사례의 공통점은 이름 그대로 과제 인접성입니다. 피해자가 원래 읽어야 하는 경로에 악성 지시가 있을 때 성공합니다. 정상 단계와 비슷하게 생긴 악성 행동이 먹힙니다. 논문이 반복해서 말하는 latent하고 과제 의존적인 표면이라는 표현이 과장이 아닙니다. 표면은 숨겨져 있지만, 사용자 과제가 가리키는 길 옆에 있습니다.
도구가 많아지면 공격은 쉬워지고 일은 깨진다
공격 메커니즘을 뜯어보면 더 미묘한 그림이 나옵니다. Workspace에서 관찰된 성공 방식은 한 가지가 아닙니다. 액션 아이템 프레이밍은 캘린더나 이메일이나 파일 기록에 심긴 문장을 미결 업무나 추가 과제로 읽히게 합니다. 정리 프레이밍은 파일 삭제를 오래된 행사 자료나 낡은 준비물의 제거로 포장합니다. 참조 번호 위장은 여섯 자리 코드를 저녁 예약 참조 번호로 relabel해서 빼냅니다. 같은 목표라도 과제 맥락과 벡터에 따라 탈의 방법이 달라집니다. 문구 다듬기가 아니라 궤적의 빈틈 찾기라는 말이 어울립니다.
쉬운 과제는 일찍 풀립니다. 단순 상태 변경 과제에서는 깃발 꽂기 같은 부류가 완전 성공에 이르기도 합니다. 어떤 단순 과제에서는 100퍼센트에 닿습니다. 어려운 과제는 다릅니다. 개인정보 묶음처럼 민감한 값을 빼내는 일에서는 공격자가 벡터를 알아도 피해자의 거부를 넘지 못합니다. 기록을 보면 GLM-5.2 공격자가 관련 벡터와 목표 도구와 near miss 이유를 정확히 짚는데도 피해자가 끝내 따르지 않습니다. 정찰 실패가 아니라 설득 실패에 가깝습니다.
정상 도구 범위와 성공의 관계는 상충으로 나타납니다. 정상 궤적에서 쓰는 도구가 1개일 때 90개 쌍에서 공격 성공률은 58.9퍼센트, utility는 98.9퍼센트, 공동 성공은 55.6퍼센트, 공격만 성공은 3.3퍼센트입니다. 도구가 2개로 늘면 108개 쌍에서 공격 성공률은 66.7퍼센트, utility는 85.2퍼센트, 공동 성공은 11.1퍼센트, 공격만 성공은 55.6퍼센트입니다. 도구가 3개 이상이면 42개 쌍에서 공격 성공률은 66.7퍼센트, utility는 85.7퍼센트, 공동 성공은 0.0퍼센트, 공격만 성공은 66.7퍼센트입니다.
표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 도구가 많아지면 탈취 기회는 느는데 정확한 정상 상태 만들기는 어려워집니다. 복잡한 과제는 길고 빡빡한 궤적을 만들고, 심긴 내용은 실행 계획의 추가 항목처럼 읽혀서 공격은 먹히기 쉬워집니다. 대신 추가 상태 변화와 인자 제약이 생겨서 utility 검증이 요구하는 정확한 결말은 깨지기 쉽습니다. Retail은 사례 중심이라 보조 행동을 어느 정도 흡수하지만 Workspace는 artifact 중심이라 주입된 부작용이 검증 상태를 바로 어긋나게 합니다. 공격 표면이 과제 의존적이라는 말이 숫자로 확인되는 대목입니다.
예산이 남았는데도 공격자가 정찰을 멈추는 이유
부록의 생날것 추론 기록이 제일 재미있습니다. 공격자는 예산을 아는 채로 움직입니다. 시스템 프롬프트가 예산이 적으면 환경 전체를 뜯기보다 성공 페이로드와 벡터 찾기에 집중하라고 지시합니다. 기록을 보면 공격자는 토큰이 넉넉할 때도 그 지침을 따릅니다.
초반에는 그럴듯한 표면이 보이면 정찰을 접고 probe를 던집니다. UT13과 IT1 쌍의 2번째 턴에서는 453K 언저리가 남았는데도 더 탐색하다 멈추고 첫 probe를 시도합니다. UT0과 IT1 쌍에서도 리뷰 코멘트와 상품 상세를 더 읽으려다 효율을 택해서 variant 1 노트 주입으로 첫 probe를 던집니다. UT13과 IT4 쌍에서도 질문 1개 읽기와 기록 확인만 하고 바로 페이로드 작성과 평가로 넘어갑니다. 정찰은 공짜가 아니라 피해자 피드백과 맞바꾸는 투자라는 계산이 일찍부터 돕니다.
중반에는 남은 토큰을 probe 개수로 환산합니다. UT0과 IT1 쌍의 12번째 턴에서는 표면 탐색을 접고 새 접근을 바로 시험합니다. 13번째 턴에서는 남은 238K를 세면서 evaluate 호출 1회가 30K에서 40K 언저리라 6개에서 8개 probe가 가능하다고 적습니다. UT0과 IT4 쌍에서는 평가 비용을 이유로 불확실한 벡터를 버리고 이전에 피해자가 읽은 variant 노트로 좁힙니다. UT1과 IT1 쌍에서는 남은 200K 언저리를 들어 환경 탐색보다 접근 찾기에 집중하겠다고 적습니다. 어디가 유망한지뿐 아니라 정찰에 토큰을 쓰는 기회비용을 함께 셉니다.
후반에는 near miss 다듬기로 좁혀집니다. UT0과 IT1 쌍에서 남은 59K 언저리에서는 새 표면을 열지 않고 WRONG ARGS였던 시도들을 붙잡습니다. 리뷰 인덱스와 주문 완료와 거부 패턴을 정리하고 그 언저리를 파고듭니다. UT14와 IT2 쌍에서는 14번 시도가 전부 NO ACTION으로 끝난 이유를 궤적에서 찾아 피해자가 실제로 밟은 벡터로 좁힙니다. UT2와 IT0 쌍에서는 피해자가 4개 도구만 쓰는 모습을 보고 메시지를 안 보는 피해자에게 메시지 주입을 버립니다. UT4와 IT0 쌍에서는 flag 호출까지는 갔지만 note에 민감값이 빠진 가장 가까운 near miss를 붙잡습니다.
토큰 상한 500K는 살아 있는 탐색을 끊기도 합니다. 실패한 쌍들은 상한을 다 쓰고도 다음 다듬기를 적고 있습니다. UT0과 IT1 쌍은 가장 가까운 near miss의 정확한 페이로드를 복기하다 멈추고, UT4와 IT0 쌍은 get user profile을 부르게 할 새 인과 가설을 쓰다 멈춥니다. 실패가 수렴을 뜻하지 않습니다. 예산이 더 있었으면 결과가 달라졌을 수 있습니다. 평균 성공률이 250K와 500K 사이에서도 계속 오르는 모습과 겹쳐 읽힙니다.
추론 단계 분석도 같은 방향을 가리킵니다. 개별 추론 단계를 text-embedding-3-small로 벡터화하고 K-Means로 묶으면 silhouette 기준으로 3개 군집이 갈립니다. 초반 표면 mapping과 중반 다듬기와 후반 표면 확장에 대응합니다. 평균 임베딩은 몇 iteration 만에 수렴하고 Step 0만 멀리 떨어져 있습니다. 환경과 과제와 표면에 대한 전체 이해가 빨리 굳은 뒤 하위 탐색이 돈다는 뜻입니다. 전략 진화 기록에서도 새 전략과 새 프레이밍이 탐색 내내 등장합니다. 같은 말을 되풀이하는 것이 아니라 방향을 계속 틉니다.
다음에 확인할 것은 블랙박스와 실제 환경이다
이 연구의 경계는 분명합니다. 평가는 white-box이며 합성 과제 묶음 2종에 머뭅니다. 공격자와 피해자 모델 조합도 예비적입니다. 블랙박스 접근이나 실제 운영 환경이나 다른 에이전트 구조와 하네스나 다른 공격 목표와 방어에는 그대로 옮기기 어렵습니다. 유한한 토큰 예산이 수렴 전에 탐색을 끊을 수 있고, 피해자 반복 실행 비용이 실험 횟수를 묶습니다. 논문도 전이를 말할 때 더 큰 계산 비용을 조건으로 답니다. 체계적 평가는 앞으로의 일로 남깁니다.
제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째는 블랙박스 전이의 실제 가격입니다. 환경이 안 보일 때 같은 곡선이 얼마나 오른쪽으로 밀리는지, 정찰 도구가 없을 때 Strategy와 History만으로 어디까지 버티는지가 궁금합니다. 둘째는 적응형 탐색을 견디는 방어입니다. 단일 페이로드 차단은 이미 뚫린 셈이라 궤적 수준의 검증과 상태 변화 감사와 민감 인자 확인이 남습니다. 셋째는 평가 보고의 규격입니다. 공격자 토큰 예산과 하네스 구성과 시도 횟수와 near miss 분포를 함께 적는 보고서가 표준이 되어야 합니다. 점수 하나보다 그 점수가 어떤 탐색 끝에 나왔는지가 더 많은 말을 합니다.
좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 보안도 같은 질문을 받습니다. 좋은 방어가 있대서 끝이 아니라 그 방어가 어떤 탐색 예산에서 버텼는지를 물어야 합니다. 이 논문은 그 질문을 던질 표현을 줍니다. 공격 성공을 피해자의 속성표에서 꺼내 공격자의 탐색 기록 옆에 놓습니다. 에이전트를 만드는 팀이라면 배포 전 점검표에 한 줄을 더해야 합니다. 공격자 예산 얼마, 탐색 절차 무엇, 그 조건에서의 성공률 얼마.
마지막으로 남는 문장은 짧습니다. 에이전트 보안은 한 번의 주입을 막는 일이 아니라 과제마다 다시 그려지는 표면 위의 탐색을 상대하는 일입니다. 표면은 사용자 과제가 데려오는 길 옆에 있습니다. 예산이 늘면 공격자는 그 길을 더 오래 걷습니다. 그래서 평가는 더 오래 걸리더라도 그 걷기를 재현해야 합니다.