AI 코딩과 앱 제작 준비
질문 100개

누가 어떤 문제를 해결하고 어떤 화면에서 행동하는지 설명하세요. 사용할 기술 이름만 나열하기보다 실제 사용자 흐름과 완료 조건을 먼저 정하는 편이 좋습니다.

핵심 작업을 끝내는 데 꼭 필요한 화면과 데이터만 남기세요. 나중에 추가할 기능을 별도로 적으면 작업 도중 범위가 계속 커지는 것을 줄일 수 있습니다.

사용자가 시작하는 위치부터 결과를 확인하는 순간까지 행동 순서로 적으세요. 로그인이나 오류가 발생했을 때의 이동도 함께 설명하는 것이 좋습니다.

확인 가능한 행동과 결과로 적으세요. 예쁘게 만들기보다 어떤 입력에서 무엇이 저장되고 어디에 표시되는지 명확히 해야 검증할 수 있습니다.

버튼과 저장, 외부 연결이 실제로 동작하는지 기준으로 구분하세요. 화면만 구현된 부분을 운영 가능한 기능이라고 표시하지 않는 것이 좋습니다.

화면과 데이터 접근 범위를 설계하기 전에 정하세요. 운영자와 일반 사용자의 차이를 나중에 덧붙이면 권한 처리가 여러 곳에 흩어질 수 있습니다.

첫 사용과 검색 결과 없음 같은 상황을 미리 설계하는 것이 좋습니다. 예시 데이터를 실제 저장 결과처럼 표시하지 말고 다음 행동을 안내하세요.

사용자가 이해할 수 있는 원인과 재시도 방법을 설명하세요. 내부 오류나 비밀값을 그대로 보여주지 않고 작업이 저장됐는지도 명확히 알려야 합니다.

어떤 작업이 진행 중인지와 중복 실행을 피할 수 있는 상태를 표시하세요. 실제 진행률을 알 수 없다면 임의의 숫자를 완료율처럼 만들지 마세요.

핵심 화면과 입력 흐름을 설계할 때 함께 고려하세요. 마지막에 폭만 줄이면 표와 메뉴, 버튼이 잘리거나 사용할 수 없게 될 수 있습니다.

기능에 필요한 값과 필수 여부, 허용 형식을 적으세요. 화면에 입력란을 만들기 전에 저장 후 어떻게 조회하고 수정할지도 생각하는 것이 좋습니다.

검수나 예외 처리가 필요한 단계는 명시적으로 남길 수 있습니다. 자동으로 처리된 것처럼 보이게 만들기보다 사람이 해야 할 작업과 상태를 보여주세요.

필요한 계정과 권한, 실패 시 동작을 먼저 정하세요. 연결 전에는 실제 호출이 구현됐다고 표시하지 말고 설정 대기 상태를 구분해야 합니다.

화면 확인용 데이터임을 표시하고 운영 데이터와 분리하세요. 배포 때 예시 고객이나 성과가 실제 기록처럼 보이지 않는지 확인해야 합니다.

새 요구가 기존 완료 조건을 바꾸는지 먼저 정리하세요. 핵심 기능의 검증을 마치고 추가 작업을 별도로 계획하면 변경의 영향을 파악하기 쉽습니다.

정상 흐름부터 구현할 수 있지만 공개 전에는 빈값과 실패, 권한 없는 접근도 확인해야 합니다. 잘 되는 입력 하나만으로 전체 기능이 완성됐다고 판단하지 마세요.

편집 주체와 수정 빈도에 따라 데이터 저장과 관리 화면이 달라집니다. 개발자만 바꿀 정보와 운영자가 직접 바꿀 정보를 구분하세요.

설치와 실행, 필요한 설정, 검증 방법을 적으세요. 실제 연결되지 않은 기능과 운영 시 남은 작업도 명확히 기록하는 편이 좋습니다.

대표 입력과 원하는 결과 예제를 함께 주면 해석 차이를 줄일 수 있습니다. 민감한 실제 자료 대신 형식을 유지한 안전한 예제를 사용하세요.

정한 사용자 흐름과 오류 처리가 실제 환경에서 동작하는지 확인하세요. 빌드 성공과 배포 성공, 사용자 작업 완료를 각각 구분해야 합니다.

독립적인 역할이나 반복되는 UI를 기준으로 나누세요. 파일을 작게 만드는 것만 목표로 삼으면 관련 코드가 흩어져 이해하기 어려울 수 있습니다.

비밀값과 권한 검사는 서버에 두고 사용자 상호작용은 필요한 범위에서 브라우저로 보냅니다. 어디서 실행되는지 파일과 데이터 흐름으로 확인해야 합니다.

자주 바뀌지 않는 설명과 공개 글에 적합할 수 있습니다. 수정 후 언제 다시 생성되고 공개되는지 운영 흐름도 함께 정하세요.

요청마다 다른 권한이나 최신 데이터가 필요한 경우에 검토할 수 있습니다. 모든 페이지를 동적으로 만들기보다 실제 갱신 요구를 기준으로 선택하세요.

사용자가 찾는 주제와 자원의 관계가 드러나도록 정하세요. 주소가 바뀔 수 있다면 기존 링크를 유지할 이동 규칙도 생각해야 합니다.

없는 자원임을 나타내는 상태와 이해 가능한 안내를 제공하세요. 오류 화면을 정상 콘텐츠처럼 응답하면 사용자와 수집기가 상태를 오해할 수 있습니다.

입력 목적을 사용자와 보조 기술에 명확히 전달하기 위해 필요합니다. placeholder가 사라져도 무엇을 입력해야 하는지 알 수 있어야 합니다.

문제가 있는 입력과 가까운 위치에 구체적인 수정 방법을 표시하세요. 전체 실패 메시지만 보여주면 사용자가 어느 값을 고쳐야 하는지 찾기 어렵습니다.

브라우저 검사는 편의를 위한 것이며 우회될 수 있습니다. 서버에서도 필수값과 형식, 권한을 다시 확인해야 합니다.

여러 화면이 공유하는 상태와 변경 흐름이 실제로 복잡한지 먼저 확인하세요. 작은 로컬 상태까지 전역으로 만들면 변경 원인을 추적하기 어려워질 수 있습니다.

공유와 새로고침 후에도 같은 화면 조건을 복원할 수 있습니다. 개인정보나 비밀값은 주소에 넣지 않도록 구분해야 합니다.

저장된 값과 사용자가 아직 수정 중인 값은 의미가 다릅니다. 둘을 섞으면 저장 실패나 새로고침 때 변경이 사라지는 이유를 설명하기 어렵습니다.

실제 버튼과 링크는 역할에 맞는 요소를 사용하는 편이 좋습니다. 키보드와 보조 기술의 기본 동작을 활용할 수 있기 때문입니다.

행과 열 제목을 의미에 맞게 표시하고 단위를 설명하세요. 모바일에서도 값이 어느 제목에 속하는지 알 수 있어야 합니다.

이미지 영역을 미리 확보하면 로딩 중 화면 이동을 줄일 수 있습니다. 실제 표시 크기에 맞는 파일과 의미 있는 대체 텍스트도 확인하세요.

필요한 글꼴과 굵기만 사용하고 로딩 중에도 본문을 읽을 수 있게 구성하세요. 외부 요청과 라이선스 조건도 함께 확인하는 것이 좋습니다.

페이지가 답하는 주제와 대표 주소가 다르기 때문입니다. 모든 페이지에 같은 제목과 설명을 복사하면 목적을 구분하기 어려워집니다.

화면과 같은 콘텐츠 원본을 사용해 서버에서 생성하는 방법이 좋습니다. 실제 보이지 않는 답변이나 가격을 메타데이터에만 추가하지 마세요.

서로 다른 코드가 같은 데이터 형식을 기대하도록 돕습니다. 타입이 있어도 외부 요청의 실제 값은 실행 시 검사가 필요합니다.

코드만으로 알기 어려운 이유와 제약을 설명하는 주석이 유용합니다. 동작을 그대로 반복하는 주석보다 중요한 선택의 배경을 남기세요.

데이터 양과 동시 수정, 조회 방식, 운영 환경을 기준으로 선택하세요. 서버리스 파일 시스템을 영구 데이터 저장소처럼 가정하지 않는 것이 중요합니다.

실행 환경의 저장 특성을 확인해야 합니다. 임시 파일 시스템이라면 재시작이나 새 배포 후 사라질 수 있어 영구 저장소가 필요합니다.

이름이 바뀌어도 같은 항목을 찾고 수정하기 위해 필요합니다. 화면 순서나 표시 이름만으로 기록을 식별하지 않는 편이 좋습니다.

처음 만든 시각과 실제 내용이 변경된 시각을 구분하세요. 조회하거나 배포했다는 이유로 수정일을 갱신하지 않는 것이 좋습니다.

임시 파일에 기록한 뒤 교체하는 등 중간 상태가 공개되지 않는 방식을 검토하세요. 실패 후 기존 데이터가 보존되는지도 시험해야 합니다.

잠금이나 트랜잭션 등 환경에 맞는 동시성 제어가 필요합니다. 마지막 저장이 앞선 변경을 덮어쓰는 상황을 실제로 시험하세요.

작업을 구분하는 키와 처리 완료 기록을 활용하세요. 요청을 다시 받았을 때 기존 결과를 확인하는 동작이 필요합니다.

기존 기록을 새 형식으로 옮기는 절차와 복구 방법을 준비하세요. 코드만 바꾸고 과거 데이터가 같은 구조라고 가정하지 마세요.

저장 기능을 운영하기 전에 복구까지 시험하는 것이 좋습니다. 백업 파일이 있다는 사실과 실제로 복원할 수 있다는 사실은 다릅니다.

필드의 의미와 필수 여부, 오류 응답을 명확히 정하세요. 성공 응답만 문서화하지 말고 권한과 입력 실패도 함께 다루는 편이 좋습니다.

응답이 오지 않는 작업이 계속 자원을 점유하지 않게 제한하는 것이 좋습니다. 시간 초과 후 재시도할지 사용자가 확인할지 동작도 정하세요.

실패 종류를 구분하고 간격을 두는 재시도 정책을 적용하는 편이 좋습니다. 인증 실패처럼 반복해도 해결되지 않는 오류는 설정 확인으로 넘겨야 합니다.

사용자와 외부 서비스의 제한을 각각 고려하세요. 서버 인스턴스가 여러 개면 한 프로세스의 메모리 제한만으로 전체 요청을 제어할 수 있는지 확인해야 합니다.

데이터가 늘어날 때 응답 크기와 읽기 편의를 고려해 결정하세요. 다음 페이지가 있는지와 정렬 기준이 안정적인지도 함께 설계해야 합니다.

같은 결과를 반복해서 가져오며 일정 시간 지연을 허용할 수 있을 때 검토하세요. 갱신과 권한이 중요한 데이터는 캐시 범위를 특히 주의해야 합니다.

데이터 저장 결과와 캐시 갱신 경로를 나누어 확인하세요. 화면만 새로고침하는 것이 실제 서버 캐시를 바꾸는지 확인해야 합니다.

발신 인증과 이벤트 식별자, 처리할 대상 범위를 확인하세요. 같은 이벤트가 다시 도착했을 때 중복 실행하지 않는 처리도 필요합니다.

파일 크기와 허용 형식, 저장 위치를 제한하세요. 파일 이름이나 선언된 형식만 믿지 말고 실제 처리 단계의 위험도 검토해야 합니다.

다른 도구에서 파일을 다시 열어 값과 형식이 유지되는지 확인하세요. 빈값과 특수문자, 긴 텍스트도 시험하는 것이 좋습니다.

삭제할 대상과 권한을 서버에서 확인하고 되돌릴 수 있는 범위를 정하세요. 화면에서 버튼을 숨기는 것만으로 삭제 권한이 제어되지는 않습니다.

공개되면 안 되는 키는 서버에서 관리해야 합니다. 이름을 숨기거나 코드를 압축해도 브라우저로 전달된 값이 비밀로 유지되는 것은 아닙니다.

브라우저에 공개되어도 되는 설정만 넣는 곳입니다. 프레임워크의 공개 변수 규칙을 확인하고 관리자 토큰이나 서비스 비밀키를 넣지 마세요.

환경 파일을 제외하고 커밋 전 변경 목록을 확인하세요. 이미 노출된 키는 파일만 지우는 것으로 끝내지 말고 폐기와 교체를 검토해야 합니다.

로그인은 사용자가 누구인지 확인하고 권한 검사는 무엇을 할 수 있는지 판단합니다. 로그인했다는 사실만으로 모든 기록을 읽거나 수정하게 해서는 안 됩니다.

서버에서 요청 사용자와 대상 기록의 관계를 확인하세요. URL의 ID나 브라우저에서 보낸 소유자 값을 그대로 믿지 않는 것이 중요합니다.

주소를 알기 어렵게 만드는 것만으로 접근을 보호할 수는 없습니다. 인증과 역할 검사, 요청 검증을 실제 관리 기능에 적용해야 합니다.

인증된 사용자의 의도된 요청인지 확인하는 보호가 필요합니다. 쿠키 인증을 쓴다면 출처 검사와 CSRF 대응 방식을 함께 검토하세요.

문자열이 실행 가능한 코드로 해석되지 않도록 안전하게 렌더링하세요. 검증되지 않은 HTML을 그대로 삽입하는 기능은 특히 주의해야 합니다.

데이터와 명령을 분리하는 매개변수화된 방식을 사용하세요. 문자열을 이어 붙여 쿼리를 만드는 방식은 입력이 실행 구조를 바꿀 위험이 있습니다.

내부 주소와 제한된 네트워크 자원에 접근하지 않도록 검증해야 합니다. 최초 주소뿐 아니라 DNS 결과와 이동한 주소도 확인해야 합니다.

허용한 주소가 내부나 금지된 주소로 이동할 수 있어 다시 검사해야 합니다. 이동 횟수와 응답 크기, 시간도 제한하는 편이 좋습니다.

예상보다 큰 입력이 서버 자원을 과도하게 사용하지 않게 하기 위해 필요합니다. 기능에 필요한 범위를 기준으로 제한과 오류 안내를 정하세요.

비밀번호와 인증 키, 불필요한 개인정보는 남기지 않는 것이 좋습니다. 문제 재현에 필요한 식별자와 오류 유형 중심으로 기록하세요.

도구 인자와 대상, 실행 권한을 애플리케이션에서 확인해야 합니다. 모델 출력이 형식에 맞는다는 이유만으로 실행을 승인하지 마세요.

읽을 자료로 취급하고 시스템의 작업 지시나 권한으로 승격하지 마세요. 문서가 메일 발송이나 파일 삭제를 요구해도 별도 권한 검사가 필요합니다.

생성 코드나 외부 작업이 접근할 수 있는 파일과 네트워크 범위를 줄일 수 있습니다. 격리 환경이 있다고 모든 코드의 동작 검토가 불필요해지는 것은 아닙니다.

공식 출처와 유지 상태, 필요한 권한과 기능 범위를 확인하세요. AI가 제안한 패키지 이름이 실제로 존재하고 의도한 프로젝트인지도 검증해야 합니다.

사용자가 어떤 자료를 연결하고 어떤 작업을 허용하는지 이해할 수 있어야 합니다. 기능과 무관한 기술 세부 대신 실제 접근 범위와 행동을 설명하세요.

보호된 페이지와 API에 다시 접근할 수 없는지 확인하세요. 화면에서 이름이 사라진 것만으로 세션이 무효화됐다고 판단하지 마세요.

자동 검사는 알려진 조건을 확인하는 데 도움이 되지만 설계 전체를 보증하지는 않습니다. 데이터와 권한의 흐름을 실제 사용 시나리오로 검토해야 합니다.

요구사항과 연결된 파일부터 읽고 입력·처리·출력 흐름을 따라가세요. 모든 줄을 같은 깊이로 읽기보다 권한과 저장, 외부 실행을 우선 확인하는 편이 좋습니다.

타입 검사는 코드의 형식적 불일치를 찾는 데 도움이 됩니다. 실제 사용자 행동과 데이터 처리 결과가 맞는지는 별도 실행 검증이 필요합니다.

작은 기능의 중요한 규칙과 경계 조건을 확인합니다. 구현 내용을 그대로 복사한 테스트보다 잘못 동작했을 때 실제 문제가 되는 조건을 검사하세요.

저장과 승인, 외부 요청처럼 여러 부분이 연결되는 흐름을 확인할 때 유용합니다. 각 함수가 따로 맞아도 연결 순서와 상태 변경에서 오류가 날 수 있습니다.

사용자가 입력하고 이동하며 결과를 확인하는 흐름을 실제 화면에서 검증하세요. 자바스크립트 오류와 모바일 넘침, 키보드 동작도 함께 확인하는 편이 좋습니다.

공개 본문이 최초 HTML에 있는지 확인하기 위해서입니다. 화면 상호작용과 검색용 핵심 콘텐츠를 구분해 검증할 수 있습니다.

빈 입력과 잘못된 형식, 권한 없는 요청, 중복 실행을 포함하세요. 정상 예제에서는 드러나지 않는 저장과 권한 문제가 발견될 수 있습니다.

배포할 코드와 자원을 생성할 수 있었다는 사실을 확인한 것입니다. 실제 운영 계정과 외부 연결, 사용자 작업의 성공을 모두 뜻하지는 않습니다.

실제 호스팅 환경에서 화면과 API가 동작하는지 확인하세요. 운영 도메인과 데이터에 영향을 주지 않는지 배포 대상도 분명히 확인해야 합니다.

프로젝트 ID와 연결 도메인, 현재 운영 버전을 확인하세요. 비슷한 이름의 다른 프로젝트에 배포하면 기존 사이트를 바꿀 수 있습니다.

접근 보호가 유지된 상태이므로 일반 사용자와 크롤러가 본문을 읽을 수 없습니다. 공개가 필요한 사이트는 승인된 범위에서 보호 설정과 실제 비로그인 응답을 확인하세요.

변수가 빌드 때 사용되는지 실행 때 읽히는지 확인해야 합니다. 특히 미리 생성된 페이지에는 새 설정이 자동 반영되지 않을 수 있습니다.

이전 정상 버전과 데이터 변경의 복구 방법을 함께 기록하세요. 코드만 되돌려도 데이터 형식이 맞지 않으면 복구가 끝나지 않을 수 있습니다.

변경 내용과 소스 버전, 배포 주소, 수행한 검증을 남기세요. 확인하지 못한 부분도 적어 다음 작업자가 완료 범위를 오해하지 않게 해야 합니다.

서버 오류와 실패 요청, 핵심 사용자 작업의 결과를 확인하세요. 방문 수만 보는 것보다 기능이 실제로 완료되는지 관측하는 것이 좋습니다.

실제 사용자의 기기와 네트워크에 가까운 조건을 포함하세요. 개발 컴퓨터에서 빠르다는 사실만으로 모든 환경에서 빠르다고 판단하지 마세요.

주소나 콘텐츠 목록이 바뀌는 배포에서 함께 확인하는 것이 좋습니다. 페이지가 생성됐어도 연결이 끊기면 사용자가 찾기 어렵습니다.

검토 가능한 목적의 변경을 묶어 남기세요. 관련 없는 수정과 비밀값이 함께 들어가지 않도록 커밋 전 목록을 확인해야 합니다.

설치와 설정, 실행과 검증, 배포 방법이 필요합니다. 실제 연결된 계정과 아직 수동으로 해야 할 작업을 구분해 기록하세요.

현재 빌드핀 도구는 제작 준비와 확인 항목을 정리하는 체크리스트입니다. 실제 코드 작성과 실행, 배포 검증은 별도 작업으로 진행해야 합니다.