왜 소스분석이 필요한가?

기획자가 개발자에게 계속 물어봐야 했던 세 가지 순간

기획자라면 누구나 이런 경험이 있습니다. 화면에서 이상한 동작을 발견했는데 왜 그런지 모르겠고, 기능을 변경하려는데 어디에 영향이 가는지 알 수 없고, 개발자는 바쁜데 매번 물어보기 눈치가 보입니다. 이게 바로 소스 분석 문제입니다.

지금 방식 vs AI 통역사 방식

AI 통역사 패러다임

소스 코드를 읽는 게 아니라, 소스 코드에게 묻는 것입니다

패러다임 전환

기존에는 코드를 이해하려면 두 가지 방법뿐이었습니다. 직접 코딩을 공부하거나, 개발자에게 매번 물어보거나. 이제 세 번째 방법이 생겼습니다.

오늘의 목표

오늘 워크샵에서 여러분이 얻어가는 것들입니다.

안전 수칙

AI 도구를 사용하기 전 반드시 지켜야 할 세 가지

7단계 프로세스

코드 숲에서 길을 잃지 않기 위한 지도

소스 분석은 막막하게 느껴질 수 있습니다. 하지만 순서대로만 따라가면 누구나 비즈니스 룰을 찾아낼 수 있습니다. 마치 등산할 때 코스를 따라가면 정상에 도달하는 것처럼요.

두 가지 트랙

오늘 실습은 자신의 업무 상황에 맞게 트랙을 선택할 수 있습니다.

번들링 & 엔트리맵

Step 1–2: 코드 숲을 한 장짜리 지도로 만들기

Step 1 — 번들링: 179개 파일을 하나로

소스 코드는 보통 수백 개의 파일로 나뉘어 있습니다. 마치 여러 권의 책으로 나뉜 백과사전처럼요. AI에게 분석을 맡기려면 이 책들을 한 권으로 합쳐야 합니다. 그것이 번들링입니다.

Step 2 — 엔트리맵: 구조 지도 만들기

번들 파일만으로는 어떤 파일이 어디에 연결되는지 알기 어렵습니다. 엔트리맵은 각 화면(Entry)이 어떤 서비스, 어떤 API와 연결되는지 한눈에 보여주는 지도입니다. 도서관 안내도처럼요.

엔트리맵 예시 구조

NotebookLM 업로드

Step 3: 나만의 소스 지식 베이스 만들기

왜 NotebookLM인가?

일반 ChatGPT나 Claude에 번들 파일을 붙여넣으면 토큰 한계에 막히거나 파일이 너무 커서 분석이 어렵습니다. NotebookLM은 파일을 소스(Source)로 등록하면 이후 모든 대화에서 그 내용을 참조합니다. 마치 책을 미리 읽어둔 전문가에게 질문하는 것과 같습니다.

NotebookLM 활용 꿀팁

Step 4 — 전체 훑기

처음엔 숲을 봐야 합니다. 나무를 보는 건 그 다음입니다.

소스 분석의 첫 번째 단계는 세부 로직이 아니라 "이 화면이 대체 뭘 하는 화면인가"를 파악하는 것입니다. 등산로 입구에서 전체 지도를 보는 것과 같습니다.

📋 전체 훑기 프롬프트 템플릿

아래 프롬프트를 복사해서 NotebookLM 또는 Gemini (+ NotebookLM 소스 첨부)에 붙여넣으세요.

첨부된 소스 파일을 보고, 이 화면을 "업무 관점"에서 전체적으로 훑어 설명해 주세요.
- [screen_bundle.txt]: 화면의 UI 구성과 프런트 로직의 근거
- [EntryMap]: 데이터 흐름과 백엔드 연동 구조의 근거

요구사항:
- 이 화면의 역할이 무엇인지
- 어떤 업무 흐름의 일부인지 (앞단 / 본단 / 뒷단)
- 어떤 도메인(주문, 재고, 점포, 메타, 날씨 등)이 엮여 있는지
- Front와 Backend가 어떻게 연결될 것으로 보이는지

결과를 표(Table) 형식으로 정리해 주세요.

전체 훑기에서 얻을 수 있는 것들

Step 5 — 로직 시각화

텍스트를 넘어, 흐름을 그림으로 봅니다

전체 훑기가 끝나면 핵심 로직을 다이어그램으로 변환합니다. 텍스트로 설명된 비즈니스 룰은 머릿속에서 금방 사라지지만, 다이어그램은 팀과 공유하고 개발자에게 확인받기에 훨씬 효과적입니다.

📋 로직 시각화 프롬프트 템플릿

<context>
분석 목표: 기술적 소스 코드를 비즈니스 운영 정책 관점에서 재해석하여 의사결정용 맵으로 변환
분석 관점: 비즈니스 프로세스의 단절 및 정책적 예외 상황을 식별하는 데 집중
분석 대상: screen_bundle.txt (UI 및 프런트 로직), EntryMap (데이터 흐름 및 백엔드 연동)
최종 산출물: 비즈니스 정책과 예외 처리가 포함된 Mermaid Flowchart
</context>

<instructions>
제공된 파일을 정밀 분석하여 다음 지침에 따라 업무 로직 다이어그램을 작성하십시오.
1. 흐름 설계: 화면 진입, 목록 로딩, 데이터 편집, 정책 검증, 저장 처리, 결과 반영에 이르는 End-to-End 과정을 포함하십시오.
2. 용어 최적화: API 명칭이나 DB 필드명 같은 기술 용어를 배제하고, 업무 단계 및 정책명 중심의 비즈니스 용어를 사용하십시오.
3. 분기 로직 구체화: 성공 흐름뿐만 아니라 검증 실패 및 예외 상황에 따른 결정(Decision) 노드를 상세히 표현하십시오.
</instructions>

<output_specifications>
형식: Mermaid flowchart TB 문법 사용
언어: 한국어 전용
스타일링:
  정책 검증 노드: 노란색 계열 적용 (fill:#fff4dd, stroke:#d4a017)
  차단/오류 노드: 붉은색 계열 적용 (fill:#ffebee, stroke:#c62828)
</output_specifications>

다이어그램을 그리는 도구들

Step 6A — 기획자 관점 상세분석

Track A: 비즈니스 룰을 기획 명세로 번역하기

Track A는 소스 코드를 기획자가 이해하고 현업에 즉시 활용할 수 있는 언어로 번역하는 과정입니다. 코딩 지식이 전혀 없어도 됩니다.

📋 기획자 관점 분석 프롬프트

<context>
분석 목표: screen_bundle.txt와 EntryMap을 대조하여 기획자, 실무자, 개발자가 즉시 합의할 수 있는
고수준 서비스 명세서 및 화면정의서 작성 분석 자료 생성
- screen_bundle.txt: 프런트엔드 UI 컴포넌트 및 클라이언트 사이드 유효성 검사 로직
- EntryMap: 백엔드 API 인터페이스, 데이터 도메인 연동 및 비즈니스 정책 근거
</context>

<instructions>
제공된 소스를 바탕으로 아래 7가지 항목을 포함한 상세 명세서를 작성하십시오.
1. 화면 개요 및 IA: 해당 화면의 핵심 목적과 정보 구조 정리
2. 사용자 시나리오: 페르소나별 주요 활동 흐름 정의
3. 입력/출력 데이터 상세: 화면상의 필드명, 데이터 형식, 필수 여부, 연동 API 정보를 표 형식으로 정리
4. 비즈니스 룰: 핵심 업무 로직 및 정책 검증 규칙 상세화
5. 저장 및 트랜잭션 정책: 데이터 생성/수정/삭제 시의 정합성 유지 정책
6. 예외 메시지 카탈로그: 상황별 오류 메시지와 사용자 안내 가이드를 표 형식으로 정리
7. 변경 포인트 정의(Change Surface): 요구사항 변경 시 영향이 미치는 범위 정의
</instructions>

<constraints>
전문 용어는 최소화하고 비즈니스 언어로 작성하십시오.
강조를 위한 별표 기호(**)를 절대 사용하지 마십시오.
답변은 불필요한 서문 없이 본론부터 서술하십시오.
</constraints>

기획자가 발굴하는 유용한 인사이트

Step 6B — 개발자 관점 상세분석

Track B: 레이어 구조를 파악해 공수 산정까지

Track B는 시스템 레이어 구조를 이해하는 심화 과정입니다. "이 기능을 바꾸면 어디를 고쳐야 하나요?"라는 질문에 스스로 답할 수 있게 됩니다. 개발자와의 공수 산정 회의에서 훨씬 구체적인 대화를 할 수 있습니다.

레이어 구조 이해

📋 개발자 관점 프롬프트

이제 제공된 소스를 기준으로, 화면 동작 및 비즈니스로직을 개발자와 상의할 수 있는
수준으로 상세하게 분석해 주세요.

분석 항목:
1. Entry(Vue) → Controller → Service → Mapper → XML 레이어별 담당 역할 정리
2. 기능 변경 시 영향 받는 레이어 범위
3. 서버 검증 로직과 클라이언트 검증 로직 구분
4. 비즈니스 정책이 구현된 레이어 위치 (Service vs Controller)
5. DB 접근 패턴 (단순 조회 / 트랜잭션 / 복합 조인)

결과는 표 형식으로, 기술 용어를 최소화하여 기획자도 이해할 수 있게 작성해 주세요.

Step 7 — 황금 질문

숨겨진 제약 조건을 찾아내는 날카로운 질문들

분석이 끝나도 아직 끝이 아닙니다. AI의 분석 결과에서 숨겨진 제약 조건, 예외 케이스, 비즈니스 정책을 찾아내는 확인 질문이 Mastery Package의 마지막 조각입니다.

황금 질문 예시

Mastery Package란?

오늘 실습의 최종 결과물입니다. 이 세 가지를 갖추면 여러분은 소스 분석을 완성한 것입니다.

• 화면 역할과 업무 흐름을 한 문단으로 설명할 수 있다
• 핵심 비즈니스 룰을 3개 이상 찾아냈다
• 비즈니스 흐름 다이어그램을 생성했다
• 예외 메시지 카탈로그를 작성했다
• 개발자에게 확인할 황금 질문을 2개 이상 준비했다

꿀팁 대방출

AI 소스분석을 더 잘하기 위한 3가지 전략

전략 1 — 준비

좋은 분석은 좋은 준비에서 시작됩니다

NotebookLM + Gemini 시너지

두 도구를 따로 쓰면 절반의 효과입니다. 함께 쓰면 배가 됩니다. 마치 참고서(NotebookLM)를 미리 읽어둔 과외 선생님(Gemini)에게 질문하는 것과 같습니다.

Source of Truth 지정 — 환각을 줄이는 방법

AI에게 질문할 때 "어떤 파일을 근거로 답하라"고 명시하면 환각(Hallucination) 확률이 크게 줄어듭니다. 식재료 이름을 정확히 대면 요리사가 더 정확한 요리를 만드는 것처럼요.

전략 2 — 지시

AI의 논리를 정연하게 만드는 법: 틀을 먼저 짜주세요

4줄 지시법 + 표 형식 고정

AI의 답변이 들쑥날쑥한 이유는 지시가 불명확하기 때문입니다. 결과의 '틀'을 미리 정해주면 AI는 그 틀 안에서 논리적으로 채워 넣습니다. 빈 칸 채우기 시험지를 주는 것과 같습니다.

XML 박스 활용 — 데이터와 지침을 분리하기

기획자에게 XML은 코딩이 아닙니다. 정보를 섞이지 않게 담는 '라벨링 된 이삿짐 박스'입니다. context 박스에는 배경 정보를, instructions 박스에는 해야 할 일을, constraints 박스에는 제약 조건을 담습니다.

<context>
첨부된 파일은 발주 시스템 화면 소스입니다.
</context>

<instructions>
이 소스에서 예외 처리 로직만 추출하십시오.
</instructions>

<constraints>
기술 용어를 배제하고 비즈니스 언어로만 작성하십시오.
답변 전 제시된 제약 사항과 일치하는지 최종 검증할 것.
</constraints>

Gemini 맞춤 프롬프트 구조

전략 3 — 분석

길을 잃지 않기 위한 4단계 핵심 루틴

4단계 핵심 루틴

소스 분석 중에 어디까지 왔는지 모르는 상태가 되기 쉽습니다. 아래 4단계를 순서대로 따라가면 항상 진행 상황을 파악할 수 있습니다.

관점 렌즈 끼우기

코드는 객관적 사실이지만, 해석은 렌즈에 따라 달라집니다. 같은 코드를 두 가지 렌즈로 보세요.

자기 검증 루프 — AI의 성급한 답변 막기

AI는 때로 충분히 검토하지 않고 빠르게 답변합니다. 프롬프트 마지막에 이 한 문장을 추가하면 AI가 스스로 한 번 더 검토합니다.

최종 답변을 출력하기 전, 누락된 조건은 없는지 스스로 1번 더 비판하고 검증해.

다른 사람의 프롬프트로 재분석하기

같은 소스를 동료가 다른 프롬프트로 분석하면 전혀 다른 인사이트가 나옵니다. 실습 2차에서는 동료의 프롬프트를 보고 다시 한번 분석해보세요. 어떤 관점을 내가 놓쳤는지 발견하는 것도 중요한 학습입니다.

Mastery Package

오늘 실습의 최종 결과물 — 세 가지를 갖추면 완성입니다

오늘 여러분이 만든 결과물을 Notion 베이스캠프 개인 시트에 저장하세요. 이 세 가지 패키지가 있으면 소스 분석 역량을 증명할 수 있습니다.

Miso 에이전트 활용하기

반복적인 소스 분석 업무가 있다면 Miso 에이전트로 만들어두세요. 매번 긴 프롬프트를 작성하지 않고, 화면 이름만 입력하면 Mastery Package 초안을 자동으로 생성할 수 있습니다.

베이스캠프 회고

오늘의 여정을 돌아보는 시간 — Notion 개인 시트에 기록하세요

오늘 실습에서 경험한 것을 Notion 베이스캠프 개인 시트에 기록하며 스스로의 인사이트를 정리해 주세요. 기록이 곧 나만의 프롬프트 노하우가 됩니다.

오늘 배운 것 정리