저는 Claude를 만드는 일을 합니다. 흥미로운 경험입니다. 매일 저는 Claude와 함께, 혹은 Claude 혼자서 이뤄 낸 성과를 하나씩 더 알게 되는데, 그중에는 제가 생각해 본 적 없거나, 가능하다고 여기지 않았거나, 그저 시도해 볼 호기심과 시간이 없었던 일들이 있습니다. 이번 달에 Claude는 새로운 행성을 발견하는 데 도움을 주었을 수도 있고, 저는 정말 마음에 드는 첫 AI 뮤직비디오를 보았으며, 우리는 수학의 새 시대를 논의하고 있습니다.
모델의 능력은 균일하게 성장하지 않습니다. Terence Tao의 표현을 빌리면, 모델은 "어떤 방향으로는 경이롭지만, 다른 방향으로는 부족합니다". 어떤 사람들은 그 경이로운 능력을 능숙하게 조종해서 마치 날고 있는 것처럼 보입니다. 제가 만든 제품으로 사람들이 믿기 힘든 높이에 도달하는 모습을 지켜보는 일은 중독성이 있습니다. 하지만 다른 많은 사람들은 아직도 새로 얻은 날개를 작동시키느라 애쓰고 있고, "프랑스의 수도는 어디인가요"나 "이 이메일을 덜 화난 것처럼 다듬어 줄래요" 같은 질문 말고 이 날개를 어디에 써야 할지 궁금해하고 있습니다.
저는 (AI 분야에서 일하는 다른 사람들과 함께) AI를 쓸 때 더 야심 차야 한다고 자주 외칩니다. 이 말은 일종의 구호가 되었습니다. 인상적인 무언가를 볼 때마다 우리는 그것을 다시 공유하면서 "우리는 충분히 야심 차지 않다"라고 씁니다. 저는 그 조언을 따르기가 얼마나 까다로운지 이해합니다. 그래서 더 야심 차게 되는 방법을 튜토리얼로 정리했습니다.
저는 야망을 네 가지 유형으로 생각합니다. 속도(Speed), 고도(Altitude), 깊이(Depth), 범위(Range)입니다.
- 속도: 같은 일을 더 짧은 시간에 해내는 것으로, AI가 만드는 경제적 가치의 기본입니다. 코드를 작성해야 한다면 저는 Claude와 함께 더 빨리 해낼 것입니다. 이 유형은 이미 잘 정착되어 있고, AI에 접근하는 방식에 창의성이 거의 필요하지 않으므로 여기서는 건너뛰겠습니다.
- 고도: 추상화 수준을 높여서, 개별 작업이 아니라 결과를 고려하는 것입니다.
- 깊이: 그 분야를 이끄는 전문가가 바라보는 방식으로 작업을 고려하는 것입니다. 작업이 놓인 층위에서 움직이는 대신 한 단계 더 깊이 내려가서, 그 밑에 있는 데이터와 도구와 문제를 직접 다룹니다.
- 범위: 작업이 겉으로 필요로 하는 한 분야에만 기대지 않고 여러 분야를 끌어오는 것으로, 평소라면 쓰지 않았을 지식과 도구와 기법을 활용합니다.
저는 주로 Claude를 쓰지만(당연하죠), 제 조언은 특정 모델에만 해당하지 않습니다.
고도(Altitude)
우리는 이것을 흔히 가볍게 "모델이 더 높은 추상화 수준에서 일하게 한다"라고 부릅니다. 모델에게 작업을 주면, 모델은 원하는 결과에 도달하는 방법에 대해 여러분이 내린 최선의 추측을 실행합니다. 고도 측면에서 더 야심 차려면 스스로에게 물어보십시오. 다음에는 무슨 일이 일어나기를 원하나요? 목표 너머의 목표는 무엇인가요? 작년 초까지만 해도 저는 Claude에게 개별 크래시를 고쳐 달라고 요청했습니다. 그러다 결국 Claude에게 우리 앱을 크래시 없는 상태로 그냥 계속 유지해 달라고 요청하게 되었습니다.
일상적인 (감히 말하자면 따분한) 사무 작업을 하나 생각해 봅시다. 여러분은 가상의 회사인 Acme Inc에 다니고, 분기보고서에 쓸 발표 자료를 만들어야 합니다. 데이터를 잔뜩 주면 Claude는 기꺼이 슬라이드를 만들어 줄 것입니다. 어쩌면 템플릿이 이미 있어서 Claude가 그 안을 채우기만 하면 될 수도 있습니다. 이것은 새로운 행성을 발견하는 일과 견줄 만한 수준이 전혀 아니므로, 접근 방식을 더 야심 차게 만드는 구체적인 단계를 살펴보겠습니다. 기본에서 출발해서 단계마다 조금씩 더 야심 차게 나아가겠습니다.
- 대부분의 리뷰가 입력으로 받고 싶어 하는 것은 이번 분기에 무엇이 바뀌었는지, 왜 바뀌었는지, 그에 대해 무엇을 해야 하는지입니다. 템플릿에 있는 숫자만 업데이트하고 싶은 충동을 참으십시오. 모델이 여러분의 사업을 이해할 수 있도록, 손에 넣을 수 있는 데이터를 최대한 많이 모델에게도 주십시오. "이번 분기에 무엇이 바뀌었는지, 왜 바뀌었는지, 그리고 우리가 무엇을 해야 하는지 알려 줘."
- (적어도 좋은 종류의) 회의는 이상적으로는 몇 가지 결정으로 끝납니다. Claude에게 이렇게 요청하십시오. "지금까지 알게 된 모든 것을 고려할 때 가장 시급한 결정 세 가지가 무엇인지 파악하고, 찬반 논거와 함께 가능한 방향을 검토하기 시작해 줘."
- 분기보고서는 좋은 리뷰를 하려면 사람이 데이터를 꼼꼼히 걸러 보고, 그 데이터가 무엇을 의미하는지, 사업 방향을 조정해야 하는지를 직접 파악해야 했던 시절에 생겨났습니다. Claude에게 이렇게 요청하십시오. "이 리뷰는 경영진이 문제를 일찍 발견하고 돈과 사람을 올바른 곳으로 옮기기 위해 존재해. 분기별 발표 자료보다 더 나은 방법을 설계하고, 그 방법이 문제를 더 빨리 잡아냈을 것이라는 점을 우리 회사의 과거 기록으로 보여 준 다음, 한 분기 동안 지금 방식과 나란히 운영해 줘."
고도 접근법은 여러분이 정말로 어떤 궁극적인 결과를 추구할 때 가장 잘 작동하고, 창작 작업에는 덜 효과적입니다. 고도 측면의 야망이 좋은 선택인지 알려 주는 확실한 신호가 하나 있습니다. 지금 작업하는 일을 논의하려고 회의를 열게 될 것 같다면 고도를 높여 볼 만합니다. 현재로서는 한계도 있습니다("Claude, 가서 돈 벌어 와"는 2026년 현재 대부분의 사업에서 그것만으로는 통하지 않는 것 같습니다). 하지만 대체로 모델이 유능해질수록 더 높은 추상화 수준에서 일할 수 있게 되는 것 같다는 점을 저는 체감하고 있습니다.
또한 고도는 사람이 루프에 개입하지 않아도 지속적으로 돌아가는 워크플로를 사람들이 찾아내는 영역이기도 합니다. 그러면 모델에게 작업을 하나하나 계속 업데이트해 줄 필요가 줄어듭니다. 이를 잘해 내려면 흔히 워크플로 자체를 바꿔야 합니다. Claude가 우리 앱에서 크래시가 나지 않도록 관리하게 하려고, 저는 먼저 Claude가 크래시 보고서를 쉽게 가져올 수 있게 하고, 어떤 앱 버전이 어떤 git 커밋에 대응하는지 이해할 수 있게 하고, Windows와 macOS와 Linux 컴퓨터에 접근할 수 있게 해서 크래시를 독립적으로 재현하고 수정 사항을 검증할 수 있게 만들어야 했습니다.
깊이(Depth)
그저 작업 하나를 정말 잘 해내고 싶을 때가 있습니다. 깊이 측면에서 야심 차다는 것은, 그 분야의 최고 전문가들이 쓰는 도구와 기법과 매체와 지식을 모델이 사용하도록 밀어붙이는 것입니다. 그리고 그 전문가들조차 여러분의 작업에서 새로운 것을 배울 수 있을 때까지 계속 밀어붙이는 것입니다.
Acme Inc의 분기 사업 리뷰 발표 자료 예시를 이어 가 봅시다. 잠시 Acme Inc가 사용자 이탈(시간이 지나면서 고객을 잃는 현상) 문제로 고전하고 있다고 가정하겠습니다. 저는 다음 기법들을 섞어 쓰는 것이 유용하다는 것을 알게 되었습니다.
- 업계 최고 수준의 사람들이 쓰는 것과 같은 도구를 고집하십시오: 전문가처럼 행동하라는 프롬프트를 받으면, 모델은 실제로 방법을 바꾸지 않은 채 어휘만 바꾸는 경우가 많습니다. 우리 문제를 깊이 있게 다루려면 최고의 데이터 과학자와 통계학자가 쓰는 것과 같은 도구를 써야 합니다. Claude가 마크다운 표를 쓰려고 하면, 데이터베이스와 통계 모델을 쓰라고 고집하십시오. 전문가들이 무엇을 쓰는지 여러분이 꼭 알아야 할 필요는 없습니다. 보통은 Claude가 알고 있습니다.
- 터무니없는 목표를 고르고, 모델에게는 그 목표가 아주 합리적이라고 말하십시오: 웹사이트가 10초가 아니라 5초 안에 로드되어야 하나요? 200ms를 요구하십시오. 모델이 보기에 무언가가 불가능해 보이나요? 그 문제는 충분히 풀 수 있으며 그저 계속 진행하기만 하면 된다고 다시 말해 주십시오.
- 알고 있는 것에 도전하십시오: 특히 사업에서 우리가 사실이라고 믿는 많은 것들은 현실을 대략 근사한 것에 불과합니다. 모델이 원본 정보와 데이터에 접근할 수 있게 하고, 가정을 적대적으로 검증해 달라고 요청하십시오. "우리는 이탈이 온보딩 문제라고 믿고 있어. 원본 데이터에서 그 결론을 재현해 봐."
- 새로운 지식을 만들어 내십시오: 이 기법은 앞에서 다룬 '알고 있는 것에 도전하기'에 쉽게 덧붙일 수 있습니다. Claude가 이미 데이터 깊숙이 들어가 있다면, 사각지대를 찾아 달라고 요청하십시오. "우리 로그로 지난 1년을 재현하는 고객 시뮬레이션을 만들어 줘. 그런 다음 우리가 아직 모르는 가장 이른 이탈 신호를 찾고, 그 신호가 본 적 없는 데이터에서도 예측력을 갖는다는 것을 보여 줘."
- 외부 심판을 쓰십시오: 모델에게 자기 자신을 평가하라고 요청하지 마십시오. 저는 모델 지능이 높아지면서 이 문제가 결국 해결될 것이라고 가정하지만, 2026년 10월 현재로서는 외부 검증을 고집하라고 간곡히 권합니다. 이상적으로는 모델이 실행해서 즉시 피드백을 받을 수 있는 도구가 그 역할을 맡아야 합니다.
제게 자주 도움이 되는 간단한 프롬프트가 있습니다.
이 작업을 더 크게 하는 것이 아니라 더 깊이 있게 하고 싶어. 다시 쓰기 전에 (1) 이 분야의 최고 전문가라면 여기서 내가 요청하지 않은 무엇을 할지 말해 줘. (2) 나를 위해 이미 소화된 자료 대신 그 전문가가 출발점으로 삼을 가공되지 않은 원자료를 말해 줘. (3) 그 전문가가 쓸 구체적인 방법과 도구를 말해 줘. (4) 너나 내가 아닌 무엇으로 결과가 옳다는 것을 입증할 수 있을지 말해 줘. 그런 다음 정확히 그것을 요청하도록 내 프롬프트를 다시 써 줘.
범위(Range)
간단히 말하면, 범위 측면에서 야심 차다는 것은 우리 작업을 여러 다른 분야의 관점에서 고려한다는 뜻입니다. 과거라면 경제적으로 감당할 수 있었던 것보다 더 많은 분야의 관점에서 말입니다. 이것이 특별히 독창적인 통찰은 아닙니다. 모든 하이스트 영화는 처음 30분을 다양한 캐릭터와 재능을 모으는 데 씁니다. AI 제품 덕분에 (여러 스레드나 오케스트레이터, 혹은 단순히 서브에이전트를 써서) 멀티 에이전트 시스템을 돌리기가 점점 쉬워지면서, 저는 Claude에게 다른 분야를 더 끌어오라고 간곡히 요청했을 때 정말 흥미로운 결과를 보아 왔습니다.
이것을 실천하기는 쉽지 않습니다. 창의성이 필요합니다. 제 동료 Alex Albert가 Blender로 인테리어 디자인을 렌더링하는 것을 보기 전까지, 저는 제 홈페이지에 쓸 3D 환경을 만드는 데 Claude를 써 볼 생각을 한 번도 하지 않았습니다. 예전에 비디오 게임을 만든 적도 있는데 말입니다! 그래도 마법 같은 일이 일어나는 모습을 제가 가장 많이 목격하는 영역은 단연 이곳입니다.
그렇다면 어떻게 해야 할까요? 저는 다음 기법들을 씁니다.
- 명사를 동사로 바꿔 보십시오: Tom Kelley와 Jonathan Littman이 쓴 The Art of Innovation에 나오는 오래된 요령입니다. 분기 리뷰는 "발표 자료"가 아닙니다. 그것은 "바쁜 사람들이 인과에 관한 이야기를 믿게 하고, 불확실한 상황에서 30분 안에 결정하게 하는 일"입니다. 동사로 표현하면, 어떤 분야가 독특하고 유용한 관점을 가져올 수 있을지 저와 Claude 모두 이해하기 쉬워집니다.
- 팀을 꾸리십시오: 이 발표 자료가 놀라울 만큼 훌륭하지 않으면 외계인이 지구를 날려 버린다고 해 봅시다. 인류는 어떤 팀을 꾸릴까요? 결과물의 품질을 위해서라면 저는 분석가, 기자, 편집자를 데려오겠습니다. 발표까지 해야 한다면 모션 디자이너와 오디오 디자이너도 필요할 것입니다. 적대적인 "레드 팀"을 두는 것도 유용할 수 있으니, 공매도 투자자와 법회계사도 데려옵시다.
실수로 역할극에 빠지기 쉬운데, 역할극은 실제 결과를 개선하지 못한 채 대화 기록만 더 이상하게 만듭니다. 이 방법은 분야와 기법을 찾는 데 쓰십시오. 모델에게 공매도 투자자처럼 쓰라고 요청하지 말고, 공매도 투자자가 자기 포지션을 조사하려고 하는 일을 하라고 요청하십시오.
제가 설명한 모든 방식의 야망은 모델이 소프트웨어를 설치할 수 있는 컴퓨터를 갖고 있고, (MCP 커넥터나 다른 수단을 통해) 온갖 관련 데이터에 접근할 수 있어야 가능합니다. 이를 가능하게 해 주는 도구는 많고, 저는 그중 하나를 쓰라고 권합니다.
우리는 전에도 여기 와 본 적이 있습니다
여기까지가 더 야심 차게 되는 방법에 대한 제 구체적인 조언입니다. 잠시만 더 머물러 주실 수 있다면, 애초에 이것이 왜 필요하다고 생각하는지 이야기하고 싶습니다.
우리 인간은 언제나 가능하다고 믿는 범위에 발목을 잡혀 왔습니다. 더 나쁜 점은, 우리가 대개 아주 좁은 분야에서만 자신을 믿는다는 것입니다. 미켈란젤로는 시스티나 성당에 그림을 그리고 싶어 하지 않았던 것으로 유명합니다. 아시다시피 그는 화가가 아니라 조각가였기 때문입니다.
야망이라는 문제를 조사하면서, 저는 심리학에 이 현상을 가리키는 이름이 있다는 것을 알게 되었습니다. 바로 자기효능감(self-efficacy)입니다. 간단히 말하면, 자기효능감이 높은 사람은 자기 능력을 더 믿고, 그 결과 실제로 더 많은 것을 이뤄 냅니다. 자기효능감을 의도적으로 끌어올릴 수 있다는 증거도 있습니다. Locke와 Latham은 35년에 걸친 목표 설정 연구를 샅샅이 검토한 끝에, 구체적이고 어려운 목표를 받은 사람이 그저 최선을 다하라는 말만 들은 사람보다 더 좋은 성과를 낸다고 자신 있게 단언했습니다. Stripe 창업자 Patrick Collison은 “Fast” 목록을 관리하면서, 대담한 목표와 빠듯한 마감을 함께 받았을 때 인간이 이뤄 낸 수많은 일을 기록하고 있습니다. 잘 기록된 요령 몇 가지는 다음과 같습니다.
- 가능하다고 믿어서 어려운 일을 해내기: 1939년에 George Dantzig는 버클리의 통계학 수업에 늦게 들어와 칠판에 적힌 문제 두 개를 베껴 썼고, 숙제라고 생각하고 풀이를 제출했습니다. 그 두 문제는 통계학에서 아직 풀리지 않은 문제였습니다.
- 다른 사람이 해내는 것을 본 뒤에 어려운 일을 해내기: 수십 년 동안 인류는 1마일 4분 벽을 쫓았습니다. Roger Bannister는 1954년 5월에 그 벽을 깼지만, 그가 그 기록을 가진 유일한 인간으로 남은 기간은 고작 46일이었습니다. 달리기를 좋아하는 분이라면 아시겠지만, 지금 우리는 마라톤 2시간 벽에서 비슷한 일이 벌어지는 것을 보고 있습니다. Sabastian Sawe는 올해 4월 런던에서 공식 기록으로는 처음으로 2시간 이내에 마라톤을 완주했습니다. 같은 경기에서 2위를 한 선수도 2시간 벽을 깼습니다.
- 실패해도 된다고 스스로 허락해서 어려운 일을 해내기: 모두가 가장 좋아하는 비즈니스 책은 아마 The Inner Game of Tennis인 것 같은데, 저는 바로 지난주에야 이 책을 알게 되었습니다. 이 책의 핵심 주장은, 정말 정말 열심히 하려고 애쓰면 최고의 테니스 경기를 하지 못한다는 것입니다. 우리 엔지니어들은 Linux가 "그냥 취미일 뿐이고, gnu처럼 크고 전문적인 프로젝트가 되지는 않을 것"이라는 말과 함께 발표되었던 것을 기억할지도 모릅니다.
자기효능감은 새로운 문제가 아니지만, 지금은 더 절실한 문제가 되었습니다. 우리의 능력이 몇 주마다 도약하는 세상에서는, 생각해 보지 않았거나 가능하다고 믿지 않았던 일을 해낼 수 있게 해 주는 기법이 필요합니다. 더 야심 차게 되도록 도와주는 기법을 더 찾으신다면 꼭 알려 주십시오!
이 글의 이미지는 Francisco Goya의 "Modo de volar"(날아가는 방법)입니다.
Deep Dive
2026-10-19
고도는 위로, 깊이는 아래로, 범위는 옆으로
세 방향은 작업의 서로 다른 축을 움직인다. 고도는 목표 자체를 위로 옮긴다("이탈 슬라이드를 만들어 줘" → "이탈을 줄여 줘"). 깊이는 같은 목표를 이루는 재료와 방법과 검증을 한 층 아래로 내린다(요약 표 → 원본 로그, 문장 해석 → 통계 모델, 자기 평가 → 보지 않은 데이터). 범위는 목표를 이루는 데 필요한 능력을 옆으로 펼쳐 다른 분야를 데려온다(분석가에 기자, 편집자, 공매도 투자자를 더함). 한 작업에 셋을 함께 적용할 수도 있지만, 지금 바꾸려는 것이 목표인지, 방법인지, 참여하는 분야인지를 먼저 구분해야 맞는 기법을 고를 수 있다.
기법마다 모델의 기본 실패 하나를 교정한다
이 글의 기법들은 모델이 기본적으로 빠지는 실패 하나씩을 겨냥한 교정 장치로 읽으면 이해하기 쉽다.
| 모델의 기본 동작 | 그대로 두면 생기는 일 | 교정하는 기법 |
|---|---|---|
| 사람이 추측한 방법을 충실히 실행한다 | 목표를 낮게 주면 결과도 거기서 멈춘다 | 고도: 목표 너머의 목표를 넘긴다 |
| "전문가처럼"을 어휘로만 받아들인다 | 말투만 전문가 같고 방법은 그대로다 | 깊이: 전문가의 도구와 원자료를 고집한다 |
| 불가능해 보이면 목표를 낮춘다 | 결과가 무난한 수준에서 타협한다 | 깊이: 터무니없는 목표를 합리적이라고 말한다 |
| 자기 결과를 자기가 평가한다 | 같은 맹점 때문에 "문제없음"이 돌아온다 | 깊이: 실행해서 피드백을 주는 외부 심판 |
| 팀을 꾸리라면 캐릭터를 연기한다 | 대화만 이상해지고 결과는 같다 | 범위: 그 분야가 하는 일을 하게 한다 |
세 번째 행은 글 끝의 자기효능감 이야기와 구조가 같다. Locke와 Latham의 목표 설정 연구가 사람에게 내리는 처방(구체적이고 어려운 목표)을 저자는 모델에게도 똑같이 내린다. 사람도 모델도 가능하다고 믿는 범위에서 멈춘다.
야망의 상한선은 환경이 정한다
크래시 사례에서 저자가 먼저 한 일은 프롬프트를 고치는 것이 아니라, Claude가 크래시 보고서를 가져오고, 앱 버전과 git 커밋을 대응시키고, 세 운영체제 컴퓨터를 쓸 수 있게 만드는 것이었다. 깊이의 원자료와 외부 심판, 범위의 서브에이전트도 모두 모델이 손댈 수 있는 환경이 있어야 가능하다. 저자가 범위 절 끝에 "모델이 소프트웨어를 설치할 수 있는 컴퓨터와 관련 데이터에 접근할 수 있어야 가능하다"고 덧붙인 이유가 여기에 있다.
Key Insight
야망의 상한선을 정하는 것은 프롬프트의 문구가 아니라, 모델이 손댈 수 있는 원자료와 도구, 사람도 모델도 아닌 판정 장치, 그리고 그것을 요구할 수 있다고 믿는 사람의 자기효능감이다.