태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

한국어(한글) 코드 이야기 (8)

2015.06.23 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 


1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코드로 통일되는 시기가 올 수도 있겠지만 아직까지는 한국어만 해도 여러 문자세트와 인코딩이 공존을 하고 있고 소프트웨어 개발자에게는 여간 귀찮은 일이 아닐 수 없다. 이에 대해서 잘 알고 있고 경험이 많은 개발자라면 별 문제가 없지만 한국어 문자세트와 인코딩에 대해서 조금 헷갈리는 경우라면 소프트웨어를 개발하면서 수많은 지뢰를 만나게 된다. 그나마 한국어는 중국이나 일본에 비해서는 문자세트와 인코딩의 표준화가 잘되어 있어서 훨씬 수월한 편이라고 할 수 있다.


이제 유니코드가 대세라고 Application을 유니코드를 지원하도록 만든다고 다 해결되는 것은 아니다. 네트워크를 통해서 다른 시스템과 통신을 할 때 다른 인코딩을 사용할 수도 있고, 파일로 저장할 때 다른 형식을 써야 할 때도 많다. 왜냐하면 아직도 수많은 시스템이 유니코드를 지원하지 않고 있고, 우리는 그런 시스템과도 연동을 해야 하기 때문이다.


데이터베이스의 인코딩을 어떤 것을 선택할지도 큰 이슈다. 지금은 누구나 유니코드의 인코딩을 선택하지만 몇 년 전까지만 해도 EUC-KR이나 다른 인코딩을 선택하기도 했다. 이런 경우 시스템의 국제화를 추진하게 되면 심각한 문제에 봉착하게 된다. 데이터베이스 이슈는 추후 별도로 다루도록 하겠다.


우리는 Application을 개발하면서 외부 라이브러리를 사용하기도 한다. 그런데 외부 라이브러리가 유니코드 기반이 아닌 경우도 많다. 그럴 때는 라이브러리를 사용하기 위해서 문자열을 변환해야 하는 복잡한 문제에 봉착하기도 한다. 상황에 따라 다르지만 유니코드와 여러 가지 인코딩이 공존하는 세상에서 개발해야 하는 개발자들은 이런 문제를 겪기도 하고 해결해야 한다는 것을 알아야 한다.


그래서 현재 한국어를 표현하기 위해서 사용되고 있는 문자세트와 인코딩에 대해서 간단하게 집고 가려고 한다. 물론 문자가 깨지는 경우에 이를 해결하는 데는 경험이 훨씬 중요하다. 하지만 문자세트와 인코딩의 지식은 기본으로 필요하다.


(한국어 문자세트와 인코딩 포함 관계)



1. KSC 5601 (문자세트)


한국산업규격 한국어문자집합이다. 공식 명칭은 KS X 1001이다. 1974년 처음 제정되었고 2004년에 마지막 개정이 있었다. 2바이트 부호체계이며 8,836문자를 규정하고 있다. 한글, 숫자, 특수문자, 한자, 로마자, 그리스문자, 키릴문자 등으로 구성되어 있다. 

한글 2,350자와 한자 4,888자를 정의하고 있는데 실제 사용하는 한글과 한자에 비해서는 턱없이 부족한 문제가 있다.


2. EUC-KR (인코딩)


문자세트는 실제 컴퓨터에서 사용하는 코드는 아니다. 컴퓨터에서는 인코딩을 사용하며 EUC-KR은 널리 사용되는 한국어 인코딩 중 하나다. KSC 5601을 그대로 포함하고 있으며 영어 영역은 ASCII를 사용한다. 정확하게는 KS X 1003인데 ASCII라고 알고 있어도 무방하다. EUC-KR은 KSC 5601이 가지고 있는 문제를 그대로 가지고 있다.


3. ISO-2022-KR (인코딩)


지금은 쓸 이유도 없는 인코딩이지만 하위 호환 때문에 가끔 만나게 된다. ISO2022는 원래 둘 이상의 문자집합을 한꺼번에 표현하기 위한 국제 규약이었는데 여기에 한국어를 추가했다. 지금은 상상이 잘 안되지만 과거에는 Email을 전송할 때 7bit로만 전송하던 시절이 있었다. ISO-2022-KR은 8bit를 사용하는 KSC 5601 문자를 7bit로 전환해서 Email를 전송할 수 있게 하였다. 그럼으로써 ISO-2022-KR을 지원하는 Email 클라이언트에서 한국어 Email을 볼 수 있게 되었다. 코드 중간에 0x0e 문자를 만나면 이제부터 한국어라는 뜻이고 0x0f를 만나면 영어로 간주를 한다. 


지금은 Email을 8bit로 전송할 수도 있고, Base64로 인코딩해서 보내는 방법도 있어서 ISO-2022-KR은 쓸 이유가 점점 없어지고 있다. 또한, Email을 아예 유니코드(UTF-8)로 보내는 비율이 점점 늘고 있다. 유니코드로 Email을 보낸다는 의미는 내가 보낸 Email이 전세계 어디서나 문제없이 볼 수 있다는 의미다. 물론 Email 클라이언트가 유니코드를 지원해야 하며 유니코드 폰트가 존재해야 한다. 아직은 모든 시스템이 유니코드의 모든 문자의 폰트를 포함하고 있지 못하다. 이 이슈는 추후 폰트 관련 글에서 따로 다루겠다.


4. CP949 (인코딩)


마이크로소프트에서 사용하는 한국어 코드페이지다. 원래는 KSC5601을 표현하는 코드페이지였으나 KSC5601에 없는 한글 문자가 많아서 8822자의 현대한글을 추가하였다. 이렇게 문자를 새로 추가하다 보니 한국어 코드의 순서가 가나다 순서와는 다르게 뒤죽박죽이 되는 문제가 있다. 하지만 EUC-KR에서는 표현할 수 없는 많은 문자를 표현 할 수 있다. Windows에서 파일로 “똠방각하”를 저장할 때 ANSI 형식 선택해도 KSC5601에 없는 “똠”라를 저장할 수 있는 이유는 Windows는 EUC-KR 대신 CP949를 선택하기 때문이다. 따라서 CP949의 모든 문자를 EUC-KR 인코딩으로 변환할 수는 없다. 이런 변환 과정을 거치면 몇몇 글자는 깨질 수가 있다. OS에 따라서 한국어 문자가 깨지는 상황이 발생했을 때 OS가 어떠한 인코딩을 사용하는지 살펴볼 필요가 있다.



지금은 위 4가지가 아니라면 거의 유니코드일 것이다. 유니코드에 대해서는 추후 자세히 다룰 것이다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, 국제화

유니코드 영토 전쟁의 승리자는? (7)

2015.06.16 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하여 문자가 깨지는 등 복잡한 문제에 봉착할 수 있다. 이때 유니코드의 체계의 원리를 아는 것은 문제를 해결하는데 도움이 될 것이다.


지구상의 문자를 모두 하나의 문자 코드에 집어 넣는 유니코드를 만드는 작업은 쉬울 수가 없었다. 고서적에 쓰는 문자들도 코드화를 해야 하기 때문에 유사이래 탄생한 모든 문자를 포함해야 했다. 그 중에서 압권은 중국어 즉, 한자다. 현재까지 알려진 한자만 10만자가 넘는다는 설이 있고 공식 한자만 8만자가 넘는다. 그러니 2바이트 유니코드 65,536 글자에는 중국의 한자도 다 들어 갈 수 없었다. 


두번째로 문자가 많은 나라는 한국이다. 현대 한국어 글자는 조합 가능한 문자가 1만자가 넘고 한자도 1만5천자는 사용을 한다. 물론 KSC5601에서는 한글 2350자, 한자 4888자를 정의하고 있지만 모든 글자를 표현하기에는 턱없이 모자란 숫자다. 게다가 고어까지 모두 포함하면 조합 가능한 글자는 백만자가 넘는다고 한다. 물론 실제 사용하는 글자는 훨씬 적다.


이런 상황이라면 유니코드 65,536 글자 안에 어느 나라 글자가 많이 포함되느냐가 관건이 될 수 있다. 


1991년 유니코드 1.0에서는 한국어는 완성형코드가 포함되어 있었고 표현 못하는 글자가 수두룩하고 배열도 엉망이었다. 하지만 1996년에개정된 유니코드 2.0에는 한글 조합형의 모든 글자와 옛한글을 표현할 수 있는 코드 11,172개와 한글 자모가 포함되었다. 그 과정에서 유니코드 1.0에 포함된 한글코드는 사장시키고 새로운 코드영역으로 이동을 했는데 이런 대규모 이동은 유니코드 역사상 획기적인 일이었다. 유니코드 2.0부터는 한국어 표기 문제가 거의 해결되었다고 볼 수 있다. 그로인해 유니코드 1.0을 지원하는 소프트웨어가 유니코드2.0과 호환이 안되서 초기에는 불평이 많았지만 이제는 옛날 얘기가 되었다.




한자는 한국, 중국, 대만, 일본, 베트남 등에서 공통으로 많이 쓰는 한자를 통합하여 약 2만7천자를 할당하였다. 그 외의 한자는 다른 Plane에 포함되었다. BMP에 포함된 2만7천자의 한자는 2바이트로 표현이 가능하지만 나머지 한자는 4바이트를 사용해야 표현할 수 있다. 중국의 고서적을 표현할 때는 4바이트 코드를 써야 하며 한국의 옛한글도 코드는 있지만 전용 소프트웨어가 필요하다.


유니코드의 역사는 훨씬 더 복잡하지만 이 정도로 간단히 알아보고 유니코드 안에는 어떠한 글자들이 있는지 구경이나 한번 해보자. 대표적인 코드 영역을 몇가지 소개한다. 굳이 암기할 필요도 없고 미래에 문자가 깨지는 상황이 발생할 때 약간의 도움이 될 때가 있을 것이다.


문자들은 환경에 따라서 폰트의 지원여부 때문에 깨져 보일 수가 있으니 이미지로 표시를 했다.



다음 시간에는 한국어의 코드체계와 유니코드 인코딩에 대해서 알아보도록 하겠다.

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화

유니코드는 어떻게 탄생했을까? (6)

2015.06.09 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.




소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다.  게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직도 세상은 유니코드로 통일이 되지 못하고 수많은 문자세트가 넘쳐나고 소프트웨어를 개발하다보면 수시로 문자가 깨지고 문제가 발생한다. 그래서 유니코드를 비롯해서 문자세트와 인코딩에 대해서 간단하게 알아볼 기회를 가지려고 한다. 


먼저, 유니코드는 언제, 왜 탄생했는지 그 역사를 간략하게 알아보자. 필자는 유니코드 탄생 이전부터 개발을 했기 때문에 그 역사를 보아 왔다고 할 수 있다. 유니코드의 역사를 알아보기 위해서 그 이전의 문자세트, 문자인코딩의 역사를 거슬러 올라가보자. 


유니코드를 설명하려면 문자세트 문자인코딩이라는 용어를 구분해야 한다. 흔히 헷갈려 하는 용어다. 문자세트는 그야말로 문자들의 집합이다. 문자들의 집합에 각 문자에 번호를 부여한 것이다. 문자인코딩은 그런 문자들을 어떻게 코드를 할당하느냐를 나타낸 것이다. 문자세트를 특별한 변화 없이 그대로 1:1로 나타내는 문자인코딩도 있고, 별도의 규칙에 의해 변경해서 표기하는 문자인코딩도 있다. KSC5601은 문자세트고 이를 영문자와 합쳐서 그대로 인코딩 한것은 EUC-KR이다. 앞으로 문자세트와 인코딩을 마구 섞어서 사용할 것인데 혼동하지는 말자.


1950년대 최초로 컴퓨터가 탄생하고 초창기 컴퓨터에는 표준 문자세트이라는 것이 없었다. 즉, 컴퓨터마다 다른 문자세트를 사용하고 있었다. 그래서 1967년 미국에서 표준 문자세트를 제정한 것이 ASCII다. 미국에서 만들었기 때문에 알파벳과 숫자 등의 글자로 이루어졌다.

 

ASCII는 7비트 128글자를 사용하며 거의 모든 문자세트의 기본이 된다. 하지만 ASCII는 유럽글자를 표현 할 수 없었다. 그래서 유럽 사람들은 1980년대 중반 ASCII를 확장하여 ISO-8859를 만들게 된다. ISO-8859의 특징은 기존 ASCII 영역을 건들지 않고 8비트 128글자 영역을 사용하여 미국에서 작성한 문서도 그대로 볼 수 있게 하였다.


ISO-8859-1은 네델란드어, 노르웨이어, 독일어 등 주로 서유럽의 언어를 지원한다.

ISO-8859-2은 체코어, 폴란드어, 헝가리어 등 주로 중앙유럽의 언어를 지원한다.

ISO-8859-3은 터키어 등 주로 남유럽의 언어를 지원한다. 이런 식으로 ISO-8859-16까지 추가되었는데 암기할 필요는 없다. ISO-8859를 사용해도 여러 유럽어를 동시에 표현할 수는 없었다.


그 무렵 아시아에서는 문자세트 혼란의 시기가 도래하였다.


한국에서는 1980년대 초부터 여러 가지 한글 조합형 인코딩을 사용했다. 1987년 KSC5601(KSX1001)이라는 한글(한국어) 완성형 문자세트가 제정된 후 조합형과 완성형은 공존을 하다 조합형은 사라지게 된다. 조합형과 완성형의 팽팽한 균형이 무너진 시점은 윈도우95가 나오면서부터다. 그럼에도 불구하고 그 당시 똠방박하의 "똠"자를 윈도우에서 쓸 수 없다는 것은 많은 이슈가 되었다.



중국과 일본도 제 각각의 문자세트와 인코딩을 정의해서 전세계, 특히 아시아는 문자세트 춘추 전국시대가 되었다. 한나라 안에서도 수많은 문자세트와 인코딩이 넘쳐나고 있었다. 이는 전세계 컴퓨터, 소프트웨어가 서로 호환되지 않는다는 의미를 얘기한다. 알파벳과 숫자를 제외하고는 깨져버리기 일쑤였다.


하나의 인코딩으로 영어와 한국어는 표시할 수 있고, 영어와 일본어도 표현을 할 수 있다. 하지만 영어, 한국어, 일본어, 중국어 이렇게 다양한 언어를 한꺼번에 표현할 수는 없었다. 그래서 탄생한 것이 ISO2022다. 중간에 특수한 문자를 만나면 문자세트가 바뀌는 것이다. ISO2022 인코딩의 문자열은 중간부터 읽을 경우 무슨 문자인지 알 수 없는 약점이 있었다.


80, 90년대 이런 춘추전국 시대에 개발을 해본 개발자라면 이런 혼란을 잘 알고 있을 것이다. 근래에 개발을 시작한 개발자들에게는 먼 옛날 얘기일 것이다.


그 당시에는 대부분의 소프트웨어가 나라별 버전을 따로 만들곤 했다.


이러한 혼동 속에서 하나의 문자세트로 전세계 문자를 모두 표현하려는 움직임이 있었고, 썬마이크로시스템즈, 애플, MS, IBM, 볼랜드 등의 회사들이 유니코드컨소시엄을 만들어서 전세계 문자를 통합한 유니코드(Unicode)를 만들기 시작했다. 참여한 회사들을 보면 거의 미국 회사인 것을 알 수 있다. 미국 회사들이 전세계에 소프트웨어를 팔다보니 본인들이 힘들어서 통합의 필요성을 느낀 것이다. 그렇게 미국이 주도하여 1991년 유니코드 1.0이 탄생한다. 



(유니코드에 포함된 나라별로 다른 문자들)


이렇게 제정된 유니코드의 문자세트는 UCS-2(Universal Character Set 2)라고 불린다. UCS-2를 가지고는 고어를 포함한 전세계 모든 문자를 표현하는데는 한계가 있다. 사실 중국어만 해도 10만 글자가 넘는다. 그래서 UCS-4에는 고대 언어를 포함한 모든 언어가 포함된다. 하지만 우리는 대부분 UCS-2를 사용하며 유니코드라고 말하면 UCS-2를 의미하는 경우가 많다. 단, Unix계열의 OS에서는 4바이트 문자세트인 UCS-4를 기본으로 사용한다.



향후 소개될 소프트웨어 국제화의 내용을 쉽게 이해하기 위해서는 문자세트, 인코딩 그리고 유니코드에 대해서 잘 알아야 한다. 그래서 본 글에서 간략히 소개를 했다. 다음에는 유니코드의 내부를 좀 살펴보고 인코딩 등 유니코드에 대해서 조금 더 알아보자.


이글은 네이버포스트에 게재한 글입니다.

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화

  1. 조합형,완성형 이야기를 오래간만에 보내요. 일의 특성 상 한글에서 고어자판으로 설정하고 일을 하는데 완성형 일변도로 나갔다면 정말 고전쪽 전산화는 어려울 뻔했네요.

    한자입력도 그랬고 참 우여곡절이 많았네요. 지난 세기를 돌이켜보니.

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

2015.06.02 14:15 by 전규현


잠시 후 Google blogger로 이동됩니다.






김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 부분을 일본어로 고치기 시작했다. 밤을 새워가며 고친 덕분에 일주일안에 모든 문장을 일본어로 수정할 수 있었다. 그래서 테스트를 포함하여 2주일만에 일본어버전을 뚝딱 만들어냈다. 빨리 개발했다고 사장님께 칭찬도 들었다. 


하지만 이렇게 한국어 버전과 일본어 버전의 소스코드가 따로 존재하다 보니 소스코드를 수정하려면 양쪽을 모두 고쳐야 했다. 그래서 개발시간은 기존보다 150%가 소요되었고, 나중에는 귀찮고 시간도 없어서 일본어 버전에는 최신 기능을 반영하지 못하게 되었다. 그러다가 치명적인 버그를 발견하면 양쪽을 모두 고쳤다. 한국어버전과 일본어버전 소스코드는 점점 달라지게 되었다.


그런 와중에 사장님이 중국어 버전도 만들라고 한다. 사장님은 김과장은 2주만 주면 뚝딱 만들어 낸다고 여기 저기 자랑을 하신다. 김과장은 또 소스코드를 복사해서 중국어 버전도 2주만에 만들었다. 이제 소스코드가 세벌이다. 뭘 하나 고쳐도 세 군데를 고쳐야 하는데 관리는 잘 안 된다. 소스코드가 엉망이 되서 관리가 안되는 것을 사장님은 잘모른다. 사장님이 유럽도 진출한다고 하는데 감당이 안돼서 퇴사할까 고민 중이다.


1. 소스코드 복사 


아래 그림과 같이 각 언어 버전 별로 소스코드를 제 각각으로 유지하는 방법으로 주위에서 흔히 볼 수 있다. 일단 소스코드를 복사하면 되돌아 올 수 없는 강을 건넌 것과 같다.



2. 별도의 Application


소스코드를 복사하는 것은 심각한 문제의 시작이기 때문에 국제화된 소프트웨어를 개발하더라도 소스코드를 하나로 유지하기 위한 노력은 꾸준히 되어 왔다. 두 번째 아키텍처는 기본적인 Application의 소스코드는 하나로 유지를 하면서 국제화 라이브러리와 지역화 라이브러리를 조합하여 지역화된 Application을 만드는 것이다.


기존에 Microsoft Office나 Windows에 적용되전 방식이다. 지금은 Microsoft도 바뀌었지만 예전에는 한국어, 일본어 버전을 따로 출시하였다. 물론 내부에서 개발할 때는 소스코드를 하나로 유지한다. 한국어, 일본어 지역화 라이브러리만 다를 뿐이다.


이런 아키텍처는 Application 개발자가 한국어의 특징이나 문화, 일본어의 특징이나 문화를 전혀 알 필요가 없다. 단지 국제화 라이브러리인 i18n library를 사용하기만 하면 된다. 그러면 각 버전에 맞게 다르게 동작하게 된다.


하지만 이 방식은 언어(로케일)별로 별도의 Application을 관리해야 하는 부담이 있다.



3. 하나의 소스코드, 하나의 Application


다음 아키텍처는 소스코드도 하나로 유지를 하고 하나의 Application만 출시를 하는 것이다. 언어(로케일) 설정을 바꾸기만 하면 해당 언어(로케일)로 출력되고 동작하는 것이다. 가장 권장되는 방식이면서 많은 소프트웨어가 사용하고 있다.


이 방식의 장점은 Application에서 국제화 관련 기능을 완전히 독립시킴으로써 Application 개발자의 부담을 덜었다. 그리고 L10n 라이브러리를 추가 장착만 함으로써 다양한 언어(로케일)을 추가로 지원할 수 있게 된다. 흔히 Language Pack이라고 부르기도 하는데 추가로 언어(로케일)를 지원한다고 제품을 다시 출시 하지 않아도 된다. 인터넷에서 Language Pack을 별도로 다운 받아서 설치하기만 하면 된다.


이런 아키텍처를 구성하려면 i18n library를 초기에 잘 만들어 놔야 한다. 언어(로케일)별로 다른 기능을 잘 추상화해서 미리 국제화 모듈을 만들어 놔야 한다. 나중에 고치려면 엄청나게 어렵다. 



먼저 한국어 버전만 만들고 나중에 다양한 언어(로케일)를 추가 지원하려는 계획을 가지고 있다면 어떻게 해야 할까? 그렇다고 대충 한국어 버전을 만들고 나중에 변경하려면 이미 망친 것이다. 미래에 국제화 계획이 있다면 아래 아키텍처처럼 한국어만 지원하더라도 국제화 라이브러리를 별도로 잘 만들어 놔야 한다. 처음에 이런 방식으로 개발하면 개발 시간이 10% 정도 더 들어간다. 하지만 나중에 여러 언어(로케일)를 지원할 때 몇 배, 몇 십 배의 시간이 절약된다.



물론 국제화 라이브러리를 제대로 만드는 것은 쉬운 일이 아니다. 웬만한 경험만으로 만드는 것은 매우 어렵다. 구조적으로도 어렵고 기능적으로도 어렵다. 또한, 입맛에 딱 맞게 만들어 놓은 상용라이브러리를 구하기도 어렵다. 필요한 회사나 개발자가 잘 설계를 해서 만들어야 한다. 


소프트웨어를 개발할 때는 항상 미리 국제화 계획을 검토해야 한다. 지금, 혹은 미래에 국제화 계획이 있다면 처음부터 국제화 아키텍처를 반영해야 한다. 그리고 소스코드는 무조건 한 벌을 유지해야 한다. 또한 Application도 하나로 유지를 해야 한다. 이런 대원칙에서 벗어나면 지옥을 맛보게 될 것이다. 그럼에도 지옥을 맛보지 못했다면 장사가 잘 안돼서 별 문제가 없었거나, 소프트웨어가 너무 작아서 어떻게 해도 별 문제가 안 되는 경우일 것이다. 


소프트웨어의 아키텍처는 항상 회사의 미래 전력을 내다봐야 하는 것이다. 오늘의 문제만 해결한다면 좋은 아키텍처라고 볼 수 었다.


이글은 네이버포스트에 게재한 글입니다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화

  1. Blog Icon
    다음엔

    아키텍처 디자인에 하단 국제화 라이브러리 모듈 설계 말고도 상단부 UX,UI 도 국제화에 맞게 바뀌어야 됩니다.

    따라서 전체적인 full architecture design 그림에 대한 개념도가 필요할 것으로 보이는데요.

  2. Blog Icon

    비밀댓글입니다

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

2015.05.26 14:10 by 전규현


잠시 후 Google blogger로 이동됩니다.





10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서 버그가 보고 되었다.


날짜를 2015/05/15 이렇게 표시를 했는데 미국에서는 05/15/2015로 표기해 달라는 것이다.


김과장은 소스코드를 다음과 같이 수정해서 버그를 해결했다.


if (locale == “en_US”)

     date_format = “mm/dd/yyyy”;

else

     date_format = “yyyy/mm/dd”;


물론 의사코드(pseudocode)이므로 정확한 소스코드는 아니다. 예를 든 것뿐이다. 


그런데 얼마 안 있어서 호주에서는 15/05/2015로 표기를 해달라고 하는 것이다. 기존의 표기는 헷갈린다고 한다. 이렇게 하나씩 고치다 보니 날짜뿐만 아니라 여러 가지 분야에서 끝도 없는 수정이 계속 되었다. 문제는 이렇게 고쳐달라고 요청하는 사용자보다 틀린 것을 참고 쓰거나 아예 포기를 해버리는 사용도 많을 텐데 파악이 안 된다는 것이다.


김과장은 로케일만 알았지 로케일이 시스템에 무엇을 바꾸는지는 잘 몰랐던 것이다. 김과장은 로케일을 제대로 이해하고 있었다면 이렇게 김과장이 직접 로케일의 변화에 따른 프로그래밍을 직접 할 필요가 없었다. 그냥 시스템에서 제공하는 함수를 쓰면 되는 것이었다. 물론 OS나 개발 라이브러리에 따라서 사용법은 조금씩 다르다.




로케일은 시스템의 무엇을 바꿀 수 있을까? 이렇게 로케일이 시스템에 미치는 영향을 6가지로 구분하여서 이를 로케일 카테고리라고 한다.


로케일 카테고리의 약자인 “LC”를 앞에 붙여서 LC_TIME, LC_NUMERIC, LC_MONETARY, LC_COLLATE, LC_CTYPE, LC_MESSAGES 이렇게 6가지가 정의되어 있다. 대부분의 OS와 개발 라이브러리에서 이를 지원하고 있다.


사용법은 setlocale(로케일 카테고리, 로케일) 이다. 즉, setlocale(LC_TIME, “de_DE”) 이렇게 하면 날짜와 시간을 독일 식으로 표현하라는 얘기다. 이렇게 6개를 모두 설정하려면 귀찮기 때문에 LC_ALL이라는 것을 둬서 setlocale(LC_ALL, “de_DE”)이라고 하면 한번에 6개의 카테고리가 모두 독일식으로 설정된다. 


그럼 하나씩 알아보자.


LC_TIME 시간과 날짜의 표현에 대한 설정이다. 김과장이 이 카테고리만 설정하고 이와 관련된 함수만 사용했어도 위에서와 같은 고생은 안 해도 됐다. LC_TIME이 영향을 미치는 함수는 개발 라이브러리에 따라서 다르다. GNU C 라이브러리인 경우에는 strftime(), strptime()이다. PHP나 Python도 strftime()을 지원한다. LC_TIME를 세팅하면 로케일 별로 다른 시간과 날짜가 표시된다.


LC_NUMERIC 숫자 표현을 위한 설정이다. 나라마다 숫자 표현이 크게 다르다는 것을 모르는 개발자도 상당히 많다. 우리는 소수점으로 점(.)을 쓰는 것을 당연하게 생각하지만 그렇지 않은 나라도 매우 많다. 우리가 이렇게 로케일별로 다른 표현을 다 연구할 필요는 없다. LC_NUMERIC이 영향을 미치는 함수를 쓰기만 하면 된다. strtod(), atof()가 그 예이고 sprintf(), printf() 함수도 영향을 받는다. 자세한 것은 나중에 다루겠다.


LC_MONETARY 화폐, 금액을 다루기 위한 설정이다. 영향을 받는 함수는 strfmon()이 있다. 최근에는 유로화를 지원하기 시작하면서 좀 복잡해졌다. 라이브러리 별로 지원하는 것이 조금씩 다르기도 하다.




LC_COLLATE 정렬에 관한 것인데 조금 복잡하다. 정확하게 이해하려면 사전에 어떠한 순서로 정렬이 되는 것이 자연스러운지 생각해보면 된다. 영어에는 대소문자에 대한 정렬 방법이 일반 ASCII 정렬방법과는 약간 다르고 한국어에도 ‘ㄱ’이 어느 위치에 정렬되어야 하는지는 EUC-KR 코드의 순서와는 약간 다르다. ASCII 순서에 따르면A, B, a, b 이렇게 되지만 사전에서는 a, A, b, B이기 때문이다. 물론로케일별로 다르다. Collation이라는 용어는 나중에 Database 설정에도 나오기 때문에 잘 알아두는 것이 좋다. LC_COLLATE가 영향을 미치는 함수는 strcoll(), wcscoll() 등이 있다. 즉, 이런 함수를 이용해서 정렬 함수를 만들어야 각 로케일에 맞는 정렬이 된다.


LC_CTYPE 문자의 종류를 다루기 위한 설정이다. 문자인가 숫자인가, 대소문자 구분을 다룬다. strlen(), stricmp(), strlwr(), strupr() 등의 함수가 영향을 받는다.


LC_MESSAGES 로케일 별로 번역된 메시지를 표현하기 위한 설정이다. catopen(), gettext() 등이 영향을 받는데, 메시징은 국제화에서 별도로 다뤄야 할 만큼 중요하기 때문에 추후 여러 회에 걸쳐서 다뤄질 것이다.


이렇게 거의 모든 OS와 개발라이브러리에서 다루는 6가지 로케일 카테고리 외에도 LC_ADDRESS, LC_NAME, LC_PAPER, LC_TELEPHONE 등을 사용하는 곳도 있다.


우리는 로케일을 지정함으로써 로케일별로 다른 표현 및 기능이 자동으로 바뀌도록 개발을 해야 한다. 소스코드에 if (locale == "de_DE") 등과 같은 표현이 절대로 있어서는 안된다. if (lang == "english")는 더더욱 안된다.


이미지 by Kolmisoft

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 국제화

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

2015.05.19 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다.


경영자가 개발자에게 독일어 버전을 만들라고 하면 어떨까? 대부분은 콩떡 같이 말하면 찰떡같이 알아듣겠지만 엄밀히 말하면 틀린 얘기다. 정확한 표현이 아니라고 하는 것이 낫겠다.


우리는 우연히 한 국가에서 하나의 언어만 쓰고 있다. 공식 언어가 존재한다. 하지만 미국만 하더라도 공식 언어가 존재하지 않는다. 누구나 미국의 공식 언어는 영어라고 생각하지만 관습 헌법 같은 것일 뿐이다. 그나마 미국은 영어가 대표적인 언어다. 하지만 바로 위의 캐나다로 가면 영어와 프랑스어를 쓰고 있으며 어느 한 언어를 무시할 수 없다.


스위스로 가면 독일어, 프랑스어, 이탈리아어, 로만슈어의 네 가지 언어가 공용 언어다.  이렇게 한 나라에서 여러 가지 언어를 쓰는 경우는 매우 많다. 오히려 한 가지 언어만 쓰는 나라가 더 적다.


반대로 언어의 관점으로 보면 하나의 언어가 매우 많은 나라에서 쓰인다. 독일에서 쓰는 표준 독일어와 스위스에서 쓰는 독일어는 조금 다르다. 독일 사람들은 스위스 사람들이 말하는 독일어를 이해하지 못하곤 한다. 스페인어도 매우 많은 나라에서 쓰인다. 스페인을 비롯해서, 멕시코, 칠레, 미국 등 국가에서 사용된다. 


그럼 독일어 버전을 만들라고 하면 표준 독일어를 말하는 것일까? 오스트리아, 스위스, 룩셈부르크 어느 나라의 독일어를 지원하라는 얘기일까? 대충 다 알아보지 않을까?라고 생각하는 것은 안일한 생각이다. 각 나라 별로 같은 언어라고 하더라도 쓰는 방법이 다 다르다.


그래서 소프트웨어 국제화에서는 언어와 국가, 정확하게 말하면 지역을 조합해서 부른다. 이것을 로케일(Locale)이라고 한다. 그래서 앞으로 소프트웨어 국제화를 얘기할 때는 언어나 국가로 얘기하지 않고 로케일을 기준으로 얘기를 해야 한다.


로케일의 컨셉은 거의 모든 OS와 개발 언어에 포함되어 있다. 


로케일의 표기 방법은 다음과 같다. 


[language[_territory][.codeset]]


language는 언어를 나타내며 알파벳 소문자 두 글자로 이루어져 있다. 한국어는 “ko”, 일본어는 “ja”, 영어는 “en”, 독일어는 “de”라고 표기한다. ISO639에 표준이 정의 되어 있다.


territory는 지역을 의미하며 알파벳 대문자 두 글자를 사용하며 생략하기도 한다. 한국은 “KR”, 일본은 “JP”, 미국은 “US”, 독일은 “DE”를 사용한다. ISO3166에 표준이 정의 되어 있다.


codeset은 어떠한 코드셋을 사용했는지 나타내는 것으로 생략할 수 있다. 한국어인 경우 “UTF-8” 또는 “euc-kr”을 사용한다.


그래서 한국어는 ko_KR이라는 로케일을 사용하게 된다.


독일어 하나만 해도 de_DE(독일), de_AT(오스트리아), de_LU(룩셈부르크), de_CH (스위스) 이렇게 여러 가지 로케일로 표한 할 수 있다. 


이렇게 해서 탄생할 수 있는 로케일의 개수는 수백 개가 넘지만 개발 언어의 라이브러리 별로 지원하는 범위가 조금씩 다르다. 하지만 우리가 흔히 지원하려고 하는 로케일은 거의 포함이 되어 있으므로 걱정할 필요는 없다.


이외에 “C” 로케일이라는 것이 있다. 이것은 GNU C에서 사용되는 것으로서 로케일을 지정하지 않으면 지정되는 디폴트 로케일로서 “POSIX”로케일이라고도 한다.


어플리케이션에서 로케일을 지정하는 방법은 setlocale() 이라는 함수를 쓰거나 환경 변수를 바꾸는 함수를 사용하는 것이다. OS나 개발 언어에 따라서 조금씩 다르다. 


로케일이 바뀌면 무엇이 바뀌는지는 다음 연재글에서 알아보자.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, locale, 국제화

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

2015.05.12 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든 서비스든 국제화, 지역화에 실패하여 해외 시장에서 실패하는 경우가 매우 많다. 그럼 소프트웨어 회사들, 개발자들이 흔히 하는 실수에는 어떤 것이 있는지 알아보자. 실수를 알아보는 것은 같은 실수를 하지 않도록 교훈을 준다.


먼저 소프트웨어 국제화, 지역화를 하는데 있어서 기술적인 목표를 알아보자. 비즈니스적인 목표는 개발자들이 크게 상관할 바는 아니지만 기술적인 목표는 잘 알아야 흔들림 없이 개발을 할 수 있다.


첫 번째 목표는 국제화, 지역화 품질이다. 해당 지역, 국가에서 받아들여 질만해야 한다. 어색한 번역 외에도 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역, 언어별로 신경을 써야 한다. 소프트웨어마다 신경을 써야 하는 범위가 다르고 나라마다 받아들이는 정도도 다르다. 첫술에 이 모든 것을 다 처리하기는 어렵고 앞으로 중요한 순서대로 자세히 알아보려고 한다.


두 번째 목표는 생산성이다. 국제화, 지역화를 위해서 너무 많은 시간과 비용이 들어간다거나 이를 유지하기 위해서 많은 부담이 되면 실패다. 특히, 번역은 소프트웨어가 업그레이드 될 때마다 계속 변하는데 번거로운 수동 프로세스로 진행을 하면 비용도 많이 들뿐더러 실수로 인한 버그가 발생하게 된다. 또한 국제화, 지역화 아키텍처를 잘못 만들면 돌이킬 수 없는 비효율의 구렁텅이로 빠지게 된다. 아키텍처와 프로세스에 대해서도 앞으로 다루겠다.


그럼 많은 소프트웨어 회사들이 흔히 빠지는 실수는 어떤 것이 있나 알아보자. 우리는 이런 함정을 피해 다녀야 한다.


첫째, 일단 한국어 버전을 먼저 만들고 나중에 국제화, 지역화를 적용한다.


의도했던 의도하지 않았던 이런 회사는 매우 많다. 혼자서 만드는 아주 작은 소프트웨어라면 어떻게 해도 다 되지만 중간 규모 이상의 소프트웨어를 나중에 국제화하는 것은 다 지어서 아파트에 주민들이 살고 있는 상황에서 리모델링을 하는 격이다. 제대로 국제화가 되지도 않고 비용도 10배 이상 많이 들어간다.


둘째, 번역이 전부인줄 알고 번역만 한다.


경영자들은 아주 쉽게 개발자에게 “영어 버전 만들어”, “독일어 버전 만들어” 이렇게 얘기를 한다. 물론 이 말은 정확한 표현도 아니다. 이 시리즈를 계속 읽다 보면 왜 이렇게 말하면 안 되는지 알게 된다. 번역은 소프트웨어 국제화 시 고려해야 할 200가지 중에서 한가지일 뿐이다. 200가지 전부를 완벽하게 지원하는 것은 어떠한 소프트웨어라도 불가능하지만 그중 몇 가지는 꼭 신경을 써야 한다.


셋째, 해외 버전을 별도로 만드는 것이다.


현재 한국어버전 소프트웨어 밖에 없는 경영자가 어느 날 갑자기 “한달 안에 일본어 버전을 만들어”라고 강요를 하면 개발자들이 흔히 하는 선택은 소스코드를 그대로 복사해서 소스코드의 한국어 부분을 전부 일본어로 바꾸는 것이다. 이 방법은 가장 빠른 방법이지만 가장 느리다. 첫 버전은 가장 빠르지만 점점 느려진다. 소스코드를 수정할 때마다 두 소스코드를 모두 고쳐야 한다. 이 와중에 “독일어 버전도 만들어”라고 하면 개발자는 앞이 캄캄해진다. 첫번째 소스코드가 복사된 순간 “지옥문”을 연 것이다. 무식한 경영진을 탓해야 하지만 그렇다고 소스코드를 복사한 개발자도 똑 같은 책임이 있다.


이런 실수는 거대기업을 무너뜨리는 결과를 낳기도 한다.


넷째, 국제화, 지역화 기능을 모두 직접 구현하는 것이다.


이는 자동차를 만들라고 했더니 타이어도 직접 제작하고 유리를 녹여서 유리창도 만들고 에어백도 직접 생산하는 꼴이다. 자동차를 제대로 만드는 방법은 설계를 잘하고 핵심 부품만 우리가 만들고 수많은 부품은 사다가 조립하고 것이다. 그런데 많은 개발자들은 그런 부품이 시장에 있는지도 모르고 직접 만들곤 한다. 물론 엉터리다. 수십 년간 진화해온 전문 부품을 개발자가 며칠 동안 흉내 낼 수 있겠는가? 특히 메시지 번역관련 라이브러리는 많이들 직접 만들어 쓰는데 필자가 수십 가지 사례를 봐왔지만 제대로 만들어서 쓰고 있는 사례는 0 건이었다. 그 외에도 날짜함수, 숫자함수를 직접 만들어서 낑낑대며 고생하는 개발자들도 많이 봐왔다. 국제화, 지역화 기능은 표준이 있으며 직접 구현해야 하는 것도 있지만 상당수는 라이브러리를 이용하거나 OS에 이미 포함된 기능을 써야 한다.


다섯째, 한국어 코드체계를 기반으로 개발을 한다.


한국어 버전을 먼저 만든 경우 흔히 저지르는 실수인데 한국어 인코딩인 “EUC-KR”로 DB나 파일을 저장할 경우 중국어, 일본어나 다른 언어를 저장하려고 할 경우 글자들이 깨지게 된다. 영어까지는 저장하는데 문제가 없어서 무신경하게 지나가곤 한다. “EUC-KR”은 전세계 모든 글자를 담을 수가 없다. 제품이든 서비스든 일단 “EUC-KR”기반으로 소프트웨어를 개발하면 나중에 유니코드 기반으로 소프트웨어를 변경하기는 매우 어렵다. 데이터를 변환해야 하며 모든 기능을 다시 다 테스트 해야 한다. 엄두가 나지 않는 일인 경우가 많다.


여섯째, 우리의 기준으로 외국을 이해하는 것이다.


우리나라가 이러하니 다른 나라도 이럴 것이다라고 착각을 하는 경우다. 우리가 “.”을 소수점으로 사용하니 다른 나라도 그럴 것이다. 단어 사이에는 띄어쓰기를 할 것이다. 종이는 다 A4용지를 사용할 것이다. 하지만 전세계에는 수많은 다른 문화가 있다. 물론 완벽하게 이 모든 문화를 지원할 수는 없지만 일단 다르다는 의심을 가지고 시작해야 한다. 그 중에서 중요한 것들은 지원을 해야 한다.





그럼 어떻게 해야 할까? 반대로 하면 된다. 처음부터 국제화, 지역화 전략을 가지고 아키텍처를 구성해야 하며 하나의 소스코드를 유지해야 하고 잘 개발된 표준과 라이브러리를 이용해서 유니코드를 기반으로 만들어야 한다. 


혹시 경영자가 당장 외국 버전을 턱도 없이 짧은 시간 내에 만들어 내라고 한다면 “그 시간 안에는 안됩니다. 아키텍처를 제대로 구성해서 제대로 만들려면 시간이 더 필요합니다.”라고 주장할 용기가 있어야한다. 이런 것이 씨도 안 먹히는 조직문화를 가진 회사도 많지만 이는 경영자가 시켰다고 6개월 후면 무너질 것을 알면서도 다리를 만드는 것도 같다. 누구의 책임이 더 클까? 생각해볼 문제다. 모든 것을 경영자 등 외부의 탓으로 돌리는 것은 경계해야 할 자세다.


필자는 수십개의 회사를 직접적으로 또 간접적으로는 더 많은 회사의 상황을 직접 봐왔고 이런 어설픈 국제화 적용으로 망해가는 회사를 봐왔기 때문에 이 시리즈를 시작하게 된 것이다. 나는 지식과 정보, 경험, 노하우을 전하겠지만 이것이 얼마나 도움이 될지는 독자의 몫이다.


이 글은 네이버포스트에 게재한 글입니다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 국제화

외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1)

2015.05.05 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다.


오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에 올리면 바로 다음날부터 전세계 수십, 수백 나라에서 즉시 사용된다.


이제 소프트웨어 국제화는 소프트웨어 개발자라면 필수적으로 알아야 할 지식이다. 소프트웨어 국제화 전문가가 되기 위해서는 십 수년의 공부와 경험이 필요하지만 최소한의 기본 지식은 갖추도록 하자.


기본적으로 영어권 개발자들이 만든 소프트웨어는 국제화에 대해서 별로 신경을 안 써도 큰 문제 없이 전세계에서 사용되는 경우가 많다. 우리도 영어만 지원하는 소프트웨어를 얼마나 많이 써왔던가? 비단 메시지만 영어로 나오는 것뿐만 아니라 날짜 표기, 이름 표기 등도 우리 문화와는 다르지만 소프트웨어를 사용하는 데는 큰 문제가 없다. 물론 한국어 폰트가 깨지는 등 문제가 있는 경우도 많지만 개발자들은 이런 것은 신경도 안 쓰는 경우가 많다. 우리는 소수 사용자이기 때문이다.


하지만 비 영어권 개발자들이 만든 소프트웨어는 상황이 전혀 다르다. 기본적으로 우리 문화에 맞춰서 개발한 소프트웨어는 영어권뿐만 아니라 우리나라를 제외한 대부분의 나라에서 거부감을 갖게 된다. 그만큼 우리나라 개발자들이 만든 소프트웨어가 전세계로 확산되기는 쉽지 않다. 그러다 보면 전세계 1% 시장이라는 우리나라 소프트웨어 시장만을 대상으로 소프트웨어를 만들게 된다.


100배 큰 시장으로 나가기 위해서는 소프트웨어 국제화를 잘 알아야 한다.


일단 용어부터 알아보자.


첫 번째 용어는 국제화, 영어로는 Internationalization이다. 이 용어는 1985년에 Apple에서 사용하기 시작하였다. 오랫동안 이렇게 긴 영어 단어로 사용되다가 유니코드 컨소시엄에서 i18n이라는 줄임말을 사용하기 시작했다. 사실 정확하게 누가 먼저 사용했는지는 알기 어렵다. "인터네셔널라이제이션"이라는 긴 단어를 발음하다보면 혀가 꼬이기 일쑤다. 그래서 i와 n 사이에 18글자의 알파벳이 있다는 의미로 i18n을 사용하기 시작했다.


i18n은 소프트웨어를 여러 나라 언어와 문화를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다. i를 소문자로 쓰는 이유는 대문자로 쓸 경우 L의 소문자와 헷갈리기 때문이다.

 

두 번째 용어는 지역화, 영어로는 Localization이다. 이 또한 줄여서 L10n이라고 한다. L를 흔히 대문자로 쓰는 이유도 역시 헷갈리지 않게 하기 위함이다. 


L10n은 소프트웨어를 특정 지역의 언어와 문화를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.




전세계 개발자와 회사들은 1980년대부터 본격적으로 소프트웨어 국제화와 지역화에 대해서 연구를 해왔고 그 결과 1991년 유니코드가 탄생을 하였고 수많은 표준이 제정되었다. 그 지식과 정보는 너무나 방대해서 어느 개발자도 모두 알기는 어렵다. 따라서 앞으로 이 중에서 소프트웨어 개발자가 알아야 할 필수적인 내용을 연재하겠다.


이 글인 네이버포스트에 게재한 글입니다.

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 소프트웨어국제화

QA팀이 필요없다고?

2013.08.22 20:06 by 전규현


잠시 후 Google blogger로 이동됩니다.






최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다.


회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^)


좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다.


사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상은 택도 없을 것이다.


겉으로는 유망한 스타트업이고 Global Service를 준비중이며, 대규모 IR을 진행하고 있다고 한다. 그래도 꽤 유망하다는 스타트업이 이런 정도의 수준이라니 실망스럽기 짝이 없다.


회사의 품질관리를 고객에게 맡긴다는 것도 우습고 고객이 비용을 들여서 테스트를 해준다는 것도 우습다. 고객은 확인하는 정도의 Acceptance Test라면 말이 되지만 이렇게 같이 개발하는 형태의 개발은 세계적으로 유래를 찾아보기 어려울 것 같다.


이런 형태가 가능한 것이 스펙도 불확실한 상태에서 개발을 하다보니 고객과 개발사가 같이 으쌰으쌰하면서 개발을 한다. 주먹구구의 대표적인 행태이다. 이러다 보니 제대로 기획된 제품이 만들어지기 보다는 고객 담당자 취향대로 개발이 되곤 한다.


필자의 경험에 의하면 많은 회사들이 이 회사와 크게 다르지 않다. 또한번 갈길이 멀고 넘어야 할 산이 많다는 것을 느낀다.



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/품질관리

  1. "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"
    뭔가 있어보이는 전형적인 개소리네요. ㅎㅎ
    고객이 테스트를 해준다니 조금 이해가 가지만, 고객이 할 테스트와 연구소내에서 할 테스트는 좀 구분이 되어야 겠죠.
    근데 저도 그런 형편없는 회사에 다니는 1인 이네요 ㅜ.ㅜ

  2. 그래서 우리 회사도 QA 뽑고 있습니다.. 좋은 글 감사 하하 :)

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

2013.06.03 23:37 by 전규현


잠시 후 Google blogger로 이동됩니다.






소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 


그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.


1%


스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.


10%


그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.


30%


이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.


100%


SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.


따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.


image by Nuwandalice

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 개발 경력을 꽤 되는데 SRS 는 적어 본 적이 없는 SRS 초보자입니다.

    지난 번 SRS 강의를 들으며 나름대로 이해(or 오해 ^^) 한 바가 있는데요.

    SRS 는 템플릿이 아니고 "글을 잘 써야 한다" 는 말씀에서 느끼는 바가 있어서요.

    요즈음은 "나는 기술자가 아니라 소설가이다" 라는 자기 최면을 걸어 놓고 '나름 SRS(?)' 쓰는 걸 시도하고 있습니다.

    맥락을 전혀 모르는 독자들에게 내가 고민 했던 것, 하고 싶은 말을 충실히 적는 글짓기 연습부터 하고 있는 셈이지요.

    문장력이 좀 생기면 그때 가서 템플릿에 맞추어 볼 생각입니다.

    우리 회사 개발자들은 제 '나름 SRS'에 시큰둥 하고요.

    마케팅/기획 쪽 분들은 아주 좋아 하시더군요. ^^

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..