15년이 지나 Microsoft가 내 다이어그램을 ‘morged’했다
(nvie.com)- Microsoft의 공식 Learn 포털에 게시된 다이어그램이 과거 널리 알려진 Git 브랜칭 모델 도식과 매우 유사하다는 지적이 제기됨
- 원작자는 2010년에 해당 다이어그램을 직접 제작해 공개했으며, 이후 서적·강연·블로그·팀 위키·YouTube 등에서 폭넓게 사용되어 왔음
- Microsoft가 이를 AI 이미지 생성기로 변형해 출처 없이 게시한 것으로 보이며, 결과물에는 “continvoucly morged” 같은 오타와 잘못된 화살표 등 조악한 품질이 드러남
- 작성자는 단순한 사용보다 과정과 세심함의 결여, 즉 타인의 정교한 작업을 기계로 희석해 자기 것처럼 배포한 행위를 문제로 지적함
- 그는 출처 표기와 원문 링크 제공만으로 충분하다고 밝히며, 향후 이와 같은 AI 기반 표절 콘텐츠 확산에 대한 우려를 표함
Microsoft Learn 포털에서의 사건
- 최근 Microsoft Learn 포털에 게시된 다이어그램이 2010년 작성된 Git 브랜칭 모델 도식과 매우 유사하다는 사실이 Bluesky와 Hacker News를 통해 알려짐
- 원작자는 당시 Apple Keynote로 직접 디자인하며 색상, 곡선, 배치 등을 세밀히 조정해 브랜치 관계를 명확히 표현함
- 원본 소스 파일도 공개해 누구나 활용할 수 있도록 했으며, 이후 인터넷 전반에 널리 퍼짐
- Microsoft가 15년 후 해당 도식을 AI 이미지 생성기로 변형해 게시한 것으로 보이며, 출처나 링크 표기 없이 사용됨
AI 생성물의 품질 문제
- 변형된 다이어그램은 원본의 시각적 언어와 레이아웃을 잃고, 색상·선로·점 정렬 등이 흐트러진 형태로 표현됨
- 일부 화살표가 누락되거나 방향이 잘못되었고, “continvoucly morged”라는 문구가 포함되어 AI 생성물의 흔적이 명확함
- 작성자는 이를 “AI slop”이라 표현하며, Microsoft 수준에 어울리지 않는 부주의한 결과물이라 평가함
커뮤니티 반응과 밈 확산
- 다이어그램의 형태가 원본과 충분히 유사해 사람들이 즉시 인식했고, Microsoft의 표절 의혹을 제기하며 원작자에게 연락함
- “continvoucly morged”라는 문구는 인터넷 밈으로 확산되었으며, 많은 이용자들이 원작자를 지지함
문제의 본질과 우려
- 작성자는 단순한 재사용이 아니라, 타인의 세심한 작업을 기계로 세탁해 열화된 형태로 배포한 행위를 문제로 지적함
- 이는 “영감을 받아 발전시킨 것”이 아니라, “잘 작동하던 것을 망가뜨린 것”이라고 표현함
- 그는 이번 사례가 유명한 도식이라 쉽게 표절로 인식되었지만, 앞으로는 덜 알려진 콘텐츠가 AI로 변형되어 식별이 어려워질 위험이 있다고 경고함
요청과 마무리
- 작성자는 원문 링크와 출처 표기만으로 충분하다고 밝힘
- Microsoft Learn 페이지가 어떻게 만들어졌는지, 제작 과정과 검수 절차가 있었는지에 대한 설명을 요구함
- 글은 “Till next 'tim'.”이라는 문구로 마무리됨
Hacker News 의견들
-
원래의 git-flow 모델에 대해, 왜 굳이 ‘develop’ 브랜치에서 통합 작업을 하고 ‘main/master’는 단지 릴리스 태그만 붙이는 용도로 쓰는지 이해가 안 됨
차라리 ‘main’ 브랜치를 통합용으로 쓰면 깔끔할 것 같음. 태그로 최신 릴리스를 구분할 수 있는데 굳이 ‘develop’이 필요할까 싶음
‘feature’, ‘release’, ‘hotfix’ 브랜치 개념은 훌륭하지만, ‘develop’만큼은 이상한 유물처럼 느껴짐- 맞음. 당신이 말한 건 사실상 trunk-based development임. 훨씬 낫다고 생각함
git-flow가 유행한 건 이름과 다이어그램이 멋져서였다고 봄. 비판하면 “표준인데 왜 바꾸냐”는 반응이 돌아옴
더 나은 접근으로 trunkbaseddevelopment.com을 참고할 수 있음 - 나는 ‘main/master’로만 수년간 작업해왔는데, ‘develop’이 없으면 생기는 문제도 있음
‘master’에 머지하면 QA가 끝날 때까지 다음 릴리스를 막게 됨. 반면 ‘develop’에서는 독립적인 변경을 cherry-pick해서 원하는 순서로 릴리스할 수 있음 - 이 모델은 예를 들어 3.2 버전을 개발하면서 동시에 3.1 버전을 유지보수해야 할 때 유용함
- 결국 차이는 릴리스 프로세스에 달려 있음
제품 기반 팀이라면 릴리스된 커밋을 명확히 표시할 수 있는 브랜치가 필요함. 태그만으로도 충분하지만, 브랜치로 관리하면 hotfix 적용 시점까지 추적 가능함 - git-flow의 복잡함은 여러 버전을 동시에 유지해야 하는 상황에서 빛을 발함
요즘 SaaS 환경에서는 드물지만, 보안 패치나 백포팅에는 여전히 유용함
대부분의 경우엔 trunk 기반 개발과 feature 브랜치만으로 충분함
- 맞음. 당신이 말한 건 사실상 trunk-based development임. 훨씬 낫다고 생각함
-
요즘 AI 생성 콘텐츠가 너무 심각해짐
Los Alamos 영상도 가짜 이미지였고, GG-1 기관차 다큐도 AI 이미지로 엉망이었음
YouTube 썸네일까지 AI가 엉터리로 만들고, 잘못된 조언을 하는 영상이 넘쳐남
이런 자료들이 다시 LLM 학습 데이터로 들어가면 악순환이 생김- 사실의 출처 체인을 유지하는 건 어렵고 비용이 큼. 그래서 사람들은 그냥 듣기 좋은 거짓을 만들어냄
결과적으로 진짜 피해는 남에게 돌아감 - 나도 YouTube에서 Feynman이 화성 왕복 불가능성을 설명한다는 영상을 봤는데 완전 가짜였음
목소리도 텍스트도 전부 합성된 거였고, “그의 물리학 강의를 기반으로 했다”는 변명만 덧붙여져 있었음 - “GG-1 다큐” 얘기하니 혹시 그 유명한 공학 재난 팟캐스트 얘기 아님?
- 사실의 출처 체인을 유지하는 건 어렵고 비용이 큼. 그래서 사람들은 그냥 듣기 좋은 거짓을 만들어냄
-
해외에서 AI로 조작된 상품을 받은 적 있음
아이 방에 행성 러그를 주문했는데, 글자가 망가진 AI 이미지가 인쇄된 제품이 옴 (예: MARS → MɅPS)
다행히 환불받고 다른 판매자에게서 제대로 된 걸 구입했음
요즘 일부 상인들이 AI로 남의 디자인을 대충 베끼는 듯함- 우리 가족도 비슷한 일 있었음. Amazon에서 “hug in a box”를 주문했는데, 도착한 건 “hug in a boy”라고 적혀 있었음
사진에서도 오타를 물체로 가려놨더라. 웃기지만 황당한 경험이었음 - 그래서 요즘은 오프라인 쇼핑으로 돌아감. AI 쓰레기 상품을 걸러내는 게 너무 피곤함
조금 더 비싸도 직접 보고 사는 게 마음 편함
- 우리 가족도 비슷한 일 있었음. Amazon에서 “hug in a box”를 주문했는데, 도착한 건 “hug in a boy”라고 적혀 있었음
-
원래의 다이어그램은 삭제됐지만 archive.is/twft6에 보관돼 있음
- 봤는데 생각보다 훨씬 엉망이었음. 화살표 방향, 주석, 버블 전부 뒤죽박죽임. 이런 게 공개됐다는 게 놀라움
- 새 다이어그램은 이번엔 Atlassian의 것을 베꼈다는 말도 있음
관련 링크 - 이건 전형적인 AI 이미지 모델의 기억 복제 현상 같음. 원본을 거의 그대로 베끼고 약간만 수정한 수준임
-
“continvoucly morged”라는 표현이 너무 완벽하게 상황을 요약함. 시적임
- 마치 누군가 AI를 억지로 삼키며 말하는 소리 같음
- Raymond Chen이 “Microspeak: Morged”라는 블로그를 쓸 것 같다는 농담도 나옴
- 처음엔 ‘morged’가 새로운 슬랭인 줄 알았음. 놀라움
- AI를 놀리지 말자는 농담도 있었음. “AI도 감정이 있다”면서 새로운 지배자를 환영한다는 식의 유머였음
- 수십 년간의 공개 지식과 코드가 이제 ‘morg’ 속으로 흡수되고 있음. 저항은 무의미함
-
사실 이 사태가 웃기면서도 무섭다고 느낌
AI가 위험한 이유는 자의식 때문이 아니라, 무책임한 사용자의 확신 때문임- “Automatic Soldier Sveijk” 같은 풍자적 표현도 나옴
- 결국 시스템의 가장 약한 고리는 인간임
- 문제는 무능이 아니라 무관심임. AI는 오히려 쓸모없는 일을 더 강화시킴
-
Microsoft의 부사장이 Bluesky에서 해명글을 올림
관련 글 링크
“벤더가 만든 자료이며, 원인을 조사 중이고 곧 삭제할 것”이라 했지만, 이런 변명은 공허하게 들림
이런 규모의 조직에서 이런 오류가 공개까지 간 건 시스템적 실패임- “모든 게 너무 빠르게 움직인다”는 말에 대한 답은 간단함 — 속도를 늦춰야 함
이런 통제 부재로 언젠가 더 큰 사고가 날 것임 - 회사 규모가 품질을 보장하지는 않지만, 가치 있는 기업이라면 이런 실수를 반복해선 안 됨
Microsoft의 최근 실수들이 누적되며 시장 가치에 의문이 생김 - 실제로는 벤더가 작성한 문서를 repo owner 한 명이 승인만 하면 게시됨
검토 절차가 거의 없다는 점이 문제임 - 이런 사소한 다이어그램엔 사후 분석(postmortem) 을 하면서, 정작 Copilot 같은 핵심 제품엔 안 하는 게 아이러니함
- ‘morged 다이어그램’ 하나에 포스트모템이라니, 웃기지만 교훈적임
- “모든 게 너무 빠르게 움직인다”는 말에 대한 답은 간단함 — 속도를 늦춰야 함
-
Microsoft는 왜 항상 반쯤 완성된 결과물만 내놓는지 모르겠음
AI로 만든 그래프라도 Paint로 고칠 수 있었을 텐데
exFAT처럼 표면상 잘 돌아가지만 속을 보면 엉망인 사례가 너무 많음- “Microsoft답다”는 말이 딱 맞음. exFAT은 Mac, Linux, Windows 모두에서 돌아가지만 여전히 불편함
그래도 어쩔 수 없이 쓸 수밖에 없음
- “Microsoft답다”는 말이 딱 맞음. exFAT은 Mac, Linux, Windows 모두에서 돌아가지만 여전히 불편함
-
LinkedIn도 요즘 AI 생성 슬라이드로 도배됨
ChatGPT로 “더 좋게 만들어줘” 한 결과물들이 문법도 엉망이고 그래프도 말이 안 됨
특히 에너지 업계는 데이터센터 붐 덕에 이런 콘텐츠가 넘쳐남 -
wiktionary의 morg 항목을 보면 영어 단어는 아니지만 아일랜드어에는 있음
AI가 이런 뜻밖의 혼돈을 만들어내는 게 오히려 매력적임
예를 들어 내가 만든 QWOP 클론은 다리가 헬리콥터처럼 돌아가며 하늘로 날아감. 의도치 않았지만 멋졌음
그래서 일부러 버그를 기계적으로 재도입하는 실험을 하고 있음. 아직은 말도 안 되는 결과만 나오지만 흥미로움- 하지만 이런 혼돈을 즐길 여유가 없는 초보 개발자 입장에선 혼란스러울 것임
- ‘morg’가 영어에 없지만 ‘morgue’와 비슷해서 익숙하게 느껴지는 것 같음
- 유머러스한 결과는 좋지만, 실제 문제 해결 중에는 방해가 됨.
약간의 혼돈을 일부러 넣은 LLM을 만드는 건 어렵지 않겠지만, 나는 정확한 출력을 더 선호함