에이전트 시대의 개발자 교육 및 평가

에이전트 시대의 개발자 교육 및 평가

이 분석은 2026년 7월 26일 현재의 교육 및 자격증 환경을 반영합니다.

서론

자율 코딩 에이전트는 소프트웨어 개발을 코드 작성 중심의 작업에서 작업 명세화, 작업 위임, 실행 감독, 결과 검토 중심의 작업으로 변화시키고 있습니다.

최신 코딩 에이전트는 저장소를 검사하고, 구현 계획을 개발하고, 여러 파일을 수정하고, 테스트를 실행하고, 오류에 대응하며, 인간 검토를 위한 풀 리퀘스트를 열 수 있습니다. GitHub의 현재 문서는 개발자가 에이전트에 이슈를 할당하고, 작업을 모니터링하고, 코드 검토를 요청하고, 피드백을 제공하며, 결과를 승인하거나 거부하는 워크플로우를 설명합니다. (docs.github.com)

이는 교육에 있어 어려운 질문을 던집니다.

만약 학생이 에이전트에게 작동하는 프로그램을 생성해달라고 요청할 수 있다면, 학생은 무엇을 이해해야 할까요?

답은 프로그래밍 기본을 포기하는 것이 아닙니다. 그 기본이 사용되는 목적을 바꾸는 것입니다.

학생들은 여전히 자료 구조, 알고리즘, 프로그래밍 언어, 시스템 설계, 보안, 테스팅, 디버깅을 이해해야 합니다. 그러나 점차 그 지식을 다음을 위해 적용해야 합니다.

• 모호한 문제를 관리 가능한 작업으로 분해
• 정확한 명세 및 인수 기준 작성
• 코딩 에이전트에 유용한 컨텍스트 제공
• 생성된 코드가 정확하고 유지보수 가능한지 판단
• 숨겨진 결함을 드러내는 테스트 설계
• 보안, 프라이버시, 성능 및 아키텍처 위험 검토
• 통제력을 잃지 않고 여러 에이전트 또는 도구 조율
• 기술적 결정 설명 및 옹호

따라서 다음 세대의 개발자 교육은 학생의 대량 코드 생산 능력보다 학생의 소프트웨어 시스템을 이해하고, 지시하고, 검증하고, 개선하는 능력을 더 많이 평가할 것입니다.

핵심 변화: 코드 생산에서 엔지니어링 판단으로

코딩 에이전트는 단순히 더 빠른 자동 완성이 아니다

전통적인 코딩 도우미는 한 줄, 함수 또는 작은 코드 블록을 제안합니다. 자율 코딩 에이전트는 더 큰 규모로 작동합니다. 여러 파일에 걸쳐 작업하고, 개발 도구를 호출하고, 테스트를 실행하고, 문서를 검사하며, 여러 단계를 계속해서 진행할 수 있습니다.

이는 작업 단위를 변화시킵니다. 개발자의 워크플로우는 점점 다음과 같이 변하고 있습니다.

1. 사용자 또는 비즈니스 문제 이해.
2. 원하는 동작 정의.
3. 작업을 더 작은 작업으로 분해.
4. 적절한 작업을 에이전트에 할당.
5. 에이전트의 계획 검토.
6. 통제된 환경 내에서 에이전트가 구현하도록 허용.
7. 테스트 및 보안 점검 실행.
8. 결과 검토.
9. 변경 요청 또는 설계 수정.
10. 소프트웨어 승인, 병합 및 모니터링.

계획 및 검토 단계를 건너뛰는 사람은 여전히 코드를 생성할 수 있지만, 신뢰할 수 있는 제품을 안정적으로 생산할 수는 없습니다.

원시 코드 출력의 한계

원시 코드 생산은 에이전트가 그럴듯한 코드를 대량으로 빠르게 생성할 수 있기 때문에 능력의 약한 척도가 되고 있습니다. 동시에 에이전트는 장기적인 소프트웨어 진화, 다중 파일 변경, 불분명한 요구사항, 반복적인 수정 전반에 걸쳐 동작을 유지하는 데 계속 어려움을 겪고 있습니다. 2025년 한 벤치마크 연구에 따르면, 고립된 문제 해결에서의 에이전트 성능과 더 복잡하고 장기적인 소프트웨어 진화 작업 간에 상당한 격차가 있음이 밝혀졌습니다. (arxiv.org)

이는 중요한 교육적 구분을 만듭니다.

• 코드를 생성할 수 있는 학생은 그것을 이해하지 못할 수도 있습니다.
• 코드를 설명하고, 테스트하고, 이의를 제기하고, 수정할 수 있는 학생은 더 깊은 역량을 보여줍니다.

따라서 교육 목표는 단순히 성공적인 코드 생성이 아니라 검증된 소프트웨어 판단이 되어야 합니다.

교육 과정은 어떻게 적응하고 있는가

대학 교육 과정은 이해 및 검증으로 나아가고 있다

ACM, 전기전자공학회 컴퓨터 소사이어티, 그리고 인공지능 발전 협회의 컴퓨터 과학 교육 과정 2023 보고서는 생성형 인공지능이 프로그래밍 교육을 변화시킬 것이라고 예상했습니다. 이 지침은 학생들이 코드 읽기, 이해, 검증, 편집, 수정, 적용, 테스트에 더 많은 비중을 두어야 한다고 제안합니다. 또한 문제 분해를 더욱 중요해질 영역으로 지목합니다. (csed.acm.org)

같은 지침은 중요한 점을 강조합니다. 에이전트가 프로그램을 작성하더라도, 프로그램이 올바른지 여부를 결정하는 책임은 인간에게 있습니다. 이는 프로그래밍 교육이 프롬프트 작성으로만 축소될 수 없음을 의미합니다. 학생들은 결과물을 평가하기에 충분한 기술적 이해를 필요로 합니다.

이 보고서는 또한 코드 생성, 디버깅, 정적 분석 및 코드 검토를 위한 인공지능의 활용 증대 등 소프트웨어 공학 교육의 변화를 예상합니다. 이러한 도구의 효과적인 사용은 약한 디자인 및 코드 이해력 기술이 아닌, 더 강력한 디자인 및 코드 이해력 기술을 요구합니다. (csed.acm.org)

인증은 더 넓은 엔지니어링 성과를 보상하기 시작한다

공학 기술 인증 위원회(ABET)의 현재 컴퓨팅 인증 기준은 이미 다음을 강조합니다.

• 복잡한 컴퓨팅 문제 분석
• 컴퓨팅 솔루션 설계 및 평가
• 전문적인 의사소통
• 법적 및 윤리적 책임
• 보안 및 프라이버시
• 컴퓨팅의 사회적 영향
• 종합적인 프로젝트 또는 체험적 요소 (abet.org)

이러한 성과는 에이전트 기반 개발 환경에 잘 부합하는데, 이는 키 입력보다는 판단과 책임을 측정하기 때문입니다.

2026년 7월 26일 현재, 2026-2027 주기 공학 기술 인증 위원회(ABET)의 제안된 변경 사항에는 추가적인 인공지능 프로그램 기준과 졸업생이 인공지능 이론, 모델 및 기술을 복잡한 문제에 적용할 수 있어야 한다는 요구사항이 포함되어 있습니다. 제안된 변경 사항은 최종 채택을 기다리고 있었으며, 2026년 가을 회의 이후 발효되어 2027-2028 검토 주기 동안 처음 적용될 것으로 예상됩니다. (abet.org)

예상되는 방향은 분명합니다. 프로그램은 학생들이 단순히 고립된 프로그래밍 연습을 완료하는 것을 넘어 시스템을 구축하고 평가할 수 있음을 보여주어야 할 것입니다.

새로운 과정들은 에이전트 사용을 엔지니어링 학문으로 가르치고 있다

몇몇 최근 대학 과정들이 나타나는 패턴을 보여줍니다.

메릴랜드 대학교의 2025년 인공지능 코딩 보조 도구 및 에이전트 효과적 사용 과정은 빌드 시스템을 호출하고, 테스트를 실행하며, 오류를 수정할 수 있는 도구들을 다루었습니다. 또한 유지보수성, 아키텍처, 애플리케이션 프로그래밍 인터페이스 설계, 효율성, 확장성, 보안, 지속적 통합, 코드 검토, 비동기 에이전트, 자동화된 코드 검토도 다루었습니다. (cs.umd.edu)

펜실베이니아 대학교는 인공지능 기반 소프트웨어 개발에 초점을 맞춘 2학년 수준의 컴퓨터 과학 과정을 제안했습니다. 제안된 주제에는 코딩 작업 위임, 모듈식 설계, 확장 가능한 테스팅, 위험 관리, 재현성, 협업 및 윤리가 포함됩니다. (seas.upenn.edu)

미시간 대학교의 2026년 가을 학기 과정인 응용 에이전트 소프트웨어 공학(Applied Agentic Software Engineering)은 훨씬 더 명확합니다. 이 과정은 세 단계로 구성됩니다.

1. 코딩 에이전트를 효과적으로 사용
2. 대규모 언어 모델 애플리케이션 프로그래밍 인터페이스를 사용하여 에이전트 구축
3. 에이전트 오케스트레이터 설계, 평가 및 배포

이 과정은 전통적인 시험 대신 프로젝트, 실습, 시연 및 확인 과정을 활용합니다. 채점은 결과물보다는 이해도를 보상할 것이며, 학생들에게 에이전트가 실패한 이유와 주변 시스템을 어떻게 수정해야 하는지를 설명하도록 요청합니다. (eecs498-aase.github.io)

이는 중요한 설계 변화입니다. 이 과정은 학생들이 코드를 더 빠르게 생성하도록 가르치는 것이 아닙니다. 코드를 생성하는 시스템의 기술 감독자가 되도록 가르치는 것입니다.

부트캠프는 어떻게 변화하고 있는가

부트캠프는 커리큘럼이 고용 요구사항과 밀접하게 연결되어 있기 때문에 많은 전통적인 프로그램보다 빠르게 적응하고 있습니다. 하지만 적응의 품질은 다양합니다.

전용 인공지능 부트캠프 모델

르 웨건(Le Wagon)의 현재 인공지능 소프트웨어 개발 부트캠프는 풀스택 개발과 인공지능 통합을 결합합니다. 공개된 커리큘럼에는 인공지능 지원 코딩, 대규모 언어 모델 통합, 프로덕션 배포, 검색 증강 생성, 자율 인공지능 에이전트가 포함됩니다. (lewagon.com)

이 모델은 인공지능을 단일 선택 수업이 아니라 프로그램 전체를 관통하는 핵심 요소로 다룹니다. 학생들은 다음 두 가지를 모두 배우도록 기대됩니다.

• 기존 소프트웨어 시스템이 어떻게 작동하는지
• 인공지능 도구를 사용하여 그러한 시스템을 구축하고 운영하는 방법

이러한 조합은 중요합니다. 에이전트 작동법만 아는 학습자는 결함 있는 아키텍처를 인식하지 못할 수 있습니다. 기존 프로그래밍만 아는 학습자는 현대적인 개발 워크플로우에 대비하지 못할 수 있습니다.

"인공지능 유닛 추가" 모델

스프링보드(Springboard)의 소프트웨어 엔지니어링 부트캠프는 웹 개발, 애플리케이션 프로그래밍 인터페이스, 프론트엔드 개발, 백엔드 개발 및 풀스택 프로젝트의 전통적인 기반을 유지하면서, 프롬프트 엔지니어링과 생성 도구와의 협업에 초점을 맞춘 인공지능 유닛을 추가합니다. (springboard.com)

이 모델은 강력한 프로그래밍 기초가 먼저 필요한 학습자들에게 유용합니다. 또한 실용적인 현실을 반영합니다. 많은 학생들은 자율 에이전트 구축부터 시작해서는 안 됩니다. 먼저 소프트웨어가 어떻게 작동하는지, 버전 제어를 사용하는 방법, 오류 메시지를 읽는 방법, 프로그램을 테스트하는 방법을 배워야 합니다.

약점은 짧은 프롬프트 엔지니어링 모듈이 너무 피상적일 수 있다는 점입니다. 진지한 에이전트 시대 커리큘럼은 코드를 요청하는 방법 이상을 가르쳐야 합니다. 다음을 가르쳐야 합니다.

• 저장소 컨텍스트 파일을 생성하는 방법
• 기술 명세를 작성하는 방법
• 작업 경계를 정의하는 방법
• 에이전트의 권한을 제한하는 방법
• 에이전트 계획을 검토하는 방법
• 생성된 테스트를 평가하는 방법
• 보안 문제를 탐지하는 방법
• 대안 설계를 비교하는 방법
• 에이전트 개입을 문서화하는 방법

부트캠프 학생들이 찾아야 할 것

예비 학생들은 프로그램이 다음을 평가하는지 물어봐야 합니다.

• 학생들이 직접 타이핑하지 않은 코드를 설명할 수 있는가?
• 학생들이 결함 있는 에이전트 결과물을 검토하고 수정하는가?
• 테스트, 보안, 유지보수성이 채점되는가?
• 라이브 시연 또는 기술적 옹호가 있는가?
• 학생들이 버전 관리되는 프로젝트 이력을 유지하는가?
• 필요할 때 에이전트 없이 작업하는 방법을 배우는가?
• 프로그램이 제품 발견 및 요구사항 분석을 가르치는가?
• 도구별 기술이 지속 가능한 엔지니어링 원칙과 균형을 이루는가?

"일주일 만에 인공지능으로 애플리케이션 구축"을 광고하는 프로그램은 빠른 프로토타이핑에는 탁월할 수 있지만, 전문가 수준의 소프트웨어 엔지니어링을 준비시키는 것과는 다릅니다.

자격증은 어떻게 적응하고 있는가

자격증 제공기관들은 크게 세 가지 유형의 자격증을 개발하고 있습니다.

도구별 지식 자격증

마이크로소프트의 GitHub Copilot 자격증은 책임감 있는 사용, Copilot 기능, 데이터 아키텍처, 컨텍스트 및 프롬프트 작성, 개발자 생산성, 프라이버시, 콘텐츠 제외 및 보호 장치를 평가합니다. 시험은 감독관이 있으며, 100분 동안 진행되며, 상호작용형 구성 요소를 포함할 수 있습니다. (learn.microsoft.com)

이 자격증은 유용한 직무 지식을 인정합니다. 특정 개발 플랫폼을 책임감 있게 사용하는 방법을 이해하고 있음을 보여줄 수 있습니다.

그 한계는 하나의 제품에 강하게 묶여 있다는 것입니다. GitHub Copilot을 사용하는 방법을 아는 전문가는 복잡한 제품 요구사항을 분해하거나, 아키텍처 선택에 이의를 제기하거나, 보안에 민감한 변경 사항을 검토할 능력이 여전히 부족할 수 있습니다.

플랫폼 기반 인공지능 개발 자격증

AWS 공인 생성형 AI 개발자 – 전문(Professional) 자격증은 더 광범위합니다. 시험 가이드에는 파운데이션 모델 통합, 데이터 관리, 규정 준수, 구현, 에이전트 인공지능 솔루션, 보안, 거버넌스, 테스트, 문제 해결, 모니터링 및 최적화가 포함됩니다. (docs.aws.amazon.com)

하지만 이 시험은 주로 객관식 및 복수 응답 형식입니다. 상당한 지식 테스트이지만, 응시자가 작동하는 시스템을 구축하고, 검토하거나, 옹호할 수 있는지 여부를 완전히 보여주지는 못합니다. (aws.amazon.com)

이는 더 큰 문제를 보여줍니다. 지식 시험은 수행 능력 시험보다 확장하기 쉽습니다. 자격증 기관은 용어와 설계 원칙을 효율적으로 테스트할 수 있지만, 실제 역량은 응시자가 결정을 내리고 실패에 대처해야 하는 환경을 필요로 합니다.

실습 및 프로젝트 기반 자격증

마이크로소프트 Applied Skills 자격증은 더 유망한 모델을 제공합니다. 이는 학습자가 실습 기반 평가에서 실제 업무와 관련된 상호작용형 과제를 완료하도록 요구합니다. 마이크로소프트는 이 자격증들을 응시자가 단순히 정보를 기억하는 것이 아니라 실제 클라우드 및 인공지능 과제를 해결할 수 있다는 증거로 제시합니다. (learn.microsoft.com)

카네기 멜론 대학교의 최고 경영자 교육 에이전트 인공지능 프로그램은 실시간 교육, 가이드 실습, 과제, 다중 에이전트 워크플로우, 평가, 가드레일, 로깅, 관측 가능성 및 캡스톤 프로젝트를 결합합니다. (execonline.cs.cmu.edu)

이 프로그램들이 독립적인 전문 자격증과 동일하지는 않지만, 자격증이 나아갈 방향을 보여줍니다.

• 더 짧은 실용적 평가
• 샌드박스 개발 환경
• 현실적인 저장소
• 평가 및 관측 가능성 작업
• 캡스톤 시스템
• 구두 또는 녹음된 기술 설명
• 책임감 있는 도구 사용의 증거

이해도를 측정하는 평가 기법

최고의 평가 전략은 모든 과제에서 에이전트 사용을 금지하지 않습니다. 에이전트가 전문적인 관행을 반영하는 곳에 에이전트를 사용하고, 독립적인 이해도를 측정하기 위한 일부 활동은 따로 둡니다.

1. 명세 및 분해 문서

코드를 작성하기 전에 학생들에게 다음을 제출하도록 요구하세요.

• 사용자 문제
• 기능 요구사항
• 비기능 요구사항
• 가정
• 제약사항
• 자료 구조
• 인터페이스
• 인수 기준
• 작업 분해
• 알려진 위험

문서는 문제가 특정 작업으로 나뉘어진 이유를 설명해야 합니다.

이는 학생이 에이전트에게 구현을 요청하기 전에 문제를 이해하고 있는지 측정합니다.

2. 에이전트 계획 검사점

구현을 시작하기 전에 학생들에게 에이전트가 제안한 계획을 보여주도록 요구하세요. 학생은 다음을 식별해야 합니다.

• 계획 중 허용 가능한 부분
• 불완전한 부분
• 안전하지 않은 가정
• 인간의 승인이 필요한 작업
• 추가해야 할 테스트

최종 성적은 에이전트 계획의 길이가 아닌, 학생의 판단 품질에 보상을 주어야 합니다.

3. 코드 검토 평가

학생들에게 의도적인 결함이 포함된 에이전트 생성 저장소를 제공하세요. 결함은 다음을 포함할 수 있습니다.

• 잘못된 엣지 케이스 처리
• 안전하지 않은 인증
• 부실한 오류 처리
• 숨겨진 성능 문제
• 중복된 로직
• 불명확한 인터페이스
• 불충분한 테스트
• 프라이버시 침해
• 의존성 위험

학생들에게 심각도 수준, 증거, 제안된 수정 사항 및 회귀 테스트를 포함한 검토를 작성하도록 요청하세요.

이는 학생들이 처음부터 또 다른 작은 애플리케이션을 만들도록 요청하는 것보다 전문 소프트웨어 작업에 더 가깝습니다.

4. 설명 및 구두 변호

학생은 다음을 설명할 수 있어야 합니다.

• 시스템이 하는 일
• 아키텍처가 선택된 이유
• 어떤 부분이 생성되었는지
• 에이전트가 어떤 가정을 했는지
• 테스트가 정확성을 어떻게 입증하는지
• 여전히 실패할 수 있는 것
• 어떤 트레이드오프가 수용되었는지

짧은 구두 변호는 개별적으로 또는 소그룹으로 진행될 수 있습니다. 위협적일 필요는 없습니다. 5~10개의 집중적인 질문만으로도 학생이 제출물을 이해하고 있는지 파악하기에 충분한 경우가 많습니다.

5. 전이 과제

학생이 에이전트 지원 프로젝트를 완료한 후, 원래 프롬프트를 단순히 반복하는 것만으로는 해결할 수 없는 새로운 요구사항을 제공하세요.

예를 들어:

• 새로운 데이터 소스 추가
• 성능 목표 변경
• 예상치 못한 입력 형식 지원
• 의존성 제거
• 접근 제어 추가
• 실패하는 테스트 설명
• 동작을 변경하지 않고 모듈 리팩토링

학생은 에이전트를 사용할 수 있지만, 계획을 설명하고, 변경 사항을 검증하며, 결과를 옹호해야 합니다.

전이 과제는 학생이 성공적인 상호작용을 암기한 것이 아니라 일반적인 방법을 배웠는지 측정합니다.

6. 테스트 설계 및 적대적 테스팅

학생들은 생성된 코드가 제공된 테스트를 통과하는지 여부뿐만 아니라, 테스트의 품질에 따라 채점되어야 합니다.

유용한 요구사항은 다음과 같습니다.

• 경계 테스트 작성
• 음수 테스트 생성
• 유효하지 않은 입력 테스트
• 실패 복구 테스트
• 성능 가정 확인
• 적절한 경우 속성 기반 테스트 사용
• 보안에 민감한 동작 테스트
• 테스트되지 않은 부분 설명

핵심 질문은 "코드가 통과했는가?"가 아니라 "학생이 무엇을 테스트해야 하는지 알았는가?"입니다.

7. 버전 이력 및 과정 포트폴리오

프로젝트 포트폴리오에는 다음이 포함될 수 있습니다.

• 초기 명세
• 작업 분해
• 에이전트 계획
• 주요 프롬프트 또는 지침
• 커밋
• 테스트 결과
• 검토 의견
• 실패한 접근 방식
• 설계 변경 사항
• 최종 성찰

과정 포트폴리오가 모든 사적 대화 라인을 제출해야 하는 요구사항이 되어서는 안 됩니다. 거대한 대화록보다는 대표적인 기록이 더 유용한 경우가 많습니다.

예를 들어, 프린스턴 대학교의 2025년 프로그래밍 과정은 생성형 인공지능 도구 사용을 허용했지만, 학생들이 README 파일에 상세한 대화록 대신 대표적인 요약으로 사용 내용을 기술하도록 요구했습니다. (cs.princeton.edu)

8. 구조화된 동료 검토

동료 검토는 학생들을 단순히 코드 생산자에서 코드 비평가로 변화시킵니다. 초기 연구에 따르면, 루브릭 기반의 동료 평가는 평가적 사고와 참여를 개발하는 동시에 강사 평가를 중간 정도의 정확도로 근사할 수 있음을 시사합니다. (arxiv.org)

학생들은 증거를 가지고 자신의 의견을 정당화하도록 요구되어야 합니다. "이 코드는 좋지 않다"는 검토가 아닙니다. "이 함수는 루프 내에서 데이터베이스 쿼리를 수행하여 컬렉션이 커질 때 성능 문제를 일으킬 가능성이 있다"는 검토입니다.

9. 프롬프트 및 명세 문제

프롬프트 문제는 학생들이 인공지능 시스템이 명세를 충족하는 코드를 생성하도록 하는 자연어 지시를 작성하는 프로그래밍 연습입니다. 이 접근 방식은 코드 생성 시스템에 계산 요구사항을 전달하는 방법을 명시적으로 가르칩니다. (arxiv.org)

이는 유용할 수 있지만, 유일한 평가 방법이 되어서는 안 됩니다. 900명 이상의 학생이 참여한 2026년 연구에 따르면, 흔한 오류 중 하나는 프롬프트에서 중요한 세부 사항을 누락하는 것이었습니다. 생성된 코드가 실패했을 때, 학생들은 코드를 추적하거나 테스트 케이스를 검토하기보다는 자신의 의도를 명확히 하는 데 집중하는 경우가 많았습니다. (arxiv.org)

따라서 프롬프팅은 분해 및 의사소통 기술을 드러낼 수 있지만, 코드 읽기, 테스트, 디버깅 및 검토와 결합되어야 합니다.

샘플 평가 구조

실용적인 프로젝트는 다음 가중치를 사용할 수 있습니다.

이 구조는 여전히 작동하는 제품에 보상을 주지만, 에이전트가 대규모 코드베이스를 생성했다는 이유만으로 학생이 높은 점수를 받는 것을 방지합니다.

에이전트 지원 과제에서의 학업 윤리

전면 금지 및 무제한 사용은 모두 부적절하다

전면적인 금지는 특정 기초 평가, 특히 학습 목표가 독립적인 프로그래밍 연습일 때 적절할 수 있습니다. 그러나 전면적인 금지는 시행하기가 점점 더 어려워지고, 학생들이 전문적인 업무에서 접하게 될 도구를 배우는 것을 막을 수 있습니다.

무제한 사용 또한 부적절합니다. 학생들이 에이전트가 생성한 작업을 설명 없이 제출할 수 있다면, 평가는 학습보다는 도구 접근성을 측정할 수 있습니다.

가장 강력한 접근 방식은 명시적인 과제별 정책입니다.

세 가지 유용한 정책 모드

모드 1: 에이전트 금지

다음 경우에 사용합니다.

• 시험
• 기초 프로그래밍 연습
• 개별 디버깅 시연
• 핵심 알고리즘 연습
• 보조 없이 회상 또는 구현을 측정하도록 설계된 평가

카네기 멜론의 명령형 계산 원리(Principles of Imperative Computation) 과정은 솔루션 생성, 솔루션 설명, 코드 형식 지정 및 테스트 케이스 생성을 포함하여 채점되는 작업의 어떤 부분에서도 인공지능 도구를 금지합니다. (cs.cmu.edu)

모드 2: 에이전트 제한

학생들이 다음을 요청할 수 있는 경우에 사용합니다.

• 개념 설명
• 문서화 도움
• 오류 메시지 해석
• 라이브러리 또는 애플리케이션 프로그래밍 인터페이스 설명
• 브레인스토밍
• 학생이 만든 디자인에 대한 비판
• 사소한 리팩토링

카네기 멜론 시스템 과정은 애플리케이션 프로그래밍 인터페이스, 라이브러리, 프레임워크, 제공된 코드 및 오류 메시지 이해를 위해 인공지능 도구를 허용하는 반면, 부분적 또는 완전한 과제 솔루션 요청은 금지합니다. (cs.cmu.edu)

모드 3: 공개를 조건으로 에이전트 허용

현실적인 소프트웨어 엔지니어링 프로젝트에 사용합니다. 학생들에게 다음을 공개하도록 요구하세요.

• 어떤 도구가 사용되었는지
• 어떤 작업이 위임되었는지
• 생성된 코드가 복사, 수정 또는 다시 작성되었는지 여부
• 결과물이 어떻게 테스트되었는지
• 학생이 무엇을 배웠는지
• 디자인의 어떤 부분이 학생의 책임으로 남아 있는지

프린스턴의 학문적 진실성 지침은 허용된 인공지능 사용도 여전히 공개되어야 하며, 생성된 결과물을 자신의 것처럼 표현하거나 사용을 공개하지 않는 것은 진실성 위반이 될 수 있다고 명시합니다. (scholarlyintegrity.princeton.edu)

하버드 교육대학원도 마찬가지로 명확화, 브레인스토밍, 탐색과 같은 사용은 허용하지만, 학생들이 인공지능이 생성한 과제물을 자신의 것으로 제출하는 것은 금지합니다. 또한 허용된 사용에 대한 문서화를 요구하며, 학생들은 정확성, 프라이버시, 저작권 및 편향에 대한 책임을 여전히 진다고 경고합니다. (registrar.gse.harvard.edu)

실용적인 공개 진술서

과정은 간단한 템플릿을 제공할 수 있습니다.

저는 [도구 이름]을 [계획, 디버깅, 코드 생성, 테스트, 문서화 또는 검토]에 사용했습니다. 저는 [특정 작업]을 위임했습니다. 저는 결과물을 검토하고 수정했으며, 생성된 시스템을 테스트했고, 제출물의 정확성, 보안 및 독창성에 대한 책임은 저에게 있습니다.

학생들은 위임된 구현과 동일한 방식으로 일반적인 맞춤법 교정을 공개하도록 요구되어서는 안 됩니다. 정책은 사소한 도움과 상당한 인지적 또는 기술적 기여를 구분해야 합니다.

프라이버시 및 동등한 접근

기관은 승인된 도구 또는 대안을 제공해야 합니다. 학생들은 기밀 과제, 개인 정보, 미공개 연구 또는 독점 코드를 공공 시스템에 업로드하도록 요구되어서는 안 됩니다.

유네스코의 지침은 프라이버시, 안전, 공정성, 포용성 및 기관의 준비 상태를 다루는 인간 중심의 접근 방식을 요구합니다. (unesco.org)

과정은 여러 유료 도구를 감당할 수 없는 학생들도 고려해야 합니다. 공정한 과정은 다음을 할 수 있습니다.

• 공유 기관 도구 제공
• 로컬 또는 오픈소스 대안 제공
• 특정 벤더에 의존하지 않는 과제 설계
• 가장 강력한 모델에 대한 접근성보다는 추론 과정을 평가
• 모든 필수 학습 성과에 대해 비에이전트 경로 허용

에이전트를 생산적으로 통합하는 실용적인 방법

통제된 저장소 사용

학생들에게 다음이 포함된 저장소를 제공하세요.

• 명확한 README 파일
• 작지만 현실적인 코드베이스
• 자동화된 테스트
• 지속적 통합 워크플로우
• 알려진 문제 목록
• 스타일 가이드
• 보안 체크리스트
• 변경 로그

이는 에이전트 사용을 관찰 가능하게 하고, 학생들에게 빈 코딩 연습보다 더 현실적인 것을 제공합니다.

구현 전 계획 요구

학생들은 에이전트에게 "전체 애플리케이션을 구축해달라"고 요청하는 것으로 시작해서는 안 됩니다. 다음 순서를 요구하세요.

1. 에이전트에게 저장소를 검사하도록 요청합니다.
2. 아키텍처 요약을 요청합니다.
3. 위험 요소와 누락된 정보를 요청합니다.
4. 학생 자신의 작업 계획을 작성합니다.
5. 하나의 작은 구현 작업을 승인합니다.
6. 결과 변경 사항을 검토합니다.
7. 계속하기 전에 테스트를 실행합니다.

이는 맹목적인 위임이 아닌 통제된 위임을 가르칩니다.

명확한 역할을 가진 에이전트 팀 사용

간단한 오케스트레이션 패턴은 다음을 포함할 수 있습니다.

• 기획자: 작업 분해 제안
• 구현자: 코드 수정
• 테스터: 테스트 생성 및 실행
• 검토자: 결함 및 위험 요소 탐색
• 인간 평가자: 변경 승인 또는 거부

학생들은 더 많은 에이전트를 추가하는 것이 자동으로 품질을 향상시키지는 않는다는 것을 배워야 합니다. 더 많은 에이전트는 모순된 지시, 중복된 노력, 증가된 비용 및 불분명한 책임을 야기할 수 있습니다.

교육 목표는 가장 큰 다중 에이전트 시스템을 구축하는 것이 아닙니다. 신뢰할 수 있는 결과를 생산하는 가장 간단한 워크플로우를 선택하는 것입니다.

인간 승인 게이트 구축

에이전트가 다음을 수행하기 전에 명시적인 승인을 요구하세요.

• 인증 변경
• 데이터 스키마 수정
• 의존성 추가
• 프로덕션 시스템 접근
• 배포 구성 변경
• 파일 삭제
• 풀 리퀘스트 병합

이는 자율성이 권한과 검토에 의해 제한되어야 함을 학생들에게 가르칩니다.

의도적으로 실패를 채점

에이전트는 유익한 방식으로 실패할 때 가장 교육적입니다. 강사는 다음을 포함해야 합니다.

• 모호한 요구사항
• 충돌하는 제약사항
• 불완전한 테스트
• 보안에 민감한 작업
• 오해의 소지가 있는 문서
• 불안정한 테스트
• 성능 한계
• 올바르게 보이지만 다른 기능을 손상시키는 변경

학생의 과제는 실패를 진단하고 프로세스를 개선하는 것입니다.

2026년부터 2031년까지의 역량 프레임워크

다음 프레임워크는 특정 도구가 변경되더라도 유용하게 유지되도록 설계되었습니다.

도메인 1: 기술적 기반 및 코드 리터러시

역량 있는 개발자는 다음을 할 수 있습니다.

• 익숙하지 않은 코드 읽기
• 제어 흐름 및 데이터 흐름 설명
• 인터페이스 및 의존성 이해
• 알고리즘 복잡도 분석
• 버전 제어 사용
• 에이전트에 전적으로 의존하지 않고 디버깅

증거: 코드 설명, 수동 디버깅 작업, 디자인 비판 및 개별 전이 연습.

도메인 2: 문제 구성 및 분해

역량 있는 개발자는 다음을 할 수 있습니다.

• 사용자 목표 명확화
• 제약사항 및 가정 식별
• 필수 요구사항과 선택적 요구사항 분리
• 작업을 독립적으로 테스트 가능한 작업으로 분해
• 인수 기준 정의
• 작업이 신뢰할 수 있는 위임에 너무 광범위할 때 인식

증거: 명세, 작업 그래프, 위험 등록부 및 분해 선택에 대한 설명.

도메인 3: 에이전트 지시 및 컨텍스트 엔지니어링

역량 있는 개발자는 다음을 할 수 있습니다.

• 관련 저장소 컨텍스트 제공
• 정확한 지시 제공
• 경계 및 권한 정의
• 에이전트를 언제 사용하고 언제 사용하지 않을지 선택
• 대안 계획 비교
• 에이전트가 잘못된 해석을 따를 때 복구

증거: 계획 검사점, 대표적인 상호작용 기록 및 실시간 수정 작업.

도메인 4: 검증 및 검토

역량 있는 개발자는 다음을 할 수 있습니다.

• 생성된 코드 검사
• 의미 있는 테스트 설계
• 숨겨진 가정 식별
• 보안 및 프라이버시 위험 검토
• 유지보수성 평가
• 테스트가 입증하지 못하는 것 설명

증거: 코드 검토, 적대적 테스트, 결함 찾기 연습 및 구두 변호.

도메인 5: 오케스트레이션 및 운영

역량 있는 개발자는 다음을 할 수 있습니다.

• 계획, 구현, 테스트 및 검토 도구 조율
• 검사점 및 인간 승인 게이트 사용
• 비용, 시간 및 도구 동작 추적
• 재현 가능한 워크플로우 유지
• 실패를 관찰하고 시스템 개선
• 여러 에이전트가 가치를 추가하는지 여부 결정

증거: 작동하는 오케스트레이션 워크플로우, 로그, 평가 보고서 및 비용 또는 성능 분석.

도메인 6: 제품 및 시스템 설계

역량 있는 개발자는 다음을 할 수 있습니다.

• 적절한 수준의 자동화 선택
• 모듈식 시스템 설계
• 속도, 품질, 비용 및 위험 균형 유지
• 기술적 결정을 사용자 결과에 연결
• 간단한 비에이전트 솔루션이 더 나은 경우 인식

증거: 제품 요약서, 아키텍처 결정 기록, 프로토타입 및 사용자 중심 시연.

도메인 7: 책임감 있는 전문 실천

역량 있는 개발자는 다음을 할 수 있습니다.

• 인공지능 지원 공개
• 개인 정보 및 독점 정보 보호
• 저작권 및 라이선스 의무 준수
• 편향 및 신뢰성 위험 식별
• 불확실성 전달
• 최종 시스템에 대한 책임 수용

증거: 공개 진술서, 위험 평가, 프라이버시 검토 및 전문 발표.

제안된 숙련도 수준

2031년까지 전문 자격증은 특정 소프트웨어 도구에 대한 단순한 숙련도 확인이 아니라 이러한 수준을 통한 발전 과정을 보여주어야 합니다.

다양한 이해관계자를 위한 권고 사항

대학교

• 기존 과정에 에이전트 인식 소프트웨어 공학 모듈 추가.
• 기초 프로그래밍 및 알고리즘 유지.
• 일부 코드 생성 과제를 검토 및 전이 과제로 대체.
• 학생들에게 중요한 작업을 설명하고 옹호하도록 요구.
• 에이전트 도구, 평가 설계, 프라이버시 및 윤리 정책에 대해 교수진 교육.
• 공유 저장소 및 샌드박스 환경 구축.

부트캠프

• 기존 개발과 에이전트 지원 개발을 함께 가르칩니다.
• 테스트, 아키텍처 및 보안을 커리큘럼의 핵심 부분으로 만듭니다.
• 과정 기록이 포함된 포트폴리오 프로젝트를 요구합니다.
• 라이브 기술 시연을 추가합니다.
• 제품 발견 및 요구사항 작성을 가르칩니다.
• 프롬프팅만으로 즉시 실무에 투입 가능한 엔지니어를 양성한다고 약속하는 것을 피합니다.

자격증 제공 기관

• 실습 기반 평가의 활용도를 높입니다.
• 코드 검토, 테스트, 디버깅 및 위협 분석을 포함합니다.
• 고립된 객관식 문제 대신 현실적인 저장소를 사용합니다.
• 도구에 독립적인 판단력을 테스트합니다.
• 짧은 구두 설명 또는 녹화된 시연을 추가합니다.
• 특정 벤더의 인터페이스에 자격증이 종속되지 않도록 콘텐츠를 자주 업데이트합니다.

강사

• 모든 평가에 허용되는 사항을 정확히 명시합니다.
• 의도된 학습 성과를 중심으로 과제를 설계합니다.
• 학생들에게 승인된 도구 또는 동등한 대안을 제공합니다.
• 과정, 추론 및 검증을 평가합니다.
• 로그를 유일한 증거가 아닌 증거로 사용합니다.
• 인공지능 탐지 소프트웨어를 주요 진실성 메커니즘으로 의존하는 것을 피합니다.

학습자와 제품 개발자

• 생성된 코드를 읽고 이의를 제기할 수 있을 만큼 충분히 기존 프로그래밍을 배웁니다.
• 모호하고 큰 애플리케이션보다는 작은 제품으로 시작합니다.
• 에이전트를 사용하기 전에 명세를 작성합니다.
• 한 번에 하나의 이슈를 위임합니다.
• 모든 변경 사항을 검토하고 모든 가정을 테스트합니다.
• 중요한 결정을 기록으로 남깁니다.
• 에이전트를 의심할 여지 없는 전문가가 아닌, 빠른 주니어 협업자로 대합니다.

첫 번째 다음 단계

제품 생성 여정을 시작하는 사람에게 가장 유용한 첫 번째 단계는 다음과 같습니다.

에이전트에게 코드를 작성하도록 요청하기 전에, 하나의 작은 사용자 문제를 선택하고 한 페이지 분량의 명세를 작성하세요.

포함할 내용:

• 사용자가 누구인지
• 그들이 어떤 문제를 가지고 있는지
• 첫 번째 버전이 무엇을 해야 하는지
• 무엇을 해서는 안 되는지
• 세 가지 인수 테스트
• 한 가지 중요한 보안 또는 프라이버시 문제
• 세 가지 작은 구현 작업

그런 다음 에이전트에게 전체 제품을 구축하도록 하는 것이 아니라 명세를 검토하고 누락된 요구사항을 식별하도록 요청하세요.

명세를 수정한 후, 첫 번째 작업만 위임합니다. 제안된 계획을 검토하고, 변경 사항을 확인하며, 테스트를 실행하고, 에이전트가 무엇을 잘못했는지 기록합니다.

이 한 가지 연습은 에이전트 시대의 가장 중요한 교훈을 가르칩니다. 결과의 품질은 에이전트가 생산할 수 있는 코드의 양보다 인간이 작업을 얼마나 명확하게 정의하고, 감독하고, 평가하는지에 더 많이 달려 있다는 것입니다.

결론

개발자 교육은 새로운 균형으로 나아가고 있습니다.

학생들은 특히 기초 개념을 배우는 동안 여전히 코드를 작성해야 할 것입니다. 그러나 전문 역량은 점차 문제 분해, 명세화, 코드 이해, 검토, 테스트, 오케스트레이션, 제품 판단, 그리고 자율 시스템의 책임감 있는 사용을 통해 입증될 것입니다.

가장 강력한 교육 과정은 코딩 에이전트를 부정행위 도구 또는 마법 같은 튜터로 취급하지 않을 것입니다. 강력하지만 오류 가능성이 있는 엔지니어링 도구로 취급할 것입니다. 학생들은 언제 사용해야 하는지, 어떻게 제한해야 하는지, 결과물을 어떻게 평가해야 하는지, 그리고 최종 시스템에 대한 책임을 어떻게 져야 하는지를 배울 것입니다.

향후 5년간 가장 지속 가능한 개발자는 손으로 가장 많은 코드를 생산하거나 가장 긴 프롬프트를 생성하는 사람이 아닐 것입니다. 그것은 불분명한 목표를 신뢰할 수 있는 프로세스로 전환하고, 여러 도구를 그 목표로 이끌며, 실패를 조기에 감지하고, 결과 소프트웨어가 신뢰받을 가치가 있는 이유를 설명할 수 있는 사람일 것입니다.