바이브코딩 패치 지옥에서 살아남은 방법
Cursor-first(Composer→Opus)로 Ask/Agent 돌리며 프로덕션 12회 스모크 통과한 과정
프로젝트: “StyleSense — 퍼스널 컬러 진단 + AI 코디 추천 서비스” 패치 업데이트 v0.1
서비스 링크: https://stylesense-khaki.vercel.app/
기간: 2026년 4월 3일 ~ 4일(총 9시간)
스택: LangGraph + OpenAI GPT + fal-ai FLUX/schnell + Next.js
결과: 프로덕션 스모크 테스트 12회 통과(댄디/섹시 포함)
워크플로우: Cursor-first로 진행(초반 Composer 2.0 중심 → 막히는 구간은 Opus 4.6로 전환). Ask/Agent 모드로 진단→최소 패치→재검증 루프를 반복했습니다.한 줄 요약: “프롬프트는 길면 똑똑해지는 게 아니라, 희석됩니다.”
※ 아래 ‘모델 특성’(예: 부정어 처리, 토큰 살리언스 등)은 이번 프로젝트에서의 관측 기반입니다. 모델/버전/프롬프트 구조에 따라 달라질 수 있습니다.
결론
이번 패치 사이클에서 얻은 결론은 3가지였습니다.
- 스타일별 두더지잡기보다 공통 guardrail이 유지보수에 압도적으로 유리했습니다.
- 이미지 모델(FLUX/schnell)은 ‘NO X’(부정어)를 잘 이해하지 못합니다. 따라서 “하지 마”보다 “대신 이렇게”가 훨씬 강합니다.
- Headless QA는 ‘기본 검증’, Live 스모크 테스트는 ‘최종 판정’입니다.
(Headless는 통과했는데, 크리티컬은 모두 프로덕션 수동 스모크에서 발견되었습니다.)
배경: 왜 이런 일이 벌어졌나
StyleSense는 사용자 사진을 분석해 퍼스널 컬러를 진단하고, 날씨/성별/스타일 키워드에 맞는 코디 이미지 2장을 생성합니다. 문제는 여기서부터였습니다.
- 텍스트 모델(LLM)은 충분히 논리적이지만
- 이미지 모델(FLUX/schnell)은 “프롬프트를 내가 중요하다고 생각한 순서대로” 읽지 않습니다.
- 그래서 패치를 몇 번 반복하다 보면, 한쪽을 고치면 다른 쪽이 터지는 일이 자주 일어납니다.
이 글은 그 과정에서 제가 실제로 겪은 이슈, 최소 패치, 검증 결과, 그리고 운영 관점의 교훈을 기록한 내용입니다.
또한 이번 사이클은 Cursor-first로 진행했습니다. 초반에는 Composer 2.0로 빠르게 Ask/Agent를 돌려 원인을 좁혔고, 후반에 프롬프트 구조/모델 특성처럼 난도가 올라간 구간은 Opus 4.6으로 진단·패치를 마무리했습니다.
해결한 이슈와 핵심 인사이트 (7라운드)
각 라운드는 “증상 → 원인 → 최소 패치 → 검증 → 교훈” 포맷으로 정리했습니다.
Round 1 — 온도 회귀(15~23°C mild band)
증상: 21°C인데 코트/목폴라/앵클부츠가 등장했습니다.
원인: LLM이 만든 추천문(recommendation_ko)에 겨울 아이템이 섞이면, 후속 파이프라인이 그걸 그대로 OUTFIT SPEC(강한 긍정 스펙)으로 고정해버렸습니다.
최소 패치: 스타일과 무관하게 15~23°C에서 공통 mild-band clamp 도입(후처리 레이어)
- coat → blazer/shirt jacket
- turtleneck/heavy knit → crew-neck tee / shirt
- boots → loafers/sneakers
검증: 15~23°C 구간에서 겨울 아이템 회귀율이 크게 줄었습니다.
교훈: 스타일별 패치보다 공통 guardrail이 이깁니다.
Round 2 — sexy/macho 예외 과잉
증상: mild clamp에 sexy/macho 예외를 두었더니, 해당 스타일에서 다시 겨울 코디가 회귀했습니다.
원인: “예외”가 늘어나는 순간, guardrail은 무력화됩니다.
최소 패치: 예외 제거 + 15°C 이상에서는 sexy/macho도 운영용 경량화 clamp 적용
검증: sexy/macho에서도 온도 준수율이 개선되었습니다.
교훈: 예외 규칙은 최소한으로. 예외는 ‘기능’이 아니라 ‘부채’입니다.
※ clamp: 값이 튀지 못하게 규칙으로 제한/치환하는 처리
Round 3 — 전신샷(head-to-toe) 회귀
증상: 여성에서 특히 전신이 아니라 상반신만 나오는 문제가 반복되었습니다.
원인: 프롬프트 길이가 4500자 수준으로 비대해지면서, 전신 프레이밍 지시가 전체 토큰에서 희석되었습니다.
최소 패치: 중복 lock 제거 + 금지 목록 다이어트로 프롬프트를 3000자대로 압축
검증: head-to-toe(신발 포함) 전신샷이 안정화되었습니다.
교훈: 이미지 모델에서 프롬프트 길이는 곧 신호 희석입니다. “짧고 강하게”가 답이었습니다.
| After | |
 |  |
전신샷을 안정화하고 나니, 이번엔 반대로 ‘색상 신호’가 프롬프트 뒤로 밀려 약해지는 문제가 나타났습니다(라운드 4). 그리고 부정어는 역효과가 날 수 있다는 점도 확인했습니다(라운드 5).
Round 4 — 퍼스널 컬러 약화
증상: 패치를 거듭하면서 퍼스널 컬러 반영이 약해졌습니다.
원인: 색상 지시가 아이템 설명 맨 뒤(… in Warm Brown)에 붙는 suffix 구조라, 모델이 형태/금지 지시를 먼저 먹고 색은 무시했습니다.
최소 패치:
- 색상을 prefix로 이동(예:
Warm Brown blazer…) - 프롬프트 상단에 COLOR LOCK 1줄 추가
- bottom에도 색 신호를 일부 주입
검증: palette 축(웜/쿨, 밝기/채도)의 일관성이 회복되었습니다.
교훈: 중요한 신호일수록 프롬프트 앞쪽에 배치해야 합니다.
| After | |
 |  |
Round 5 — 부정어의 역설(bra-top 이슈)
증상: “NO bra top, NO bralette…”를 넣을수록 브라탑이 더 나오는 역설이 발생했습니다.
원인(관측): FLUX/schnell은 부정어를 정교하게 처리하지 못하고, 오히려 금지 토큰 자체가 생성 확률을 자극하는 패턴이 있었습니다.
최소 패치: 부정어를 줄이고, 물리적 묘사로 차단
- “blazer buttoned at waist”
- “structured jacket with closure”
검증: 이너를 입지 않은 수준의 크리티컬한 노출이 확률적으로 줄어들었습니다(완전 0%는 아니지만 의미 있게 감소).
교훈: “하지 마”는 통하지 않고, “대신 이렇게”만 통합니다.
극단적인 노출은 줄였으나, 브라탑 제거 등의 결과 수정은 프롬프트로 통제 가능한 영역이 아니었습니다. 같은 조건에서도 계속 결과가 바뀌었는데, 입력 이미지/퍼스널 컬러 차이에 따른 이미지 모델(fal-ai FLUX/schnell)의 랜덤성이었습니다.
| After | |
 |  |
Round 6 — 복부 노출 잔여
증상: 아우터 closure를 넣었는데도 간헐적으로 복부 노출이 남았습니다.
최소 패치: “fitted inner top covering navel to collarbone” 같은 물리적 범위 지정을 짧게 추가(7~10 단어 수준)
검증: 잔여 노출이 더 줄었습니다.
교훈: 마이크로 패치는 양성 묘사 + 물리 범위가 가장 안전합니다.
Round 7 — “댄디” 키워드의 성별 편향
증상: 여성+댄디에서 남성처럼 나오는 편향이 있었습니다.
원인(관측): dandy/gentleman은 역사적으로 남성 패션 용어에 가까워, 이미지 모델이 그 편향을 충실히 반영했습니다.
최소 패치: 여성일 때만 “mannish chic / tailored feminine elegance”로 치환(프론트 변경 없이 백엔드 분기)
검증: 여성 댄디가 “남성화”로 치우치는 문제가 줄었습니다.
교훈: 도메인 용어에는 편향이 내장돼 있고, 이미지 모델은 그걸 그대로 학습해 반영합니다.
프로덕션 스모크 결과
이번 패치는 최종적으로 프로덕션 스모크 12회(댄디/섹시 포함) 통과로 종료했습니다.
디테일 품질 개선은 다음 시즌(여름) 체크로 넘깁니다.
종합 교훈(운영 관점)
이번 패치로 가장 크게 느낀 점은 “문제를 고치는 기술”보다 문제가 터지지 않게 운영하는 구조가 더 중요하다는 점이었습니다.
1) 비개발자에게 바이브코딩 패치는 정말 어렵습니다
한 군데 고치면 다른 데가 터지는 일이 잦았습니다. 특히 Prompt Bloat가 대표적입니다.
프롬프트가 길어질수록 핵심 지시는 희석되고, 결과는 더 불안정해졌습니다.
- 변수를 독립적이고 최소로 설계하는 것이 유지보수에 유리합니다.
- “나중에 프롬프트로 해결”이 아니라, 처음부터 구조적으로 설계해야 합니다.
2) 비용 효율형 이미지 모델은 ‘프롬프트만으로 통제’에 한계가 있습니다
FLUX/schnell은 비용/속도 측면에서 장점이 있지만, 프롬프트를 “정확히 실행”하는 데는 한계가 있어 보였습니다.
그래서 운영 단계에서는 “완벽 통제”보다 안전한 가드레일이 더 중요해졌습니다.
3) 범위 확장은 끝이 없습니다(겨울 → 봄 → 여름…)
처음엔 겨울 기준으로 시작했고, 작업 중에 봄 날씨가 되면서 온도 대응이 바뀌었습니다.
여름(24°C+)에서는 또 다른 실패가 생길 수 있습니다.
그래서 저는 이렇게 정했습니다.
- 이번엔 범위를 키우지 않고 종료
- 여름에 다시 최소 스모크 + 최소 패치만 진행
4) Headless QA는 편하지만, Live 수동 스모크는 필수입니다
Headless QA(백엔드 batch)는 정말 좋았습니다. 빠르고 반복 가능했습니다.
하지만 크리티컬 이슈는 Live 스모크 테스트를 통해서 제가 직접 발견했습니다.
정리하면:
- Headless QA = 기본 검증
- Live 스모크 = 최종 판정
마무리
이번 경험을 통해, 다음에는 아래 원칙을 더 강하게 지키려고 합니다.
- 한 번에 1곳만 수정
- 즉시 로컬 재현 테스트
- 프로덕션 스모크로 최종 확정
- 프롬프트는 가능하면 3000자 이하 유지
- “NO X”(부정어)보다 “대신 이렇게”를 우선
다음 시즌(여름)에는 24°C+ 구간만 최소 스모크로 재검증하고, 필요한 경우에만 최소 패치를 적용할 계획입니다.
One Comment