프레임워크, API, PRD — 무엇으로 만들고 어떻게 지시할까

한 줄 요약

변수·함수·객체부터 프레임워크, 프론트엔드와 백엔드, API와 목업 데이터, PRD까지 훑고 페어프로그래밍으로 게임 두 개를 만들었다.

1. 오늘 배운 것

용어를 늘어놓으면 따로따로처럼 보이지만, 실은 한 줄기로 이어진다. 아래 순서대로 읽으면 앞의 내용이 뒤의 전제가 된다.

순서	무엇에 답하는가
변수 · 함수 · 객체	코드는 무엇으로 이루어지는가
프레임워크	무엇으로 만들 것인가
프론트엔드 · 백엔드	그 코드는 어디서 실행되는가
API	나뉜 둘은 어떻게 대화하는가
목업 데이터	한쪽이 아직 없으면 어떻게 하는가
PRD	그래서 무엇을 만들 것인가

1-1. 코드의 기본 단위 — 변수, 함수, 객체

변수 — 메모리에 저장된 값을 가리키는 이름. 값 자체가 아니라 이름표에 가깝다.
함수 — 입력을 받아 작업을 수행하고, 필요하면 값을 돌려주는 코드의 단위.
객체(오브젝트) — 변수 + 함수. 흩어진 값과 동작을 하나의 덩어리로 묶은 것.

객체가 왜 필요한지는 자동차로 생각하면 바로 잡힌다. 속도와 색은 상태(변수), 가속하고 멈추는 것은 행동(함수)이다. 따로 관리하면 자동차가 열 대일 때 변수 이름이 스무 개로 늘어난다. 하나로 묶으면 “이 자동차의 속도”로 다룰 수 있다.

1-2. 프레임워크란?

이미 만들어진 골격과 규칙의 묶음. 처음부터 자유롭게 짜는 대신, 정해진 방식에 맞춰 내용을 채워 넣는다.

HTML만으로 만들면 왜 힘든가. 오늘 이 부분이 제일 납득이 갔다.

페이지마다 반복되는 구조(머리말, 메뉴, 목록 항목)를 매번 복사해 붙여야 한다
데이터가 바뀌면 화면을 어디까지 고쳐야 하는지 직접 챙겨야 한다
규모가 커지면 무엇이 무엇에 영향을 주는지 파악이 안 된다

프레임워크는 화면을 조각 단위로 나눠 재사용하게 해주고, 데이터가 바뀌면 화면이 따라 바뀌도록 구조를 미리 정해둔다. 자유를 조금 내주고 그 대가로 질서를 받는 거래다.

어떤 것을 고를까. 정답이 하나 있는 게 아니라 기준이 있었다.

만들려는 것의 성격에 맞는가
자료와 커뮤니티가 충분한가 — 막혔을 때 검색해서 답이 나오는가
AI가 잘 아는 것인가 — 바이브 코딩에서는 이게 꽤 큰 기준이다. 사례가 많은 프레임워크일수록 AI가 만들어주는 코드도 안정적이다
배우는 데 드는 시간이 감당되는가

1-3. 프론트엔드와 백엔드 — 어디서 실행되는가

같은 서비스인데도 코드가 두 곳에서 나뉘어 돌아간다. 기준은 실행되는 위치다.

구분	어디서 실행되나	무엇을 맡나
프론트엔드	사용자의 브라우저	화면, 클릭과 입력에 대한 반응
백엔드	서버	데이터 저장, 로그인 처리, 남에게 보이면 안 되는 로직

왜 나누는지가 중요했다. 프론트엔드 코드는 사용자의 브라우저로 내려가기 때문에 누구나 들여다볼 수 있다. 그래서 비밀번호 확인이나 중요한 계산을 프론트엔드에 두면 안 된다. 그건 서버에서 해야 한다. 또 데이터가 서버 한 곳에 모여 있어야 여러 사용자가 같은 정보를 볼 수 있다.

프레임워크가 담당 영역별로 나뉘는 것도 이 구분을 따른다. 화면을 만드는 프론트엔드 프레임워크, 스타일을 담당하는 CSS 프레임워크, 서버 쪽을 담당하는 백엔드 프레임워크.

1-4. API — 나뉜 둘을 잇는 창구

API는 서로 다른 프로그램(또는 서비스)이 정해진 규칙에 따라 데이터를 주고받게 해주는 약속된 창구다.

레스토랑으로 보면 — 손님은 주방에 직접 들어가 요리를 만들 수 없다. 웨이터에게 “이 메뉴 주세요”라고 주문하면 웨이터가 주방에 전달하고 완성된 요리를 가져온다. 손님은 주방이 어떻게 돌아가는지 몰라도 되고, 정해진 메뉴판대로 주문만 하면 된다. 그 메뉴판이 API 문서다.

날씨 앱 예시 — 날씨 앱을 만든 회사는 전 세계 기상 데이터를 직접 측정하지 않는다. 기상청 API에 “서울, 오늘 날씨”를 요청하면 “맑음, 25도”가 돌아온다. 앱은 받은 데이터를 화면에 보기 좋게 보여주면 된다.

이때 데이터가 오고 가는 형식 중 하나가 JSON이다. 예전에는 XML을 많이 썼지만 지금은 JSON이 더 널리 쓰인다.

여기서 짚어둘 것은, API가 단순한 통로가 아니라 “무엇을 어떤 형태로 주고받을지 정한 약속”이라는 점이다. 이 약속이 다음 항목의 기준이 된다.

1-5. 목업 데이터 — 백엔드가 아직 없을 때

실제로는 프론트엔드와 백엔드가 동시에 만들어진다. 그래서 화면을 만들어야 하는데 받아올 데이터가 아직 없는 상황이 생긴다. 이때 쓰는 것이 목업 데이터, 즉 임시로 만든 가짜 데이터다.

핵심은 아무 형태로나 만들면 안 된다는 것이다. API가 이미 “무엇을 어떤 형태로 주고받는다”를 정해 놓았으니, 목업 데이터도 그 형태에 그대로 맞춰서 만든다.

그러면 나중에 백엔드가 완성됐을 때 데이터를 주는 쪽만 갈아끼우면 되고, 화면 코드는 고치지 않아도 된다. 반대로 형태를 임의로 만들어 두면, 실제 API를 붙이는 순간 화면을 전부 다시 손봐야 한다.

1-6. PRD — 그래서 무엇을 만들 것인가

PRD(Product Requirements Document) 는 무엇을 왜 만드는지 적어둔 문서다. 담기는 것은 대체로 이렇다.

항목	적는 것
목적	왜 만드는가, 어떤 문제를 푸는가
사용자	누가 쓰는가
핵심 기능	반드시 되어야 하는 것
화면과 흐름	사용자가 무엇을 보고 어떤 순서로 움직이는가
제외 범위	이번에는 만들지 않는 것
완료 조건	무엇이 되면 끝인가

AI와 함께 쓸 때가 특히 달랐다. 처음부터 완벽하게 쓰지 않아도 된다. 초안을 던지고 LLM에게 질문을 받으면서 빈칸을 채우는 방식이 훨씬 빨랐다.

구체화의 핵심은 모호한 말을 판단 가능한 말로 바꾸는 것이다.

“예쁘게” → 어떤 색, 어떤 배치, 어떤 화면 크기에서
“간단하게” → 화면 몇 개, 기능 몇 개
“게임 만들어줘” → 규칙, 승리 조건, 실패 조건, 점수 계산

그리고 제외 범위를 적는 게 의외로 중요했다. 안 적으면 AI가 요청하지 않은 기능까지 알아서 늘려버린다.

왜 필요한가

바이브 코딩에서 내가 하는 일은 코드를 타이핑하는 게 아니었다. 무엇을 만들지 정의하고(PRD), 무엇으로 만들지 고르고(프레임워크), 나온 결과를 검토하는 것이다. 오늘 배운 것들은 그 세 가지를 하기 위한 최소 어휘였다.

2. 실습 / 코드 — 페어프로그래밍

진행 방식

2인 1조로 드라이버(키보드를 잡고 직접 작업)와 네비게이터(요청하고 검토)로 나뉘어, 10분마다 역할을 바꿨다.

네비게이터가 드라이버에게 만들 게임을 요청한다
드라이버가 PRD를 작성하고, LLM과 대화하며 구체화한다
그 사이 네비게이터에게 구체적인 내용을 피드백받는다
구체화된 PRD로 LLM에게 제작을 의뢰한다
완성작을 네비게이터가 확인하고 수정 사항을 낸다
부족한 부분과 위험한 부분을 반영해 마무리한다

만든 것은 카드 뒤집기와 벽돌깨기 두 개다.

PRD 구체화 — 실제로 이런 차이였다

처음 요청은 이렇게 짧았다.

카드 뒤집기 게임 만들어줘

이대로 넘기면 AI가 알아서 다 정하기 때문에, 내가 원한 것과 다른 게 나온다. 대화를 거쳐 구체화한 뒤에는 이런 모양이 됐다.

[목적]
같은 그림 짝을 기억해 맞추는 간단한 웹 게임

[핵심 규칙]
- 4x4, 총 16장 (8쌍)
- 시작 시 모두 뒷면. 클릭하면 앞면으로 뒤집힌다
- 두 장을 뒤집어 같으면 계속 열린 채로 둔다
- 다르면 1초 후 다시 뒷면으로 돌아간다
- 한 번에 세 장 이상 뒤집히지 않게 한다

[완료 조건]
- 8쌍을 모두 맞추면 시도 횟수와 함께 완료 메시지 표시

[화면]
- 카드 격자 1개, 상단에 시도 횟수, 하단에 다시 시작 버튼

[이번에 만들지 않는 것]
- 점수 순위표, 난이도 선택, 소리

한 번에 세 장 이상 뒤집히지 않게 같은 조건은 처음에 전혀 생각하지 못했던 것이다. LLM이 되묻는 과정에서, 그리고 네비게이터가 검토하면서 나왔다.

검토 단계에서 나온 것

네비게이터의 확인에서 두 종류의 수정 사항이 나왔다.

보완 — 빠진 조건, 어색한 동작. 위의 “세 장 뒤집힘” 같은 예외 상황이 대부분이었다
보안 — 안전과 관련된 지적

혼자 만들면 “돌아가니까 됐다”에서 멈추는데, 검토하는 사람이 따로 있으니 그 다음이 나왔다. 코드를 짤 줄 몰라도 요청·피드백·검토는 할 수 있다는 것이 이 방식의 핵심으로 느껴졌다.

3. 그림 / 스크린샷

변수는 값을 가리키는 이름, 함수는 입력을 받아 처리하는 단위, 객체는 상태와 행동을 묶은 것 — 그림 1. 변수 + 함수 = 객체

API를 레스토랑의 웨이터에 비유한 그림과 날씨 앱의 실제 요청 응답 대응, JSON 응답 예시 — 그림 2. API — 주방에 직접 들어가지 않고 웨이터에게 주문한다

백엔드가 없을 때 API 규약에 맞춘 목업 데이터를 쓰고 나중에 실제 백엔드로 갈아끼우는 구조 — 그림 3. 목업 데이터는 API 규약에 맞춰 만든다

페어프로그래밍에서 요청부터 PRD 구체화, 제작, 검토, 수정까지의 흐름 — 그림 4. 오늘의 페어프로그래밍 흐름

4. 막혔던 점과 해결

막힌 지점	궁금했던 이유	정리한 답
프레임워크는 여러 개를 동시에 쓸 수 있는가?	각각 장점이 있으니 섞으면 더 좋은 게 아닌가 싶었다	쓸 수는 있지만 같은 역할끼리는 겹칠 이유가 없다. 차를 만들 때 차체를 두 개 쓰지 않는 것과 같다. 다만 역할이 다르면(화면 + 스타일) 함께 쓰는 게 오히려 일반적이다
함수와 변수는 항상 같이 쓰이는가?	수업에서 “짝꿍처럼 함께 나온다”고 들었다	변수는 함수 없이도 존재할 수 있다. 값을 담아두는 것만으로 성립한다. 다만 쓸모 있는 프로그램은 값을 담는 일(변수)과 그 값으로 무언가 하는 일(함수)이 거의 항상 함께 필요하다. 문법상 필수가 아니라 실질적으로 짝을 이룬다는 뜻으로 정리했다
목업 데이터는 어디서 어떻게 정리하는가?	실제 데이터가 없는 상태에서 화면을 먼저 만들 때 기준이 없었다	API 규약이 기준이다. API가 프론트엔드와 백엔드 사이에서 무엇을 어떤 형태로 주고받을지 정해 놓았으니, 목업 데이터도 그 형태에 그대로 맞춘다. 그래야 나중에 실제 API로 갈아끼울 때 화면을 고치지 않아도 된다 (그림 3)
API는 허가 없이 써도 되는가?	남의 서버에 요청을 보내는 일이라 걸렸다	공개된 API는 누구나 쓸 수 있다. 다만 증권이나 은행처럼 민감한 정보를 다루는 API는 승인을 받은 사람만 사용할 수 있다

5. 스스로 확인하기

변수를 “값”이 아니라 다른 말로 설명할 수 있는가?
객체가 왜 필요한지 예를 들어 말할 수 있는가?
HTML만으로 만들 때의 불편함을 두 가지 이상 말할 수 있는가?
프레임워크를 고르는 기준을 세 가지 댈 수 있는가?
비밀번호 확인을 프론트엔드에 두면 안 되는 이유를 설명할 수 있는가?
API를 비유 없이 설명할 수 있는가?
목업 데이터를 무엇에 맞춰 만들어야 하는지, 왜 그런지 말할 수 있는가?
PRD에 반드시 들어가야 할 항목을 문서 없이 나열할 수 있는가?
모호한 요청 한 줄을 판단 가능한 조건으로 바꿔 쓸 수 있는가?

6. 더 알아볼 것

프레임워크의 종류와 장단점 — 이름과 특징을 실제로 비교해 보기
라이브러리와 프레임워크의 차이
목업 데이터로 만든 화면에 실제 API를 붙여 갈아끼워 보기
AI와 PRD를 쓸 때 주의할 점 — 어디까지 맡기고 어디부터 내가 정해야 하는가
공개 API를 하나 골라 문서를 읽고 실제로 요청해 보기
오늘 나온 용어들 다시 짚기 (객체, 프레임워크, API, JSON, 목업 데이터, PRD)