인쇠물 색깔 추천기

만든 동기

인쇠물(CMYK)랑 화면(RGB+화면CMYK)이 서로 다르기에 이것을 제대로 알려주고 색깔을 추천해주기 위해서

어려웠던 점

1.브라우저(모니터)는 본질적으로 빛의 삼원색($RGB$)을 더해 밝아지는 구조이고, 인쇄물은 잉크($CMYK$)를 섞을수록 어두워지는 구조입니다. 브라우저라는 가산혼합 공간 안에서 감산혼합 잉크의 탁해지는 성질(색역 왜곡)을 실시간으로 구현하는 것 자체가 수학적 모순이었습니다. 2. 브라우저 환경에 따른 스포이드(EyeDropper) API의 파편화 문제점: 이번에 새로 도입한 내장 EyeDropper API는 별도의 무거운 이미지 처리 라이브러리 없이 화면 색상을 바로 딸 수 있어 성능상 매우 훌륭합니다. 하지만 Safari나 Firefox 같은 일부 브라우저에서는 보안 및 정책상의 이유로 여전히 이 기능을 정상적으로 지원하지 않습니다. 3. Gemini LLM의 JSON 출력 안정성 및 다중 모델 백업 구조 설계 문제점: 사용자가 입력한 감성적인 자연어(예: "달콤한 딸기 라떼 느낌")를 정확히 해석해서 색상 코드와 5가지 조화로운 배열을 JSON 형태로 완벽하게 받아내야 했습니다. 하지만 가끔 AI 모델이 답변 앞뒤에 백틱(```json)을 붙이거나 텍스트 설명을 주저리주저리 붙이면 브라우저의 JSON.parse가 터져 먹통이 되는 치명적인 문제가 생깁니다. 4. 3가지 색상 영역에 따른 실시간 텍스트 명도 반전 로직문제점: 모니터(RGB), 모니터(CMYK), 인쇄물(CMYK) 박스 3개가 동시에 시시각각 바뀝니다. 만약 사용자가 밝은 라임색을 고르면 모니터 박스는 글자가 검은색이어야 읽히지만, 톤다운된 인쇄물 박스에서는 어두워지므로 글자가 흰색으로 변해야 가독성이 유지됩니다.해결의 고충: 3개 칸의 실제 배경색을 실시간 루마 연산($0.2126R + 0.7152G + 0.0722B$)으로 따로따로 계산하여, 글자 색상을 독립적으로 줬다 뺐다 매끄럽게 처리하는 DOM 제어 로직이 손이 참 많이 가고 섬세함을 요구했습니다.

해결한 방법

2.해결의 고충: 스포이드 기능을 추가하되, 미지원 브라우저 환경에서 스크립트 에러가 터져 전체 앱이 멈추는 대형 참사(Crash)를 막아야 했습니다. 따라서 if (!window.EyeDropper) 분기 조건을 걸어 예외 처리를 유연하게 하고, 안전하게 안내용 토스트 메시지를 띄우는 예방 코드를 꼼꼼하게 삽입해야 했습니다. 3.해결의 고충: 이를 막기 위해 엄격한 responseSchema를 지정해 주었고, 혹시 모를 특정 모델의 서버 지연이나 응답 오류에 대비해 gemini-2.5-flash-preview ➔ gemini-2.5-flash ➔ gemini-1.5-flash 순으로 순식간에 우회 점검하는 다중 모델 폴백(Fallback) 파이프라인을 바닐라 자바스크립트의 비동기 반복문만으로 설계해야 했습니다.

배운 점