태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

빈 줄도 지워서는 안된다.

2015.04.13 14:25 by 전규현


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






SVN 쓸까? Git 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 중요한 것은 SVN이나 Git 상관없이 어떻게 하면 여러 개발자들과 협업이 되도록 코딩을 하느냐다.


많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.


혼자서 개발을 하더라도 수많은 브랜치가 발생할 있고 한두 명끼리는 그럭저럭 개발을 하더라도 개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.


그럼 어떻게 코딩을 하는 것이 좋을까?


첫째, 줄도 고쳐서는 된다.


내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서 고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 


뿐만 아니다. Indentation 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.


둘째, 파일 이름을 바꾸지 말아야 한다.


처음에 대충 파일을 만들다 보면 파일이름이 마음에 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을 피할 길을 없다. 처음에 정해야 한다. 


셋째, 함수 이름과 정의를 바꾸지 않아야 한다.


대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는 것은 비용이 많이 든다. 아주 작은 시스템만 경험해 개발자는 이런 방법이 빠르다고 주장할지 몰라도 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.


넷째, 소스코드를 재배치하지 말아야 한다.


파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge 어려워진다. 처음에 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.


이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.


외에도 변수를 어떻게 선언하느냐는  협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은 혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.





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

전규현 기반시스템/소스코드관리 GIT, merge, svn

  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    저는 조금 반대입니다.

    저는 조금 반대인게 변경해야 하는 내용이 규격화된 내용과 맞지 않는 형식이라면 고치는게 맞다고 생각합니다.
    머지를 하는게 처음엔 힘들수 있지만 일정한 표준화가 되고 난 다음부터는 그렇게 힘들지 않습니다.
    일단 제 경험상으론 그렇네요.

  3. Blog Icon
    나그네

    이럴때 필요한게 리팩토링 이지요...

    프로젝트 중간 팀원들과 리팩토링을 하여 정보를 공유하는게 좋을듯합니다..

    빈줄도 지워서는 안된다는 좀 심한듯..

Hotfix에서의 소스코드관리

2010.05.04 11:26 by 전규현


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





아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.









우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.
계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.
Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.
Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 
Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

 Hotfix  정식 Patch
계획되지 않은 긴급한 패치
보통 충분히 테스트 되지 않고 릴리즈
또다른 문제를 일으킬 가능성이 매우 높음
다른 개발일정에 영향을 줌
고객은 수정된 버전을 바로 받아볼 수 있음
미리 계획됨
계획된 테스트를 수행하고 릴리즈
일상적인 수준의 리스크를 가지고 있음
계획된 일정대로 개발이 가능
고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

 Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.
1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?
2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 
1. 그때 그때 다르다.
2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.
Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.
그럼 개발팀 바깥이란 무엇일까요? 
테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.
이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.
Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.
  1. 상세한 버그 내용
  2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
  3. 버그로 인해서 발생하는 고객의 예상 피해
  4. 버그를 얼마나 빨리 해결해야 하는지
  5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
  6. 버그 수정에 투입해야 하는 인력 및 자원
  7. 기존 개발일정에 미치는 영향
여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 
Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.
그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.



Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

 마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.
지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Paul L McCord Jr

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

전규현 기반시스템/소스코드관리 3WayMerge, Branch, build, Firefighter, FireFighting, hotfix, IDE, merge, Patch, release, TAG

  1. 좋은 글 잘 봤습니다. 가급적 정식패치를 가져가고 싶지만 고객은 당장해결해달라고 하는경우가 많네요 ㅠㅠ 버그의 수준이 심각한게 아니더라도 말이죠. 일단 Hotfix가 많이 나오지 않도록 코드품질에 신경써야겠고 영업측에도 Hotfix의 위험성에 대해서 설득해야 겠습니다. ^^

  2. 안녕하세요. 차우차우님
    말씀하신 현상은 우리나라 소프트웨어 회사에서 너무나 흔히 볼 수 있는 현상입니다.
    또한 우리나라 소프트웨어 회사들이 성장하지 못하는 가장 중요한 요소중 하나입니다.
    개발자들이 적당히 설득해서 영업이 바뀌었으면 벌써 잘 되었겠죠. 영업을 설득하는 것은 그렇게 쉽지 않습니다.
    특히, 경영자가 Sales oriented되어 있으면 더욱 힘듭니다. 개발자들도 심정적으로는 그렇게 하면 안되는 것을 알지만 좀더 전문적으로 강력하게 설득할 힘이 부족한 것이 현실입니다.
    그래서 저같은 전문가가 회사에 가서 경영자와 영업도 교육을 시키고, 시스템, 프로세스, 문화를 바꿔주는 것이지요. ^^
    해보다가 난관에 부닥히면 도움을 요청하세요. 감사합니다.

  3. 잘 읽었습니다. 볼 때마다 소스코드 관리 안하고 그냥 개발해서 뜨끔뜨끔합니다 ㅎㅎㅎ;;

  4. 안녕하세요. 루돌님 반갑습니다.
    엄청 오래된 블로그를 가지고 계시네요. 대단하십니다. ^^
    종종 들려서 좋은 정보를 나눠요.

  5. 그래도 cvs에 비해서 svn은 viewvc 등에서 tag를 보기가 힘든 단점이 있는거 같더라구요.
    아무튼 태그와 브랜치간에 오고가는거에 대한 문서는 보기 힘들던데
    그 부분에 대해서(실제 cvs, svn 명령어를 통해) 자세한 설명을 부탁드립니다.

  6. 안녕하세요. 구차니님
    viewvc같은 이슈는 전체 소스코드관리 이슈에서 너무나 미미한 이슈입니다. 지엽적인 이슈에 크게 좌지우지 되지 않는 것이 좋겠습니다.
    사실 시중의 모든 소스코드관리를 다루는 책에서 브랜치, 태그, 머지 등에 대해서 설명이 되어 있지만, 책을 보고 한번에 익히는 것은 대단히 어렵습니다.
    그래서 실무를 통해서 배우는 것이 가장 좋은데 제대로 하고 있는 선배들이 별로 없으니 이또한 어렵기는 마찬가지 입니다.
    그렇다고 블로그의 글을 통해서 모든 것을 전달하기도 어렵습니다. 어쨋든 나름대로 앞으로도 글을 계속 써보기는 할텐데, 글들을 보고 깨우치는 사람도 있을 것이고 그렇지 못한 사람도 있을 겁니다.
    제 Office에 한번 오시면 제가 직접 설명을 해드리면 더 빠를텐데요. ^^

    아무튼 앞으로도 계속 관심을 기울이고 실무에 적용을 해보면서 궁금한 것이 있으면 또 물어보고 이렇게 반복을 하다보면 어느새 다 깨우치게 될 겁니다.

    질문 중에서 "태그와 브랜치간의 오가는 것"이란 무엇을 말하는 것인가요? 질문이 매우 모호해서 구체적인 답변을 드리기가 어렵네요.

    댓글이나 Email을 통해서 자세히 설명을 해주시면 제가 답변을 드리도록 하겠습니다

    감사합니다.

혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

2010.05.03 14:00 by 전규현


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





소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다.

Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다.

또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자들끼리 담당 소스코드를 철저히 나눠서 서로 충돌이 나는 일이 없도록 개발을 하는 경우가 허다합니다. 이런 것을 Component Owner라고 하고 이런 체제에서는 개발자들 간의 기술의 공유가 어려워지고 회사의 규모가 커질수록 개발 효율성은 점점 떨어지게 됩니다.

그럼, 어떤 상황에서 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황이 발생하는지 알아보도록 하겠습니다.

첫째, Hotfix인 경우입니다.
소프트웨어의 종류는 워낙 다양하기 때문에 획일적으로 말할 수 없습니다. 그래서 간단한 예를 하나 들어보죠. 매일 한번씩 패치를 만들어서 정해진 시간에 인터넷으로 업데이트를 하는 소프트웨어를 개발하고 있다고 칩십니다. 오늘 오후 5시에 내보낼 패치에 들어갈 Bug fix와 Feature를 열심히 넣고 있는데 긴급 Hotfix 상황이 발생한 겁니다. 따라서 정식 패치때까지 기다릴 수는 없고 일단 시급한 버그 하나만 고쳐서 서둘러서 업데이트를 해줘야 합니다. 이러한 상황에서 소스코드관리시스템을 사용하는 능숙도에 따라서 대처하는 방법들이 매우 다릅니다.

 하수

소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

 중수

이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

 고수

Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다. 
우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다. 
3Way Merge를 적용하려면 3개의 기준점이 필요합니다. 3개의 기준점은 다음과 같습니다.

Base - 어제 릴리즈한 Baseline(Tag)
Their - 오늘 Hotfix 릴리즈한 Baseline(Tag)
Mine - Trunk의 Head revision(최신소스)

3Way Merge를 통하면 거의 99% 자동으로 Merge가 되고 Conflict가 나는 소스코드들도 KDiff3나 P4Merge등의 GUI가 뛰어난 3Way Merge툴을 이용하여 쉽게 Merge를 할 수 있습니다.

그리고 현재 로컬에서 고치고 있던 소스코드와 통합을 해야 합니다. 이를 Rebase라고 하는데 SVN에서는 Update명령을 내리면 서버에서 바뀐 내용이 자동으로 Working copy와 통합이 됩니다. 이때도 3Way Merge를 이용하게 됩니다.

즉, 개발자는 소스코드 내용 고치는데만 신경을 쓰면 되고 나머지는 소스코드관리시스템이 다 알아서 해 줍니다. 소스코드 통합하는데 불과 얼마 걸리지 않고 혼동도 없습니다. 시간은 하수,중수의 수십분의 1이면 가능하게 됩니다.

혼자 개발하더라도 제대로 하지 않으면 이렇게 혼동이 있고 소스코드관리시스템의 기능을 잘 사용만하며 이렇게 손 쉬운데 개발자가 수십명, 수백명이서 하수, 중수의 방법으로 어떻게 소프트웨어를 제대로 개발할 수 있을까요?

물론 이것이 다는 아니죠. 기능을 충분히 사용하는 것은 이제 시작입니다. 더 큰 조직에서 조직적으로 제대로 사용하려면 프로세스, 규칙, 문화 등과 접목되어서 돌아가야 하는데, 이는 더 어렵습니다. 그러데 하물며 기능도 제대로 사용을 못하는 회사가 대부분인데 그 다음은 말할 필요하고 없죠.

Hotfix 경우 외에도 기존 소스코드에 큰 변경을 가해서 성공 여부를 확신할 수 없는 기능을 추가할때.
시간이 오래 걸리는 기능을 추가하면서 중간 중간에 다른 변경에 대한 릴리즈를 해야 할 때.
등 혼자서 개발을 하더라도 Branch/Merge를 해야 할 경우는 수도 없이 나오게 됩니다.

소스코드관리를 너무 쉽게 생각하면 안됩니다. 잘해 놓으면 무척 쉽고 개발에 매우 큰 도움을 주지만, 대충대충 하다보면 큰 발목을 잡히게 됩니다. 혼자 개발하더라도 제대로 하겠다는 마음가짐을 가지고 완벽하게 전체 기능을 다 알아야 합니다. 그리고 나면 이좋은 것을 왜 지금까지는 제대로 하지 않았을까 아쉬움이 들겁니다.

책을 보고 해보는 방법도 있지만 시간이 좀 많이 걸리겠지요. 주변에서 잘아는 사람에게 물어보는 것은 시간을 절약할 수 있는 좋은 방법입니다. 주변에 그런 사람이 없다면 블로그에 궁금한 것을 올려주세요. 제가 힘이 닿는한 잘 설명드리겠습니다. 제가 쓴 책(소프트웨어개발의 모든 것)에서는 이러한 부분이 이론적이 아닌 실제 방법을 자세히 설명하고 있으니 보시는 것도 도움이 많이 될 것입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Carly & Art


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

전규현 기반시스템/소스코드관리 Branch, merge, SCM, 소스코드관리시스템

  1. 확실히 태그는 몰라도 브랜치는 사용법을 잘 모르겠더라구요. ㅠ.ㅠ
    나중에 브랜치 사용법 cvs/svn 에서 강좌가능하실까요? ^^;

  2. 안녕하세요. 구차니님
    브랜치/머지를 교과서적으로 뭔지 아는 것은 10분이면 됩니다. 하지만 제대로 쓰려고 이해를 하려면 시간이 많이 걸립니다. 그리고 수많은 케이스에서 적절하게 쓰는 방법을 모두 익히려면 1,2년 써보면서 알게 됩니다. 대부분은 시행착오로 배우는데, 시행착오 없이 배우면 더욱 좋지요. 제가 쓴 책에 자세히 적혀 있으니 참고하시고요. 필요한 부분은 구체적으로 물어봐주시면 설명 드리겠습니다. ^^
    강좌에 대해서는 한번 생각해 봐야겠네요. 작년에 Bit와 연계를 해서 교육을 실시한 적도 있기는 합니다. 그리고 몇몇 고객은 소스코드관리에 대해서만 세미나 식으로 교육을 실시한 적도 있죠.
    필요한신 것이 있으면 요청해주세요. 감사합니다.

  3. 좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.

  4. 안녕하세요. 차우차우님
    Hotfix에 대한 용어 정의는 회사마다 조금씩 다르겠지만, 일반적으로 Hotfix는 계획되지 않은 긴급패치를 말하므로 Hotfix가 많아진다는 것 자체가 문제가 될 수 있습니다. 이는 항상 호떡집에 불난 모양으로 FireFighting mode가 될 수 있습니다. 이왕 Hotfix의 버전 관리에 대해서 문의를 하셨는데 설명해야 할 내용이 댓글로 달기는 너무 많으므로 블로그에 포스트를 하도록 하겠습니다.

  5. 답변감사합니다. ^^
    역시 Hotfix가 많아진다는것 자체가 문제가 있는 상황인거네요. 릴리즈할때 좀더 완벽하게 준비한다면 hotfix를 남발하지 않아도 될테구요.
    나중에 Hotfix의 버전관리에 대해서도 포스팅해주시면 많은 도움이 되겠습니다.

  6. Hotfix에서의 버전관리포스트 올렸습니다.
    http://allofsoftware.net/entry/HotfixVersionControl

  7. 으아~ 너무 좋은 글인데요.
    재밌게 잘 읽었습니다^^

  8. 안녕하세요. Benjamin님
    재미있는 글은 아닌데 재미있게 보셨나니 SW개발을 정말 좋아하시는 것 같군요. ^^

  9. 저도 개인 프로젝트 진행 때 브랜치나 머지가 과연 필요할까 했는데 바로 이거군요!!

    감사합니다^ㅡ^/

  10. 안녕하세요. Yarmini님
    들려주셔서 감사합니다.

  11. Blog Icon
    알콜알프

    금융에서만 일을 했는데... merge에 대한 불안감은 있네요.. 제가 있던 곳에서만 그런건지 궁금하네요. 금융 계정계 같이 크리티컬한 부분에서도 merge 기능을 사용하나요??

  12. 안녕하세요. 알콜알프님
    금융쪽이라면 생각할 것이 좀더 많습니다. 물론 금융이라고 해서 소프트웨어자체가 더 복잡하다고 볼 수는 없지만, DB, Middle ware와 인터페이스가 있고, 대외계, 원장 등 연동해야 할 것이 많습니다.
    그래서 Merge를 못하는 것이 아니고 개발할 때 Merge를 감안해서 미리 생각하고 구현을 하면 됩니다.
    그렇게 하면 일반 Application보다 더 용이하게 Merge가 가능합니다.
    흔히 Merge를 하면 모든 것이 끝나는 것으로 생각을 하지만, 소스코드가 잘 Merge가 되었는지 직접 Diff를 이용해서 확인하는 것이 좋고, Merge 후 테스트를 또 해보는 것은 당연합니다.
    특히 계정계같은 숫자 하나 까딱 잘못되면 큰일나는 심각한 곳에서는 더 철저히 검증을 해야죠.
    그래도 이렇게 Merge를 이용하는 것이 완전 수동으로 하는 것보다 시간도 훨씬 적게 걸리고, 오류 가능성도 더 적습니다.

  13. Blog Icon
    이재주니

    안녕하세요 저는 기계과 대학원 생입니다.
    소프트웨어 분야는 아니지만 Simulation이다 장비 테스트다 하면서 하루에
    프로그래밍에 보내는 시간은 컴공 친구들이랑 비교해도 뒤지지 않는다고 생각합니다.(착각인가?)

    다름이 아니라 저희 대학원생들은 모두 기계과나 전자과를 나와서 소프트웨어 개발에 대한 체계적인 틀이 잡혀있지 않습니다. 코드는 어떻게 관리하는지 Document는 어떻게 만들어야 하는지 등등이요.

    [소스코드가 없어졌다] 글에서 나왔던 것 처럼 한 학생이 열심히 프로그램을 짜놓고 외국으로 가버렸습니다. 물론 소스코드를 들고 튀지는 않았지만 코드에 대한 어떤 코멘트도 Document도 없이 가버려서 그 코드를 읽고 이해하는데만 한달 가까이 걸렸던 것 같습니다. 제대로된 관리가 안되니 소스코드가 사라져버리는 일도 있었지요.
    얼마전에는 대청소를 했었는데 왠 낡은 컴퓨터가 있길래 버렸는데 알고보니 굉장히 중요한 소스코드가 들어있었던 적이 있었습니다. 결국 그 코드는 찾을 수 없었습니다.

    계속 이런 일들이 일어나는 상황에서 교수님께서 한명이 맡아서 코드관리 시스템을 만들라고 하셨습니다.
    지금 이 답글을 쓰고 있는 제가 맡게 되었는데요. 처음에는 막막하고 답답했는데 SVN에 대해 읽어 볼 수록
    이런게 있다는 걸 조금만 더 빨리 알았더라면이라는 생각이 들더군요.

    지금은 연구실에 SVN서버를 설치하기 전에 임시적으로 개인 서버를 만들어서 테스트하고 있는데요,
    SVN에 기능이 너무 많아서 어떤 기능 부터 써봐야할지 감이 잡히질 않습니다.
    모든 기능들을 테스트 해보기에는 시간이 없고, 꼭 알아야하고 제가 연구실 팀원들에게 알려주어야 할 기능들이
    있다면 조언이 가능한지 여쭙고 싶습니다.

    어쩌다보니 자기소개처럼 되어버렸네요.
    좋은 글 감사드립니다. 조만간 책도 사서 읽어봐야겠네요.^^

  14. 시중에 SVN에 관련된 책이 많이 있으니 참고를 하시면 되겠습니다. 단순 명령어 사용법 보다 핵심 원리를 깨닫고 싶다면 "소프트웨어 개발의 모든 것"이라는 책을 보시기 바랍니다.

Diff and Merge in SCM(Software Configuration Management)

2008.11.21 01:03 by 전규현


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



에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다.

일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요.
사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다.
  • 대부분의 소스코드는 거의 영어로 되어 있고, 
  • 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고,
  • 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다.
  • 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 문제가 안되었습니다.
이것은 단지 한글 깨지는 것이 큰 이슈가 아니었다는 얘기입니다.
하지만 한글이 큰 이슈라면 AcroDiff나 WinMerge를 사용하시면 될 것 같습니다.
TortoiseSVN은 외부 Application을 등록하여 사용할 수 있도록 되어 있으니 한글(2byte)문자를 지원하는 AcroDiff나 WinMerge를 사용하세요. 
물론 Araxis Merge같은 상용제품을 사용하시면 금삼첨화지요.
Araxis Merge은 단순히 한글 지원 장점 외에도 3-way Merge를 지원하므로 제대로된 Merge Tool이라고 할 수 있습니다.
3-Way Merge를 지원하는 Merge Tool 중에서 무료로 사용할 수 있는 것은 KDiff3가 있습니다.
GPL 라이센스라서 무료이기는 하나 한글지원에서 약간 문제가 있습니다.
머지 기능 자체의 문제는 아니고 한글 부분이 약간 깨져서 보입니다만 Merge는 잘됩니다.
그래서 저는 KDiff3를 사용합니다.

얘기가 나온 김에 3-Way Merge가 무엇이며 왜 필요한지 "소프트웨어개발의 모든것"이라는 책의 내용을 잠시 소개하겠습니다.

 머지(Merge)

머지는 분기된 소스코드를 하나로 합치는 일이다. 머지를 능수능란하게사용할 수 있어야 소스코드관리시스템을 원활하게 사용할 수 있다.

머지는 크게 2-way 머지와3-way 머지로 나뉜다. 2-way 머지는 두 개의 파일을 가지고 서로 다른 부분을 비교하면서하나로 합치는 것이다. 이 방법은 100% 수동에 의존할수 밖에 없다. 서로 다른 부분 중 어느 것을 빼고 어느 것을 남겨야 하는지 어느 것이 옛날 내용이고어느 것이 새로 바뀐 것인지 직접 보고 판단해야 한다. 우리가 흔히 보는 머지툴의 대부분이 2-way 머지툴이다.

위 그림은 파일1과 파일2를합쳐서 파일3을 만들려는 것이다. 파일1과 파일2 는 원래는 하나의 파일이었으나 과거에 브랜치가 되어서 각각따로 수정된 것이다. 이 경우 어떻게 합쳐야 할 지 막막하다. B shark일지 monkey일지 판단하는 것이 쉽지 않다. F=mango는 새로 추가된 것인지 원래 있던 것이 반대 파일에서 삭제된 것인지 알기 어렵다. 따라서 소스코드를 잘 알고 있는 사람이 내용을 모두 보고 판단하는 수밖에 없는 것이다.

하지만 3-way 머지는 방법이 좀 다르다. 두 파일을 단순히 비교하는 것이 아니고 두 파일로 나누어지기 전의 파일도 같이 포함하여 비교하며 머지하는 것이다. 그렇게 되면 어떤 내용이 추가되거나 삭제되거나 변경되었는지를 알 수 있기 때문에 최종본으로 합치는 일이 훨씬수월하다. 파일의 충돌만 없다면 자동으로도 머지가 가능하다. 파일의충돌이 있을 경우에만 충돌된 부분을 사람이 판단하여 통합하면 되는 것이다.


여기서 새로 등장한 파일0은 파일1과파일2가 브랜치 되기 전의 원래 파일이다. 파일0, 파일1, 파일2를 각각비교하면, 파일1에서 monkey shark로 수정된 것을 알 수 있다. , 파일2에서 apple은삭제되고 mango가 추가된 것도 알 수 있다. 이 정도면사람이 별도로 판단할 필요 없이 자동으로 머지가 가능하다. 이러한3-way 머지툴에는 다음과 같은 것들이 있다.

  • Perforce Merge
    • Publisher: Perforce software
    • License: 무료
  • Araxis Merge
    • Publisher: Araxis ltd.
    • License: 유료
  • KDiff3
    • Publisher: KDevelop
    • License: GPL

이 중에서 KDiff3는 인터넷을 통해서 쉽게 구하여 사용할 수 있다.

3-way 머지를 이용하면 또 다른 기능을 이용할 수도 있는데, 부분 머지(Range Merge)가 바로 그것이다. 예를 들어 브랜치를 하여 수정한 여러 부분에서 특정 부분만 트렁크와 머지를 하고 싶을 때가 있다. 고객의 요구에 의해 브랜치를 했고, 해당 브랜치에는 고객의 특별요구 기능이 반영이 되어 있었다. 그런 다음 브랜치에서 발견한 버그를 수정했는데, 이를 트렁크에도 반영하고 싶을 때가 있다. 이 경우에 3-way 머지를 이용하면 다른 부분은 빼고 버그를 수정한 부분만 골라서 머지를 할 수 있다.


소스코드관리시스템과 3-way 머지툴을 효과적으로 사용하면 머지작업이아주 효율적으로 진행된다. 그러나 3-way 머지가 매우유용한 방법인 것은 사실이나 100% 자동에 의존할 수는 없다.3-way 머지툴이 충돌없이 머지에 성공했다 하더라도, 그 결과를 눈으로 직접 확인하는것이 더욱 안전할 것이다.

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

전규현 기반시스템/소스코드관리 diff, merge, SCM

  1. TortoiseSVN 1.5.5 버전에서는 깨지지 않고 잘 동작하는군요!
    여러 의견 주신 분들께 감사드립니다.
    Ray님, 브랜치 내용을 병합할때 3-way merge의 필요성을 아주 깔끔하게 정리해 주셨군요!
    참고로 AraxisMerge를 쓰고 있는데, 3-way merge는 프로페셔널 버전에서만 지원됩니다. 비싸요~
    TortoiseMerge는 공짜이면서 3-way merge를 지원하므로 이것만으로도 Subversion을 사용할 만한 가치가 있다고 생각됩니다. (게다가 1.5.5에서는 한글도 안 깨지구요 ^^)

  2. 안녕하세요. 헝그리맨님
    1.5.5가 10월말에 릴리즈 되었군요.
    저도 설치를 했습니다. 한글 문제는 해결이 되었네요.

    TortoiseSVN이 3-way merge를 지원하기는 하나 머지창에 3개의 소스파일을 모두 보여주지 않고 Base File을 안보여 줘서 조금 불편하더군요. 그리고 Merge결과도 다른 여타 3-way merge보다 손이 더 많이 갑니다.

    다음 버전쯤에서는 본격적인 3-way merge툴과 같이 업그레이드가 되지 않을까 기대합니다.

    Araxis Merge가 좋기는 하나 워낙 비싸서 무료인 KDiff3를 권하는데 한글 문제가 있죠. 아직 0.9.92버전이니까 나중에 1.0 버전이 나올 때에는 해결이 되겠죠.

  3. Diff/Merge 툴로 Araxis Merge 만큼 강력하면서도 좀 저렴한 Beyond Compare 라는 것도 있습니다. 더 저렴한 UltraEdit의 UltraCompare도 있구요.

  4. 김선동님 안녕하세요.
    애들이 이쁘네요. :)
    Beyond Compare가 version 3부터 3-way merge를 지원하나보네요. 가격도 저렴하고 좋네요. UltraCompare도 좋네요. 좋은 정보 주셔서 감사합니다.
    블로그가보니 ID에 AcroEdit가 있군요. AcroEdit개발자이신가 보네요. 반갑습니다.
    AcroDiff도 발전시켜서 Enterprise급의 Merge툴로 만들면 어떨까요? ^^
    소프트웨어 개발에 관련된 많은 애기 나누면 좋겠습니다.

  5. 링크타고 들어와서 좋은 블로그를 발견하고 바로 구독하고 있습니다. 전문가님들이 이렇게 나서주시니 저 같은 무지랭이 개발자에게는 많은 도움이 됩니다요. AcroDiff 는 걸음마 수준이라서 개선에 대해선 늘 생각만 하고 실행에 옮기지 못하네요..^^

  6. 김선동님 안녕하세요.
    무슨 겸손의 말씀을:)
    AcroEdit 항상 관심을 가지고 주시하고 있습니다.
    우리나라에서도 세계적인 제품이 나와야죠.
    소프트웨어 업계에 오래 있으면서 아쉬운 점은 우리나라 개발자들은 대부분 글로벌하게 경쟁할 생각을 별로 안한다는 겁니다. 실력은 좋은데, 대부분 국내에서 어떻게 해볼까 생각을 합니다.
    다음 주제로 소프트웨어 개발에 있어서 Global mind에 대해서 적어볼까 생각하고 있었는데, 이참에 정리해서 글을 올려봐야겠네요.
    어쨋든 AcroEdit는 하기에 따라서 얼마든지 글로벌 경쟁력있는 제품이 될 수 있다고 생각합니다. 이제는 Open된 세상이기 때문에, 박스 실고 가서 팔아야 하는 시대는 아니기 때문에 누구에게나 기회는 있다고 생각합니다.
    아자~ ;)

  7. 글로벌하게 하고 싶어도 영어가 문제죠...ㅎㅎ
    조금씩은 노력을 하겠지만 영어에 능숙하지 못하니 느릴수 밖에요...

  8. AcroEditor는 세계에 내놔도 기능적으로는 경쟁이 충분히 될 수 있다고 생각합니다.
    제품을 Global화 할려면
    Software를 국제화(i18n), 지역화(L10n)해야하는데, 대부분의 개발자들이 이에 대해서 주먹구구식이더라구요. 나와 우리회사에서는 소프트웨어의 국제화에 전문적인 지식과 다양한 경험을 가지고 있습니다. 저의 Boss는 미국 선마이크로시스템즈의 제품 국제화 표준과 솔루션, 프로세스를 만드신 분입니다. 현재 전세계 대부분의 회사와 제품에서 그 표준을 따르고 있죠.
    그리고 Maketing이겠죠.
    제품의 국제화에 대해서 궁금하신 내용이 있으면 언제든지 연락주세요.
    감사합니다.

  9. 3-Way Merge는 오늘 처음 알았습니다.+____+! 좋은 내용 정말 감사합니다~
    즐겁게 점심먹으러 갈수 있겠네요~ ^^

  10. sozu님 안녕하세요.
    3-way merge 컨셉을 완벽하게 이해하기란 쉽지 않습니다. 제가 쓴 책(소프트웨어 개발의 모든 것)을 보시면 좀더 많이 이해되리라 생각합니다.

  11. 와웅~ 감사합니다.^^ 저 책보는거 완전 좋아합니다.ㅋㅋ
    꼭 사서 보겠습니다~~

  12. Blog Icon
    함수

    그런데 Merge 후 충돌 났을 때 충돌된 라인의 구분과 충돌 해결 후 SVN에 어떻게 적용하나요?
    지금까지 SVN에 있는 기본 머지툴을 사용하다가 위 설명한 툴을 써보니 다 좋은데 그걸 모르겠다는;

  13. 안녕하세요. 함수님
    직접 보면서 설명하면 간단한데 글로 설명하기는 어렵군요.
    우선 3Way Merge툴을 사용하셔야 합니다.
    각 툴은 SVN과 연결하는 방법이 안내가 되어 있습니다.
    TortoiseSVN의 External Merge툴에 등록을 하는 겁니다.
    그리면 SVN이 자동 Merge를 하다가 충돌이 나면 등록된 Merge툴이 실행됩니다. 3way merge툴의 기능을 이용해서 충돌을 해결하고 저장을 합니다.
    그리고 TortoiseSVN의 Update화면에서 "resolved" 체크를 한번 해줘야 합니다. 이부분이 가장 중요합니다.
    그러면 merge를 위해 생성되었던 임시 파일들이 모두 사라져서 Commit할 수 있는 상태가 됩니다.
    그리고나서 Commit을 하면 됩니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바