진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 

툴, 시스템

재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.

문서 관리

비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 

문서 작성 역량

비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.

보고

진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.

화상 회의 빈도

가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.

회의 결과 관리

가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.

메신저 사용

가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 

업무 만족도

가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.

재택근무 가능 여부

가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.

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

비대면 소프트웨어 개발을 위한 핵심 시스템 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에 기고한 칼럼입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

스타트업에서 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에 기고한 글입니다.

왜 하나만 써야 하는가?

이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 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개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.

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

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

결론

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

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

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

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

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

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

개발자들이 얼마나 많은 일을 했는지 다음을 보면 알 수 있습니다.

• SCM 사용기록 통계
• 소스코드 라인수
• 문서 갱신 기록
• 다른 개발자의 코드를 리뷰한 기록
•  Bug Track System 사용 통계
• 보고한 이슈
• 할당된 이슈
• 해당 기간 동안 해결한 이슈
• 댓글 수
• 리뷰 기록
• 리뷰 실시 기록
• 리뷰 참석 기록
• Wiki 작성 기록
• 문서관리시스템 업데이트 기록

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

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

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

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

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

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

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

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

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

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

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

감사합니다.

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

개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다.

이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다.

따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다.

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

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

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

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

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

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의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.