Prologue

"지금 이 AI 시대에, 나는 파도를 타고 있는가? 아니면 파도에 휩쓸려 가고 있는가?"

첫 영상이 "왜"라면, 둘째 영상은 "어떻게"입니다.

Part 1. AI Native — 능력이 아니라 디폴트가 된 시대

1.1 75%가 쓴다, 그러나 그것은 시작일 뿐이다

영상 1의 첫 질문은 단순합니다.

• "AI를 자기 돈 내고 쓰는 사람이 한국에 몇 %나 있을까?"
• "그렇다면 AI를 쓰는 모든 사람이 AI Native일까?"

답은 "아니다"입니다. AI를 쓴다는 것과 AI Native가 된다는 것은 완전히 다른 차원의 문제입니다.

수치로 먼저 풀어봅시다. Microsoft와 LinkedIn이 31개국 31,000명의 지식 노동자를 대상으로 진행한 2024 Work Trend Index에 따르면, 글로벌 지식 노동자의 75%가 이미 업무에서 생성형 AI를 쓰고 있고 그 비율은 6개월 만에 2배 가까이 늘었습니다. ChatGPT 한 곳만 봐도 2025년 10월에 주간 활성 사용자 8억 명을 돌파했고, 2026년 들어 9억 명에 가까워졌습니다.

1.2 "Native"라는 단어의 무게

한국어 네이티브를 떠올려 보면 직관적입니다. 한국에서 태어나 한국어로 생각하고, 한국어로 농담하고, 한국어로 꿈꾸는 사람. 누가 가르쳐서 잘하는 게 아니라 의식하지 않아도 한국어가 먼저 나오는 상태입니다.

AI Native도 마찬가지입니다.

조금 더 직관적으로 말하면 — AI를 도구가 아니라 동료로 대하는 사람입니다. 도구는 필요할 때 꺼내고 끝나면 서랍에 넣지만, 동료는 옆에 계속 있고 새 일이 떨어지면 같이 시작하고 막히면 같이 풉니다.

1.3 AI-Enhanced vs AI-Native

영상 1은 AI를 활용하는 사람을 두 그룹으로 나눕니다.

영상 1에서 누군가는 "AI Native 직원은 일반 직원보다 10배 생산적"이라고 표현했다고 합니다. 과장처럼 들리지만 — 그렇게까지 비현실적이지 않을 수 있다는 것이 영상의 주장이고, 뒤에 나올 실험 데이터가 그 주장을 일부 뒷받침합니다.

1.4 같은 시기에 Karpathy가 한 말 — Software 3.0

이 흐름은 한 명의 메타 엔지니어 혼자 던지는 메시지가 아닙니다. OpenAI 공동창업자였던 Andrej Karpathy는 2026년 봄 AI Ascent 강연 "From Vibe Coding to Agentic Engineering"에서 거의 같은 진단을 합니다 — 우리는 지금 "Software 3.0" 시대에 들어섰다고. 신경망이 곧 프로그래머블 컴퓨터가 되고, 프롬프트가 코딩을 대체하기 시작한 시대.

Karpathy의 표현을 빌리면, 영상 1의 메시지는 이렇게 다시 읽힙니다.

"AI Native가 된다는 것은, 'Software 3.0' 환경의 모국어를 쓰는 사람이 된다는 뜻이다."

영상 1과 Karpathy의 강연이 향하는 곳은 같습니다. 다만 다음 질문이 남습니다 — "AI Native가 안 되면, 정확히 무엇이 잘못되는가?"

Part 2. 격차는 매일 누적되고 있다

영상 1은 AI를 쓰는 75%와 AI Native 1%의 차이를 추상적으로만 말하지 않고, 세 층위의 데이터로 보여줍니다 — 개인, 채용 시장, 회사.

2.1 개인 단위 — GitHub Copilot 연구의 진짜 디테일

영상 1이 인용한 "AI를 적극 활용한 개발자가 55% 더 빨랐다"는 수치는 GitHub와 Microsoft Research가 함께 진행한 arXiv 논문 2302.06590에서 나옵니다. 영상에서는 한 줄로 지나간 이 연구가 사실 꽤 흥미로운 디테일을 담고 있습니다.

영상이 다루지 않은 부분이 더 흥미롭습니다 — 품질을 깎아 속도를 얻은 게 아니었다는 점입니다. 개발자들은 보일러플레이트와 문법 검색에 쓰던 시간을 줄이고, 그 시간을 비즈니스 문제와 아키텍처 결정에 더 썼습니다.

2.2 작업 품질 — BCG/Harvard "Jagged Frontier" 연구

영상 1의 두 번째 인용은 BCG와 Harvard Business School이 758명의 컨설턴트를 대상으로 진행한 Navigating the Jagged Technological Frontier 실험입니다. 영상에서는 "12% 더 많은 작업, 40% 더 높은 품질" 두 숫자만 언급되지만, 원 논문은 그보다 훨씬 입체적입니다.

논문이 강조하는 더 중요한 메시지는 "Jagged Frontier(들쭉날쭉한 프론티어)"라는 개념입니다.

영상의 데이터와 합쳐 읽으면 이렇게 됩니다 — AI를 잘 쓰는 사람은 빨라지고 좋아진다. 그러나 어디까지 맡길지 모르는 사람이 AI를 더 많이 쓰면 더 자주 틀린다. 이 둘의 격차는 같은 회사, 같은 직급, 같은 월급에서 매일 벌어지고 있습니다.

2.3 채용 시장 — "AI 써 보셨나요"는 더 이상 면접 질문이 아니다

작년만 해도 "AI를 잘 다루면 우대"였던 채용 공고가, 올해는 기본 자격으로 옮겨가고 있습니다. LinkedIn Economic Graph의 분석에 따르면 미국 내 AI 리터러시를 요구하는 채용 공고가 전년 대비 70% 증가했고, AI 엔지니어 직군은 2년 연속으로 가장 빠르게 성장하는 직군입니다.

면접에서 묻는 질문도 그래서 달라졌습니다.

답을 못 하면 다음 질문으로 넘어가지도 않는다는 것이 영상의 표현이고, LinkedIn 데이터는 그 진단을 뒷받침합니다.

2.4 회사 단위 — 6주 vs 6시간

가장 무서운 건 회사 단위입니다.

같은 시장인데 한 회사는 6주, 다른 회사는 6시간이 걸린다면 — 1년이 누적될 때 시장 점유율이 어떻게 될지는 굳이 보지 않아도 뻔합니다.

여기까지가 영상 1의 진단입니다. 자연스럽게 다음 질문이 따라옵니다.

"그래서, 무엇을 해야 하는가?"

Part 3. 다리 — Karpathy가 같은 시기에 한 말

흥미롭게도, 영상 1·2가 올라온 비슷한 시점에 Karpathy도 정확히 같은 질문에 답하는 강연을 했습니다. 그의 답을 한 줄로 옮기면 이렇습니다.

Karpathy는 같은 강연에서 한 가지 개념도 함께 던집니다 — "Jagged Intelligence". LLM은 검증 가능한 영역(수학·코드·논리)에선 정점에 가깝지만, 열린 추론에서는 여전히 들쭉날쭉하다는 진단입니다. BCG/HBS 논문의 "Jagged Frontier"와 결을 같이하는 통찰입니다.

영상 2가 풀어내는 "하네스 엔지니어링"은 정확히 이 질문에 대한 한 사람의 구체적 답입니다 — "디테일한 스펙과 가드레일을 어떻게 시스템으로 만들 것인가."

Part 4. 하네스 — AI라는 말에 채우는 마구

4.1 결론부터: 우리는 이미 하네스를 쓰고 있다

영상 2의 첫 메시지가 의외입니다.

2026년 초 Claude Code의 시스템 프롬프트가 부분적으로 유출되면서 이 사실이 더 분명해졌습니다. 그 안에는 강력한 가드레일이 박혀 있었습니다.

• 메인 브랜치에 force push 절대 금지
• 자동화 불가능한 위험 명령 차단
• 항상 새 커밋을 생성해 히스토리 보존 (--amend 우회 방지)
• 위험한 git 명령은 시스템 차원에서 막아 놓음

영상 1에서 말한 하네스의 네 기둥 — 컨텍스트 파일, 게이팅, 도구 경계, 피드백 루프 — 이 이미 Claude Code 안에 모두 내장되어 있다는 뜻입니다.

4.2 Martin Fowler의 정의 — Guides + Sensors

이 "하네스"라는 단어는 영상 2가 만든 용어가 아닙니다. 같은 시기 소프트웨어 업계의 거장 Martin Fowler도 같은 표현을 쓰며 Harness Engineering for Coding Agents라는 권위 있는 글을 발표했습니다. 정의는 이렇습니다.

Fowler는 하네스를 두 메커니즘으로 분해합니다 — 영상 2의 "컨텍스트 vs 가드레일" 구분과 정확히 매핑됩니다.

영상 2의 비유 — "하네스는 AI라는 거대한 말이 우리가 원하는 방향으로 달리게 만들어 주는 마구(馬具)다" — 와 Fowler의 정의는 다른 언어로 같은 개념을 가리킵니다.

4.3 내장 하네스의 한계

하지만 Claude Code의 내장 하네스에는 한계가 있습니다 — 범용이라는 점입니다. 모두를 위해 만든 것이라, 내 프로젝트만의 규칙은 모릅니다.

• "API 호출은 반드시 이 wrapper를 거쳐라"
• "이 외부 라이브러리는 쓰지 마라"
• "DB 스키마는 이미 확정됐으니 절대 건드리지 마라"

이런 도메인 스페시픽한 규칙·아키텍처 결정·기술 선택의 이유 — 이걸 AI에게 알려주는 것이 곧 2층 하네스를 쌓는 일입니다.

4.4 두 갈래 — 오픈소스 vs 커스텀

2층을 쌓는 방법은 크게 두 가지입니다.

영상 2가 소개한 oh-my-claudecode는 한국 개발자 Yeachan Heo가 만든 오픈소스로, GitHub 스타가 빠르게 누적되며 한국어 README까지 포함되어 있습니다. 핵심 사양은 다음과 같습니다.

• 19개의 전문 에이전트: analyst, architect, code-reviewer, exploration, getter 등 역할별 분리
• 자동 파이프라인: plan → execute → verify → fix 루프를 시스템이 알아서 진행
• 36개+ 스킬: 자주 쓰는 작업 패턴을 스킬로 저장해 한 번에 실행

회사에서 팀원들이 역할을 나눠 일하듯, AI도 분야별로 전문화시키면 자기 분야에 집중하니까 품질이 올라간다는 발상입니다. 다만 한 가지 — 처음부터 풀 세팅으로 갈 필요는 없습니다. 프로젝트가 커지면서 하나씩 붙여 나가는 방식이 더 현실적이라는 게 영상 2의 권고입니다.

Part 5. 커스텀 하네스 — 4가지 기둥

영상 2가 직접 만든 가벼운 프레임워크는 네 부분으로 구성됩니다.

5.1 docs/ — 프로젝트의 뇌

여기에 프로젝트의 모든 컨텍스트가 들어갑니다. Fowler 분류로는 모두 **Guides(Feedforward)**입니다.

5.2 CLAUDE.md — 프로젝트 헌법

예시 규칙:

• "Anthropic SDK 사용 금지" (외부 라이브러리 제한)
• "API는 반드시 이 wrapper로 호출"
• "UI에는 AI slop 패턴 금지"

5.3 실행 엔진 — /harness 커맨드 + 파이프라인

/harness 슬래시 커맨드 하나로 다음이 자동화됩니다.

여기서 핵심 두 가지 개념이 등장합니다.

claude -p 헤드리스 모드 — 페이즈별 컨텍스트 분리

하나의 세션에서 모든 페이즈 돌리기 (X)
→ 컨텍스트가 누적되어 후반 페이즈 품질 저하

페이즈마다 claude -p 새 세션 (O)
→ 컨텍스트 분리, 일정한 품질 유지
→ 단점: 기억이 없으니 상태 관리 필수

JSON 상태 파일 — AI가 자기 진행을 읽을 수 있게

페이즈마다 결과·에러를 JSON으로 기록합니다. AI는 사람보다 JSON을 더 잘 읽고, 다음 세션이 이전 상태를 정확히 이어받을 수 있습니다.

5.4 Hooks — 자동 검증 게이트

Fowler 분류로는 **Sensors(Feedback)**입니다.

Part 6. FeedbackPulse 데모와 그 안의 두 메시지

영상 2의 후반부는 이 프레임워크로 **유튜브 댓글 분석 앱(FeedbackPulse)**을 만드는 과정을 실시간으로 보여줍니다. 핵심 워크플로만 정리하면 다음과 같습니다.

이 데모는 단순한 "AI로 앱 만들기" 시연이 아니라, 두 가지 묵직한 메시지를 품고 있습니다.

6.1 메시지 1: 기획이 결정한다 — Spec-Driven Development

이 메시지는 영상 2 혼자만의 통찰이 아닙니다. 같은 시기 업계는 비슷한 방향으로 움직이고 있었습니다 — vibe coding의 한계가 분명해지면서 **Spec-Driven Development(SDD)**가 프로페셔널 표준으로 자리 잡고 있었습니다. Red Hat을 비롯한 여러 출처가 같은 진단을 내립니다.

"Vibe coding은 프로토타입에는 좋지만 프로덕션에서는 무너진다.
코드가 아니라 스펙이 source of truth가 되어야 한다."

Karpathy의 강연 인용을 다시 꺼내봅니다.

"사람은 스펙과 계획에 대한 책임자여야 한다.
에이전트와 함께 매우 디테일한 스펙을 설계해라."

영상 2의 "기획에 20~30분, 5~6번 갈굼, 관점 바꿔 보강" 워크플로는 이 SDD 흐름을 한 사람의 작업 패턴으로 구체화한 것입니다.

한 번에 만족하지 마라 — 5~6번은 갈궈야 한다

영상 2의 인상적인 표현:

"AI는 많이 갈궈 줘야 좋은 계획을 더 많이 준다.
처음에는 '이 정도면 충분할 것 같다'고 했다가, '이건 어때? 저건 어때? 한 번 더 생각해 봐' 하면 더 좋은 계획을 준다.
한 5~6번은 갈궈야 된다."

관점을 바꿔서 보강하라

같은 문서도 관점을 바꿔서 다시 검토하게 시키면 매번 빠진 점이 새로 나옵니다.

극단까지 밀고 가면 사람이 개입하지 않아도 밤새 돌아가는 Ralph 루프(밤새 돌리는 자동화 루프)가 되고, 스펙을 마크다운이 아니라 JSON 구조로 작성하면 AI가 더 잘 읽고 상태 관리가 자동화됩니다 — 이것이 SDD의 심화 버전입니다.

6.2 메시지 2: AI 시대, 더 중요해지는 것은 "취향"

영상 2의 마지막 통찰이 가장 묵직합니다.

이 진단은 Karpathy의 "Jagged Intelligence"와 정확히 맞물립니다 — LLM이 검증 가능한 영역에서는 정점에 가깝지만 열린 추론에선 들쭉날쭉하다면, 그 들쭉날쭉한 빈 공간을 채우는 것이 결국 사람의 판단·취향이 됩니다.

패러다임의 전환

"코드를 매번 손으로 고치는 게 아니라, AI에게 주는 맥락의 품질을 최대로 올린 다음 가드레일을 깔고 — 그냥 출발하면 끝까지 갈 수 있도록 만드는 것. 그게 하네스 세팅의 본질이다."

같은 의미를 Fowler는 이렇게 말했습니다 — "좋은 하네스는 사람의 개입을 없애는 것이 아니라, 사람의 개입이 가장 중요한 곳에 그것을 집중시키는 것이다."

Epilogue. 파도를 탈 결정은 우리에게 있다

두 영상의 메시지를 한 줄씩 묶으면 이렇게 됩니다.

이 글이 남기는 체크리스트

AI Native 마인드셋 (영상 1 + Karpathy)

• 새 일이 떨어졌을 때, 손이 먼저 AI로 가는가? 아니면 의식적으로 "AI 써 볼까?" 망설이는가?
• 같은 프로젝트 컨텍스트를 매번 처음부터 다시 설명하고 있지는 않은가?
• 자주 쓰는 워크플로가 스킬·에이전트·프롬프트 템플릿으로 정리되어 있는가?
• Jagged Frontier를 의식하는가? AI에게 맡길 일과 맡기면 안 될 일을 가르고 있는가?

하네스 엔지니어링 실천 (영상 2 + Fowler)

• CLAUDE.md에 CRITICAL 신호로 표시한 프로젝트 헌법이 있는가? (Guide)
• docs/ 폴더에 PRD / Architecture / ADR이 모두 채워져 있는가? (Guide, 특히 MVP 제외 사항)
• TDD 강제 / 위험 명령 차단 / 서킷 브레이커 훅이 깔려 있는가? (Sensor)
• 기획 단계에서 5~6번 갈구고 관점 바꿔 보강하는 절차가 있는가? (Spec-Driven)
• 페이즈를 claude -p 헤드리스로 분리해 컨텍스트 누적을 막고 있는가?

출처 일괄

영상 (이 글의 출발점)

• 채널: 실밸 개발자
• 영상 1: AI Native가 되는 법
• 영상 2: 하네스 엔지니어링 — 직접 세팅하기

1차 자료 (수치·정의 출처)

• ChatGPT 8억 WAU: TechCrunch (Sam Altman 발표, 2025-10-06)
• 지식 노동자 75% AI 사용: Microsoft & LinkedIn 2024 Work Trend Index
• GitHub Copilot 55%: Microsoft Research, arXiv 2302.06590
• BCG/HBS 12% / 40% / Jagged Frontier: HBS Working Paper 24-013, Dell'Acqua et al. (2023)
• AI 채용 시장: LinkedIn Economic Graph — AI Skills Resources

외부 권위 (개념 보강)

• Andrej Karpathy, From Vibe Coding to Agentic Engineering (AI Ascent 2026)
• Martin Fowler, Harness Engineering for Coding Agents
• Vibe coding 한계 진단: Red Hat Developer — "The uncomfortable truth about vibe coding"
• Claude Code 시스템 프롬프트 분석: Nate's Substack — Surfing the Guardrails

오픈소스

• oh-my-claudecode — Yeachan Heo, 19 agents · 36 skills · 한국어 README