Part 1 — 기획의 기술

"좋은 개발"보다 먼저 필요한 것

기술 중심 사고의 함정 · 3축 균형 · 프레임워크 · Lean Canvas · 사업성

박수현 · SW마에스트로 특강 · 2026

🎨 이미지 프롬프트: "A blueprint table where code snippets blur into the background while a sharp question mark and a user persona glow in focus, architectural draft style, teal and purple, 16:9, no text"

"좋은 개발"보다 먼저 필요한 것

기술은 구현 방법이고,
기획은 무엇을 왜 만드는지 정의하는 기술이다

이 시간이 끝나면

관점이 바뀝니다

• ✅ "기능을 추가한다" 대신 "어떤 문제를 푸는가" 로 말한다
• ✅ 기획서의 3축(기획성·기술성·사업성) 균형을 안다
• ✅ 프레임워크를 암기가 아니라 사고 도구로 쓴다

직접 해봅니다

• ✅ 내 프로젝트로 SWOT · STP 즉석 적용
• ✅ Mom Test 로 우리 문제 가설 점검
• ✅ 우리 팀 아이디어를 Lean Canvas 한 장으로 재구성

오늘 Part 1의 길

1-1. SW마에스트로 프로젝트는
왜 망하는가?

학생 프로젝트가 시작되는 네 가지 말

공통점: "누가·왜 쓰는가" 가 빠져 있습니다. 시작이 기술이지 문제가 아닙니다.

같은 6개월, 갈리는 결과

심사위원과 사용자는 "무엇을 만들었나" 가 아니라 "누구의 무슨 문제를 풀었나" 를 봅니다.

한 줄로

SW마에스트로 팀은 3명 다 개발자입니다. 그래서 아무도 문제를 정의하지 않는 사고가 자주 일어납니다.

좋은 기획서 = 세 축의 균형

한 축만 크면 무너집니다: 기술만 → "그래서 누가 써요?" · 기획만 → "구현은요?" ·
균형이 안 맞으면 심사도, 사용자도 설득 못 합니다.

🎨 이미지 프롬프트: "An equilateral triangle balanced on a point, three labeled vertices glowing: 기획성 (compass), 기술성 (gear), 사업성 (value coin), each pulling the balance, clean flat infographic, teal and purple, Korean labels readable, 16:9"

좋은 기획서 = 세 축의 균형

1-2. 개발자 사고 vs 기획자 사고

같은 상황, 다른 첫 질문

어느 쪽이 옳다가 아니라 — 둘 다 필요한데 팀에 한쪽만 있는 게 문제입니다.

왜 벡터DB · RAG · 멀티에이전트 · 쿠버네티스에 끌릴까

기술 난이도는 내가 통제 가능해서 안전지대입니다. 사용자는 통제 불가라 회피하게 됩니다 — 그게 함정.

실제 산업에서 더 크게 따지는 것

기술 난이도(E)는 다섯 중 하나일 뿐 — 그런데 학생 팀은 시간의 90%를 E에 씁니다.

사람들은 드릴이 아니라 구멍을 원한다

Jobs To Be Done — 사용자는 기능을 원하는 게 아니라, 어떤 할 일(Job) 을 끝내려고 제품을 잠깐 "고용" 한다 (안 되면 바로 "해고")

질문을 바꾸세요: "무슨 기능?" → "사용자는 어떤 상황에서, 무엇을 끝내려고, 무엇을 대신 쓰고 있나?"

🎨 이미지 프롬프트: "Jobs-To-Be-Done concept: a hand reaching past a row of power drills toward a clean round hole in a wall, the hole glowing as the real goal, minimal flat conceptual illustration, teal and purple accents, no text, 16:9"

사람들은 드릴이 아니라 구멍을 원한다

문제를 정의하는 법 — 해법 말고 문제부터

❌ "AI 면접 서비스를 만들자"(해법) → ✅ "면접 준비생은 피드백 받을 데가 없어 막막하다"(문제). 해법은 그다음.

페르소나 — "사용자"를 한 사람으로

이름·상황·행동·불편이 한 문장에 그려져야 — 기능 우선순위·메시지·STP가 그 사람 기준으로 정해집니다.

1-3. 기획 프레임워크는
왜 존재하는가

기획도 공학입니다

프레임워크 = 외울 용어가 아니라 빠뜨리지 않게 해주는 체크리스트 + 사고 순서

항상 묻습니다: 왜 생겼나 · 언제 쓰나 · 뭘 안 빠뜨리게 해주나.

SWOT — 내부/외부를 분리해서 보기

💬 4칸 채우기가 끝이 아니라 — S×O(살릴 길)·W×T(피할 길) 교차 가 전략

✏️ 즉석 실습 (2분): 주제 "AI 면접 코칭 서비스" — 팀별 S·W·O·T 각 1개.
흔한 실수: O·T 자리에 또 내부 얘기 → 외부 변수 강제 훈련.

🎨 이미지 프롬프트: "SWOT analysis 2x2 matrix, four equal quadrants labeled 강점(S)·약점(W)·기회(O)·위협(T), top row marked 내부(우리가 통제) and bottom row 외부(환경), clean flat business infographic, teal and purple, Korean labels clearly readable, 16:9"

SWOT — 내부/외부를 분리해서 보기

SWOT — 채워본 예 ("SW마에스트로 AI 면접 코칭")

칸을 채우면 전략이 보입니다: W(데이터 부족) × O(수요↑) → "좁은 직군 1개 데이터에 집중".

PEST — 기술만 보면 놓치는 바깥 바람

예: "생성형 AI 자소서" — 기술(T) 은 쉬운데 저작권·평가 공정성(S/P) 이 진짜 변수.
(확장판 STEEP = Social · Technological · Economic · Environmental · Political)

🎨 이미지 프롬프트: "PEST analysis diagram: a central product circle surrounded by four labeled environment sectors 정치(Political)·경제(Economic)·사회(Social)·기술(Technological), with a faded fifth 'STEEP: +환경' chip, clean flat infographic, teal and purple, Korean labels clearly readable, 16:9"

PEST — 기술만 보면 놓치는 바깥 바람

3C — "우리 서비스는 특별해요" 가 깨지는 곳

학생들은 경쟁사를 안 봅니다. 진짜 경쟁자는 비슷한 앱이 아니라 —
"그냥 안 쓰기" · 엑셀 · 손작업 · 기존 습관 입니다. (JTBD의 "대신 쓰는 것")

🎨 이미지 프롬프트: "3C analysis as three overlapping circles (Venn) labeled 고객(Customer)·경쟁사(Competitor)·자사(Company), the center intersection highlighted, clean flat strategy infographic, teal and purple, Korean labels clearly readable, 16:9"

3C — "우리 서비스는 특별해요" 가 깨지는 곳

STP — 모든 사용자를 노리면 아무도 안 옵니다

Segmentation → Targeting → Positioning

초기 타겟은 좁을수록 강합니다. 좁힌 다음 넓히는 거지, 처음부터 넓히면 못 넓힙니다.

🎨 이미지 프롬프트: "STP strategy as a funnel narrowing left to right: wide '시장 세분화(Segmentation)' → '타겟 선정(Targeting)' → a sharp point '포지셔닝(Positioning)' aimed at one persona, clean flat infographic, teal and purple, Korean labels clearly readable, 16:9"

STP — 모든 사용자를 노리면 아무도 안 옵니다

① Segmentation — 시장을 의미 있게 쪼갠다

좋은 세분화 = 세그먼트마다 행동이 실제로 다르게 갈린다.

② Targeting — 어디부터 칠지 고른다 (전부 ❌)

타겟팅의 본질은 집중 — 못 고르면 메시지가 모두에게 흐려집니다.

③ Positioning — 타겟의 머릿속 한 자리 를 차지한다

한 문장에 안 들어가면 — 아직 포지셔닝이 없는 것입니다.

4P — 만들고 나서가 아니라 기획할 때 같이 본다

같은 4P(Product · Price · Place · Promotion)라도 사업마다 완전히 다릅니다:

Price·Place가 다르면 완전히 다른 사업 — 기능만 설계하면 절반만 한 것.

🎨 이미지 프롬프트: "Marketing mix 4P diagram: a central product hub with four labeled spokes 제품(Product)·가격(Price)·유통(Place)·촉진(Promotion), each spoke a small icon, clean flat marketing infographic, teal and purple, Korean labels clearly readable, 16:9"

4P — 만들고 나서가 아니라 기획할 때 같이 본다

언제 무엇을 쓰나 (암기 말고 용도)

막힌 질문에 맞는 도구를 꺼내 씁니다:

• SWOT — "우리 위치는?" (내부 강·약 / 외부 기회·위협)
• PEST — "바깥 바람은?" (규제 · 경제 · 사회 · 기술)
• 3C — "경쟁·대체재는?" (고객 / 경쟁 / 우리)
• STP — "누구에게 먼저?" (세분화 → 타겟 → 포지셔닝)
• 4P — "어떻게 전달·과금?" (제품 / 가격 / 채널 / 홍보)

다섯 개를 다 쓸 필요 없습니다. 막힌 질문 하나에 맞는 한 개면 충분합니다.

공학자는 패턴을 다 쓰지 않는다 — 필요한 것만 쓴다

GoF 디자인 패턴도 23개를 전부 쓰지 않죠. 유형이 있고, 문제에 맞는 하나를 고를 뿐:

패턴이 많고 좋다고 다 끼워 넣으면 과설계(안티패턴). 문제에 맞는 하나 = 좋은 설계.
기획 프레임워크(SWOT·PEST·3C·STP·4P)도 똑같습니다 — 막힌 질문에 맞는 한 개만.

구구절절 < 한 단어 — 전문 용어는 압축된 합의다

같은 말을 풀어 설명 vs 키워드 — 위는 길고 모호, 아래는 한 방에 통합니다:

키워드 = 팀·심사위원과 공유된 정신 모델. 기획도 똑같습니다 —
❌ "사람들이 들어와선 뭘 할지 몰라 5분 만에 나가요" → ✅ "Activation 문제".
그래서 SWOT·JTBD·PMF·STP 를 배웁니다: 구구절절 대신 한 단어로 정확·빠르게.

단, 아무도 모르는 키워드는 — 0점

키워드는 청중과 공유될 때만 압축입니다. 모르는 단어는 압축이 아니라 벽:

평가위원 입장: "내가 이해 못 하는 것에 좋은 점수를 줄 수는 없다." 발표는 설득이지 과시가 아닙니다.
심사위원·멘토는 다양한 분야 — 내 분야 용어를 모를 수 있습니다. 핵심 용어엔 한 줄 해설/비유를.

문제 검증 — 엄마도 거짓말한다 (Mom Test)

"이거 좋아요?" 라고 물으면 모두 "응 좋아" — 쓸모없는 검증

의견이 아니라 과거 행동을 물어라. 돈·시간을 이미 쓴 적 있으면 — 그게 진짜 문제.

1-4. Lean Canvas · MVP · 사업성

"서비스 설명" 과 "사업 설명" 은 다릅니다

발표 첫 30초에 왼쪽을 말하면 심사위원은 이미 흥미를 잃습니다.

Lean Canvas — 9칸

채우다 보면 빈 칸이 생깁니다. 그 빈 칸이 지금 우리 팀이 모르는 것 입니다.

🎨 이미지 프롬프트: "Lean Canvas one-page template, a 3x3-ish grid of labeled blocks 문제·솔루션·고유가치·고객·채널·수익·비용·핵심지표·경쟁우위, clean flat startup infographic, teal and purple, Korean block titles clearly readable, 16:9"

Lean Canvas — 9칸

MVP — 가장 작게 만들어 가장 빨리 배운다

MVP는 "기능 적은 v1"이 아니라 — 하나의 가설을 검증하는 가장 싼 실험입니다.

AI·LLM 기능 — "잘 된다"를 어떻게 증명하나

"정확도 95%"는 어디서 잰 95%인가? 데이터가 새면(leakage) 무의미. 검증 설계를 기획 단계에 박으세요.

AI·LLM — 정확도 하나로 우기지 마라

정량 + 정성(휴먼)을 함께. 심사 단골: "환각·오답 나면 어떻게 처리?" → 폴백·근거 표시·사람 최종 확인.

"우리는 사업 안 할 건데요?" — 그래도 사업성은 본다

사업성 = 돈 이 아니라 "왜 이게 세상에 존재할 가치가 있는가". 3축(slide 9) 중 비면 탈락하는 한 축.

✏️ 실습 — 우리 프로젝트를 Lean Canvas로

오늘 가져갈 단 하나: "기능 설명"을 "문제 해결 구조"로 바꾸는 훈련.

요구사항 — 기능만 적으면 절반만 한 것

NFR이 곧 DoD·아키텍처·평가 기준입니다. 학생은 FR만 적다가 발표에서 "느려요/터져요/안 정확해요"로 무너집니다.

Part 1 정리 — 기획은 문제를 정의하는 기술

• ✅ 망하는 시작: 기술·기능 / 사는 시작: 문제·사용자
• ✅ 기획서 = 기획성·기술성·사업성 균형 (한 축만 크면 탈락)
• ✅ JTBD — 사용자는 구멍을 원한다 / 프레임워크 = 체크리스트
• ✅ Mom Test 로 검증, Lean Canvas·MVP 로 가설 실험
• ✅ 사업성 = 돈이 아니라 가치 증명 (오픈소스도)

다음 — Part 2: 잘 기획해도, Agile이라는 이름으로 운영에서 무너집니다.