AI를 써먹기 위한 최소 지식 4편: 좋은 질문보다 좋은 입력 묶음

개발자가 AI 코딩 도구에 작업을 맡길 때 사용할 수 있는 입력 패키지 구조와 예시를 정리합니다.

목차

지난 글에서는 토큰과 컨텍스트 윈도우를 기준으로, AI에게 줄 수 있는 정보에는 공간의 한계가 있다는 점을 정리했습니다.

그럼 이제 남는 문제는 이것입니다.

제한된 공간 안에 무엇을 넣어야 할까요?

AI에게 코딩을 맡길 때 가장 흔한 요청은 이런 형태입니다.

이거 만들어줘.
이거 고쳐줘.
이 에러 해결해줘.

간단해서 좋습니다.

하지만 결과가 매번 안정적이지는 않습니다. AI가 문제를 넓게 해석하거나, 내가 생각한 제약을 놓치거나, 완료 기준을 다르게 잡을 수 있기 때문입니다.

그래서 저는 코딩 작업에서는 "좋은 질문"보다 좋은 입력 묶음이 더 중요하다고 봅니다.

입력 묶음은 작은 작업 명세서다

입력 묶음은 거창한 문서가 아닙니다.

AI가 작업을 시작하기 전에 봐야 할 최소 명세입니다.

목표:
- 무엇을 만들거나 고칠 것인가

범위:
- 어떤 파일/화면/API가 관련 있는가

제약:
- 바꾸면 안 되는 것
- 유지해야 하는 정책

자료:
- 로그, 에러, 예시, 기존 코드

검증:
- 어떤 명령이나 화면으로 확인할 것인가

이 정도만 있어도 AI의 작업 방향이 훨씬 안정됩니다.

특히 제약과 검증이 중요합니다.

사람은 "당연히 이건 유지하겠지"라고 생각하지만, AI는 말하지 않은 조건을 항상 지켜주지는 않습니다. (사람도 가끔 못 지킵니다..ㅎㅎ)

나쁜 요청과 좋은 요청 비교

예를 들어 블로그에 좋아요 기능을 붙인다고 해보겠습니다.

나쁜 요청은 아닙니다.

글마다 좋아요 누를 수 있게 해줘.

하지만 이 요청만으로는 애매한 부분이 많습니다.

• 같은 사람이 여러 번 누르면 어떻게 할까?
• 프리뷰 페이지에서도 좋아요가 올라가야 할까?
• 홈 화면 카드에도 좋아요 수를 보여줄까?
• API 실패 시 UI는 어떻게 할까?
• 비용은 괜찮을까?

조금 더 나은 입력 묶음은 이렇습니다.

목표:
- 블로그 글마다 좋아요 버튼을 추가한다.
- 홈 화면 글 요약에도 좋아요 수를 보여준다.

정책:
- 비공개 검토 화면에서는 좋아요 API를 호출하지 않는다.
- 공개 글에서만 좋아요를 기록한다.
- 같은 브라우저의 반복 클릭은 localStorage로 1차 방지한다.

관련 영역:
- 글 상세 HTML
- 홈 글 목록 카드
- 저장 API
- 좋아요 저장소 또는 기존 통계 저장소

검증:
- 공개 글에서 좋아요 클릭 시 수가 증가한다.
- 비공개 검토 글에서는 API가 호출되지 않는다.
- 정적 페이지 생성 명령 성공
- 공개되지 않은 글의 URL은 외부에서 열리지 않음

이제 AI는 "버튼 하나 추가"가 아니라 전체 흐름을 이해하고 작업할 수 있습니다.

완료 기준을 반드시 적는다

AI에게 작업을 맡길 때 가장 좋은 습관 중 하나는 완료 기준을 적는 것입니다.

완료 기준이 없으면 AI는 "코드를 바꿨다"에서 멈출 수 있습니다.

하지만 실제 개발에서는 코드 변경이 끝이 아닙니다.

완료 기준:
- 타입체크 통과
- 테스트 통과
- 로컬 페이지에서 UI 확인
- 운영 프리뷰 URL 응답 확인
- public surface에 draft 노출 없음

이렇게 쓰면 작업의 마지막이 명확해집니다.

특히 배포나 데이터 변경이 있는 작업에서는 검증 기준이 없으면 위험합니다.

완료 기준은 가능하면 명령, 화면, 데이터, 운영 영향으로 나누면 좋습니다.

이렇게 나누면 AI가 "코드는 바꿨습니다"에서 멈추기 어렵습니다.

"하지 말 것"을 적는 게 중요하다

AI에게는 해야 할 것만큼 하지 말아야 할 것도 중요합니다.

예를 들어:

하지 말 것:
- 홈 화면에 블로그 진입 링크 추가하지 않기
- 기존 알림/자동화 명령어 깨지 않기
- public RSS에 draft 글 넣지 않기
- 앱 클라이언트 수정이 필요한 작업인지 먼저 구분하기
- 비밀값이나 외부 연동 URL 출력하지 않기

이런 조건은 작업 품질보다 안전에 가깝습니다.

특히 개인 프로젝트라도 운영 서비스에 연결되어 있으면 "하지 말 것"이 명확해야 합니다.

AI에게 먼저 계획을 세우게 한다

입력 묶음을 줬다면 바로 구현하게 할 수도 있습니다.

하지만 저는 보통 먼저 계획을 보게 하는 편이 좋다고 봅니다.

먼저 짧은 계획을 세우고 시작해줘.
계획에는 수정할 파일, 검증 방법, 위험한 지점을 포함해줘.

계획을 보면 AI가 내 요청을 어떻게 이해했는지 바로 드러납니다.

만약 잘못 이해했다면 이 단계에서 수정하면 됩니다.

이건 작업이 커질수록 중요합니다.

작은 CSS 수정은 바로 해도 되지만, DB/배포/권한/결제/보안이 들어가면 계획 없이 들어가는 건 위험합니다.

입력 묶음 검수 체크리스트

작업을 맡기기 전에 아래 항목만 확인해도 결과가 꽤 달라집니다.

이 체크리스트를 통과하면 AI가 추측해야 하는 공간이 줄어듭니다.

개발자 입장에서도 좋습니다. 작업이 끝난 뒤 "이게 끝난 건가?"를 다시 고민하지 않아도 됩니다.

재사용 가능한 템플릿

저는 이런 템플릿을 자주 씁니다.

목표:
-

배경:
-

관련 파일/화면/API:
-

제약:
-

하지 말 것:
-

완료 기준:
-

진행 방식:
- 먼저 계획을 세운다.
- 그 다음 구현한다.
- 마지막에 검증 결과와 남은 TODO를 정리한다.

이 템플릿은 복잡해 보이지만, 실제로는 빈칸을 다 채울 필요가 없습니다.

작은 작업이면 목표와 완료 기준만 있어도 됩니다.

예를 들어 작은 UI 수정이라면 이렇게 줄여도 충분합니다.

목표:
- 모바일에서 글 카드가 가로 스크롤을 만들지 않게 수정한다.

제약:
- PC 레이아웃은 최대한 유지한다.
- 홈 화면에 새 메뉴는 추가하지 않는다.

완료 기준:
- 모바일 390px 폭에서 가로 스크롤 없음
- 글 제목과 버튼 텍스트가 겹치지 않음
- 변경 파일과 확인 결과 보고

진행 방식:
- 먼저 계획을 짧게 세우고 진행한다.

반대로 배포나 데이터가 들어가면 템플릿을 더 자세히 채워야 합니다.

중요한 건 AI에게 "정답을 맞혀봐"가 아니라 "이 조건 안에서 작업해줘"라고 말하는 것입니다.

정리하면

AI 코딩 작업은 프롬프트 문장 하나로 끝내기보다 입력 묶음으로 주는 편이 안정적입니다.

좋은 입력 묶음:
- 목표
- 배경
- 관련 파일/로그
- 제약
- 하지 말 것
- 완료 기준
- 보고 방식

이렇게 하면 AI는 더 적게 추측하고, 사람은 더 쉽게 검증할 수 있습니다.

다음 글에서는 사람이 매번 이 입력 묶음을 직접 만들지 않아도 되도록, AI가 모르는 문서나 내 코드베이스 정보를 어떻게 찾아보게 할 수 있는지 RAG와 검색 인덱스를 기초부터 정리해보겠습니다.