웹은 어떻게 함께 움직일까? 초보 풀스택 개발자 용어 12개

Об этом предложении

안녕하세요, 카피바라 개발자입니다. 🦫🍊 프론트엔드와 백엔드를 함께 공부하다 보면 "API를 호출한다", "DB에 저장한다", "배포한다"는 말을 한꺼번에 듣게 됩니다. 오늘은 회원가입 버튼을 누르는 한 번의 행동을 따라가며, 웹서비스가 함께 움직이는 데 필요한 용어를 제 말로 정리해 보았습니다. 어떤 문제를 해결하려 했는지 처음에는 화면을 만들면 서비스가 끝난 줄 알았습니다. 그런데 사용자가 입력한 이름을 저장하고, 다음에 다시 보여 주려면 화면 밖에서 일하는 여러 친구가 필요했습니다. 이 글의 목표는 용어를 외우는 것이 아니라, 브라우저에서 버튼을 누른 뒤 화면이 다시 바뀔 때까지 흐름을 연결해 보는 것입니다. 먼저 한 장으로 보는 흐름 사용자 → 프론트엔드 → API → 백엔드 → 데이터베이스 → 백엔드 → API → 프론트엔드 예를 들어 "귤 목록 불러오기" 버튼을 누르면 프론트엔드는 서버에 요청을 보내고, 백엔드는 데이터베이스에서 목록을 찾아 응답합니다. 프론트엔드는 그 응답을 화면에 그립니다. 1. 프론트엔드와 백엔드 프론트엔드(Frontend): 사용자가 직접 보는 부분 프론트엔드는 버튼, 입력창, 글 목록처럼 브라우저에 보이는 화면입니다. HTML은 뼈대, CSS는 꾸밈, JavaScript는 클릭했을 때의 동작을 맡는다고 생각하면 이해가 빨랐습니다. 백엔드(Backend): 화면 뒤에서 규칙을 처리하는 부분 백엔드는 "로그인한 사람만 글을 쓸 수 있다" 같은 규칙을 확인하고, 필요한 데이터를 꺼내거나 저장합니다. 사용자가 직접 보지는 않지만 서비스의 중요한 판단을 담당합니다. 프론트엔드는 식당의 메뉴판과 주문대, 백엔드는 주방에 비유할 수 있습니다. 메뉴판만 예쁘다고 음식이 나오지는 않고, 주방만 있어도 손님이 주문하기 어렵습니다. 2. 클라이언트와 서버 클라이언트(Client): 요청을 시작하는 쪽 보통은 사용자의 웹 브라우저가 클라이언트입니다. 앱도 서버에 정보를 요청하면 클라이언트가 될 수 있습니다. 서버(Server): 요청을 받아 답하는 쪽 서버는 요청을 받고 규칙에 따라 처리한 뒤 결과를 돌려줍니다. 서버라고 해서 꼭 거대한 컴퓨터 한 대를 뜻하지는 않습니다. 요청을 처리하도록 실행 중인 프로그램과 그 환경을 함께 떠올리면 됩니다. 3. HTTP와 HTTPS: 웹의 대화 규칙 HTTP(HyperText Transfer Protocol)는 브라우저와 서버가 정보를 주고받는 약속입니다. 클라이언트가 보내는 말을 요청(Request) , 서버가 돌려주는 말을 응답(Response) 이라고 합니다. HTTPS는 이 HTTP 통신에 TLS 암호화를 더한 형태입니다. 로그인 정보처럼 보호가 필요한 데이터도 있으므로 실제 서비스에서는 HTTPS를 기본으로 고려해야 합니다. 자주 보는 상태 코드는 이렇게 읽었습니다. 200 OK : 요청을 정상 처리했다. 201 Created : 새 데이터를 만들었다. 400 Bad Request : 보낸 요청 형식이나 값이 맞지 않는다. 401 Unauthorized : 인증 정보가 없거나 유효하지 않다. 404 Not Found : 찾는 주소나 데이터가 없다. 500 Internal Server Error : 서버 처리 중 예상하지 못한 문제가 생겼다. 4. API: 프로그램끼리 만나는 창구 API(Application Programming Interface)는 프로그램끼리 정해진 방식으로 정보를 주고받는 창구입니다. 프론트엔드가 데이터베이스에 직접 들어가지 않고, 백엔드의 API에게 부탁하는 이유는 권한과 규칙을 한곳에서 관리하기 위해서입니다. 아래는 프론트엔드에서 목록 API를 부르는 아주 짧은 예시입니다. const response = await fetch('/api/tangerines'); const data = await response.json(); console.log(data); 첫 줄의 fetch 는 브라우저가 /api/tangerines 주소로 요청을 보내는 함수입니다. await 는 응답이 올 때까지 다음 줄을 잠시 기다리게 합니다. 둘째 줄의 json() 은 서버가 보낸 JSON 형식의 글자를 JavaScript에서 다루기 쉬운 값으로 바꿉니다. 마지막 줄은 받은 데이터를 개발자 도구 콘솔에 확인하는 용도입니다. 5. JSON: 서로 알아듣기 쉬운 데이터 포장 JSON(JavaScript Object Notation)은 데이터를 키: 값 형태로 표현하는 텍스트 형식입니다. 언어 이름에 JavaScript가 들어가지만 Java, Python 등 다른 언어에서도 널리 씁니다. { "name": "한라봉", "stock": 12 } 여기서 name 과 stock 은 데이터의 이름(키)이고, 한라봉 과 12 는 값입니다. API를 만들 때는 어떤 키를 어떤 자료형으로 주고받을지 팀과 약속하는 일이 중요합니다. 6. 데이터베이스와 DBMS 데이터베이스(Database, DB)는 서비스가 오래 보관해야 하는 데이터를 저장하는 공간입니다. 게시글, 사용자 정보, 주문 내역처럼 새로고침해도 남아야 하는 데이터가 여기에 들어갑니다. DBMS(Database Management System)는 그 데이터를 넣고 찾고 바꾸기 쉽게 해 주는 프로그램입니다. MySQL, PostgreSQL, MongoDB 같은 이름은 보통 DBMS 종류를 가리킵니다. SELECT name, stock FROM tangerines WHERE stock > 0; SELECT 는 가져올 열을 고릅니다. 여기서는 이름과 재고입니다. FROM 은 데이터를 찾을 표를 지정합니다. WHERE 는 조건을 붙입니다. 재고가 0보다 큰 귤만 찾습니다. 실제 서비스에서는 사용자의 입력을 문자열로 이어 붙여 SQL을 만들지 않는 것이 중요합니다. SQL 인젝션 같은 보안 문제가 생길 수 있으므로, 라이브러리의 파라미터 기능이나 ORM을 사용합니다. 7. 인증과 인가: 둘은 다르다 인증(Authentication) 은 "당신이 누구인가?"를 확인하는 일입니다. 로그인에서 아이디와 비밀번호, 소셜 로그인 등을 확인하는 과정이 여기에 가깝습니다. 인가(Authorization) 는 "그 일을 해도 되는가?"를 확인하는 일입니다. 로그인했다고 해서 다른 사람의 글을 수정할 수 있는 것은 아닙니다. 이 둘을 섞어 생각하면 보안 오류를 찾기 어려웠습니다. 인증은 신원 확인, 인가는 권한 확인으로 나누어 기억하면 편했습니다. 8. 쿠키와 토큰: 로그인 상태를 이어 가는 방법 HTTP는 기본적으로 각각의 요청을 따로 처리합니다. 그래서 서버는 "방금 로그인한 사람"을 저절로 기억하지 않습니다. 쿠키(Cookie)는 브라우저가 저장했다가 같은 사이트 요청에 함께 보낼 수 있는 작은 데이터입니다. 토큰(Token)은 사용자의 권한 정보를 검증할 수 있게 만든 값으로, 어디에 어떻게 보관하고 전송할지는 서비스 구조에 따라 다릅니다. 둘 다 로그인과 관련 있다고 해서 비밀번호를 그대로 저장하면 안 됩니다. HttpOnly , Secure , 만료 시간, HTTPS 같은 설정과 함께 설계해야 합니다. 9. 환경 변수: 코드 밖에 두는 설정값 환경 변수(Environment Variable)는 실행 환경에 따라 달라지는 값을 코드 밖에서 전달하는 방법입니다. 데이터베이스 주소나 비밀 키처럼 저장소에 올리면 안 되는 값에 특히 유용합니다. DATABASE_URL=postgres://example PORT=3000 DATABASE_URL 은 백엔드가 접속할 데이터베이스 위치를 담는 예시입니다. PORT 는 서버 프로그램이 요청을 기다릴 번호를 정합니다. .env 파일은 편리하지만, 비밀 값이 있다면 Git에 올리지 않도록 .gitignore 에 추가해야 합니다. 10. Git과 GitHub: 코드의 타임머신과 공유 공간 Git은 파일 변경 이력을 기록하는 버전 관리 시스템입니다. 실수한 코드를 되돌리거나, 왜 바꿨는지 확인할 때 도움이 됩니다. GitHub는 Git 저장소를 온라인에서 공유하고 협업할 수 있게 해 주는 서비스입니다. Git과 GitHub는 같은 말이 아니라는 점이 처음엔 특히 헷갈렸습니다. git status git add . git commit -m "귤 목록 API 추가" git status 는 지금 바뀐 파일 상태를 보여 줍니다. git add . 는 다음 기록에 포함할 변경을 선택합니다. 처음에는 . 대신 파일을 하나씩 확인해도 좋습니다. git commit 은 선택한 변경을 메시지와 함께 하나의 기록으로 남깁니다. 11. 배포와 CI/CD: 내 컴퓨터 밖에서도 실행하기 배포(Deployment)는 개발한 서비스를 사용자가 접속할 수 있는 환경에 올리는 일입니다. 내 컴퓨터에서는 잘 되는데 배포 환경에서 안 되는 이유는 운영체제, 설정값, 네트워크가 다를 수 있기 때문입니다. CI(Continuous Integration)는 코드가 합쳐질 때 테스트와 검사를 자주 자동 실행하는 흐름입니다. CD(Continuous Delivery 또는 Deployment)는 검증된 결과를 배포 가능한 상태로 만들거나 실제 배포까지 자동화하는 흐름을 말합니다. 팀마다 CD의 마지막 D를 다르게 쓰므로, 문서에서 범위를 확인하는 습관이 필요합니다. 12. Docker: 실행 환경을 상자에 담는 도구 Docker는 애플리케이션과 필요한 실행 환경을 컨테이너라는 단위로 묶어 실행하는 도구입니다. "내 컴퓨터에서는 되는데요?" 문제를 줄이는 데 도움이 될 수 있습니다. 다만 Docker가 모든 배포 문제를 자동으로 해결해 주지는 않습니다. 비밀 값 관리, 데이터 보관, 네트워크 설정, 이미지 크기 같은 일은 여전히 챙겨야 합니다. 초보자가 자주 헷갈릴 부분 API와 서버는 같은 말일까? API는 요청을 받는 규칙과 창구이고, 서버는 그 요청을 처리하는 프로그램 또는 환경입니다. 서버 하나가 여러 API를 제공할 수 있습니다. 데이터베이스를 프론트엔드에서 바로 호출해도 될까? 개발 중 테스트 도구가 직접 연결되는 경우는 있어도, 일반적인 웹서비스에서는 백엔드를 거치게 합니다. 데이터 접근 권한과 검증 로직을 화면에 노출하지 않기 위해서입니다. 백엔드가 있으면 프론트엔드는 필요 없을까? 아닙니다. 백엔드는 데이터를 처리하고, 프론트엔드는 그 결과를 사람이 이해하고 조작할 수 있는 화면으로 만듭니다. 둘은 역할이 다릅니다. 실제로 적용하며 느낀 한계 이 글은 용어 사이의 연결을 잡기 위한 첫 지도입니다. REST, GraphQL, 캐시, 메시지 큐, 로드 밸런서처럼 더 깊이 들어가면 새로운 선택지가 계속 나옵니다. 또한 기술 선택에는 정답이 하나가 아닙니다. 작은 개인 프로젝트와 많은 사용자가 동시에 접속하는 서비스는 필요한 구조와 비용이 다를 수 있습니다. 다음에 개선하고 싶은 점 다음 글에서는 이 용어들을 실제 미니 프로젝트에 붙여 보고 싶습니다. 로그인한 사용자가 귤 목록을 저장하고 다시 불러오는 기능을 만들면서, 요청·응답과 데이터베이스 흐름을 직접 확인해 보려고 합니다. 참고한 공식 문서 MDN: Client-server overview MDN: Overview of HTTP GitHub Docs: About Git Docker Docs: What is Docker? 아직 배워 가는 초보 개발자입니다. 내용 중 잘못 이해한 부분이나 더 좋은 방법이 있다면 한 수 가르쳐 주시면 감사하겠습니다. 😊