[비개발자 사고법 11강·종강] 웹개발 전체가 '식당 한 채'였습니다 — 프론트·백엔드·DB·배포 한 방 정리

"안 돼요, 고쳐 줘"가 무한 반복되는 진짜 이유

막히는 지점은 늘 비슷합니다. ① 분명히 저장했는데 새로고침하면 사라진다. ② 앱을 껐다 켜니 아무것도 없다. ③ 그럴듯하게 만들어 친구에게 보냈는데 친구 폰에서는 열리지 않는다. 이건 실력이 부족해서가 아니라, 지금 무엇이 어디서 막혔는지 가리킬 '지도'가 없어서 생기는 일입니다. 지도가 없으니 할 수 있는 말이 "안 돼요"밖에 없고, AI는 그 한마디를 듣고 앱 전체를 처음부터 다시 뒤집니다.

김지백 강사에 따르면, 아무리 클로드 코드나 코덱스 같은 에이전틱 코딩 도구가 코드를 잘 짜 준다고 해도 비개발자가 개발의 '흐름'을 모르면 따라갈 수가 없습니다. 반대로 말하면, 코딩을 한 줄도 배우지 않아도 웹 개발이 어떤 식으로 이루어지는지 정확하게 알게 되면 충분히 해낼 수 있다는 뜻이기도 합니다. 필요한 건 딱 두 가지예요. 어디가 잘못돼 있는지 정확하게 짚는 것, 그리고 그것을 어떤 식으로 물어보고 어떤 식으로 명령해야 하는지 아는 것. 이 두 가지만 손에 쥐면 대부분의 막힘은 풀립니다.

🍽️ 풀스택은 '식당 한 채' — 열 가지 단계 한 장 정리

풀스택이 뭐냐고 물으면 저는 늘 "식당 한 채"라고 답합니다. 손님이 앉는 홀부터, 보이지 않는 주방과 창고, 문에 걸린 자물쇠, 길가에 세운 간판까지 한 채를 통째로 갖춘 것. 지금까지 시리즈에서 하나씩 뜯어본 조각들이 사실은 전부 이 한 채의 부분이었습니다. 아래 표가 오늘 글 전체의 지도입니다.

이 중 다섯 조각은 자료실에 지난 편 심화 자료가 그대로 정리돼 있습니다 — 주방(백엔드), 알바생(API), 창고(데이터베이스), 자물쇠(권한·인증), 개업(배포). 오늘 글을 읽다가 한 조각이 흐릿하면 그 편만 다시 펼쳐 보시면 됩니다.

물론 실제 개발 현장에서 보면 이 열 단계는 한참 단순화한 설명입니다. 그래도 비개발자가 에이전틱 코딩과 손발을 맞추려면 최소한 이 열 가지는 머릿속에 있어야 합니다. 그래야 어디에 문제가 있고 어떤 지시를 새로 해야 하는지 스스로 파악할 수 있으니까요.

🦴 홀에서 벌어지는 일 — 뼈대(HTML)·옷(CSS)·생명(JavaScript)

손님이 들어와 앉는 홀이 프론트엔드입니다. 겉에 보이는 모든 화면이죠. 그 홀은 세 가지로 만들어집니다. HTML은 뼈대입니다. 제목이 여기, 버튼이 여기, 사진이 여기 — 자리를 잡는 구조예요. CSS는 옷입니다. 같은 뼈대에 어떤 색과 배치를 입히느냐에 따라 완전히 다른 가게가 됩니다. 그리고 JavaScript는 생명이자 전기입니다. 우리가 만들고 있는 웹 프로젝트에 전기를 불어넣어, 누르면 반응하고 펼쳐지고 움직이게 만드는 역할이죠.

이걸 알아야 하는 이유는 딱 하나, 지시가 달라지기 때문입니다. "남성복 티셔츠 가게에 올릴 디자인으로 예쁘게 만들어 줘"라고 하면 AI는 제멋대로 해석합니다. 대신 "헤더 섹션은 어떤 색으로 만들고, 사진이 들어가는 플렉스 박스에서는 글씨를 좀 더 두껍게 표현해 줘"처럼 콕 집어 말하면 결과가 눈에 띄게 달라져요.

자바스크립트 작업을 하다 보면 AI가 먼저 물어봅니다. "누르면 반응하는 것도 넣어 드릴까요?" 반응에 어떤 종류가 있는지 모르면 그냥 "아, 예" 하게 되고, 뭔가 멋있게 움직이긴 하는데 내 마음에는 안 드는 결과가 나옵니다. 명상과 힐링 콘셉트로 제품을 파는 쇼핑몰인데 화면이 확확 튀면 곤란하겠죠.

⏳ 깃(Git)은 타임머신 — 멘탈과 토큰을 함께 지키는 장치

건물만 올리고 간판만 걸면 장사가 되느냐, 그렇지 않습니다. 전선 하나를 잘못 설치해 두면 손님이 식사하는 도중에 불이 나가요. 짜증이 나겠죠. 건물을 지을 때는 누구나 실수를 하고 변수가 생깁니다. 웹페이지 작업도 똑같습니다. 아무리 뼈대를 세우고 옷을 입히고 생명을 불어넣어도, 되돌아갈 방법이 없으면 열심히 만든 게 이상해진 순간 그대로 끝입니다.

그래서 깃(Git)은 타임머신입니다. 게임에서 파이널 보스를 한 번에 깰 수 없으니 중간중간 저장하잖아요. 그 저장이 커밋(commit)입니다. 그리고 새로운 시도를 할 때는 브랜치(branch)를 따로 걸어서 작업하고, 결과가 마음에 들면 그 부분만 본체에 합칩니다. 그게 머지(merge)예요. 처음 공사에 들어갔던 장비를 통째로 다시 끌어올 필요 없이, 브랜치에서 만든 것만 새로 합쳐 주면 되는 겁니다.

깃을 아느냐 모르느냐는 우리 멘탈에 상당한 영향을 줍니다. 되돌릴 곳이 있으니 과감하게 시도할 수 있고, 망가진 것을 처음부터 다시 설명하며 복구시키지 않아도 되니 토큰도 크게 아낍니다. 반대로 커밋조차 해 두지 않았거나, 깃허브에도 올리지 않은 채 로컬 파일까지 잃어버리면 다음에 이어서 작업할 방법이 없습니다.

🧱 리액트는 조각 레고 — "통째로 뜯지 말고, 이 부분만"

지난 편에서 리액트를 똑똑한 국밥집 주방에 비유했습니다. 한 번 정해 둔 조리법(컴포넌트)으로 국밥을 몇 그릇이든 똑같이 말아내듯, 한 번 만든 부품을 여러 화면에 그대로 찍어내는 개념이었죠. 이번엔 조각 레고를 하나 더 얹어 보세요. 같은 카드, 같은 버튼을 레고처럼 만들어 두고 필요한 곳에 끼워 쓰는 겁니다.

개념보다 중요한 건 명령할 때 정확해진다는 점입니다. 회원가입 페이지가 마음에 안 든다고 "회원가입 페이지 고쳐 줘"라고만 하면, 아무리 높은 모델이라도 — 특히 클로드 코드를 오토 모드로 돌리고 있다면 — 제 마음대로 통째로 뜯어 버릴 수 있습니다. 잘 굴러가던 다른 화면까지 같이 흔들리는 거죠.

리액트라는 개념을 알고 있으면 이렇게 말할 수 있습니다. "여기 있는 이 부분만 고쳐 줘", "이 동일한 컴포넌트만 수정해 줘." 각 부품이 따로 있다는 걸 아니까 작업도 빨라지고, 고칠 때도 정확하게 고칠 수 있습니다. 리액트를 알아야 한다는 말은 곧 "AI에게 수술 부위를 지정할 줄 알아야 한다"는 말과 같습니다.

📋 알바생(API)과 📦 창고(데이터베이스) — 주문이 오가는 길

홀도 잘 돌아가고 주방도 잘 돌아갑니다. 그런데 손님이 주방장에게 직접 가서 주문을 넣을 수는 없죠. 중간에 알바생이 개입해서 주문을 받아 와야 합니다. 그 알바생이 API입니다. 다른 말로 메뉴판이기도 하고요. 다만 실제로 사람이 왔다 갔다 하는 게 아니라 API 주소를 만들어서 그 길로만 오가게 하는 것이라고 이해하시면 됩니다.

예를 들어 "내가 2년 동안 결제한 내역을 가져와"라고 주문하면, 창고(데이터베이스)에서 이 회원의 결제 기록을 찾아와야 하죠. 그 요청이 API 주소로 나갑니다. 주소가 제대로 먹히면 200, 잘못 요청됐으면 400번대, 서버가 터졌으면 500번대가 뜹니다. 이 상태 코드만 볼 줄 알아도 "주문이 잘못 들어갔구나"인지 "주방이 멈췄구나"인지 방향이 잡혀요.

주문 양식에도 종류가 있습니다. 지난 API 편에서 정리한 GET(겟)·POST(포스트)·PUT(풋)·PATCH(패치)·DELETE(델리트) 다섯 가지 — 가져오기·등록하기·바꾸기·부분 수정하기·지우기죠. API는 결국 정해진 양식대로, 정해진 길로만 주문을 넘기고 그 결과를 손님에게 되돌려 주는 역할입니다.

그리고 만들다 보면 AI가 반드시 물어봅니다. "데이터 저장 방식은 어떻게 할까요?" 여기서 "알아서 해 줘"라고 답하면 큰일 납니다. 새로고침 한 번에 다 날아가는 결과를 또 만나게 되거든요. "데이터베이스에 저장해", "파이어베이스 파이어스토어에 저장해", "수파베이스에 저장해"처럼 창고를 콕 집어 주셔야 합니다. 예전엔 개발자가 하던 연결 작업도 요즘은 에이전틱 코딩이 거의 다 잡아 줘요. 플레이라이트를 켜서 직접 등록하게 시켜도 되고, 막히면 화면을 스크린샷으로 찍어 "여기에 어떤 키를 넣어야 해?"라고 물어봐도 됩니다.

🔒 자물쇠(권한·인증)와 🪧 개업(배포) — 마지막 두 조각

창고를 잘 만들었는데 아무나 열 수 있으면 안 되겠죠. 식당에도 손님이 봐야 하는 자료, 직원이 봐야 하는 자료, 사장님만 다 볼 수 있는 자료가 따로 있습니다. 그게 뒤섞여 손님도 전부 볼 수 있게 되면 사고죠. 그래서 권한과 인증을 제대로 짜야 합니다. 손님의 주문 기록은 절대 뚫리면 안 되고, 비밀번호는 평문이 아니라 해시 값으로 저장해야, 창고가 털려도 진짜 비밀번호는 드러나지 않습니다.

마지막은 개업입니다. 내 컴퓨터에서만 돌아가는 로컬호스트(localhost)는 연습이고, 배포가 진짜 개업입니다. 앞에서 말한 "친구에게 카톡으로 보냈는데 안 열린다"는 증상의 정체가 바로 이것이에요. 가게는 다 지어 놨는데 아직 세상에 문을 열지 않은 상태, 간판을 안 건 상태인 거죠. 아무리 잘 만들어도 배포하지 않으면 그 가게에는 나 혼자만 들어갈 수 있습니다.

🔄 손님 한 명이 도는 한 바퀴 — 이 순환이 곧 풀스택

이제 손님 한 명을 끝까지 따라가 보겠습니다. 손님이 들어옵니다 — 우리 웹페이지에 이용자가 방문한 것이죠. 손님이 이용하는 홀이 겉으로 보이는 HTML·CSS·자바스크립트, 즉 프론트엔드입니다. 그런데 홀에서 곧장 주방과 창고로 걸어 들어갈 수는 없어요. 중간에 자물쇠, 곧 권한과 인증이 걸려 있습니다. 손님이 "대짜국밥 주세요" 하고 API 요청을 넣으면, 그 요청이 이 자물쇠를 통과해 주방(백엔드)으로 들어가고, 주방은 창고(데이터베이스)에서 재료를 꺼내 요리를 만들어 다시 손님에게 내어 줍니다.

이 한 바퀴가 끊기지 않고 계속 돌아가면 우리 웹페이지가 잘 돌아가고 있는 것입니다. 반대로 어딘가 멈췄다면, 이제는 "안 돼요" 대신 한 바퀴 중 어느 칸이 막혔는지를 짚어서 말할 수 있습니다. 아래 표를 증상별 처방전으로 쓰세요.

고칠 곳을 한 단어로 좁혀 주는 것 — 이것이 "안 돼요" 손님과 "여기를 이렇게" 사장의 차이입니다. AI가 "뒤에서 데이터 주고받는 연결에서 에러가 납니다"라고 던져도, 이제는 "홀 말고 주방 쪽이라는 거지? 창고에 값이 실제로 들어갔는지도 같이 확인해 줘"라고 받아칠 수 있어요.

🧑‍🍳 "그렇게 하면 실무에선 못 쓴다"는 지적에 대한 답

영상마다 개발자분들이 종종 댓글을 주십니다. "이렇게 허술하게 하면 실제 비즈니스에선 못 써먹는다, 나중에 난리 난다." 정말 맞는 말씀입니다. 상품을 결제받고 수천 명, 수만 명의 고객을 관리하려고 이 강의를 듣는 것이라면 솔직히 한계가 분명합니다.

다만 우리의 목표는 그게 아닙니다. 김지백 강사에 따르면 우리가 지금 만드는 건 아주 작은, 내 삶과 내 업무를 바꾸기 위한 AI입니다. 그 작은 것이 되어야 나중에 결제도 붙일 수 있고 인증도 붙일 수 있습니다. 거꾸로 데이터베이스가 어떤 건지, API 키를 어떻게 넣는 건지조차 모르면 나중에 큰 사업은 절대 못 합니다. 큰 비즈니스를 하려는 게 아니더라도, 작은 AI 서비스 하나로 내 하루를 바꿔 보려는 분이라면 이 열 단계가 정확히 그 출발선입니다.

이 시리즈가 왜 계속 "이름을 알아야 콕 집어 시킨다"고 반복했는지도 이제 한 문장으로 정리됩니다. 코드는 AI가 짜고, 우리는 사장입니다. 사장이 "음식 좀 잘 만들어 봐"라고만 하면 식당은 굴러가지 않아요. 홀·주방·창고·자물쇠·간판이라는 단어를 알아야 어디를 어떻게 고칠지 지시할 수 있습니다.