개발 회의에 처음 앉으면 분명 한국말인데 못 알아듣는 순간이 온다. 그런데 그 자리에서 오가는 용어는 짝으로 붙어 다니는 것까지 묶으면 열다섯 개 정도고, 걸리는 건 대개 비슷하게 들려서 바꿔 쓰기 쉬운 몇 쌍이다. “RFP 언제 나와요?” “POC부터 돌려 보죠.” “PRD는 누가 씁니까.” 이런 말들이다.
여기서 초보가 오해하는 게 하나 있다. 이 말들을 알아야 하는 이유가 고개를 끄덕이기 위해서라고 생각하는 것이다. 실제 이유는 다른 데 있다. AI에게 일을 시키는 사람에게 이 단어들은 곧 작업 지시의 단위다.
“이런 거 만들어 줘”와 “이 기능의 PRD를 써 줘”는 같은 요청이 아니다. 뒤쪽은 AI가 무슨 형식으로, 어떤 항목을 채워서 답해야 하는지까지 정해 준다. 그래서 결과물의 모양이 달라진다.
용어를 왜 외워야 하나
회의에서 못 알아듣는 게 문제가 아니라, 원하는 것을 부를 이름이 없으면 AI에게도 흐릿하게 시키게 되기 때문이다. 이 블로그 오른쪽 사이드바에 있는 돌림판을 만들 때가 그랬다. 처음에는 “글 하나 랜덤으로 뽑아 주는 거”라고만 말했고, 나온 결과도 그만큼 흐릿했다. 크기, 색, 도는 시간, 멈춘 뒤에 보여 줄 것까지 적어 준 뒤에야 쓸 만한 게 나왔다. 그 적어 준 문서가 업계에서 PRD라고 부르는 것의 축소판이었다.
그 과정을 순서대로 풀어 놓은 글은 따로 있다. 바이브코딩으로 웹 게임 만들기에 기획부터 배포까지 일곱 단계로 적어 뒀으니, 순서가 궁금하면 그쪽을 보면 된다. 이 글은 순서가 아니라 단어를 다룬다. 특히 비슷하게 들려서 바꿔 쓰기 쉬운 짝들을.
POC, 프로토타입, MVP는 무엇이 다른가
확인하려는 대상이 다르다. POC는 기술이 되는지, 프로토타입은 쓰는 사람이 이해하는지, MVP는 사람들이 실제로 쓰는지를 본다. 회의에서 이 셋이 제일 자주 뒤섞인다.
POC(Proof of Concept, 개념검증)는 “이게 기술적으로 가능한가”만 확인하는 실험이다. 화면이 못생겨도 된다. 데이터가 열 개뿐이어도 된다. 되는지 안 되는지만 알면 목적을 다한 것이라 대개 그대로 버린다.
프로토타입은 만져 보게 하는 가짜다. 버튼을 누르면 다음 화면으로 넘어가지만, 뒤에서 진짜 일은 아무것도 일어나지 않는다. 안을 채우기 전에 “이 흐름이 맞나”를 물어보려고 만든다.
MVP(Minimum Viable Product, 최소기능제품)는 앞의 둘과 성격이 아예 다르다. 실제 사용자 앞에 내놓는 진짜 제품이고, 다만 기능이 최소다. 이 말을 널리 퍼뜨린 The Lean Startup은 MVP를 “배움을 최대한 빨리 시작하기 위한” 최소판이라고 설명한다. 핵심은 작다는 게 아니라 배우려고 내놓는다는 데 있다.
경계가 회사마다 조금씩 다르다는 점도 알아 두면 좋다. 어디서는 클릭되는 시안을 MVP라 부르고, 어디서는 결제까지 붙어야 MVP라고 한다. 회의에서 이 단어가 나오면 뜻을 짐작하지 말고 한 번 물어보는 게 낫다. 이번엔 어디까지를 MVP로 보는지.
AI에게 시킬 때는 이렇게 갈라서 말하면 결과가 달라진다.
POC 요청: “이게 기술적으로 되는지만 확인할 최소 코드를 짜 줘. 화면은 안 꾸며도 되고, 데이터는 임시로 넣어.”
MVP 요청: “여기서 없어도 되는 기능을 빼고 MVP 범위를 정해 줘. 뺀 것마다 왜 뺐는지 한 줄로 적어 줘.”
PRD랑 기능명세서는 왜 따로 있나
PRD는 무엇을 왜 만드는지를, 기능명세서는 그래서 버튼이 정확히 어떻게 움직이는지를 적는다. 앞쪽이 없으면 방향을 잃고, 뒤쪽이 없으면 매번 다시 물어야 한다.
PRD(Product Requirements Document, 제품요구사항문서)의 정의는 도구 회사들이 내놓은 템플릿을 보면 분명하다. 아틀라시안의 PRD 템플릿은 PRD를 “제품이나 기능의 요구사항, 곧 목적과 기능과 동작을 정의하는 안내서”라고 적어 두고, 채울 칸을 다섯 단계로 준다. 기본 정보와 역할, 목표와 성공 지표, 가정과 대안, 참고 자료, 그리고 열린 질문과 스코프 크리프.
마지막 칸이 재미있다. 스코프 크리프(scope creep)는 처음 정한 범위 밖의 요청이 슬금슬금 들어와 일이 불어나는 현상인데, 이게 회의 유행어가 아니라 요구사항 문서의 정식 항목으로 들어가 있다. 그만큼 자주 일어난다는 뜻이다.
기능명세서는 그다음이다. “로그인 버튼을 누른다”까지가 PRD라면, 기능명세서에는 아이디가 비었을 때 뭐라고 보여 줄지, 비밀번호를 다섯 번 틀리면 어떻게 할지가 들어간다. 스펙이라고 줄여 부르는 그 문서다.
PRD 요청: “이 기능의 PRD를 써 줘. 목적, 쓸 사람, 화면별 동작, 다 됐다고 볼 기준 순서로.”
명세 요청: “위 PRD를 기능명세서로 바꿔 줘. 버튼마다 눌렀을 때 무슨 일이 일어나는지, 값이 비었거나 틀렸을 때 화면에 뭐라고 뜨는지까지 적어.”
이 문서들을 대신 써 주는 도구도 있다. 매니패스트를 정리한 글에서 다뤘는데, 대화로 시작해 PRD와 기능명세서, 유저플로우, 와이어프레임까지 뽑아 준다. 와이어프레임은 색과 그림을 다 빼고 배치만 그린 화면 골격이고, 유저플로우는 사용자가 밟는 화면 순서다. 둘 다 회의에서 종이에 대충 그리면서 나오는 말이라 이름만 알면 충분하다.
RFP는 언제 듣게 되나
돈을 주고 남에게 개발을 맡기거나, 반대로 맡는 자리에서 듣는다. 혼자 만들 때는 안 나온다.
RFP(Request for Proposal, 제안요청서)는 발주하는 쪽이 “이런 걸 만들어 주세요”를 문서로 정리해 뿌리는 것이다. 만들 것, 지켜야 할 조건, 일정, 예산 범위, 어떤 기준으로 업체를 고를지가 들어간다. 그걸 받은 업체가 답으로 내는 게 제안서와 견적이다. 공공기관 일이라면 이 흐름을 눈으로 볼 수도 있다. 공고가 나라장터에 뜨고, 첨부파일에 제안요청서가 붙는다.
초보에게 이 단어가 중요한 이유는 따로 있다. RFP를 쓰는 연습이 곧 요구사항을 쓰는 연습이다. 남에게 맡길 만큼 분명하게 적을 수 있으면, AI에게 시키는 말도 분명해진다. 실제로 두 문서는 뼈대가 닮았다. 무엇을, 왜, 어디까지, 언제까지, 무엇으로 다 됐다고 볼지.
API랑 SDK는 어디까지 다른가
API는 창구고, SDK는 그 창구를 쓰기 편하게 묶어 놓은 꾸러미다. 같은 것을 가리킬 때도 있어서 헷갈리기 쉽다.
MDN 용어집은 API를 사람이 쓰는 화면과 대비해서 설명한다. 프로그램 안에 있는 기능과 규칙의 묶음이고, 사람이 아니라 다른 소프트웨어가 그걸 통해 접속한다는 것이다. 그리고 API를 “제공하는 쪽과 쓰는 쪽 사이의 계약”으로 봐도 된다고 적어 뒀다. 이 비유가 회의에서 제일 쓸모 있다. 계약이니까 정해진 형식으로 요청해야 하고, 답도 정해진 형식으로 온다.
워드프레스에도 REST API가 있다. 공식 핸드북에 주소와 형식이 정리돼 있는데, 글 목록을 프로그램이 받아 가는 창구다. 사이드바 돌림판이 최신 글 여덟 개를 받아 칸을 채우는 것도 그 창구를 쓴 결과다. 사람이 화면을 보고 제목을 옮겨 적는 게 아니라, 프로그램이 목록을 받아 온다.
SDK(Software Development Kit)는 그 위에 얹히는 것이다. 결제 회사의 API를 직접 부르려면 주소와 형식을 다 알아야 하지만, SDK를 깔면 함수 한 줄로 끝난다. 안에서 결국 API를 부른다. 회의에서 “SDK 붙이면 돼요”라고 하면 남이 만든 지름길을 쓰겠다는 뜻이고, “API 직접 붙일게요”라고 하면 그 지름길 없이 규격대로 하겠다는 뜻이다.
백엔드와 프론트엔드도 여기서 같이 정리된다. 눈에 보이는 화면 쪽이 프론트엔드, 데이터를 준비해 넘겨주는 안 보이는 쪽이 백엔드다. API는 둘 사이에서 말이 오가는 지점이다.
“내 컴퓨터에선 됐는데”는 왜 배포에서 터지나
내 컴퓨터와 실제 서버가 같은 환경이 아니기 때문이다. 그래서 스테이징과 프로덕션이라는 말이 따로 있다.
프로덕션(운영 환경)은 손님이 오는 곳이다. 스테이징은 그 앞의 연습장으로, 실제 서버와 최대한 비슷하게 맞춰 두고 먼저 올려 보는 자리다. 배포(디플로이)는 만든 것을 그 위에 올리는 일이고, 잘못 올렸을 때 이전 상태로 되돌리는 게 롤백이다.
이 블로그에서 실제로 겪은 일이 있다. 글 주소를 예쁜 형태로 바꿨더니 모든 글이 404를 냈다. 흔한 원인은 주소 설정 화면을 다시 방문해 규칙을 새로 쓰게 하면 풀린다. 우리 경우는 그게 아니었다. 아파치가 설정 파일 자체를 무시하도록 되어 있어서, 워드프레스 안에서 뭘 해도 안 됐다. 서버 설정을 고쳐야 풀렸다. 고유주소를 정리한 글에 두 원인을 나눠 적어 뒀다.
여기서 배울 건 하나다. 증상이 같아도 원인이 다르면 해법이 다르다. 그래서 AI에게도 증상만 던지면 안 된다.
배포 문제 요청: “내 컴퓨터에선 되는데 올린 주소에서는 안 돼. 환경 차이로 생길 수 있는 원인부터 순서대로 짚어 줘. 어떤 걸 먼저 확인해야 하는지도.”
버그를 어떻게 말하면 빨리 고쳐지나
언제, 무엇을 했을 때, 무슨 일이 일어났는지를 순서대로 적으면 된다. 이 세 줄을 재현조건이라고 부르고, 개발자가 버그리포트에서 제일 먼저 찾는 부분이다.
“안 돼요”는 정보가 없다. “버튼을 두 번 빠르게 누르면 원판이 멈추지 않아요”는 정보다. 앞의 것은 질문을 되돌려 받고, 뒤의 것은 그 자리에서 재현된다. QA(품질 확인)는 이런 걸 미리 찾아내는 단계고, 회의에서 “QA 돌았어요?”는 여러 상황에서 실제로 눌러 봤냐는 뜻이다.
주사위 게임을 본문에 넣을 때 이 그물에 걸린 게 있다. 게임을 불러오는 짧은 코드 한 줄을 본문에 넣는 방식이었는데, 그 코드를 예시로 보여 주려고 코드 상자 안에 똑같이 적어 뒀더니 상자 안의 것까지 실행돼 게임이 두 번 나타났다. 예시를 특수문자 표기로 바꿔 글자로만 보이게 해서 고쳤다. 게임 자체가 아니라 게임을 설명하는 문장이 게임을 하나 더 만들어 낸 것이다. 이런 건 눌러 보지 않으면 절대 안 보인다. 주사위 게임 글에서 만든 그 게임이다.
버그 요청: “버튼을 두 번 빠르게 누르면 원판이 멈추지 않아. 크롬 최신 버전, 휴대폰에서도 같아. 원인 후보를 셋만 짚고 확인 순서를 알려 줘.”
혼자 만드는데 스프린트가 필요할까
혼자면 회의 형식은 필요 없지만, 구간을 끊는 습관은 남는다. 애자일에서 쓰는 말들이 대개 그렇다. 형식은 팀 것이고, 뼈대는 혼자에게도 쓸모가 있다.
정의는 스크럼 가이드에 짧게 나온다. 판본이 갱신되는 문서라 2026년 7월에 올라와 있는 문장을 그대로 옮긴다. 스프린트는 “일관성을 만들기 위해 한 달 이하로 길이를 고정한 행사”다. 데일리 스크럼은 15분짜리 행사고, 목적은 목표까지 얼마나 왔는지 살펴 그날 할 일을 다시 맞추는 것이다. 백로그는 “제품을 개선하기 위해 필요한 것들의 순서 있는 목록”이라고 적혀 있다. 순서가 있다는 말이 핵심이다. 쌓아 둔 더미가 아니라 위에서부터 꺼내는 줄이다.
혼자 만드는 사람이 가져갈 건 이 정도다. 할 일을 한 줄로 세워 놓고(백로그), 이번 주에 여기까지만 한다고 끊고(스프린트), 하루 시작할 때 어제 어디까지 왔는지 본다(데일리 스크럼). 이름이 거창해서 뭔가 대단해 보이지만 내용은 이게 다다.
기술부채라는 말도 여기 붙어 있다. 급해서 대충 해 두고 나중에 정리하기로 미뤄 둔 것들이다. 이 블로그에도 있다. 올린 이미지를 서버에서 가벼운 형식으로 바꿔 내보내는 스크립트가 있는데, png와 jpg만 골라내도록 짜여 있다. GIF는 그 그물을 그냥 통과한다. 당장 고장은 안 나지만, 언젠가 GIF를 잔뜩 올리면 그날 청구서가 온다.
회의에서 나오는 용어 15개
짝으로 붙어 다니는 말은 뜻 칸에 함께 적었다.
| 용어 | 우리말 | 회의에서 뜻 |
|---|---|---|
| RFP | 제안요청서 | “이런 걸 만들어 주세요” 발주 문서. 답이 제안서·견적 |
| PRD | 제품요구사항문서 | 무엇을 왜 만드는지 |
| 기능명세서 | 스펙 | 버튼 하나까지 어떻게 움직이는지 |
| 와이어프레임 | 화면 골격 | 배치만 그린 스케치. 화면 순서는 유저플로우 |
| POC | 개념검증 | 기술적으로 되는지만 보는 실험 |
| 프로토타입 | 시제품 | 만져 보게 하는 가짜 |
| MVP | 최소기능제품 | 사용자에게 내놓는 최소판 |
| 스코프 크리프 | 범위 번짐 | 정한 선 밖 요청이 슬금슬금 들어옴 |
| API | – | 프로그램끼리 주고받는 창구 |
| SDK | 개발 도구 꾸러미 | 그 창구를 쓰기 쉽게 묶은 것 |
| 백엔드 | 안 보이는 쪽 | 데이터를 준비해 넘김. 화면 쪽은 프론트엔드 |
| 스테이징 | 시험 환경 | 먼저 올려 보는 연습장. 실제는 프로덕션 |
| QA | 품질 확인 | 여러 상황에서 실제로 눌러 보는 단계. 버그는 재현조건부터 적는다 |
| 스프린트 | 작업 구간 | 한 달 이하로 끊은 기간. 할 일 줄은 백로그 |
| 기술부채 | 미뤄 둔 뒷정리 | 급해서 대충 해 두고 넘긴 것 |
나라면 다섯 개만 먼저 외운다
열다섯 개를 다 외우려 들면 하나도 안 남는다. 바이브코딩을 하는 사람에게 실제로 값을 하는 건 다섯 개다.
PRD, 기능명세서, POC, MVP, 재현조건. 이유는 단순하다. 이 다섯 개가 AI에게 그대로 시킬 수 있는 말이기 때문이다. 나머지 열 개는 회의에서 나올 때 알아듣기만 하면 된다. 알아듣는 건 이 글을 한 번 읽어 두면 되는 일이고, 시키는 건 매번 해야 하는 일이다.
그리고 하나만 덧붙이자면, 뜻을 짐작하고 넘어가는 습관이 제일 비싸다. 같은 단어를 서로 다르게 알고 회의를 나오면 그 차이는 결과물에서 드러난다. MVP까지 만들자고 합의했는데 한쪽은 클릭되는 시안을, 한쪽은 결제까지 붙은 서비스를 떠올렸다면 그 회의는 아무것도 정하지 않은 것이다. 모르는 단어가 나오면 그 자리에서 묻는 게 낫다. 초보라서 묻는 게 아니라, 그게 확인이라서 묻는 것이다.