이것이 디자인 문제인지 확실하지 않지만, 일단 이 카테고리에 올립니다.
리치 텍스트 편집기에 이미지를 업로드할 때:
후자의 시나리오는 클릭 여부와 관계없이 드래그하면 이미지가 다시 업로드되는 것이 아니라 위치가 이동해야 한다고 생각하기 때문에 혼란스럽습니다. 
이것이 버그가 아니라 의도된 디자인이라면, 반복 업로드가 사용되는 시나리오에 대해 알려주시면 감사하겠습니다. 
이 문제를 재현할 수 없어요 
다른 누군가는 재현할 수 있을지도 모르겠네요.
어떤 브라우저를 사용 중이세요?
Edge 브라우저, 버전 145.0.3800.82, 방금 148.0.3967.54로 업데이트했지만 개선되지 않았습니다.
네, 다른 누군가가 성공적으로 재현할 수 있기를 바랍니다. 
저는 이 문제가 실제로 존재한다는 것만 확인할 수 있을 뿐, 구체적인 원인은 알지 못합니다.
처음에는 제 웹사이트에서 한 사용자가 업로드한 이미지를 드래그할 때 이 문제를 겪었다며 제게 불평을 했습니다. 당시에도 제가 직접 그 사용자가 이미지를 업로드할 때 사용한 마크다운을 복사하지 않는 한 재현이 어려웠습니다. 이 문제는 웹사이트와 첨부파일 자체(문제가 있는 이미지들은 모두 PNG 파일인 것 같습니다) 모두와 관련이 있는 것으로 보이며, Meta에서도 재현할 수 없었습니다(같은 첨부파일을 Meta에 업로드해도 마찬가지였죠). 그래서 이 문제는 일단 보류되었습니다.
이 토픽을 만든 날, 갑자기 영감이 떠올라 영상에 있는 Discourse 기본 로고의 PNG 이미지를 시도해 보았고, 마침내 Meta에서 문제를 재현하는 데 성공했습니다. 혹시 을 사용해 몇 가지 시도를 해보실 수 있을까요?
요약하자면, 이것은 트리거를 유발하기가 매우 어려운 경계선 사례이지만, 일단 트리거가 되면 같은 사이트의 같은 첨부파일에 대해 안정적으로 재현됩니다.
아니요, 죄송하지만 어떤 방식으로 드래그를 시도해도, 예시 로고를 사용하더라도 문제를 재현할 수 없습니다.
테스트할 Edge 브라우저가 준비되어 있지 않아 브라우저 관련 문제일 수도 있습니다. Chromium 기반 브라우저에서 테스트해 주실 수 있을까요?
안녕하세요, Edge(버전 148.0.3967.54 (공식 빌드) (64비트))에서 이 버그를 재현하기 위해 시도하고 있습니다…
이것은 RTE에서 제가 업로드한 고양이 사진으로, 이 텍스트 위로 끌어 올려진 상태입니다.
…아래에 고양이 사진을 업로드 중입니다…
이것은 고양이 이미지 뒤의 텍스트입니다
Edge가 Chromium 기반 브라우저가 아닌가요?
음… 이 버그를 재현해 보려고 했는데, 아직까지는 실패했습니다. 조금 더 구체적으로 알려주시면 다시 시도해서 결과를 보고드리겠습니다.
이해가 안 되네요 – 먼저 클릭하지 않고 어떻게 드래그할 수 있나요?
게시글에 가 두 번 등장하는 것을 확인했습니다. 이는 성공적인 재현의 결과인가요? 즉, 작은 로고로는 재현할 수 있지만, 고양이 사진으로는 재현할 수 없다는 말씀이신가요?
먼서 커서를 다른 텍스트 위에 배치한 다음, 이미지에서 왼쪽 마우스 버튼을 누른 채로 직접 드래그하세요. 먼저 클릭(그리고 놓은) 후 드래그하면 실제로 이미지가 선택됩니다.
네, Edge에서 RTE를 사용하고 새로 시작해서 시도해 보고 있습니다…
아래에 새 이미지를 업로드하는 중입니다…
… 그리고 이제 이미지를 아래 다음 단락 아래로 드래그하는 중입니다..
여기가 다음 단락입니다…
이것은 다음 단락입니다. 이제 이미지를 여기 아래로 드래그하겠습니다…
위 테스트(최신 Edge에서 수행했으며, Discourse 편집기에서 RTE를 사용)에서 이전에 업로드된 이미지를 드래그했을 때 올바르게 동작하는 것 같았습니다. 다시 업로드해야 한다는 표시는 보이지 않았거든요?
아마도 님은 이 버그를 경험해본 적이 없을 만큼 운이 좋으신 분일 수 있습니다 하지만 어쨌든, 아래 영상에서는 KeyCastOW를 사용하여 업로드와 이동이라는 두 가지 작업을 트리거하는 키 입력 흐름을 시연하고 있습니다. 이를 통해 해당 프로세스를 명확하게 이해하실 수 있도록 했습니다.
참고로, 님의 고양이 이미지()와 다른 이미지()를 테스트해 보았지만, 두 이미지 모두 이 문제를 트리거하지 않았습니다.
테스트를 위해 를 사용하시기를 권장합니다. 적어도 저에게는 이 문제를 안정적으로 재현할 수 있는 테스트 자료로 알려져 있습니다. 이 자료로 문제를 재현할 수 없다면, 아마도 님은 정말로 운이 좋으신 분인 것 같습니다. 
이 문제가 해당 이미지로만 제한되는 것일까요?
아래 2개는 RTE 모드에서 composer에 붙여넣기한 것입니다…
아래 2개는 Markdown 모드에서 composer에 붙여넣기한 것입니다
!\[image\](/images/discourse-logo-sketch-small.png)
후자의 시나리오에 대해, 이미지가 2개의 다른 인스턴스/복사본으로 업로드되고 서버에 2개의 파일이 저장된다는 말씀인가요?
아니면, 붙여넣은 이미지는 실제로 서버에 업로드되지 않으며, (업로드 후) 클릭해야만 비로소 업로드되고 저장된다는(그리고 그때는 이미지의 해당 인스턴스/파일 하나만 서버에 업로드되고 저장된다는) 말씀인가요?
아니요, 제 웹사이트에서 이 문제를 재현할 수 있는 이미지가 여러 개 있지만, 저는 Meta에 대해 많은 조사를 하지 않았고, 지금까지 이 경우 하나만 발견했습니다.
아니요, 사실 Discourse는 우리가 생각했던 것보다 더 지혜롭습니다. 예를 들어:
제 웹사이트에서 사용자가 이미지를 업로드하면, 마크다운 편집기에서는 다음과 같이 표시됩니다:
...
...
브라우저의 개발자 도구를 통해 전체 링크를 확인했습니다: https://example.com/uploads/default/original/1X/8826bc6c1be0e501979df4a004b9b2ae51c50320.jpeg. 그래서 편집기에서 전체 링크 형식으로 이미지를 참조했습니다:
리치 텍스트 편집기에서 클릭하지 않고 드래그하면(업로드가 트리거됨), 마크다운 편집기의 콘텐츠는 다음과 같이 변합니다:
Discourse가 드래그가 업로드를 트리거한다고 표시하지만, 이미지는 실제로 로 나타나며, 이는 해당 사용자가 원래 https://example.com/uploads/default/original/1X/8826bc6c1be0e501979df4a004b9b2ae51c50320.jpeg로 업로드한 것과 동일한 첨부 파일에 해당합니다.
 형식으로 참조된 이미지를 드래그해도 동일한 처리가 적용됩니다.이 관점에서 보면, 업로드를 다시 트리거해도 실제로는 추가적인 저장 공간을 차지하지 않습니다 — 처음 업로드된 파일만이 서버 저장 공간을 실제로 차지합니다. 따라서 이는 단순히 사용자 경험 문제입니다: "이미지를 드래그할 때(클릭한 후 마우스를 놓지 않고 드래그하는 경우) 예상대로 이동하지 않고, 왜 업로드 진행 중이 표시되고 이미지가 중복되는가?"라는 혼란을 겪는 것입니다.
그렇다면, 지금은 (좋은 소식이지만!) 이미지가 실제로 반복적으로 업로드되는 것이 아니라, 단지 하나의 인스턴스만 업로드되는 것 같다는 결론을 내릴 수 있을 것 같습니다.