학습 목표
- 백엔드와 요청 흐름 이해하기의 역할과 적용 조건을 설명할 수 있다.
- 글 조회·생성·수정·삭제의 주소와 메서드를 정하세요.
- 비로그인·타인·잘못된 입력으로 직접 요청해 거절 결과를 확인하세요.
사전 지식
앞선 Git과 GitHub로 변경 기록 남기기를 먼저 읽으면 용어를 이해하기 쉽습니다. 이미 아는 내용이면 이 장부터 시작해도 됩니다.
개념 이해
서버는 화면의 요청을 그대로 믿고 저장하는 장치가 아닙니다. 사용자의 신원과 권한, 입력 형식, 업무 규칙을 검사하고 일관된 결과를 돌려주는 경계입니다.
REST API·요청·응답
REST는 자원을 주소로 표현하고 HTTP 메서드로 작업을 나누는 설계 방식입니다. URL, 헤더, 본문을 구분하고 JSON 성공/실패 형식을 일관되게 정합니다.
HTTP 상태 코드
200대는 성공, 400대는 입력·인증·권한 등 요청 관련 문제, 500대는 서버 문제입니다. 401과 403을 구분하되 민감한 내부 오류를 그대로 공개하지 않습니다.
서버리스와 API 서버
서버리스는 서버가 없다는 뜻이 아니라 실행 환경 운영을 제공자가 맡는 방식입니다. API 서버는 요청을 처리하는 역할이며 상시 프로세스나 서버리스로 운영할 수 있습니다.
인증·권한·업무 규칙
토큰 서명과 만료를 검증한 뒤 그 사용자가 해당 자원을 수정할 수 있는지 판단합니다. 제목 길이 같은 입력 검증과 게시 한도 같은 비즈니스 규칙도 서버가 적용합니다.
오류와 로그
사용자에게는 다음 행동을, 운영 로그에는 비밀을 제외한 요청 ID와 실패 지점을 남깁니다. 같은 실패를 무한 재시도하지 않도록 분류합니다.
실제 사용 사례
게시글 수정 요청에서 요청 본문의 ownerId를 믿으면 다른 사람 글을 수정할 수 있습니다. 서버가 검증한 토큰 UID와 저장된 글의 소유자를 비교해야 합니다.
단계별 실습
실습은 운영 서비스가 아닌 별도 연습 프로젝트에서 진행하세요. 기존 파일이 있다면 변경 전 기록을 남깁니다.
- 글 조회·생성·수정·삭제의 주소와 메서드를 정하세요.
- 각 요청의 인증·소유권·입력·업무 검증 순서를 적으세요.
- 성공과 실패 JSON, 상태 코드를 정의하세요.
- 비로그인·타인·잘못된 입력으로 직접 요청해 거절 결과를 확인하세요.
코드와 프롬프트
아래 요청에서 대괄호 부분을 내 프로젝트에 맞게 바꾼 뒤 AI 도구에 전달하세요.
[자원] API를 설계해줘. 메서드·요청·응답·상태 코드와 인증→권한→입력→업무 규칙 순서를 적고 비로그인·소유자·타인·관리자의 허용표를 만들어줘. 운영 로그에는 키와 개인정보를 남기지 않게 해줘.자주 발생하는 문제와 해결
| 문제와 원인 | 해결 방법과 확인 기준 |
|---|---|
| UI에서는 막히는데 직접 요청은 성공함 | 서버나 데이터 정책에서 소유권을 검증합니다. |
| 모든 실패를 200으로 반환함 | 실패 종류에 맞는 상태와 안전한 오류 형식을 사용합니다. |
핵심 요약
- 화면 입력은 신뢰할 수 없는 데이터입니다.
- 요청마다 자원 단위 권한을 검사합니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 요금·사용 한도·제품 기능·설정 경로는 변경될 수 있으므로 작업 직전 공식 문서와 설치 버전을 확인하세요.