메뉴는 실행의 사전 분포다, 온라인 에이전트를 위한 상태 경로 도구 메뉴

이번에 다룰 논문은 The Menu Is an Execution Prior: State-Path Tool Menus for Online Agents로, arXiv 번호 2609.09395로 공개된 연구입니다. 이 연구는 도구 메뉴를 요청 문장과의 관련도 순위가 아니라 실행 경로에 대한 사전 분포로 설계해야 한다고 주장합니다. 원문 링크는 제목 아래에 걸어 두었습니다.

안녕하세요, 패트릭입니다. 저는 이 논문을 처음 봤을 때 제목에서 잠시 멈췄습니다. 메뉴라는 단어가 너무 일상적이었기 때문입니다. 보통 에이전트 연구에서 메뉴라고 하면 검색 결과를 보여주는 사소한 인터페이스처럼 들리는데, 저자들은 그 사소해 보이는 장치가 온라인 성패를 가른다고 말합니다. 그렇다면 메뉴는 왜 이렇게 중요해졌을까요. 그 이야기는 식당에서 시작하면 가장 빨리 이해됩니다.

식당 메뉴로 보면 이 논문이 바로 이해됩니다

손님이 식당에 들어와서 김치찌개를 주문했다고 해보죠. 주방 입장에서 이 주문을 완성하려면 마지막 행동만으로는 부족합니다. 쌀을 씻어 밥을 짓고, 육수를 내고, 재료를 손질하고, 불 조절을 해야 비로소 찌개 한 그릇이 나옵니다. 그런데 만약 주방에 전달된 메뉴판에 완성된 찌개 사진만 크게 실려 있고 정작 밥솥과 육수 냄비 사용법이 빠져 있다면 어떻게 될까요. 요리사는 무엇을 만들어야 하는지는 알지만, 그것을 만들 손발이 묶인 상태가 됩니다.

온라인 에이전트의 상황도 이와 크게 다르지 않습니다. 에이전트가 쓸 수 있는 도구는 수천 개에 이르는데, 실행 직전에 모델이 실제로 볼 수 있는 건 그중 짧게 잘라낸 순서 있는 부분집합뿐입니다. 논문은 이것을 도구 메뉴라고 부르는데, 메뉴에 없는 도구는 그 실행에서 아예 호출할 수 없다는 규칙이 있습니다. 그래서 메뉴는 단순한 추천 목록이 아니라 행동의 경계가 됩니다. 저는 이 정의가 참 마음에 들었습니다. 그동안 검색과 순위 이야기는 에이전트 바깥의 정보검색 문제처럼 다뤄졌는데, 여기서는 실행 가능성을 미리 정해버리는 장치로 위치가 바뀌기 때문입니다.

그렇다면 다음 질문이 바로 생깁니다. 지금의 메뉴 구성 방식은 어디에서 어긋나는 걸까요.

왜 요청과 닮은 도구를 고르면 일이 풀리지 않을까

지금 널리 쓰이는 메뉴 구성 방식은 요청과의 관련도로 도구를 줄 세우는 일입니다. 요청 문장에 자주 등장하는 단어를 포함한 도구, 설명문이 요청과 의미적으로 가까운 도구가 위로 올라옵니다. 이 방식은 한 단계짜리 질문에는 꽤 잘 맞습니다. 날씨를 묻는데 날씨 조회 도구가 1등으로 뜨는 장면처럼요. 문제는 여러 단계가 얽힌 작업에서는 사정이 달라진다는 데 있습니다.

여러 단계로 된 작업은 마지막 행동만으로는 절대 완성되지 않습니다. 결제라는 최종 행동을 하려면 먼저 본인 인증을 거쳐야 하고, 인증을 하려면 예약 번호를 조회해야 하며, 예약 번호를 알려면 검색 기록을 불러와야 하는 식입니다. 즉 최종 행동의 입력이 되려면 앞선 도구들이 차례로 결과물을 만들어줘야 합니다. 그런데 관련도 순위는 대개 마지막 행동을 맨 위로 올립니다. 요청 문장에 결제가 들어 있으니 결제 도구의 점수가 가장 높게 나올 수밖에 없기 때문입니다. 반면 예약 조회나 본인 인증 같은 도구는 요청 문장과 직접 닮지 않아서 뒤로 밀립니다.

제가 이 대목에서 가장 흥미롭게 본 부분은 저자들이 이 실패를 검색 품질의 문제로 보지 않았다는 점입니다. 점수를 조금 더 잘 매기면 해결될 일이 아니라, 애초에 무엇을 기준으로 줄을 세우느냐가 잘못됐다고 본 것이죠. 관련도는 무엇을 할지를 말해주지만, 어떤 순서로 무엇을 준비해야 하는지는 말해주지 않습니다. 그래서 메뉴에는 최종 행동이 버젓이 있는데도 에이전트는 첫발을 떼지 못합니다. 실행 가능한 입구가 없고, 중간 재료를 만들어줄 생산자 도구가 빠져 있기 때문입니다. 실제 시스템 관점에서 보면 이 지적은 꽤 아픕니다. 저희가 새로운 AI 아키텍처를 볼 때도 숫자 이전에 실패의 모양을 먼저 보는데, 이 논문이 짚은 실패는 너무 익숙한 모양이기 때문입니다. 도구는 많은데 시작할 도구가 없는 상태요.

여기서 재미있는 질문이 생깁니다. 관련도가 아니라면 메뉴는 무엇을 기준으로 줄을 세워야 할까요.

메뉴를 실행의 사전 분포로 본다는 게 무슨 뜻일까

저자들의 답은 메뉴를 실행 사전 분포로 보자는 것입니다. 사전 분포라는 말이 어렵게 들리지만, 생각해보면 사람도 비슷하게 판단합니다. 여행을 떠나기 전에 지도 앱을 켜면 앱은 현재 위치에서 목적지까지 갈 수 있는 경로들을 먼저 보여주고, 그 경로 위에 있는 주유소나 휴게소를 함께 보여줍니다. 목적지와 이름이 비슷한 장소를 전부 나열하지는 않죠. 갈 수 있는 길 위에 있는 것만 보여주는 것이고, 그 선택 자체가 이미 실행에 대한 추측입니다.

논문이 말하는 상태 경로는 바로 이 지도 위의 길에 가깝습니다. 관찰 가능한 요청 상태에서 원하는 결과 상태까지, 실행 전에 미리 그려보는 경로라는 것이죠. 그리고 메뉴는 그 경로들에 대한 사전적인 믿음, 즉 어떤 길이 실제로 걸어볼 만한지를 미리 담아두는 그릇이 됩니다. 요청 문장과 닮았느냐가 아니라, 이 상태에서 저 상태까지 이어지는 길 위에 있느냐가 기준이 됩니다. 그래서 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 메뉴의 역할이 검색 결과에서 실행 계획의 일부로 이동했기 때문입니다.

물론 여기서 조금 조심해서 읽을 필요가 있습니다. 사전 분포라고 해서 에이전트의 자유를 빼앗는 고정 스크립트를 뜻하지는 않습니다. 메뉴는 여전히 후보일 뿐이고, 실제 선택은 온라인 실행 중에 에이전트가 합니다. 다만 출발 전에 갈 만한 길의 모양을 알려주는 것이죠. 등산로 입구에 세워진 안내판처럼요. 안내판이 정상을 대신 올라가주지는 않지만, 어느 갈림길에서 물을 채우고 어느 능선에서 체력을 아껴야 하는지는 미리 알려줍니다. 이 논문의 메뉴도 같은 일을 합니다. 무엇을 할지가 아니라, 어떤 순서로 준비하면 걸어볼 만한지가 담깁니다.

그렇다면 이런 메뉴는 실제로 어떻게 만들 수 있을까요. 무작정 크게 만들면 되는 걸까요.

메뉴를 크게 만들면 해결될 문제는 아닙니다

직관적으로는 메뉴를 크게 만들면 될 것 같습니다. 32개를 보여줘서 부족하면 64개, 128개를 보여주면 언젠가는 필요한 도구가 들어오지 않을까요. 그런데 이 논문이 보여주는 장면은 정반대입니다. 잘 설계된 32개짜리 메뉴가 기존 방식의 128개짜리 목록보다 더 많은 완전한 체인을 담아낸다는 것이죠. 숫자로 보면 4분의 1인데, 실행 가능성으로 보면 오히려 앞섭니다.

이 차이는 생각보다 중요합니다. 메뉴가 커지면 에이전트가 봐야 할 분량이 늘어나고, 그만큼 주의가 분산되며, 컨텍스트 비용도 함께 늘어납니다. 반면 메뉴가 작아도 실행 순서가 맞으면 에이전트는 바로 움직일 수 있습니다. 마치 요리 레시피처럼요. 재료가 백 가지 나열된 장보기 목록보다, 10가지 재료가 순서대로 정리된 레시피가 요리에 훨씬 도움이 됩니다. 양이 아니라 배열이 일을 하기 때문입니다.

개인적으로 인상 깊었던 점은, 이 결과가 단순히 운이 좋아서 나온 것이 아니라 구조에서 비롯됐다는 것입니다. 관련도 순위로 뽑은 128개는 최종 행동 주변에 비슷한 것들을 잔뜩 모아두는 경향이 있습니다. 이름은 비슷하지만 실행 순서를 잇지 못하는 도구들이죠. 반면 상태 경로를 기준으로 고른 32개는 서로 이어집니다. 들어갈 수 있는 입구가 있고, 중간에 입력을 채워주는 도구가 있으며, 마지막에 결과를 매듭짓는 도구가 있습니다. 저는 여기서 멈칫했습니다. 우리가 에이전트 성능을 논할 때 모델 크기나 프롬프트 이야기는 많이 하는데, 정작 모델 눈앞에 무엇을 어떤 순서로 올려두느냐는 이야기는 적었기 때문입니다.

그렇다면 이 이어지는 메뉴는 어떤 기계로 만드는 걸까요. 그 속을 들여다볼 차례입니다.

상태 경로는 출발지에서 목적지까지 미리 그려보는 길입니다

상태 경로라는 아이디어를 조금 더 천천히 살펴보겠습니다. 에이전트가 받는 요청은 대개 완결된 문장이지만, 시스템 입장에서 보면 그건 출발 상태에 가깝습니다. 아직 로그인이 안 됐고, 아직 조회 결과가 없고, 아직 인증 토큰이 없는 상태요. 원하는 결과는 그 반대편에 있습니다. 결제가 끝났고, 예약이 확정됐고, 문서가 발행된 상태입니다. 두 상태 사이에는 빈틈이 있고, 그 빈틈은 도구 호출로만 메울 수 있습니다.

상태 경로는 그 빈틈을 메우는 순서를 미리 그려보는 일입니다. 어떤 도구가 지금 상태에서 바로 실행될 수 있는지, 그 도구의 결과가 다음 도구의 어떤 입력을 채워주는지, 그리고 그런 순서가 과거의 성공 경로에서 자주 등장했는지를 함께 봅니다. 세 가지가 따로 놀면 안 되고 같이 맞아야 합니다. 지금 실행할 수 없는 도구는 아무리 목적지와 닮아도 소용없고, 입력을 채워주지 못하는 중간 도구는 길을 끊어버리며, 한 번도 본 적 없는 낯선 순서는 도박에 가까워지기 때문입니다.

여기서 저자들의 선택이 영리하다고 느낀 지점은 경로를 실행 후에 설명하는 용도로 쓰지 않았다는 데 있습니다. 보통은 에이전트가 실행한 뒤에 로그를 보고 경로를 복원하는데, 이 연구는 순서를 뒤집어 실행 전에 경로를 메뉴에 녹입니다. 그래서 메뉴 자체가 일종의 지도 초안이 됩니다. 에이전트는 여전히 온라인에서 판단하지만, 빈 종이가 아니라 밑그림이 있는 종이 위에서 판단하는 것이죠. 실제 운영을 떠올리면 이 차이는 큽니다. 밤사이 스키마가 바뀌거나 아침에 특정 도구가 점검 중이어도, 밑그림이 있으면 에이전트는 다음 갈림길을 빨리 찾습니다.

그런데 이 밑그림을 그리려면 세 가지 신호를 한꺼번에 읽는 눈이 필요합니다. 그 눈이 바로 인코더입니다.

세 가지 신호를 함께 읽는 인코더가 생긴 이유

인코더 이야기가 나오면 어렵게 느껴질 수 있는데, 하는 일로 보면 단순합니다. 각 도구를 따로 평가하지 않고, 경로 위에서의 역할로 평가하는 것이죠. 논문이 함께 보는 세 가지 신호는 각각 다른 질문에 답합니다. 지금 상태에서 이 도구가 바로 실행될 수 있는가, 이 도구의 출력이 뒤따르는 도구의 입력을 실제로 채워주는가, 그리고 이런 순서가 학습 경로에서 반복적으로 등장했는가입니다.

첫 번째 신호는 실행 가능성입니다. 아무리 좋은 도구라도 지금 가진 입력으로 호출할 수 없으면 메뉴 앞부분에 둘 이유가 없습니다. 예를 들어 예약 번호 없이 결제 확인을 부르는 일은 순서가 어긋난 것이죠. 두 번째 신호는 입출력 궁합입니다. 앞 도구가 만든 날짜 형식이 뒤 도구가 요구하는 형식과 맞아야 하고, 사용자 식별자가 다음 단계로 그대로 이어져야 합니다. 이름만 비슷한 도구를 고르면 바로 이 지점에서 길이 끊깁니다. 세 번째 신호는 과거의 순서 기억입니다. 학습 경로에서 자주 함께 등장한 순서는 그 자체로 검증된 습관에 가깝습니다. 물론 과거에 자주 등장했다고 해서 항상 옳지는 않지만, 아무 단서 없이 고르는 것보다는 훨씬 낫습니다.

저는 이 세 신호의 조합을 일종의 오답 노트처럼 읽었습니다. 하나만 보면 속기 쉬운데, 셋을 겹치면 실수가 드러나기 때문입니다. 실행 가능성만 보면 당장 누를 수 있는 버튼만 모이고, 입출력 궁합만 보면 당장은 못 누르는 도구가 섞이며, 과거 순서만 보면 지금 상황과 안 맞는 옛날 길이 들어옵니다. 셋을 함께 봐야 지금 여기서 걸어볼 만한 길이 보입니다. 그리고 이 겹쳐보기가 메뉴 전체의 성격을 바꿉니다. 도구를 하나씩 고르는 일이 아니라, 이어지는 길을 통째로 고르는 일이 되기 때문입니다.

그렇다면 이 인코더의 판단은 실제 메뉴 조립 과정에서 어떻게 쓰일까요.

들어갈 자리를 만들고 순서를 바로잡는 두 단계 장치

전체 장치는 검색기와 순위 재조정기라는 두 단계로 움직입니다. 이름은 거창하지만, 하는 일을 풀어 쓰면 꽤 직관적입니다. 먼저 걸어 들어갈 만한 후보들을 빠짐없이 모으고, 그다음에 그 후보들을 실행 순서대로 다시 줄 세우는 것이죠. 순서가 중요한 이유는 메뉴가 순서 있는 목록이기 때문입니다. 에이전트는 위에서부터 읽으며 다음 행동을 정하는데, 생산자가 소비자보다 뒤에 있으면 눈에는 보여도 손이 먼저 가지 않습니다.

검색기가 챙겨야 하는 몫은 세 가지로 나뉩니다. 바로 실행할 수 있는 입구, 비어 있는 입력을 채워줄 생산자, 그리고 마지막에 일을 끝낼 최종 행동입니다. 이 셋 중 하나라도 빠지면 체인이 끊깁니다. 입구가 없으면 시작을 못하고, 생산자가 없으면 중간에 멈추며, 최종 행동이 없으면 마무리를 못 합니다. 그래서 검색기의 목표는 비슷한 것을 많이 모으는 일이 아니라, 끊기지 않는 조합을 모으는 일이 됩니다. 저는 이 대목에서 무릎을 쳤습니다. 검색의 성공 기준이 관련도에서 완결성으로 바뀌었기 때문입니다.

다음으로 순위 재조정기는 생산자를 소비자 앞으로 당깁니다. 겉으로 보면 정렬을 바꾸는 사소한 일 같지만, 에이전트의 실행 흐름에서는 결정적입니다. 먼저 인증 토큰을 만들고 나서 결제를 부르는 순서가 눈에 보이면 에이전트는 자연스럽게 그 길을 따릅니다. 반대로 결제가 먼저 보이면 에이전트는 없는 입력을 쥐고 헤매게 됩니다. 같은 재료라도 조리 순서가 적힌 카드와 뒤섞인 카드의 차이만큼 결과가 달라지는 것이죠. 이 장치는 에이전트 자체를 바꾸지 않습니다. 모델 가중치도 그대로고 프롬프트 기법도 그대로입니다. 바뀌는 건 모델이 실행 직전에 보는 풍경뿐인데, 그 풍경이 바뀌자 온라인 성공률이 움직였다는 것이 이 논문의 주장입니다.

그렇다면 그 움직임을 숫자로 확인해볼 차례입니다. 숫자는 그대로 믿기 전에 조건을 봐야 합니다.

32개가 128개를 이기는 장면을 어떻게 읽어야 할까

ToolBench에서의 결과는 한눈에 들어옵니다. 온라인 성공률이 0.737에서 0.898로 올랐고, 검색과 순위 재조정과 생성과 라우팅을 각각 내세운 기준선들을 에이전트를 바꾸지 않은 채로 앞섰다는 것이죠. 0.737이라는 출발점이 이미 낮은 점수는 아닌데, 거기서 0.16포인트 넘게 올렸다는 것은 실패하던 작업 6개 중 1개꼴을 추가로 살려냈다는 뜻에 가깝습니다. 운영 관점에서 보면 이 차이는 작지 않습니다. 열 번 중 일곱 번 되던 일이 열 번 중 아홉 번 되는 일로 바뀌면, 재시도와 사람 개입의 빈도가 눈에 띄게 줄기 때문입니다.

더 눈에 띄는 숫자는 32와 128의 대비입니다. 상태 경로 메뉴는 32개만으로도 완전한 체인을 더 많이 담아냈는데, 기존 공식 목록은 128개를 보여주고도 그에 못 미쳤다는 것이죠. 이 대목은 오해하기 쉬워서 조금 조심해서 읽을 필요가 있습니다. 32가 128보다 항상 낫다는 뜻이 아니라, 무엇을 기준으로 고르느냐가 개수보다 중요하다는 뜻입니다. 관련도로 뽑은 큰 메뉴는 비슷한 최종 행동 주변에 밀집되는 반면, 경로 기준으로 뽑은 작은 메뉴는 입구와 생산자와 마무리를 고루 담기 때문입니다. 같은 예산을 어디에 쓸지 고르는 일이라고 보면 됩니다. 넓게 뿌리는 대신 이어지게 쓰는 것이죠.

여기서는 반론도 함께 들어야 합니다. ToolBench는 도구 사용 능력을 재는 대표적인 장터이지만, 모든 실무 환경을 대신하지는 않습니다. 도구의 설명 품질이나 스키마 안정성, 외부 시스템의 응답 지연 같은 변수는 벤치마크 바깥에 남아 있습니다. 그럼에도 제가 이 결과를 가볍게 보지 않는 이유는 이득의 모양이 일관되기 때문입니다. 단일 벤치마크의 뾰족한 숫자가 아니라, 체인을 더 많이 담아내고 순서를 바로잡는 구조적 변화가 숫자로 따라왔다는 것이죠. 숫자는 결과일 뿐이고, 그 앞에 있는 배열의 변화가 진짜 이야기라고 봅니다.

그렇다면 이 배열의 변화는 모델이 바뀌어도 유지될까요.

에이전트를 바꾸지 않고도 성능이 오르면 남는 질문

이 논문에서 제가 앞으로 보고 싶은 것 중 하나는 실행기 교체 실험입니다. 저자들은 서로 다른 크기와 계열의 모델을 실행기로 바꿔 끼워도 성공률 향상이 유지된다고 보고합니다. 이 보고가 사실이라면 의미가 큽니다. 메뉴의 이득이 특정 모델의 눈치나 버릇에 기대는 것이 아니라, 실행 구조 자체에서 오기 때문입니다. 작은 모델은 길을 잃기 쉬워서 지도가 더 필요하고, 큰 모델은 지도 없이도 헤매지 않을 것 같지만 실제로는 큰 모델도 순서가 꼬이면 헛걸음을 하기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그렇다면 이 메뉴는 어디에 두는 것이 가장 쌀까요. 실행 직전에 매번 계산하는 비용과 미리 계산해두는 비용 중 어느 쪽이 운영에 맞을까요. 인코더가 세 가지 신호를 읽으려면 도구들의 입출력 명세와 과거 경로를 들고 있어야 하는데, 도구가 수천 개로 늘고 스키마가 자주 바뀌는 환경에서는 이 준비물의 신선도를 유지하는 일이 만만치 않습니다. 메뉴가 좋아도 메뉴를 만드는 시간이 길어지면 온라인 이득이 상쇄될 수 있기 때문입니다. 논문은 에이전트를 바꾸지 않고 메뉴만으로 이득을 봤다는 점을 내세우는데, 저는 그 다음 문장이 궁금합니다. 메뉴를 만드는 비용은 누가, 언제, 얼마나 내는가 하는 것이죠.

또 하나 짚고 싶은 것은 실패의 모양입니다. 성공률이 0.898까지 올랐다는 것은 뒤집으면 1할 남짓은 여전히 실패한다는 뜻입니다. 그 남은 실패는 어디에서 생길까요. 입구는 찾았는데 생산자의 출력 형식이 미묘하게 어긋나는 경우일 수도 있고, 과거에 없던 새로운 순서가 필요한 경우일 수도 있습니다. 지도가 아무리 좋아도 공사 중인 도로는 지도에 없습니다. 그래서 저는 다음 버전의 연구가 성공한 체인뿐 아니라 끊긴 체인의 지도도 함께 보여주길 바랍니다. 어디에서 길이 끊기는지를 알아야 다음 지도를 더 잘 그릴 수 있기 때문입니다.

이제 마지막으로, 이 연구가 에이전트 설계 전체에 던지는 질문을 정리해보겠습니다.

제가 다음 연구에서 보고 싶은 장면들

오래된 질문이 하나 있습니다. 에이전트를 똑똑하게 만드는 일은 모델을 키우는 일일까요, 아니면 모델이 보는 세상을 정리해주는 일일까요. 이 논문은 후자에 손을 들어줍니다. 모델은 그대로 두되, 실행 직전에 보여주는 메뉴를 경로의 관점에서 다시 짜면 온라인 성공률이 크게 뛴다는 것이죠. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 그런 눈으로 보면 이 연구의 변화는 분명합니다. 도구를 고르는 기준이 닮음에서 이어짐으로 바뀌었고, 그 바뀐 기준이 메뉴의 순서까지 바꿨습니다.

그렇다면 이 흐름은 어디에서 끊을 수 있을까요. 그 이야기는 마지막에 다시 다루겠습니다. 메뉴가 만능은 아니기 때문입니다. 상태 경로라는 발상은 출발 상태가 비교적 또렷할 때 힘을 발휘합니다. 요청이 모호해서 출발지 자체가 안갯속일 때는 경로를 그리기 어렵습니다. 또한 도구의 출력이 다음 입력으로 깔끔하게 이어지지 않는 작업, 예를 들어 사람의 확인이나 오프라인 결재처럼 시스템 바깥에서 끊기는 작업에서는 경로의 예측력이 떨어질 수 있습니다. 지도를 잘 그리는 일과 실제 도로를 닦는 일은 다른 일이기 때문입니다.

그럼에도 저는 이 논문이 에이전트 연구의 질문을 조금 옮겼다고 봅니다. 질문도 바뀌었습니다. 어떤 도구가 요청과 가장 닮았는가에서 어떤 순서가 실행을 끝까지 이어주는가로 말이죠. 이 질문이 좋은 이유는 답이 메뉴라는 작은 장치에 바로 떨어지기 때문입니다. 거대한 모델을 다시 학습시키지 않아도, 당장 내일 적용해볼 수 있는 손잡이가 생기는 것이죠. 앞으로 보고 싶은 것은 이 손잡이가 더 어려운 환경에서 어디까지 버티는지입니다. 도구가 실시간으로 바뀌고, 입력 형식이 자주 흔들리고, 여러 에이전트가 같은 도구를 놓고 다투는 환경에서도 경로 메뉴가 길을 잃지 않을까요. 그 답을 확인하는 날, 메뉴는 검색 결과가 아니라 에이전트의 실행 계획서로 불리게 될 것입니다. 그렇다면 사람의 역할은 무엇일까요. 저는 길을 걷는 일이 아니라 어떤 길을 미리 그려둘지를 정하는 일에 더 가까워질 것이라고 봅니다.