https://ai.23yellow.com/ai_Engineering_01 ko AI 엔지니어링 (2026-09-01 11:32:06) https://ai.23yellow.com/ai_Engineering_01/%ED%97%A4%EB%A5%B4%EB%A9%94%EC%8A%A4-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%EB%B4%87-%EB%AA%A8%EB%93%9C%EB%A1%9C-ai-%EC%A7%81%EC%9B%90%EC%9D%84-%EA%B3%A0%EC%9A%A9%ED%95%B4%EB%B4%A4%EC%8A%B5%EB%8B%88%EB%8B%A4/ 얼마 전 헤르메스 에이전트에 '봇 모드'라는 기능이 정식으로 들어왔습니다. 한 문장으로 정리하면 — 역할이 다른 AI 봇들을 메신저 친구 목록처럼 등록해두고, 팀으로 굴리는 기능입니다. 각자 다른 성격과 업무를 가진 봇들이 서로 일을 넘기고, 단톡방에서 회의하고, 중요한 결정은 나에게 물어봅니다. 이번 영상에서는 뉴스를 수집하는 리서처, 뉴스레터를 쓰는 에디터, 팩트체크하는 검수자 — AI 직원 3명을 실제로 채용해서 뉴스레터 팀을 만드는 전 과정을 보여드립니다. 봇 생성부터 성격 설정(SOUL.md), 매일 아침 자동 출근(크론잡), @멘션으로 일 넘기기, 그리고 하이라이트인 단톡방 편집 회의까지 — 전부 실제 화면으로 진행합니다. 시연은 별도 API 키 없이 ChatGPT 구독 로그인만으로 진행했고, 사용한 설정 전부를 가이드 문서로 정리해뒀습니다. 시연은 ChatGPT Plus 구독, macOS 데스크톱 앱 기준입니다. ▶ 이번 영상에서 배우는 핵심 내용 봇 모드가 뭔가요 — 프로필을 AI 직원 명단으로 바꾸는 기능 설치와 연결 — 데스크톱 앱 설치, ChatGPT 구독으로 로그인 봇 만들기 — 이름·직함·설명 3칸으로 10초 채용 SOUL.md — 봇에게 성격과 글 스타일을 입히는 '영혼 파일' Advanced 설정 — 프로필 복제, 봇마다 다른 모델 지정 크론잡 — 매일 아침 8시, 알아서 출근하는 봇 만들기 @멘션 — 봇들끼리 업무를 주고받는 방법 그룹챗 — AI 셋의 단톡방 회의, 그리고 중요한 결정은 나에게]]> 최고관리자 2026-09-01T11:32:06+09:00 https://ai.23yellow.com/ai_Engineering_01/%ED%97%A4%EB%A5%B4%EB%A9%94%EC%8A%A4-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%EC%93%B0%EB%A9%B4-%EC%93%B8%EC%88%98%EB%A1%9D-%EB%98%91%EB%98%91%ED%95%B4%EC%A7%91%EB%8B%88%EB%8B%A4-%EC%8A%A4%EC%8A%A4%EB%A1%9C-%EC%A7%84%ED%99%94%ED%95%98%EB%8A%94-ai/ Details 헤르메스 에이전트(Hermes Agent)! 직접 구축하고 실제 업무까지 돌려봤습니다. 기존 클로드 코드와 무엇이 다른지부터, 지속형 메모리와 스스로 반복 작업을 스킬로 만드는 자가 개선구조 까지 쉽게 설명합니다. 비개발자도 따라올 수 있도록 VPS에 헤르메스 에이전트를 24시간 구동하는 과정부터 모델 설정, Docker 환경, Discord 연결까지 직접 세팅합니다. 여기서 끝이 아니라 예약 작업(Cron Job), VS Code SSH 원격 연결, Kanban 기반 멀티 에이전트까지 연결해서 실제 업무가 어떻게 자동으로 흘러가는지도 보여드립니다. 단순히 설치만 해보는 영상이 아니라, 헤르메스 에이전트가 정말 내 업무에 필요한지, 그리고 쓸수록 내 맥락을 학습하는 시스템을 어떻게 만들 수 있는지 궁금하셨다면 이번 영상에서 확인해보세요!]]> 최고관리자 2026-08-30T23:32:26+09:00 https://ai.23yellow.com/ai_Engineering_01/%EB%A3%A8%ED%94%84-%EB%82%98%EC%98%A8%EC%A7%80%EB%8F%84-%EC%96%BC%EB%A7%88-%EC%95%88-%EB%90%90%EB%8A%94%EB%8D%B0-%EA%B7%B8%EB%9E%98%ED%94%84-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-5%EB%B6%84%EB%A7%8C%EC%97%90/ 그래프 엔지니어링 상세 정리 > **원본 영상:** [루프 나온지도 얼마 안 됐는데 그래프 엔지니어링? 5분만에 쉽게 설명해드림.](https://www.youtube.com/watch?v=BtM2JZCMtL8) > **채널:** ZeroCho TV > **게시일:** 2026년 7월 28일 > **영상 길이:** 18분 46초 > **핵심 주제:** 루프 엔지니어링과 그래프 엔지니어링의 관계, 도입 시점, 상태 관리, LangGraph 기반 구현 개념 > **광고 안내:** 영상 중간에 Hostinger VPS 협찬 구간이 포함되어 있습니다. *** ## 1\. 영상의 핵심 메시지 이 영상은 최근 등장한 \*\*그래프 엔지니어링(Graph Engineering)\*\*이라는 표현을 소개하면서, 이것이 완전히 새로운 기술은 아니라고 설명합니다. 영상의 관점을 한 문장으로 정리하면 다음과 같습니다. > **루프가 단순할 때는 프롬프트나 반복문으로 충분하지만, 작업·조건 분기·병렬 처리·상태가 많아져 사람이 흐름을 머릿속으로 추적하기 어려워지면 노드와 엣지로 명시적인 그래프를 설계해야 한다.** 그래프 엔지니어링은 AI에게 단순히 “완료할 때까지 반복하라”고 요청하는 방식보다 한 단계 더 구조적입니다. * 각 작업 단계를 \*\*노드(Node)\*\*로 정의합니다. * 다음 단계로 이동하는 조건을 \*\*엣지(Edge)\*\*로 연결합니다. * 모든 단계가 공유하는 데이터를 \*\*상태(State)\*\*로 표준화합니다. * 실행 위치를 저장해 중단된 작업을 **체크포인트에서 재개**합니다. * 작업 성격에 따라 AI, 일반 프로그램, 사람을 적절한 노드에 배치합니다. 영상은 이러한 방식이 LangGraph 같은 도구를 통해 이미 구현되어 왔으며, ‘그래프 엔지니어링’이라는 이름만 최근에 새롭게 주목받은 것이라고 설명합니다. *** ## 2\. ‘그래프 엔지니어링’이라는 용어에 대한 영상의 입장 영상은 그래프 엔지니어링이라는 말이 기존 AI 엔지니어링 용어가 너무 자주 바뀌는 현상을 풍자하는 농담에서 시작됐다고 설명합니다. 영상이 제시하는 흐름은 다음과 같습니다. 1. 프롬프트 엔지니어링 2. 컨텍스트 엔지니어링 3. 하네스 엔지니어링 4. 루프 엔지니어링 5. 그래프 엔지니어링 처음 표현을 확산시킨 사람들은 “아직도 루프 엔지니어링을 이야기하느냐, 이제 그래프로 넘어가야 한다”는 식으로 빠르게 바뀌는 용어를 풍자했지만, 영향력 있는 인물들의 말이 진지하게 받아들여지면서 강의와 로드맵이 만들어졌다고 설명합니다. 영상에서는 다음과 같은 과장된 주장과 출처가 불명확한 정보가 함께 확산됐다고 지적합니다. * 특정 기업이 기존 기술을 그래프 엔지니어링으로 대체했다는 주장 * 유명 대학이나 AI 기업이 그래프 엔지니어링을 공식 채택했다는 주장 * 그래프 엔지니어링을 도입하면 정확도가 일정 비율 향상되고 비용이 크게 줄어든다는 일반화 특히 정확도 향상과 비용 절감 수치로 언급된 사례는 영상의 조사에 따르면 특정 산업용 도면 작업에만 적용된 좁은 연구였으며, 모든 AI 업무에서 같은 효과가 발생하는 것처럼 확대 해석해서는 안 된다고 설명합니다. > 이 문서는 영상 내용을 요약한 것이며, 위 용어의 기원과 사례에 관한 주장은 영상 제작자의 설명을 기준으로 정리했습니다. *** ## 3\. 프롬프트부터 그래프까지의 관계 각 엔지니어링 개념은 완전히 대립하는 기술이 아니라, AI 시스템에서 설계하는 범위가 점점 넓어지는 관점으로 이해할 수 있습니다. | 개념 | 설계 대상 | 핵심 질문 | | --- | ----- | ----- | | **프롬프트 엔지니어링** | 한 번의 지시와 질문 | 어떻게 요청할 것인가? | | **컨텍스트 엔지니어링** | 모델이 판단할 때 보는 정보 | 무엇을 보여줄 것인가? | | **하네스 엔지니어링** | 모델을 둘러싼 규칙·도구·권한·환경 | 어떤 환경에서 일하게 할 것인가? | | **루프 엔지니어링** | 실행·검증·수정·종료의 반복 | 어떻게 반복하고 언제 멈출 것인가? | | **그래프 엔지니어링** | 여러 작업·분기·병렬 처리·상태의 전체 흐름 | 복잡한 실행 경로를 어떻게 명시적으로 연결하고 관리할 것인가? | ### 개념이 서로 대체되는 것은 아니다 그래프 안에서도 각 AI 호출에는 프롬프트와 컨텍스트가 필요합니다. AI가 사용할 도구와 제한은 하네스로 구성되고, 그래프의 일부 경로는 반복되는 루프가 될 수 있습니다. 즉, 다음과 같은 포함 관계로 이해하는 것이 자연스럽습니다. * 그래프 안에 여러 루프가 존재할 수 있습니다. * 루프를 실행하는 에이전트에는 하네스가 필요할 수 있습니다. * 하네스는 컨텍스트와 도구를 관리합니다. * 각각의 AI 호출에는 프롬프트가 들어갑니다. *** ## 4\. 루프도 그래프의 일종이다 영상은 루프와 그래프 사이에 명확한 경계선이 없다고 강조합니다. 그래프는 일반적으로 다음 두 요소로 구성됩니다. * **노드:** 작업이나 절차를 나타내는 상자 * **엣지:** 다음 작업으로 이동하는 경로를 나타내는 화살표 루프 역시 노드와 엣지로 구성되며, 한 경로가 이전 노드로 되돌아가는 그래프입니다. 따라서 수학적·구조적으로 보면 **루프도 그래프의 한 형태**입니다. 그래프 엔지니어링은 루프와 완전히 다른 기술이라기보다, 단순한 순환 구조가 복잡해졌을 때 이를 명시적인 노드·엣지·상태로 관리하는 방법에 가깝습니다. *** ## 5\. 그래프 엔지니어링이 필요한 세 가지 상황 영상은 작업 상자가 늘어나고 흐름이 복잡해지는 대표적인 이유를 세 가지로 설명합니다. ### 5.1 실패 원인마다 대응 방법이 다른 경우 단순 루프에서는 어떤 실패가 발생하더라도 이전 단계로 돌아가 다시 작업하게 만들 수 있습니다. 하지만 실무의 실패는 원인이 서로 다릅니다. 예를 들면 다음과 같습니다. | 실패 유형 | 올바른 대응 예시 | | ----- | --------- | | **테스트 실패** | 코드를 수정하고 테스트 재실행 | | **요구사항 모호함** | 사람에게 질문하고 답변을 기다림 | | **외부 서버 장애** | 코드를 수정하지 않고 일정 시간 대기 후 재시도 | | **권한 부족** | 필요한 권한 요청 또는 작업 중단 | | **사용량 제한 초과** | 재시도 시간을 예약하거나 캐시된 결과 사용 | 외부 서버가 죽은 상황에서 코드를 다섯 번 다시 작성하게 하는 것은 의미가 없습니다. 실패 유형을 먼저 분류하고 원인에 맞는 경로로 이동해야 하므로 그래프의 분기가 늘어납니다. ### 5.2 여러 작업을 동시에 처리하는 경우 서로 독립적인 파일 다섯 개를 순서대로 수정하면 시간이 오래 걸립니다. 독립적으로 처리할 수 있다면 작업을 여러 갈래로 나누어 동시에 실행하고, 완료된 결과를 마지막에 합칠 수 있습니다. 이를 그래프 용어로 표현하면 다음과 같습니다. * **Fan-out:** 하나의 작업을 여러 병렬 작업으로 분배 * **Worker nodes:** 각 파일이나 하위 작업을 독립적으로 처리 * **Fan-in:** 병렬 작업 결과를 하나로 합침 * **Final verification:** 합쳐진 결과에 전체 테스트 실행 ### 5.3 작업 단계 사이에서 상태를 공유해야 하는 경우 노드가 많아지면 각 단계가 다음 단계로 데이터를 전달해야 합니다. 노드마다 서로 다른 형식으로 데이터를 읽고 쓴다면 전체 시스템이 복잡해집니다. 따라서 그래프에서는 다음 정보를 표준화된 상태로 관리합니다. * 현재 처리 중인 파일 * 파일별 작업 완료·실패 여부 * 오류 유형과 메시지 * 재시도 횟수 * 사람의 검토·승인 여부 * 생성된 결과물의 위치 * 다음에 실행할 노드 정리하면 **조건 분기, 병렬 처리, 상태 관리**가 늘어나면서 단순 루프가 복잡한 그래프로 발전합니다. *** ## 6\. 그래프의 모든 노드가 AI일 필요는 없다 그래프 엔지니어링이라는 이름 때문에 모든 작업을 AI 에이전트가 수행해야 한다고 오해하기 쉽습니다. 영상은 각 노드가 다음 중 어느 것이든 될 수 있다고 설명합니다. * LLM 또는 AI 에이전트 * 일반 프로그램 함수 * 셸 명령어 * 테스트 명령어 * 문자열 검색이나 정규식 * 외부 API 호출 * 일정 시간 대기 * 사람의 검토와 승인 예를 들어 테스트 통과 여부는 AI에게 자연어로 물어보기보다 `npm test` 같은 결정론적인 명령을 실행하고 종료 코드로 판정하는 것이 더 안전합니다. 그래프 엔지니어링의 목적은 AI 노드를 많이 만드는 것이 아니라, **업무에 필요한 서로 다른 절차를 가장 적합한 방식으로 연결하는 것**입니다. *** ## 7\. 단순 루프와 그래프 구조 비교 ### 단순 루프 ``` flowchart TD A["작업 수행"] --> B["테스트 실행"] B -->|통과| C["완료"] B -->|실패| A ``` 이 구조는 간단하고 이해하기 쉽지만 모든 실패를 동일하게 취급합니다. ### 실패 유형을 구분하는 그래프 ``` flowchart TD A["작업 수행"] --> B["테스트 실행"] B -->|통과| C["완료"] B -->|실패| D["실패 유형 분류"] D -->|테스트 오류| A D -->|요구사항 모호| E["사람에게 질문"] D -->|외부 장애| F["대기 후 재시도"] E --> A F --> B ``` 두 번째 구조에서는 실패 원인에 따라 다음 행동이 달라집니다. 이러한 조건 분기가 여러 겹으로 늘어나면 프롬프트나 단순 반복문만으로 관리하기 어려워집니다. *** ## 8\. 그래프를 코드로 정의하는 이유 영상은 단순한 프롬프트와 셸 반복문 대신 그래프를 코드로 정의할 때 얻는 장점을 네 가지로 정리합니다. ### 8.1 실행 전에 전체 흐름 검사 그래프를 시각화하면 다음 문제를 실행 전에 발견할 수 있습니다. * 도달할 수 없는 노드 * 끝나지 않는 반복 경로 * 어디에도 연결되지 않은 막다른 길 * 처리되지 않은 실패 유형 * 반드시 거쳐야 하는 검증 단계의 누락 ### 8.2 중단된 지점부터 재개 사람의 승인을 기다리거나 서버가 종료된 경우 현재 상태를 저장해 두었다가 같은 지점에서 작업을 이어갈 수 있습니다. ### 8.3 이전 상태로 되돌려 다른 경로 재실행 결과가 좋지 않다면 특정 체크포인트로 돌아가 다른 분기나 다른 설정으로 다시 실행할 수 있습니다. ### 8.4 특정 노드만 교체 전체 시스템을 다시 만들지 않고 특정 노드의 프롬프트·도구·AI 모델만 교체해 성능과 비용을 개선할 수 있습니다. *** ## 9\. 루프에서 그래프로 넘어가야 하는 시점 영상은 그래프 엔지니어링을 무조건 도입하라고 권하지 않습니다. 다음과 같은 상황이 생길 때 도입을 검토할 수 있습니다. * 조건문이 여러 겹으로 중첩됩니다. * 실패 원인별로 이동해야 할 단계가 다릅니다. * 여러 작업을 병렬로 실행하고 다시 합쳐야 합니다. * 사람이 승인할 때까지 멈춰야 합니다. * 중단된 작업을 며칠 뒤 이어서 실행해야 합니다. * 현재 작업이 어느 단계인지 추적하기 어렵습니다. * 여러 노드가 공유하는 데이터 형식을 통일해야 합니다. * 특정 단계만 다른 모델이나 도구로 교체하고 싶습니다. 반대로 흐름이 머릿속으로 쉽게 따라갈 수 있을 정도로 단순하다면 프롬프트와 루프만으로도 충분합니다. > **루프로 시작하고, 복잡성을 감당하기 어려워지는 순간 그래프로 전환한다.** *** ## 10\. 실습 1: 단순 루프를 코드로 표현하기 영상의 실습은 단순한 루프 구조를 코드로 표현하는 것부터 시작합니다. 기본 노드는 다음과 같습니다. 1. 작업 수행 2. 테스트 실행 3. 반복 횟수 초과 시 사람에게 이관 기본 흐름은 다음과 같습니다. 1. 코드를 수정합니다. 2. 테스트를 실행합니다. 3. 통과하면 종료합니다. 4. 실패하면 다시 수정합니다. 5. 최대 5회 실패하면 사람에게 넘깁니다. 이 구조는 노드가 적고 실패 유형이 하나이므로 단순 반복문으로도 관리할 수 있습니다. *** ## 11\. 실습 2: 실패 분류 노드 추가하기 단순 루프의 문제는 모든 실패를 하나로 묶어 처리한다는 점입니다. 이를 개선하기 위해 **Classifier 노드**를 추가합니다. Classifier는 반드시 복잡한 AI 모델일 필요가 없습니다. 오류 메시지 파일을 읽고 문자열을 검색하는 간단한 프로그램으로도 만들 수 있습니다. 예시는 다음과 같습니다. * 오류 메시지에 `test failed`가 있으면 테스트 오류 경로 * `ambiguous`가 있으면 요구사항 확인 경로 * `external`이나 연결 오류가 있으면 외부 장애 경로 분류 결과에 따른 행동은 다음과 같이 달라집니다. * 테스트 오류 → 코드 수정 노드 * 요구사항 모호 → 사람에게 질문하는 노드 * 외부 서버 장애 → 60초 대기 노드 분류 노드가 추가되면서 기존 세 개의 상자가 다섯 개 이상으로 늘어나고, 단순 루프가 조건 분기를 가진 그래프로 발전합니다. *** ## 12\. 실습 3: 여러 파일 병렬 처리하기 영상에서는 하나의 파일을 수정하던 루프를 여러 파일에 동시에 적용하는 예시를 보여줍니다. ### 동작 순서 1. 처리할 파일 목록을 확인합니다. 2. 분배 노드가 파일별 작업을 생성합니다. 3. 여러 Worker 노드가 파일을 동시에 수정합니다. 4. 모든 Worker가 끝날 때까지 기다립니다. 5. 결과를 하나로 합칩니다. 6. 프로젝트 전체 테스트를 실행합니다. 작업 대상 파일 수에 따라 Worker 노드가 동적으로 늘어날 수 있습니다. 이렇게 그래프가 펼쳐졌다가 다시 합쳐지는 과정에서는 각 작업의 완료 여부와 결과를 안정적으로 추적할 상태가 필요합니다. *** ## 13\. 상태\(State\)를 표준화해야 하는 이유 그래프에서 상태는 노드 사이를 이동하는 **공통 데이터 묶음이자 작업일지**입니다. 영상의 예시를 기준으로 상태 객체는 다음 정보를 가질 수 있습니다. ``` files: parser.ts: pending formatter.ts: failed attempt_count: 2 error_type: test_failure human_reviewed: false next_node: fix_code ``` 실제 상태 구조는 프로젝트에 따라 달라지지만 다음 원칙이 중요합니다. * 모든 노드가 같은 상태 형식을 이해해야 합니다. * 각 노드는 자신이 담당하는 필드만 명확하게 수정해야 합니다. * 실패와 재시도 이유가 상태에 기록되어야 합니다. * 다음 실행이 상태만 읽고 작업을 이어갈 수 있어야 합니다. * 상태 변경 내역을 통해 전체 실행 과정을 추적할 수 있어야 합니다. ### 상태가 작업일지가 되는 과정 각 노드는 작업을 시작할 때 현재 상태를 읽고, 작업을 마치면 결과를 상태에 기록합니다. 예를 들면 다음과 같습니다. * 파일 A: 통과 * 파일 B: 테스트 실패 * 재시도 횟수: 2회 * 첫 실패 원인: 테스트 오류 * 두 번째 실패 원인: 외부 연결 중단 * 사람 승인 여부: 대기 중 이 기록이 있으면 왜 계획보다 반복 횟수가 늘어났는지 확인할 수 있으며, 작업이 중단돼도 처음부터 다시 실행할 필요가 없습니다. *** ## 14\. LangGraph로 구현하는 기본 구조 영상은 그래프 엔지니어링을 구현하는 대표적인 도구로 LangGraph를 소개합니다. 구체적인 코드 문법보다 다음 구조를 이해하는 것이 핵심입니다. ### 1단계: 상태 구조 정의 노드들이 주고받을 데이터의 필드와 형식을 클래스나 객체로 정의합니다. ### 2단계: 노드 함수 작성 각 함수가 상태를 입력받아 작업을 수행하고 수정된 상태를 반환하게 합니다. 예시는 다음과 같습니다. * `work`: 코드나 파일 수정 * `test`: `npm test` 실행 * `classify`: 오류 유형 분류 * `wait`: 외부 서비스 복구 대기 * `human`: 사람의 답변 또는 승인 요청 * `finish`: 완료 결과 정리 ### 3단계: 노드와 엣지 연결 * `add\_node`와 같은 방식으로 함수들을 노드로 등록합니다. * `add\_edge`로 노드 사이의 이동 경로를 연결합니다. * 조건부 엣지로 테스트 결과와 오류 유형에 따라 분기합니다. ### 4단계: 종료와 재시도 조건 정의 * 최대 재시도 횟수 * 테스트 통과 여부 * 사람에게 이관할 조건 * 외부 서비스 재시도 간격 * 전체 시간과 비용 제한 ### 5단계: 그래프 컴파일 및 실행 정의한 상태 그래프를 컴파일하면 실행 가능한 그래프 애플리케이션이 됩니다. 그래프를 시각화해 노드와 엣지가 올바르게 연결됐는지 확인할 수도 있습니다. *** ## 15\. 체크포인트와 중단 후 재개 그래프 엔지니어링의 중요한 장점 중 하나는 현재 상태를 데이터베이스에 체크포인트로 저장하고 나중에 이어서 실행할 수 있다는 점입니다. ### 사람이 승인해야 하는 예시 1. AI가 작업 결과를 생성합니다. 2. Human 노드에서 실행을 중단합니다. 3. 현재 상태와 다음 실행 위치를 데이터베이스에 저장합니다. 4. 사람이 며칠 뒤 결과를 검토하고 답변합니다. 5. 저장된 상태를 불러옵니다. 6. Human 노드 다음 단계부터 실행을 재개합니다. 단순 셸 반복문은 터미널이 꺼지거나 프로세스가 종료되면 현재 위치를 잃기 쉽습니다. 반면 그래프는 상태와 실행 위치를 저장해 긴 작업과 승인 대기를 안정적으로 처리할 수 있습니다. ### 재개할 때 확인해야 할 것 * 저장된 상태의 스키마가 현재 코드와 호환되는가? * 외부 데이터가 중단 시점 이후 변경되지 않았는가? * 이미 실행한 노드를 다시 실행해도 안전한가? * 동일 작업이 중복 처리되지 않도록 설계됐는가? * 사람의 승인 결과가 올바른 실행 ID에 연결됐는가? *** ## 16\. 노드별로 다른 모델 사용하기 그래프에서는 각 노드를 독립적인 부품처럼 교체할 수 있습니다. 모든 작업에 가장 크고 비싼 AI 모델을 사용할 필요는 없습니다. | 작업 유형 | 적합한 처리 방식 | | ----- | --------- | | 문자열 검색, 테스트 통과 여부 | 일반 코드와 명령어 | | 오류 유형 단순 분류 | 규칙 기반 또는 작은 모델 | | 문서 요약과 형식 변환 | 빠르고 저렴한 모델 | | 복잡한 설계와 디버깅 | 추론 성능이 높은 모델 | | 중요한 최종 검증 | 강한 검증 모델 또는 사람 | 노드별로 적합한 모델과 도구를 선택하면 비용과 속도를 최적화할 수 있습니다. *** ## 17\. 그래프 엔지니어링의 주요 장점 ### 복잡한 흐름의 가시성 작업 절차를 그림으로 확인할 수 있어 조건 분기, 병렬 처리, 반복과 종료 경로를 이해하기 쉬워집니다. ### 실패 원인별 대응 모든 실패를 동일하게 재시도하지 않고, 오류 종류에 따라 수정·대기·질문·중단으로 나눌 수 있습니다. ### 병렬 실행 서로 독립적인 작업을 동시에 처리하고 결과를 안전하게 합칠 수 있습니다. ### 장기 작업의 지속성 체크포인트와 상태를 저장하면 프로세스 종료나 사람의 승인 대기 후에도 작업을 이어갈 수 있습니다. ### 구성요소 교체 특정 노드의 모델·프롬프트·도구만 교체해 전체 시스템을 단계적으로 개선할 수 있습니다. ### 실행 과정 추적 상태 변경 기록을 통해 어느 단계에서 실패했고, 왜 반복됐으며, 누가 승인했는지 분석할 수 있습니다. *** ## 18\. 그래프 엔지니어링 도입 시 주의할 점 영상은 그래프가 복잡해 보인다는 이유만으로 노드를 늘리지 말라고 경고합니다. ### 18.1 필요하지 않은 노드 추가 간단한 작업을 여러 노드로 잘게 나누면 토큰 비용, 코드량과 디버깅 시간이 늘어납니다. > 흐름이 단순하다면 루프만으로 처리하고, 실제 복잡성이 생겼을 때 그래프로 전환합니다. ### 18.2 모든 작업을 AI에 맡기기 결정론적인 명령으로 정확히 처리할 수 있는 작업까지 AI 노드로 만들면 환각과 비용이 증가합니다. * 테스트 실행 → `npm test` * 문자열 검색 → `grep` 또는 정규식 * 파일 존재 확인 → 일반 프로그램 로직 * JSON 형식 검증 → 스키마 검증기 AI는 의미 해석과 복잡한 판단이 필요한 단계에 선택적으로 사용해야 합니다. ### 18.3 분기만 만들고 동일한 작업 수행 오류를 여러 종류로 분류한 뒤 모든 경로가 다시 같은 작업으로 연결된다면 분류의 의미가 없습니다. 분기는 실제로 다른 대응이 필요할 때만 만듭니다. ### 18.4 종료 조건이 없는 반복 그래프 안에 무한 루프가 생기지 않도록 다음 제한을 설정해야 합니다. * 최대 재시도 횟수 * 전체 실행 시간 * 토큰과 API 비용 상한 * 동일 오류 반복 횟수 * 진전이 없을 때 중단 * 사람에게 이관할 조건 그래프를 시각화하면 종료되지 않는 순환 경로를 비교적 쉽게 발견할 수 있습니다. ### 18.5 상태 스키마를 자주 바꾸기 상태를 데이터베이스에 저장한 뒤 코드의 상태 구조를 변경하면 이전 체크포인트를 불러올 때 문제가 발생할 수 있습니다. 상태 버전 관리와 마이그레이션 전략이 필요합니다. *** ## 19\. 루프와 그래프 선택 기준 | 상황 | 권장 방식 | | --- | ----- | | 한 가지 작업을 검증 결과에 따라 반복 | 단순 루프 | | 실패 유형이 하나이고 재시도 방식도 동일 | 단순 루프 | | 노드와 경로를 머릿속으로 쉽게 추적 가능 | 단순 루프 | | 실패 유형별 대응이 다름 | 그래프 | | 여러 작업을 병렬로 나누고 합쳐야 함 | 그래프 | | 사람의 승인까지 장시간 대기 | 그래프와 체크포인트 | | 중단된 실행을 특정 위치에서 재개 | 그래프와 상태 저장 | | 노드별 모델·도구 최적화 필요 | 그래프 | | 실행 경로를 시각적으로 감사해야 함 | 그래프 | *** ## 20\. 실무 적용 예시: 코드 수정 자동화 그래프 ### 목표 여러 파일의 포맷과 테스트 오류를 자동으로 수정하되, 요구사항이 모호하거나 외부 서비스에 문제가 있으면 적절한 경로로 분기합니다. ### 노드 구성 1. **Load state:** 기존 작업 상태 불러오기 2. **Distribute:** 수정할 파일을 병렬 작업으로 분배 3. **Workers:** 파일별 수정 수행 4. **Merge:** 수정 결과 합치기 5. **Test:** 전체 테스트 실행 6. **Classify:** 실패 원인 분류 7. **Fix:** 코드 오류 수정 8. **Wait:** 외부 시스템 복구 대기 9. **Human:** 요구사항 확인과 승인 요청 10. **Finish:** 결과 정리와 완료 처리 ### 종료 조건 * 테스트 전체 통과 * 최대 수정 5회 * 전체 실행 시간 제한 * 동일 오류 2회 이상 반복 시 사람에게 이관 * 외부 서비스 장애가 지정 시간을 넘으면 중단 ### 상태 예시 ``` run_id: run-2026-001 files: parser.ts: passed formatter.ts: retrying attempt_count: 2 last_error: test_failure human_approval: pending next_node: fix started_at: 2026-07-28T09:00:00Z ``` *** ## 21\. 그래프 설계 체크리스트 ### 구조 * 각 노드의 역할이 하나의 명확한 작업으로 정의되어 있는가? * 노드 사이에 전달되는 상태의 형식이 표준화되어 있는가? * 모든 조건 분기에 실제로 서로 다른 대응이 연결되어 있는가? * 도달할 수 없는 노드나 막다른 경로가 없는가? * 병렬 실행 후 결과를 합치는 지점이 명확한가? ### AI 사용 * 일반 코드나 명령어로 처리할 수 있는 작업을 불필요하게 AI에게 맡기지 않았는가? * 의미 판단이 필요한 노드에만 AI를 사용했는가? * 작업 난이도에 맞게 노드별 모델을 선택했는가? * AI 출력은 스키마 또는 결정론적 검증기로 확인하는가? ### 안정성 * 각 루프에 최대 반복 횟수가 있는가? * 시간·토큰·API 비용 상한이 있는가? * 외부 시스템 장애와 속도 제한을 처리하는가? * 사람에게 넘겨야 할 조건이 정의되어 있는가? * 같은 작업을 재실행해도 중복 부작용이 발생하지 않는가? ### 상태와 재개 * 현재 노드와 다음 노드가 상태에 기록되는가? * 작업 결과와 실패 원인이 기록되는가? * 체크포인트가 영구 저장되는가? * 중단 후 재개 과정을 실제로 테스트했는가? * 상태 스키마 변경에 대비한 버전 관리가 있는가? *** ## 22\. 광고 구간 요약 영상의 07:41\~08:40 구간은 Hostinger VPS 협찬 내용입니다. 영상에서는 장시간 또는 24시간 실행되는 AI 비서와 자동화 작업을 운영하려면 개인 컴퓨터를 계속 켜두기보다 VPS 같은 서버를 사용할 수 있다고 설명합니다. Hostinger의 VPS 상품, 할인 코드와 무료 도메인 혜택을 소개한 뒤 실습으로 돌아갑니다. 이 내용은 그래프 엔지니어링의 필수 구성요소가 아니라 영상 제작을 지원한 서비스 소개입니다. 그래프는 로컬 컴퓨터, 사내 서버, 클라우드와 다른 VPS에서도 구현할 수 있습니다. *** ## 23\. 타임라인별 상세 목차 | 시간 | 내용 | | --- | --- | | **00:00** | 그래프 엔지니어링 용어가 등장한 배경 | | **01:08** | 그래프 엔지니어링 5분 핵심 요약 시작 | | **01:39** | 루프도 그래프의 일종이라는 설명 | | **02:12** | 노드가 많아질 때 그래프가 필요한 이유 | | **02:47** | 실패 원인별 조건 분기 | | **03:19** | 여러 작업의 병렬 실행과 결과 병합 | | **03:36** | 노드 사이의 표준화된 상태 관리 | | **04:20** | 모든 노드가 AI일 필요는 없다는 설명 | | **04:42** | 실행 전에 그래프를 코드로 정의하는 이유 | | **05:04** | 사전 검사·재개·되돌리기·노드 교체의 장점 | | **05:32** | 루프에서 그래프로 넘어가야 하는 시점 | | **05:52** | LangGraph와 기존 그래프 기반 에이전트 기술 | | **06:51** | 이론 부분 핵심 정리 | | **07:41** | Hostinger VPS 협찬 구간 | | **08:40** | 그래프 엔지니어링 실습 시작 | | **09:08** | 단순 루프를 코드 구조로 표현 | | **09:43** | 실패 분류 노드와 조건별 처리 추가 | | **10:33** | 여러 파일을 동시에 처리하는 병렬 그래프 | | **11:16** | 중간 결과와 실패 기록을 상태로 관리 | | **12:50** | LangGraph 상태·노드·엣지 구현 개념 | | **13:55** | 그래프 시각화와 실행 흐름 확인 | | **14:46** | 체크포인트를 이용한 중단 후 재개 | | **16:14** | 노드별로 다른 AI 모델 사용하기 | | **16:39** | 그래프 설계 시 주의할 점 | | **17:45** | 최종 정리 | *** ## 24\. 최종 정리 영상에서 말하는 그래프 엔지니어링은 루프 엔지니어링을 대체하는 완전히 새로운 기술이 아닙니다. **단순 루프가 여러 조건 분기, 병렬 작업, 사람의 승인과 장기 상태를 포함하면서 복잡해졌을 때 전체 흐름을 명시적으로 관리하는 방법**입니다. 핵심 내용을 다섯 문장으로 압축하면 다음과 같습니다. 1. **루프도 그래프의 한 종류이며 두 개념 사이에 절대적인 경계는 없습니다.** 2. **실패 유형별 분기, 병렬 처리와 상태 관리가 많아지면 그래프가 필요합니다.** 3. **노드는 AI뿐 아니라 일반 함수, 테스트 명령어, 외부 API와 사람도 될 수 있습니다.** 4. **표준화된 상태와 체크포인트가 있어야 중단된 장기 작업을 안정적으로 이어갈 수 있습니다.** 5. **흐름이 단순하면 루프를 유지하고, 사람이 구조를 추적하기 어려워질 때 LangGraph 같은 그래프 도구를 도입합니다.** 결국 그래프 엔지니어링의 가치는 새로운 용어 자체보다 **복잡한 AI 작업을 눈으로 검토하고, 코드로 통제하고, 중단 후 복구하며, 각 단계에 가장 적합한 도구를 배치할 수 있다는 점**에 있습니다. *** ## 참고 자료 및 작성 기준 * 원본 영상: [https://www.youtube.com/watch?v=BtM2JZCMtL8](https://www.youtube.com/watch?v=BtM2JZCMtL8) * ZeroCho 강좌: [https://www.zerocho.com/lecture](https://www.zerocho.com/lecture) * ZeroCho GitHub: [https://github.com/zerocho](https://github.com/zerocho) * 영상 설명란과 전체 한국어 자동 자막을 기준으로 정리했습니다. * 자막의 명백한 오인식은 영상 문맥에 맞게 교정했습니다. * 영상 속 광고는 기술 요약과 분리해 표시했습니다. * 일부 코드와 상태 예시는 영상의 개념을 이해하기 쉽게 재구성한 것으로, 실제 구현 시 사용하는 LangGraph 버전과 환경에 맞게 조정해야 합니다.]]> 최고관리자 2026-08-29T21:46:28+09:00 https://ai.23yellow.com/ai_Engineering_01/codex-%EB%A7%88%EC%8A%A4%ED%84%B0-%ED%81%B4%EB%9E%98%EC%8A%A4-1%EC%8B%9C%EA%B0%84-%ED%8E%B8%EC%A7%91%EB%B3%B8-%ED%95%98%EB%84%A4%EC%8A%A4-%EC%84%A4%EA%B3%84%EB%B6%80%ED%84%B0/ Codex 마스터 클래스 상세 요약 > **원본 영상:** [Codex 마스터 클래스 1시간 편집본｜하네스 설계부터 서비스 배포까지](https://www.youtube.com/watch?v=wScdyoQjj8E) > **채널:** 개발동생 > **게시일:** 2026년 5월 17일 > **영상 길이:** 51분 43초 > **실습 프로젝트:** Commit Hero > **핵심 주제:** Codex 하네스 구성요소를 이해하고, 아이디어 구체화부터 웹서비스 구현·검증·병렬 개발·배포까지 연결하는 실전 워크플로우 *** ## 1\. 영상 전체 요약 이 영상은 Codex를 단순한 코드 생성 도구가 아니라, **규칙·기억·업무 절차·외부 도구·강제 장치·병렬 에이전트를 결합해 실제 프로젝트를 수행하는 개발 에이전트**로 활용하는 방법을 설명합니다. 전반부에서는 Codex의 하네스를 구성하는 다음 여섯 요소를 다룹니다. 1. `AGENTS.md` 2. Memory 3. Skills 4. MCP 5. Hooks 6. Sub-agents 후반부에서는 이 요소들을 실제 개발 흐름에 적용해 **GitHub 사용자의 공개 활동을 분석하여 RPG 캐릭터 카드를 생성하는 ‘Commit Hero’ 서비스**를 만듭니다. 실습은 다음 순서로 진행됩니다. > 러프한 아이디어 → AI의 역질문 인터뷰 → 요구사항 확정 → 계획 문서 작성 → 목업 UI 구현 → 브라우저 검증 → GitHub API 연동 → GitHub 업로드 → 워크트리 병렬 개발 → AI 기능 추가 → Vercel 배포 영상의 가장 중요한 메시지는 다음과 같습니다. > **좋은 결과는 긴 프롬프트 하나에서 나오는 것이 아니라, AI가 일하는 기준과 절차를 프로젝트 안에 반복 가능한 구조로 고정할 때 나온다.** *** ## 2\. 하네스 엔지니어링이란? 영상에서는 하네스를 **AI가 일하는 방식을 일정하게 고정하는 구조**라고 설명합니다. 프롬프트만으로 애플리케이션 전체를 안정적으로 개발하기는 어렵습니다. 대화할 때마다 지시가 달라질 수 있고, 작업이 길어지면 처음의 목표를 잊거나 프로젝트 규칙을 어길 수도 있습니다. 하네스 엔지니어링은 AI 에이전트 주변에 다음과 같은 장치를 설치해 이 문제를 줄입니다. * 항상 따라야 하는 프로젝트 규칙 * 이전 작업과 사용자 선호를 이어주는 기억 * 반복 업무를 표준화한 절차 * 외부 시스템과 연결되는 도구 * 반드시 지켜야 하는 제한을 강제하는 프로그램 로직 * 독립된 컨텍스트에서 병렬로 일하는 전문 에이전트 ### 하네스 도입 효과 영상은 하네스의 주요 효과를 다음처럼 설명합니다. * **반복성:** 같은 작업을 일정한 방식으로 반복할 수 있습니다. * **강제와 자율성의 분리:** 반드시 지켜야 할 것은 시스템으로 강제하고, 나머지는 AI가 자율적으로 판단하게 합니다. * **팀 단위 축적:** 개인의 프롬프트와 노하우를 프로젝트 파일로 만들어 팀과 공유할 수 있습니다. * **세션 간 일관성:** 대화가 바뀌더라도 동일한 프로젝트 규칙과 절차를 재사용할 수 있습니다. * **장기 작업 안정성:** 작업이 길어져도 계획 문서와 규칙을 기준으로 방향을 유지할 수 있습니다. *** ## 3\. Codex 하네스의 6가지 구성요소 | 구성요소 | 핵심 역할 | 적합한 사용 상황 | | ---- | ----- | --------- | | **AGENTS.md** | AI가 항상 참고할 규칙과 프로젝트 지침 정의 | 코딩 규칙, 테스트 방법, 금지사항, 프로젝트 구조 고정 | | **Memory** | 이전 세션에서 얻은 사용자 선호와 반복 맥락 재사용 | 자주 쓰는 기술 스택, 작업 습관, 반복되는 결정 기억 | | **Skills** | 지시·자료·스크립트·템플릿을 묶은 재사용 워크플로우 | 인터뷰, 문서 작성, 배포, 디자인 검토 등의 반복 절차 | | **MCP** | AI가 외부 시스템의 정보와 기능을 사용하도록 연결 | Gmail, Slack, GitHub, Notion 등 외부 서비스 접근 | | **Hooks** | 특정 이벤트에서 프로그램 로직을 강제로 실행 | 비밀 파일 접근 차단, 명령 검사, 자동 검증과 가드레일 | | **Sub-agents** | 별도 컨텍스트를 가진 전문 에이전트에 작업 위임 | 병렬 조사·개발·검증, 생성자와 검토자 역할 분리 | *** ## 4\. AGENTS\.md: 에이전트가 따라야 할 규칙 `AGENTS.md`는 Codex가 프로젝트를 작업할 때 참고하는 **규칙 파일**입니다. 프롬프트마다 같은 내용을 반복하지 않고, 에이전트가 계속 따라야 할 지침을 파일로 고정할 수 있습니다. ### 적용 범위 영상에서는 규칙의 범위를 크게 두 가지로 설명합니다. #### 전역 규칙 모든 프로젝트에서 공통으로 적용할 지침입니다. 예시는 다음과 같습니다. * 답변과 주석에 사용할 언어 * 공통적인 코드 품질 기준 * 파일을 수정할 때 따라야 할 기본 원칙 * 테스트와 검증에 대한 공통 규칙 #### 프로젝트 규칙 특정 저장소에서만 적용할 지침입니다. * 기술 스택과 버전 * 프로젝트 디렉터리 구조 * 네이밍 규칙 * 빌드·테스트·린트 명령어 * 디자인 시스템과 컴포넌트 사용 규칙 * 수정하면 안 되는 파일 * 작업 완료 기준 ### 중첩 구조 `AGENTS.md`는 프로젝트 루트뿐 아니라 하위 디렉터리에도 둘 수 있습니다. Codex는 전역 지시와 프로젝트 루트에서 현재 작업 디렉터리까지의 지시를 순서대로 참고합니다. 이를 이용하면 다음처럼 규칙을 나눌 수 있습니다. * 프로젝트 루트: 전체 프로젝트 공통 규칙 * `frontend/`: 프론트엔드 전용 규칙 * `backend/`: 백엔드와 API 전용 규칙 * `tests/`: 테스트 작성과 실행 규칙 ### 실무에서 중요한 이유 `AGENTS.md`는 개인 컴퓨터 안에만 두는 임시 프롬프트가 아니라, 가능한 경우 저장소에 포함해 **팀이 함께 검토하고 버전 관리하는 개발 규칙**으로 운영하는 것이 좋다고 설명합니다. *** ## 5\. Memory: 세션을 넘어 반복 맥락 기억하기 Memory는 이전 대화와 작업에서 반복적으로 유용한 내용을 저장하고, 이후 세션에서 필요한 기억을 다시 불러오는 기능입니다. 영상에서는 다음과 같은 내용을 기억할 수 있다고 설명합니다. * 사용자가 선호하는 작업 방식 * 자주 사용하는 기술 스택 * 반복되는 업무 흐름 * 프로젝트 관리 방식 * 이전에 자주 발생했던 실수 * 다음 세션에서도 참고해야 할 결정 ### 활성화 방법 영상 촬영 시점에는 Memory가 기본적으로 비활성화된 기능으로 소개됩니다. Codex 앱의 설정에서 개인 맞춤 설정 영역을 통해 활성화하거나, 설정 파일을 직접 수정하거나, Codex에게 설정 변경을 요청하는 방식이 제시됩니다. ### AGENTS.md·플랜 문서와의 차이 | 장치 | 저장하는 내용 | | --- | ------- | | **AGENTS.md** | 반드시 따라야 할 명시적인 프로젝트 규칙 | | **Memory** | 대화와 작업에서 추출된 사용자 선호와 반복 맥락 | | **플랜 문서** | 현재 기능이나 프로젝트의 목표·범위·구현 순서 | Memory에 모든 것을 맡기기보다, 반드시 지켜야 할 규칙은 `AGENTS.md`에 명시하고 프로젝트별 계획은 저장소 안의 문서로 남기는 것이 안정적입니다. *** ## 6\. Skills: 반복 절차를 재사용 가능한 패키지로 만들기 Skill은 특정 업무에서 Codex가 따라야 하는 **지시, 참고 자료, 스크립트, 템플릿과 에셋을 하나로 묶은 재사용 가능한 워크플로우**입니다. 단순 프롬프트 템플릿은 텍스트 지시만 포함하지만, Skill은 다음과 같은 자료를 함께 포함할 수 있습니다. * 핵심 지침을 담은 `SKILL.md` * 세부 참고 문서 * 자동화 스크립트 * 출력 템플릿 * 이미지나 기타 에셋 ### 점진적 공개 방식 영상에서 강조하는 Skill의 장점은 필요한 모든 자료를 처음부터 컨텍스트에 넣지 않는다는 점입니다. 1. 먼저 Skill의 이름과 간단한 설명을 확인합니다. 2. 해당 Skill이 필요할 때 `SKILL.md`를 읽습니다. 3. 작업에 실제로 필요한 경우에만 참고 문서·스크립트·에셋을 추가로 읽습니다. 이 방식은 컨텍스트 사용량을 줄이면서도 전문화된 절차를 재사용할 수 있게 합니다. ### Skill로 만들기 좋은 작업 * 새로운 서비스 아이디어를 구체화하는 인터뷰 * `AGENTS.md` 생성 * 디자인 검토와 화면 QA * 정해진 형식의 보고서 작성 * 배포 전 검증 절차 * 반복적인 데이터 처리 * 코드 리뷰 체크리스트 실습에서는 **Deep Interview Skill**과 `AGENTS.md` 생성용 Skill을 활용합니다. *** ## 7\. MCP: 외부 서비스와 연결하기 MCP(Model Context Protocol)는 Codex가 기본 환경 밖의 외부 서비스와 상호작용하도록 연결하는 표준 방식입니다. 예를 들면 Codex가 다음 작업을 수행할 수 있게 합니다. * Gmail에서 메일 읽기와 답장 작성 * Slack 메시지 확인과 전송 * GitHub 저장소와 이슈·코드 확인 * Notion 문서 읽기와 작성 * 배포 서비스의 프로젝트 상태 확인 MCP를 연결하면 AI는 단순히 작업 방법을 설명하는 데서 끝나지 않고, 사용자의 승인과 권한 범위 안에서 외부 시스템을 사용해 실제 작업을 진행할 수 있습니다. *** ## 8\. Hooks: 반드시 지켜야 할 규칙 강제하기 `AGENTS.md`, Memory, Skills는 AI가 읽고 판단하여 따르는 지침입니다. 따라서 모든 상황에서 100% 지켜진다고 보장하기 어렵습니다. Hooks는 특정 실행 이벤트에 프로그램 로직을 연결하여, 중요한 규칙을 **결정론적으로 강제하는 런타임 자동화와 가드레일**입니다. ### Hook을 실행할 수 있는 시점 예시 * 세션이 시작될 때 * 사용자가 프롬프트를 제출했을 때 * AI가 도구를 사용하기 직전 * 한 작업 턴이 종료됐을 때 ### 활용 예시 * `.env`와 같은 비밀 파일 접근 차단 * 위험하거나 허용되지 않은 명령 실행 방지 * 코드 수정 후 자동 테스트 실행 * 작업 완료 전 린트·빌드 검사 * 외부 전송 전 승인 절차 적용 영상의 실무 사례에서는 환경변수와 비밀 키가 저장된 파일에 에이전트가 접근하지 못하도록 Hook으로 차단한다고 설명합니다. *** ## 9\. Sub\-agents: 병렬 작업과 전문 역할 분리 Sub-agent는 메인 에이전트가 별도의 에이전트를 생성해 작업 일부를 맡기는 기능입니다. 각 Sub-agent는 독립적인 컨텍스트에서 작업할 수 있습니다. ### 주요 활용 방식 * 서로 독립적인 여러 기능을 병렬 개발 * 조사와 구현을 분리 * 작성자와 검증자 역할 분리 * 프론트엔드·백엔드·테스트를 전문 역할로 나누기 * 메인 세션의 컨텍스트 부담 줄이기 영상에서는 서브에이전트를 단순한 속도 향상 도구가 아니라, **복잡한 작업을 전문 역할과 별도 컨텍스트로 분리하는 장치**로 설명합니다. *** ## 10\. 상황별로 선택하는 하네스 기능 | 해결하려는 문제 | 적합한 기능 | | -------- | ------ | | 같은 실수를 반복하지 않게 하고 싶다 | `AGENTS.md`, Hooks | | 이전 결정과 사용자 선호를 재사용하고 싶다 | Memory | | 반복 업무를 표준 워크플로우로 만들고 싶다 | Skills | | 외부 서비스와 데이터를 사용하고 싶다 | MCP·플러그인 | | 반드시 지켜야 할 제한이 있다 | Hooks | | 전문 작업을 분리하거나 동시에 진행하고 싶다 | Sub-agents·Worktree | | 긴 프로젝트의 방향을 유지하고 싶다 | 플랜 문서, `AGENTS.md` | 영상은 처음부터 모든 하네스를 완벽하게 설계하려 하지 말고 다음 순서로 필요한 요소를 쌓아가라고 권합니다. 1. `AGENTS.md`로 기본 규칙 정의 2. 반복되는 절차를 Skills로 분리 3. 필요한 외부 도구를 MCP로 연결 4. 중요한 제한을 Hooks로 강제 5. 병렬화와 검증이 필요하면 Sub-agents 추가 6. 반복 작업에서 얻은 선호와 맥락은 Memory로 재사용 *** ## 11\. 실습 프로젝트: Commit Hero Commit Hero는 GitHub 사용자 이름을 입력하면 공개 활동 데이터를 분석해 개발자를 RPG 캐릭터 카드로 표현하는 웹서비스입니다. ### 주요 사용자 흐름 1. 사용자가 GitHub 사용자 이름을 입력합니다. 2. 서버가 GitHub 공개 데이터를 가져옵니다. 3. 저장소·커밋·사용 언어 등의 활동을 분석합니다. 4. 개발자의 클래스, 레벨, 능력치, 스킬, 약점 등을 생성합니다. 5. 짧은 분석 보고서와 함께 RPG 카드를 보여줍니다. 6. 결과를 URL이나 파일로 공유합니다. 실습에서 최종적으로 확인된 결과에는 ‘리팩터링 성기사’ 같은 개발자 캐릭터명이 표시됐으며, URL 공유와 PDF 다운로드 기능도 구현됐습니다. *** ## 12\. 러프한 프롬프트에서 시작하기 강사는 처음부터 완벽한 요구사항을 작성하려 하지 않고 다음 정도의 러프한 아이디어로 시작합니다. > GitHub 사용자 이름을 입력하면 해당 사용자의 정보를 분석해 RPG 게임 형식의 재미있는 카드를 만들어주는 바이럴 웹서비스를 만들고 싶다. 여기서 곧바로 개발을 시작하지 않고, AI에게 **서비스를 만들기 전에 필요한 인터뷰를 진행해 달라**고 요청합니다. 이 접근의 핵심은 사용자가 처음부터 자신이 원하는 것을 모두 알고 있다는 가정을 버리는 것입니다. AI가 역으로 질문하도록 만들면 모호했던 아이디어가 선택 가능한 요구사항으로 바뀝니다. *** ## 13\. Deep Interview로 요구사항 구체화 Deep Interview Skill은 러프한 아이디어를 바탕으로 서비스의 목표, 사용자 경험, 기술 선택과 MVP 범위를 질문합니다. 실습에서 결정된 주요 요구사항은 다음과 같습니다. | 질문 항목 | 결정 내용 | | ----- | ----- | | **1차 성공 기준** | 정확한 개발자 평가보다 재미있고 공유하고 싶은 카드 생성에 우선순위 | | **서비스 분위기** | 개발자 밈과 유머 중심 | | **입력 방식** | OAuth 로그인 없이 GitHub 사용자 이름만 입력 | | **결과물** | RPG 캐릭터 카드와 짧은 분석 보고서 모두 제공 | | **공유 기능** | 결과 URL 공유와 카드 파일·PDF 저장 | | **초기 분석 방식** | 우선 규칙 기반으로 만들고 이후 AI를 붙일 수 있게 확장 | | **클래스 이름** | 웃긴 개발자 밈과 멋있는 RPG 명칭을 혼합 | | **디자인** | 다크 판타지와 SaaS 인터페이스의 혼합 | | **프론트엔드** | Next.js 기반 | | **패키지 관리** | pnpm 사용 | | **배포 대상** | Vercel | | **서비스 언어** | 한국어 | 이 과정에서 사용자는 대부분 선택지를 고르고 짧게 답변합니다. 질문에 답할수록 목표와 범위가 구체화되므로, 처음부터 긴 프롬프트를 혼자 작성하는 부담이 줄어듭니다. *** ## 14\. 인터뷰 후 바로 전체 개발을 시작하지 않는 이유 인터뷰가 끝난 뒤에도 곧바로 모든 기능을 구현하지 않습니다. 영상에서는 다음 두 단계를 먼저 수행합니다. 1. 인터뷰 결과와 구현 계획 정리 2. 백엔드 연결 없이 프론트엔드 목업 UI부터 구현 이렇게 하면 서비스의 방향과 화면 구성을 낮은 비용으로 먼저 검증할 수 있습니다. 잘못된 방향으로 백엔드와 AI 기능까지 개발한 뒤 되돌리는 일을 줄일 수 있습니다. *** ## 15\. In\-app Browser로 실제 화면 검증 Codex 앱에는 개발 중인 웹페이지를 열어볼 수 있는 내장 브라우저가 있으며, 에이전트가 브라우저를 제어해 결과를 확인할 수도 있습니다. 실습에서는 다음 작업을 수행합니다. * 로컬 개발 서버 실행 * `localhost:3000` 접속 * 메인 화면과 카드 결과 화면 확인 * 에이전트가 렌더링 결과를 직접 검증 * 영어로 생성된 인터페이스를 한국어로 변경 이 기능의 중요한 점은 코드를 작성하는 것에서 끝나지 않고, **실제로 화면이 렌더링되고 상호작용이 동작하는지 에이전트가 확인하게 할 수 있다는 것**입니다. 프론트엔드 작업에서는 다음과 같은 완료 조건을 함께 요청하는 것이 좋습니다. * 브라우저로 대상 페이지 열기 * 주요 버튼과 입력창 동작 확인 * 모바일·데스크톱 화면 점검 * 콘솔 오류 확인 * 발견한 문제를 수정한 뒤 다시 검증 *** ## 16\. 모델·추론 강도·속도 설정에 대한 설명 영상에서는 데모 당시 강사가 사용한 모델과 설정도 소개합니다. * 복잡한 개발 작업에는 높은 추론 강도 사용 * 라이브 방송에서는 빠른 진행을 위해 속도 옵션을 높임 * 속도를 높이면 결과가 빨리 나오지만 크레딧 소모도 빨라질 수 있음 * 실제 업무에서는 여러 세션을 병렬로 실행하므로 일반 속도로 충분할 수 있음 핵심은 한 작업이 가장 빨리 끝나는 것보다, 여러 작업을 병렬로 맡기고 각 에이전트가 충분히 검토하도록 운영하는 것이 더 효율적일 수 있다는 점입니다. *** ## 17\. GitHub 공개 API 연동 계획 목업 화면을 확인한 뒤 실제 GitHub 데이터를 연결합니다. 이 단계에서도 바로 구현하지 않고 필요한 결정을 다시 인터뷰합니다. ### 결정된 방향 * GitHub의 공개 데이터만 사용 * OAuth 로그인은 MVP 범위에서 제외 * 토큰 없이 호출 가능한 공개 REST API 사용 * 분석 점수는 설명 가능한 단순 규칙 기반으로 구성 * AI 기능은 후속 단계에서 추가 이후 인터뷰 결과를 바탕으로 GitHub API 연동 계획 문서를 작성합니다. *** ## 18\. 플랜 문서를 ‘외부 기억장치’로 활용하기 영상은 복잡한 작업일수록 인터뷰가 끝난 뒤 플랜 문서를 먼저 만들 것을 강조합니다. 작업이 길어지면 대화의 컨텍스트 윈도우가 점점 채워지고, 초반의 중요한 결정이 희미해질 수 있습니다. 반면 계획을 저장소 안의 파일로 남겨두면 에이전트가 대화 내용과 별개로 해당 문서를 다시 읽고 일관된 방향을 유지할 수 있습니다. 플랜 문서에는 다음 내용이 포함될 수 있습니다. * 기능의 목표 * MVP 범위와 제외 범위 * 사용자 흐름 * 데이터 계약 * API 구조 * 구현 단계 * 검증 방법 * 완료 조건 프로젝트별 계획이므로 일반적으로 전역 설정 폴더보다 **해당 프로젝트 저장소 안에 두는 방식**이 적합하다고 설명합니다. *** ## 19\. 계획을 HTML로 변환해 사람의 검토 속도 높이기 Markdown은 AI와 개발자가 구조적인 텍스트를 다루기에는 좋지만, 긴 계획을 사람이 짧은 시간 안에 검토하기에는 불편할 수 있습니다. 영상에서는 다음과 같은 요청을 사용합니다. > 지금 만든 플랜을 사람이 5분 안에 검토할 수 있는 단일 HTML 검토 화면으로 만들어줘. HTML 검토 화면에는 목표, 제외 범위, 사용자 흐름, API 계약 등이 시각적으로 정리됩니다. 이를 통해 사람이 중요한 항목을 빠르게 확인하고 승인할 수 있습니다. 이 방식은 계획뿐 아니라 다음 작업에도 응용할 수 있습니다. * 코드 리뷰 요약 * 아키텍처 변경 검토 * 데이터 흐름 확인 * 화면 요구사항 검토 * 릴리스 변경사항 검토 즉, AI에게 좋은 문서를 쓰게 하는 것뿐 아니라 **사람이 빠르게 승인할 수 있는 검토 인터페이스를 만들게 하는 것**도 하네스의 일부입니다. *** ## 20\. GitHub API 연동 결과 계획 검토 후 GitHub 공개 API를 실제 화면에 연결합니다. 사용자가 GitHub 사용자 이름을 입력하면 공개 계정 정보를 바탕으로 카드를 생성합니다. 실습 결과에서 확인된 기능은 다음과 같습니다. * GitHub 사용자 이름 입력 * 공개 계정 활동 분석 * RPG 클래스와 능력치 생성 * 짧은 분석 결과 표시 * 결과 URL 공유 * PDF 다운로드 이 시점까지는 설명 가능한 규칙 기반 분석이 중심이며, 이후 별도 작업으로 AI 생성 기능을 추가합니다. *** ## 21\. 기능 단위로 새 세션을 여는 이유 강사는 하나의 긴 대화에서 모든 기능을 계속 구현하기보다, 기능 단위로 새로운 세션을 여는 방식을 사용합니다. 예를 들어 다음처럼 분리합니다. * 세션 1: 기본 UI와 GitHub API 연동 * 세션 2: AI 기반 밈과 캐릭터 설명 생성 * 세션 3: 배포와 운영 설정 이렇게 하면 다음과 같은 장점이 있습니다. * 각 세션의 컨텍스트가 특정 기능에 집중 * 오래된 대화가 쌓여 성능이 떨어지는 문제 감소 * 독립적인 기능을 동시에 개발 가능 * 실패했을 때 영향을 받는 범위 축소 *** ## 22\. Worktree로 충돌 없이 병렬 개발하기 새로운 AI 기능은 기존 세션에서 계속 작업하지 않고, 새로운 세션과 Git Worktree를 생성해 별도의 작업 공간에서 구현합니다. Worktree를 사용하면 같은 저장소를 기반으로 하면서도 서로 다른 폴더에서 코드를 수정할 수 있습니다. ### 실습 구조 * **메인 작업 공간:** GitHub API 연동과 배포 진행 * **별도 Worktree:** OpenAI 모델을 이용한 AI 캐릭터·밈 생성 기능 구현 두 에이전트가 서로 다른 폴더에서 작업하므로 개발 중 파일 충돌이 줄어듭니다. 기능 구현이 끝나면 Worktree의 변경사항을 메인 브랜치에 병합합니다. ### Worktree가 유용한 상황 * 프론트엔드와 백엔드 동시 개발 * 기능 개발과 버그 수정 병렬 수행 * AI 기능과 배포 작업 동시 진행 * 서로 다른 해결책을 독립적으로 실험 * 여러 Codex 세션을 동시에 실행 *** ## 23\. GitHub 저장소 업로드 기본 기능이 동작하는 것을 확인한 뒤 프로젝트를 GitHub 저장소에 업로드합니다. 영상에서는 Codex가 저장소 생성과 코드 푸시 과정을 도와주며, 실제 저장소에 소스가 올라간 것을 확인합니다. 여기서 중요한 실무 원칙은 다음과 같습니다. * 로컬 검증이 끝난 상태를 먼저 저장소에 반영 * 병렬 작업은 별도 브랜치·Worktree에서 진행 * 공통 플랜과 규칙 문서는 메인 저장소에서 관리 * 기능이 완성된 뒤 검토하고 메인 브랜치에 병합 *** ## 24\. 플러그인으로 Vercel 배포하기 영상은 플러그인을 MCP와 Skills 같은 확장 기능을 설치하기 쉽게 묶어둔 번들 형태로 설명합니다. Codex에서 Vercel 플러그인을 선택한 뒤 다음과 같이 요청합니다. > Vercel을 사용해서 현재 GitHub 저장소에 올라간 프로젝트를 배포하고 싶은데 어떻게 하면 될까? 플러그인이 연결된 Vercel 계정과 프로젝트 정보를 확인하고, 저장소를 Vercel 프로젝트에 연결해 배포를 진행합니다. 이후 실제 배포 URL에서 Commit Hero가 실행되는 것을 확인합니다. 영상에서는 플러그인 목록에서 GitHub, Slack, Chrome, Notion, Gmail 등의 서비스 연결과 공식 Skills 설치도 가능하다고 소개합니다. *** ## 25\. AI 기능 추가와 Structured Output 별도 Worktree에서는 OpenAI 모델을 이용해 규칙 기반 결과보다 재미있는 캐릭터 설명과 밈을 생성하는 기능을 개발합니다. 영상에서 계획한 핵심 방향은 다음과 같습니다. * OpenAI API 연결 * 구조화된 출력(Structured Output) 사용 * 모델 결과를 정해진 데이터 구조로 받기 * 기존 카드 UI가 해당 데이터를 안정적으로 표시하도록 설계 * 기능 완성 후 메인 브랜치로 병합 Structured Output을 사용하면 모델이 자유로운 문장만 반환하는 대신, 클래스명·레벨·스킬·약점·설명처럼 애플리케이션이 요구하는 필드를 일정한 구조로 받을 수 있습니다. *** ## 26\. 환경변수와 비밀정보 보호 AI API를 사용하려면 API 키를 환경변수에 저장하고, 배포 환경인 Vercel에도 해당 환경변수를 설정해야 합니다. 영상은 실무에서 환경변수 파일이 유출되면 큰 문제가 되므로, 평소에는 에이전트가 비밀 파일에 접근하지 못하도록 Hook으로 차단한다고 설명합니다. ### 권장 원칙 * API 키를 소스 코드에 직접 작성하지 않기 * `.env` 파일을 Git 저장소에 커밋하지 않기 * 에이전트가 비밀 파일을 읽지 못하도록 차단하기 * 배포 서비스의 환경변수 관리 기능 사용 * 외부 전송과 배포 전 승인 절차 두기 * 로그에 비밀 값이 출력되지 않는지 확인하기 *** ## 27\. API 비용과 호출 제한 영상 실습에서는 두 가지 운영상 제약이 확인됩니다. ### OpenAI API 비용 AI 기능을 사용할 때마다 모델 API 요청이 발생하므로 사용량에 따라 비용이 부과됩니다. 따라서 실제 서비스에서는 다음과 같은 비용 통제 장치가 필요합니다. * 사용자별 호출 횟수 제한 * 전체 일일·월간 예산 설정 * 동일 요청 결과 캐시 * 입력 길이와 출력 토큰 제한 * 오류 발생 시 무제한 재시도 방지 * 비정상적인 요청 패턴 차단 ### GitHub 공개 API 제한 토큰 없이 GitHub 공개 API를 호출하는 방식은 구현이 간단하지만 호출 한도가 낮습니다. 라이브 시청자들이 동시에 테스트하면서 원본 IP 기준 시간당 호출 제한에 도달했고, 일부 조회가 정상적으로 처리되지 않는 상황이 발생합니다. 이 문제는 실제 서비스 설계에서 다음 사항을 검토해야 한다는 점을 보여줍니다. * 인증된 GitHub API 사용 여부 * 서버측 캐싱 * 요청 제한과 대기 안내 * 동일 사용자 정보의 중복 조회 방지 * 외부 API 장애 시 대체 화면 *** ## 28\. 영상에서 보여준 전체 개발 워크플로우 ``` flowchart TD A["러프한 서비스 아이디어"] --> B["Deep Interview"] B --> C["요구사항·MVP 확정"] C --> D["플랜 문서 작성"] D --> E["HTML로 사람 검토"] E --> F["목업 UI 구현"] F --> G["내장 브라우저 검증"] G --> H["GitHub API 연동"] H --> I["GitHub 푸시·Vercel 배포"] I --> J["Worktree에서 AI 기능 병렬 개발"] J --> K["메인 브랜치 병합·환경변수 설정"] K --> L["최종 배포와 운영 제한 확인"] ``` 이 흐름에서 하네스는 특정 기능 하나가 아니라 다음 요소들의 조합으로 나타납니다. * Deep Interview Skill로 요구사항 구체화 * 플랜 문서로 장기 작업의 방향 유지 * `AGENTS.md`로 프로젝트 규칙 고정 * 내장 브라우저로 실제 결과 검증 * Worktree로 병렬 작업 공간 분리 * 플러그인과 MCP로 GitHub·Vercel 연결 * Hooks로 비밀정보 접근 제한 * 새 세션과 Sub-agent로 전문 작업 분리 *** ## 29\. 실무에 적용할 수 있는 핵심 원칙 ### 1\. 처음부터 완벽한 프롬프트를 쓰려고 하지 않는다 러프한 아이디어를 전달한 뒤 AI에게 역으로 질문하도록 하면 요구사항을 더 쉽게 구체화할 수 있습니다. ### 2\. 인터뷰와 계획을 분리한다 인터뷰는 원하는 것을 발견하는 단계이고, 플랜은 결정된 내용을 실행 순서로 고정하는 단계입니다. ### 3\. 계획을 파일로 남긴다 대화에만 남겨두면 컨텍스트가 길어질수록 중요한 결정을 잃기 쉽습니다. 플랜 문서를 프로젝트 저장소에 저장해 외부 기억장치로 사용합니다. ### 4\. 사람의 검토 인터페이스를 따로 설계한다 Markdown 계획이 길다면 HTML 검토 화면이나 요약 대시보드로 변환해 빠르게 승인합니다. ### 5\. 구현 후 실제 화면을 검증한다 코드가 생성됐다는 사실을 완료로 보지 않고, 브라우저에서 실행·렌더링·상호작용을 확인합니다. ### 6\. 기능 단위로 세션과 작업 공간을 분리한다 한 세션에 모든 작업을 누적하지 않고, 기능별로 세션과 Worktree를 나눠 컨텍스트와 코드 충돌을 줄입니다. ### 7\. 지침과 강제를 구분한다 * AI가 판단하며 따라도 되는 내용: `AGENTS.md`, Skills * 반드시 막거나 실행해야 하는 내용: Hooks ### 8\. 외부 서비스 연동에는 운영 조건이 따라온다 MCP와 플러그인은 개발과 배포를 편리하게 하지만, 권한·비밀정보·호출 제한·API 비용을 함께 설계해야 합니다. *** ## 30\. Codex 프로젝트 시작 체크리스트 ### 기획 * 서비스를 한 문장으로 설명할 수 있는가? * AI에게 역질문 인터뷰를 요청했는가? * 핵심 사용자와 성공 기준이 정해졌는가? * MVP와 제외 범위가 구분되어 있는가? ### 하네스 * 프로젝트 루트에 `AGENTS.md`가 있는가? * 팀의 코딩·테스트·검증 규칙이 명시되어 있는가? * 반복 절차를 Skill로 분리할 필요가 있는가? * 필요한 외부 서비스를 MCP나 플러그인으로 연결했는가? * 비밀 파일과 위험 명령을 Hooks로 제한했는가? * 전문 작업을 Sub-agent에 위임할 필요가 있는가? ### 계획과 구현 * 인터뷰 결과를 플랜 문서로 저장했는가? * 목표, 제외 범위, 데이터 계약과 완료 조건이 있는가? * 긴 계획을 사람이 빠르게 검토할 화면이 있는가? * 목업 UI로 방향을 먼저 검증했는가? * 기능 단위로 세션을 분리했는가? * 병렬 작업에는 Worktree를 사용했는가? ### 검증과 배포 * 테스트·린트·빌드가 성공하는가? * 실제 브라우저에서 핵심 사용자 흐름을 검증했는가? * API 키가 코드와 로그에 노출되지 않는가? * 배포 환경변수가 올바르게 설정됐는가? * 외부 API 호출 제한과 장애 상황을 처리하는가? * AI API 비용과 호출 횟수에 상한이 있는가? *** ## 31\. 타임라인별 상세 목차 | 시간 | 내용 | | --- | --- | | **00:00** | 오늘 다룰 내용: Codex 하네스와 실전 서비스 빌드 | | **01:00** | 하네스 엔지니어링이 중요한 이유 | | **02:00** | Codex 하네스의 6가지 구성요소 | | **05:00** | 설정 경로와 `AGENTS.md`의 전역·프로젝트 규칙 | | **08:00** | Memory와 Skills의 역할 | | **11:00** | MCP, Hooks, Sub-agents | | **15:59** | Commit Hero 실습 시작 | | **20:00** | 러프한 프롬프트로 서비스 아이디어 제시 | | **21:00** | Deep Interview로 요구사항 구체화 | | **26:54** | Next.js 목업 UI 구현 요청 | | **27:59** | Codex 내장 브라우저로 화면 검증 | | **31:30** | GitHub 공개 API 연동 방향 결정 | | **33:00** | 플랜 문서 작성과 컨텍스트 관리 | | **34:43** | 플랜을 단일 HTML 검토 화면으로 변환 | | **38:00** | Codex Memory 활성화 방법 | | **38:55** | GitHub API 연동 결과 확인 | | **39:40** | 새 세션과 Worktree로 AI 기능 병렬 구현 | | **41:20** | GitHub 업로드와 Vercel 플러그인 배포 흐름 | | **45:27** | Vercel 배포 결과 확인 | | **46:00** | Hooks로 환경변수 파일 보호 | | **47:00** | Worktree 위치와 메인 브랜치 병합 | | **48:08** | AI API 비용과 호출 방식 설명 | | **48:50** | AI 기능과 배포 환경변수 확인 | | **49:16** | GitHub 공개 API 호출 제한 발생 | | **49:50** | 전체 서비스 빌드 워크플로우 정리 | *** ## 32\. 최종 정리 이 영상에서 소개하는 Codex 활용법의 핵심은 AI에게 코드를 한 번 생성해 달라고 요청하는 것이 아닙니다. 프로젝트를 안정적으로 진행하기 위한 **규칙, 인터뷰, 계획, 작업 공간, 검증, 외부 연동과 안전장치**를 하나의 반복 가능한 개발 환경으로 설계하는 것입니다. 핵심 내용을 다섯 문장으로 압축하면 다음과 같습니다. 1. **`AGENTS.md`는 AI가 계속 따라야 할 프로젝트 규칙을 고정합니다.** 2. **Skills는 반복 업무를 재사용 가능한 워크플로우로 바꿉니다.** 3. **플랜 문서는 긴 작업에서 목표를 잃지 않게 하는 외부 기억장치입니다.** 4. **새 세션과 Worktree는 여러 기능을 충돌 없이 병렬 개발하게 합니다.** 5. **MCP·플러그인·Hooks는 실제 서비스 연동과 배포를 가능하게 하지만, 권한·비밀정보·비용 제한을 함께 설계해야 합니다.** 결국 하네스 엔지니어링은 AI의 자율성을 무작정 높이는 방법이 아니라, **AI가 자율적으로 판단해도 되는 영역과 반드시 지켜야 할 영역을 구분하고, 그 경계를 문서와 시스템으로 구현하는 과정**입니다. *** ## 참고 자료 * 원본 영상: [https://www.youtube.com/watch?v=wScdyoQjj8E](https://www.youtube.com/watch?v=wScdyoQjj8E) * 라이브 전체 영상: [https://youtube.com/live/F5pr-hfyuEE](https://youtube.com/live/F5pr-hfyuEE) * 강의 자료: [https://devbrothers.ai/lectures/codex/harness-engineering/](https://devbrothers.ai/lectures/codex/harness-engineering/) * Commit Hero 소스코드: [https://github.com/devbrother2024/commit-hero](https://github.com/devbrother2024/commit-hero) * OpenAI Codex: [https://openai.com/ko-KR/codex/](https://openai.com/ko-KR/codex/) ## 작성 기준 * 영상 설명란의 공식 타임라인과 전체 한국어 자막을 기준으로 정리했습니다. * 자동 생성 자막의 명백한 오인식은 영상 문맥에 맞게 교정했습니다. * 체크리스트와 권장 원칙은 영상의 설명과 실습 흐름을 실제 프로젝트에 적용하기 쉽게 재구성한 내용입니다.]]> 최고관리자 2026-08-29T20:42:02+09:00 https://ai.23yellow.com/ai_Engineering_01/%EB%A3%A8%ED%94%84-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-10%EB%B6%84%EB%A7%8C%EC%97%90-%EA%B0%80%EC%9E%A5-%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85%ED%95%B4%EB%93%9C%EB%A0%A4%EC%9A%94%E3%85%A3%ED%95%B5%EC%8B%AC-%EA%B0%9C%EB%85%90-%EB%8F%84%EC%9E%85/ 루프 엔지니어링 10분 핵심 정리 > **원본 영상:** [루프 엔지니어링 10분만에 가장 쉽게 설명해드려요｜핵심 개념, 도입 효과, 실제 예시](https://www.youtube.com/watch?v=9tVJb46g7nA) > **채널:** 이동훈의 루트AI > **게시일:** 2026년 8월 12일 > **영상 길이:** 9분 51초 > **주제:** 프롬프트 엔지니어링에서 루프 엔지니어링으로 이어지는 AI 활용 방식의 변화 *** ## 1\. 영상의 핵심 메시지 이 영상이 말하는 \*\*루프 엔지니어링(Loop Engineering)\*\*은 사람이 AI에게 매번 다음 행동을 지시하는 방식에서 벗어나, AI가 **정해진 조건에 따라 작업을 시작하고, 실행 결과를 검증하고, 부족하면 다시 시도하며, 완료 조건을 만족하면 스스로 멈추도록 반복 구조를 설계하는 것**입니다. 한 문장으로 줄이면 다음과 같습니다. > **“AI에게 일을 잘 시키는 기술”을 넘어, “AI가 스스로 계속 일하도록 업무를 위임하는 기술”이다.** 영상은 이를 신입사원에게 매번 세부 지시를 내리는 단계에서, 일정 기간 경험을 쌓은 직원에게 업무 주기·매뉴얼·검증 기준·보고 조건까지 포함해 일을 통째로 위임하는 단계로 발전하는 것에 비유합니다. 다만 AI는 사람처럼 근무 경험이 자연스럽게 축적되지 않습니다. 대화가 끝나면 이전 작업의 세부 맥락을 잊기 쉽고, 모르는 내용을 자신 있게 추측할 수도 있습니다. 따라서 AI가 숙련된 직원처럼 일하게 하려면 **반복 실행 구조, 업무 매뉴얼, 외부 도구, 독립적인 검증자, 진행 상태 기록**을 시스템으로 마련해야 합니다. *** ## 2\. AI를 다루는 기술의 4단계 영상은 AI 활용 방식이 다음 네 단계로 발전했다고 설명합니다. | 단계 | 핵심 질문 | 주요 역할 | 간단한 예시 | | --- | ----- | ----- | ------ | | **프롬프트 엔지니어링** | AI에게 어떻게 질문할 것인가? | 한 번의 요청을 명확하고 효과적으로 작성 | “너는 10년 차 마케터야. 이 톤으로 작성해 줘.” | | **컨텍스트 엔지니어링** | 판단에 필요한 무엇을 보여줄 것인가? | 사내 자료, 과거 회의록, 브랜드 문체와 같은 배경정보 제공 | 회사 자료와 기존 문서를 함께 전달 | | **하네스 엔지니어링** | AI가 어떤 환경에서 일하게 할 것인가? | 도구, 규칙, 권한, 자료 접근 환경을 구성 | 업무 규칙 문서, 파일 접근, 실행 도구 제공 | | **루프 엔지니어링** | AI가 언제 시작하고, 반복하며, 멈추게 할 것인가? | 작업의 시작·실행·검증·재시도·종료 구조 설계 | 새 메일이 오면 처리하고, 기준을 만족할 때까지 수정 | ### 2.1 프롬프트 엔지니어링 프롬프트 엔지니어링은 AI에게 **한 번의 질문이나 지시를 잘 전달하는 기술**입니다. 역할, 목표, 출력 형식, 말투 등을 구체적으로 정해 더 나은 답변을 얻는 방식입니다. 이 단계에서는 사람이 매 요청마다 AI를 호출하고, 결과를 확인한 뒤 다음 지시를 다시 입력합니다. 따라서 작업 진행의 중심에는 계속 사람이 있습니다. ### 2.2 컨텍스트 엔지니어링 좋은 질문만으로는 회사나 프로젝트의 특수한 상황을 AI가 알 수 없습니다. 컨텍스트 엔지니어링은 AI가 올바르게 판단하는 데 필요한 **배경정보 전체를 선별하고 구성해 제공하는 기술**입니다. 예를 들면 다음과 같습니다. * 회사 내부 자료 * 이전 회의록과 의사결정 기록 * 브랜드의 톤앤매너 * 프로젝트 요구사항 * 참고 문서와 기존 결과물 즉, 프롬프트가 “무엇을 시킬 것인가”에 집중한다면, 컨텍스트는 “AI가 일을 이해하려면 무엇을 알아야 하는가”에 집중합니다. ### 2.3 하네스 엔지니어링 하네스 엔지니어링은 AI가 일할 수 있도록 **업무 환경 전체를 마련하는 단계**입니다. 영상은 이를 새 직원에게 책상, 노트, 사내 규칙, 온보딩 자료와 업무 도구를 제공하는 것에 비유합니다. 대표적인 구성 요소는 다음과 같습니다. * AI가 사용할 수 있는 도구 * 반드시 따라야 하는 업무 규칙 * 참고해야 할 문서와 데이터 * 파일·메일·메신저 등에 접근할 수 있는 권한 * 결과를 검사하거나 실행할 수 있는 환경 ### 2.4 루프 엔지니어링 루프 엔지니어링에서는 이전 세 단계와 비교해 한 가지가 크게 달라집니다. > 이전 단계는 **사람이 시킬 때 AI가 잘 움직이게 하는 기술**이고, 루프 엔지니어링은 **사람이 매번 시키지 않아도 AI가 돌아가게 만드는 기술**이다. 영상은 이 개념이 2026년 6월 구글의 엔지니어 Addy Osmani가 글로 정리하면서 빠르게 알려졌다고 설명합니다. *** ## 3\. 선풍기와 에어컨으로 이해하는 루프 영상은 일반적인 AI 사용과 루프 방식의 차이를 선풍기와 에어컨에 비유합니다. ### 선풍기 방식: 사람이 계속 개입 * 더우면 사람이 직접 켭니다. * 추워지면 사람이 직접 끕니다. * 상태를 계속 확인하고 조작해야 합니다. 이는 AI에게 프롬프트를 입력하고, 결과를 확인하고, 수정 요청을 다시 입력하는 기존 방식과 비슷합니다. ### 에어컨 방식: 목표만 설정 * 목표 온도를 26도로 설정합니다. * 현재 온도를 측정합니다. * 26도보다 높으면 냉방을 실행합니다. * 목표 온도에 도달하면 멈춥니다. * 온도가 다시 올라가면 냉방을 재개합니다. 이 구조를 AI 작업에 옮기면 다음과 같습니다. 1. **목표를 정한다.** 2. **작업을 실행한다.** 3. **결과를 확인한다.** 4. **완료 기준을 만족하면 멈춘다.** 5. **만족하지 못하면 수정하고 다시 실행한다.** 여기서 가장 중요한 차이가 있습니다. 에어컨에는 온도계가 이미 달려 있지만, **AI 루프의 ‘온도계’, 즉 완료 여부를 판단하는 기준은 사람이 직접 설계해야 합니다.** 완료 기준이 없거나 모호하면 AI는 작업이 끝났는지 판단하지 못하고 계속 반복할 수 있습니다. *** ## 4\. 루프 엔지니어링은 ‘업무 위임의 기술’이다 영상은 루프 엔지니어링을 회사의 신입사원 교육과 업무 위임 과정으로 설명합니다. ### 입사 첫날의 직원 처음 입사한 직원에게는 다음처럼 하나씩 지시합니다. * “이 업무를 해보세요.” * “이 부분이 틀렸으니 다시 수정해 주세요.” * “이번에는 이 형식으로 작성해 주세요.” 이 방식은 사람이 매번 AI에게 프롬프트를 입력하는 것과 같습니다. ### 6개월 차 직원 업무에 익숙해진 직원에게는 다음처럼 일 전체를 위임할 수 있습니다. > “매주 금요일까지 주간보고서를 올려주세요. 양식은 여기에 있고, 숫자가 맞지 않으면 재무팀에 확인하고, 판단하기 애매하면 저에게 물어보세요.” 이 지시에는 루프의 주요 요소가 모두 포함되어 있습니다. | 요소 | 위 예시에서의 의미 | | --- | ---------- | | **주기·트리거** | 매주 금요일 | | **목표** | 주간보고서 작성 및 제출 | | **매뉴얼** | 지정된 보고서 양식 | | **검증** | 숫자가 맞는지 확인 | | **외부 협업** | 재무팀에 확인 | | **사람에게 이관** | 판단하기 애매하면 담당자에게 질문 | ### AI가 가진 문제 AI는 한 번 잘 가르쳤다고 해서 실제 직원처럼 경험이 계속 쌓이지 않습니다. * 대화가 끝나면 이전 맥락을 잊을 수 있습니다. * 다음 실행에서는 다시 ‘입사 첫날’처럼 행동할 수 있습니다. * 모르는 정보를 모른다고 말하지 않고 추측해 채울 수 있습니다. * 작업 진행 상태를 외부에 기록하지 않으면 처음부터 같은 일을 반복할 수 있습니다. 따라서 루프 엔지니어링의 목적은 **‘영원히 입사 첫날인 AI’를 시스템의 도움으로 ‘6개월 차 직원처럼’ 일하게 만드는 것**이라고 정리할 수 있습니다. *** ## 5\. 이너 루프와 아우터 루프 영상은 AI의 반복 구조를 \*\*이너 루프(Inner Loop)\*\*와 \*\*아우터 루프(Outer Loop)\*\*로 나눕니다. ### 5.1 이너 루프 이너 루프는 AI가 한 번의 작업 세션 안에서 수행하는 작은 반복입니다. 1. 상황을 생각합니다. 2. 필요한 도구를 사용합니다. 3. 실행 결과를 확인합니다. 4. 결과를 바탕으로 다시 판단합니다. 이는 Claude Code와 같은 에이전트형 AI 도구 안에 이미 구현되어 있으므로 사용자가 처음부터 다시 만들 필요는 없습니다. ### 5.2 아우터 루프 아우터 루프는 이너 루프를 둘러싼 더 큰 운영 구조입니다. 루프 엔지니어링이 실제로 설계하는 대상은 주로 이 아우터 루프입니다. 아우터 루프에서는 다음을 결정합니다. * 작업을 **언제 시작할 것인가** * AI에게 **어떤 일을 맡길 것인가** * 결과가 완료됐는지를 **누가, 무엇으로 판단할 것인가** * 실패하면 **몇 번, 어떤 방식으로 다시 시도할 것인가** * 어떤 상황에서 **사람에게 넘길 것인가** * 비용이나 시간이 어느 수준에 도달하면 **멈출 것인가** 즉, 이너 루프가 AI 한 명의 작업 과정이라면, 아우터 루프는 그 AI가 반복적으로 일하도록 관리하는 **업무 운영 시스템**입니다. *** ## 6\. 루프를 구성하는 5가지 부품과 1개의 기억장치 영상은 루프를 만드는 데 필요한 요소를 **5가지 핵심 부품과 1개의 상태 기억장치**로 정리합니다. | 번호 | 구성 요소 | 담당 역할 | 회사 업무에 비유하면 | | --- | ----- | ----- | ----------- | | 1 | **자동화** | 루프가 시작되는 시점 결정 | 출근 시간이나 업무 접수 알림 | | 2 | **작업 공간 분리** | 여러 AI의 작업 충돌 방지 | 직원마다 문서 사본을 따로 제공 | | 3 | **스킬** | 반복 사용할 업무 방식과 노하우 제공 | 업무 매뉴얼 | | 4 | **MCP·커넥터** | 외부 서비스의 데이터와 기능 사용 | 사무실·메일·업무 시스템 접근 권한 | | 5 | **서브에이전트** | 결과를 독립적으로 검사 | 작성자와 별도의 검토자 | | 6 | **상태 파일** | 이전 작업의 진행 상황 기억 | 인수인계 노트 | ### 6.1 자동화: 언제 시작할지 정한다 아무리 좋은 매뉴얼과 도구를 제공해도 AI가 실행되지 않으면 아무 일도 일어나지 않습니다. 따라서 루프에는 시작 조건이 필요합니다. 예시는 다음과 같습니다. * 매일 오전 9시에 실행 * 새 이메일이 도착할 때 실행 * 특정 폴더에 자료가 업로드될 때 실행 * 코드 저장소에 변경 사항이 생길 때 실행 * 매주 정해진 요일에 보고서 생성 이와 같은 트리거가 없다면 반복 운영되는 루프가 아니라, 사람이 한 번 실행한 단발성 작업에 가깝습니다. ### 6.2 작업 공간 분리: 충돌을 막는다 여러 AI가 동시에 동일한 파일을 수정하면 작업 결과가 충돌할 수 있습니다. 두 사람이 같은 문서를 각자 수정한 뒤 저장하면 어느 파일이 최종본인지 알기 어려운 것과 같습니다. 따라서 각 AI에게 독립된 작업 사본을 제공하고, 작업이 끝난 뒤 검토를 거쳐 결과를 합쳐야 합니다. 개발 환경에서는 이런 독립 작업 공간의 예로 \*\*Git 워크트리(worktree)\*\*를 사용할 수 있습니다. 핵심 원칙은 간단합니다. > **여러 AI에게 동시에 일을 시키려면 먼저 작업 공간과 파일 사본을 분리한다.** ### 6.3 스킬: 회사의 업무 매뉴얼을 제공한다 스킬은 AI가 반복해서 따라야 할 **업무 절차, 회사 규칙, 문체, 출력 형식, 품질 기준과 노하우를 문서화한 것**입니다. 스킬이 없으면 루프가 실행될 때마다 AI는 회사의 방식과 사용자의 의도를 새로 추측하게 됩니다. 그 결과 실행할 때마다 품질과 형식이 달라질 수 있습니다. 반대로 스킬을 만들어 두면 다음과 같은 효과를 기대할 수 있습니다. * 동일한 기준으로 반복 작업 수행 * 결과물의 형식과 품질을 일정하게 유지 * 사람이 매번 같은 설명을 입력하는 수고 감소 * 개인의 암묵적인 노하우를 재사용 가능한 절차로 전환 ### 6.4 MCP·커넥터: 실제 업무 시스템에 접근한다 AI가 파일 내부의 내용만 볼 수 있다면 현실의 업무를 끝까지 수행하기 어렵습니다. 메일을 읽고, 메신저에 결과를 공유하고, 스프레드시트에서 데이터를 가져오고, 노션에 결과를 정리하려면 외부 서비스와 연결할 수 있어야 합니다. MCP 또는 커넥터는 AI에게 다음 두 가지를 제공합니다. 1. 외부 정보와 서비스에 접근할 수 있는 **권한** 2. 해당 서비스에서 실제 행동을 수행할 수 있는 **도구** 이 연결을 통해 AI는 단순히 “이렇게 하면 됩니다”라고 답하는 수준을 넘어, 허용된 범위 안에서 실제 업무를 처리할 수 있습니다. ### 6.5 서브에이전트: 만드는 역할과 검사하는 역할을 분리한다 사람도 자신이 작성한 결과물을 스스로 검토하면 오류를 놓치기 쉽습니다. 영상은 AI 역시 자신이 만든 결과물에 관대할 수 있다고 설명합니다. 따라서 다음처럼 역할을 분리합니다. * **생성 에이전트:** 자료 조사, 문서 작성, 코드 구현 등 실제 결과물 생성 * **검증 에이전트:** 누락, 오류, 규칙 위반, 완료 조건 충족 여부를 의심하며 검사 두 에이전트에 서로 다른 지시문을 주거나, 필요하면 다른 AI 모델을 사용하는 방법도 제안합니다. 사람이 직접 지켜보지 않는 동안 루프를 안전하게 운영하려면 결과를 비판적으로 확인하는 독립 검증자가 필요합니다. ### 6.6 상태 파일: 어제까지의 진행 상황을 기억한다 스킬이 **회사의 업무 방식**을 기억하는 장치라면, 상태 파일은 **현재 작업이 어디까지 진행됐는지**를 기억하는 장치입니다. 상태 파일에는 다음 내용을 기록할 수 있습니다. * 이번 실행에서 완료한 작업 * 아직 남아 있는 작업 * 실패한 시도와 실패 원인 * 다음 실행에서 해야 할 일 * 검증 결과와 수정 내역 * 사람이 판단해야 할 문제 영상은 이를 퇴근 전에 작성하는 **인수인계 노트**에 비유합니다. 상태를 대화 밖의 파일에 기록해야 다음 실행이 어제 멈춘 지점에서 이어질 수 있습니다. 정리하면 다음과 같습니다. * **스킬 = 반복해서 지켜야 할 업무 매뉴얼** * **상태 파일 = 현재 업무를 이어가기 위한 인수인계 노트** 이 두 장치가 AI에게 실제 직원의 ‘6개월 경험’을 대신 제공하며, 나머지 자동화·작업 공간·커넥터·서브에이전트는 AI가 그 경험을 바탕으로 일할 수 있게 만드는 실행 조건입니다. *** ## 7\. 가장 중요한 설계 요소: 종료 조건 영상이 가장 강조하는 부분은 **AI가 언제 멈춰야 하는지를 명확히 설계하는 것**입니다. 종료 조건이 없는 루프는 온도계가 없는 에어컨과 같습니다. 목표에 도달했는지 알 수 없으므로 계속 실행되고, 그 과정에서 시간과 토큰 비용이 누적됩니다. ### 7.1 두 가지 종료 방식 #### 횟수 기반 종료 정해진 횟수까지만 반복합니다. * 최대 3회 수정 * 최대 5번 재시도 * 검토 에이전트의 재검증은 2회로 제한 설계하기 쉽고 비용을 통제할 수 있지만, 최대 횟수에 도달했다고 해서 결과가 완성됐다는 보장은 없습니다. #### 조건 기반 종료 검증 가능한 완료 조건을 만족할 때까지 반복합니다. * 모든 필수 항목이 작성됨 * 숫자의 출처가 전부 링크됨 * 자동 테스트가 모두 통과함 * 지정된 형식과 글자 수를 만족함 * 검토 에이전트가 오류 없음으로 판정함 영상은 조건 기반 종료가 더 강력하지만, 조건이 **누가 판단해도 참·거짓을 구분할 수 있을 정도로 구체적이어야 한다**고 강조합니다. ### 7.2 나쁜 완료 조건과 좋은 완료 조건 | 모호한 조건 | 검증 가능한 조건 | | ------ | --------- | | 좋은 보고서가 될 때까지 | 필수 항목 5개가 모두 채워질 때까지 | | 내용이 충분할 때까지 | 각 주장에 근거 자료가 하나 이상 연결될 때까지 | | 디자인이 보기 좋을 때까지 | 지정된 컬러·폰트·간격 규칙을 모두 통과할 때까지 | | 코드가 잘 작동할 때까지 | 테스트·린트·빌드가 모두 성공할 때까지 | ### 7.3 반드시 겹쳐 두어야 할 안전장치 영상은 루프를 운영할 때 하나의 종료 조건만 믿지 말고 다음 안전장치를 여러 겹으로 설정해야 한다고 설명합니다. 1. **검증 통과 조건:** 객관적인 완료 기준을 만족해야 종료 2. **최대 반복 횟수:** 일정 횟수 이상 반복하지 않도록 제한 3. **시간·비용 한도:** 정해진 실행 시간이나 토큰 비용을 넘으면 중단 4. **진전 없음 감지:** 같은 오류를 반복하거나 결과가 개선되지 않으면 중단 필요한 경우 루프를 무조건 실패로 끝내는 대신, 상태와 문제를 기록한 뒤 사람에게 판단을 요청하도록 **에스컬레이션 조건**도 함께 설계해야 합니다. *** ## 8\. 영상 내용을 실무 흐름으로 재구성한 예시 ### 예시: 매주 자동으로 주간보고서 만들기 #### 목표 매주 금요일 오후까지 팀의 업무 데이터로 주간보고서를 작성하고 지정된 공간에 등록합니다. #### 루프 설계 1. **트리거:** 매주 금요일 오전 9시에 자동 실행 2. **자료 수집:** 메일, 스프레드시트, 프로젝트 관리 도구에서 주간 데이터 수집 3. **작업 공간 분리:** 이번 주 보고서 전용 사본 생성 4. **스킬 적용:** 회사 보고서 양식, 문체, 필수 항목, 금지 표현 적용 5. **초안 생성:** 작성 에이전트가 보고서 초안 작성 6. **독립 검증:** 검토 에이전트가 수치·누락·출처·형식 검사 7. **재시도:** 실패한 항목만 수정하고 다시 검증 8. **완료:** 모든 필수 항목과 출처가 확인되면 보고서 등록 9. **사람에게 이관:** 숫자가 서로 충돌하거나 판단이 애매하면 담당자에게 질문 10. **상태 기록:** 사용한 자료, 수정 내역, 미해결 문제, 최종 결과 위치 저장 #### 종료 조건 예시 * 필수 항목 5개가 모두 존재 * 모든 핵심 수치가 원본 데이터와 일치 * 모든 수치에 출처 링크가 연결됨 * 회사 지정 양식 준수 * 검증 에이전트 승인 * 최대 수정 3회 * 총 실행 시간 30분 이하 이 예시의 핵심은 보고서 작성 프롬프트 하나를 길게 만드는 것이 아닙니다. **업무가 시작되는 순간부터 자료 수집, 작성, 검토, 수정, 완료, 이관, 기록까지 전체 흐름을 설계하는 것**이 루프 엔지니어링입니다. *** ## 9\. 도입 효과 영상의 설명을 바탕으로 정리하면 루프 엔지니어링의 주요 효과는 다음과 같습니다. ### 반복 업무의 자동화 사람이 매번 AI를 호출하고 다음 프롬프트를 입력하는 과정이 줄어듭니다. 정해진 시간이나 사건을 기준으로 업무가 자동 시작됩니다. ### 품질의 일관성 향상 스킬과 검증 조건을 적용하면 실행할 때마다 회사 규칙과 동일한 품질 기준을 반복해서 적용할 수 있습니다. ### 사람의 병목 감소 사람이 모든 중간 결과를 직접 확인하고 다음 행동을 지시할 필요가 줄어듭니다. 사람은 예외 상황과 중요한 의사결정에 집중할 수 있습니다. ### 여러 AI의 협업 가능 작성, 조사, 검증 등의 역할을 나누고 작업 공간을 분리하면 여러 에이전트를 동시에 활용할 수 있습니다. ### 장기 작업의 연속성 확보 상태 파일을 이용하면 대화가 끝나거나 실행이 중단돼도 이전 진행 상황을 바탕으로 다음 작업을 이어갈 수 있습니다. ### 실제 업무 수행 범위 확대 MCP나 커넥터를 통해 이메일, 메신저, 문서, 스프레드시트 등의 외부 서비스와 연결하면 AI가 조언만 하는 것을 넘어 실제 업무 처리 과정에 참여할 수 있습니다. *** ## 10\. 주의할 점과 실패 패턴 ### 완료 기준이 모호한 경우 “최대한 잘 만들어라”처럼 주관적인 기준만 있으면 AI가 작업 완료 여부를 판정하기 어렵습니다. 객관적으로 검사할 수 있는 항목으로 바꿔야 합니다. ### 종료 제한이 없는 경우 검증을 통과하지 못할 때 무제한으로 재시도하면 비용과 시간이 계속 증가합니다. 반복 횟수와 실행 예산을 반드시 제한해야 합니다. ### 생성과 검증을 같은 역할에 맡긴 경우 자신이 만든 결과를 자신이 검사하면 오류를 놓칠 가능성이 높습니다. 가능하면 생성자와 검증자의 역할과 지시를 분리해야 합니다. ### 상태를 대화 안에만 남긴 경우 대화가 종료되거나 컨텍스트가 초기화되면 작업의 연속성이 끊깁니다. 진행 상태와 다음 행동을 외부 파일에 저장해야 합니다. ### 여러 AI가 같은 파일을 동시에 수정하는 경우 충돌과 덮어쓰기가 발생할 수 있으므로 에이전트별 작업 공간을 분리하고, 결과를 합치는 절차를 따로 둬야 합니다. ### 외부 접근 권한을 과도하게 준 경우 영상은 MCP와 커넥터의 업무 수행 능력을 강조합니다. 실제 도입 시에는 AI에게 필요한 범위의 권한만 주고, 중요한 변경이나 외부 전송에는 승인 절차를 두는 것이 안전합니다. *** ## 11\. 처음 루프를 만들 때 사용할 체크리스트 * 반복할 업무가 명확하게 정해져 있는가? * 루프를 시작할 시간 또는 사건이 정의되어 있는가? * AI가 따라야 할 매뉴얼과 품질 기준이 문서화되어 있는가? * 필요한 자료와 외부 도구에 접근할 방법이 있는가? * 여러 AI가 동시에 작업할 경우 작업 공간이 분리되어 있는가? * 결과를 만든 역할과 검사하는 역할이 분리되어 있는가? * 완료 여부를 참·거짓으로 판정할 수 있는가? * 최대 반복 횟수가 정해져 있는가? * 시간과 비용의 상한이 정해져 있는가? * 결과가 개선되지 않을 때 중단할 수 있는가? * AI가 해결하지 못하는 문제를 사람에게 넘기는 기준이 있는가? * 이전 작업의 진행 상황을 외부 상태 파일에 기록하는가? *** ## 12\. 타임라인별 상세 목차 | 시간 | 내용 | | --- | --- | | **00:00** | 오프닝: Claude Code 책임자의 “이제 프롬프트 대신 루프를 설계한다”는 발언 소개 | | **00:38** | AI를 다루는 네 가지 기술의 전체 구조 | | **00:45** | 프롬프트 엔지니어링 | | **00:57** | 컨텍스트 엔지니어링 | | **01:09** | 하네스 엔지니어링 | | **01:28** | 루프 엔지니어링과 이전 단계의 차이 | | **01:59** | 선풍기·에어컨 비유로 이해하는 루프 | | **02:56** | 업무 위임의 기술과 신입사원 비유 | | **04:08** | 이너 루프와 아우터 루프 | | **04:46** | 자동화, 작업 공간, 스킬, MCP, 서브에이전트, 상태 파일 | | **08:29** | 종료 조건과 비용 통제를 위한 안전장치 | *** ## 13\. 최종 정리 루프 엔지니어링의 핵심은 단순히 AI를 여러 번 실행하는 데 있지 않습니다. **목표와 완료 조건을 먼저 정의하고, 실행·검증·수정·기록이 스스로 이어지는 반복 구조를 설계하는 것**이 핵심입니다. 특히 다음 세 가지를 기억하면 영상의 내용을 압축해서 이해할 수 있습니다. 1. **프롬프트는 한 번의 지시를 개선하고, 루프는 반복되는 업무 전체를 설계한다.** 2. **스킬과 상태 파일이 AI에게 매뉴얼과 업무 경험을 대신 제공한다.** 3. **좋은 루프의 핵심은 실행 횟수가 아니라 검증 가능한 종료 조건이다.** 결국 루프 엔지니어링은 AI에게 더 길고 복잡한 프롬프트를 쓰는 방법이 아니라, 사람이 매번 개입하지 않아도 AI가 정해진 범위 안에서 **일을 시작하고, 확인하고, 고치고, 끝낼 수 있게 만드는 운영 설계 방식**입니다. *** ## 출처 및 작성 기준 * 원본 영상: [https://www.youtube.com/watch?v=9tVJb46g7nA](https://www.youtube.com/watch?v=9tVJb46g7nA) * 영상 설명란의 공식 타임라인과 한국어 자막을 기준으로 정리했습니다. * 자동 생성 자막의 명백한 오인식은 영상 문맥에 맞게 교정했습니다. * 실무 예시와 체크리스트는 영상에서 설명한 개념을 이해하기 쉽게 재구성한 내용입니다.]]> 최고관리자 2026-08-29T20:29:47+09:00 https://ai.23yellow.com/ai_Engineering_01/%ED%95%98%EB%84%A4%EC%8A%A4-%EB%A7%90%EA%B3%A0-%EB%A3%A8%ED%94%84-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81%EB%8F%84-%EB%82%98%EC%99%94%EB%8B%A4%EA%B3%A0-4%EB%B6%84%EB%A7%8C%EC%97%90-%EA%B0%84%EB%8B%A8%ED%95%98%EA%B2%8C-%EC%84%A4%EB%AA%85%ED%95%B4%EB%93%9C%EB%A6%BC/ 최고관리자 2026-08-29T20:26:52+09:00 https://ai.23yellow.com/ai_Engineering_01/%ED%95%98%EB%84%A4%EC%8A%A4-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-15%EB%B6%84-%EB%A7%8C%EC%97%90-%EC%9D%B4%ED%95%B4%EC%8B%9C%EC%BC%9C%EB%93%9C%EB%A6%BD%EB%8B%88%EB%8B%A4-%EA%B0%9C%EB%85%90-%ED%95%B5%EC%8B%AC/ 최고관리자 2026-08-29T20:16:02+09:00 https://ai.23yellow.com/ai_Engineering_01/openai-codex%EB%A1%9C-%ED%95%98%EB%8A%94-%ED%95%98%EB%84%A4%EC%8A%A4-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-%EC%8B%A4%EC%8A%B5-%EC%9A%94%EC%95%BD%EB%B3%B8-%EB%9D%BC%EC%9D%B4%EB%B8%8C/ 최고관리자 2026-08-29T20:14:22+09:00