woolta

아이디어에서 제품까지 - AI로 기획부터 디자인과 모든 개발하는 과정을 실제 업무로 진행해보자

wooltaUserImgetc | 2026-08-09

들어가며

최근 claude, codex와 같은 ai도구들의 도움으로 이전대비 개발의 생산성이 급격하게 증가하고 있고 개인적으로도 크게 느끼고 있습니다. 다만 SNS, 인터넷을 보면 이런글들을 많이 다들 많이 보실텐데요

  • 혼자서 3일만에 사내 ERD 시스템 구축 !
  • 일주만일에 혼자서 수익화 서비스를 만들었어요.!!

이렇게 AI만 잘 사용하면 혼자서 아이디어 → 기획 → 디자인 → FE, BE 개발 모든 풀스택을 정말 쉽게 할수있다 고 홍보하고 있는데 사실 잘 공감이 되지는 못하였습니다. (실제 운용중인 대규모 서비스 대상으로는 쉽지 않다고 생각하기 때문 입니다.) 다만 진짜로 실무에 이러한 멀티직군 업무를 할수 있는지에 대한 고민 포인트가 있었고 이번에 실제 서비스에 도입한 기능을 아이디어 부터 제품화까지 만들게 된 경험을 공유하며 어떻게 가능했는지를 이야기해보려 합니다.

ZIP 서비스

현재 제가 담당하는 zigzag라는 서비스에는 ZIP이라는 서비스가 존재합니다. 해당 서비스는 유투버 등의 크리에이터들이 지그재그의 상품들을 모아서 추천하는 기능을 제공하고 있습니다. (인스타에서의 링크 모아보기, 무신사 서비스의 보석함 같은 서비스 와 같은 성격입니다.)

https://image.woolta.com/3fe9d32de95765f7.png

아.. 검색이 있으면 좋겠는데..

해당 zip 플랫폼 런칭 시점에는 검색기능이 없었습니다. 때문에 인앱 내부에서는 유저들이 자신들이 원하는 인플루언서들에 대해 검색을 할수 없고 플랫폼이 추천해주는 인플루언서들만 탐색하거나 인플루언서들이 자신의 채널에 남긴 링크를 통해서만 해당 크리에이터 화면을 진입할 수 있었습니다. https://image.woolta.com/3fe81406a310104d.png 위의 이미지 처럼 플랫폼 내부가 아닌 자신의 채널을 홍보해서 들어가야만 유저가 진입할 수 있는 상태

개인적으로는 이러한 부분들이 몹시 불편하게 느껴서 크리에이터 혹은 폴더에 대한 검색기능을 추가하고 싶었으나 안타깝게도 당시 개발 인력 리소스와 우선순위 사항에 밀려 바로는 추가할 수 없는 상황이였습니다.

내가 한번 해볼까…?

마침 조금씩의 재료들이 구성되고 있던 상태였습니다.

  • PRD 기획: 어느정도 팀내 작성 skill 존재 + 검색에 대한 기본 정책 구상한것이 존재
  • BE: 컨벤션, 프로젝트 아키텍쳐 등은 해당 REPO에서 BE분들이 이미 구성 완료
  • 디자인: 사내 디자인시스템이 존재 + 클로드 디자인을 통해 어느정도 구현 가능

때문에 실제로도 작업이 가능한지에 대한 검증을 해당 검색기능을 만들어보여 진행해보기로 하였습니다.

기획 문서 및 디자인

기획문서의 경우에는 팀내에서 사용중인 기획문서 작성용 클로드 스킬이 존재하여 해당 스킬을 트리거 하여 내가 작업하고 싶은 기능 (크리에이터 검색, 추천검색어, 최근검색어, 폴더 검색) 에 대한 구체적인 원하는 기능들을 나열하여 클로드 팀내 PRD 작성 스킬 + 노션MCP를 사용하여 노션에 관련된 기획 문서를 기록해두었습니다.

이후 해당 기획문서 + 사내 디자인 시스템 + 같은 ZIP 서비스의 여러 페이지 UI들을 클로드 디자인 에게 전달하여 관련된 작업 산출물을 FIGMA를 통해 전달받았습니다. 정리하자면 핵심은 다음과 같습니다.

기획문서

  • 만들고 싶은 기능에 대해 최대한 자세하게 서술한 후 이를 PRD 스킬 트리거 하여 노션에 문서화

디자인

  • 만들어진 기획 노션 문서(PRD) + 사내 디자인 시스템 + 같은 ZIP 서비스 페이지들을 클로드 디자인에 주입하여 관련된 산출물 FIGMA를 통해 산출물 구성

백엔드 작업의 시작

개발 경력 초창기에는 어느정도 백엔드 개발을 하긴 했지만 그때 경험 했던건 단순한 java + spring + jpa 정도의 스펙으로 기본적인 REST_API 에 대한 기초지식정도는 존재하였습니다. 현재는 꽤나… 오랜 시간이 지나 어렴품 기억은 하지만 사실 대부분의 스펙은 제대로 모르는 상태입니다.

더군다나 팀내 프로젝트는 코틀린 + graphql + facade구조 등 사실상 전부 처음 접하는 개념들이어서 프로젝트를 열어보자마자 어디서 부터시작하지라는 막막한 생각이 있긴했으나 그럼 어디서 시작할지부터 클로드와 함께 해보자 라는 생각으로 클로드와 함께 온보딩을 진행해보기로 합니다.

프로젝트 온보딩을 ai와 함께

사실 해당 BE프로젝트는 이미 BE 개발자분들이 관련된 ai가 읽을수 있는 컨벤션 프로젝트 구조 등이 잘 정리되어 있는 상태였습니다. 우선은 AI를 사용하여 이러한 문서들을 기반으로 프론트개발자를 기준으로 해당 프로젝트에 대한 온보딩을 구성해달라고 AI학습 플로우를 만들기 시작하였습니다. 이후 학습을 진행하면서 추가적으로 AI와의 질의응답을 몇번 진행하여도 안풀리는 부분에 있어서는 BE개발자분들에게 문의를 드리며 프로젝트의 아키텍쳐, 흐름 등을 파악하였고 약 이틀정도 파악한끝에 대략적인 개발의 아키텍쳐 작업 프로세스등을 대략적으로 파악할 수 있었습니다.

대전제 - 내가모르는것은 반영하지 않는다.

예전 토스에서 AI관련 온라인 행사를 진행할때 들은 제일 공감가는 대사가 있었습니다. "내가 모르는것은 반영하지 않는다" 최근 ai관련 강의들 보면 사람이 병목, 이해하는것이 병목 등의 방법론 들이 존재하지만 아직까지의 제 가치관에서는 "내가 모르는것은 반영하지 않는다" 라는 기준은 반드시 필요하다고 생각하여 이것을 대 전제로 진행하였습니다.

BE 구조만 아는데 어떻게 작업을 할수 있나요..?

모르는것은 반영을 하지 않는것이기 때문에 최초에는 최대한 원하는 backend의 작업 명세사항을 구체적으로 만들어 이를 기반으로 AI에게 플랜을 만들고 작업을 지시합니다.

이후 작업이 완료되면 작업파일들을 확인해보고 우선적으로 1개의 추가 스킬을 트리거 합니다.

해당 스킬은 백엔드 엔지니어링의 스펙을 React 엔지니어에게 비교해서 이해할수 있는 학습자료를 만드는 스킬로 이를 통해 이해한 부분들을 한개씩 반영해나가며 전체 BE코드를 작업할 수 있었습니다.

https://image.woolta.com/3feaa651f8195e2c.png

위의 이미지 처럼 내가 알고있는 아키텍쳐, 문법기반으로 비교설명을 해주기 떄문에 이는 몹시 빠르고 직관적으로 이해할 수 있었습니다. 또한 이러한 학습 로그는 게속 쌓이기 때문에 복습조차 용이하였습니다.

https://image.woolta.com/3febcb7bb0e9652b.png

제품화 완성..!! (프로토 타입)

디자인 + BE + FE까지 전부 작업이 되어서 팀내에 바로 해당 기능을 실제로 사용까지 가능한 상태로 공유하였습니다. 이후 긍정적인 피드백을 받았고 실제로 해당 기능이 서비스에 성공적으로 릴리즈 되었습니다..!!! 물론 개발한 제품 그대로를 QA → 릴리즈 한것은 아니고 기획, 디자인 적인 부분은 팀내 기획자, 디자이너 분이 디테일을 추가로 잡아주셨고 BE작업에 경우 해당 BE팀 개발자분들에게 전체 코드리뷰를 진행하여 피드백 및 개선사항을 반영하여 보다 완성도 있는 제품을 만들어 릴리즈 할 수 있었습니다.

작업하고 느낀점

해당 작업 이후로도 간단히 다른직군( 특히BE) 를 조금씩 해보며 느낀건 디테일이나 핵심노하우는 떨어지기에 아에 해당직군을 대체하는 정도로 업무 퍼포먼스가 나오지는 못하지만 타직군 서포팅의 역활은 어느정도 충족할수 있지 않을까 라는 생각이 존재합니다. 실제로도 이러한 경험을 토대로 이후에 작업시 다른 직군의 리소스가 별로 없는경우에 사전에 어느정도 작업을 진행하고 있어 실 생산성 측면에서도 큰 이점을 얻을 수 있었습니다.

다만 아래와 같은 단점이 존재할 수 있습니다.

  • 타직군 작업을 해야하는 부담감
  • 최초 작업시 해야하는 온보딩 학습비용
  • 같은 리소스 투입시 FE작업만 하는것이 더 빠를수도 있는 트레이드오프

또한 근본적으로 드는 생각은 타직군의 업무역활에 대한 서포팅 부분에 있어서는 이점이 있을수 있으나 100%의 대체까지는 힘들지 않을까 라는 생각이 아직은 존재합니다. (ex. 프론트에서는 최적화, 유저경험등에 대한 디테일 기반지식, 백엔드에서는 대규모 트래픽등에 대한 디테일 기반지식등의 차이)

특히 FE↔BE간의 서포팅은 이정도가 팀내 생산성 측면에서 좋지 않을까 개인적으로는 생각해봅니다. 그러나 다른직군의 업무에 대한 학습비용 과 퀄리티 등을 생각해보면 해당 시간에 본인직군 업무를 더욱 생산성있고 디테일하게 하는게 더 좋을 수 있지 않을까 라는 반대쪽 생각도 게속 들고 있습니다. 즉 아직까지 정확한 답은 없어 보입니다.

FE직군의 BE 엔지니어링

  • 간단한 운영이슈
  • 트래픽이 크지 않은 기능 작업
  • 타 부서 api와의 커뮤니케이션까지 필요없는 정도의 작업

BE직군의 FE엔지니어링

  • 간단한 운영이슈, ui 깨짐 이슈
  • 주로 백오피스성 기능 및 페이지 개발

팀내에서 하고 있는것

이러한 타직군을 시도해보고싶은 경우 학습에 대한 비용을 최대한 줄이고 잘 안착할수 있도록 위에처럼 클로드 스킬을 통해 Frontend 직군에서의 비교 학습 노트들을 정리하여 리스트업해서 만들고 사내 슬랙봇으로 해당 기능들을 짧게 요약해 학습을 도와주는 형식 등 여러 방면으로 지원중에 있습니다. 아마 다음에는 이러한 팀에서 실제로 도입후 실제 작업한 후기를 공유로 찾아오도록 하겠습니다..!!