이미지/태그/설명을 선택적으로 입력하면 네이버 OGQ마켓 규격에 맞는 24종 스티커 세트를 자동으로 생성해주는 웹입니다. product URL: https://ogq.vercel.app/
Frontend
Backend
# 프론트엔드
npm install
npm run dev # 개발 서버 실행
백엔드는 별도 서버로 구동되며, 프론트엔드는 /api/generate-set 엔드포인트를 통해 생성 작업을 요청하고 결과를 SSE로 수신합니다.
본 프로젝트에는 아래의 오픈소스 모델을 활용하였습니다.
torch (BSD): PyTorch 딥러닝 연산 및 GPU 가속diffusers (Apache 2.0): SDXL 및 IP-Adapter 파이프라인 제어, DPMSolver 스케줄링transformers (Apache 2.0): BLIP 캡셔닝 모델 및 SDXL 텍스트 인코더 실행compel (MIT): SDXL 듀얼 텍스트 인코더 프롬프트 가중치/임베딩 정밀 제어rembg (MIT): ISNet 기반 캐릭터 배경 제거FastAPI (MIT): 비동기 이모티콘 생성 API 백엔드 서버 구축uvicorn (BSD): ASGI 웹 서버 실행pyngrok (MIT): 로컬 서버 개발용 ngrok 연동Pillow (HPND): 이미지 처리 및 전/후처리python-dotenv (BSD): 환경 변수 관리파이썬 버전: python 3.13.12
os, gc, io, json, time, uuid, base64, logging, traceback, threading, contextlib
기존의 BLIP이 원본 이미지의 특징을 제대로 잡아내지 못해 캐릭터의 특징이 이모티콘에 제대로 담기지 않는 이슈 발생(눈 색깔 변경/머리 색깔 변경 등) -> 기존의 BLIP모델 대신 WD14 Tagger를 사용하여 캡션을 생성
set_ip_adapter_scale에 값을 실수 형태로 넣으니 참조이미지의 구도, 체형 등 이모티콘에 참조하지 말아야할 특징까지 참조됨 -> _set_ip_scale함수를 만들어{"up": {"block_0": scale}}의 딕셔너리 형식으로 ip_scale를 조정해 얼굴과 옷 등 필요한 특징만 가져옴
기존에는 참조 이미지를 IP-Adapter에 직접 입력하여 캐릭터의 특징을 유지하였다. 하지만 IP-Adapter의 영향이 너무 강한 경우 원본 이미지의 얼굴이나 의상뿐만 아니라 자세, 체형, 구도까지 그대로 따라가는 문제 발생
-> IP-Adapter의 적용 강도를 조절하고, 참조 이미지에서 유지해야 할 특징은 WD14 Tagger와 Character Profile을 통해 텍스트 프롬프트로도 함께 전달하도록 변경
-> 캐릭터의 특징과 새로운 포즈 사이의 균형을 맞출 수 있지만, IP-Adapter의 강도를 너무 낮게 설정하면 캐릭터의 특징이 제대로 유지되지 않고, 너무 높게 설정하면 기존과 같이 포즈나 구도를 과하게 따라갈 수 있어 적절한 값을 설정해야 함
기존에는 참조 이미지를 모델 입력 크기에 맞추기 위해 정해진 크기로 바로 resize하였다. 이 과정에서 가로세로 비율이 다른 이미지의 경우 캐릭터의 얼굴이나 체형이 눌리거나 늘어나는 문제 발생
-> 원본 이미지의 비율을 유지한 상태로 정사각형 영역에 padding을 추가한 후 모델 입력 크기로 resize하도록 전처리 방식을 변경
기존에는 각 이모티콘마다 Text-to-Image 방식으로 완전히 새로운 이미지를 생성하였다. 이로 인해 캐릭터의 기본적인 형태를 일정하게 유지하기 어려운 문제 발생
-> 최초 한 번만 Text-to-Image 방식으로 기준 캐릭터를 생성하고, 이후 감정과 행동별 이모티콘은 해당 기준 이미지를 이용한 Image-to-Image 방식으로 생성하도록 변경하였다.
-> 얼굴, 머리, 의상 등의 기본적인 디자인을 유지하기 쉬워졌지만, 기준 이미지의 형태에 영향을 받기 때문에 Image-to-Image의 strength 값이 너무 낮으면 새로운 포즈나 큰 동작을 생성하기 어려운 단점 발생
기존에는 하나의 프롬프트에 대해 이미지 한 장만 생성하고 결과를 바로 사용하였다. 따라서 손이나 얼굴이 깨지거나 캐릭터 특징이 크게 달라진 이미지가 생성되어도 그대로 결과에 포함되는 문제 발생
-> 같은 프롬프트에 대해 여러 개의 후보 이미지를 생성한 후 CLIP을 이용해 참조 이미지 및 기준 이미지와의 유사도를 계산하고, 가장 높은 점수를 받은 이미지를 선택하도록 변경
-> 품질이 낮거나 캐릭터 특징이 크게 달라진 결과가 선택될 가능성을 줄일 수 있지만, CLIP은 이미지의 전체적인 의미와 특징을 비교하기 때문에 손가락 오류나 작은 그림 깨짐과 같은 세부적인 품질 문제까지 정확하게 평가하기는 어렵고, 한 장의 이모티콘을 만드는데 여러 개의 이미지를 생성하기때문에 속도가 느려짐
기존에는 LoRA의 적용 강도를 높게 설정하여 이모티콘 및 2D 캐릭터 스타일을 강하게 적용하였다. 이 경우 LoRA가 학습한 스타일이 참조 캐릭터의 특징보다 강하게 나타나 서로 다른 캐릭터가 비슷한 형태로 생성되는 문제 발생
-> LoRA의 가중치를 기존보다 낮추고 IP-Adapter와 Character Profile을 함께 사용하여 캐릭터 특징과 이모티콘 스타일을 동시에 유지하도록 조정
기존에는 생성된 이미지를 그대로 rembg에 입력하여 배경을 제거했는데, 이 과정에서 캐릭터의 검은 외곽선이나 머리카락 끝부분처럼 배경과 경계가 복잡한 영역이 함께 제거되거나 깨지는 문제 발생
-> 배경 제거 후 캐릭터가 존재하는 영역을 다시 계산하고, 비율을 유지한 상태로 크기를 조절하여 740×640 크기의 투명 캔버스 중앙에 배치하도록 후처리 과정을 추가
기준 이미지를 image2image 생성의 입력으로 사용하더라도 strength값을 높이면 캐릭터의 자세를 크게 변경할 수 있지만, 동시에 얼굴이나 의상 등 캐릭터의 고유 특징까지 변형되는 문제 발생
-> OpenPose 기반 ControlNet을 추가하여 캐리거의 외형과 새로운 자세를 별도의 입력으로 제어하도록 하였다.
기존에는 감정별 프롬프트에 "웃눈 표정", "화난 표정", "손을 흔드는 모습"과 같은 단어 설명만 전달하였다. 그러나 이만으로는 기준 이미지의 자세를 그대로 유지하거나 원하는 동작이 제대로 만들어지지 않는 문제 발생
-> llm을 이용하여 프롬프트를 구체화하여 보다 원하는 동작을 직접적으로 제어할 수 있도록 하였다.
기존에는 사용자가 업로드한 원본 이미지를 그대로 참조이미지로 사용해 이모티콘을 생성하였는데, 이 때문에 원본 이미지의 그림체, 자세, 구도 등의 영향이 모든 이미지에 적용되는 문제가 발생하였다.
-> 사용자가 업로드한 원본 이미지로부터 하나의 기준 이미지(이모티콘 스타일)를 생성하고, 사용자에게 승인받는 방법으로 기준이미지가 제대로 생성되지 않았을 경우(퀄리티가 너무 낮거나 특징이 사라진 경우)모든 이모티콘이 망가지는 경우를 방지하였다.
기존 로컬에서 서버를 돌리는 방식은 컴퓨터를 항상 켜둘수도 없고, 하드웨어의 한계로 사진 한 장을 생성하는데 20분씩 걸리는 문제가 있었다. -> 이를 해결하기 위해 runpod에서 a40 gpu를 대여하여 그곳에서 서버를 돌려 cpu_offload로 인한 병목현상을 제거하였다.
기존에 서버에 저장되어있는 테마 프롬프트는 유저가 원하는 테마를 완전히 충족시켜줄 수 없다. -> 이를 해결하기 위하여 각 테마(셀)마다 유저가 선택적으로 프롬프트를 작성할 수 있게 변경하였다. 이를 입력하면 기존 서버의 테마 프롬프트와 같이 사용하되, RANK를 유저의 프롬프트가 더 높게 하여 유저의 프롬프트가 더 적극적으로 반영되도록 구현하였다.
기존의 프롬프트는 기준이미지와 테마 프롬프트 모두에서 자세, 구도, 외형 특징 구분 없이 모두 RANK에 따라 중요도를 매겨 최종 프롬프트로 변형되었다. 이로 인해 모든 이미지들의 구도가 기준이미지를 따라가는 경향이 생겼다 -> 이를 해결하기 위하여 유저 프롬프트와 테마 프롬프트에서 구도, 표정 등의 정보를 참조하고(중요도: 유저 프롬프트 > 테마 프롬프트) 외형 특정등의 정보는 기준 이미지
기존의 시스템에서는 사용자에게 개인정보 처리방침 등에 동의하게 하지 않는 등 저작권 등의 문제에 휘말릴 우려가 있었다. -> 서비스 이용약관 및 개인정보 처리방침 동의를 넣어 사용자가 동의해야 이모티콘 생성할 수 있도록 하였다.
기존의 서버의 요청처리 순서는 먼저 들어온 요청을 끝낸 후 다음 요청으로 넘어가는 방식이었는데, 이 경우 첫 사용자의 모든 사진 생성이 끝날 때까지 그 뒤 사용자들은 한 장도 생성하지 못할 수 있다는 단점이 있다. -> 한 요청이 끝날때까지 기다리는게 아닌 모든 요청들을 돌아가며 한 장씩 처리하여 한 장을 생성하는데 조금 더 오래 걸리더라도 사용자가 아예 진행이 되고있지 않다라는 생각이 들지 않도록 하였다.
기존에 만들었던 데이터는 새로고침하거나 하면 저장되지 않고 만든 후 다운받지 않았다면 그대로 날아간다는 단점이 있다. -> 계정에 만들었던 이모티콘들을 저장할 수 있도록 하여 후에 불러올 수 있게 하였다.
현재 전체 파이프라인
원본 이미지 -> WD14 Tagger를 이용한 캐릭터 프로필 생성 -> IP-Adapter + 캐릭터 프로필 + LoRA를 이용한 기준 이미지 생성 -> 생성된 기준 이미지를 WD14로 다시 분석하여 기준이미지 프로필 생성 -> 사용자가 기준이미지를 확인하고 승인/재생성 -> LLM이 감정별 상세 프롬프트와 OpenPose 관절 좌표 생성 -> 기준 이미지를 img2img의 초기 이미지로 사용 -> OpenPose ControlNet으로 새로운 자세 적용 -> LoRA를 이용하여 이모티콘 스타일 유지 -> 여러 후보이미지를 생성 -> CLIP으로 기준이미지 및 프롬프트와의 유사도 평가 후 가장 높은 점수의 이미지 선택 -> 배경 제거 -> 후처리 후 최종 이모티콘 세트 출력
현재 tensor.art에서 이모티콘 스타일을 입힐 LoRA를 학습시키는 중 + 파이프라인을 좀 더 간결하게 하는 등 수정을 진행 중
backend - frontend 통신 방식을 http sse방식으로 변경하. 이제 frontend에서 계속해서 jobid로 get요청을 보내는 방식이 아닌 sse방식으로 전환
이미지/태그/설명을 선택적으로 입력하면 네이버 OGQ마켓 규격에 맞는 24종 스티커 세트를 자동으로 생성해주는 웹입니다. product URL: https://ogq.vercel.app/
Frontend
Backend
# 프론트엔드
npm install
npm run dev # 개발 서버 실행
백엔드는 별도 서버로 구동되며, 프론트엔드는 /api/generate-set 엔드포인트를 통해 생성 작업을 요청하고 결과를 SSE로 수신합니다.
본 프로젝트에는 아래의 오픈소스 모델을 활용하였습니다.
torch (BSD): PyTorch 딥러닝 연산 및 GPU 가속diffusers (Apache 2.0): SDXL 및 IP-Adapter 파이프라인 제어, DPMSolver 스케줄링transformers (Apache 2.0): BLIP 캡셔닝 모델 및 SDXL 텍스트 인코더 실행compel (MIT): SDXL 듀얼 텍스트 인코더 프롬프트 가중치/임베딩 정밀 제어rembg (MIT): ISNet 기반 캐릭터 배경 제거FastAPI (MIT): 비동기 이모티콘 생성 API 백엔드 서버 구축uvicorn (BSD): ASGI 웹 서버 실행pyngrok (MIT): 로컬 서버 개발용 ngrok 연동Pillow (HPND): 이미지 처리 및 전/후처리python-dotenv (BSD): 환경 변수 관리파이썬 버전: python 3.13.12
os, gc, io, json, time, uuid, base64, logging, traceback, threading, contextlib
기존의 BLIP이 원본 이미지의 특징을 제대로 잡아내지 못해 캐릭터의 특징이 이모티콘에 제대로 담기지 않는 이슈 발생(눈 색깔 변경/머리 색깔 변경 등) -> 기존의 BLIP모델 대신 WD14 Tagger를 사용하여 캡션을 생성
set_ip_adapter_scale에 값을 실수 형태로 넣으니 참조이미지의 구도, 체형 등 이모티콘에 참조하지 말아야할 특징까지 참조됨 -> _set_ip_scale함수를 만들어{"up": {"block_0": scale}}의 딕셔너리 형식으로 ip_scale를 조정해 얼굴과 옷 등 필요한 특징만 가져옴
기존에는 참조 이미지를 IP-Adapter에 직접 입력하여 캐릭터의 특징을 유지하였다. 하지만 IP-Adapter의 영향이 너무 강한 경우 원본 이미지의 얼굴이나 의상뿐만 아니라 자세, 체형, 구도까지 그대로 따라가는 문제 발생
-> IP-Adapter의 적용 강도를 조절하고, 참조 이미지에서 유지해야 할 특징은 WD14 Tagger와 Character Profile을 통해 텍스트 프롬프트로도 함께 전달하도록 변경
-> 캐릭터의 특징과 새로운 포즈 사이의 균형을 맞출 수 있지만, IP-Adapter의 강도를 너무 낮게 설정하면 캐릭터의 특징이 제대로 유지되지 않고, 너무 높게 설정하면 기존과 같이 포즈나 구도를 과하게 따라갈 수 있어 적절한 값을 설정해야 함
기존에는 참조 이미지를 모델 입력 크기에 맞추기 위해 정해진 크기로 바로 resize하였다. 이 과정에서 가로세로 비율이 다른 이미지의 경우 캐릭터의 얼굴이나 체형이 눌리거나 늘어나는 문제 발생
-> 원본 이미지의 비율을 유지한 상태로 정사각형 영역에 padding을 추가한 후 모델 입력 크기로 resize하도록 전처리 방식을 변경
기존에는 각 이모티콘마다 Text-to-Image 방식으로 완전히 새로운 이미지를 생성하였다. 이로 인해 캐릭터의 기본적인 형태를 일정하게 유지하기 어려운 문제 발생
-> 최초 한 번만 Text-to-Image 방식으로 기준 캐릭터를 생성하고, 이후 감정과 행동별 이모티콘은 해당 기준 이미지를 이용한 Image-to-Image 방식으로 생성하도록 변경하였다.
-> 얼굴, 머리, 의상 등의 기본적인 디자인을 유지하기 쉬워졌지만, 기준 이미지의 형태에 영향을 받기 때문에 Image-to-Image의 strength 값이 너무 낮으면 새로운 포즈나 큰 동작을 생성하기 어려운 단점 발생
기존에는 하나의 프롬프트에 대해 이미지 한 장만 생성하고 결과를 바로 사용하였다. 따라서 손이나 얼굴이 깨지거나 캐릭터 특징이 크게 달라진 이미지가 생성되어도 그대로 결과에 포함되는 문제 발생
-> 같은 프롬프트에 대해 여러 개의 후보 이미지를 생성한 후 CLIP을 이용해 참조 이미지 및 기준 이미지와의 유사도를 계산하고, 가장 높은 점수를 받은 이미지를 선택하도록 변경
-> 품질이 낮거나 캐릭터 특징이 크게 달라진 결과가 선택될 가능성을 줄일 수 있지만, CLIP은 이미지의 전체적인 의미와 특징을 비교하기 때문에 손가락 오류나 작은 그림 깨짐과 같은 세부적인 품질 문제까지 정확하게 평가하기는 어렵고, 한 장의 이모티콘을 만드는데 여러 개의 이미지를 생성하기때문에 속도가 느려짐
기존에는 LoRA의 적용 강도를 높게 설정하여 이모티콘 및 2D 캐릭터 스타일을 강하게 적용하였다. 이 경우 LoRA가 학습한 스타일이 참조 캐릭터의 특징보다 강하게 나타나 서로 다른 캐릭터가 비슷한 형태로 생성되는 문제 발생
-> LoRA의 가중치를 기존보다 낮추고 IP-Adapter와 Character Profile을 함께 사용하여 캐릭터 특징과 이모티콘 스타일을 동시에 유지하도록 조정
기존에는 생성된 이미지를 그대로 rembg에 입력하여 배경을 제거했는데, 이 과정에서 캐릭터의 검은 외곽선이나 머리카락 끝부분처럼 배경과 경계가 복잡한 영역이 함께 제거되거나 깨지는 문제 발생
-> 배경 제거 후 캐릭터가 존재하는 영역을 다시 계산하고, 비율을 유지한 상태로 크기를 조절하여 740×640 크기의 투명 캔버스 중앙에 배치하도록 후처리 과정을 추가
기준 이미지를 image2image 생성의 입력으로 사용하더라도 strength값을 높이면 캐릭터의 자세를 크게 변경할 수 있지만, 동시에 얼굴이나 의상 등 캐릭터의 고유 특징까지 변형되는 문제 발생
-> OpenPose 기반 ControlNet을 추가하여 캐리거의 외형과 새로운 자세를 별도의 입력으로 제어하도록 하였다.
기존에는 감정별 프롬프트에 "웃눈 표정", "화난 표정", "손을 흔드는 모습"과 같은 단어 설명만 전달하였다. 그러나 이만으로는 기준 이미지의 자세를 그대로 유지하거나 원하는 동작이 제대로 만들어지지 않는 문제 발생
-> llm을 이용하여 프롬프트를 구체화하여 보다 원하는 동작을 직접적으로 제어할 수 있도록 하였다.
기존에는 사용자가 업로드한 원본 이미지를 그대로 참조이미지로 사용해 이모티콘을 생성하였는데, 이 때문에 원본 이미지의 그림체, 자세, 구도 등의 영향이 모든 이미지에 적용되는 문제가 발생하였다.
-> 사용자가 업로드한 원본 이미지로부터 하나의 기준 이미지(이모티콘 스타일)를 생성하고, 사용자에게 승인받는 방법으로 기준이미지가 제대로 생성되지 않았을 경우(퀄리티가 너무 낮거나 특징이 사라진 경우)모든 이모티콘이 망가지는 경우를 방지하였다.
기존 로컬에서 서버를 돌리는 방식은 컴퓨터를 항상 켜둘수도 없고, 하드웨어의 한계로 사진 한 장을 생성하는데 20분씩 걸리는 문제가 있었다. -> 이를 해결하기 위해 runpod에서 a40 gpu를 대여하여 그곳에서 서버를 돌려 cpu_offload로 인한 병목현상을 제거하였다.
기존에 서버에 저장되어있는 테마 프롬프트는 유저가 원하는 테마를 완전히 충족시켜줄 수 없다. -> 이를 해결하기 위하여 각 테마(셀)마다 유저가 선택적으로 프롬프트를 작성할 수 있게 변경하였다. 이를 입력하면 기존 서버의 테마 프롬프트와 같이 사용하되, RANK를 유저의 프롬프트가 더 높게 하여 유저의 프롬프트가 더 적극적으로 반영되도록 구현하였다.
기존의 프롬프트는 기준이미지와 테마 프롬프트 모두에서 자세, 구도, 외형 특징 구분 없이 모두 RANK에 따라 중요도를 매겨 최종 프롬프트로 변형되었다. 이로 인해 모든 이미지들의 구도가 기준이미지를 따라가는 경향이 생겼다 -> 이를 해결하기 위하여 유저 프롬프트와 테마 프롬프트에서 구도, 표정 등의 정보를 참조하고(중요도: 유저 프롬프트 > 테마 프롬프트) 외형 특정등의 정보는 기준 이미지
기존의 시스템에서는 사용자에게 개인정보 처리방침 등에 동의하게 하지 않는 등 저작권 등의 문제에 휘말릴 우려가 있었다. -> 서비스 이용약관 및 개인정보 처리방침 동의를 넣어 사용자가 동의해야 이모티콘 생성할 수 있도록 하였다.
기존의 서버의 요청처리 순서는 먼저 들어온 요청을 끝낸 후 다음 요청으로 넘어가는 방식이었는데, 이 경우 첫 사용자의 모든 사진 생성이 끝날 때까지 그 뒤 사용자들은 한 장도 생성하지 못할 수 있다는 단점이 있다. -> 한 요청이 끝날때까지 기다리는게 아닌 모든 요청들을 돌아가며 한 장씩 처리하여 한 장을 생성하는데 조금 더 오래 걸리더라도 사용자가 아예 진행이 되고있지 않다라는 생각이 들지 않도록 하였다.
기존에 만들었던 데이터는 새로고침하거나 하면 저장되지 않고 만든 후 다운받지 않았다면 그대로 날아간다는 단점이 있다. -> 계정에 만들었던 이모티콘들을 저장할 수 있도록 하여 후에 불러올 수 있게 하였다.
현재 전체 파이프라인
원본 이미지 -> WD14 Tagger를 이용한 캐릭터 프로필 생성 -> IP-Adapter + 캐릭터 프로필 + LoRA를 이용한 기준 이미지 생성 -> 생성된 기준 이미지를 WD14로 다시 분석하여 기준이미지 프로필 생성 -> 사용자가 기준이미지를 확인하고 승인/재생성 -> LLM이 감정별 상세 프롬프트와 OpenPose 관절 좌표 생성 -> 기준 이미지를 img2img의 초기 이미지로 사용 -> OpenPose ControlNet으로 새로운 자세 적용 -> LoRA를 이용하여 이모티콘 스타일 유지 -> 여러 후보이미지를 생성 -> CLIP으로 기준이미지 및 프롬프트와의 유사도 평가 후 가장 높은 점수의 이미지 선택 -> 배경 제거 -> 후처리 후 최종 이모티콘 세트 출력
현재 tensor.art에서 이모티콘 스타일을 입힐 LoRA를 학습시키는 중 + 파이프라인을 좀 더 간결하게 하는 등 수정을 진행 중
backend - frontend 통신 방식을 http sse방식으로 변경하. 이제 frontend에서 계속해서 jobid로 get요청을 보내는 방식이 아닌 sse방식으로 전환