1편에서는 개발자의 역할이 오케스트레이터로 옮겨가는 이유, AI의 5가지 실패 패턴, 그리고 읽기:쓰기 = 10:1 인사이트를 다뤘습니다. 2편에서는 이 원리를 실제 업무에 적용하는 구체적인 실행 프로세스 — 지식 축적 시스템, Task DAG, Branch Hunt, Ralph Loop, 그리고 이를 지원하는 커스텀 인프라를 소개합니다.
1편 요약
1편에서 다룬 핵심 인사이트는 세 가지였습니다.
- 핵심 노동의 이동: 코드를 쓰는 시간보다 탐색하고 설계하는 시간이 10배 더 많았습니다
- AI의 예측 가능한 실패: 5가지 패턴(원인 축소, 가설 고착, 국소 최적화, 환경 맹점, 탐색 중단)은 모두 컨텍스트 품질 문제로 수렴합니다
- 읽기:쓰기 = 10:1: 좋은 코드의 출발점은 빠른 생성이 아니라 정확한 탐색입니다
이번 글에서는 이 원리를 실제 업무에 어떻게 적용하는지, 구체적인 실행 프로세스를 소개합니다.
AI의 가장 큰 약점 — 기억하지 못한다
지식은 축적돼야 합니다.
AI 세션은 휘발적이므로 세션이 끝나면 소중한 지식들이 사라집니다. 3개월 전에 같은 문제를 해결한 적이 있어도, AI는 그걸 모릅니다. 매번 처음부터 탐색하고, 같은 실수를 반복하고, 같은 결정을 다시 내리게 됩니다.
이게 AI의 가장 큰 구조적 약점 중 하나입니다.
근데 이건 시스템으로 해결할 수 있습니다.
사람의 기억도 완벽하진 않습니다. 예를 들어 3개월 전 정산 배치에서 어떤 결정을 했는지, 왜 그 방식을 골랐는지 정확히 기억하기 어렵습니다. 하지만 기록이 있고 검색할 수 있다면 얘기가 달라집니다. AI도 마찬가지입니다. 세션이 기억을 유지할 수 없으면, 외부 기억 시스템을 붙이면 됩니다.
Obsidian + 로컬 시맨틱 검색
지식 축적 흐름: 작업 중 발견한 지식 → Obsidian 자동 기록(MCP 연동) → 로컬 임베딩 인덱스(QMD) → recall 스킬로 시맨틱 검색 → “3개월 전 정산 배치에서 비슷한 이슈 있었는데…” → 즉시 회상
| 구성 요소 | 역할 |
|---|---|
| Obsidian | 로컬 마크다운 지식 저장소. 세션 요약, 아키텍처 결정, 트러블슈팅 기록 |
| QMD 플러그인 | 로컬 임베딩 생성. 외부 서버 불필요. 프라이빗 데이터 안전 |
| recall 스킬 | AI 세션 내에서 시맨틱 검색 호출. “이전에 비슷한 작업 있었어?” |
| Obsidian MCP | AI가 직접 Obsidian에 읽기/쓰기. 작업 결과를 자동 기록 |
활용 순서는 다음과 같습니다.
-
세션의 컨텍스트를 요약해서 obsidian에 저장하고 Vector DB에 임베딩하는 skill 생성
- 의사결정 사항, 도메인 지식, 비즈니스 규칙, 실행 환경 등
- md파일 태그, 일시 등의 메타데이터를 포함
- 디렉토리 구조를 자율적으로 구조화
- QMD cli를 사용하여 변경/추가된 문서 임베딩
-
obsidian 적재 skill을 사용하여, 세션의 내용을 주기적으로 저장
- 세션이 완료되었을 때 또는 중요한 지식이 확보되었을 때
- 다음에도 이 지식을 활용하고 싶을 때
-
QMD cli를 활용하여 주어진 키워드를 기반으로 시멘틱 서치를 수행하는 skill 생성
- QMD cli 커맨드를 통해 Vector DB에 쿼리 조회
- 키워드 기반 시멘틱 서치 결과 문서 반환 - 컨텍스트 확보
-
시멘틱 서치 skill을 사용하여 확보한 컨텍스트를 기반으로 작업 진행
-
obsidian 문서 저장 skill 예시
### obsidian-vault-manager
**Obsidian vault 문서 관리 자동화 스킬**
AI가 Obsidian vault의 구조를 **동적으로 탐색**하여, 새 문서의 최적 위치를 스스로 판단하고 생성/수정/인덱싱까지 수행한다.
**핵심 워크플로우:**
1. **탐색** — vault 디렉토리/태그/MOC 현황 파악 (하드코딩 없이 매번 동적 탐색)
2. **라우팅** — 문서 내용 분석 → 영역(업무/기술/커리어 등) 자동 분류 → 위치 결정
3. **생성** — 문서 작성 + 관련 문서 링크 + 태그 자동 부여
4. **인덱싱** — MOC(Map of Contents) 허브에 링크 추가, 태그 체계 문서 업데이트
**사용 예:** "이 회의 내용 옵시디언에 정리해줘" → vault 탐색 → `회사/프로젝트/` 하위에 문서 생성 → MOC 업데이트 → 관련 문서 링크까지 완료- 과거 AI 세션의 시맨틱 검색 + 임베딩 skill 예시
QMD 벡터 DB를 활용해 과거 대화를 의미 기반으로 검색하고, wikilink/tag 그래프를 2-hop까지 순회하여 관련 문서를 확장한다. 미기록 세션은 Obsidian 데일리 노트에 자동 요약·동기화.
두 가지 모드:
모드 동작
/recall <query> QMD 시맨틱 검색 → 그래프 fan-out(wikilink + 공유 태그 + 2-hop) → 통합 결과 반환
/recall sync 미기록 세션 탐지 → 한국어 요약 생성 → 데일리 노트에 기록 → QMD 임베딩 + 그래프 캐시 갱신임베딩한 문서의 벡터 공간을 시각화한 예시입니다.
여기서 qmd cli를 활용해 아래 커맨드를 수행하면 키워드 기반의 시멘틱 서치가 수행됩니다. (물론 이 커맨드도 skill 안에 포함시켜 에이전트가 자율적으로 수행 가능합니다)
qmd vsearch "정기결제" --json -n 10 -c "obsidian vault"예를 들어 정기결제 관련 작업을 수행하고자 할때, 세 세션을 열고 정의해둔 스킬을 사용하여 시멘틱 서치를 수행하면 아래와 같이 문서를 가져오게됩니다. 미리 만들어둔 문서를 기반으로 컨텍스트를 확보한 상태에서 작업을 수행할 수 있습니다
간단하게 말하면 로컬 RAG를 구축한 것입니다.
RAG를 서비스로서 제공하는 Saas도 많지만, Saas의 임베딩 모델에 의존하는 것을 피하고자, 그리고 외부연동 및 과금 없이 로컬 환경에서 구축하고자, 이렇게 구성해서 사용하고 있습니다.
회사 코드, 아키텍처 결정, 비즈니스 로직이 외부 서버로 나가지 않습니다. QMD 플러그인이 로컬에서 임베딩을 만들고, 검색도 로컬에서 수행하기 때문입니다.
이 시스템 덕분에 AI 세션은 일회성이 아니라 축적되는 자산이 됩니다. 3개월 전의 의사결정 근거를 추적하고, 반복 실수를 방지하고, 새 세션에서 과거 컨텍스트를 바로 복원할 수 있어요.
실행 사이클
앞의 인사이트들을 실제 업무에 적용하는 실행 프로세스입니다.
- 심층 인터뷰 플래닝 (~1시간)
- Task DAG 구성 → 병렬 처리
- Ralph 구현 (자동 반복 루프)
- 검증 → 구멍 발견 시 1번으로 복귀
대부분의 중규모 이상 작업에 적용하는 프로세스입니다.
Step 1 — 심층 인터뷰 플래닝
구현 시작 전에 거의 구멍이 없을 정도로 요구사항과 제약을 확정합니다. 적게는 30분에서 많게는 1~2시간까지 걸립니다.
플래닝에서 확인하는 것들:
- 요구사항의 정확한 범위와 경계
- 기존 코드베이스의 컨벤션과 패턴
- 의존하는 외부 시스템과 제약 조건
- 성공 기준과 검증 방법
- 병렬 가능한 단위와 의존성 관계
“2시간을 플래닝에 쓰는 게 과한 거 아닌가요?” 라고 생각하실 수 있을 것 같습니다.
처음엔 저도 그렇게 생각했습니다. 근데 플래닝에 투자한 시간만큼 구현에서 재작업이 줄어들었습니다. 플래닝 없이 바로 구현하면, 중간에 방향을 수정하거나 처음부터 다시 하는 비용이 훨씬 큽니다.
AI한테 “만들어줘”가 아니라 “이 조건으로, 이 순서로, 이 기준까지”를 전달하는 게 플래닝의 요점입니다. AI는 지시의 명확도에 비례해서 품질이 올라갑니다.
Step 2 — 두 가지 병렬 전략
Task DAG — 구현 병렬화
제가 작업을 DAG(Directed Acyclic Graph)로 쪼갭니다.
(아래는 예시 테스크 입니다)
| Layer | 태스크 | 의존성 |
|---|---|---|
| 0 (병렬) | A: DB 스키마, B: 공통 DTO | 없음 |
| 1 (병렬) | C: API 엔드포인트, D: 배치 프로세서 | C←A+B, D←B |
| 2 (병렬) | E: 프론트 리스트, F: 프론트 상세, G: 배치 스케줄러 | E←C, F←C, G←D |
| 3 | H: 통합 테스트 | E+F+G 모두 완료 후 |
A와 B는 DAG 상 같은 Layer로 분해된 태스크로 병렬 처리가 가능합니다. C는 A+B 둘 다 끝나야 시작할 수 있다는 의존 관계가 있으며, D는 B만 선행되면 작업이 가능합니다. 즉 단순 팬아웃이 아니라 위상 정렬 기반 실행 순서가 핵심입니다.
- Task DAG를 통한 구현 병렬화 예시
이전에 전체 서비스 또는 특정 사용자의 결제를 차단하는 기능을 개발해야했습니다. kill switch 상태값을 공통 관리하고, 그 값에 따라 여러 서버에서 관련 기능을 제공해야했는데요.
이때 Task DAG를 통하여 여러 서버에 걸친 개발 건을 DAG로 도식화하고 병렬 수행함으로써 수일이 걸릴 작업을 하루만에 끝낼 수 있었습니다.
┌──────────────────────────────────────────────────────────────────────────────┐
│ 결제 즉시 차단 (FTC-1270) 전체 DAG │
├──────────────────────────────────────────────────────────────────────────────┤
│ ■ = 완료 □ = 미실행 ▒ = 블로커 대기 │
│ │
│ PHASE 1: 즉시 차단 기능 │
│ ──────────────────────────────────────────────────────────────────────────── │
│ │
│ L0 (탐색) │
│ │
│ ┌───────────────────────┐ ┌────────────────────────┐ │
│ │ ■ T0A │ │ ■ T0B │ │
│ │ pg-front 탐색 │ │ member-api 탐색 │ │
│ └──────────┬────────────┘ └──────────┬─────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ │
│ L1 (핵심 서비스) │
│ │
│ ┌──────────────────────────────┐ ┌────────────────────────────────────┐ │
│ │ ■ T1 │ │ ■ T5 │ │
│ │ Kill Switch + │ │ NoAuthCaseResolver │ │
│ │ Block 추상화 (1254) │ │ + 토글 차단 체크 (1260) │ │
│ └──────────────┬───────────────┘ └──────────────┬─────────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ │
│ L2 (API + 진입점 차단) │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ ■ T2 │ │ ■ T3 │ │ ■ T4 │ │
│ │ 차단 API │ │ 재활성화 │ │ 공통 Reg │ │
│ │ 1257 │ │ 1267 │ │ 1256 │ │
│ └──────┬────────┘ └──────┬────────┘ └──────┬────────┘ │
│ │ │ │ │
│ └───────────────┬─┴─────────────────┘ │
│ ▼ │
│ │
│ ----------------------------- 리팩터링 ---------------------------------- │
│ │
│ L3 (품질) │
│ │
│ ┌──────────────────────────────┐ │
│ │ ■ R1 │ │
│ │ Map -> DTO 리팩터링 │ │
│ └──────────────┬───────────────┘ │
│ ▼ │
│ │
│ L4 (코드리뷰) │
│ │
│ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │
│ │ ■ CR1 │ │ ■ CR2 │ │
│ │ pg-front 리뷰 │ │ member-api 리뷰 │ │
│ │ C2, M5 발견 -> 수정 │ │ M3 발견 -> 수정 │ │
│ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ │
│ L5 (테스트 + 피드백 반영) │
│ │
│ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │
│ │ ■ FIX1 │ │ ■ FIX2 │ │
│ │ pg-front 테스트 │ │ member-api 테스트 │ │
│ │ + CR 피드백 반영 │ │ + @Volatile/@Profile │ │
│ │ 62 PASS │ │ 50 PASS │ │
│ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │
│ │ │ │
│ └──────────────┬───────────────────┘ │
│ ▼ │
│ │
│ L6 (통합) │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ □ T6 │ │
│ │ Phase 1 통합 테스트 (FTC-1261) │ │
│ │ 두 레포 dev 배포 후 실행 │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ PHASE 2: 결제 제어 (미확정 사항 대기) │
│ ──────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │
│ │ ▒ FTC-1262 │ │ ▒ FTC-1263 │ │
│ │ 환금성 상품 │ │ 금액 임계치 │ │
│ │ 빠른결제 override │ │ 빠른결제 override │ │
│ │ (카테고리코드 TBD) │ │ (임계값 TBD) │ │
│ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │
│ │ │ │
│ └──────────────┬───────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────┐ │
│ │ □ FTC-1266 │ │
│ │ Phase 2 통합 테스트 │ │
│ └──────────────────────────────┘ │
│ │
│ PHASE 3: BO 어드민 (기획서 대기) │
│ ──────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐ │
│ │ ▒ FTC-1258 │ │ ▒ FTC-1268 │ │ ▒ FTC-1269 │ │
│ │ BO 사용자 차단 화면 │ │ BO 재활성화 화면 │ │ Audit 로깅 시스템 │ │
│ │ (기획서 필요) │ │ (기획서 필요) │ │ (범위 미정의) │ │
│ └────────────────────┘ └────────────────────┘ └────────────────────┘ │
│ │
├──────────────────────────────────────────────────────────────────────────────┤
│ Phase 1: 12/13 ███████████░ T6만 남음 │
│ Phase 2: 0/3 ▒▒▒▒▒▒▒▒▒▒ 미확정 사항 대기 │
│ Phase 3: 0/3 ▒▒▒▒▒▒▒▒▒▒ 기획서 대기 │
│ │
│ pg-front: 4 commits (feature/FTC-1270) │
│ member-api: 2 commits (feature/FTC-1270) │
└──────────────────────────────────────────────────────────────────────────────┘Branch Hunt — 디버깅 병렬화
부모 세션이 코드베이스를 DFS(깊이 우선 탐색)로 스캔하면서, 이슈를 발견할 때마다 독립 Branch 세션을 띄우는 전략입니다. 이때 부모 세션은 멈추지 않고 이슈 탐색을 위해 전진하고, 각 Branch는 이슈를 독립적으로 조사 및 디버깅하는 전략입니다.
- Branch Hunt를 통한 디버깅 병렬화 예시 (병렬로 작업을 수행 중인 독립 Branch 세션들)
| Task DAG | Branch Hunt | |
|---|---|---|
| 목적 | 구현 속도 | 버그 수렴 |
| 분해 주체 | AI가 사전에 분해 | AI가 발견 시 분기 |
| 실행 순서 | 사전 확정 (DAG) | 동적 (DFS 중 발견) |
| 종료 조건 | 모든 Wave 완료 | 스캔 클린 + 이슈 0 |
오케스트레이션 범주 안의 상황에 따라 골라 쓰거나 결합해서 사용합니다.
주로 신규 개발 건 및 리팩터링 작업에 대해 Task DAG 전략을, 디버깅 및 코드 리뷰 작업에 대해 Branch Hunt 전략을 사용합니다.
Step 3 — 자동 구현 + 검증 (Ralph Loop)
Ralph는 끝날 때까지 자동으로 반복하는 실행 모드입니다.
Ralph 실행 루프: 구현 시작 → 자동 검증(Build · Type Check · Test) → 통과하면 다음 태스크, 실패하면 수정 후 재검증 (자동 반복)
세 가지 특성이 있습니다:
- 무인 자동 실행: 제가 중간에 개입하지 않아도 완료 조건을 만족할 때까지 알아서 작업을 진행합니다
- 검증 내장: 수정 2회마다 자동 검증 1회 — Ralph가 타입 체크·빌드·테스트를 알아서 수행합니다
- 안전장치: 실패하면 자동 재시도. 3회 연속 실패하면 멈추고 보고합니다
정산 배치 개발을 DAG 전략으로 병렬화 하고 + E2E 테스트를 진행할 때 — 기존에 약 5일 걸리던 작업을 DAG 구성 2분 + 병렬 실행 20분으로 끝냈습니다. Ralph가 각 서브태스크의 구현과 검증을 자동으로 반복하는 동안, 저는 최종 결과만 확인했습니다.
물론, 많은 재수행없이 Ralph 루프로 작업의 퀄리티를 올리려면, 앞선 단계들이 탄탄히 진행되어야한다는 전제가 있습니다.
커스텀 인프라
이 실행 사이클을 지원하기 위해 직접 만든 도구들이에요.
| 도구 | 역할 | 왜 필요했나 |
|---|---|---|
| Session Spawn MCP | iTerm에 독립 AI 세션을 병렬 생성 | 기존 도구는 서브에이전트만 지원. 완전 독립 세션이 필요했습니다 |
| 메시지 인박스 | 각 세션이 완료 시 중앙 인박스에 결과 보고 | 병렬 세션의 결과를 수집할 통합 채널이 없었기 때문입니다 |
| 전용 스킬 | dag-orchestrator, branch-hunt 같은 실행 방식을 스킬화 | 반복되는 실행 패턴을 재사용하기 위함입니다 |
Session Spawn MCP는 부모 에이전트의 컨텍스트 오염을 방지하면서, 자식 에이전트를 병렬로 실행할 수 있게끔 만든 MCP입니다.
위에서 소개해드린 dag-orchestration과 branch-hunt skill 등에서도 사용하는 mcp입니다. 아래는 Session Spawn MCP가 갖고있는 Tool list입니다.
| Tool | 설명 |
|---|---|
| spawn_session | 독립 AI 세션을 새 터미널 윈도우에 생성. 부모 컨텍스트 오염 없이 병렬 실행 |
| check_inbox | 자식 세션들의 완료 보고를 폴링. 가장 빠른 결과부터 수집 |
| report_result | 자식 세션이 작업 완료 시 부모에게 결과를 구조화해서 보고 |
| send_message | 실행 중인 자식 세션에 추가 지시 전달 (타임아웃 경고, 방향 수정 등) |
| get_session | 특정 세션의 상태/출력 조회. 고스트 완료(보고 없이 종료된 세션) 감지용 |
| close_session | 완료된 세션 정리 |
메시지 인박스는 각 세션의 중간 결과/진행 상황/최종 보고 내용을 취합하는 중앙 집중형 저장소에요. 부모 에이전트가 여러개의 자식세션을 동적으로 모니터링하고 핸들링할 수 있도록 하기 위해서 만들었습니다.
서브 에이전트를 사용할 때는 주의해야할 점이 몇가지 있습니다. 첫번째로 항상 서브 에이전트가 위임받은 작업을 잘 수행하는 것은 아니라는 점. 두번째로 서브 에이전트는 부모 에이전트의 컨텍스트 윈도우를 공유한다는 점입니다.
부모 에이전트와 컨텍스트를 공유하게되면 추가적인 컨텍스트 확보 없이 갖고있는 컨텍스트만으로 작업을 수행할 수 있다는 장점이 있지만, 탐색/추론/작업 과정에서의 컨텍스트 윈도우가 함께 소모되기때문에 자칫하면 부모에이전트의 컨텍스트를 오염시킬 수 있습니다.
그래서 중규모 이상의 작업에 대해 Session Spawn MCP와 메시지 인박스를 활용하여, 자식 에이전트를 병렬로 운용하되 부모 에이전트의 컨텍스트 윈도우 손상 없이 결과만 보고받는 형태로 동작하게 됩니다.
컨텍스트를 공유하지 않으므로 재탐색에 대한 토큰 소모량이 늘어나는 단점이 있지만, 각 자식 에이전트에게 할당된 작업에 대해 더욱 집중할 수 있고, 부모 컨텍스트는 장기적으로 컨텍스트 품질을 유지하며 오케스트레이션 작업을 할 수 있게됩니다.
- Session Spawn Mcp + 메시지 인박스 아키텍처
이 커스텀 인프라가 940세션에서 2,594개 서브에이전트를 운용할 수 있었던 근본적인 이유입니다.
이 도구들은 각각 독립적으로도 쓸모 있지만, 합쳐졌을 때 진짜 힘이 납니다. Session Spawn으로 병렬 세션을 만들고, 인박스로 결과를 모으고, 전용 스킬(dag-orchestrator, branch-hunt)로 실행 패턴을 재사용하는 것입니다. 이 인프라가 하나의 파이프라인으로 돌아가면서 대규모 작업의 병렬 실행이 가능해졌습니다.
시리즈를 마치며
1편과 2편에 걸쳐 다룬 핵심을 정리합니다.
1. 핵심 노동은 구현이 아니라 분해·플래닝·검증 코드를 쓰는 시간보다 탐색하고 설계하는 시간이 10배 더 많았습니다.
2. 탐색 품질이 결과 품질을 결정 구현 전에 높은 품질의 컨텍스트를 확보하는 데 투자했습니다.
3. AI는 예측 가능하게 실패하니까, 대응 패턴을 알면 관리 가능 5가지 패턴 + 대응법이 있습니다.
4. 지식은 축적돼야 한다 Obsidian + 시맨틱 검색으로 세션의 휘발성을 극복했습니다.
이 네 가지는 따로 놀지 않고 서로 선순환을 가져옵니다. 탐색 품질(2)이 높으면 분해·플래닝(1)이 정확해지고, 실패 패턴(3)을 알면 검증(1)이 효율적이 되고, 지식 축적(4)은 다음 작업의 탐색 품질(2)을 높입니다.
개발자에서 오케스트레이터로
“앞으로 개발자의 경쟁력은 구현량보다 오케스트레이션 능력에서 더 크게 갈릴 것이라고 생각합니다.”
AI를 통해 업무 방식을 오케스트레이션으로 전환하면서 많은 변화가 있었습니다
- 배포 주기가 절반으로 줄었습니다. 플래닝과 검증이 자동화되니까 “이거 배포해도 되나?” 하는 망설임이 줄었습니다.
- 기존보다 2~3배 많은 테스트 수행할 수 있었습니다. 직접 테스트를 짜는 게 아니라, AI가 구현하면서 테스트까지 함께 만들고 돌리는 구조이기 때문입니다.
- 덕분에 배포에 자신감이 생겼습니다. 검증 단계가 구조적으로 보장되니까, 핫픽스 횟수도 눈에 띄게 줄었습니다.
AI를 쓰면 빨라지는 것만 이야기하기 쉬운데, 실제로 가장 크게 달라진 건 품질에 대한 확신이었습니다. 빠르게 만드는 건 누구나 할 수 있지만, 빠르게 만들면서도 안심하고 배포할 수 있는 건 검증 구조가 있을 때만 가능합니다.
코드를 이해하는 능력은 여전히 필수입니다. AI가 아무리 잘 짜줘도 “이게 맞는 방향인지”는 사람이 판단해야 합니다. 다만 코드를 직접 타이핑하는 시간의 비중은 점점 줄어들 것입니다. 그 자리를 AI가 잘 일할 수 있도록 구조를 설계하는 시간이 채웁니다.
마무리
제가 AI를 많이 사용한 이유는 단순히 AI와 많이 대화했기 때문이 아니라, AI가 일할 수 있는 구조를 설계했기 때문입니다.
AI 시대의 핵심 역량은 더 빨리 타이핑하는 것이 아니라 더 잘 분해하고, 위임하고, 검증하는 것입니다.
결국 AI를 많이 쓴 건 사실입니다. 근데 많이 쓰면서 배운 건, 많이 쓰는 게 중요한 게 아니라는 거였어요.
이 글에서 소개한 방식이 정답은 아닙니다. 다만 53일 동안 148000번의 대화를 거치면서 자연스럽게 정착된 제 방식입니다. 같은 고민 중이신 분들께 참고가 되면 좋겠습니다.
