AI 도구가 답답해지는 이유: 실용적인 학습 지도

Ailoot 사용 방법에 관한 자세한 내용은 문서에서 확인할 수 있습니다.

보편적 심리 법칙이 아닌 학습 비유#

심리 진단보다 좁은 질문을 해 보세요. 기대가 검증 가능한 결과와 맞나요? 끝내려던 일과 실제 동작을 비교하고 그 증거로 다음 작업을 조정하세요.

자신감만으로 능력을 측정하지 말고 실제 결과와 이를 뒷받침하는 검사를 보세요.

그 이후 던닝–크루거 곡선은 네 단계로 이루어진 대중적인 도식이 되었습니다. 먼저 자신감이 “어리석음의 산 정상”까지 치솟습니다. 그러다 “절망의 계곡”으로 곤두박질칩니다. 이후 “깨달음의 경사”를 천천히 올라 “지속 가능성의 정체기”에 도달합니다.

곡선은 이 글의 비유입니다. 독자 연구로 포기율, 고정 학습 기간, 보편적인 단계 경로를 입증하지 않았습니다.

바이브 코딩의 4단계—당신은 지금 어디에 있나요?#

각 단계는 전형적인 생각과 행동으로 알아볼 수 있습니다. 여기 지도가 있습니다.

1단계—어리석음의 산 정상

Claude Code에 관한 글을 읽습니다. 동영상을 봤을 수도 있습니다. 모든 것이 명확해 보입니다. 도구를 설치하고, 프롬프트를 입력하면, 코드가 나옵니다. 글을 쓴 사람들은 “하룻밤 만에 SaaS를 만들었다”고 합니다. 당신도 하룻밤 만에 그렇게 하고 싶어집니다.

머릿속 생각:

• “이해한 것 같아.”
• “그냥 채팅인데, 더 똑똑할 뿐이야.”
• “나는 기업가야. 프로그래머는 필요 없어.”
• “한 달이면 익혀서 두바이로 떠날 거야.”

행동:

• Claude Code를 내려받아 설치합니다.
• 채팅에 “예약 앱을 만들어 줘”라고 입력합니다.
• 실행되지 않는 코드를 받습니다.
• 모델이 잘못된 것이라고 생각해 Max 구독을 구매합니다.

가능한 시작 모습 중 하나입니다. 기대가 실제 결과와 떨어지면 답답함이 커질 수 있습니다. 작은 프로젝트와 명확한 검사는 구체적인 학습 근거를 줍니다.

실용적인 자기 점검으로 다른 사람이 같은 산출물을 명시 기준에 따라 살펴보게 하세요. “AI 전문가”라는 자신 있는 소개는 생성 결과의 품질 증거가 아닙니다.

초기의 자신 있는 인상은 가설로 두세요. 코드를 실행하고 출력을 확인해 실제 결과에 따라 자신의 능력 추정을 바꾸세요.

2단계—절망의 계곡

더 깊이 파고듭니다. MCP에 관한 글을 읽고 서버 연결을 시도합니다. 이미 만들어진 Skill을 내려받아 이해하려고 해봅니다. Plan Mode를 실행하면 에이전트가 계획을 작성하지만 세 번째 단계에서 엉뚱한 길로 빠집니다. ~/.claude/를 열어 보니 폴더가 12개나 있고, 각각의 용도를 하나도 모르겠습니다.

머릿속 생각:

• “나는 아무것도 할 줄 몰라.”
• “SNS에 있는 사람들은 다 거짓말을 하는 거야.”
• “다른 사람에게 되는 게 나한테는 안 돼.”
• “내가 너무 일찍 시작한 걸까?”
• “토큰에 $200를 썼는데, 남은 게 뭐지?”

행동:

• 문서 탭을 한꺼번에 20개 엽니다.
• 모든 채팅을 “이전 맥락은 잊어”로 시작합니다.
• 포럼을 둘러보며 “X가 내 프로젝트를 망가뜨렸다” 같은 글을 읽습니다.
• Claude와 Cursor, Cursor와 Codex, Codex와 Cline을 비교합니다. 도구를 잘못 고른 것이라고 생각합니다.
• 아침에 코딩하려고 앉지만 점심때가 되기도 전에 피드를 내리고 있습니다.

답답한 상황일 수 있습니다. 측정된 이탈률은 없으므로 아래 신호에서 시험할 변화 하나를 찾으세요.

3단계—깨달음의 경사

멈춥니다. 속도를 늦춥니다. 새로 나오는 것마다 붙잡으려는 일을 그만둡니다. 첫 CLAUDE.md를 작성해 프로젝트에 넣습니다. business/ 폴더를 만들고 제품, 가격, 대상 고객에 대한 설명을 넣습니다. /compact를 열 번 실행한 뒤에야 어떤 맥락을 남겨야 하는지 이해합니다. 특정 작업을 위한 30줄짜리 첫 Skill을 만듭니다.

머릿속 생각:

• “아, 이렇게 작동하는구나.”
• “일주일 전에는 못 했던 일을 오늘 해냈어.”
• “business/와 ai-clone/가 어떻게 다른지 알 것 같아.”
• “작업 X에 쓸 준비된 프롬프트가 이미 있어.”

행동:

• 새로운 작업을 시작할 때마다 Plan Mode로 돌아갑니다.
• Claude에 무엇이든 쓰기 전에 “이 내용이 내 CLAUDE.md에 있나?”라고 자문합니다.
• 다음 방법론 규칙을 찾습니다. 이제 새로운 도구가 주의를 끌지 않습니다.
• 채팅에서 다른 사람을 돕습니다. “나도 여기서 막혔는데, 이렇게 해봐.”

4단계—지속 가능성의 정체기

이 단계는 모든 일이 쉬워지는 지점이 아닙니다. 지식과 자신감이 마침내 일치하는 지점입니다.

머릿속 생각:

• “내가 무엇을 모르는지 알고 있어.”
• “이 작업은 세 시간 걸릴 거야. 전에 해봤으니까.”
• “이건 새 Skill이 필요하겠어. 지금 만들어 둬야지.”
• “Claude가 계획에서 벗어나면 가능한 이유가 세 가지 떠올라.”

행동:

• 제품을 꾸준히 만듭니다. 하나는 하룻밤 만에, 다른 하나는 주말 동안 만듭니다.
• 프로젝트마다 자체 Skills 폴더, 자체 하위 에이전트, 자체 business/ 폴더가 있습니다.
• 근본적으로 혼자 처리할 수 없는 부분에 한해 선택적으로 외주를 맡깁니다.
• 다른 사람의 동영상 튜토리얼은 새 아이디어를 얻기 위해 볼 뿐, 기초를 배우려고 보는 경우는 드뭅니다.

자기 평가 체크리스트—지금 어느 단계인가요?

• Claude Code를 아직 써보지 않았고 “하룻밤이면 할 수 있겠는데”라고 생각한다면 1단계입니다.
• 써보고 MCP를 열어 Skills를 읽으려 시도했고 “내가 왜 이걸 시작했을까?”라고 생각한다면 2단계입니다.
• CLAUDE.md를 만들었고 Claude의 행동이 실제로 어떻게 달라지는지 알 수 있다면 3단계입니다.
• 제품을 꾸준히 만들고 언제 어떤 도구를 써야 하는지 정확히 안다면 4단계입니다.

지금 절망의 계곡에 있다는 7가지 신호#

계곡은 갑자기 찾아오지 않습니다. 서서히 스며듭니다. 다음은 그 신호들입니다.

1. 무언가를 만드는 대신 도구를 비교합니다. “Cursor vs Claude Code” 탭을 엽니다. 다 읽고 “Cline vs Cursor”를 엽니다. 그다음에는 “Codex vs 나머지 전부”를 엽니다. 비교할 때마다 “내가 잘못된 곳을 파고 있는 건 아닐까?”라고 생각합니다. 하루가 끝날 때까지 코드 한 줄도 쓰지 않고 네 시간을 보냅니다.

2. 새로운 채팅을 시작할 때마다 “그전에 있었던 일은 전부 잊어”라고 합니다. CLAUDE.md가 없고 /compact를 익히지 못했으며 컨텍스트 창이 무엇인지도 이해하지 못합니다. 모든 세션이 백지에서 시작합니다. 일주일 뒤에는 Claude에게 같은 내용을 열다섯 번째 설명했다는 사실을 알아차립니다.

3. 프롬프트를 모으기만 하고 사용하지 않습니다. Notion에 “Claude Code Prompts” 폴더를 만들었습니다. 그 안에 북마크가 47개 있습니다. 한 번이라도 두 번 사용한 것은 없습니다. 매번 “이건 확실히 내가 필요한 거야”라고 생각합니다.

4. 다른 사람은 “인맥이 있어서 성공한다”고 생각합니다. SNS를 열어 누군가 주말 동안 제품의 첫 버전을 출시한 것을 봅니다. “저 사람은 팀도 있고 인맥도 있어. 나는 못 해”라고 생각합니다. 그 사람이 4단계에 있고 자신은 2단계라는 점은 생각하지 않습니다.

5. 프로젝트를 3일째 되는 날 포기합니다. 새 프로젝트는 “대단한 걸 만들 거야!”라는 흥분으로 시작해 3일째에 끝납니다. 과제가 “채팅에 인사말 보내기”에서 “결제 처리하기”로 어려워지면 떠납니다. 어려운 일을 하는 게 두렵습니다.

6. Claude가 잘 작동하지 않아 ChatGPT에서 답을 찾습니다. Claude가 나쁜 답을 주자 ChatGPT를 엽니다. ChatGPT가 나쁜 답을 주자 Gemini를 엽니다. 요청을 잘못 표현했을 가능성은 떠올리지 않습니다. 언제나 도구가 문제라고 생각합니다.

7. “이건 나랑 맞지 않아”라고 말합니다. 학습 불가능보다 답답함의 표현일 수 있습니다. 계곡은 비유이며 누가 이 느낌을 겪고 이후 어떻게 되는지의 비율이나 기간은 측정되지 않았습니다.

여러 신호가 맞으면 확인 가능한 작은 작동 결과를 목표로 정하세요. 장애를 기록하고 작업 방식 한 부분을 바꾸세요. 목록은 개선 기간을 예측하지 않습니다.

사람들이 계곡에서 포기하는 이유—그리고 그게 게으름이 아닌 이유#

도구에 대한 답답함은 능력의 믿을 만한 측정이 아닙니다. 장기 결정을 내리기 전에 작업 크기, 부족한 지식, 실행 환경을 살펴보세요.

어려웠던 한 주로 뇌의 기제를 추정하지 말고 시도, 작동한 것, 다음 단계를 막은 오류, 시간을 기록하세요. 구체적으로 개선할 위치를 찾을 수 있습니다.

계곡에서는 두 가지 충격을 동시에 받습니다. 첫째, 자신의 진전이 기대에 미치지 못합니다. 둘째, 주변 사람들이 자신은 내지 못한 결과를 발표합니다. SNS를 열면 누군가는 제품의 첫 버전을 출시했고, 누군가는 에이전트를 만들었으며, 누군가는 Claude API로 첫 $100를 벌었습니다. 당신은 3주 동안 데이터베이스 연결조차 하지 못했습니다.

빨라졌다는 인상과 실제 시간을 함께 기록하세요. 에이전트는 생산적으로 느껴져도 리뷰·재작업을 늘릴 수 있습니다. 주관적 이득을 실측으로 보지 말고 대표 작업을 기존 방식과 비교하세요.

낯선 작업에서 느린 진행은 능력 부족의 증거가 아닙니다. 학습 비용과 도구 출력을 분리하고 확인 가능한 더 작은 결과를 정하세요.

반복 가능한 다음 단계가 없으면 도구를 바꾸거나 작업을 포기하기 쉽습니다. 아래 세 기둥은 저자의 제안 구조이며 이탈 원인의 통계적 증명이 아닙니다.

세 가지 기둥—계곡을 벗어나는 방법론#

여기에 설명한 저자의 경험에서는 계곡을 벗어나는 데 3개월이 걸렸습니다. 그동안 수십 가지 도구를 시도했습니다. 그리고 한 가지를 깨달았습니다. 문제는 Claude가 아니었습니다. 매번 백지에서 시작한 것이 문제였습니다. 기억도, 규칙도, 경계도 없었습니다.

그 뒤 프레임워크를 만들었습니다. 이름은 “세 가지 기둥”입니다. Claude Code 워크플로 전체를 떠받치는 세 가지 구성 요소를 가리킵니다. 이 중 하나라도 제거하면 프레임워크가 무너집니다.

기둥 1—나를 닮은 AI 클론

AI 클론은 Claude가 자동으로 적용할 수 있는 형식으로 정리한 당신의 전문성입니다.

절망의 계곡에서는 매번 “이 작업 좀 도와줘”라고 Claude에 쓰고 자신의 접근 방식을 처음부터 설명합니다. 기둥 1은 이를 해결합니다. ai-clone/ 폴더에 여러 파일로 방법론을 보관합니다. “고객 사례를 처리하는 방법”에 관한 Skill, “Telegram 게시물을 작성하는 방법”에 관한 Skill, 계획 단계에서 당신처럼 생각하는 “product architect” 하위 에이전트가 있습니다.

기둥 1의 실제 모습:

• Skills—특정 작업을 위한 지침 파일입니다(/build-article, /build-reel-script).
• 하위 에이전트—전문 분야가 서로 다른 페르소나로, Claude가 이들 사이에 하위 작업을 위임합니다.
• ai-clone/feedback/ 폴더—실수에서 배운 규칙을 담습니다. 각 규칙은 Rule - Why - How 형식을 따릅니다.

이 내용은 Skills, Subagents, MCP, Plugins 가이드에서 자세히 다뤘습니다. 언제 무엇을 써야 하는지 알려 주는 안내서입니다.

기둥 2—세컨드 브레인

세컨드 브레인은 Claude가 바로 접근할 수 있는 프로젝트 지식의 구조화된 저장소입니다.

절망의 계곡에서는 매 세션마다 제품이 무엇인지, 대상 고객은 누구인지, 비즈니스 모델은 무엇인지 Claude에 설명합니다. 3주째가 되면 같은 내용을 15번째 설명했다는 사실을 깨닫습니다. 기둥 2는 이를 해결합니다. 프로젝트 지식을 코드와 함께 파일로 정리하면 필요할 때 Claude가 직접 읽습니다.

기둥 2의 실제 모습:

• CLAUDE.md—에이전트의 진입점입니다. 행동 규칙, 경로, 다른 모든 항목을 가리키는 링크를 담습니다.
• business/ 폴더—제품, 대상 고객, 경제성, 목표, 콘텐츠 계획, 경쟁사를 담습니다.
• plans/ 폴더—단계별 기술 계획과 각 계획의 상태를 담습니다.
• retrospectives/ 폴더—같은 실수를 반복하지 않도록 이전 세션에서 얻은 교훈을 담습니다.

전체 내용은 CLAUDE.md 설정 가이드와 Claude Code에서 세컨드 브레인 만들기 가이드를 참조하세요.

기둥 3—컨텍스트 엔지니어링

컨텍스트 엔지니어링은 Enter를 누르기 전에 Claude의 컨텍스트 창에 무엇을 넣을지 관리하는 것입니다.

절망의 계곡에서는 채팅이 40개 메시지에 이르면 Claude가 지시를 “잊는” 이유를 이해하지 못합니다. /compact가 왜 필요한지 이해하지 못합니다. “쓰지 않는 편이 더 빠르다”며 Plan Mode를 열지 않습니다. 기둥 3은 이를 해결합니다. 컨텍스트에 무엇을 불러올지 의도적으로 정합니다. 더 관련 있는 입력을 주지만 주장과 결과는 여전히 검증해야 합니다.

기둥 3의 실제 모습:

• Plan Mode—에이전트가 먼저 작업 계획을 작성하고, 당신이 승인하면 실행합니다. 사용하지 않으면 첫 시도가 혼란스러운 결과를 낳습니다.
• /compact—채팅 기록을 지능적으로 압축합니다. 컨텍스트가 차기 시작하면 압축하고 핵심 결정만 남깁니다.
• 구조화된 프롬프트—“도와줘” 대신 “맥락 A는 다음과 같고, 작업 B를 수행해 형식 C로 결과를 반환해”라고 씁니다.
• 하위 에이전트—새로운 컨텍스트에 하위 작업을 위임해 기본 컨텍스트에 과부하가 걸리지 않게 합니다.

이 내용은 컨텍스트 엔지니어링 가이드와 Plan Mode 가이드에서 다뤘습니다.

세 가지인 이유—하나만으로는 안 되는 이유

세컨드 브레인만 만들 수도 있습니다. 그러면 Claude는 프로젝트를 알게 되지만 규칙 없는 인턴처럼 행동합니다.

AI 클론만 만들 수도 있습니다. 그러면 Claude가 당신의 전문성을 맡지만 프로젝트 기억이 없어 매 세션을 처음부터 시작합니다.

컨텍스트 엔지니어링은 작업 입력을 개선할 수 있지만 원활한 실행이나 지식 보존을 그 자체로 보장하지는 않습니다.

세 가지를 모두 결합해야만 제가 “예측 가능한 프레임워크”라고 부르는 것을 얻을 수 있습니다. Claude는 프로젝트를 기억합니다. 당신의 방법론을 자동으로 적용합니다. 그리고 작업 중에 맥락을 놓치지 않습니다.

그때 절망의 계곡에서 빠져나오게 됩니다.

계곡에 머물게 하는 7가지 안티패턴#

자신의 작업 방식에서 점검할 만한 안티패턴:

1. CLAUDE.md 없이 “작동하는 앱을 만들어 줘”라고 합니다. Claude Code에서 새 채팅을 열고 곧바로 작업을 지시합니다. Claude는 프로젝트, 방법론, 선호에 관한 맥락이 없습니다. 일반적인 템플릿을 내놓고, 당신은 실망합니다.

할 일: CLAUDE.md를 만들고 최소한의 내용을 넣으세요. 기술 스택, 비즈니스 모델, 대상 고객, 다른 파일로 연결되는 링크입니다. 모든 채팅은 이 맥락에서 시작합니다.

2. /compact 없이 긴 대화를 이어 갑니다. 메시지 80개짜리 세션을 진행합니다. Claude는 12번째 메시지에서 무엇을 결정했는지 더는 기억하지 못합니다. 컨텍스트 창에는 핵심 결정은 없고 우왕좌왕한 기록만 들어차 있습니다. 답변의 품질이 떨어집니다.

할 일: 30~40개 메시지마다 /compact를 호출하고 무엇을 남겨야 하는지 말하세요. 컨텍스트가 더 집중됩니다.

3. 첫 번째 답변을 그대로 신뢰합니다. Claude가 해결책을 내놓으면 바로 적용합니다. 한 시간 뒤 다른 파일 세 개가 망가졌다는 사실을 알게 됩니다. “또 제대로 작동하지 않네”라며 포기합니다.

할 일: 복잡한 작업에는 Plan Mode를 사용하세요. 먼저 계획을 세우고, 계획을 논의한 다음, 실행합니다. 이렇게 하면 반나절 작업한 뒤가 아니라 계획 단계에서 오류를 발견할 수 있습니다.

4. 구조가 없는 엉성한 프롬프트를 씁니다. Claude가 알아서 이해하리라 기대하며 “잘해줘”라고 씁니다. 하지만 Claude는 당신에게 “잘한다”는 것이 무엇인지 모릅니다. 그래서 추측합니다.

할 일: “맥락 - 작업 - 제약 조건 - 형식” 구조로 프롬프트를 작성하세요. 첫 시도에서 좋은 결과를 얻을 가능성이 크게 높아집니다.

5. 비용 추적을 무시합니다. 토큰을 얼마나 쓰는지 모릅니다. 월간 플랜이 끝나 대시보드를 열어 보니 $200를 써버렸습니다. 놀라서 그만둡니다.

할 일: 토큰 지출 추적기를 설정하세요. 도구는 토큰 추적기 가이드에서 검토했습니다. 지출을 실시간으로 확인하면 토큰을 쓸데없이 소모하지 않게 됩니다.

6. “올바른 도구”를 끝없이 찾습니다. Cursor가 나오면 Cursor로 바꾸고, Cline이 나타나면 Cline을 시도합니다. Codex가 업데이트되면 다시 Codex로 돌아갑니다. 2주마다 새 도구로 옮겨 매번 처음부터 시작합니다. 도구가 자신에게 맞춰 작동하기 시작하는 수준에 도달하지 못합니다.

할 일: 도구 하나를 선택하세요. 3개월 동안 사용하세요. 사소한 구실이 생길 때마다 바꾸지 마세요. 저는 현재 도구로 근본적으로 할 수 없는 일이 있을 때만 비교해 봅니다.

7. “방법론을 읽을 시간은 없어”라고 합니다. 도구는 준비 없이 작동해야 한다고 생각합니다. 프롬프트 작성은 타고난 기술이라고 생각합니다. CLAUDE.md는 “불필요한 단계”라고 생각합니다. 그 결과 두 번째 달에도 방법론을 사용했다면 일주일 만에 끝낼 수 있었던 일을 계속하고 있습니다.

할 일: Claude Code도 다른 전문 도구처럼 학습이 필요하다는 점을 받아들이세요. 방법론을 통해 배워야 합니다. 여기서는 직관이 통하지 않습니다.

관련 내용: Claude Code에서 아첨을 피하는 가이드는 계곡에서 가장 큰 오해, 즉 Claude가 당신의 생각에 동의하면 언제나 옳다는 믿음을 피하는 방법을 살펴봅니다.

깨달음의 경사에 올라섰다는 5가지 신호—계곡을 벗어났는지 확인하는 법#

3단계에 도달했다는 다섯 가지 신호입니다.

1. 200줄이 넘는 CLAUDE.md가 있고, 의도적으로 관리해 왔습니다. 템플릿을 복사한 게 아니라 직접 쌓아 올렸습니다. 모든 섹션과 그 이유를 압니다. 새로운 패턴을 보면 규칙을 추가합니다.

2. 일상적이지 않은 작업을 시작하기 전에 Plan Mode를 켭니다. 누가 시켜서도 아니고, 단순한 규율 때문도 아닙니다. 계획이 없으면 한 시간을 허비하고 잘못된 결과를 얻는다는 점을 이해하기 때문입니다. 이제 “추가 단계”가 아니라 반사적인 행동이 되었습니다.

3. 자체 Skills 및 Subagents 목록이 있습니다. GitHub에서 내려받은 것이 아니라 직접 만든 것입니다. 자신이 구체적으로 하는 작업에 맞춰져 있습니다. 새로운 작업이 이전 작업과 비슷하면 처음부터 프롬프트를 쓰는 대신 자신의 Skill을 떠올립니다.

4. 작업 속도가 안정되었습니다. 이제 “이런 작업은 3시간 걸려”라고 압니다. “금방 끝나겠는데”도 아니고 “영원히 걸리겠는데”도 아닙니다. 현실적인 시간 추정치를 갖고 있습니다. 이는 던닝–크루거 효과의 양방향에서 벗어났다는 뜻입니다. 과대평가도 과소평가도 멈춘 것입니다.

5. 사람들이 당신에게 묻기 시작합니다. 채팅에서 누군가 MCP에 관해 질문하면 구체적인 사례로 답합니다. “나한테는 이렇게 됐어.” 누군가 Plan Mode에 관해 물으면 자신의 사례를 보여 줍니다. 이는 방법론을 익힌 결과입니다. 계곡에 있는 사람들은 자신의 경험을 당신에게서 알아보고 찾아옵니다.

이 신호로 최근 진전을 돌아보되 점수나 평지 도달 시기를 예측하지 마세요. 시간이 지나며 추정과 실제 결과가 더 일치하는지 재확인하세요.

정체기에 도달하면 에이전트가 있는 프레임워크에서 사람의 역할이 바뀝니다.

그것이 계곡을 벗어난 여정의 결과입니다. 더는 “프롬프트 쓰는 법을 배우는 중”이 아닙니다. 에이전트 프레임워크를 관리하고, 프로세스 설계자가 되며, 최상위에서 방향을 잡는 사람이 됩니다.

지금 당장 의욕을 잃고 있다면 할 일#

다음 작업에서 시험할 세 단계입니다.

1단계—현재의 구체적인 어려움을 말합니다. “현재 작업 방식의 이 부분이 답답하다. 구체적인 장애를 말하고 더 작은 다음 단계를 고를 수 있다.”

2단계—속도를 늦춥니다. 프로젝트 하나를 선택하세요. 둘도 셋도 아닌 하나입니다. 세 기둥 중 하나를 선택하세요. 이 프로젝트에서 가장 많은 문제를 해결할 기둥입니다. 프로젝트가 새것이고 맥락이 전혀 없다면 세컨드 브레인(CLAUDE.md)을 선택하세요. 프로젝트는 있지만 Claude가 “당신처럼” 행동하지 않는다면 AI 클론(Skills)을 선택하세요. 작업이 길고 컨텍스트가 차고 있다면 컨텍스트 엔지니어링(Plan Mode + /compact)을 선택하세요.

프로젝트 하나, 기둥 하나, 2주입니다. 주말 동안 모든 것을 만들려 하지 마세요. 그러면 계곡으로 되돌아갑니다.

3단계—체계를 갖춥니다. 직접 방법론을 만들 수 있습니다. 여기에 설명한 저자의 경험에서는 3~6개월이 걸렸습니다.

모델을 계속 사용하려면 Ailoot로 이동하세요.