티스토리 뷰
목차
웹 퍼블리셔로 일하면서 화면만 만들면 된다고 생각했던 시절이 있었습니다. 그런데 React 프로젝트를 맡고 나서 처음으로 API를 직접 호출했을 때, 서버와 데이터베이스가 실제로 어떻게 연결되어 있는지 어렴풋이 느꼈습니다. 프론트엔드부터 백엔드, 데이터베이스까지 이어지는 IT 시스템의 전체 흐름을 제 경험을 토대로 풀어봤습니다.
프론트엔드: 화면 너머에서 벌어지는 일
저도 처음엔 프론트엔드는 그냥 화면을 예쁘게 만드는 일이라고 생각했습니다. HTML로 구조를 잡고, CSS로 스타일을 입히고, JavaScript로 버튼 클릭 같은 이벤트를 처리하는 것. 그게 전부라고 여겼습니다.
그런데 React 프로젝트에서 회원정보 조회 기능을 구현하면서 생각이 바뀌었습니다. 화면에 데이터를 보여주려면 서버에 요청을 보내야 했고, 그 응답을 받아서 다시 화면에 뿌려주는 작업이 필요했습니다. 단순히 마크업을 짜는 게 아니라, 데이터의 흐름 자체를 다루고 있다는 걸 그때 처음 체감했습니다.
프론트엔드는 크게 세 가지를 담당합니다. 사용자에게 화면을 보여주는 것, 버튼 클릭이나 입력 같은 이벤트를 처리하는 것, 그리고 서버와 데이터를 주고받는 통신입니다. 웹 환경에서는 브라우저 주소창에 URL을 입력하면 DNS(Domain Name Server)를 거쳐 IP 주소로 변환된 후 서버에 접속하게 됩니다. 여기서 DNS란 사람이 읽기 쉬운 도메인 이름을 컴퓨터가 실제로 찾아갈 수 있는 IP 주소로 바꿔주는 일종의 인터넷 전화번호부입니다.
앱이라면 조금 다릅니다. 안드로이드는 자바나 코틀린, iOS는 스위프트나 오브젝티브 C로 개발되며, 리액트 네이티브나 플러터 같은 프레임워크를 쓰면 두 플랫폼을 동시에 지원하는 앱을 만들 수 있습니다. 앱이든 웹이든 서버와의 통신에는 HTTP 또는 HTTPS 프로토콜을 씁니다. 여기서 HTTPS란 기존 HTTP에 암호화 계층을 더한 보안 통신 방식으로, 상용 서비스라면 사실상 필수입니다.
백엔드: 클라이언트 요청을 받는 서버의 구조
프론트엔드가 데이터를 요청할 때 실제로 그 요청을 받아서 처리하는 쪽이 백엔드입니다. 백엔드는 서버와 데이터베이스로 구성되는데, 이 둘의 역할을 처음에는 구분하기가 좀 모호했습니다. 그냥 "서버에서 데이터 가져온다"고만 알고 있었거든요.
조금 더 들여다보면 백엔드 서버 안에서도 역할이 나뉩니다. 웹 서버인 Apache나 Nginx는 HTML, CSS, 자바스크립트, 이미지처럼 내용이 고정된 정적 파일을 저장하고 응답하는 역할을 합니다. 반면 WAS(Web Application Server)는 동적인 데이터를 처리합니다. 여기서 WAS란 단순히 파일을 전달하는 데 그치지 않고, 로직을 직접 수행해서 데이터베이스를 조회하거나 데이터를 저장·수정·삭제하는 기능까지 담당하는 서버를 말합니다.
제가 React 프로젝트에서 API를 호출할 때마다 응답이 돌아온 것도 결국 이 WAS가 요청을 받아 처리하고 JSON 형태로 데이터를 돌려줬기 때문입니다. 서버는 항상 클라이언트의 요청을 대기(Listen)하고 있다가, 요청이 오면 해당 로직을 실행하고 응답을 전송하는 구조입니다.
서버 프로그램은 다양한 언어와 프레임워크로 개발됩니다. 대표적으로는 자바 기반의 스프링·스프링 부트, 파이썬 기반의 장고·플라스크, 자바스크립트 기반의 Node.js 등이 있으며, 이들 모두 API를 개발하고 데이터베이스와 연동하는 것이 핵심 역할입니다.
- 웹 서버(Apache, Nginx): HTML·CSS·이미지 등 정적 파일 응답
- WAS: 비즈니스 로직 실행, 데이터베이스 CRUD 처리, 동적 응답 생성
- 서버 언어/프레임워크: 스프링(자바), 장고·플라스크(파이썬), Node.js(자바스크립트)
API 통신: 프론트와 백엔드를 잇는 다리
제가 처음 API를 호출했을 때는 그냥 "서버에서 데이터 받아오는 함수" 정도로만 이해했습니다. 그런데 프로젝트를 거듭하면서 API가 프론트엔드와 백엔드 사이의 약속된 통신 규격이라는 걸 점점 실감하게 되었습니다.
API(Application Programming Interface)란 서로 다른 소프트웨어 시스템이 정해진 방식으로 데이터를 주고받을 수 있게 해주는 인터페이스입니다. 쉽게 말해 프론트엔드가 "이 형식으로 요청하면 서버는 이 형식으로 응답한다"는 계약서 같은 것입니다. 앱에서 조회 버튼을 누르면 API 호출이 발생하고, WAS가 요청을 받아 데이터베이스에 SQL 쿼리를 보냅니다. 데이터베이스가 결과를 돌려주면 WAS는 이를 JSON 또는 XML 형태로 가공해 앱에 전달하고, 앱은 받은 데이터를 화면에 표시합니다.
JSON(JavaScript Object Notation)이란 데이터를 키-값 쌍으로 표현하는 경량 데이터 포맷으로, 사람이 읽기도 쉽고 기계가 처리하기도 편해서 현재 API 응답 형식으로 가장 널리 쓰입니다. 제가 React에서 fetch나 axios로 서버 응답을 받았을 때 항상 JSON이 돌아왔던 것도 이 때문입니다.
API 통신의 보안 측면에서 보면, 상용 서비스는 거의 모두 HTTPS를 사용합니다. 출처: IANA(Internet Assigned Numbers Authority)에 따르면 HTTPS는 TLS(Transport Layer Security) 프로토콜을 통해 데이터를 암호화하여 전송합니다. 이렇게 암호화가 이뤄지기 때문에 클라이언트와 서버 사이에 주고받는 민감한 정보가 외부에 노출될 위험이 줄어듭니다.
데이터베이스: 모든 서비스의 중심
프론트엔드에서 열심히 화면을 만들고, WAS에서 로직을 처리해도 결국 데이터가 없으면 아무 의미가 없습니다. 그 데이터를 저장하고 꺼내주는 게 데이터베이스입니다. 제 경험상 데이터베이스를 직접 다루는 건 백엔드 개발자의 영역이었지만, 어떤 구조로 데이터가 저장되는지는 프론트에서도 알아야 API 응답 구조를 이해할 수 있었습니다.
데이터베이스는 데이터를 체계적으로 저장하는 소프트웨어로, MySQL이나 오라클이 대표적입니다. 데이터베이스는 여러 개의 테이블로 구성되며, 각 테이블은 엑셀 표처럼 가로(레코드)와 세로(컬럼) 구조로 데이터를 저장합니다. 예를 들어 사용자 테이블이라면 이름, 아이디, 이메일 같은 정보가 컬럼이 되고, 각 사용자의 실제 데이터가 레코드로 쌓이는 식입니다.
WAS는 이 데이터베이스를 SQL(Structured Query Language)로 조작합니다. SQL이란 데이터베이스에 데이터를 생성(Create)·읽기(Read)·수정(Update)·삭제(Delete)하는 CRUD 작업을 수행하는 언어입니다. 클라이언트가 데이터베이스에 직접 접속하지 않는 이유는 보안 때문입니다. WAS가 중간에서 검증과 처리를 담당하고, 데이터베이스는 WAS의 요청만 받아들이는 구조가 훨씬 안전합니다.
일반적으로 이 구조를 "프론트엔드 → WAS → 데이터베이스"로 단순화하는 경우가 많은데, 실제 서비스는 이보다 복잡합니다. CDN(Content Delivery Network), 로드밸런서, 캐시 서버, 인증 서버, 외부 API 연동 등 다양한 레이어가 추가됩니다. 그래서 제 생각에 이 기본 구조는 전체 흐름을 처음 이해하기 위한 개념적 모델로 보는 게 적절합니다. 실제 운영 환경에 그대로 적용되는 설계라고 보기는 어렵습니다. 출처: MDN Web Docs(Mozilla)에서도 클라이언트-서버 구조를 설명하면서 실제 서비스의 아키텍처는 이 기본 모델에서 훨씬 확장된다고 명시하고 있습니다.
자주 묻는 질문
Q. 프론트엔드 개발자도 백엔드 구조를 알아야 하나요?
A. 제 경험상 알면 확실히 도움이 됩니다. API 응답 구조를 이해해야 데이터를 화면에 제대로 그릴 수 있고, 오류가 났을 때 원인이 프론트에 있는지 서버에 있는지 빠르게 파악할 수 있습니다. 전부 깊게 파고들 필요는 없지만, 전체 흐름을 아는 것과 모르는 것은 실제 작업 속도에서 차이가 납니다.
Q. WAS와 웹 서버의 차이가 뭔가요?
A. 웹 서버(Apache, Nginx)는 이미 만들어진 HTML, 이미지 같은 정적 파일을 그대로 전달하는 역할을 합니다. WAS는 여기에 더해 로직을 실행하고, 데이터베이스에서 데이터를 꺼내 동적으로 응답을 만들어내는 역할까지 합니다. 실제 프로젝트에서는 두 역할이 하나의 서버에서 함께 돌아가는 경우도 있어서 경계가 항상 명확한 건 아닙니다.
Q. API 응답이 왜 항상 JSON 형식인가요?
A. 의무는 아닌데 사실상 표준처럼 굳어졌습니다. JSON은 구조가 단순하고 자바스크립트와 자연스럽게 연동되며, 용량도 가볍습니다. 예전에는 XML도 많이 썼지만 JSON이 더 읽기 편하고 파싱도 빠르다 보니 현재는 대부분 JSON으로 주고받는 편입니다.
Q. 클라이언트가 데이터베이스에 직접 접속하면 안 되는 이유가 뭔가요?
A. 보안 문제가 가장 큽니다. 클라이언트가 데이터베이스에 직접 접근할 수 있다면 접속 정보가 외부에 노출될 위험이 있고, 악의적인 SQL 쿼리를 직접 실행할 수도 있습니다. WAS가 중간에서 요청을 검증하고 필터링하는 역할을 해야 데이터를 안전하게 지킬 수 있습니다.
결론
웹 퍼블리셔 시절에는 화면을 만드는 것 자체가 전부였습니다. 그런데 직접 겪어보니 프론트엔드가 API를 통해 서버와 통신하고, WAS가 데이터베이스에 SQL로 요청을 보내고, 그 응답이 JSON으로 다시 화면에 표시되는 이 흐름 전체가 하나의 시스템으로 연결되어 있다는 걸 나중에야 실감했습니다.
기본 구조를 이해하는 것과 모르는 것은 실제 개발 과정에서 꽤 큰 차이를 만들어냅니다. 다만 이 구조는 시작점이지, 실제 서비스의 전부가 아닙니다. CDN, 로드밸런서, 캐시 서버 같은 요소들이 추가될수록 구조는 복잡해집니다. 이 흐름을 먼저 확실히 이해한 다음, 각 요소를 하나씩 확장해나가는 방식으로 접근하는 게 저는 가장 효율적이라고 생각합니다.