Vol. 04 - AI Prompt & Parameter

안녕하세요. 제로백데브 백엔드 개발자 박건우입니다.

이번 제로백데브 LAB에서는 블라인드몬스터라는 프로젝트에서 AI 이미지 합성 모델을 교체하면서 겪은 경험을 공유하려 합니다.

배경: 내 방 창문에 블라인드를 달아보기

블라인드몬스터는 커튼·블라인드 이커머스 플랫폼입니다. 사용자가 자신의 방 사진을 업로드하면 AI가 실제 제품을 창문에 합성해서 보여주는 기능을 개발하고 있었습니다.

발단: 공식 문서를 읽다가 발견한 종료일

이미지 합성 품질을 높이기 위해 구글 공식 문서를 살펴보던 중, 눈에 걸리는 항목이 하나 있었습니다.

당시 이미지 합성 파이프라인에서 사용하던 모델이 gemini-2.5-flash-image 였습니다. 종료일까지 시간이 있긴 했지만, 어차피 교체해야 할 거라면 지금 하는 게 낫겠다고 판단했습니다. 대응은 간단해 보였습니다. 권장 교체 모델로 모델명만 바꿔주면 끝이라고 생각했습니다.

// Before
model: "gemini-2.5-flash-image"
// After
model: "gemini-3.1-flash-image-preview"

그게 실수였습니다.

모델명만 바꿨는데 1분이 4분이 됐다

모델명을 교체하고 테스트를 돌렸더니 합성 시간이 4분을 넘어버렸습니다.

코드 변경은 모델명 한 줄이 전부였는데, 성능이 네 배 이상 나빠진 겁니다. 처음엔 새 모델이 무거워서 그런가 싶었고, 네트워크 문제인가도 의심했습니다. 몇 번을 돌려도 결과는 같았습니다.

기존 파이프라인은 어떻게 돌아갔나

변경 전 합성 흐름은 이렇게 동작하고 있었습니다.

Step 0a 방 사진 분석 (텍스트 모델)
↓
Step 0b 제품 배경 제거 (이미지 모델)
↓
Step 1 방에 제품 합성 (이미지 모델)
↓
Step 2 합성 결과 보정 (이미지 모델)

이미지 모델을 세 번 호출하는 구조가 된 데는 이유가 있었습니다. 블라인드와 커튼은 단순히 창문 위에 이미지를 얹는 게 아닙니다. 창문 프레임의 정확한 크기와 위치를 인식하고, 제품의 재질과 광투과율에 따라 빛이 어떻게 반응하는지까지 표현해야 했습니다. 공간적 제약이 까다로운 작업이다 보니, 2.5 모델만으로는 한 번에 완성도 높은 합성을 뽑기 어려웠습니다. Step 1에서 제품을 배치하면 경계면이 어색하거나 색상이 번지는 경우가 많았고, 이를 Step 2에서 다시 보정하는 방식으로 품질을 맞추고 있었습니다. 그래도 당시엔 합성 한 번에 1분 미만으로 동작하고 있었고, 운영에는 문제 없는 수준이었습니다.

원인 1: Gemini 3.x는 파라미터 설정이 다르다

코드를 다시 뜯어보다가 이 부분이 눈에 들어왔습니다.

// GeminiProperties.java
temperature: 0.2
topP: 0.8

2.5 모델을 쓸 때부터 유지해온 설정값이었습니다. 여기서 temperature는 AI가 결과를 얼마나 일관되게 뽑을지 조절하는 값입니다. 낮게 설정할수록 매번 비슷한 결과가 나오고, 높을수록 결과가 다양해집니다. 이미지 합성 특성상 창의적인 변형보다 일관된 결과가 중요하다고 판단해서 낮게 설정해뒀던 건데, 모델을 교체하면서 그냥 그대로 가져왔습니다.

구글 공식 문서를 확인했더니 이런 내용이 있었습니다.

"Gemini 3 모델을 사용할 때는 temperature를 기본값인 1.0으로 유지하는 것이 좋습니다. 온도를 변경하여(1.0 미만으로 설정) 복잡한 수학적 또는 추론 작업에서 루핑이나 성능 저하와 같은 예기치 않은 동작이 발생할 수 있습니다."

여기서 두 모델의 차이가 있었습니다. 기존에 쓰던 gemini-2.5-flash-image는 애초에 Thinking 기능이 없는 이미지 전용 모델이었고, 이 구성에서는 temperature를 0.2로 낮춰도 성능 문제가 거의 없었습니다. 반면 새로 적용한 gemini-3.1-flash-image-preview는 이미지를 생성하기 전에 "어떻게 그릴지"를 먼저 추론하는 Thinking 과정을 기본으로 포함하는 모델이라, 같은 temperature 설정이 오히려 루핑이나 지연을 유발하는 원인이 되었습니다.

구글 문서에서 경고하는 것처럼, 실제로 우리 워크로드에서도 temperature 0.2 설정을 그대로 유지하자 이미지를 만들기 전 추론 단계에서만 몇 분씩 걸리는 현상이 나타났습니다.

// Before
temperature: 0.2
topP: 0.8
// After — 기본값 사용 (설정 제거)
// temperature: 1.0 (default)
// topP: 0.95 (default)

원인 2: 프롬프트 구조도 새 모델에 맞지 않았다

속도는 해결됐는데 이번엔 합성 결과가 이상했습니다.

원하는 건 "이 방 창문에 이 블라인드를 그대로 달아줘"였는데, 모델이 구도나 블라인드 설치 위치를 자기 판단으로 바꿔버리는 경우가 생긴 겁니다. temperature를 올리면서 모델이 더 적극적으로 추론하게 됐는데, 프롬프트 지시가 느슨하니까 그 추론이 엉뚱한 방향으로 흘러버린 거였습니다.

원인을 찾다 보니 프롬프트 구조 문제였습니다. 구글 공식 문서에 Gemini 3.x는 역할과 제약 조건을 명확하게 구분해서 주는 방식에 잘 맞는다고 나와 있었고, 기존 프롬프트는 그런 구분 없이 지시사항을 쭉 나열한 형태였습니다. 프롬프트를 처음부터 다시 썼고, 모델이 임의로 판단할 여지를 최대한 없앴습니다. 그러고 나서야 합성 결과가 안정됐습니다.

그리고 파이프라인도 함께 정리했다

파라미터와 프롬프트를 손보는 김에, 파이프라인 구조도 들여다봤습니다.

Gemini 3.1은 2.5에서 여러 단계로 나눠야 했던 공간 추론과 재질 표현을 한 번에 처리할 수 있을 만큼 개선되어 있었습니다. 기존에 두 단계로 나눠서 처리하던 합성과 보정을 한 번으로 끝낼 수 있었고, 제품 배경 제거 단계도 프롬프트에서 처리할 수 있었습니다.

Before

Step 0a 방 사진 분석 (텍스트 모델)
↓
Step 0b 제품 배경 제거 (이미지 모델)
↓
Step 1 방에 제품 합성 (이미지 모델)
↓
Step 2 합성 결과 보정 (이미지 모델)

(위 이미지는 4분 소요)

After

Step 0 방 사진 분석 (텍스트 모델)
↓
Step 1 방에 제품 합성 (이미지 모델)

(위 이미지는 30초 소요)

최종 결과입니다.

교체 전 (2.5 모델): 1분 미만
교체 직후 (설정값 유지): 4분 이상
파라미터 + 프롬프트 수정: 40초 미만

참고로 더 높은 품질의 Pro 모델을 선택하지 않은 이유도 있습니다. 가상 피팅 특성상 사용자가 버튼을 누른 뒤 최대한 빠르게 결과를 받을 수 있게 하고 싶었습니다. Pro 모델은 품질은 높지만 응답 속도가 느립니다. Flash 모델로도 충분한 합성 품질을 뽑을 수 있었기 때문에, 속도와 품질 사이의 균형을 고려해 Flash를 선택했습니다.

마치며

이번 경험에서 얻은 교훈은 두 가지입니다.

모델을 바꾸면 파라미터와 프롬프트도 처음부터 다시 검토해야 합니다. 이전 모델에서 이유가 있어 설정한 값과 구조라도, 새 모델에서는 그 이유가 유효하지 않을 수 있습니다. 특히 Gemini처럼 버전 간 내부 아키텍처가 크게 달라지는 경우라면 더욱 그렇습니다.

공식 문서는 처음부터 읽는 게 낫습니다. 품질 개선을 위해 문서를 읽다가 종료 공지를 발견했고, 교체 과정에서 다시 문서를 통해 원인을 찾았습니다. 처음 모델을 도입할 때 문서를 더 꼼꼼히 읽었다면 겪지 않아도 됐을 시행착오였습니다.

모델 이름 한 줄만 바꾸면 끝날 거라 생각했던 작업이 결국 파이프라인 전체를 다시 들여다보는 계기가 됐습니다.