Anthropic의 코딩 에이전트 연구자 Eric이 바이브 코딩(AI에게 코드 작성을 전적으로 맡기는 방식)을 실제 서비스 환경에서 어떻게 안전하게 활용할 수 있는지를 다룬 발표입니다. 단순히 AI로 코드를 많이 생성하는 것과 바이브 코딩은 다르며, Andrej Karpathy의 정의처럼 “코드가 존재한다는 사실 자체를 잊는 것”이 핵심이라고 설명합니다. AI가 처리할 수 있는 작업 규모가 7개월마다 두 배로 늘고 있는 상황에서, 이 흐름을 활용하지 못하면 경쟁에서 뒤처질 수밖에 없다는 문제의식에서 출발합니다.

핵심 주장

• 바이브 코딩의 원칙은 “코드는 잊되, 제품은 잊지 말 것”입니다. 컴파일러가 생성한 어셈블리를 일일이 읽지 않듯, AI가 작성한 코드 자체보다 결과물의 품질과 정확성을 검증하는 데 집중해야 한다고 봅니다.
• 개발자의 역할이 직접 구현하는 사람에서 Claude의 프로덕트 매니저(PM)로 전환되어야 합니다. 신입 엔지니어에게 업무를 맡길 때처럼, 요구사항과 코드베이스 맥락, 제약조건을 충분히 정리해 AI에 전달하는 과정이 15~20분 이상 소요되더라도 그 투자가 성공률을 크게 높인다고 합니다.
• 바이브 코딩은 코드베이스의 리프 노드(다른 코드가 의존하지 않는 말단 기능)에 집중해야 합니다. 핵심 아키텍처나 다른 모듈이 의존하는 근간 코드는 여전히 사람이 깊이 이해하고 관리해야 합니다.
• 검증 가능성 설계가 필수적입니다. Anthropic 내부에서 22,000줄 규모의 강화학습 코드를 Claude로 작성해 프로덕션에 머지한 사례에서, 스트레스 테스트와 입출력 기반 검증 체크포인트를 설계해 코드를 전부 읽지 않고도 안정성과 정확성을 확인했다고 합니다.

현재의 한계

• 기술 부채(tech debt)는 코드를 직접 읽지 않고는 측정하거나 검증할 좋은 방법이 아직 없습니다. 이 점이 바이브 코딩을 리프 노드에 한정해야 하는 가장 큰 이유입니다.
• 비개발자가 보안이나 결제 같은 민감한 영역까지 바이브 코딩으로 프로덕션 시스템을 구축하는 것은 위험합니다. 올바른 질문을 던질 수 있는 기술적 판단력이 전제되어야 합니다.

차별점

• 바이브 코딩을 단순한 유행이 아닌 소프트웨어 산업의 구조적 전환으로 프레이밍하고, CTO가 전문가를 관리하거나 CEO가 회계사의 업무를 검증하는 것처럼 “구현을 모르면서도 결과를 검증하는 문제”는 문명만큼 오래된 과제라는 점을 짚은 것이 인상적입니다.

시사점

• 소프트웨어 엔지니어에게 요구되는 역량이 코드 한 줄 한 줄을 쓰는 능력에서, 요구사항을 정밀하게 정의하고 결과를 구조적으로 검증하는 능력으로 이동하고 있습니다. AI 도구의 성능 향상 속도를 고려하면, 이 전환에 적응하는 시점이 빠를수록 유리할 것으로 보입니다.

[출처] https://news.hada.io/topic?id=28824

Anthropic의 코딩 에이전트 연구자 Eric이 바이브 코딩(AI에게 코드 작성을 전적으로 맡기는 방식)을 실제 서비스 환경에서 어떻게 안전하게 활용할 수 있는지를 다룬 발표입니다. 단순히 AI로 코드를 많이 생성하는 것과 바이브 코딩은 다르며, Andrej Karpathy의 정의처럼 “코드가 존재한다는 사실 자체를 잊는 것”이 핵심이라고 설명합니다. AI가 처리할 수 있는 작업 규모가 7개월마다 두 배로 늘고 있는 상황에서, 이 흐름을 활용하지 못하면 경쟁에서 뒤처질 수밖에 없다는 문제의식에서 출발합니다.

핵심 주장

• 바이브 코딩의 원칙은 “코드는 잊되, 제품은 잊지 말 것”입니다. 컴파일러가 생성한 어셈블리를 일일이 읽지 않듯, AI가 작성한 코드 자체보다 결과물의 품질과 정확성을 검증하는 데 집중해야 한다고 봅니다.
• 개발자의 역할이 직접 구현하는 사람에서 Claude의 프로덕트 매니저(PM)로 전환되어야 합니다. 신입 엔지니어에게 업무를 맡길 때처럼, 요구사항과 코드베이스 맥락, 제약조건을 충분히 정리해 AI에 전달하는 과정이 15~20분 이상 소요되더라도 그 투자가 성공률을 크게 높인다고 합니다.
• 바이브 코딩은 코드베이스의 리프 노드(다른 코드가 의존하지 않는 말단 기능)에 집중해야 합니다. 핵심 아키텍처나 다른 모듈이 의존하는 근간 코드는 여전히 사람이 깊이 이해하고 관리해야 합니다.
• 검증 가능성 설계가 필수적입니다. Anthropic 내부에서 22,000줄 규모의 강화학습 코드를 Claude로 작성해 프로덕션에 머지한 사례에서, 스트레스 테스트와 입출력 기반 검증 체크포인트를 설계해 코드를 전부 읽지 않고도 안정성과 정확성을 확인했다고 합니다.

현재의 한계

• 기술 부채(tech debt)는 코드를 직접 읽지 않고는 측정하거나 검증할 좋은 방법이 아직 없습니다. 이 점이 바이브 코딩을 리프 노드에 한정해야 하는 가장 큰 이유입니다.
• 비개발자가 보안이나 결제 같은 민감한 영역까지 바이브 코딩으로 프로덕션 시스템을 구축하는 것은 위험합니다. 올바른 질문을 던질 수 있는 기술적 판단력이 전제되어야 합니다.

차별점

• 바이브 코딩을 단순한 유행이 아닌 소프트웨어 산업의 구조적 전환으로 프레이밍하고, CTO가 전문가를 관리하거나 CEO가 회계사의 업무를 검증하는 것처럼 “구현을 모르면서도 결과를 검증하는 문제”는 문명만큼 오래된 과제라는 점을 짚은 것이 인상적입니다.

시사점

• 소프트웨어 엔지니어에게 요구되는 역량이 코드 한 줄 한 줄을 쓰는 능력에서, 요구사항을 정밀하게 정의하고 결과를 구조적으로 검증하는 능력으로 이동하고 있습니다. AI 도구의 성능 향상 속도를 고려하면, 이 전환에 적응하는 시점이 빠를수록 유리할 것으로 보입니다.

[출처] https://news.hada.io/topic?id=28749

TL;DR;

• AI를 잘 쓰는 핵심 역량은 출력물의 품질을 판단하고 교정하는 능력이며, 이 능력은 AI에 의존할수록 오히려 약화됨
• Bjork의 “바람직한 어려움” 이론에 따르면, 쉽게 처리한 정보는 장기 기억에 남지 않음
• Roediger & Karpicke(2006) 연구에서 인출 연습 그룹의 일주일 후 기억 보존율이 반복 읽기 그룹보다 약 50% 높았음
• AI가 코드를 대신 작성하면 본질적 인지 부하(germane load) 까지 제거되어 스키마 형성 기회 자체가 사라짐
• 숙련된 개발자일수록 신경 효율성으로 인해 AI 출력을 읽는 것만으로는 뇌에 걸리는 부하가 거의 없음
• AI 이전에도 성장이 멈추는 경로는 존재했지만, AI는 그 경로의 마찰을 극적으로 제거함

상세 요약

AI를 잘 쓰려면 코드를 알아야 하는 역설

• “이걸 만들어줘”라고 말할 수 있는 사람은 많지만, AI 결과물을 보고 “이 구조는 변경에 취약하다”, “이 인터페이스는 두 가지 책임을
  가지고 있다”고 구체적으로 교정할 수 있는 사람은 훨씬 적음
• 이 능력은 수많은 실패와 디버깅과 리팩토링 경험에서 형성된 직감에 가까움
• AI 사용법 학습과 코드 패턴 학습은 양자택일 관계가 아니라, 후자가 전자의 토대인 관계임
• “AI를 가장 잘 활용할 수 있는 개발자는 AI 없이도 코드를 판단할 수 있는 개발자”

뇌는 편하면 기억하지 않는다

• Bjork의 “바람직한 어려움”: 학습 과정에 적절한 난이도와 저항이 존재할 때 단기 수행은 느려지지만 장기 기억 보존과 전이는 향상됨
• Roediger & Karpicke(2006): 반복 읽기 vs 인출 연습 실험
  • 5분 후 테스트: 반복 읽기 그룹 성적이 더 높음
  • 일주일 후 재테스트: 인출 연습 그룹의 기억 보존율이 약 50% 더 높음
• 능동적 인출 그룹은 해마–전두엽 피질 연결성이 강화되고 감각운동 네트워크 활성도 증가
• 수동 학습 상태의 뇌는 해마–방추상회 연결만 활성화 — “정보를 보고 있을 뿐 처리하지 않는 것”에 가까움
• 생성 효과 (Slamecka & Graf, 1978): “뜨거운-차___” 처럼 직접 완성한 그룹이 완성된 쌍을 읽은 그룹보다 기억 보존율이 유의미하게 높음
• 유창성의 착각: 정보를 쉽게 처리할 수 있다는 느낌이 잘 기억할 것이라는 착각으로 이어짐

코딩 실력은 절차 기억이다

• 코딩 실력의 상당 부분은 절차 기억 — 자전거 타기처럼 한번 체화되면 의식하지 않아도 자동 실행됨
• Anderson의 적응적 사고 통제(ACT) 모델: 절차 기억 형성 3단계
  • 인지 단계: 모든 것을 의식적으로 한 단계씩 실행, 작업 기억 대부분 소모
  • 연합 단계: 개별 절차들이 통합되어 하나의 흐름으로 실행 가능
  • 자동화 단계: 작업 기억 거의 차지하지 않고 자동 실행 — 남은 여유를 설계 판단에 활용 가능
• 단계 전환은 반복적인 직접 수행을 통해서만 진행됨
• 청킹 (Chase & Simon 체스 연구): 전문가와 초보자의 차이는 작업 기억 슬롯 수가 아니라, 하나의 청크에 담을 수 있는 정보의 양
  • 체스 고수는 말의 개별 위치가 아닌 “시실리안 디펜스의 전형적인 중반 배치” 같은 의미 있는 패턴을 하나의 청크로 인식
  • 무작위 배치 실험에서 고수와 초보자 차이가 사라짐으로써 입증됨

AI는 이 과정을 방해한다

• AI에게 구현을 맡기면 본질적 인지 부하(germane load) 까지 AI가 대신 처리 — 스키마 구축 기회 자체가 사라짐
• 절차 기억 관점: 인지 단계에서 끙끙대는 시간이 줄어 연합 단계 전환이 지연되고 자동화 단계 도달이 어려워짐
• AI 출력 코드를 읽는 것은 생성 효과 실험의 “완성된 단어 쌍을 읽는 것”에 해당 — 이해한 것 같지만 깊이 각인되지 않음
• 숙련된 개발자일수록 신경 효율성으로 코드를 더 적은 자원으로 처리 → AI 출력 읽기는 생각보다 뇌에 부하를 거의 걸지 않음
• 직접 코드를 짤 때는 예측–피드백 루프로 시냅스가 수정되지만, 완성된 AI 코드 읽기는 예측 과정이 생략된 사후 해석에 불과함
• 주니어에게 특히 심각: 인지 단계에 있는 패턴이 많은 상태에서 AI가 그 단계를 건너뛰게 하면 절차 기억 형성 없이 경력만 쌓임

뇌에 부하를 거는 방법

• AI에게 맡기기 전에 먼저 자신의 설계안 작성: 생성 효과를 의도적으로 활용 — AI 출력과 비교·평가하는 과정에서 뇌의 의미 처리와 실행
  제어 영역이 동시 활성화
• 진지한 코드 리뷰: “왜 이 구조인가”, “6개월 뒤에 수정한다면 어디가 문제가 될까”를 의식적으로 묻는 것 — 귀찮음 자체가 바람직한
  어려움
• 직접 코드를 짜보는 시간 확보: 절차 기억 형성에 대체 불가능 — 막혔을 때는 전체 답이 아닌 최소한의 힌트만 AI에게 요청
• 생산과 학습의 최적 전략은 다름: AI는 생산 도구로는 탁월하지만, 학습 도구로는 한계가 있음
• 결국 뇌에 남은 것들이 코드 리뷰의 질, 설계 판단의 정확도, 역설적으로 AI 활용 능력을 결정함

[출처] https://news.hada.io/topic?id=28653&utm_source=weekly&utm_medium=email&utm_campaign=202616

• 2022~2026년, AI 개발 패러다임이 세 번 전환됨: Prompt Engineering → Context Engineering → Harness Engineering
• 각 전환은 이전 패러다임이 약속을 지키지 못한 실패에서 비롯되었으며, 엔지니어링의 엄밀함은 사라진 것이 아니라 프롬프트에서 컨텍스트로, 컨텍스트에서 하네스로 위치를 옮겼을 뿐임
• [1시대] Prompt Engineering (2022~2024)
  • “영어가 곧 프로그래밍 언어”, “단계별로 생각하라”
  • 아무리 정교한 프롬프트도 컨텍스트 윈도우에 없는 파일은 모름
• [2시대] Context Engineering (2025)
  • “어떤 말을 해야 하나”에서 “어떤 정보를 넣어야 하나“로
  • 완벽한 컨텍스트를 구성해도, 그것을 소비하는 루프 자체가 잘못 설계되면 여전히 실패
• [2.5시대] 바이브 코딩과 그 숙취
  • diff도 안 보고 AI 제안을 전부 수락 – 코드가 읽을 수 있는 수준을 넘어서 자라남
  • “LLM이 코드를 썼더라도 당신이 리뷰했다면 그건 vibe coding이 아니다”
• [3시대] Harness Engineering (2026~)
  • “에이전트가 실수하면 에이전트가 아니라 하네스를 고쳐라“
  • 에이전트 = 모델 + 하네스
  • Anthropic 3-에이전트 아키텍처, Ralph 패턴, Lethal Trifecta, Meta AI의 Rule of Two
• 2026년 현재 핵심 메트릭은 프롬프트 품질이 아니라 KV-cache hit rate(모델이 이전 계산을 재활용하는 비율)와 하네스 복잡도로 전환됨
• 바이브 코딩(Vibe Coding)의 숙취, 에이전트의 자기 평가 불능, 보안 취약점 등 실제 프로덕션 장벽들이 각 시대의 한계를 증명했으며, 하네스는 이 모든 문제에 대한 구조적 대응임
• 각 시대는 이전 시대를 대체하지 않고 포함(subsume) 하며, 프롬프트 엔지니어링은 죽은 것이 아니라 하네스 엔지니어링의 서브모듈이 되었음
• 하네스는 뜯어낼 수 있어야(rippable) 함 — 모델이 발전하면 기존 에러 복구 로직의 절반이 불필요해짐
• 엄밀함의 다음 이동 방향: Guardian Agent(실시간 감시 레이어) → 평가 엔지니어링(behavior beats benchmarks) → 지식 엔진(코드 그래프·커밋 히스토리·메모리 결합)

• “하네스 구성해줘” 한 마디로 도메인에 맞는 전문 에이전트팀을 설계하고, 에이전트가 사용할 스킬까지 자동 생성해주는 메타 스킬
• 6가지 아키텍처 패턴을 지원하며, 에이전트 간 오케스트레이션과 에러 핸들링 프로토콜을 포함
• 아키텍처 패턴
  • 파이프라인: 순차 의존 작업
  • 팬아웃/팬인: 병렬 독립 작업
  • 전문가 풀: 상황별 선택 호출
  • 생성-검증: 생성 후 품질 검수
  • 감독자: 중앙 에이전트가 동적 분배
  • 계층적 위임: 상위→하위 재귀적 위임
• 6단계 워크플로우 : 도메인 분석 → 팀 아키텍처 설계(에이전트 팀 vs 서브 에이전트) → 에이전트 정의 생성 → 스킬 생성 → 통합 및 오케스트레이션 → 검증 및 테스트
• 실행 모드는 두 가지:
  • 에이전트 팀(기본): TeamCreate + SendMessage + TaskCreate 방식, 2개 이상 에이전트·협업 필요 시 권장
  • 서브 에이전트: Agent 도구 직접 호출, 단발성 작업·통신 불필요 시 적합
• 하네스 실행 시 .claude/agents/에 에이전트 정의 파일(예: analyst.md, builder.md, qa.md), .claude/skills/에 스킬 파일이 자동 생성됨
• 생성할 수 있는 팀 구성 예시
  • 딥 리서치 — 리서치 하네스를 구성해줘. 어떤 주제든 여러 각도에서 조사할 수 있는 에이전트 팀이 필요해 — 웹 검색, 학술 자료, 커뮤니티 반응 — 교차 검증 후 종합 보고서를 작성하는 팀.
  • 웹사이트 제작 — 풀스택 웹사이트 개발 하네스를 구성해줘. 디자인, 프론트엔드(React/Next.js), 백엔드(API), QA 테스트를 와이어프레임부터 배포까지 파이프라인으로 조율하는 팀.
  • 웹툰 제작 — 웹툰 에피소드 제작 하네스를 구성해줘. 스토리 작성, 캐릭터 디자인 프롬프트, 패널 레이아웃 기획, 대사 편집 에이전트가 필요하고 서로의 작업물을 스타일 일관성 관점에서 리뷰해야 해.
  • 유튜브 콘텐츠 기획 — 유튜브 콘텐츠 제작 하네스를 구성해줘. 트렌드 조사, 대본 작성, 제목/태그 SEO 최적화, 썸네일 컨셉 기획을 감독자 에이전트가 조율하는 팀.
  • 코드 리뷰 — 종합 코드 리뷰 하네스를 구성해줘. 아키텍처, 보안 취약점, 성능 병목, 코드 스타일을 병렬로 감사하는 에이전트들이 결과를 하나의 리포트로 통합하는 팀.
  • 기술 문서 작성 — 이 코드베이스에서 API 문서를 자동 생성하는 하네스를 구성해줘. 엔드포인트 분석, 설명 작성, 사용 예제 생성, 완성도 리뷰를 파이프라인으로 처리하는 팀.
  • 데이터 파이프라인 설계 — 데이터 파이프라인 설계 하네스를 구성해줘. 스키마 설계, ETL 로직, 데이터 검증 규칙, 모니터링 설정을 계층적으로 위임하는 에이전트 팀.
  • 마케팅 캠페인 — 마케팅 캠페인 제작 하네스를 구성해줘. 타겟 시장 조사, 광고 카피 작성, 비주얼 컨셉 디자인, A/B 테스트 계획을 반복적 품질 리뷰와 함께 진행하는 팀.
• revfactory/harness-100 — 10개 도메인, 100개의 프로덕션 레디 에이전트 팀 하네스(한영 200패키지) 공개
  • 각 하네스에 4-5명의 전문 에이전트, 오케스트레이터 스킬, 도메인 특화 스킬 포함
  • 콘텐츠 제작·소프트웨어 개발·데이터/AI·비즈니스 전략·교육·법률·헬스케어 등 1,808개 마크다운 파일로 구성
  • 모두 Harness 플러그인으로 생성됨
• 클로드 코드의 에이전트 팀 기능 활성화 필요: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

[출처] https://news.hada.io/topic?id=27969

• AI가 워크플로를 완전히 바꿔놓았고 생산성도 크게 높여줬지만, 매일 쓰다 보니 이제 더 이상 새로울 게 없는 일상이 됨
• Hacker News 등 개발자 커뮤니티가 거의 동일한 Claude Code 워크플로 자랑과 AI 도구 설정 이야기로 뒤덮여, 흥미로운 프로젝트와 문제 해결 논의가 밀려남
• 2023년에는 코드보다 제품 가치(Product Engineer) 에 집중하자는 흐름이 있었는데, 지금은 엔지니어링에서 가장 쉬운 부분을 더 쉽게 만드는 도구에 집착하는 방향으로 퇴보
• 경영진까지 AI에 올라타면서 개발자당 토큰 사용량 같은 무의미한 지표를 측정하기 시작, 과거 코드 줄 수 측정과 다를 바 없음
• 도구가 아니라 그 도구로 무엇을 만들고 있는지, 누군가에게 가치를 전달하는 진짜 목적을 이야기해야 함

AI 피로감: 놀랍지만 이제는 일상

• AI는 놀라운 기술이고 매일 사용하며 워크플로를 완전히 바꿔놓았지만, 일상적으로 쓰다 보니 더 이상 대화할 거리가 남지 않은 느낌
• 최근 새 역할을 맡아 까다로운 도메인에서 웹 스케일 작업을 시작했는데, AI 덕분에 몇 주 만에 생산성이 0에서 1로 올라감
• 변화의 속도가 빠른 건 맞지만, 하루하루 체감하는 수준에서는 루틴화된 상태

개발자 커뮤니티의 AI 편중

• Hacker News는 원래 흥미로운 프로젝트와 문제 해결로 가득했지만, 지금은 세 명이 올리는 거의 동일한 Claude Code 워크플로와 OpenClaw로 고양이 쓰다듬고 비디오 게임 하면서 절약한 시간으로 또 AI 도구를 설정한다는 포스트로 변질
• 이 현상이 자기 충족적(self-fulfilling) 순환 구조를 만들고 있음
• Kagi Small Web도 같은 현상의 예시로, ‘next’ 버튼을 20번 누르면 AI 관련 글이 얼마나 되는지 확인해볼 만함

Product Engineer에서 도구 집착으로의 퇴보

• 2023년, 누구든 Claude Code 터미널을 열 수 있는 사람을 ‘AI 엔지니어’라 부르기 전, ‘Product Engineer’ 가 가장 뜨거운 개념이었음
• 코드에 대한 집착에서 벗어나 제품이 전달하는 가치에 집중하자는 방향이었고, 매우 합리적이었음
• 하지만 지금은 코드 대신 과도하게 비대해진 자동완성 도구(overgrown auto-complete) 에 집착하는 상태로 퇴보
  • 엔지니어링에서 가장 쉬운 부분을 더 쉽게 만드는 데 몰두하는 꼴
• 목공 커뮤니티에 비유하면, 만든 테이블 사진을 올리던 곳에서 모두가 같은 망치를 같은 방식으로 쓰면서 망치 이야기만 소리치는 상황

경영진의 AI 개입과 무의미한 지표

• 과거 매니저들은 데이터베이스 기술, IDE, JavaScript 프레임워크에 관심이 없었고 기능 완성과 판매만 원했음
• 이번에는 경영진이 구현 세부사항에 직접 발을 들여놓기 시작
• 대부분의 개발자가 올해 목표에 ‘AI를 더 사용하라’ 는 회사 이니셔티브를 받았을 것
• 기존 경영진의 SDLC 개입은 DORA 메트릭스 등 산출물(faster deploys, time to respond) 중심이었지만, 지금은 개발자당 토큰 사용량을 측정하고 있음
  • 이는 과거 코드 줄 수(lines of code) 측정만큼이나 무의미한 지표

결론: 도구가 아니라 만드는 것을 이야기하자

• 사용하는 도구보다 그 도구로 만드는 멋진 결과물을 더 이야기해달라는 요청
• 코딩을 포함한 모든 크래프트의 본래 목적은 누군가에게 가치를 전달하는 것, 그 누군가가 자기 자신이더라도
• AI에 대한 글을 불평하는 글 자체가 AI에 대한 글이라는 아이러니를 인지하고 있음

[출처] https://news.hada.io/topic?id=27827