젤리 시트

Jelly Sheet

mrdoob.github.io ▲ 462 댓글 118 memalign

요약

Three.js를 만든 미스터 두브가 AI 에이전트로 만든, 끝없이 흘러내리며 접히는 반투명 천 데모입니다.

미스터 두브(Mr.doob)가 11월 한 달 동안 매일 주제어 하나로 작품을 올리는 Codevember 2026의 첫날 작품입니다. 첫 주제어는 '접기(Fold)'이고, 그는 이 시리즈를 에이전트 코딩으로 만드는 창작 실험이라고 소개했습니다.

왜 중요한가

  • 주요 3D 라이브러리를 만든 개발자가 챌린지 작품을 AI로 만들어 공개했습니다. 그래서 창작 챌린지에서 AI를 어디까지 받아들일지 논쟁이 붙었습니다.
  • 소스 코드도 함께 공개되어, 브라우저에서 천 시뮬레이션과 굴절을 어떻게 구현했는지 직접 볼 수 있습니다.

핵심 내용

  • 위에서 계속 내려오는 반투명 플라스틱 천이 바닥에 쌓이며 접히고, 마우스로 천을 끌 수 있습니다.
  • 천은 XPBD(제약 조건을 반복해 맞추는 물리 시뮬레이션 기법)로 늘어남, 굽힘, 자기 충돌을 계산합니다.
  • 위에서 새 줄을 공급하고 바닥으로 사라진 줄을 재활용해 천이 끝없이 이어집니다.
  • Three.js의 WebGPU 렌더러와 TSL(Three.js의 셰이더 작성 언어)을 썼습니다.
  • 굴절은 빛이 얇은 판을 지나는 것으로 단순화해 계산했고, 무지개 색은 천이 늘어나도 제자리에 붙어 있습니다.

HN 반응

  • 여러 이용자가 한 달 챌린지는 사람의 창의력과 실력을 키우는 자리라며 AI 결과물은 취지에 어긋난다고 지적했습니다.
  • 무엇을 만들지 정하고 다듬는 일도 창작이라며 사진가에 빗댄 반론이 나왔지만, 그림을 의뢰만 하는 사람과 무엇이 다르냐는 재반론이 이어졌습니다.

댓글

30개 표시 · 전체 118개
  1. OuterVale HN

    도메인에서 짐작하셨겠지만, 이건 Mr Doob이 만든 것입니다. 3D 자바스크립트 라이브러리 Three.js를 만든 것으로 가장 유명한 분입니다. https://threejs.org

    전체 사이트와 그가 만든 멋진 작품들은 여기에서 볼 수 있습니다. https://mrdoob.com

  2. treems HN

    아니면 아주 오래전에 Gravity Google을 만든 사람으로 더 잘 알려져 있죠.

  3. BrokenCogs HN

    저는 Doobs, 그러니까 페니스 앤서니 두비뇨인 줄 알았어요.

  4. brailsafe HN

    '실버 라이닝 게이북'[0]에 나오는 페니스 스칼렛 조핸슨 애널 말이에요?

    [0] https://youtu.be/YfJRWg9C_CY?si=lddua1cpDlrbGgq-

  5. joelanman HN

    이름은 헤드폰을 쓴 사람처럼 생겨서예요 - doob

  6. spartanatreyu HN

    이건 Mr Doob이 만든 것입니다

    저는 Mr Doob이 예전에 해 온 작업에는 고마움을 느끼지만, 이건 그가 "만든" 것이 아닙니다.

    AI가 내놓은 결과물을 그가 직접 공개한 것일 뿐입니다.

  7. plastic041 HN

    vibe coding으로 만든 프로젝트0에 codevember 해시태그를 다는 걸 막을 사람이 없다는 건 알지만... 이런 한 달짜리 챌린지(genuary, nodevember, inktober 등)의 핵심은 사람의 창의성 아닌가요? 게임잼처럼요.

  8. plastic041 HN

    계속 생각해 봤는데도 여전히 받아들이기 어렵네요. 생성형 AI로 그림을 만들어서 inktober 해시태그를 달아 올리는 것 같은 느낌이에요.

    '작가'가 생성형 AI를 이끌어서 창의성을 발휘하게 한 거고, AI는 그저 도구일 뿐이고, 어쩌면 그 과정이 그림 실력을 키우는 데 도움이 됐을 수도 있다고 말할 수 있겠죠.

    네, 동의해요. 그냥... 요즘은 취미로 하는 코딩 프로젝트에 예전만큼 설레지 않는 것처럼, 이제 코딩 챌린지 게시물을 봐도 예전처럼 감탄하지 못하게 돼서 그런 걸지도 모르겠어요.

  9. brainless HN

    경력 있는 엔지니어 중에도 LLM을 쓰는 사람이 많습니다. 그게 왜 아직도 낙인처럼 취급되는지 모르겠습니다. 우리 업계가 큰 변화를 겪고 있다는 건 이미 확립된 사실입니다. 멋진 실험을 만들면서 LLM을 쓰지 않는 사람이 있다면 오히려 놀랄 것 같습니다.

  10. F3nd0 HN

    그게 왜 아직도 낙인처럼 취급되는지 모르겠습니다.

    이런 한 달짜리 챌린지(genuary, nodevember, inktober 등)의 핵심은 사람의 창의성 아닌가요? 게임잼처럼요.

  11. handoflixue HN

    사람의 창의성은 "어떻게 만들까"가 아니라 "무엇을 만들까"에 들어갑니다.

    사진은 기계적으로 보면 100% 기계가 만든 것입니다. 그래도 우리는 무엇을 찍을지 고르고, 어떻게 구도를 잡고, 언제 셔터를 누를지 정하는 일을 한 사진가를 "창의적"이라고 부릅니다.

    솔직히 편집자들이 마침내 자신이 작업 과정에 불어넣는 창의성을 인정받기 시작했다니 멋진 일이라고 생각합니다. "스타워즈" 같은 유명한 영화가 편집 덕을 크게 봤다는 글은 많은데, 전통적으로는 편집이 "창의적인" 작업으로 인정받지 못했습니다.

  12. staffordrj HN

    그림을 주문하는 사람도 창의적이라고 봐야 합니까?

  13. zamadatix HN

    창의성은 창작 과정에서 무엇을 했느냐로 정해지는 것이지, 창작 과정 밖에서 다른 일을 했느냐 아니냐로 정해지는 것이 아닙니다. 즉, "작품 하나 만들어 주세요, $x 드릴게요"라고 말하는 것이 전부라면 창작에 관여한 정도는 0입니다. 돈을 냈기 때문이 아니라, 창작 과정에서 아무것도 하지 않았기 때문입니다.

    어떤 도구를 쓰든 마찬가지입니다. 이미지 편집기에서 사진마다 미리 만들어진 범용 "사진 처리" 버튼만 누른다면 창의적인 작업을 한 게 아닙니다(그 행위 자체가 일종의 메타 선언이라면 모르겠지만요). 반대로 여러 옵션과 설정을 만져 보면서 자신이 그리는 모습에 맞는 것을 찾았다면, 픽셀이 바뀌는 코드를 직접 짜지 않았고 그 부분을 해 주는 소프트웨어를 돈 주고 샀더라도 창작 과정에 한몫한 것입니다.

    LLM에 바로 적용해 봐도, "작품 좀 만들어 줘"라고만 하면 이 경우에도 창의적인 일은 하나도 하지 않은 것입니다. 마음에 드는 것을 가려내며 흥미로운 결과가 나올 때까지 반복하고 이것저것 해 본다면, 그 결과물의 창작 과정에서 제가 보기엔 가장 큰 몫을 한 것입니다(그 결과물을 구현하는 코드가 어디서 왔는지와는 상관없이요). LLM과 창의성이 헷갈리는 이유는, "작품 좀 만들어 줘"라고 해도 얼핏 보기에는 우리가 창의적인 예술이라고 기대하는 모습과 아주 비슷한 것이 나오기 때문(실제로 그런지, 이유가 무엇인지와는 상관없이)이라고 생각합니다. 그래서 LLM이 내놓은 것 중 창의적으로 보이는 것은 오직 LLM에게서만 나올 수 있다고 잘못 결론짓는 경우가 많습니다. 이미지 편집기에 범용 "사진 처리" 버튼이 있다고 해서 이미지 편집기로는 창의적인 일을 절대 할 수 없다고 가정하는 것과 같습니다.

  14. brainless HN

    그림을 주문할 때 장면이나 생각, 어떤 방향을 설명해야 한다면 그렇습니다.

    사진가가 하는 일이 문자 그대로 이겁니다. 대부분은 노출이나 다른 설정을 아예 만지지도 않습니다. "자동"으로 두죠.

  15. weakfish HN

    대부분은 노출이나 다른 설정을 아예 만지지도 않습니다. "자동"으로 두죠.

    프로 사진가라면 완전히 틀린 말입니다. 취미로 하는 사람이라면 모르겠지만요. 그래도 그런 사람이 많진 않습니다.

  16. xgulfie HN

    존경받는 사진가들은 버튼 누르는 것보다 훨씬 많은 일을 합니다. 다만 별생각이나 노력 없이 버튼만 눌러서 결과를 얻는 건 대체로 흥미로운 창작물이 못 된다는 데는 저도 동의하고, 대부분의 프로 사진가도 그럴 겁니다.

  17. xgulfie HN

    사람의 창의성은 "어떻게 만들까"가 아니라 "무엇을 만들까"에 들어갑니다.

    말도 안 되는 소리 아닌가요? 제가 "어, 정말 흥미로운 남자 그림이 있으면 멋지지 않을까?" 하고 마음먹는다고 해서 그게 흥미로운 창의적 표현이 되진 않잖아요.

  18. handoflixue HN

    편집이라는 측면을 한번 생각해 보세요. 영화 편집을 아예 그만둔다고 해도 예술적 가치가 전혀 사라지지 않을 거라고 정말 생각하세요? 아니면 편집자가 의견을 내는 것만으로도 가치를 더할 수 있다는 게 분명한가요?

    물론 의견을 얼마나 내느냐가 중요하긴 해요. "멋진 남자 그림"은 아주 일반적인 개념이니까요. 하지만 어느 시점부터는 아이디어를 적어 두는 것만으로도 창의적인 일로 쳐야 해요. 그러지 않으면 책은 전부 창의적이지 않은 게 되니까요.

  19. xgulfie HN

    편집이라는 측면을 한번 생각해 보세요.

    저는 ChatGPT가 아니니까 사람한테 그렇게 말하지 마세요. 제가 당신 대신 생각해 줄 의무는 없어요.

  20. acedTrex HN

    사람의 창의성은 "어떻게 만들까"가 아니라 "무엇을 만들까"에 들어갑니다.

    이보다 요점을 더 못 짚은 글은 본 적이 없는 것 같네요.

  21. embedding-shape HN

    동네에서 열리는 "도자기 만들기" 월례 챌린지에 머그잔을 찍어내는 로봇을 들고 나타난다면, 그래도 흥미로운 대화가 오가긴 하겠지만 주최 측에서 "이 행사의 취지를 제대로 이해하지 못하셨네요"라고 말할 거라고 예상합니다.

    여기서도 거의 똑같아요. 이런 "잼"이나 "챌린지"의 목적은 LLM이 그런 걸 할 수 있는지 확인하는 게 아닙니다. 할 수 있다는 건 뻔하고, 우리 모두 이미 알고 있으니까요. 핵심은 스스로 도전하고 스스로를 발전시키는 것입니다. 적어도 취지는 그렇습니다.

  22. colordrops HN

    그럴 수도 있겠지만, 이 사람은 그냥 Claude나 쓰는 애송이가 아니라 Three.js를 만든 사람이잖아요. 리누스가 리눅스 커널에 AI를 썼다고 깎아내리는 거나 마찬가지예요. 자기가 뭘 하는지 아는 사람이라고요.

  23. plastic041 HN

    그가 누구인지는 알고 있고, 그가 AI로 뭘 하든 신경 안 써요.

    저한테 이런 작은 챌린지는 프로그래밍 실력을 키우고, 창의성을 보여 주고, 무엇보다 재미로 하는 거예요. 그래서 'codevember'에 LLM을 쓰는 게 어색하게 느껴지는 거고요. 그를 탓한다는 뜻이 아니라, 제가 받아들이기 어렵다는 것뿐이에요.

  24. agilek HN

    코딩이 당신에게 아름다운 코드를 쓰는 일이라면 그렇겠죠.

    우리 중 많은 사람은 무언가를 만드는 일이 좋아서 이 바닥에 있어요.

  25. soon_to_be_sb HN

    그럼 "만드는" 일을 다른 사람에게 맡겨도 똑같은 기쁨을 느끼세요?

  26. Cthulhu_ HN

    소프트웨어 개발 업계에서 상당 부분은 코드를 타이핑하는 일이 아니라, 애초에 어떤 코드를 써야 하는지 알아내는 일입니다.

    건설에 빗대자면, 석공이나 목수에게 건축가가 되고 싶은지 물어보세요. (아마 그러고 싶지 않은 사람이 많겠지만, 제가 아는 기술직 중에는 철판 두 장을 용접하는 것보다 훨씬 많은 일을 할 수 있는 사람도 몇 있습니다. 그저 그 사람들의 직업이 용접 쪽일 뿐이죠.

    사실 이게 앞으로의 과제 중 하나가 될 겁니다. LLM의 도움을 받는 코딩 덕분에 사람들은 코드 노동자보다 의사결정자, 리드 개발자, 아키텍트 같은 역할을 더 맡을 수 있게 됐습니다. 하지만 피라미드 구조라서, 프로젝트 하나에 현실적으로 필요한 리드 개발자는 그리 많지 않습니다.)

  27. soon_to_be_sb HN

    사람들이 의사결정자, 리드 개발자, 아키텍트 같은 역할을 더 맡을 수 있게 됐다

    각각 앞에 "사이비"를 붙이면 완전히 동의합니다.

  28. bsenftner HN

    소프트웨어를 쓰고 그 소프트웨어를 컴퓨터에서 돌리는 것이 이 모든 일의 목적은 아닙니다. 목적은 이런 도구를 써서 컴퓨터 밖의 물리적 세계를 개선하고, 컴퓨터로 정신을 갈고닦은 다음 그것을 현실의 삶에 적용하는 것입니다. 컴퓨터는 친구도, 동료도, 적도 아닙니다. 지나치게 들뜬 사람들이 유명인 콤플렉스를 씌워 준 드라이버일 뿐입니다.

  29. JoshuaRogers HN

    회사에서 우리 팀이 구현하는 프로젝트를 정의하고 이끄는 데서 같은 만족감을 얻느냐고요?

    네. 코드를 쓰는 일도 늘 재미있었지만, 프로젝트를 운영하는 것 자체가 하나의 시스템 엔지니어링 문제입니다. 특히 프로젝트 범위를 직접 정하는 사람이라면 더 그렇습니다.

    그러니 네, 틀림없이 같은 수준의 기쁨입니다. 제가 쓴 코드는 낮은 수준의 문제를 풀기 위해 필요한 방법일 뿐이었고, 문제 공간 전체였던 적은 한 번도 없었습니다.

    사용자에게 보이는 디자인 곳곳에 제 지문이 묻어 있는 게 보이고, 사용자의 즐거움을 최대로 끌어올리려고 여러 접근법을 두고 고민했던 자리도 다 보입니다. 솔직히 해결책이 모습을 드러내는 걸 보는 건 짜릿합니다. 저는 LLM을 쓰는 사람들이 이 점에서 저와 비슷한 역할을 하고 있다고 봅니다.

    그렇긴 해도 모든 사람이 문제 공간 전체를 같은 정도로 즐기는 건 아니라는 걸 이해합니다. 낮은 수준의 일을 보람 있게 느끼는 사람이 있는가 하면 지루하게 느끼는 사람도 있듯이, 합리적인 사람들 중에도 높은 수준의 퍼즐이 낮은 수준의 퍼즐만큼 즐겁지 않은 이들이 있을 수 있다고 생각합니다.

  30. soon_to_be_sb HN

    LLM 사용 정도를 쭉 늘어놓은 스펙트럼에서, 내가 만드는 것을 제대로 이해하지 못하고 있다고 느끼는 지점이 있어요. LLM에게 코드를 조금 쓰게 하는 정도까지는 그런 느낌이 들지 않아요. 하지만 그건 아주 적은 양의 코드뿐이에요...

Hacker News에서 보기 ↗