라인

107 개의 포스트

techblog.lycorp.co.jp/ko

태그로 필터

line원문

AI로 생성한 이미지는 어떻게 평가할까요? (블랙박스 최적화 적용편) (새 탭에서 열림)

LY Corporation은 전용 디자인 스타일을 반영한 텍스트 투 이미지(text-to-image) 모델을 통해 디자이너의 반복 업무를 줄이고 창의성을 극대화하는 프로젝트를 진행하고 있습니다. 좋은 품질의 이미지를 일관되게 생성하기 위해서는 모델의 구조적 이해와 더불어 하이퍼파라미터 최적화가 필수적이며, 이를 위해 이미지를 수치적으로 평가하고 탐색하는 과정이 중요합니다. 본 글은 스테이블 디퓨전과 최신 SD3.5 모델의 작동 원리를 바탕으로 최적의 이미지를 얻기 위한 기술적 기반을 상세히 다룹니다. ### 디퓨전 및 스테이블 디퓨전 모델의 작동 원리 - **디퓨전 프로세스**: 이미지에 점진적으로 가우스 잡음을 추가하여 무작위 상태로 만드는 '전방향 프로세스'와, 학습된 모델이 노이즈를 단계적으로 제거하며 이미지를 복원하는 '역방향 프로세스'로 구성됩니다. - **잠재 공간(Latent Space) 활용**: 스테이블 디퓨전(SD)은 연산량을 줄이기 위해 고차원의 픽셀 공간이 아닌 저차원의 잠재 공간에서 디퓨전 프로세스를 수행하며, VAE(Variational Autoencoder)를 통해 이미지와 잠재 벡터를 상호 변환합니다. - **모델의 진화**: SDXL은 텍스트 인코더를 추가해 프롬프트 이해도를 높였으며, SD3.5는 U-Net 대신 MMDiT(Multimodal Diffusion Transformer)를 도입하여 텍스트와 이미지 모달리티 간의 결합력을 강화했습니다. ### 플로 매칭(Flow Matching)과 결정적 이미지 생성 - **플로 모델로의 전환**: SD3.5는 기존의 디퓨전 방식이 아닌 플로 매칭 방식을 채택하여 정규 분포와 실제 데이터 분포 사이의 벡터 장(vector field)을 학습합니다. - **결정적(Deterministic) 특성**: 랜덤 노이즈에서 데이터 포인트로 이동하는 속도(velocity)를 계산하여 이미지를 생성하기 때문에, 입력값이 같으면 항상 동일한 결과가 나오는 안정적인 구조를 가집니다. ### 이미지 품질을 좌우하는 주요 하이퍼파라미터 - **시드(Seed)와 랜덤 노이즈**: 이미지 생성의 출발점인 초기 잠재 벡터를 결정하는 값으로, '좋은 시작 지점'을 찾는 것이 최종 결과물의 구도와 품질에 큰 영향을 미칩니다. - **프롬프트(Prompt)**: 사용자의 의도를 모델에 전달하는 창구로, 텍스트 임베딩과 어텐션 메커니즘을 통해 노이즈 제거 과정에 개입합니다. - **Classifier-Free Guidance (CFG)**: 생성된 이미지에 프롬프트의 정보를 얼마나 강하게 반영할지 조절하는 수치이며, 텍스트 조건부 노이즈와 네거티브 프롬프트 기반 노이즈의 차이를 활용해 정확도를 조절합니다. 효과적인 AI 이미지 생성을 위해서는 단순히 프롬프트를 수정하는 것에 그치지 않고, 시드와 CFG 같은 파라미터가 이미지의 구도와 스타일 변화에 미치는 기술적 메커니즘을 이해해야 합니다. 특히 수동으로 최적의 값을 찾는 것은 비효율적이므로, 이미지 평가 지표를 활용해 하이퍼파라미터 탐색 과정을 자동화하는 워크플로우를 구축하는 것이 실무적으로 큰 도움이 됩니다.

line원문

코드 품질 개선 기법 10편: 적절한 거리 유지에 신경 쓰자 (새 탭에서 열림)

코드 품질을 높이기 위해서는 각 레이어나 컴포넌트가 서로의 세부 구현을 알지 못하도록 적절한 거리를 유지하는 것이 중요합니다. 특히 UI와 데이터 레이어가 암묵적인 규칙을 공유하며 의존할 경우, 사양 변경 시 예측하지 못한 버그가 발생하기 쉬우므로 명확한 상태 값과 인터페이스를 통해 책임을 분리해야 합니다. **암묵적 정보 공유의 문제점** * 리포지터리 레이어에서 UI의 표시 형식을 고려해 '최대 개수 + 1'의 데이터를 조회하는 식의 구현은 레이어 간의 경계를 무너뜨립니다. * UI 레이어가 리포지터리의 특정 동작(예: 100개 초과 시 리스트 크기가 101임)에 의존해 비즈니스 로직을 판단하면 코드의 가독성과 유지보수성이 떨어집니다. * 이러한 방식은 주석으로만 의도를 설명할 수 있을 뿐, 코드 구조 자체로는 데이터의 의미를 명확히 전달하지 못하는 한계가 있습니다. **명시적인 속성을 활용한 책임 분리** * 모델 클래스에 `hasMoreItems`와 같은 명시적인 불리언 속성을 추가하여 데이터의 상태를 직접적으로 표현하는 것이 좋습니다. * 리포지터리는 모델 인스턴스를 생성할 때 추가 데이터 존재 여부를 판단하는 로직을 수행하고, UI에는 정제된 데이터만 전달합니다. * UI 레이어는 더 이상 특정 상수값이나 리포지터리의 조회 규칙을 알 필요 없이, 모델이 제공하는 속성에만 기반하여 화면을 구성할 수 있게 됩니다. **로직과 상수의 적절한 위치 선정** * 데이터 개수를 제한하는 상수(`ITEM_LIST_MAX_COUNT`)는 서비스의 성격에 따라 비즈니스 로직 레이어(도메인, 유스 케이스 등)에서 정의하는 것이 이상적입니다. * 비즈니스 레이어를 별도로 두기 어려운 규모라면 모델 클래스 내부에 정의할 수도 있으나, 이때는 데이터 구조와 알고리즘 간의 의존 방향이 모호해지지 않도록 주의해야 합니다. * 특정 기능에 국한된 로직이 범용적인 데이터 모델에 포함되어 재사용성을 해치지 않는지 검토하는 과정이 필요합니다. **실용적인 제언** 코드 작성 시 "이 컴포넌트가 다른 컴포넌트의 내부 사정을 너무 자세히 알고 있지는 않은가?"를 자문해 보시기 바랍니다. 다른 레이어의 세부 동작에 암묵적으로 의존하는 코드를 피하고, 인터페이스를 통해 명확한 정보를 주고받도록 설계하는 것이 변경에 유연한 소프트웨어를 만드는 핵심입니다.