<div>예전부터 만들어온 프로그램이 있다면 그걸 유니코드를 지원하게 포팅하는 난이도는 있을거고요.

</div>그게 아니라 처음부터 만드는거면, 사실 귀찮은거지 별로 어려운 건 없습니다.

제가 생각한 프로그램은 오래 된 건 아니니 귀찮은 것인가 보군요.<div>답변, 고맙습니다.</div>

컴파일러에서 기본적으로 유니코드를 지원하지 않는 경우가 있습니다.<div>그런데 그런 경우에도 몇글자만 넣어주면 유니코드 인식이 잘 됩니다.</div><div><br></div><div>...결론적으로 프로그래머가 귀찮았던겁니다.</div>

프로그래머적인 입장에서 말하자면, 기본설정이 유니코드가 아니기 때문입니다.<br>프로그래밍을 배울때 기준도 유니코드가 아닌 Ansi코드로 배웠기 때문에 익숙치 않을 뿐더러,<br>유니코드를 지원해준다는것은 여전히 Ansi코드도 지원해주는것이 일반적입니다. <br>그 타협점으로 생겨난것처럼 보이는 UTF-8같은것도 고려해야 하고..<br>케이스에 따라 유니코드를 고려하는것 만으로 수배 더 힘들어집니다.<br>단순히 '귀찮아서'의 범주를 벗어납니다. <br>특히나 영문권에서는 유니코드를 왜 지원해줘야 하는것인지 납득하기 힘들죠.<br>

보통 유니코드 지원이라고 말을 할 때 그 유니코드 지원이, UTF-8, UTF-16(LE, BE), UTF-32(LE, BE) / BOM 여부··· 등을 포함해서 다 지원하는 걸 말하진 않습니다.<div>기존의 Ascii 기반 레거시를 지원할 필요가 있으면 그냥 UTF-8로 만들면 되고, 그런게 없으면 아무거나 골라 잡아도 되죠. (LE나 BE는 보통 아키텍처에 따라 따라오기 마련이고, 역시 해당 프로그램이 여러 아키텍처를 커버해야 할 필요가 없을 때는 신경 쓰지 않아도 되는 부분입니다.) 구버전 프로그램이 존재하고 해당 국가 전용 인코딩으로 만들어진 레거시가 있을 경우에는 조금 이야기가 다르지만, 대부분의 프로그램은 이런 경우가 아닙니다.</div><div><br></div><div>표준이 정해진지 상당히 오랜 시간이 지난 C++ 같은 경우는, 유니코드를 지원하면서 크로스 컴파일이 가능한 프로그램을 만들기 위해서는 좀 더 신경 써 줘야 하는 부분이 있긴 합니다만 (컴파일러별로 동작이 다른 부분이 여러가지 있습니다. 예를 들어서 VS의 경우 유니코드 문자열을 처리할 때는 C 표준에서 정의된 함수가 아닌, 별개의 함수를 사용하는 경우가 일반적이죠. 그런 부분의 잡음을 해결하기 위해 C++0x에서는 유니코드 지원을 위해 여러가지 추가요소가 등장하고요.) 역시 크로스 컴파일을 고려하지 않으면 크게 신경을 써야 할 만한 부분은 없습니다.</div><div><br></div><div>사실 윈도의 대부분의 프로그램이 ANSI(라기보단 사실 시스템 기본 인코딩이라고 봐야죠.) 기반으로 만들어 지듯, 리눅스의 대부분의 프로그램이 UTF-8 기반으로(역시 이것도 UTF-8을 시스템 기본 인코딩으로 사용하는 경우가 많으니까요) 만들어 진다는 걸 생각해 보면, 유니코드 지원이 본질적으로 어려운게 아님을 쉽게 알 수 있다고 봅니다.&nbsp;</div><div>실제로는 시스템 기본 인코딩이 아닌 프로그램을 만들기 위해서 추가적인 설정을 하는게 귀찮던지, 아니면 아예 방법을 모르고 있던지 둘 중 하나죠. (물론 타국인이 사용할 걸 고려할 필요가 없는 프로그램이라면, 추가적인 '약간'의 작업을 할 필요가 없다고 판단하는 것도 충분히 옳을 수 있습니다. 그런데 그게 난이도가 있는 작업은 명백히 아닙니다.) 실제로 시스템 기본 인코딩을 사용할 때의 귀찮음과 특정 유니코드 인코딩을 사용할 때의 귀찮음이 등가라면 (파이썬이 이런 경우에 해당합니다.) 윈도에서만 동작하게 만들어진 프로그램이라도 기본 인코딩이 UTF-8이거나 한 경우를 흔히 볼 수 있습니다.</div>