본문 바로가기

프로젝트

한국어(한글) 코드 이야기 (8) 유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코드로 통일되는 시기가 올 수도 있겠지만 아직까지는 한국어만 해도 여러 문자세트와 인코딩이 공존을 하고 있고 소프트웨어 개발자에게는 여간 귀찮은 일이 아닐 수 없다. 이에 대해서 잘 알고 있고 경험이 많은 개발자라면 별 문제가 없지만 한국어 문자세트와 인코딩에 대해서 조금 헷갈리는 경우라면 소프트웨어를 개발하면서 수많은 지뢰를 만나게 된다. 그나마 한국어는 중국이나 일본에 비해서는 문자세트와 인코딩의 표준화가 잘되어 있어서 훨씬 수월한 편이라고 할 수 있다. 이제 유니코드가 대세라고 A.. 더보기
유니코드 영토 전쟁의 승리자는? (7) 이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하여 문자가 깨지는 등 복잡한 문제에 봉착할 수 있다. 이때 유니코드의 체계의 원리를 아는 것은 문제를 해결하는데 도움이 될 것이다. 지구상의 문자를 모두 하나의 문자 코드에 집어 넣는 유니코드를 만드는 작업은 쉬울 수가 없었다. 고서적에 쓰는 문자들도 코드화를 해야 하기 때문에 유사이래 탄생한 모든 문자를 포함해야 했다. 그 중에서 압권은 중국어 즉, 한자다. 현재까지 알려진 한자만 10만자가 넘는다는 설이 있고 공식 한자만 8만자가 넘는다. 그러니 2바이트 유니코드 65,536 글자.. 더보기
유니코드는 어떻게 탄생했을까? (6) 소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직도 세상은 유니코드로 통일이 되지 못하고 수많은 문자세트가 넘쳐나고 소프트웨어를 개발하다보면 수시로 문자가 깨지고 문제가 발생한다. 그래서 유니코드를 비롯해서 문자세트와 인코딩에 대해서 간단하게 알아볼 기회를 가지려고 한다. 먼저, 유니코드는 언제, 왜 탄생했는지 그 역사를 간략하게 알아보자. 필자는 유니코드 탄생 이전부터 개발을 했기 때문에 그 역사를 보아 왔다고 할 수 있다. 유니코드의 역사를 알아보기 위해서 그 이전의 문자세트, 문자인코딩의 역사를 거슬러 올라가보자. 유니코드를 .. 더보기
외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5) 김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 부분을 일본어로 고치기 시작했다. 밤을 새워가며 고친 덕분에 일주일안에 모든 문장을 일본어로 수정할 수 있었다. 그래서 테스트를 포함하여 2주일만에 일본어버전을 뚝딱 만들어냈다. 빨리 개발했다고 사장님께 칭찬도 들었다. 하지만 이렇게 한국어 버전과 일본어 버전의 소스코드가 따로 존재하다 보니 소스코드를 수정하려면 양쪽을 모두 고쳐야 했다. 그래서 개발시간은 기존보다 150%가 소요되었고, 나중에는 귀찮고 시간도 없어서 일본어 버전에는 최신 기능을 반영하지 못하게 되었다. 그러다가 치명.. 더보기
외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4) 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로 표기를 해달.. 더보기
독일어 버전 소프트웨어란 말이 잘못된 이유 (3) 본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자가 개발자에게 독일어 버전을 만들라고 하면 어떨까? 대부분은 콩떡 같이 말하면 찰떡같이 알아듣겠지만 엄밀히 말하면 틀린 얘기다. 정확한 표현이 아니라고 하는 것이 낫겠다. 우리는 우연히 한 국가에서 하나의 언어만 쓰고 있다. 공식 언어가 존재한다. 하지만 미국만 하더라도 공식 언어가 존재하지 않는다. 누구나 미국의 공식 언어는 영어라고 생각하지만 관습 헌법 같은 것일 뿐이다. 그나마 미국은 영어가 대표적인 언어다. 하지만 바로 위의 캐나다로 가면 영어와 프랑스어를 쓰고 있으며 어느 한.. 더보기
소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2) 우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든 서비스든 국제화, 지역화에 실패하여 해외 시장에서 실패하는 경우가 매우 많다. 그럼 소프트웨어 회사들, 개발자들이 흔히 하는 실수에는 어떤 것이 있는지 알아보자. 실수를 알아보는 것은 같은 실수를 하지 않도록 교훈을 준다. 먼저 소프트웨어 국제화, 지역화를 하는데 있어서 기술적인 목표를 알아보자. 비즈니스적인 목표는 개발자들이 크게 상관할 바는 아니지만 기술적인 목표는 잘 알아야 흔들림 없이 개발을 할 수 있다. 첫 번째 목표는 국제화, 지역화 품질이다. 해당 지역, 국가에서 받아들.. 더보기
외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1) 가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다. 오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에 올리면 바로 다음날부터 전세계 수십, 수백 나라에서 즉시 사용된다. 이제 소프트웨어 국제화는 소프트웨어 개발자라면 필수적으로 알아야 할 지식이다. 소프트웨어 국제화 전문가가 되기 위해서는 십 수년의 공부와 경험이 필요하지만 최소한의 기본 지식은 갖추도록 하자. 기본적으로 영어권 개발자들이 만든 소프트웨어는 국제화에 대해서 별로 신경을 안 써도 큰 문제 없이 전세계에서 사용되는 경우가 많다. 우리도 영어만 지원하는 소프트웨어를 얼마나 많이 써왔던가? 비단 메시지만 영어로 나오는 것뿐만 .. 더보기
QA팀이 필요없다고? 최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다. 회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^) 좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다. 사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상.. 더보기
SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까? 소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?남이 작성한 SRS를 보면 도움이 될까? 가상으로 한번 써보면 도움이 될까? 케이스별로 얼마나 도움이 될지 알아보자. 1% 스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?1%정도 밖에 도움이 안된다.남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다. 10% 그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면.. 더보기

티스토리툴바