클로드 코드로 앱·웹 만들 때 막힘을 줄이는 해결 순서
클로드 코드로 앱이나 웹을 만들 때는 AI에게 한 번에 전부 맡기기보다, 범위와 완료 기준을 먼저 정하는 것이 중요해요. 토큰 사용이나 예외 상황을 점검하려면 요청을 작게 나누고 결과를 확인하는 순서로 진행해 보세요.
이 글에서는 작업 범위 정하기, 예외 확인하기, 도구 선택하기, 배포 전 검수하기까지 사장님이나 1인 마케터가 바로 적용할 수 있는 방법을 차례로 살펴볼게요.
클로드 코드를 쓰면 토큰이 금방 차는데 어떻게 줄이나요?
불필요한 탐색을 줄이려면 이번 작업에 필요한 범위와 목표를 분명히 알려주는 것이 좋아요. 먼저 수정할 범위와 원하는 결과를 정하고, 한 번에 하나의 문제를 해결하는 방식으로 요청하는 것이 좋아요.
아래 순서로 요청을 작게 나눠 보세요.
- 목표를 한 문장으로 정하기
- “로그인 화면을 고쳐줘”처럼 넓게 쓰기보다 “로그인 버튼을 눌렀을 때 입력값이 비어 있으면 안내 문구를 보여줘”처럼 적어요.
- 화면을 새로 만드는지, 기존 코드를 수정하는지도 구분해요.
- 결과를 확인할 기준도 함께 적어요. 예를 들어 입력값이 없을 때와 정상 입력일 때 각각 어떻게 보여야 하는지 정할 수 있어요.
- 읽어야 할 범위 정하기
- 관련 화면, 기능, 파일 또는 폴더를 먼저 지정해요.
- “전체 프로젝트를 확인해줘”라는 표현은 정말 필요한 경우에만 사용해요.
- 문제가 발생한 화면과 연결된 부분부터 확인하고, 추가 조사가 필요할 때 범위를 넓히는 편이 효율적이에요.
- 조사와 수정을 나누기
- 첫 요청에서는 원인과 수정안을 설명하게 하고, 바로 여러 파일을 바꾸게 하지 않아요.
- 원인이 맞는지 확인한 다음 실제 수정을 요청해요.
- 수정 뒤에는 변경된 내용과 확인해야 할 항목을 다시 정리하게 하면 불필요한 재작업을 줄일 수 있어요.
자주 하는 실수는 기능 하나를 설명하면서 디자인 변경, 데이터 처리, 배포까지 한꺼번에 요청하는 거예요. 이러면 어떤 부분에서 문제가 생겼는지 확인하기 어려워져요. 작업을 기능 단위로 쪼개고, 한 단계가 끝날 때마다 화면과 동작을 직접 확인해 보세요.
AI에게 시켰는데 예외 상황을 안 다뤘어요. 어떻게 확인하나요?
정상적으로 작동하는 한 가지 상황만 확인하면 부족해요. 입력이 비어 있거나 잘못됐을 때, 사용자가 중간에 취소했을 때, 데이터가 없을 때처럼 실패할 수 있는 상황을 먼저 목록으로 만들고 각각의 결과를 확인해야 해요.
기능을 확인할 때는 다음 질문을 써 보세요.
- 아무것도 입력하지 않고 진행하면 어떻게 되나요?
- 예상과 다른 형식의 값을 입력하면 어떻게 되나요?
- 같은 버튼을 여러 번 누르면 중복으로 처리되지 않나요?
- 처리 중 화면을 닫거나 이전 화면으로 이동하면 어떻게 되나요?
- 결과가 없을 때 빈 화면만 보이지 않고 다음 행동을 알 수 있나요?
- 권한이 없거나 로그인이 풀린 상태에서는 어떤 안내가 나오나요?
- 저장이나 전송에 실패했을 때 사용자가 다시 시도할 수 있나요?
- 휴대전화처럼 화면이 좁은 환경에서도 주요 버튼을 찾을 수 있나요?
AI에게는 “예외 상황도 처리해줘”라고만 하지 말고, 상황별 기대 결과를 붙여 요청하는 것이 좋아요. 예를 들어 “입력값이 비어 있으면 저장하지 말고 무엇을 입력해야 하는지 안내해줘. 저장에 실패하면 사용자가 다시 시도할 수 있게 알려줘”처럼 조건과 결과를 함께 적어요.
예외 처리가 제대로 됐는지는 코드 설명만 보고 판단하지 말고 실제 흐름으로 확인해야 해요. 정상 입력, 빈 입력, 잘못된 입력, 중복 실행, 취소, 실패 상황을 각각 시험하고, 사용자에게 이해하기 어려운 문구나 멈춘 화면이 없는지 살펴보세요.
특히 결제, 예약, 문의 접수, 회원 정보처럼 되돌리기 어려운 작업은 더 신중해야 해요. 실제 데이터에 바로 적용하기보다 테스트용 환경이나 복사본에서 흐름을 확인한 다음 진행하는 편이 안전해요. 수정 전에는 현재 상태를 되돌릴 방법도 준비해 두세요.
범위 없이 조사해 많은 파일을 읽는 상황을 어떻게 막나요?
범위를 줄이려면 AI가 무엇을 볼지와 무엇을 보지 않을지를 요청서에 함께 적어 보세요. 문제의 화면, 기능 이름, 관련 경로, 확인 목적을 먼저 정하면 불필요한 탐색을 줄일 수 있어요.
요청을 만들 때는 다음 항목을 넣어 보세요.
- 작업 목적: 무엇이 잘못됐고 어떤 결과를 원하는지
- 확인 대상: 특정 화면, 기능, 파일 또는 폴더
- 제외 대상: 이번 작업과 관계없는 화면이나 기능
- 완료 조건: 어떤 상태가 되면 작업이 끝난 것으로 볼지
- 변경 제한: 꼭 필요한 부분만 고치고 다른 동작은 유지할 것
- 확인 방법: 어떤 입력과 흐름으로 결과를 점검할지
처음부터 “원인을 찾아서 전체를 고쳐줘”라고 하기보다 단계별로 요청해 보세요.
- 문제가 나타나는 화면과 연결된 범위만 확인해요.
- 의심되는 원인을 몇 가지로 정리해요.
- 각 원인을 확인할 방법을 제안하게 해요.
- 원인이 맞는지 확인한 뒤 수정해요.
- 수정한 파일과 바뀐 동작을 요약하게 해요.
- 남은 위험 요소와 추가 점검 항목을 확인해요.
범위를 적을 때는 “이 기능과 관련된 부분만 확인하고, 관련 없는 파일은 수정하지 마세요”처럼 제한을 분명히 하는 것이 좋아요. 다만 실제 연결 관계가 예상보다 넓을 수 있으므로, AI가 추가 파일을 확인해야 한다고 말하면 그 이유를 먼저 확인한 뒤 범위를 넓히세요.
잘 됐는지 확인하려면 작업이 끝난 뒤 변경 목록을 받아 보세요. 요청한 기능과 관계없는 파일이 바뀌었거나, 원래 유지해야 할 동작까지 수정됐다면 범위를 다시 줄여 검토하는 것이 좋아요. 파일 개수 자체보다 변경 이유가 설명되는지가 더 중요해요.
커서와 클로드 코드 중 뭘 써야 하나요?
두 도구 중 무엇을 사용할지는 현재 작업의 방식과 필요한 기능을 기준으로 판단해 보세요. 특정 부분을 빠르게 고칠지, 여러 파일과 작업 단계를 정리할지에 따라 자신에게 맞는 도구를 선택해 보세요.
선택할 때는 이름보다 다음 기준을 보세요.
- 지금 하려는 일이 한 화면의 작은 수정인지, 여러 부분이 연결된 작업인지
- 코드를 직접 확인하면서 한 줄씩 고치고 싶은지, 작업 계획을 먼저 정리하고 싶은지
- 수정 전후를 비교하고 되돌리는 흐름을 쉽게 관리할 수 있는지
- 프로젝트의 구조와 작업 범위를 직접 지정할 수 있는지
- 결과를 테스트할 수 있는 환경이 준비되어 있는지
작은 문구 변경이나 특정 화면의 간단한 수정은 편집 화면에서 결과를 바로 확인하는 방식으로 진행해 볼 수 있어요. 기능의 흐름을 조사하거나 여러 파일의 변경 계획을 세워야 한다면, 먼저 범위와 완료 조건을 정한 뒤 작업을 진행해 보세요.
처음부터 도구를 하나로 고정할 필요도 없어요. 같은 작업을 두 도구에 무작정 반복하기보다, “요구사항 정리”, “코드 수정”, “화면 확인”, “문제 재현”처럼 역할을 나누고 어떤 방식이 현재 작업에 맞는지 판단해 보세요.
다만 어떤 도구를 쓰든 결과 검수는 따로 해야 해요. AI가 만든 코드는 실행된다는 사실만으로 충분하지 않아요. 사용자가 실제로 밟는 흐름을 직접 따라가고, 예외 상황과 모바일 화면, 기존 기능의 유지 여부까지 확인해야 해요.
앱이나 웹을 만들었는데 배포는 어떻게 하나요?
배포는 개발이 끝났다는 뜻이 아니라, 실제 사용자가 접근할 수 있는 환경에 결과를 옮기고 운영 상태를 확인하는 과정이에요. 수정한 기능을 바로 공개하기보다 준비, 점검, 적용, 사후 확인의 순서로 진행하는 것이 안전해요.
배포 전에는 다음 항목을 확인해 보세요.
- 서비스 이름과 주소가 실제 운영 대상과 맞는지
- 주요 화면이 정상적으로 열리는지
- 로그인, 입력, 저장, 전송 같은 핵심 흐름이 이어지는지
- 빈 입력과 잘못된 입력에 안내가 나오는지
- 모바일 화면에서 글자와 버튼이 겹치지 않는지
- 이미지나 첨부 자료가 빠지지 않았는지
- 운영에 필요한 설정값이 테스트용 값과 섞이지 않았는지
- 기존에 사용하던 기능이 그대로 작동하는지
- 문제가 생겼을 때 이전 상태로 돌아갈 방법이 있는지
배포를 AI에게 맡길 때도 “배포해줘” 한 문장으로 끝내지 않는 것이 좋아요. 어떤 환경에 적용할지, 공개 전에 무엇을 확인할지, 실패하면 어떻게 되돌릴지, 배포 후 어떤 화면을 확인할지를 먼저 정리해야 해요. 실제 변경이 일어나는 작업은 AI의 설명을 읽고 한 번 더 확인한 뒤 진행하세요.
배포 직후에는 새 기능만 보지 말고 기존 기능도 다시 확인해야 해요. 특히 웹에서는 첫 화면만 열리는지 확인하지 말고, 메뉴 이동과 문의·예약·저장처럼 사업에 직접 연결된 흐름까지 살펴보세요. 오류가 생기면 증상이 나타난 화면, 입력값, 발생한 상황을 기록해 다시 좁은 범위로 점검하는 것이 좋아요.
검색 유입을 생각한다면 기술적인 배포와 함께 내용의 구조도 확인해야 해요. 구글은 AI 검색만을 위한 별도 최적화 방법은 없다고 안내하고 있으므로, 좋은 내용과 크롤링 가능한 구조라는 기본 원칙이 중요해요. 네이버 서치어드바이저와 구글 서치콘솔에 사이트를 등록하고 사이트맵을 내는 것도 기본 점검 항목이에요.
중요한 글 내용은 자바스크립트로만 그리지 않고 HTML에서 바로 보이게 두는 편이 좋아요. 네이버 검색 로봇은 자바스크립트로 그리는 화면을 잘 읽지 못하는 편이기 때문이에요. llms.txt에 우선순위를 두기보다 기본 콘텐츠와 사이트 구조를 먼저 점검하세요.
ZORA 로 하는 법
클로드 코드나 AI 개발 도구에 맡길 일을 정리하기 어렵다면, ZORA의 「작업 요청서」에서 필요한 내용을 먼저 구조화할 수 있어요. 작업 종류와 필수 정보를 입력하면 지시서를 미리 확인한 뒤, 작업에 맞는 봇 대화로 넘길 수 있어요.
아래 영상으로 먼저 훑어보세요.
시작하려면 작업 요청서로 이동하거나, 왼쪽 메뉴에서 「글·블로그」를 누른 뒤 「작업 요청서」를 선택해요. 봇에게 맡길 일이 무엇인지와 대상 사이트 주소를 먼저 정해 두면 입력이 수월해요.
작업 종류를 먼저 골라요
화면에는 블로그 원고, 사이트 진단, 트래픽 상담, SEO 개선, 카드뉴스, 이미지, 사이트 편집, 자유 요청과 관련된 작업 종류를 고를 수 있어요. 앱이나 웹의 문제를 점검하고 싶다면 요청 내용에 맞는 작업을 선택하고, 무엇을 골라야 할지 모르겠으면 「자유 요청」에 원하는 결과를 적어 보세요.
다른 타일을 누르면 앞에서 적은 칸이 비워질 수 있으므로 작업 종류를 먼저 고른 뒤 내용을 입력하는 것이 좋아요.
필요한 칸을 채우고 범위를 적어요
왼쪽 「— 몇 가지만 알려주세요」 칸에 작업 내용을 입력해요. 빨간 * 표시가 붙은 칸은 꼭 작성해야 하고, 선택 칸은 비워 둘 수 있어요. 클로드 코드나 개발 도구에 전달할 작업이라면 대상 사이트 주소, 문제가 나타나는 화면, 원하는 결과, 확인해야 할 예외 상황을 구체적으로 적어 보세요.
예를 들면 다음 내용을 넣을 수 있어요.
- 어떤 화면이나 기능이 문제인지
- 이번에 확인할 범위와 제외할 범위
- 정상 입력과 실패 상황에서 기대하는 결과
- 기존에 유지해야 하는 기능
- 수정 후 직접 확인할 항목
- 배포 전에 검토할 내용
지시서를 확인한 뒤 보내요
오른쪽 「완성된 작업 지시서」에서 [작업], [주제]처럼 정리된 내용을 확인해요. 필수 칸이 비어 있으면 아래에 ‘필수 항목을 입력하면 더 정확해요’가 나오고 보내기 버튼이 잠길 수 있으니, 빠진 내용을 채워 주세요.
내용이 맞으면 「이대로 봇에게 보내기」를 눌러 작업에 맞는 봇의 대화 창으로 넘길 수 있어요. 채팅 화면에서 보내기를 누르면 전달되고, 다른 곳에 사용하려면 「복사」를 누르면 돼요.
작업 요청서의 지시서 끝에는 ‘부족한 정보가 있으면 한 번에 모아서 물어봐줘’가 자동으로 붙어요. 필요한 정보가 여러 개일 때 질문을 나눠 받는 일을 줄이는 데 도움이 돼요.
작업 요청서를 만드는 과정은 AI를 사용하지 않지만, 봇에게 보낸 뒤의 대화와 작업은 AI 대화 이용량에 들어가요. 사이트 편집처럼 실제로 내용이 바뀌는 작업은 봇 대화에서 결과를 한 번 더 확인하고 진행하세요. 자세한 사용법은 작업 요청서 사용법에서 확인할 수 있어요.
정리
클로드 코드로 앱·웹을 만들 때는 전체 작업을 한 번에 맡기지 말고 범위, 완료 조건, 예외 상황을 먼저 정하세요.
정상 흐름뿐 아니라 빈 입력, 실패, 취소, 중복 실행과 모바일 화면까지 직접 확인해야 해요.
배포 전에는 핵심 기능과 되돌릴 방법을 점검하고, 배포 후에도 기존 기능을 다시 살펴보세요.
다음에는 ZORA의 「작업 요청서」에서 맡길 일과 확인 범위를 먼저 정리해 보세요.