본문 바로가기

기반시스템

누가 소스코드를 몰래 바꿔놨다. 누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다. 실제로 이러한 걱정을 하는 회사도 많이 있습니다. 영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다. 정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회 사들에서는 언제든지 일어날 수 있는 일입니다. 정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 .. 더보기
버그관리시스템 사용 현황 조사 결과 그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다. 소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다. 물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다. 질문은 다음과 같습니다. 버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요. 복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다. 그럼 그 투표결과를 분석해보도록 하겠습니다. 버그관리시스템 사용 vs. 미사용 비율 보시다시피 버그관리시스템은 68%만이 사용하고 있었고 32%의 사용자는 버그관리시스템을 사용하고 있지 않습니다. 버그관리시스템을 사용하지 않은.. 더보기
소스코드관리 상세 조사 결과 리포트 지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 2주에 걸쳐서 2차 조시를 실시했습니다. 질문항목이 26개나 되는 상당히 긴 투표였지만, 많은 분들이 응해주셔서 나름대로 의미있는 수치를 얻을 수 있었습니다. 투표에 참여해주신 모든 분께 감사드립니다. 투표위젯에 참 참여자 수를 보는 방법이 없어서 가장 많은 득표를 한 항목으로 미루어 짐작해서 35명이 투표에 참여한 것으로 생각하고 있습니다. 질문은 다음과 같았습니다. 각 항목별로 총 득표수는 다음과 같습니다. 아래 조사는 소스코드관리시스템을 사용하는 회사를 기준으로 계산을 할 것이므로 1번 항목은 100%입니다. 그럼 각 항목 별로 분석을 해보도록 하겠습.. 더보기
몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다. 주변의 회사들을 보면 몇 억짜리 툴을 사서 활용도 제대로 못하는 경우를 정말 많이 봤습니다. 제가 이전에 올린 글을 보면 소프트웨어를 개발하는데 있어서 그 팀의 성숙도에 따라서 무엇을 우선 도입해야 하고 무엇은 좀더 성숙도가 높아진 다음에 도입해야 하는지 설명한 적이 있습니다. 이중에서 가장 중요한 소스코드관리시스템과 버그관리시스템은 좋은 무료 툴들이 정말 많습니다. 하지만 이러한 무료 툴조차 쓰지 않거나 쓰더라도 아주 기초적인 기능만 사용을 하고 제대로 활용을 못하면서 정작 문제를 엉뚱한 곳에서 찾으려고 합니다. 그래서 비싼 툴을 팔고 있는 영업사원들에게 현혹되어서 몸에 걸맞지 않은 액세서리를 걸치듯 효용성도 떨어지는 툴을 사놓고 제대로 활용 못하는 경우가 많습니다. 쓰다 보면 그리 좋지 않다는 것을 .. 더보기
사라진 소스코드 바이너리는 있는데 소스코드는 없어서 낭패를 보신 적은 없으신가요? 소스코드 백업은 흔히 소홀히 하기 쉽습니다. 사고가 발생한 후에야 문제가 되고, 사고가 그렇게 자주 발생하는 것은 아니죠. 자주 발생하지는 않지만, 일단 발생하는 타격이 아주 큽니다. 일상 생활에서는 보험을 들지만, 소프트웨어를 개발하는 현장에서는 보험을 드는 격인 백업을 제대로 하는 경우는 흔히 보기 어렵습니다. 소스코드는 이러한 경우에 흔히 사라지거나 깨지게 됩니다. 이 때 백업이 없으면 낭패가 됩니다. HDD는 그리 드물지 않게 깨집니다. 그냥 운영 중에 HDD가 깨져버리는 경험은 많이들 있을 겁니다. 장비를 사무실 내에서 옮기거나, 회사가 이사를 갈 때는 HDD가 깨지는 경우가 더 흔합니다. 컴퓨터바이러스 등의 악성 코드에 의해서 .. 더보기
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 소프트웨어를 개발하다 보면 소스코드의 브랜치가 일어나고 이를 Merge(머지)하는 일은 피하기가 어렵습니다. 이 Merge(머지)과정을 자동화 툴을 이용하면 상당히 많은 시간을 절약할 수 있습니다. 특히 Merge의 자동화를 위해서는 3way-Merge가 필수적인데, 시중에서 3way머지가 지원된다고 하는 툴 4가지와 SVN에서 지원하는 Unified diff, 이렇게 총 5가지를 비교해봤습니다. 그 결과는 아래와 같이 평가를 하였습니다. KDiff3, P4Merge와 Araxis Merge가 우수하게 나왔습니다. 2way merge툴은 같은 레벨에서 비교 대상이 되지 않기 때문에 비교하지 않았습니다. 2way merge툴보다는 꼭 3way merge툴을 쓰기를 권장합니다. 3way merge툴은 실무에.. 더보기
Build Script를 C언어로 작성하기 Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까? 저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요? 누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다. 물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요. Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다. C언어는 기가 막히게 잘 아는 Scr.. 더보기
소스코드 관리 방법 조사 결과 그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다. 현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다. 이번 소스코드관리 설문의 질문은 다음과 같습니다. 소스코드는 어디에 보관하세요? (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능) 약 3주간의 설문 결과 아래와 같은 분포가 나왔습니다. Answer TextVotes% Subversion 50 45.87% CVS 18 16.51% 개인 PC에 보관 14 12.84% 공용개발서버에 보관 8 7.34% Visual SourceSafe 7 6.42% IBM Rational ClearCase 4 3.67% FileServ.. 더보기
깨끗한 개발 환경, 빌드 환경, 테스트 환경 개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다. 이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다. 따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다. 일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다. 빌드가 무엇인지 먼저 얘기를 해보죠. .. 더보기
Daily Build를 하십니까? Daily Build는 많은 혜택을 줍니다. 소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며 모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다. 요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다. 여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다. 하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요. 저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Bui.. 더보기