@extends('layouts.app') @section('title', 'IT기획 백과사전') @push('styles') @endpush @section('content')
아카데미 IT기획

IT기획 백과사전

IT 기획의 정의부터 프로세스, 산출물, 도구, 방법론까지 체계적 학습 자료

IT 기획자가 화이트보드에서 설계하는 모습
{{-- ============================================================ --}} {{-- 1. 개요 --}} {{-- ============================================================ --}}

1 개요

IT 기획이란?

IT 기획(IT Planning)이란 비즈니스 목표를 달성하기 위해 IT 서비스와 제품을 구상, 설계, 구체화하는 과정이다. 사용자의 문제를 정의하고, 해결책을 설계하며, 개발팀이 구현할 수 있는 명확한 산출물을 만들어내는 것이 핵심이다.

기획자 역할 다이어그램

기획자의 역할과 위치

기획자는 비즈니스 팀개발 팀 사이에서 번역자 역할을 수행한다. 경영진의 비전을 구체적인 기능 요구사항으로 변환하고, 사용자 경험을 설계하여 개발팀에 전달한다.

단순히 문서를 작성하는 것이 아니라, 프로젝트의 방향을 결정하고 이해관계자들의 의견을 조율하며, 제한된 자원 안에서 최적의 결과물을 이끌어내는 의사결정 허브이다.

핵심 역할: "무엇을(What) 만들 것인가"와 "왜(Why) 만들어야 하는가"를 정의한다. "어떻게(How) 만들 것인가"는 개발팀의 영역이다.

기획자의 종류

서비스 기획자 (Service Planner)

  • - 서비스 전체의 사용자 경험 설계
  • - 화면 설계서, 스토리보드 작성
  • - 사용자 리서치 및 데이터 분석
  • - 국내 IT 업계에서 가장 보편적인 직함

프로덕트 매니저 (Product Manager)

  • - 제품 전략 및 로드맵 수립
  • - 비즈니스 목표와 사용자 니즈 균형
  • - 데이터 기반 의사결정 (A/B 테스트 등)
  • - 글로벌 IT 기업에서 주로 사용하는 직함

UX 기획자 (UX Planner/Designer)

  • - 사용자 중심 설계 (User-Centered Design)
  • - 와이어프레임, 프로토타입 제작
  • - 사용성 테스트 및 개선
  • - 정보 구조(IA) 설계

프로젝트 매니저 (Project Manager)

  • - 프로젝트 일정, 범위, 리소스 관리
  • - 이해관계자 커뮤니케이션
  • - 리스크 관리 및 이슈 해결
  • - 기획보다는 관리(Management)에 초점

기획자에게 필요한 역량

논리적 사고력

복잡한 문제를 구조화하고, 원인과 결과를 분석하며, 체계적인 해결책을 도출하는 능력. MECE(Mutually Exclusive, Collectively Exhaustive) 원칙으로 빈틈 없이 분류한다.

커뮤니케이션

개발자, 디자이너, 경영진, 고객 등 다양한 이해관계자와 효과적으로 소통하는 능력. 기술 용어를 비즈니스 언어로, 비즈니스 요구를 기술 요구사항으로 변환한다.

기술 이해력

프론트엔드/백엔드, API, 데이터베이스 등 기술 구조를 이해하여 현실적인 기획을 수립하는 능력. 코딩을 직접 하진 않지만, 기술적 제약과 가능성을 판단한다.

데이터 분석력

사용자 행동 데이터, 시장 트렌드, 경쟁사 분석 등을 통해 근거 있는 의사결정을 내리는 능력. 감이 아닌 숫자로 설득한다.

기획자의 하루

09:00 데일리 스탠드업 — 어제 진행 사항 공유, 오늘 계획 발표, 블로커 확인
09:30 메일/슬랙 확인 — 이해관계자 요청사항 검토, 긴급 이슈 대응
10:00 기획 작업 — 화면 설계서 작성, PRD 업데이트, 와이어프레임 수정
11:00 개발팀 미팅 — 기획 리뷰, 기술적 피드백 수렴, QA 이슈 논의
13:00 데이터 분석 — GA/Mixpanel에서 사용자 행동 데이터 확인, 지표 리포트 작성
14:00 이해관계자 미팅 — 경영진 보고, 유관부서 협의, 요구사항 조율
15:00 디자이너 협업 — 목업 리뷰, UI 피드백, 디자인 시스템 논의
16:00 문서 정리 — JIRA 티켓 업데이트, 회의록 정리, 백로그 관리
17:00 스프린트 리뷰/회고 — (주 1회) 완성된 기능 데모, 개선점 도출
{{-- ============================================================ --}} {{-- 2. 기획 프로세스 --}} {{-- ============================================================ --}}

2 기획 프로세스

전체 프로세스 흐름도

IT 기획 전체 프로세스 흐름도

IT 기획 전체 프로세스 흐름도

요구사항 수집 분석 설계 개발 테스트 배포

각 단계는 반복적(Iterative)으로 수행되며, 피드백에 따라 이전 단계로 돌아갈 수 있다.

요구사항 수집 및 분석

이해관계자 인터뷰 장면

이해관계자 인터뷰

요구사항 수집은 기획의 첫 단추이다. 이 단계에서 방향이 잘못되면 이후 모든 작업이 무의미해진다.

수집 방법

  • 이해관계자 인터뷰 — 경영진, 실무자, 고객의 니즈를 1:1 면담으로 파악
  • 사용자 리서치 — 설문조사, 포커스 그룹, 사용성 테스트, 현장 관찰
  • 데이터 분석 — 기존 서비스의 로그, 이탈률, 전환율 등 정량 데이터 분석
  • 벤치마킹 — 경쟁사/유사 서비스의 기능과 UI 패턴 분석
  • VOC(Voice of Customer) — 고객센터 문의, 리뷰, SNS 피드백 수집

주의: "고객이 원하는 것"과 "고객에게 필요한 것"은 다를 수 있다. 헨리 포드의 명언 — "사람들에게 무엇을 원하냐고 물었다면, 더 빠른 말이라고 답했을 것이다."

시장 조사 및 경쟁 분석

시장과 경쟁사를 분석하여 서비스의 차별화 포인트시장 기회를 발견한다.

분석 유형 설명 활용 도구
SWOT 분석 강점/약점/기회/위협 파악 Miro, FigJam
경쟁사 분석 경쟁 서비스의 기능, UX, 가격 비교 스프레드시트, Notion
시장 규모 분석 TAM/SAM/SOM 산출 리서치 보고서
사용자 세그먼트 페르소나 정의, 고객 여정 맵핑 Figma, Miro

서비스 정의 및 범위 설정 (스코프 관리)

수집된 요구사항을 바탕으로 "무엇을 만들 것인가"의 범위를 명확히 정의한다. 범위가 불분명하면 스코프 크리프(Scope Creep) — 기능이 끝없이 추가되는 현상 — 가 발생한다.

In-Scope

이번 버전에 포함할 기능

Out-of-Scope

다음 버전으로 미루는 기능

Not Doing

하지 않기로 결정한 기능

우선순위 결정

제한된 시간과 리소스 안에서 무엇을 먼저 할 것인가를 결정하는 것은 기획자의 핵심 역량이다.

MoSCoW 방법

Must Have

반드시 필요

Should Have

있으면 좋음

Could Have

가능하면

Won't Have

이번엔 안 함

RICE 스코어

RICE = (Reach x Impact x Confidence) / Effort

  • Reach — 영향 받는 사용자 수 (분기당)
  • Impact — 사용자당 임팩트 (0.25 ~ 3)
  • Confidence — 확신도 (50% ~ 100%)
  • Effort — 소요 공수 (인/월)

Kano 모델

  • 기본 품질(Must-be) — 없으면 불만, 있어도 당연시 (예: 로그인 기능)
  • 성능 품질(One-dimensional) — 좋을수록 만족도 비례 증가 (예: 검색 속도)
  • 매력 품질(Attractive) — 없어도 불만 없지만, 있으면 감동 (예: AI 추천)
{{-- ============================================================ --}} {{-- 3. 기획 산출물 --}} {{-- ============================================================ --}}

3 기획 산출물

요구사항 정의서 (PRD)

PRD(Product Requirements Document)는 제품이 "무엇을 해야 하는가"를 정의하는 문서이다. 모든 이해관계자가 동일한 이해를 갖도록 하는 단일 진실 소스(Single Source of Truth) 역할을 한다.

PRD에 포함되는 항목

1. 프로젝트 개요 및 배경
2. 목표 및 핵심 지표(KPI)
3. 타깃 사용자 및 페르소나
4. 기능 요구사항 (상세 명세)
5. 비기능 요구사항 (성능, 보안)
6. 제약 조건 및 가정
7. 릴리즈 일정
8. 성공 기준 / 수용 기준

정보 구조도 (IA, Information Architecture)

정보 구조도(IA) 트리 다이어그램

IA 트리 다이어그램 예시

정보 구조도(IA)는 서비스의 전체 메뉴 체계와 콘텐츠 계층을 시각화한 문서이다. 사이트맵과 유사하지만 더 상세한 레벨의 구조를 포함한다.

IA 작성 원칙

  • - 사용자 멘탈 모델에 맞는 분류 체계
  • - 깊이(Depth)보다 폭(Breadth)을 우선 — 3~4단계 이내
  • - 각 메뉴명은 명확하고 예측 가능하게
  • - 카드소팅(Card Sorting) 기법으로 검증

화면 설계서 / 스토리보드

와이어프레임에서 프로토타입까지

Wireframe → Mockup → Prototype 진행 과정

단계 산출물 특징 목적
1단계 Wireframe 흑백, 레이아웃 중심 구조와 기능 배치 검증
2단계 Mockup 컬러, 폰트, 이미지 포함 시각적 디자인 확정
3단계 Prototype 클릭, 전환 인터랙션 포함 사용자 흐름 테스트

실무 팁: 모든 화면을 다 만들 필요 없다. 핵심 흐름(Critical Path)에 해당하는 화면만 먼저 설계하고, 나머지는 개발 진행과 병행하여 보완한다.

플로우차트 / 유저 플로우

유저 플로우는 사용자가 특정 목표를 달성하기까지의 단계별 경로를 시각화한 다이어그램이다.

유저 플로우 (User Flow)

사용자 관점의 화면 전환 흐름. 어떤 화면에서 어떤 행동을 하면 어디로 이동하는지를 표현.

플로우차트 (Flowchart)

시스템 로직 관점. 조건 분기(if/else), 반복, 예외 처리를 포함한 비즈니스 로직 흐름.

유저 플로우 다이어그램

유저 플로우 다이어그램 예시

유스케이스 / 유저 스토리

유스케이스 (Use Case)

시스템과 사용자 간의 상호작용을 상세히 기술한다.

UC-001: 회원가입

액터: 비회원 사용자

사전조건: 회원가입 페이지 접근

주요흐름:

1. 이메일 입력

2. 비밀번호 설정

3. 약관 동의

4. 가입 완료

대안흐름: 소셜 로그인

예외흐름: 중복 이메일

유저 스토리 (User Story)

사용자 관점에서 기능을 한 문장으로 표현한다.

"[사용자 유형]으로서, [기능]을 원한다. 왜냐하면 [가치] 때문이다."

"신규 사용자로서, 소셜 로그인을 원한다. 왜냐하면 빠르게 서비스를 체험하고 싶기 때문이다."

"관리자로서, 사용자 목록 필터를 원한다. 왜냐하면 특정 조건의 사용자를 빠르게 찾고 싶기 때문이다."

기능 명세서 (Functional Specification)

기능 명세서는 각 기능이 "어떻게 동작해야 하는가"를 개발자가 구현할 수 있을 만큼 구체적으로 기술한 문서이다.

항목 예시
기능 ID FN-LOGIN-001
기능명 이메일 로그인
입력값 이메일(필수), 비밀번호(필수)
검증 규칙 이메일 형식, 비밀번호 8자 이상
성공 시 대시보드로 리다이렉트, 세션 생성
실패 시 에러 메시지 표시, 5회 실패 시 잠금

데이터 모델 / ERD

ERD(Entity-Relationship Diagram)는 데이터베이스의 테이블(엔티티)과 관계를 시각화한 다이어그램이다. 기획자가 직접 작성하기보다 개발자와 협업하여 도출하는 경우가 많다.

기획자가 알아야 할 ERD 기초

  • 엔티티(Entity) — 테이블, 데이터의 단위 (예: 회원, 주문, 상품)
  • 속성(Attribute) — 컬럼, 엔티티의 세부 정보 (예: 이름, 이메일, 가격)
  • 관계(Relationship) — 엔티티 간의 연결 (1:1, 1:N, N:M)
  • PK(Primary Key) — 각 레코드를 유일하게 식별하는 키
  • FK(Foreign Key) — 다른 테이블과의 관계를 나타내는 키

기획자의 역할: ERD를 직접 그리지 않더라도, 화면에 필요한 데이터가 무엇인지(어떤 정보를 저장하고, 조회하고, 수정하는지)를 명확히 정의하면 개발자가 적절한 DB 구조를 설계할 수 있다.

{{-- ============================================================ --}} {{-- 4. 기획 도구 --}} {{-- ============================================================ --}}

4 기획 도구

Figma UI 디자인 작업 화면

Figma 작업 화면

IT 기획자가 업무에 사용하는 도구는 크게 6가지 카테고리로 나눌 수 있다. 도구 자체보다 어떤 목적으로 사용하는가가 더 중요하다.

문서 작성

Notion

올인원 워크스페이스. 문서, DB, 칸반, 위키를 하나로 통합. 스타트업에서 가장 인기.

Confluence

Atlassian 생태계. Jira와 연동이 강점. 대기업/중견기업에서 주로 사용.

Google Docs

실시간 협업 편집. 접근성이 좋고 무료. 빠른 초안 작성에 적합.

화면 설계

Figma

브라우저 기반 디자인 도구. 실시간 협업, 프로토타이핑, 디자인 시스템 관리. 업계 표준.

Sketch

macOS 전용. 가볍고 빠름. 플러그인 생태계 풍부. Figma에 점유율 추월당한 상태.

Adobe XD

Adobe 생태계 연동. Photoshop/Illustrator 사용자에게 친숙. 2024년 서비스 종료 예정.

프로젝트 관리

Jira

스프린트/칸반 보드. 이슈 트래킹의 표준.

Trello

직관적 칸반 보드. 소규모 팀에 적합.

Asana

타임라인/리스트/보드 뷰. 마케팅팀에 인기.

Linear

빠르고 깔끔한 UI. 개발팀 중심. 최근 급부상.

다이어그램

Miro

무한 화이트보드. 브레인스토밍, 마인드맵, 워크숍에 최적.

Draw.io

무료 오픈소스 다이어그램. ERD, 플로우차트, 시스템 구성도.

Lucidchart

전문 다이어그램 도구. 실시간 협업, 템플릿 풍부.

프로토타이핑

Figma Prototype

디자인과 프로토타입을 하나의 도구에서. 트랜지션, 인터랙션 설정.

InVision

이미지 기반 프로토타이핑. 간단한 클릭 흐름 테스트.

Framer

코드 수준 인터랙션. 실제 웹사이트처럼 동작하는 프로토타입.

데이터 분석

Google Analytics

웹 트래픽 분석의 표준. 페이지뷰, 이탈률, 전환율 추적.

Mixpanel

이벤트 기반 분석. 퍼널, 리텐션, A/B 테스트. 제품 분석에 강점.

Amplitude

사용자 행동 분석. 코호트 분석, 경로 분석. 데이터 기반 PM에 필수.

{{-- ============================================================ --}} {{-- 5. 기획 방법론 --}} {{-- ============================================================ --}}

5 기획 방법론

워터폴 (Waterfall)

전통적인 순차적(Sequential) 개발 방법론. 각 단계가 완료된 후 다음 단계로 넘어가며, 이전 단계로 돌아가기 어렵다.

요구분석 설계 개발 테스트 배포 유지보수

장점

  • - 명확한 단계와 산출물
  • - 관리와 추적이 용이
  • - 문서화가 철저

단점

  • - 변경 대응이 어려움
  • - 완성까지 결과물 확인 불가
  • - 긴 개발 주기

애자일 (Agile)

반복(Iterative)점진적(Incremental) 개발을 핵심으로 하는 방법론. 2~4주 단위의 스프린트로 작은 단위의 기능을 지속적으로 배포한다.

스크럼 보드와 스프린트 미팅

스크럼 보드와 스프린트 미팅

스크럼 (Scrum)

  • - 2~4주 스프린트 주기
  • - 데일리 스탠드업 (15분)
  • - 스프린트 리뷰 & 회고
  • - PO, SM, Dev Team 역할 분리

칸반 (Kanban)

  • - 스프린트 없이 지속적 흐름
  • - WIP(Work In Progress) 제한
  • - 시각적 보드로 병목 파악
  • - 운영/유지보수에 적합

린 스타트업 (Lean Startup)

에릭 리스(Eric Ries)가 제안한 방법론. 가설 → 실험 → 학습의 반복 사이클로 낭비를 최소화하고 빠르게 시장 검증한다.

Build

MVP 개발

Measure

데이터 측정

Learn

학습/피벗

핵심 개념

  • MVP(Minimum Viable Product) — 핵심 기능만 포함한 최소 제품. 빠르게 시장에 출시하여 피드백 수집.
  • Pivot — 가설이 틀렸을 때 방향을 전환하는 것. 실패가 아니라 학습의 결과.
  • Validated Learning — 데이터를 통해 검증된 학습. 감이 아닌 증거 기반 의사결정.

디자인 씽킹 (Design Thinking)

스탠포드 d.school에서 체계화한 인간 중심(Human-Centered) 문제 해결 방법론. 사용자에 대한 깊은 공감에서 출발한다.

디자인 씽킹 5단계

디자인 씽킹 5단계 프로세스

1

공감

Empathize

2

정의

Define

3

아이디어

Ideate

4

프로토타입

Prototype

5

테스트

Test

실무 적용 사례

기획자-개발자-디자이너 협업

기획자-개발자-디자이너 협업 장면

실무에서는 하나의 방법론만 고수하기보다 상황에 맞게 혼합(Hybrid)하여 사용한다.

상황 추천 방법론 이유
신규 서비스 런칭 린 스타트업 + 디자인 씽킹 시장 불확실성 높음, 빠른 검증 필요
기존 서비스 개선 애자일 (스크럼) 점진적 개선, 정기 배포 주기
대규모 SI 프로젝트 워터폴 + 애자일 혼합 계약/산출물 필수, 단계별 검수
운영/유지보수 칸반 비정형 업무, 우선순위 수시 변경
UX 개선 프로젝트 디자인 씽킹 + 애자일 사용자 공감에서 출발, 반복 검증
데이터 분석 대시보드

데이터 기반 의사결정 — 분석 대시보드

핵심 정리

IT 기획은 단순한 문서 작성이 아니라, 비즈니스 가치를 기술적 솔루션으로 전환하는 과정이다. 좋은 기획자는 사용자를 깊이 이해하고, 데이터로 의사결정하며, 팀과 효과적으로 소통한다. 어떤 방법론을 사용하든 핵심은 "사용자에게 가치를 전달하는 것"이다.

@endsection