최근 링크드인을 열면 “AI로 이런 거 만들어봤어요!” 같은 글이 하루에도 몇 개씩 올라오더라구요.
이런 글들을 보다 보면, AI만 잘 쓰면 비개발자도 바로 제품을 만들 수 있을 것 같은 분위기가 느껴집니다.
진짜 그럴까요? 회사 안에서도 AI만 있으면 비개발자도 제품을 만들 수 있을까요?
솔직히 말하면, 쉽지는 않습니다.
저도 최근 AI 제품 개발에 관심을 갖고 다른 회사 분들을 종종 만나 얘기를 나눠보는데요, 다들 비슷하게 말씀하시더라구요. 고객이 사용하는 제품에 아무 코드나 배포할 수는 없으니까요. 보안, 인프라, 코드 리뷰 — 당연히 거쳐야 할 것들이 있고요. 이를 위해서는 비개발자가 배포할 수 있는 환경 자체가 먼저 갖춰져야 합니다.
당근, 마이리얼트립 같이 AX(AI Transformation)에 앞장서는 회사들은 이런 환경을 단계적으로 만들어가고 있는 것 같아요. 예를 들면, 백엔드 개발자가 프론트 제품을 만들 수 있는 단계, 비개발자가 제품을 만들 수 있는 단계 — 이런 식으로요.
그렇다면 비개발자의 제품 개발은 허황된 이야기일까요?
그렇지는 않습니다.
저는 최근 회사에서 AI를 활용해, 적은 시간으로 조직의 생산성을 높이거나 제품의 임팩트를 높이는 데 기여한 경험이 있습니다. 고객용 제품은 아니지만, 팀이 매일 쓰는 도구를 직접 만들었습니다.
어떤 사례들이었는지 소개해볼게요.
사례 1. 팀이 매일 보는 성과 리포트의 변신
매일 스프레드시트를 열어야 했던 팀
저는 커뮤니티 제품 담당 Product Owner로 일하고 있어요. 커뮤니티에 더 많은 고객분들이 찾아오게 하기 위해, 크리에이터가 더 좋은 글을 쓸 수 있도록 관리하고 있습니다. 이 좋은 글이 더 많은 고객분들에게 가닿을 수 있도록 내외부 트래픽을 모으고, 고객 경험을 개선해서 더 많은 분들이 플랫폼을 이용하도록 하는 것이 제 역할이에요.
이 과정에서 매달 크리에이터들의 S급 게시글 실적을 관리해야 했어요. (S급 게시글이란, 조회수·댓글·공유 등 일정 기준을 충족하는 콘텐츠를 말합니다.)
그런데 기존 방식은 이랬습니다:
- 데이터가 Excel 스프레드시트에 쌓여 있음
- 크리에이터별 실적을 확인하려면 시트를 직접 열어서 필터를 걸어야 함
- 크리에이터 본인이 자기 성과를 직접 확인하기 어려운 구조
- 팀에 현황을 공유하려면 매번 수동으로 정리해야 함
개발팀에 요청하면 되지 않냐구요? 솔직히, 이런 내부 도구는 늘 우선순위에서 밀립니다. 고객이 직접 사용하는 제품이 아니니까요.
“이거 하나 만들어주세요”라고 말하기엔 개발팀 리소스가 아깝고, 그렇다고 엑셀로 계속 하기엔 한계가 있고 — 딱 그 애매한 영역이었거든요.
AI와 함께 하루 만에 대시보드를 만들었습니다
그래서 직접 만들기로 했어요.
전체 소요 시간은 이랬습니다:
| 단계 | 소요 시간 | 내용 |
|---|---|---|
| PRD 작성 | 30분 | 목표, 주요 기능, 데이터 구조, UI 요구사항 정의 |
| API 개발 | 1시간 | Google Apps Script로 데이터 API 구축 |
| 프론트엔드 개발 | 2~3시간 | Claude(AI)와 함께 React 대시보드 구현 |
| 배포 | 10분 | Vercel에 Git Push → 자동 배포 |
하루 안에 MVP가 나왔어요. (저도 처음엔 반신반의했는데, 진짜 되더라구요.)
어떤 제품이 만들어졌나
데이터 흐름은 이렇게 구성했어요:
BigQuery (원본 데이터)
↓ 쿼리 추출
Google Sheets (DB 역할)
↓ Apps Script API
React 대시보드 (Vercel 배포)
↓
Slack 알림 (매일 아침 자동 발송)
주요 기능:
- 크리에이터별 월 목표 대비 달성률 표시
- 분야별(집중분석, 최신이슈, 마인드셋, 경험담) 성과 분석
- 전체 크리에이터 랭킹
- 어제 S급 달성 시 축하 효과 (confetti!)
- 매일 아침 Slack으로 자동 리포트 발송
여러분이 궁금해하실 것 같은 부분을 미리 정리해볼게요.
“코드를 직접 짠 건가요?”
아니요. PRD를 작성하고, Claude(AI)에게 기능을 하나씩 요청했어요. “목표 달성률을 계산해서 표시해줘. 공식은 (현재 실적 / 월 목표) × 100이야.” 이런 식으로요.
여기서 중요했던 건 코드를 짜는 능력이 아니었어요. 무엇을 만들어야 하는지 명확하게 정의하는 능력이 핵심이었습니다. PRD를 30분 안에 쓸 수 있었던 건, 기획자로서 매일 해오던 일이었기 때문이에요.
“왜 이 데이터를 보려고 하는가?”, “무엇을 확인하려고 하는가?”, “어떤 기준으로 판단하려고 하는가?” — 이 세 가지가 명확하면 AI에게 제대로 된 요청을 할 수 있었어요.
“Google Sheets를 DB로 쓴 이유가 있나요?”
운영 DB에 직접 접근할 수 없는 환경이었거든요. 대신 BigQuery에서 쿼리로 데이터를 추출하고, Google Sheets에 저장한 뒤, Apps Script로 API를 만들었어요. 별도 서버를 구축하지 않아도 바로 시작할 수 있었습니다.
팀이 매일 쓰는 도구가 되었습니다
배포 이후, 크리에이터들이 매일 자기 성과를 직접 확인하기 시작했어요. Slack 알림이 매일 아침 자동으로 발송되니, 팀 전체가 현황을 따로 정리하지 않아도 자연스럽게 공유가 되더라구요.
그리고 여기서 배운 점이 하나 더 있었는데요.
사용자 피드백을 바로바로 반영할 수 있었다는 거예요.
- “달성 가능성이 뭔지 모르겠어요” → “달성률”로 용어 변경
- “모바일에서 보기 힘들어요” → 모바일에서는 테이블 대신 카드 형태로 전환
- “월이 바뀌었는데 대시보드가 업데이트 안 돼요” → 월 선택 옵션을 동적 생성으로 변경
개발팀에 요청했다면 이런 소소한 피드백은 한참 뒤에야 반영되었을 거예요. 직접 만들었기 때문에, 피드백을 받은 당일에 수정하고 재배포할 수 있었습니다. (이게 직접 만드는 것의 가장 큰 장점이었던 것 같아요.)
이런 방식으로도 활용했습니다
사례 2. KISA 스팸 소명서 자동 생성기
KISA(한국인터넷진흥원)에서 스팸 신고가 들어오면, 건별로 조치내역서를 작성해야 하는데요.
기존에는 이랬어요:
- 신고 엑셀 파일을 한 줄씩 확인하고
- DOCX 템플릿에 수동으로 내용을 입력하고
- 건별로 작성 → 건당 약 10분
AI로 자동화한 이후에는요:
- 엑셀 파일을 업로드하면 전체 건에 대한 DOCX/PDF가 자동 생성
- 전체 1분이면 끝
건당 10분이 걸리던 작업이, 전체를 합쳐도 1분이면 됩니다. 매번 같은 패턴의 서류를 반복 작성하는 업무라면, 이런 방식의 자동화가 가능하더라구요.
사례 3. AI 요약 프롬프트 설계
회사 제품에 전문가 칼럼 AI 요약 기능을 추가하는 프로젝트가 있었는데요. 여기서 프롬프트를 설계한 건 개발자가 아니라 기획자인 저였어요.
사용자 맥락을 이해하는 사람이 프롬프트를 설계해야 결과물의 품질이 높아지거든요. “이 글을 읽는 사람이 궁금해하는 건 뭘까?”, “핵심 정보를 어떤 순서로 보여줘야 할까?” — 이런 판단은 기획의 영역이니까요.
프롬프트를 여러 버전으로 테스트하고, 최적의 버전을 개발팀에 전달했어요. 결과적으로 체류시간이 증가하고, 가입 전환율도 상승했습니다.
프롬프트 설계는 “개발”이 아니라 “기획”의 연장선이라고 생각해요.
그래서, 기획자가 직접 만들어도 되는 건가요?
이 경험들을 통해 제가 배운 가장 중요한 기준이 하나 있어요:
| 구분 | 누가 만드는가 | 이유 |
|---|---|---|
| 고객용 제품 | 개발팀 | 품질, 보안, 확장성이 필수. 코드 리뷰, 테스트, 배포 프로세스가 필요 |
| 내부 구성원용 도구 | 기획자가 직접 가능 | 빠른 프로토타이핑과 즉각적 피드백 반영이 핵심 |
고객이 직접 사용하는 제품은 여전히 개발팀의 영역이에요. 보안, 확장성, 안정성을 보장해야 하니까요. 물론 이 부분도 배포 환경이나 코드 리뷰 프로세스가 갖춰지면, 비개발자가 고객용 제품 개발에도 직접 기여하는 날이 올 수 있다고 생각해요.
하지만 지금 당장은, 내부 도구는 기획자가 더 빠르게 만들 수 있었습니다. “무엇이 필요한지”를 가장 잘 아는 사람이 기획자이고, 사용자 피드백을 즉시 반영할 수 있고, 개발팀의 리소스를 쓰지 않아도 되니까요.
이 경계를 알고 나니, “개발팀에 부탁하기 애매한 영역”이 사라지더라구요.
배운 점
3가지 사례를 통해 제가 배운 것을 정리하면요.
코드를 짤 줄 아느냐가 중요한 게 아니었어요.
중요한 건 “이걸 AI한테 시키면 되겠는데?”라고 떠올릴 수 있느냐의 문제였습니다. 저는 코드를 직접 짜지 않았어요. PRD를 쓰고, AI에게 기능을 하나씩 요청하고, 결과물을 확인하고, 피드백을 주는 과정을 반복했거든요. 돌이켜보면, 이건 기획자가 매일 하는 일과 크게 다르지 않았어요.
그리고 “무엇을 만들 것인가”를 명확히 정의하는 것이 핵심이었습니다.
AI는 “대시보드를 예쁘게 만들어줘” 같은 추상적인 요청에는 추상적인 결과를 줘요. 반면 “목표 달성률이 100% 이상이면 초록색, 70% 이상이면 청록색, 그 외는 주황색으로 표시해줘”라고 구체적으로 요청하면, 바로 쓸 수 있는 결과가 나오더라구요.
요구사항을 정의하고, 기준을 명확히 하고, 우선순위를 정하는 것 — 기획자는 이미 이런 일을 매일 하고 있잖아요. 그 역량이 AI 활용에서도 그대로 통했습니다.
여러분도 지금 엑셀이나 수작업으로 반복하고 있는 업무가 하나쯤 있지 않으신가요?
개발팀에 부탁하기엔 애매하고, 그렇다고 계속 수동으로 하기엔 시간이 아까운 그런 일 말이에요.
그게 바로 여러분이 직접 만들 수 있는 것입니다.
한 가지 더 말씀드리고 싶은 건, 처음 만드는 제품은 아주 작아도 좋으니 최소 1명 이상이 꾸준히 사용할 수 있는 것이면 좋겠다는 거예요. 저도 회사에서 다른 분들과 매주 AI 세션을 갖고 있는데요, 이때도 항상 강조하는 것이 “거창할 필요 없으니, 실제로 누군가의 문제를 해결하는 제품을 만들어보세요”라는 거거든요.
일단 AI와 함께 시작해보시기를 추천드려요. 처음에는 AI가 손에 익을 때까지 오히려 더 많은 시간이 걸리기도 합니다. 기존에 하던 방식이 더 빠르게 느껴지기도 하구요. 하지만 그 시기를 지나고 나면, 어느새 익숙해진 나 자신을 발견하실 수 있을 거예요.
그럼 저는 또 AI한테 다음 도구 만들어달라고 시키러 가볼게요!