Zaply - AI 기반 Multi-SNS 콘텐츠 배포 및 관리 서비스

⭐️ 서비스 소개

여러 플랫폼을 운영하고 싶어하는 크리에이터들을 위한

AI 기반 Multi-SNS 콘텐츠 배포 및 관리 서비스 Zaply

⭐️ 팀 소개

팀명: 8분 카레

🌟 R&R 분배

분야	이름	포지션
기획	김민규	📈 PM, 서비스 기획 - 서비스 정책 확립, 비즈니스 모델 구축
기획	박주혜	📊 서비스 기획 - 유저 리서치, 와이어프레임 작성, UX writing
디자인	주신아	🔐 디자인 리드, ux/ui디자인, gui 디자인, 서비스 디자인
디자인	박민영	📢 프로젝트 매니징, ux/ui디자인, gui 디자인, 서비스 디자인
프론트엔드	이유승	🔦 프론트엔드 리드, 화면 UI 구현, 서버 연동
프론트엔드	성태현	📱 화면 UI 구현, 서버 연동
백엔드	정성호	🖥️ 백엔드 리드, DB 및 API 구축, 서버 배포
백엔드	염지은	💻 DB 및 API 구축, 서버 배포

🌟 기획

배경 및 필요성

1️⃣ 문제정의

어떤 분석을 통해 문제를 인식했나요?

크리에이터 경제가 빠르게 성장함에 따라, 유튜브·틱톡·인스타그램 등 다양한 SNS를 동시에 운영하는 1인 크리에이터들이 급증하고 있습니다.

자료 출처: 센터타워

그러나 각기 다른 플랫폼 포맷에 맞춰 콘텐츠를 반복 제작하고, 성과는 플랫폼별로 나뉘어 별도로 분석·관리해야 하는 비효율을 겪고 있다는 점이 리서치를 통해 확인되었습니다.

👉🏻 한줄 문제정의

멀티플랫폼(SNS) 운영 환경에서 콘텐츠 반복 제작, 분산된 성과 데이터, 비효율적인 주제 선정으로 인해 크리에이터가 콘텐츠 운영 전반에 과도한 시간과 노력을 소모하고 있습니다.

2️⃣ 문제인식

설정한 가설과 검증과정, 이를 바탕으로 문제를 어떻게 정의했나요?

재플리 팀은 다음과 같은 가설을 바탕으로, 다양한 카테고리의 크리에이터 6인과 심층 인터뷰를 진행하여 문제를 구체화했습니다.

• 가설1: 크리에이터는 동일한 주제를 플랫폼마다 따로 제작하는 데 시간과 노력을 많이 소비한다.
• 가설2: 플랫폼별로 흩어진 성과 데이터를 통합 분석하지 못하고 있다.
• 가설3: 콘텐츠 주제 기획 시 데이터 기반 인사이트가 부족해 시행착오가 잦다.

📌 인터뷰 종합 인사이트 요약

공통 Painpoint

• 시간 부족 및 반복 작업 피로감
• 다중 플랫폼 관리(업로드·댓글·분석)의 비효율
• 빠르게 변하는 트렌드와 알고리즘 대응 어려움

기능별 주요 painpoint

• 콘텐츠 재가공 (워딩/비율/톤 재편집)
• 인사이트 개별 확인의 번거로움
• 댓글 누락 및 반복 대응 스트레스
• 알고리즘 불확실성에 따른 노출 한계

🎯 결론

이처럼 단순 반복 작업, 흩어진 관리 환경, 복잡한 플랫폼 구조는 크리에이터의 지속 가능한 활동을 가로막는 병목이 되고 있습니다.

3️⃣ 해결 방안

문제를 어떻게 해결해 나가고자 하나요?

"하나의 콘텐츠로, 모든 플랫폼에."
zaply 슬로건

재플리는 이러한 문제를 해결하기 위해 다중 콘텐츠 발행 및 관리 AI 플랫폼을 개발하고 있습니다.

1. 콘텐츠 입력 및 변환

⇒ 하나의 콘텐츠를 입력하면, 모든 플랫폼에 맞춰 자동 변환됩니다.

콘텐츠 입력

• 텍스트·제목·이미지 업로드로 간편하게 시작
• 이미지 최대 10장 업로드 가능

AI 콘텐츠 변환

• 미리 설정된 프롬프트 기반으로 플랫폼 맞춤 변환
• 인스타그램, 스레드, 페이스북 등 형식 자동 최적화

플랫폼별 미리보기 및 수정

• 변환 결과를 한 눈에 확인
• 필요시 해시태그, 워딩, 이미지 순서 등을 수정 가능 (1차 MLP에서는 일부 구현)

2. 인사이트 통합 관리

⇒ 모든 플랫폼의 게시물 성과 데이터를 한눈에 확인하고 분석할 수 있습니다.

성과 데이터 수집 및 시각화

• 게시물별 반응을 테이블 형태로 일괄 제공

3. 댓글 목록 표시 및 관리

⇒ 모든 플랫폼들의 댓글을 하나의 창에서 모두 관리할 수 있습니다.

댓글 수집 및 정렬

• 주기적으로 댓글 수집
• 플랫폼, 작성시간, 상태별로 필터링 가능

댓글 응답 지원

• 유사 질문 자동 감지 및 OpenAI 기반 답변 제안
• 템플릿 선택 또는 직접 수정하여 응답 가능

즉시 게시 기능 제공

• 수정 완료된 댓글을 플랫폼 API로 바로 게시

시장분석

🔎 STEEP 분석 (거시환경 분석)

요소	내용
Social (사회적)	- 크리에이터 경제의 성장 → '1인 미디어', '디지털 노마드' 등 직업 다변화 현상 - Z세대, 밀레니얼 세대 중심으로 SNS 이용률/의존도 증가 - 짧고 빠른 콘텐츠 소비문화 확산 (숏폼, 릴스, 스토리 등)
Technological (기술적)	- GPT, DALL·E, Stable Diffusion 등 생성형 AI 기술 급속 발전 - 각 플랫폼 API 공개로 자동화 시스템 연동 용이 - 클라우드 기반의 콘텐츠 운영 구조 보편화 (예: AWS, Vercel 등) - 노코드/로우코드 툴로 자동화 구현 비용/시간 감소
Economic (경제적)	- 크리에이터들이 수익화에 적극적 → 툴 사용에 지출 의향 존재 - 구독형 SaaS 비즈니스 모델 대중화 - 글로벌 경기 불확실성 속에서도 콘텐츠 산업은 상대적으로 견조한 성장세
Environmental (환경적)	- ESG 흐름에 따라 디지털 탄소 발자국 이슈 부각 → 텍스트 기반 자동화가 친환경적 대안 될 수 있음 - 원격 근무/비대면 중심의 SaaS 서비스 이용 선호
Political (정치·법률적)	- 플랫폼 별 개인정보보호 정책 및 API 사용 조건 강화 (ex: Meta/Instagram Graph API 제약) - 각국의 AI 윤리 가이드라인 마련 → 투명성, 편향성 대응 필요 - 소셜미디어에 대한 법적 규제 논의 증가 (가짜뉴스, 중독 등)

🔥 경쟁사 분석

경쟁사	개요	주요기능	차별점∙한계점
Typefully	트위터용 쓰레드 작성∙예약 툴	글쓰기 지원, 예약, 협업	플랫폼 한정 (X에만 집중), AI 자동화 기능 제한
Hypefury	트위터 자동화 플랫폼	예약, 리트윗 자동화, 분석	예약 기능이 있지만 콘텐츠 생성력은 약함
FeedHive	멀티 플랫폼 SNS 자동화	콘텐츠 생성, 예약, 분석	인스타∙페이스북∙X 등 다중 지원, AI 생성 기능 존재. UI 복잡, 한국어∙아시아권 지원 부족
Make (ex-Integromat)	워크플로우 자동화 플랫폼	다양한 SaaS 연동 가능	노코드지만 일반 사용자가 사용하기 어려운 설정 복잡성
Zapier	범용 자동화 툴	다양한 트리거/액션 조합	콘텐츠 품질 개선보단 연동 중심, 직관적인 콘텐츠 생성 기능 부족

🧠 포지셔닝

✅ 차별화 포인트

AI 기반 콘텐츠 자동 변환 및 멀티 플랫폼 배포까지 자동화

• GPT 기반 텍스트 변환 + 플랫폼별 맞춤 프롬프트 세팅으로, 콘텐츠 제작부터 배포까지 한 번에
• Instagram, Threads, Facebook 등 주요 SNS API 연동 및 자동 배포 기능 제공

크리에이터 중심의 사용 흐름과 UX 설계

• 제목·텍스트·이미지 입력만으로 콘텐츠 완성 → AI 자동 변환 → 플랫폼별 미리보기·수정
• 댓글 통합 목록 관리 + AI 응답 제안 기능으로 피드백 대응 효율화
• 성과 통합 대시보드로 모든 콘텐츠의 조회수, 좋아요, 저장 등 주요 지표를 시각화 제공

🚀 기회요소

• 국내 시장에 크리에이터 전용 콘텐츠 자동화 SaaS가 본격 출시되지 않음
• 콘텐츠 운영에 필요한 다중 플랫폼 관리 수요는 급증, 반복 제작·배포의 피로도도 증가
• 실제 인터뷰 결과, 미러링 부담, 시간 부족, 인사이트 분석 어려움, 댓글 대응의 비효율성 등이 공통 문제로 도출됨 → 재플리는 이 문제를 단일 플랫폼에서 자동화 + 통합 관리로 해결

IA 및 Userflowchart

1. IA (TO-BE)

2. 초기 User Flowchart

주요 화면 Lo-fi 와이어프레임

Lofi Wireframe

1. 연동

2. 콘텐츠 제작 및 배포

3. 인사이트 관리

4. 댓글 관리

UT 시나리오

사전 질문

• 간단한 자기소개 부탁드립니다.
• 평소 어떤 SNS를 가장 활발히 사용하시나요?
• 콘텐츠를 여러 채널에 업로드해본 경험이 있으신가요?
• 콘텐츠 기획/작성/업로드 과정에서 가장 어려운 단계는 무엇인가요?

테스트 과업 안내

📍과업1 - 콘텐츠 생성

화면 기능

• 콘텐츠 제목, 본문 작성
• 이미지 업로드 후 플랫폼별 콘텐츠 자동 미리보기
• 플랫폼별 문구·톤 변환 확인 및 직접 수정

질문

• 입력 필드 및 구성은 이해하기 쉬웠나요?
• 자동 생성된 문구는 플랫폼 성격에 잘 맞았나요?
• 수정이 필요한 부분은 손쉽게 바꿀 수 있었나요?

📍과업2 - 콘텐츠 배포

화면 기능

• 배포 대상 플랫폼 선택
• 즉시/예약 옵션 설정
• '배포하기' 버튼 클릭

질문

• 어떤 플랫폼을 선택하고 싶은지 바로 알 수 있었나요?
• 업로드 방식(예약/즉시)의 구분은 명확했나요?
• 배포 직전 화면에서 혼란스러운 부분은 없었나요?

📍과업3 - 인사이트 통합 대시보드

화면 기능

• 콘텐츠별 조회수·좋아요 등 확인
• 플랫폼/기간별 필터

질문

• 어떤 정보가 가장 눈에 들어왔나요?
• 원하는 방식으로 필터를 조작할 수 있었나요?
• 데이터를 통해 어떤 인사이트를 얻을 수 있었나요?

UT 결과

콘텐츠 여러 플랫폼 업로드 불편한 점/답변

답변

• 그 플랫폼에 맞춘 감성으로 글을 작성하는 과정에서 고민이 많이 되었다.
• 플랫폼 성격에 맞도록 말투나 정보를 약간씩 바꿔서 입력해야하는 경우가 불편합니다.
• 적은 내용이 날아가서 다시 동일한 내용을 작성해야하는 것..
• 콘텐츠에 대한 내용을 적는 것이 가장 어려웠습니다
• 로그인 여러번하는 번거로움
• 동일한 내용을 여러번 작성해서 올려야 하는 것
• 각 플랫폼마다 느낌이 달라서 다르게 작성하는게 불편
• 이미지 올리기?
• 귀찮다
• 같은 내용을 복붙하고 같은 이미지를 찾아서 붙여넣기 하는 과정이 번거롭다.

task 1 로그인 - 계정 연결

task 2 콘텐츠 생성, 예약

UT기반 GUI 개선사항

• 개선사항1 : '계정에서 불러오기' 태스크에 대해 해당 버튼 인지 못하는 경우 존재 → '불러오기' 버튼을 더 눈에 띄게 배치하는 GUI 로 수정 완료

  

• 개선사항2 : '업로드위치' 까지 스크롤 가지 못하고 인지 못하는 경우 존재 → 해당 step 스크롤 개선 및 불필요한 상단 공간 개선

• 개선사항3 : '한번에 예약','플랫폼별예약' 피커박스에 대한 인지적 오류 존재 → 체크박스 해제 시 플랫폼별 예약 사항 뜨도록 수정

• 개선사항4 : '플랫폼별 게시글 내용'의 차이 인지를 위한 스크롤 불필요 → 글 위계를 사진 보다 올림

task 3 인사이트

프로토타이핑 미스클릭: 섀브론 대신 바 영역 터치하여 접고펼치려고 함

그 외 정성 의견 및 UT 발견사항

• 게시물 하나하나에 대한 인사이트가 중요한지, 종합결과가 중요한지를 생각해보면 어느 플랫폼에서 가장 반응이 좋은지 어디서 가장 저조한지 비교하거나 - 혹은, 이전 콘텐츠보다 성과가 이만큼 좋다 하는 꺾은 선 그래프 같은거, 요약해서 알 수 있는 정보가 있으면 좋을듯
• 플랫폼별 차이를 진입화면에서 볼 수 있는 방법이 없는지?
• 진입화면에서 정보가 오밀조밀 들어가 있어서 압축해서 넣다보니 복잡해진듯, 리스트도 함축해서 들어가있어서 조금 여유 두는게 좋지 않을지
• 상세화면의 조회수 등의 리스트들 - 텍스트로만 들어가있어서 읽어야만 알 수 있어서 아이콘 달아주면 좋을듯
• 플랫폼별 차이를 알기가 어려워서 각각의 플랫폼 고유색상(서비스컬러)를 반영해주거나 메뉴바 구분이 좀 더 잘 되게 하거나 아이콘이 들어가거나 .. 디자인이 명확하게 나와야 할듯.
• 진입화면: 전체적으로 색상이 연하게 느껴진다. 파란색,회색 둘 다

task 4 댓글관리

그 외 정성 의견 및 UT 발견사항

• 해당 플랫폼에 대한 댓글같지가 않은 느낌, 시각적으로 멀리 떨어져 있어서. 해당플랫폼별 게시글내용 같은 경우는 이미 썸네일만 보더라도 알 것 같아서 숨겨져있어도 좋을 것 같다. 혹은 글을 좀 더 숨기기
• 댓글바로가기 = 해당 플랫폼에서 유도하려는 기능이 아니면 맨 아래에 있는게 좋을듯 댓글관리 위에 있는 것 보다
• 하단 CTA가 고정되어있어서 영역을 가리는 것 + 이미 나와있는 것 = 오히려 이해하기 어려운 느낌
• 어려웠다. 긍정적/부정적 기준에 대한 이해가 모호함. 전체 댓글 보기 있어야 할듯.
• 진입화면에서 3개까지만 제한을 두지 말고 오늘,어제 정도는 개수 제한 더 늘려도 좋지않을지?
• 디바이더 어플별 차이가 잘 안느껴짐
• 댓글바로가기 밑에 나오는게 좋을듯.
• 같이 묶어서 대답할만한거 한번에 대답하는거 좋은듯
• 정보의 양이 너무 많음, 점 더 여백을 많이 주어야 좋을듯
• 프라이머리 컬러가 잘 안 보임
• 댓글을 눌러야 겠다는 생각이 안듦
• 문의,긍정,부정 댓글 간격띄우기
• 댓글 숨기기 후 댓글 복구하기가 어려웠음
• 부정 탭 들어가면 댓글 숨기기 누르기 전 오른쪽을 먼저 클릭함
• 비슷한 댓글 찾는 것에 초기 어려움 있었음
• AI 답변 생성 기대감 및 이해도: 잘 생성이 되고 좋았음. 그런데 AI 사용하는 부분이 많은데 이게 잘 작동이 될지가 의문
• 부정 탭을 바로 인지하지 못함
• 댓글 숨기기 시 오른쪽 버튼을 먼저 클릭함 (수민과 공통된 액션)
• 부정 탭을 바로 찾지 못함
• 비슷한 답글에 대한 일괄 답변을 하나 이상 눌러야 된다는 설명이 있으면 좋을 듯함
• 숨기기는 좋았으나 복구하는 버튼은 선택할 수 있다라는 것을 인지하기 어려울 수 있음 복구 버튼이 앞에 있는게 특이함

테스트 후 설문

성과 지표

1. 1차 인스타그램 광고 성과

광고성과 1	광고성과 2	광고성과 3

구분	콘텐츠 변환	인사이트 관리	댓글 관리	총합
조회	628	646	380	1,624
웹사이트 방문	27 (4.29%)	8 (1.23%)	5 (1.31%)	40 (2.5%)
DB 남기기	2 (7.4%)	0 (0%)	0 (0%)	2 (2.5%)

예비 고객 DB 수집

🌟 디자인

📃 컨셉 무드보드

📃 디자인 시스템

Typography System

Color System

ICON System

Grid & Spacing

📃 브랜딩

• Branding Experience

📃 랜딩페이지

• Landing Page

URL: https://zaply-landing.vercel.app

📃 GUI 화면 디자인

• 로그인/회원가입

• 1. (HOME)업로드

• 1-1) HOME>새콘텐츠생성

• 2. 인사이트

• 3. 댓글 관리

• 4. 마이페이지

• 4-1) 마이페이지>계정 연동

📃 프로젝트 포트폴리오 & 포스터

Behance 링크 https://www.behance.net/gallery/226676895/Zaply-AI-SNS-

포스터

🌟 개발

👬 Member

정성호	염지은	성태현	이유승
@SeongHo5356	@yumzen	@dvp-tae	@youth-o

FrontEnd

Tech Stack

Technologies Used

Stack	Reason
Next.js 14	React 기반 프레임워크로, 서버 컴포넌트와 서버 액션을 통해 클라이언트 측 JavaScript 양을 줄여 성능 최적화. App Router를 통한 파일 시스템 기반 라우팅, SSR/SSG 기본 지원, 컴포넌트 재사용성, 증분적 정적 재생성(ISR), 이미지 최적화, Vercel과의 간편한 통합 배포 환경을 제공하여 선정.
TypeScript	정적 타입 시스템을 통한 코드 안정성 향상 및 협업 용이성. 개발 단계에서 오류 사전 발견으로 런타임 에러 방지, 코드 힌트와 자동 완성 기능으로 생산성 향상.
Zustand	간결하고 직관적인 상태 관리 방식과 최소한의 보일러플레이트로 높은 유연성 제공. 상태 변경 시에만 컴포넌트를 렌더링하여 불필요한 렌더링 최소화와 성능 최적화.
PNPM	효율적인 node_modules 관리로 디스크 공간 절약 및 설치 속도 향상을 제공하는 패키지 매니저.
TailwindCSS	HTML과 CSS 파일을 별도로 관리할 필요 없이 개발 가능한 편의성. 클래스명 고민 시간 절약으로 빠른 개발과 일관된 디자인 시스템 구축 가능.
Shadcn/UI	TailwindCSS와의 원활한 통합으로 일관된 스타일링. 높은 확장성과 유연한 커스터마이징 기능을 통해 프로젝트 요구사항에 맞는 UI 효율적 구현.
TanStack Query	효율적인 데이터 페칭 및 관리 시스템. 데이터 캐싱 기능으로 불필요한 요청 감소, 성능 최적화 및 네트워크 비용 절감 가능.
Vercel	깃 저장소와 통합된 자동 감지 및 자동 배포 시스템. 코드 변경 사항 푸시 시 자동 배포로 효율적이고 간편한 웹사이트 배포 환경 제공.
PWA	웹 기술 기반의 크로스 플랫폼 지원. 앱 스토어 없이 홈 화면에 추가 가능한 높은 접근성과 편의성. 개발 비용 절감 및 빠른 배포 가능.

Naming Rules

• 폴더명: camelCase
• 파일명: PascalCase
• 타입, 유틸함수 등: camelCase
• 상수: UPPER_CASE

Commit Convension

커밋 메시지는 태그: 커밋 메시지 형식으로 작성합니다.

예시: git commit -m "feat: 카카오 로그인 기능 구현"

태그명	설명
feat	새로운 기능 개발
fix	코드 및 버그 수정
style	CSS 스타일링 및 퍼블리싱 작업
docs	문서 작업(README.md 등)
test	배포 테스트, QA 테스팅 관련
chore	패키지 매니저 수정, 그 외 기타 수정
build	빌드 시스템 또는 외부 종속성에 영향을 미치는 변경 사항
refactor	코드 리팩토링
rename	폴더 혹은 파일명 변경
remove	파일 삭제

---

BackEnd

📝 Technology Stack

Category	Technology
Language	Java 21
Framework	Spring Boot 3.3.10
Databases	Postgresql, Redis
Authentication	JWT, Spring Security, OAuth2.0
Development Tools	Lombok
API Documentation	Swagger UI (SpringDoc)
Storage	AWS S3, Naver Object Storage
Infrastructure	Terraform, NCP Server, HashiCorp Vault
Build Tools	Gradle
Monitoring	Prometheus, Grafana, Loki, Promtail

📅 ERD

API 명세서

http://zapply.site/swagger-ui/index.html

🔨 Project Architecture

⭐️ 기술스택/선정이유

1️⃣ Java 21

• Java 21은 최신 언어 기능(예: 패턴 매칭, 레코드, 가상 스레드 등)을 제공하여 코드의 가독성과 유지보수성을 높이며, 개발 생산성을 향상시킵니다.
• 최신 버전의 자바는 성능 최적화와 효율적인 메모리 관리 기능이 개선되어, 대규모 애플리케이션에서도 안정적이고 빠른 실행이 가능합니다.
• 장기 지원 버전이므로, 앞으로의 유지보수와 안정성 측면에서 신뢰할 수 있는 기반을 제공합니다.

2️⃣ SpringBoot 3.3.10

• 최신 버전의 Spring Boot는 스프링 프레임워크 및 관련 라이브러리와의 호환성이 뛰어나며, 보안 패치와 최신 기능들이 반영되어 있습니다.
• 자동 설정 기능과 다양한 내장 기능 덕분에 복잡한 설정 없이도 빠르게 애플리케이션을 개발할 수 있으며, 마이크로서비스 아키텍처 구축에 유리합니다.
• RESTful API, 데이터 액세스, 보안 등의 기능이 통합되어 있어 개발자가 비즈니스 로직에 집중할 수 있는 환경을 제공합니다.

3️⃣ SpringData JPA

• Spring Data JPA는 데이터베이스와의 인터랙션을 단순화하고, 불필요한 보일러플레이트 코드를 줄여 개발 효율성을 높여줍니다.

5️⃣ PostgreSQL

• PostgreSQL는 복잡한 쿼리 처리와 대규모 데이터셋 관리에 강점을 가집니다.

6️⃣ Docker compose

• Docker Compose는 여러 컨테이너를 손쉽게 구성하고 관리할 수 있도록 도와주어, 개발 및 배포 과정에서 환경 설정을 간소화합니다.

7️⃣ NCP(CLOVA studio, Server, Object Storage)

• NCP(네이버 클라우드 플랫폼)는 CLOVA Studio 및 서버 인프라 호스팅에 활용되어, 안정적이고 안전한 클라우드 환경을 제공함으로써 프로젝트의 운영 효율성을 높입니다.

8️⃣ Hashicorp Vault

• 민감한 데이터(플랫폼 별 사용자 accessToken 등)를 안전하게 관리하고, 보안성을 강화할 수 있습니다.

9️⃣ Terraform

• 인프라를 코드로 관리할 수 있게 해 주어, 반복 가능하고 일관된 인프라 구축 및 유지보수가 가능합니다.

9️⃣ Promtail, Loki, Prometheus, Grafana

• Promtail → Loki: 애플리케이션·시스템 로그를 수집·라벨링해 Loki에 전송 → 대량 로그를 효율적으로 인덱싱·검색합니다.
• Prometheus: Pull 방식으로 API 응답 시간·CPU·메모리 같은 시계열 메트릭을 스크랩·저장합니다.
• Grafana: Loki·Prometheus 데이터를 대시보드로 시각화합니다.

🔟 K6

• JavaScript로 실제 사용자 흐름(로그인→API 호출→스케줄링)을 스크립트화해 REST 성능을 측정합니다.
• vus, stages, thresholds 등 옵션으로 동시 사용자 수·스파이크·지속 테스트를 커스터마이징하면서 테스트합니다.
• 콘솔·JSON 출력으로 응답 시간·처리량·에러율 메트릭을 수집하고 Grafana에 연동해 결과 시각화합니다.

💬 Convention

commit convention
#이슈번호 conventionType: 구현한 내용

convention Type

convention type	description
feat	새로운 기능 구현
chore	부수적인 코드 수정 및 기타 변경사항
docs	문서 추가 및 수정, 삭제
fix	버그 수정
test	테스트 코드 추가 및 수정, 삭제
refactor	코드 리팩토링

🪵 Branch

• 컨벤션명/#이슈번호-작업내용
• pull request를 통해 develop branch에 merge 후, branch delete
• 부득이하게 develop branch에 직접 commit 해야 할 경우, !hotfix: 사용

📁 Directory

src/
├── main/
│   ├── domain/
│   │   ├── entity/
│   │   ├── controller/
│   │   ├── service/
│   │   ├── repository/
│   │   └── dto/
            ├── request/
            └── response/
│   ├── global/
│   │   ├── apiPayload/
│   │   ├── config/
│   │   ├── security/
		 

📈 부하테스트

각 플랫폼(Instagram, Facebook, Threads) API에는 계정/시간 당 발행 가능한 게시물 수에 제한이 있어, 부하 테스트에는 제약이 존재합니다. 이에 따라 저희는 즉시 발행이 아닌 "예약 발행" API를 활용한 부하 시뮬레이션 방식을 구성하였습니다.

시나리오 ① 10명이 1초 동안 최대한의 요청을 보낸다.	시나리오 ② 2000명이 1초 동안 최대한의 요청을 보낸다.
✅ 총 120개의 요청이 문제없이 처리됨 - 평균 요청 처리 시간 : 82.09 ms - 최소 요청 처리 시간 : 22.52ms - 최대 요청 처리 시간 : 164.64ms	✅ 총 4002개의 요청이 문제없이 처리됨 - 평균 요청 처리 시간 : 7.74s - 최소 요청 처리 시간 : 21.9s - 최대 요청 처리 시간 : 18.28s - 95th 퍼센타일 : 14.95s

시나리오 ③ 사용자 수 변동 시나리오	시나리오 ④ 응답 시간이 5초 이내인 최대 요청 수 파악
0초 ~ 2초 : 50명, 2초 ~ 12초 : 300명, 12초 ~ 17초 : 1000명, 17초 ~ 18초 : 500명	5초가 지날 경우 사용자 이탈이 늘어날 것이라고 판단하여 1초 동안 1000명의 사용자가 요청을 보내 요청 처리 시간이 5초 이내인 요청 개수를 파악
✅ 총 3789개의 요청이 문제없이 처리됨 - 평균 요청 처리 시간 : 1.94s - 최소 요청 처리 시간 : 20.53ms - 최대 요청 처리 시간 : 7.88s	✅ 총 2002개의 요청이 시간 내 처리됨

테스트 결과 분석

• 현재 시스템은 동시 약 1,000건 수준까지는 안정적으로 요청을 처리할 수 있는 것으로 보입니다. 시나리오 ③처럼 사용자 수가 점차 증가하는 상황에서도 평균 응답 시간은 1.94초, 최대 응답 시간은 7.88초로, 대부분의 요청이 정상적으로 처리되었습니다.
• 하지만 시나리오 ②처럼 2,000명의 동시 요청이 들어오면 평균 응답 시간이 7.74초, 최대 18.28초까지 증가하면서 응답 지연이 발생하였습니다. 이 결과는 대규모 트래픽에 대한 성능 한계가 있음을 보여주며, 추후 이를 개선할 필요가 있습니다.
• 시나리오 ④에서는 1000명의 사용자가 동시에 요청을 보낸 경우, 총 2,002건의 요청이 5초 이내에 처리되었습니다. 이는 현재 시스템이 실시간 대응보다는 예약 처리에 더 적합한 구조임을 보여줍니다.
• 일반적으로 사용자 이탈이 늘기 시작하는 5초 이내 응답을 기준으로 예상 접속자 수 약 1,000명 정도에 대해서는 충분히 안정적인 성능을 제공할 수 있다고 판단됩니다.

💫 Zaply | Create Once, Spread With Zaply