스크립팅 및 자동 완성

이득:

• 인라인 완료를 통해 올바른 작업 유형에 채팅 모드를 매핑하는 기능
• 입력/출력 계약, 엣지 케이스 및 스타일 제약 조건을 포함하는 강력한 제작 프롬프트를 작성하는 능력
• 병합하기 전에 생성된 코드와 새로 제안된 종속성을 검증하는 기능

개발자가 AI와 처음 접촉하는 지점은 자동 완성(입력할 때 다음 줄을 제안하는 기능)이거나 채팅 창에 "해당 기능을 입력하세요"라고 말하는 경우가 많습니다. 둘 다 동일한 엔진을 사용하지만 서로 다른 분야가 필요합니다. 이 단원에서는 코드 생성을 무작위로 "기록"하는 것에서 출력을 예측하고 검증할 수 있는 엔지니어링 단계로 변환합니다.

목표는 AI를 타이핑 기계의 속도를 높이는 도구에서 설정한 제약 조건 내에서 작동하는 견습생으로 전환하는 것입니다. 잘 지도된 견습생은 시간을 절약합니다. 지도받지 않은 견습생은 나중에 정리해야 할 엉망진창을 만듭니다.

두 가지 사용 모드: 인라인 완성 및 채팅

편집기에 입력할 때 인라인 완성이 작동합니다. 함수 서명이나 주석 줄을 입력하면 나머지 부분이 제안됩니다. 속도면에서는 훌륭하지만 컨텍스트가 좁습니다. 바로 인접한 영역의 코드만 볼 수 있습니다. 그렇기 때문에 댓글에 의도를 명확하게 적어주시면 가장 효과가 좋습니다. 예를 들어 //사용자 이메일 유효성을 검사하고 잘못된 주석이 있는 경우 ValidationError를 발생시키면 아래 제안이 크게 향상됩니다.

채팅 모드는 "이 클래스에 페이지 매김 추가", "해당 서비스의 인터페이스 추출"과 같이 더 크고 구조화된 작업을 위한 것입니다. 여기에는 역할, 맥락 및 형식을 제공하는 사치가 있습니다. 일반적인 규칙은 작고 흐름이 빠른 작업은 완료하고 사고와 구조가 필요한 작업은 대화입니다.

팁: "Tab"을 통한 완성 제안을 맹목적으로 받아들이지 마십시오. 제안된 줄을 잠시 읽어보세요. 잘못된 변수 이름이나 반전된 조건이 여기에서 가장 일반적으로 누출됩니다.

의도를 코드로 변환하는 단계

1. 계약을 정의합니다. 함수의 입력, 출력 및 오류 동작은 무엇입니까? "이메일을 받고 유효한 경우 정규화하고 유효하지 않은 경우 오류 발생"과 같습니다.
2. 제약 조건을 명시하세요. 외부 종속성을 사용하지 않습니까? 특정 스타일 가이드? 성능 제한이 있나요?
3. 예를 들어보세요. 입력-출력 쌍(“ali@x.com → 유효한, ali@ → 오류”)은 모델의 의도에 대한 이해를 예측에서 정밀도로 이동시킵니다.
4. 작은 조각을 요청하세요. 하나의 기능, 하나의 책임. 그런 다음 다음으로 넘어갑니다.
5. 생성된 코드를 읽고 실행합니다. 컴파일 + 빠른 수동 시도가 가장 저렴한 보증 단계입니다.

미니 케이스 3개

사례 1 - 댓글 기반 생산으로 정확성이 향상됩니다. 개발자는 먼저 빈 본문으로 날짜 구문 분석 기능을 요청했고 3라운드에서 올바른 결과를 얻었습니다. 두 번째 시도에서는 4줄 주석(허용 형식, 시간대 규칙, 오류 조건)으로 함수를 정의하고 요청했더니 1차에서 작동했던 코드가 나왔습니다. 같은 모델, 같은 날; 차이점은 의도의 명확성뿐이었습니다.

사례 2 - 버전을 지정하지 않으면 비용이 많이 듭니다. 한 팀은 Node.js용으로 생성된 코드에서 fs.promises를 대체하는 레거시 콜백 기반 API로 인해 어려움을 겪었습니다. "Use Node 20, ESM, async/await" 줄이 프롬프트에 추가되었을 때 프로덕션은 처음으로 프로젝트를 따랐습니다. 수정에 소요된 평균 12분의 시간이 재설정되었습니다.

사례 3 — 상용구 코드의 실제 이득. 마이크로서비스에는 6개의 새로운 DTO(데이터 전송 개체 - 계층 간에 데이터를 전달하는 간단한 데이터 클래스)와 해당 유효성 검사 규칙이 필요합니다. 기존에는 약 90분 정도 걸리던 수작업이 AI로 제작 및 검토되면서 35분으로 단축되었습니다. 코드 반복률이 높고 패턴이 명확하기 때문에 AI는 여기서 가장 효율적인 영역에서 작동했습니다.

복사 가능한 템플릿 4개

계약 기반 기능 생성:

역할: 귀하는 부지런한 {{언어}} 개발자입니다. 기능 계약:- 이름: {{이름}}- 입력: {{유형 및 의미}}- 출력: {{유형 및 의미}}- 오류 상태: {{발생/반환되는 경우}}제약: {{외부 종속성/스타일/성능 없음}}예:- {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}먼저 서명 + 간단한 계획을 제공한 다음 코드를 작성하세요. 테스트를 작성하고 기능만 수행하세요.

기존 스타일과 일치시키려면(코드 베이스에 맞게 조정):

다음은 우리 프로젝트의 예제 함수입니다. 여기서 이름 지정, 오류 처리 및 주석 달기 스타일을 알아보세요. 동일한 스타일로 {{new_task}}에 대한 함수를 작성합니다. 예: {{현재_코드}}

뼈대에서 채우기까지(스텁 → 구현):

주석의 TODO에 따라 아래 함수 뼈대를 채우세요. 서명과 반환 유형을 변경합니다. 존재하지 않는 도우미 함수를 만들지 마세요. 필요한 경우 "이 도우미가 필요합니다"라고 알려주십시오. {{skelet_kod}}

대체 앱 비교:

{{task}}에 대해 2가지 다른 구현을 제공합니다: (a) 가독성 우선순위, (b) 성능 우선순위. 각 항목 아래에 "언제 바람직합니까?"라는 문장을 1개씩 적습니다.

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

약함: "이메일 확인 기능을 작성해 주세요."

Strong: "TypeScript 5, 표준 라이브러리 전용입니다. isValidEmail(input: string): boolean을 작성하세요. 공백을 자르고 대소문자를 구분하지 않게 만드세요. a@b.co는 유효하고, a@, @b.co, 빈 문자열은 유효하지 않습니다. 정규식을 사용하려면 지나치게 복잡하지 마세요. 주석 2줄을 추가하세요."

강력한 버전; 언어, 버전, 서명, 엣지 케이스 및 스타일 제약 조건을 반환합니다. 따라서 생성된 코드는 프로젝트에 적합하고 작동합니다.

접근

언제 사용하나요?

주의

인라인 완성

흐름에 작은 인서트

제안을 읽지 않고 수락하지 마세요.

채팅을 통한 계약 기반 제작

새로운 함수/클래스

예와 극단적인 경우를 제시하세요

스타일 샘플별 제작

기존 코드에 추가

현재 샘플 코드 선택

해골 채우기

서명 고정, 본문 공백

서명 변경

코드 중복과 의존성 함정

AI는 작업을 더 쉽게 하기 위해 종종 새로운 라이브러리를 추천합니다. 때로는 이것이 정확하기도 하고 때로는 프로젝트에 불필요한 종속성을 추가하거나 존재하지 않는 패키지를 제안하기도 합니다(환각). 규칙: 각각의 새로운 종속성을 확인합니다. 패키지가 실제로 존재하고 유지 관리되며 적절한 라이센스가 있는지 확인하지 않고 프로젝트에 추가하지 마십시오. 대부분의 경우 이미 프로젝트에 참여하고 있는 도우미가 새 패키지보다 낫습니다.

주의: AI가 제안한 가져오기 라인을 검토하세요. 존재하지 않는 패키지 이름("typo-squatting"이라고 하는 가짜 패키지와 유사할 수도 있음)은 컴파일을 중단하고 보안 위험을 초래합니다.

일반적인 실수

• 모델에 따라 서명이 결정됩니다. 입력/출력 유형을 수정하지 않으면 제작할 때마다 다른 시그니처가 제공되어 통합이 어려워집니다.
• 극단적인 경우는 말할 것도 없습니다. 빈 입력, null, 음수, 매우 큰 값 - 이를 지정하지 않으면 모델은 가장자리를 건너뛰고 "행복한 경로"를 작성합니다.
• 테스트하지 않고 제안을 결합합니다. 작동하는 것처럼 보이는 코드가 작동한다는 의미는 아닙니다.
• 불필요한 의존성을 수용합니다. 단일 라이너에 전체 라이브러리를 추가하면 기술적 부채가 발생합니다.
• 스타일 불일치. 프로젝트의 나머지 부분과 다른 이름 지정 및 오류 처리로 인해 코드 기반이 고르지 않게 됩니다.

요약하면

의도를 명확한 계약으로 변환하면 코드 생성이 강력해집니다. 소규모 인스트림 작업과 대화에서 구조를 설정하는 작업에는 인라인 완성을 사용합니다. 입력/출력 유형, 엣지 케이스, 버전 및 스타일을 지정합니다. 모델의 예를 들어보세요. 각각의 새로운 종속성을 확인합니다. 생산된 모든 작품을 실행하고 읽습니다. AI는 공식적이고 반복적인 코드에서 가장 좋은 결과를 얻습니다. 설정한 한도 내에서 바로 실행하세요.

응용과제

작성해야 하는 프로젝트에서 실제 작은 함수를 선택하세요. 먼저 입력/출력 유형, 두 가지 엣지 케이스 및 스타일 제약 조건을 제공하는 "계약 기반 함수 생성" 템플릿을 사용하여 AI에 인쇄합니다. 생성된 코드를 컴파일하고 두 가지 다른 입력으로 시도해 보세요. 그런 다음 동일한 기능을 다시 요청하고 이번에는 컨텍스트 없이 "나에게 이것을 작성"하고 두 출력을 한 줄씩 비교합니다. 어떤 엣지 케이스가 누락되었는지, 얼마나 많은 수정이 필요했는지?

체크리스트

• [ ] 인라인 완성 기능이 있는 채팅 모드를 어디에서 사용해야 하는지 알고 있습니다.
• [ ] 함수 생성 시 입출력 계약과 엣지 케이스를 결정합니다.
• [ ] 나는 프롬프트에 언어와 버전 정보를 추가하는 습관을 들였습니다.
• [ ] 제작된 각 작품을 조립하기 전에 편집하고 테스트합니다.
• [ ] AI가 제안하는 새로운 종속성 각각의 존재와 필요성을 검증하여 확인합니다.
• [ ] 생성된 코드가 프로젝트 스타일과 일치하는지 확인합니다.