기획·리서치 워크플로

기획자와 리서치 실무자의 하루는 생각보다 덜 화려하다. 새로운 아이디어를 떠올리는 시간보다 자료를 읽고, 비교하고, 기준을 정리하고, 결국 문서로 남기는 시간이 훨씬 길다. 문제는 이 과정이 늘 비슷하게 반복된다는 데 있다. 회의 전에는 자료를 요약해야 하고, 대안을 검토할 때는 비교표를 만들어야 하며, 결정 직전에는 판단 기준을 정리해야 하고, 마지막에는 보고서 초안을 써야 한다. 일이 바뀌는 것 같아도 뼈대는 늘 비슷하다.

중급 프롬프트의 관점에서 보면 이 업무는 "자료를 읽고 똑똑하게 정리해 줘" 같은 한 문장짜리 부탁으로 끝나지 않는다. 입력이 무엇인지, 어떤 관점으로 읽을지, 어떤 형식으로 비교할지, 의사결정에 어떤 기준을 쓸지, 보고서 초안은 누구를 위한 문서인지까지 설계해야 한다. 기획·리서치 업무에서 AI를 잘 쓴다는 것은 문장을 잘 만드는 것이 아니라, 판단에 필요한 중간 산출물을 차례대로 만들어 가는 것이다.

이 장에서는 자료 요약, 비교표 작성, 의사결정 기준 정리, 보고서 초안 작성으로 이어지는 흐름을 하나의 워크플로로 묶어 보겠다. 핵심은 간단하다. AI를 검색 엔진처럼 한 번 쓰고 끝내지 말고, 기획 문서가 만들어지는 순서대로 연결하는 것이다.

기획·리서치 업무를 네 단계로 나누기

기획·리서치 업무는 얼핏 복잡해 보여도 네 단계로 나누면 훨씬 다루기 쉬워진다.

이 표에서 중요한 것은 AI의 역할이 모든 판단을 대신하는 것이 아니라는 점이다. 기획자는 기준을 정하고, AI는 그 기준에 맞게 재료를 정리한다. 좋은 워크플로는 이 역할 분담이 분명하다.

시작점은 "자료를 읽기 전에 질문을 정하는 것"이다

리서치가 엉키는 가장 흔한 이유는 자료가 부족해서가 아니라 질문이 흐릿해서다. 질문이 흐리면 요약도 길어지고, 비교표도 애매해지고, 보고서도 결론 없는 친절한 메모가 된다.

예를 들어 "협업 툴을 바꿔야 할까?"라는 질문은 너무 넓다. 대신 이렇게 바꾸면 워크플로가 살아난다.

• 우리 50인 규모 팀에 맞는 협업 툴 후보 3개를 비교한다.

• 기준은 도입 비용, 온보딩 난이도, 외부 협업 기능, 보안 옵션, 자동화 연동성이다.

• 최종 산출물은 팀장 검토용 2페이지 제안서 초안이다.

이렇게 바꾸는 순간 AI에게 맡길 수 있는 작업 단위가 생긴다. 무엇을 읽고, 무엇을 남기고, 무엇을 버려야 하는지가 보이기 시작한다.

실무에서는 자료를 붙여 넣기 전에 먼저 아래 네 가지를 적어 두는 습관이 좋다.

이 네 줄이 있으면 프롬프트가 훨씬 안정된다. AI는 자료를 읽는 기계이기도 하지만, 기준이 주어졌을 때 훨씬 더 유능해지는 정리 도구이기도 하다.

1단계: 자료 요약은 "전체 요약"보다 "목적 있는 요약"이 중요하다

기획자가 문서를 읽는 이유는 감상문을 쓰기 위해서가 아니다. 다음 판단에 필요한 정보를 추려 내기 위해서다. 그래서 자료 요약 단계에서는 "중요한 내용을 요약해 줘"보다 "무엇을 남길지"를 먼저 정해야 한다.

예를 들어 서비스 기획자가 경쟁사 기능 문서를 읽는 상황이라면, 모든 내용을 똑같이 압축하는 요약은 큰 도움이 안 된다. 대신 가격 정책, 핵심 기능, 차별점, 도입 장벽, 우리 서비스에 주는 시사점처럼 목적 중심으로 자르는 편이 훨씬 낫다.

다음처럼 요청하면 좋다.

다음 자료를 서비스 도입 검토 관점에서 요약하라.
반드시 아래 항목으로 나눠서 정리하라.
1) 핵심 기능
2) 도입 비용 관련 정보
3) 보안·권한 관리 관련 정보
4) 외부 협업 기능
5) 우리 팀 도입 시 장점
6) 우리 팀 도입 시 우려 사항
자료에 없는 내용은 추정하지 말고 '자료 없음'이라고 표시하라.
마지막에는 5문장 이내의 요약 결론을 추가하라.

이 프롬프트가 좋은 이유는 단순하다. 다음 단계인 비교표 작성에 바로 쓸 수 있는 형태로 요약을 받아내기 때문이다. 중급 실무에서는 멋진 요약보다 다음 작업으로 넘기기 쉬운 요약이 더 가치 있다.

또 한 가지 중요한 점은 여러 자료를 한꺼번에 넣었을 때다. 이때 AI는 종종 자료별 차이를 지워 버리고 평균적인 문장을 만들어 낸다. 그래서 여러 자료를 다룰 때는 먼저 자료별 요약을 만들고, 그다음 공통점과 차이점을 묶는 2단계 방식을 쓰는 편이 안정적이다.

먼저 자료별 요약을 만들고, 그다음 이렇게 요청한다.

아래 세 개의 요약을 비교해 공통점과 차이점을 정리하라.
공통점과 차이점은 반드시 판단 가능한 문장으로 쓰고,
모호한 표현 대신 비교 가능한 항목명으로 묶어라.
예: 가격 구조, 관리자 기능, 외부 공유 방식, 보안 통제 수준

이렇게 하면 AI가 정보를 섞어 버리는 문제를 줄일 수 있다.

2단계: 비교표는 "예쁜 표"가 아니라 "결정 가능한 표"여야 한다

비교표를 만드는 이유는 보기 좋게 정리하기 위해서가 아니다. 선택지를 좁히기 위해서다. 그래서 비교표는 항목이 많다고 좋은 것이 아니라, 판단을 움직일 정도로 날카로운 항목이 들어 있어야 좋다.

초보자는 비교표에 흔히 이런 항목을 넣는다. "장점", "단점", "특징". 읽기는 쉽지만 결정에는 약하다. 중급 실무자는 대신 "월간 비용 구조", "권한 세분화 가능 여부", "외부 사용자 초대 방식", "API 또는 자동화 연동 지원 여부"처럼 확인 가능한 항목을 넣는다.

예를 들어 협업 툴 검토라면 이런 표가 더 유용하다.

이 표의 장점은 각 칸이 의견만 담지 않는다는 데 있다. 사실, 기능, 해석이 섞여 있지만 최소한 비교 축이 분명하다. 기획 실무에서는 바로 이런 표가 회의를 살린다.

비교표를 만들 때 AI에게는 항목 생성과 내용 채우기를 한 번에 맡길 수도 있지만, 더 안정적인 방법은 두 단계로 나누는 것이다. 먼저 항목 후보를 만들고, 사람이 그중 필요한 것을 고른 뒤, 그다음 표를 채운다.

첫 단계 프롬프트는 이렇게 만들 수 있다.

아래 검토 목적에 맞는 비교표 항목 후보를 10개 제안하라.
목적: 우리 팀에 맞는 협업 툴 도입 검토
조건: 실제 의사결정에 도움이 되는 항목만 제안하고,
막연한 항목(예: 장점, 단점, 특징)은 제외하라.
각 항목 옆에 왜 필요한지 한 줄 설명을 붙여라.

그다음 사람이 5~7개 항목을 고른 뒤, 표 작성 프롬프트로 이어 간다.

선정된 비교 항목만 사용해 표를 작성하라.
정보가 확인되지 않은 칸은 비워 두지 말고 '확인 필요'라고 적어라.
각 셀은 2문장 이내로 간결하게 작성하라.
마지막 행에는 '한줄 판단'을 추가하라.

이렇게 하면 AI가 스스로 비교 기준을 너무 넓히거나, 근거 없이 칸을 채워 넣는 문제를 줄일 수 있다.

3단계: 의사결정 기준 정리는 "느낌"을 "문장"으로 바꾸는 과정이다

기획 회의에서 자주 나오는 말이 있다. "이건 좀 아닌 것 같아요." 문제는 모두가 고개를 끄덕이지만, 왜 아닌지 문서에는 남지 않는다는 점이다. 의사결정 기준 정리는 바로 이 흐릿한 느낌을 평가 가능한 문장으로 바꾸는 작업이다.

예를 들어 협업 툴을 고를 때 "사용성이 좋아야 한다"는 기준은 너무 넓다. 대신 "새로운 팀원이 1시간 내 기본 사용법을 익힐 수 있어야 한다"라고 바꾸면 판단 가능한 기준이 된다. "보안이 중요하다"도 마찬가지다. "관리자 권한을 역할별로 나눌 수 있어야 한다"처럼 바꾸면 비교 가능한 기준이 된다.

AI는 이런 기준 문장화를 도와줄 때 특히 유용하다. 막연한 평가 항목을 구체적인 판단 문장으로 바꾸는 데 강하기 때문이다.

다음 프롬프트를 보자.

아래의 막연한 평가 기준을 실제 의사결정에 쓸 수 있는 문장으로 바꿔라.
각 기준은 '무엇을 확인하면 충족으로 볼 수 있는지'가 드러나야 한다.
입력 기준: 사용성, 보안, 협업 편의성, 자동화, 비용 효율성
출력 형식: 기준명 | 판단 문장 | 확인 방법 예시

이렇게 요청하면 회의용 추상어가 검토용 문장으로 바뀐다. 예시는 다음과 같은 느낌이 될 수 있다.

기획자가 여기서 해야 할 일은 이 기준을 그대로 믿는 것이 아니라, 실제 조직 상황에 맞게 다듬는 것이다. 예를 들어 스타트업이라면 "도입 속도"의 가중치가 높을 수 있고, 대기업이라면 "권한 통제"가 더 중요할 수 있다. AI는 초안을 만드는 데 유능하지만, 우선순위를 정하는 책임까지 넘겨서는 안 된다.

4단계: 보고서 초안은 "자료 나열"이 아니라 "판단 흐름"으로 써야 한다

많은 사람이 AI로 보고서를 쓰면 문장이 부드러워진다고 생각한다. 맞는 말이다. 하지만 실무에서 더 중요한 것은 문장력보다 구조다. 특히 기획·리서치 문서는 예쁘게 쓰는 것보다, 왜 이런 결론에 도달했는지가 보이게 써야 한다.

좋은 초안은 보통 다음 순서를 따른다.

이 구조는 화려하지 않지만 강하다. 읽는 사람 입장에서 "그래서 왜 이 결론인가?"를 따라가기 쉽기 때문이다.

AI에게 초안을 요청할 때는 문체보다 먼저 포함 요소를 잠가 두는 것이 좋다.

아래 자료를 바탕으로 팀장 검토용 제안서 초안을 작성하라.
문서 목적은 협업 툴 도입 방향 제안이다.
구성은 다음 순서를 따른다.
1) 검토 배경
2) 비교 대상과 범위
3) 핵심 발견 3가지
4) 비교 결과 요약
5) 의사결정 기준
6) 추천안과 이유
7) 추가 확인 필요 사항
조건:
- 자료에 없는 내용은 단정하지 말 것
- 추천안은 반드시 장점과 리스크를 함께 쓸 것
- 한 문단은 4문장 이내로 유지할 것
- 마지막에 임원 보고용 5줄 요약을 별도로 붙일 것

이 프롬프트의 포인트는 "보고서처럼 써 줘"라고 하지 않는 데 있다. 보고서의 구조와 독자를 먼저 고정해 두었기 때문에, 초안이 훨씬 실무적으로 나온다.

한 번에 끝내지 말고, 중간 산출물을 넘겨 가라

기획·리서치 워크플로에서 자주 실패하는 이유는 모든 일을 한 프롬프트에 몰아넣기 때문이다. 자료 다섯 개를 넣고, 요약도 하고, 비교도 하고, 추천안도 뽑고, 임원 보고 문구까지 달라고 하면 그럴듯한 문장은 나올 수 있어도 판단의 밀도는 낮아진다.

실무에서는 오히려 중간 산출물을 저장하면서 가는 편이 훨씬 낫다. 예를 들어 이런 흐름이다.

이 방식의 장점은 중간에 틀어진 부분을 바로잡기 쉽다는 것이다. 요약이 흔들리면 비교표도 흔들리고, 비교표가 흔들리면 보고서 초안도 힘을 잃는다. 그래서 중간 결과를 확인하는 것이 곧 품질 관리다.

실무용 프롬프트 세트 만들기

이 장의 내용을 실제 업무에 적용하려면, 하나의 긴 프롬프트보다 짧은 프롬프트 세트를 준비해 두는 편이 좋다. 기획·리서치 업무는 반복되기 때문이다. 아래는 그대로 응용할 수 있는 기본 세트다.

자료 요약 프롬프트

역할: 너는 기획 검토를 돕는 리서치 보조자다.
목적: 아래 자료를 다음 의사결정에 바로 쓸 수 있게 요약한다.
검토 주제: [주제 입력]
중점 관점: [비용/사용성/보안/시장성 등 입력]
출력 형식:
- 핵심 내용
- 중요 수치 또는 사실
- 장점
- 우려 사항
- 우리 팀에 주는 시사점
규칙:
- 자료에 없는 내용은 추정하지 말 것
- 중복 표현은 제거할 것
- 마지막에 3문장 요약을 붙일 것

비교표 프롬프트

아래 요약본들을 바탕으로 비교표를 작성하라.
비교 대상: [대상 입력]
비교 항목: [항목 입력]
출력 조건:
- 표 형식으로 작성
- 각 셀은 짧고 비교 가능하게 작성
- 정보가 없으면 '확인 필요'라고 표시
- 마지막 행에 '추천 상황'을 추가

의사결정 기준 프롬프트

다음 비교표를 바탕으로 의사결정 기준을 정리하라.
목표는 회의에서 선택 기준을 명확히 하는 것이다.
출력 형식:
기준명 | 왜 중요한가 | 충족 판단 문장 | 추가 확인 필요 사항
조건:
- 추상어 대신 검토 가능한 문장 사용
- 우리 조직 상황에 따라 중요도가 갈릴 수 있으면 그 이유를 덧붙일 것

보고서 초안 프롬프트

아래 정보를 바탕으로 보고서 초안을 작성하라.
독자: [팀장/임원/실무자]
문서 목적: [도입 제안/기능 우선순위/시장 검토 등]
반드시 포함할 내용:
- 배경
- 핵심 발견
- 비교 결과
- 의사결정 기준
- 제안안
- 리스크 및 추가 확인 사항
문체 조건:
- 명확하고 간결하게 작성
- 과장 표현 금지
- 근거와 해석을 섞지 말 것

이렇게 분리해 두면 업무 종류가 바뀌어도 뼈대는 유지된다. 경쟁사 분석, 툴 도입 검토, 사용자 인터뷰 정리, 기능 우선순위 논의처럼 주제가 달라져도 같은 흐름으로 적용할 수 있다.

기획·리서치 업무에서 특히 조심할 오류

이 직무에서 AI를 쓸 때는 글이 매끄럽다는 이유로 안심하면 안 된다. 오히려 문장이 자연스러울수록 틀린 판단이 숨어 들어가기 쉽다.

가장 흔한 오류는 자료에 없는 결론을 자연스럽게 보태는 것이다. 예를 들어 세 개의 툴을 비교해 놓고, 실제 근거는 약한데도 "장기적으로 가장 적합하다" 같은 문장을 붙여 버리는 경우가 있다. 이런 문장은 회의 자리에서는 그럴듯해 보이지만, 나중에 책임 소재가 흐려진다.

또 다른 오류는 요약과 해석이 섞이는 것이다. "이 기능은 부족하다"는 해석이고, "이 기능은 관리자 권한을 세분화하지 못한다"는 관찰이다. 리서치 문서에서는 이 둘을 구분해야 한다. AI에게도 이 구분을 명시적으로 요구하는 편이 좋다.

예를 들어 다음 한 줄만 추가해도 품질이 많이 달라진다.

각 항목에서 '사실 요약'과 '해석 또는 시사점'을 구분해 작성하라.

이 문장 하나가 문서의 신뢰도를 높여 준다.

작은 사례: 기능 우선순위 기획에 적용해 보기

이번에는 도구 도입 검토 대신 제품 기획 사례로 바꿔 보자. 어떤 서비스 팀이 다음 분기 기능 우선순위를 정해야 한다고 하자. 입력 자료는 사용자 인터뷰 메모, 고객 문의 요약, 경쟁사 기능 비교, 내부 개발 리소스 메모다.

이때도 흐름은 같다. 먼저 자료를 요약한다. 사용자 불만, 반복 요청, 경쟁사 대비 격차, 구현 난이도 같은 항목으로 정리한다. 다음으로 기능 후보를 비교표로 만든다. 예를 들어 "알림 설정 개선", "모바일 결제 간소화", "관리자 대시보드 강화" 같은 후보를 놓고 사용자 영향도, 개발 난이도, 긴급도, 매출 연관성, 운영 부담을 비교할 수 있다.

그다음 의사결정 기준을 정리한다. "고객 이탈 방지 효과가 큰가", "다음 분기 내 출시 가능한가", "핵심 고객군에 직접 영향을 주는가" 같은 문장으로 기준을 세운다. 마지막으로 보고서 초안을 쓸 때는 단순히 1순위, 2순위를 나열하는 대신 왜 그런 우선순위가 나왔는지 논리를 적는다.

이 과정을 거치면 AI는 아이디어 생성 도구가 아니라 판단 정리 도구가 된다. 바로 이것이 기획·리서치 워크플로에서의 핵심 변화다.

좋은 기획 문서는 "답"보다 "판단 과정"이 보여야 한다

기획과 리서치의 결과물은 정답지가 아니다. 주어진 정보와 제약 속에서 가장 합리적인 선택을 제안하는 문서다. 그래서 AI를 활용할 때도 결론만 빨리 얻으려 하기보다, 결론에 이르는 과정을 단계적으로 남기는 것이 중요하다.

자료 요약은 재료를 고르는 단계이고, 비교표는 차이를 보이게 만드는 단계이며, 의사결정 기준 정리는 회의의 언어를 맞추는 단계이고, 보고서 초안 작성은 이 모든 흐름을 문서로 고정하는 단계다. 이 순서를 지키면 AI의 출력은 덜 화려할 수 있어도 훨씬 쓸모 있어진다.

결국 기획·리서치 실무에서 반복 가능한 프롬프트란, 똑똑한 문장 하나가 아니다. 자료를 읽는 방식, 비교하는 방식, 판단하는 방식, 문서화하는 방식을 일정한 흐름으로 묶어 주는 작업 설계서다. 그 설계서가 있을 때, AI는 바쁜 실무자의 시간을 아껴 주는 조수에 머무르지 않고, 팀의 판단 품질을 높이는 워크플로의 일부가 된다.

다음 장에서는 이 흐름을 한 단계 더 발전시켜, 실제로 반복 가능한 결과물을 만들어 내는 미니 캡스톤 프로젝트를 다룬다. 이제 우리는 프롬프트를 잘 쓰는 단계를 넘어, 하나의 생성 시스템을 설계할 준비가 되었다.