중학생 눈높이의 앱 기획 교안. 화면 뒤에서 앱이 어떻게 굴러가는지를 '식당' 비유 하나로 끝까지 따라갑니다. 목표는 기술 암기가 아니라 겁먹지 않을 큰 그림 — architecture(IT 입문) 1·5·7장과 이어집니다. 강사가 읽고 그대로 말할 수 있는 설명 산문을 슬라이드마다 넣었습니다.
이 장은 용어를 나열한 게 아니라 한 질문을 식당 비유 하나로 끝까지 따라가는 논증이다. 본론에 들어가기 전, 우리가 지나갈 전체 길을 먼저 펼쳐 둔다. 통념(앱=화면 하나)을 깨고, 앱을 홀·주방·창고로 나눈 뒤, 이 셋이 요청·응답으로 협력하는 그림까지 간다.
학생들에게 "앱이 뭐냐"고 물으면 거의 다 눈에 보이는 화면을 떠올린다. 버튼을 누르면 화면이 알아서 다 처리한다고 여기는 것이다. 하지만 화면은 식당의 홀일 뿐 — 그 뒤에는 보이지 않는 주방과 창고가 따로 있다. 이 착각을 깨는 데서 이 강의가 시작된다.
식당에 가면 손님은 홀(테이블·메뉴판)만 본다. 하지만 음식은 안 보이는 주방에서 만들어지고, 재료는 창고에 쌓여 있다. 홀만 보고 "식당 = 테이블"이라 하면, 막상 음식이 늦을 때 어디가 막혔는지 짚을 수 없다.
이 강의가 증명하려는 한 문장은 이것이다 — 앱은 겉과 속이 따로 있고, '식당'처럼 세 부분이 협력해 굴러간다. 손님이 보는 홀은 화면(프런트엔드), 안 보이는 곳에서 일하는 주방은 서버(백엔드), 재료를 쌓아 둔 창고는 데이터베이스(DB)다. 셋 중 하나만 빠져도 식당은 돌아가지 않는다.
앞으로 세 슬라이드에 걸쳐 이 셋을 하나씩 열어 본다. 핵심은 "어디서 무슨 일이 일어나는가"를 부분별로 나눠 말할 줄 아는 것 — 그게 기획자의 첫 번째 능력이다.
프런트엔드는 식당의 홀이다. 버튼·글씨·이미지·색·간격처럼 사용자가 눈으로 보고 손으로 만지는 모든 것이 여기 속한다. AWS는 프런트엔드를 "사용자가 보는 것 — 버튼·체크박스·그래픽·글자 같은 시각 요소"라고 정의한다. 그래서 '버튼을 어디에 둘까, 색을 무엇으로 할까'는 전부 프런트엔드의 몫이다.
홀은 음식을 만들지 못하고, 재료를 보관하지 못한다. 마찬가지로 화면은 비밀번호가 진짜 맞는지 확인하거나, 내 글을 영구히 저장하지 못한다. 그건 주방과 창고의 일이다.
화면(홀)이 받은 주문은 안 보이는 주방으로 넘어간다. 주방(백엔드)은 계산·검사·결정을 맡는 서버다. MDN은 서버가 하는 일을 "요청에 응답해 어떤 내용을 돌려줄지 고르고, 보낸 데이터를 검증하며, 데이터베이스를 써서 정보를 저장·검색하는 것"이라고 설명한다. 그리고 그 정보가 쌓이는 곳이 바로 창고(DB)다.
안 보이는 곳에서 일을 처리한다. 예: 로그인할 때 '비밀번호가 맞나' 확인하는 건 화면이 아니라 서버가 한다. 퀴즈의 정답 채점도 주방의 몫이다.
정보를 보관하는 곳. 가입 정보·작성한 글·점수를 저장해 둔다. 앱을 껐다 켜도 내 글이 남아 있는 건 화면이 아니라 DB에 저장돼 있어서다.
홀·주방·창고를 잇는 끈이 바로 요청(request)과 응답(response)이다. MDN은 웹의 동작을 "클라이언트(화면)에서 서버로 요청이 가고, 서버에서 클라이언트로 응답이 온다"고 그림으로 설명한다. 식당으로 옮기면, 버튼을 누르는 건 주문서를 주방에 넣는 일이고, 결과가 화면에 뜨는 건 요리가 나오는 일이다.
"AI를 모든 화면에 넣으면 더 좋지 않냐"는 생각은 절반만 맞다. AI는 주방에 새로 들어온 특별 요리사다 — 글·그림을 척척 만들어 주지만, 한 접시 만들 때마다(토큰만큼) 재료비가 든다. 일반 메뉴는 일반 조리대로 충분한데, 모든 메뉴를 특별 요리사에게 시키면 식당이 적자가 난다.
지금까지의 논증이 도착한 곳은 단순하다 — 기획자가 코딩까지 할 필요는 없다. 다만 '겉과 속이 따로 있다'는 식당 그림을 알면, AI나 개발자에게 무엇을 부탁할지가 또렷해진다. "화면을 고쳐 달라"와 "저장을 고쳐 달라"는 서로 다른 부탁이기 때문이다. 큰 그림이 곧 또렷한 요청서다.
| 증상 / 하고 싶은 말 | 어디 일인가? | 어떻게 부탁? |
|---|---|---|
| "버튼이 안 보여요 / 색을 바꾸고 싶어요" | 홀 = 프런트엔드 | "화면을 고쳐 주세요" |
| "채점이 틀려요 / 로그인 검사가 이상해요" | 주방 = 백엔드 | "처리(서버)를 고쳐 주세요" |
| "껐다 켜니 내 글이 사라졌어요" | 창고 = DB | "저장(DB)을 고쳐 주세요" |
| "AI 답이 너무 느려요 / 비싸요" | 특별 요리사 = AI | "AI를 어디에 쓸지 다시 정하자" |
이 장은 용어를 모은 게 아니라, 하나의 질문을 식당 비유로 끝까지 따라간 추론이었다. 출발점은 "앱=화면 하나"라는 통념이었고, 도착점은 "앱은 홀·주방·창고가 요청·응답으로 협력하는 식당"이라는 그림이었다. 그 사이를 AWS·MDN 같은 1차 자료가 각자의 역할로 이어 주었다.
'프런트/백엔드/DB'는 말로만 들으면 끝까지 추상적이다. 그래서 이 장은 몸으로 한 번 굴려 보는 것으로 닫는다 — 식당 역할극으로 흐름을 느끼고, 한 장 지도로 내 앱을 직접 나눠 본다. 목표는 다시 한 번, 기술 암기가 아니라 겁먹지 않을 큰 그림이다.
한 명은 홀(화면: "주문 받습니다"), 한 명은 주방(서버: 계산·조리), 한 명은 창고(DB: 재료 보관).
A4를 세 칸으로 나눠 홀(화면) / 주방(서버) / 창고(DB) 라벨을 붙이고, 내 앱 기능 3개가 각각 어느 칸 일인지 화살표로 잇는다.