LLM이 본질적으로 잘하는 일과 못하는 일, 즉 불가능하다는 뜻은 아니지만 근본적 제약 때문에 성공 가능성이 낮은 일을 더 깊이 이해해 가는 흐름이 반가움
소프트웨어 아키텍처는 사람이 정하고 함수 구현은 LLM에 맡기는 방식, 데이터 분석 자체를 시키기보다 SQL 질의를 쓰게 하는 방식과 비슷함
어떤 작업 단위가 LLM에 잘 맞고 어떤 것은 아닌지에 대한 더 명확한 작업 분류 체계와 연구가 있으면 좋겠고, 직관은 조금씩 생기지만 아직 많은 사람이 여기서 자주 넘어지는 걸 봄
“아키텍처는 사람이 정하고 함수는 LLM이 쓰게 한다”는 방식은 얼마 전까지만 해도 LLM 코딩 보조 도구 초기 사용자들이 권장하던 사용법이었음
먼저 개요를 만들게 하고, 각 함수를 따로 구현하게 하는 식이었고, 애니메이션 작업에서 따온 용어로 이 접근을 보여주는 블로그 글도 HN에 몇 번 올라왔음
LLM과 관련해 근본적 제약이라는 표현이 자주 나오지만, 그런 제약이 존재한다는 엄밀한 증명은 아직 하나도 없음
2년 전만 해도 문자 세기나 음운 처리처럼 “근본적 제약” 때문에 불가능하다고 하던 작업들이 지금은 도구 없이도 별문제가 아닌 경우가 많아졌음
이미지 생성 프롬프트를 읽을 때마다 모델이 명백히 무시한 매우 구체적인 디테일이 보임
여기서도 마지막 두 이미지의 초콜릿/사탕은 장인 수제 느낌과는 거리가 멀고, 너무 멸균된 대량생산품처럼 보이며, 시점도 정확하지 않음
모델이 대부분을 무시한다면 왜 이렇게 장황한 프롬프트를 쓰는지 의문임
“스튜디오 조명”을 요청했더니 사진 안에 스튜디오 조명 장비를 잔뜩 넣어버린 예시가 마음에 들었음
사탕들은 실제로 장인 수제처럼 보이려는 게 아니라, 훈련 데이터에서 회사들이 artisanal이라고 홍보하고 라벨 붙인 이미지와 맞추려는 것임
rustic, homemade, amateur 같은 표현이 태깅과 더 잘 맞을 수도 있음
이미지 생성을 몇 번 써봤을 때도 정확히 이런 부분에서 계속 실패했음
처음엔 내 프롬프트 작성 능력 부족이라고 여겼지만, 이런 불일치를 의식하고 보기 시작하면 꽤 흔하게 드러남
자세한 프롬프트 대부분은 AI가 생성한 것이라고 봄
이걸 전부 떠올리는 데 얼마나 걸렸을지 궁금함
마지막처럼 작은 “버튼”들이 나선형으로 배열된 이미지를 원했다면, 사탕처럼 보이지도 않지만, Blender를 잘 못하는 편이어도 오후 하나면 만들 수 있었을 것 같음
AI 생성 이미지에서 텍스트와 숫자를 안정적으로 얻는 간단한 기법을 찾았음
이미지 모델들이 이미 이렇게 하지 않는 게 의외라서, 꽤 유용하게 쓰고 있어 공유하고 싶었음
어떤 면에서는 ControlNet 사용과 비슷함
SVG만 기반 이미지로 쓰는 같은 기법을 한동안 써왔고, 잘 작동함
매우 인상적이고, 단순하며, 안정적임
이미지 생성 연구소들이 곧 받아들일 것 같음
이건 일종의 사고의 연쇄(chain of thought), 즉 https://arxiv.org/abs/2201.11903와 비슷한 것 아닌가 싶음
사용자가 모델이 0-shot으로 풀게 하는 대신 1-shot 또는 k-shot으로 해결책을 돕는 구조임
비슷한 기법을 매우 효과적으로 써봤고, 분야가 너무 새롭고 빠르게 움직여 공통 용어가 아직 부족한 느낌이라 블로그와 예시는 매우 유용함
다만 이 현상이 이미 더 작은 커뮤니티나 다른 이름으로 관찰되고 이해됐을 가능성도 있어 보임
요약하면 먼저 SVG로 올바른 윤곽을 만든 뒤, 그 이미지를 텍스트 프롬프트와 함께 Gemini 3.0 Pro에 보내 정확한 숫자와 텍스트가 들어가도록 렌더링하게 하는 방식임
이건 올바른 구조를 가진 첫 이미지를 코드로 만든 img2img일 뿐임
맞음, 정확히 그 방식임
Stable Diffusion 초창기부터 생성 모델을 써왔다면 꽤 흔하고 유용한 기법으로, 스케치(SVG, 손그림 등)를 임시 ControlNet처럼 써서 생성 모델 출력을 유도하는 것임
예전에는 건축 시각화를 배치할 때 비슷한 접근을 썼음
소파, 의자나 다른 가구를 특정 위치에 두고 싶으면 Poser 같은 도구로 주요 “세트 피스” 위치를 대략 잡은 단순 장면을 만들고, 거기서 깊이 지도를 생성해 당시 SDXL 같은 생성 모델에 넣어 객체 배치를 유도할 수 있었음
대체로 저자가 말한 그대로이고, 입문자를 위해 맥락을 조금 붙인 것에 가까움
맞지만, 그 코드를 만들 때 다른 코드 생성 모델을 쓸 수 있음
이 해킹은 확실히 “아, 왜 이걸 생각 못 했지” 싶은 부류의 요령임
다음에 이미지 생성이 기대에 못 미칠 때 쓸 수 있게 되어 반가움
원래 Stable Diffusion 앱에도 이미 image-to-image가 있었음
다만 성능이 지금만큼 좋지 않았을 뿐이라, 이게 왜 새롭다고 여겨지는지 잘 모르겠음
표준적인 반론은 이것임: LLM이 정말 지능적이라면 왜 이 2단계 과정이 더 나은 결과를 낸다는 걸 스스로 알아내지 못하나?
기본 수준에서 이미지 모델은 텍스트 토큰을 입력받아 이미지 토큰을 내보내는 구조일 뿐임
전략을 세우고, 결과를 검토하고, 다시 시도하려면 그 위에 에이전트형 프로세스가 필요함
Nano Banana와 gpt-image-2에는 이런 것이 조금 들어간 듯하지만, 모델에게 코드를 한 번에 쓰게 하는 것과 도구를 갖춘 에이전트 하네스가 처리하게 하는 것의 차이와 비슷함
아주 기본적인 에이전트도 ChatGPT 단독보다 더 나은 코드를 만들 수 있음
LLM은 대체로 “이미지 만들기”류 프롬프트를 약간 다듬어서 별도 모델에 넘기도록 하드코딩되어 있기 때문임
모르는 건 모르는 것임
사실 지능적이지 않기 때문임
아무도 그렇게 하라고 요청하지 않았음
이런 방식은 오래전부터 해왔고, 깊이 지도나 선화를 써서 실루엣을 제어하는 것과 비슷함
결론부의 “작동하지만, 사실은 그렇지도 않다”는 느낌이 좋았음
LLM/생성 AI 열풍답게, 아주 좁은 예시 하나를 맞추려고 복잡한 노력을 들였지만 거의 되는 듯하면서도 결국 제대로 되지는 않는다는 걸 글 전체로 보여줌
일부라도 작동하면 유용함
사람이 숫자가 맞는지 확인하기는 쉽고, 틀리면 이미지를 다시 생성하면 됨
모델 없이 처음부터 이미지를 만드는 것보다 몇 자릿수는 더 쉬움
흔한 과제인 “자전거 타는 펠리컨의 SVG”에는 반대 방향 접근을 해볼 수 있겠다고 생각했음
SVG를 바로 뱉게 하면 당연히 품질이 나쁠 가능성이 큼
하지만 이미지 생성은 멋진 사실적 이미지를 쉽게 만들 수 있으니, 먼저 이미지를 생성하고 모델이 그걸 추적해 SVG로 만들게 하면 괜찮은 자전거-펠리컨 SVG를 얻는 좋은 방법일 수 있음
결국 사람도 메모장에 숫자만 입력해서 SVG 예술품을 만드는 경우는 드물고, 핵심은 여전히 그것을 이미지로 보고 생각하는 데 있음
사람이 정확히 하려는 방식과도 비슷해 보임
예술가에게 수정이나 스케치 없이 한 번에 큰 원형 배열의 돌을 순서대로 번호까지 넣어 그리라고 하면, 배치 오류가 생겨도 이상하지 않음
Hacker News 의견들
LLM이 본질적으로 잘하는 일과 못하는 일, 즉 불가능하다는 뜻은 아니지만 근본적 제약 때문에 성공 가능성이 낮은 일을 더 깊이 이해해 가는 흐름이 반가움
소프트웨어 아키텍처는 사람이 정하고 함수 구현은 LLM에 맡기는 방식, 데이터 분석 자체를 시키기보다 SQL 질의를 쓰게 하는 방식과 비슷함
어떤 작업 단위가 LLM에 잘 맞고 어떤 것은 아닌지에 대한 더 명확한 작업 분류 체계와 연구가 있으면 좋겠고, 직관은 조금씩 생기지만 아직 많은 사람이 여기서 자주 넘어지는 걸 봄
먼저 개요를 만들게 하고, 각 함수를 따로 구현하게 하는 식이었고, 애니메이션 작업에서 따온 용어로 이 접근을 보여주는 블로그 글도 HN에 몇 번 올라왔음
2년 전만 해도 문자 세기나 음운 처리처럼 “근본적 제약” 때문에 불가능하다고 하던 작업들이 지금은 도구 없이도 별문제가 아닌 경우가 많아졌음
이미지 생성 프롬프트를 읽을 때마다 모델이 명백히 무시한 매우 구체적인 디테일이 보임
여기서도 마지막 두 이미지의 초콜릿/사탕은 장인 수제 느낌과는 거리가 멀고, 너무 멸균된 대량생산품처럼 보이며, 시점도 정확하지 않음
모델이 대부분을 무시한다면 왜 이렇게 장황한 프롬프트를 쓰는지 의문임
rustic, homemade, amateur 같은 표현이 태깅과 더 잘 맞을 수도 있음
처음엔 내 프롬프트 작성 능력 부족이라고 여겼지만, 이런 불일치를 의식하고 보기 시작하면 꽤 흔하게 드러남
마지막처럼 작은 “버튼”들이 나선형으로 배열된 이미지를 원했다면, 사탕처럼 보이지도 않지만, Blender를 잘 못하는 편이어도 오후 하나면 만들 수 있었을 것 같음
AI 생성 이미지에서 텍스트와 숫자를 안정적으로 얻는 간단한 기법을 찾았음
이미지 모델들이 이미 이렇게 하지 않는 게 의외라서, 꽤 유용하게 쓰고 있어 공유하고 싶었음
SVG만 기반 이미지로 쓰는 같은 기법을 한동안 써왔고, 잘 작동함
이미지 생성 연구소들이 곧 받아들일 것 같음
사용자가 모델이 0-shot으로 풀게 하는 대신 1-shot 또는 k-shot으로 해결책을 돕는 구조임
비슷한 기법을 매우 효과적으로 써봤고, 분야가 너무 새롭고 빠르게 움직여 공통 용어가 아직 부족한 느낌이라 블로그와 예시는 매우 유용함
다만 이 현상이 이미 더 작은 커뮤니티나 다른 이름으로 관찰되고 이해됐을 가능성도 있어 보임
이건 올바른 구조를 가진 첫 이미지를 코드로 만든 img2img일 뿐임
Stable Diffusion 초창기부터 생성 모델을 써왔다면 꽤 흔하고 유용한 기법으로, 스케치(SVG, 손그림 등)를 임시 ControlNet처럼 써서 생성 모델 출력을 유도하는 것임
예전에는 건축 시각화를 배치할 때 비슷한 접근을 썼음
소파, 의자나 다른 가구를 특정 위치에 두고 싶으면 Poser 같은 도구로 주요 “세트 피스” 위치를 대략 잡은 단순 장면을 만들고, 거기서 깊이 지도를 생성해 당시 SDXL 같은 생성 모델에 넣어 객체 배치를 유도할 수 있었음
이 해킹은 확실히 “아, 왜 이걸 생각 못 했지” 싶은 부류의 요령임
다음에 이미지 생성이 기대에 못 미칠 때 쓸 수 있게 되어 반가움
다만 성능이 지금만큼 좋지 않았을 뿐이라, 이게 왜 새롭다고 여겨지는지 잘 모르겠음
표준적인 반론은 이것임: LLM이 정말 지능적이라면 왜 이 2단계 과정이 더 나은 결과를 낸다는 걸 스스로 알아내지 못하나?
전략을 세우고, 결과를 검토하고, 다시 시도하려면 그 위에 에이전트형 프로세스가 필요함
Nano Banana와 gpt-image-2에는 이런 것이 조금 들어간 듯하지만, 모델에게 코드를 한 번에 쓰게 하는 것과 도구를 갖춘 에이전트 하네스가 처리하게 하는 것의 차이와 비슷함
아주 기본적인 에이전트도 ChatGPT 단독보다 더 나은 코드를 만들 수 있음
이런 방식은 오래전부터 해왔고, 깊이 지도나 선화를 써서 실루엣을 제어하는 것과 비슷함
결론부의 “작동하지만, 사실은 그렇지도 않다”는 느낌이 좋았음
LLM/생성 AI 열풍답게, 아주 좁은 예시 하나를 맞추려고 복잡한 노력을 들였지만 거의 되는 듯하면서도 결국 제대로 되지는 않는다는 걸 글 전체로 보여줌
사람이 숫자가 맞는지 확인하기는 쉽고, 틀리면 이미지를 다시 생성하면 됨
모델 없이 처음부터 이미지를 만드는 것보다 몇 자릿수는 더 쉬움
흔한 과제인 “자전거 타는 펠리컨의 SVG”에는 반대 방향 접근을 해볼 수 있겠다고 생각했음
SVG를 바로 뱉게 하면 당연히 품질이 나쁠 가능성이 큼
하지만 이미지 생성은 멋진 사실적 이미지를 쉽게 만들 수 있으니, 먼저 이미지를 생성하고 모델이 그걸 추적해 SVG로 만들게 하면 괜찮은 자전거-펠리컨 SVG를 얻는 좋은 방법일 수 있음
결국 사람도 메모장에 숫자만 입력해서 SVG 예술품을 만드는 경우는 드물고, 핵심은 여전히 그것을 이미지로 보고 생각하는 데 있음
사람이 정확히 하려는 방식과도 비슷해 보임
예술가에게 수정이나 스케치 없이 한 번에 큰 원형 배열의 돌을 순서대로 번호까지 넣어 그리라고 하면, 배치 오류가 생겨도 이상하지 않음