“투두앱 만들어줘”보다 더 좋은 요청 방식은 무엇일까?
1. 왜 “투두앱 만들어줘”는 아쉬운 요청일까
처음 AI 코딩을 시작하면 가장 많이 쓰는 문장이 “투두앱 만들어줘”입니다. 짧고 편하지만, 실전에서는 이 방식이 오히려 시간을 늘릴 때가 많습니다. 이유는 간단합니다. 이 요청에는 기능 범위, 사용 기술, 데이터 저장 방식, UI 기준, 예외 처리 규칙이 모두 빠져 있기 때문입니다. AI는 빠르게 결과를 내지만, 빠른 결과와 맞는 결과는 다릅니다.
예를 들어 어떤 사용자는 로컬스토리지를 원하고, 어떤 사용자는 서버 API 연동을 원합니다. 어떤 사람은 모바일 반응형이 필수고, 어떤 사람은 데스크톱 내부 도구면 충분합니다. 그런데 요청이 한 줄이면 AI는 이 차이를 추측으로 메웁니다. 결국 “원하던 것과 다르다”는 피드백이 생기고, 재요청과 재수정이 반복됩니다. 처음 30초를 아끼려다 30분을 잃는 패턴이 자주 발생하는 이유입니다.
2. 좋은 요청이 갖춰야 할 4요소
좋은 요청은 화려한 문장보다 구조가 중요합니다. 최소한 네 가지는 항상 넣는 것이 좋습니다. 첫째, 목표: 무엇을 만들고 어떤 상태를 완료로 볼지. 둘째, 범위: 이번 단계에서 할 것과 하지 않을 것. 셋째, 제약: 기술 스택, 파일 구조 유지, 금지 사항. 넷째, 출력 형식: 코드만 줄지, 설명과 테스트 방법까지 줄지. 이 네 가지가 있으면 AI의 추측이 줄어들고 결과 편차가 크게 줄어듭니다.
특히 초보자일수록 “한 번에 완성”보다 “단계별 완성” 전략이 효율적입니다. 1단계는 기본 기능, 2단계는 UX 개선, 3단계는 리팩터링과 테스트처럼 구분하면 수정 포인트가 명확해집니다. 좋은 프롬프트는 길어서 좋은 것이 아니라, 다음 행동을 결정할 단서가 충분해서 좋습니다.
| 요소 | 부족한 요청 예시 | 개선된 요청 예시 |
|---|---|---|
| 목표 | 투두앱 만들어줘 | 할 일 추가/수정/삭제/완료 토글 가능한 단일 페이지 앱 작성 |
| 범위 | 전부 알아서 | 이번 단계는 인증 없이 로컬 저장만 구현 |
| 제약 | 기술 조건 없음 | HTML/CSS/Vanilla JS만 사용, 외부 라이브러리 금지 |
| 출력 형식 | 아무 형식이나 | 파일별 코드 + 실행 방법 + 테스트 체크리스트 제공 |
3. 실제로 바꿔 쓰는 프롬프트 예시
아래처럼 한 줄 요청을 구조화하면 결과 품질이 즉시 좋아집니다. “너는 프론트엔드 개발자야. HTML/CSS/JavaScript만 사용해서 투두앱을 만들어줘. 기능은 추가, 삭제, 완료 토글, 필터(전체/완료/미완료)까지 포함해줘. 데이터는 localStorage에 저장하고, 모바일 375px에서도 레이아웃이 깨지지 않게 해줘. 출력은 index.html, style.css, app.js 순서로 제공하고 각 파일 하단에 핵심 로직 1줄 설명을 적어줘.”
여기서 더 좋아지는 포인트는 “완료 기준”을 붙이는 것입니다. 예: “새로고침 후에도 리스트가 유지되면 성공”, “빈 문자열 입력 시 추가되지 않으면 성공”. 이렇게 검증 가능한 문장을 넣으면 AI가 결과를 체크 가능한 형태로 만듭니다. 즉, 요청이 곧 테스트 명세가 됩니다.
4. 작업 속도를 높이는 운영 팁
실제로는 한 번의 완벽한 프롬프트보다, 두세 번의 정확한 반복이 더 빠릅니다. 첫 요청에서는 기능 골격을 받고, 두 번째 요청에서는 코드 스타일과 예외 처리를 맞추고, 세 번째 요청에서 접근성이나 성능을 개선합니다. 이 순서를 지키면 큰 재작업 없이 품질이 올라갑니다.
또 하나 중요한 습관은 피드백을 추상적으로 하지 않는 것입니다. “이상해요” 대신 “완료 버튼 클릭 시 텍스트가 사라지지 않고 취소선만 적용되게 수정”처럼 행동 단위로 말하면 AI가 정확히 고칩니다. 결국 좋은 요청 방식은 AI를 똑똑하게 만드는 기술이 아니라, 내 의도를 실행 가능한 작업 단위로 바꾸는 기술입니다.
5. 자주 묻는 질문
Q1. 프롬프트를 매번 길게 써야 하나요?
아닙니다. 핵심은 길이가 아니라 구조입니다. 목표, 범위, 제약, 출력 형식만 포함하면 짧아도 충분히 좋습니다.
Q2. 기술 스택을 모를 때는 어떻게 요청하나요?
“입문자용으로 가장 단순한 스택을 제안하고 이유를 3줄로 설명해줘”라고 먼저 묻고, 제안된 스택으로 구현 요청을 이어가면 됩니다.
Q3. 결과가 마음에 안 들면 처음부터 다시 시켜야 하나요?
전체 재요청보다 부분 수정이 효율적입니다. 변경 대상 파일, 원하는 동작, 금지 변경점을 함께 적으면 기존 결과를 살리면서 빠르게 개선할 수 있습니다.