← 과정 목록으로

찾아가는교육모집중오프라인

AX 키트 - 개발직

개발 생산성을 극대화하는 AI 에이전트 엔지니어링 구현 실무

단순한 코딩 보조를 넘어, 하네스를 구성하고 스펙 주도 개발로 운영 체계를 완성하는 전 과정을 실습합니다.

#AI에이전트#하네스엔지니어링#SDD#품질게이트

모집 기간

상시 모집

교육 일시

상시 편성

방식

오프라인

교육 도입 문의

ENGINEERING AX KIT 코드를 생성하는 AI에서 검증 가능한 개발을 수행하는 에이전트로 AI에게 코드를 요청하는 데서 멈추지 않습니다. 작업 단위·컨텍스트·도구·테스트를 연결한 실행 하네스를 구성하고, 명확한 스펙을 기준으로 구현과 검증이 반복되는 개발 체계를 직접 설계합니다. AI 코딩 에이전트 하네스 엔지니어링 스펙 주도 개발 재현 가능한 실행 환경 스펙·구현·테스트 연계 드리프트 관리 품질 게이트 Human-in-the-Loop 권한과 로그 16시간 · 팀 단위 재사용 AI에게 코드를 요청하는 개발자에서, AI가 일할 환경과 검증 체계를 설계하는 개발자로 코딩·테스트·리뷰를 에이전트에 맡기되, 명확한 스펙과 품질 게이트 안에서 재현 가능하게 운영하는 개발 체계를 구축합니다. THE BOTTLENECK 코드 생성은 빨라졌지만, 개발 전체가 빨라진 것은 아닙니다 AI 코딩의 생산성은 생성 속도만으로 결정되지 않습니다. 어떤 컨텍스트를 참고하고, 어디까지 수정하며, 어떤 테스트를 통과해야 완료되는지 명확해야 실제 개발 프로세스에 적용할 수 있습니다. 코드 생성 이후 반복되는 검증 루프 루프가 닫히지 않는 구조 01 · 02 · 03 개발자 요청 · 코드 생성 · 프로젝트 적용 컨텍스트 부족 작업 범위 불명확 프로젝트 규칙 미반영 04 · 05 · 06 구조 불일치 발견 · 오류 수정 · 테스트 추가 예상하지 못한 코드 수정 테스트 누락 변경 근거 추적의 어려움 07 · 08 · 09 요구사항 재확인 · 재요청 · 리뷰 부담 증가 요구사항 해석 차이 결과 재현의 어려움 리뷰 비용 증가 요청 → 코드 생성 → 오류 발견 → 추가 설명 → 다시 생성 → 리뷰 부담 증가 · 다시 요청 개발 현장의 말 “같은 작업을 다시 요청하면 결과가 매번 달라집니다.” 참고할 컨텍스트와 수정 가능 범위, 완료 조건이 명세되지 않으면 동일한 결과를 재현하기 어렵습니다. 개발 현장의 말 “코드는 돌아가는데, 요구사항을 충족했는지 확인이 어렵습니다.” 스펙과 구현, 테스트가 서로 연결되어 있지 않으면 완료 판단이 개발자의 감에 의존하게 됩니다. 개발 현장의 말 “개인이 만든 활용 방식을 팀에서 재사용하기 어렵습니다.” 파일·명령·실행 권한 기준과 품질 게이트가 문서화되지 않으면 개발자마다 품질 기준이 달라집니다. 필요한 것은 더 긴 프롬프트가 아니라, 에이전트가 일할 수 있는 실행 하네스와 검증 가능한 스펙입니다. ASSISTANT VS AGENT 코드를 제안하는 도구와, 작업을 수행하는 에이전트는 다릅니다 AI 코딩 보조 제안 중심 · 단일 요청 현재 작성 중인 코드 제안 개별 함수나 코드 블록 생성 개발자의 직접적인 입력과 조작 중심 단일 요청과 단일 결과 작업 범위가 비교적 좁음 AI 코딩 에이전트 작업 수행 · 다단계 실행과 검증 여러 파일과 단계가 포함된 작업 수행 프로젝트 컨텍스트와 명세 참조 도구와 스크립트 실행 구현 후 테스트 및 결과 확인 실패 시 수정과 재실행 가능 여러 단계의 결과와 변경 내역 생성 권한과 검증 기준 필요 에이전트가 모든 개발 결정을 자율적으로 내리는 것은 아닙니다. 작업 범위와 실행 권한, 완료 조건은 개발팀이 정의합니다. HARNESS ENGINEERING 에이전트가 일할 수 있는 개발 환경을 설계합니다 node: coding-agent 에이전트는 하네스가 정의한 입력·도구·환경·검증 안에서만 작업을 수행합니다. 1 작업 단위 수행할 구체적인 개발 과제 시작 조건과 완료 조건 수정 가능한 범위 2 컨텍스트 프로젝트 구조 코딩 규칙 관련 소스코드 요구사항과 문서 과거 결정과 제약사항 3 도구와 스크립트 search build lint test static-analysis docs 프로젝트에 필요한 개발 명령을 정의해 연결합니다. 4 실행 환경 격리된 작업 공간 허용된 파일과 명령 의존성 재현 가능한 환경 조건 5 검증 단계 스펙 충족 여부 테스트 결과 코드 품질 기준 변경 범위 확인 보안 및 운영 영향 검토 사람의 최종 리뷰 하네스는 특정 도구 하나가 아니라, 에이전트가 작업을 수행하고 결과를 검증할 수 있도록 구성한 전체 실행 체계입니다. TASK DEFINITION 좋은 요청 한 번보다, 반복 가능한 작업 구조가 중요합니다 일반적인 요청 “이 기능을 구현해줘.” 참고 범위가 불명확 완료 기준이 없음 테스트 기준이 없음 수정 가능 범위가 불명확 결과가 매번 달라질 수 있음 작업 명세로 구조화 하네스 기반 작업 명세 항목 구성 예시 goal 작업 목표 inputs 입력 자료 context 참고할 컨텍스트 writable_scope 수정 가능 범위 tools 사용할 도구 forbidden 금지할 작업 tests 실행할 테스트 done_when 완료 기준 report 결과 보고 형식 review_points 사람의 검토 지점 SPEC-DRIVEN DEVELOPMENT 코드보다 먼저, 실행 가능한 스펙을 작성합니다 요구사항 → 실행 가능한 스펙 → 에이전트 작업 계획 → 구현 → 테스트 → 스펙 충족 여부 검증 → 리뷰 · 완료 또는 수정 실행 가능한 스펙 구성 spec/feature-x.md 개발 목적 해결할 문제와 범위 시나리오 사용자 또는 시스템 흐름 입력 조건 허용 값과 전제 처리 규칙 동작 정의 출력 결과 반환 형태와 상태 예외 상황 실패 조건과 처리 수정 가능 범위 변경 허용 경로 비기능 요구사항 성능·보안·호환성 테스트 조건 검증할 케이스 완료 기준 통과해야 하는 조건 스펙의 역할 스펙은 설명 문서로 끝나는 것이 아니라, 구현과 테스트, 리뷰의 공통 기준으로 사용됩니다. 이 과정에서의 관점 스펙 주도 개발은 유일한 개발 방법론이 아니라, AI 에이전트와 개발팀이 같은 완료 기준을 공유하기 위한 실무 접근법으로 다룹니다. 프로젝트 규모와 팀 상황에 맞게 스펙의 상세도와 검증 단계를 조정합니다. 스펙이 없는 작업은 에이전트에 위임하기 전에 범위와 완료 조건부터 정의합니다. TRACEABILITY 요구사항이 코드와 테스트까지 이어지는 구조 추적표 구성 예시 스펙 항목 구현 코드 테스트 검증 상태 스펙 항목 A 구현 코드 A 테스트 A 통과 스펙 항목 B 구현 코드 B 테스트 B 일부 미통과 스펙 항목 C · 예외 처리 예외 처리 C 테스트 C 검토 필요 스펙 항목 D 구현 없음 테스트 없음 구현 누락 스펙에 없음 추가된 동작 테스트 없음 스펙 외 구현 추적표로 확인하는 질문 어떤 스펙이 어떤 코드로 구현되었는가 해당 스펙을 어떤 테스트가 검증하는가 통과하지 못한 항목은 무엇인가 구현되지 않은 요구사항은 무엇인가 스펙에는 없지만 추가된 동작은 무엇인가 DRIFT MANAGEMENT 스펙이 바뀌면, 코드와 테스트도 함께 바뀌어야 합니다 드리프트는 현재 구현이 최신 스펙과 어긋나는 상태입니다. 스펙과 코드가 자동으로 항상 동기화되지는 않기 때문에, 도구로 차이를 점검하고 사람이 검토하는 절차를 함께 설계합니다. 기존 스펙 → 요구사항 변경 → 스펙 버전 갱신 → 영향 범위 확인 → 구현 변경 → 테스트 변경 → 스펙과 구현 비교 → 리뷰 및 승인 최신 스펙과 현재 구현 비교 spec v1.3 ↔ main 최신 스펙 현재 구현 상태 처리 규칙 정의 동일하게 구현 일치 추가된 입력 조건 미반영 구현 누락 명시되지 않음 추가 동작 존재 스펙 외 구현 변경된 예외 조건 이전 기준의 테스트 테스트 미반영 갱신된 출력 형식 문서와 동작 불일치 검토 필요 드리프트 점검 항목 스펙에 있지만 구현되지 않은 기능 구현됐지만 스펙에 없는 기능 변경된 스펙을 반영하지 않은 테스트 실제 동작과 다른 문서 오래된 요구사항을 기준으로 작성된 코드 예외 조건의 불일치 QUALITY GATES 에이전트의 완료 선언보다, 통과한 검증 기준을 확인합니다 프로젝트에 따라 단계 구성은 달라짐 1 작업 범위 확인 허용된 경로 외 변경 여부 2 빌드 확인 정상 빌드 여부 3 린트 · 정적 검사 규칙 위반과 취약 패턴 4 단위 테스트 기능 단위 검증 5 통합 테스트 연동 동작 확인 6 스펙 충족 여부 완료 기준 대비 검증 7 변경 내역 검토 수정 이유와 근거 추적 8 보안 · 운영 영향 데이터·권한·장애 영향 검토 9 사람의 코드 리뷰 시스템 맥락 기반 판단 10 최종 승인 병합과 배포 결정 오류 · 환각 가능성 점검 존재하지 않는 함수·옵션·의존성 사용 여부 확인 잘못된 가정으로 작성된 로직 확인 인용한 문서와 실제 코드의 일치 여부 확인 테스트가 실제 요구사항을 검증하는지 확인 결과 근거를 로그와 변경 내역으로 추적 검증의 한계 테스트를 통과했다는 사실만으로 코드의 안전성과 운영 적합성이 보장되지는 않습니다. 최종 판단에는 시스템 맥락을 이해하는 사람의 검토가 필요합니다. ISOLATION · PERMISSION · LOG 무엇을 할 수 있는지보다, 어디까지 허용할지가 먼저입니다 격리 독립된 작업 공간 프로덕션 환경과 분리 재현 가능한 의존성 실패 시 영향을 제한할 수 있는 구조 권한 읽을 수 있는 파일 allow 수정할 수 있는 경로 allow 실행할 수 있는 명령 allow-list 접근 가능한 데이터 limited 외부 연결 범위 limited 배포 및 운영 변경 approval 로그 task · 수행한 작업 files · 수정한 파일 commands · 실행한 명령 tests · 테스트 결과 failures · 실패와 재시도 approvals · 사람이 승인한 내용 프로덕션 환경에서 에이전트가 제한 없이 명령을 실행하도록 구성하지 않습니다. 실행 권한과 수정 범위는 사전에 정의하고, 승인이 필요한 작업은 별도로 분리합니다. HUMAN-IN-THE-LOOP 반복 작업은 에이전트가, 기술적 책임은 개발팀이 AI 에이전트가 지원하는 영역 코드 초안 작성 반복적인 코드 수정 테스트 코드 작성 테스트 실행 문서 초안 작성 스펙과 구현의 차이 후보 탐색 변경 내역 정리 정해진 검증 단계 실행 실패 결과 보고 개발자와 QA가 담당하는 영역 요구사항과 스펙 확정 시스템 아키텍처 결정 기술 선택과 트레이드오프 판단 작업 범위와 실행 권한 설정 데이터와 보안 정책 검토 테스트 전략과 품질 기준 설계 비즈니스 로직의 정확성 검증 예외 상황과 운영 영향 판단 최종 코드 리뷰 병합과 배포 승인 장애와 품질에 대한 최종 책임 BEFORE & AFTER 개인의 AI 활용에서, 팀이 운영할 수 있는 개발 체계로 BEFORE 기존 AI 코딩 방식 자연어 요청으로 코드 생성 개발자별로 서로 다른 컨텍스트 제공 요청할 때마다 작업 기준이 달라짐 코드 생성 후 사람이 처음부터 검토 테스트와 문서가 별도로 관리 요구사항 변경 이력 추적이 어려움 개인의 노하우에 의존 수정 범위와 실행 권한이 불명확 16시간 실습 AFTER 교육에서 구축하는 방식 자동화할 개발 과제를 먼저 진단 작업 단위와 완료 조건 정의 프로젝트 컨텍스트와 도구를 하네스로 구성 실행 가능한 스펙 작성 스펙을 기준으로 구현과 테스트 연결 변경 이력과 드리프트 점검 품질 게이트와 사람의 검토 배치 권한과 로그를 운영 기준으로 관리 팀에서 재사용할 수 있는 형태로 정리 개발 속도나 생산성의 향상을 보장하는 교육이 아닙니다. 반복 작업을 체계적으로 위임하고 결과를 검증할 수 있는 개발 운영 구조를 직접 구축하는 것을 목표로 합니다. CURRICULUM 과제 진단부터 하네스 구성, 스펙 운영, 품질 가드와 팀 확산까지 8단계 총 8과목 · 16시간 진단 · 에이전트의 역할과 자동화 과제 발굴 → 구성 · 하네스 이해와 개발 작업 적용 → 운영 · 스펙 주도 개발과 드리프트 관리 → 검증·확산 · 품질 가드와 팀 재사용 STEP 01 AI 코딩 에이전트 활용과 개발 과제 진단 보조 도구와 에이전트의 차이를 구분하고 자동화 후보를 발굴합니다. 2H 단원 · 개발 업무에서 AI 활용 범위와 자동화 과제 발굴 AI 코딩 보조 도구와 자율적으로 작업하는 에이전트의 차이 이해 코딩·테스트·리뷰·문서 등 반복 작업 진단 자동화 후보 발굴 AI 생성 결과를 검증해야 하는 이유 이해 STEP 02 하네스 엔지니어링 기초 작업 단위·컨텍스트·도구가 연결되는 실행 하네스의 구조를 이해합니다. 2H 단원 · 에이전트 실행 하네스의 개념과 구성 에이전트가 작업을 실행하는 하네스의 개념과 구성요소 이해 작업 단위·컨텍스트·도구가 연결되어 동작하는 흐름 파악 격리되고 재현 가능한 실행 환경 구성 원칙 이해 STEP 03 하네스 엔지니어링 적용 선정한 개발 작업에 하네스를 구성하고 실행 결과를 개선합니다. 2H 단원 · 개발 작업에 하네스 구성·적용 실습 선정한 개발 작업에 맞춘 하네스 구성 필요한 도구·스크립트·검증 단계를 하네스에 연결 실행 결과 확인 및 구성 개선 STEP 04 스펙 주도 개발(SDD) 실습 요구사항을 실행 가능한 스펙으로 작성하고 에이전트와 연동합니다. 2H 단원 · 스펙 기반 개발 워크플로우 실습 코드보다 명세를 기준으로 개발하는 스펙 주도 개발 개념과 흐름 이해 요구사항을 실행 가능한 스펙으로 작성 작성한 스펙을 기준으로 구현하고 에이전트와 연동 STEP 05 스펙 주도 개발 운영 스펙·구현·테스트가 연계되는 재현 가능한 파이프라인을 구성합니다. 2H 단원 · 스펙 기반 개발 운영 체계 구성 스펙을 중심으로 개발이 진행되는 운영 흐름 설계 스펙·구현·테스트가 연계되는 운영 체계 구성 반복적으로 재현 가능한 개발 파이프라인 구성 STEP 06 스펙 주도 개발 변경·품질 관리 스펙 변경 이력을 관리하고 구현과의 드리프트를 점검합니다. 2H 단원 · 스펙 변경·드리프트·리뷰 관리 스펙 변경 이력 관리 및 버전 추적 스펙과 실제 구현 간 드리프트 점검 및 리뷰 품질 기준과 리뷰 게이트 설정 STEP 07 에이전트 검증·품질 가드 테스트 게이트를 배치하고 사람이 검토하는 지점을 설계합니다. 2H 단원 · 산출물 검증과 사람 검토 체계 에이전트 산출물 검증 테스트 게이트 배치 오류·환각 가능성 점검 결과 근거 추적 최종 판단에 사람이 검토하는 지점 설계 STEP 08 통합 실습·팀 확산 전체 내용을 하나의 개발 시나리오로 통합하고 확산 방안을 정리합니다. 2H 단원 · 통합 개발 시나리오와 운영 확산 전체 내용을 하나의 개발 시나리오로 통합 구현 권한·로그·운영 체계 정리 팀 확산 및 재사용 방안 발표 시간 편성 2H × 8과목 = 16H OUTCOME 교육이 끝날 때, 에이전트를 운영할 개발 체계가 남습니다 개발 과제 진단 → 작업 단위 정의 → 하네스 구성 → 스펙 작성 → 구현·테스트 연계 → 드리프트 점검 → 품질 게이트 → 통합 시나리오 → 팀 확산 진단 산출물 개발 반복 업무 진단표 AI 에이전트 적용 과제 자동화 후보 우선순위 에이전트 작업 단위와 완료 조건 하네스 산출물 프로젝트 컨텍스트 구성 도구·스크립트·검증 단계가 연결된 실행 하네스 격리되고 재현 가능한 실행 환경 원칙 스펙 운영 산출물 실행 가능한 개발 스펙 스펙 기반 구현·테스트 흐름 스펙 변경 이력 관리 방식 스펙과 구현의 드리프트 점검 기준 품질 · 확산 산출물 품질 기준과 리뷰 게이트 테스트와 사람 검토가 포함된 품질 가드 권한과 로그 관리 기준 통합 개발 시나리오 팀 확산 및 재사용 방안 FOR ENGINEERING TEAMS 이런 개발 실무자에게 적합합니다 결과 품질이 일정하지 않은 개발자 AI 코딩 도구를 사용하지만 결과 품질이 일정하지 않은 개발자 AI가 생성한 코드의 테스트와 리뷰 부담이 커진 개발자 작업을 위임하려는 엔지니어 여러 파일과 단계가 포함된 작업을 AI 에이전트에 위임하고 싶은 소프트웨어 엔지니어 AI 산출물에 대한 테스트와 검증 체계를 만들고 싶은 QA 엔지니어 스펙과 코드의 정합성을 관리할 팀 요구사항과 코드, 테스트의 불일치를 줄이고 싶은 개발팀 스펙 주도 개발을 AI 에이전트와 연결하고 싶은 실무자 운영 체계를 표준화할 리더 AI 에이전트의 파일·명령·실행 권한을 체계적으로 관리하려는 담당자 개인의 AI 코딩 방식을 팀의 재사용 가능한 프로세스로 발전시키려는 기술 리더 개발 자동화의 속도뿐 아니라 품질과 추적 가능성을 함께 확보하려는 조직 AI 개발 생산성은 코드 생성량이 아니라 신뢰하고 반복할 수 있는 개발 체계에서 나옵니다 AI 에이전트가 코드를 작성하고 테스트를 실행하더라도, 작업의 목적과 범위, 품질 기준이 불명확하면 검토 부담은 다시 개발팀에 돌아옵니다. 이 과정에서는 작업 단위·컨텍스트·도구·검증 절차를 연결한 실행 하네스를 구성하고, 스펙을 기준으로 구현과 테스트가 이어지는 개발 운영 체계를 직접 구축합니다. 에이전트는 반복 작업을 수행하고, 개발팀은 스펙과 품질, 기술적 책임을 관리합니다.