[태그:] Codex

Codex와 AI 코딩 도구, 에이전틱 개발, 자동화된 개발 워크플로를 다룬 글을 모았습니다. 개발자 생산성 변화 흐름을 살펴봅니다.

  • AI 스킬 만들기, 파일 3개로 시작하는 Claude·GPT 업무 자동화

    AI 스킬 만들기, 파일 3개로 시작하는 Claude·GPT 업무 자동화

    반복 업무를 AI에게 맡길 때마다 같은 설명을 다시 쓰고 있다면, 문제는 프롬프트 길이가 아니라 업무 구조일 수 있습니다. AI 스킬 만들기는 “좋은 문장 하나”를 찾는 일이 아니라, AI가 반복해서 꺼내 쓸 수 있는 업무 매뉴얼과 자료 묶음을 만드는 일에 가깝습니다.

    AI 스킬 만들기 핵심 질문: 프롬프트와 스킬은 무엇이 다른가
    출처: SURVIVAL AI 유튜브 영상 캡처. 프롬프트와 스킬의 차이를 설명하는 도입 장면입니다.

    AI 스킬 만들기는 프롬프트를 ‘업무 패키지’로 바꾸는 과정입니다

    영상의 핵심 비유는 명확합니다. 프로젝트 지시문은 레시피이고, 스킬은 밀키트입니다. 레시피만 있으면 요리 순서는 알 수 있지만 재료, 도구, 계량 기준은 따로 준비해야 합니다. 밀키트는 레시피와 재료, 필요한 도구와 기준이 한 묶음으로 들어 있습니다.

    AI 업무에서도 같은 차이가 생깁니다. 프로젝트 지시문은 특정 프로젝트 안에서 반복 지시를 적용하는 방식입니다. 반면 스킬은 대화창에서 해당 업무를 요청했을 때 AI가 알아서 관련 절차와 참고자료를 불러와 실행하도록 만드는 패키지입니다.

    프로젝트 지시문과 스킬의 차이

    프로젝트 지시문은 “이 프로젝트에서는 이렇게 일해”라는 텍스트 규칙에 가깝습니다. 회의록 정리 방식, 컨설팅 PPT 작성 방식, 보고서 구조를 프로젝트 안에 넣어두면 그 공간에서는 반복적으로 작동합니다.

    스킬은 범위가 다릅니다. 핵심 지시문뿐 아니라 참고자료, 템플릿, 검증 스크립트까지 함께 묶을 수 있습니다. 그래서 “이렇게 써라”가에 그치지 않고 “이 자료를 참고하고, 이 순서로 처리하고, 마지막에 이 기준으로 점검하라”까지 포함할 수 있습니다.

    AI 스킬 만들기 비유: 프로젝트 지시문은 레시피, 스킬은 밀키트
    프로젝트 지시문과 스킬의 차이를 레시피와 밀키트로 설명하는 장면입니다.

    왜 지금 AI 스킬이 중요해졌을까

    초기 AI는 질문 하나에 답 하나를 주는 챗봇에 가까웠습니다. 이메일 문장을 다듬거나 번역하거나 아이디어를 묻는 방식이 중심이었습니다.

    지금의 AI는 다릅니다. 여러 단계를 연결하고, 외부 시스템과 연동하고, 중간 판단을 하며, 사용자가 자리를 비운 동안에도 작업 흐름을 이어갈 수 있습니다. 이 변화 때문에 “질문을 예쁘게 쓰는 능력”만으로는 부족해졌습니다.

    프롬프트 엔지니어링의 역할도 바뀌었습니다

    AI의 언어 이해력이 좋아지면서 어설픈 표현도 어느 정도는 AI가 보정합니다. 하지만 좋은 결과가 자동으로 보장되는 것은 아닙니다. 먼저 볼 부분은 AI가 어떤 목표와 기준으로 판단해야 하는지 구조화하는 능력입니다.

    예를 들어 “이 주식 오를까?”라고 묻는 것과 “손실을 최소화하는 진입 전략을 세우고, 위험 신호와 분할 매수 기준을 제시하라”고 지시하는 것은 완전히 다른 결과를 만듭니다. 스킬은 이런 구조화된 판단 기준을 반복 가능한 형태로 저장하는 장치입니다.

    좋은 AI 스킬의 기본 구조

    영상에서 소개한 기본 구조는 단순합니다. 최상위 폴더 안에 핵심 파일인 SKILL.md가 있고, 필요에 따라 references/scripts/ 폴더를 둡니다. 파일이 3개 또는 3개 영역으로 정리된다는 설명은 바로 이 구조를 말합니다.

    AI 스킬 만들기 기본 구조: SKILL.md, references, scripts
    스킬 폴더와 핵심 파일 구조를 설명하는 장면입니다.

    SKILL.md는 스킬의 실행 설명서입니다

    SKILL.md는 스킬의 중심입니다. 언제 이 스킬을 써야 하는지, 어떤 순서로 작업해야 하는지, 어떤 결과물을 만들어야 하는지, 마지막에 무엇을 검증해야 하는지가 들어갑니다.

    이 파일 하나만 있어도 스킬은 작동할 수 있습니다. 주의할 점은 모든 내용을 한 파일에 몰아넣으면 AI가 중요한 지시를 놓칠 수 있습니다. 그래서 핵심 절차는 SKILL.md에 두고, 길고 세부적인 자료는 별도 폴더로 분리하는 것이 좋습니다.

    references는 필요할 때 꺼내 읽는 지식 창고입니다

    references/는 매번 읽을 필요는 없지만 특정 단계에서 참고해야 하는 문서를 보관하는 곳입니다. 예를 들어 도메인별 작성 패턴, 검토 기준, 예시 문서, 설치 가이드 등을 넣을 수 있습니다.

    먼저 볼 부분은 “필요할 때만 읽게 만드는 것”입니다. AI에게 항상 모든 자료를 읽게 하면 지시가 길어지고 집중도가 떨어질 수 있습니다. 반대로 필요한 순간에 정확한 참고자료를 열게 하면 결과의 일관성이 높아집니다.

    scripts는 반복 결과를 고정하는 자동화 도구입니다

    scripts/는 말로 지시하면 매번 달라지는 작업을 코드로 고정하는 영역입니다. 영상에서는 라면 끓이는 기계를 예로 듭니다. 사람이 말로만 지시하면 매번 조금씩 다르게 만들지만, 기계에 순서와 시간을 입력하면 결과가 일정해집니다.

    업무에서도 마찬가지입니다. PPT 색상과 위치, 파일 변환, 데이터 검증, 표준 포맷 검사처럼 결과가 일정해야 하는 작업은 스크립트로 고정하는 편이 좋습니다.

    스킬 생성기는 질문부터 시작해야 합니다

    좋은 스킬은 사용자의 요구를 먼저 확인합니다. AI가 성능이 좋아질수록 애매한 요청도 알아서 처리하려고 하지만, 업무 스킬은 오히려 단계별 확인이 더 봐야 합니다.

    영상의 예시인 스킬 생성기는 6단계 인터뷰로 시작합니다. 도메인을 확인하고, 세부 도메인을 분류하고, 고위험 영역인지 판단한 뒤, 스킬 이름과 설명, 워크플로우, 검토 기준을 차례로 정리합니다.

    AI 스킬 만들기 절차: 인터뷰 기반 스킬 생성 워크플로우
    스킬 생성기가 요구사항을 단계별로 확인하는 흐름을 설명하는 장면입니다.

    고위험 도메인은 사람 검토를 포함해야 합니다

    법무, 계약, 채용, 보안처럼 실수의 비용이 큰 영역은 AI가 그럴듯한 결과를 만들더라도 최종 검토가 해야 합니다. 좋은 스킬은 이런 위험을 숨기지 않습니다.

    오히려 “이 단계에서는 사람 검토가 필요하다”, “이 결과는 참고용이며 최종 판단은 담당자가 해야 한다”처럼 책임 경계를 명시해야 합니다. 그래야 스킬이 업무 효율을 높이면서도 위험을 키우지 않습니다.

    Claude와 GPT/Codex에서 스킬을 만드는 방법

    영상에서는 Claude와 GPT/Codex 양쪽의 실전 생성 방법도 소개합니다. Claude에서는 사용자 지정 메뉴의 스킬 영역에서 업로드하거나, Claude와 대화하며 스킬을 만들 수 있습니다. GPT/Codex에서는 스킬 및 앱 메뉴, 또는 스킬 크리에이터 흐름을 사용할 수 있습니다.

    Claude와 GPT Codex에서 AI 스킬 만들기 실전 메뉴
    Claude와 GPT/Codex에서 스킬을 생성하거나 업로드하는 방법을 안내하는 장면입니다.

    업로드보다 먼저 볼 부분은 검토입니다

    AI가 만들어 준 스킬이 보기에는 그럴듯해도, 그 분야를 전혀 모르면 좋은 스킬인지 판단하기 어렵습니다. 그래서 최소한 해당 업무의 기본 언어와 흐름은 알아야 합니다.

    좋은 방법은 이미 공개된 우수한 스킬이나 워크플로우를 참고하는 것입니다. GitHub나 공식 예시에서 비슷한 분야의 구조를 살펴보고, 내 업무에 맞게 변형하면 시행착오를 줄일 수 있습니다.

    AI 스킬 만들기 체크리스트

    점검 항목 확인 질문 실무 포인트
    목적 이 스킬이 해결할 반복 업무는 무엇인가? 한 문장으로 설명되지 않으면 범위가 넓을 수 있습니다.
    발동 조건 언제 이 스킬을 사용해야 하는가? “이런 요청이 오면 사용” 조건을 명확히 적습니다.
    입력 정보 사용자가 무엇을 제공해야 하는가? 누락 시 질문해야 할 항목을 정리합니다.
    실행 절차 어떤 순서로 처리해야 하는가? 단계별 워크플로우를 번호로 씁니다.
    참고자료 항상 필요한 자료와 가끔 필요한 자료는 무엇인가? 긴 자료는 references로 분리합니다.
    자동화 매번 같은 결과가 필요한 부분은 무엇인가? 변환·검증·생성은 scripts 후보입니다.
    검증 완료 전에 무엇을 확인해야 하는가? 결과물 품질 기준과 오류 대응을 넣습니다.
    위험 사람 검토가 필요한 영역은 어디인가? 법무·보안·채용·재무 등은 경고를 명시합니다.

    결론: 스킬은 AI 시대의 업무 자산입니다

    AI 스킬 만들기의 본질은 “내가 일하는 방식을 AI가 반복 실행할 수 있는 구조로 바꾸는 것”입니다. 남이 만든 스킬을 가져다 쓰는 것도 도움이 되지만, 직접 만들고 써 보고 고치면서 축적한 스킬은 쉽게 대체되지 않는 업무 자산이 됩니다.

    처음부터 완벽한 스킬을 만들 필요는 없습니다. 작은 반복 업무 하나를 고르고, SKILL.md로 핵심 절차를 정리하고, 필요한 자료를 references/로 분리하고, 반복 검증이 필요한 부분을 scripts/로 옮기면 됩니다. 먼저 볼 부분은 한 번에 끝내는 것이 아니라 실제 사용 후 수정하고 보완하는 반복입니다.

    FAQ

    AI 스킬 만들기와 프롬프트 작성은 무엇이 다른가요?

    프롬프트 작성은 한 번의 요청을 잘 쓰는 데 초점이 있습니다. AI 스킬 만들기는 반복 업무에 필요한 절차, 참고자료, 템플릿, 검증 기준을 묶어 AI가 계속 재사용하도록 만드는 데 초점이 있습니다.

    SKILL.md 하나만 있어도 스킬이 되나요?

    가능합니다. 주의할 점은 업무가 복잡해지면 참고자료와 스크립트를 분리하는 편이 좋습니다. 그래야 AI가 핵심 지시와 부가 자료를 구분하고 필요한 순간에만 추가 정보를 읽을 수 있습니다.

    AI가 만들어 준 스킬을 그대로 써도 되나요?

    간단한 개인 업무라면 바로 시험해 볼 수 있습니다. 하지만 법무, 보안, 채용, 재무처럼 위험이 큰 업무라면 반드시 사람 검토 단계를 넣어야 합니다. 또한 실제 사용 후 결과를 보며 계속 수정해야 합니다.

    어떤 업무부터 스킬로 만들면 좋을까요?

    반복 빈도가 높고 결과 형식이 비교적 일정한 업무가 좋습니다. 회의록 정리, 보고서 초안, 블로그 검수, 자료 변환, 체크리스트 기반 리뷰처럼 절차와 기준을 정의하기 쉬운 업무부터 시작하면 됩니다.

    참고자료

    함께 읽으면 좋은 글

  • 하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법

    하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법

    하네스 엔지니어링은 앞으로 AI 에이전트와 함께 일하는 사람에게 중요한 개념이 될 가능성이 높습니다. 지금까지 많은 사람은 “AI에게 어떻게 더 잘 말할 것인가”에 집중했습니다. 하지만 AI가 실제 코드를 만들고, 테스트하고, 수정하고, 보고하는 단계로 들어오면 질문이 달라집니다.

    이제 중요한 것은 “AI에게 무엇을 말할 것인가”만이 아닙니다. AI가 제대로 일할 수밖에 없는 환경을 어떻게 만들 것인가입니다.

    하네스 엔지니어링 도입부: 바이브 코딩에서 에이전틱 코딩으로
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    Read in English: This article is also available in English for global readers.

    이 글은 Jay Choi | 인디해커 라이프의 영상 「하네스 엔지니어링: 바이브 코딩에서 에이전틱 코딩으로」를 바탕으로, 바이브 코딩 이후 개발자가 어떤 방식으로 AI 에이전트를 다뤄야 하는지 정리한 글입니다. 관련 흐름은 이전 글 「에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식」과 함께 읽으면 더 잘 연결됩니다.

    하네스 엔지니어링이란 무엇인가

    하네스 엔지니어링은 AI 모델이나 에이전트가 움직이는 작업 환경 전체를 설계하는 일입니다. 여기서 말하는 환경은 단순한 채팅창이 아닙니다. 프로젝트 폴더 구조, 규칙 문서, 테스트 명령, 도구 목록, MCP, 스킬, 훅, 리뷰 절차, 자동 검증 흐름까지 포함합니다.

    프롬프트 엔지니어링이 “모델에게 잘해 달라고 말하는 기술”에 가깝다면, 하네스 엔지니어링은 “모델이 잘할 수밖에 없는 구조를 만드는 기술”에 가깝습니다.

    부탁이 아니라 구조를 만드는 일

    AI에게 “테스트까지 확인해 줘”라고 말할 수는 있습니다. 하지만 에이전트가 실제로 테스트를 실행했는지, 실패를 어떻게 해석했는지, 결과를 기준에 맞게 보고했는지는 별개의 문제입니다.

    하네스 엔지니어링은 이 지점을 구조로 해결하려고 합니다. 예를 들면 이렇게 볼 수 있습니다.

    • 작업이 끝나면 반드시 테스트 명령을 실행하게 한다.
    • 변경된 파일과 테스트 결과를 보고 양식에 맞춰 남기게 한다.
    • 위험한 명령은 실행 전 확인 절차를 거치게 한다.
    • 너무 많은 도구를 주지 않고, 작업 목적에 맞는 도구만 제공한다.
    • 프로젝트 규칙을 문서화해 에이전트가 항상 읽을 수 있게 한다.

    이런 구조가 있으면 매번 사람이 프롬프트로 잔소리하지 않아도 됩니다. 에이전트가 그 환경 안에서 자연스럽게 올바른 절차를 따르게 됩니다.

    바이브 코딩은 바닥을 올리고, 하네스 엔지니어링은 천장을 올린다

    영상의 핵심 표현 중 하나는 “바이브 코딩은 바닥을 올리고, 에이전틱 엔지니어링은 천장을 올린다”는 말입니다.

    바이브 코딩은 개발 경험이 적은 사람도 앱을 만들 수 있게 해 주었습니다. 자연어로 요구사항을 말하면 AI가 코드를 제안하고, 화면을 만들고, 오류를 고쳐 줍니다. 이 변화는 분명히 진입 장벽을 낮췄습니다.

    하지만 진입 장벽이 낮아졌다고 해서 좋은 소프트웨어가 자동으로 만들어지는 것은 아닙니다. 실제 서비스에서는 보안, 결제, 예외 처리, 유지보수, 테스트, 배포, 사용자 경험이 모두 더 봐야 합니다.

    하네스 엔지니어링이 중요한 이유와 2026년 AI 에이전트 흐름
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    코드 생성보다 검증이 더 어려워진다

    AI가 코드를 빠르게 만드는 시대에는 “코드를 작성하는 능력”보다 “코드가 쓸 만한지 판단하는 능력”이 더 더 봐야 합니다. AI가 그럴듯한 코드를 만들 수는 있지만, 그 코드가 실제 요구사항을 만족하는지 확인하는 책임은 여전히 사람과 시스템에 남습니다.

    하네스 엔지니어링은 바로 이 검증 문제를 다룹니다. 에이전트가 작업을 완료했다고 말할 때, 그 말만 믿지 않고 실제 실행 결과와 테스트 결과를 확인하게 만드는 것입니다.

    프롬프트를 더 길게 쓰는 것으로는 부족하다

    많은 사용자는 AI 결과가 마음에 들지 않으면 프롬프트를 더 자세히 씁니다. 역할을 부여하고, 예시를 넣고, “실수하지 말라”고 지시합니다. 물론 이런 방식도 도움이 됩니다.

    하지만 매번 사람이 개입해야 한다면 한계가 있습니다. 같은 유형의 실수를 반복해서 고쳐야 하고, 작업이 길어질수록 맥락이 흐려지며, 에이전트가 실제로 무엇을 했는지 확인하기 어렵습니다.

    하네스 엔지니어링은 프롬프트보다 실행 환경을 설계하는 접근
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    좋은 프롬프트보다 좋은 작업장

    영상에서는 프로젝트 전체가 하나의 거대한 프롬프트가 된다고 설명합니다. 에이전트는 채팅창의 문장만 읽는 것이 아닙니다. 폴더 구조, 파일 이름, README, 규칙 문서, 기존 코드 스타일, 테스트 파일, 설정 파일을 모두 참고합니다.

    정리된 프로젝트에서는 에이전트도 정리된 방식으로 일할 가능성이 높습니다. 반대로 프로젝트가 어지럽고 규칙이 없으면, 에이전트도 어지러운 결과를 만들기 쉽습니다.

    그래서 하네스 엔지니어링의 첫걸음은 거창한 자동화가 아닐 수 있습니다. 오히려 프로젝트를 정리하고, 규칙을 문서화하고, 반복 작업을 스크립트로 만들고, 검증 절차를 명확히 하는 것에서 시작됩니다.

    도구는 많을수록 좋은 것이 아니다

    AI 에이전트에게 많은 도구를 연결하면 더 강력해 보입니다. 검색, 터미널, 브라우저, 파일 편집, 배포, 데이터베이스, 메신저까지 모두 붙이면 무엇이든 할 수 있을 것처럼 느껴집니다.

    하지만 실제로는 도구가 너무 많으면 에이전트가 어떤 도구를 써야 할지 판단하는 데 에너지를 씁니다. 사람도 선택지가 많을수록 결정을 미루듯, AI도 불필요한 선택지 앞에서 흔들릴 수 있습니다.

    하네스 엔지니어링에서 도구 선택과 검증 구조의 중요성
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    작업별로 좁고 정확한 도구를 준다

    좋은 하네스는 모든 도구를 한꺼번에 열어 주지 않습니다. 작업 목적에 맞춰 필요한 도구만 제공합니다.

    예를 들어 코드 리뷰 에이전트라면 파일 읽기, diff 확인, 테스트 로그 분석이 더 봐야 합니다. 반면 배포 권한이나 외부 메시지 전송 권한은 필요하지 않을 수 있습니다. 데이터 수집 에이전트라면 웹 검색과 저장 도구는 필요하지만, 운영 서버 명령 권한은 제한하는 편이 안전합니다.

    도구를 줄이는 것은 성능을 낮추는 일이 아닙니다. 오히려 에이전트가 더 빠르게 판단하고, 실수할 표면을 줄이며, 사람이 신뢰할 수 있는 결과를 만드는 방법입니다.

    하네스 엔지니어링의 실무 체크리스트

    개발자는 AI 팀 리더가 된다

    하네스 엔지니어링을 실제 업무에 적용하려면 다음 항목부터 점검해 볼 수 있습니다.

    점검 항목 질문 예시
    목표 정의 에이전트가 끝내야 할 작업이 명확한가? “로그인 오류 수정”보다 “재현 절차 확인 후 테스트 통과까지”
    도구 제한 이 작업에 꼭 필요한 도구만 열려 있는가? 코드 수정 에이전트에 배포 권한 제외
    규칙 문서 프로젝트 규칙을 에이전트가 읽을 수 있는가? README, AGENTS.md, CLAUDE.md, 테스트 가이드
    검증 루프 작업 후 자동으로 확인하는 절차가 있는가? lint, unit test, build, smoke test
    보고 형식 결과를 사람이 판단하기 쉽게 남기는가? 변경 파일, 실행 명령, 실패/성공 로그 요약
    인간 판단 AI가 결정하면 안 되는 영역이 분리되어 있는가? 결제 정책, 환불 기준, 보안 예외, UX 우선순위

    이 표에서 중요한 것은 자동화 자체가 아닙니다. AI에게 맡길 일과 사람이 판단할 일을 분리하는 것입니다.

    영상의 마지막 메시지는 강합니다. 생각은 AI에게 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다는 것입니다.

    코드 작성, 분석, 리뷰 초안 작성은 AI가 점점 더 잘하게 됩니다. 하지만 왜 이 기능이 필요한지, 어떤 예외를 고려해야 하는지, 어떤 구조가 장기적으로 유지보수에 유리한지는 사람이 이해해야 합니다.

    하네스 엔지니어링 시대 개발자는 AI 팀 리더가 된다
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    직접 코딩하는 사람에서 작업 환경을 설계하는 사람으로

    앞으로 개발자의 역할은 “모든 코드를 직접 치는 사람”에서 “AI 에이전트 팀이 제대로 일하도록 환경을 만드는 사람”으로 이동할 가능성이 높습니다.

    이 변화는 개발자에게만 해당하지 않습니다. 기획자, 창업자, PM, 데이터 분석가도 마찬가지입니다. AI에게 일을 맡기려면 작업 기준, 검증 방법, 보고 방식, 권한 범위를 설계해야 합니다.

    결국 하네스 엔지니어링은 AI 시대의 협업 설계입니다. AI가 잘하는 실행은 AI에게 맡기되, 사람이 이해하고 책임져야 할 부분은 구조 안에 남겨 두는 방식입니다.

    결론: AI에게 “해줘”라고 말하는 시대의 다음 단계

    바이브 코딩은 많은 사람에게 만들기의 문을 열었습니다. 하지만 실제 결과물을 안정적으로 운영하려면 다음 단계가 해야 합니다. 그 단계가 하네스 엔지니어링입니다.

    좋은 하네스는 에이전트에게 자유를 주되, 방향과 경계를 함께 제공합니다. 필요한 도구만 주고, 프로젝트 규칙을 읽게 하며, 작업 후에는 테스트와 리뷰를 통과하게 만듭니다. 사람은 모든 중간 과정을 붙잡는 대신 최종 판단과 중요한 설계에 집중합니다.

    AI에게 “해줘”라고 말하는 것만으로는 충분하지 않습니다. 이제는 AI가 제대로 해낼 수 있는 환경을 설계해야 합니다. 하네스 엔지니어링은 바로 그 환경을 만드는 일입니다.

    참고자료

  • 에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식

    에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식

    에이전틱 엔지니어링은 바이브 코딩의 다음 단계입니다. 안드레이 카파시는 Sequoia Capital의 AI Ascent 2026 대담에서, 최신 AI 코딩 도구가 단순한 자동완성 수준을 넘어 개발자의 역할 자체를 바꾸고 있다고 설명합니다. 이제 중요한 질문은 “AI가 코드를 얼마나 빨리 쓰는가”가 아니라, “사람이 에이전트를 어떻게 지휘하고 검증할 것인가”입니다.

    에이전틱 엔지니어링 - 안드레이 카파시 대담 소개
    출처: 스테이지5 유튜브 「안드레이 카파시: 바이브 코딩에서 에이전틱 엔지니어링으로」 화면 캡처. 안드레이 카파시가 대담을 시작하는 장면입니다.

    왜 에이전틱 엔지니어링이 중요해졌나

    카파시는 자신이 “프로그래머로서 가장 뒤처진 느낌을 받았다”고 말합니다. 놀라운 말입니다. 그는 OpenAI 공동창업자였고, Tesla Autopilot 개발에도 참여한 인물입니다. 그런 개발자조차 최신 AI 코딩 도구의 변화 속도 앞에서 기존 감각이 흔들렸다고 말한 것입니다.

    2025년 말 이후의 전환점

    그가 짚은 전환점은 2025년 말입니다. 이전의 에이전트 도구는 코드 조각을 제안해 주는 보조 도구에 가까웠습니다. 사람이 자주 고쳐야 했고, 결과를 완전히 믿기는 어려웠습니다.

    하지만 어느 순간부터 최신 모델은 더 긴 코드 덩어리도 꽤 안정적으로 만들기 시작했습니다. 개발자는 직접 타이핑하는 시간을 줄이고, 요구사항을 설명하고, 결과를 검토하는 쪽으로 이동합니다. 이것이 바이브 코딩의 출발점입니다.

    Software 3.0은 무엇인가

    카파시는 이 변화를 Software 3.0이라는 개념으로 설명합니다. Software 1.0은 사람이 직접 작성한 코드입니다. Software 2.0은 데이터셋과 신경망 학습으로 만들어진 모델입니다. Software 3.0은 LLM이라는 인터프리터를 프롬프트와 컨텍스트로 조종하는 방식입니다.

    에이전틱 엔지니어링 - Software 3.0 설명
    출처: 스테이지5 유튜브 화면 캡처. Software 3.0과 프롬프트 기반 프로그래밍을 설명하는 구간입니다.

    코드는 파일에만 있지 않다

    Software 3.0에서는 코드만이 프로그램이 아닙니다. 프롬프트, 문서, 테스트, 예시, 오류 로그, 저장소 구조, 컨텍스트 윈도우까지 모두 프로그램의 일부가 됩니다. 개발자는 LLM이 해석할 수 있는 환경을 설계해야 합니다.

    이 관점에서는 “좋은 프롬프트”보다 “좋은 작업 맥락”이 더 더 봐야 합니다. 에이전트가 문제를 이해하고, 스스로 탐색하고, 실행 결과를 확인할 수 있어야 하기 때문입니다.

    바이브 코딩은 누구나 만들게 하지만, 실무는 다르다

    바이브 코딩은 아이디어를 빠르게 제품 형태로 바꾸는 방식입니다. 말로 요구사항을 설명하고, AI가 코드를 작성하게 하며, 결과물을 보면서 계속 수정합니다. 이 방식은 진입 장벽을 크게 낮춥니다.

    MenuGen 사례가 보여준 것

    카파시는 메뉴판 사진을 찍으면 음식 이미지를 붙여 보여주는 MenuGen 앱을 바이브 코딩으로 만들었습니다. 그런데 나중에는 Gemini와 이미지 생성 모델에 메뉴판 사진을 주고 바로 오버레이를 요청하는 방식이 더 자연스럽다는 점을 깨달았다고 말합니다.

    에이전틱 엔지니어링 - MenuGen 사례
    출처: 스테이지5 유튜브 화면 캡처. MenuGen 사례를 통해 기존 앱 구조가 Software 3.0 방식으로 바뀔 수 있음을 설명하는 장면입니다.

    이 사례는 중요한 질문을 던집니다. 앞으로 어떤 앱은 더 잘 만들어지는 것이 아니라, 아예 필요 없어질 수 있습니다. 사용자가 원하는 결과를 LLM과 생성 모델이 직접 만들어낸다면, 중간에 있던 많은 소프트웨어 계층이 사라질 수 있습니다.

    에이전틱 엔지니어링은 스펙과 검증의 기술이다

    카파시는 바이브 코딩과 에이전틱 엔지니어링을 구분합니다. 바이브 코딩이 빠른 구현의 감각이라면, 에이전틱 엔지니어링은 실무 시스템을 안전하게 만들기 위한 설계 방식입니다.

    사람이 여전히 책임져야 하는 영역

    AI 에이전트는 놀라운 속도로 코드를 작성하지만, 이상한 설계 실수도 합니다. 카파시는 결제 크레딧을 사용자 계정과 연결하는 예시를 듭니다. 에이전트가 Stripe 이메일과 Google 이메일을 그냥 맞춰 자금을 연결하려 했다는 것입니다.

    겉보기에는 그럴듯하지만, 실제 서비스에서는 치명적인 설계입니다. 사용자는 결제 이메일과 로그인 이메일을 다르게 쓸 수 있습니다. 이런 문제는 코드 문법이 아니라 도메인 이해, 데이터 모델, 보안, 제품 판단의 문제입니다.

    에이전틱 엔지니어링 - 바이브 코딩 이후의 실무 전환
    출처: 스테이지5 유튜브 화면 캡처. 바이브 코딩에서 에이전틱 엔지니어링으로 넘어가는 차이를 설명하는 구간입니다.

    그래서 사람은 스펙, 계획, 판단 기준, 테스트 전략을 책임져야 합니다. 에이전트는 구현을 많이 맡을 수 있지만, 무엇을 만들지와 왜 그렇게 만들어야 하는지는 사람이 설계해야 합니다.

    검증 가능한 환경이 AI 제품의 핵심 기회다

    카파시는 검증 가능성을 매우 중요하게 봅니다. 코드가 AI에 잘 맞는 이유도 여기에 있습니다. 실행해 볼 수 있고, 테스트할 수 있고, 오류 메시지를 받을 수 있습니다. 즉, 모델이 스스로 개선할 수 있는 피드백 루프가 있습니다.

    창업자는 무엇을 봐야 할까

    창업자에게 중요한 질문은 “AI로 무엇을 자동화할 수 있나”보다 더 구체적이어야 합니다. “검증 가능한 환경을 어떻게 만들 수 있나”가 핵심입니다. 정답 여부를 측정할 수 있고, 실패를 감지할 수 있으며, 개선 데이터를 쌓을 수 있는 영역이 강력한 기회가 됩니다.

    예를 들어 테스트 자동화, 보안 점검, 문서 검증, 데이터 정합성 검사, 운영 절차 자동화 같은 영역은 에이전트와 잘 맞습니다. 반대로 결과가 맞는지 판단하기 어렵고, 책임 소재가 불분명한 영역은 더 조심해야 합니다.

    AI 네이티브 개발자의 차이는 어디서 생기나

    AI 네이티브 개발자는 그냥 ChatGPT를 자주 쓰는 사람이 아닙니다. Claude Code, Codex, OpenClaw 같은 도구를 자기 작업 흐름에 맞게 세팅하고, 에이전트가 읽을 수 있는 문서와 구조를 준비합니다.

    생산성 차이는 타이핑 속도가 아니다

    이제 생산성 차이는 코드를 빨리 치는 능력에서만 나오지 않습니다. 문제를 잘게 나누는 능력, 좋은 스펙을 쓰는 능력, 테스트를 설계하는 능력, 결과물을 검증하는 능력에서 차이가 커집니다.

    카파시는 뛰어난 개발자가 AI 도구를 잡으면 10배를 넘어서는 생산성 차이가 날 수 있다고 봅니다. 이유는 간단합니다. 좋은 개발자는 에이전트가 놓치기 쉬운 맥락을 알고, 잘못된 방향을 빠르게 감지하며, 더 좋은 작업 환경을 설계할 수 있기 때문입니다.

    에이전트 퍼스트 인프라가 필요하다

    현재 많은 에이전트는 사람용 웹페이지와 설정 화면을 억지로 조작합니다. 버튼을 누르고, URL을 열고, 메뉴를 찾아갑니다. 카파시는 이런 방식이 비효율적이라고 지적합니다.

    에이전틱 엔지니어링 - 에이전트 퍼스트 인프라
    출처: 스테이지5 유튜브 화면 캡처. 에이전트가 사용하기 쉬운 인프라와 데이터 구조의 필요성을 설명하는 장면입니다.

    사람용 UI와 에이전트용 인터페이스는 다르다

    앞으로 서비스는 사람에게 보기 좋은 UI뿐 아니라, 에이전트가 이해하고 실행하기 쉬운 인터페이스를 제공해야 합니다. 명확한 API, 기계가 읽기 쉬운 문서, 구조화된 설정, 자동 검증 가능한 작업 단위가 더 봐야 합니다.

    이 변화는 개발 도구에만 국한되지 않습니다. 클라우드, 결제, 데이터베이스, 배포, 보안, 고객지원 도구까지 모두 에이전트 친화적으로 재설계될 가능성이 높습니다.

    결론: 개발자는 사라지는 것이 아니라 역할이 올라간다

    카파시의 메시지는 개발자의 종말론과 다릅니다. 그는 사람이 여전히 이해와 판단을 담당한다고 봅니다. 주의할 점은 직접 코드를 쓰는 비중은 줄고, 에이전트를 지휘하고 검증하는 비중이 커집니다.

    에이전틱 엔지니어링 시대의 개발자는 구현자이면서 동시에 감독자입니다. 좋은 개발자는 코드를 많이 쓰는 사람에서, 좋은 문제 정의와 검증 가능한 환경을 설계하는 사람으로 이동합니다.

    지금 필요한 준비는 거창하지 않습니다. 작은 프로젝트부터 에이전트에게 맡길 수 있는 작업과 사람이 직접 판단해야 하는 작업을 구분해 보아야 합니다. 그리고 문서, 테스트, 스펙, 배포 절차를 에이전트가 이해할 수 있게 정리해야 합니다. 그것이 바이브 코딩 이후의 실무 경쟁력입니다.

    FAQ

    에이전틱 엔지니어링은 바이브 코딩과 무엇이 다른가요?

    바이브 코딩은 AI와 대화하며 빠르게 구현하는 방식에 가깝습니다. 에이전틱 엔지니어링은 실무 시스템을 만들기 위해 스펙, 테스트, 보안, 검증, 운영까지 포함해 에이전트를 지휘하는 방식입니다.

    Software 3.0은 코딩을 대체한다는 뜻인가요?

    완전한 대체라기보다 코딩의 단위가 바뀐다는 뜻에 가깝습니다. 코드뿐 아니라 프롬프트, 문서, 컨텍스트, 테스트가 개발의 핵심 재료가 됩니다.

    개발자는 무엇을 준비해야 하나요?

    AI 도구 사용법만 익히는 것으로는 부족합니다. 요구사항을 명확히 쓰는 능력, 테스트를 설계하는 능력, 결과를 검증하는 능력, 에이전트가 이해하기 쉬운 문서를 만드는 능력을 함께 길러야 합니다.

    참고자료

    함께 읽으면 좋은 글