최근 수정 시각 : 2024-11-03 16:07:05

강제 줄 바꿈

강제 개행에서 넘어옴
1. 개요2. 사례
2.1. 옛 동양의 존대 표현(대두)2.2. 강제 줄바꿈이 불가피한 경우2.3. 의도적인 강제 줄바꿈2.4. 문서의 양식이 결정되어 있지 않은 경우2.5. 기타
3. 가독성 문제
3.1. 나무위키에서3.2. 편집 디자이너들의 적

1. 개요

페이지의 끝에 다다르거나 문장이 끝나기 전에 줄 바꿈을 넣어서 문장을 다음 줄로 보내는 행위.

동의어로는 행갈이, 강제 개행[1]이 있고, 전산학에서는 개행(line alignment)이라는 말도 쓴다.

2. 사례

2.1. 옛 동양의 존대 표현(대두)

파일:상세 내용 아이콘.svg   자세한 내용은 대두(높임법) 문서
번 문단을
부분을
참고하십시오.

2.2. 강제 줄바꿈이 불가피한 경우

편집 단계에서 보이는 텍스트 편집 창의 폭에 맞춰서 무조건 강제 줄 바꿈을 하는 것인데, PC통신 시절 본의 아니게 문단이 깨지는 것을 막기 위하여 적절한 위치에서 줄을 바꾸던 것이 이어진 것으로 보인다. PC통신 시절에 쓰던 VT 환경은 가로가 80바이트로 제한이 되어 있었는데, 2바이트 코드 지원이 미비해서 맨 끝 글자가 깨지는 일이 잦았다. 예를 들어, 한 행의 80열째에 글자를 쓰면 80, 81열에 한글 코드가 기록이 되어야 하는데, VT상에서 81열은 없기 때문에 앞부분 코드만 기록되고 뒷부분 코드는 잘려버린다. 이렇게 되면 전혀 의도하지 않은 문자가 출력되는데, 한글 코드 맨 앞 비트가 1로 시작하기 때문에 아스키 코드 확장 영역에 있는 특수문자가 뿌려지는 일이 많았다. 강제 줄 바꿈을 하는 이유는 이런 일을 막기 위함이었고, 당시 PC통신 프로그램의 편집기는 아예 자동으로 개행을 넣어주는 일이 많았다.

하지만 현 시대의 인터넷 환경에서는 이런 식으로 줄을 넘어가면 몹시 읽기 불편해진다. PC통신 시절과 달리, 인터넷 환경에서는 편집 칸과 실제 보는 페이지의 문장 폭이 다른 경우가 많고, 특히 편집 단계와 보는 단계 폰트가 각각 달라서 문장이 들쭉날쭉해지는 경우가 많다. 그리고 뷰어에서 알아서 줄을 넘어가니까 강제로 줄을 바꿀 필요는 절대 없다.

일부 게시판 상에는 자동 줄바꿈 기능을 지원하지 않아, 강제 줄 바꿈을 하지 않으면 글이 좌우로 너무 길어져서 가독성이 떨어지는 경우도 생긴다. 그래서 강제 줄 바꿈을 적용해서, 제한선이 있는 것처럼 보이게 하기도 한다. 하지만 사이트의 디자인이 바뀌어서 게시 글의 가로폭이 변하는 상황도 있을 수 있고, 보는 기기(데스크탑/노트북/스마트폰/태블릿PC 등)의 가로폭은 얼마든지 다를 수 있기 때문에 적절하게 사용하는 것이 좋다.

PC통신때부터 글을 많이 써오던 이는 이때의 습관이 배여서, 인터넷 시대 이후에도 강제 줄바꿈해서 글을 쓰는 문체가 습관화된 경우가 일부 있다.

2.3. 의도적인 강제 줄바꿈

예1 예2
가에서
설작업
지어서
들바들
이기를
대신귀
여운알
파카를
드리겟
습니다

세로드립이 그 한 예다.

또는 한국어가 아니라 영어일 경우, 강제 줄 바꿈을 잘 쓰면 의미가 180도 뒤집힐 수도 있기 때문에 여러 작품에서 많이 볼 수 있다. 특히 노래가 그런데, 노래에서 멜로디만 뚝 떼어놓고 가사만 보면 전혀 다른 느낌을 주는 반전이 숨어있는 경우가 많다.

서적으로 발간된 예로는 로저 젤라즈니의 휴고상 수상작 '내 이름은 콘래드'에서 초능력자들끼리 서로 텔레파시를 주고받을 때 문장의 모양새를 대화 내용을 표현할 수 있는 아이콘으로 만들어서 통신하는 모습에서 종종 언급된다.

또한 유명한 동화 이상한 나라의 앨리스에서도 이런 줄 바꿈이 존재한다. 앨리스가 눈물의 샘에 빠진 뒤 생쥐를 만났을 때 생쥐가 신세 한탄을 하며 개 재판관과 나누던 이야기를 기록한 부분이 그것인데 원작에서는 이 부분을 일부러 연기처럼 점점 작아지는 모양에 맞춰 넣는 식으로 줄을 넘어가서 써 놓았다. 앨리스가 생쥐의 말에 집중하지 않고 점점 딴 생각을 하고 있다는 것을 묘사하기 위한 것.[2][3]

또 소설가 박민규도 이러한 강제 줄 바꿈을 자주 사용한다. 주로 강제 줄 바꿈으로 인한 '문장이 끊어지는 느낌'을 이용해 독자의 호흡 조절과 '낯설게 하기' 를 이끌어낸다. 또 작가 특유의 말하는 듯한 느낌을 만들어내기도 한다. 강제 줄 바꿈 외에도 폰트 변경, 글자 크기 변경, 그림 사용 등 파격적인 시도를 많이 하는 편이다. 이러한 특징은 박민규의 단편 중 하나인 「수다스러울 절」[4]에서 모두 찾아볼 수 있다.

문학동네 시인선의 표지는 단색 바탕에 강제 줄 바꿈으로 제목이 쓰여 있다.

한국에서도 이와 관련하여 광고의 한 획을 그은 작품이 존재하는데 카피라이터 김태형의 은성석유난로 광고가 있다. 이런 식으로 말하고자 하는 사물의 모습을 줄 바꿈을 통해 강조하는 기법으로 쓰인다.

2.4. 문서의 양식이 결정되어 있지 않은 경우

특정 프로그램의 특성상 개행을 하지 않으면 한 문단이 좌우로 주욱 길게 늘어진다. 폭 안에 문장이 다 들어오는 가독성을 위하여 줄바꿈을 해줘야 한다. 이메일 관련 프로그램인 아웃룩 익스프레스가 대표적이다. 메모장에 긴 문장을 입력하고 서식 메뉴의 자동 줄바꿈을 꺼버리면, 왜 줄바꿈을 해야 하는지 알게 된다.

이런 사례에서의 줄바꿈 문제는 문서의 좌우 폭이 정해지지 않는 경우에 생기는 문제임을 쉽게 알 수 있는데[5] 컴퓨터의 보급과 모니터해상도 확장으로 인해 불거지는 문제이므로 위에서 논하는 전통적인 사유 및 비판과는 별개로 보아야 한다.

2.5. 기타

2017년 기준으로 특히 크로뮴 프로젝트 기반 웹 브라우저들에서 편집 화면에서 줄 끝에서 띄어쓰기를 입력하면 실제 편집된 문서에는 개행으로 반영되는 버그가 있다. 이걸 편집으로 수정하려고 해도 버그가 계속 먹히면서 수정이 잘 되지 않는데, 이럴 때에는 먼저 앞부분 임의의 위치에서 엔터키를 눌러서 줄을 바꾸고 버그로 개행된 부분을 수정한 뒤에[6] 다시 수동으로 개행한 부분도 되돌려 놓으면 된다.

여담으로 이 강제 줄 바꿈의 전통이 본격 왕정 국가 북한에도 묘하게 이어져서 우상화의 일련으로 김씨일가의 이름은 한 줄에 두 번 제시되지 않게 되어 있다 한다. 문화어 용법 참조.

컴퓨터 용어로는 CR+LF. 이는 '캐리지 리턴과 라인 피드'(Carriage Return and Line Feed)의 약자로, 입력 커서의 위치를 처음으로 돌리고(CR) 한 줄을 내리는 행위(LF)다. CR과 LF는 각각 아스키 코드에서는 제어문자 13(0x0D)과 10(0x0A)으로 코드화되어 있다. C언어의 경우, 아스키 제어 문자 입력용 이스케이프 시퀀스는 CR은 \r, LF는 \n이다.

줄 하나 띄는데 2바이트씩 먹는 비효율적인 방식을 사용하는 것은 타자기의 유산. 즉, 타자기에서 줄 바꿈을 위해서는 먼저 캐리지[7]를 행의 맨 앞으로 복귀시키고, 타자용지를 한 줄 위로 밀어올려주는 2단계의 동작이 필요했기 때문에, 각 동작을 따로따로 아스키 코드로 부호화시킨 것이 MS-DOSWindows에 그대로 남아있는 것이다.

물론 이건 비효율적이므로 유닉스/리눅스 계열(Mac OS X 포함)에서는 LF만, Mac OS 9에서는 CR만 사용한다. 이 때문에 유닉스/리눅스나 Mac OS X에서 작성된 텍스트 문서를 윈도우 메모장에서 바로 읽어들이면 줄바꿈을 인식하지 못해서 줄이 모두 붙는다. 메모장보다 기능이 많은 대부분의 텍스트 에디터[8]는 줄 바꿈 변환을 기본적으로 지원한다.

수십 년간 이 문제로 골치 썩은 사람들이 많아서 그런지 변환 툴도 무수하게 나와 있다. 윈도우 10에서부터는 메모장이 이전보다 더 프로그래밍 친화적으로 바뀌어서, 인코딩의 종류와 개행문자의 종류도 직접 선택할 수 있고 리눅스나 맥OS의 개행문자도 정상적으로 개행으로 인식하도록 바뀌었다.

파일:기다려주십시아랫도리오....png
Windows XP의 베타버전인 Windows Codename Whistler의 한글 버전의 종료 화면이다. 무슨 이유에서인지 "기다려 주십시오..."라는 문구가 중간에 강제 개행이 된다.[9]

코딩 스타일중 일정 문자가 넘어가면 강제개행 하는 스타일이 있다. 79-80 째 문자에서 무조건 개행하는 것으로 과거 천공 카드의 문자 제한에서 내려오는 전통이고 와이드 스크린이 대중화된 현대에도 2분할 화면으로 사용 시 80자에서 강제개행을 하게 되면 한 화면에 두 코드를 표시할 수 있다보니 여전히 애용되는 스타일이다.

3. 가독성 문제

(詩)와 같은 운문에서는 운율감을 살리기 위해 사용할 수 있지만[10] 시가 아닌 산문에서는 매체를 봐가며 조심해서 다뤄야 한다. 나무위키 같은 경우는 강제 줄 바꿈이 적용된 매체가 아니다.

한편 사람마다 다 개인차가 있기 때문에 강제 줄 바꿈을 남용하는 문장이 보기 더 쉬워 보인다는 사람도 많다. 같은 내용이라도 이렇게 줄을 바꾸면 한번에 시각적으로 소화하는 정보량이 줄어들기 때문에 독서 부담이 감소한다고 느끼기 때문이라고 한다.

그 외에도 문장의 길이가 좀 짧아서 글을 다 썼을 경우에 끝 부분 약간만 줄이 넘어가는 경우 등 강제로 줄을 바꾸지 않으면 보기 흉한 경우도 그러한 예시가 될 수 있겠다. 어떤 게시판의 경우에 횡폭이 매우 커서 어지간히 긴 글이나 문장 자체가 한 줄에 나타나는 경우가 있는데 이렇게 될 경우 가독성이 떨어지게 된다.

하지만 그렇다고 역으로 그걸 남용하면 쓸데없는 공백이 지나치게 많아지고 문단의 모양이 보기 흉해지기 때문에 되려 가독성을 낮추는 요인이 된다. 문장과 글 사이에는 문단이라는 개념이 있어서 글 덩어리의 주제별로 덩어리를 나누는 것이 가능하다. 그런데 이런 구분 가능한 이어지는 내용들이 강제 개행으로 여러 번 분리되어 있다면 가독성이 떨어지는 것은 당연한 일일 것이다.

태블릿 컴퓨터, 스마트폰 등 인터넷 이용 가능한 소형 화면 장착 장치들의 적이라고 할 수 있는데, 단순히 PC 화면을 기준으로 강제 줄 바꿈을 넣어버리면 같은 화면을 태블릿 컴퓨터나 스마트폰으로 봤을 때 가독성이 그야말로 시망 수준이 되기 때문이다. 그렇다고 반대로 이런 소형 화면을 기준으로 강제 줄 바꿈을 넣으면 이번엔 PC 화면에서 보는 내용이 매우 민망해진다. 따라서 소형 화면이 대중화한 이후론 지양하는 것이 더 좋은 개념이라고 할 수 있다.

즉 예를 들자면 다음과 같다.
22인치 와이드 모니터로 위키의 어떤 페이지를 열었을 경우
위키 문서 내에 강제개행을 넣음으로써
얻는 이득 중 하나는 가독성을 높일 수 있게 된다는 것이다.

하지만 다른 사이즈의 화면에서 같은 화면을 열람하게 되면
오히려 문단이 어색하게 나뉘게 되어
가독성을 해치는 부작용이 있을 수 있다.
5인치 스마트폰 화면으로
같은 페이지를 열었을 경우
위키 문서 내에 강제개행을
넣음으로써
얻는 이득 중 하나는
가독성을 높일 수 있게 된다는 것이다.

하지만 다른 사이즈의 화면에서
같은 화면을 열람하게 되면
오히려 문단이 어색하게
나뉘게 되어
가독성을 해치는 부작용이
있을 수 있다.

다만 요즘 웹 문학에 한해, 사실상 모바일 화면을 기준으로 해서 PC화면에 띄울 때의 문제는 신경 쓰지 않는 경우가 많다. 특히 소설은 기존 방식으로 서술하게 되면 모바일 화면에서는 화면에 빽빽하게 글자가 들어차는 경우가 많은데 이는 독자로 하여금 읽기도 전에 질려버리는 상황을 야기한다. 그렇다 보니 문장이 끝날 때마다 줄을 바꾸고 심지어 문단이 바뀔 때는 사이에 빈 행까지 넣는 경우도 다반사.

이렇게 매 문장마다 엔터를 치면서 강제 줄 바꿈을 의도적으로 사용하는 것을 이른바 '웹소설식 줄 바꿈'이라 한다. 많은 웹소설 독자들과 웹소설 플랫폼들은 이렇게 강제 줄 바꿈을 일부러 사용하여 가독성을 높일 수 있다오 여기고, 반대로 강제 줄 바꿈을 자제하는 기존 종이책 방식의 서술을 '벽돌'이라 부르며 혐오한다.

이러한 '웹소설식 줄 바꿈'에 해당되는 경우들은 십중팔구 상업성을 추구하는 물건들의 가독성 확보를 위한 일종의 고육지책이기 때문에 문법이나 어법에서 틀린 경우가 많다. 웹소설 독자들과 웹소설 플랫폼들이 '웹소설식 줄 바꿈'을 통해서 충분히 가독성을 개선할 수 있는데 왜 문법이나 어법을 따를 것을 고집하여 가독성을 악화하는 문법 나치 행위를 하냐고 작가들을 압박하기 때문에 문법이나 어법이 틀렸어도 그 점이 무시되는 것이다. 이 문제가 가장 두드러지게 나타나는 웹소설 플랫폼이 카카오페이지.

문학적 소양이 있고 좀 신경을 쓰는 작가들은 문장을 모바일 환경에 맞게 써 내려가기도 하지만 많은 작가들은 작문 방식을 웹소설로 배워서 그렇게 쓸 수 없다. 설령 소양이 있는 작가가 글을 쓰더라도 웹소설 독자들과 웹소설 플랫폼들이 모바일 환경에 맞춰진 문장을 원하기 때문에 문법이나 어법은 뒷전이 되기 일쑤이다. 혹 작가 지망생이라면 다른 작품들을 섭렵할 때 웹 문학에서 접한 문단 나누기나 줄 바꿈 방식들 중 적어도 절반 이상은 문법이나 작문법에 맞지 않을 거라는 생각을 하며 연습하는 게 좋다. 이에 대한 보다 자세한 설명은 웹소설/문제점 문서를 참조.

이런 식의 글쓰기는 인터넷 글쓰기에도 영향을 줘서 오탈자가 적고 문어체의 비중이 높으며 문법을 어느 정도 준수하는 글이 틀딱체로 여겨지며 경멸의 대상이 되기도 한다. 인터넷 커뮤니티에 올리는 글임에도 가독성 증진 목적의 강제 줄 바꿈을 꺼리는 습관이 있다면 오히려 가독성이 나쁘다는 이유만으로도 빌런 취급하며 아무리 청년 코스프레를 해도 곧바로 중년임이 들통나는 경우가 많은데, 2020년대를 기준으로 젊은 세대는 커뮤니티나 SNS에 글을 쓸 때 매 문장마다 엔터를 치면서 강제 줄 바꿈을 의도적으로 사용하는 이른바 '웹소설식 줄 바꿈'을 선호하며 스스로도 자주 사용하는 경향이 있기 때문이다.

3.1. 나무위키에서

나무위키에서는 규정에 의거해 특수한 경우 외에는 금지하고 있다.[11]

보통 위키에선 들여쓰기[12]를 사용하지 않으며[13] 나무위키의 경우 문단 나누기가 필요할 땐 문단 사이에 행 한 개를 비워서 대신한다. 이 문서만 해도 글 덩어리들이 들여쓰기처럼 개행하고 붙어있지 않고 전부 빈 행 하나로 나뉘어있는 것이 보일 것이다. 가독성/나무위키 문서도 참고하면 좋다.

위키 등 가로 길이가 적당한 사전에서는 지나치게 강제 줄 바꿈을 할 때 가독성이 더 떨어져 보일 수 있고 본문 오른쪽에 강제 줄 바꿈을 하면서 생기는 여백으로 인해 내용이 지저분해질 수 있으므로 이러한 행위를 규칙으로 규정하여 전면 금지하고 있다. 또한 스포일러 틀 아래에 줄을 무작정 많이 넘어가는 것은 기본적으로 강제 줄 바꿈과 같은 취급을 받기에 하면 안 된다.

그러나 실제 글쓰기에서는 문단 사이에 빈 행을 두지 않으며 현실에서 이 방법을 쓸 경우 글이 이상하다고 여겨질 수 있으니 주의해야 한다. 글의 길이가 길어질 때 문단 사이에 행 하나를 비워두면 문단이 독립되어 보여 가독성이 증가하는 효과를 볼 수 있지만, 설명문 · 신문 등에서는 거의 사용하지 않는 방법이며 논술 시험 등에서는 더더욱 쓰지 않는다. 자소서에는 쓸 수도 있지만 신중하게 사용해야 한다. 이렇듯 기존에는 전혀 쓰이지 않은 방식이기 때문에 행 하나를 비워서 글을 나누는 것은 인터넷의 특이성 때문에 생겨난 일종의 인터넷 문화라고 보는 게 적절할 것이다. 그렇다 보니 자소서 중 웹페이지 시스템상으로 들여쓰기를 무시해 버리는 양식인 경우에는 나무위키에서처럼 빈 행 1개를 삽입해서 문단을 구분하는 방법이 많이 쓰인다.

간혹 선술한 것과 같이 엔하계 위키 시절부터 글을 쓰던 이용자들은 그 습관이 배어 나와서 개행하며 편집하려다 규정에 걸리는 경우도 있었다.

기술적 변경으로, 틀에 삽입된 글이 자동 줄바꿈이 된 것처럼 서술되는 대신 틀이 옆으로 무한히 늘어나게 되었다. 이에 따라 글자 수가 많을 경우 틀의 가독성이 심하게 저하되는 문제가 생겼다.

3.2. 편집 디자이너들의 적

적당한 강제 줄 바꿈이 가독성을 높이는 것은 사실이지만, 모든 곳에 적용하는 것은 무리가 있다.

예를 들어 '나무위키'라는 단어가 들어가는 긴 문장에서 '나'자만 첫 번째 줄에 있고, '무위키'는 다음 줄로 내려가는 것을 막기 위해 '나무위키'가 모두 한 줄에 들어가도록 조절할 경우 다른 단어가 안 맞는 경우가 생기게 된다. 따라서 시각적인 요소에 민감한 편집 디자이너들도 웬만하면 적당한 선에서 맞추려고 하는데, 유독 강제 줄 바꿈에 집착하는 편집부 직원이 이를 까다롭게 요구하여 디자이너와 마찰이 많은 편. 디자이너가 "왜 이게 안 되는지"를 알기 쉽게 설명을 해도 고집을 꺾지 않는 직원이 있다면, 이는 디자이너를 견제하기 위한 꼼수일 가능성이 거의 100%라고 볼 수 있다.

물론, 편집부 직원 입장에서도 할 말은 있다. 이런 사람들은 활자에 집중하는 경향이 있으니 아무래도 눈에 거슬리는 부분이 많고, 원래 남들이 쉽게 간과하는 부분을 체크하라고 뽑아 놓은 사람들이라 업무를 열심히 한다는 걸 상사에게 보여 주고픈 욕심도 있다. 더군다나 이들의 업무가 고난도인데 비해, 이 사람들이 수고한 흔적은 티가 나지 않으니 초짜일수록 이런 무리수를 두려는 유혹에 빠지기 쉽다.

하지만 문제는 이들이 직접 편집 프로그램을 다뤄 보지도 않았으면서 디자이너를 쪼아 댄다는 것. 그래도 초짜들은 디자이너가 안 된다 하면 내가 모르는 기술적인 문제가 있나 보다 하고 수긍하는데 짬밥 좀 먹은 대리급이 되면 짬부심으로 꼰대짓을 하는 경우가 있다. 게다가 1인 사업자인 프리랜서 디자이너 같은 주로 만만한 사람을 타깃으로 하니 디자이너 입장에선 밉상일 수밖에 없는 것이다.

파일:analyzed.jpg

영어권에서는 이것을 이용해서 대놓고 드립을 치기도 한다. 해당 광고는 어덜트 스윔에서 방영되는 해몽 관련 코미디 시리즈다. analyzed(분석된)라는 단어를 일부러 anal(항문의)-yzed로 잘라 쓴 것.[14]


[1] 개행([ruby(改行, ruby=かいぎょう)])이라는 단어는 일본에서 왔기 때문에 한국에서는 잘 쓰지 않고 국어사전에도 없다. 한자를 보면 고칠 개다닐 행을 쓰는데, 순우리말로 바꾸면 '줄 바꿈' 정도가 된다.[2] 어느 번역판은 'tale(이야기)'를 'tail(꼬리)'로 번역해서 꼬리 모양으로 구부러져 있다."라고 하기도 한다.[3] 한국 번역판에 강제 줄 바꿈을 제대로 유지해 놓은 판본은 처음에는 적었지만 이후 많아졌다. 이상한 나라의 앨리스를 보다 면밀하게 고찰하는 주석서 등을 보면 보다 분명히 알 수 있으며 대표적인 책으로 '마틴 가드너의 이상한 나라의 앨리스'가 있다.[4] 𪚥, 유니코드 U+2A6A5. 특히 이 소설의 장르는 무협이다. 물론 일반적인 무협은 아니지만 여하튼 장르부터 박민규의 파격적인 면이 잘 드러나는 작품이다(소설집 『더블』, side b권 수록).[5] 가령 MS 워드아래아 한글에서 문제가 없던 이유는 이들 문서가 A4에 맞추어 좌우 폭을 제한해주기 때문이다.[6] 이때는 띄어쓰기가 줄 끝에 위치하지 않으므로 정상적으로 입력된다.[7] 타자기에서 글자를 찍을 때마다 타자용지를 한 칸씩 옆으로 옮겨주는 타자기 부품[8] 예를 들어 notepad++같은 것은 물론이고 윈도우 기본 탑재 워드패드도 여기에 해당된다.[9] 영문판으로 설치한 후, 한글 MUI를 설치해도 마찬가지다.[10] 문학적 용어로는 행간걸침이라고 한다. 웹페이지 등으로 시를 퍼오거나 했을 때는 가능한 그대로 쓰는 것이 좋다.[11] 이 때 나무위키의 문장문단의 정의는 사전의 것과는 다르기 때문에 주의해야 한다. 나무위키의 공식 문서에서 문단은 '1. 개요', '2. 설명' 같은 항목들을 말하며, 문장은 그 항목으로 나누어진 내용들 중 빈 행으로 구분된 글 한 덩이를 말한다. 해당 문서들을 참조하면 좋다.[12] 문단의 줄을 바꿔서 새 문단을 시작할 때 첫머리에 공백을 삽입하여 공간을 만드는 행위. 첫줄이 옆쪽으로 움푹 들어간듯 보이기 때문에 들여쓰기라 부른다.[13] 아예 기술적으로 들여쓰기의 적용이 어려운 위키들도 있다. 예를 들어 나무위키에서는 문단이 시작되는 것을 표시하기 위해 들여쓰기를 적용시키려 했을 경우, 일반적인 한국어 글쓰기에서의 들여쓰기와는 달리 해당 문단 전체가 왼쪽에 공간을 두는 식으로 들여쓰기가 적용되어 버리므로 유의해야 한다. 이 문제 때문에 나무위키에서는 문단의 시작을 표시하기 위해서 들여쓰기를 사용하는 것이 기술적으로 사실상 불가능하다.[14] 로마자를 사용한 글에서는 줄 바꿈으로 단어 하나가 갈라지면 이전 줄의 마지막 글자의 뒤에 하이픈 기호을 붙인다.

파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 문서의 r3730에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r3730 (이전 역사)
문서의 r613 (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

분류