2009년 1월 19일 월요일
프로젝트는 연습이 아니다.
2012년 10월 29일 월요일
절대 코딩하지 마라
2011년 11월 14일 월요일
프로토타입을 재활용하면 될까? 안될까?
2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?
소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.
여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.
필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.
그 이유는 다음과 같은 것들이 있다.
- 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다.
- 보통 에러처리와 약간의 버그는 무시한다.
- 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
- 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
- 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다.
보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.
제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.
그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다.
그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.
- 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
- 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
- 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
- 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
- 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.
스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다.
어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.
스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.
이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.
프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.
단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.
2008년 10월 29일 수요일
책소개 - 소프트웨어개발의모든것(All of Software Project)
이번에 집필한 책입니다.
책소개 |
|
저자 및 역자 소개 |
| ||||
|
목차/책속으로 |
|
• 출판사 리뷰
| ||
지금까지 일이 지지부진했던 이유와 개선방향을 제시해준 책. 맨날 밤새고 집에도 못가지만, 주먹구구식으로 짜보고 고치는 습관을 고치지 못했던 게 후회가 되었다. 우리회사, 우리 팀의 개발 현실의 문제점을 알 수 있었고, 현실적인 대안을 찾을 수 있었다. 물론 실천하기는 쉽지 않겠지만 ^^; |
2014년 2월 2일 일요일
CMMI는 회사를 망칠 수도 있다
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가지의 시스템을 알아봤는데, 이런 시스템을 모두 사용한다고 완벽하게 비대면으로 소프트웨어를 개발할 수 있는 것은 아니다. 또한 모두 비대면으로 소프트웨어를 개발해야 더 생산성이 높은 것은 아니다. 시스템을 잘 활용하여 개발과 업무를 진행하면 비대면 비율이 높아질 수 있다. 그 자체가 개발 및 업무 생산성이 높아지는 것과 일맥상통한다.
2008년 12월 20일 토요일
빌딩과 개집
2008년 12월 30일 화요일
소프트웨어는 소프트하지 않다.
2020년 10월 17일 토요일
비대면 소프트웨어 개발에 가장 중요한 문서는?
코로나19로 인해 전세계적으로 비대면 업무 방식이 확대되고 있고 소프트웨어 개발도 비대면 개발 방식이 크게 요구되고 있다. 비대면 업무 방식은 업무 효율성 증대와 생산성 향상에 기여를 하기 때문에 코로나19가 아니라도 도입이 필요하다.
글로벌 소프트웨어 회사인 깃랩은 코로나 이전에도 1300명 전직원이 재택근무를 했고, 구글이나 페이스북 같은 글로벌 소프트웨어 회사도 코로나19 이전부터 상당수의 직원이 풀타임 재택 근무를 수행했고, 현재는 재택 근무를 대대적으로 확대하고 있으며 앞으로 전면 재택 근무로 전환하겠다고 하는 회사도 많다. 이렇게 할 수 있는 이유는 이전부터 비대면 개발이 가능한 형태로 일을 해왔기 때문이다.
비대면 소프트웨어 개발을 위해서는 시스템, 프로세스, 문서, 문화 등 여러가지를 갖추고 있어야 한다. 이중에서 문서는 얘기를 해보려고 한다. 소프트웨어를 개발할 때 프로젝트에 따라서 다르지만 여러가지 문서를 작성한다. 이중에서 비대면 개발을 위해서 가장 필요한 문서는 무엇일까?
비대면 개발에 가장 중요한 문서는 스펙
필자가 생각하는 가장 중요한 문서는 “스펙”이다.
“스펙”은 비대면 개발을 위해서만 필요한 것이 아니고 소프트웨어 개발 전체에 가장 핵심적인 문서이다.
과거 80년대 전세계적인 소프트웨어 위기를 극복하기 위해 소프트웨어 공학이 급속히 발전하면서 소프트웨어 프로젝트 성공을 위해서 가장 중요한 요소로 “스펙”을 꼽았다.
2000년 이후 우리나라의 수많은 대기업들이 글로벌 회사로 성장하면서도 소프트웨어 개발의 문제를 겪으면서, 방법론, 프로세스, 고가의 툴 등을 도입하면서 문제를 해결하려고 했으나, 기대만큼 문제를 해결하지 못했고, 몇몇 회사들은 “스펙”의 중요성을 인식하고 “스펙” 작성 역량에 투자를 하고 있다.
많은 회사들이 소프트웨어를 개발할 때 대략의 요구사항을 가지고 개발자들이 밀접히 접촉하여 의논하면서 소프트웨어를 개발한다. “스펙” 문서를 주고, 자신이 담당한 부분을 나눠서 멀리 떨어진 장소에서 일할 수 있는 회사는 그렇게 많지 않다. 이유는 “스펙” 문서를 제대로 작성하지 못하기 때문이다.
애자일이나 스크럼 방식으로 개발을 하는 경우 과거처럼 “스펙” 문서는 필요 없다고도 하는데, 그렇지 않다. 방식만 다를 뿐이지 “스펙”은 필요하다.
다같이 모여서 개발을 한다면 수시로 의논하며, 조율하여 개발을 해나갈 수 있지만, 비대면 개발을 한다면 그렇게 할 수 없다. 자신이 개발할 부분이 명확하게 정의가 되어 있어야 서로 떨어져서 개발을 할 수 있다. 하지만 스펙 문서가 없이 개발하거나 대략의 요구사항을 가지고 서로 모여서 조율해가면서 개발하는 방식에 익숙한 대부분의 회사들은 비대면 개발을 할 수가 없다.
그럼 코로나 이전에도 1300명의 전직원이 재택근무를 하고 있는 깃랩이나, 수많은 직원이 집에서 일하고 있었던 구글이나 페이스북은 어떻게 진작에 비대면 개발을 광범위하게 수행하고 있었을까?
시스템, 프로세스, 문화, 문서 등 여러가지 요소가 있지만, 잘 작성한 스펙이 그중에서 중요한 역할을 한다. 코딩은 개발 단계에서 가장 많은 인원이 참여하는 단계다. 많은 개발자가 서로 떨어져서 일할 수 있도록 스펙을 잘 작성해서 공유하기 때문이다.
여기서 문제는 스펙을 잘 작성하는 것이 소프웨어 개발에서 가장 어려운 주제라는 것이다. 국내 많은 기업들이 소프트웨어 개발 역량을 글로벌 수준으로 끌어 올리는데 여전히 어려움을 겪고 있는 이유도 스펙 작성의 어려움이 한 요소로 작용하고 있다.
스펙 문서는 꼼꼼하게 모든 것을 방대하게 작성하는 것이 잘 작성하는 것도 아니고, 간단하게 작은 문서로 작성하는 것이 잘 작성하는 것도 아니다. 방대한 템플릿을 꼼꼼하게 채우는 것이 올바른 방법도 아니다.
스펙의 역할은 여러가지가 있지만, 개발자 관점에서는 스펙 문서를 보고 자신이 개발한 부분을 충분히 구현할 수 있을 정도가 되어야 한다.
잘 작성한 스펙 문서가 어떤 것인지는 칼럼에서 짧게 다룰 수 있는 주제는 아니다. 그래서 여기서 스펙 문서에 대해서는 구체적으로 자세히 설명하지는 않겠다.
거대한 방법론이나 소프트웨어 공학 이론에서도 소프트웨어 스펙을 작성하는 방법을 이론적으로 다루고 있고, 이를 따라하면 방대하고 복잡한 스펙을 작성해야 한다. 하지만 깃랩, 구글, 페이스북이 이런 방식을 따르고 있지 않다. 이론은 이론일뿐, 실전적인 방법으로 스펙을 작성하고 있다. 대부분의 회사는 이런 이론을 따라하다가는 백이면 백 실패한다.
스펙을 작성하는 방법은 피아노와 골프를 배우듯 실전적인 방법을 배워나가야 한다.
10배의 비용과 시간을 들여서 완벽하게 자세한 스펙문서를 작성할 수 있을지는 몰라도 대부분의 실제 프로젝트에서 그런 방법은 쓸모가 없다.
최소 비용으로 효과적으로 스펙을 작성하는 것이 실전적인 방법이다.
스펙은 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위한 것
소프트웨어 프로젝트에서 스펙을 잘 작성하는 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위함이다.
그래서 거대 방법론에서 제안하는 수십가지의 문서를 작성하는 방법은 실전적인 프로젝트에서 효용성이 떨어진다. 많은 회사가 이 방법을 시도했다가 포기하거나 프로세스는 따르지만 정작 소프트웨어 문제를 해결하지 못한 상태가 계속 되곤 한다.
아직도 많은 회사들이 소프트웨어 개발에 문제를 가지고 있다. 대부분의 프로젝트는 계획된 일정에 끝내지 못한다. 그래서 계획된 사업 로드맵에 맞춰 제때 소프트웨어가 출시되지 못해서 많은 사업이 차질을 빚고 있다. 또한 출시된 소프트웨어는 여러가지 문제가 발생하고 유지보수에 어려움을 겪고 있다. 소프트웨어 회사의 사업을 영위하는데 큰 어려움을 주고 있는 것이다.
이러한 소프트웨어 문제를 해결하기 위해서는 소프트웨어 공학에서 언급하는 프로세스, 툴, 품질, 설계, 형상관리 등 여러가지가 다 필요하고 이러한 것들은 충분히 확보가 가능하다.
하지만 가장 근본적이고 어려운 “스펙"을 작성하는 역량을 확보하지만 않으면 넘을 수 없는 벽에 부딪히게 된다. 소프트웨어에 있어서 2류까지는 가능할지 몰라도 1류가 되기는 어렵다.
그래서 나는 기업들이 소프트웨어 문제를 해결하고 구글이나 페이스북과 같은 글로벌 수준의 소프트웨어 개발 역량을 확보하고 싶다면 개발자들이 스펙을 제대로 작성할 수 있는 역량을 확보할 수 있도록 해야 한다고 주장한다.
스펙은 분석 아키텍트가 혼자서 스펙이라는 문서를 달랑 작성하면 되는 것이 아니다. 스펙을 제대로 작성한다는 것은 회사 전체가 같이 움직이는 것을 말한다. 모든 관련자가 요구사항을 충분히 수집에 협조하고, 여러 전문가가 참여를 하며 작성된 스펙 문서에 대해서 관련자들이 철저히 리뷰를 하고 변경관리도 제대로 해야 한다. 모든 직원들은 스펙 문서를 이해하고 읽고 이에 따라서 일할 수 있어야 하고, 개발자는 스펙 문서를 파악하고 떨어져서 개발을 할 수 있어야 한다. 이러한 관행을 갖추려면 많은 노력과 오랜 시간이 걸린다.
여기서 중요한 것은 방법론, 툴이 아니고 문화, 습관, 인식의 변화다. 또한 이런 것을 이끌려면 경영자의 강력한 의지도 중요하다. 몇년전 국내 S사에서 소프트웨어 역량의 근본적인 해결을 위해 내부에서 분석아키텍트를 양성하기 위한 노력을 시작했는데 이런 활동을 매우 긍정적으로 생각한다. 시간이 오래 걸리겠지만, 꾸준히 노력하면 글로벌 수준의 소프트웨어 역량을 갖추는데 중요한 발판이 될 것으로 생각한다.
대기업보다 움직이기 수월한 스타트업이나 중소기업은 노력여하에 따라서 스펙 작성 역량을 확보하기 더 용이하다. 소프트웨어 1류가 되고 싶다면 스펙에 관심을 가지고 스펙 역량을 확보해야 한다.