작업을 주기 전에 맥락을 줘라

AI는 당신이 보는 방식으로 당신의 프로젝트를 볼 수 없다. 당신의 프레임워크 버전도, 파일 구조도, 이미 확립한 컨벤션도 모른다. 이것을 건너뛰면, AI는 추측한다 — 그것도 형편없이. 더 나쁜 것은, 자신만만하게 추측한다는 점이다. 그래서 출력은 당신의 실제 코드베이스와 충돌하기 전까지는 그럴듯해 보인다.

같은 요청에 대한 이 두 프롬프트를 비교해보라.

이메일을 검증하는 함수를 추가해줘.

이것은 검증에 Express와 Zod를 쓰는 TypeScript 백엔드야.
우리는 이미 src/schemas/ 에서 Zod 스키마로 입력을 검증해.
그 스타일로 이메일 검증 스키마를 추가해줘. 이메일은
소문자여야 하고, 최대 254자이며, src/config.ts 의 기존
BLOCKED_DOMAINS 목록에 있는 일회용 도메인을 거부해야 해.

첫 번째 프롬프트는 당신이 원하지 않는 정규식을 쓸 수도 있는, 당신의 코드베이스와 맞지 않는 스타일의 일반적인 코드를 낳는다. 두 번째는 그대로 붙여 넣을 수 있는 코드를 낳는다. 규칙은 이것이다: 스택, 컨벤션, 그리고 AI가 재사용해야 할 기존 요소들을 진술하라.

좋은 프롬프트는 이 조각들을 아래에서 위로 순서대로 쌓는다 — 맨 아래에 맥락, 맨 위 가까이에 실제 요청:

        ┌──────────────────────────────┐
        │   예시                       │  입력 하나 → 출력
        ├──────────────────────────────┤
        │   제약                       │  하지 말 것
        ├──────────────────────────────┤
        │   엣지 케이스                │  빈 값, 무효, 에러
        ├──────────────────────────────┤
        │   입력 / 출력                │  타입과 형태
        ├──────────────────────────────┤
        │   목표                       │  명확한 작업 하나
        ├──────────────────────────────┤
        │   맥락                       │  스택, 파일, 패턴
        └──────────────────────────────┘
              기초가 먼저 ▲

엔터를 치기 전에 쓸모 있는 마음속 체크리스트: 언어와 프레임워크(중요하다면 버전까지), 관련 파일이나 모듈, 프로젝트에 이미 있는 패턴, 그리고 AI가 선호하거나 피해야 할 라이브러리. 매번 넷 다 필요한 건 아니다 — 하지만 답이 그중 하나에 따라 달라진다면, 그것을 명명하라. 확신이 없으면, 새 코드가 맞춰야 할 실제 시그니처, 타입, 또는 설정을 붙여 넣어라. 몇 줄의 기존 코드가 한 단락의 설명보다 당신의 컨벤션을 AI에게 훨씬 잘 가르친다.