레이블이 기반시스템인 게시물을 표시합니다. 모든 게시물 표시
레이블이 기반시스템인 게시물을 표시합니다. 모든 게시물 표시

2020년 7월 29일 수요일

비대면 소프트웨어 개발을 위한 핵심 시스템 10가지

비대면으로 소프트웨어를 잘 개발하는 방법은 비대면이 아니라도 일반적으로 소프트웨어를 잘 개발하는 방법과 다르지 않다. 그래서 비대면으로 소프트웨어를 잘 개발하는 방법을 도입하는 것은 의미가 있다.

비대면으로 소프트웨어를 효과적으로 개발하기 위해서는 필수적으로 도입해야 하는 툴, 시스템이 있다. 이 툴 중 대부분은 비단 소프트웨어 개발 뿐만 아니라 회사의 일반 업무에도 필요한 시스템이다. 소프트웨어 회사가 아니라도 관심을 가지고 보자. 툴과 시스템을 도입하는 것은 회사의 문화, 인식, 프로세스를 바꾸는 것보다는 쉽다.

좋은 툴, 시스템을 도입해야 개발 및 업무 효율성이 배가 된다. 툴, 시스템은 오랫동안 진화를 해왔고, 지금도 진화하고 있다. 이것들을 잘 선택하는 것도 실력이다. 워낙 많은 툴, 시스템을 도입해야 하기 때문에 선택도 쉽지는 않다. 그렇다고 잘 도입해서 사용하고 있는 한 회사의 사례를 그대로 따라하는 것도 좋은 것은 아니다. 회사마다 프로젝트의 성격, 규모, 문화, 환경이 다르기 때문이다.

꼭 비싼 툴을 도입하는 것이 좋은 것은 아니다. 그렇다고 무료 툴이 무조건 좋은 것도 아니다. 비싼 툴은 비싼 값을 하지만 기능이 너무 많거나 복잡해서 회사에 따라서는 오히려 과한 경우도 있다. 회사의 규모, 문화, 프로세스에 따라서 적합한 툴의 조합을 잘 선택해야 한다.

툴, 시스템을 도입하는 것은 쉽지만 잘 쓰는 것은 어렵다. 도입만 하고 안쓰거나 형식적으로 쓰는 경우도 많다. 툴만 도입하고 프로세스와 연계를 안하거나 회사의 상황에 너무 과한 툴, 시스템을 도입한 경우에도 정착에 실패할 수 있다.

회사의 기존 프로세스를 잘 적용할 수 있는 시스템을 선택하기 보다는 툴, 시스템의 철학에 맞게 회사의 프로세스와 업무 방식을 바꾸는게 낫다. 업무 방식은 좀더 자율적이고 능동적이어야 하며 수평적으로 바뀌어야 한다. 그래야 비대면 업무가 효율적으로 진행될 뿐만 아니라 생산성도 증가한다.

각 툴, 시스템들은 서로 연결이 되어서 유기적으로 작동한다. 한 회사에서 개발한 여러 툴 세트를 쓰면 연동이 잘 되기는 하지만 그렇다고 한 회사의 툴을 쓰는 것이 무조건 좋은 선택은 아니다. 회사의 프로세스와 잘 엮어서 여러 회사의 툴을 섞어 사용하기도 한다.

그럼 비대면 소프트웨어 개발을 위해서 꼭 도입해야 할 시스템을 알아보자.

1. 문서 공유 시스템


문서들이 직원들의 각자 PC에서 생산되고 이메일을 통해서 돌아다닌다면 보통 혼란스러운 것이 아니다. 문서의 버전을 관리하기도 어렵고, 보관도 어렵다. 문서 공유 시스템을 도입하면 문서의 버전을 철저히 관리하고 적절한 공유, 권한 제어, 외부 전달, 백업이 가능하다. 비용이 들기는 하지만 비용 이상의 생산성 향상을 줄 수 있는 시스템이다.

가장 마음이 드는 기능 중 하나는 검색 기능이다. 시스템마다 차이는 있지만 회사의 수만 개의 문서 중에서 내가 찾는 문서를 간단한 검색을 통해서 몇 초 만에 찾아준다. 문서의 본문까지 모두 찾아주는 시스템도 있으니 매우 편리하다.

몇몇 문서 공유시스템은 PC의 파일 탐색기와 연동하여 편리하게 사용할 수 있도록 해준다.

회사의 문서를 외부 공간인 클라우드에 저장하는 것에 보안 상 우려를 하는 기업도 있지만, 회사 내부에서 여기저기 문서가 굴러다니는 것보다 더 안전할 수 있다.

대표적인 시스템으로는 Dropbox, Apple iCloud, Google Drive, MS Sharepoint, Amazon WorkDocs 등이 있다.

국내 기업으로는 사이버다임사의 문서관리시스템이 있다.

2. 문서 공동 작업/리뷰 시스템


문서 공유 시스템과 접목하여 문서를 공동 작업 및 리뷰할 수 있도록 하는 시스템이다. 여러 사람이 동시에 문서를 작업해도 충돌 없이 같이 작업할 수 있다. 완벽한 문서 공동 작업 솔루션이 나온 것은 그렇게 오래되지 않았다. 불과 수년 전만 해도 상상하기 어려웠던 기능인데, 이제는 일반화 되었다.

문서를 리뷰할 수 있는 기능도 제공한다. 문서 리뷰를 실시하면 여러 관련자가 문서의 곳곳에 자신의 의견을 댓글로 남기면서 토론을 할 수 있다. 그 결과를 문서에 반영하고 다시 리뷰를 진행하는 사이클로 진행된다. 이렇게 문서 온라인 리뷰를 진행하면 관련된 모든 사람의 의견을 꼼꼼히 문서에 반영할 수 있다. 이런 시스템 없이 오프라인으로 문서를 리뷰하고 반영하는 것은 보통 어려운 일이 아니다. 오프라인으로 문서를 작성한 것보다 훨씬 완성도 높은 문서를 작성할 수 있다.

이렇게 문서를 온라인으로 보관하고 공동 작업하고 리뷰하는 프로세스를 적용하고 적응해 나가면 어느덧 비대면 업무 방식에 익숙해져 간다.

대표적인 시스템으로는 MS Office 365, Google Docs, Apple iWork 등이 있다.

3. 요구사항 관리 시스템


소프트웨어를 개발하는데 있어서 가장 중요한 것 하나를 꼽으라면 요구사항을 분석해서 스펙을 작성하는 일이다. 스펙을 문서화 하기 위해서 MS Word로 작성하기도 하고, GoogleDocs, Wiki를 이용하기도 하지만, 전문적인 관리시스템을 사용하기도 한다.

MS Office와 같은 문서 위주의 편집 툴을 사용하여도 소프트웨어 요구사항을 충분히 분석하고, 협업하고, 리뷰할 수 있지만, 전문적인 요구사항 관리 시스템은 조금 더 많은 기능을 제공한다.

요구사항을 수집, 관리, 협업, 리뷰, 버전 관리, 요구사항 추적, 재활용 등에서 좀더 많은 기능 및 편리함을 제공한다. 요구사항 분석 역량을 충분히 갖춘 회사라면 한번 도입해 볼만하다.

대표적인 시스템으로는 Jama, Orcanos, DOORS, ReqSuite, Accompa 등이 있다.

4. 이슈 관리 시스템


이슈 관리 시스템은 소프트웨어 회사만 필요한 시스템이 아니다. 이슈 관리 시스템은 버그 관리 시스템에서 출발하여 점차 진화를 거듭하여 회사의 모든 이슈를 관리하는 시스템으로 성장하였다. 이제는 거의 모든 형태의 회사에 필요한 시스템이 되었다.

이슈 관리 시스템은 단순히 설치해서 사용하는 것 만으로는 그 혜택을 다 볼 수 없다. 회사의 업무 철학과 방식이 바뀌어야 한다. 업무 방식을 지시와 보고 형태에서 자발적 업무와 모니터링 형태로 바뀌어야 한다. 일일이 업무를 지시하고 추후 결과 보고를 받는 형태로 업무를 계속 하면서 그 프로세스를 이슈 관리 시스템에 적용하면 비대면 프로세스로 전환하기도 어렵고, 이슈관리시스템의 철학과는 좀 멀어지고 업무 효율성도 떨어진다.

이슈 관리 시스템이 완전히 정착되면 모든 업무가 투명하게 진행되는 효과가 있다. 투명한 업무 진행을 꺼려하는 조직도 있지만, 적응하고 나면 업무 생상선이 대폭 증가하는 것을 경험할 수 있다.

이슈 관리 시스템을 도입하여 효과를 최대로 보고 비대면 업무를 효율적으로 진행하려면 업무 방식을 바꾸는 것에 많은 노력을 들여야 한다는 것을 명심하자.

대표적인 시스템으로는 Jira, Redmine, Mantis, Bugzilla, Trello 등이 있다.

Jira는 상용 소프트웨어지만 현재 10유저까지는 무료로 제공하고 있어서 스타트업에서 매우 유용하게 쓸 수 있다.

5. 소스코드 관리 시스템


소스코드 관리 시스템을 사용하지 않는 소프트웨어 회사는 거의 없을 것이다. 만약에 특별한 이유로 소스코드 관리 시스템을 사용하고 있지 않다면 꼭 도입을 해야 한다. 특별한 이유라는 것도 소스코드 관리 시스템을 사용하지 못하는 결정적인 이유는 아닐 것이다.

소스코드 관리 시스템은 도입은 쉽지만 제대로 쓰는 것이 만만치는 않다. 브랜치, 머지, 베이스라인, 체크인에 대한 여러가지 규칙을 잘 만들고 지켜야 한다.

소스코드 관리 시스템은 중앙 집중형과 분산형이 있으니 회사의 상황에 맞게 선태하면 된다.

대표적인 시스템으로는 Subversion, Git, Murcurial, Perforce 등이 있다.

설치형, 클라우드 형이 있으며, 클라우드 형으로는 Github, Gitlab, Bitbucket 서비스 등이 있다. 각자 유/무료 정책이 있으니 비교하여 선택하면 된다.

6. CI(지속적인 통합) 시스템


개발자들이 서로 떨어진 장소에서 얼굴 안보고 실시간으로 협업을 하기 위해서는 소스코드가 항상 빌드가 가능한 상태로 유지가 되어야 한다. 소스코드는 매시간, 매분 새로 업데이트가 된다. 그런데, 한 개발자가 빌드가 안되는 상태의 소스코드를 등록하면 개발팀 전체가 개발에 차질이 생긴다. 개발자는 항상 빌드 가능한 소스코드를 등록해야 하며 이 규칙은 매우 엄격하다.

CI(지속적인 통합) 시스템을 이용하면 소스코드를 등록할 때마다 소스코드를 점검하고, 빌드 가능한 상태를 유지하도록 도와준다. 이때 회사의 코딩 규칙 검사, 자동 테스트 등을 수행하며 소스코드의 버그를 줄여주기도 한다.

CI 시스템이 잘 구축되어 있으면 개발자는 자신이 담당한 모듈을 코딩해서 소스코드 관리시스템에 등록하기만 하면 된다. 나머지는 시스템이 알아서 해준다.

대표적인 시스템으로는 Jenkins, Bamboo, Cirble CI, GitLab CI 등이 있다.

7. 코드 리뷰 시스템


코드 리뷰는 온라인, 오프라인으로 진행하며 여러가지 방법이 있지만, 비대면 개발을 위해서는 코드 리뷰 시스템이 필수다. 모여서 코드 리뷰를 할 필요가 없고, 온라인 코드 리뷰 시스템에 코드 리뷰를 등록하면 관련된 수많은 사람이 온라인으로 코드 리뷰를 진행한다. 온라인 코드 리뷰는 오프라인보다 훨씬 많은 사람이 참여할 수 있고, 시간을 많이 절약해준다. 그래서 코드 리뷰를 좀더 활성화하는데 도움을 준다.

회사의 프로세스마다 다른데, 소스코드를 등록한 후에 코드 리뷰를 하기도 하고, 코드 리뷰를 통과한 소스코드만 회사의 메인 소스코드 저장소에 등록하도록 하기도 한다.

코드 리뷰가 활성화 된 회사일수록 개발자가 더 잘 성장한다. 그리고 고참 개발자가 될수록 코드 리뷰에 더 많은 시간을 할애해야 한다. 고참 개발자는 코드 리뷰를 통해서 후배를 양성하기도 하지만, 본인이 성장하는 수단이 되기도 한다.

많은 회사들이 코드 리뷰 도입에 실패하지만, 좋은 온라인 코드 리뷰 시스템을 도입하면 코드 리뷰 정착에 도움이 된다.

대표적인 시스템으로는 Gerrit, Crucible, GitHub, GitLab, Review Board 등이 있다.

8. 지식 공유 시스템


소프트웨어 회사만 필요한 시스템은 아니다. 회사에서 업무를 하다 보면 공유할 수많은 정보, 지식이 생성된다. 지식 공유 시스템이 없다면 이런 정보는 연기처럼 사라지거나 개인의 저장소에 묵히게 된다.
정보를 생산할 때 실시간으로 정보를 정리하여 공유할 시스템이 필요하다. 그래서 지식 공유 시스템은 비대면 개발의 핵심이다.

회사, 제품, 프로젝트, 프로세스 등 여러가지 분야로 잘 나뉘어서 정리된 지식과 정보는 이 사람 저 사람 찾아다니면서 물어보지 않아도 업무를 할 수 있게 해준다. 원격으로 접속 가능한 시스템이므로 지역적인 제약없이 일할 수 있다.

대표적인 지식 공유 시스템은 Wiki와 KMS다. Wiki의 용도는 매우 다양하다. 이를 회의록으로 사용하는 경우도 많고 회의록 기능을 강화한 Wiki 시스템도 있다.

설치형, 클라우드형이 있다. 장단점이 있으니 상황에 맞게 선택해야 한다.

대표적인 Wiki 시스템으로는 Confluence(10유저 무료), Bookstack(무료), Wiki.js(무료) 등이 있다.
KMS는 국내업체인 사이버다임날리지큐브가 제공하고 있다.

9. 화상 회의 시스템


비대면 개발을 하더라도 얼굴을 보고 회의를 해야 할 때도 있다. 재택 근무가 완벽하게 진행되어 모든 업무를 문서와 시스템으로 진행한다고 하더라도, 정서상의 이유와 팀워크 유지를 위해서 얼굴을 보고 얘기를 할 필요도 있다. 또 온라인으로, 문서로 쉽게 답이 안나오는 이슈는 얼굴 보고 논의하는 것이 훨씬 효율적이다. 이럴 때는 웹캠을 이용해서 화상 회의를 실시하는 것이 좋다.

화상 회의는 주기적인 프로젝트 회의로 진행하기도 하고, 이슈가 있을 때 비정기적으로 실시하기도 한다.

회상 회의는 1:1 뿐만 아니라 여러 명이 동시에 회의를 할 수도 있다. 여러 명이 원활히 화상 회의를 하기 위해서는 빠른 인터넷도 필수다. 화상 회의는 일반 회의와 마찬가지로 용건만 짧게 빠르게 진행해야 한다.

화상 회의 시스템은 부가 기능으로 녹화, 화면 공유, 화이트 보드, 그룹 스케줄러 기능을 제공하기도 한다.

대표적인 시스템으로는 Teams, Skype Business, Google Meet(hangout), Zoom 등이 있다.

10. 협업 시스템


협업을 위한 여러가지 기능을 한꺼번에 넣어 놓은 종합 선물세트다. 소프트웨어 회사 뿐만 아니라 모든 형태의 회사에 비대면 업무를 효율적으로 진행하기 위해서 필요한 시스템이다.

기본적으로 팀 관리, 채팅, 파일관리 등이 기본 기능이지만 화상 회의, Wiki 등 위에서 언급한 여러가지 툴 중 일부를 포함하고 있는 경우도 많다.

비대면 업무 필요성이 증가할수록 도입하는 기업이 늘 것으로 생각된다.

대표적인 시스템으로는 Teams, Slack, Swit, 잔디, 라인웍스 등이 있다.

이상 10가지의 시스템을 알아봤는데, 이런 시스템을 모두 사용한다고 완벽하게 비대면으로 소프트웨어를 개발할 수 있는 것은 아니다. 또한 모두 비대면으로 소프트웨어를 개발해야 더 생산성이 높은 것은 아니다. 시스템을 잘 활용하여 개발과 업무를 진행하면 비대면 비율이 높아질 수 있다. 그 자체가 개발 및 업무 생산성이 높아지는 것과 일맥상통한다.

이 글은 ZDNet Korea에 기고한 칼럼입니다.

2014년 10월 14일 화요일

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.

이 글은 ZDNet Korea에 기고한 칼럼입니다.

2012년 10월 25일 목요일

스타트업에서 SW 개발에 꼭 필요한 시스템


소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.

회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.

1. 소스코드관리시스템
필요성: ★★★★★
추천 형태: 호스팅
추천 서비스: Bitbucket, Github
추천 시스템: Git, SVN

소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.

호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.

Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.

2. 이슈관리시스템 (버그추적시스템)
필요성: ★★★★★
추천 형태: 호스팅
추천 서비스: Atlassian Jira OnDemand
추천 시스템: Jira, Redmine

요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.

과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.

3. 빌드시스템
필요성: ★★★☆☆
추천 형태: 자체 구축
추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)

위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.

적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.

4. Wiki
필요성: ★★☆☆☆
추천 형태: 호스팅
추천 시스템: Confluence OnDemand

꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.

Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.

스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.

5. 프로젝트관리시스템
필요성: ☆☆☆☆☆
추천 시스템: 시스템보다는 엑셀 파일 이용

시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.

일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.

기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.

소스코드관리시스템
1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.
2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.
3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.
4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.

이슈관리시스템
1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.
2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.
3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.
4. 모든 이슈는 전 직원에 오픈한다.

지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.

기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.

소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.

이글은 Techit에 기고한 글입니다.

2011년 8월 13일 토요일

왜 하나만 써야 하는가?

이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 2008년에 작성한 소프트웨어 회사의 개발 역량 평가 표에는 20점 중 2점을 차지하고 있다.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표 

종종 "여러개를 쓰면 어떤가?"하는 궁금증이 있어서 그 이유를 설명하고자 하다.
 소스코드관리시스템을 여러개 쓰고 있다면?
 
회사가 아무리 크더라도 소스코드관리시스템은 하나만 쓰는 것이 좋다. 한 종류의 시스템을 여러개 설치에서 쓰는 것도 좋지 않다. 또한 특별한 이슈가 없는 경우라면 하나의 Repository에 소스코드를 관리하는 것이 좋다.

여러 시스템을 쓰는 경우는 대부분 팀마다 각자 취향에 따라서 VSS도 쓰고 SVN도 쓰고 Git도 쓰는 경우이다. 이러한 경우 각자 핑계들이 있다. Visual Studio에 최적화된 VSS를 써야 한다는 둥, 오픈소스를 이용하기 때문에 Git가 좋다는 둥의 주장을 하다가 각 팀에서 알아서 쓰기로 결정을 종종 하게 된다.

팀마다 다른 시스템을 쓰게 되면 여러가지 문제가 발생한다. 

첫째, 공통 모듈 관리가 전혀 안되서 공통 모듈을 서로 복사해서 쓰기도 하고 비슷한 모듈을 따로 개발하기도 한다. 공통모듈이 없는 SW회사는 거의 없다. 관리를 안할 뿐이다. 이것이 얼마나 큰 문제가 되냐고 생각하는 사람들도 있다. 하지만 제품이 많아지고 고객이 많아지면 이렇게 복사된 공통모듈로 개발은 엉망진창이 된다. 유지보수 비용이 몇배로 들게 된다. 

둘째, 개발자는 각 팀마다 스위치가 자유로워야 하는데 서로 다른 시스템을 배우기 위해서 시간이 들어간다. 기본 기능은 배우는데 얼마 안걸리지만 완전히 손에 익어서 능수능란하게 쓰기에는 시간이 걸리는데 괜히 쓰지않아도 될 시간이 들게 된다.

그외에 전사적으로 관리가 잘 안되서 백업도 비용이 더 많이 들고 여러가지 문제가 발생한다. 주먹구구 식으로 작은 규모로 대충 개발할 때 문제가 눈에 안 띨분이지 나중에 댓가를 치르게 된다.  나중에 문제가 발생한 후에 통합은 거의 불가능하다 처음부터 하나를 써야 한다.

 버그관리시스템을 여러개 쓰고 있다면?
 
버그관리시스템은 개발자들만 쓰는 것이 아니다. CEO를 비롯해서 전직원 모두가 쓰는 시스템이다.
그런데 각 팀마다 서로 다른 시스템을 쓰고 있는 경우라면 십중팔구 개발자나 QA팀만 쓰고 있는 경우이다. 전사적으로 통일된 결정이 없었고 회사의 지원이 없어서 개발자들이 팀내에서 알아서 결정해서 쓰는 경우가 많다. 이는 반쪽만 사용하고 있는 경우이다.

버그관리시스템은 개발을 포함해서 회사의 거의 모든 이슈가 관리되는 곳이다. 기껏해야 회계나 HR이슈들이 빠질 뿐이다. 그런데 팀마다 다른 시스템을 쓰고 있다면 이슈가 통합되서 관리도 안되고 통계도 안나오고 개발팀 바깥의 부서에서는 여러 시스템을 모두 써야 하는 불편함도 있다.

또한 여러 시스템을 다 배워야 하기 때문에 이만저만 불편한 것이 아니다. 이또한 나중에 통합은 어려우므로 처음에 하나로 잘 결정해야 한다.
 SVN과 Git를 같이 쓰는 경우는?
 
종종 SVN을 쓰면서도 출장을 자주 나가서 출장지에서 직접 개발을 해야 하는 경우들도 있다. 이런 경우 SVN과 Git를 연동해서 쓰면 유용하다.

SVN만 사용하면 출장을 나가서 1주일동안 여러가지 기능과 버그를 수정했을 경우 복귀후 Commit을 하게 되면 그동안 수정한 내용이 한번에 커밋이 되서 관리가 어려워진다.

이때 SVN Repository를 Git에 담아서 출장을 가서 개발할 때마다 여러번 Commit을 하면 복귀후 SVN과 다시 통합을 하면 그 History가 고스란히 합쳐진다.

이런 경우 처럼 Git를 보조적으로 쓰는 것도 좋다.
 다른 시스템은 쓸 필요가 없나?
 
나는 보통의 SW회사에서 소스코드관리시스템과 버그관리시스템 2개면 충분하다고 주장한다. 사실 왠만큼 회사가 커지기 전까지는 이 두가지면 충분하다. 

결재가 필요하기 때문에 전자결재를 위한 그룹웨어를 도입하고 싶어하기도 한다. 하지만 소프트웨어 회사에서 그룹웨어는 그렇게 효율적이지 않다. 전자결재는 SW개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.

그 외에 작업관리, 고객요청관리, 테스트 관리등 여러가지 관리의 필요성을 느끼게 된다. 
일단 이 두개만 가지고 쓸 수 있는 한 최대한 써보기를 권한다. 그러면 의외로 거의 모든 것을 다 커버하게 된다는 것을 알게 될 것이다.

그후에 회사의 규모가 정말로 커져서 인원이 몇백명이 되고 좀더 관리를 잘 하고 싶으면 테스트관리나 서비스데스크등 개발자들에게는 부담이 안되지만 관리에 도움이 되는 시스템을 우선적으로 도입하면 좋다.


 결론
 
나중에 통합은 어렵다. 이미 여러개의 시스템을 쓰고 있다면 합칠 수 있다면 지금이라도 합치는 것이 좋다. 나중에는 늦는다.

2011년 1월 22일 토요일

우리 회사에도 숨어서 놀고 있는 개발자가 있나?

소프트웨어 개발 조직은 전통적인 관리 방법이 별로 효과적이지 않습니다. 

소프트웨어 개발 조직은 프로세스와 시스템에 의한 자율적이고 투명한 방법이 필요합니다. 그런데 전통적이고 관료적인 관리 방법도 사용하지 않고 효율적인 프로세스와 시스템도 사용하고 있지 않는 조직에서는 개발자들이 어떻게 일을 하고 있는지 잘 파악안되곤 합니다.

물론, 놀고 있는 개발자를 찾아내고자 이 글을 쓰는 것은 아닙니다. 개발자들은 스스로 자신이 해야할 일을 찾아내고 스스로 관리해야 합니다. 물론 개발자에게 업무와 이슈가 할당되고 자신에게 주어진 일을 해야 하지만 이것이 다가 아니고 많은 일들은 스스로 해야만 회사가 경쟁력을 갖출 수 있습니다.

그러기 위해서는 효율적인 프로세스와 시스템을 갖추고 있어야 하고 문서화도 잘 해야 합니다. 그러다보면 누가 얼마나 많은 일을 했는지 자연스럽게 드러나게 됩니다. 거꾸로 들키지 않고 일을 하지 않기도 어렵습니다.

개발자들이 얼마나 많은 일을 했는지 다음을 보면 알 수 있습니다.
  • SCM 사용기록 통계
    • 소스코드 라인수
    • 문서 갱신 기록
    • 다른 개발자의 코드를 리뷰한 기록
  •  Bug Track System 사용 통계
    • 보고한 이슈
    • 할당된 이슈
    • 해당 기간 동안 해결한 이슈
    • 댓글 수
  • 리뷰 기록
    • 리뷰 실시 기록
    • 리뷰 참석 기록
  • Wiki 작성 기록
  • 문서관리시스템 업데이트 기록

물론 이 기록들을 점수를 매겨서 누가 더 열심히 일했는지 절대로 알 수는 없습니다. 같은 소스코드 라인수라고 해도 서로 난이도가 다르고 버그를 똑같이 고쳐도 10분 걸리는 버그가 있는가 하면 한달동안 고쳐야 하는 버그가 있기 때문입니다. 따라서 평가에 직접적인 기준으로 삼는 것도 위험합니다.

개발자들은 이러한 시스템을 통해서 자신이 하는 작업들이 항상 기록에 남고 별도의 관리를 하지 않아도 항상 모니터링할 수 있습니다. 이러한 방법이 매일 해야 하는 일을 일일이 관리하는 것보다 훨씬 효율적입니다.

일안하고 숨어서 딴짓하는 개발자를 찾아내는 것은 그냥 부수적인 효과일 뿐입니다.

2009년 3월 5일 목요일

몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다.


주변의 회사들을 보면 몇 억짜리 툴을 사서 활용도 제대로 못하는 경우를 정말 많이 봤습니다.

제가 이전에 올린 글을 보면 소프트웨어를 개발하는데 있어서 그 팀의 성숙도에 따라서 무엇을 우선 도입해야 하고 무엇은 좀더 성숙도가 높아진 다음에 도입해야 하는지 설명한 적이 있습니다.

이중에서 가장 중요한 소스코드관리시스템과 버그관리시스템은 좋은 무료 툴들이 정말 많습니다. 하지만 이러한 무료 툴조차 쓰지 않거나 쓰더라도 아주 기초적인 기능만 사용을 하고 제대로 활용을 못하면서 정작 문제를 엉뚱한 곳에서 찾으려고 합니다. 그래서 비싼 툴을 팔고 있는 영업사원들에게 현혹되어서 몸에 걸맞지 않은 액세서리를 걸치듯 효용성도 떨어지는 툴을 사놓고 제대로 활용 못하는 경우가 많습니다.

쓰다 보면 그리 좋지 않다는 것을 느끼게 되도, 이를 도입한 담당자는 자신의 실수와 미숙함을 숨기기 위해서 효과를 과대포장하는 경우가 많습니다.

제가 장담 하건데 대부분의 소프트웨어 회사들은 무료 개발툴(기반시스템)로 충분히 좋은 소프트웨어를 만들 수 있습니다. 제가 이 블로그에서 소개하는 툴이나 기반시스템도 대부분은 Open Source나 무료 소프트웨어에 포커스를 하고 있습니다. 이러한 것들이 유료툴에 못지 않게 좋으니까요.

하지만 결국 무료냐 유료냐를 떠나서 얼마나 툴을 잘 사용하느냐가 중요합니다. 소프트웨어 개발에 문제가 있는 개발팀이 어느날 툴하나 도입했다고 해서 갑자기 드라마틱하게 상황이 바뀌지는 않습니다. 결국 사람들이 바뀌어야 하는데, 프로세스, 조직도 바꾸고, 각 개발자들의 마인드도 바꿔야 합니다. 스스로의 노력으로 오랜 시간에 걸쳐서 바꿀 수도 있고, 전문가의 도움을 받을 수 있죠.

앞으로도 이와 같은 툴을 유용하게 쓰는 법이나, 개발 프로세스 등 소프트웨어 개발에 우선적으로 필요한 요소들을 계속 올릴 겁니다.

감사합니다.

2009년 2월 5일 목요일

깨끗한 개발 환경, 빌드 환경, 테스트 환경

개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다.
이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다.
따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다.

일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다.

빌드가 무엇인지 먼저 얘기를 해보죠. 개발자 Visual Studio나 Eclipse 같은 IDE을 이용해서 빌드하는 것은 여기서 말하는 빌드는 아닙니다. 여기서 말하는 빌드는 공식 빌드입니다. 공식 빌드는 Release를 위해서 빌드하는 것을 말합니다. 개발자들이 하는 빌드는 그냥 개발의 일부이죠.

많은 개발자들이 자신의 개발 환경에서 그냥 빌드한 결과물을 묶어서 제품을 만들어 고객에게 전달하곤 합니다. 그렇게 되면 IDE의 빌드 설정에 따라서 빌드의 결과가 달라져서 예기치 못한 문제가 발생하기도 하고, 개발자가 퇴사하고 새로운 개발자가 빌드를 하려고 하니 빌드가 안되기도 합니다. 또는 개발자 PC의 환경에 영향을 받아서 개발자 PC에서는 잘 동작했으나, 고객의 환경에서는 문제가 발생하기도 합니다.




각각의 환경의 관리는 개발팀, B/R팀, 테스트 팀이 맡고 있고 함부로 건드리지 못합니다. 

지금까지 이러한 구분없이 개발을 하고 계셨다면 혹시 이로 인한 문제는 없었는지 생각해보세요. 없었다면 정말 운이 좋은 겁니다. 시스템이 점점 커지고 고객이 많아지는데도 계속 운만을 바랄 수는 없겠죠. 

2009년 2월 4일 수요일

Daily Build를 하십니까?

Daily Build는 많은 혜택을 줍니다.
소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며
모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다.

요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다.
여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다.
하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요.
저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Build를 할 수 있어야 한다고 생각합니다.
기본적인 개발 Stage를 사용하던, Iteration을 쓰던 간에 설계의 결과물은 빌드가 되어야 한다는 것입니다. TDD를 사용할 경우 Test 코드를 먼저 작성을 하기 때문에 빌드가 가능합니다. 테스트는 통과를 하지 못하더라도 말입니다. 즉 껍데기, Class, Public function의 Prototype을 정해 놓고 빌드가 가능한 상태로 만들어 놓고 구현을 시작합니다.

이때 SCM에 Baseline을 한번 설정을 하고 소스코드의 내용을 채워 나가기 시작합니다. Daily Build의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.

2009년 2월 3일 화요일

서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System)

소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다.

이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다.

만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다.

그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단하게 예를 들어 보겠습니다. 여기서 예라고 하는 이유는 계속 개량 발전시켜나면 연동하는 것들은 점점 늘어나고 자동화 되면서 효율은 더욱 높아지기 때문입니다.

물론 이 외에도 사용하는 기반시스템들도이 있지만, 아래 그림이 소프트웨어 회사라면 필수록 필요한 최소한만 추린 것입니다. 


  
각각의 연동 방식이나 자세한 내용은 많은 양이므로 추후 하나씩 설명하도록 하겠습니다.
그리고 하나하나의 운영 방법도 다양하고 계속 발전하고 있어서 자신의 회사에 적당한 방법을 찾아야 합니다.

이렇게 서로 연동되고 있지 않으면 자동화 될 수 있는 일에 괜히 시간과 노력을 들이고 있는 겁니다. 그렇게 된다면 개발자들은 개발을 해야 할 소중한 시간에 쓸데 없는데 시간을 허비하고 실수에 의한 사고 가능성도 높아집니다. 또 오랫동안 개발 정보가 쌓여도 그리 효율적으로 활용되지 못합니다. 

일단 이런 식으로 잘 갖추워진 기반시스템 하에서 개발을 하다보면 과거의 방식으로는 도저히 돌아갈 수 없고, 과거에 왜 그렇게 개발을 하면서 시간을 낭비했는지 안타까운 마음이 생길 겁니다.

2009년 1월 28일 수요일

이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac



자바 개발자를 위한 책을 소개합니다.

---------------------------------------------------------------------------

Trac을 비롯한 필수 유틸리티로 프로젝트 환경에 단비를 내리는 책 

이 책은 Trac(위키와 이슈 트래커), Subersion, Mylyn, Subclipse 플러그인, CVS, Ant, JUnit을 사용해서 자바 프로젝트 환경을 개선하는 책이다. 이 책의 내용은 유틸리티의 설치와 사용법 그리고 이클립스에서 유틸리티를 통합해서 사용하는 방법에 중심을 두고 있다. 

마지막 장에서 다루는 프로젝트는 책에서 다루는 모든 유틸리티와 플러그인을 사용해서 실제 개발 프로젝트를 보인다. 어떻게 개발자의 프로젝트 환경을 변화시키는지 직접 확인할 수 있다. 

이클립스 필수 단축키 수록
독자 Q&A 포럼: http://eclipseforum.net/ 

프로젝트 유틸리티란 무엇이고 이 책에서는 무엇을 다루었는가? 

프로젝트 유틸리티(Project Utility)란 말 그대로 프로젝트에 도움을 주는 유틸리티란 얘기다. 그리고 이클립스에 기반을 둔다는 것은 프로젝트 유틸리티가 이클립스에 통합되어 활용이 가능하다는 것을 의미한다. 

다음은 이 책에서 다루는 용도에 따른 프로젝트 유틸리티의 분류다.

  • 버전 관리 시스템: 소스나 문서 등의 파일이나 폴더를 공유하고 이력을 관리하는 시스템
    => CVS, Subversion, Subclipse 플러그인
  • 빌드 자동화 시스템: 빌드, 배포 등의 반복 작업을 자동화하는 시스템
    => Ant
  • 테스팅 시스템: 단위 테스트를 자동화, 정규화하여 코드의 안정성을 확보하는 시스템과 프레임워크
    => JUnit
  • 이슈 관리 시스템: 버그나 이슈 등을 한 곳에 모아 관리하는 시스템
    => Trac용 Issue Tracker, Mylyn
  • 위키: 온라인 협업 문서화 시스템
    => Trac용 Wiki
그리고 이 책의 초판과 달라진 점은 다음과 같다.
  1. CVS, Ant, JUnit의 새로운 버전의 설치와 사용법 그리고 이클립스에서의 사용법
  2. Subversion과 Subclipse 플러그인의 설치와 사용법 그리고 이클립스에서의 사용법
  3. Trac용 Wiki의 설치와 사용법, Wiki 문법 그리고 이클립스에서의 사용법
  4. Trac용 Issue Tracker의 사용법 그리고 이클립스에서의 사용법
  5. Mylyn과 Mylyn Trac connector의 설치와 사용법
  6. TOW를 이용해서 간단히 Trac과 플러그인을 설치 및 설정하는 방법
    (TOW는 오픈 소스 프로젝트로 Trac의 사용 환경을 간단히 구축할 수 있는 패키지다. 현재 저자가 이 프로젝트에 참여하고 있다.)
  7. 이클립스 필수 단축키(잘라서 붙여놓고 볼 수 있다)
이러한 이 책의 내용들이 "유틸리티를 왜 사용하고 또 어떻게 사용할까?"를 궁금해하는 독자들에게 답을 줄 것이다

----

이 책에 대한 A/S는 http://eclipseforum.net/ 에서 한다고 합니다.

예약구매 페이지는 한빛미디어에서 합니다.

2008년 12월 8일 월요일

우리 개발자는 뭐든 뚝딱 잘 만들어요.

소프트웨어를 개발하기 위해서는 기본적으로 갖춰야 할 인프라스트럭쳐시스템(Infrastructure System, 기반시스템)에 대해서 이미 본 블로그에 글을 올린 적이 있습니다.

그런데 여러 회사를 만나보니 이러한 시스템 중에서 일부를 직접 만들어서 사용하려는 경우를 종종 접하게 됩니다.

이런 회사를 "Tool company"라고 부릅니다.

자신들의 주력 제품이 아니고 개발하기 위해서 필요한 툴들을 만들어서 사용하려는 회사를 말합니다.
물론 워낙 특수한 형태의 툴로서 세상에 존재하지 않거나 구할 수가 없는 예외적인 경우도 있습니다.
하지만 개발 프로세스에 일반적으로 필요한 시스템들은 직접 만들어서 사용한다는 것은 큰 문제입니다.
특히, 버그관리시스템이나 프로젝트관리시스템을 만들어서 사용하거나, 만들려고 시도하는 회사가 많습니다.
그런 회사들은 이렇게 말합니다.

  • 우리회사는 다른 회사와 다르다. 우리는 임베디드 소프트웨어를 개발한다. 우리는 금융회사다. 우리는 게임회사다. 우리는 포탈이다. 이유도 많습니다.
  • 상용제품의 우리회사만의 요구사항을 만족할 수 없다.
  • 우리가 만들면 사용제품보다 더 잘 만들 수 있다. 
  • 우리 입맛에 딱 맞게 만들 수 있다. 그리고 필요할 때 언제든지 수정해서 사용할 수 있다.

특히, 개발자들이 이런 주장을 하는 경우가 흔합니다. 개발자들은 이런 것을 만드는 일을 만만하게 보는 경우가 많습니다. 경험이 적은 개발자들은 단순히 코딩해서 동작하도록 구현하는 것만 생각하는 경우가 흔합니다. 그 뒤에서 수십배의 일과 문제가 기다리고 있다는 것은 잘 모릅니다.
당장 원하는 기능의 툴을 만드는 것은 어려운 것이 아닙니다.
일단 툴을 만들어서 사용하기 시작하면 개미지옥에 빠져든 개미처럼 점점 빠져들며 헤어나오기 어려워집니다.
이렇게 만들어진 툴도 하나의 소프트웨어로서 유지보수가 필요해집니다. 기존의 버그도 잡아야겠고, 사용하다가 불편하면 계속 수정사항을 요구합니다. 
만들 때는 간단해 보였는데, 쓰면 쓸수록 손 볼일이 많아집니다.
본연의 개발업무에 집중해야 할 개발팀이 내부 툴 유지보수 하느라 시간을 낭비하고 쓸수록 기능도 만족스럽지 않다는 것을 알게 됩니다.

일단 우리회사는 다른 회사와 다르다고 생각하는 것은 좁은 시야와 경험의 부족에서 오는 착각입니다. 그리고 상용제품이 우리회사의 요구사항을 만족할 수 없는 것이 있다면 회사가 바뀌는 것이 좋습니다. 이 경우 회사의 프로세스가 잘못되어 있을 확률이 99%이상입니다. 사소하게 보아 넘기는 기능 하나하나에 깊은 의미가 있다고 생각하고, 좋은 툴이라면 거기에 맞추겠다는 생각으로 회사의 프로세스나 조직, 문화 등을 먼저 다시 생각해보는 것이 좋겠습니다.  

좋은 툴을 도입하는 것은 단순히 비용을 절약하는 것을 떠나서, 회사의 개발 프로세스까지 선진화된 형태로 바꿀 수 있는 힘이 있습니다. 반대로 말하면 이러한 툴이 없이 제대로 된 개발 프로세스로 개발을 하는 것이 불가능하다는 의미이기도 합니다.

이러한 것을 만들어서 쓰려는 "Tool Company"가 되어서는 안되고 좋은 툴을 찾아서 전사적으로 사용하면서 선진적인 개발프로세스와 문화를 받아들이는 자세가 필요합니다.