소프트웨어 팀을 위한 인공 지능: 작업 모델 및 한계

이득:

• 코딩 어시스턴트가 언어 모델로 작동하는 방식과 토큰, 컨텍스트 창, 환각의 개념을 설명하는 능력
• AI가 강한 소프트웨어 업무와 약한 소프트웨어 업무를 멘탈맵으로 구분하는 능력
• 제안-생산-검증의 기본 업무주기를 자신의 업무에 적용할 수 있는 능력

소프트웨어 개발자의 하루는 "처음부터 코드 작성"에 소비되는 경우가 거의 없습니다. 실시간; 다른 사람이 작성한 코드 읽기, 버그 재현 시도, 로그 스캔(애플리케이션 실행 중 생성된 로그 라인), 테스트 작성, PR(풀 요청 - 팀 검토를 위해 코드 변경 사항이 제출되는 병합 요청) 설명 작성 및 문서 업데이트. 인공지능(AI)은 눈에 보이지 않는 거의 모든 직업을 다룰 수 있는 속도 승수입니다. 하지만 안전하게 사용하기 위한 첫 번째 조건은 그것이 무엇인지, 무엇이 아닌지를 정확하게 이해하는 것입니다.

이 단원에서는 먼저 코딩 도우미의 기본 기술을 일반 언어로 설명합니다. 그런 다음 모델의 강점과 약점에 대한 정신적 지도를 만듭니다. 마지막으로 전체 모듈에서 사용할 기본 작업 원칙(제안, 생산, 검증)을 설정합니다. 이 세 단계는 다음 11개 단위의 중추입니다.

참고: 이 모듈은 일반 교육입니다. 보안이 중요한 소프트웨어(결제 처리, 의료, 인증, 중요 인프라)에서 AI 출력은 자격을 갖춘 엔지니어의 검토 및 승인을 대체할 수 없습니다. AI는 조수입니다. 서명자는 엔지니어입니다.

코딩 어시스턴트는 실제로 무엇을 합니까?

대부분의 코딩 도우미는 대규모 언어 모델(LLM, 다음으로 가능성이 가장 높은 "청크"를 예측하는 엄청난 양의 텍스트와 코드에 대해 훈련된 AI)을 기반으로 구축되었습니다. 모델은 인간처럼 코드를 "이해"하지 않습니다. 방대한 예제 풀에서 학습한 패턴을 기반으로 사용자가 제공한 컨텍스트의 가장 가능성 있는 연속성을 생성합니다. 겉보기에 단순해 보이는 이 메커니즘은 실제로 놀라울 정도로 뛰어난 결과를 제공합니다. 왜냐하면 대부분의 소프트웨어는 HTTP 요청, 루프, Null 검사, 테스트 패턴 등 반복되는 패턴으로 구성되어 있기 때문입니다.

여기서는 세 가지 용어가 중요합니다. 토큰은 모델이 텍스트를 나누어 처리하는 가장 작은 단위입니다. 대략 몇 글자 또는 단어의 일부입니다. 컨텍스트 창은 모델이 한 번에 "볼" 수 있는 토큰의 양입니다. 코드, 오류 메시지 및 지침이 이 창에 맞아야 합니다. 프롬프트는 모델에 제공하는 모든 지침과 컨텍스트입니다. 얻는 결과의 품질은 이 두 가지에 직접적으로 달려 있습니다. 즉, 모델에 더 나은 맥락과 명확한 지침을 제공할수록 더 나은 결과를 얻을 수 있습니다. 잘못된 입력은 잘못된 결과를 낳습니다. 비록 그것이 스마트 모델이라 할지라도 — 소프트웨어의 고전적인 "가비지 인, 쓰레기 아웃" 규칙은 AI에도 적용됩니다.

강점과 약점 지도

AI가 올바른 일을 하도록 지시하기 위해서는 그것이 어디에서 빛나고 어디에서 비틀거리는지 알아야 합니다. 이 맵을 외우면 다음 미션마다 "이 작업을 AI에 아웃소싱해야 할까, 아니면 직접 해야 할까?"라는 의문이 생길 것입니다. 몇 초 안에 질문에 답할 수 있습니다.

그 강점은 상용구 코드 생성, 한 언어에서 다른 언어로 번역, 정규식(regex) 작성, 함수 설명, 테스트 뼈대 생성, 오류 메시지 해석, 문서 초안 작성, 변수/함수 이름 제안 및 사소한 리팩토링(동작을 변경하지 않고 코드 구조 개선)입니다.

약점: 회사별 비즈니스 규칙을 알고, 전체 코드 기반을 기억하고, 실제로 코드를 실행 및 확인하고, 최신 라이브러리 버전을 확실히 알고, 100% 보장된 보안 취약점을 탐지합니다. 가장 위험한 것은 환각입니다. 모델은 존재하지 않는 함수, 라이브러리 또는 API(애플리케이션 간 데이터 교환을 가능하게 하는 인터페이스)를 매우 설득력 있는 언어로 발명합니다. 코드는 일반 텍스트와 달리 "작동"하는지 테스트할 수 있으므로 이러한 위험은 실제로 유리하게 바뀔 수 있습니다. 확인 단계를 건너뛰지 마십시오.

임무 유형

AI의 역할

남자의 역할

상용구/골격 생성

초안을 생성합니다

적응, 검토

코드 설명

빠른 요약 제공

코드의 중요한 부분을 확인합니다.

테스트 작성

사례에서 시사하는 바

적용 범위 및 정확성 확인

보안에 중요한 논리

유용한 아이디어

결정과 책임은 전적으로 인간에게 있습니다.

API/라이브러리 사용법

샘플 생성

존재 여부와 버전을 확인합니다.

건축학적 결정

다양한 옵션

상황을 알고 선택하고 방어합니다.

단계별: 기본 작업 주기

1. 작업을 명확히 하세요. 원하는 것을 한 문장으로 쓸 수 없다면 모델도 마찬가지입니다. 불확실성이 입력에 일찍 스며들수록 출력에서 ​​불확실성이 더 커집니다.
2. 맥락을 제공하세요. 관련 코드, 전체 오류 메시지, 언어/프레임워크 버전 및 제약 조건을 프롬프트에 추가합니다. "이 문제를 해결하세요"라고 말하지 말고 "Python 3.11, FastAPI 0.110; 이 함수는 500 오류를 제공하며 요청 본문이 비어 있으면 폭발합니다"라고 말합니다.
3. 부과 역할 및 형식. "당신은 고참 Go 개발자입니다. 코드와 두 문장의 근거만 제공하면 됩니다."와 같은 프레임워크는 출력에 중점을 둡니다.
4. 작은 것을 요구하십시오. 하나의 거대한 요청보다는 여러 단계로 나누십시오. 각 단계를 개별적으로 확인하세요. 주요 변경 사항은 확인하기 어렵고 오류를 숨기기 쉬우므로 위험합니다.
5. 확인하다. 실행하고, 테스트하고, 시각적으로 읽어보세요. 검증되지 않은 AI 코드는 '솔루션'이 아닌 '스케치'입니다. 이는 사이클에서 가장 협상할 수 없는 단계입니다.

미니 케이스 3개

사례 1 - 시간 절약 효과는 상당하지만 미미합니다. 팀이 AI를 사용하여 새로운 CRUD(생성-읽기-업데이트-삭제) 엔드포인트를 골격화했을 때 첫 번째 초안 시간은 약 40분에서 8분으로 단축되었습니다. 그러나 검토 및 테스트를 통해 총 시간은 25분이었습니다. 따라서 실제 이득은 40에서 25, 약 38%입니다. "10배 가속했다"는 기대 대신에 측정된 이 비율은 지속 가능한 이득입니다.

사례 2 — 환각에는 비용이 많이 듭니다. 개발자가 검증 없이 AI가 제안한 request.get_json() 호출을 사용했습니다. 그런 메소드(정확하게는 response.json())가 없었습니다. 코드가 컴파일되지 않아 20분이 낭비되었습니다. 간단한 "이 방법이 실제로 존재합니까?" 확인하면 손실이 재설정됩니다.

사례 3 — 좋은 컨텍스트는 출력을 두 배로 늘립니다. 동일한 버그에 대해 한 개발자는 단순히 "오류가 발생합니다"라고 썼고 다른 개발자는 전체 스택 추적, 버전 및 입력 샘플을 추가했습니다. 후자는 첫 번째 시도에서 올바른 해결책을 얻었습니다. 첫 번째는 3턴을 소비했습니다. 차이점은 모델에 있는 것이 아니라 입력에 있었습니다.

복사 가능한 템플릿 4개

범용적이고 강력한 시작 프롬프트:

역할: 귀하는 숙련된 {{언어}} 개발자입니다. 작업: {{what_want}}컨텍스트:- 프레임워크/버전: {{framework_and_version}}- 제약 조건: {{성능, 스타일, 종속성 규칙}}규칙:- 존재하지 않는 라이브러리/함수를 사용하지 마십시오. 확실하지 않은 경우 "확인"으로 표시하세요. - 먼저 간단한 계획을 제시하고 코드를 제시한 다음 정당화하는 문장을 2개 제시합니다. - 테스트 가능하고 작동하는 코드를 생성합니다.

불확실성을 모델로 다시 필터링하려면 다음을 수행하십시오.

아래 작업을 해결하기 전에 누락되었거나 불분명하다고 생각되는 항목을 질문으로 최소 3개 이상 나열하세요. 답장하기 전에 코드를 작성하지 마세요.작업: {{task}}

출력을 자체 검사하려면 다음을 수행하십시오.

다음 코드를 생성했습니다. 이제 역할을 바꾸고 이 코드를 비판해 보세요. - 작동하지 않을 수 있는 3가지 사례(극단적인 사례)를 나열하십시오. - 구성할 수 있는 API/함수가 있습니까? 마크.- 수정된 버전을 제공하세요.코드:{{code}}

결정을 옵션으로 분류하려면 다음을 수행하세요.

{{문제}}에 대한 해결 방법을 2~3개 제안하세요. 각각에 대해: 간단한 설명, 플러스/마이너스, 선택 시기. 표 형식으로 제공하십시오. 나를 위해 선택하지 마십시오. 옵션을 명확히 하세요.

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

약함: "이 코드의 버그를 수정하세요." (어떤 오류? 어떤 언어? 예상되는 동작은 무엇입니까?)

Strong: "Python 3.11 / FastAPI 0.110. 요청 본문이 비어 있을 때 다음 끝점은 KeyError와 함께 500을 반환합니다. 빈 본문에 400과 의미 있는 메시지를 반환하고 싶습니다. 먼저 이유를 설명하고 수정된 함수를 제공한 다음 이 시나리오에 대한 테스트를 작성합니다. [코드]"

강력한 버전; 언어, 버전, 실제 오류, 예상 동작 및 출력 형식을 제공합니다. 모델은 더 이상 예측할 필요가 없습니다.

일반적인 실수

• 검증 없이 신뢰합니다. 가장 흔하고 비용이 많이 드는 실수입니다. 코드가 컴파일되고 테스트될 때까지 "해결되었습니다"라고 말하지 마십시오.
• 맥락 없이 질문을 합니다. 버전, 오류 텍스트 및 제한 사항이 없는 답변은 일반적이며 잘못된 경우가 많습니다.
• 하나의 큰 요청입니다. 300라인 생산을 한번에 요청하고 검토할 수 없으면 실수가 보이지 않습니다.
• 모델의 자신감을 증거로 오해하는 것. AI는 자신있게 잘못된 말을 할 수 있습니다. 톤은 정확성을 나타내는 지표가 아닙니다.
• 회사비밀을 무작위로 붙여넣습니다. 개인 키, 고객 데이터 또는 개인 소스 코드를 승인되지 않은 도구에 입력해서는 안 됩니다(이 주제는 10단원에서 자세히 살펴보겠습니다).

팁: 모든 AI 출력을 "이것은 초안입니다."로 취급하십시오. 이 하나의 정신적 습관은 모듈 전반에 걸쳐 보게 될 대부분의 위험을 소멸시킵니다.

요약하면

코딩 도우미는 다음으로 가능성이 가장 높은 조각을 예측하는 언어 모델입니다. 코드를 이해하지 못하고 패턴을 생성합니다. 이것이 바로 그가 반복적이고 형식적인 작업에 강한 이유입니다. 상황에 맞는 확인이 필요한 작업에는 주의해서 사용해야 합니다. 가장 큰 위험은 환각이고 유일한 해독제는 검증이다. 전체 모듈에서 우리가 따를 규율은 명확합니다. 즉, 작업을 명확하게 하고, 맥락을 제공하고, 작은 것을 요청하고, 각 결과물을 검증하는 것입니다.

응용과제

지난 주에 수행한 세 가지 소프트웨어 작업(예: 버그 수정, 테스트, README 업데이트)을 적어보세요. 각각의 '강점과 약점 지도'를 보고 AI가 이 일을 하게 했다면 당신과 AI의 역할이 무엇인지 한 문장으로 설명해보세요. 그런 다음 위의 "시작 프롬프트" 템플릿을 사용하여 이러한 작업 중 하나를 AI에 제공하고 실행하고 출력을 확인합니다. 얼마나 많은 시간을 절약했고, 얼마나 많은 실수를 수정해야 했는지 기록해 보세요.

체크리스트

• [ ] 나는 LLM이 코드를 "이해"하는 것이 아니라 패턴을 생성한다는 것을 깨달았습니다.
• [ ] 토큰, 컨텍스트 창, 프롬프트의 개념을 한 문장으로 설명할 수 있습니다.
• [ ] AI가 강한 작업 유형과 약한 작업 유형을 구분할 수 있습니다.
• [ ] 나는 환각이 무엇인지 알고 있으며 유일한 해독제는 검증이다.
• [ ] 나는 "제안, 생산, 검증" 주기를 내 업무에 맞게 조정했습니다.
• [ ] 구체적인 예를 통해 강한 프롬프트와 약한 프롬프트의 차이를 보여줄 수 있습니다.