AI 생성 코드 검토 교육: 개발자가 모델이 작성한 코드를 검토하는 방법을 가르치는 방법

한 개발자가 조수에게 사용자가 보고서를 다운로드할 수 있는지 확인하는 함수를 만들어 달라고 요청합니다. 코드는 컴파일되고, 정상 작동 테스트도 통과합니다. 풀 리퀘스트도 깔끔해 보입니다. 그런데 2주 후, 동료가 해당 함수가 사용자의 로그인 여부는 확인하지만, 보고서가 해당 사용자의 것인지는 전혀 확인하지 않는다는 사실을 발견합니다.

이는 예시 시나리오일 뿐, 실제로 발생한 사건은 아닙니다. AI 기반 코드 검토 교육이 극복해야 할 과제를 보여주는 예시입니다. 기본적인 검사를 통과한 생성된 코드라도 권한 문제나 동시 실행 오류와 같은 결함이 있을 수 있으며, 코드 검토자는 이를 찾아내고 왜 중요한지 설명해야 합니다.

이 가이드는 엔지니어링 지원 리더와 엔지니어링 관리자를 위한 것입니다. 성능 문제 설명, 격차 진단, 준비 및 실습 설계, 사례 분석, 그리고 습득한 기술이 실제 검토에 적용되는지 평가하는 방법을 다룹니다. 즉, 교육 설계에 관한 내용입니다. 프로그램의 모든 결함, 테스트 및 검토 규칙은 선임 엔지니어와 보안 팀의 검증을 거쳐야 합니다.

AI 기반 코드 검토 학습이란 무엇인가요?

AI 기반 코드 검토 교육은 개발자가 어시스턴트에게 명확하게 질문을 던지고, 반환된 내용을 평가하고 검토하는 방법을 가르칩니다. 즉, 코드가 정확한지, 안전한지, 동시 부하 환경에서 제대로 작동하는지, 충분히 효율적인지 등을 검토하는 것입니다. 이 교육은 특정 도구를 사용하는 방법을 가르치는 것이 아니라, 도구가 바뀌더라도 유지될 수 있는 코드 검토 습관을 기르도록 도와줍니다.

빠른 사실

1. 성능 문제를 설명하세요

먼저 다음과 같은 작업을 수행하십시오. 생성된 코드를 감사하고 테스트를 통해 위험을 입증하십시오. 감사는 의심을 가지고 코드를 읽는 것입니다. 입증은 의심을 증거로 바꾸는 것으로, 일반적으로 실패하는 테스트 또는 결함을 보여주는 재현 가능한 예제를 통해 이루어집니다.

이 연구는 왜 의도적인 연습이 필요한지 시사합니다. GitHub Copilot에 대한 연구에서 Pearce와 그의 동료들은 알려진 취약점 유형을 고려하여 선택된 89개 시나리오에 걸쳐 1,689개의 프로그램을 생성했고, 그 중 약 40%가 취약한 것으로 나타났습니다.피어스와 동료들, 2021이는 초기 도구였고 특정 시나리오에 국한된 것이므로, 이 수치를 오늘날의 AI 비서에 대한 비율로 간주해서는 안 됩니다. 별도의 사용자 연구에서는 참가자들에게 AI 비서를 사용한 경우와 사용하지 않은 경우로 코드를 작성하도록 요청했습니다. AI 비서를 사용한 참가자들은 보안성이 떨어지는 코드를 작성했으며, 자신의 코드가 안전하다고 믿는 경향이 더 높았습니다.페리와 동료들, 2023같은 연구에 따르면, 보조자를 덜 신뢰하고 보조자의 안내에 더 적극적으로 참여한 참가자들이 취약점을 덜 드러낸 것으로 나타났습니다.

훈련 설계에 있어 두 가지 교훈이 있습니다. 첫째, 타당한 결과물을 위해서는 적극적인 검토자가 필요합니다. 둘째, 확신은 증거가 아니므로, 훈련은 의견이 아닌 검증을 요구해야 합니다.

성능 평가문을 한 문장으로 작성하고 엔지니어링 관리자에게 확인을 받으세요. "개발자는 변경 사항이 주어졌을 때, 예상되는 보안, 동시성 및 효율성 위험을 나열하고, 각 위험에 대해 이를 보여줄 수 있는 테스트를 설명하거나 작성합니다."

2. 학습 및 맥락 격차를 진단합니다.

무엇을 만들기 전에, 현재 프로그램에서 연습하고 평가하는 내용과 비교해 보세요. 일반적으로 다음 세 가지 질문을 통해 교육 격차와 다른 요소를 구분할 수 있습니다.

1. 현재의 실무는 실제 과제를 활용하고 있는가? 만약 교육 과정에서 프롬프트 작성만 다루고 개발자에게 결과물을 검토하도록 요구하지 않는다면, 아무도 감사 연습을 하지 않은 것입니다. 만약 평가가 안전한 코딩 규칙에 대한 객관식 시험이라면, 그것은 단순히 암기력만을 측정하는 것입니다.
2. 인지적 요구 사항은 무엇입니까? 블룸의 개정된 분류 체계에서 코드의 안전성을 판단하고 이를 입증하는 테스트를 선택하는 것은 분석 및 평가 수준에 해당하며, 더 나은 프롬프트나 수정 사항을 설계하는 것은 창조 수준에 해당합니다. 이러한 수준에 활동을 연결하는 방법은 저희 가이드에서 다룹니다. 학습 활동을 블룸의 분류 체계에 맞추기.
3. 실력 외에 다른 요인이 방해가 되는 건가요? 검토 시간, 도구 및 담당자를 확인하세요. 검토자가 풀 리퀘스트당 5분밖에 주어지지 않는다면, 아무리 교육을 받아도 감사를 제대로 수행할 수 없습니다. 파이프라인에 정적 분석이나 테스트 환경이 없다면, 개발자는 위험을 발견할 수는 있어도 그 위험성을 입증할 수는 없습니다. 교육과 무관한 원인은 문제를 해결할 수 있는 담당자에게 보고하세요.

3. 설계 준비 및 실습

교육을 통해 어떤 격차를 해소할 수 있는지 파악했다면, 각 단계에 명확한 역할을 부여하십시오.

예비. 간단한 진단을 통해 필수 요건을 확인하세요. 스택이 직면한 일반적인 취약점 유형, 테스트 구조, 팀에서 사용하는 검토 체크리스트 등을 점검할 수 있습니다. 이 단계에서는 자기 주도 학습이 적합합니다. 복습 점검은 필수 요건 충족 여부만 확인합니다.

연습. 실제 코드와 유사한 환경에서 생성된 코드를 기반으로 감사 연습을 진행하세요. 각 연습에는 소유권 확인 누락, 두 요청 간의 경쟁 조건 발생, 비효율적인 루프 등 다양한 유형의 결함과 정상적인 코드를 소량씩 포함시키세요. 개발자는 코드를 검토하고, 각 위험 요소를 명시하고, 심각도를 평가하고, 해당 결함을 보여줄 수 있는 테스트 방법을 제안해야 합니다. 단순히 코드 줄 번호를 나열하는 것이 아니라, 그 이유를 설명하도록 요청하세요.

피드백. 총점보다는 결정 사항과 연결하세요. "공유 카운터에서 루프는 표시했지만 경쟁 조건은 표시하지 않았고, 테스트는 요청을 한 번에 하나씩 실행하기 때문에 이를 감지하지 못했을 것입니다."와 같은 메시지가 "3개 중 2개 발견"보다 더 유용합니다.

실시간 입력 방식인가요, 아니면 비동기식 검토 방식인가요? 실시간 피드백은 위험이 모호할 때 가장 큰 가치를 제공하며, 개발자는 선임 엔지니어가 병합을 차단하는 이유를 설명하는 것을 들으면서 배울 수 있습니다. 비동기 리뷰는 개발자의 의견과 전문가의 주석이 달린 리뷰를 비교하는 데 충분합니다. 많은 팀이 두 가지 방법을 모두 사용합니다. 먼저 자기 주도 학습으로 준비한 후, 어려운 사례에 대해 전문가의 도움을 받는 세션을 진행합니다.

4. 현실적인 예를 통해 살펴보세요

예시입니다. 엔지니어링 관리자는 사용 전에 사례와 답변 기준을 검증해야 합니다.

경우. 생성된 엔드포인트는 송장 ID로 고객의 송장을 반환합니다. 호출자가 유효한 세션을 가지고 있는지 확인하고, 매개변수화된 쿼리를 사용하며, 기본 테스트를 통과합니다. 동일한 함수가 잠금 없이 공유 다운로드 카운터를 증가시킵니다.

그 임무. 개발자는 자신이 파악한 각 위험 요소를 명시하고, 순위를 매기고, 각 위험 요소를 입증할 수 있는 테스트에 대해 설명합니다.

첫 시도입니다. "괜찮아 보이네요. 쿼리가 매개변수화되어 있고 테스트도 통과했어요." 개발자는 테스트 통과를 증거로 받아들이고 테스트에서 다루지 않는 부분이 무엇인지 묻지 않았습니다.

피드백 후 다시 시도하세요. 검토자는 개발자에게 세션 확인이 무엇을 증명하고 무엇을 증명하지 못하는지 명시해 달라고 요청합니다. 재시도 과정에서는 서로 다른 두 고객과 두 개의 동시 요청을 고려해 보라고 요구합니다.

좀 더 나은 시도였습니다. "세션 확인은 발신자가 누구인지 확인하는 것이지, 송장이 발신자의 것인지를 확인하는 것은 아닙니다. 고객 A가 고객 B의 송장 ID를 요청하고 거절당할 것으로 예상하는 테스트를 작성할 것입니다. 카운터는 동기화 없이 증가하므로 두 요청이 동시에 발생하면 업데이트가 누락될 수 있습니다. 동시 실행 테스트를 실행하고 카운트를 비교할 것입니다. 쿼리 자체는 매개변수화되어 있으므로 그 부분에 시간을 투자하지는 않을 것입니다." 이 답변은 위험 요소를 순위별로 나열하고 각 위험 요소를 테스트와 연결하고 있다는 점에 주목하세요.

각 답변이 타당한지 또는 불완전한지 판단하는 이유. 각 항목을 평가할 때는 검토자의 개인적인 선호가 아닌 승인된 기준에 따라 평가해야 합니다. 첫 번째 시도는 습관에 따른 것이지만 근거가 부족합니다. 더 나은 시도는 구체적이고 우선순위가 정해져 있으며 검증 가능합니다.

5. 역량을 평가하고 이전 계획을 수립합니다.

학습 능력의 증거는 학습자가 이전에 접해보지 못한 새로운 연습 문제를 수행하는 것입니다. 점수 검증의 질과 관련 결함의 식별이 중요합니다. 간단한 평가 기준표는 각 기준에 대해 0에서 2까지의 척도를 사용합니다.

평가 기준: 0은 부재 또는 미지원, 1은 관련 누락이 있는 부분적 지원, 2는 합의된 기준에 부합하는 완전하고 타당한 지원입니다. 보호되지 않은 접근 경로가 있는 코드 승인과 같은 중요한 오류는 별도로 정의하여 전체 점수에 오류가 포함되지 않도록 하십시오. 이 평가 기준표는 제안 사항이며 검증된 준비 표준이 아닙니다. 엔지니어링 관리자와 협의하여 수정하고 시범 운영해 보십시오. 유용한 피드백을 제공하는 상호작용적 연습 설계 의사 결정과 연계된 피드백 작성 방법을 보여줍니다.

의도적으로 계획 이전을 진행하세요. 연습 후, 각 개발자에게 생성된 코드가 포함된 실제 풀 리퀘스트를 주고 함께 검토하거나, 최근 검토에서 놓친 부분을 중심으로 간단한 회고를 진행하세요.

상호작용적 전달이 도움이 되는 경우

상호작용형 형식은 모든 구성원이 그룹 토론 전에 의견을 제시하고 확정할 수 있도록 도와줍니다. 실시간 세션에서는 진행자가 생성된 코드 조각을 보여주고, 각 개발자에게 예상되는 위험 요소와 작성할 테스트를 입력하도록 요청한 다음, 토론 전에 전체 내용을 공개할 수 있습니다. 동일한 연습을 자기 주도 학습 방식으로 미리 진행할 수도 있습니다. AhaSlides는 상호작용형 학습을 지원하며 실시간 및 자기 주도 학습 방식 간의 전환을 용이하게 합니다. AhaSlides는 프레젠테이션 및 학습 도구이지 코드를 실행하는 도구가 아니므로 코드 연습은 자신의 환경에서 실행해야 합니다. 사용하려는 특정 작성, 피드백 또는 보고 기능이 자신의 워크플로와 호환되는지 확인하십시오. 형식 선택에 대한 자세한 내용은 관련 문서를 참조하십시오. 적응형 학습, 상호작용형 학습, 실시간 학습은 언제 사용해야 할까요?.

변화된 것을 측정하세요

개발자가 해당 작업을 수행할 수 있음을 보여줄 방법을 사전에 결정하십시오. 기준선과 비교하여 미지의 연습 문제에 대한 검증 품질 및 결함 식별률을 비교하십시오. 참여 대상, 분모 및 기간을 정의하십시오. 결과가 개선되면 교육 이수를 인정하기 전에 새로운 정적 분석 규칙, 수정된 검토 체크리스트 또는 보조 담당자 변경과 같이 동일 기간 동안 변경된 다른 사항을 확인하십시오.

남아 있을 수 있는 제약 조건

• 복습 시간입니다. 감사는 간략 검토보다 시간이 더 오래 걸리고, 마감일은 간략 검토 쪽으로 쏠립니다.
• 압형. 테스트 장비나 스캐닝 ​​시스템이 구축되어 있지 않으면 위험성을 입증하기 어렵습니다.
• 도구를 바꾸다. 어시스턴트는 빠르게 변화하므로 특정 제품이 아닌 리뷰 습관에 대한 연습을 지속하세요.
• 사건 처리 범위. 한 연습문제는 몇 가지 결함 유형을 보여줍니다. 점수만으로는 개발자의 판단력을 전반적으로 설명할 수 없습니다.
• 이전. 워크숍에서의 성과는 바쁜 리뷰 대기열에서의 성과와는 다릅니다.

이러한 문제점들을 스폰서에게 조기에 알리고 별도의 해결 방안을 계획하세요. 교육은 개발자가 발견하고 입증할 수 있는 능력을 향상시켜 줍니다. 하지만 교육이 시간이나 도구를 만들어 주는 것은 아닙니다.

자주하는 질문

AI 기반 코드 검토 학습이란 무엇인가요?

이 프로그램은 개발자에게 AI 어시스턴트가 생성한 코드를 검토, 평가 및 감사하는 방법을 가르쳐 보안, 동시성 및 효율성 문제를 찾아내고 각 문제를 테스트로 뒷받침할 수 있도록 합니다.

생성된 코드가 사람이 작성한 코드보다 보안성이 떨어지는가?

연구 결과는 위험성을 시사하지만, 결과는 도구, 작업 및 연구 설계에 따라 달라집니다. 한 사용자 연구에서는 보조 도구를 사용한 참가자들이 보안 수준이 낮은 코드를 작성했지만 더 큰 자신감을 느꼈다는 결과가 나왔는데, 이는 코드 검토 습관을 기르는 것이 중요하다는 것을 보여줍니다.

개발자가 생성된 코드를 감사할 수 있는지 어떻게 평가하나요?

새로운 코드 연습 문제를 제시하고, 합의된 기준에 따라 검증 품질과 결함 식별 능력을 평가합니다. 안전한 코딩 규칙에 대한 퀴즈는 필수 요건 충족 여부만 확인합니다.

교육을 위해 코드 샌드박스가 필요하신가요?

연습을 실행할 공간이 필요하며, 일반적으로는 자신의 환경이 적합합니다. 사용하는 도구가 필요한 기능을 지원하는지 확인한 후에 사용하십시오.

어디서 시작하나요

코드베이스에서 반복적으로 발생하는 변경 사항 한 가지를 선택하세요. 성능 설명서를 작성하고, 엔지니어링 관리자에게 심어놓은 결함과 이를 보여줄 테스트를 검증받으세요. 그리고 0에서 2까지의 척도로 평가하는 3가지 기준과 중요한 오류 목록을 작성하세요. 전체 배포 전에 소규모 그룹으로 시범 운영해 보세요.

감사 실습을 팀원들과 함께 실시간으로 진행하고, 이후에도 자율 학습 방식으로 재사용하는 방법을 알아보려면 AhaSlides를 살펴보세요.