모노스페이스 폰트가 꼭 필요한지 아직 결정하지 못했지만, 이전 버전보다 업데이트된 폰트가 확실히 개선된 것 같습니다 (이전 상황과는 반대로, 이제는 글자 크기를 약간 더 크게 해도 될 것 같습니다).
어쨌든, 예전부터 좋았던 ASCII 아트가 이제 다시 돌아올 수 있게 되어 기쁩니다 ![]()
|-----------|
| LONG LIVE |
| THE BUNNY |
|-----------|
(\__/) ||
(•ㅅ•) ||
/ づ
모노스페이스 폰트가 꼭 필요한지 아직 결정하지 못했지만, 이전 버전보다 업데이트된 폰트가 확실히 개선된 것 같습니다 (이전 상황과는 반대로, 이제는 글자 크기를 약간 더 크게 해도 될 것 같습니다).
어쨌든, 예전부터 좋았던 ASCII 아트가 이제 다시 돌아올 수 있게 되어 기쁩니다 ![]()
|-----------|
| LONG LIVE |
| THE BUNNY |
|-----------|
(\__/) ||
(•ㅅ•) ||
/ づ
이 주제에서 이전에 언급했듯이, 변경 사항에 대해 조금 더 시간을 두고 살펴볼 필요가 있습니다. 최소한 한 주 정도 더 기다려 주세요.
여기서 답은 확실히 '가능하다’입니다. 긍정적인 피드백이든 부정적인 피드백이든 계속 보내 주세요. 우리는 모든 내용을 읽고 있습니다.
내부적으로 고민하고 있는 문제 중 하나는 다양한 “페르소나”/"대상 독자"를 어떻게 타겟팅할 것인가입니다.
어려운 문제입니다. 우리는 사용자 설정을 더 추가하는 것에 대해 항상 신중하지만, 여기에 일리가 있다는 점은 인정합니다. 다만, 일주일 후 우리의 감도가 어떻게 변할지 지켜보고 싶습니다.
비침습적인 시각적 단서를 여러 가지로 고민해 봤는데, 쉽지 않네요. ![]()
허용할 수 있는 유일한 방법은 어딘가에 라벨을 붙이는 것 같습니다. 예를 들어:

그리고 시각적 기억을 돕기 위해 색상 변화를 주는 것도 좋을 것 같습니다:

비침습적이면서도 꽤 잘 보입니다. 물론 단점도 있습니다. 공간을 차지하긴 하지만, 일시적인 전환 기간이라면 괜찮을 것 같습니다. 100% 확신은 없지만, 흥미로운 대안이 될 수 있다고 생각합니다. 그냥 아이디어를 공유하고 싶었습니다. (GIF 파일을 새 탭에서 열어 전체 크기로 확인해 보실 수 있습니다. 전체 화면 버튼이 없어서요)
이건 왜인지 내가 들어본 반대 논거 중에서도 가장 좋은 것 같아요. 그래서 VS Code 에디터에서 해당 폰트를 직접 확인해 봤는데, 아, 저는 코더입니다. 데스크톱에 코드 에디터를 열어 두었는데, 역시나 등폭(monospace) 폰트였어요. 저는 그걸 전혀 눈치채지 못했거든요. 그런데 왜인지 여기에서, 그리고 제 인스턴스에서는 어색하게 느껴져요. 샘이 말한 대로 일주일만 써볼게요. 변화가 당혹스럽긴 하지만, 일주일 후에는 아무것도 느끼지 못할지도 모르거든요.
동의합니다. 방금 정말 긴 글을 썼는데, 솔직히 모노스페이스 폰트가 두통을 유발합니다. 저는 글을 매우 꼼꼼하게 교정하는데, 그러다 보니 원본 마크다운과 포맷된 글 사이를 오가며 읽는 경향이 있습니다. 그런데 이제 에디터 섹션에서 그렇게 하는 것이 매우 어렵습니다.
또한 일반적으로 WYSIWYG를 좋아하지 않습니다. 제 경험상 WYSIWYG는 매우 버벅거리고, 저는 그것을 사용할 의사가 전혀 없습니다. 따라서 저에게는 영원히 존재해 온 마크다운 에디터가 매끄러운 사용자 경험을 유지해야 합니다.
@schneeland의 의견에 동의합니다. 저는 소프트웨어 엔지니어이며, 당연히 모노스페이스 폰트를 사용하는 IDE를 정기적으로 사용하지만, 이것은 단순히 다른 맥락입니다. Jira가 갑자기 모노스페이스 폰트를 사용하기 시작한다면 정말 어색할 것입니다.
마크다운에서 테이블을 작업하는 데 문제를 겪어 본 적이 있는지 모르겠습니다. 그리고 무엇보다, 모노스페이스를 사용하더라도 각 셀에는 서로 다른 길이의 텍스트가 들어갈 가능성이 높으므로 열 사이의 세로 막대가 정렬되지 않습니다.
어쨌든, 이 변경 사항이 조금 더 자리를 잡게 두기를 원한다는 것은 압니다. 하지만 이 피드백이 도움이 되길 바랍니다. 제 코멘트는 최근의 모노스페이스 폰트 기준으로 작성되었으며, 이전 버전은 보지 못했습니다. 따라서 저는 며칠 전 사용된 첫 번째 모노스페이스 폰트가 아니라, 수년 동안 존재해 온 경험과 비교하고 있는 것입니다.
이러한 이점을 정당화할 정도로 실제로 포럼 답변에서 표를 사용할 사람이 얼마나 될까요? 또한 Obsidian은 마크다운을 사용하며, 표 내부에는 모노스페이스 폰트를, 표 외부에는 산세리프 폰트를 사용하고 있습니다:
두 폰트가 공존할 수 있는데, 왜 작성기 전체를 모노스페이스로 바꿔야 하는지 이해가 되지 않습니다.
우리가 작성하는 것의 99%는 마크다운이 아닌 “일반” 텍스트라고 생각합니다.
솔직한 제 의견으로는, 사용자가 숨 쉴 틈을 주도록 허용하더라도 이 기능을 사용자에게 "강제"하는 것은 좋은 기능이 아닙니다. 이는 사용자가 안도감을 느끼는 변경 사항이 아니며, 대부분의 댓글에서 이를 확인할 수 있습니다. 이는 사용자 설정(옵션)이어야 합니다.
작성기가 미리보기와 동일한 글꼴을 사용하는 데에는 아무런 문제가 없다고 봅니다. 무슨 일이 일어나고 있는지 이해하는 것이 꽤 쉽기 때문입니다. 이미 수년간 그래왔지 않나요? "고치지 않으면 안 되는 것이 아니다(If it’s not broken, don’t fix it)"라는 말이 있듯이, 여기에도 해당한다고 생각합니다.
이 변경 사항에 어려움을 겪고 있는 분들을 위해 한 가지 추천을 드립니다:
미리보기 기능을 비활성화하고 며칠 동안 사용해 보세요.
미리보기가 비활성화되면 글꼴 변경이 훨씬 더 자연스럽게 느껴집니다.
아직 피드백을 수집 중이며, 모든 것이 100% 확정된 것은 아닙니다. 여기에 사용자 설정 옵션을 더 추가할 수도 있으며, 아직 알 수 없습니다.
이 글꼴은 https://<site>/admin/config/fonts에서 설정할 수 있어야 하지만, 현재는 설정할 수 없습니다.
모노스페이스 폰트가 마음에 들지 않아서(코딩에는 좋지만 포럼에 글쓰기에는 부적합) 제 테마에 아래 CSS를 추가해서 원래대로 되돌렸습니다(더 나은 방법이 있으면 알려주세요!)
.d-editor-container--rich-editor-enabled .d-editor-textarea-wrapper textarea.d-editor-input {
font-family: var(--font-family) !important;
font-size: var(--base-font-size) !important;
line-height: var(--line-height-large) !important;
}
이 기능은 사용자 설정으로 제공되어야 한다고 생각합니다. 가독성 있는 글꼴을 사용하려면 WYSIWYG 뷰를 사용해야 한다는 강제 사항은 없어야 합니다. 저에게 단색 글꼴은 코드 외의 일반 텍스트를 읽는 데 거의 불가능합니다. 특히 모바일에서는 미리보기와 편집 화면을 나란히 볼 수 없어 이 문제가 더욱 두드러지지만, 데스크톱에서도 여전히 불편합니다. 모든 사이트 관리자가 이러한 사용자 피드백에 응답하지 않을 수 있으므로, 사이트 설정이나 CSS 오버라이드만으로는 충분하지 않다고 봅니다.
전적으로 동의합니다 (동의의 뜻을 전하기 위해 계정도 만들었습니다!).
Markdown은 자동으로 줄바꿈을 처리하고, "문서 처리"와 “코드” 사이의 경계를 흐리게 만드는 다른 속성들을 가지고 있습니다. 토론 포럼에서는 분명히 문서 편집기에 더 가깝고… 저는 과거의 동작 방식에 대해 꽤 만족해 왔습니다. 모호함 없이 자유롭게 복사하고 붙여넣을 수 있는 점을 좋아했습니다. WYSIWYG 편집기가 제가 무엇을 의도했을지 상상하는 것보다는, 엔터를 치면 바로 줄바꿈이 되는 것을 선호합니다.
고정 폭 폰트를 사용하여 Markdown 편집을 하는 것은 편집 기능이나 즐거움을 더해주지 않습니다. 오히려 나빠지죠… 실제로 Markdown을 사용하는 사람은 누구나 동의할 것입니다.
결국 Markdown은 현재, 어떤 모드에 있는지 시각적으로 강조하기 위해 2급 시민 취급을 받고 있습니다.
여러분 중 UX 디자이너분들께 질문드리고 싶습니다. 거의 항상 나쁜 트레이드오프인, 대부분 코드가 아닌 텍스트를 편집할 때 고정 폭 폰트를 사용하는 것을 요구하지 않으면서, 모드를 더 잘 강조할 수 있는 더 나은 방법이 있는지요.
그런 좋은 답이 나온다면, 고정 폭과 비고정 폭을 전환할 옵션은 필요 없을 것입니다. 왜냐하면 항상 비례 폰트가 사용될 테니까요.
정당한 지적 두 가지입니다!
우리가 "잠시 시간을 두자"고 한 지 꽤 많은 시간이 흘렀습니다. 보시는 것처럼, 이 변화는 우리 모두가 "놀라운 변화!"라고 말한 것은 아닙니다.
다른 누군가가 말했듯이, 이 변화에 대한 엄청난 수요가 있었나요? 저는 잘 모르겠습니다… 아마도 아니었을 것이라 생각하지만, 제가 틀렸을 수도 있겠지요.
마크다운을 “코딩” 언어로 보고 모노스페이스(고정폭) 폰트를 정당화하려는 시도는 제 생각에는 큰 의미가 없습니다. 저는 마크다운을 “코딩” 언어라기보다는 텍스트를 서식 처리하는 수단으로 봅니다. VS Code, Cursor 등 모노스페이스 폰트가 적절한 개발 도구를 사용하는 것과 달리, 마크다운을 사용한다고 해서 반드시 개발자일 필요는 없으니까요.
포럼에서 새 주제나 답변을 작성할 때 우리는 "코딩"을 하는 것이 아니라 "텍스트"를 작성하는 것입니다. 그리고 텍스트는 읽기 편해야 합니다. 모노스페이스 폰트는 그저 읽기 편하지 않습니다. 마크다운 편집기에서 150단락의 글을 작성하더라도 마크다운 “구문”(그렇게 불리는 것이라면요)을 전혀 사용하지 않을 수 있습니다. 그래서 저는 마크다운을 모든 것이 반드시 따라야 할 "서식"이라기보다는, 텍스트를 서식 처리할 때 사용할 수 있는 추가적인 도구로 봅니다. 이 설명이 의미가 있다면 말입니다.
이 내용을 CSS에 추가하세요 @seanblue & @alltiagocom. 이렇게 하면 작성기를 사이트 기본 설정으로 되돌릴 수 있습니다.
/* Changes the font in the composer from monospace back to the san-serif default */
.d-editor-container .d-editor-textarea-wrapper textarea.d-editor-input {
font-family: var(--font-family);
font-size: 1rem; /* or use 16px, or your specific default size */
}
저는 사용자에게 선택권을 주는 것을 지지합니다. 어떤 사용자는 모노스페이스 폰트를 원할 수도 있죠. 저는 잘 모르겠습니다. 저는 일부 아주 기이한 VS Code 테마(예: 검은색 글씨가 들어간 초록색 배경, 혹은 그보다 더 심한 경우)를 본 적이 있는데, 저는 절대 그런 것을 사용하지 않을 것입니다. 하지만 사람은 사람마다 다릅니다.
저는 제 설정을 분명히 산세리프로 변경할 예정입니다. 하지만 제가 여기서 드리고 싶은 메시지는, 사용자에게 이러한 옵션을 제공할 수 있다는 것입니다. 그것뿐입니다. 어떤 사용자는 마크다운에 모노스페이스를, 어떤 사용자는 산세리프를 원합니다. 또 어떤 사용자는 마크다운에는 관심이 없고 리치 텍스트만 원합니다. 제 생각에, 이러한 옵션을 네이티브로 지원하는 것이 더 나은 선택이 될 것입니다.
저는 디스코urse 직원으로서 편향되어 있지만, 저는 새 모노스페이스 폰트를 훨씬, 훨씬 더 선호합니다. 따라서 “아, 괜찮네”라고 하거나 심지어 “음, 몰랐네”라고 하는 사람들이 의견을 내지 않을 가능성이 높습니다.
우리 중 적어도 수십 명은 그렇게 생각할 것입니다 ![]()
물론이죠. 밖에 개발자와 코더들이 정말 많으니까요 ![]()
(하지만 일반인들에게는 모노스페이스 폰트를 가독성 좋은 폰트로 보지 않습니다. 저와 제 사용자들에게는 CSS 트릭이 역할을 했기 때문에, 저 같은 관리자 입장에서는 이것이 더 학술적인 문제입니다. 하지만 이 변경이 다수를 위해 이루어졌고 널리 사용된다고 말하는 것은 중단합시다. 그것은 사실이 아니므로요.)
당신에 대해 사실이 아닌 가정들을 하고 있는 것 같아 ![]()
동의합니다. 등폭 글꼴은 예상치 못한 부분일 뿐만 아니라 보기에도 안 좋습니다. 또한 불필요합니다. 이미 도구창에 우리가 어떤 모드에 있는지 알려주는 슬라이더가 있습니다.
글쎄요, 저는 안 했어요. 모든 것이 당신에 의해, 또는 당신을 위해 이루어진 건 아니었으니까요.
어쨌든요. 컴포저에서 두 가지 옵션을 유지하는 것은 훌륭한 해결책이었습니다. 모노스페이스는 그렇지 못했지만, CSS 변경이 제대로 작동하기만 하면 저는 만족합니다. 하지만 그런 사용자 설정을 두는 취지는 이해해요. 다만, 이미 설정할 항목이 꽤 많은데다, 일반 사용자들이 실제로 설정을 변경하는 경우가 얼마나 될지 확신이 안 서서요… 결국 얼마나 복잡하든 상관없겠지요 ![]()