[태그:] Cursor

  • 바이브 코딩 입문자가 막히는 이유, 코딩보다 먼저 알아야 할 IT 지도

    바이브 코딩 입문자가 막히는 이유, 코딩보다 먼저 알아야 할 IT 지도

    바이브 코딩은 코딩 입문자의 출발선을 크게 낮췄습니다. Cursor나 Claude 같은 AI 도구에 원하는 기능을 말하면 코드가 빠르게 만들어집니다. 문제는 그다음입니다. 파일이 어디에 저장되는지, 서버는 왜 필요한지, API 오류는 무엇을 뜻하는지 모르면 AI가 만든 결과 앞에서 다시 멈춥니다.

    바이브 코딩 필수 IT 지식 도입 화면
    출처: 기술노트with 알렉 YouTube 영상 캡처. 바이브 코딩 필수 IT 지식의 전체 흐름을 소개하는 장면입니다.

    바이브 코딩은 도구보다 구조 이해가 먼저다

    AI가 코드를 대신 작성해 주는 시대에도 개발의 기본 구조는 사라지지 않습니다. 오히려 초보자는 더 넓은 지도를 알아야 합니다. AI가 만든 코드가 화면에 관한 것인지, 서버에 관한 것인지, 데이터 저장에 관한 것인지 구분해야 수정 요청도 정확해집니다.

    AI가 코드를 만들어도 판단은 사람이 한다

    바이브 코딩의 먼저 볼 부분은 “문법을 모두 외우지 않아도 만들 수 있다”는 점입니다. 하지만 AI의 답이 항상 프로젝트 상황에 맞는 것은 아닙니다. 사용자는 최소한 다음 질문에 답할 수 있어야 합니다.

    • 이 코드는 프런트엔드 코드인가, 백엔드 코드인가?
    • 지금 오류는 실행 환경 문제인가, 문법 문제인가?
    • 만든 결과를 내 컴퓨터에서만 볼 것인가, 인터넷에 배포할 것인가?
    • 데이터는 파일에 저장되는가, 데이터베이스에 저장되는가?

    이 질문에 답할 수 있으면 AI에게 다시 물어볼 때도 훨씬 구체적으로 지시할 수 있습니다.

    ChatGPT, Claude, Cursor는 같은 역할이 아니다

    ChatGPT나 Gemini는 질문하고 답을 받는 대화형 AI로 이해하면 쉽습니다. 반면 Cursor는 코드 편집기와 AI가 결합된 개발 환경에 가깝습니다. Claude도 단순 대화뿐 아니라 개발 보조 도구와 연동되어 코드 작업에 활용됩니다.

    바이브 코딩 Cursor IDE 설명 화면
    출처: 기술노트with 알렉 YouTube 영상 캡처. Cursor 같은 IDE형 AI 도구를 설명하는 장면입니다.

    IDE는 코드를 다루는 작업실이다

    IDE는 Integrated Development Environment의 줄임말입니다. 한국어로는 통합 개발 환경입니다. 코드를 작성하고, 파일을 관리하고, 실행이나 빌드까지 연결하는 작업실이라고 보면 됩니다. Visual Studio Code, Cursor 같은 도구가 예로 들 수 있습니다.

    바이브 코딩을 시작하는 사람은 “AI 도구를 고르는 일”과 “개발 환경을 이해하는 일”을 분리해야 합니다. 어떤 AI를 쓰든 결국 코드는 파일로 남고, 그 파일은 개발 환경 안에서 수정되고 실행됩니다.

    프롬프트보다 컨텍스트가 중요하다

    초기 AI 활용법은 프롬프트를 잘 쓰는 데 집중했습니다. 이제는 컨텍스트가 더 더 봐야 합니다. 컨텍스트는 AI가 판단하는 데 필요한 전후 상황입니다. 프로젝트 목적, 현재 파일 구조, 에러 메시지, 원하는 출력 형태를 함께 알려주면 AI의 답변 품질이 올라갑니다.

    예를 들어 “로그인 기능 만들어줘”보다 “React 프런트엔드와 FastAPI 백엔드가 있고, JWT 방식으로 로그인하려 한다. 현재 오류는 401이다”라고 말하는 편이 낫습니다. AI는 상황을 알 때 더 정확하게 움직입니다.

    소스와 GitHub를 모르면 AI가 만든 코드를 잃어버린다

    AI가 만든 결과물은 결국 소스 코드입니다. Java, Python, JavaScript, HTML 같은 언어로 된 파일입니다. 이 파일을 어디에 두고, 어떻게 바뀌었는지 관리하는 체계가 해야 합니다.

    바이브 코딩 GitHub와 소스 관리 설명 화면
    출처: 기술노트with 알렉 YouTube 영상 캡처. GitHub를 통한 프로젝트별 소스 관리 설명 장면입니다.

    Git은 변경 이력, GitHub는 협업 공간이다

    Git은 코드 변경 이력을 관리하는 도구입니다. GitHub는 그 코드를 온라인 저장소에 올리고 프로젝트 단위로 관리하는 서비스입니다. 초보자에게 Git은 처음에 어렵게 느껴집니다. 그래도 최소한 저장소, 커밋, 브랜치, 푸시 개념은 알아두는 편이 좋습니다.

    바이브 코딩에서 GitHub가 중요한 이유는 분명합니다. AI가 코드를 잘못 바꿨을 때 이전 상태로 돌아갈 수 있습니다. 다른 컴퓨터에서도 같은 프로젝트를 이어서 작업할 수 있습니다. 협업하거나 외주 개발을 맡길 때도 기준 파일을 공유할 수 있습니다.

    빌드와 실행은 “코드가 서비스가 되는 과정”이다

    소스 코드는 그 자체로 끝이 아닙니다. 어떤 언어와 환경에서는 컴파일이나 빌드 과정을 거쳐 실행 가능한 형태가 됩니다. 웹 프로젝트에서는 라이브러리와 설정 파일이 함께 묶여 배포 가능한 결과물로 만들어집니다.

    AI가 “빌드 오류”를 말할 때는 코드 문법만의 문제가 아닐 수 있습니다. 라이브러리 버전, 환경 변수, 실행 명령어, 폴더 위치도 영향을 줍니다. 그래서 바이브 코딩 입문자는 코드를 읽는 능력보다 먼저 프로젝트 구조를 보는 눈을 키워야 합니다.

    프런트엔드와 백엔드를 구분하면 오류가 절반은 줄어든다

    프런트엔드는 사용자가 보는 화면을 만드는 영역입니다. 웹 화면, 앱 화면, 버튼, 입력창, 목록, 디자인이 여기에 들어갑니다. React, React Native, Flutter 같은 도구가 자주 언급됩니다.

    백엔드는 화면 뒤에서 데이터를 처리한다

    백엔드는 서버에서 실행되는 프로그램입니다. 로그인, 게시글 저장, 결제 처리, 데이터 조회 같은 기능을 담당합니다. Spring Boot, Node.js, FastAPI 같은 프레임워크가 백엔드 개발에 많이 쓰입니다.

    바이브 코딩으로 앱을 만들 때 “화면은 보이는데 저장이 안 된다”면 프런트엔드만 볼 일이 아닙니다. 백엔드 API, 서버 실행 상태, 데이터베이스 연결까지 함께 체크해 두세요.

    바이브 코딩 백엔드와 서버 개념 설명 화면
    출처: 기술노트with 알렉 YouTube 영상 캡처. 백엔드와 서버 프로그램의 역할을 설명하는 장면입니다.

    웹과 앱은 서버를 통해 데이터를 주고받는다

    사용자가 보는 화면은 클라이언트입니다. 클라이언트는 서버에 요청을 보내고, 서버는 필요한 데이터를 찾아 응답합니다. 이 구조를 이해하면 “내 컴퓨터에서는 되는데 다른 사람은 접속이 안 된다”는 문제도 더 쉽게 이해됩니다.

    내 컴퓨터에서만 실행되는 상태는 로컬호스트입니다. 실제 서비스로 쓰려면 서버나 클라우드에 올려야 합니다. Cloudflare Pages, Vercel, AWS 같은 서비스는 이 배포 과정을 돕는 선택지입니다.

    서버, 포트, API, 데이터베이스는 배포 이후의 기본 언어다

    서버 프로그램은 특정 포트와 함께 실행됩니다. 웹 서버는 80번이나 443번 포트와 연결되는 경우가 많습니다. 개발 중에는 3000, 5000, 8000 같은 포트를 자주 보게 됩니다. 포트는 같은 서버 안에서 어떤 프로그램으로 갈지 알려주는 번호라고 이해하면 됩니다.

    URL과 HTTP는 요청의 주소와 약속이다

    사용자가 웹 주소를 입력하면 브라우저는 HTTP 또는 HTTPS라는 약속으로 서버에 요청을 보냅니다. 서버는 요청을 처리한 뒤 HTML, JSON, 이미지 같은 응답을 돌려줍니다. 이 과정이 반복되면서 웹 서비스가 동작합니다.

    바이브 코딩 도중 “CORS 오류”, “404”, “500”, “connection refused” 같은 메시지를 만나면 당황하기 쉽습니다. 하지만 대부분은 주소, 포트, 서버 실행 여부, API 경로, 권한 문제로 좁혀 볼 수 있습니다.

    API는 화면과 서버가 대화하는 통로다

    API는 클라이언트와 서버가 데이터를 주고받는 약속입니다. GET은 데이터를 가져올 때, POST는 새 데이터를 보낼 때, PUT은 수정할 때, DELETE는 삭제할 때 자주 사용됩니다. 응답 형식으로는 JSON이 많이 쓰입니다.

    바이브 코딩 API와 데이터베이스 설명 화면
    출처: 기술노트with 알렉 YouTube 영상 캡처. API, JSON, 데이터베이스 개념을 설명하는 장면입니다.

    데이터베이스는 실제 데이터를 저장하는 공간입니다. MySQL, MongoDB 같은 이름을 자주 보게 됩니다. SQL은 데이터베이스에 데이터를 조회하거나 수정하라고 요청하는 언어입니다. 회원 관리, 게시판, 주문 내역처럼 저장이 필요한 기능은 데이터베이스를 피하기 어렵습니다.

    바이브 코딩 입문자가 먼저 익히면 좋은 순서

    모든 기술을 한 번에 공부할 필요는 없습니다. 대신 막히는 지점을 줄이기 위해 다음 순서로 익히면 좋습니다.

    순서먼저 볼 개념왜 필요한가
    1IDE와 파일 구조AI가 만든 코드가 어디에 있는지 알아야 합니다.
    2Git과 GitHub변경 이력을 남기고 이전 상태로 복구할 수 있습니다.
    3프런트엔드와 백엔드화면 문제와 서버 문제를 구분할 수 있습니다.
    4로컬호스트와 포트내 컴퓨터 실행과 외부 접속 문제를 이해할 수 있습니다.
    5API와 JSON화면과 서버가 데이터를 주고받는 방식을 알 수 있습니다.
    6데이터베이스와 SQL저장되는 데이터의 흐름을 이해할 수 있습니다.
    7클라우드 배포만든 결과를 실제 서비스로 공개할 수 있습니다.

    이 순서를 따라가면 “AI에게 무엇을 물어봐야 하는지”가 선명해집니다. 바이브 코딩은 AI에게 모든 것을 맡기는 방식이 아니라, AI와 함께 개발 흐름을 빠르게 통과하는 방식에 가깝습니다.

    FAQ

    바이브 코딩을 하려면 프로그래밍 언어부터 배워야 하나요?

    언어 문법을 깊게 외우는 것보다 개발 구조를 먼저 이해하는 편이 실용적입니다. 주의할 점은 JavaScript, Python, HTML 같은 기본 이름과 역할은 알아두어야 AI의 답변을 점검할 수 있습니다.

    Cursor만 쓰면 GitHub를 몰라도 되나요?

    그렇지 않습니다. Cursor는 코드를 작성하고 수정하는 작업 환경입니다. GitHub는 코드 이력과 저장소를 관리하는 공간입니다. 둘은 역할이 다릅니다.

    로컬호스트와 서버는 무엇이 다른가요?

    로컬호스트는 내 컴퓨터에서만 실행되는 환경입니다. 서버는 다른 사용자도 접속할 수 있도록 네트워크에 연결된 실행 환경입니다. 배포는 로컬에서 만든 결과를 서버나 클라우드로 옮기는 과정입니다.

    API를 꼭 알아야 하나요?

    화면만 만드는 간단한 실험이라면 몰라도 됩니다. 하지만 로그인, 게시판, 결제, 데이터 저장처럼 실제 서비스 기능을 만들려면 API 개념은 반드시 해야 합니다.

    마무리: AI 코딩의 속도는 기본 개념 위에서 나온다

    바이브 코딩은 코딩을 쉽게 만들어 줍니다. 하지만 쉬워졌다는 말이 기본 구조가 사라졌다는 뜻은 아닙니다. AI가 코드를 생성할수록 사람은 더 좋은 질문을 해야 하고, 결과가 어디에서 막혔는지 판단해야 합니다.

    처음부터 모든 기술을 완벽히 알 필요는 없습니다. IDE, GitHub, 프런트엔드, 백엔드, 서버, API, 데이터베이스의 관계만 잡아도 시행착오가 크게 줄어듭니다. 그 지도가 있어야 AI가 만든 코드를 내 서비스로 연결할 수 있습니다.

    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가 제대로 해낼 수 있는 환경을 설계해야 합니다. 하네스 엔지니어링은 바로 그 환경을 만드는 일입니다.

    참고자료