Data Vision

AI에게 PRD를 맡길 때 반드시 넣어야 하는 6개 항목

Pro.Dev — Tue, 12 May 2026 23:05:41 +0900

요즘은 Cursor, Claude Code, Windsurf 같은 AI 개발 도구 덕분에
“아이디어 → 서비스 구현” 속도가 엄청 빨라졌습니다.

그런데 실제 현업에서는 많은 사람들이 AI에게 이렇게 요청합니다.

“커뮤니티 서비스 만들어줘”
“배달앱 만들어줘”
“AI SaaS 만들어줘”

그리고 결과를 보고 실망합니다.

왜냐하면 AI는 “개발자”이기 전에
입력된 요구사항(PRD)을 기반으로 움직이는 시스템이기 때문입니다.

즉,
PRD(Product Requirement Document)가 부실하면
AI도 엉뚱한 결과를 만들어냅니다.

실제로 현업에서는 AI에게 일을 맡기기 전에
아래 6개 항목을 반드시 정리합니다.

1. 서비스 목적 (Why)

가장 먼저 필요한 건:

“왜 이 서비스를 만드는가?”

입니다.

AI는 목적이 명확할수록
기능 우선순위를 훨씬 정확하게 잡습니다.

예시:

잘못된 예시
- “운동 앱 만들어줘”
좋은 예시
- “직장인이 퇴근 후 10분 운동 루틴을 기록하고 공유하는 서비스”

차이가 느껴지시나요?

두 번째는:

타겟
사용 상황
핵심 가치

가 모두 포함되어 있습니다.

현업에서는 이걸 가장 중요하게 봅니다.

왜냐하면 목적이 명확해야:

기능 범위가 줄어들고
UX 방향이 정해지고
AI도 올바른 구조를 설계하기 때문입니다.

2. 핵심 사용자 (Who)

AI는 사용자를 알아야
화면 구조와 기능을 제대로 설계할 수 있습니다.

예시:

대학생
스타트업 PM
개발자
소상공인
헬스 트레이너

이렇게 구체적으로 지정해야 합니다.

그리고 더 중요한 건:

사용자의 문제
현재 불편한 점
기존 대체 수단

까지 적는 것입니다.

예시:

항목내용

사용자	스타트업 PM
문제	회의 내용 정리가 너무 오래 걸림
현재 방식	노션 수기 작성
원하는 결과	AI가 자동으로 회의 요약

이 정보를 넣으면
AI가 훨씬 현실적인 기능을 제안합니다.

3. 핵심 기능 (Core Features)

많은 사람들이 가장 많이 실수하는 부분입니다.

기능을 너무 많이 넣습니다.

현업에서는 처음부터 모든 기능을 만들지 않습니다.

대신:

“MVP에서 반드시 필요한 기능”

만 정의합니다.

예시:

커뮤니티 서비스 MVP

필수 기능:

회원가입
게시글 작성
댓글
좋아요

제외 기능:

실시간 채팅
알림 시스템
관리자 통계
추천 알고리즘

왜냐하면 AI도 기능 범위가 작을수록
훨씬 높은 품질의 코드를 생성하기 때문입니다.

4. 화면 흐름 (User Flow)

AI는 “사용자가 어떻게 움직이는지”를 알면
프론트엔드 구조를 훨씬 잘 만듭니다.

현업에서는 보통 이렇게 작성합니다.

로그인
→ 메인 피드 진입
→ 게시글 클릭
→ 댓글 작성
→ 마이페이지 이동

간단해 보여도 엄청 중요합니다.

왜냐하면 이것만 있어도 AI가:

라우팅 구조
페이지 구성
상태관리 흐름
API 연결 구조

를 유추할 수 있기 때문입니다.

특히 Cursor나 Claude Code에서
이 부분이 있으면 코드 품질 차이가 매우 커집니다.

5. 기술 스택 & 인프라 조건

이걸 안 넣으면 AI는 자기 마음대로 선택합니다.

예시:

Frontend: Next.js
Backend: FastAPI
DB: PostgreSQL
Cache: Redis
Infra: AWS ECS
CI/CD: GitHub Actions + Docker

이렇게 명확히 지정해야 합니다.

실제로 현업에서는:

회사 표준 스택
운영 비용
배포 방식
트래픽 구조

때문에 기술 선택이 매우 중요합니다.

특히 AI에게:

Docker 사용 여부
AWS 구조
RDS 사용 여부
NoSQL 사용 여부

를 알려주면
아키텍처 수준이 훨씬 올라갑니다.

6. 성공 기준 (Success Metric)

현업 PRD에서 가장 중요한 부분입니다.

“이 서비스가 성공했는지 어떻게 판단할 것인가?”

예시:

회원가입 전환율 30%
DAU 1,000명
평균 체류시간 10분
재방문율 40%
API 응답속도 200ms 이하

이걸 넣으면 AI가:

로그 구조
분석 이벤트
데이터 테이블
모니터링 구조

까지 고려해서 설계합니다.

즉:
“단순 기능 개발”이 아니라
“운영 가능한 서비스” 수준으로 바뀝니다.

실제 현업에서는 이렇게 합니다

현업 AI 개발팀은 보통:

1. PRD 작성
2. AI에게 역할 부여
3. 기능 단위로 작업 분리
4. 코드 생성
5. 리뷰 & 수정
6. 자동 배포

순서로 진행합니다.

중요한 건:

AI에게 개발을 맡기기 전에
인간이 문제 정의를 정확히 해야 한다

입니다.

AI 시대가 되면서
오히려 기획 능력(PRD)이 더 중요해졌습니다.

정리

AI에게 서비스를 맡길 때
반드시 포함해야 하는 6개 항목:

서비스 목적
핵심 사용자
핵심 기능
화면 흐름
기술 스택 & 인프라
성공 기준

이 6개만 제대로 작성해도
AI 결과물 품질이 완전히 달라집니다.

그리고 이것이 바로
현재 실리콘밸리와 국내 스타트업들이 실제로 사용하는 방식입니다.

Agentic AI는 RAG와 뭐가 다른가

Pro.Dev — Tue, 12 May 2026 01:09:05 +0900

요즘 AI 개발을 공부하다 보면 RAG, AI Agent, Agentic AI라는 말을 자주 봅니다.
그런데 많은 분들이 이 셋을 비슷하게 이해합니다.

결론부터 말하면, RAG는 정보를 찾아 답변하는 구조이고, Agentic AI는 목표를 달성하기 위해 스스로 판단하고 도구를 사용하는 구조입니다.

쉽게 말하면 RAG는 “검색해서 답하는 AI”에 가깝고, Agentic AI는 “일을 처리하는 AI”에 가깝습니다.

1. RAG란 무엇인가

RAG는 Retrieval-Augmented Generation의 약자입니다.

사용자가 질문하면 시스템은 먼저 외부 문서나 데이터베이스에서 관련 정보를 찾습니다.
그리고 찾은 정보를 LLM에게 넣어 답변을 생성합니다.

흐름은 보통 이렇게 됩니다.

사용자 질문
→ 관련 문서 검색
→ 검색 결과를 프롬프트에 추가
→ LLM이 답변 생성

예를 들어 사내 문서 검색 챗봇을 만든다고 해보겠습니다.

사용자가 이렇게 묻습니다.

우리 회사 연차 정책 알려줘

RAG 시스템은 사내 규정 문서에서 연차 관련 내용을 검색하고, 그 내용을 바탕으로 답변합니다.

즉 RAG의 핵심은 이것입니다.

질문에 필요한 정보를 잘 찾아서 답변 품질을 높이는 것

2. Agentic AI란 무엇인가

Agentic AI는 단순히 답변만 하지 않습니다.

목표를 받고, 필요한 단계를 나누고, 도구를 호출하고, 중간 결과를 확인하면서 작업을 진행합니다.

흐름은 보통 이렇게 됩니다.

사용자 목표 입력
→ 해야 할 작업 계획
→ 필요한 도구 선택
→ 도구 실행
→ 결과 확인
→ 다음 행동 결정
→ 최종 결과 생성

예를 들어 사용자가 이렇게 요청한다고 해보겠습니다.

지난달 고객 문의 데이터를 분석해서 주요 불만 원인 5개를 정리하고, 개선 액션까지 제안해줘

Agentic AI는 단순히 답변하는 것이 아니라 다음과 같이 움직일 수 있습니다.

1. 고객 문의 데이터 가져오기
2. 카테고리별로 분류하기
3. 감정 분석하기
4. 불만 원인 추출하기
5. 우선순위 정하기
6. 개선 액션 제안하기
7. 보고서 형태로 정리하기

즉 Agentic AI의 핵심은 이것입니다.

답변이 아니라 작업 완료

3. RAG와 Agentic AI의 핵심 차이

구분RAGAgentic AI

목적	정확한 답변 생성	목표 달성
중심 기능	검색 + 생성	계획 + 도구 사용 + 실행
입력	질문	목표 또는 작업 요청
출력	답변	작업 결과물
대표 예시	사내 문서 Q&A	리서치 자동화, 보고서 작성, 코드 수정
복잡도	비교적 낮음	높음
필요한 요소	벡터DB, 검색기, 프롬프트	도구, 메모리, 상태관리, 평가, 승인 흐름

4. 예시로 이해하기

RAG 예시

사용자:

우리 제품의 환불 정책 알려줘

RAG 시스템:

문서에서 환불 정책을 검색한 뒤 답변한다.

결과:

환불은 결제 후 7일 이내 가능하며, 사용 이력이 없는 경우 전액 환불됩니다.

Agentic AI 예시

사용자:

최근 3개월 환불 문의를 분석해서 환불 정책 개선안을 만들어줘

Agentic AI:

1. 고객 문의 데이터 조회
2. 환불 관련 문의 필터링
3. 문의 사유 분류
4. 반복되는 불만 패턴 분석
5. 개선안 작성
6. 보고서 생성

결과:

환불 정책 개선 보고서
- 주요 불만 원인
- 빈도 분석
- 고객 영향도
- 개선 우선순위
- 정책 수정안

이 차이가 중요합니다.

RAG는 “환불 정책이 뭐야?”에 답합니다.
Agentic AI는 “환불 정책을 어떻게 개선할까?”라는 일을 수행합니다.

5. RAG도 Agentic AI의 일부가 될 수 있다

중요한 점은 RAG와 Agentic AI가 서로 경쟁 관계가 아니라는 것입니다.

Agentic AI 안에 RAG가 들어갈 수 있습니다.

예를 들어 리서치 에이전트를 만든다면 다음과 같은 구조가 가능합니다.

Agent
├── 문서 검색 도구
├── 웹 검색 도구
├── 데이터베이스 조회 도구
├── 요약 도구
├── 평가 도구
└── 보고서 작성 도구

이때 문서 검색 도구가 바로 RAG 역할을 합니다.

즉 RAG는 Agentic AI를 구성하는 하나의 도구가 될 수 있습니다.

6. 언제 RAG를 쓰고, 언제 Agentic AI를 써야 할까

RAG가 적합한 경우

질문에 대한 정확한 답변이 필요한 경우

예시:

사내 문서 Q&A
고객센터 FAQ 챗봇
제품 매뉴얼 검색
법무/정책 문서 검색
논문 기반 질의응답

이런 경우에는 굳이 Agentic AI까지 갈 필요가 없습니다.
RAG만으로도 충분합니다.

Agentic AI가 필요한 경우

여러 단계를 거쳐 작업을 완료해야 하는 경우

예시:

시장 조사 보고서 작성
고객 문의 분석
코드 리뷰 자동화
장애 원인 분석
영업 리드 정리
데이터 분석 리포트 생성
반복 업무 자동화

이런 경우에는 단순 검색과 답변만으로는 부족합니다.
계획, 실행, 검증이 필요하기 때문에 Agentic AI 구조가 필요합니다.

7. 실무에서 가장 많이 하는 실수

가장 흔한 실수는 모든 문제를 Agentic AI로 풀려고 하는 것입니다.

하지만 실무에서는 반대로 접근해야 합니다.

먼저 RAG로 충분한지 확인한다.
그래도 부족하면 Agentic AI로 확장한다.

처음부터 복잡한 에이전트 구조를 만들면 이런 문제가 생깁니다.

디버깅이 어렵다
비용이 증가한다
결과가 불안정하다
보안 위험이 커진다
운영이 복잡해진다

따라서 실무에서는 아래 순서가 좋습니다.

1. 단순 프롬프트
2. RAG
3. Workflow
4. Agentic AI

8. 결론

RAG와 Agentic AI의 차이는 한 문장으로 정리할 수 있습니다.

RAG는 정보를 찾아 답변하는 기술이고,
Agentic AI는 목표를 달성하기 위해 판단하고 행동하는 시스템이다.

처음 AI 서비스를 만든다면 RAG부터 시작하는 것이 좋습니다.

하지만 사용자의 요청이 단순 질문을 넘어
“조사해줘”, “분석해줘”, “정리해서 보고서 만들어줘”, “수정하고 배포해줘”처럼
작업 완료를 요구한다면 Agentic AI 구조가 필요합니다.

앞으로의 AI 서비스는 단순 챗봇에서 끝나지 않을 것입니다.
결국 중요한 것은 질문에 답하는 AI가 아니라 일을 끝내는 AI입니다.

대화하는 AI vs 일을 하는 AI

Pro.Dev — Wed, 1 Apr 2026 01:43:42 +0900

ChatGPT는 “대화 도구”다

ChatGPT는 정말 훌륭한 AI입니다.

특히 이런 작업에서 강합니다.

글 작성
아이디어 정리
코드 설명
간단한 분석

하지만 본질적으로 ChatGPT는 대화 기반 도구입니다.

즉 대부분의 결과가 이렇게 끝납니다.

“이렇게 하면 됩니다.”

실제로 뭔가를 만들거나 실행하지는 않습니다.

Claude Code는 “실행 도구”다

Claude Code를 사용하면서 가장 크게 느낀 차이는 이것입니다.

ChatGPT는 대화하는 AI

Claude Code는 일하는 AI

예를 들어 이런 요청을 해봅니다.

“이 설명을 정리해서 웹페이지 하나 만들어줘.”

ChatGPT의 결과

HTML 코드 생성

Claude Code의 결과

실제 웹페이지 생성
코드 수정
파일 생성
배포

즉 Claude Code는 결과를 설명하는 것이 아니라 실제로 실행합니다.

두 AI의 결정적인 차이 3가지

1️⃣ 글의 퀄리티

ChatGPT의 글은 대부분 맞는 말입니다.

하지만 읽어보면 이런 느낌이 들 때가 있습니다.

맞는 말인데 깊이가 없다.

반면 Claude는

문장 흐름이 자연스럽고
단어 선택이 인간에 가깝고
의도를 더 잘 이해합니다.

특히 한국어 글쓰기에서도 훨씬 자연스러운 경우가 많습니다.

콘텐츠 제작자에게는 이 차이가 상당히 크게 느껴집니다.

2️⃣ 리서치 능력

ChatGPT의 웹 검색은 기본적으로

검색 결과 요약

에 가까운 경우가 많습니다.

하지만 Claude Code는

실제 웹페이지 접속
스크롤 분석
콘텐츠 비교
자료 조사

까지 진행합니다.

즉 단순 요약이 아니라

실제 조사 수준의 리서치가 가능합니다.

3️⃣ 실행 능력

ChatGPT

→ 설명

Claude Code

→ 실행

예를 들어

파일 생성
코드 수정
시스템 변경
앱 제작

같은 작업을 실제로 수행합니다.

이 차이는 업무 자동화에서 엄청난 차이를 만듭니다.

Claude를 “AI 비서”로 만드는 방법

Claude Code에는 Skills라는 개념이 있습니다.

이것은 ChatGPT의 Custom GPT와 비슷하지만 더 강력합니다.

차이를 쉽게 설명하면

Custom GPT
명함

Claude Skill
업무 매뉴얼

즉 단순 정보가 아니라

업무 규칙
작업 흐름
실행 프로세스

까지 포함됩니다.

아침 업무 시작 방식이 완전히 바뀌었다

예전에는 아침마다 이렇게 시작했습니다.

노션 확인
캘린더 확인
이메일 확인
할 일 정리

보통 20~30분이 걸렸습니다.

지금은 이렇게 합니다.

“오늘 브리핑해줘”

그러면 Claude가

진행 중 프로젝트
우선순위
해야 할 작업

을 정리해 하루 업무 브리핑을 제공합니다.

업무 준비 시간이

30분 → 1분

으로 줄었습니다.

AI를 쓸 때 사람들이 가장 많이 하는 실수

마지막으로 중요한 이야기입니다.

1️⃣ 매번 새로 설명하기

AI에게 비즈니스 정보를 계속 설명하는 것은 시간 낭비입니다.

맥락을 정리한 파일을 만들어 두는 것이 좋습니다.

2️⃣ 결과를 검토하지 않기

AI는 여전히

사실 오류
톤 문제

가 발생할 수 있습니다.

그래서 반드시 사람 검토 단계가 필요합니다.

3️⃣ 너무 빨리 자동화하기

많은 회사들이

프로세스 없이 자동화

를 시도합니다.

하지만 올바른 순서는

1️⃣ 사람이 직접 작업
2️⃣ 패턴 발견
3️⃣ 매뉴얼 작성
4️⃣ 자동화

입니다.

AI는 지금 단순 챗봇 시대를 넘어가고 있습니다.

앞으로 AI는

대화하는 도구가 아니라

일을 수행하는 시스템

이 될 가능성이 높습니다.

그리고 Claude Code는
그 변화를 가장 먼저 보여주는 도구 중 하나입니다.

메타 공식 API로 인스타그램 자동화 시스템 만들기

Pro.Dev — Mon, 16 Mar 2026 14:29:01 +0900

따라하기 쉬운 실전 가이드

인스타그램 계정을 메타 공식 API에 연결하고, AI 에이전트로 이미지 생성 + 포스팅 자동화를 시작하는 과정을 쉽게 따라할 수 있도록 정리한 가이드입니다.

1. 이 가이드로 할 수 있는 것

이 시스템을 만들면 다음과 같은 흐름을 자동화할 수 있습니다.

메타 공식 API로 인스타그램 계정 연결
AI 에이전트에 인스타그램 업로드 권한 부여
이미지 자동 생성
포스팅 문구 및 해시태그 자동 작성
인스타그램에 자동 업로드
일정 기반 반복 포스팅 자동화

즉,
“이미지 만들기 → 글 쓰기 → 업로드하기 → 반복 실행하기”
이 흐름을 사람이 일일이 하지 않고 자동으로 돌릴 수 있게 만드는 것이 목표입니다.

2. 준비물

시작 전에 아래 항목을 준비하세요.

필수 준비물

메타(페이스북) 계정
인스타그램 계정
Meta for Developers 계정
AI 에이전트를 실행할 도구
- Antigravity(안티그래비티) 사용
계정을 연결하고 작업할 PC

있으면 좋은 것

자동 포스팅용 콘텐츠 주제
- 예: AI 교육, 카페 홍보, 제품 소개, 자기계발, 패션, 여행 등
이미지 생성 프롬프트
포스팅 문체 가이드
- 예: 친근한 말투, 전문가 말투, 짧은 홍보형 등

3. 전체 흐름 한눈에 보기

전체 과정은 아래 순서로 진행됩니다.

메타 개발자 페이지에서 앱 생성
앱에 인스타그램 계정 연결
인스타그램 테스터 초대 및 수락
Access Token 발급
AI 에이전트에 계정 ID와 토큰 입력
이미지 생성 + 포스팅 명령 실행
자동 반복 업로드 코드 또는 일정 설정

4. 단계별 따라하기

STEP 1. 메타 개발자 페이지에서 앱 만들기

먼저 메타 개발자 페이지에 들어가 로그인합니다.

진행 순서

Meta 개발자 페이지 접속
로그인 후 My Apps(내 앱) 클릭
Create App(앱 생성) 클릭
앱 이름 입력
- 예: AI Agent, Instagram Agent, Arin Instagram Agent
이메일 입력
Next 클릭

중요한 선택 포인트

유스케이스를 고를 때:

Other(기타) 선택
다음 화면에서 Business(비즈니스) 선택

체크

앱 이름 입력 완료
Other 선택 완료
Business 선택 완료
앱 생성 완료

STEP 2. Instagram Setup으로 들어가기

앱이 생성되면 여러 메뉴가 보일 텐데, 여기서 핵심은 Instagram Setup입니다.

진행 순서

생성한 앱 화면에서 Instagram Setup 클릭
Setup 버튼 선택
Add Account 클릭
연결할 인스타그램 계정 추가

여기서 말하는 의미는
“이 앱이 어떤 인스타그램 계정과 연결될지 등록하는 단계”입니다.

체크

Instagram Setup 진입 완료
연결할 인스타그램 계정 추가 완료

STEP 3. App Role에서 인스타그램 테스터 등록하기

이 단계는 처음 보면 헷갈리기 쉬운데, 쉽게 말하면
“이 인스타그램 계정이 이 앱을 테스트할 수 있도록 승인 대상에 넣는 과정”입니다.

진행 순서

앱 메뉴에서 App Role로 이동
Role 화면으로 들어감
Add People 클릭
역할(Role)에서 Instagram Tester 선택
연결하려는 인스타그램 아이디 입력
Add 클릭

정상적으로 되면 상태가 Pending(대기 중) 으로 보일 수 있습니다.

체크

Instagram Tester 추가 완료
상태가 Pending인지 확인

STEP 4. 인스타그램에서 테스터 초대 수락하기

이제 방금 추가한 계정 쪽에서 초대를 수락해야 합니다.

진행 순서

Instagram Manage Account 관련 페이지에 접속
연결하려는 인스타그램 계정으로 로그인
테스터 초대 또는 앱 연결 요청 화면 확인
방금 만든 앱이 연결 요청한 것을 확인
수락(Accept) 클릭

이 과정을 해야
앱과 인스타그램 계정 연결이 실제로 활성화됩니다.

체크

인스타그램 계정 로그인 완료
테스터 초대 확인 완료
초대 수락 완료

STEP 5. Access Token 발급받기

이제 API 연동에 필요한 핵심 정보인 Access Token을 발급받습니다.

진행 순서

다시 메타 앱 화면으로 돌아감
왼쪽 메뉴에서 인스타그램 관련 설정으로 이동
API Setup with Instagram Login 선택
화면에서 다음 두 항목 확인
- 계정 ID
- Access Token 생성 메뉴
Generate Access Token 클릭
로그인/권한 허용 진행
I understand 체크
토큰 복사

꼭 기억할 점

계정 ID와 Access Token 둘 다 필요합니다.
특히 Access Token은 비밀번호처럼 민감한 정보입니다.
절대 공개 문서, 깃허브, 채팅방 등에 그대로 올리지 마세요.

체크

계정 ID 복사 완료
Access Token 생성 완료
토큰 안전하게 저장 완료

STEP 6. AI 에이전트 툴에서 프로젝트 폴더 만들기

Antigravity(안티그래비티) 를 사용합니다.

진행 순서

Antigravity 실행
Open Folder 클릭
새 폴더 생성
- 예: Arin, Instagram Agent, insta-agent
폴더 열기
Open Agent Manager 클릭
새로 만든 인스타그램 에이전트 선택
제공받은 스킬(skill) 또는 가이드 파일 붙여넣기

여기서 skill.md가 생성되고,
이 문서를 “에이전트에게 주는 업무 매뉴얼”처럼 사용합니다.

즉:

이 에이전트는 어떤 일을 해야 하는지
어떤 방식으로 포스팅해야 하는지
어떤 API를 써야 하는지

이런 규칙을 이 문서에 적어두는 방식입니다.

체크

프로젝트 폴더 생성 완료
에이전트 생성 또는 선택 완료
skill 문서 반영 완료

STEP 7. .env 파일에 계정 정보 저장하기

이제 발급받은 값을 안전하게 넣어야 합니다.

보통 아래처럼 .env 파일에 저장합니다.

INSTAGRAM_ACCOUNT_ID=여기에_계정_ID
INSTAGRAM_ACCESS_TOKEN=여기에_액세스_토큰

왜 .env에 넣나요?

코드에 직접 토큰을 쓰지 않기 위해
외부 공개를 줄이기 위해
프로젝트별 비밀값을 따로 관리하기 위해

주의사항

.env 파일은 외부 공유 금지
GitHub에 올릴 때 .gitignore에 반드시 추가
토큰이 노출되면 재발급 고려

체크

.env 파일 생성 완료
계정 ID 입력 완료
Access Token 입력 완료
외부 공개되지 않도록 보호 완료

STEP 8. 첫 번째 자동 포스팅 실행하기

이제 실제로 에이전트에게 일을 시켜봅니다.

“AI가 이미지를 만들고, 글을 쓰고, 업로드까지 한다” 입니다.

예시 명령

아래처럼 자연어로 지시할 수 있습니다.

예시 1. AI 교육 계정용

인공지능으로 이미지 생성하는 방법을 배울 수 있도록 어울리는 이미지를 하나 생성하고, 인스타그램 포스팅 문구와 해시태그까지 작성해서 업로드해줘.

예시 2. 오프라인 매장 홍보용

우리 카페를 홍보할 수 있는 감성적인 이미지를 만들고, 오늘의 추천 메뉴를 소개하는 글과 해시태그를 작성해서 인스타그램에 올려줘.

예시 3. 제품 홍보용

신제품 런칭 홍보용 이미지를 만들고, 구매 욕구를 자극하는 문구와 브랜드 해시태그를 포함해 업로드해줘.

STEP 9. 이미지 프롬프트를 넣어 더 좋은 결과 만들기

처음에는 간단한 지시만으로 테스트하고,
그다음에는 더 구체적인 프롬프트를 넣으면 퀄리티를 높일 수 있습니다.

좋은 프롬프트 예시

극사실주의 시네마틱 스타일의 인물 포트레이트 이미지를 생성하고, AI 이미지 생성 교육용 게시물로 사용할 수 있게 설명형 캡션과 관련 해시태그를 작성해서 업로드해줘.

실무 팁

프롬프트에는 아래 요소를 넣으면 좋습니다.

주제
분위기
스타일
색감
구도
타깃 독자
포스팅 목적

예를 들어:

따뜻한 조명, 고급스러운 카페 인테리어, 디저트가 돋보이는 구성, 인스타그램 감성, 홍보용 이미지

이렇게 구체적으로 넣을수록 결과가 좋아집니다.

STEP 10. 자동 반복 업로드 설정하기

1개월치 자동 포스팅 계획까지 만들게 합니다.

예시 지시 방식은 아래와 같습니다.

지금부터 한 달간 인스타그램 포스팅을 매일 하루에 하나씩 해줘.
매일 트렌드를 참고해서 주제를 정하고, 이미지 생성, 포스팅 문구 작성, 해시태그 작성, 업로드 시간 결정까지 자동으로 해줘.
그리고 일정 기반으로 자동 실행되도록 설정해줘.

여기서 기대하는 자동화 범위

Day 1 ~ Day 30 포스팅 계획 생성
매일 업로드 주제 자동 선정
이미지 자동 생성
캡션/태그 자동 작성
업로드 시간 자동 결정
일정 등록

5. 바로 써먹는 명령어 예시 모음

아래 문장을 그대로 바꿔가며 써도 됩니다.

예시 A. 교육 계정 운영

AI 초보자가 관심 가질 만한 주제로 인스타그램 카드뉴스용 이미지를 생성해줘.
설명형 캡션과 저장 유도 문구를 포함하고, 관련 해시태그도 작성해서 업로드해줘.

예시 B. 카페/매장 홍보

우리 카페의 시그니처 메뉴를 홍보할 수 있는 감성적인 이미지를 생성하고, 방문을 유도하는 짧은 홍보 문구와 지역 기반 해시태그를 작성해서 업로드해줘.

예시 C. 전문가 브랜딩

퍼스널 브랜딩용 인스타그램 게시물을 만들어줘.
전문적이고 신뢰감 있는 이미지, 짧고 강한 인사이트형 문구, 저장/공유 유도 문장을 포함해서 업로드해줘.

예시 D. 한 달 자동 운영

앞으로 30일 동안 매일 1개의 인스타그램 게시물을 자동으로 올릴 수 있게 콘텐츠 계획을 세워줘.
주제 선정, 이미지 생성, 캡션, 해시태그, 업로드 시간 추천까지 포함해서 자동 실행 흐름으로 구성해줘.

6. 추천 업무 매뉴얼(skill.md) 구성 예시

에이전트에게 줄 업무 매뉴얼은 아래 구조로 만들면 좋습니다.

역할

당신은 인스타그램 마케팅 자동화 에이전트다.
브랜드 성격에 맞는 게시물을 기획, 생성, 업로드한다.

해야 할 일

게시물 주제 선정
이미지 생성
캡션 작성
해시태그 작성
업로드 실행

작성 원칙

브랜드 톤앤매너 유지
과장 표현 최소화
스팸성 해시태그 남용 금지
읽기 쉬운 캡션 작성
업로드 전 결과 검토

입력값

브랜드 주제
타깃 고객
원하는 분위기
업로드 빈도
계정 ID / Access Token

7. 초보자가 가장 많이 막히는 부분

1) 앱은 만들었는데 계정 연결이 안 됨

원인:

Instagram Tester 등록 안 함
테스터 초대 수락 안 함

해결:

App Role에서 테스터 등록
인스타그램 쪽에서 초대 수락

2) 토큰은 만들었는데 업로드가 안 됨

원인:

계정 ID 또는 토큰 복사 오류
토큰 만료 또는 권한 문제
.env 저장 실수

해결:

계정 ID 재확인
토큰 재발급
.env 오탈자 확인

3) 이미지 품질이 기대보다 낮음

원인:

프롬프트가 너무 짧음
스타일, 구도, 목적이 불명확함

해결:

프롬프트를 더 구체적으로 작성
예시 이미지 스타일을 텍스트로 자세히 설명

4) 자동화는 되는데 결과물이 들쭉날쭉함

원인:

에이전트 업무 기준이 없음
브랜드 가이드가 없음

해결:

skill.md에 규칙 명확히 작성
톤, 길이, 금지 표현, 목적을 미리 정의

8. 운영할 때 꼭 주의할 점

보안

Access Token은 절대 외부에 공개하지 마세요.
코드 저장소 업로드 전 .env 제외 여부 확인하세요.

품질

자동 생성 게시물도 초반에는 꼭 검수하세요.
AI가 쓴 문장이 내 브랜드 톤과 맞는지 확인하세요.

정책 준수

메타 공식 API를 사용하더라도, 실제 운영 시에는 메타 및 인스타그램의 정책과 권한 범위를 확인해야 합니다.
과도한 자동화, 스팸성 업로드, 허위·기만성 콘텐츠는 피해야 합니다.

현실적인 운영 팁

처음부터 30일 완전 자동보다
- 1일 1포스트 테스트
- 3일 테스트
- 1주 자동화
- 1개월 확장
  순으로 가는 것이 안정적입니다.

9. 가장 추천하는 시작 방식

처음에는 아래 3단계로 시작하는 것을 추천합니다.

1단계

메타 앱 생성 + 인스타그램 계정 연결

2단계

이미지 1개 생성 + 게시물 1개 업로드 테스트

3단계

3일치 자동 포스팅 계획 실행

이렇게 하면 문제를 빨리 발견하고 수정할 수 있습니다.

10. 따라하기용 최종 체크리스트

계정/연동

메타 개발자 계정 생성
앱 생성 완료
Other 선택
Business 선택
Instagram Setup 완료
인스타그램 계정 추가 완료
Instagram Tester 등록 완료
테스터 초대 수락 완료

API 정보

계정 ID 확보
Access Token 발급 완료
토큰 안전 저장 완료

에이전트 구성

프로젝트 폴더 생성 완료
에이전트 생성 완료
skill.md 구성 완료
.env 입력 완료

실행

테스트 이미지 생성 완료
캡션 생성 완료
첫 포스팅 업로드 완료
자동 반복 실행 설정 완료

SQL·파이썬 몰라도 KPI 분석하는 방법 (질문 한 줄로 끝)

Pro.Dev — Thu, 5 Feb 2026 00:50:20 +0900

저는 테크니컬 리드이자 데이터 분석가로 일해왔습니다.
그동안은 데이터를 분석하고 가공해서, 서비스에 필요한 AI 기능을 만들고 개발하는 일을 주로 했습니다.

SQL도 다루고, 파이썬으로 분석도 하고, 모델링도 할 줄 아는 편이었습니다.
그래서 “데이터 분석” 자체는 자신 있는 영역이라고 생각했습니다.

그런데 이번에 프로덕트 오너 역할까지 맡게 되면서, 전혀 다른 종류의 부담이 생겼습니다.

프로덕트/그로스 데이터 분석은 결이 달랐습니다

제가 기존에 해오던 분석은 대체로 이런 목적이었습니다.

데이터를 깔끔하게 만들고
모델이 학습할 수 있게 가공하고
예측이나 분류 성능을 개선하는 것

그런데 프로덕트 오너가 되자 질문이 달라졌습니다.

이번 기능 출시, 성공한 건가?
전환율이 떨어졌다면, 어디서 떨어졌나?
문제는 마케팅 때문인가, 프로덕트 때문인가?
그래서 지금 당장 뭘 해야 하나?

여기서 제가 느낀 건 하나였습니다.

SQL과 파이썬을 잘하는 것만으로는 부족했습니다.

왜냐하면 프로덕트/그로스 데이터 분석은
퍼널, 코호트, 리텐션, 활성화 같은 용어와 프레임을 빠르게 이해하고
바로 의사결정으로 연결해야 했기 때문입니다.

클로드 코드로, 데이터분석가 만들기 : https://inf.run/tj3Np

더 중요한 건 “분석”이 목적이 아니었습니다

이때 더 크게 깨달았던 게 있습니다.

데이터 분석의 목적은 “분석 자체”가 아니었습니다.
예쁘게 차트를 만들고, 멋진 리포트를 만드는 것도 아니었습니다.

핵심은 하나였습니다.

실행할 액션을 도출하고
그 액션을 실행하고
비즈니스가 실제로 개선되게 만드는 것

현업에서 데이터 분석은 “정답 맞히기 게임”이 아니라
“지금 당장 무엇을 해야 하는지”를 빠르게 결정하는 도구였습니다.

그래서 저는 ‘오지표 팀장’을 만들었습니다

그때부터 저는 이런 생각을 했습니다.

“질문을 길게 잘 던질 필요 없이,
딱 한 줄만 입력하면 분석과 액션이 바로 나오는 방식이면 어떨까?”

그렇게 만들게 된 것이
**데이터 분석 팀장 ‘오지표 팀장’**입니다.

오지표 팀장의 컨셉은 단순합니다.

질문 한 줄 → 분석 → 인사이트 → 실행 액션 TOP3

예를 들어 이런 질문을 던질 수 있습니다.

“이번 주 광고 성과 분석해줘”
“이번 주 전환율 분석해줘”
“이번 릴리즈 성과 분석해줘”
“이번 주 KPI 요약해줘”
“문의 폭주 원인 분석해줘”

그리고 중요한 포인트는 여기서 끝이 아닙니다.

“원인이 뭐다”라고 말하고 끝나는 게 아니라,
오늘 당장 실행할 액션을 같이 제시하는 것이 핵심이었습니다.

파이썬 몰라도, 머신러닝 몰라도 ‘분석’은 가능합니다

또 하나 확실히 느낀 점이 있습니다.

많은 분들이 데이터 분석을 시작하기 전에
SQL, 파이썬, 머신러닝을 먼저 공부해야 한다고 생각합니다.

그런데 현실에서 더 필요한 것은
“지금 당장 비즈니스에 도움이 되는 질문을 던지고,
결론과 액션을 얻는 경험”이라고 생각했습니다.

그래서 오지표 팀장은
파이썬 문법을 몰라도, 머신러닝을 몰라도
다음과 같은 질문도 가능하도록 구성했습니다.

“이탈 가능성이 높은 유저 그룹을 찾아줘”
“결제할 확률이 높은 유저 TOP 100 추천해줘”
“전환율 하락 원인을 영향 큰 요인 순으로 알려줘”
“행동 패턴으로 유저를 5개 그룹으로 분류해줘”

마무리: 데이터 분석은 실행을 시작하게 만드는 도구였습니다

결론적으로 저는 이렇게 정리하게 되었습니다.

데이터 분석의 목적은 실행할 액션을 도출해서
비즈니스를 성장시키는 것입니다.

오지표 팀장은 그 과정을 더 빠르게 만들기 위해
제가 직접 만든 “실무형 데이터 분석 팀장”입니다.

오지표 팀장 만드는 방법 (강의 안내)

오지표 팀장을 만드는 과정은
블로그 글 하나로 다 담기에는 길어서, 강의로 정리해두었습니다.

인프런 강의 링크: https://inf.run/tj3Np

필요한 분들께 도움이 되었으면 좋겠습니다.

앤드류 응, 스탠포드 강연 요약 - “코딩만으론 안 됩니다” AI 시대 개발자 생존법

Pro.Dev — Wed, 21 Jan 2026 20:20:36 +0900

이제는 코드를 짜는 게 어려운 게 아니라, 뭘 만들어야 할지가 더 어렵다

요즘 개발을 조금이라도 해본 사람이라면
이 말에 고개가 끄덕여질 거다.

예전에는
“이거 구현 가능해?”가 제일 어려운 질문이었다면
지금은
“이 기능, 진짜 필요한가요?”가 더 어렵다

이건 그냥 개인적인 생각이 아니다.
스탠포드에서 열린 강연에서,
AI 분야의 최전선에 있는 앤드류 응 교수는 이걸 아주 명확하게 짚었다.

AI 시대에 문제는 코딩이 아니다.
무엇을 만들지 결정하는 게 훨씬 어렵다.

특히 이 말은
신입·주니어 개발자일수록 더 중요하다.

왜 이런 말이 나왔을까?

이건 “개발자도 기획 좀 해라” 같은 뻔한 소리가 아니다.
현장에서 실제로 벌어지고 있는 변화 때문이다.

1. 코딩은 정말 빠르게 쉬워지고 있다

AI 코딩 도구를 써본 사람은 안다.

예전엔 30분~1시간 걸리던 코드가
지금은 설명 몇 줄이면 바로 나온다

심지어:

에러 원인 찾기
리팩토링
테스트 코드 작성

이런 것도 AI가 같이 해준다.

그래서 요즘 개발 현장에서는 이런 장면이 자주 나온다.

“일단 만드는 건 금방 만드는데,
이걸 왜 만드는지 설명하는 데 시간이 더 걸린다”

코드 자체는 더 이상 병목이 아니다.

2. 회사에서 개발자에게 묻는 질문이 바뀌었다

예전엔 이런 질문이 많았다.

이거 기술적으로 가능해요?
구현하는 데 얼마나 걸려요?

요즘은 질문이 이렇게 바뀐다.

이 기능, 누가 쓰죠?
이거 안 만들면 어떤 문제가 생기죠?
사용자는 이걸 언제, 왜 쓰나요?

이 질문에 답할 수 있는 개발자는
회의에서 목소리가 커진다.

반대로
코딩은 잘하는데 이 질문에 답을 못 하면
점점 “시키는 일만 하는 사람”이 된다.

앤드류 응이 말하는 개발자의 역할 변화

앤드류 응은 개발을 이렇게 설명한다.

예전:
기획서 → 개발 → 배포
지금:
만들기 → 써보게 하기 → 피드백 → 고치기 → 다시 만들기

이게 반복되는 루프다.

중요한 건,
이 루프에서 가장 중요한 역할이
“코드를 많이 치는 사람”이 아니라는 점이다.

무엇을 만들지 정하고
사용자 반응을 보고
다음에 뭘 고칠지 판단하는 사람

이 사람이 속도를 쥔다.

그래서 그는 요즘 개발자를
단순한 코더가 아니라
‘프로덕트를 이해하는 엔지니어’라고 부른다.

이 얘기가 신입·주니어에게 더 중요한 이유

경력이 쌓인 개발자는
이미 경험으로 “이건 별로다 / 이건 될 것 같다”는 감이 있다.

하지만 신입·주니어는 다르다.

기술 스택은 열심히 공부했는데
막상 “그래서 뭘 만들어야 하지?”에서 막힌다

여기서 두 갈래로 갈린다.

A. “일단 시키는 것만 잘하자”

→ 안정적이지만, 성장 속도는 느리다

B. “이거 왜 만드는지부터 이해해보자”

→ 초반엔 어렵지만, 체감 성장 속도가 다르다

앤드류 응이 말하는 건
신입에게 갑자기 PM이 되라는 얘기가 아니다.

“질문 하나만 바꿔도 된다”는 얘기다.

신입·주니어 개발자가 바로 써먹을 수 있는 질문 3가지

기능 하나를 맡았을 때,
아래 질문 중 하나라도 던질 수 있으면 충분하다.

이 기능, 누가 쓰나요?
이거 없으면 사용자가 제일 불편한 상황이 뭐죠?
나중에 이 기능이 잘 됐는지는 어떻게 판단하나요?

이 질문을 던질 수 있는 개발자는
이미 코드 밖을 보기 시작한 사람이다.

그래서 지금 뭘 하면 좋을까?

앤드류 응의 조언을
신입/주니어 기준으로 정리하면 딱 이거다.

배우기만 하지 말고, 뭐라도 만들어라
완벽하지 않아도 괜찮다
대신 “왜 만들었는지”는 설명할 수 있어야 한다

토이 프로젝트든,
회사에서 맡은 작은 기능이든,

“이 기능은 ○○ 문제를 해결하려고 만들었다”

이 문장을 말할 수 있으면
그 순간부터 개발자의 역할이 달라진다.

마지막으로, 이 문장만 기억하면 된다

앤드류 응이 스탠포드에서 한 말을
한 문장으로 줄이면 이거다.

이제는 코드를 잘 짜는 개발자보다
왜 이 코드를 짜는지 설명할 수 있는 개발자가 더 빨리 성장한다.

신입·주니어일수록
이걸 빨리 체감할수록
커리어 속도가 확실히 달라진다.

LlamaIndex Cloud 란? 언제 사용하면 좋을까?

Pro.Dev — Wed, 21 Jan 2026 14:58:20 +0900

RAG를 직접 만들 수 있는데도

나는 LlamaIndex Cloud를 썼다

20년 넘게 SW 개발을 하면서,
데이터 파이프라인, 검색 시스템, ML 서빙, 인프라까지
다 해봤다.

RAG도 마찬가지다.
구조도 알고, 병목도 알고,
성능이 어디서 갈리는지도 안다.

그런데 이번 프로젝트에서는
의외로 빠르게 LlamaIndex Cloud를 선택했다.

이유는 단순했다.

“이건 기술 문제가 아니라, 제품 개발 문제였기 때문이다.”

RAG를 직접 만들면 뭐가 다른가?

할일이 조금 늘어난다.

문서 파서 정리
Chunk 전략 결정
Embedding 모델 실험
벡터 DB 선택
검색 파이프라인 튜닝
프롬프트 결합
성능 평가 기준 설계
운영 / 재인덱싱 / 변경 관리

이건 난이도가 높아서 문제가 아니다.
문제는 이걸로 할까 저걸로 할까 결정할게 너무 많다는 거다.

그리고 그 대부분은
제품 차별화와 직접적인 관계가 없다.

이번 프로젝트의 조건은 이랬다

RAG는 핵심 기능이지만, 핵심 차별점은 아님
빠른 실험과 반복이 중요
“지금 왜 잘 되는지”를 설명할 수 있어야 함
PoC가 아니라 실사용 단계를 전제로 함

이 조건에서
“RAG 인프라를 직접 설계·운영”하는 건
솔직히 가성비가 안 맞았다.

그래서 선택한 게 LlamaIndex Cloud였다

결정한 포인트는 명확했다.

RAG의 표준적인 복잡도를 이미 캡슐화해둠
인덱싱 / 검색 / 평가를 운영 관점에서 제공
PoC → Production 전환 비용이 낮음

즉,

“우리가 잘 아는 문제를
다시 증명하지 않아도 되는 것”

이였다.

실제로 적용한 사례 ①

사내 문서 기반 Q&A (운영 전제)

이건 흔한 케이스지만,
운영까지 가면 얘기가 달라진다.

요구사항

문서 변경이 잦음
답변 일관성 중요
“왜 이 답이 나왔는지” 설명 필요

LlamaIndex Cloud를 쓰면서
의외로 가장 만족스러웠던 건 이거였다.

Chunk / Retrieval 전략을 디폴트로 믿을 수 있음
인덱스 변경에 대한 운영 부담 감소
검색 결과와 답변의 관계가 명확함

기술적으로 새로울 건 없었다.
대신 예측 가능성이 생겼다.

실제로 적용한 사례 ②

고객 상담 로그 기반 응답 보조

이건 “LLM을 어디까지 믿을 것인가”가 핵심인 문제였다.

그래서 선택한 전략은:

자동 응답 X
상담원 보조 O

과거 상담 로그를 인덱싱해서
“이 상황에서 보통 이렇게 대응했다”를
구조적으로 보여주는 방식으로 썼다.

이때 LlamaIndex Cloud의 장점은 명확했다.

검색 품질이 안정적
답변 근거를 같이 제시 가능
품질 이슈가 생겼을 때 추적 가능

Eval 기능은 “있으면 좋은 옵션”이 아니었다

솔직히 말하면,
이 부분 때문에 선택했다고 해도 과언이 아니다.

LLM 프로젝트에서 가장 곤란한 질문은 이거다.

“지금 이 시스템, 좋아진 건가요?”

LlamaIndex Cloud에서는:

질문 세트 정의
기준 답변 설정
변경 전/후 비교

이게 가능하다.

이건 개발 편의성의 문제가 아니라
조직 내 커뮤니케이션 문제를 해결해준다.

그래서 내가 내린 결론

LlamaIndex Cloud는
“RAG를 못 만드는 팀을 위한 도구”가 아니다.

오히려,

RAG를 이미 알고 있는 팀이
그걸 ‘제품화’할 때 선택하는 도구

에 가깝다.

직접 구현이 더 나은 경우도 분명 있다

연구 목적
비표준 검색 구조
초대규모 트래픽 최적화
인프라 자체가 경쟁력인 경우

이런 상황이라면
당연히 직접 만드는 게 맞다.

그러나 다음처럼,

“우리가 잘하는 걸 증명하는 대신,
우리가 만들어야 할 걸 만들자.”

이게 LlamaIndex Cloud를 쓴 이유다.

도메인 주도 설계(Domain-Driven Design, DDD)란? 현업 사용 방식

Pro.Dev — Tue, 20 Jan 2026 18:41:21 +0900

0. 이 글을 쓰는 이유

“그래서 실제로 언제 쓰게 되느냐”
“안 쓰면 뭐가 얼마나 불편해지느냐”

이 글은
DDD를 이미 알고 있는 사람이 아니라,
적용해야 할지 고민 중인 개발자를 위한 글이다.

1. 대부분의 서비스는 DDD 없이 시작한다 (나도 그랬다)

나도 처음부터 DDD를 염두에 두고 개발하지 않았다.

초기 구조는 아주 흔했다.

Controller → Service → Repository

CRUD 위주
Service에 조건 분기 몇 개
빠른 개발, 빠른 검증

이 단계에서는
DDD를 안 쓰는 게 정답에 가깝다고 생각한다.

솔직히 말하면,
이 시점에 DDD를 얹으면 이런 말이 나온다.

“이거 너무 과한 거 아니에요?”

맞는 말이다.

2. “Service가 망가지고 있다”는 느낌이 처음 든 순간

문제는 서비스가 커지면서 생겼다.

처음엔 단순히 Service 파일이 커졌다.
200줄 → 400줄 → 600줄.

그런데 어느 순간부터 성격이 바뀌었다.

같은 정책 로직이 여러 Service에 복붙된다
조건 하나 바꾸려면 파일 여러 개를 열어본다
기능 추가보다 기존 로직 수정이 더 무섭다

그때 실제로 있었던 코드가 이런 형태였다.

(Before) 흔한 Service 비대화 코드

@Transactional
public PolicyResult getPolicyForLearning(Long userId) {

    User user = userRepository.findById(userId).orElseThrow();

    Subscription sub = subscriptionRepository.findActiveByUserId(userId);
    ParentSetting setting = parentSettingRepository.findByUserId(userId);

    boolean isPremium = sub != null && sub.getExpireAt().isAfter(Instant.now());
    int childAge = user.getChildAge();
    boolean isBlocked =
        setting != null && setting.getBlockedCategories().contains("GAME");

    if (childAge < 7) {
        return PolicyResult.denied("age_limit");
    }
    if (isBlocked) {
        return PolicyResult.denied("blocked_category");
    }
    if (!isPremium) {
        return PolicyResult.limited("not_premium");
    }

    return PolicyResult.allowed();
}

이 코드 자체가 “나쁜 코드”는 아니다.
문제는 이 정책 로직이 여기저기 흩어지기 시작했다는 것이다.

3. 그때 깨달은 문제의 본질

처음엔 이렇게 생각했다.

“Service를 더 쪼개야 하나?”
“클래스를 나누면 해결될까?”

그런데 쪼개도 해결이 안 됐다.

왜냐하면,
문제는 크기가 아니라 책임이었기 때문이다.

이 정책 로직의 주인은 누구인가?
이 규칙을 고치면 어디까지 영향이 가는가?

코드만 봐서는 답이 없었다.

이때 처음으로 DDD를
아키텍처가 아니라 ‘규칙 정리 방법’으로 보기 시작했다.

4. 내가 적용한 DDD는 “라이트 DDD”였다

여기서 중요한 포인트가 있다.

DDD를 적용했다고 해서
구조가 갑자기 복잡해지지는 않았다.

내가 한 건 딱 하나였다.

“규칙을 Service에서 도메인 객체로 옮기기”

5. (After) 규칙의 주인을 만든다 — Policy 도메인

Domain: 규칙의 주인

public final class UserPolicy {

    private final SubscriptionStatus subscriptionStatus;
    private final ChildAge childAge;
    private final ParentRestrictions restrictions;

    public UserPolicy(SubscriptionStatus subscriptionStatus,
                      ChildAge childAge,
                      ParentRestrictions restrictions) {
        this.subscriptionStatus = subscriptionStatus;
        this.childAge = childAge;
        this.restrictions = restrictions;
    }

    public PolicyResult evaluateForLearning() {
        if (childAge.isUnder(7)) {
            return PolicyResult.denied("age_limit");
        }
        if (restrictions.isCategoryBlocked("GAME")) {
            return PolicyResult.denied("blocked_category");
        }
        if (!subscriptionStatus.isPremiumActive()) {
            return PolicyResult.limited("not_premium");
        }
        return PolicyResult.allowed();
    }
}

Value Object: 규칙을 읽기 쉽게 만든다

public final class ChildAge {
    private final int value;

    public ChildAge(int value) {
        this.value = value;
    }

    public boolean isUnder(int limit) {
        return value < limit;
    }
}

public final class SubscriptionStatus {
    private final Instant expireAt;

    public SubscriptionStatus(Instant expireAt) {
        this.expireAt = expireAt;
    }

    public boolean isPremiumActive() {
        return expireAt != null && expireAt.isAfter(Instant.now());
    }
}

여기서 핵심은
조건문이 줄었냐가 아니다.

“정책 로직이 UserPolicy로 고정됐다”는 점이다.

6. Service는 이렇게 얇아졌다

@Transactional(readOnly = true)
public PolicyResult getPolicyForLearning(Long userId) {

    User user = userRepository.findById(userId).orElseThrow();
    Subscription sub = subscriptionRepository.findActiveByUserId(userId);
    ParentSetting setting = parentSettingRepository.findByUserId(userId);

    UserPolicy policy = new UserPolicy(
        new SubscriptionStatus(sub == null ? null : sub.getExpireAt()),
        new ChildAge(user.getChildAge()),
        new ParentRestrictions(
            setting == null ? null : setting.getBlockedCategories()
        )
    );

    return policy.evaluateForLearning();
}

Service는 이제:

데이터 조합
도메인 호출
흐름 제어

만 담당한다.

7. 이때 처음으로 체감한 DDD의 효과

이 구조로 바꾸고 나서
팀에서 이런 말이 나왔다.

“아, 정책은 여기만 보면 되는구나.”

그 한마디로
DDD 적용의 목적은 달성됐다고 느꼈다.

8. DDD가 오히려 독이 되었던 경험

DDD를 한 번 적용해보고 나면,
이런 생각이 들기 쉽다.

“이 도메인도 중요해 보이는데,
처음부터 DDD 구조로 가면 더 깔끔하지 않을까?”

나도 그랬다.

한 번은 비교적 단순한 영역에
미리 도메인을 만들어두고 시작했다.

Entity
Policy
Validator
Domain Service

겉보기엔 그럴듯했다.
그런데 시간이 지나면서 문제가 생겼다.

실제 규칙은 거의 늘지 않았고
대부분 CRUD였고
도메인 객체는 껍데기가 됐다

그때 팀에서 이런 말이 나왔다.

“이거… 그냥 Service에 있으면 되는 거 아닌가요?”

맞는 말이었다.

이 경험 이후로 생긴 기준은 하나다.

DDD는 ‘중요해 보이는 영역’이 아니라,
‘실제로 복잡해진 영역’에만 써야 한다.

9. DDD는 왜 항상 “중간에” 들어오는가

돌아보면,
DDD는 항상 리팩토링의 결과로 등장했다.

한 번도 이런 적은 없었다.

“이번 프로젝트는 처음부터 DDD로 갑시다.”

대신 항상 이런 흐름이었다.

빠르게 만들고
로직이 쌓이고
규칙이 얽히고
Service가 버거워지고
구조를 다시 보게 된다

그리고 그때서야
“도메인”이라는 개념이
코드로 드러나기 시작한다.

재밌는 건,
이 과정을 겪기 전엔 DDD가 잘 와닿지 않았다는 거다.

책으로 볼 땐 과해 보였던 구조가,
막상 겪고 나면 “아, 이걸 말하는 거였구나”가 된다.

10. DDD를 했다고 말할 수 있는 현실적인 기준

누군가 나에게 묻는다.

“이 정도면 DDD 했다고 말해도 되나요?”

내 대답은 늘 비슷하다.

아래 질문에 “예”라고 답할 수 있다면 충분하다

규칙이 한 곳에 모여 있는가?
규칙의 이름이 코드에 드러나는가?
정책 수정 시 고칠 위치가 명확한가?
팀원이 “이 로직 어디 보면 되죠?”라고 묻지 않는가?

이걸 만족하면,

패키지가 단순해도
레이어가 많지 않아도

DDD를 적용했다고 말해도 무리 없다고 본다.

11. DDD의 진짜 효과는 “테스트”에서 나온다

DDD를 적용하고 나서
가장 체감이 컸던 건 테스트였다.

이전에는:

Service 테스트 = DB 세팅
조건 하나 테스트하려고
- 데이터 여러 개 생성

DDD 이후에는:

도메인 객체 하나로
규칙 테스트 가능

실제로 생긴 도메인 테스트

class UserPolicyTest {

    @Test
    void under_age_should_be_denied() {
        UserPolicy policy = new UserPolicy(
            new SubscriptionStatus(Instant.now().plusSeconds(3600)),
            new ChildAge(6),
            new ParentRestrictions(Set.of())
        );

        PolicyResult result = policy.evaluateForLearning();

        assertThat(result.isDenied()).isTrue();
        assertThat(result.getReason()).isEqualTo("age_limit");
    }

    @Test
    void blocked_category_should_be_denied_even_if_premium() {
        UserPolicy policy = new UserPolicy(
            new SubscriptionStatus(Instant.now().plusSeconds(3600)),
            new ChildAge(10),
            new ParentRestrictions(Set.of("GAME"))
        );

        PolicyResult result = policy.evaluateForLearning();

        assertThat(result.isDenied()).isTrue();
        assertThat(result.getReason()).isEqualTo("blocked_category");
    }
}

이 테스트가 생긴 순간,
팀에서 이런 말이 나왔다.

“아, 이제 정책 고치는 게 무섭지 않네요.”

12. DDD는 ‘코드를 예쁘게 만드는 기술’이 아니다

DDD를 해보면서 가장 크게 느낀 건 이거다.

DDD는 구조를 멋있게 만드는 게 아니라,
변경을 덜 무섭게 만드는 선택이다.

규칙이 바뀔 때
예외가 추가될 때
정책이 복잡해질 때

DDD가 있으면,
“어디를 고쳐야 하는지”가 보인다.

CQRS(명령 쿼리 책임 분리) 란? 언제 왜 하는거야?

Pro.Dev — Tue, 20 Jan 2026 18:40:17 +0900

CQRS를 언제 쓰는지에 대한 이야기

이 글에서 말하는 CQRS는

Event Sourcing 없음
쓰기/읽기 DB 완전 분리 없음
“모든 API를 CQRS로” 아님

이다.

이 글에서 말하는 CQRS는 딱 이 수준이다.

“쓰기 로직과 조회 로직을
같은 모델, 같은 사고방식으로 묶지 않겠다는 선택”

1. CQRS를 고민하기 전, 실제 코드 상태

DDD를 어느 정도 적용한 이후였다.

쓰기 로직은 도메인 규칙 중심
Service 코드도 많이 정리됨
정책/권한 같은 로직은 제자리를 찾음

그런데 조회 쪽 코드가 문제였다.

실제로 있던 Service 코드 (요약)

@Transactional(readOnly = true)
public UserLearningSummary getUserLearningSummary(Long userId) {

    User user = userRepository.findById(userId)
        .orElseThrow();

    Subscription subscription = subscriptionRepository
        .findActiveByUserId(userId);

    List<LearningHistory> histories =
        learningHistoryRepository.findRecentByUserId(userId);

    boolean canAccessPremium =
        subscription != null && !subscription.isExpired();

    int completedCount = histories.stream()
        .filter(LearningHistory::isCompleted)
        .count();

    return new UserLearningSummary(
        user.getName(),
        canAccessPremium,
        completedCount
    );
}

이 코드를 처음 보면,
딱히 이상해 보이지 않는다.

문제는 이런 코드가 수십 개였다는 거다.

2. 문제가 터진 지점 (실제 계기)

문제는 늘 조회에서 터졌다.

실제로 반복되던 상황

“이 화면에 필터 하나만 추가해주세요”
“정렬 기준을 바꿔야 해요”
“이 값도 같이 내려주세요”

그때마다:

Repository 쿼리를 고치고
Entity를 건드리고
Service 로직을 다시 확인했다

어느 순간부터 이런 생각이 들었다.

“이거 쓰기 로직이랑 아무 상관도 없는 변경인데,
왜 이렇게 조심해야 하지?”

결정적인 계기는 성능 이슈였다.

3. 조회 성능 이슈 + 도메인 코드 결합의 문제

특정 조회 API가 느려졌다.

원인을 보면:

조인 5~6개
N+1 이슈
불필요한 Entity 로딩

그래서 자연스럽게 이런 작업을 하게 된다.

@Entity
public class User {
    // fetch 전략 변경
    @OneToMany(fetch = FetchType.LAZY)
    private List<LearningHistory> histories;
}

그런데 이 변경이,
쓰기 로직에도 영향을 주기 시작했다.

트랜잭션 범위가 바뀌고
예상치 못한 LazyInitializationException
도메인 로직 테스트가 깨짐

이때 처음으로 들었던 생각이 이거다.

“조회 때문에 도메인 코드가 흔들리는 게 맞나?”

4. CQRS를 고민하게 된 진짜 이유

CQRS를 고민하게 만든 건
“확장성”이나 “아키텍처 멋짐”이 아니었다.

딱 이거였다.

“조회 요구사항 때문에
쓰기/도메인 코드가 계속 오염된다.”

조회는 화면 중심
쓰기는 규칙 중심
성격이 완전히 다른데
같은 구조에 묶여 있었다

5. 처음 시도한, 가장 작은 CQRS

처음부터 큰 구조를 바꾸진 않았다.

가장 먼저 한 건 이것 하나였다.

조회 전용 Service + Repository를 따로 만들기

기존

UserService
 ├── createUser()
 ├── updateSubscription()
 └── getUserLearningSummary()

변경 후

UserCommandService
 ├── createUser()
 └── updateSubscription()

UserQueryService
 └── getUserLearningSummary()

이것만으로도 체감이 있었다.

6. 조회 쪽 코드 변화 (실제 스냅샷)

조회 쪽에서는 Entity를 버렸다.

CQRS 이후 Query 코드

public UserLearningSummaryDto getUserLearningSummary(Long userId) {

    return userQueryMapper.selectUserLearningSummary(userId);
}

<select id="selectUserLearningSummary" resultType="UserLearningSummaryDto">
SELECT
    u.name            AS userName,
    CASE
        WHEN s.id IS NOT NULL AND s.expire_at > NOW()
        THEN true
        ELSE false
    END                AS canAccessPremium,
    COUNT(lh.id)       AS completedCount
FROM users u
LEFT JOIN subscriptions s ON s.user_id = u.id
LEFT JOIN learning_history lh ON lh.user_id = u.id
WHERE u.id = #{userId}
GROUP BY u.id
</select>

중요한 포인트는 이거다.

도메인 Entity X
비즈니스 규칙 X
화면에 필요한 데이터만 O

7. CQRS 적용 후, 처음으로 느낀 변화

이 구조로 바꾸고 나서
처음으로 이런 경험을 했다.

조회 쿼리를 대폭 수정했는데
쓰기 로직은 단 한 줄도 안 봤다.

성능 튜닝 자유로움
화면 요구사항 대응 빨라짐
도메인 코드 안정화

이때 확신이 생겼다.

“아, 이 정도 분리는
CQRS라고 불러도 되겠다.”

8. CQRS를 잘못 썼던 순간도 있었다

CQRS를 한 번 성공적으로 써보면,
사람 마음이 간사해진다.

“이것도 CQRS로 나누면 더 깔끔해지지 않을까?”

나도 그랬다.

실제로 했던 실수

단순한 조회 API까지
굳이 Query Service / Mapper로 분리
Entity 안 써도 되는 걸 자랑처럼 여김

결과는 어땠냐면,

코드 양만 늘고
흐름 파악은 더 어려워지고
팀원은 “이건 왜 분리된 거죠?”를 계속 물었다

그때 깨달은 게 있다.

CQRS는 ‘문제가 생긴 영역’을 분리하는 거지,
‘깔끔해 보일 것 같은 영역’을 분리하는 게 아니다.

9. “이 정도면 CQRS 아닌가?” 착각 포인트

CQRS 얘기 나오면
사람들이 자주 헷갈리는 지점이 있다.

착각 1: “읽기/쓰기 메서드 나눴으니까 CQRS”

public User getUser(Long id);        // Query
public void updateUser(User user);  // Command

이건 그냥 메서드 분리다.
CQRS라고 부르기엔 너무 약하다.

착각 2: “Service만 나눴으니까 CQRS”

UserService
UserQueryService

이건 출발점은 맞지만,
조회가 여전히 Entity/도메인에 묶여 있으면
효과는 제한적이다.

내가 체감한 CQRS의 핵심은 이거였다.

조회가 도메인 코드에
영향을 주지 않게 되었는가?

이 질문에 “예”라고 답할 수 있어야
CQRS의 의미가 생긴다.

10. CQRS가 과해지는 순간들

CQRS가 부담이 되기 시작하는 시점도 분명히 있다.

이런 신호가 보이면 과하다

조회 코드보다
- 구조 설명이 더 길다
신규 개발자가
- “이건 Command예요? Query예요?”부터 묻는다
조회 하나 추가하려고
- 파일을 4~5개 만든다

이때는 잠깐 멈춰야 한다.

“이 분리가 지금 문제를 해결하고 있나,
아니면 구조를 유지하기 위한 구조가 됐나?”

11. CQRS를 안 쓰는 게 맞았던 실제 사례

모든 프로젝트에서 CQRS를 쓰진 않았다.

한 번은 이런 경우가 있었다.

조회 API는 많지 않고
대부분 단건 조회
성능 이슈도 거의 없음
도메인 규칙도 단순

이 상황에서 CQRS를 쓰면?

코드만 늘어난다
구조 설명 비용이 생긴다
얻는 이득은 거의 없다

이때는 의도적으로 CQRS를 안 썼다.

그리고 그 판단은 지금도 맞다고 생각한다.

12. 그래서 정리된 나만의 CQRS 기준

여러 번 써보고, 망해보고 나서
내 기준은 이렇게 정리됐다.

CQRS를 고민해볼 만한 조건

아래 중 3개 이상이면 고민한다.

조회 API가 계속 늘어난다
조회 요구사항이 자주 바뀐다
조인/집계/필터가 많다
조회 성능 이슈가 반복된다
조회 때문에 도메인 코드가 흔들린다

하나만 해당되면?

아직은 아니다.

13. “CQRS를 적용했다”고 말할 수 있는 최소 기준

DDD 때랑 비슷하게,
CQRS도 현실적인 기준이 필요하다.

내 기준은 이렇다.

쓰기 로직과 조회 로직이
- 코드 구조상 분리돼 있다
조회가
- 도메인 Entity에 의존하지 않는다
조회 변경이
- 쓰기 로직에 영향을 주지 않는다

이 정도면,

“풀 CQRS는 아니지만, CQRS를 적용했다”

라고 말해도 충분하다고 본다.

14. DDD와 CQRS의 관계를 다시 정리하면

마지막으로 이건 꼭 정리하고 싶다.

DDD ≠ CQRS
DDD → CQRS (강제 아님)
CQRS는 DDD의 보조 수단일 수는 있다

내 경험상 가장 자연스러운 흐름은 이거였다.

Service가 버거워진다
규칙을 정리하려고 DDD를 적용한다
조회와 쓰기의 성격 차이가 드러난다
그 차이를 구조로 인정하면서 CQRS를 쓴다

디자이너 없어도 Figma로 UX 플로우 프로토타입 만드는 방법

Pro.Dev — Thu, 15 Jan 2026 23:13:22 +0900

요즘 서비스 기획을 하다 보면
디자이너가 항상 바로 붙어주기 어려운 상황이 자주 생깁니다.

아이디어는 계속 나오는데
이게 실제로 갈지 말지도 모르는 단계에서
매번 디자이너에게 화면 작업을 요청하기엔
솔직히 좀 애매한 순간들이 많았습니다.

그러다 최근에
‘UX Flow 중심으로 빠르게 프로토타입을 만드는 방법’을 다룬 강의를 하나 듣게 됐는데,
생각보다 실무에 바로 써먹을 수 있어서 정리 겸 후기를 남깁니다.

기획 단계에서 항상 이런 문제가 있었습니다.

말로 화면을 설명하다 보니 서로 이해가 다름
회의 때는 다 알겠다고 했는데 결과물이 다르게 나옴
개발 들어간 뒤 다시 기획 수정
디자이너 리소스는 항상 부족

그래서
“완성도 높은 디자인”이 아니라
의사결정을 빠르게 할 수 있는 화면을
기획 단계에서 만들 수 있으면 좋겠다고 생각하던 차였습니다.

직접 써보니 좋았던 점

디자이너 없이, 피그마 몰라도 이렇게 프로토타입 했습니다.

기획 단계에서 화면을 이렇게 접근하게 됐습니다.

디자인 퀄리티는 신경 안 씀
클릭만 되면 되는 수준으로 화면 구성
“이 기능이 필요한지 / 이 흐름이 맞는지”만 확인

이렇게 하니까,

회의가 훨씬 빨리 끝나고
디자이너와 이야기할 때도 기준이 명확해지고
개발 들어가서 다시 뒤집는 일이 줄었습니다.

특히
“이 정도면 충분하다”는 기준을 잡아준 점이 제일 좋았습니다.

이런 분들께 추천

이 강의는 아래 같은 분들께 잘 맞을 것 같습니다.

디자이너는 있지만 항상 바쁜 팀
기획 아이디어를 말로 설명하다가 자주 꼬이는 분
Figma를 깊게 몰라도 화면 기획이 필요한 기획자/개발자
빠르게 합의하고 결정해야 하는 조직 환경

반대로
혼자 개발·디자인까지 다 하는 분들이나
완성도 높은 UI 디자인을 배우고 싶은 분들께는
조금 안 맞을 수도 있겠다는 생각은 들었습니다.

강의 링크

기획 단계에서
프로토타입을 **‘결과물’이 아니라 ‘의사결정 도구’**로 쓰고 싶다면
한 번쯤 들어볼 만한 강의라고 느꼈습니다.

[강의 링크]

가격도 부담 없는 편이라
개인적으로는 시간 아끼는 용도로 충분히 만족스러웠습니다.