기획자도 쉽게 배우는 SQL 기초

안녕하세요, IT 다이어리 독자 여러분~! 오늘부터 기획자분들을 위한 데이터베이스와 SQL 시리즈를 시작해볼게요. 회사에서 개발자들이랑 소통할 때 DB 얘기만 나오면 머리가 아픈 분들 많으시죠? 이 시리즈를 통해 개발자들과 더 원활하게 소통하고, 신뢰를 받을 수 있을 거예요!

## 기획자, 왜 데이터베이스를 알아야 할까요?

"아니... 난 기획자인데 데이터베이스를 왜 알아야 하냐고요?" 라고 생각하시는 분들, 잠시만요! 요즘 어떤 서비스든 데이터 기반으로 움직이고 있잖아요. 사용자가 어떤 버튼을 더 많이 클릭하는지, A/B 테스트 결과는 어떤지, 서비스 개선 방향을 어떻게 잡아야 할지... 이 모든 게 결국 데이터에서 시작된다는 거 다들 아시죠?

제가 실제로 기획자로 일하면서 데이터베이스를 알게 되니까 이런 장점들이 있더라고요:

- 개발자랑 회의할 때 "DB 테이블 구조 같이 봐도 될까요?"라고 물어보면 개발자들이 더 적극적으로 설명해줌 (리얼 한 팀으로 일할 수 있음!)
- 데이터 분석가한테 "이 테이블이랑 저 테이블 조인해서 이런 데이터 뽑아주실 수 있나요?"라고 정확하게 요청 가능
- 급하게 데이터가 필요할 때 개발자 스케줄 기다릴 필요 없이 직접 간단한 쿼리 날려서 확인 가능 (업무 효율성 증가!)
- 서비스 구조를 더 깊이 이해하게 되어 "아, 이건 DB 구조상 이렇게 하면 더 효율적이겠다" 같은 인사이트로 기획 품질 향상

IT 업계에서는 이제 기획자도 데이터를 직접 다룰 줄 알아야 해요. 특히 요즘 핫한 제품 관리자(PM)나 그로스 해커(Growth Hacker) 같은 포지션은 SQL을 기본 스킬로 생각하는 추세죠. 채용공고만 봐도 "SQL 사용 가능자 우대" 이런 문구 많이 보이잖아요!

## 데이터베이스가 뭔데요? 그냥 엑셀이랑 뭐가 달라요?

쉽게 말해서 데이터베이스는 **체계적으로 정리된 데이터 모음**이에요. "아, 그냥 엑셀 시트 같은 거구나~" 라고 생각하실 수도 있는데, 훨씬 더 강력하고 대용량 데이터를 효율적으로 관리할 수 있어요.

10만 건의 고객 데이터를 엑셀로 관리하다가 파일이 깨졌다고 생각해보세요... 진짜 끔찍하겠죠?

### 엑셀 vs 데이터베이스, 뭐가 다를까요?

가장 큰 차이점은 **확장성**과 **안정성**이에요. 엑셀은 개인이 소규모 데이터를 다루기에 좋지만, 서비스가 성장하면서 발생하는 방대한 데이터를 처리하기엔 한계가 있어요.

저도 학부생때 운영했던 서비스의 모든 데이터를 엑셀로 관리했다가 사용자가 늘어나면서 엑셀이 감당을 못해서 급하게 DB로 마이그레이션 했던 아찔한 경험이 있어요...

## 관계형 데이터베이스 vs 비관계형 데이터베이스

이왕 배우는 거 제대로 알아야겠죠? 데이터베이스에는 크게 두 가지 유형이 있어요.

### 관계형 데이터베이스 (RDBMS)

- 테이블 형태로 데이터 저장 (행과 열로 구성, 엑셀 시트랑 비슷한 느낌)
- 각 테이블 간의 관계를 설정할 수 있음 (이게 진짜 강력해요!)
- SQL을 사용해 데이터 관리 (이번 시리즈에서 배울 내용!)
- 대표적인 것들: MySQL(무료), PostgreSQL(무료), Oracle(유료), SQL Server(유료)
- 장점: 구조화된 데이터, 정확성, 일관성 보장 (금융, 쇼핑몰 같은 곳에서 중요)
- 단점: 한번 구조 만들어놓으면 변경하기 어려움, 수평 확장의 한계 (서버 늘리기 어려움)

### 비관계형 데이터베이스 (NoSQL)

- 다양한 형태로 데이터 저장 (문서, 키-값, 그래프 등)
- "이거 필요해? 그럼 그냥 추가해!" 식의 유연한 구조
- 엄청난 양의 데이터 처리에 유리 (빅데이터 처리할 때 좋음)
- 대표적인 것들: MongoDB(문서형), Redis(키-값), Neo4j(그래프형), Cassandra(컬럼형)
- 장점: 유연성, 확장성, 빠른 개발 (스타트업이나 소셜미디어에서 선호)
- 단점: "이 데이터 정확한 거 맞아?" 일관성 보장이 상대적으로 약함

기획자는 주로 관계형 데이터베이스를 접할 일이 많으니 이번 시리즈에서는 관계형 데이터베이스와 SQL에 집중할게요! (근데 MongoDB 같은 것도 요즘 많이 쓰이니 나중에 기회 되면 그것도 다뤄볼게요!)

## 데이터베이스 기본 용어 (개발자들이 자주 쓰는 용어 해석!)

개발자들이랑 회의할 때 자주 나오는 용어들을 정리해봤어요:

**테이블(Table)**: 데이터를 저장하는 표 형태의 객체예요. 예를 들어 '사용자' 테이블, '주문' 테이블 등이 있을 수 있어요. 엑셀의 시트와 비슷하다고 생각하시면 돼요. 실제로 네이버 같은 서비스는 수백 개의 테이블이 있어요!

**레코드(Record) 또는 행(Row)**: 테이블에서 하나의 데이터 항목이에요. 사용자 테이블에서는 한 명의 사용자 정보가 하나의 레코드가 되죠. 엑셀의 한 행과 같아요. 예를 들어 "김민준, 26세, 서울 거주" 같은 정보가 하나의 레코드죠.

**필드(Field) 또는 열(Column)**: 각 데이터의 속성이에요. 사용자 테이블이라면 '이름', '이메일', '가입일' 등이 필드가 될 수 있어요. 엑셀의 열과 동일한 개념이에요. 필드마다 데이터 타입도 지정할 수 있어요 (텍스트인지, 숫자인지, 날짜인지 등).

**스키마(Schema)**: 데이터베이스의 구조와 제약 조건을 정의한 것이에요. 쉽게 말해 데이터베이스의 설계도라고 할 수 있어요. "아파트 평면도" 같은 개념이라고 생각하시면 됩니다. 기획자가 이해하면 정말 도움 많이 되는 부분이에요!

**기본 키(Primary Key)**: 각 레코드를 고유하게 식별할 수 있는 값이에요. 주민등록번호 같은 개념이죠. 보통 '사용자ID'와 같은 것이 기본 키가 돼요. 절대로 중복될 수 없고, NULL(비어있음)이 될 수 없어요. "user_123456" 같은 식별자예요.

**외래 키(Foreign Key)**: 다른 테이블의 기본 키를 참조하는 필드예요. 이걸로 테이블 간의 관계를 설정해요. 예를 들어, 주문 테이블의 '사용자ID'는 사용자 테이블의 '사용자ID'를 참조할 수 있어요. 이게 바로 '관계형' 데이터베이스의 핵심이죠!

**인덱스(Index)**: 데이터 검색 속도를 높이기 위한 데이터 구조예요. 책의 색인과 비슷한 개념으로, 특정 데이터를 빠르게 찾을 수 있게 해줘요. 인덱스가 없으면 천만 건의 데이터에서 한 명을 찾을 때 처음부터 끝까지 다 뒤져야 하는데, 인덱스가 있으면 빠르게 찾을 수 있어요!

**쿼리(Query)**: 데이터베이스에 정보를 요청하는 명령어예요. SQL로 작성되며, 데이터 조회, 추가, 수정, 삭제 등의 작업을 수행할 수 있어요. 기획자라면 최소한 SELECT 쿼리는 작성할 줄 알면 좋아요 (다음 시간에 배울 거예요!)

**트랜잭션(Transaction)**: 데이터베이스에서 하나의 논리적 작업 단위를 말해요. 예를 들어, 계좌 이체는 출금과 입금이 모두 성공해야 완료되는 하나의 트랜잭션이죠. 중간에 문제가 생기면 모든 변경사항이 취소돼요(롤백). 은행 송금할 때 "보내는 건 성공했는데 받는 건 실패했다"는 일이 없도록 해주는 거죠!

## 데이터베이스 관계의 종류 (이건 기획할 때 정말 중요해요!)

테이블 간의 관계는 세 가지 유형으로 나눌 수 있어요. 이거 이해하면 서비스 설계할 때 큰 도움이 된답니다!

### 1:1 (일대일) 관계

- 한 테이블의 레코드가 다른 테이블의 레코드 하나와만 연결되는 관계
- 예: 사용자와 사용자 상세 정보 (한 사용자는 하나의 상세 정보만 가짐)
- 실제 사례: 카카오톡에서 기본 프로필과 상세 프로필 정보를 분리해서 저장하는 경우
- 활용: 자주 사용하지 않는 데이터를 별도 테이블로 분리할 때 주로 사용 (성능 최적화 위해)

### 1:N (일대다) 관계

- 한 테이블의 레코드가 다른 테이블의 여러 레코드와 연결되는 관계
- 예: 사용자와 주문 (한 사용자는 여러 주문을 할 수 있음)
- 실제 사례: 네이버 카페에서 한 회원이 여러 개의 게시글을 작성하는 관계
- 활용: 가장 흔한 관계 유형으로, 대부분의 비즈니스 로직에서 발견됨

### N:M (다대다) 관계

- 양쪽 테이블의 레코드가 서로 여러 개와 연결될 수 있는 관계
- 예: 학생과 강의 (한 학생이 여러 강의를 수강하고, 한 강의에 여러 학생이 참여)
- 실제 사례: 유튜브에서 사용자와 구독 채널의 관계 (한 사용자가 여러 채널 구독, 한 채널은 여러 구독자 보유)
- 활용: 직접 구현은 어려워서 보통 중간 테이블(연결 테이블)을 통해 두 개의 1 관계로 구현

예를 들어서 '사용자-강좌' 다대다 관계를 구현할 때는 '수강신청' 이라는 중간 테이블을 만들어서 해결할 수 있어요. 이렇게 하면 "언제 수강신청 했는지", "수강완료 했는지" 같은 정보도 함께 저장할 수 있거든요!

## 실제 서비스에서의 데이터베이스 구조 예시

실제 서비스는 어떻게 데이터베이스를 구성할까요? 인스타그램 같은 SNS 앱을 예로 들어볼게요:

```

사용자(Users) 테이블:
- 사용자ID (기본 키) ← "user_123456" 같은 고유 식별자
- 이름 ← "김민준"
- 이메일 ← "minjun@example.com"
- 프로필사진 ← "profile_123.jpg" (실제 이미지가 아닌 경로만 저장)
- 가입일 ← "2024-05-07 14:30:00"
- 상태 ← "active" (활성 / 휴면 / 탈퇴 등)

게시물(Posts) 테이블:
- 게시물ID (기본 키) ← "post_789012"
- 사용자ID (외래 키) ← "user_123456" (누가 작성했는지)
- 내용 ← "오늘 한강에서 피크닉 중!"
- 이미지URL ← "photo_789.jpg"
- 작성일 ← "2024-05-07 15:20:00"
- 수정일 ← "2024-05-07 15:25:00"
- 공개상태 ← "public" (전체공개 / 친구공개 / 비공개 등)

댓글(Comments) 테이블:
- 댓글ID (기본 키) ← "comment_456789"
- 게시물ID (외래 키) ← "post_789012" (어떤 게시물의 댓글인지)
- 사용자ID (외래 키) ← "user_654321" (누가 댓글 달았는지)
- 내용 ← "날씨 좋네요! 어디서 찍으셨어요?"
- 작성일 ← "2024-05-07 15:30:00"
- 수정일 ← "2024-05-07 15:30:00"

좋아요(Likes) 테이블:
- 좋아요ID (기본 키) ← "like_135790"
- 게시물ID (외래 키) ← "post_789012"
- 사용자ID (외래 키) ← "user_654321"
- 생성일 ← "2024-05-07 15:35:00"

팔로우(Follows) 테이블:
- 팔로우ID (기본 키) ← "follow_246801"
- 팔로워ID (외래 키, Users 테이블의 사용자ID 참조) ← "user_654321" (팔로우 하는 사람)
- 팔로잉ID (외래 키, Users 테이블의 사용자ID 참조) ← "user_123456" (팔로우 당하는 사람)
- 생성일 ← "2024-05-07 16:00:00"

```

이런 구조에서는 다음과 같은 관계가 있어요:

- 사용자와 게시물: 일대다 관계 (한 사용자가 여러 게시물 작성)
- 게시물과 댓글: 일대다 관계 (한 게시물에 여러 댓글 달림)
- 사용자와 댓글: 일대다 관계 (한 사용자가 여러 댓글 작성)
- 사용자와 게시물 좋아요: 다대다 관계 (좋아요 테이블로 구현)
- 사용자와 팔로우: 다대다 관계 (팔로우 테이블로 구현)

이런 데이터 관계를 이해하면 "인기 게시물 피드", "팔로우한 사람들의 최신 게시물", "내가 좋아요 누른 게시물 모아보기" 같은 기능을 기획할 때 어떤 테이블들을 어떻게 연결해야 할지 명확하게 설명할 수 있어요!

## ERD(Entity-Relationship Diagram) - 개발자와 소통의 필수 도구!

ERD는 데이터베이스의 구조를 시각적으로 표현한 다이어그램이에요. 테이블(엔티티)과 그 관계를 한눈에 볼 수 있어서, 개발자와 소통할 때 매우 유용해요.

기본적인 ERD 기호:

- 직사각형: 엔티티(테이블)
- 타원: 속성(필드)
- 마름모: 관계
- 선: 엔티티 간 연결, 관계의 종류에 따라 다르게 표시

전 개인적으로 ERD를 볼 때 "아, 이 서비스는 이런 데이터 구조를 가지고 있구나!"라는 인사이트를 많이 얻어요. 특히 복잡한 서비스일수록 ERD를 보면 전체 그림을 이해하기 쉬워져요.

기획 단계에서 개발자가 만든 ERD를 함께 검토하면 "아, 이 기능을 추가하려면 이 테이블에 이런 필드가 필요하겠네요"라고 더 구체적으로 커뮤니케이션할 수 있어요!

## DBMS(Database Management System) - 데이터베이스 관리 시스템

DBMS는 데이터베이스를 관리하는 소프트웨어예요. 회사마다 선호하는 DBMS가 달라요. 대표적인 DBMS로는:

### MySQL

- 오픈 소스, 무료
- 가장 널리 사용되는 DBMS 중 하나
- 웹 애플리케이션에 많이 사용됨
- 장점: 사용하기 쉬움, 커뮤니티 지원 활발 (구글만 해도 자료 엄청 많아요)
- 단점: 대규모 데이터처리에서는 성능 한계
- 실제 사용 사례: WordPress, Facebook(초기 버전), 배달의민족 등

### PostgreSQL

- 오픈 소스, 무료
- 고급 기능이 많고 확장성이 좋음
- 복잡한 쿼리와 대용량 데이터에 강점
- 장점: 표준 SQL 준수, 고급 데이터 타입 지원
- 단점: 초기 설정이 복잡할 수 있음
- 실제 사용 사례: 인스타그램, 우버, 넷플릭스 등

### Oracle

- 상용 DBMS, 유료
- 엔터프라이즈급 애플리케이션에 많이 사용
- 안정성과 보안성이 뛰어남
- 장점: 강력한 성능, 많은 기능
- 단점: 고비용, 복잡한 관리
- 실제 사용 사례: 국내 은행들, 삼성, LG 같은 대기업, 정부 시스템 등

### Microsoft SQL Server

- 상용 DBMS, 유료(Express 버전은 무료)
- Windows 환경에 최적화
- 기업용 솔루션에 많이 사용
- 장점: Windows 통합, 사용하기 쉬운 관리 도구
- 단점: 주로 Windows 환경에 제한
- 실제 사용 사례: 스타벅스, eBay, 마이크로소프트 서비스 등

기획자가 사실 데이터베이스 종류까지 고려할 필요는 크게 없지만, 그래도 이왕 배우는 김에 알아두면 좋잖아요!!

## 기획자를 위한 데이터베이스 이해 TIP (실무에서 바로 써먹는 팁!)

1. **서비스의 핵심 데이터 파악하기**:
    - 우리 서비스에서 가장 중요한 데이터는 뭐지? (예: 쇼핑몰이면 상품, SNS면 게시물)
    - 어떤 데이터를 수집해야 사용자 경험을 개선할 수 있을까? (예: 검색 기록, 클릭 로그)
    - 데이터의 생명주기는 어떻게 관리해야 할까? (예: 탈퇴 후 데이터 보관 기간)
    - 개인정보는 어떻게 안전하게 저장할 수 있을까? (암호화 필요한 필드 식별)
2. **데이터 간의 관계 생각하기**:
    - 사용자와 콘텐츠 사이에는 어떤 관계가 있지? (작성자, 좋아요, 구매자 등)
    - 이 기능을 위해서는 어떤 테이블들이 연결되어야 하지?
    - 이 데이터는 다른 데이터와 어떻게 연결되어야 의미가 있을까?
    - 중복 데이터를 줄이려면 어떻게 구조를 설계해야 할까?
3. **데이터 흐름 이해하기**:
    - 사용자가 회원가입하면 DB에 어떤 데이터가 어떤 순서로 저장될까?
    - 결제가 완료되면 주문 상태는 어떻게 변경되고, 재고는 어떻게 조정될까?
    - 게시물을 삭제하면 연관된 댓글, 좋아요는 어떻게 처리해야 할까?
    - 데이터 백업과 복구는 어떤 방식으로 이루어질까?
4. **데이터 요구사항 명확히 하기**:
    - 대시보드에서 보여줄 핵심 지표는 무엇일까? (DAU, WAU, 전환율 등)
    - A/B 테스트를 위해 어떤 데이터를 수집해야 할까?
    - 사용자 행동 분석을 위해 어떤 이벤트 로그를 남겨야 할까?
    - 마케팅 효과 측정을 위해 어떤 데이터가 필요할까?
5. **데이터 모델링에 참여하기**:
    - 기획 단계에서 개발자와 함께 ERD 회의에 참석해보세요!
    - "이 기능을 위해서는 이런 데이터가 필요해요"라고 구체적으로 요청해보세요.
    - 개발자들의 데이터 모델을 기획 관점에서 검토해보세요.
    - "이 필드는 나중에 확장성을 고려해서 더 넓게 설계해두면 어떨까요?" 같은 제안도 해보세요.

예를 들어서 개발팀에게 "이런 데이터가 필요해요" 라고 말하는 것보다, "이 테이블에서 이런 조건으로 데이터를 조회하고 싶어요"라고 구체적으로 말했을 때 훨씬 더 빠르게 피드백을 받을 수 있을거에요. 데이터베이스를 이해하는 기획자와 그렇지 않은 기획자는 개발자들의 신뢰도가 확실히 달라요!!

---

다음 편에서는 SQL의 기본 문법과 간단한 쿼리문 작성법에 대해 알아볼 거예요. "SELECT * FROM users WHERE age > 25 ORDER BY signup_date DESC LIMIT 10" 이런 거 한 번 써보면 왠지 개발자 된 것 같은 기분이 들거든요! 😁

개발자에게 "이런 데이터가 필요해요"라고 말하는 대신, 직접 데이터를 조회해볼 수 있는 방법을 배워볼게요!

질문이나 의견이 있으시면 댓글로 남겨주세요! 특히 "이런 내용도 다뤄주세요!" 하는 요청 있으시면 알려주세요~ 다음 내용에 반영할게요! 그럼 다음 글에서 만나요!

기획자를 위한 데이터베이스 기초

기획 업무 생산성을 높여줄 최신 모델 비교

안녕하세요~ IT 다이어리 독자 여러분 😊

지난번 포스팅에서 ReAct 프롬프팅에 대해 간략히 소개했는데, 오늘은 이 부분에 대해 더 자세히 설명해 드릴거에요!

## ReAct가 뭐예요?

'ReAct'는 'Reason(추론)'과 'Act(행동)'의 합성어예요. 쉽게 말해, AI가 주어진 문제에 대해 먼저 생각(추론)하고, 그 생각을 바탕으로 행동하는 방식이에요. 그리고 행동의 결과를 보고 다시 생각하고, 또 행동하고... 이런 과정을 반복하면서 문제를 해결해 나가는 방식이죠.

우리 인간도 사실 뭔가를 해결할 때 이런 과정을 거치잖아요? 예를 들어, 여행 계획을 세울 때:

1. **생각(Reason)**: "서울에서 부산까지 어떻게 가지?"
2. **행동(Act)**: 네이버에 '서울 부산 교통' 검색
3. **관찰(Observe)**: KTX, 버스, 비행기 등의 옵션이 있네?
4. **생각(Reason)**: "KTX가 가장 빠르겠다. 요금은 얼마지?"
5. **행동(Act)**: '서울 부산 KTX 요금' 검색
...

ReAct는 이런 인간의 문제 해결 방식을 AI에게 가르쳐주는 거예요! 😲

[백서](https://www.kaggle.com/whitepaper-prompt-engineering)에서는 이렇게 설명하고 있어요:

> "ReAct는 LLM이 복잡한 작업을 해결하기 위해 자연어 추론과 외부 도구를 결합하는 패러다임입니다. 이는 인간이 실제 세계에서 작동하는 방식, 즉 언어적으로 추론하고 정보를 얻기 위한 행동을 취하는 방식을 모방합니다."
> 

## ReAct 프롬프팅이란?

ReAct는 Reasoning(추론)과 Acting(행동)을 결합한 특별한 **프롬프팅 기법**이에요. 이 기법은 AI가 생각하고, 행동하고, 관찰하는 세 단계를 반복하면서 문제를 해결하도록 안내해요.

**ReAct의 주요 구성요소:**

- **Reasoning(추론)**: "이 문제를 해결하려면 어떤 정보가 필요할까?"
- **Acting(행동)**: "그 정보를 얻기 위해 무엇을 해야 할까?"
- **Observation(관찰)**: "행동의 결과로 무엇을 배웠을까?"

## 왜 기획자가 이걸 알아야 하나요?

사실 ReAct는 개발팀에서 구현해야 하는 고급 기술이에요. 하지만 기획자가 이걸 이해하고 있으면 다음과 같은 엄청난 이점이 있어요:

1. **개발팀과 소통이 수월해져요** - "그냥 AI 챗봇 만들어주세요"가 아니라 "ReAct 방식으로 구현해서 사용자 질문에 더 정확히 답변할 수 있게 해주세요"라고 구체적으로 요청할 수 있어요.
2. **더 강력한 AI 기능을 기획할 수 있어요** - 단순 Q&A를 넘어, 실시간 데이터를 검색하고 활용하는 고급 기능을 구상할 수 있어요.
3. **프로토타입 테스트가 가능해요** - 간단한 ReAct 프로토타입을 만들어 사용자 반응을 미리 테스트해볼 수 있어요.

## ReAct는 어떻게 작동하나요?

ReAct의 작동 과정은 생각보다 직관적이에요:

1. **사용자 질문 입력**: 사용자가 질문이나 요청을 입력해요.
2. **추론(Reasoning)**: AI가 이 질문에 대해 먼저 생각해요. "이 질문에 답하려면 어떤 정보가 필요할까?"
3. **행동(Acting)**: 필요한 정보를 얻기 위해 외부 도구(검색, API 호출 등)를 사용해요.
4. **관찰(Observation)**: 행동의 결과를 관찰해요.
5. **다시 추론**: 얻은 정보를 바탕으로 다시 생각해요.
6. **최종 답변**: 충분한 정보를 모았다고 판단되면 최종 답변을 제공해요.

이 과정을 시각적으로 표현하면 이런 느낌이에요:

```
사용자: 메탈리카 밴드 멤버들의 자녀는 총 몇 명이야?

AI 내부 생각: 메탈리카 밴드 멤버가 누구인지, 그리고 각 멤버의 자녀 수를 알아야겠다.

AI 행동: [검색] 메탈리카 밴드 멤버는 누구인가?
AI 관찰: 제임스 헷필드, 라스 울리히, 커크 해밋, 로버트 트루히요

AI 내부 생각: 각 멤버의 자녀 수를 알아봐야겠다.

AI 행동: [검색] 제임스 헷필드의 자녀 수는?
AI 관찰: 3명

AI 행동: [검색] 라스 울리히의 자녀 수는?
AI 관찰: 3명

...계속 진행...

AI 최종 답변: 메탈리카 밴드 멤버들의 자녀는 총 10명입니다.
```

## 이거 그냥 AI Agent 아니에요? ReAct랑 Agent랑 뭐가 달라요?

너무 좋은 질문이에요! 사실 헷갈릴 수밖에 없는 개념이거든요. 근데 핵심 차이를 간단히 말하자면:

**AI 에이전트** = 일을 처리하기 위해 만들어진 AI 시스템 전체 (자동차와 같은 완성품)

**ReAct 프롬프팅** = 에이전트가 효과적으로 작동하게 하는 특정 기술 (자동차의 엔진과 같은 부품)

쉽게 설명하자면, **ReAct는 에이전트를 만드는 방법 중 하나**라고 생각하시면 돼요.

## 기획자가 ReAct를 활용하는 방법

개발팀에 요청하기 전에, 실제로 어떤 기능이 가능한지 이해하는 게 중요해요. 아래는 ReAct를 활용한 실제 사례들이에요.

### 1. 데이터 기반 의사결정 도우미

```
사용자: 우리 앱의 최근 3개월 이탈률 데이터를 분석해서 개선 방안을 제안해줘.

AI 내부 생각: 이탈률 데이터가 필요하고, 업계 평균과 비교해야겠다.

AI 행동: [데이터베이스 쿼리] 최근 3개월 이탈률 데이터 가져오기
AI 관찰: 1월 30%, 2월 35%, 3월 40%로 증가 추세

AI 행동: [검색] 모바일 앱 평균 이탈률
AI 관찰: 업계 평균은 25%

AI 내부 생각: 이탈률이 업계 평균보다 높고 증가 추세에 있다. 주요 이탈 시점과 원인을 확인해야겠다.

AI 행동: [데이터베이스 쿼리] 사용자 여정에서 주요 이탈 지점 분석
AI 관찰: 온보딩 완료 후 첫 사용 시점에서 이탈률이 가장 높음

...계속 진행...

AI 최종 답변: 3개월간 이탈률이 30%에서 40%로 증가했으며, 특히 온보딩 이후 첫 사용 단계에서 이탈이 많습니다. 다음과 같은 개선 방안을 제안합니다: 1) 온보딩 단순화, 2) 첫 사용 인센티브 제공, 3) 푸시 알림 최적화...
```

### 2. 맞춤형 사용자 지원 챗봇

```
사용자: 내 주문 #12345는 언제 배송될까요?

AI 내부 생각: 주문 번호를 확인하고 배송 상태를 조회해야겠다.

AI 행동: [API 호출] 주문 #12345 상태 확인
AI 관찰: 포장 완료 상태, 예상 배송일 5월 15일

AI 내부 생각: 배송이 지연된 이유가 있는지 확인해보자.

AI 행동: [API 호출] 해당 지역 배송 상황 확인
AI 관찰: 서울 지역 물류센터 정상 운영 중, 지연 없음

AI 최종 답변: 주문 #12345는 현재 포장이 완료되었으며, 5월 15일에 배송될 예정입니다. 서울 지역 배송이 정상적으로 운영 중이라 지연 없이 받으실 수 있을 것 같습니다. 배송 상태가 변경되면 알림을 보내드리겠습니다.
```

### 3. 경쟁사 분석 도우미

```
사용자: 우리 서비스와 비슷한 A사의 최근 업데이트 내용과 사용자 반응을 알려줘.

AI 내부 생각: A사의 최근 업데이트 내용과 사용자 반응을 찾아봐야겠다.

AI 행동: [검색] A사 최근 앱 업데이트 내역
AI 관찰: 4월 10일 버전 3.5 출시, 주요 기능: 다크모드, 새로운 결제 시스템, UI 개선

AI 행동: [API 호출] 앱스토어 A사 앱 리뷰 분석
AI 관찰: 최근 리뷰 평점 4.2/5, 다크모드에 대한 긍정적 반응, 결제 시스템 버그 관련 불만 다수

AI 행동: [소셜미디어 분석] A사 관련 트위터 감성 분석
AI 관찰: 긍정적 언급 65%, 부정적 언급 35%, 주요 불만은 결제 오류

...계속 진행...

AI 최종 답변: A사는 4월 10일 버전 3.5를 출시했으며, 다크모드, 새 결제 시스템, UI 개선이 주요 업데이트입니다. 사용자들은 다크모드에 매우 긍정적이나, 새 결제 시스템에서 버그를 경험하고 있습니다. 이는 우리가 결제 시스템 안정성을 강조하는 마케팅 포인트로 활용할 수 있는 기회입니다...
```

## 개발팀에 효과적으로 ReAct 요청하기

개발팀에 ReAct 구현을 요청할 때는 다음과 같은 요소를 명확히 전달하는 게 좋아요:

1. **어떤 외부 도구가 필요한지**: 검색 엔진, 데이터베이스, API, 파일 시스템 등
2. **사용자 시나리오**: 구체적인 사용 사례와 예상 질문
3. **추론 과정 표시 여부**: 사용자에게 AI의 생각 과정을 보여줄지 여부
4. **기대하는 결과물**: 최종 답변의 형식과 구조

예를 들어 이렇게 요청할 수 있어요:

```

"사용자 지원 챗봇에 ReAct 기능을 구현해주세요. 이 챗봇은:
1. 주문 관리 시스템 API에 접근해 주문 상태 확인
2. 배송 추적 API를 통해 배송 현황 조회
3. 자주 묻는 질문 데이터베이스 검색
4. 사용자에게는 최종 결과만 표시하되, 어드민 모드에서는 추론 과정도 확인 가능하게 구현
5. 답변 형식은 문제 확인 → 해결 방법 → 추가 안내 순으로 구성"

```

## 실제 ReAct 코드는 어떻게 생겼나요?

개발자가 아니더라도 기본적인 코드를 이해하면 소통에 도움이 돼요. 아래는 구글 백서에서 제시한 ReAct 기본 구현 코드예요:

```python
from langchain.agents import load_tools
from langchain.agents import initialize_agent
from langchain.agents import AgentType
from langchain.llms import VertexAI

# 사용자 질문
prompt = "메탈리카 밴드 멤버들의 자녀는 몇 명인가요?"

# AI 모델 설정 (낮은 온도 = 더 정확한 추론)
llm = VertexAI(temperature=0.1)

# 외부 도구 로드 (여기서는 검색 기능)
tools = load_tools(["serpapi"], llm=llm)

# ReAct 에이전트 초기화
agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True# 추론 과정 보여주기
)

# 실행
agent.run(prompt)
```

이렇게 실행하면 아래와 같은 출력이 나와요:

```
> 메탈리카는 4명의 멤버가 있습니다.
행동: 검색
행동 입력: 제임스 헷필드의 자녀 수는?
관찰: 3명의 자녀

생각: 1/4 메탈리카 밴드 멤버는 3명의 자녀가 있습니다.
행동: 검색
행동 입력: 라스 울리히의 자녀 수는?
관찰: 3명

생각: 2/4 메탈리카 밴드 멤버는 6명의 자녀가 있습니다.
행동: 검색
행동 입력: 커크 해밋의 자녀 수는?
관찰: 해밋은 1998년부터 두 번째 부인 라니와 결혼했습니다. 그들은 두 아들, 앤젤(2006년 9월 29일 출생)과 빈센조(2008년 6월 28일 출생)가 있습니다.

생각: 3/4 메탈리카 밴드 멤버는 8명의 자녀가 있습니다.
행동: 검색
행동 입력: 로버트 트루히요의 자녀 수는?
관찰: 2명

생각: 4/4 메탈리카 밴드 멤버는 10명의 자녀가 있습니다.
최종 답변: 10명
```

## 기획자가 자체 테스트해볼 수 있는 방법은?

개발팀에 요청하기 전에 간단히 테스트해보고 싶다면, 다음과 같은 방법이 있어요:

1. **ChatGPT Plus 활용하기**: ChatGPT Plus의 웹 브라우징 기능을 사용하면 간단한 ReAct 동작을 테스트해볼 수 있어요.
2. **LangChain Playground 사용하기**: 개발 지식이 있다면 LangChain의 웹 인터페이스에서 ReAct 테스트가 가능해요.
3. **단계별 대화 시뮬레이션하기**: 평범한 ChatGPT에서도 다음과 같이 ReAct를 시뮬레이션해볼 수 있어요:

```
당신은 ReAct(Reasoning + Acting) 방식으로 작동하는 AI 비서입니다.
다음 단계를 따르세요:
1. 내 질문을 분석하고 필요한 정보를 파악하세요(생각)
2. 필요한 정보를 얻기 위해 어떤 검색이나 도구를 사용할지 설명하세요(행동)
3. 그 검색이나 도구를 통해 얻을 수 있는 정보를 가정하세요(관찰)
4. 1-3단계를 충분한 정보를 얻을 때까지 반복하세요
5. 최종 답변을 제공하세요

질문: 2024년 대한민국 최고 흥행 영화 TOP3와 각 영화 감독은 누구인가요?
```

## 마무리하며

ReAct는 단순히 AI가 "답을 아는" 것을 넘어서 "답을 찾아내는" 방식으로 작동해요. 이는 실시간 정보가 필요하거나, 복잡한 추론이 필요한 상황에서 특히 유용해요.

물론 ReAct를 구현하려면 개발 리소스가 필요하고, 외부 API나 도구 연동이 필요해서 간단하지만은 않아요. 하지만 기획자로서 이런 개념을 이해하고 있으면, AI 기능을 더 효과적으로 기획하고 개발팀과도 더 원활하게 소통할 수 있어요.

---

*이 글은 구글의 ["Prompt Engineering" 백서](https://drive.google.com/file/d/1AbaBYbEa_EbPelsT40-vj64L-2IwUJHy/view)와 ReAct 관련 논문 ["ReAct: Synergizing Reasoning and Acting in Language Models"](https://arxiv.org/abs/2210.03629)를 참고했어요.*

ReAct 프롬프팅 완전 가이드

# 기획자를 위한 프롬프트 엔지니어링 완벽 가이드 (feat.구글 백서 리뷰)

안녕하세요~ IT 다이어리 독자 여러분!

요새 기획자들 중에서도 ChatGPT, Claude, Gemini 같은 AI 툴 안 쓰시는 분들이 거의 없죠? 저도 기획 업무하면서 하루에도 수십 번 AI와 대화하고 그럴때마다 프롬프트를 작성하게 되는데요, 이때 단순히 물어보는 것과 '잘' 물어보는 건 하늘과 땅 차이라는 거! 이미 많은 분들이 아실거라고 생각합니다.

그래서 오늘은 제가 최근에 발견한 구글의 프롬프트 엔지니어링 백서(2025년 2월 발표)를 완전 분석해서, 현업 기획자들이 당장 써먹을 수 있는 꿀팁만 정리해봤어요.

커피 한 잔 마시면서 읽다 보면 여러분도 프롬프트 엔지니어링 고수가 될 수 있을 거예요! 

## 1. 프롬프트 엔지니어링이 뭐길래?

우리가 그냥 "OO 기능 기획서 작성해줘"라고 물어봤을 때와 "OOO 서비스를 위한 OO 기능 기획서를 작성해줘. 타깃 유저는 2030 여성이고, 페인포인트는 OOO야. 기능 목표는 OOO이고, 꼭 포함되어야 할 요소는 OOO이야."라고 물어봤을 때, 결과물 퀄리티가 천지차이 나는 걸 경험해보셨을거에요.

이렇게 AI에게 더 좋은 결과물을 얻기 위해 질문(프롬프트)을 디자인하는 과정을 바로 '프롬프트 엔지니어링'이라고 해요.

구글 백서에 따르면, 프롬프트 엔지니어링은 "데이터 과학자나 ML 엔지니어가 아니더라도 누구나 할 수 있지만, 효과적인 프롬프트를 작성하려면 여러 요소를 고려해야 한다"고 해요.

## 2. AI 출력을 조절하는 꿀파라미터 3가지

AI 파라미터가 뭔지는 몰라도 괜찮아요! 그냥 AI한테 뭘 물어볼 때 조절할 수 있는 설정값이라고 생각하시면 돼요. 근데 이거 알아두시면 진짜 유용해요!

### 2-1. Temperature (창의성 조절기)

AI 답변의 무작위성(=창의성)을 조절하는 값이에요.

**낮은 온도 (0~0.3)**

- 더 예측 가능하고 일관된 답변
- 사실적인 정보나 정확한 답변이 필요할 때 좋음
- 예) 기술 명세 작성, 데이터 분석, 코드 작성

**높은 온도 (0.7~1)**

- 다양하고 창의적인 답변
- 브레인스토밍이나 창의적 작업에 좋음
- 예) 카피라이팅, 콘텐츠 아이디어 발굴, 스토리텔링

저는 실무에서 기획서 초안 작성할 때는 0.7 정도로 두고, 스펙 명세같이 정확해야 하는 문서는 0.1~0.2로 낮춰서 써요!

### 2-2. Top-K & Top-P (다양성 조절기)

좀 어려울 수 있는데, 단순하게 설명하자면:

**Top-K**: AI가 다음 단어를 고를 때 고려하는 후보 단어의 개수

- 높을수록 더 다양한 표현 (창의적)
- 낮을수록 더 제한적인 표현 (안정적)

**Top-P**: 누적 확률 기준으로 고려할 단어를 제한

- 0에 가까울수록 제한적
- 1에 가까울수록 다양함

뭔소리인지 모르겠다고요? 그냥 이렇게 외우세요:

- **초반 기획 아이디어 발산**: temperature 0.9, top-P 0.99, top-K 40
- **기획서 작성**: temperature 0.2, top-P 0.95, top-K 30
- **명세서, 수치 계산**: temperature 0, top-P & top-K는 신경 안써도 됨!

## 3. 진짜 써먹을 수 있는 8가지 프롬프트 기법

### 3-1. Zero-shot (그냥 물어보기)

그냥 질문을 직접 던지는 방식이에요. 가장 기본적이지만 복잡한 일엔 부족할 수 있어요.

**예시:**

```
OO 서비스의 온보딩 페이지를 3개 화면으로 기획해줘.
```

### 3-2. Few-shot (예시 주면서 물어보기) ⭐️⭐️⭐️

몇 가지 예시를 주고 비슷한 형식으로 답변해달라고 요청하는 방식이에요. 특히 특정 형식의 결과물이 필요할 때 너무 유용해요! 저도 이 방식을 실무에서 상당히 많이 쓰는 것 같아요 😄

**예시:**

```
유저 인터뷰 결과를 페인포인트와 니즈로 정리해줘.

예시:
인터뷰: "출근할 때 커피를 사려면 줄을 서야 해서 너무 오래 기다려요. 그래서 종종 커피를 못 마시고 출근하는 경우가 있어요."
페인포인트: 출근 시간에 커피숍 대기 시간이 너무 김
니즈: 출근 시간에 빠르게 커피를 구매하고 싶음

인터뷰: "저는 요가를 시작한지 얼마 안 됐는데, 집에서 혼자 할 때 자세가 맞는지 확인할 방법이 없어요."
```

이렇게 하면 AI가 패턴을 학습해서 내가 원하는 형식으로 답변해주는 장점이 있답니다!

### 3-3. 시스템 프롬프팅 (구체적인 지시 주기)

출력 형식이나 조건을 구체적으로 지정하는 방식이에요.

**예시:**

```
다음 고객 인터뷰 결과를 분석해서 JSON 형태로 반환해줘.
각 인터뷰에서 페인포인트, 니즈, 감정을 추출하고, 심각도(1-5)를 평가해줘.

인터뷰: "..."

스키마:
{
  "interviews": [
    {
      "pain_point": string,
      "needs": string,
      "emotion": string,
      "severity": number(1-5)
    }
  ]
}
```

### 3-4. 역할 프롬프팅 (전문가가 되어달라고 부탁하기) ⭐️⭐️⭐️

AI에게 특정 역할이나 페르소나를 부여하는 방식이에요. 제가 제일 자주 쓰는 기법!

**예시:**

```

당신은 10년 경력의 UX 리서처입니다. 다음 사용자 인터뷰 결과를 분석하고, 핵심 인사이트 5가지를 도출해주세요. 각 인사이트별로 이를 해결할 수 있는 기능 제안도 함께 해주세요.

사용자 인터뷰:
"..."
```

요즘 제가 자주 쓰는 역할은 '경험 많은 기획자', '유능한 UX 라이터', '꼼꼼한 QA 담당자' 이런 식이에요. 역할을 부여하면 그 분야에 맞는 전문적인 답변을 받을 수 있어요!

### 3-5. 맥락적 프롬프팅 (배경 설명 주기)

배경 정보나 맥락을 제공해서 더 관련성 높은 답변을 유도하는 방식이에요.

**예시:**

```

맥락: 우리 서비스는 2030 여성을 타깃으로 한 패션 큐레이션 앱이에요. 현재 월 활성 사용자는 5만 명이고, 주요 사용자층은 25-34세 여성이에요. 최근 유저 리텐션이 감소하는 추세고, 특히 첫 일주일 이탈률이 70%에 달해요.

이런 상황에서 리텐션 개선을 위한 기능 아이디어 5가지를 제안해주세요.
```

### 3-6. Step-back 프롬프팅 (한발 물러서서 생각하기)

구체적인 문제에 바로 뛰어들기 전에 더 넓은 관점에서 생각해보는 방식이에요.

**실제 예시:**

```
# 일반적인 방식:
우리 앱에 온보딩 튜토리얼을 어떻게 디자인하면 좋을까요?

# Step-back 방식:
모바일 앱에서 효과적인 온보딩 경험의 핵심 원칙은 무엇인가요?
[AI 응답]
위 원칙을 고려할 때, 패션 큐레이션 앱의 온보딩 튜토리얼을 어떻게 디자인하면 좋을까요?
```

### 3-7. Chain-of-Thought (생각 과정 보여달라고 하기) ⭐️⭐️

AI가 생각 과정을 단계별로 보여주게 하는 방식이에요. 복잡한 문제나 분석에 유용!

**예시:**

```
다음 MAU 데이터를 분석해서 성장률 변화의 원인을 추론해주세요. 단계별로 생각해보세요.

1월: 10,000
2월: 12,000
3월: 15,000
4월: 13,500
5월: 12,000
```

### 3-8. ReAct (검색 & 행동 결합하기)

AI가 추론하고, 검색하고, 행동하는 과정을 결합한 복잡한 방식이에요. 코드 작성이 필요한 고급 기법인데, 개발팀에 요청할 때 알아두면 좋은 부분이라, 다음 주제로 이 프롬프트 기법을 좀 더 자세하게 다뤄볼게요! 지금은 그냥 이런게 있다, 라고만 생각해주세요!

## 4. 기획자를 위한 활용 팁 6가지

### 4-1. 모든 프롬프트에 예시를 넣으세요! ⭐️⭐️⭐️

아무리 잘 설명해도 예시 하나가 백마디 말보다 낫습니다! 원하는 형식이나 스타일의 예시를 꼭 포함하세요.

### 4-2. 답변 형식을 구체적으로 요청하세요

"기획서 써줘"가 아니라 "다음 형식으로 기획서를 작성해줘: 1) 배경 및 목적 2) 핵심 기능 설명 3) 사용자 시나리오 4) KPI 및 성공 지표"처럼 구체적으로!

### 4-3. "하지 마"보다 "이렇게 해줘"로 부탁하세요

"기술적인 용어 쓰지 마" 대신 "일반 사용자도 이해할 수 있는 쉬운 용어로 설명해줘"처럼 긍정적인 지시가 더 효과적이에요.

### 4-4. JSON으로 데이터 추출하세요

데이터 분석이나 정보 추출할 때는 JSON 형태로 요청하면 구조화된 데이터를 얻을 수 있어요. 특히 엑셀로 정리해야 할 때 최고!

### 4-5. 개선을 위해 계속 시도하기!

프롬프트 엔지니어링은 한 번에 완벽하게 되는 게 아니라, 계속 시도하고 개선하는 반복 과정이에요. 저도 아직도 매일 새로운 방법을 시도하고 있어요!

### 4-6. 좋은 프롬프트는 기록해두세요 📝

효과가 좋았던 프롬프트는 노션이나 메모장에 모아두세요. 아래와 같이 템플릿을 만들어두고 활용하면 편해요!

- **용도**: UX 라이팅 개선
- **프롬프트**: [전체 프롬프트 복사]
- **효과**: ⭐️⭐️⭐️⭐️
- **메모**: 버튼 텍스트 개선에 특히 좋음

## 5. 기획자를 위한 꿀 프롬프트 3가지

제가 실제로 많이 사용하는 프롬프트 템플릿을 공개할게요!

### 5-1. 유저 리서치 결과 분석기

```
당신은 경험 많은 UX 리서처입니다. 다음 사용자 인터뷰 내용을 분석해주세요:

[인터뷰 내용 붙여넣기]

다음 형식으로 분석해주세요:
1. 핵심 페인포인트 (우선순위별로 5가지)
2. 주요 니즈 (우선순위별로 5가지)
3. 감정적 요소 (사용자가 느끼는 감정과 그 이유)
4. 기회 영역 (이 문제를 해결했을 때의 비즈니스/사용자 가치)
5. 추천 기능 (각 페인포인트를 해결할 수 있는 기능 아이디어)
```

### 5-2. 기획서 리뷰 요청기

```
당신은 10년 경력의 꼼꼼한 제품 기획자입니다. 다음 기획서를 상세히 리뷰해주세요:

[기획서 내용 붙여넣기]

다음 관점에서 분석해주세요:
1. 명확성 - 설명이 모호하거나 추가 설명이 필요한 부분이 있나요?
2. 일관성 - 내용 간에 충돌하거나 모순되는 부분이 있나요?
3. 완전성 - 빠진 중요한 정보나 시나리오가 있나요?
4. 사용자 중심성 - 사용자의 니즈와 여정이 충분히 고려되었나요?
5. 실현 가능성 - 기술적 또는 비즈니스적으로 현실적인가요?

각 문제점에 대해 구체적인 개선 제안도 함께 해주세요.
```

### 5-3. 경쟁사 분석 도우미

```
당신은 경험 많은 경쟁사 분석 전문가입니다. 다음 두 서비스를 비교 분석해주세요:

서비스 A: [서비스명과 설명]
서비스 B: [서비스명과 설명]

다음 형식으로 분석해주세요:
1. 핵심 차별점 (각 서비스의 고유한 강점)
2. 공통 기능 비교 (주요 기능별 비교표 형태로)
3. UX/UI 접근 방식 차이
4. 타깃 사용자층 차이
5. 비즈니스 모델 차이
6. 우리 서비스가 벤치마킹할 수 있는 요소

깊이 있는 분석과 함께, 각 항목에 대한 실질적인 인사이트를 제공해주세요.
```

## 마무리

여기까지 68페이지에 달하는 구글 프롬프트 엔지니어링 백서를 완전히 분석해서 기획자가 실제로 써먹을 수 있는 내용만 쏙쏙 뽑아봤는데요, 사실 AI와 대화하는 게 엄청 복잡한 것처럼 느껴질 수 있지만, 몇 가지 원칙만 기억하면 됩니다!

1. 구체적으로 요청하기
2. 예시 보여주기
3. 원하는 형식 명시하기
4. 계속 실험하고 개선하기

이제 오늘부터 회사에서 AI와 대화할 때 써먹을 수 있는 팁이 생겼죠? 😊

다음 포스팅에서는 "AI와 함께하는 서비스 기획 전체 프로세스"에 대해 알아볼게요! 질문이나 더 알고 싶은 내용 있으면 댓글로 알려주세요~

그럼 오늘도 힘내세요! 🔥

---

*이 글은 구글이 2025년 2월에 발표한 "Prompt Engineering" 백서를 참고해 작성했어요. 원문이 궁금하신 분들은 [문서](https://www.kaggle.com/whitepaper-prompt-engineering)를 참고해보세요!*

기획자를 위한 프롬프트 엔지니어링

# 난 기획자인데.. 왜 AI를 알아야 할까?

안녕하세요, IT 다이어리 독자 여러분! 요즘 주변 기획자 친구들이랑 얘기하다 보면 이런 말 정말 많이 들어요.

> "AI? 그거 개발자들이나 알면 되는 거 아냐?"
> 
> 
> "나는 기획자인데 AI 트렌드 따라갈 필요 있어?"
> 

하지만 여러분! 지금 AI는 더 이상 '선택'이 아니라 '필수'가 되어가고 있어요. 특히 기획자라면 더더욱요! 오늘은 왜 기획자들이 AI 트렌드를 알아야 하는지, 그리고 어떻게 이 파도에 올라탈 수 있는지 같이 이야기해보면 좋겠습니다. 그리고 앞으로 여러분이 AI와 더 친해지실 수 있도록 IT다이어리가 어떤 컨텐츠들을 정리해드릴지 미리 설명 드리는 시간을 가져볼거에요 😆

## IT 시장은 이미 AI로 재편되고 있어요

혹시 최근 IT 업계 뉴스 보셨나요? 대규모 인력 감축 소식이 계속 들려오고 있죠. 2022년부터 지금까지 IT 기업 470여 곳에서 무려 14만 명이 넘는 사람들이 해고되었다고 해요. 인텔은 전 세계 인력의 15%(약 1만 5천 명), 시스코는 7%, 델은 약 6천 명을 해고했어요.

근데 이런 대규모 해고 와중에도 **AI 관련 채용**은 오히려 늘어나고 있다는 사실! [잡코리아의 분석](https://www.aitimes.com/news/articleView.html?idxno=169873)에 따르면 올해(2025) 1분기 AI 키워드가 포함된 채용공고는 3년 전보다 28%나 증가했대요. 특히 경력직 구인은 53%나 늘었고요.

더 놀라운 건 이런 AI 포지션에 지원하는 사람들의 수예요. 2022년 1분기와 비교해서 무려 157%나 증가했다고 해요! 특히 11년 이상 경력직 지원자는 240%나 증가했어요. 경력 많은 시니어들도 AI에 올인하고 있다는 거죠.

즉, 시장은 이미 'AI 중심'으로 재편되고 있어요. 기획자로서 이런 트렌드.. 반드시 알아야겠죠?

## "기획자는 AI랑 상관없어"는 이제 통하지 않아요

"아니, 나는 기획자인데 AI가 뭐가 중요해?"라고 생각하시나요?

과거에는 통했을지 모르지만 이젠 달라요. AI는 이제 모든 비즈니스 의사결정의 중심에 있거든요. 어떤 프로젝트를 기획하든, AI가 어떻게 활용될 수 있는지 모른다면 경쟁에서 뒤쳐질 수밖에 없어요. 한마디로 "활용하거나, 또는 뒤쳐지거나" 인거죠.

예를 들어볼게요:

1. **제품 기획**: 요즘은 거의 모든 제품에 AI 기능이 들어가요. AI 챗봇, 추천 시스템, 이미지 인식... AI의 가능성과 한계를 모른다면 실현 불가능한 기능을 기획할 수도 있고, 반대로 혁신적인 아이디어를 놓칠 수도 있어요.
2. **콘텐츠 기획**: 콘텐츠 제작에도 AI가 깊이 관여하고 있어요. 글쓰기, 이미지 생성, 영상 편집... 기획자가 이런 AI 도구들을 활용하면 작업 효율이 엄청나게 올라가요.
3. **사용자 경험 기획**: AI는 사용자 데이터를 분석해 개인화된 경험을 제공할 수 있어요. 이런 AI의 특성을 이해하고 UX를 기획하는 것과 그렇지 않은 것은 하늘과 땅 차이예요.
4. **비즈니스 모델 기획**: AI로 인해 새로운 비즈니스 모델이 계속 등장하고 있어요. 기존 방식으로만 생각한다면 혁신적인 비즈니스 모델을 놓칠 수 있죠.

포레스터의 수석 애널리스트 피오나 마크도 [이렇게 말했어요](https://www.cio.com/article/3588109/%EA%B5%AC%EC%A1%B0%EC%A1%B0%EC%A0%95%EA%B3%BC-%EC%B1%84%EC%9A%A9%EC%A0%84%EC%9F%81-%EC%82%AC%EC%9D%B4%C2%B7%C2%B7%C2%B7-it%EC%97%85%EA%B3%84-57%EB%A7%8C%EB%AA%85-%EB%82%B4%EB%B3%B4%EB%82%B4%EA%B3%A0.html): "AI는 조직의 최우선 관심사이며, AI 관련 기술이 없는 인재보다 AI 기술을 갖춘 인재에 대한 수요가 훨씬 더 높다." 이건 개발자뿐만 아니라 **기획자에게도 해당되는 이야기**예요.

## AI가 대체할 수 있는 기획자 vs 대체할 수 없는 기획자

AI가 발전하면서 기획자의 일부 업무는 AI가 대체할 가능성이 높아요. 예를 들면:

- 단순 리서치 작업
- 기본적인 데이터 분석
- 반복적인 문서 작업
- 일정 관리나 코디네이션

그렇다면 대체되지 않을 기획자는 어떤 사람일까요? 바로 **AI를 도구로 활용해 더 높은 가치를 창출할 줄 아는 기획자**예요.

AI를 이해하고 활용하는 기획자는:

- AI의 결과물을 검증하고 개선할 수 있어요
- AI를 활용해 더 창의적인 아이디어를 발전시킬 수 있어요
- AI의 한계를 알고 인간만이 할 수 있는 부분에 집중할 수 있어요
- AI와 인간의 협업을 설계할 수 있어요

생각해보세요. '그냥 기획자'와 'AI를 전략적으로 활용할 줄 아는 기획자' 중 누가 더 가치 있을까요?

## AI는 기획자의 가장 강력한 무기가 될 수 있어요

사실 AI는 기획자에게 위협이 아니라 엄청난 기회예요! AI를 잘 활용하면 기획자로서 할 수 있는 일의 범위와 깊이가 크게 확장돼요.

제가 AI를 활용해서 얻은 변화를 몇 가지 공유할게요:

- **리서치 시간 단축**: 예전에는 시장 조사에 며칠씩 걸렸는데, 이제는 AI의 도움으로 몇 시간 만에 완료해요.
- **아이디어 발상**: 기획 초기 단계에서 AI와 브레인스토밍하면 생각지도 못한 아이디어가 나오곤 해요.
- **데이터 기반 의사결정**: AI는 복잡한 데이터도 쉽게 분석해주니까 더 확신 있는 기획이 가능해요.
- **프로토타이핑 속도**: 간단한 프로토타입을 만드는 데 AI 도구들이 정말 유용해요.
- **업무 자동화**: 반복적인 업무는 AI에게 맡기고 저는 더 창의적인 일에 집중할 수 있게 됐어요.

결국, AI를 이해하고 활용하는 기획자는 그렇지 않은 기획자보다 몇 배는 더 생산적이고 창의적일 수 있어요. 이건 경쟁력의 차이죠!

## 실제로 기업들은 어떻게 AI를 활용하고 있을까요?

구체적인 사례를 보면 AI의 중요성을 더 실감할 수 있을 것 같아요.

### 잡코리아의 AI 활용 사례

잡코리아는 자체 생성 AI '룹'을 통해 개인 이력서와 행동패턴을 분석해 맞춤형 공고를 추천해주는 'AI 추천' 서비스를 운영하고 있어요. 또한 인기 공고를 AI로 요약해서 메일로 보내주는 '1분 레터' 서비스도 출시했어요.

이런 서비스를 기획한 사람들은 분명 AI의 가능성을 이해하고 활용할 줄 아는 기획자들이었을 거예요. 만약 그들이 AI에 대해 무지했다면 이런 서비스를 기획할 수 있었을까요?

### 인재 채용과 AI

컨설팅 기업 로버트 하프의 데이터에 따르면, IT 직군 채용 담당자의 58%가 2024년 하반기에 채용을 계획하고 있다고 해요. 여기서 중요한 건, 기업들이 "AI처럼 신기술 분야에서 실력 있는 인재를 확보하기 위해 연봉, 유연성, 복리후생을 조정하고 있다"는 사실이에요.

즉, AI를 이해하고 활용할 줄 아는 인재라면 더 좋은 조건으로 취업할 기회가 많다는 거죠!

## 기획자로서 AI 트렌드를 따라잡으려면 어떻게 해야 할까요?

"아, 그래서 AI가 중요하다는 건 알겠는데... 나 같은 기획자가 어떻게 시작해야 할지 모르겠어!"

걱정 마세요! 저도 처음엔 그랬으니까요. 제가 기획자로서 AI를 공부하면서 효과적이었던 방법들을 공유할게요:

### 1) AI 기초 개념부터 이해하기

AI의 모든 기술을 알 필요는 없어요. 하지만 기본적인 개념은 이해해야 해요.

- 머신러닝과 딥러닝의 차이
- 생성형 AI의 원리와 한계
- AI 모델의 학습 방식
- AI 윤리와 편향성 문제

이런 기초 지식만 있어도 충분해요! (앞으로 IT다이어리에서 이 부분도 다뤄볼게요.)

### 2) 실제 AI 도구 사용해보기

ChatGPT, Midjourney, Notion AI, Otter.ai 같은 AI 도구들을 직접 사용해보세요. 이론보다 실제 사용해보는 게 훨씬 더 많은 걸 배울 수 있어요.

저는 매일 30분씩 새로운 AI 도구를 실험해보는 시간을 가져요. 덕분에 실무에서 어떤 AI 도구가 필요할 때 바로 활용할 수 있게 됐는데요, 제가 유용하게 사용한 AI 도구들을 모아서 소개해드리는 아티클도 언젠가 한번 꼭 공유드릴게요.

### 3) AI 관련 커뮤니티 참여하기

AI 관련 온라인 커뮤니티나 밋업에 참여해보세요. 개발자뿐만 아니라 다양한 분야의 사람들이 AI를 어떻게 활용하고 있는지 배울 수 있어요.

### 4) 작은 프로젝트부터 시작하기

업무에 AI를 바로 적용하기 부담스럽다면, 개인 프로젝트부터 시작해보세요. 예를 들어, 주간 보고서를 AI로 요약해보거나, 팀 미팅 내용을 AI로 정리해보는 것부터요. 저는 자료조사를 할 때 AI Agent를 적극 활용하고 있는데요, 제가 직접 하나하나 정리하는 것보다 훨씬 더 좋은 퀄리티를 비교도 안되게 빠른 시간 안에 만들어낼 수 있어서 정말 유용하게 사용하고 있어요.

### 5) AI와 협업하는 방법 배우기

AI는 만능이 아니에요. AI의 출력물을 그대로 믿지 말고, 검증하고 개선하는 과정을 배워야 해요. AI에게 어떻게 질문하고 지시해야 더 좋은 결과를 얻을 수 있는지 연습해보세요. 프롬프트 엔지니어링을 좀 더 심도있게 공부해보시는 것도 좋아요! 이번달에 구글이 69페이지 분량의 [프롬프트 엔지니어링 백서](https://www.kaggle.com/whitepaper-prompt-engineering)를 발표하기도 했는데요, 이 부분도 조만간 IT 다이어리에서 다뤄볼게요🥰

## AI는 기획자의 미래를 바꿀 거예요

지금까지 왜 기획자가 AI 트렌드를 알아야 하는지 살펴봤는데요, 요약하자면:

1. 시장은 이미 AI 중심으로 재편되고 있어요
2. AI는 모든 기획 프로세스에 영향을 미치고 있어요
3. AI를 이해하고 활용하는 기획자만이 대체되지 않을 거예요
4. AI는 기획자의 능력을 몇 배로 확장시켜줄 수 있어요
5. 실제로 많은 기업들이 AI를 활용해 혁신하고 있어요

과거로 사라져간 수많은 직업을 생각해보면.. AI를 모르는 기획자는 곧 과거의 유물이 될지도 몰라요. 하지만 반대로 생각하면, AI를 이해하고 활용하는 기획자는 그만큼 더 큰 가치를 창출할 수 있는 황금기를 맞이하고 있는 거예요!

너무 어렵게 생각하지 마시고, IT 다이어리에 올라오는 주제들만 차근차근 읽어보시는 건 어떨까요? 지금 시작한다면, 1년 후엔 완전히 다른 기획자가 되어 있을 거예요. 그리고 그때 여러분은 이 글을 읽기 참 잘했다고 생각하실 거예요.

앞으로 AI에 대해서 여러분이 더 친숙하게 느끼실 수 있도록 많은 이야기를 소개해드릴게요. 궁금한 점이나 더 알고 싶은 내용이 있으시면 알려주세요!

---

*이 글이 도움이 되셨다면 공유를 부탁드려요! 여러분의 응원이 더 좋은 콘텐츠를 만드는 원동력이 됩니다.*

기획자도 AI를 알아야 해요?

GAR에 대해서

안녕하세요, IT 다이어리 독자 여러분! 오늘은 모든 서비스 기획자가 한 번쯤 고민해봤을 주제에 대해 이야기해볼게요. 바로 '사용자 경험을 해치지 않으면서 광고 수익을 올리는 방법'인데요.

특히 무료 서비스를 운영하는 기획자라면 한 번쯤 "이 화면에 광고를 넣으면 수익은 오르겠지만 UX가 망가지지 않을까?"라는 고민을 해보셨을 거예요. 오늘은 실제 사례를 통해 이 딜레마를 어떻게 해결할 수 있는지 함께 알아보겠습니다!

## 사례 분석: 일본 최대 배달 서비스의 광고 전략

오늘 함께 살펴볼 사례는 일본 최대 배달 앱 '데마에칸(出前館)'의 광고 도입 전략이에요. [LINE Plus ABC Studio에서 공유해주신 실제 경험](https://techblog.lycorp.co.jp/ko/maximizing-ad-revenue-while-preserving-usability)을 바탕으로, 어떻게 사용성을 지키면서 광고 매출을 극대화했는지 알아볼게요.

## 좋은 광고란 무엇일까?

먼저 '좋은 광고'란 무엇인지 생각해볼 필요가 있어요. 기획자 입장에서는

1. 높은 클릭률(CTR)과 전환율
2. 높은 eCPM(1000번 노출당 광고 단가)
3. 충분한 임프레션(노출 횟수)

이 모든 것을 원하죠. 

하지만 사용자 입장에서는 어떨까요?

1. 콘텐츠 이용을 방해하지 않는 광고
2. 자신에게 관련성 높은 광고
3. 가능하면 적은 수의 광고

아마 이런 것들을 원할 것입니다!

그래서 이 두 가지 상반된 요구사항 사이에서 균형을 맞추는 것이 관건인데요. 데마에칸의 사례에서 어떻게 이 문제를 해결했는지 살펴보겠습니다.

## 데마에칸의 광고 표시 형식 결정 과정

데마에칸 팀은 고민 끝에 **팝업 대신 배너 형식**을 선택했어요. 팝업은 배너보다 eCPM이 2~3배 높다는 장점이 있지만, 사용자 경험을 크게 해칠 수 있거든요. 그래서 그들은 배너 형식을 선택하되, **광고 지면을 효과적으로 배치**하는 전략을 취했습니다.

> "높은 광고 매출 달성에 욕심이 있었지만 사용성을 저해하면서까지 광고를 보여주는 것은 원치 않았습니다. 광고 거부감으로 인한 서비스 이탈이 더 큰 손해라고 생각했기 때문인데요."
> 

(저도 전적으로 공감했던 부분이에요.)
![이미지](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/bf457edd1e7f40338db109ac10236582.png?updatedAt=1737617912000)

## 광고 위치 선정의 핵심: 주문 동선을 방해하지 않기

데마에칸 팀이 가장 중요하게 생각한 것은 **주문 동선을 방해하지 않는 것**이었어요. 그래서 광고를 넣기에 가장 적합한 두 위치를 선정했습니다:

### 1. 주문 완료 화면

이커머스에서 결제 직후의 시간을 'Happy Moment'라고 부른대요. 이 순간에는 사용자가 기분이 좋아서 광고에 더 관대해진다고 합니다. 좋아하는 음식을 주문하고 설렘으로 기다리는 그 짧은 순간, 광고에 대한 거부감이 낮아진다는 거죠!

(사용자의 감정 상태를 고려한 배치라는 점이 개인적으로 되게 흥미로웠던 포인트에요!)
![이미지](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/9684800e30c2417f8257a94ddb713ba8.png?updatedAt=1737617954000)

### 2. 주문 현황 화면

데마에칸의 데이터에 따르면 주문한 사용자 중 60%가 주문 현황 페이지를 조회하고, 평균 1.7번 방문한다고 해요. 임프레션을 충분히 확보할 수 있는 지면이죠.

하지만 여기서 문제가 발생했어요. 주문 현황 화면에 지도, 배송 예정 시간, 주문 상태 등 중요 정보가 있다 보니 광고가 한 화면에 다 보이지 않았거든요. 어떻게 해결했을까요?

## 지도 크기 조정: 작은 변화로 큰 효과

데마에칸 팀은 화면의 절반 이상을 차지하던 지도를 2/3 크기로 축소하는 실험을 진행했어요. 그리고 A/B 테스트 결과, **광고가 한 화면에 모두 표시되는 그룹에서 클릭 수와 매출이 두 배 이상** 증가했다고 합니다! 놀랍게도 지도 크기 변화에 대한 사용자 불만은 단 한 건도 없었다고 해요.

> "사용자는 생각보다 지도 크기의 변화에 민감하지 않았습니다."
> 

이 부분에서 깨달은 점: 우리가 기획자로서 때로는 사용자가 어떤 요소에 가치를 두는지 과대평가할 수 있다는 거예요. 데이터에 기반한 실험이 필요한 이유죠!
![이미지](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/ff6f925301d540c18d323be34a16f3d6.png?updatedAt=1737618077000)

## 광고 매출 극대화 전략: 사용자 타겟팅의 힘

먼저 광고 용어를 쉽게 설명해 드릴게요:

- **임프레션(Impression)**: 광고가 사용자에게 보여진 횟수예요. 쉽게 말해 "광고가 화면에 등장한 횟수"라고 생각하시면 됩니다.
- **eCPM(effective Cost Per Mille)**: 광고 1,000번 노출당 벌어들이는 금액이에요. 쉽게 말해 "광고를 1,000번 보여줬을 때 버는 돈"입니다. 이 금액이 높을수록 광고로 더 많은 수익을 올릴 수 있어요.

데마에칸 팀은 광고 매출을 높이기 위해 두 가지 방법을 고려했어요:

1. **임프레션 늘리기**: 광고를 더 많이 보여주기
2. **eCPM(광고 단가) 올리기**: 광고 한 번 보여줄 때마다 더 많은 돈 받기

첫 번째 방법인 '임프레션 늘리기'는 쉽지 않았어요. 왜냐하면 광고가 보이는 화면(주문 완료, 주문 현황)은 사용자가 주문할 때만 볼 수 있기 때문이죠. 또한 한 화면에 광고를 여러 개 넣으면 사용자 경험이 나빠질 수 있었어요.

그래서 두 번째 방안인 **광고 한 번 보여줄 때마다 더 많은 돈을 받는 방법**에 집중했습니다.

### 타겟팅 광고의 놀라운 효과

처음에 데마에칸 팀은 단순히 광고만 보여줬어요. 사용자의 정보를 활용하지 않고 모든 사람에게 동일한 광고를 보여준 거죠.

결과는 어땠을까요? 처음 일주일은 광고 수익이 괜찮았지만, 그 후로는 급격히 떨어졌어요. 광고를 보여줘도 수익이 거의 나지 않는 상황이 된 거예요.

그래서 데마에칸 팀은 방향을 바꿨습니다. 사용자에 대한 정보(성별, 생년월일, 주소, 어떤 음식을 주문했는지 등)를 활용해서 **'이 사람에게 맞는 광고'**를 보여주기 시작했어요. 물론 개인정보는 암호화해서 안전하게 처리했고요.

![이미지](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/8bcb350fb45440ee9e41bedf6e3643f4.png?updatedAt=1737618192000)

예를 들면:

- 20대 여성이라면 화장품이나 패션 광고
- 30대 남성이라면 가전제품이나 자동차 광고
- 피자를 자주 주문하는 사람에게는 관련 음식점 광고

이렇게 **사용자에게 관련 있는 광고**를 보여주니 결과가 어땠을까요?

> "광고 매출이 놀랍게 개선되어 2개월 후에는 처음보다 더 높은 수익을 올릴 수 있었습니다. 특히 9월에는 목표로 했던 광고 수익의 5배 이상을 달성했어요!"
> 

더 놀라운 점은, 9월에는 배달 주문 수가 8월보다 줄었는데도 광고 수익은 오히려 늘었다는 거예요! 이건 정말 대단한 성과죠. 이 결과는 '얼마나 많은 사람이 광고를 보는가'보다 '얼마나 관련성 높은 광고를 보여주는가'가 더 중요하다는 것을 증명했어요.

## UI/UX 개선으로 광고 효과 높이기

사용자 맞춤형 광고 외에도, 데마에칸 팀은 광고의 디자인과 작동 방식을 개선해서 효과를 더 높였어요.

### 1. 인앱 브라우저 대신 외부 브라우저로 연결: 친숙한 환경에서 쇼핑하게 하기

이 부분을 쉽게 설명해 드릴게요!

**인앱 브라우저**란?

- 앱 안에서 웹페이지를 볼 수 있는 미니 웹브라우저예요. 앱을 나가지 않고도 웹사이트를
볼 수 있어서 편리해 보이지만 기능이 제한적이고, 사용자가 익숙하지 않은 환경이에요

**외부 브라우저**란?

- 사용자가 평소에 쓰는 Chrome, Safari 같은 독립된 웹브라우저 앱이에요! 앱을 잠시 벗어나긴 하지만, 사용자에게 익숙한 환경이에요.

데마에칸 팀은 원래 광고를 클릭하면 앱 안에서 웹페이지가 열리게 했어요(인앱 브라우저). 하지만 이를 바꿔서 사용자가 평소 쓰는 웹브라우저(Chrome, Safari 등)로 열리게 했더니 어떤 일이 생겼을까요?

1. 사용자들이 익숙한 환경에서 더 편하게 쇼핑했어요
2. 평소 쓰던 브라우저니까 로그인 정보도 저장되어 있고, 북마크도 할 수 있어서 편리했죠
3. 또한 주문 앱으로 다시 돌아가려는 유혹이 줄어들었어요

간단히 말해, "사용자가 평소 쓰던 브라우저로 광고 페이지를 열어주니 더 많은 사람들이 실제로 물건을 구매했다"는 거예요!

### 2. 광고 디자인 최적화

- 글꼴 크기 확대 및 제목 추가
- 광고 텍스트 형식 개선 (인덱스 추가로 가독성 향상)
- '다음 광고 보기' 버튼 추가 (사용자가 관심 있는 광고를 선택할 기회 제공)

특히 이미지 없이 텍스트만 사용한 이유도 있었어요. 광고의 크기를 늘리지 않으면서도 화면의 주된 목적(주문 완료 알림 및 배송 시간 확인)을 해치지 않기 위해서였습니다.

## 기획자를 위한 실전 팁

데마에칸의 사례를 통해 배울 수 있는 광고 UX 전략을 정리해봤어요:

1. **사용자 여정의 '행복한 순간' 공략하기**
    - 주문 완료, 결제 성공 등 사용자가 긍정적인 감정을 느끼는 순간에 광고가 더 효과적입니다.
2. **핵심 기능 방해 금지!**
    - 주문, 결제 등 핵심 기능 화면에는 광고를 자제하고, 대기 시간이나 결과 확인 화면에 배치하세요.
3. **데이터 기반으로 결정하기**
    - A/B 테스트로 UI 변경이 사용자 경험과 광고 성과에 미치는 영향을 측정하세요.
    - 지도 크기처럼 우리가 중요하다고 생각하는 요소가 사용자에게는 덜 중요할 수 있어요.
4. **타겟팅의 힘을 활용**
    - 사용자 데이터를 활용한 타겟팅은 광고 효과를 극대화하고 사용자에게도 관련성 높은 정보를 제공합니다.
5. **세심한 디자인 개선이 큰 차이를 만든다!**
    - 글꼴 크기, 텍스트 포맷, '다음 보기' 옵션과 같은 작은 디자인 변화가 큰 효과를 가져올 수 있어요.

## 마치며

광고와 UX는 늘 대립하는 개념으로 여겨졌는데요, 데마에칸의 사례는 둘 사이의 균형점을 찾을 수 있다는 희망을 보여준다고 생각해요. 그리고 핵심은 **사용자 가치를 중심에 두는 것**이라는 사실을 배울 수 있었습니다. 사용자에게 관련성 높은 광고를 적절한 순간에 제공하면, 광고는 방해물이 아닌 서비스의 자연스러운 일부가 될 수 있다는 것이죠.

다음에 또 다른 유익한 주제로 찾아올게요. 도움이 되셨다면 주변에 공유해주세요!

IT다이어리는 여러분의 애정과 응원으로 성장하고 있습니다 🥹

UX와 광고 매출 사이 줄타기

안녕하세요! IT 다이어리 독자 여러분!

요즘 AI 없이 일하는 분들 거의 없죠? 저도 ChatGPT나 Claude 없이는 하루도 못 버티는 사람 중 하나인데요. 근데 이런 생각 한 번쯤 해보셨을 거예요.

"아... 이 AI가 내 구글 드라이브도 검색하고, 내 노션 문서도 찾아줬으면 좋겠다!"

근데 지난번 아티클에서 공유드렸듯이.. 이게 가능해졌어요! 'MCP' 덕분이죵..!

오늘은 기획자 관점에서 이 MCP를 어떻게 활용할 수 있는지, 그리고 미리 알아둬야 할 위험 요소는 무엇인지 최대한 쉽게 설명해볼게요.

## 저는 지난번 글 못봤어요! MCP가 뭔데요?

MCP(Model Context Protocol)는 쉽게 말해서 **우리의 AI를 슈퍼 파워로 업그레이드해주는 연결 통로**라고 생각하시면 돼요.

예를 들어볼게요. 평소에는 AI와 이런식으로 대화하셨을거에요!!

> "안녕 ChatGPT, 내일 회의 발표자료 어떻게 만들면 좋을까?"
> 

그런데 MCP를 사용하면 이런 대화가 가능해져요:

> "안녕 ChatGPT, 내 구글 드라이브에서 지난주 회의록 찾아서 읽고, 거기 있는 내용으로 내일 발표자료 만들어줘. 다 만들면 내 노션에 저장하고 슬랙으로 팀원들한테 알려줘!"
> 

마법 같죠? 복붙 지옥에서 벗어나는 거예요! (미리 축하드립니다)

## 기획자에게 MCP가 왜 중요할까요?

기획자인 우리가 MCP에 관심을 가져야 하는 이유는 두 가지예요:

1. **시간 절약의 끝판왕**: 다양한 도구와 데이터를 오가며 복사-붙여넣기하는 시간을 획기적으로 줄여줍니다.
2. **실행력 향상**: 단순히 기획서를 작성하는 것을 넘어서 실제 액션까지 자동화할 수 있어요. (예: 회의록 작성 → 일정 등록 → 슬랙 공지까지 한 번에!)

## 현실적으로 이런 것들이 가능해져요

- **시장 조사 자동화**: "경쟁사 A, B, C의 홈페이지를 분석해서 우리 제품과의 차별점을 정리해줘"
- **데이터 기반 기획**: "우리 앱의 지난 달 사용자 데이터를 분석해서 가장 인기 있는 기능 TOP5를 알려줘"
- **통합 문서 작업**: "지난 회의록에서 중요한 결정사항만 뽑아서 새 기획서에 반영해줘"

솔직히 생각만 해도 설레지 않나요?

## 하지만... 그림자도 있다구요!

아무리 좋은 기술도 위험성이 있기 마련이죠. MCP도 예외는 아니에요. 기획자라면 반드시 알아둬야 할 [함정들](https://blog.sshh.io/p/everything-wrong-with-mcp)을 소개할게요.

### 1. 보안의 함정

여러분이 모든 앱에 항상 똑같은 비밀번호를 사용한다고 생각해보세요. 한 곳이 뚫리면 모든 곳이 위험해지죠.

MCP도 비슷해요. 여러분의 구글 드라이브, 노션, 슬랙 등을 AI에 연결해놓으면, 한 번의 실수로 모든 데이터가 위험해질 수 있어요.

예를 들어 이런 상황:

> "내일 발표할 제품 기획서 최종본 보여줘! 그리고 팀원들 연락처도 정리해줘!"
> 

AI가 열심히 일하는 동안, 누군가 중간에서 데이터를 훔쳐볼 수도 있다는 거죠.

특히 MCP 프로토콜 자체가 아직 완벽한 인증 방식을 정의하지 않았다는 점이 문제예요. 초기에는 인증 사양이 없었고, 지금은 있지만 많은 사람들이 마음에 들어하지 않는 상황이에요. 이로 인해 각 MCP 서버가 제각각 다른 "인증" 방식을 사용하게 되었고, 민감한 데이터 접근에 대한 보안 메커니즘이 천차만별이라 걱정스러운 부분이 있어요.

### 2. 비용이 생각보다 많이 들어요

LLM은 데이터를 많이 처리할수록 비용이 증가해요. 여러분의 드라이브에 파일이 10,000개 있다고 상상해보세요. AI가 "내 파일 중에 마케팅 관련 문서 찾아줘"라는 간단한 요청을 처리하려면 모든 파일을 살펴봐야 할 수도 있어요.

이건 마치 도서관에서 책 한 권을 찾기 위해 모든 책장을 뒤지는 것과 같아요. 시간도 오래 걸리고, 비용도 많이 들거든요..

실제로 LLM 세계에서는 대역폭이 매우 비싸요. 1MB의 출력은 약 $1의 비용이 발생할 수 있고, 그 데이터를 포함하는 모든 후속 메시지에서도 과금된답니다! 사용자의 서비스 비용이 MCP 통합과 토큰 효율성에 크게 의존하게 되는 거예요. 따라서 비용 관리를 위해 효율적인 요청 방법을 알아두는 게 중요해요.

### 3. "AI가 알아서 해줄 거야"라는 환상

MCP가 마법처럼 모든 것을 해결해주지는 않아요. 예를 들어서 여러분이 "지난 분기 회의록에서 제품 관련 결정사항만 찾아줘" 이렇게 질문했다고 할때, 파일 이름에 '회의록'이나 '제품'이란 단어가 없으면 AI가 이 내용들을 정확히 찾기 어려울 수 있어요. 인간은 모든 세부 맥락을 정확하게 이해하지만, AI는 아직 그런 수준까지는 아니랍니다..🥹

(심지어 가장 최신 모델인 Claude 3.7 Sonnet도 소프트웨어 디버깅 분야에서 아직 인간을 따라잡기 어렵다는 [연구 결과](https://arxiv.org/pdf/2503.21557)까지 있답니다! 아직 갈 길이 멀어요.)

LLM 신뢰성은 종종 주어진 지시 컨텍스트의 양과 반비례한다는 점도 알아두세요. 더 많은 데이터와 통합을 제공하면 모든 문제가 해결될 것이라고 생각하기 쉽지만, 실제로는 MCP 서버가 커지고 사용자가 더 많은 도구를 통합할수록 오히려 어시스턴트의 성능이 저하되고 비용만 늘어날 수 있어요.

### 4. 의도치 않은 정보 노출

예를 들어 여러분이 의료 정보가 포함된 개인 문서를 가지고 있고, 블로그 글을 쓰기 위해 AI에게 도움을 요청했어요. AI는 '도움이 되고자' 여러분의 개인 의료 정보를 글에 자연스럽게 포함시킬 수도 있어요.

별거 아닌것 같지만,, 실무에서는 훨씬 더 민감한 문제가 될 수 있어요. 예를들어 경영진 회의록에 접근할 수 있는 AI가 그 내용을 무심코 다른 문서에 인용할 수도 있으니까요.

더 무서운 점은 MCP를 통해 AI가 수행할 수 있는 프롬프트 주입 공격이에요. LLM은 시스템 프롬프트(어시스턴트의 행동과 정책 제어)와 사용자 프롬프트(사용자 제공) 두 가지 수준의 지시를 가지고 있는데, MCP를 통해 제공되는 도구들은 종종 어시스턴트의 시스템 프롬프트 일부로 신뢰받아 에이전트 동작을 재정의할 수 있는 더 많은 권한을 가질 수 있어요. 그래서 악의적인 MCP 서버가 AI의 행동을 조종할 가능성이 있답니다.

### 5. MCP가 데이터 접근 제어 방식을 뒤엎을 수 있어요

회사들이 내부 데이터에 AI 에이전트와 MCP를 연결하면, 의외의 결과가 나올 수 있어요. "AI + 직원이 이미 접근할 수 있는 모든 데이터"의 조합이 예상치 못한 결과를 가져올 수 있거든요.

직원의 에이전트가 해당 직원의 권한 내에서만 데이터에 접근한다고 해도, 데이터를 지능적으로 집계하고 분석하는 AI의 능력 때문에 민감한 정보가 도출될 수 있어요. 몇 가지 예를 들어볼게요:

- 직원이 공개 슬랙 채널, 직원 직함, 공유 내부 문서에 접근할 수 있을 때: "모든 임원진과 법무팀 구성원을 찾고, 아직 발표되지 않은 회사 이벤트(주식 계획, 주요 사직, 소송 등)를 추론하기 위해 그들의 최근 대화와 문서 업데이트를 살펴봐"
- 관리자가 팀원들의 슬랙 메시지를 읽을 수 있을 때: "한 사람이 부정적인 상급자 리뷰를 썼는데, 이런 사람들 중에서 누가 가장 이 피드백을 썼을 가능성이 높은지 알려줘"

이런 정보 추출은 사용자가 기존에 접근할 수 없었던 것은 아니지만, AI를 통해 훨씬 쉽고 효율적으로 할 수 있게 된다는 점이 달라진 부분인 것이죠.

## 기획자를 위한 실전 MCP 활용 가이드

그럼 실제로 어떻게 사용하면 좋을까요?

### 1. 안전한 시작..

- **단계적으로 접근하기!!** : 처음부터 모든 데이터를 연결하지 말고, 덜 민감한 데이터부터 시작하세요. 덜 민감한 데이터에만 정확히 접근 권한을 주고 사용하세요.
- **공개 문서로 테스트**: 민감한 정보가 없는 공개 문서로 먼저 테스트해보세요.
- **확인 과정 설정**: 중요한 액션(예: 파일 삭제, 이메일 전송)은 항상 확인 과정을 거치도록 설정하세요.

### 2. 정확하게 지시하기!

- **구체적인 요청하기**: "모든 파일 찾아줘" 대신 "2025년 3월에 작성된 '마케팅 전략'이 제목에 들어간 문서 찾아줘"
- **중요 문서는 태그 달기**: AI가 쉽게 찾을 수 있도록 문서 이름과 태그를 명확하게 설정하세요.
- **요청 전 경로 확인**: "내 드라이브의 '2024년 프로젝트' 폴더에서..."처럼 경로를 명확히 지정하세요.

### 3. 요즘 똑똑한 기획자들은 MCP로 이거 한다

- **경쟁사 분석 자동화**: 경쟁사 웹사이트, 자료, SNS를 주기적으로 분석하게 하세요.
- **회의 준비 도우미**: "다음 회의 주제는 A인데, 관련된 우리 내부 문서와 시장 현황을 요약해줘"
- **사용자 피드백 분석**: "지난달 수집한 사용자 피드백에서 가장 많이 언급된 불만 사항을 알려줘"

## 강력함과 위험성 사이의 균형

MCP가 정말 강력하긴 하지만,, 아직은 초기 단계라 발전할 부분이 많고, 완벽하지 않아요. 하지만 AI시대를 살아가는 기획자로서 이런 기술의 흐름을 이해하고 앞서가는 것은 정말 중요한 부분이라고 생각합니다!

훌륭한 프로토콜이란 '행복한 경로'가 본질적으로 안전하도록 보장하고, 훌륭한 애플리케이션은 사용자를 교육하며 일반적인 함정으로부터 보호하고, 잘 알고 있는 사용자는 자신의 선택의 뉘앙스와 결과를 이해하는 거라고 생각해요. MCP의 문제점들은 이 세 가지 모든 측면에서 개선이 필요하겠죠.

그래서 위험을 인지하면서 조심스럽게 활용한다면, 이 글을 읽으시는 기획자 여러분의 업무 효율성은 정말 엄청나게 발전할 거라는 확신이 듭니다!!

다음에 더 유용한 IT 트렌드로 찾아올게요! 읽어주셔서 감사합니다~ 💕

MCP가 위험할수도 있는 이유

AI가 협업을 한다구?

안녕하세요, IT 다이어리 독자 여러분! 오늘은 기획자라면 꼭 알아두면 좋을 'API 문서화와 명세'에 대해 한번 제대로 파헤쳐 볼게요. 'API'라는 단어만 들어도 "아, 그거 개발자들이나 신경 쓰는 거 아냐?"라고 생각하시는 분들 많으실 텐데요. 사실 요즘 서비스 기획하면서 API 모르고 지나가기는 정말 힘들어졌어요.

이번 글에서는 왜 기획자인 우리가 API를 알아야 하는지, API 문서가 뭔지, 그리고 이걸 어떻게 활용해서 더 일 잘하는 기획자가 될 수 있는지 같이 알아볼게요. 커피 한 잔 마시면서 편하게 읽어보세요!

## API란 무엇인가?

'Application Programming Interface'의 약자인 API는 쉽게 말하면 다른 소프트웨어랑 데이터를 주고받기 위한 '약속된 방법'이에요. 맛집에 비유해볼게요. API는 메뉴판이자 웨이터 역할이라고 생각하면 돼요. 손님(프론트엔드)이 웨이터(API)한테 "돈까스 하나요~"라고 주문하면, 웨이터는 주방(백엔드)에 그 요청을 전달하고, 완성된 맛있는 돈까스를 다시 손님 테이블에 가져다 주는 거죠.

요즘 웹이나 앱 서비스에서는 화면에 보이는 부분(프론트엔드)과 서버에서 데이터 처리하는 부분(백엔드)이 API를 통해 소통해요.

실생활 예시로 이해해볼까요? 여러분이 인스타그램에서 팔로워 목록을 볼 때는 이런 일이 벌어져요:

1. 인스타 앱이 "이 유저 팔로워 누구누구 있는지 알려줘"라는 요청을 API에 던집니다.
2. API가 이 요청을 서버에 전달해요.
3. 서버는 DB 뒤적뒤적 팔로워 정보를 찾아서 API 통해 다시 앱으로 쏴줍니다.
4. 앱은 이 정보를 받아서 화면에 쫙 보여주는 거죠.

이게 다 1초도 안 걸려서 이루어진다니, 신기하지 않나요? 🤓

## 기획자가 API 문서를 읽을 줄 알아야 하는 이유

"그래서, 이게 왜 기획자인 내가 알아야 하는 건데?" 하는 생각 드는 분들 많으실 텐데요. 요즘 기획자가 API 문서를 이해하는 건 선택이 아니라 필수가 됐어요. 그 이유를 살펴볼게요:

1. **현실적인 기획 가능**: API가 어떻게 돌아가는지 알면, 개발팀이 "이거 못해요ㅠㅠ" 소리 안 나오는 기능을 기획할 수 있어요. "이 기능을 구현하려면 이런 API가 필요한데, 우리 일정 내에 가능할까?" 이런 고민을 미리 할 수 있죠.
2. **개발자랑 대화가 됨**: 개발자한테 "이 API에 사용자 나이 정보도 좀 추가해주세요!"라고 명확하게 요청할 수 있어요. 개발자가 "이 기능은 API 구조를 바꿔야 해서 시간이 좀 걸려요"라고 할 때도 "아~ 그렇구나" 하고 이해할 수 있고요.
3. **외부 서비스 연동 기획 가능**: 카카오 로그인, 네이버 지도, 토스 페이먼츠 같은 외부 API 쓰는 기능 기획할 때, API 문서 보고 "이거 되네! 이건 안 되네!" 직접 확인할 수 있어요. 이게 진짜 중요한 포인트!!! 이런거 하나하나 물어보면 개발자도 피곤하고 기획자도 미안하고,, 얼마나 힘들겠어요.. 이제 우리가 직접 알아보고 제안하는 걸로 해요!
4. **일정 산출 정확도 UP**: API 개발이 얼마나 복잡한지 감이 있으면 "이 기능 언제쯤 나올까요?" 물었을 때 "글쎄요... 2주?" 이런 애매한 답변 안 듣고 더 정확한 일정 예측이 가능해요.
5. **데이터 흐름 이해로 UX 향상**: 화면 설계할 때 "이 데이터는 어디서 와서 어디로 가는구나~" 하고 이해하면 사용자 경험도 훨씬 자연스럽게 설계할 수 있어요.

## API 문서화의 중요성

API 문서는 쉽게 말해 API의 '사용 설명서'예요. 냉장고 살 때 설명서 없으면 당황스럽듯이, API도 문서 없이는 어떻게 써야 할지 모르거든요. 좋은 API 문서는 개발자뿐만 아니라 기획자도 읽고 이해할 수 있어야 해요. API 문서화가 중요한 이유, 한번 살펴볼까요?

1. **소통이 잘됨**: "아~ 이거 이렇게 하는 거구나!" 개발팀, 기획팀, 디자인팀이 같은 그림을 보고 일할 수 있어요. 오해도 줄고요.
2. **개발 속도 쭉쭉**: 개발자가 API 어떻게 쓰는지 명확히 알면 삽질(?) 없이 빠르게 개발 가능해요. 헤매는 시간이 확 줄어든다고 보면 돼요.
3. **버그 확 줄어듦**: "어? 난 이렇게 이해했는데..." 하는 오해에서 생기는 버그들이 확 줄어들어요.
4. **유지보수가 편해짐**: 프로젝트 중간에 개발자가 바뀌거나, 1년 뒤에 기능 추가할 때도 "이거 어떻게 작동하지?" 하는 고민 없이 문서 보고 바로 이해 가능해요.
5. **테스트할 때 기준점**: QA팀이 "이게 제대로 작동하는 건가?" 확인할 수 있는 명확한 기준이 되어줘요.

## API 명세서 형식 이해하기

API 명세서는 보통 일정한 형식이 있어요. 뭐 이력서 양식이 있듯이 API도 문서 작성하는 표준 양식이 있는 거죠. 대표적으로 Swagger(OpenAPI), API Blueprint, RAML 같은 것들이 있는데요. 가장 많이 쓰이는 Swagger를 중심으로 API 명세서에 어떤 내용이 들어가는지 살펴볼게요:

### 1. 기본 정보

- **API 이름과 버전**: "토스페이먼츠 결제 API v2.0" 같은 공식 이름과 버전
- **기본 URL**: API 요청할 때 기본 주소 (예: `https://api.tosspayments.com/v2`)
- **인증 방식**: API 쓰려면 어떻게 인증해야 하는지 (API 키, 카카오 로그인 같은 OAuth 등)

### 2. 엔드포인트 (Endpoint)

엔드포인트는 API의 실제 주소인데요, 각각 특정 기능을 담당해요. 예를 들면:

- `/users` - 유저 정보 관련 기능
- `/products` - 상품 정보 관련 기능

각 엔드포인트에는 이런 정보들이 있어요:

- **HTTP 메소드**: GET(정보 조회), POST(정보 생성), PUT(정보 수정), DELETE(정보 삭제) 같은 것들
- **요청 파라미터**: API 부를 때 보내야 하는 데이터 (예: 상품ID, 검색어 등)
- **응답 형식**: API가 돌려주는 데이터 형식 ("이런 JSON 형태로 줄게요~")
- **에러 코드**: 문제 생기면 어떤 에러 코드가 나오는지 ("401은 권한 없음, 404는 정보 없음...")

### 3. 데이터 모델

API에서 다루는 데이터의 구조예요. 예를 들어 '사용자' 모델은 이렇게 생겼어요:

```
User {
  id: integer (사용자 고유번호)
  username: string (아이디)
  email: string (이메일)
  created_at: datetime (가입일시)
}

```

### 4. 예제 코드

실제로 API를 어떻게 호출하는지 예제 코드도 보여주는 경우가 많아요. "아 이렇게 쓰는구나~" 이해하기 쉽게요. 자바, 파이썬, 자바스크립트 등 여러 언어로 된 예제를 제공하기도 해요.

## 실제 API 문서 읽는 방법

API 문서 처음 보면 좀 복잡해 보이죠? 일단 걱정 마시고 이렇게 단계별로 읽어보세요!!

### 1. 전체 구조 대충 훑어보기

처음부터 세세하게 볼 필요 없어요. 일단 API가 어떤 기능들을 제공하는지 대략적으로 살펴보세요. "아하, 이 API는 회원 관리, 게시물 관리, 결제 처리 이런 걸 할 수 있구나~" 정도로 큰 그림을 그려보는 거예요.

### 2. 내가 필요한 것만 콕 집어보기

여러분이 지금 기획 중인 기능에 필요한 부분만 찾아보세요. 예를 들어, 유저 프로필 페이지를 만들고 있다면 `/users/{id}` 같은 엔드포인트를 찾아보는 거죠. 다른 건 나중에 필요할 때 보면 돼요!

### 3. 주고받는 데이터 이해하기

찾은 엔드포인트에 대해 세 가지만 확인하세요:

- 뭘 보내야 하는지 (요청할 때 필요한 데이터)
- 뭘 받을 수 있는지 (응답으로 오는 데이터)
- 어떤 에러가 날 수 있는지 (에러 코드와 의미)

### 4. 직접 눌러보기

요즘 API 문서는 대부분 Swagger UI나 Postman 같은 도구로 바로 테스트해볼 수 있어요. "이 버튼 누르면 뭐가 나오지?" 하고 직접 API 호출해보면 백 번 읽는 것보다 이해가 빨라요. 개발자 없이도 여러분이 직접 API 동작을 확인할 수 있는 거죠!

## 기획 단계에서 API 명세 활용하기

이제 기획자가 API 명세를 실제로 어떻게 활용할 수 있는지 실전 팁을 알려드릴게요:

### 1. 기능 기획할 때 API 먼저 체크

새 기능 기획 전에 "우리 지금 가진 API로 이거 만들 수 있나?" 확인부터 해보세요. 필요한 데이터가 현재 API에서 안 나온다면, 개발팀에 "이런 API 하나 추가해주세요~" 라고 미리 요청할 수 있어요. 나중에 기획 다 끝내고 개발팀에 전달했는데 "이 데이터는 현재 서버에서 제공 안 해요ㅠㅠ 새로 만들어야 하는데 최소 2주 걸려요..." 이런 답변 듣게 되면 일정 망하잖아요. 미리 확인하면 이런 사태를 예방할 수 있어요.

### 2. 와이어프레임에 API 메모하기

화면 와이어프레임 만들 때 각 화면에 필요한 API도 같이 적어두세요. 예를 들면:

- 유저 프로필 화면: `GET /users/{id}` (이 API로 프로필 정보 가져옴)
- 상품 목록 화면: `GET /products?category={category}` (이 API로 카테고리별 상품 가져옴)

이러면 개발자가 "어, 이 화면은 이 API 써서 만들면 되는구나" 하고 바로 이해할 수 있어요.

### 3. 사용자 시나리오에 API 흐름 추가

사용자 시나리오 작성할 때 각 단계마다 어떤 API가 필요한지도 같이 적으면 개발자가 좀 더 편할 수 있어요. 근데 개인적으로 요건 개발자마다 취향의 차이가 있을 수 있다고 생각해서 개발팀과 논의 후에 적용해보시는걸 추천드려요!

1. 유저가 로그인 버튼 눌러요 → `POST /auth/login` (로그인 정보 전송)
2. 유저가 프로필 페이지로 이동해요 → `GET /users/me` (내 정보 가져오기)
3. 유저가 프사 바꿔요 → `PUT /users/me/profile-picture` (새 사진 업로드)

이렇게 하면 개발자가 "아~ 이 순서대로 API 호출하면 되는구나"하고 이해가 더 빨리 될 수 있어요!

## 좋은 API 기획을 위한 체크리스트

자, 이제 마지막으로 API 관련 기획 검토할 때 쓸 수 있는 체크리스트를 드릴게요. 실무에서 바로 써먹을 수 있는 꿀팁!

### 기능성 체크

- 필요한 데이터가 API에서 다 제공되나요?
- 많은 데이터를 처리해야 할 때 페이지네이션(한 번에 10개씩 보기 같은 기능), 필터링, 정렬 기능이 필요하진 않나요?
- 자주 불러오는 데이터는 캐싱 전략을 고려했나요? (서버 과부하 방지)

### 사용성 체크

- API 응답 구조가 프론트엔드 개발자가 쓰기 편한가요? (복잡하게 중첩된 구조보다 단순한 구조가 좋아요)
- 에러 났을 때 사용자에게 좀 더 친절한 메시지를 보여줄 수 있나요? ("시스템 에러" 말고 "지금 인터넷 연결이 불안정한 것 같아요" 같은…)
- API 응답 시간이 너무 길지 않나요? (3초 이상 기다리면 사용자 절반이 이탈한다는 연구 결과가 있어요!)

### 보안 체크

- 로그인 같은 인증 방식이 안전한가요?
- 개인정보, 결제정보 같은 민감한 데이터는 암호화됐나요?
- 누군가 API를 무한정 호출해서 서버를 다운시키는 공격을 막을 수 있나요? (속도 제한 기능)

### 확장성 체크

- 나중에 기능 추가하기 쉬운 구조인가요?
- API 버전 관리 전략이 있나요? (v1, v2 이런 식으로)
- 웹, 앱, 태블릿 등 다양한 기기에서 다 쓸 수 있나요?

이 체크리스트만 잘 활용해도 개발팀이 "기획팀이 API까지 이렇게 꼼꼼하게 생각했네!"라고 감탄하게 할 수 있을 거예요. 😎

## 마치며

API 문서화와 명세 이해하기, 어떠셨나요? 생각보다 어렵지 않죠? API는 더 이상 개발자만의 영역이 아니에요. 기획자인 우리도 API를 이해하면 개발자와 대화도 잘 통하고, 현실적인 기획을 할 수 있어요.

이제 개발자가 "API 명세 좀 확인해주세요"라고 하면 당황하지 마세요! 이 글에서 배운 내용 토대로 API 문서 쓱쓱 읽어보고, 여러분의 기획에 적극 활용해보세요. 개발팀과 기획팀 사이의 소통이 한결 수월해질 거예요.

여기까지 읽으신 여러분은 이제 API 기본기를 탄탄히 다지셨습니다. 축하드려요! 🎉

다음 IT 다이어리에서는 또 다른 꿀팁을 들고 찾아올게요. 궁금한 주제 있으시면 알려주세요! 이 글이 도움이 되셨다면 좋아요와 공유도 부탁드려요~

우리 모두 멋진 기획자로 함께 성장해봐요! 다음에 또 만나요! 👋

---

*이 글이 유용하셨다면 주변에 많이 공유해주세요!! IT 다이어리는 여러분의 응원으로 더 많은 콘텐츠를 만들어갑니다.*

기획자가 API 문서를 읽을 줄 알아야 하는 이유

안녕하세요, IT 다이어리 독자 여러분! 오늘은 AI 세계에서 주목받고 있는 새로운 개념인 MCP(Model Context Protocol)에 대해 알아보겠습니다. 복잡한 기술적 개념이지만 기획자 관점에서 꼭 알아두면 좋을 내용들을 쉽게 풀어보겠습니다🥰

## MCP란 무엇인가?

MCP(Model Context Protocol)는 AI 모델들이 외부 세계와 소통하는 방식을 표준화한 프로토콜입니다. 쉽게 말해, AI 모델이 필요한 정보를 가져오고, 특정 작업을 수행하며, 외부 도구를 활용할 수 있게 해주는 '언어'라고 생각하면 됩니다.

우리가 인터넷을 사용할 때 HTTP라는 프로토콜이 필요하듯, AI 모델이 외부 세계와 효과적으로 소통하기 위해서는 MCP와 같은 표준화된 방식이 필요했습니다.

## 왜 MCP가 필요한가?

최근 AI 모델들은 점점 더 강력해지고 있지만, 한 가지 큰 한계가 있었습니다. 바로 '제한된 맥락(Context)'입니다. GPT나 Claude 같은 AI 모델들은 학습된 정보와 대화 중에 받은 정보만을 바탕으로 답변을 생성합니다. 실시간 데이터에 접근하거나 복잡한 계산을 수행하는 등의 능력은 원천적으로 제한되어 있었죠.

이런 한계를 극복하기 위해 탄생한 것이 MCP입니다. MCP는 AI 모델에게 다음과 같은 힘을 부여합니다:

1. **외부 도구 접근**: 검색 엔진, 계산기, 코드 실행기 등 다양한 외부 도구에 접근할 수 있습니다.
2. **실시간 데이터 활용**: 최신 뉴스, 주가 정보, 날씨 데이터 등 실시간 정보를 활용할 수 있습니다.
3. **맥락 확장**: 제한된 대화 길이를 넘어 더 많은 정보를 참조할 수 있습니다.
4. **행동 수행**: 사용자를 대신해 특정 작업을 수행할 수 있습니다.

## MCP의 작동 원리

MCP는 어떻게 작동할까요? 간단히 설명하자면 다음과 같은 과정을 거칩니다:

1. **요청 해석**: AI 모델이 사용자의 요청을 분석합니다.
2. **도구 결정**: 어떤 외부 도구나 정보가 필요한지 결정합니다.
3. **함수 호출**: 필요한 도구를 호출하는 함수를 생성합니다.
4. **결과 처리**: 도구의 실행 결과를 받아 처리합니다.
5. **응답 생성**: 최종 응답을 생성하여 사용자에게 제공합니다.

이 과정을 코드로 표현하면 대략 다음과 같은 모습입니다:

```jsx
// MCP 기반 AI 모델의 작동 과정 (의사 코드)
function processUserRequest(userInput) {
  // 1. 요청 해석
  const userIntent = analyzeIntent(userInput);

  // 2. 필요한 도구 결정
  const requiredTools = determineTools(userIntent);

  // 3. 함수 호출 (외부 도구 접근)
  if (requiredTools.includes('search')) {
    const searchResults = callExternalTool('search', userIntent.query);
    updateContext(searchResults);
  }

  // 4. 결과 처리
  const enhancedContext = processToolResults();

  // 5. 응답 생성
  return generateResponse(enhancedContext);
}

```

## 실제 사용 사례: 기획자를 위한 MCP 활용법

기획자 입장에서 MCP는 어떤 의미가 있을까요? 몇 가지 실용적인 사례를 살펴보겠습니다:

### 1. 데이터 기반 의사결정

```
사용자: "우리 제품의 주 타겟층인 30대 여성들의 최근 6개월간 온라인 쇼핑 트렌드를 분석해줘."

AI (MCP 활용):
1. 검색 도구를 호출하여 최신 트렌드 데이터 수집
2. 데이터 분석 도구로 패턴 파악
3. 시각화 도구로 그래프 생성
4. 분석 결과와 인사이트 제공

```

이처럼 MCP를 통해 AI는 실시간 데이터를 수집하고 분석하여 기획자에게 더 가치 있는 정보를 제공할 수 있습니다.

### 2. 프로토타이핑 지원

```
사용자: "모바일 앱에서 사용자 온보딩 화면 5개를 프로토타이핑해줘."

AI (MCP 활용):
1. 디자인 참조를 위해 유사 사례 검색
2. 디자인 도구 연동하여 와이어프레임 생성
3. 코드 실행 도구로 인터랙션 구현
4. 결과물 시각화하여 제공

```

MCP를 통해 AI는 단순히 아이디어를 제안하는 것을 넘어, 실제 프로토타입을 생성하는 데까지 도움을 줄 수 있습니다.

## MCP의 기술적 구성요소

조금 더 기술적인 측면에서 MCP의 구성요소를 살펴보겠습니다:

### 1. 함수 호출 (Function Calling)

MCP의 핵심은 AI 모델이 특정 함수를 호출할 수 있는 능력입니다. 예를 들어:

```json
{
  "name": "searchWeb",
  "description": "인터넷에서 정보를 검색합니다",
  "parameters": {
    "query": "검색할 키워드나 질문",
    "limit": "반환할 결과 수 (기본값: 5)"
  }
}

```

이와 같이 정의된 함수를 AI 모델이 호출하면, 실제로 웹 검색이 수행되고 그 결과가 모델에게 전달됩니다.

### 2. 도구 세트 (Toolset)

MCP는 다양한 도구를 표준화된 방식으로 제공합니다:

- **검색 도구**: 웹 검색, 내부 문서 검색 등
- **계산 도구**: 복잡한 수학적 계산, 통계 분석 등
- **코드 실행 도구**: 프로그래밍 코드 실행 및 결과 반환
- **외부 API 연동**: 날씨 정보, 주가 정보, 지도 등 외부 서비스 연동
- **파일 처리 도구**: 문서, 이미지, 오디오 등 다양한 파일 처리

### 3. 컨텍스트 관리 (Context Management)

AI 모델의 제한된 컨텍스트 윈도우를 효과적으로 관리하는 메커니즘도 MCP의 중요한 부분입니다:

- **컨텍스트 압축**: 중요 정보만 남기고 압축하는 기술
- **정보 인덱싱**: 필요할 때 빠르게 찾을 수 있는 인덱싱 방식
- **메모리 관리**: 장기/단기 메모리 분리 및 관리

## MCP 활용을 위한 기획자의 준비사항

기획자로서 MCP의 장점을 활용하기 위해 어떤 준비가 필요할까요?

1. **API 기본 개념 이해**: MCP는 기본적으로 API 호출을 기반으로 합니다. API가 무엇인지, 어떻게 작동하는지에 대한 기본적인 이해가 필요합니다.
2. **프롬프트 엔지니어링 역량**: AI에게 효과적으로 지시를 내리는 방법을 익혀야 합니다. 특히 어떤 도구를 사용해야 할지 명확하게 지정하는 능력이 중요합니다.
3. **데이터 구조화 능력**: AI가 효과적으로 처리할 수 있도록 데이터를 구조화하는 능력이 필요합니다.
4. **적절한 도구 선택**: 다양한 MCP 도구 중에서 목적에 맞는 적절한 도구를 선택할 수 있어야 합니다.
→ MCP 서버 모음 사이트: https://smithery.ai/ (여기 외에도 많습니다!)

## MCP의 미래: 기획자가 주목해야 할 점

1. **자율성 증가**: AI 모델이 스스로 필요한 도구를 결정하고 활용하는 자율성이 높아질 것입니다.
2. **멀티모달 확장**: 텍스트뿐만 아니라 이미지, 오디오, 비디오 등 다양한 형태의 데이터를 처리하는 MCP로 확장될 것입니다.
3. **개인화된 도구 세트**: 사용자나 조직 특성에 맞춘 맞춤형 도구 세트가 발전할 것입니다.
4. **보안과 프라이버시**: 외부 도구 접근에 따른 보안과 프라이버시 이슈가 중요해질 것입니다.

## 기획자에게 MCP가 갖는 의미?

MCP는 단순한 기술적 개념을 넘어 기획자의 업무 방식을 근본적으로 변화시킬 잠재력을 가지고 있습니다. AI를 단순한 질의응답 도구가 아닌, 실제 업무를 지원하는 옆자리 동료로 활용할 수 있게 해주기 때문입니다.

기획자는 MCP를 통해:

- 더 정확하고 최신의 데이터에 기반한 의사결정
- 반복적인 작업의 자동화
- 보다 창의적인 업무에 집중할 수 있는 여유
- 프로토타이핑과 실험의 가속화

등의 이점을 누릴 수 있습니다!

MCP에 대한 이해와 활용 능력은 앞으로 기획자에게 중요한 경쟁력이 될거에요.

이상으로 MCP에 대한 소개를 마칩니다. 다음 IT 다이어리에서 또 다른 흥미로운 주제로 찾아뵙겠습니다!

MCP가 뭐에요?

오늘은 기획자 여러분들이 개발자와 더 효과적으로 소통하고, 더 나은 제품을 만들기 위해 알아두면 좋을 API 설계 원칙과 문서화에 대해 이야기해볼게요.

## 왜 기획자가 API에 관심을 가져야 할까요?

프로덕트 기획자로서 여러분은 사용자와 개발자 사이의 다리 역할을 합니다. 사용자의 니즈를 이해하고, 그것을 개발자가 구현할 수 있는 형태로 전달하죠. 이 과정에서 API에 대한 기본 이해는 의사소통을 원활하게 하고, 프로젝트 일정과 범위를 더 정확하게 예측할 수 있게 해줍니다.

예를 들어볼까요? 여러분이 새로운 기능을 기획했다고 가정해 봅시다. "사용자가 자신의 위치 근처 카페를 찾을 수 있는 기능이 필요해요." 이 간단한 요구사항 뒤에는 수많은 API 관련 결정이 숨어있습니다:

- 위치 정보를 어떻게 가져올 것인가?
- 카페 정보는 어디서 가져올 것인가?
- 거리 계산은 어떻게 할 것인가?
- 결과를 어떤 형태로 보여줄 것인가?

이런 질문들에 대한 기본적인 이해가 있다면, 개발팀과의 대화가 훨씬 생산적이고 효율적으로 변합니다. 불필요한 오해나 재작업을 줄이고, 진짜 중요한 부분에 집중할 수 있게 되죠.

## API란 무엇인가요? 기획자를 위한 쉬운 설명

API(Application Programming Interface)는 쉽게 말해서 서로 다른 소프트웨어 간의 '대화 방식'입니다. 마치 식당에서 메뉴판을 보고 음식을 주문하면, 주방에서 그 주문을 받아 음식을 만들어 내는 것처럼요.

여기서:

- 메뉴판 = API 문서
- 주문 방식 = API 호출 방법
- 주문한 음식 = API 응답

우리가 사용하는 대부분의 앱과 서비스는 여러 API를 통해 데이터를 주고받습니다. 카카오톡으로 메시지를 보내거나, 배달의민족에서 음식을 주문하거나, 네이버 지도에서 길을 찾을 때도 모두 API가 작동하고 있어요.

## 좋은 API 설계의 핵심 원칙

기획자로서 API 설계의 세부적인 기술적 내용까지 알 필요는 없지만, 핵심 원칙을 이해한다면 개발팀과의 소통이 훨씬 수월해집니다. 여기 알아두면 좋을 핵심 원칙들을 소개합니다:

### 1. 일관성(Consistency)

인터페이스 디자인에서 일관성이 중요한 것처럼, API에서도 일관성은 매우 중요합니다. 엔드포인트 이름부터 요청/응답 형태까지 모든 것이 일관된 패턴을 따라야 합니다.

예를 들어, 사용자 정보를 가져오는 API가 `/get-user`이고, 게시물을 가져오는 API가 `/posts/retrieve`라면? 개발자는 혼란스러울 겁니다. `/users`와 `/posts`처럼 일관된 형태를 유지하는 게 좋습니다.

기획자로서 여러분은 기능의 명명법이나 사용자 여정에 일관성을 부여하듯이, API 설계에도 같은 원칙이 적용된다는 점을 이해하면 도움이 됩니다.

### 2. 직관성(Intuitiveness)

좋은 API는 직관적입니다. 마치 잘 설계된 UX처럼, 개발자가 처음 봐도 어떻게 사용해야 할지 알 수 있어야 합니다.

예를 들어:

- `/users` - 사용자 목록을 가져온다
- `/users/{id}` - 특정 사용자 정보를 가져온다
- `/users/{id}/posts` - 특정 사용자의 게시물을 가져온다

이런 구조는 마치 잘 정리된 파일 시스템처럼 직관적으로 이해할 수 있습니다.

### 3. 단순성(Simplicity)

복잡한 기능도 가능한 한 단순하게 표현하는 것이 중요합니다. "모든 것이 가능한" API보다는 "필요한 것만 제공하는" API가 더 좋습니다.

기획 단계에서도 마찬가지죠. 모든 기능을 한 번에 넣으려 하기보다, 사용자에게 정말 필요한 기능에 집중하는 것처럼요.

### 4. 확장성(Extensibility)

좋은 API는 미래의 변화에 대응할 수 있어야 합니다. 오늘 설계한 API가 내일의 요구사항도 수용할 수 있어야 합니다.

기획자로서 여러분도 제품의 로드맵을 고려하여 기능을 설계하듯이, API도 미래 확장성을 고려해 설계해야 함을 이해하면 좋습니다.

## REST API: 가장 널리 사용되는 API 디자인 패턴

현대 웹 서비스에서 가장 많이 사용되는 API 디자인 패턴은 REST(Representational State Transfer)입니다. REST API의 기본 개념을 이해하면, 개발자와의 대화에서 많은 도움이 됩니다.

### REST API의 핵심 특징:

1. **리소스 중심 설계**: 모든 것을 '리소스'(자원)로 표현합니다. 사용자, 게시물, 댓글 등이 모두 리소스가 될 수 있습니다.
2. **HTTP 메서드 활용**: 리소스에 대한 작업은 HTTP 메서드로 표현합니다.
    - GET: 데이터 조회
    - POST: 새 데이터 생성
    - PUT/PATCH: 데이터 수정
    - DELETE: 데이터 삭제
3. **상태를 저장하지 않음**: 각 요청은 독립적이며, 이전 요청에 의존하지 않습니다.

기획자 관점에서 이해하면:

- 리소스 = 관리해야 할 주요 데이터(사용자, 상품, 주문 등)
- HTTP 메서드 = 해당 데이터로 수행할 수 있는 작업(조회, 생성, 수정, 삭제)

## API 문서화: 왜 중요하고 어떻게 활용해야 할까?

API 문서화는 단순히 개발자를 위한 것이 아닙니다. 기획자에게도 큰 도움이 되는 자료입니다.

### 좋은 API 문서의 특징:

1. **완전성**: 모든 엔드포인트, 파라미터, 응답 형식이 상세히 기술되어 있어야 합니다.
2. **명확성**: 기술적 용어뿐만 아니라 비즈니스 맥락도 포함해야 합니다.
3. **예시**: 실제 요청과 응답 예시가 포함되어 있어야 합니다.
4. **업데이트**: 항상 최신 상태를 유지해야 합니다.

### 기획자가 API 문서를 활용하는 방법:

1. **기능 범위 이해**: API 문서를 통해 현재 시스템의 기능 범위를 이해할 수 있습니다.
2. **새 기능 기획 시 참고**: 새로운 기능을 기획할 때, 기존 API와의 연계 가능성을 검토할 수 있습니다.
3. **타임라인 예측**: 어떤 API가 이미 구현되어 있고, 어떤 것이 새로 개발해야 하는지 파악하면 일정 예측에 도움이 됩니다.
4. **커뮤니케이션 도구**: 개발팀과의 대화에서 공통 언어로 활용할 수 있습니다.

## 실제 사례로 보는 API 설계와 문서화

실제 사례를 통해 API 설계와 문서화가 어떻게 제품 개발에 영향을 미치는지 살펴봅시다.

### 사례 1: 카카오 지도 API

카카오 지도 API는 좋은 예입니다. 단순한 지도 표시부터 복잡한 경로 검색까지, 다양한 기능을 직관적인 인터페이스로 제공합니다.

기획자 관점에서:

- 위치 기반 서비스를 기획할 때, 카카오 지도 API 문서를 참고하면 어떤 기능이 가능한지 빠르게 파악할 수 있습니다.
- API 문서에 있는 예시 코드를 개발팀과 공유하며 "이런 식으로 구현하면 될까요?"라고 물어볼 수 있습니다.

### 사례 2: 결제 시스템 API

결제 시스템은 복잡하지만 중요한 부분입니다. 토스페이먼츠나 포트원(구 아임포트) 같은 결제 API는 복잡한 결제 프로세스를 단순한 API 호출로 가능하게 합니다.

기획자 관점에서:

- 결제 시스템 API 문서를 통해 어떤 결제 방식이 지원되는지, 각 방식별로 어떤 정보가 필요한지 파악할 수 있습니다.
- 결제 실패 시나리오나 환불 프로세스 같은 예외 케이스도 미리 확인하고 기획에 반영할 수 있습니다.

## 기획자를 위한 API 이해 팁

API에 대한 이해도를 높이고 싶은 기획자를 위한 실용적인 팁을 몇 가지 소개합니다:

### 1. API 문서 읽는 습관 들이기

여러분의 서비스나 경쟁사 서비스의 API 문서를 읽어보세요. 처음에는 어렵게 느껴질 수 있지만, 점차 패턴을 발견하게 될 것입니다.

### 2. 개발팀과의 대화에 참여하기

API 설계 논의 과정에 참여해보세요. 처음에는 듣기만 해도 좋습니다. 개발자들이 어떤 식으로 API를 설계하고 논의하는지 관찰하면 많은 것을 배울 수 있습니다.

### 3. API 테스트 도구 사용해보기

Postman 같은 API 테스트 도구를 사용해보세요. 실제로 API를 호출하고 응답을 받아보면 더 직관적으로 이해할 수 있습니다.

### 4. 마이크로 프로젝트 시도하기

간단한 API를 사용하는 토이 프로젝트를 시도해보세요. 날씨 API를 이용한 간단한 날씨 앱이나, 공공 데이터 API를 활용한 정보 대시보드 등이 좋은 시작점이 될 수 있습니다.

## 마무리: API는 소통의 다리

결국 API는 소프트웨어 간의 소통 방식인 동시에, 기획자와 개발자 간의 소통 도구이기도 합니다. API에 대한 기본적인 이해는 더 나은 제품을 만들기 위한 토대가 됩니다.

기획자로서 여러분이 API 설계와 문서화의 중요성을 이해하고, 이를 활용할 수 있다면, 개발팀과의 협업은 더욱 원활해지고 제품의 품질은 향상될 것입니다.

오늘 이 글이 여러분의 API 여정에 작은 도움이 되었기를 바랍니다. 기획과 개발 사이의 간극을 좁히는 일, 함께 해봐요!

---

*이 글이 도움이 되셨다면 주변에 많이 공유해주세요😚* 

개발자와 한 팀이 되는 비밀 노트: API 설계 원칙

안녕하세요, IT 다이어리 독자 여러분! 오늘은 요즘 AI 분야에서 가장 뜨거운 기술 중 하나인 'RAG(Retrieval-Augmented Generation)' 시스템에 대해 알아보려고 합니다. "또 어려운 기술 이야기네..."라고 생각하시는 분들,,😅 걱정 마세요! 기획자의 관점에서 쉽게 이해할 수 있도록 설명해 드릴게요.

## RAG가 뭐길래 이렇게 핫한가요?

여러분, 챗GPT나 클로드 같은 LLM을 사용해 보셨나요? 이런 대규모 언어 모델(LLM)들은 정말 똑똑하지만, 한 가지 치명적인 단점이 있습니다. 바로 **여러분의 회사 데이터를 모른다**는 점이죠.

- "우리 회사의 2023년 4분기 매출은 얼마였지?"
- "우리 제품의 최신 기술 스펙이 뭐야?"
- "지난주 경영진 회의에서 결정된 사항은?"

이런 질문들에 챗GPT는 "죄송합니다, 저는 귀사의 내부 데이터에 접근할 수 없습니다"라고만 답할 수 있죠. 여기서 등장한 게 바로 RAG 시스템입니다. RAG는 기존 AI 모델에 여러분의 데이터를 '검색(Retrieval)'하여 '생성(Generation)'에 활용하는 기술이에요. 쉽게 말해, **내 회사 데이터를 알고 있는 나만의 AI 비서**를 만드는 기술인 셈이죠!

## RAG의 작동 원리, 쉽게 이해하기

RAG 시스템이 어떻게 작동하는지 가장 직관적인 방법으로 설명해 드릴게요.

### 1. 데이터 수집 및 처리

먼저, 회사의 데이터를 모아야 합니다. 어떤 데이터가 필요할까요?

- 내부 문서 (보고서, 회의록, 정책 문서)
- 제품 매뉴얼이나 기술 사양서
- 고객 서비스 데이터
- 회사 위키나 지식 베이스
- 마케팅 자료 등

이 데이터들은 보통 PDF, Word, 엑셀, HTML 등 다양한 형태로 존재합니다. RAG 시스템에서는 이 데이터들을 모두 텍스트로 변환하고, 작은 '청크(chunk)'라고 불리는 조각들로 나눕니다. 왜 이렇게 할까요? 너무 긴 문서는 한 번에 처리하기 어렵기 때문이에요. 보통 청크 하나의 크기는 500~1000자 정도로 설정합니다.

### 2. 임베딩(Embedding) 생성

자, 이제 중요한 부분입니다. 컴퓨터는 텍스트의 '의미'를 어떻게 이해할까요? 바로 '임베딩'이라는 기술을 사용합니다. 임베딩은 텍스트를 숫자 벡터로 변환하는 과정인데, 의미가 비슷한 텍스트는 비슷한 벡터값을 갖게 됩니다.

예를 들어보죠:

- "고객 만족도가 상승했습니다"
- "고객들의 만족도가 좋아졌어요"

이 두 문장은 표현은 다르지만 의미는 비슷하죠? 임베딩을 통해 이 두 문장은 벡터 공간에서 가까운 위치에 놓이게 됩니다. 대표적인 임베딩 모델로는 OpenAI의 `text-embedding-ada-002`나 구글의 `embedding-gecko-001` 등이 있어요.

### 3. 벡터 데이터베이스에 저장

생성된 임베딩 벡터들은 특별한 데이터베이스에 저장해야 합니다. 일반 데이터베이스(MySQL, PostgreSQL 등)와 달리, 벡터 데이터베이스는 '의미적 검색'에 최적화되어 있습니다. 대표적인 벡터 데이터베이스로는:

- Pinecone
- Weaviate
- Chroma
- Qdrant
- Milvus

등이 있어요. 이들은 모두 '벡터 유사도'를 빠르게 계산할 수 있도록 설계되었습니다.

### 4. 검색(Retrieval) 단계

사용자가 질문을 하면 어떤 일이 일어날까요? 다음과 같은 과정이 진행됩니다:

1. 사용자의 질문도 임베딩 벡터로 변환합니다.
2. 이 질문 벡터와 가장 유사한 문서 청크들을 벡터 데이터베이스에서 검색합니다.
3. 보통 유사도 점수가 가장 높은 상위 3~5개 청크를 가져옵니다.

여기서 중요한 개념이 바로 'k-NN(k-Nearest Neighbors)' 알고리즘입니다. 가장 가까운 이웃 k개를 찾는 방식인데, RAG에서는 질문과 가장 관련 있는 문서 조각 k개를 찾는 데 사용됩니다.

### 5. 생성(Generation) 단계

마지막으로, 검색된 관련 정보와 함께 사용자의 질문을 LLM(GPT-4, Claude 등)에 전달합니다. 이때 프롬프트는 대략 이런 형태가 됩니다:

```
다음 정보를 바탕으로 사용자의 질문에 답변해 주세요:

[검색된 문서 청크 1]
[검색된 문서 청크 2]
[검색된 문서 청크 3]

사용자 질문: "2023년 4분기 마케팅 캠페인의 ROI는 얼마였나요?"

```

LLM은 주어진 문서 정보를 참고하여 질문에 답변합니다. 이 과정에서 핵심은 LLM이 **스스로 알고 있는 정보가 아니라, 검색된 문서의 정보를 바탕으로** 답변한다는 점입니다. 이렇게 하면 최신 정보나 회사 내부 데이터에 기반한 정확한 답변을 얻을 수 있죠.

## RAG 시스템의 구체적인 구현 방법

자, 이제 RAG 시스템을 실제로 어떻게 구축하는지 더 구체적으로 알아볼까요?

### 필요한 기술 스택

RAG 시스템 구축에 필요한 주요 기술 요소들입니다:

1. **데이터 처리 파이프라인**
    - 문서 로더: 다양한 형식의 문서를 읽어들이는 도구 (LangChain, LlamaIndex 등)
    - 텍스트 분할기: 문서를 적절한 크기의 청크로 나누는 도구
    - 데이터 정제: 불필요한 태그, 중복 내용 제거 등
2. **임베딩 모델**
    - OpenAI Embeddings API
    - Google's Text Embedding API
    - Hugging Face의 오픈소스 모델(BERT, Sentence-BERT 등)
3. **벡터 데이터베이스**
    - 클라우드 서비스형: Pinecone, Weaviate Cloud
    - 자체 호스팅: Chroma, Qdrant, Milvus
    - PostgreSQL + pgvector 확장(소규모 프로젝트용)
4. **대규모 언어 모델(LLM)**
    - 상용 API: OpenAI(GPT-4), Anthropic(Claude), Google(Gemini)
    - 자체 호스팅: Llama 2, Mistral 등의 오픈소스 모델
5. **통합 프레임워크**
    - LangChain: 가장 널리 사용되는 LLM 애플리케이션 개발 프레임워크
    - LlamaIndex: 데이터 인덱싱과 쿼리에 특화된 프레임워크
    - Haystack: 검색 중심의 NLP 프레임워크

### 간단한 구현 흐름 예시

```python
# 이는 개념적인 코드 예시입니다(실제 작동 코드는 아님)

# 1. 데이터 로딩
from langchain.document_loaders import DirectoryLoader
loader = DirectoryLoader('./company_docs/')
documents = loader.load()

# 2. 텍스트 분할
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = text_splitter.split_documents(documents)

# 3. 임베딩 생성
from langchain.embeddings import OpenAIEmbeddings
embeddings = OpenAIEmbeddings()

# 4. 벡터 저장소 설정
from langchain.vectorstores import Chroma
vectorstore = Chroma.from_documents(chunks, embeddings)

# 5. 검색기 설정
retriever = vectorstore.as_retriever(search_type="similarity", search_kwargs={"k": 3})

# 6. LLM 설정
from langchain.llms import OpenAI
llm = OpenAI(temperature=0)

# 7. RAG 체인 구성
from langchain.chains import RetrievalQA
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever
)

# 8. 질의응답
query = "2023년 4분기 마케팅 캠페인의 ROI는 얼마였나요?"
response = qa_chain.run(query)
print(response)

```

여기까지 따라오신 여러분! 기본적인 RAG 시스템 구축 방법을 모두 이해하셨습니다.

축하드려요!! 🎉🎉

## RAG 시스템 구축 시 주의사항

기획자로서 실무에 RAG 시스템 도입을 고려하신다면, 다음 사항들을 꼭 확인해 보세요:

### 1. 데이터 품질 관리

RAG 시스템을 사용하실 때는 '쓰레기가 들어가면 쓰레기가 나온다(Garbage In, Garbage Out)' 원칙을 꼭 기억하셔야 해요. 데이터의 정확성, 최신성, 관련성을 지속적으로 관리해야 좋은 퀄리티의 결과물을 얻을 수 있습니다!

### 2. 개인정보 및 보안

회사 내부 데이터를 AI 시스템에 연결할 때는 항상 보안과 개인정보 보호에 신경 써야 합니다:

- 민감한 개인정보가 포함된 문서는 제외하거나 마스킹 처리
- 데이터 액세스 권한 관리
- 온프레미스 또는 프라이빗 클라우드 배포 고려

### 3. 환각(Hallucination) 관리

LLM은 때때로 없는 정보를 지어내는 '환각' 현상을 보입니다. RAG에서는 이를 최소화하기 위해:

- 낮은 temperature 설정 사용
- 답변 생성 시 인용문, 출처 요구
- 불확실성을 표현하도록 LLM 지시

### 4. 성능 측정

RAG 시스템의 성능을 객관적으로 평가하기 위한 지표들:

- 정확도: 사실적으로 맞는 답변의 비율
- 관련성: 질문과 관련된 정보를 제공하는지 여부
- 검색 효율성: 관련 문서를 얼마나 잘 검색하는지
- 응답 시간: 질문에 답변하는 데 걸리는 시간

## RAG 시스템 활용 사례

그럼 다양한 업종에서 RAG 시스템이 어떻게 활용될 수 있는지 살펴보겠습니다:

### 1. 고객 서비스 강화

- 상담원이 제품 매뉴얼, FAQ, 과거 상담 사례를 빠르게 검색하여 고객 문의에 응대
- 고객이 직접 이용할 수 있는 지식 기반 챗봇 구축

### 2. 내부 지식 관리

- 사내 위키, 문서, 이메일 등의 정보를 통합하여 직원들이 쉽게 필요한 정보를 찾을 수 있는 시스템 구축
- 신입 사원 온보딩 및 교육 지원

### 3. 연구 및 분석 보조

- 연구원이 방대한 논문, 보고서를 빠르게 검색하고 분석할 수 있는 도구
- 경쟁사 동향, 시장 트렌드 분석에 활용

### 4. 프로덕트 기획 및 개발

- 사용자 피드백, 버그 리포트, 기능 요청 등을 분석하여 제품 개선 방향 도출
- 개발 문서, API 문서 등을 쉽게 검색하여 개발 효율성 향상

## 마치며: 기획자가 RAG를 고려해야 하는 이유

RAG 시스템은 AI의 최신 트렌드일 뿐만 아니라, 실질적인 비즈니스 가치를 창출할 수 있는 기술입니다. 기획자로서 RAG를 고려해야 하는 이유는 다음과 같습니다:

1. **정보 접근성 향상**: 회사의 내부 지식을 누구나 쉽게 접근하고 활용할 수 있게 만듭니다.
2. **생산성 증대**: 정보 검색에 소요되는 시간을 대폭 줄여 업무 효율성을 높입니다.
3. **의사결정 지원**: 관련 데이터와 인사이트를 신속하게 제공하여 더 나은 의사결정을 돕습니다.
4. **지식 보존**: 퇴사자가 가져가는 암묵적인 지식들을 시스템화하여 조직 내에 보존할 수 있습니다.
5. **경쟁 우위 확보**: 정보를 더 효과적으로 활용하는 조직이 시장에서 우위를 점할 수 있습니다.

RAG 시스템은 기술적으로 복잡해 보일 수 있지만, 기획자로서 이 기술의 원리와 가능성을 이해한다면 조직 내에서 더 가치 있는 AI 프로젝트를 기획하고 추진할 수 있을 것입니다.

---

여러분의 조직에서는 어떤 데이터가 RAG 시스템과 결합되면 가장 큰 가치를 창출할 수 있을까요?

오늘 아티클이 도움이 되셨다면, 주변에 널리 공유해주세요!

여러분의 관심이 더 좋은 콘텐츠를 만들어갑니다 😄

기획자가 알아야 할 RAG 시스템의 모든 것

안녕하세요, IT 다이어리 독자 여러분! 오늘은 요즘 AI 개발 분야에서 핫한 키워드, '랭체인(LangChain)'과 '랭그래프(LangGraph)'에 대해 알아볼게요. 개발자들끼리만 알 법한 이 기술들, 기획자인 우리도 알면 회의 때 한 수 위로 보일 테니 차근차근 살펴봅시다! 😉

## 🤖 그래서 랭체인(LangChain)이 뭔데?

먼저 랭체인의 정체를 파헤쳐 봅시다. 거창하게 들리지만, 쉽게 말하면 '**AI 언어 모델을 활용한 애플리케이션을 더 쉽게 만들기 위한 도구**'예요.

ChatGPT나 Claude 같은 AI 모델을 실제 서비스에 적용하려면 여러 단계의 작업이 필요한데, 이걸 마치 레고 블록처럼 조립할 수 있게 해주는 프레임워크라고 생각하시면 됩니다.

### 랭체인이 해결하는 문제들:

1. **AI에게 기억력 주기** - AI는 대화 맥락을 잘 잊어버려요. 랭체인은 대화 기록을 관리해줍니다.
2. **외부 정보 연결하기** - AI가 구글 검색이나 데이터베이스에 접근할 수 있게 해줍니다.
3. **복잡한 사고 과정 설계하기** - 여러 단계의 사고 과정을 설계할 수 있어요.

기획자 입장에서는 "AI가 실제로 우리 서비스에서 어떻게 동작할 수 있을까?"라는 질문에 대한 실질적인 답을 제공하는 도구라고 볼 수 있어요.

## 📦 랭체인의 핵심 구성 요소

랭체인은 아래 핵심 컴포넌트들로 구성되어 있어요:

### 1. 모델 (LLMs & Chat Models)

AI 두뇌에 해당하는 부분입니다. OpenAI의 GPT 모델, Anthropic의 Claude, 오픈소스 모델인 Llama 등을 연결해 사용할 수 있어요.

```python
from langchain_openai import ChatOpenAI

# ChatGPT 모델을 초기화
llm = ChatOpenAI(
    model="gpt-3.5-turbo",
    temperature=0.7
)

# 간단한 질문하기
response = llm.invoke("안녕하세요, 오늘 날씨 어때요?")
print(response.content)

```

`temperature=0.7`은 AI의 창의성 수준을 조절하는 값이에요. 0에 가까울수록 일관된 답변, 1에 가까울수록 창의적인 답변을 제공합니다.

### 2. 프롬프트 템플릿 (Prompt Templates)

AI에게 질문하는 방식을 표준화하는 도구예요. 마치 설문지 템플릿 같은 거죠.

```python
from langchain.prompts import PromptTemplate

# 프롬프트 템플릿 만들기
template = PromptTemplate.from_template(
    "고객의 이름은 {name}이고, 관심사는 {interest}입니다. 맞춤형 인사말을 작성해주세요."
)

# 템플릿에 변수 채우기
prompt = template.format(name="김기획", interest="UX 디자인")
print(prompt)

```

이렇게 하면 매번 비슷한 패턴의 질문을 일일이 작성하지 않아도 되죠!

### 3. 메모리 (Memory)

AI가 대화 내용을 기억하게 해주는 기능이에요. 실제 서비스에서는 정말 중요한 부분이죠.

```python
from langchain.memory import ConversationBufferMemory

# 대화 기억 공간 만들기
memory = ConversationBufferMemory()

# 대화 내용 저장하기
memory.save_context(
    {"input": "안녕하세요, 저는 김기획입니다."},
    {"output": "안녕하세요 김기획님, 반갑습니다!"}
)

# 지금까지 대화 내용 불러오기
print(memory.load_memory_variables({}))

```

이 기능 덕분에 "아까 말한 그거"라고 언급해도 AI가 이해할 수 있어요.

### 4. 체인 (Chains)

여러 단계를 하나로 연결하는 기능이에요. 각 단계의 출력이 다음 단계의 입력으로 전달됩니다.

```python
from langchain.chains import LLMChain

# AI 모델과 프롬프트 템플릿을 연결한 체인 만들기
chain = LLMChain(
    llm=llm,
    prompt=template,
    verbose=True
)

# 체인 실행하기
result = chain.invoke({"name": "이과장", "interest": "데이터 분석"})
print(result["text"])

```

### 5. 도구 (Tools)

AI가 외부 세계와 상호작용할 수 있게 해주는 기능이에요. 검색 엔진, 데이터베이스, API 등을 연결할 수 있습니다.

```python
from langchain.tools import DuckDuckGoSearchRun

# 검색 도구 만들기
search_tool = DuckDuckGoSearchRun()

# 검색하기
search_result = search_tool.invoke("2023년 가장 인기있는 AI 서비스는?")
print(search_result)

```

### 6. 에이전트 (Agents)

AI에게 스스로 판단해서 적절한 도구를 사용하게 하는 기능이에요. 마치 비서에게 "이거 알아봐줘"라고 지시하는 것과 비슷합니다.

```python
from langchain.agents import initialize_agent, AgentType

# 에이전트 만들기
agent = initialize_agent(
    tools=[search_tool],
    llm=llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

# 에이전트에게 질문하기
agent.invoke("최근 개봉한 영화 중 평점이 가장 높은 것은?")

```

에이전트는 스스로 검색할지, 계산할지, 다른 작업을 할지 판단해서 결과를 도출합니다.

## 🕸️ 랭그래프(LangGraph)는 또 뭐야?

랭그래프는 랭체인을 만든 팀에서 최근에 공개한 신기술이에요. 쉽게 말하자면 "**복잡한 AI 워크플로우를 그래프 형태로 설계할 수 있는 도구**"입니다.

### 랭체인 vs 랭그래프

랭체인이 직선적인 작업 흐름(A → B → C)을 만들기 좋다면, 랭그래프는 분기가 많은 복잡한 흐름(A → B 또는 C → D 또는 다시 A)을 설계하기에 좋아요.

```
랭체인: A → B → C → 끝
랭그래프: A → B → C → D → B → C → 끝
               ↓       ↑
               E → F →→↑

```

### 랭그래프 기본 구조

랭그래프는 노드(작업)와 엣지(연결)로 구성된 그래프를 만들어요.

```python
from langgraph.graph import StateGraph
import operator

# 상태 그래프 정의하기
graph = StateGraph()

# 노드(작업) 추가하기
graph.add_node("검색", search_function)
graph.add_node("요약", summarize_function)
graph.add_node("응답생성", response_function)

# 엣지(연결) 추가하기
graph.add_edge("검색", "요약")
graph.add_conditional_edges(
    "요약",
    decide_next_step,  # 조건에 따라 어디로 갈지 결정하는 함수
    {
        "더_검색_필요": "검색",  # 더 검색이 필요하면 검색으로 돌아감
        "응답_생성": "응답생성"   # 아니면 응답생성으로 진행
    }
)

# 시작과 끝 정의
graph.set_entry_point("검색")
graph.add_edge("응답생성", END)

```

이런 식으로 복잡한 의사결정 과정을 가진 AI 워크플로우를 설계할 수 있어요.

## 💡 기획자가 알면 좋은 활용 사례

랭체인과 랭그래프를 이용하면 어떤 서비스를 만들 수 있을까요? 기획자 관점에서 재미있는 활용 사례를 살펴봅시다.

### 1. 맞춤형 고객 서비스 챗봇

고객 DB와 연결된 랭체인 기반 챗봇은 단순 응답을 넘어, 고객의 과거 구매 이력을 분석해 맞춤형 상품을 추천해줄 수 있어요.

```python
# 고객 관리 시스템과 연결된 도구
crm_tool = CRMTool()

# 상품 추천 시스템과 연결된 도구
recommendation_tool = RecommendationTool()

# 이 도구들을 에이전트에 연결하면 맞춤형 상담 가능!
customer_agent = initialize_agent(
    tools=[crm_tool, recommendation_tool],
    llm=llm
)

```

### 2. 데이터 분석 비서

비즈니스 데이터를 분석하고 인사이트를 제공하는 AI 도우미를 만들 수 있어요.

```python
# 데이터 분석과 시각화 도구들
data_tools = [
    DataLoadTool(),
    DataAnalysisTool(),
    DataVisualizationTool()
]

# 랭그래프로 복잡한 분석 워크플로우 설계
analysis_graph = StateGraph()
analysis_graph.add_node("데이터_로드", data_tools[0])
analysis_graph.add_node("데이터_분석", data_tools[1])
analysis_graph.add_node("데이터_시각화", data_tools[2])
# ...

```

### 3. 콘텐츠 제작 파이프라인

기획자가 아이디어만 입력하면 콘텐츠 초안부터 SEO 최적화, 이미지 생성까지 자동화하는 시스템도 가능해요.

```python
# 콘텐츠 생성 → SEO 최적화 → 이미지 생성까지 연결된 체인
content_chain = LLMChain(
    llm=llm,
    prompt=content_template
)
seo_chain = LLMChain(
    llm=llm,
    prompt=seo_template
)
image_chain = ImageGenerationChain()

# 체인들을 순차적으로 연결
content_pipeline = SequentialChain(
    chains=[content_chain, seo_chain, image_chain]
)

```

## 🚀 실전: 간단한 기획 도우미 만들기

실제로 랭체인을 활용한 간단한 '기획 아이디어 확장 도우미'를 만들어볼까요?

```python
from langchain_openai import ChatOpenAI
from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain
from langchain.tools import DuckDuckGoSearchRun

# 1. AI 모델 초기화
llm = ChatOpenAI(model="gpt-3.5-turbo")

# 2. 검색 도구 초기화
search_tool = DuckDuckGoSearchRun()

# 3. 아이디어 확장 프롬프트 만들기
idea_template = PromptTemplate.from_template(
    """당신은 창의적인 기획자의 조수입니다.
    다음 아이디어를 더 발전시키고 구체화해주세요:

    아이디어: {idea}

    최신 트렌드와 시장 상황을 고려하여 이 아이디어의:
    1. 장단점
    2. 타겟 사용자
    3. 차별화 포인트
    4. 발전 방향 3가지

    를 제시해주세요."""
)

# 4. 시장 조사 프롬프트 만들기
research_template = PromptTemplate.from_template(
    """다음 아이디어와 관련된 시장 조사 결과를 바탕으로 인사이트를 도출해주세요:

    아이디어: {idea}
    시장 조사 결과: {research}

    이 정보를 바탕으로 구체적인 전략 방향을 제시해주세요."""
)

# 5. 아이디어 확장 체인 만들기
idea_chain = LLMChain(
    llm=llm,
    prompt=idea_template,
    output_key="expanded_idea"
)

# 6. 시장 조사 함수 만들기
def do_market_research(idea):
    search_query = f"{idea} 시장 동향 최신 트렌드"
    return search_tool.invoke(search_query)

# 7. 시장 조사 기반 전략 체인 만들기
strategy_chain = LLMChain(
    llm=llm,
    prompt=research_template
)

# 8. 전체 파이프라인 실행 함수
def expand_idea(idea):
    # 아이디어 확장
    expanded = idea_chain.invoke({"idea": idea})

    # 시장 조사
    research = do_market_research(idea)

    # 전략 도출
    strategy = strategy_chain.invoke({
        "idea": idea,
        "research": research
    })

    return {
        "원본 아이디어": idea,
        "확장된 아이디어": expanded["expanded_idea"],
        "시장 조사": research[:300] + "...",  # 너무 길면 줄임
        "전략 방향": strategy["text"]
    }

# 9. 실행 예시
result = expand_idea("반려동물을 위한 AI 건강 모니터링 서비스")
print(result)

```

이렇게 만든 기획 도우미는 아이디어를 입력하면 자동으로 확장하고, 실시간 시장 정보를 검색해 전략까지 제안해주는 실용적인 도구가 됩니다!

## 🔍 랭체인과 랭그래프, 왜 기획자가 알아야 할까?

기획자에게 랭체인과 랭그래프를 알아두면 좋은 이유는:

1. **현실적인 AI 서비스 기획 가능** - 단순히 "AI를 넣자"가 아닌, 구체적으로 어떤 기능이 가능한지 이해할 수 있어요.
2. **개발자와 소통 원활** - "GPT API 연결하면 되잖아요?"보다 훨씬 구체적인 대화가 가능합니다.
3. **프로토타입 직접 제작** - 간단한 코드만으로도 실제 작동하는 프로토타입을 만들 수 있어요.
4. **비용과 시간 예측** - 어떤 기능이 복잡하고 비용이 많이 드는지 가늠할 수 있습니다.

## 💌 마치며

이제 랭체인과 랭그래프가 대체 뭔지 감이 오시나요? 복잡한 AI 기술을 실용적으로 활용할 수 있게 해주는 도구라고 생각하시면 됩니다.

완벽히 이해하지 못해도 괜찮아요. 이런 도구들이 있다는 것과 대략적인 기능을 알고 있는 것만으로도, 개발팀과의 회의에서 한층 더 깊이 있는 대화가 가능해질 거예요.

---

*이 글이 도움이 되셨다면 주변에 공유해주세요! 여러분의 응원과 관심이 더 좋은 콘텐츠를 만들어갑니다!*

Langchain, Langgraph가 대체 뭐야?

# 파이썬, 어떻게 배워야할까요?

기획자 신입으로 입사했는데, 개발 용어들을 이해 못하는 상황에 당황하신 분들 많으시죠?

오늘은 기획자분들이 개발자와 소통할 때 도움이 될 파이썬 기본 문법을 재미있게 알아보려고 합니다. "코딩은 어렵다"라는 편견, 오늘 함께 깨보는걸로 해요!

## 🐍 파이썬이 인기 있는 이유

먼저, 왜 파이썬이 이렇게 핫한지 알아볼까요? 파이썬은 마치 영어 문장처럼 읽히는 직관적인 문법을 가졌습니다. 다른 언어에서 복잡한 괄호나 세미콜론으로 머리 아플 일이 거의 없죠.

```python
# 다른 언어: System.out.println("Hello World!");
# 파이썬:
print("Hello World!")

```

단순히 "print"하고 말하면 되는 직관성! 이런 특징 때문에 개발자가 아닌 분들도 빠르게 배울 수 있어요.

## 🔠 변수와 데이터 타입 - 정보를 담는 그릇

변수는 정보를 담는 상자라고 생각하면 쉬워요. 다른 언어와 달리 파이썬에서는 상자의 종류(데이터 타입)를 미리 선언할 필요가 없습니다.

```python
# 숫자형 변수
age = 30

# 문자열 변수
name = "김파이썬"

# 불리언(참/거짓) 변수
is_programmer = False

# 실수형 변수
height = 175.5

```

여기서 포인트! 파이썬은 스스로 "아, 이건 숫자구나", "이건 문자열이구나"라고 알아서 판단합니다. 꽤 똑똑하죠?

## 📋 컬렉션 - 여러 데이터를 한번에 다루기

여러 데이터를 한 번에 다루고 싶을 때는 컬렉션 타입을 사용해요. 마치 쇼핑 카트에 여러 물건을 담는 것처럼요!

### 리스트 (List) - 순서가 있는 컬렉션

```python
# 팀원 리스트
team_members = ["김기획", "박디자인", "이개발"]

# 특정 팀원에 접근하기 (인덱스는 0부터 시작)
print(team_members[0])  # 결과: 김기획

# 리스트에 새 팀원 추가하기
team_members.append("최마케팅")
print(team_members)  # 결과: ["김기획", "박디자인", "이개발", "최마케팅"]

```

리스트는 마치 정렬된 책장처럼 순서가 있어요. 그리고 0부터 숫자를 매기는 점! 꼭 기억하세요.

### 딕셔너리 (Dictionary) - 키와 값의 쌍

```python
# 팀원 정보 딕셔너리
team_info = {
    "김기획": "기획팀",
    "박디자인": "디자인팀",
    "이개발": "개발팀"
}

# 특정 팀원의 소속 확인하기
print(team_info["김기획"])  # 결과: 기획팀

# 새 팀원 정보 추가하기
team_info["최마케팅"] = "마케팅팀"

```

딕셔너리는 사전처럼 키(이름)를 통해 값(소속)을 찾을 수 있어요. 개인정보를 저장하거나 복잡한 데이터를 구조화할 때 유용합니다.

## 🔄 제어문 - 코드의 흐름 조절하기

### if-else 조건문 - 결정을 내리는 방법

```python
budget = 1000000  # 100만원 예산

if budget >= 1500000:
    print("프리미엄 서비스를 사용할 수 있습니다.")
elif budget >= 1000000:
    print("스탠다드 서비스를 사용할 수 있습니다.")
else:
    print("베이직 서비스만 사용 가능합니다.")

```

특이한 점은 콜론(:)과 들여쓰기로 코드 블록을 구분한다는 거예요. 중괄호({})가 없어서 깔끔하죠?

### for 반복문 - 반복 작업 처리하기

```python
# 팀원 명단 출력하기
for member in team_members:
    print(member + "님, 회의 시간입니다!")

# 1부터 5까지 출력하기
for number in range(1, 6):
    print(number)

```

`for` 반복문은 마치 자동화된 컨베이어 벨트처럼 데이터를 하나씩 처리해줍니다. 특히 `range()`는 숫자 범위를 쉽게 생성해주는 유용한 함수예요.

## 🧩 함수 - 재사용 가능한 코드 블록

함수는 반복되는 작업을 패키지화한 것입니다. 마치 자주 쓰는 보고서 템플릿 같은 거죠!

```python
# 팀원 환영 메시지 함수
def welcome_team_member(name, team):
    message = name + "님, " + team + "에 오신 것을 환영합니다!"
    return message

# 함수 호출하기
new_message = welcome_team_member("김신입", "기획팀")
print(new_message)  # 결과: 김신입님, 기획팀에 오신 것을 환영합니다!

```

함수 정의는 `def`로 시작하고, `return`으로 결과값을 반환합니다. 매개변수를 통해 다양한 입력에 대응할 수 있어요.

## 🔮 문자열 다루기 - 텍스트 마술사 되기

파이썬은 문자열 처리가 정말 강력합니다. 기획자분들이 보고서나 콘텐츠를 다루듯, 파이썬도 텍스트를 자유자재로 다루죠.

```python
# 문자열 결합
first_name = "파이썬"
last_name = "김"
full_name = last_name + first_name
print(full_name)  # 결과: 김파이썬

# 문자열 포매팅 (f-string)
age = 30
intro = f"{full_name}은 {age}살입니다."
print(intro)  # 결과: 김파이썬은 30살입니다.

# 문자열 메서드
slogan = "파이썬으로 세상을 바꾸자"
print(slogan.upper())  # 결과: 파이썬으로 세상을 바꾸자
print(slogan.replace("세상", "미래"))  # 결과: 파이썬으로 미래를 바꾸자

```

특히 f-string(formated string)은 최신 파이썬에서 가장 편리한 문자열 포매팅 방식으로, 변수를 문자열 안에 직접 넣을 수 있어요.

## 📁 모듈과 라이브러리 - 필요한 도구 가져오기

파이썬의 진짜 강점은 풍부한 라이브러리입니다. 필요한 기능이 이미 누군가에 의해 만들어져 있는 경우가 많아요.

```python
# 날짜/시간 관련 기능 가져오기
import datetime

# 현재 날짜 출력하기
today = datetime.datetime.now()
print(f"오늘 날짜: {today.year}년 {today.month}월 {today.day}일")

# 랜덤 기능 사용하기
import random

# 1부터 45까지 숫자 중 6개 뽑기 (로또 번호 생성기)
lotto_numbers = random.sample(range(1, 46), 6)
print(f"이번주 추천 로또 번호: {sorted(lotto_numbers)}")

```

`import`로 필요한 기능을 가져오는 것! 이것이 파이썬의 모듈 시스템입니다. 기본 제공되는 표준 라이브러리만으로도 정말 많은 것을 할 수 있어요.

## 💼 실전 예제 - 간단한 투두 리스트 만들기

이제 배운 내용을 활용해 간단한 투두 리스트 프로그램을 만들어 볼까요?

```python
# 할 일 관리 프로그램
todo_list = []

# 할 일 추가 함수
def add_task(task):
    todo_list.append({"task": task, "completed": False})
    print(f"'{task}' 할 일이 추가되었습니다.")

# 할 일 완료 표시 함수
def complete_task(index):
    if 0 <= index < len(todo_list):
        todo_list[index]["completed"] = True
        print(f"'{todo_list[index]['task']}' 할 일이 완료되었습니다.")
    else:
        print("잘못된 인덱스입니다.")

# 할 일 목록 출력 함수
def show_tasks():
    if not todo_list:
        print("할 일이 없습니다.")
        return

    print("\\n===== 할 일 목록 =====")
    for index, task in enumerate(todo_list):
        status = "✅" if task["completed"] else "⬜"
        print(f"{index}. {status} {task['task']}")
    print("=====================\\n")

# 프로그램 실행
add_task("회의 자료 준비하기")
add_task("디자이너와 미팅")
add_task("개발자에게 요구사항 전달")
show_tasks()
complete_task(0)
show_tasks()

```

이렇게 간단한 코드로도 실용적인 프로그램을 만들 수 있답니다!

## 🎯 마치며 - 이제 파이썬이 더 친근하게 느껴지나요?

파이썬은 진입 장벽이 낮고 실용적인 언어이기 때문에, 기획자분들도 조금만 시간을 투자하면 기본적인 스크립트를 작성하거나 개발자들의 코드를 이해할 수 있게 됩니다.

전문 개발자가 되는 것이 목표가 아니더라도, 파이썬의 기본 문법을 이해하면:

1. 개발자와 소통이 더 원활해집니다
2. 데이터 분석이나 자동화 같은 실용적인 작업을 직접 할 수 있습니다
3. IT 프로젝트의 기술적 제약사항을 더 잘 이해할 수 있습니다

여기서 배운 내용은 빙산의 일각이지만, 파이썬의 철학인 "아름다움이 추함보다 낫다(Beautiful is better than ugly)"와 "단순함이 복잡함보다 낫다(Simple is better than complex)"를 느끼셨길 바랍니다.

다음에는 기획자를 위한 파이썬 데이터 분석 기초에 대해 알아보겠습니다. 질문이나 다루었으면 하는 주제가 있으시면 댓글로 알려주세요!

해피 코딩! 🐍✨

기획자를 위한IT 다이어리