AI와 코딩할 때, 첫 요청은 작을수록 좋습니다.

“앱 하나 만들어줘” 다음에 생기는 일

결과 화면은 빨리 나와도 저장이 안 되거나 새로고침하면 데이터가 사라질 수 있습니다. 코드의 양보다 사용자가 끝까지 할 수 있는 행동이 중요합니다. 첫 요청은 로그인, 결제, 대시보드를 한꺼번에 만드는 대신 한 가지 행동을 완성하도록 좁혀보세요.

예를 들어 메모 앱이라면 “제목과 내용을 저장하고 새로고침해도 남아 있게 한다”가 출발점입니다. 저장 위치가 브라우저인지 서버인지도 정해야 합니다. 화면만 같은 두 앱이 실제로는 전혀 다르게 작동할 수 있습니다.

보조 도구와 작업 에이전트 구분하기

GitHub Copilot은 편집기와 개발 작업에 AI 도움을 제공하고, Claude Code는 코드베이스를 읽고 수정하는 작업 흐름을 안내합니다. 구체적인 지원 환경과 기능은 공식 문서에서 현재 상태를 확인하세요.

어떤 도구를 고르든 파일 변경을 이해할 수 있는 범위로 나누는 것이 중요합니다. 자동화 범위가 넓어질수록 변경 내역과 실행 결과를 함께 확인할 장치가 필요합니다.

작은 기능 하나를 끝까지 만드는 순서

아래 순서는 웹페이지의 검색창을 만드는 상황을 가정합니다. 검색 결과가 보이는 순간이 아니라, 빈 검색과 결과가 없는 경우까지 확인했을 때 하나의 기능이 완성됩니다.

1. 현재 코드를 읽고 수정할 파일과 방법부터 설명하게 합니다.
2. 검색 대상과 일치 기준을 정합니다. 대소문자·공백 처리도 포함합니다.
3. 변경 전 상태를 Git이나 복사본으로 보관합니다.
4. 한 기능을 구현하고 실제 데이터로 결과를 확인합니다.
5. 빈 입력·특수문자·결과 없음·모바일 화면을 검사합니다.
6. 변경한 파일과 테스트 결과를 확인한 뒤 다음 기능으로 넘어갑니다.

복사해서 쓸 수 있는 작업 요청

실제 파일명과 실행 명령은 프로젝트에 맞게 바꾸세요. 여기서 중요한 것은 범위, 완료 조건, 변경 전에 확인할 내용을 같이 주는 것입니다.

현재 프로젝트의 검색 기능을 먼저 읽어주세요. 제목과 태그에서 공백을 정리한 부분 일치 검색을 구현하고, 결과가 없으면 검색어 변경 안내를 보여주세요. 기존 디자인은 유지하세요. 수정 전에 영향을 받는 파일을 설명하고, 수정 후 빈 검색·한글·영문 대소문자·결과 없음으로 검증하세요.

실패한 동작을 수정 요청으로 바꾸기

“저장이 안 돼요”만 전달하면 원인을 넓게 추측하게 됩니다. 입력한 값, 누른 버튼, 기대한 결과, 실제 결과를 순서대로 적으세요. 예를 들어 “제목을 입력하고 저장하면 목록에는 나타나지만 새로고침 후 사라진다”는 설명은 화면 상태와 영구 저장을 구분하는 단서가 됩니다.

브라우저 콘솔이나 서버 로그를 전달할 때는 오류가 발생한 시각과 함께 필요한 부분만 복사합니다. 비밀키나 사용자 정보가 섞여 있지 않은지 확인하세요. AI가 제안한 수정이 원인을 해결하는지, 단지 오류 메시지를 숨기는 것인지도 살펴야 합니다.

수정 후에는 문제가 났던 입력을 그대로 다시 시도합니다. 그다음 정상 입력 한 개와 경계 상황 한 개를 확인하세요. 저장 기능이라면 새로고침, 빈 제목, 같은 제목 두 번 저장을 점검할 수 있습니다. 테스트 조건을 고정해야 수정 전후가 비교됩니다.

재현 순서: 제목에 “첫 메모” 입력 → 저장 → 새로고침
기대: 메모가 목록에 남아 있음
실제: 새로고침하면 목록이 비어 있음
요청: 현재 저장 위치를 확인하고 원인을 설명한 뒤 수정하세요. 오류 표시를 숨기는 방식으로 해결하지 마세요. 같은 순서로 재검증한 결과를 알려주세요.

작동했다는 보고를 확인하는 방법

도구가 테스트 통과라고 적었더라도 어떤 테스트인지 확인해야 합니다. 빌드 성공은 문법과 묶음 생성이 가능하다는 신호이지, 결제나 저장이 정상이라는 증거가 아닙니다. 사용자가 실제로 수행할 동작을 한 번 따라가 보세요.

배포 전에는 비밀번호나 API 키가 코드와 브라우저에 노출되는지 살핍니다. 삭제·발송·결제처럼 되돌리기 어려운 기능은 테스트 환경에서 확인하고 사람의 승인 단계를 두세요. 외형보다 실패했을 때의 동작을 확인하는 습관이 오래 갑니다.