요청·응답·상태·데이터
AI가 코드를 대신 생성하고, 설계를 보조하며, 디버깅까지 도와주는 시대이다. 그러나 이 모든 변화 속에서도 웹의 근본 구조는 단 한 번도 변하지 않았다.
웹은 단 네 가지 요소만으로 움직인다.
요청(Request)
응답(Response)
상태(State)
데이터(Data)
수많은 프레임워크, 라이브러리, 기술 스택이 등장하지만 웹이 동작하는 원리는 이 네 가지의 변주일 뿐이다.
도구를 잘 사용하는 사람은 이 네 요소를 도구보다 더 깊이 이해하고, 도구에게 무엇을 어떻게 구성해야 하는지 정확하게 전달할 수 있는 사람이다. AI에게 코드를 요청할 때 이 네 개념이 빠지면 AI는 겉보기엔 동작하지만 실전에선 위험한 코드를 만들어낸다. 그리고 초보자는 그 차이를 구분하지 못한다.
이 장은 "웹이 작동하는 방식"을 이해함으로써 바이브 코딩을 제대로 수행하기 위한 기반을 다지는 단계이다.
1) 요청(Request) — 웹의 출발점
모든 웹 기능은 "요청"이라는 하나의 동작에서 시작한다. 사용자가 버튼을 클릭하거나, 페이지를 이동하거나, 데이터를 제출하면 브라우저는 서버에게 이렇게 말한다. "이 작업을 해줘."
요청에는 항상 다음 정보가 포함된다.
어떤 동작을 원하는지 (HTTP 메서드: GET/POST/PATCH/DELETE 등)
어디로 요청을 보내는지 (URL)
어떤 데이터를 포함하는지 (Body / Params / Headers)
누가 요청하는지 (Authentication / Token 정보)
이것을 모르고 AI에게 코드를 부탁하면 아래와 같이 된다.
요청 : "회원정보 수정 API 만들어줘"
AI는 겉보기엔 정상처럼 보이는 코드를 만들지만, 다음과 같은 치명적인 문제들이 숨어 있을 수 있다.
실제로는 수정이 아니라 새 사용자를 생성해 버릴 수도 있다.
인증 정보가 빠져 보안 취약점이 생긴다.
메서드가 POST인지 PATCH인지 혼동한다.
이전 prefix가 있음에도 불구하고 URL 규칙을 새로 만들어 일관성을 해친다.
웹 개발은 결국 요청이 정확해야 응답이 정확해지는 구조다. 도구 사용에서도 요청을 어떻게 설계하고 설명하느냐가 결과물의 품질을 결정한다.
2) 응답(Response) — 웹이 움직이는 방식
웹은 요청에 대한 결과를 항상 "응답" 형태로 돌려준다. 응답은 단순히 "데이터 한 덩어리"가 아니다. 그 안에는 다음 정보가 모두 담겨 있다.
작업이 성공했는지 실패했는지
실패했다면 왜 실패했는지
다음 화면을 그리는 데 필요한 정보가 무엇인지
사용자가 어떤 행동을 취해야 하는지
로그인 요청의 응답을 예로 들면 다음과 같다.
성공시:
access_token
refresh_token
사용자 정보
권한 정보
실패시:
400 → 입력값 오류
401 → 비밀번호 틀림
429 → 시도 횟수 제한
초보자는 응답을 단지 "화면에 보여주는 데이터"로 이해하지만, 실제 웹 서비스에서 응답은 다음 동작을 결정하는 설계도다.
도구 사용 시 이 개념이 부족하면 다음과 같은 문제가 발생한다.
로그인은 되는데 화면 전환이 안 됨
회원가입 성공했는데 에러처럼 보임
서버 오류인지, 사용자의 실수인지 구분 불가
인증 실패인데 계속 페이지 이동이 진행되면서 무한 루프에 빠짐
AI에게 요청을 보낼 때 응답 형식을 명확히 지정해야 정확한 API 코드와 정확한 UI 코드가 생성된다.
3) 상태(State) — 화면이 '왜 그렇게 보이는지'를 결정하는 힘
웹의 모든 화면은 상태(state)에 따라 결정된다.
로그인된 상태인가?
장바구니에 몇 개가 들어 있는가?
선택한 메뉴가 무엇인가?
API 성공/실패 여부는?
로딩 중인가?
상태를 모르면 이런 현상을 해결할 수 없다.
데이터는 갱신됐는데 화면에는 반영 안 되고, 멈춘 것처럼 보임.
이전 페이지의 상태가 다음 페이지에 남아 있음
API 응답 속도가 느려서 UI가 깨지는 문제
같은 버튼을 눌렀는데 상황에 따라 다르게 동작
AI가 만든 코드에서 가장 자주 틀리는 부분도 바로 상태 관리다. 왜냐하면 AI는 상황의 맥락을 완벽하게 이해하지 못한 채 일반적인 패턴만 적용하기 때문이다.
도구를 제대로 사용하려면 다음과 같은 원리를 설명할 수 있어야 한다.
어떤 상태가 있어야 하는지
그 상태가 언제 변하는지
그 상태가 변하면 UI에서 무엇이 달라져야 하는지
상태는 화면의 뼈대이자 규칙이다. 상태를 설명하지 못하면 도구는 절대 올바른 UI 코드를 생성하지 못한다.
4) 데이터(Data) — 웹의 최종 목적지
웹의 모든 동작이 궁극적으로 도달하는 지점은 "데이터"다. 웹 개발의 모든 기능은 다음 중 하나에 속한다.
데이터를 읽고(Read)
데이터를 저장하고(Create)
데이터를 수정하고(Update)
데이터를 삭제한다(Delete)
이 네 가지의 조합을 CRUD라고 부르며 웹 서비스의 90%를 구성한다.
그러나 초보자는 데이터를 단순한 "값의 모음"으로만 이해한다. 하지만 실제로 데이터는 다음 요소들로 구성된다.
스키마(구조)
제약조건
관계 (1:1, 1:N, N:M)
인덱싱
무결성
트랜잭션
보안 정책
AI에게 스키마 설계를 맡기면 겉보기엔 완벽해 보이지만 아래와 같은 구조적 문제를 자주 만든다.
중복 데이터
삭제 시 관계 오류
인덱스 미설정으로 인해 속도 저하
참조 무결성 붕괴
잘못된 enum 또는 타입 지정
도구 사용에서 데이터 구조를 인간이 설계하지 않으면 서비스는 시간이 지날수록 망가진다. AI는 데이터를 "생성"할 수 있지만 데이터의 의미와 관계를 판단하는 것은 인간의 역할이다.
5) 이 네 가지 개념이 바이브 코딩에서 더 중요해진 이유
AI가 코드를 대신 만들면 사람은 더 이상 "코드를 짜는 사람"이 아니라 코드의 구조를 설계하고 검증하는 사람이 된다.
그러나 다음과 같은 상황을 떠올려보자. AI가 코드를 생성했다. 문제가 생겼다. 이제 누구의 책임일까?
개발자의 책임이다. AI에게 잘못된 요청을 보낸 것도 사람이고, AI의 응답 내용을 검증하지 않은 것도 사람이다. 이러한 이유로 AI 코딩 시대에는 웹의 본질을 이해하는 능력이 과거보다 훨씬 더 중요해졌다.
AI는 패턴을 이해하지만 서비스의 의도와 맥락은 이해하지 못한다. AI가 틀린 코드를 만들었을 때 그것을 발견하고 수정 방향을 제시하는 것은 온전히 인간이 해야 하는 일이다.
웹의 본질은 요청 → 응답 → 상태 → 데이터의 순환이다. AI는 이 순환의 각 단계에서 코드를 만들어줄 수 있지만, 그 순환의 의미를 이해하는 것은 인간만이 할 수 있다.
바이브 코딩은 코드를 대신 만들어주는 기술이 아니라 웹의 구조를 정확하게 설명할 수 있는 사람만 제대로 사용할 수 있는 기술이다.
웹의 본질을 이해한 사람만이 도구와 함께 안정적이고 확장 가능한 서비스를 만들 수 있다.