🎙️MCP가 여는 AI의 미래: 맥락(Context)과 능력(Capability)을 연결한다

튜링 포스트의 Ksenia가 흥미로운 AI 학계 연구자들 또는 업계의 사업가들을 만나 나눈 이야기들을 유튜브 영상과 함께 튜링 포스트 코리아의 ‘Interviews with Innovators’ 시리즈를 통해서 소개해 드립니다.

현재 시점, AI 영역의 의미있는, 큰 도약(Leap)은 ‘모델의 사이즈를 더 키우는’ 게 아니라 ‘모델과 에이전트가 실제로 액션을 할 수 있게끔 하는 방법을 제공’하는 영역에서 나오고 있다고 볼 수 있습니다.

튜링 포스트의 이번 ‘Interview with Innovators’ 에피소드에서는 Block(전 Square)의 시니어 소프트웨어 엔지니어, 오픈소스의 Multi-Purpose AI 에이전트 ‘Goose’의 핵심 컨트리뷰터이면서, MCP (Model Context Protocol) 운영위원회 위원인 Alex Hancock과 함께, 조용히 다음 세대의 AI를 움직이고 있는 인프라스트럭처에 대해 이야기를 나눠 보구요. Alex가 향후 1년 정도의 시간동안 프로토콜 개발이 어떤 방향으로 어떻게 이뤄질 건지에 대한 생각, 그리고 오랫동안 사랑받아야 할 도구를 만들 때 개인적인 취미라고 하는 ‘달리기’의 마음가짐이 어떤 영향을 주는지 이야기해 줍니다.

만약에 AI 에이전트를 만들고 있거나, 새롭게 떠오르는 AI의 ‘프로토콜 계층(Protocol Layer)’을 이해하고 싶다면, 이 인터뷰를 한 번 읽어보시고 이후에 곰곰히 생각해 보시면 좋을 것 같습니다.

인터뷰 전체 동영상은 아래를 참고하시구요:

그럼, 시작합니다!

Q. 안녕하세요, Alex. 이 무더운 한여름에 이렇게 인터뷰 시간을 내주셔서 감사합니다.

A. 네, 만나서 반갑습니다. 초대해 주셔서 감사합니다.

Q. Alex는 Block의 시니어 소프트웨어 엔지니어이자, 오픈소스의 다목적 AI 에이전트인 ‘Goose’에 깊이 관여하고 계시고, MCP(Model Context Protocol) 운영위원회에서도 활동하고 계시죠. 기본적인 질문부터 해 보자면, MCP가 뭐고, 왜 중요하다고 생각하시나요?

MCP는 모델에 ‘맥락(Context)에 대한 접근 권한’을 부여하는 프로토콜이라고 할 수 있습니다. 큰 틀에서 보면, MCP가 빠르게 성공하고 성장한 이유는, 우리가, 개발자 커뮤니티가 느끼는 핵심적인 문제와 필요를 해결했기 때문이라고 봐야겠죠. 데이비드 파라(David Parra)의 초기 발표 중에, 아주 똑똑한 모델을 ‘병 속의 뇌’라고 표현한 게 있습니다 - 놀라운 능력을 가졌지만 주변 세상과는 단절돼 있다는 뜻이죠. MCP는 그 ‘병’ - 단절된 경계 - 을 없애 줍니다. 모델이 주변의 데이터 소스에 연결되고, 다양한 시스템에서 액션을 할 수 있는 도구를 호출할 수 있게 해 줍니다. 즉, 모델에 ‘팔과 다리’를 달아주는 셈이라고나 할까요?

Q. 초기에는, 많은 개발자들이 그 중요한 장점을 바로 인식하지는 못했던 것 같은데요. 왜 그랬을까요?

좋은 질문이예요, 제가 경험한 걸 말씀드리면 도움이 될 것 같아요. 저희는 AI 에이전트를 만들고 있었는데, 그 기능을 확장할 수 있는 유연한 방법이 필요했습니다. 리소스를 읽고, 작업을 수행하고, 파일을 수정하고, 다른 애플리케이션의 설정을 변경하는 것 등등이요. MCP의 스펙을 읽어보니, 저희가 필요한 내용에 딱 맞을 것 같아서 검토해 보고 채택하게 됐습니다.

MCP를 도입한 이후로 AI 에이전트를 만드는 속도, 도구들을 통합하는 속도가 급격하게 빨라졌는데요. 전세계적으로 더 빠르게 도입이 이루어지고 있는 건 그 이유가 있는 것 같습니다.

Q. 요즘 컨퍼런스에서 MCP 이야기를 안 하는 경우를 거의 볼 수 없기는 하지만, MCP 운영위원회(Steering Committee)는 여전히 잘 모르는 사람이 많고 정보도 거의 없는 것 같아요. 어떤 조직인가요?

앞으로는 그런 상황을 조금 바꿔보기 위해서 노력할 것 같아요. 운영위원회는 MCP에 다양한 방식으로 관여해 온 사람들의 모임입니다. 오픈소스 저장소(Repo)와 스펙(Specification)에 기여를 했거나, MCP 클라이언트나 서버를 구축하거나, 프로토콜 개선에 시간과 노력을 들여 온 분들이죠. 비밀스러운 집단이 아닌데, 그런 인식이 있는 것 같아서 바꿔보려고 해요.

지난주 웹사이트에 거버넌스와 운영 체계 문서를 올렸는데, 관심있으신 분은 어떻게 참여할 수 있는지, 그리고 프로토콜에 대한 결정이 어떻게 내려지는지 등을 확인해 보실 수 있어요. 앞으로 더 많은 분들이 폭넓게 편하게 참여하실 수 있기를 바랍니다.

Q. 최근 MCP 운영위원회에서 많은 일이 벌어지고 있다고 들었는데, 어떤 일들이 있나요?

대부분의 작업은 스펙 저장소(Spec Repository)에서 직접 진행돼요. MCP GitHub 저장소, 이슈, 그리고 Discussion에서 말이죠. 제 관점에서 보면, 스펙 준수(Spec Compliance)와 관련해서 많은 논의와 노력이 진행되고 있어요. MCP는 빠르게 발전하잖아요? 3월에 새 스펙 버전이 나왔고, 6월에 또 나왔습니다. 지금은 여러 언어의 SDK가 이런 변화를 따라잡고 있는 중이고, 그 사이의 간극을 어떻게 줄일지 고민하고 있습니다. 우리의 목표는, 모든 언어에서 서버와 클라이언트를 잘 지원하면서 최신 스펙과 항상 동기화된 SDK를 유지하는 거예요.

그 외에, 에이전트 워킹 그룹(Agents Working Group)도 시작되고 있고, 에이전트와 에이전트 기반 프로젝트를 만드는 사람들한테 중요한 주제에 초점을 맞추는 그룹입니다. 제가 Goose에서 하는 작업과도 관련이 깊어서, 프로토콜 구현의 일관성을 유지하면서 동시에 프로토콜 자체를 발전시키는 노력이 진행되는 것을 보면서 앞으로 기대가 커지고 있어요.

Q. 에이전트와의 연결성에 대해 좀 더 들었으면 좋겠어요. MCP가 그 부분에서 겪고 있는 병목이나 문제는 뭐고, 다음 목표는 뭔가요?

병목, 문제들 중에 일부는 어찌보면 기본적인 문제로 돌아오는 것 같아요. 예를 들어서, 맥(Mac)에서 스위프트(Swift)로 에이전트를 만든다면, 해당 언어로 된, 제대로 된 SDK가 필요하겠죠. 이런 기초 작업이 에이전트 기반 프로젝트 뿐만 아니라 다른 프로젝트에도 도움이 됩니다.

인증(Authentication)도 큰 부분이예요. 최근 MCP의 인증 표준으로 OAuth 2.1을 채택하면서, 슬랙(Slack), 스트라이프(Stripe), 스퀘어(Square) 같은 플랫폼에서 작업을 자동화하는 에이전트를 훨씬 쉽게 만들 수 있게 됐습니다. 또 장기 실행 프로세스(long-running processes)를 지원하는 초기 논의도 있구요. 예를 들어서, 도구 호출이 몇 분이 아니라 몇 시간이 걸릴 수 있고, 그런 경우는 에이전트가 도구 호출 결과에 비동기적으로(Asynchronous) 접근해야 하겠죠. 이런 것들이 모두 에이전트 개발과 아주 밀접하게 관련되어 있습니다.

Q. MCP에서 프라이버시와 보안은 어떤가요?

조금 전에 말씀드린 ‘OAuth 2.1의 채택’이 큰 진전이었습니다. 6개월 전만 해도 MCP에는 ‘인증’ 내용이 전혀 없었죠. 단순히 클라이언트와 서버 간의 전송 프로토콜과 메시지 형식만 있었구요. 이제는 수년간 실전에서 검증된 안전한 업계 표준 연결 모델을 채택한 셈이예요.

더 넓게 봤을 때, 프라이버시와 보안 관점에서는, MCP 서버를 사용한다는 건 일반적인 다른 서버나 라이브러리를 사용한다는 것과 비슷하다고 보면 됩니다. 즉, 소스를 신뢰해야 하죠. 프로토콜은 아직 서버의 진위 여부를 검증하는 방법에 대해서는 크게 다루지 않지만, 이 문제를 해결하려는 프로젝트가 나올 거라고 예상합니다. 시작할 때는 이 부분이 없었지만, 서두르기보다는 천천히, 올바른 선택을 하기 위해서 시간을 들이고 있어요. 현대적인 OAuth 2.1를 채택한 것도 그 결과의 하나라고 보고, 이전의 인증이 전혀 없던 상태와 비교하면 확실하게 개선된 상태입니다. 앞으로는 더 나아질 거예요.

Q. 운영위원회에 대해서 좀 더 명확하게 듣고 싶은게 있는데요 – 운영위원회의 목표는 뭐고, 얼마나 자주 만나는지, 그리고 어떻게 구성원들이 참여를 하게 되나요? 마이크로소프트와 오픈AI 사람들이 꽤 있는 걸로 알고 있고, 앤트로픽 사람들도 있지 않나 싶은데요. 운영 방식이 궁금합니다.

지금까지는 커뮤니케이션이 꽤 비공식적인 형태였습니다. 대부분 깃허브(GitHub)에서의 논의가 전부였죠. 지난 3월, 샌프란시스코에서 열린 MCP 개발자 서밋에서 처음으로 대면 모임을 가졌구요. 이름만 알던 사람들과 얼굴을 맞대고 같은 공간에서 MCP를 모두에게 유용하게 만드는 방법을 논의할 수 있어서 기분이 좋았습니다. 참여자들의 헌신적인 모습을 보면서 깊은 인상도 받았구요. 이 기술이 앞으로 발전해 나가는데 있어서 아주 특별한 시기라는 느낌이 들었고, 그 일원이 된 것이 감사했습니다.

Q. 앞으로 이 기술을 더욱 키워나가기 위해서 지금 운영위원회에서 논의 중인 주요 주제는 뭔가요?

참여자가 늘어나면서 워킹 그룹이나 프로젝트도 많아지고 있습니다. 제가 관여하는 가장 큰 주제 중 하나는 MCP 서버의 글로벌 레지스트리(Global Registry)입니다. 제가 처음 제안했고, 이후 다른 분들이 주도해서 발전시킨 아이디어예요. 이 개념을 통해서 클라이언트가 자기들이 필요한 내용에 맞는 서버를 쉽게 찾을 수 있고, 서버 개발자는 중앙 디렉토리에 서버를 등록할 수 있게 됩니다.

또 하나 중요한 흐름은 SDK 지원이예요. 사람들이 원하는 모든 언어에서 MCP 기능이 구현되고, 언어별로 일관적으로 스펙이 준수(Compliance)될 수 있게끔 하는 거죠.

앞서 말씀드린 에이전트 워킹 그룹은 이제 막 시작 단계구요. 에이전트 기반의 프로젝트가 MCP를 어떻게 활용하는지, 그리고 에이전트가 의존하는 접근의 패턴을 지원하기 위해서 프로토콜에 어떤 변화가 필요한지 등에 대해서 집중적으로 다룰 예정입니다. 물론 스펙 자체의 진화는 항상 계속되고 있습니다.

Q. A2A 같은 다른 프로토콜에 대해서는 어떻게 보시나요? 협력의 여지가 있을까요? 예를 들어서 마이크로소프트의 A2A 레지스트리는 MCP에도 도움이 될 수 있지 않을까요?

당연히 있습니다. 지금은 사실상 모든 게 초기 단계입니다. 우리 모두가, 모델이 사용자에게 유용한 작업을 수행할 수 있도록 필요한 정보와 도구를 제공하는 최선의 방법을 찾고 있는 거예요. A2A 발표를 봤을 때, 그 방향성이 타당하다고 느꼈고 MCP와 상호 보완적이라고 생각했습니다.

MCP는 슬랙(Slack), 스퀘어(Square), 캐시 앱(Cash App) 등 개별 시스템 내에서 모델이나 AI 기반의 앱을 적절한 맥락과 도구에 연결하는 데 강점이 있습니다. A2A는 더 높은 수준에서, 에이전트들이 서로 비교적 구조화되지 않은 방식(거의 영어처럼)으로 대화하는 구조를 지향해요. 여러 가지의 다양한 접근 방식이 공존할 가능성이 높습니다. 어떤 경우에는 A2A가, 또 다른 경우에는 MCP가 더 잘 맞을 수 있죠. 건강한 경쟁과 중복은 문제가 없습니다.

Goose는 모델 중립적이고 프로토콜 중립적입니다. 현재는 MCP를 지원하지만, 우리가 하는 일에 도움이 된다면 A2A나 다른 프로토콜도 고려할 겁니다.

Q. 아직은 시작 단계라고 하셨는데요. ‘뇌’를 실제의 ‘행동’으로 연결해서 실행자(Doer)로 만드는 과정이죠. 향후 1년 동안 이 분야가 어떻게 발전할 것으로 보시나요?

1년도 이미 엄청나게 긴 시간으로 느껴질 정도네요. 제가 이 일을 시작한 지 6개월인데, 변화의 속도는 어마어마합니다 - 모델의 능력이든, 그걸 둘러싼 도구든간에 말이죠. 구체적으로 예측하기는 힘들지만, 지금 가장 큰 도전과제는 ‘맥락(Context)’의 문제인 것 같아요.

모델이 똑똑하더라도, 모델에게 주어진 작업이 성공할 것이냐 여부는 올바른 맥락(Context)을 얼마나 잘 제공하느냐에 달려 있다고 봐요. 적절한 맥락을 주면 훌륭한 결과를 내지만, 틀린 맥락을 주면 실패합니다. 그래서 맥락을 발견하고 관리할 수 있는 확장 가능한(Scalable) 방법 – 맥락의 발견 알고리즘, 맥락의 관리 시스템 – 개발에 집중하고 있습니다.

Q. ‘사람’으로서의 제 입장에서 본다면, 모델과 협업할 때는 ‘계속해서 조정’하는 과정과 작업이 필요해요. 예를 들어서, 새 모델이 나오면, 그 새 모델과 대화하는 방식도 조금씩 달라지니까요. Goose는 모델에 상관없이(Model-Agnostic) 작동한다고 하는데, 서로 다른 모델에서도 비슷하게 작업이 잘 되게끔 어떤 조정을 하는 건가요?

Goose에는 최상위의 시스템 프롬프트가 있어요. 모델의 종류와 관계없이 적용되고, 사용자를 돕는 ‘AI 에이전트’로서 Goose를 정의합니다. 이론적으로는 자주 변경할 필요가 없고, 실제로도 보통 그렇습니다.

물론 새 모델이 나오면 성능 향상을 하기 위해서 프롬프트를 테스트하고 가끔 조정도 합니다. 새 모델이나오면 가끔 놀라운 변화도 있죠 - 어떤 행동은 더 잘 하고, 예상치 못하는 방식으로 변하는 경우도 있구요. 예를 들어서, 최근에 제가 코딩 작업을 하는데 사용한 모델들을 작성한 코드를 마크다운 형식으로 정리해서 문서화까지 해 주더라구요. 엔지니어 입장에서는 꽤나 큰 생산성의 향상이예요.

Goose의 목표는, 모델이 어떻게 바뀌든간에 대규모로 재작업을 하지 않으면서도 모델의 변화에 쉽게 적응하는 도구를 만드는 겁니다. 아직까지는 큰 변경이 없이 개별적인 모델이 개선되는 흐름의 장점을 살릴 수 있었구요.

Q. ‘연결’, ‘프로토콜’ 이야기로 돌아가 보죠. 아직도 많이 부족하다고 생각하는 점은 어떤 것들일까요?

‘레지스트리’가 큰 과제입니다. 제대로 된, 쓸만한 ‘레지스트리’를 배포하고 세상에 내놓는 것 말이예요. 설계는 대부분 완료됐고, API도 구성되고 있구요, 구현 작업이 진행 중입니다. 깃허브에 릴리스 체크리스트를 추적하는 이슈가 있습니다. 레지스트리가 라이브가 되면, 클라이언트가 검색이나 API를 통해 서버를 발견할 수 있게 될 텐데, 이건 그 자체로 큰 의미가 있는 변화가 될 겁니다.

‘스펙 준수’ 문제도 아직 빈틈이라고 봐요. 많은 SDK들이 아직 6월 릴리즈된 스펙을 따라잡지 못하고 있어요. 예를 들어서, 6월 릴리즈에서 추가된, 아주 훌륭한 기능인, ‘Elicitation’은 대부분의 SDK에서 아직 지원이 안 돼요. 모든 언어에서의 SDK를 최신 스펙과 호환되도록 하는게 중요해요.

Q. 6개월 뒤를 생각해 본다면, 이상적으로는 에이전트들이 서로 일관적으로 협력하고, 모든 프로토콜을 찾아서 연결할 수 있어야겠네요.

맞습니다. 약간 이상적인 청사진이지만요. 모든 상황이 잘 풀린다면, ‘맥락’의 발견, 그리고 관리가 가장 중요하고 큰 요소가 될 거예요. 모델에 ‘적절한’ 맥락을 주면 훌륭한 결과를 내고, ‘틀린’ 맥락을 주면 실패하니까요.

현재는 주어진 작업에 대해서 모델이 필요한 ‘맥락’이 어떤 건지 정말 제대로 이해하는 사람은 거의 없다고 봐요. 그래서 우리 목표가 이런 개념과 기법을 대중화하는 거예요. 궁극적으로는, 에이전트 시스템이 스스로 올바른 맥락을 능동적으로 찾아낼 수 있는 알고리즘을 만드는 것이구요. 아직 그 단계에는 이르지 못했지만, 앞으로의 과제라는 것만은 명확합니다. 누구나 에이전트에게 목표를 주고, 현재 최고 수준의 AI 사용자가 내는 결과와 맞먹거나 더 나은 성과를 얻을 수 있는 시스템을 만드는 겁니다.

Q. 여전히, 에이전트 뿐 아니라 심지어는 AI 시스템이라는 것에 깊이 발을 들여놓거나 고민하지 않는 개발자들도 많은데요. Alex는 어떻게 이 분야에 들어오게 됐나요?

저는 작년 11월 Block에서 Goose 작업을 시작했습니다. 특정한 작업의 스트림을 도우려고 합류했는데, 프로젝트의 의미가 너무 커서, 풀타임으로 이 일을 하고 싶다는 생각이 들었습니다. 그래서 조인했어요.

Q. 많은 개발자들이 뉴스를 팔로우하면서 각종 새로 생기는 용어의 뜻, 그리고 어떻게 그걸 이해하고 사용하는지 등에 대해서 공부도 하고 이해하려고 하는 것 같아요. 정말, AI 시대로의 흐름이 너무나 강력한 것 같습니다.

맞아요. AI 기술이 소프트웨어를 만드는 방식을 근본적으로 변화시키고 있어요. 이건 그냥 단순히 점진적으로 개선되는 기법이나, 새로운 개발자 도구가 아니예요. 전혀 새로운 작업 방식이고, 앞으로 소프트웨어 개발 뿐만 아니라 컴퓨터로 하는 모든 종류의 일을 바꿔놓을 거예요. 저도, 이 흐름에 올라타서 함께 하게 된 것 자체가 감사해요.

Q. 소프트웨어 개발 하시면서 생산성이 얼마나 높아졌다고 느끼세요?

정확히 측정하기는 어렵지만, 제 15년 소프트웨어 엔지니어 경력으로 볼 때, 단일한 요소로서는 가장 큰 생산성의 증가를 가져오는 기술이라고 봐요. 아주 극적인 차이를 만들어 냅니다.

Q. 제 남편이 개발자인데, 이제 네 개의 전혀 다른 프로젝트를 동시에 진행할 수 있다고 하더군요. 하나의 모델이나 에이전트를 돌려놓고 다른 작업으로 전환을 해 가면서요. 속도가 최소 네 배는 빨라졌다고 합니다.

맞습니다. 예전에는 몇 시간을 꼬박 집중해서 해야 했던 코드 작업을 이제는 몇 분만에 할 수 있어요. 그 다음의 과제는, 그 결과물을 어떻게 처리하고 다루느냐죠. 여러 에이전트를 실행하는 도중에 하나가 긴급하게 내 입력이나 피드백을 필요로 한다면, 그 사실을 명확하게 표시하고 알려주면서 나머지는 백그라운드에서 계속 실행되도록 해야 돼요. 물론, 고전적인 인터페이스 설계 원칙은 여전히 적용이 되고, 이 새로운 기술과 능력에 맞게끔 조금씩 바꿔가면 됩니다.

Q. 올바른, 적절한 ‘맥락’을 주면 작업에 성공하고, 그렇지 않으면 ‘실패’한다고 하셨는데요. 더 큰 그림에서 본다면, AGI에 대해서는 어떤 생각을 갖고 계신가요?

제 역할과 범위를 넘어서는 주제이긴 하지만, 이런 AI 시스템이 매주 더 강력해지고 있다는 것만은 크게 느낍니다. 더 많은 데이터, 더 다양한 상호작용 모드, 더 관련성 높은 맥락이 모두 결합해서 Goose 같은 에이전트가 할 수 있는 일을 빠르게 향상시켜주고 있어요.

AGI 자체에 대해서는, ‘전후(Before and After)의 순간이 아니다’라는 관점을 좋아해요. AGI는 역량이 점진적으로 성장하는 과정인 것 같아요. 어느 시점이 되면 – 어쩌면 이미 – 이런 시스템이 엄청나게 강력하고 지능적이라는 사실을 순간 깨닫게 되는 거죠.

Q. 얀 르쿤(Yann LeCun) 박사의 주장과도 비슷하네요. AGI가 어느 날 갑자기 ‘도착’하는 게 아니고, 점진적이라는 것이죠. 하지만 맥락 이야기를 들으니, 그 시나리오에는 항상 사람이 개입하게 되는 것 같습니다.

맞습니다. 여전히 엄청난 양과 질의, 사람의 전문성이 필요해요. 같은 작업을 하라는 지시를 받고 에이전트 시스템을 두고 두 사람이 앉아 있다고 해 보죠. 그 프로젝트에 대해서 이미 잘 이해하는 사람은 곧바로 훌륭한 결과를 낼 수 있을 거예요. 반면에, 그 프로젝트를 한 번도 해본 적 없는 사람은 모델에 어떤 파일을 지정해야 하는지, 뭐가 중요한지 알지 못할 가능성이 높죠. 그래서 여전히, 좋은 결과를 얻으려면 사람의 전문성이 필요합니다.

Q. 앞으로도 그럴 거라고 생각해요. 제가 인터뷰를 마무리하면서 늘 드리는 질문이 있거든요? 당신의 인생에 큰 영향을 준 책 한 권을 꼽아주세요. 직업과 관련이 있어도 좋고, 전혀 상관없는 책이어도 됩니다.

저 개인을 형성한 책이라고 한다면, 기술과는 상관없는 제 인생의 또 다른 중요한 부분인데요, ‘장거리 달리기’와 관련이 있습니다. 저는 육상 트랙, 크로스컨트리, 로드 레이스를 뛰는데요, 그중에서도 『Once a Runner』를 꼽겠습니다. 육상 선수라면 누구나 아는 책일 거예요. 달리기에 관한 고전이기도 하고, 큰 경기를 준비할 때 늘 다시 읽는 제 영감의 원천입니다.

Q. 흥미로운데요? 조금만 더 이야기해 주세요. 그 책에서 주는 중요한 교훈은 뭔가요?

‘무언가에 전념한다’는 것에 관한 책입니다. 작가 존 파커(John Parker)가 실제 4분 이내 마일 기록을 가진 스스로의 경험을 바탕으로 쓴 주인공이, 4분 이내 마일 달리기를 목표로 도전을 해요. 이 책이 좋은 이유는, 단순히 잘하는 수준이 아니라 ‘탁월함’에 도달하려면 뭐가 필요한지를 정확히 보여주기 때문입니다. 자신에게 중요한 목표를 선택하고, 그 목표를 이루기 위해 삶을 그에 맞게 설계하는 내용입니다.

Q. 멋지네요! 책에 대한 질문이 좋은 이유가, 전혀 다른 관점에서 그 사람을 이해할 수 있게끔 해 주기 때문인가봐요. 오늘 시간 내 주셔서 감사합니다.

그럴 수도 있겠네요. 오늘 인터뷰 즐거웠습니다.

읽어주셔서 감사합니다. 재미있게 보셨다면 친구와 동료 분들에게도 뉴스레터를 추천해 주세요.