3강 — 앱 설계

🎯 학습 목표

개발에서 설계가 왜 먼저인지, 설계 없이 코딩하면 무슨 일이 벌어지는지 설명할 수 있다
앱 설계의 표준 4단계(사용자 → 요구사항 → 기능 → 화면)를 순서대로 따라갈 수 있다
사용자의 말을 기술 요구사항으로 번역하고, 요구사항을 기능·기술로 구체화할 수 있다
지금까지 배운 분석 기술들을 조립해 리뷰 분석 대시보드의 전체 설계도(3-tier 아키텍처)를 그릴 수 있다

📖 해설

1. 개발에서 가장 중요한 단계 — 설계

오늘부터는 분석 기술을 하나의 앱(서비스)으로 묶는 이야기를 시작합니다. 그런데 코드를 짜기 전에, 개발에서 가장 중요한 단계를 먼저 배웁니다. 바로 설계입니다.

질문 하나 드리겠습니다. 실무에서 프로젝트가 실패하는 원인 1위가 뭘까요? 개발 실력 부족이 아닙니다. 설계 부족입니다. "일단 만들면서 고치자"는 접근은 생각보다 위험합니다. 통계적으로 설계가 부족한 채 시작한 프로젝트는 일정이 2~3배 늘어난다는 연구 결과가 있습니다.

개발은 설계 내용에 의존적으로 따라옵니다. 무엇을 만들지, 어떻게 만들지를 설계부터 정해야 합니다. 이것이 수준 높은 개발자의 핵심 역량입니다. 그래서 오늘은 코드를 짜기보다, 설계하는 방법 자체를 배웁니다.

이번 시간 설계는 네 단계로 진행합니다. 그리고 이 순서가 핵심입니다.

사용자 정의 — 누가 쓸까? (모든 설계의 출발점)
요구사항 도출 — 그 사용자가 무엇을 원하는가?
기능 정의 — 요구사항을 충족할 기능은 무엇인가?
화면 설계 — 그 기능을 어떻게 보여줄까?

화면부터 그리거나 기능부터 정하면 곤란합니다. 반드시 사용자부터 시작해 화면까지 순차적으로 내려갑니다. 이것이 소프트웨어 공학의 기본 원칙입니다.

2. 설계 안 하고 바로 코딩하면 안 될까요?

당연히 이런 생각이 듭니다. "설계할 시간 아까운데, 바로 코딩하면 안 되나?" 무언가 만들고 싶으면 바로 키보드부터 잡고 싶고, 그래야 진도도 빨리 나가는 것 같죠.

실제 프로젝트에서 무슨 일이 일어나는지 보겠습니다. 한 개발팀이 급한 프로젝트를 맡았습니다. 설계할 시간이 없다며 바로 개발을 시작했고, 일주일 만에 완성했습니다. 그런데 데모를 보던 고객이 이렇게 말합니다. "어, 이 기능 말고 저 기능이 필요한데요." 그 한마디에 며칠간 만든 걸 전부 버리고 처음부터 다시 해야 했습니다. 급해서 설계를 건너뛰었는데, 결국 더 오래 걸린 겁니다.

설계 없이 개발하면 실무에서 자주 이런 문제가 생깁니다.

문제	무슨 일이 벌어지나
다 만들었는데 필요 없는 기능	업계 조사에 따르면 개발된 기능 중 45%가 실제로 안 쓰입니다. 며칠 걸려 만든 게 "그거 안 써요" 한마디에 폐기됩니다
중간에 구조를 바꿔야 함	가장 비용이 큰 문제. 데이터베이스 구조를 잘못 잡으면 코드를 아무리 잘 짜도 소용없습니다. 집의 기초가 잘못된 것과 같아 처음부터 다시 해야 합니다
화면이 안 맞음	기능은 다 되는데 사용자가 어디서 뭘 눌러야 할지 모릅니다. UX 테스트에서 "이 버튼 어디 있어요?"가 가장 많이 나옵니다
결국 시간이 더 걸림	급해서 바로 시작했는데 재작업하느라 2~3배 걸립니다

특히 비용 측면에서 무서운 숫자가 있습니다. IBM 연구에 따르면, 요구사항 단계의 결함을 코딩이 끝난 뒤에 고치면 비용이 100배 증가합니다. 그래서 "급할수록 돌아가라"는 말이 있는 거죠. 설계가 바로 그 돌아가는 길입니다.

3. 설계는 지도, 개발은 여행

이렇게 생각하면 쉽습니다. 설계는 지도이고, 개발은 여행입니다.

처음 가는 곳에 지도 없이 가면 어떻게 되나요? 헤매고, 돌아가고, 시간을 낭비합니다. 심하면 목적지에 못 가기도 하죠. 내비게이션 없이 처음 가는 길을 운전하면 "여기서 회전이었나?" 하며 되돌아갑니다. 코딩도 똑같습니다. 설계 없이 코딩하면 "아, 여기서 이렇게 했어야 했나" 하며 코드를 지우고 다시 씁니다.

그래서 우리는 지도를 먼저 그립니다. 목적지가 어디인지, 어떤 길로 갈지, 중간에 무엇이 있는지를 먼저 정해 두면 개발할 때 헤매지 않습니다. 지도를 보고 가니까요. 소프트웨어 공학에서는 이 지도를 설계 문서라고 부릅니다. 실무에서는 요구사항 정의서 또는 기획서라고도 합니다.

4. 우리는 이미 재료를 다 가지고 있습니다

설계를 시작하기 전에, 지금까지 배운 걸 한 번 정리해 봅시다.

32차시: 3-tier(3계층) 구조 — 프론트엔드는 Streamlit으로 화면을, 백엔드는 FastAPI로 로직을, 데이터베이스는 SQLite로 저장하는 구조
1일차: 데이터 수집 — Steam API로 리뷰 가져오기
2일차: 전처리 — 텍스트 정제, 노이즈 제거
3~4일차: LLM 분석 — 감성 분석, 키워드 추출, 시각화

여기서 핵심입니다. 기술은 이미 여러 가지 배웠습니다. 재료는 다 있습니다. 이제 필요한 건, 이 재료로 무엇을 만들지 정하는 것입니다. 요리로 치면 레시피가 필요한 거죠. 그 레시피가 바로 지금 시작할 설계입니다.

5. Step 1 — 사용자 정의: 누가 쓸까요?

설계의 첫 단계는 사용자 정의입니다. 왜 이게 제일 먼저일까요? 간단합니다. 누가 쓰는지 모르면, 무엇을 만들어야 할지도 알 수 없기 때문입니다. 요리할 때도 누가 먹을지 먼저 생각하잖아요. 아이가 먹으면 싱겁게, 어른이 먹으면 조금 짜게 — 먹는 사람에 따라 달라집니다.

여기서 가장 흔한 실수가 있습니다. "누구나 쓸 수 있게 만들자" — 이게 곤란합니다. 막연하게 "누구나"라고 하면 실제로는 아무도 못 쓰는 경우가 많습니다. 모든 사람을 만족시키려다 아무도 만족시키지 못하는 거죠. 이걸 타깃 사용자 부재라고 합니다.

그래서 한 명의 구체적인 사용자를 상상해야 합니다. UX에서는 이걸 페르소나(persona)라고 부릅니다. 이름을 붙이고, 직업을 정하고, 어떤 고민이 있는지까지 정합니다. 그 한 사람을 위해 만드는 것이 첫 단계입니다.

그럼 우리 앱은 누가 쓸까요? 후보를 하나씩 따져 봅시다.

개발자? — 직접 코드를 짜서 분석할 수 있으니 굳이 앱이 필요 없을 수 있습니다.
일반 게이머? — 게이머는 리뷰를 분석할 필요가 없습니다. 그냥 게임이 하고 싶은 거죠.
그럼 누가 리뷰를 분석하고 싶을까요? 리뷰 데이터가 실제 업무에 필요한 사람 — 바로 게임 회사 직원들(마케팅팀, 기획팀, CS팀)입니다. 유저 피드백을 분석해야 하는데 개발은 못하는 경우가 많은 분들이죠.

이 중 한 명을 구체적으로 정의해 페르소나를 만듭니다.

페르소나 — '김대리' - 게임 회사 마케팅팀에서 일함, 입사 3년 차 - 코딩은 못하고, 엑셀은 잘함 - 하루 업무: 신작 게임 리뷰 모니터링, 주간 보고서 작성 - 고민: 리뷰가 너무 많아 다 못 읽음. 중요한 불만을 놓칠까 봐 불안함 - 원하는 것: 클릭 몇 번으로 "요즘 유저가 뭐라 하는지" 빠르게 파악하고, 그걸로 보고서를 쓰고 싶음

김대리의 하루를 그려 보면 이렇습니다. 아침에 출근해 이메일을 확인하고 커피 한 잔 마신 뒤 리뷰를 살펴봅니다. 그런데 신작이면 하루에 수백 개씩 리뷰가 쏟아집니다. 이걸 다 읽는 건 물리적으로 거의 불가능하죠. 그래서 김대리는 늘 불안합니다. "중요한 불만이 있는데 내가 못 봤으면 어쩌지?"

이 페르소나가 곧 우리의 설계 기준입니다. 김대리가 편하게 쓸 수 있으면 성공입니다.

6. Step 2 — 요구사항 도출: 사용자의 말을 기술로 번역하기

사용자가 정해졌으니, 이제 그 사람 입장에서 무엇을 원하는지 생각합니다. 김대리가 월요일 아침에 출근했습니다. 지난 주말 동안 리뷰가 500개 쌓였어요. 이 상황에서 김대리에게 필요한 게 무엇일까요?

여기서 가장 중요한 스킬이 나옵니다. 사용자의 말을 기술 요구사항으로 "번역"하는 것입니다. 이걸 요구사항 추출이라고 합니다. 예를 들어 김대리가 "일일이 읽기 힘들어요"라고 말하면, 이를 기술로 번역하면 "자동 분석 기능이 필요하다"가 됩니다. "긍정인지 부정인지 빨리 알고 싶어요"는 "감성 분석 결과를 보여줘야 한다"가 되고요.

이렇게 도출한 요구사항에는 R1, R2, R3…처럼 번호를 붙입니다. 나중에 기능과 연결하려면 번호가 있어야 추적이 쉽거든요. 이걸 요구사항 추적성(traceability)이라고 합니다.

김대리의 니즈를 요구사항 5가지로 정리하면 이렇습니다.

번호	사용자의 말(니즈)	기술 요구사항으로 번역
R1	리뷰를 한곳에서 보고 싶어요	리뷰 저장 및 목록 조회 기능 필요
R2	일일이 읽기 힘들어요	자동 분석 기능 필요 (AI가 대신 읽어줌)
R3	긍정/부정 비율이 궁금해요	감성 분석 결과 시각화(차트) 필요
R4	자주 나오는 키워드가 뭐죠?	키워드 추출 및 표시 필요
R5	보고서에 쓸 요약이 필요해요	전체 요약 기능 필요

보이시죠? 사용자 니즈 하나하나가 기술 요구사항으로 변환됐습니다. 페르소나 입장에서 생각하니 요구사항이 자연스럽게 도출됩니다. 이게 사용자 중심 설계의 핵심입니다. 실무에서는 이 목록을 요구사항 명세서라고 부릅니다.

7. Step 3 — 기능 정의: 그래서 무엇을 만들까요?

요구사항(R1~R5)이 나왔으니, 이제 이걸 구체적인 기능으로 바꿉니다. 요구사항과 기능은 비슷해 보이지만 추상화 수준이 다릅니다.

요구사항 = 뭘 원하는가
기능 = 뭘 만들 것인가
기술 = 어떻게 구현할 것인가

예를 들어 R2 "일일이 읽기 힘들어요"라는 요구사항은 → 자동 분석 기능으로 바뀌고 → 이를 구현하는 기술은 LLM API 호출이 됩니다. 이렇게 요구사항 → 기능 → 기술로 점점 구체화하는 것을 요구사항 구체화라고 합니다.

요구사항 5가지를 기능과 기술로 매핑하면 이렇습니다.

요구사항	→ 기능	→ 기술
R1 리뷰를 한곳에서	리뷰 저장/조회	DB 저장 + 목록 API
R2 일일이 읽기 힘듦	자동 분석	LLM API 호출
R3 긍정/부정 비율	감성 차트	파이 차트 시각화
R4 자주 나오는 키워드	키워드 목록	막대 그래프
R5 보고서용 요약	요약 텍스트	LLM 요약 생성

이렇게 각 요구사항이 기능·기술과 연결된 표를 요구사항 추적 매트릭스라고 합니다. 설계의 핵심 문서 중 하나죠. 무엇을 만들어야 하는지가 명확해지니까요.

여기서 좋은 소식이 있습니다. 지난 4일 동안 배운 게 그대로 기능이 됩니다. 새로운 걸 배우는 게 아니라, 이미 배운 것들을 조립하는 겁니다.

배운 것	→ 앱에서는?
1일차 데이터 수집	'리뷰 수집' 버튼 (누르면 Steam에서 리뷰 가져옴)
2일차 전처리	분석 전 자동으로 돌아가는 정제 파이프라인 (사용자에게 안 보이지만 백그라운드 필수)
3일차 LLM 분석	'분석 실행' 버튼 (누르면 AI가 분석)
4일차 시각화	결과 대시보드 화면 (차트·그래프로 결과 표시)

레고 블록을 조립하듯, 우리가 가진 것들을 어떻게 구성해 원하는 앱을 만들 것인가를 생각하는 겁니다. 소프트웨어 개발에서는 이걸 컴포넌트 기반 설계라고 합니다.

8. 현실 감각 — MVP로 핵심부터 만들기

하지만 현실적으로, 모든 걸 완벽하게 만드는 데는 한계가 있습니다. 시간과 자원이 늘 부족하니까요. 그래서 MVP라는 개념이 있습니다.

MVP(Minimum Viable Product, 최소 기능 제품) — 없으면 안 되는 핵심만 먼저 만들고, 나머지는 나중에 추가하는 방식입니다. 스타트업에서 표준으로 쓰는 방법이고, 린 스타트업 방법론의 핵심 개념이죠. 완벽하게 만들려다 시간을 다 보내지 말고, 핵심만 빠르게 만들어 시장의 검증을 먼저 받는 겁니다.

우리 MVP는 세 가지입니다.

리뷰 저장/조회 — 수집한 리뷰를 DB에 저장하고 목록으로 볼 수 있으면 됨
분석 실행 — 선택한 리뷰를 LLM으로 분석하고 결과를 자동 저장
결과 대시보드 — 감성 비율 차트 + 키워드 목록 + 요약을 보여줌

이 세 개만 있으면 김대리가 업무에 활용할 수 있습니다. 나머지는 피드백을 받으며 추가하면 됩니다. 이게 애자일(agile) 개발 방식입니다.

9. Step 4 — 화면 설계: 어떻게 보일까요?

기능이 정해졌으니, 이제 이 기능들을 화면에 배치합니다. 이걸 UI 설계라고 해요. 여기서도 중요한 건 김대리 입장에서 생각하는 겁니다.

김대리가 어떤 순서로 업무를 처리할까요?

출근 → 리뷰 목록 확인 → 분석할 리뷰 고르기 → 분석 버튼 → 결과 확인 → 보고서 작성

이 흐름을 사용자 플로우(user flow)라고 합니다. UX 설계의 기본이죠. 이 흐름대로 화면을 만들면 김대리가 자연스럽게 헤매지 않고 쓸 수 있습니다. 그리고 각 화면에 무엇이 필요한지 — 버튼인지, 입력창인지, 차트인지 — 정합니다. 이런 화면 구성 요소를 UI 컴포넌트라고 합니다.

우리 앱은 사용자 플로우에 맞춰 3개 페이지로 구성합니다.

페이지	역할	필요한 UI 컴포넌트
메인 페이지 (랜딩)	출근해서 처음 보는 화면. 리뷰 목록 조회 + 새 리뷰 수집	테이블(리뷰 목록), 입력창(게임 ID), 버튼(수집)
분석 페이지	분석할 리뷰를 골라 분석 실행	체크박스(리뷰 선택), 버튼(분석), 진행바(로딩)
결과 페이지 (대시보드)	분석 결과 확인 + 보고서 작성	파이 차트(감성), 막대 그래프(키워드 순위), 텍스트(요약)

여기서 진행바를 빼먹지 마세요. 분석이 얼마나 진행됐는지 보여주는 진행바는 사용자 피드백을 위한 필수 UI입니다. 이게 없으면 사용자는 "되고 있는 건가?" 하며 불안해집니다. 결과 페이지의 요약 텍스트는 김대리가 그대로 복사해 보고서에 붙여넣을 수 있게 만드는 것이 포인트입니다.

10. 전체 설계도 완성 — 3-tier 아키텍처

이제 전체를 하나의 그림으로 묶습니다. 이걸 시스템 아키텍처 다이어그램이라고 합니다. 32차시에 배운 3-tier(3계층) 구조 그 자체입니다.

            ┌─────────────────────────────┐
            │  사용자: 김대리 (게임회사 마케터)  │
            └──────────────┬──────────────┘
                           │ 클릭 · 입력
                           ▼
   ┌───────────────────────────────────────────────┐
   │  프론트엔드 (Streamlit)                          │
   │   3개 화면:  [메인]  →  [분석]  →  [결과]          │
   └──────────────┬────────────────────────────────┘
                  │ API 요청 / 응답
                  ▼
   ┌───────────────────────────────────────────────┐
   │  백엔드 (FastAPI) — 비즈니스 로직 레이어           │
   │   수집 API  ·  분석 API  ·  조회 API              │
   └──────────────┬────────────────────────────────┘
                  │ 데이터 저장 / 읽기
                  ▼
   ┌───────────────────────────────────────────────┐
   │  데이터베이스 (SQLite) — 데이터 레이어             │
   │   2개 테이블:  reviews  ·  analysis_results       │
   └───────────────────────────────────────────────┘

위에서 아래로, 그리고 다시 아래에서 위로 데이터가 오가며 앱이 동작합니다. 사용자가 화면에서 버튼을 누르면 → 프론트엔드가 백엔드 API를 호출하고 → 백엔드가 DB에서 데이터를 읽거나 저장한 뒤 → 다시 화면으로 결과를 돌려주는 흐름입니다.

이 설계도가 있으면 개발할 때 헤매지 않습니다. 만들 범위(구현 범위)도 명확하니까요. 이것이 우리가 그릴 지도입니다.

11. 설계 사고 과정 정리 — 어떤 앱에도 통하는 프레임워크

오늘 거친 설계의 사고 과정을 한 줄로 압축하면 이렇습니다.

단계	질문	우리의 답
Step 1	누가 쓸까?	김대리 — 게임회사 마케터 (구체적 페르소나)
Step 2	뭘 원할까?	빠른 리뷰 분석 + 보고서용 요약 (페르소나 입장)
Step 3	뭘 만들까?	저장·분석·대시보드 3개 기능 (MVP)
Step 4	어떻게 보일까?	메인·분석·결과 3개 화면 (UI 설계)

사용자 → 요구사항 → 기능 → 화면. 이 순서를 따라가면 설계가 완성됩니다. 어떤 앱을 만들든 이 순서는 동일합니다. 이것이 소프트웨어 설계의 표준 프로세스입니다. 실무에서 앱을 만들 일이 있으면, "누가 쓰지?"부터 시작하세요.

🔑 핵심 용어

용어	쉬운 설명
설계(design)	코딩 전에 무엇을·어떻게 만들지 정하는 단계. 개발의 '지도'에 해당
설계 문서 / 요구사항 정의서	설계 내용을 적어둔 문서. 실무에서는 기획서라고도 함
페르소나(persona)	한 명의 구체적인 가상 사용자. 이름·직업·고민까지 정해 설계 기준으로 삼음
요구사항 추출	사용자의 말("읽기 힘들어요")을 기술 요구사항("자동 분석 필요")으로 번역하는 작업
요구사항 추적성	R1, R2…처럼 번호를 붙여 요구사항을 기능·기술과 연결·추적할 수 있게 하는 것
요구사항 추적 매트릭스	요구사항 → 기능 → 기술을 한 표로 연결한 설계 핵심 문서
MVP(최소 기능 제품)	없으면 안 되는 핵심 기능만 먼저 만드는 방식. 린 스타트업의 핵심 개념
컴포넌트 기반 설계	이미 만든 기능 조각(블록)을 조립해 앱을 구성하는 설계 방식
사용자 플로우(user flow)	사용자가 업무를 처리하는 화면 이동 순서. UX 설계의 기본
UI 컴포넌트	버튼·입력창·차트·테이블처럼 화면을 이루는 구성 요소
3-tier 아키텍처	프론트엔드(Streamlit)·백엔드(FastAPI)·DB(SQLite) 3계층으로 나눈 구조

🎮 게임 기획자 시점

오늘 배운 설계 4단계는 사실 게임 기획서를 쓰는 과정과 똑같습니다. 기획자가 시스템을 설계할 때도 "누가(타깃 유저) → 무엇을 원하나(코어 니즈) → 어떤 시스템·기능으로 풀까 → 어떤 UI/화면으로 보여줄까" 순으로 내려가죠. 페르소나는 곧 타깃 유저 정의이고, 요구사항을 기능으로 번역하는 일은 유저 니즈를 게임 시스템·콘텐츠로 옮기는 작업과 같습니다. "누구나 즐기게 만들자"가 아무도 만족 못 시키듯, 게임도 타깃을 뭉개면 핵심 재미가 흐려집니다. MVP 사고는 풀스펙을 한 번에 넣지 말고 코어 루프부터 검증하는 라이브 운영·소프트론칭 감각과 통하고, 요구사항 추적 매트릭스는 "이 기능이 어떤 유저 가치에서 나왔는가"를 역추적하게 해 줘 불필요한 기능(개발 기능의 45%!)을 쳐내는 기획 판단에 그대로 쓸 수 있습니다.

⚠️ 흔한 오해 / 짚고 갈 점

"설계는 시간 낭비, 일단 만들면서 고치자"는 오해입니다. 요구사항 결함을 코딩 후에 고치면 비용이 100배(IBM 연구)로 뜁니다. 설계가 곧 지름길입니다.
"누구나 쓸 수 있게"는 좋은 목표가 아닙니다. 타깃을 뭉개면 아무도 못 쓰는 앱이 됩니다. 반드시 한 명의 구체적 페르소나를 정하세요.
요구사항·기능·기술은 같은 말이 아닙니다. "뭘 원하나(요구사항) → 뭘 만드나(기능) → 어떻게 만드나(기술)"로 추상화 수준이 다릅니다. 섞으면 설계가 흐려집니다.
순서를 거꾸로 하면 안 됩니다. 화면부터 그리거나 기능부터 정하면 곤란합니다. 항상 사용자 → 요구사항 → 기능 → 화면 순입니다.
MVP는 "대충 만들기"가 아닙니다. 핵심을 제대로, 다만 범위를 좁혀 만드는 겁니다. 나머지는 검증 후 추가합니다.

✅ 30초 정리

설계가 먼저다. 코딩 전에 지도(설계)부터 그려야 헤매지 않습니다. 설계 없이 시작하면 일정이 2~3배 늘고, 요구사항 결함은 뒤로 갈수록 100배 비쌉니다.
설계 4단계는 사용자 → 요구사항 → 기능 → 화면. 한 명의 페르소나(김대리)에서 출발해, 그의 말을 요구사항으로 번역하고, 기능·기술로 구체화한 뒤(추적 매트릭스), MVP로 좁혀 화면에 배치합니다.
배운 것이 곧 기능이 된다. 수집·전처리·분석·시각화가 그대로 앱 기능이 되고, 이를 Streamlit·FastAPI·SQLite의 3-tier로 조립하면 김대리를 위한 리뷰 분석 대시보드 설계도가 완성됩니다.

▶️ 다음 강 연결

오늘 그린 설계도의 맨 아래에 데이터베이스(SQLite)가 있었죠. 다음 4강 데이터베이스 기초(36차시)에서는 이 바닥부터 쌓아 올립니다. "데이터를 어디에 저장할까?"라는 질문에서 출발해 — 엑셀과 DB의 차이, 파일 하나로 끝나는 DB인 SQLite, 그리고 데이터를 다루는 기본기인 CRUD(조회·추가·수정·삭제)를 배우고, 설계도에 적었던 reviews·analysis_results 두 테이블을 실제로 만들어 나갑니다.