AI 코딩 도구 및 워크플로 통합 — 소프트웨어 및 기술 팀을 위한 인공 지능

이득:

편집자 완성, 채팅 도우미, CLI 에이전트 및 CI 자동화 범주를 작업에 매핑하는 기능
위험에 따라 자율성 수준을 조정하고 CLI 에이전트에 '계획 우선' 원칙을 적용하는 기능
검증된 도구, 검증 게이트, 투명성 및 책임성을 기반으로 AI 사용을 팀 시스템으로 전환하는 능력

지금까지 우리는 개별 작업(코딩, 검토, 테스트, 디버깅)에서 AI를 사용하는 방법을 배웠습니다. 이 마지막 단원에서는 다양한 AI 코딩 도구에 대해 알아보고, 올바른 도구를 올바른 작업에 연결하고, 편집기에서 버전 제어, CI/CD 파이프라인에서 팀 거버넌스에 이르기까지 일상적인 개발 흐름에 안전하게 포함시키는 작업을 함께 진행합니다. 목표는 지저분한 "가끔 AI에게 물어보는" 습관을 일관되고 감사 가능한 작업 시스템으로 바꾸는 것입니다.

우리는 중립 카테고리로 차량 유형을 다룹니다(특정 제품 이름은 빠르게 변경됩니다. 카테고리가 하는 일이 중요합니다). 각 카테고리에는 "최적의 지점"과 위험 프로필이 있습니다. 숙달이란 어떤 작업에 얼마나 많은 자율성을 부여해야 하는지를 아는 것입니다.

AI 코딩 도구 카테고리

1. 에디터 내 완성. IDE(코드를 작성하는 개발 환경)에 입력할 때 줄/블록을 제안하는 플러그인입니다. 최적의 장소: 인스트림 속도, 상용구 코드. 위험: 좁은 맥락, 생각 없이 제안을 받아들이는 것.

2. 채팅/사이드 패널 보조자. 코드베이스의 일부를 볼 수 있는 IDE에 포함된 채팅 인터페이스입니다. 최적의 장소: 설명, 리팩터링, 테스트, 버그 분석. 위험: 제공한 상황에 따라 제한되며 확인이 필요합니다.

3. CLI 에이전트(에이전트 도구). 명령줄에서 실행되는 도구는 여러 파일을 읽고 수정하고, 명령을 실행하고, 다단계 작업을 자체적으로 실행할 수 있습니다. 최적의 장소: 다중 파일 변경, 반복 작업, "이 속성 추가" 유형 작업. 위험: 높은 자율성 = 높은 영향; 선택하지 않은 상태로 두면 광범위하고 확인하기 어려운 변경 사항이 발생합니다.

4. 라인/자동화 통합. PR에 자동 검토 의견을 남기고, 테스트를 제안하고, 변경 로그를 생성하는 CI(지속적 통합) 봇입니다. 최적의 장소: 피로감이 없는 첫 번째 여과기, 일관성. 위험: 소음, 잘못된 신뢰.

힌트: 자율성이 높아지면 통제도 높아져야 합니다. 편집 완료는 규모가 작고 즉각적이므로 감독이 적습니다. CLI 에이전트의 다중 파일 수정은 인간 PR보다 더 주의 깊게 검사해야 합니다.

단계별: 워크플로에 AI 삽입

작업을 도구에 매핑합니다. 소규모 인스트림 추가 → 완료; 이해/리팩터링/테스트 → 채팅; 다중 파일, 반복 작업 → CLI 에이전트; 연속 1차 필터 → CI 통합.
자율성 수준을 선택하십시오. 에이전트는 얼마나 많은 자유를 갖고 있나요? 읽기 전용 제안 또는 파일 수정 + 명령 실행? 위험에 맞게 조정하세요.
맥락을 육성하세요. 프로젝트 규칙(스타일, 아키텍처, "하지 말아야 할 일")을 도구에 영구적으로 도입합니다. 반복해서 설명하는 대신 프로젝트 지침 파일을 사용하십시오.
검증 게이트를 유지합니다. AI 변화는 인간의 변화와 같습니다. 편집, 테스트, 검토 및 (중요한 경우) 전문가 승인을 거칩니다. AI 개통PR은 승인을 우회하지 않습니다.
측정하고 조정하세요. 수정 부담이 증가하는 부분에서 실제로 속도가 빨라지는 부분을 살펴보세요. 효과가 없는 용도는 잘라내세요.

미니 케이스 3개

사례 1 - CLI 에이전트가 다중 파일 이름 바꾸기를 처리했습니다. 한 팀은 60개 파일에 분산된 개념의 이름을 변경합니다. 그들은 CLI 에이전트에게 작업을 부여하고 먼저 계획을 요청하고 계획을 승인한 다음 변경하고 전체 테스트 제품군을 실행했습니다. 에이전트 3은 파일에서 극단적인 사례를 놓쳤습니다. 테스트 결과 이를 발견하고 수정했습니다. 수작업으로 약 3시간이 소요되었던 작업이 감독하에 50분만에 완료되었습니다.

사례 2 - 확인되지 않은 자율성은 역효과를 냈습니다. 또 다른 개발자는 에이전트에게 "이 모듈을 개선"하라고 말하고 출시했습니다. 에이전트는 18개의 파일을 수정하고 2개의 종속성을 추가했습니다. 변경 내용이 너무 광범위해서 검토할 수 없었고 철회되어야 했습니다. 교훈: 상담원에게 좁은 범위, 명확한 승인 기준, 먼저 계획하고 나중에 할 규율을 제공합니다.

사례 3 - CI 검토 봇이 첫 번째 필터가 되었습니다. 한 팀은 PR에 자동화된 AI 검토 댓글을 남기는 봇을 구축했습니다. 봇이 null 검사 누락과 스타일 문제를 포착한 후 인간 검토자는 비즈니스 로직에 시간을 할애할 수 있었습니다. 그러나 팀은 봇이 "승인"을 제공하지 않았음을 분명히 밝혔습니다. 최소한 한 번의 인간 승인이 여전히 필요합니다. 소음을 줄이기 위해 그들은 높은/중간 강도의 소음만 남기도록 보트를 조정했습니다.

복사 가능한 템플릿 4개

CLI 에이전트에 대한 "우선 계획" 규율:

작업: {{명확하고 좁은 작업}}수락 기준: {{측정 가능한 결과}}제약: {{다음 디렉터리/파일}}에서만 작업합니다. 새 종속성을 추가합니다. 먼저 변경하지 않고 계획을 제시합니다. 어떤 파일, 무엇을 변경할지, 어떤 테스트를 실행할지. 내가 계획을 승인할 때까지 기다려 주세요. 그런 다음 단계별로 적용하고 각 단계에서 테스트를 실행합니다.

프로젝트 지침 파일(도구에 대한 지속적인 컨텍스트):

이 프로젝트의 AI 도구에 대한 영구 규칙:- 언어/버전: {{...}}. 스타일: {{...}}.- 아키텍처 제약: {{e.g. 레이어 간 방향}}.- 절대로: 비밀 삽입, 프로덕션 데이터 사용, {{금지된 라이브러리}}.- 모든 변경 사항은 테스트 가능해야 합니다. 묻지 않고 공개 API 서명을 변경합니다. - 의심스러우면 멈춰서 물어보세요.

작업 도구 매핑 결정:

나는 다음 작업을 정의합니다: {{task}}. (a) 편집기 완성, (b) 채팅 도우미, (c) CLI 에이전트, (d) CI 자동화 등 어떤 클래스의 도구를 사용해야 합니까? 근거, 위험 및 권장 자율성 수준(단순한 제안/파일 변경/실행 명령)을 작성합니다.

CI 검토 봇 행동 강령:

PR 검토에는 HIGH 및 MEDIUM 심각도 결과만 의견으로 남겨주세요. 각 결과: 카테고리, 심각도, 제안된 수정 사항. 스타일 기본 설정 수준의 메모를 별도의 단일 요약 메모로 수집합니다. 귀하는 동의하지 않습니다. 사람의 승인이 필요합니다.

약한 프롬프트 / 강한 프롬프트

약함: (CLI 에이전트에게) "결제 모듈을 더 좋게 만드세요."

Strong: (CLI 에이전트에게) "src/paids/에서만 실행됩니다. 작업: Refund() 함수에서 재귀 유효성 검사 논리를 단일 도우미로 추출합니다. 동작과 서명은 변경되지 않습니다. 먼저 계획을 제시하고 내 승인을 기다린 다음 테스트/지불/ 패키지를 실행하고 실행합니다. 새 종속성을 추가합니다."

강력한 버전은 범위를 좁히고 수용 기준과 제약 조건을 설정하며 "계획 우선" 원칙을 적용합니다. 모호한 "더 나은 성과" 요구는 거대하고 통제할 수 없는 변화의 근본 원인입니다.

차량 등급

그 사람이 제일 잘하는 게 뭐야?

자율성

검사 중량

에디터 완성

소규모 인스트림 추가

낮음

가벼움(즉시 읽기)

채팅 도우미

이해, 테스트, 리팩터링

중간

중간(출력 검증)

CLI 에이전트

다중 파일, 재귀

높다

Heavy (계획 + 전체 검토)

CI 자동화

연속 1차 필터

중간

중간(규칙 + 사람 승인)

팀 거버넌스: 개인 기술에서 공유 시스템까지

개인별로 AI를 잘 활용하는 것이 시작입니다. 진정한 성숙은 팀 수준의 일관된 시스템입니다. 이 시스템은 승인된 도구 목록(어떤 데이터와 함께 사용할 수 있는지 - 유닛 10에서), 검증 게이트(AI 변경이 유닛 11에서 동일한 빌드/테스트/검토 게이트를 통과함), 투명성(필요한 경우 AI 기반 변경이 추적성을 제공한다고 명시), 책임의 명확성(승인하고 책임을 지는 사람이 분명함) 등 여러 기둥을 기반으로 합니다. 이 프레임워크는 속도를 유지하면서 위험을 제한하고 새로운 팀 구성원이 동일한 원칙에 따라 작업하도록 보장합니다.

주의: 도구(특히 파일을 수정하고 명령을 실행할 수 있는 CLI 에이전트)의 자율성이 높을수록 프로덕션 환경, 기밀 데이터 및 되돌리기 어려운 작업에 대한 액세스를 더욱 엄격하게 제한합니다. 파괴적인 명령(영구 삭제, 배포)을 사람의 승인과 연결하세요.

일반적인 실수

작업은 비호환성을 의미합니다. 무거운 에이전트로 편집 완성이나 작은 첨부 파일로 여러 파일 작업을 하려고 합니다.
에이전트를 해제합니다. 좁은 범위와 "우선 계획" 없이 주어진 상담원 작업은 검토되지 않은 변화를 낳습니다.
AI 검증 게이트를 완화합니다. "AI가 해냈으니 빨리 넘어가자"는 것은 가장 위험한 예외이다. 문은 누구에게나 똑같습니다.
매번 수동으로 컨텍스트를 제공합니다. 영구 지침 파일에 프로젝트 규칙을 작성하지 않으면 불일치와 중복이 발생합니다.
CI 봇의 승인을 사람의 승인으로 착각합니다. 봇은 필터입니다. 책임 있는 사람의 승인은 필수입니다.

요약하면

AI 코딩 도구는 편집기 완성, 채팅 도우미, CLI 에이전트, CI 자동화의 네 가지 주요 범주로 분류됩니다. 숙달이란 작업을 올바른 도구와 적절한 수준의 자율성에 맞추는 것입니다. 자율성이 높아지면 통제력도 높아집니다. 도구에 지속적인 프로젝트 컨텍스트를 제공하고, 다중 파일 에이전트에 "계획 우선" 원칙을 적용하고, 인간 변경과 동일한 검증 게이트를 통해 AI 변경을 전달합니다. 개인기량; 승인된 도구 목록, 검증 게이트, 투명성 및 책임의 명확성을 기반으로 구축된 팀 시스템으로 전환하세요. AI는 엔드 투 엔드 속도 승수입니다. 계정에 서명하고 제공하는 사람은 항상 유능한 사람입니다.

응용과제

다음 주에 수행할 실제 작업 세 가지를 나열하십시오. 각각에 대해 "작업 대 차량 일치 결정" 템플릿을 사용하여 선택할 차량 클래스와 자율성 수준을 정당화합니다. 그런 다음 "계획 우선" 원칙을 사용하여 CLI 에이전트(또는 채팅 도우미)에 대해 좁은 작업을 실행합니다. 즉, 계획을 승인하고 시행하고 테스트를 실행하고 인간 PR처럼 변경 사항을 검토합니다. 마지막으로 팀을 위한 5가지 "AI 사용 규칙"(승인된 도구, 데이터 규칙, 검증 게이트, 자율성 제한, 책임) 초안을 작성하세요.

체크리스트

[ ] AI 코딩 도구 카테고리와 각각의 장점을 구분할 수 있습니다.
[ ] 나는 작업을 올바른 차량 클래스와 적절한 자율성 수준에 매핑합니다.
[ ] 나는 도구에 영구적인 프로젝트 컨텍스트(지침 파일)를 제공합니다.
[ ] 저는 CLI 상담원에게 좁은 범위와 "우선 계획" 규율을 적용합니다.
[ ] AI 변경은 인간 변경과 동일한 검증 게이트를 통해 통과합니다.
[ ] 저는 팀 수준에서 검증된 도구, 데이터 규칙, 투명성 및 책임 프레임워크를 옹호합니다.

모듈 시험

1. 코딩 도우미의 기본 대규모 언어 모델은 코드를 생성할 때 실제로 무엇을 수행합니까?

A) 주어진 상황을 기반으로 가장 가능성이 높은 연속성을 패턴적으로 예측합니다. ✔
B) 실제로 코드를 컴파일하고 실행하여 올바른 결과를 보장합니다.
C) 실시간으로 인터넷상의 코드를 스캔하여 가장 정확한 코드를 복사합니다.
D) 인간 엔지니어처럼 코드의 논리를 이해하고 의도를 이해합니다.

설명: LLM은 인간처럼 코드를 '이해'하지 않습니다. 이는 매우 큰 텍스트 및 코드 풀에서 학습한 패턴을 기반으로 주어진 컨텍스트에 대해 가장 가능성이 높은 연속성을 생성합니다. 따라서 출력의 품질은 제공하는 컨텍스트 및 지침의 품질에 직접적으로 좌우되며 각 출력의 유효성을 검사해야 합니다.

2. AI가 존재하지 않는 함수나 라이브러리를 설득력 있게 만들어내는 것을 무엇이라고 부르며, 유일한 해독제는 무엇입니까?

A) 이를 컴파일 오류라고 합니다. 해독제는 더 강한 장비입니다
B) 이것을 환각이라고 합니다. 해독제는 사용된 코드와 각 API를 확인하는 것입니다 ✔
C) 이것을 회귀라고 합니다. 해결책은 모델을 다시 시작하는 것입니다.
D) 이를 컨텍스트 오버플로라고 합니다. 해독제는 프롬프트를 단축하는 것입니다.

설명: 이를 환각이라고 하며 소프트웨어에서 가장 비용이 많이 드는 버그 중 하나를 유발합니다. 유일한 실제 해독제는 사용된 모든 함수, API 및 패키지가 실제로 존재하고 코드가 작동하는지 확인하는 것입니다. 모델의 자신감 넘치는 어조가 정확성을 입증하는 것은 아닙니다.

3. AI로 코드를 생성할 때 출력의 품질과 일관성을 가장 향상시키는 접근 방식은 무엇입니까?

A) 어떠한 맥락도 제공하지 않고 '이것을 나에게 써주세요'라고 말하여 모델을 출시합니다.
B) 가능한 가장 길고 화려한 프롬프트 작성
C) 입력/출력 계약, 엣지 케이스, 버전 및 스타일 지정 및 예 제공 ✔
D) 생성된 코드를 읽지 않고 직접 결합하기

설명: 함수의 입력/출력 유형(계약), 엣지 케이스, 언어/버전 및 스타일 제약 조건을 결정하고 모델에 예제를 제공하면 예측에서 정밀도로 전환할 수 있습니다. 컨텍스트 없는 'write me this' 요청은 매번 다른 코드를 생성하고 종종 극단적인 경우를 우회합니다.

4. AI로 외국 코드베이스를 탐색할 때 함수 이름이 'validateAndSave'이지만 AI 다이제스트가 정확하지 않을 수 있습니다. 올바른 접근 방식은 무엇입니까?

A) 이름이 설명이 필요하므로 AI 요약에 대한 완전한 신뢰
B) 읽지 않고 직접 기능 변경
다) 함수명만 보고 결정
D) AI 설명을 가설로 취급하고 코드에서 한 줄씩 중요한 주장을 확인합니다. ✔

설명: AI는 코드의 이름을 보고 '무엇을 하고 있는지' 알려줄 수 있지만 실제로는 논리가 다를 수 있습니다(또는 그 반대일 수도 있음). 그래서 AI 설명은 가설이다. 중요한 청구, 특히 보안, 권한 또는 자금 흐름과 관련된 청구는 관련 라인에서 시각적으로 확인되어야 합니다.

5. AI 지원 코드 리뷰에서 'AI가 봤어, 분명해'라고 말하는 가장 큰 위험은 무엇인가요?

A) AI는 위음성을 생성할 수 있습니다. 실제 놓친 실수는 잘못된 자신감을 만듭니다 ✔
나) AI 검토가 너무 느려 시간낭비
다) AI가 영어로만 설명을 하기 때문에 팀에서는 이해하지 못한다.
D) AI는 항상 과잉 해석을 하기 때문에 PR은 수렴되지 않습니다.

설명: AI는 거짓 긍정(문제가 존재하지 않는 곳에 표시)과 거짓 부정(실제 버그 누락)을 모두 생성합니다. 거짓 부정은 침묵합니다. 가장 위험한 실수는 리뷰에서 전혀 언급되지 않은 실수입니다. 따라서 AI는 승인이 아닌 첫 번째 필터입니다. 합병 결정은 책임 있는 사람의 몫입니다.

6. AI에게 코드와 인쇄 테스트만 주면 발생하는 가장 교활한 함정은 무엇입니까?

A) AI는 항상 너무 많은 테스트를 작성하고 코드베이스를 부풀립니다.
B) AI는 코드의 현재(아마도 잘못된) 동작을 '올바른' 것으로 테스트하고 버그를 수정합니다. ✔
C) AI는 테스트 작성 시 자동으로 코드를 삭제합니다.
D) AI는 행복한 경로뿐만 아니라 항상 극단적인 경우에 대한 테스트를 작성합니다.

설명: AI는 코드를 보고 현재 동작을 테스트하는 주장을 작성하는 경향이 있습니다. 코드가 처음부터 잘못된 경우 AI는 이 잘못된 동작을 '올바른' 것으로 수정합니다. 따라서 테스트의 기대치는 코드의 현재 출력이 아닌 필수 규칙(사양)에 따라 작성되어야 합니다.

7. AI로 버그를 디버깅할 때 가설의 정확성을 가장 결정하는 것은 무엇입니까?

A) 프롬프트가 얼마나 정중하게 작성되었는지.
B) 질문이 몇 번이나 다시 요청되었는지
C) 모델에 제공되는 증거의 품질: 전체 오류 메시지, 스택 추적, 입력 및 예상 동작 ✔
D) 코드는 어떤 색상 테마로 작성되었나요?

설명: AI는 사용자가 보는 방식으로 오류를 볼 수 없습니다. 그는 당신이 그에게 제공한 증거만을 알고 있습니다. 전체 오류 메시지, 스택 추적, 입력 트리거 및 예상 동작이 주어지면 모델은 실제 가능성을 열거합니다. 증거가 없으면 추측(환각)을 해서 잘못된 길로 인도한다.

8. 분석을 위해 AI에 생산 로그를 제공하기 전에 가장 중요한 단계는 무엇입니까?

A) 하루 종일 로그를 그대로 붙여넣기
B) 먼저 로그를 대문자로 변환
다) 로그 라인을 알파벳순으로 배열하기
라) 개인정보 및 비밀은 마스킹하고 해당 창만 공개 ✔

설명: 원시 프로덕션 로그에는 IP, 이메일, 세션 ID, 토큰이 포함되며 때로는 공개 비밀이 포함됩니다. 이를 가리지 않고 AI 도구에 집어넣는 것은 심각한 개인정보 침해입니다. 또한 로그는 좁은 기간으로 필터링되어야 합니다. 하지만 가장 먼저 필요한 것은 민감한 데이터를 정리하는 것입니다.

9. AI가 로그 분석에서 두 가지 이벤트가 '동시에' 발생했다고 말하고 하나를 근본 원인으로 선언하면 어떻게 해야 합니까?

A) 상관관계를 인과관계로 무시하고 메트릭과 코드로 주장 확인 ✔
B) AI가 시간 관계를 설정하므로 원인을 확정적인 것으로 받아들입니다.
C) 첫 번째 비난된 구성 요소를 즉시 다시 시작
라) 로그를 완전히 삭제하고 다시 수집하는 방법

설명: 로그 분석에서 가장 흔히 발생하는 함정은 상관관계와 인과관계를 혼동하는 것입니다. AI가 구축한 시간 관계는 증거가 아닌 단서이다. 진정한 인과 관계에는 타이밍, 메커니즘, 그리고 가능하다면 반복성이 필요합니다. 클레임은 메트릭과 코드로 검증되어야 합니다.

10. AI로 리팩토링할 때 타협할 수 없는 황금률은 무엇이며 이를 보장하는 것은 무엇입니까?

A) 코드는 더 짧아야 합니다. 라인 수가 이를 보장합니다.
B) 행동에 변화가 없습니다. 현재 동작을 포착하는 테스트는 이를 보장합니다 ✔
C) 코드에 더 많은 주석이 포함되어 있습니다. AI가 이를 보장한다
D) 전체 파일을 한 번에 다시 작성합니다. 대리인이 이를 보증합니다.

설명: 리팩토링은 외부 동작을 변경하지 않고 코드의 내부 구조를 개선하는 것입니다. 황금률은 행동이 일정하게 유지된다는 것입니다. 이를 보장하는 것은 테스트입니다. 현재 동작을 변경하기 전에 캡처하는 테스트넷이 각 단계 후에 설정되고 실행됩니다. 테스트넷 없이 리팩토링하는 것은 도박입니다.

11. AI가 알 수 없고 구성하기 위험한 문서 작성 계층은 무엇입니까?

A) 설치 단계를 실행하는 방법
나) 함수의 매개변수 목록
C) '왜' 디자인 결정이 그런 식으로 이루어졌는지에 대한 정당성 ✔
D) 코드는 어떤 언어로 작성되었나요?

설명: AI는 코드에서 '무엇/어떻게' 레이어(기능이 수행되는 작업, 설정 방법)를 추출할 수 있습니다. 하지만 '이유' 레이어(결정에 대한 설계 근거, 한계 값에 대한 이유)는 알 수 없습니다. 꾸며낸 '이유'는 정당하지 않은 것보다 더 위험합니다. 코드 소유자가 이 레이어를 추가해야 합니다.

12. 개발자가 긴급한 버그를 해결하는 동안 라이브 API 키가 포함된 구성 파일을 승인되지 않은 AI 도구에 붙여넣고 싶다면 어떻게 해야 합니까?

A) 속도를 위해 파일을 그대로 붙여넣은 후 채팅을 삭제하세요.
B) 파일 끝에 '기밀' 메모를 추가하고 전송합니다.
다) 키는 그대로 두고 파일명만 변경
D) 비밀을 제거/마스크하고 꼭 필요하고 민감하지 않은 컨텍스트만 제공 ✔

공개: 비밀, 개인 데이터 및 기밀 자산은 승인되지 않은 수단으로 입력되어서는 안 됩니다. 긴급성으로 인해 이 빨간색 선이 중단되지는 않습니다. 올바른 접근 방식은 비밀을 먼저 추출/마스크하고 필수적이고 민감하지 않은 컨텍스트만 제공하는 것입니다. 그래도 비밀이 유출되면 가장 먼저 해야 할 일은 즉시 해당 키를 돌리는 것입니다.

13. AI 생성 코드는 테스트를 통과하고 프로덕션에서 실행됩니다. 이것이 코드가 안전하다는 것을 증명하는 것인가요?

답) 아니요. '작동'이 보안을 의미하는 것은 아니며, 보안에는 별도의 인증 계층이 필요합니다 ✔
나) 그렇습니다. 테스트를 통과한 코드는 정의상 안전합니다.
다) 그렇습니다. 프로덕션 환경에서 실행하면 모든 취약점이 제거됩니다.
D) 아니요. 하지만 보안은 코드가 느린 경우에만 중요합니다.

설명: '작업 중'은 '보안'과 동일하지 않습니다. 코드에 SQL 주입과 같은 취약점이 포함되어 있더라도 테스트를 통과하고 원활하게 실행될 수 있습니다. 취약점은 공격자가 발견한 경우에만 드러납니다. 따라서 정확성 외에도 SAST와 같은 보안 중심의 검토 및 스캔을 별도의 레이어로 수행해야 합니다.

14. CLI 에이전트(파일을 수정하고 명령을 실행할 수 있는 자율 도구)에 다중 파일 작업을 제공할 때 가장 안전한 규칙은 무엇입니까?

A) 상담원에게 '이 모듈을 개선하세요'라고 말하고 완전한 자유를 줍니다.
B) 좁은 범위와 수용 기준을 제시하고 먼저 계획을 요청하고 승인하고 단계별로 구현하고 테스트를 실행합니다. ✔
C) 에이전트의 모든 변경 사항을 검토하지 않고 직접 병합
D) 에이전트에게 프로덕션 환경 및 기밀 데이터에 대한 무제한 액세스 권한 부여

설명: 자율성이 높아지면 통제도 높아져야 합니다. 에이전트에게 좁은 범위와 명확한 승인 기준을 제공하고 먼저 변경 없는 계획을 요청하고 계획을 승인한 다음 단계별로 구현하고 각 단계에서 테스트를 실행합니다. 이는 광범위하고 검토할 수 없으며 롤백해야 하는 변경 사항을 방지합니다.

15. 보안에 중요한 소프트웨어(예: 결제 또는 인증)의 AI 생성 코드로 인해 발생하는 책임은 누구에게 있습니까?

A) 코드는 AI에서 나오므로 차량 제공업체에 있습니다.
B) AI가 충분히 개발되면 아무도 개발하지 못합니다. 확인할 필요 없어
C) 코드를 검사, 조립, 배포하는 팀/엔지니어 AI는 동의를 대체하지 않습니다 ✔
D) 프롬프트를 작성하는 사람만 해당하고 검토하는 사람은 해당되지 않습니다.

설명: AI는 속도 승수이자 청사진 생성기입니다. 책임을 질 수 없습니다. 프로덕션 코드에서 발생하는 모든 오류, 취약점 또는 위반에 대한 책임은 해당 코드를 검토, 조립 및 배포하는 팀에 있습니다. 안전이 중요한 영역에서 AI 출력은 어떤 상황에서도 자격을 갖춘 엔지니어의 검토 및 승인을 대체할 수 없습니다.