태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '기반시스템/버그관리'

이슈를 모으기도 정말 어렵다.

2012.05.07 07:00 by 전규현


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







많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다.


복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다.


기초적인 것이 해결이 안된 상태에서 너무 어려운 것을 적용할 수 없다.


기초적인 것들이 여러가지가 있지만 회사의 이슈들을 한군데로 모으는 것만도 정말 어렵다.


이슈(버그)관리시스템을 사용하는 회사는 많지만 이슈관리시스템에 회사의 모든 이슈를 다 모아서 개발자는 오로지 이슈관리시스템만 보고 개발을 할 수 있는 회사는 드물다.


이슈관리시스템을 통하지 않고 전화, Email, 메신저를 통해서 여전히 개발 요청을 하는 경우가 많다.


어려운 시도를 하기보다는 먼저 이슈관리시스템에 모든 이슈를 모으는 일을 먼저 해보기를 권한다. 이것만 해도 회사에 제대로 정착되는데 1년이 넘게 걸리곤 한다. 그것도 잘 되었을 경우이다.


 버그, 개발요청, 업무요청, 협업관련정보 등 개발 이슈는 무조건 다 모아야 하고, 그외에 업무 이슈들도 모으면 좋다.


개발자는 하나의 시스템에서 모든 개발 요청을 다 볼 수 있고 관리할 수 있어야 한다.


전화, Email을 통한 요청을 일부라도 허용하는 예외를 둬서는 안된다. 예외는 전체 문화를 망가뜨릴 것이다.


시스템은 많아질수록 개발자가 귀찮아지고 비효율적으로 변한다.


경영자가 관리가 잘 안된다고 생각하고 자꾸 관리하는 시스템을 늘리면 관리가 잘되는 것이 아니고 빠져나갈 구멍만 늘어간다. 중심이 되는 이슈관리시스템 하나라도 제대로 사용하는 것이 중요하다. 


개발에 투입할 절대 시간은 정해져 있으니 최대한 개발에 집중할 수 있도록 시스템은 간소화 하고 집중화 해야 한다. 시스템이 많아지면 시스템 때문에 개발 시간을 빼앗기게 된다. 


하지만 이슈관리시스템으로 모을 수 없는 것들이 있다. 원래 전문 시스템이 있는 고객요요청, 재고관리, 인사, 재무, QA관련, 프로젝트 관리, 비용처리등은 ServiceDesk, ERP, HR, MIS, QMS, PMS 등의 시스템을 사용해야 한다. 일부는 이슈관리시스템과 연동할 수 있지만 대체는 안된다. 


작은 회사에서 전문 시스템이 없을 경우 이슈관리시스템으로 대충 관리를 할 수 있지만 이는 임시이다. 나중에 회사가 커지면 전문 시스템을 도입해야 한다.


이슈관리시스템 하나만 보더라도 회사의 역량이 얼마나 되는지 대충 알 수 있다. 어디 끝내주는 방법이 없을까 고민하지 말고 이슈관리시스템 하나라도 제대로 쓸 수 있도록 하자.


image by onepointzero

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

전규현 기반시스템/버그관리

이슈관리시스템을 쓰면서 일이 더 많아졌다.

2011.07.20 00:22 by 전규현


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





이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다.

이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서  일이 더 많아졌다고 하곤 한다.

이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다.

일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적으로 처리가 된다. 물론 많은 이슈는 처리하지 않고 해결하는 것으로 종료된다.

이슈가 빠짐없이 처리되는 것은 물론 이슈를 처리하는 과정은 완전히 투명하게 공개가 된다.

억지주장을 해도 모두 알게 되고 요청을 무시하거나 늦장을 부려도 누구나 알 수 있다. 완전히 투명하게 업무가 진행된다. 투명한 업무처리를 싫어하는 사람들은 이를 꺼려할 수는 있지만 전사적으로는 대단히 큰 강점이 된다. 

따라서 이슈관리시스템에는 버그 뿐만 아니라 업무요청, 자료요청, 새로운 아이디어 등 온갖 이슈는 모두 등록하는 것이 좋다. 또한 이슈관리시스템을 사용하면서 전화로 구두로 요청하는 것은 거의 없애야 하면 이슈를 공유하고 논의하는 회의의 대부분은 사라져야 한다. 회의에 불려가는 시간도 줄어야 하며 전화나 구두로 요청하는 인터럽트도 많이 줄어야 한다. 이렇게 세이브된 시간은 쉬거나 좀더 창의적인 일을 하는데 쏟는 것이 좋겠다.

이슈관리시스템은 전사적으로 제대로 쓰는 것만으로도 회사의 개발문화에 많은 변화를 가져온다.

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
 joomlatools
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/버그관리 개발문화, 이슈관리

  1. 이제 블로그 댓글에서 점점 Facebook 댓글로 옮겨 가고 있군요. ^^
    좋은 현상일까요?

  2. 아무래도 눈에 당장 들어오는게 페이스북 댓글이니까 더 손이 많이 가지 않을까요? ㅎㅎ 이름/비밀번호/홈페이지 이런거 일일이 입력하지 않아도 되구요. :)

  3. 페북계정은 있지만 웬지 정감이 안더라구요 ^^;

    음.. 일단 공론화 되는게 유쾌하지 않은 사람들이 많다는게 문제지만
    보이지 않는다고 다루지 않아도 될 문제는 아니니 바쁨을 즐겨야 할것 같아요 ㅎ

  4. 구차니님 안녕하세요.
    전 페북은 지인들과 소식 전하는 개인 용도로만 쓰고 있습니다. ^^

  5. 일반 블로그 댓글의 가장 큰 문제점은, 자기가 댓글을 단 글에 댓댓글이 달린 것을 알 수 없다는 점입니다.
    페북댓글을 사용하게 된 가장 큰 이유는 이 문제 때문 아닐까요?

  6. 안녕하세요. 이린님
    댓글알리미에서 제가 다른 블로그에 댓글 단것에 또 댓글이 달리면 알려주더군요. 그게 그 기능이 아닌가요? 되는 블로그가 있고 안되는 블로그도 있을 수 있겠군요.

  7. 이슈가 공유되서 일이 많아졌다는 것에 전적으로 공감합니다.

    이슈 관리 시스템을 쓰다보니 확실히 일이 좀 늘긴 했는데요,
    가만히 생각해보면 그간 잊혀지고 사라졌던 이슈들이 그대로 남아있기 때문이더군요.

    좋은 글 항상 잘 보고 있습니다. ^^

  8. 안녕하세요. kkamagui님
    항상 글을 읽어주셔서 감사합니다.

  9. 좋은 글입니다. 일이 많아진 게 아니라 드러나지 않던 게 드러나는 거란 통찰이 멋진 것 같습니다.

  10. 안녕하세요. 녹풍님
    반갑습니다. 이슈관리시스템 잘 쓰고 계시나보죠?

버그관리시스템 사용 현황 조사 결과

2009.04.12 20:23 by 전규현


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



그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다.
소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다.
물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다.

질문은 다음과 같습니다.

 버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요.

복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다.
그럼 그 투표결과를 분석해보도록 하겠습니다.

 버그관리시스템 사용 vs. 미사용 비율

보시다시피 버그관리시스템은 68%만이 사용하고 있었고 32%의 사용자는 버그관리시스템을 사용하고 있지 않습니다.  버그관리시스템을 사용하지 않은 그룹은 버그관리를 하지 않거나, 엑셀파일 또는 워드파일로 관리를 하거나 전문 버그관리시스템이 아닌 게시판 등을 사용하고 있었습니다.

소스코드관리시스템 미사용율은 25%였는데, 이보다 더 높은 수치를 기록하고 있습니다.

버그관리시스템을 사용하는 것만으로도 소프트웨어 개발 생산성 및 효율성은 상당히 향상됩니다. 그리고 소프트웨어의 규모나 복잡성이 증가할 수록 시스템 없이 파일 등으로 관리하는 것은 점점 불가능해집니다. 물론 소프트웨어가 아무리 작아도 엑셀파일로 관리하는 것보다는 버그관리시스템이 훨씬 낫죠.
버그관리시스템도 소스코드관리시스템과 마찬가지로 단순히 설치해서 사용하기만 하는 것은 아주 기초적인 혜택만 누리는 것입니다. 버그관리시스템의 혜택을 제대로 누리기 위해서는 개발 프로세스도 필요하며 오랜 훈련과 경험이 필요합니다.

 전체 투표 결과


전체 투표결과는 위와 같습니다. 엑셀로 버그관리를 하는 비율(18%)와 자체 제작한 버그관리시스템 사용 비율이 매우 높다는 것에 놀리자 않을 수 없었습니다. 특히 자체 제작한 버그관리시스템은 실패하는 것이 일반적입니다. 버그관리를 간단하고 쉽게 생각하고 자신의 회사에 딱 맞는 버그관리시스템을 만들 수 있다고 착각하지만, 실제 만들어서 사용하다보면 문제점이 많습니다.

우선 자신의 회사에 딱 맞는 시스템이라는 것이 기존의 회사에서 개발하는 방식에 문제가 있는 경우가 대부분이기 때문에 이에 딱 맞추면 회사의 개발 프로세스는 나아지는 것이 없습니다. 오히려 제대로 된 툴에 회사의 프로세스를 변화시켜서 맞춰나가는 것이 성공할 가능성이 더 높습니다. 또 버그관리시스템에 대한 전문적인 지식 없이 표면적인 기능만 구현을 하게 되면 계속되는 기능 추가 및 유지보수 이슈로 본업인 제품개발에 지장을 초래할 수도 있습니다. 이러다가 결국 포기하고 제대로된 툴을 사용하다보면 그동안 나쁜 버릇들이 몸에 베어서 정상적인 경우면 1,2개월이면 적응할 것을 적응 기간이 몇배 더 들고 또 실패할 수도 있습니다. 운동도 처음에 나쁜 자세가 몸에 익어버리면 제대로 배우는데 처음부터 배우는 것보다 몇배 더 오래 걸리는 것과 같은 원리입니다.

따라서 버그관리시스템은 처음부터 기존에 나와았는 상용이나 무료 툴들을 사용하는 것이 올바른 방법입니다. 서투른 다른 시도는 안하니만 훨씬 못합니다.

버그를 관리하지 않는 비율이 7%나 되는데, 음.. 버그가 하나도 없다는 얘기일까요? 신기하군요. 회사가 작다면 작은 PC에다가 Matis등의 무료 버그관리시스템을 설치해서 써보는 것도 좋은 방법입니다. 제대로 쓰기만 하면 개발 패러다임이 바뀔 것 입니니다.

 버그관리시스템의 사용 비율


버그관리시스템을 사용하고 있는 집단에서의 시스템 사용비율을 따로 뽑아봤습니다.
그 결과 Mantis가 32%를 기록했습니다. 즉 버그관리시스템을 사용하고 있다면 3명중 1명은 Matis를 사용하고 있다는 것입니다.
그리고 Trac, JIRA, Bugzilla등의 순서인데, IBM CQ나 Teamwork를 쓰고 있는 회사도 소수 있었습니다.
Matis는 설치가 쉽고 사용이 쉽고 직관적이라서 많은 개발자들이 선호하는 것으로 보입니다. 또 무료라는 것도 무시할 수 없는 매력이겠지요.

 결론

버그관리시스템의 사용비율은 예상외로 낮았습니다. - 68%
또, 자체적으로 만들어서 사용한다는 비율도 꽤 높았습니다. - 10%

이를 미루어 볼 때 버그관리에 대한 의식이 매우 낮고, 버그관리를 만만하게 보는 경향을 엿볼 수 있었습니다.
소스코드관리시스템을 만들어서 사용한다는 개발자들은 별로 보기가 힘듭니다. 일단 어려워보이거든요.
하지만 버그관리시스템을 팔기위해서가 아니고 자신들이 사용하기 위해서 만든다고 하는 개발자들을 쉽게 볼 수 있는 이유는 버그관리시스템이 만들기 쉽다고 생각하는 것 같습니다. 

DB 좀 핸들링 할 줄 알고 Web 프로그래밍을 할 수 있으면  버그관리시스템을 만들 수 있다고 생각합니다. 버그관리시스템은 그렇게 간단한 것이 아닙니다. 크고 작은 소프트웨어 회사의 전체 개발프로세스를 완전히 이해하지 않으면 이를 개발할 수는 없습니다. 현재 유명한 Mantis 등의 버그관리시스템들도 모두 수십년에 걸쳐서 축적된 버그관리 철학이 녹아 있는 것입니다.

따라서, 이러한 버그관리시스템에 잘 적응해여 사용하는 것만으로도 수십년간 축적된 개발 프로세스와 문화를 흡수할 수 있는 좋은 기회입니다.

버그관리가 별거 아니라고 생각하는 서투른 착각으로 이런 좋은 기회를 차버리는 과오를 범하면 안되겠습니다.

버그관리시스템을 도입하거나 사용하시면서 의논할 사항이 있으면 언제든지 연락을 주세요. 도움을 드리도록 하겠습니다. 감사합니다.



* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/버그관리 Bugzilla, ClearQuest, Jira, Mantis, Teamwork, trac, 버그관리, 소프트웨어, 엑셀, 이슈관리, 이슈처적, 투표

  1. 맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
    저희회사도 이제막 도입을 검토중이거든요..
    프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
    늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
    그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^

  2. 어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.

효과적인 버그 처리 방법

2008.12.09 13:31 by 전규현


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



HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다.
의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다.

개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다.
주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다.

여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠.

개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기술을 잘 아는 관리자가 있기도 하고 기술을 잘 모르는 관리자가 있기도 합니다. 하루에 버그가 하나도 보고되지 않을 수도 있고, 하루에 수백개의 버그가 보고되는 경우도 있습니다.

이러한 모든 경우에도 버그는 가장 적절한 개발자에게 신속히 할당이 되어서 신속히 해결을 해야 합니다. 해결이라함은 꼭 버그를 Fix하는 것을 의미하는 것이 아니고 연기할 수도 있고, 수정하지 않기로 할 수도 있고, 버그가 아닌 경우도 있죠. 어쨌든 이런 요구를 항상 만족시키기란 쉽지 않죠.

그래서 사람들이 찾아낸 방법이 "자율"입니다. 완전한 자율은 아니고 "Process"와 적당히 혼합된 "자율"입니다. 소프트웨어 개발에 있어서 "자율"은 매우 자주 등장하니 그리 놀랄 일도 아닙니다.

버그할당의 의무와 역할을 관리자에게만 두는 것이 아니고, 개발자도 그 역할을 조금씩 나눠 갖는 겁니다.
버그가 보고되면 관리자나 관련 개발자나 누구나 먼저 인지를 한 사람이 버그를 할당하는 겁니다. 여기서 버그를 할당했다고 해서 당장 버그를 고친다는 의미는 아닙니다.(이는 버그 관리 정책에 따라서 다릅니다.)

모든 개발자가 모든 버그를 다 감시할 수는 없겠죠. 버그의 카테고리는 기능별, 모듈별로 모두 등록을 해 놓아서 카테고리와 담당개발자의 연관성을 높이고 개발자들은 자신과 주로 관련된 카테고리들만 감시를 해도 충분합니다. RSS Feed를 지원하는 Bug Tracking System이 있으면 이렇게 감시를 하기 편리합니다. 그리고 나면 버그 해결 스케쥴은 시스템을 이용하여 정할 수도 있고, 회의를 하기도 합니다.
버그할당의 최종 책임은 관리자에게 있으므로 이렇게도 할당이 안된 버그는 관리자가 처리를 해야죠.

이러한 방법은 대부분의 경우에 상당히 효율적입니다만, 자율에 의한다는 것은 각 구성원의 성숙도에 많은 영향을 받으므로 이를 감안해서 시행해야 할 것입니다. 

버그의 처리에는 시간이 걸릴 수 있어도 버그의 인지는 신속해야 하고, 버그의 할당도 빠르게 이루어져야 합니다. 버그인지 자체가 일주일 이상 걸리는 상황이라면 그 기간 동안 버그는 완전히 방치가 되고 있는 상황이라고 할 수 있습니다. 그래서 회사에 따라서는 버그 인치와 처리 시간을 줄이기 위해서 KPI에 이 수치를 포함해서 평가의 지표로 삼곤 하는데, 별로 바람직한 시도는 아닙니다. 어차피 자율에 의한 방법이기 때문에 좀더 성숙한 개발 문화와 이를 북돋울 약간의 당근만이 필요할 뿐입니다.

이미지출처 : Microsoft Office Online

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

전규현 기반시스템/버그관리 버그관리, 버그추적, 소프트웨어, 소프트웨어 개발

  1. 자율에 의해 버그가 잘 처리 되고 개발자가 자기 모듈에서 버그가 발생된다면 해당 개발자가 맡아 주는 것이 좋겠죠? 그러나 버그 리포트만 보고 어느 모듈에서 버그가 있는지 알기 어려울때가 있고 또 이전 모듈을 담당한 개발자가 더이상 일하지 않을수도 있고, 우리의 관리자가 개발자의 이름을 다 기억 못할수도 있고 등등등. 이럴때 이전 버그 할당한 히스코리나 버그의 증상을 바탕으로 버그 트래킹 시스템이 자동으로 이 버그를 픽스할만한 후보를 3명 정도 찝어 준다면 어떨까요? 물론 이 3명을 정확하게 찝어줘야 겠지만.

  2. HannaKim님 안녕하세요.
    자동으로 후보를 찍어주는 시스템이 효과를 발휘하면 대형 프로젝트에서는 정말 멋진 시스템이 될 것 같은데요. 혹시 그런 시스템을 만드신다면 기대하고 싶네요. :)

  3. 테스트팀이 개발 설계때 부터 투입되고 개발과 테스트관련 작업?이 같이 진행되면 Bug를 발견한 테스터가 직접 개발자를 Assign해도 좋다고 생각합니다. 물론 그 만큼 개발과 테스트가 유기적으로 진행되고 있어야하겠지요. 개발자와 1:1로 개발, 테스트를 진행했었는데 이게 가장 효율적이었습니다.
    즉, 현재 조직 상황과 프로세스에 따라 다르게 적용되어야 한다고 생각합니다. 프로세스 성숙도와 규모에 따라 적용하는 것이 달라지겠지요.
    Clear Quest를 사용하면서 큰 틀은 함께하면서 팀마다 다른 스키마를 적용했었습니다.

  4. 정의의소님 안녕하세요.
    각 개발자가 컴포넌트를 완전히 구분해서 개발을 하신 경우겠네요.
    테스트팀은 말씀하신 대로 개발 초기부터 투입이 되어야 합니다. V-Model만 보더라도 테스트팀이 요구사항단계부터 투입이 됩니다.
    소프트웨어 개발은 원리를 이해하는 것이 정말 중요하다고 생각합니다.

  5. 관리자 및 개발자의 성숙한 소프트웨어 개발 프로세스 문화 뿐 아니라 QA팀에서의 Report도 많은 비중을 차지할 것 같습니다.
    일단 버그의 담당자를 지정하기 위한 자료는 Issue Report 가 전부이기 때문이죠.
    그리고 Stracking System을 Product별로 커스터마이징 해서 킥 오프 단계에서 각 개발 컴포넌트와 그 담당자를 매칭해 주고 자동 Assign 하면서 이 관계를 지속적으로 업데이트하는 방법도 효율적일 것 같습니다.
    (가능한 Tracking System 및 양질의 Issue Report, 모든 부서의 원활한 커뮤니케이션이 선행되어야 하는... 어려운(...?!?!?!) 점이 있겠지만요.)

  6. Noel님 안녕하세요.
    상당히 Detail하게 적어주셨네요. 말씀하신 모든 부분이 이슈 할당 및 처리에 도움을 주는 방법들이죠.
    버그 리포트 주체를 QA팀이 아닌 "누구나"로 확장하면 또 고려해야 할 것들이 있겠죠.
    워낙 다양한 경우가 있어서 원리만 잘 이해하고 있으면 응용력이 생기죠.
    이런 좋은 경험들이 다양한 경우에 응용력을 키워 줍니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바