1. 개요
해당 문서는 정보전달의 주관성 문제 외적인 문장의 완성도 문제를 중점으로 서술한다.가독성이란 장문의 글에서 독자를 배려하기 위한 글의 생명과 다름없는 요소로서 장문의 글이 대다수를 차지하는 나무위키도 예외는 아니다. 그럼에도 구 리그베다 위키 시절부터 유전된 고질적인 문제점은 문서 곳곳에 묻어나고 있으며 현재도 수면 위로 드러난 나무위키의 분위기에 적응하지 못하는 유저의 기여도 발견되곤 한다.
혹은 문서 작성 능력이 부족한 초보들의 실수, 일일이 지키기에 단순한 귀차니즘과 대충 적어도 되겠지란 마인드 또한 무시할 수 없고 이들을 위한 피드백이나 수정도 활발히 이뤄져야 하건만, 이마저도 미진한 것이 현실이다. 위키 유저로선 가독성 문제를 준수하고 이를 지킬 것과 동시에 문제되는 가독성을 활발하게 수정해나가는 것이 바람직한 자세다.
이 문단에 나온 가독성 저하 서술은 대부분 나무위키 편집지침에 의거 금지되어 있으므로 해당 서술을 작성할 시 단순히 가독성만 떨어지는 것이 아니라 관리자의 제재를 받을 수도 있다. 또한 가독성 개선 프로젝트 참가자들은 이와 같은 서술을 제거하는 작업을 하고 있다.
2. 무차별적 기여와 이에 따른 문서의 비대화
나무위키는 '문서의 내용을 꼼꼼히 읽어보고 이게 맞게 보완 및 수정'할 것을 권하고 있지만, 악질 서술자는 그저 '기여'하는 점에만 주안점을 맞춘 나머지 이런 권고는 무시당하기 십상이다. 개인적인 정보 전달의 성취감이 독자를 위한 배려를 고려하지 않고 나타나는 부작용. 문서는 분명 비대화해졌지만 문서 간 교집합, 겹치는 정보를 쳐내면 실질적인 알맹이는 기하급수적으로 줄어간다. 결국 아무런 필터링 없이 중복되는 서술이나 뉘앙스가 추가되어 독자 입장에서는 어디선가 읽어본 듯한 서술만을 반복해서 읽는 불편함을 겪기 마련이다. 내실도 없이 몸집만 불어난 문서에선 건질 만한 정보를 찾아내기가 상당히 어려워지고, 독자들 입장에서도 읽기가 거북해지는 글을 보고서 읽는 방향성을 잡기란 힘들다.- 원 문서의 일부 내용을 제대로 안 읽은 사람이 원 문서의 하위 문서 및 문단에 원 문서에 있던 같은 내용을 똑같이 남겨놓는다.
- 직접적인 하위 문서를 새로 분화했는데 그 사실을 모른 사람이 원 문서에 대한 삭제 또는 반달이라고 판단하여 똑같은 내용을 다시 서술한다.
- 직접적인 하위 문서를 새로 분화했는데 원 문서에서 "A는 B다"를 미처 지우지 않아서 하위 문서가 아닌 원 문서에 해당 내용이 남아있다.
- 원 문서에 있는 내용임에도 불구하고 해당 문서를 참조하라면 될 것을 /예시, /목록 등의 문서에 긴 설명을 들여서까지 중복 서술을 한다. 단, 원 문서에 없는 내용이면 당연히 중복 서술이 아니다.
문서나 문단의 주제와 관련도 없는 쓸데없는 정보의 개입 또한 문제. 작문에 '정보 과잉' 역시 없느니만 못한 존재고 쓸데없는 정보의 존재는 전체 독해에 혼선을 줄 우려도 많기 때문에 되도록 작성을 삼가는 것이 좋다. 이것의 대응으로 기타와 여담 문단을 첨가하나 이것도 여러 문단의 하위 문단을 많이 만들고 보면 형식상 지저분해 보인다.
2.1. 비대화된 문서 정리 과정의 문제점
몸집만 불어난 서술은 어느 기여자의 자발적 보완으로 정리되어야 하겠지만 정리하는 과정에서도 문서의 일관성은 실종되기 마련. 정보를 차근차근 알아야 할 내용의 순서라든지, 이어지는 문장의 개연성과 짜임새라든지, 문체의 일관성이라든지 이들을 충족시키며 복구시키는건 결코 쉽지 않은 작업이다.문서 개설 후 양이 늘어나면 독립 문서를 분화하거나 문단을 나누고, 그것도 많아지면 틀, 접기•펼치기를 동원하다가, 결국 필요없는 수식어와 서술을 다 쳐내고, 문서량이 적어진 것에 놀란 신규 위키러가 계속 서술을 추가하고, 다시 가독성 개선 작업의 반복... 그리고 과도한 문단 늘리기로 목차만 엄청나게 길어지고 문단 내용은 짧은 경우. 누군가 나서서 문단간 통폐합 정리 작업을 하기 전까진 다 읽기보다는 뒤로가기를 절로 누르게 된다.
그리고 문단의 생성이야 본래의 내용 분류를 위한 목적이면 이상적이지만, 위 총평/결론 문단에도 지적했듯 단지 자기 서술만을 눈에 띄게 만들기 위한 이기적인 목적 등으로 필요없는 문단 생성을 남발하며 기껏 생성한 문단엔 부실한 내용만이 남아버리고 목차까지 지저분해지는 현상도 발생하기도 한다. 게다가 긴 장문도 문단으로 나누는 작업도 필요하겠지만 이 과정에서도 짜임새를 보완해줄 문장을 첨가하는 작업을 거치지 않고 그저 잘라 붙이기에 불과한 기여도 발견되곤 하는데, 나뉘어진 문단을 읽어보면 두서없이 시작되는 문장에다 어색하게 이어지는 짜임새 등등 아무것도 모르는 독자가 읽기엔 방향을 종잡을수가 없는 내실없는 장문만이 탄생할 뿐이다.
이런 단락의 문제점은 악순환을 낳아가며 내용이나 문체는 들쑥날쑥해지고 문서의 완성도는 시간을 거듭할수록 떨어진다.
2.2. 문서의 파편화
나무위키 이용자가 많아서 잘 부각되지는 않지만 문서가 하위 문서들로 자잘하게 나뉘어져 있어도 문제가 생긴다. 지나친 문서 분리는 문서 간 접근성을 약화시키고, 이용자로 하여금 하위 문서에 대한 편집을 막는다. 아무리 문서 정리가 어렵다고 해도 리스트 생성 → 문단 분리 → 문서 분화와 같이 점진적인 방식을 선택해야 한다.이를 이용해 의도적으로 평가성 문단을 따로 분리시켜 해당 인물이나 단체로 관심을 분산시키는 경우도 있다. 너무 길면 분리를 하는 게 적합하지만, 내용이 짧고 충분히 요약할 수 있는 부분까지 방대화시켜서 어떻게든 해당 논란 문서의 접근성을 낮추려는 지능형 반달까지 나타나고 있다. 요컨대, '정보 과잉 → 대충 읽는 사람이 발생 → 문서 분리 → 분리 문서로의 관심 약화'로 이어지는 식이다.
3. 나무위키식 유머와 문체의 남발
4. 필요 이상으로 반전되는 논조
4.1. 반론 문단
4.2. 역접 남발
- 예시: "A이다. 다만 B이어서 A가 꼭 아니기도 한다. 다만 C여서…"
이는 문서를 만들고 편집하는 사용자들 개개인의 문제라기보다 나무위키의 서술 구조인 이어쓰기에서 발생하는 문제점으로 '정말로 A인 줄 알았지만 B였으며, 사실 이것도 C였을 가능성이 있는' 경우 이를 역접 없이 서술하기는 힘들다. 그래서 필력에 한계가 올 경우 가끔씩 역접을 두 개씩 쓰는 사람도 있다. 그렇지만 되도록이면 한 문장에 '다만' 이 3개 이상 출현하는 것은 지양해야 하고, 역접어는 반드시 필요할 때만 사용해야 한다.
글의 분위기가 양-음-양 혹은 음-양-음으로 흐를 경우에는 성격이 다른 문장 하나를 성격이 반대인 다른 문단으로 옮겨줄 수도 있으며, 혹 예외적인 상황을 제시할 경우 이어쓰기보다는 "~가 아닌 이상", "~를 제외한" 등의 형식으로 해당 결론의 전제조건을 보강해 볼 수도 있다.
이같은 접사 작성의 오류는 일일이 긴 문장보다도 짧은 단락 위주의 편집을 선호하는 위키러들의 경향에서 기인한다고 볼 수 있다. 이런 특성의 기여자들은 문서 전체를 훑어보지 않고 그때그때의 기여만을 무작정 쑤셔넣음으로 문맥의 방향은 이상해지고, 문장은 위 지적한 바와 같이 어색함을 자아내곤 한다. 이런 상황을 방지하기 위해선 귀찮더라도 문단을 전부 훑어보고 분위기에 맞게끔 접사를 조절하는 게 좋다.
5. 강조 부사 오남용
강조 부사는 애초에, 물론, 사실, 당연히, 절대, 결코, 실제로, 의외로 등의 문장이 설명하는 범위를 좁히기 위하여 사용된다.나무위키는 장문의 문장을 작성하다 보면 문장 구조를 다채롭게 하기 위해, 혹은 습관적으로 접속어가 추가되기 마련이고, 기여하는 사람 또한 직접 수정하기보단 덧붙이는 습관이 많기 때문에 역접과 마찬가지로 무리하게 강조하는 접속어를 추가시키는 경향이 짙은 편이다.
'사실'이라는 접속어의 용례는 서술하는 내용을 강조하거나, 자신의 생각과 반대되는 내용과 함께 서술한 다음 이 표현을 쓰고 자신의 생각을 서술함으로써 자신의 주장만 돋보이게 하는 것. 어느 쪽이든 좋지 않은 모양새이기 때문에 가급적이면 쓰지 않아야 한다. 문장 내용의 사실 여부를 떠나 과잉 서술로서 가독성을 해치거나 사용 남발로 인해 문서 전체의 필력을 떨어뜨릴 우려가 많으므로 문서에서 이런 표현 빈도를 고려하고 추가하는 것이 좋다.
또한 '물론'의 의미는 '말 할 필요 없음'인데, 지구의 공전, 물체간의 중력 등 불변하지 않는 진리라면 모를까 주관적인 내용을 서술할 때에는 정말 이런 과격한 표현을 써야 하는지 심사숙고해야 한다. 더 이상 말할 필요가 없다는 것은 더 이상의 논쟁을 틀어막겠다는 뜻이며, 혹여나 있을 수 있는 반대 의견을 묵살하겠다는 것과도 같기 때문이다.
이 상황이 격화될 경우 문서 내 문단을 생성하여 '옹호론'과 '비판론'을 대치시켜 병림픽을 해댈 수 있다. 이는 토론을 통해 중립 및 양비론화시켜야 하는 문제다. 위키는 특정인들의 블로그가 아니라 일반인도 볼 수 있는 곳이므로 독단적인 의견을 지양하고 객관적인 사실 등을 적어야 한다.
6. 필자 및 수정역사 내역 언급
7. 각주 문제
문서 편집에 각주 기능을 오남용하는 문제가 끊이지 않는다. 관련성이 있지만 본문에 넣기에는 문맥이 어색한 내용 또는 이해를 돕기 위한 간단한 보충 설명 정도를 각주로 넣는 것까지는 엔하계 위키 문화에서 흔한 편집 방식으로 인정되는 편이지만[1], 본문에 충분히 섞어서 넣을 수 있는 내용을 따로 떼어내 각주로 쓰거나, 과도한 연속 각주를 달거나, 각주 속 각주인 이중 각주를 달거나, 타인의 서술에 반박하거나 불만을 표시하기 위해, 또는 장난성으로 각주를 다는 경우도 많다.이미지가 포함된 각주 팝업에서 이미지가 보이지 않아 스크롤을 아래로 내려야 하는 경우도 발생했지만 2019년 9월 말 업데이트를 통해 이 문제가 해결되었다.
8. 과도한 이미지 사용
나무위키는 미디어 위키만큼이나 이미지를 많이 사용하는 위키다. 이미지를 사용함으로써 문서 내용을 이해하는데에 도움을 주지만, 오히려 이미지를 과도하게 추가해서 역효과를 일으키기도 한다. 문서 최상단에 이미지 4~5개가 연이어 걸리기도 하고, 본문에도 이미지나 동영상이 추가되기도 한다. 특히 인기 한국 아이돌 가수 멤버 문서들에 이런 일이 잦다. 해당 아이돌의 팬들이 팬심을 갖고 대량의 이미지를 삽입하다보니 문서 하나에 이미지가 50개 넘게 걸리기도 한다.심지어 그 많은 수의 이미지들 중에서도 거의 대부분이 대용량의 움짤인 경우도 있다. 데이터 네트워크를 이용하는 유저를 배려하지 않는 처사로서 나무위키를 단순히 글 중심의 위키라고 생각하고 들어가면 생각도 못한 데이터 폭탄을 맞을 수 있다.
더러는 이미지 크기를 조절하지 않아서 이미지가 너무 크게 삽입되는 경우도 많다. 이런 경우는 상당수가 외부 이미지를 그대로 링크한 것이기 때문에 온갖 문제가 다 엮이게 된다. 이런 제각각 크기의 이미지들은 서로 뒤엮여 미관을 저해한다. 모바일 유저에게는 데이터 테러에 해당하며, PC 유저에게는 페이지 로딩 속도를 살벌하게 만든다.
과유불급이란 말처럼 과도한 이미지 사용은 이러한 문제점을 발생시키므로 반드시 문서에 필요한 이미지만 남기고 수정하거나 삭제하는 것이 좋다. 아니면 펼치기 · 접기 문법을 두어 개 쓰는 것도 도움이 된다.
9. 잘못된 내부 링크의 활용
| 나무위키는 누구나 기여할 수 있는 위키입니다. 검증되지 않았거나 편향된 내용이 있을 수 있습니다. |
| 나무위키[2]/비판 문서 서술 관련 |
편집한 문서와의 관련성이 희박한데도 의미없는 내부 링크를 구태여 포함하는 경우가 있다. 심지어 위 예시 중에서 '서술 관련'은 이 문서에서 시작해서 이 문서로 오는 순환적 링크인데, 이것도 실제로 발견되는 형태이다. 나무위키에서는 순환적 링크가 금지되어 있는데, 이렇게 내부링크가 과도하게 달리는 사례에는 이상하게 순환적 링크가 자주 발견된다.
여기에 무슨 문서 전체를 가져다가 개별 단어를 일괄 수정이라도 한 것처럼, 특정 단어에 링크가 걸리면 그 단어마다 링크를 걸어서, 한 문서는 물론이고 한 문단에도 해당 단어가 3~4개씩 그 단어 문서로 내부링크가 걸려있는 상태가 발견된다. 이처럼 필요하지 않은 부분임에도 불구하고 무분별하게 추가함으로 문장은 퍼렇게 변하고는 문서의 가독성을 해치곤 한다. 내부 링크 표시도 그 자체로 색이 들어가는 강조 연출을 보일 수 있기 때문에 굳이 관련도 없는 키워드에는 설정을 피하는 것이 좋다. 심각한 경우에는 문서 서술의 문제라기 보다는 변형된 반달이 아닌가 싶을 정도이다.
| 한국어를 표기하는 데 쓰는 문자는 조선의 어느 성군과 조력자들에 의해 창제되었다. |
| 위 첫번째 링크는 한글, 두번째는 세종대왕, 세번째는 집현전으로 연결되므로 굳이 확인하지 않아도 된다. |
게다가 모바일로는 무슨 링크인지 알기 위해서 터치 홀드, 혹은 직접 들어가봐야 하는 불편을 초래할수도 있으므로 꼭 필요한 경우가 아니라면 지양하는 것이 좋다. 이런 식의 링크 활용은 나무위키식 유머에도 해당하는 서술 방식으로, 정보를 처음으로 알려고 방문하는 사람들을 배려치 않고 알 사람들끼리만 이해하고 즐기는 그들만의 놀이터로 변질될 우려도 많다.
다른 문단에서 지적하는 '과격한 서술', '나무위키식 유머'라는 문제점이 많은 명목으로 쓰이는 서술을 장문의 글에다 링크로 오묘하게 대체하는 사례도 서브컬처계 문서에서 자주 발견되곤 한다. 예를 들면 주관상 궤변으로 판단되는 어록을 통째로 개소리라는 리다이렉트를 건다던지, "이것은 절대 사람이 아니다!"[3] 이런 식으로.
9.1. 링크 모아쓰기
| 풀어쓰기 | 많은 리그 오브 레전드의 소환사들이 야스오, 마스터 이, 티모, 베인, 블리츠크랭크와 같은 챔피언들을 만나고 싶지 않아 한다. |
| 모아쓰기 | 많은 리그 오브 레전드의 소환사들이 오충대장군과 같은 챔피언들을 만나고 싶지 않아 한다. |
| 편집예시 | 많은 리그 오브 레전드의 소환사들이 [[야스오충|오]][[마이충|충]][[티모충|대]][[베인충|장]][[블리츠크랭크충|군]]과 같은 챔피언들을 만나고 싶지 않아 한다. |
| 위 3문장은 링크 내용과 순서가 완전히 같으므로 굳이 확인해보지 않아도 된다. | |
위키를 PC로 볼 경우 마우스를 링크 하나하나에 갖다 대면 링크 내용을 볼 수 있으므로 문제가 덜하지만, 모바일 웹 환경에서는 터치를 해야 링크 내용을 볼 수 있기 때문에 일일이 확인하는 데 많은 시간이 소요되어 문제가 된다. 또, 링크가 걸려 있는 문장을 싹 훑기 전에는 해당 문장에 얼마나 많은 링크가 있을지 예상할 수 없다는 문제도 있다.
이에 2018년 부로 링크 모아쓰기가 규정으로 금지되었다.[4] 하지만 원체 많은 문서들에 사용되던 터라 몇 년이 지났음에도 쉽사리 사라지지 않고 여전히 많은 문서들에 만연해 있으며, 지금까지도 근절되지 못하고 신규 서술로 추가 되고 있다.
10. 틀 오남용
10.1. 임의적으로 제작한 틀
include 문법을 사용해서 넣은 틀인 것처럼 문서에 들어가 있지만, include 문법이 아닌 'wiki style'로 시작하는 틀 문법을 사용해서 임의로 만든 틀이다.{{{#!wiki style="border: 1px solid gray; border-top: 5px solid #006400; padding: 12px"
주의. 이 문서는 DCSS 구버전의 정보가 서술되어 있습니다.이 틀이 달린 문서는 던전 크롤 스톤 수프의 0.18 버전 이전 정보를 기준으로 작성되었습니다. 일부 내용이 최신 버전의 변경 사항과 상이할 수 있으므로, 문서 열람 시 주의 바랍니다.}}}
틀:던전 크롤 이전 버전 경고 r6 버전
| wiki style="border:1px solid gray; border-top:5px solid #006400; padding:12px" |
11. 서술 시점과 관련된 문제
11.1. 날짜 표기
대부분의 문서에서 꼭 필요한 것이 해당 내용에 관한 시기 표기인데, 정확한 연도 및 날짜를 안쓰고 넘어가는 경우가 잦다. 거기에 올해, 오늘, 어제, 내일, 현재, 최근 등의 표현으로 날짜 표기를 대체하는 경우도 있는데, 이들은 어디까지나 작성자가 키보드를 두드리는 순간을 기준으로 그렇다는 것이지 미래에도 이런 표현들이 잔재하다간 어느 시점을 기준으로 최근, 오늘이라는 것인지 설명이 되지 않아 읽는 독자들을 혼란에 빠뜨릴 여지가 많다. 문서 작성 당시에 정확한 날짜 표기가 귀찮다고 넘어가면 나중에 수정하러 온 사람이 하나하나 확인해서 추가해야 하는 번거로움만 안겨줄 뿐이고, 그것조차 아무도 안 하고 방치된다면 이용자들은 계속 불편을 겪게 되고 문서의 가치는 떨어진 상태가 유지되어 버린다.또한 특히 연예인 관련 문서에서 "올해"나 "이번 연도" 같은, 작성 시기를 알지 못하면 어느 시기의 내용인지 알 수 없는 표현들도 찾아볼 수 있다. 월일만 표기할 경우 해당문서까지 온 유저들이 문서를 매우 꼼꼼히 읽어보거나 주석 등을 참고해서, 혹은 아예 포털로 다시 가서 검색해야만 몇 년도에 이 내용들이 일어난 것인지 알 수 있다.
따라서 시제 관련 표현은 더 객관적이고 구체적으로 하는 것이 좋은데, '년/월/일 기준으로~ ', '년/월/일 이후' 등으로 표현하여 미래까지도 유효하고 직관적으로 이해시시키 편한 내용으로 수정하는 것이 좋다.
[Date] 기능은 실시간으로 변하는 것에 대해 사용하는 기능이고, 제대로 지키지 못하면 그 자체로 신뢰성을 보장받지 못한다. 패치 내용을 제때 문서 내용으로 반영하지 못해서 많은 게임 관련 문서들이 비판의 포화를 맞아야 했고, 일부 문서는 그 내용을 크게 축소해야 했다.[Date] 문법이 보편화되면서 또 다른 문제도 생겼다. 'xx년 xx월 xx일 기준으로'라는 표현을 '[Date] 기준으로~'라는 표현으로 교체하거나 애초부터 '[Date] 기준으로~'라는 표현을 사용하게 된 것이다. [Date]는 독자 기준으로 최근을 설명하는 것이지, 작성자 기준으로 최근이 아니기 때문에, 작성 내용 변화에 따라 나무위키 안의 내용도 꼬박꼬박 병행 업데이트해야 하는 자신이 없는 이상에는 이러한 사용을 하지 않는 것이 좋다.이는 나무위키를 비롯해서 위키라는 시스템 자체를 마치 '현재 상황'을 실황하는 매체인 것처럼 표현하는 양 착각함에서 비롯된다고 볼 수 있고, 문서를 읽는 독자에게도 똑같은 방식으로 혼란을 준다. 위키피디아 등에서도 스스로를 encyclopedia 즉 백과사전으로 표현하고 있듯이, 나무위키를 비롯해서 위키를 비롯한 인터넷의 정보 매체들은 일반적으로 실황중계가 아닌 기록매개체로서의 역할을 하기 때문에 다소 불편하고 번거롭더라도 시점 서술이 필요한 경우는 되도록이면 마치 사서를 적듯이 정확한 시점을 제대로 표기하거나 혹은 정확한 시점을 알 수 있기에 적절한 수준으로 묘사해야 한다.
11.2. 과거의 추측
미래에 대한 추측을 서술하는 문서에서 자주 일어나는 현상이다. 예를 들어 다음과 같은 서술이 있었다고 하자.A는 B가 될 것으로 보인다.
이후 시간이 흘러 A가 B가 아니라 C가 되었을 때 상술한 문장이 다음과 같이 수정되는 경우가 많다.
A는 B가 될 것으로 보인다. 하지만 결국 C가 되었다.
과거 시점을 기준으로 한 문장인 'A는 B가 될 것으로 보인다'는 한 글자도 건드리지 않고 뒤에다가만 결과를 이어 적기만 하는 경우이다. 이러면 독자들은 뒷 문장을 읽기 전까지는 과거의 추측이 읽는 시점까지도 유효한 추측이라고 착각하게 돼서 그것이 아니라는 뒷 문장을 읽은 후 약간의 혼란이 오게 된다. 또 마지막까지 다 읽어야 제대로 된 정보를 알 수 있어 가독성이 떨어진다.가장 확실한 해결 방법은 결과가 나온 후 과거의 추측을 아예 삭제하는 것이다. 과거의 추측을 반드시 존치해야 한다면 다음과 같이 과거의 추측을 과거형으로 변경하거나, 결과를 문장의 맨 앞부분으로 이동시켜 두괄식으로 작성하는 것이 현재 시점에서는 유효하지 않은 추측이라는 것을 알 수 있게 하는 것이 독자들의 혼동을 막을 수 있다.
A는 B가 될 것으로 보였다. 하지만 결국 C가 되었다.
A가 B가 될 듯 했으나 결국 C가 되었다.
A가 B가 될 듯 했으나 결국 C가 되었다.
12. 고질적인 맞춤법 문제
누가 언제든지 수정한 내용이 검토 없이 바로 적용되는 나무위키 특성상 국어 맞춤법에 맞지 않아도 그대로 남기 때문에 눈살을 찌푸리게 만드는 경우가 있다. 자주 틀리는 한국어/목록에 있는 가장 자주 보이는 기본적인 예시들 뿐 아니라, 이외에도 가독성을 해치는 문장부호 오류 및 띄어쓰기 오류는 수도 없이 많다.이는 모든 작성자들에게 올바른 작문 교육을 기대할 수 없다는 점을 감안하면 고질적으로 안고 가야할 문제점으로, 관련 교정봇을 주기적으로 운용하거나 네이버 블로그처럼 편집창 자체에 맞춤법 검사기라도 탑재되지 않는 이상은 뾰족한 대책도 찾기 힘든 고질병이다. 그저 맞춤법 오류를 발견한 유저들의 자발적인 교정이 유일한 해결책이라 볼 수 있을 것이다.
13. 글자색의 문제
배경색과 차이가 크지 않은 글자색을 사용해서 글자 자체가 눈에 잘 안 보이는 상황이 때때로 보인다. 캐릭터나 실존 인물, 또는 특정 대상이 갖춘 상징색을 나타내기 위해서 색을 넣거나, 단순히 글자를 꾸미기 위해서 색을 넣으면서 문제가 발생한다. 이쯤 되면 '가독성의 문제'를 떠나서 '가시성의 문제'라고 봐야 한다.가장 쉽고 흔한 사례는 상징색이나 머리카락색이 노란색인 경우다. 노란색의 명도가 기본적으로 높은데, 위키의 배경색은 다른 색을 지정하지 않으면 흰색이기 때문이다. 그 결과 라이트 테마에선 이렇게(이렇게) 글자가 제대로 안 보이는 상황이 발생한다. 글자색을 #yellow로 하면 퓨어 옐로우가 적용되는데, 이 퓨어 옐로우의 명도는 8.5나 된다. 그런데 상징색이 노란색인 존재나, 금발이 캐릭터는 너무 많기 때문에 이걸 구현하겠다고 노란색을 써버리는 경우가 비교적 많다. 같은 맥락에서 비슷한 색들도 명도를 높게 잡아버리면 같은 문제가 생긴다는 것을 알 수 있다.
이런 글자색 변경이 흔하게 발생하는 것이 테이블인데, 이 경우라면 배경색도 문제가 된다.
| 이렇게 | 써 놓으면 | 안 보이긴 | 매한가지다. |
역으로, 이걸 막으면서 이미지도 넣고 글자도 보이겠다고, 테이블을 2단으로 만들고 배경색의 차이를 두는 사례도 발견된다. 색만 안 넣었어도 1단으로 충분한 문제다.
라이트 테마 환경만을 고려하고 문서를 편집할 경우 다크 테마에서 이런 문제가 의도치 않게 일어나기도 한다.
다만, 상기한 문제들은 틀 남용 문제와 유사하게 2019년의 시점에서는 상당 부분 해결된 문제다. 색을 넣어서 가독성을 떨어뜨리는 게 문제지 색을 넣는 것 자체는 문제가 아니기 때문. 이런 식으로 가시성을 파괴하는 테이블들은 대부분 수정이 된 상태다. 아이돌 문서에서 알록달록하게 틀을 꾸미는 걸 좋아하는 유저들이 많긴 하지만, 가독성을 해치는 틀이 아닌 이상 이를 비판이라 볼 수는 없겠다.
글자색을 넣는 것에 대해 일부의 비판이 남아있기는 하다. 즉, 빨간색이나 파란색, 초록초록색[6] 같이 해놓으면, 이게 문서 링크가 걸려 있는 것인지 안 걸려 있는 것인지, 링크에 문서가 있는지 없는지 알 수가 없다는 문제.[7] 그나마 PC판은 마우스를 가져다 대면 링크 문서가 있는지를 밑줄 색으로 보여주고, 어떤 문서에 링크되어 있는지를 알려주지만, 모바일은 크롬 기준 길게 눌러야 어떤 링크가 있는지 확인이 가능하고, 없는 링크인지는 작게 보이는 밑줄로만 확인할 수 있다.
[1] 일부는 이런 것도 선호하지 않아서 각주를 위키백과처럼 출처 용도로만 쓰게 하자고 주장하기도 한다.[2] 이 경우, 링크 모아쓰기에도 해당된다.[3] 천하의 개쌍놈으로 링크 처리.[4] 해당 규정은 나무위키:편집지침/일반 문서에 기재되어 있다.[5] 틀 규정을 정비하면서 이런 일반 틀의 생성은 상당한 제약이 필요해졌다.[6] '초록초록색' 문서는 존재하지 않는다. 글자색을 넣으면 링크 문서 유무를 확인할 수 없다는 것을 보여주기 위한 예시. 저게 초록과 초록색의 링크 모아쓰기인지 누가 알 수 있을까?[7] 나무위키에서 붉은색은 '링크 된 내부 문서가 없다'는 의미, 라이트 테마 한정으로 파란색은 '링크된 내부 문서가 있다'는 의미로 사용되기 때문이다.