AI 개발 프롬프트를 짜는 세 가지 방식과 작업 지침 관리법

AI 요약

작성자는 개인 문제를 해결하는 도구와 소규모 프로덕션 프로젝트를 만들 때 사용하는 AI 개발 프롬프트 전략을 소개합니다. 비즈니스 핵심 시스템을 개발하는 사람의 지침이 아니라는 점을 먼저 밝힙니다. 프롬프트는 한 가지 정답을 고르는 일이 아니라 프로젝트와 상황에 맞춰 접근법을 조절하는 일이라고 설명합니다.

세 가지 작업 방식

첫 번째는 기능을 작은 이야기 단위로 나누는 점진적 접근입니다. 기본 설정과 데이터베이스·인증을 준비한 뒤 메뉴와 탐색 기능을 만들고, 우선순위가 높거나 의존성이 있는 기능부터 하나씩 구현합니다. 요청할 때마다 결과를 시험하고 검토하며, 필요하면 후속 프롬프트로 수정하거나 디버깅합니다. 만족스러운 결과를 얻으면 새 채팅을 시작해 맥락을 정리하되, 앞선 기능과 밀접하게 얽힌 작업은 같은 대화에서 이어갑니다. 방향을 바꾸기 쉽고 모델이 의도대로 움직이지 않을 때도 대응하기 편한 방식입니다.

두 번째는 원하는 내용을 큰 프롬프트 하나에 담아 한 번에 구현을 요청하는 방식입니다. 요구사항을 미리 충분히 계획해야 하며, 작은 개발 도구 제작이나 기존 제품 복제, 다른 플랫폼으로의 마이그레이션, 개념 증명(PoC)에 기능과 마감을 더하는 작업에 잘 맞습니다. 시간이 지나면서 작성자는 이 방식을 덜 쓰게 됐다고 합니다. 점진적 접근과 한 번에 요청하는 접근은 실제로 후속 수정 프롬프트가 오가며 차이가 작아 보일 수 있지만, 처음부터 전체를 해결하려는지 작은 부분부터 쌓아가는지가 근본적인 차이라고 짚습니다.

세 번째는 먼저 대화로 선택지와 제약, 절충점을 살펴본 뒤 상세 구현 계획을 만드는 방식입니다. 작성자는 이 계획을 Markdown 파일로 정리해 실제 구현을 맡길 에이전트의 프롬프트와 함께 제공합니다. 규모가 크거나 복잡한 프로젝트, 탐색 단계의 아이디어, 익숙하지 않은 기술 스택을 다룰 때 적합합니다. 예산이 허용되면 같은 계획을 서로 다른 모델에 적용해 결과를 비교할 수도 있습니다.

접근법은 프로젝트의 명확성, 복잡도, 새 기술 사용 여부, 학습이나 PoC 목적에 따라 고릅니다. 요구사항이 불분명하면 점진적으로 시작하고, 복잡하거나 낯선 기술 스택을 쓰면 계획을 먼저 세우는 쪽을 권합니다. 작업이 전술적이고 범위가 좁다면 한 번에 요청하는 방식에 기울 수 있습니다.

프롬프트 길이와 대화 맥락

작성자는 프롬프트를 짧고 구체적으로 쓰고, 추가 정보는 파일로 붙이는 편입니다. 복잡한 계획은 단계별 Markdown 문서로, 디버깅 자료는 오류 내용을 담은 텍스트나 JSON 파일로 전달합니다. 후속 메시지에는 사용자와 모델이 주고받은 앞선 내용도 맥락으로 포함되므로, 같은 기능이나 파일을 다루는지, 이전 대화의 정보가 도움이 되는지 살펴보고 세션을 유지할지 결정합니다.

맥락을 정리해야 할 때는 자동 요약을 기다리는 대신 직접 요약을 만들기도 합니다. 자동 정리는 컨텍스트 한도에 가까워진 뒤에 일어날 수 있지만, 직접 요약하면 필요한 시점에 중요한 정보를 골라 남길 수 있다고 설명합니다. 화면 작업에는 스크린샷도 활용합니다. 이미지에 빨간 상자와 화살표를 표시하고 원하는 수정 내용을 설명하면, 긴 문장 대신 시각 자료로 의도를 전달할 수 있습니다.

새 세션 프롬프트의 구성

작성자가 새 작업에 사용하는 프롬프트는 네 부분으로 나뉩니다. 첫째는 간단한 설계 목표(SDG)입니다. 예를 들어 회의와 할 일, 채팅을 한곳에 모아 한 주의 업무를 계획하는 앱처럼, 만들 대상과 사용 가치를 한 문장으로 설명합니다. 목표를 먼저 제시하면 모델이 요구사항의 문구만 따르는 대신 요청의 취지를 파악하는 데 도움이 됩니다.

둘째는 구체적인 요구사항입니다. 데이터 출처별 합계 표시, 이번 주 회의 비율 표시, 이메일을 20개씩 불러오고 오래된 메일이 이번 주 이전이면 중단하는 처리, 원문으로 이동하는 링크처럼 동작과 구현 범위를 분명히 적습니다. 열린 형태로 맡기더라도 완료 기준은 정해야 합니다. 예를 들어 모든 업무 데이터가 앱에 표시되면 끝이라고 정의할 수 있습니다.

셋째는 주의사항(Gotchas)입니다. Teams의 채팅 API가 그룹 채팅을 다루지 못하므로 Graph API의 /me 경로를 사용하라는 식으로, 흔히 놓치는 제약과 피해야 할 방식을 적습니다. 반복해서 쓰는 주의사항은 Skill.md로 분리해 재사용할 수 있습니다. 넷째는 모델이 확신하지 못할 때 사용자에게 확인하도록 요청할 항목입니다. 이메일 페이지 처리나 인증처럼 프로젝트마다 판단이 필요한 지점을 지정합니다. 반복되는 확인 항목은 instruction.md에 추가할 수 있습니다.

프런트엔드 작업에서는 원하는 스타일과 색상표를 제시하고 서로 다른 HTML 시안 다섯 개를 요청하는 방법도 소개합니다. 다음·이전 버튼이 있는 모달을 함께 만들면 시안을 비교하기 쉽습니다.

Agent.md, Instruction.md, Skill.md

작성자는 세 파일 모두 모델에 제공하는 맥락이지만 쓰임새를 구분합니다. Agent.md에는 언어나 개발 환경에 따른 SDK, 테스트, 프로젝트 구조, 구현 지침을 둡니다. 프런트엔드와 백엔드처럼 영역별 파일을 따로 두거나 큰 프로젝트에 맞춰 세부 내용을 조정할 수 있습니다. 예를 들어 자체 Power Apps Code Apps 환경에서 바닐라 JavaScript와 지정 SDK를 사용해야 한다면, 일반적인 React·TypeScript 구조나 fetch()를 제안하지 않도록 명시합니다.

Instruction.md에는 이름 규칙, 코딩 스타일, 선호 라이브러리처럼 작성자의 공통 선호를 담습니다. 작성자는 여러 언어와 모델에서 쓸 수 있도록 이 파일을 특정 환경에 종속되지 않게 관리합니다. Claude는 Claude.md를 사용하며, 작성자는 Claude Code가 Agent.md도 받아들이게 됐다고 덧붙입니다. Claude 관련 파일이 프롬프트 우선순위에서 앞설 수 있으므로 모델별 지침을 나눠 관리하는 선택지도 제시합니다.

Skill.md는 특정 작업에 필요한 맥락을 프롬프트 가까이에 두는 파일입니다. 필요한 기술 지식과 요구사항, 예시, 템플릿, 주의사항, 선호하는 해결 방식을 담습니다. SharePoint를 쓰지 않는 앱에는 SharePoint 관련 지침을 넣지 않는 식으로 필요한 기술의 정보만 골라 제공하면, 맥락을 간결하게 유지하고 지침 사이의 충돌도 줄일 수 있습니다.

반복해서 개선하는 지침

작성자는 프롬프트와 Markdown 지침을 고정된 문서로 취급하지 않습니다. 결과가 좋았던 이유와 문제가 생긴 원인을 살펴보고 프롬프트나 지침을 갱신해야 합니다. 모델은 계속 바뀌고 같은 지침도 모델에 따라 결과가 달라질 수 있으므로, 정기적으로 내용을 다시 검토하는 편이 좋다고 말합니다. 다만 프롬프트와 지침 파일을 모델에게 전적으로 맡기지는 않습니다. 초안을 만드는 데 도움을 받을 수는 있지만 직접 읽고 고쳐야 하며, 작업에서 얻은 짧은 교훈을 적절한 Markdown 파일에 추가하는 식으로 관리합니다. 이미 공개된 지침도 활용하되, 숨은 HTML 주석에 프롬프트 인젝션이 들어간 사례가 있으니 파일 전체를 평문 편집기에서 확인하라고 당부합니다.

원문: dev.to / 번역·요약: Trawling