아티클
AI 활용의 천장은 당신의 야망이다: 속도, 높이, 깊이, 폭 네 가지 차원
Anthropic 엔지니어링 책임자 Felix Rieseberg는 'AI에 더 야심 차게 임하기'를 속도, 높이, 깊이, 폭의 네 가지 차원으로 나눕니다. 이 글은 그의 방식과 사례를 정리하고, 제 실천 노트를 더했습니다. 목표 지향적인 지시를 내리고 Multi-AI Agents 전문가 팀을 조율해 다각도 교차 검토를 하면서 작업 품질을 높이는 방법입니다.
· 6분 분량
Anthropic 엔지니어링 책임자 Felix Rieseberg는 「How to be more ambitious: A tutorial for humans with models」에서, 다른 사람이 AI로 놀라운 결과를 내는 것을 볼 때마다 자신과 주변 사람들이 늘 같은 반응을 보인다고 말합니다. "우리는 아직 충분히 야심 차지 않다."
제 해석은 이렇습니다. 사람이 AI를 쓰는 한계는 모델이 아니라 자신의 야망과 상상력에 막히는 경우가 많다.
그는 '야망'을 네 가지 차원으로 나눕니다.
- 속도(Speed): 같은 일을 더 짧은 시간에 끝낸다.
- 높이(Altitude): 추상화 수준을 끌어올려 개별 작업이 아니라 최종 결과를 본다.
- 깊이(Depth): 해당 분야 최고 전문가의 기준, 도구, 방법으로 해낸다.
- 폭(Range): 한 분야에서 벗어나 여러 분야를 넘나들며 해법을 찾는다.
결론부터 말씀드리면, 목표 지향적인 지시를 정확하게 내리고 Multi-AI Agents 전문가 팀을 조율해 다각도 협업과 교차 검토를 하면 작업 품질이 전반적으로 올라갑니다.
1. 속도: 가장 기본적이고, 가장 적은 사람이 막히는 차원#
같은 일을 더 짧은 시간에 끝내는 것입니다. Felix는 이 부분은 이미 다들 익숙하다고 보고 글에서 바로 건너뜁니다.
제 생각은 이렇습니다. 속도는 AI의 가장 직관적인 가치이지만, 속도만 좇아서는 협업 방식이 크게 달라지지 않습니다. 진짜 차이를 만드는 것은 뒤의 세 가지 차원입니다.
2. 높이: '목표 뒤의 목표'를 묻기#
핵심 질문: 다음에 진짜 원하는 결과는 무엇인가? 목표 뒤의 목표는 무엇인가?
Felix의 사례:
- 크래시 하나를 고치는 데서, 앱이 더는 크래시하지 않게 만드는 데로. 그는 처음에 Claude에게 크래시 하나를 고쳐 달라고 했다가, 나중에는 앱의 크래시를 0으로 유지해 달라고 요청했습니다. 이 일이 계속 자동으로 돌아가게 하려면 먼저 자신의 프로세스부터 바꿔야 했습니다. 크래시 리포트를 쉽게 가져올 수 있게 하고, 앱 버전을 Git 커밋에 대응시키고, Claude가 Windows, macOS, Linux 머신을 사용해 재현하고 수정을 검증할 수 있게 한 것입니다.
- 분기 비즈니스 리뷰(QBR)의 3단계 업그레이드:
- 가능한 한 원본 데이터를 사용해 이번 분기에 무엇이 달라졌는지, 왜 그런지, 다음에 무엇을 해야 하는지 설명한다.
- 가장 시급한 결정 3가지를 찾아 각각 찬반 논거를 쓴다.
- 분기 보고서보다 더 일찍 문제를 발견하는 대체 메커니즘을 설계하고, 과거 데이터로 테스트한 뒤, 현행 프로세스와 한 분기 동안 병행 운영한다.
그는 한계도 짚어 줍니다. 2026년 현재 "Claude, 가서 나 돈 좀 벌어 줘" 같은 모호한 목표는 아직 통하지 않지만, 모델이 다룰 수 있는 추상화 수준은 점점 높아질 것으로 예상합니다.
3. 깊이: 해당 분야 최고 전문가의 사양에 맞추기#
Felix의 방식:
- 그 업계에서 실제로 쓰는 도구를 쓴다. 모델은 표현만 바꾸고 방법은 바꾸지 않은 채, Markdown 표 하나 던져 놓고 끝내는 경우가 많습니다. 데이터베이스, 통계 모델처럼 진짜 분석 도구를 쓰도록 끝까지 요구해야 합니다.
- 비합리적으로 보이는 목표를 세우고, 풀 수 있는 문제라고 모델에게 알려 준다. 그의 사례: 웹사이트 로딩 시간을 10초에서 5초로 줄인 뒤, 다시 200밀리초를 요구합니다. 모델이 물러서려 할 때, 이 목표는 달성할 수 있다고 계속 밀어붙입니다.
- 스스로 믿는 가정에 도전한다. 원본 데이터를 모델에게 주고 대립적인 관점에서 검증하게 합니다. 예: "우리는 이탈의 원인이 온보딩이라고 생각한다. 원본 데이터에서 이 결론을 재현해 보라."
- 새로운 지식을 만든다. Logs로 시뮬레이션을 만들어 아직 모르는 가장 이른 이탈 신호를 찾고, 본 적 없는 데이터로 검증합니다.
- 외부 심판(Outside Judge)을 둔다. 모델이 자기 결과를 스스로 채점하게 하지 않습니다. 모델이 직접 실행할 수 있고 즉시 피드백을 주는 도구를 연결해 검증하는 것이 가장 좋습니다.
그의 프롬프트 요령은 이렇습니다. 원하는 것은 '더 큰 버전'이 아니라 '더 깊은 버전'이다. 최고의 전문가라면 무엇을 더 할지, 가장 원본에 가까운 데이터는 어디에 있는지, 어떤 방법과 도구를 쓸지, 그리고 모델이나 내 판단 말고 무엇이 결과가 맞다는 것을 증명해 줄 수 있는지를 모델이 말하게 합니다.
4. 폭: 명사 대신 동사로, 전문가 팀을 꾸리기#
- 명사 대신 동사. 이 개념을 Felix는 The Art of Innovation에서 가져왔습니다. QBR은 '발표 자료 한 편'이라기보다 '30분 안에 바쁜 사람이 인과관계를 이해하고 불확실한 상황에서 결정을 내리게 하는 것'입니다. 동사로 목표를 정의하면 어떤 분야의 역량이 필요한지 보입니다.
- 팀을 꾸린다. 좋은 발표 자료를 만들려면 애널리스트, 기자, 편집자를 두고, 무대에서 발표한다면 모션 및 사운드 디자이너를 더합니다. 대립적 검토를 하려면 공매도 기관의 리서처와 포렌식 회계사를 둡니다.
- 의미 없는 롤플레이는 하지 않는다. 모델에게 "공매도 기관의 말투로 써라"가 아니라, 공매도 기관이 리서치의 한 부분을 수행하는 방법을 실제로 실행하게 하라는 것입니다. 말투만 바꾸어서는 결과가 나아지지 않습니다.
전제는 모델에게 소프트웨어를 설치할 수 있는 컴퓨터가 있고, MCP 커넥터 등을 통해 관련 데이터에 접근할 수 있어야 한다는 것입니다.
5. 나의 실천 노트: '데이터 전달'에서 '의도 달성'으로#
아래는 소프트웨어 아키텍처와 엔지니어링 실무를 결합한 제 확장 내용이며, 원문의 내용이 아닙니다.
1. Jobs to be Done과 의도 지향(Intent-Based)#
- "무엇을 할까"가 아니라 "무엇을 달성할까"를 묻는다. 설계는
generate_deck_pdf() 같은 수동적인 데이터 전달 파이프라인에 머물지 말고, resolve_leadership_uncertainty_and_commit_budget() 같은 상태 전이의 의도로 끌어올려야 합니다.
- 진짜 손실 함수를 정의한다. 산출물만 요구하면 모델은 겉보기에 완벽한 헛소리를 만들어 냅니다. 의사결정의 불확실성을 해소해 달라고 요구해야 모델과 Sub-agent가 논리적 구멍과 리스크 경계를 스스로 메웁니다.
2. 탐색할 때는 발산하고, 검수할 때는 수렴한다#
- 탐색할 때는 먼저 발산해 가능성을 찾고, 그다음에 수렴한다.
- 검수할 때는 더 이상 발산하지 않는다. "이 일을 달리 어떻게 할 수 있을까?" 같은 경계 없는 질문은 뻔한 답만 불러옵니다.
- 목표 범위, 제약 조건, 객관적인 검증 도구를 명확히 적는다(특정 테스트 스크립트, 비즈니스 지표 기준선). 그래야 Multi-Agent 팀이 초점이 잡힌 틀 안에서 스트레스 테스트를 하고 높은 품질의 결과물을 내놓습니다.
핵심 정리#
- 목표 지향: 명사 대신 동사. 제출용 산출물이 아니라 문제를 해결하는 결과를 전달한다.
- 탐색과 수렴: 탐색할 때는 발산해 가능성을 찾고, 검수할 때는 엄격히 수렴해 경계를 검증한다.
- 추상화 초점: 핵심 질문에서 출발해 작업 흐름 전체를 다시 짠다.
- 전문가의 깊이: 전문가의 말투를 흉내 내는 데 그치지 않고, 최고 전문가의 도구와 방법으로 문제를 풀도록 모델을 몰아붙인다.
원문: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)