AS-IS TO-BE로 보면 이 기획이 말이 된다

07 Dec, 2025
- PRD

AS-IS TO-BE로 보면 이 기획이 말이 된다

또 왜냐고 묻더라

회의실. 개발팀장이 물었다.

“이 기능 왜 만들어요?”

기획서 12페이지. 유저 플로우 3개. 예상 효과까지 썼다.

그래도 묻는다. 왜.

숨 한번 쉬고 화이트보드 들었다.

“AS-IS TO-BE로 보면요.”

왼쪽에 현재. 오른쪽에 목표.

3분 만에 이해했다. 질문 끝.

이게 6년차에 배운 거다.

1년 전 나는 설명을 못했다

기획서를 길게 썼다.

배경, 목적, 기대효과, 상세기능, 예외케이스.

A4 20장. 2주 걸렸다.

대표님이 물었다. “한 줄로 요약하면?”

버벅댔다. “그러니까… 유저가…”

답을 못했다.

내가 뭘 기획한 건지 모르겠더라.

디자이너가 물었다. “지금 화면이랑 뭐가 달라져요?”

또 버벅였다. “일단… 버튼이 추가되고…”

그게 다였다. 버튼 추가.

왜 추가하는지 설명 못했다.

개발자가 말했다. “스펙이 불명확해요.”

화났다. 20장이나 썼는데.

지금 생각하면 맞는 말이었다.

나도 몰랐으니까. 뭘 만드는지.

선배가 알려준 프레임워크

점심 먹다가 토로했다.

“기획서 써도 이해를 못 해요.”

선배가 웃었다. 8년차 PM.

“AS-IS TO-BE 써봤어?”

처음 들었다.

선배가 노션 켰다.

기획서 첫 장. 표 하나.

구분	AS-IS	TO-BE
현재	…	…
목표	…	…

“이것만 명확하면 돼.”

그게 다였다.

“현재 뭐가 문제야?”

“목표는 뭐야?”

“어떻게 바뀌는 거야?”

세 질문.

이걸 답하면 기획이 된다고 했다.

반신반의했다. 너무 간단해서.

첫 적용, 회원가입 개선

다음 프로젝트. 회원가입 개선.

일단 AS-IS 썼다.

AS-IS (현재 상태)

회원가입 7단계
완료율 42%
평균 소요시간 3분 20초
이탈 지점: 본인인증(38%), 약관동의(25%)
유저 피드백: “너무 복잡해요” (CS 월 230건)

구체적으로 썼다. 숫자로.

TO-BE 정의했다.

TO-BE (목표 상태)

회원가입 3단계
완료율 목표 65%
평균 소요시간 1분 30초
소셜 로그인 우선 노출
필수 정보만 1차 수집, 나머지는 사용 중 수집

변화가 명확했다. 7단계 → 3단계.

이걸 기획서 첫 장에 넣었다.

페이지 수 12장 → 6장.

설명 시간 30분 → 10분.

질문 거의 없었다.

개발팀장이 말했다. “이제 이해됐어요.”

왜 이게 작동하는가

3개월 써보니 알았다.

사람들은 “변화”를 이해하고 싶어 한다.

기획서는 보통 목표만 쓴다.

“회원가입을 개선한다.”

현재가 없다. 비교 불가.

얼마나 개선되는지 모른다.

AS-IS TO-BE는 변화를 보여준다.

변화 = TO-BE - AS-IS

이게 기획의 가치다.

현재 7단계 → 목표 3단계 = 4단계 개선.

숫자로 보인다. 명확하다.

대표님이 좋아하는 이유.

“투자 대비 효과”가 보인다.

개발 2주 → 완료율 23%p 상승.

ROI 계산 가능.

개발자가 좋아하는 이유.

“왜 만드는지” 명확하다.

현재 문제 → 해결 방향.

동기부여 된다.

디자이너가 좋아하는 이유.

“비포 애프터”가 명확하다.

화면 개선 방향 잡힌다.

레퍼런스 찾기 쉽다.

실전 적용 3가지 케이스

케이스 1: 검색 기능 개선

AS-IS

검색 결과 없음: 43%
재검색률: 67%
이탈률: 52%
검색어 자동완성 없음
오타 보정 없음

TO-BE

검색 결과 없음: 목표 15%
연관 검색어 제안
오타 자동 보정
인기 검색어 노출
검색 히스토리 저장

변화: 검색 실패 → 검색 성공.

개발 공수: 3주.

예상 효과: 검색 성공률 28%p 상승.

승인까지 2일.

케이스 2: 결제 플로우 단순화

AS-IS

결제 5단계
결제 완료율 68%
평균 소요 시간 2분 40초
이탈 지점: 배송지 입력(45%)
모바일 결제 포기율 38%

TO-BE

결제 3단계
결제 완료율 목표 82%
배송지 자동 불러오기
간편결제 우선 노출
원클릭 결제 옵션

변화: 클릭 수 감소. 완료율 증가.

개발 공수: 4주.

예상 매출 증가: 월 1,200만원.

CFO가 바로 승인했다.

케이스 3: 푸시 알림 재설계

AS-IS

푸시 발송: 하루 평균 8건
오픈율: 12%
설정 해제율: 주 3.2%
타이밍: 오전 10시 일괄 발송
개인화 없음

TO-BE

푸시 발송: 유저당 하루 최대 3건
오픈율 목표: 25%
AI 기반 발송 시간 최적화
유저 행동 기반 개인화
알림 카테고리 선택 가능

변화: 스팸 → 유용한 정보.

개발 공수: 2주.

예상 효과: 재방문율 15% 증가.

마케팅팀이 환호했다.

AS-IS 작성할 때 팁

현재를 객관적으로 써야 한다.

주관 빼고. 숫자로.

나쁜 예시 “현재 회원가입이 복잡함”

얼마나 복잡한지 모른다.

좋은 예시 “현재 회원가입 7단계, 완료율 42%, 평균 3분 20초 소요”

측정 가능하다. 비교 가능하다.

AS-IS 작성 체크리스트:

데이터 없으면 추정한다.

“CS 문의 주 평균 50건” “유저 인터뷰 10명 중 7명 불편 호소” “경쟁사 대비 2단계 더 많음”

완벽하지 않아도 된다.

없는 것보단 낫다.

TO-BE 작성할 때 팁

목표는 현실적이어야 한다.

나쁜 예시 “완료율 100%”

불가능하다. 신뢰 떨어진다.

좋은 예시 “완료율 42% → 65% (목표)”

달성 가능하다. 근거 있다.

TO-BE 작성 체크리스트:

목표 설정 근거:

경쟁사 벤치마크 “네이버는 3단계, 카카오는 2단계”
과거 데이터 “작년 A 기능 개선 시 15% 상승”
유저 리서치 “10명 중 8명이 3단계가 적당하다고 응답”

숫자에 이유를 단다.

설명이 쉬워진다

이제 어떤 질문에도 답한다.

“왜 만들어요?” → “AS-IS가 이래서 TO-BE로 가려고요.”

“얼마나 좋아져요?” → “42%에서 65%로 예상돼요.”

“꼭 해야 해요?” → “현재 이탈률 58%인데 개선 안 하면 더 오를 거예요.”

“다른 방법은 없어요?” → “이 방법이 가장 빠르고 효과적이에요. AS-IS TO-BE 비교표 보시면…”

한 방에 끝난다.

설득이 쉬워졌다.

표 하나면 된다.

말 많이 안 해도 된다.

회의 시간 절반 줄었다.

전: 1시간 후: 30분

질문 80% 감소.

복잡한 기획도 단순해진다

3개월 전. 앱 전면 개편 기획.

120개 화면. 기능 50개.

막막했다.

AS-IS TO-BE로 쪼갰다.

화면별로. 기능별로. 유저 플로우별로.

메인 화면

AS-IS: 최신순 나열, 평균 체류 28초
TO-BE: 개인화 추천, 목표 체류 60초

마이페이지

AS-IS: 5depth, 원하는 기능 찾기 어려움
TO-BE: 2depth, 자주 쓰는 기능 상단 고정

알림 센터

AS-IS: 시간순 나열, 확인률 23%
TO-BE: 중요도 기반 정렬, 목표 확인률 45%

50개 기능 → 50개 AS-IS TO-BE.

대표님이 말했다.

“이제 보이네요. 왜 개편하는지.”

4개월 프로젝트 승인.

개발 시작.

이해관계자 설득에 최적

마케팅팀과 싸웠다.

“푸시 더 보내야죠!”

나: “오픈율 12%인데요.”

마케팅: “그래도 보내야 해요!”

AS-IS TO-BE 보여줬다.

AS-IS

하루 8건 발송
오픈율 12%
푸시 해제율 주 3.2%
3개월 후 푸시 수신 유저 0명 예상

TO-BE

하루 3건 발송 (선별)
오픈율 목표 25%
푸시 유지율 상승
장기 채널 확보

마케팅팀 조용해졌다.

”…그럼 개인화 로직은?”

협의 시작.

경영진 보고도 마찬가지.

숫자 좋아한다.

변화 좋아한다.

AS-IS TO-BE면 충분하다.

실무에서 쓰는 템플릿

노션에 템플릿 만들었다.

## AS-IS TO-BE 분석

### AS-IS (현재 상태)
- 측정 지표 1:
- 측정 지표 2:
- 측정 지표 3:
- 주요 문제점:
- 데이터 출처:

### TO-BE (목표 상태)
- 목표 지표 1:
- 목표 지표 2:
- 목표 지표 3:
- 개선 방향:
- 달성 기간:

### GAP 분석
- 변화량:
- 필요 리소스:
- 예상 효과:
- 리스크:

### 실행 계획
- 1단계:
- 2단계:
- 3단계:

모든 기획에 쓴다.

5분이면 작성 가능하다.

처음엔 10분 걸렸다.

지금은 자동이다.

팀원들도 쓰게 했다.

처음엔 귀찮아했다.

2주 후 모두 쓴다.

“설명하기 편해요.”

6개월 후 변화

기획서 페이지 수: 20장 → 8장.

승인 기간: 2주 → 3일.

개발 착수 지연: 40% → 5%.

회의 시간: 평균 1시간 → 30분.

“스펙 불명확” 지적: 주 5회 → 주 1회.

숫자로 증명됐다.

AS-IS TO-BE가 작동한다.

대표님이 말했다.

“기획이 명확해졌어요.”

최고의 칭찬.

주의할 점

AS-IS TO-BE가 만능은 아니다.

안 맞는 경우:

신규 서비스 (AS-IS 없음)
탐색적 프로젝트
컨셉 기획 단계

이럴 땐 다른 프레임워크.

흔한 실수:

AS-IS를 부정적으로만 씀
TO-BE가 너무 이상적
측정 불가능한 목표
숫자 없이 감으로

객관성 잃으면 의미 없다.

보완 방법:

유저 리서치 함께
데이터 분석 병행
프로토타입 검증
A/B 테스트 계획

AS-IS TO-BE는 시작이다.

지금도 쓴다

오늘도 기획서 썼다.

첫 장. AS-IS TO-BE.

10분 걸렸다.

슬랙에 공유했다.

개발팀장: “명확하네요. 이번 주 스프린트에 넣을게요.”

디자이너: “화면 컨셉 잡혔어요.”

마케팅: “예상 효과 공유 부탁드려요.”

질문 끝.

퇴근길 지하철.

주니어한테 DM 왔다.

“선배님, AS-IS TO-BE 어떻게 쓰는 거예요?”

템플릿 보냈다.

“한번 써봐. 세상이 달라질 거야.”

6년차가 1년차한테 배운 거.

또 전달한다.

기획은 복잡하지 않다.

현재 → 목표.

이게 전부다.

AS-IS TO-BE로 보면,

모든 기획이 말이 된다.

내일 회의. 새 프로젝트.

AS-IS TO-BE 준비했다. 또 설득한다.