3차시 함께 만들다 — 협력 설계와 MVP

🤔

생각 열기 — 다 만들려다 아무것도 못 만든다

두 개발자가 한 화면을 보며 함께 작업하는 모습 — 함께 만드는 개발 — 좋은 제품은 혼자가 아니라 역할을 나눠 협력하고 소통하는 팀에서 나온다. 사진: Lisamarie Babik, CC BY 2.0, Wikimedia Commons

아이디어는 떠올랐어요. 그런데 "회원가입, 검색, 채팅, 결제, 추천 AI, 다국어, 다크모드…" 다 만들려다 보면 학기 끝까지 아무것도 출시 못 합니다. 진짜 스타트업은 거꾸로 해요. "이 서비스가 정말 필요한지"를 가장 빨리 확인할 가장 작은 제품, MVP부터 만듭니다. 이번 차시에선 기능을 골라내고, 역할을 나누고, 짧게 만들어 피드백받는 협력 개발의 진짜 기술을 직접 손으로 익혀요.

💬 함께 생각해 보기

'학교 중고 교재 거래 앱'을 만든다면, 딱 하나의 기능만 먼저 만들 수 있다면 무엇을 만들겠어요? 왜 그게 가장 먼저일까요?

1

MVP — 가장 작게 만들어 가장 빨리 확인하기

MVP(최소 기능 제품)는 '핵심 가치를 검증할 수 있는 가장 작은 제품'이에요. 완성품이 아니라 '질문'에 가까워요. '사람들이 정말 이걸 쓸까?'라는 핵심 질문에 답하는 데 꼭 필요한 기능만 남기고 나머지는 과감히 미뤄요. 화려함이 아니라 '핵심 가치가 작동하는가'가 기준이에요. 잘못된 MVP는 핵심 기능을 빼서 아무것도 검증 못 하거나, 너무 많이 넣어 출시가 늦어져요.

📌 예시

중고거래의 핵심 가치는 '내 물건을 팔고 남의 물건을 산다'예요. MVP엔 상품 등록·목록·연락 수단만 있으면 돼요. 추천 AI·다국어·다크모드는 가치 검증과 무관하니 '다음 버전'으로! 실제 한 중고거래 앱도 초기엔 사진 한 장과 전화 연결뿐인 단순한 형태로 시작해 '거래가 일어나는가'만 확인했어요.

2

기능 우선순위 — 다 중요하면 아무것도 안 중요하다

기능을 세 칸으로 나눠요. 🟢 꼭 필요(MVP 필수): 빼면 핵심 가치가 무너지는 기능. 🟡 있으면 좋음(다음 버전): 가치를 키우지만 지금은 없어도 검증 가능한 기능. 🔴 지금은 제외: 나중에, 또는 영영 안 만들어도 되는 기능. 핵심은 '모든 기능을 🟢에 두지 않는 용기'예요. 우선순위는 '핵심 가치에 직접 기여하는가 × 개발 비용'으로 판단해요.

🤝

직접 정하기 — MVP 기능 우선순위 보드

기능 카드를 골라 세 칸으로 분류해 보세요. 🟢 MVP에 넣은 기능에 따라 예상 개발 기간·복잡도와 핵심 가치 검증 신호등이 실시간으로 바뀌어요. 너무 많이 넣어도, 핵심을 빼도 경고가 떠요!

🤝 MVP 기능 우선순위 보드 INTERACTIVE

핵심 가치:

📦 기능 풀 — 카드를 누른 뒤 아래 칸을 누르면 옮겨져요 (여기를 누르면 다시 풀로)

🟢 MVP 필수

🟡 다음 버전

🔴 지금은 제외

예상 개발 기간0주

복잡도—

핵심 가치 검증—

설계 점수—

[안내]핵심 가치를 검증할 '필수 기능'만 🟢에 넣어 보세요. 다 넣으면 범위가 너무 커져요!

3

협업 — 역할을 나누고, 같은 그림을 보며

해커톤에서 함께 협업하는 참가자들 — 해커톤 — 짧은 시간 안에 역할을 나눠 함께 만들고 겨루는 협력 개발의 축제. 사진: Moniruj, CC0, Wikimedia Commons

스타트업은 혼자가 아니라 팀이에요. 보통 기획(무엇을 왜 만드나)·디자인(어떻게 보이고 쓰이나)·개발(실제로 만든다)·테스트(잘 되는지·문제는 없는지 확인)로 역할을 나눠요. 역할이 나뉘어도 '같은 목표·같은 우선순위'를 봐야 충돌이 안 나요. 그래서 짧은 회의로 소통하고, 버전 관리(누가 무엇을 언제 바꿨는지 기록·복원)로 협업 결과를 안전하게 합쳐요.

🗣️ 매일 5분 회의

매일 짧게 '어제 한 것·오늘 할 것·막힌 것'만 공유해도 협업이 매끄러워져요. 역할이 달라도 같은 목표를 보는 게 핵심이에요.

4

애자일 반복 — 짧게 만들고, 피드백받고, 고친다

한 번에 완벽하게 만들려 하지 말고, 짧은 주기로 '프로토타입 → 테스트 → 개선'을 반복해요 (애자일). 프로토타입은 빠르게 만든 시제품이에요 — 종이 그림, 클릭만 되는 화면, 일부만 동작하는 앱 등 단계가 다양해요. 핵심은 '완성 전에 사용자에게 보여 주고 배우는 것'. 한 바퀴 돌 때마다 '무엇을 배웠는가'를 정리해 다음 바퀴에 반영해요.

🔁 두세 바퀴면 충분히 달라진다

학습 플래너를 만든다면, 1주차엔 종이로 화면을 그려 친구 5명에게 보여 줘요. '할 일 추가가 복잡하다'는 피드백을 받으면 2주차엔 버튼 하나로 줄여 실제 동작하는 버전을 만들어 다시 테스트. 두세 바퀴만 돌아도 처음 상상과 전혀 다른, 훨씬 쓸 만한 제품이 돼요.

🗂️

분류 게임 — 협업 역할 매칭

활동을 누른 뒤 알맞은 역할 바구니를 누르세요.

사용자가 진짜 원하는 게 뭔지 정하고 만들 범위를 좁힌다 핵심 가치를 가장 빨리 검증할 최소 기능(MVP)을 정한다 주문 버튼을 누르면 가게로 정보가 가도록 코드를 작성한다 등록 화면이 한눈에 들어오게 색·버튼 배치를 정한다 버튼 색이 배경과 잘 구분되는지 점검한다 사진 없이 등록하면 어떻게 되는지 일부러 시도해 본다

🧭 기획

🎨 디자인

💻 개발

🔍 테스트

💡 핵심

역할이 나뉘어도 같은 목표·우선순위를 봐야 협업이 충돌하지 않아요. MVP 범위를 정하는 것도 '기획'의 핵심 일이랍니다.

✅

확인 문제

바로바로 채점!

✏️

3차시 확인 문제

3문항 · 즉시 채점

1MVP(최소 기능 제품)를 가장 잘 설명한 것은?

2중고거래 앱 MVP의 기능 우선순위로 가장 적절한 것은? (핵심 가치: '학생끼리 교재를 사고판다')

3애자일 반복 개발·협업에 대한 설명으로 옳지 않은 것은?

📚

핵심 용어

MVP(최소 기능 제품)핵심 가치를 검증할 수 있는 가장 작은 제품. '사람들이 정말 이걸 쓸까?'에 답하는 최소한의 형태.

기능 우선순위기능을 🟢 꼭 필요 / 🟡 있으면 좋음 / 🔴 제외로 나누는 것. '가치 기여도 × 개발 비용'으로 판단.

프로토타입빠르게 만든 시제품. 종이 그림부터 일부만 동작하는 앱까지, 완성 전 사용자에게 보여 주고 배운다.

애자일 반복한 번에 완벽 대신 '만들기→피드백→개선'을 짧은 주기로 반복하는 개발 방식.

역할 분담기획·디자인·개발·테스트로 일을 나누는 것. 같은 목표·우선순위를 봐야 협업이 충돌하지 않는다.

버전 관리누가 무엇을 언제 바꿨는지 기록하고, 변경을 안전하게 합치며, 문제 시 이전으로 되돌리는 협업 기술.

➕

더 알아보기

교과서 너머의 이야기 — 클릭해서 펼쳐 보세요

실전종이로도 출시한다 — '가짜 문' 테스트와 버전 관리

MVP의 극단적 형태로 '가짜 문(fake door)' 테스트가 있어요. 아직 만들지 않은 기능의 버튼만 화면에 두고, 누른 사람 수를 세어 수요를 미리 확인하는 방법이에요. 코드를 거의 안 짜고도 '이 기능이 필요한가'를 검증할 수 있죠. 또 한 가지, 협업의 숨은 주역은 버전 관리(Git 등)예요. 여러 명이 같은 코드를 동시에 고쳐도 충돌을 합치고, 잘못된 변경은 이전으로 되돌리며, '언제 무엇이 왜 바뀌었는지' 역사를 남겨요. MVP가 '무엇을 만들까'의 기술이라면, 버전 관리는 '함께 안전하게 만들기'의 기술이에요. 이 둘이 합쳐질 때 작은 팀도 진짜 제품을 출시합니다.

개념MoSCoW — 우선순위를 정하는 네 글자

기능 우선순위를 정하는 유명한 방법이 'MoSCoW'예요. 네 단계의 앞 글자를 딴 거예요. Must(반드시 — 없으면 제품이 성립 안 됨), Should(중요하지만 당장은 아니어도 됨), Could(있으면 좋음 — 여유 있으면), Won't(이번엔 안 함 — 명확히 제외). 우리 보드의 🟢·🟡·🔴이 바로 이 생각과 똑같아요. 핵심은 'Must'를 아주 적게 유지하는 거예요. 모든 걸 'Must'로 두면 팀은 과로하고 출시는 늦어지고, 정작 사용자가 원하는지도 모른 채 거대한 제품을 만들게 돼요. 현업에서도 '이거 정말 Must인가요? 없으면 진짜 안 되나요?'를 끊임없이 되묻는 게 좋은 기획자의 습관이에요. 줄이는 것이 곧 속도이고, 속도가 곧 빠른 학습이랍니다.

생각'완벽한 혼자'보다 '부족해도 함께'

학생들이 팀 프로젝트에서 가장 많이 겪는 어려움은 기술이 아니라 '사람'이에요. 한 명이 다 하려 하거나, 서로 무엇을 하는지 몰라 같은 걸 두 번 만들거나, 막혔는데 말 못 하고 끙끙대다 마감을 넘기죠. 그래서 협업에서 가장 중요한 건 뛰어난 한 명이 아니라 '자주, 솔직하게 소통하는 팀'이에요. 막히면 빨리 말하기('나 여기서 막혔어, 도와줄래?'), 작게 자주 합치기, 서로의 결과를 존중하기. 실제로 좋은 개발 문화의 핵심 가치가 '비난 없는 회고(blameless)'예요 — 문제가 생기면 '누구 잘못'이 아니라 '무엇을 고치면 다음엔 안 그럴까'를 함께 찾는 거죠. 거창한 결과물보다, 함께 만들며 소통하고 조율한 경험 자체가 여러분이 이 단원에서 얻을 가장 값진 것이에요. 완벽한 혼자보다, 부족해도 함께가 멀리 갑니다.

함께 만들다협력 설계와 MVP