웹 서비스는 어떻게 동작하는가

웹 서비스를 처음 배우는 사람에게 가장 먼저 필요한 것은 코드를 잘 쓰는 능력보다 큰 그림을 보는 감각이다. 화면에 버튼이 있고, 버튼을 누르면 뭔가가 저장되고, 다시 새로고침하면 그 내용이 보인다. 우리는 이런 일을 너무 자연스럽게 사용하지만, 처음 만드는 입장에서는 꽤 신기하다. 도대체 누가 이 일을 하고 있을까?

답은 생각보다 단순하다. 웹 서비스는 보통 브라우저, 서버, 데이터베이스가 서로 역할을 나눠 일한다. 사용자는 브라우저에서 행동하고, 서버는 그 요청을 받아 처리하고, 데이터베이스는 필요한 정보를 기억한다. 이 흐름만 이해해도 AI가 만들어 준 코드가 왜 돌아가는지 훨씬 잘 보이기 시작한다.

웹 서비스는 결국 부탁하고 답하는 구조다

웹 서비스의 핵심은 아주 소박하다. 한쪽이 부탁하고, 다른 쪽이 답한다. 이것을 개발에서는 흔히 요청과 응답이라고 부른다.

예를 들어 사용자가 어떤 사이트에 들어가서 "글 목록 보여줘"라는 행동을 했다고 해보자. 실제로는 사용자가 그렇게 말로 하진 않지만, 브라우저는 서버에게 비슷한 뜻의 요청을 보낸다. 그러면 서버는 필요한 데이터를 확인한 뒤 "여기 글 목록이야"라고 응답한다. 브라우저는 그 응답을 받아 사람이 읽기 좋은 화면으로 보여준다.

이 구조를 이해하면 웹 서비스가 마법처럼 보이지 않는다. 단지 여러 컴퓨터가 정해진 방식으로 대화하는 것뿐이다.

브라우저는 사용자의 창문이다

브라우저는 우리가 웹 서비스를 만나는 출입구다. 크롬, 사파리, 엣지 같은 프로그램이 여기에 해당한다. 사용자는 브라우저 안에서 주소를 입력하고, 버튼을 누르고, 글을 작성하고, 로그인한다.

브라우저가 하는 일은 생각보다 많다. 서버에 요청을 보내고, 받은 데이터를 화면으로 그려 주고, 입력 폼에 사용자가 적은 내용을 모아서 다시 서버로 보내기도 한다. 쉽게 말하면 브라우저는 사용자와 서비스 사이의 통역사 같은 존재다.

초보자는 종종 화면에 보이는 것이 전부라고 느낀다. 하지만 화면은 결과일 뿐이다. 진짜 중요한 것은 그 화면 뒤에서 어떤 요청이 오가고 있는지 보는 눈이다.

서버는 일을 처리하는 관리자다

서버는 요청을 받으면 실제로 할 일을 처리하는 쪽이다. 브라우저가 "로그인할게요"라고 말하면 서버는 아이디와 비밀번호가 맞는지 확인한다. 브라우저가 "글 목록 주세요"라고 말하면 서버는 저장된 글을 찾아 정리해서 보내 준다.

서버를 식당의 주방이라고 생각해도 좋다. 손님은 메뉴를 주문하고, 주방은 주문서를 보고 음식을 만든다. 손님은 주방 안에서 무슨 냄비를 쓰는지 몰라도 된다. 다만 주문하고 결과를 받는 구조는 분명하다.

우리가 나중에 만들 서비스에서도 서버는 여러 가지 일을 맡는다. 예를 들면 이런 일들이다.

• 회원가입 요청 받기

• 로그인 상태 확인하기

• 글 작성, 수정, 삭제 처리하기

• 검색어에 맞는 글만 골라 보내기

즉, 서버는 단순히 데이터를 전달하는 창구가 아니라 규칙을 집행하는 곳이다. 누가 어떤 기능을 쓸 수 있는지, 어떤 데이터가 저장되어야 하는지, 잘못된 요청은 막아야 하는지 같은 판단이 여기서 일어난다.

데이터베이스는 기억을 담당한다

웹 서비스가 진짜 서비스처럼 보이려면, 누군가 남긴 정보가 나중에도 남아 있어야 한다. 회원 정보도 기억해야 하고, 작성한 글도 기억해야 하며, 어떤 사용자가 어떤 글을 썼는지도 기억해야 한다. 이 기억을 맡는 곳이 데이터베이스다.

데이터베이스를 아주 단순하게 표현하면, 서비스의 공책 또는 창고라고 볼 수 있다. 브라우저는 직접 데이터베이스에 접근하지 않는 경우가 많고, 보통 서버가 중간에서 필요한 정보를 읽고 쓴다.

예를 들어 사용자가 글을 작성하면 이런 흐름이 생긴다. 브라우저가 서버에 글 내용을 보내고, 서버는 그 내용을 확인한 뒤 데이터베이스에 저장한다. 나중에 다른 사용자가 목록 페이지에 들어오면, 서버는 데이터베이스에서 글들을 읽어 와서 브라우저에 보내 준다.

중요한 점은 데이터베이스가 단순 저장소 이상이라는 것이다. 잘 설계된 데이터베이스는 서비스가 커져도 정보를 안정적으로 관리하게 도와준다. 반대로 이 부분이 엉키면 서비스 전체가 금방 복잡해진다.

세 가지가 함께 일하는 흐름

이제 브라우저, 서버, 데이터베이스를 한 번에 묶어 보자. 웹 서비스는 보통 아래 순서로 움직인다.

1. 사용자가 브라우저에서 어떤 행동을 한다.

2. 브라우저가 서버에 요청을 보낸다.

3. 서버가 필요한 규칙을 확인한다.

4. 필요하면 데이터베이스에서 읽거나 저장한다.

5. 서버가 결과를 브라우저에 응답한다.

6. 브라우저가 그 결과를 화면에 보여 준다.

이 흐름은 웹 서비스 대부분에서 반복된다. 로그인도 이 흐름이고, 글 작성도 이 흐름이며, 검색도 이 흐름이다. 겉으로는 기능이 달라 보여도 뼈대는 거의 같다.

그래서 초보자에게 필요한 것은 기능 하나하나를 외우는 것이 아니라, 무슨 일이 어디서 일어나는지 구분하는 힘이다. 그래야 AI가 코드를 제안했을 때 "이건 화면 쪽 수정이구나", "이건 서버 로직이구나", "이건 데이터 저장 방식이구나" 하고 판단할 수 있다.

예시 1: 글 목록 페이지는 어떻게 열릴까

조금 더 실감 나게, 우리가 앞으로 만들 웹 서비스를 떠올려 보자. 사용자가 사이트에 들어와 글 목록 페이지를 열었다고 하자.

사용자 눈에는 그냥 페이지가 열릴 뿐이지만, 내부에서는 이런 일이 일어난다. 브라우저가 서버에 "글 목록이 필요해요"라고 요청한다. 서버는 데이터베이스에 저장된 글들을 가져온다. 그리고 최신 글부터 정렬해서 브라우저에 돌려준다. 브라우저는 그 데이터를 카드나 표 형태로 화면에 그린다.

사용자는 "페이지가 잘 열리네"라고 느끼지만, 개발자의 눈에는 다음과 같은 구조가 보인다.

• 화면을 보여 주는 역할은 브라우저

• 데이터를 모아 주는 역할은 서버

• 글을 기억하는 역할은 데이터베이스

이렇게 역할을 나눠 보면 서비스가 훨씬 이해하기 쉬워진다.

예시 2: 로그인은 왜 조금 더 민감할까

로그인은 단순히 정보를 보여 주는 것보다 더 조심해야 한다. 사용자가 이메일과 비밀번호를 입력하면 브라우저는 그 정보를 서버로 보낸다. 서버는 데이터베이스에 있는 회원 정보와 비교해 맞는지 확인한다. 맞다면 "이 사용자는 인증되었다"는 표시를 남기고, 브라우저는 로그인된 상태로 화면을 바꾼다.

여기서 중요한 것은 브라우저가 혼자 로그인 여부를 결정하면 안 된다는 점이다. 만약 화면에서만 "로그인 성공"이라고 표시할 수 있다면 누구나 속일 수 있다. 그래서 로그인처럼 중요한 판단은 서버가 맡는다.

이 원리를 알면 나중에 권한 처리도 이해하기 쉽다. "내 글만 수정할 수 있게 하려면 어디서 검사해야 하지?"라는 질문에, 자연스럽게 "서버에서 확인해야겠네"라는 생각이 들기 시작한다.

예시 3: 글 작성 버튼을 누르면 무슨 일이 생길까

사용자가 제목과 내용을 입력하고 저장 버튼을 눌렀다고 해보자. 이때 브라우저는 입력값을 모은 뒤 서버에 보낸다. 서버는 내용이 비어 있는지, 로그인한 사용자인지, 저장 가능한 형식인지 확인한다. 문제가 없으면 데이터베이스에 새 글을 저장한다. 저장이 끝나면 서버는 "정상적으로 저장됐어요"라는 응답을 보낸다. 그러면 브라우저는 작성 완료 메시지를 보여 주거나 상세 페이지로 이동시킨다.

초보자가 이 흐름을 이해하지 못하면, 모든 기능이 한 화면 안에서 다 해결되는 것처럼 느껴진다. 하지만 실제로는 화면, 처리, 저장이 협력하고 있다. 이 세 구역을 구분하면 버그를 찾을 때도 훨씬 수월하다.

예를 들어 저장 버튼을 눌렀는데 반응이 없다면 이렇게 생각할 수 있다.

• 브라우저가 요청을 아예 안 보내는 걸까?

• 서버가 요청은 받았지만 에러가 난 걸까?

• 데이터베이스 저장이 실패한 걸까?

이 질문을 할 수 있다는 것 자체가 이미 큰 진전이다.

요청과 응답은 눈에 안 보이지만 서비스의 심장이다

웹 서비스를 공부하다 보면 HTTP, API, 상태 코드 같은 단어를 만나게 된다. 처음에는 무서워 보이지만, 지금은 이렇게만 이해해도 충분하다.

HTTP는 브라우저와 서버가 대화하는 기본 규칙이고, API는 서버가 "이런 요청을 받으면 이렇게 응답할게요"라고 정해 둔 창구다. 상태 코드는 요청 결과를 짧게 알려 주는 신호라고 생각하면 된다.

예를 들어 200은 대체로 성공, 404는 찾을 수 없음, 500은 서버 쪽 문제라는 뜻이다. 숫자를 외우는 것이 중요한 것이 아니라, 요청에는 결과가 따라오고 그 결과를 보고 다음 행동을 결정한다는 감각이 중요하다.

화면이 바뀌는 방법도 한 가지가 아니다

초보자는 종종 "페이지를 열면 서버가 HTML을 주는 거 아닌가요?"라고 묻는다. 맞는 말이지만, 요즘 웹 서비스는 조금 더 다양하게 움직인다. 어떤 경우에는 서버가 거의 완성된 화면을 보내고, 어떤 경우에는 브라우저가 데이터만 받아서 직접 화면을 만든다.

하지만 입문 단계에서는 이 차이를 너무 복잡하게 볼 필요는 없다. 중요한 것은 결국 같은 질문이다.

"지금 이 정보는 어디서 왔지?"

이 질문에 답할 수 있으면 된다. 서버에서 미리 만들어 보낸 화면이든, 브라우저가 데이터를 받아 그린 화면이든, 결국 브라우저·서버·데이터베이스의 협업이라는 사실은 바뀌지 않는다.

왜 이 큰 그림이 AI 시대에 더 중요할까

예전에는 개발자가 코드를 한 줄씩 직접 짜며 구조를 몸으로 익혔다. 지금은 Claude Code나 Codex 같은 도구가 꽤 많은 부분을 대신 작성해 줄 수 있다. 그래서 오히려 큰 그림이 더 중요해졌다.

AI는 빠르게 결과물을 만들어 주지만, 그 코드가 브라우저 쪽 문제를 해결하는 코드인지, 서버 쪽 규칙을 바꾸는 코드인지, 데이터베이스 구조를 바꾸는 코드인지를 사람이 구분하지 못하면 서비스는 금방 엉킨다.

예를 들어 로그인 문제가 생겼다고 하자. 이때 AI에게 "로그인이 안 돼요. 고쳐 주세요"라고만 말하면 엉뚱한 답이 나올 수 있다. 하지만 "브라우저에서 로그인 요청은 보내는 것 같은데, 서버가 인증에 실패하고 있어요"라고 말할 수 있다면 훨씬 정확한 도움을 받을 수 있다.

즉, 큰 그림을 안다는 것은 단순 교양이 아니라 AI를 더 잘 부리는 실전 능력이다.

우리가 앞으로 계속 보게 될 핵심 질문

이 장에서 배운 내용을 앞으로 계속 써먹게 된다. 기능이 늘어날수록 코드는 많아지지만, 결국 확인할 질문은 몇 가지로 모인다.

첫째, 사용자가 브라우저에서 무엇을 했는가?

둘째, 그 행동이 어떤 요청으로 서버에 전달되는가?

셋째, 서버는 무엇을 검사하고 어떤 데이터를 읽거나 저장하는가?

넷째, 그 결과가 어떻게 다시 화면에 보이는가?

이 네 가지 질문을 붙잡고 있으면, 초보자라도 웹 서비스를 훨씬 침착하게 이해할 수 있다.

이 장의 핵심 정리

웹 서비스는 복잡해 보이지만, 기본 구조는 생각보다 단순하다. 브라우저는 사용자의 행동을 받아 요청을 보내고, 서버는 그 요청을 처리하며, 데이터베이스는 필요한 정보를 기억한다. 그리고 이 셋은 요청과 응답을 주고받으며 하나의 서비스를 완성한다.

이 흐름을 이해하면 앞으로 만들 기능들이 훨씬 덜 낯설어진다. 로그인도, 글 작성도, 검색도, 배포 후 문제 확인도 결국 같은 큰 구조 안에서 일어난다. 지금 이 감각을 잡아 두면 AI가 만들어 준 코드도 덜 무섭고, 문제가 생겨도 어디를 봐야 할지 감이 생긴다.

다음 장에서는 이 큰 그림 안에서 자주 나오는 두 역할, 프론트엔드와 백엔드가 정확히 어떻게 다른지를 조금 더 또렷하게 구분해 보겠다.