완료된 과제는 반복 훈련이 아니다 - 에이전트가 학습 여정을 단축할 때 잃는 것

완료된 과제는 반복 훈련이 아니다

TL;DR

• 글의 부제가 논지를 요약하는데 에이전트는 아무것도 가르치지 않고 과제를 끝낼 수 있으므로 전문성 축적은 이제 의도적이어야 한다는 것이다. 저자의 과거 경로가 근거다. 에이전트 이전에는 코드를 쓰는 과정의 일부로 반복 훈련을 얻었는데 여러 접근을 시도하고 무엇이 잘못됐는지 디버깅하고 남의 코드를 검토하고 많이 읽는 일이었다.
• 가장 중요한 구분이 제목에 있는데 과제가 끝났다는 것은 무언가를 배웠다는 뜻이 아니고 그냥 과제가 끝났다는 뜻이라는 것이다. 그리고 배움이 어디서 오는지 지목된다. 실수가 있을 때는 왜 잘못됐고 무엇이 더 나을 수 있었는지 생각하게 되는데, 일이 잘 되면 가르침의 순간이 없고 그냥 다음 과제로 넘어간다.
• 실증도 붙는데 2026년 앤스로픽 연구에서 파이썬 라이브러리 Trio를 배우는 주니어 엔지니어를 봤더니 AI 조수를 쓴 쪽이 후속 퀴즈에서 50퍼센트, 손으로 작업한 쪽이 67퍼센트였다. 그리고 AI 집단 내부의 차이가 더 중요하다. 좋은 결과는 모델을 코드 자판기로 취급하지 않고 개념적 질문을 하고 설명을 요구한 사람들에게서 나왔다.
• 전문성의 값이 오히려 오른다고 보는데 바닥이 올라갔으므로 AI가 사람이 가진 기술과 전문성의 수익률을 높이고 있다는 것이고 역할 분담은 검증이 바닥이고 상상이 천장이라는 한 문장으로 정리된다. 다만 한계도 지목한다. 스킬과 MCP는 유용한 워크플로를 부호화할 수 있지만, 그 가정이 더 이상 당신 시스템에 맞지 않을 때를 알려 주지는 못한다.
• 처방은 이중 루프인데 좋은 반복 훈련은 당신을 날카롭게 해야 하고 당신의 에이전트도 날카롭게 해야 한다는 것이다. 이유가 구체적이다. 그렇지 않으면 새 세션을 시작할 때마다 기억상실증이 있는 신입을 온보딩하는 것처럼 느껴지므로, 교훈을 린트 규칙이나 타입 제약, 문서 관례, 테스트로 부호화해 미래 에이전트가 찾을 수 있는 곳에 둔다.

Source

Agentic Skill Decay — Addy Osmani, 2026년 8월 31일

[addyo.substack.com/p/agentic-skill-decay](https://addyo.substack.com/p/agentic-skill-decay)

Knowledge

반복 훈련이 어디서 왔는가

글은 한 문장으로 전제를 세운다. 숙달은 여전히 반복 훈련을 하는 데서 온다는 것이다. 그리고 과거와 현재를 대비한다. 에이전트 이전에는 코드를 쓰는 과정의 일부로 반복 훈련을 얻었다는 것이다. 여러 접근을 시도해 보고 무엇이 잘못됐는지 디버깅하고 남의 코드를 검토하고 많이 읽는 일이다. 그런데 에이전트가 그 작업의 상당 부분을 건너뛸 수 있으므로 반복 훈련을 쌓는 일이 의도적이어야 한다는 결론이 나온다.

업계에 새로 들어온 사람이라면 무엇을 할지도 구체적이다. 프롬프트를 넣기 전에 가설을 세우려 하고 왜냐고 많이 묻고 디프를 읽고 무엇이 실패할지 예측하려 하고 때때로 문제를 직접 손으로 풀어 보겠다는 것이다.

좋은 에이전트 작업이 무엇에 달려 있는지도 두 능력으로 정리된다. 하나는 깊은 전문성이다. 좋은 결과를 정의할 수 있을 만큼 문제 영역을 잘 이해하는 것이고 사용자와 제품, 사업을 이해하는 것이 그 일부다. 다른 하나는 적용된 판단이다. 취향을 써서 그것을 명확하고 검증 가능한 계획으로 바꾸는 것이며 올바른 맥락과 제약, 테스트, 검증을 고르는 일이다. 그래서 연습할 기술이 넷으로 지목된다. 의사결정과 명세, 조종, 그리고 검증이다.

자기 경험이 이어진다. 소프트웨어 엔지니어링을 시작했을 때 자기가 무엇을 하는지 전혀 모른다고 느꼈다는 것이다. 만드는 것이 재미있었고 시도하고 실패하고 실수에서 배우는 것이 재미있었으며 매번 조금씩 더 나아갔다. 실패할 때마다 그것을 더 나은 엔지니어가 되는 또 하나의 건축 블록으로 삼으려 했다. 자바스크립트를 배운 방식이고 C++로 프로그래밍하고 데스크톱 애플리케이션을 만드는 법을 배운 방식이며 그래픽 집약적 애플리케이션의 성능을 튜닝하는 법을 배운 방식이라고 말한다.

방법도 구체적이다. 과제에 들어갈 때 어떤 가설이나 아이디어를 가지고 갔는데 그것이 완전히 틀렸을 때도 있었다는 것이다. 통할 것 같은 것을 시도해 보고 안 되면 스택 오버플로에 가거나 문서를 검색해 지식을 흡수했고 아주 난해한 주제면 책을 읽기도 했다. 그것을 충분히 여러 번 하면 전문성이 쌓이기 시작하는데, 특히 주말에 하는 취미 수준을 넘어 실제 프로젝트에서 시도할 때 그렇다고 한다.

그래서 판정이 나온다. 오늘 쓰는 판단 대부분이 이런 수천 번의 작은 반복 훈련에서 왔다는 것이다. 실패를 디버깅하고 남의 코드를 검토하고 실제 시스템이 되밀어낼 때까지 괜찮아 보였던 추상과 함께 살았던 일들이다. 그런데 에이전트가 이제 그 작업의 상당 부분을 건너뛸 수 있다. 그리고 구체적 상황이 지목된다. 경력 3년째라면 그럴듯한 코드가 그것을 판정할 능력보다 빠르게 도착할 수 있다는 것이다.

학습 여정을 단축하는 지름길

AI로 시작하는 많은 사람이 학습 여정의 상당 부분을 단축할 수 있다는 진단이 이어진다. 문제가 있고 여기 해법이 있다거나 여기 과제의 결과가 있다로 아주 빠르게 갈 수 있는데, 지식 기반을 쌓거나 그것을 하지 말아야 하는 이유를 알려 주거나 거래 관계를 추론하게 도와주었을 모든 것을 건너뛴다는 것이다. 그래서 요구가 나온다. 특히 주니어 엔지니어가 자기 교육 여정에 적극적이어야 하는 영역이라는 것이다.

AI 연구소들과 이야기한 관찰도 붙는다. 지금 주요 참가자 대부분이 결과를 이루거나 답을 가능한 한 빠르게 얻도록 돕는 데 아주 집중하고 있고 교육이 목표 중 하나라고 명시하지 않으면 교육 여정을 반드시 도와주지는 않는다는 것이다. 대비가 명확하다. 일정 관리 앱을 만들어 달라고 말하는 것과, 일정 관리 앱을 만들면서 한 단계씩 어떻게 하는지 가르쳐 달라고 말하는 것에 차이가 있다는 것이다. 그런데 대부분은 두 번째를 하지 않는다. 이유가 둘로 추정된다. 그것이 선택지임을 모르는 것과, 요즘 속도 기대치가 있어 빨리 출하하고 다음으로 넘어가라는 압력이 있다고 생각하는 것이다.

완료가 배움이 아닌 이유

이 글의 제목이 된 부분이 여기다. 과제가 끝났을 때 그것이 반드시 무언가를 배웠다는 뜻이 아니고 그냥 과제가 끝났다는 뜻이라는 것이다. 그래서 학습 기회를 거의 찾아 나서야 한다고 말한다.

실천 방법도 제시된다. 에이전트에게 만드는 중이나 맨 마지막에 요약을 요청할 수 있다는 것이다. 중급 개발자나 주니어 개발자로서 지식 기반을 늘리거나 문제를 생각하는 방식을 개선하는 데 도움이 될 핵심 배움이 무엇인지 묻는 것이고 그것을 계속 반복할 수 있다.

저자 자신의 사례가 붙는다. 더 복잡한 3D 그래픽 프로그래밍에 AI를 쓰고 있는데 자기가 전문가가 아니라는 것이다. 그래서 이것이 어떻게 작동하는지 설명해 줄 수 있느냐, 방금 구현한 이 개념을 가르쳐 줄 수 있느냐, 이 요소들이 어떻게 연결되는지 추론하도록 도와줄 수 있느냐고 묻는다고 한다. 배우고 싶기 때문에, 배우려는 욕구가 있기 때문에 에이전트와 짝을 이룬다는 것이다. 그리고 반대 경우가 지목된다. 배우려 하지 않으면 거기서 기회를 잃는다.

배움의 원천에 대한 관찰이 특히 날카롭다. 완료된 과제가 반복 훈련이 아닌 것은 과정에 실수가 없을 때도 일어난다는 것이다. 실수가 있을 때는 왜 잘못됐는지, 무엇이 더 나을 수 있었는지, 무엇을 생각하지 않고 있는지 생각하기 시작하고 성찰을 강제받는다. 그런데 일이 잘 되면 거기에 가르침의 순간이 정말 없고 그냥 일이 끝났으니 다음 과제로 넘어가겠다고 생각하게 된다.

50퍼센트와 67퍼센트

실증이 두 연구로 제시된다. 첫째는 2026년 앤스로픽 연구로, 파이썬 라이브러리 Trio를 배우는 주니어 엔지니어를 봤다. 결과가 명확하다. AI 조수를 쓴 사람들이 후속 퀴즈에서 50퍼센트를 받았고 손으로 작업한 집단은 67퍼센트를 받았다.

그런데 더 중요한 발견은 AI 집단 내부에 있다. 강한 결과가 모델을 코드 자판기로 취급하지 않고 개념적 질문을 하고 설명을 요구한 사람들에게서 나왔다는 것이다.

이것이 앞선 논지와 연결된다. AI를 산출물과 결과를 생성하는 데만 쓰고 짝으로 쓰지 않는다면, 비판적 사고 기술과 지식, 작동 방식에 대한 이해를 개선하는 데 쓰지 않는다면, 어떻게 작동하는지 대체로 이해하지 못하면서 프롬프트만 잘하는 상황에 이를 수 있다는 것이다. 그러면 검증 쪽에는 아마 그다지 능하지 않게 된다.

17퍼센트포인트 차이에 대한 해석도 붙는다. 질문하고 설명을 요구한 사람들이 더 잘한 것이 놀랍지 않다는 것이다. 그 사람들은 어떻게 작동하는지와 그것이 아는 다른 것들과 어떻게 연결되는지에 대해 훨씬 많이 성찰했을 것이고 패턴을 맞추며 이것이 어떻게 작동하고 어떻게 추론하며 지식의 공백이 어디인지에 대한 잔여물을 쌓기 시작한다. 다만 한계도 인정한다. 파이썬 라이브러리 하나에 대한 단기 연구였으므로 결정적이라고 말하지는 않겠지만 여전히 아주 흥미로웠다는 것이다.

두 번째 연구는 클로드 코드 세션 약 40만 건을 분석한 앤스로픽 연구다. 전문성을 과제 특수적인 것으로 봤다는 점이 지목되고 완료하려는 과제에 대해 중급 수준의 전문성만 있어도 검증된 성공에 도달할 확률이 초보자보다 높아졌다는 것을 발견했다. 그리고 해석이 붙는다. 스택 전반에 10년 경험이 있어야 한다는 뜻이 아니고 무엇이 좋은지 인식할 만큼 문제 영역을 이해해야 한다는 뜻이라는 것이다. 요즘 그것을 취향이라는 말로 이야기한다고 덧붙인다.

클로드 코드 모범 사례 안내서에 대한 평가도 나온다. 검증에 대해 이야기하며 시작하는 것을 보고 아주 기뻤다는 것이다. 테스트와 스크린샷 사용, 에이전트가 계속 반복 대조할 수 있는 다른 신호를 주고 과제가 완료됐다는 단순한 요약이 아니라 검토할 증거를 준다는 점이다.

천 시간의 성능 패널

자기가 옳게 하기까지 수천 시간을 써야 했던 것으로 성능 최적화를 든다. 예전에는 참고할 훌륭한 블로그 글이나 책이 늘 많지 않았던 영역이라는 것이다. 메모리나 하드웨어와 제약을 생각하는 방식을 다루는 괜찮은 고전 문헌이 좀 있었지만 웹 성능 최적화나 자바스크립트 최적화, 힙 최적화 같은 것에 대해서는 늘 좋은 글이 있지는 않았다.

그래서 반복 훈련을 쌓는 방식이 구체적이다. 크롬 개발자 도구에 들어가 성능 패널로 페이지나 애플리케이션의 트레이스를 돌리고 상호작용하면서 어디가 느린지 찾으려 했다는 것이다. 그리고 파고들어 가설을 세웠다. 플레임 그래프의 이 영역에 문제 대부분이 있는 것 같다거나 메모리 패널에서 쓰레기가 수집되도록 허용하지 않고 있다는 식이다. 그래서 판정이 나온다. 충분히 많은 실수를 하고 근본 원인을 찾으려 시도하는 시련을 통과해야 무엇이 통하고 무엇이 안 통하는지에 대한 이 지식, 때로는 난해한 지식이 쌓였다는 것이다.

요즘의 흐름과 대비된다. 개발자 도구 MCP가 에이전트와 함께 성능 프로파일링을 하고 알아내서 수정까지 스스로 내놓는다는 것이다. 그래서 성능에 대한 전문성을 그만큼 쌓지는 않게 된다.

검증이 바닥이고 상상이 천장이다

트위터를 스크롤할 때 피드에 상상력과 창의성이 얼마나 많은지에 늘 감탄한다는 관찰이 나온다. 놀라운 셰이더와 게임, UI, 몰입 경험을 만드는 디자이너와 창작자가 많다는 것이다. 그리고 진단이 붙는다. 기술은 이미 있었고 이제 상상이 천장이라는 것이다. 이런 것들을 훨씬 빠르게 만드는 것이 훨씬 접근 가능해졌다. 다만 조건이 있다. 애초에 아이디어를 갖고 에이전트에게 만들라고 말하려면 그 상상이 있어야 하고 그다음 그것을 검증할 전문성이 있어야 한다.

그래서 한 문장으로 정리된다. 검증이 바닥이고 상상이 천장이라는 것이다.

자기 사례가 붙는다. 음악을 하는데 다가오는 앨범 사이트를 위해 홈페이지 일부를 상호작용하는 3D 객체로 만들고 싶었다는 것이다. 3D CD 플레이어와 바이닐 레코드 플레이어, 아마 테이프 플레이어 같은 90년대 향수의 것들이다. 그런데 초기 버전은 멋져 보이지 않았을 뿐 아니라 올바른 상호작용 패턴을 따르지 않았고 모바일에서 성능이 좋지 않았다.

여기서 전문성의 역할이 단계적으로 드러난다. 우선 그것이 어떤 식으로 버그가 있다는 것을 알아차릴 전문성이 있어야 했다는 것이다. 어쩌면 어떤 사용자든 알아차릴 수 있는 것일 수도 있다. 그런데 그다음 왜 그럴지에 대한 가설이 있었고 직접 프로파일링하거나 에이전트에게 프로파일링을 요청해 무슨 일이 일어났는지 알아낼 수 있었다. 그래서 결론이 정리된다. 상상이 정말 중요하지만 전문성도 그렇다는 것이고 생각할 수 있으면 만들 수 있다는 것이다.

다음 세대가 전문성을 쌓아야 하느냐는 질문도 정면으로 다룬다. 적어도 오늘은 에이전트가 완벽하게 하지 않는 곳, 작업을 확인해야 하는 곳에서 유용하다는 것이다. 특정 루프나 애니메이션, 스케줄링 루틴을 최적화하라고 했을 때 다른 무언가를 대가로 그렇게 할 수도 있다. 그래서 무엇을 짚어야 할지 모르거나 구현을 읽고 무엇이 됐는지 이해하지 못하면, 실제로 원하는 것을 하지 않는 것을 출하하게 될 수 있다.

그리고 도구의 한계가 한 문장으로 규정된다. 스킬과 MCP는 유용한 워크플로를 부호화할 수 있지만 그 가정이 더 이상 당신의 시스템에 맞지 않을 때를 알려 주지는 못한다는 것이다.

전문성의 수익률이 오른다

소프트웨어 엔지니어링 기초가 계속 중요할 것이라고 본다. 그리고 반전이 제시된다. 바닥이 올라갔으므로 AI가 사람이 가진 기술과 전문성의 수익률을 높이고 있다는 것이다.

주니어가 주니어를 벗어나는 방식도 명확하다. 실제 것을 출하하고 실수하고 배우고 반복 훈련을 쌓는 것이다. 전문가는 무엇을 만들지, 어떻게 검증할지, 좋고 망가지지 않았고 유지 가능하고 확장되고 다른 맥락이나 플랫폼에서 작동할 것임을 어떻게 확인할지에 대한 직관을 가진다. 그리고 지금 상황이 지목된다. 아주 많은 사람이 프롬프트만으로 아이디어를 존재하게 할 수 있게 됐으므로, 그것을 고품질로 만들고 출하할 만큼 좋게 만들고 즐겁게 만들고 유지 가능하며 프로덕션에서 깨지지 않게 만드는 기술이 계속 중요할 것이라는 것이다.

주에 몇 번씩 마주친다는 실례가 붙는다. 지금 텍스트 편집기를 만들고 있는데 처음부터는 아니라는 것이다. 문법을 개선할 기회나 AI 스타일 글쓰기를 쓰지 않도록 강조해 주는 글쓰기 보조 도구를 지향한다고 한다. 프런티어 모델이 많은 왕복을 거쳐 괜찮아 보이는 UI를 만들어 줬는데 놀랍지는 않았고 여러 문제가 있었다. 화면 공간을 최적으로 쓰지 않았고 색 대비가 좋지 않았고 스크롤 모델이 좋지 않았다는 것이다. 그리고 판정이 온다. 전에 이런 실수를 해 봤고 전문성을 쌓았기 때문에 아는 것들인데, 그 전문성이 없으면 무언가를 프롬프트해서 세상에 내놓고 거기서 멈출 수 있다는 것이다. 시간을 들여 전문성을 쌓지 않았으므로 무엇이 더 나은지 모르는 것이다.

다음 에이전트가 찾을 곳에 교훈을 둔다

멘토링하는 사람들에게 하는 말이 인용된다. 에이전트와 일할 때 당신이 그것을 더 좋게 만들어야 하고 그것이 당신을 더 좋게 만들어야 한다는 것이다. 그 뜻이 구체화된다. 매일 어떤 순환이 있어서 교훈이나 기억에 무언가가 추가되어 개선될 수 있어야 한다는 것이다.

그렇지 않을 때의 상태가 인상적으로 표현된다. 새 세션을 시작할 때마다 기억상실증이 있는 신입을 온보딩하는 것처럼 느껴진다는 것이다. 그들은 사업과 제품, 팀, 사용자의 미묘함을 반드시 기억하지 못한다. 그래서 스킬뿐 아니라 맥락과 에이전트에게 주려는 온갖 것에 그토록 많은 것을 담게 된다. 다만 주의가 붙는다. 실제로 유용하고 실제로 문제에 특수한 것과, 그저 상황을 좋게 만든다고 우리가 생각하는 것을 구분하는 데 조심해야 한다는 것이다.

교훈이 사라지는 기제도 구체적이다. 채팅 창에서 문제를 풀다가 UI 컴포넌트의 미묘한 스크롤 버그를 발견하고 에이전트와 왕복하며 거기 미래에 쓸 수 있는 교훈이 있다고 하자. 그 교훈이 기억에 추가될 수도 있고 안 될 수도 있으며 특히 압축이 일어나는 긴 세션이라면 전체 교훈이 들어가지 않을 수 있다. 그러면 채팅 창이 죽을 때 그 교훈이 사라질 수 있다는 것이다.

그래서 대안이 제시된다. 대신 구체적 교훈이나 테스트, 린트 규칙 같은 것으로 부호화하려 하면, 특히 저장소에 부호화될 만큼 작은 것이면 미래 에이전트를 가르칠 수 있다는 것이다. 개인적으로 아주 도움이 됐다고 한다. 교훈을 배우면 몇 분을 들여 이것이 lessons.md에 추가할 만한지, 에이전트에게 자기 기억에 추가하라고 할 만한지 검토한다는 것이다. 이유가 솔직하다. 교훈이 사라지기를 원하지 않는데, 자기는 개인적으로 잊어버릴 것이고 다음 문제로 넘어갈 것이기 때문이다.

에이전트 기억에 대한 경고도 명시된다. 에이전트를 우리가 하는 모든 것을 기억할 것으로 취급하는데 반드시 그렇지 않다는 것이다. 기억 시스템이 있어도 배우려던 흥미로운 것들이나 일하기 좋아하는 방식, 검증에 접근하는 방식을 모두 회상하는 데 완전히 의존할 수는 없다. 그래서 마크다운 파일에 더 담기 시작해도 괜찮지만 그것을 전략으로 과잉 투자하지 않도록 아주 조심하라고 덧붙인다.

이중 루프 개념이 이 절의 결론이다. 배우는 좋은 반복 훈련이 당신을 날카롭게 해야 하고 당신의 에이전트도 날카롭게 해야 한다는 것이다. 그리고 가설이 교정됐을 때, 그 교정이 린팅 규칙이나 타입 제약, 문서 관례, 테스트가 될 자격이 있는지 고려한다. 그것이 남아서 미래에 이롭게 하기 위해서다.

엔지니어가 소유할 외부 루프

숙달에 관한 결론이 정리된다. 전문성과 장인정신에 투자하라는 것이다. 반복 훈련을 하고 실수하고 그것에서 배우면, 시간이 지나며 무엇이 존재할 자격이 있는지 알아낼 수 있게 된다. 계획을 쓰고 다듬고 완료가 무엇을 뜻하는지 정의를 세우고 정확성과 안전, 사용자 영향을 확인하기 위해 사람이 루프에 남을 지점을 계획할 수 있게 된다는 것이다. 그리고 그것이 오늘 엔지니어가 소유해야 할 외부 루프라고 규정한다.

마지막 문장이 이 글의 실천적 결론이다. AI가 엔지니어링을 추상 계층에서 계속 위로 밀어 올리는 것을 계속 볼 것이고 돌릴 수 있는 에이전트가 많아질수록 제한된 시간과 취향, 판단을 어디에 둘지 고르는 데 더 많은 주의가 필요하다는 것이다.

에이전트 사용 자체를 줄이라는 결론은 아니라고 분명히 밝힌다. 코드 수준 전문성이 오늘만큼 가치 있게 남을 기간을 모르고 모델이 너무 빠르게 개선되어 확신하기 어렵다는 것이다. 그리고 에이전트를 피하거나 모든 줄을 직접 타이핑하는 것을 낭만화하는 것이 답이라고 생각하지 않으며 자기는 공격적으로 쓴다고 한다. 어떤 날은 다섯 개나 열 개 세션을 돌리며 한 번은 잘못된 프로젝트에 다크 모드를 추가하라고 요청하고 있는 자신을 발견했다는 일화가 붙는다. 그 실수가 제약을 분명히 했다고 정리된다. 에이전트 처리량이 자기 주의력보다 빠르게 확장된다는 것이다.

더 생각해보기

• 50 대 67퍼센트라는 격차가 파이썬 라이브러리 하나의 단기 연구라면, 어떤 조건에서 이 결과가 일반화되는가.
• 질문하고 설명을 요구한 사람이 더 잘했다면, 도구가 그 행동을 기본값으로 유도하도록 설계될 수 있는가.
• 실수가 없을 때 배움이 없다는 관찰이 맞다면, 의도적으로 실수를 만들어 보는 훈련이 실무에서 가능한가.
• 검증이 바닥이고 상상이 천장이라는 정리에서, 조직은 어느 쪽을 먼저 육성해야 하는가.
• 중급 전문성만으로도 검증된 성공 확률이 오른다면, 신입 교육의 목표 수준을 어디로 잡아야 하는가.
• 교훈을 린트 규칙과 테스트로 부호화하라는 처방은 규칙이 누적될 때 어떤 부작용을 낳는가.
• 마크다운 파일에 과잉 투자하지 말라는 경고는, 어느 지점을 넘으면 과잉인지 어떻게 판별하는가.
• 에이전트 처리량이 주의력보다 빠르게 확장된다면 개인이 동시에 돌릴 에이전트 수에 상한이 있는가.
• 코드 수준 전문성의 가치 지속 기간이 불확실하다면, 지금 무엇에 투자하는 것이 가장 안전한가.