🤖
1240 in / 6000 out / 7240 total tokens
Simon Willison의 블로그에서 두 가지 흥미로운 포스트가 올라왔다. 하나는 환장할 프롬프트 실험 프로젝트고, 다른 하나는 AI 실용화에 대한 날카로운 인용이다. 둘 다 "AI를 실제로 써보면 어떤 일이 벌어지는가"라는 질문에 대한 답을 던져준다.
🔥 핫 토픽
scosman/pelicans_riding_bicycles — 펠리컨이 자전거를 타는 세상
이 프로젝트 이름부터가 레전드다. 펠리컨이 자전거를 타는 이미지를 AI가 어떻게 생성하는지 실험한 저장소다. 근데 이게 왜 중요하냐고? 이미지 생성 모델(DALL-E, Midjourney, Stable Diffusion 등)의 "창의성"과 "일관성" 사이의 긴장을 보여주는 완벽한 테스트 케이스기 때문이다.
왜 중요한지: 이미지 생성 AI는 훈련 데이터에 존재하는 패턴을 조합해서 새로운 이미지를 만들어낸다. 문제는 "펠리컨이 자전거를 타는" 장면은 훈련 데이터에 거의 없을 거라는 점이다. 펠리컨의 해부학적 구조와 자전거의 기계적 구조가 물리적으로 양립 불가능하기 때문에, 모델은 둘을 어떻게 "합성"할지 스스로 판단해야 한다. 이건 단순한 장난이 아니라, 모델의 일반화(generalization) 능력을 테스트하는 진지한 벤치마크다. 경쟁 구도에서 보면, 이런 극단적 엣지 케이스에서 어떤 모델이 더 "설득력 있는" 결과를 내는지가 모델 간 우위를 가르는 요소 중 하나다.
개발자에게 어떤 영향이 있는지: 게임 개발에서 AI 생성 에셋을 쓸 때, 정확히 이런 문제에 부딪힌다. "엘프 전사" 같은 건 훈련 데이터가 넘쳐나니까 잘 나온다. 근데 "문어 기사가 드래곤을 타고 우주에서 결투하는 장면" 같은 건? 결과가 룰렛이다. UE5에서 Nanite/Lumen과 결합해서 AI 생성 텍스처/메시를 파이프라인에 넣으려면, 이런 품질 편차를 예측 가능하게 만들어야 한다. 아니면 최소한 "이런 프롬프트는 결과 품질이 불안정하다"는 걸 문서화해야 한다. 실무에서는 "대부분 잘 되는" 걸로는 부족하고, "항상 잘 되는" 아니면 "왜 안 되는지 아는" 게 필요하다.
기술 배경: 확산 모델(Diffusion Model)은 노이즈에서 시작해서 점진적으로 이미지를 "조각"해나가는 방식으로 동작한다. 이 과정에서 모델이 학습한 시각적 패턴(펠리컨의 부리 모양, 자전거의 바퀴 구조 등)을 결합하는데, 이 결합이 물리적으로 타당한지는 보장하지 않는다. 최근 연구들은 이 문제를 해결하기 위해 물리 시뮬레이션을 생성 과정에 통합하거나, 3D 일관성을 강제하는 방법을 탐색하고 있다. 하지만 여전히 "상식적 추론"은 AI 이미지 생성의 아킬레스건이다.
출처: Simon Willison - scosman/pelicans_riding_bicycles
📰 뉴스
Andreas Påhlsson-Notini 인용 — AI 실용화의 현장 목소리
Quoting Andreas Påhlsson-Notini
Simon Willison이 블로그에서 종종 하는 방식이다. 누군가의 통찰을 인용하고, 거기에 자기 코멘트를 덧붙이는 형태. 이번엔 Andreas Påhlsson-Notini의 발언을 인용했다. 내용이 정확히 뭔지는 링크를 봐야 알겠지만, Simon이 고르는 인용은 항상 "AI를 실제로 써보면서 겪은 경험"에 관한 것들이다.
왜 중요한지: AI 연구 논문은 매일 수백 편이 나오지만, 정작 "현장에서 AI를 쓰면서 깨달은 것"에 대한 기록은 드물다. 학술적 성능 지표(FID, CLIP Score 등)가 아무리 좋아도, 실제로 API를 호출해서 프로덕션에 넣었을 때 어떤 일이 벌어지는지는 완전히 다른 문제다. Simon Willison의 블로그가 개발자 커뮤니티에서 영향력 있는 이유는 바로 이 지점에 있다. 그는 "이론"이 아니라 "실제 경험"을 공유한다. 그가 인용을 선택하는 기준도 마찬가지다. 이 인용이 중요한 건, 그게 또 다른 현장의 목소리기 때문이다.
개발자에게 어떤 영향이 있는지: 필자도 AI 사이드 프로젝트를 하면서 이걸 뼈저리게 느낀다. 튜토리얼에서는 다 잘 되더니, 실제 데이터를 넣으니까 edge case에서 폭발하는 경험. 이런 "삽질 기록"을 다른 개발자들이 공유해주는 건 엄청난 자산이다. 특히 LLM 기반 도구를 만들 때, 프롬프트 엔지니어링은 "과학"보다 "공예"에 가깝다. 다른 장인의 노하우를 보는 건 자신의 작업에 즉각적인 도움이 된다. UE5 C++ 작업하면서 AI 코딩 어시스턴트 쓸 때도 마찬가지다. "이런 패턴은 LLM이 잘 못한다"는 걸 미리 알면, 수동으로 검증할 부분을 미리 식별할 수 있다.
기술 배경: AI 실용화의 핵심 난제는 "성능"이 아니라 "신뢰성"이다. 95% 정확도는 들으면 괜찮아 보이지만, 100번 중 5번이 언제 틀릴지 모른다는 건 프로덕션에서 치명적이다. 이 문제는 자율주행, 의료 AI, 게임 NPC AI 등 모든 분야에서 공통적으로 나타난다. LLM의 경우 hallucination(환각)이 대표적인 신뢰성 문제다. 이걸 완전히 없애는 건 현재 기술로 불가능하니까, 실무에서는 "언제 틀릴 수 있는지 감지하는" 전략을 쓴다.
앞서 언급한 pelicans_riding_bicycles 실험과 이 인용은 사실 같은 맥락에 있다. 둘 다 "AI의 한계를 이해하는 것"에 관한 것이다. 펠리컨 프로젝트는 이미지 생성의 한계를 시각적으로 보여주고, 이 인용은 아마도 LLM 실용화의 한계를 언어적으로 설명할 것이다. 둘을 함께 읽으면, AI 도구를 "믿으면서도 의심하는" 태도가 왜 필요한지 감이 온다.
출처: Simon Willison - Quoting Andreas Påhlsson-Notini
💭 생각거리
이 두 포스트를 나란히 읽으면서 든 생각: AI 도구는 "뭐가 가능한가"보다 "뭐가 불가능한가"를 아는 게 더 중요하다. pelicans_riding_bicycles은 이미지 생성 모델이 어디서 삐끗하는지 보여주고, 현장의 인용은 LLM이 어디서 환각하는지 알려준다. 이걸 모르고 AI 도구를 쓰면, "되는 것 같다"는 착각에 빠져서 나중에 크게 삐긋한다.
게임 개발에서도 마찬가지다. AI NPC, AI 생성 콘텐츠, AI 테스팅... 다 좋은데, 각각의 한계를 명확히 알아야 한다. 아니면 플레이어가 이상한 버그를 발견하고 폭풍 리뷰를 남긴다. 필자는 UE5에서 AI 기반 프로시저럴 생성을 실험하다가, AI가 만든 메시가 물리 충돌에서 뚫리는 걸 보고 정신차렸다. "됐다"가 아니라 "확인해봐야 한다"가 기본 자세다.
AI의 가치는 '완벽한 결과'가 아니라 '빠른 프로토타이핑과 반복적 개선'에 있다. 한계를 아는 게 한계를 넘는 첫걸음이다.