소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.

성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.

소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.

따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.

말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 

사실 개발자들은 기획에서 정확한 요구사항을 주지 않는 다거나 나중에 요구사항을 바꾼다고 불평이 많다. 하지만 많은 경우 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 개발하고 이런 악순환을 반복하곤 한다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 최근에는 Agile이 각광을 받고 있지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하는 것이다. 또한 그 과정에서 모든 관련자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.

image by Pokey's Dad

성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다.

하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다.

시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다.

10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다.

소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로 발전시켜나가는 노력이 필요하다.

회사마다 여건이 조금씩 다르지만 몇가지 예를 들어보겠다.

10초라도 낭비하면 아까운 시간들이다.

• 빌드가 완전 자동화가 되어 있지 않아서 소스코드를 빌드할 때마다 약간이나마 중간에 수작업이 들어가는 시간 - 빌드는 완전 자동화를 구현해야 한다. 당연히 Command line으로 빌드가 되어야 하고 한번의 Enter로 최종 설치본까지 생성이 되어야 한다.
• 이슈(버그)관리시스템을 잘 관리해보고자 너무 많은 커스텀필드를 넣어서 이슈(버그)를 등록할 때마다 몇초씩 더 걸리는 시간 - 적당한 커스트마이징은 필요하지만 과도함은 삼가해야 한다.
• 이슈관리시스템이 있는데 보고나 관리를 위해서 별도의 자료를 만드는 시간 - 이슈관리시스템을 이용하면 원하는 View로 원하는 정보를 실시간으로 볼 수 있다. 관리자도 보고를 기다리지말고 직접 이슈관리시스템을 봐야 한다.
• 여러벌의 Branch에 같이 존재하는 버그를 동시에 고치기 위해서 수작업을 할 때 - SCM의 Merge기능을 믿지 못하거나 기능을 활용할 줄 몰라서 수동으로 Merge를 하는 행위는 정말 시간 낭비이다. 제대로만 사용한다면 SCM의 Merge기능은 막강하고 99.9% 믿을만하다. 수작업이 아니고 최종적인 확인 정도만 해도 되는 경우가 대부분이다.
• 개발자들의 주간 보고서 작성하기 - 이부분은 약간 논란의 이슈가 있다. 정말 간단한 주간보고서는 큰 무리가 없지만 부담스러울 정도의 주간보고서는 개발자들이 작성하지 않는 것이 좋다. 개발자들의 업무 기록은 이슈관리시스템 등에 다 남아 있다. 관리자는 개발자를 괴롭히지 말고 스스로 시스템을 보면 된다. 물론 기반시스템들이 잘 구축되어 있어야 한다.

우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 

스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효율적인 개발문화와 환경을 가지고 있는지 궁금할 것이다.

이렇게 비교를 해보자. 당장 우리 회사의 개발자들이 모두 재택근무를 하면 어떻게 될까? 그리고 일주일에 딱 하루만 회사에 나와서 필요한 회의를 한다면...

대부분은 그렇게 해서는 회사가 돌아가지 않을 것이라고 생각할 것이다. 

그렇다면 아직 먼 것이다. 소프트웨어 회사가 효율적인 프로세스와 시스템을 갖추고 개발 역량과 성숙한 개발문화를 갖추고 있다면 얼굴보고 해야 할 일이 그렇게 많지가 않다. 일주일에 몇시간이면 충분하다.

일단 회의가 너무 많은가? 회의는 정말 비효율적이다. 꼭 필요한 회의가 아니면 대부분의 회의는 시간을 비효율적으로 사용하며 많은 인원의 시간을 한꺼번에 소비한다. 대분은 시스템으로 커버가 가능하다.

개발할 때마다 얼굴을 보고 설명을 해줘야 하는가? 주먹구구식 개발의 대표적인 현상이다. 효율적으로 작성된 SRS가 있다면 설명해줘야 하는 시간은 수십분의 일로 줄어든다. 줄어들어야 제대로 작성된 SRS이다.

수시로 물어봐야 해서 항상 자리에 붙어 있어야 하는가? 성숙한 개발 환경에서는 프로세스, 시스템, 문서등이 이를 대신한다. 

실제 이런 경험이 있는 않은 경우라면 즉, 기존의 적당한 주먹구구와 공력에 의해 개발을 했거나 비효율적인 프로세스를 적용해서 나쁜 기억만 가지고 있는 경우라면 이렇게 개발하는 것이 더 비효율적인 것이 아니냐고 반문을 하곤한다. 그렇게 하려면 문서를 너무 많이 적어야 하는 것이 아닌가? 프로세스나 시스템이 오히려 더 거추장스러운 것이 아닌가? 의문을 품을 수 있다.

책이나 인터넷을 보고 프로세스를 따라한 부작용이기도 하다. 태권도장에 가서 직접 태권도를 배우면 금방 되는 것이 책을 보고 배우면 대부분은 제대로 배우지 못하고 효율적이지 못한 것과 비슷하다.

프로세스, 시스템, 문서 모든 것은 개발을 빠르고 효율적으로 하기 위해서 존재하는 것이고 그보다 더 이상 이하여서도 안된다. 이는 제대로된 경험으로만 터득이 가능하다. 따라서 경험자나 전문가의 가이드가 필요한 것이다.

나름대로 개발 환경을 개선하기 위해서 열심히 노력한 경우라도 재택근무가 가능한 수준이 아니라면 아직 갈 길이 멀다는 것을 명심하자.

이제 효율적인 개발에 한발을 내딪였을 뿐이다.

image by  edgeplot

우리나라 경영자들은 "내가 책임지고 해보겠습니다."라는 말을 좋아한다. 물론 책임감을 가지고 일을 추진하는 것은 좋은 일이다. 하지만 많은 경우 엄밀히 말하면 제대로 책임을 지는 것이 아니다. 결과적으로 책임을 지겠다고 말만하는 꼴이 되는 경우가 많다. 그럼에도 무모하더라도 추진력있게 밀고 나갈 사람이 인기가 많다.

경영자들이 이런 돌격형 인재를 좋아하는 이유는 여러가지가 있다. 실제 좋은 성과를 내는 경우도 많지만 소프트웨어에서는 상황이 좀 다르다. 

경영자들이 소프트웨어 개발에 대해서 잘 모르기 때문에 그냥 알아서 개발을 해주기를 원하는 경우가 많다. 또한 이런 경우 무모한 시도가 되는 경우가 많다. 

열심히 하는 것은 좋지만 무모한 것과는 다르다. 대부분의 무모한 프로젝트는 일정이 제대로 예측이 안되는 상태로 밀어 붙인다. 일정이 촉박하다는 이유로 분석, 설계 생략하고 코딩부터 진행하고, 개발 막바지까지 현재 진행률을 파악하기가 어렵다.

비즈니스를 하기에는 이렇게 열심히 일하지만 예측 불가능한 프로젝트보다는 합리적인 일정제시와 제시된 일정에 결과가 제대로 나오는 프로젝트가 더 좋다. 그래야 비즈니스도 계획한 대로 움직일 수 있다.

이렇게 무모한 프로젝트를 진행하는 개발자들은 불투명한 프로젝트 진행을 선호한다. 투명하게 프로젝트를 진행하는 것이 더 효율적이라는 것을 몰라서 그렇게 하기도 하지만, 정보와 지식을 숨길 수록 자신들의 가치가 더 올라간다고 착각을 하기도 한다.

이런 환경에서는 경영자는 Detail은 잘 모르고 개발자들을 쪼기만(일정 압박) 하고, 개발자들은 매일 야근에 내몰리다가 프로젝트 막바지에는 이런 저런 핑계를 만들어 내기 급급해진다. 물론 가끔은 일정내에 프로젝트가 끝나기도 하지만 그 과정에서 마케팅, 영업, QA와 유기적으로 협력이 잘 안되고 혼자 달려가는 프로젝트가 되곤한다. 개발자가 개발을 끝내주면 그때부터 다른 부서는 일이 시작된다. 무엇을 개발하고 있는지 제대로 파악이 안되므로 미리미리 준비를 하기도 어렵다.

물론 개발자는 열싱히 일을 했다. 비난을 들으면 억울할만하다. 물론 나는 개발자를 비난하는 것은 아니다. 이런 일이 벌어지는 근본적인 이유는 경영자들의 무모한 개발자를 선호하고 너무 압박을 하기 때문이다. 이런 일이 반복되면 개발자는 지치고 프로젝트는 지연된다. 잘못된 방향으로 달려가던 프로젝트는 커다란 매몰비용(Sunken cost)를 치뤄야 하기도 한다. 이런 상황에서는 경영자도 개발자도 선택의 여지가 별로 없다. 아무리 손해를 보더라도 경영자는 이런 무모한 프로젝트에 계속 후원을 할 수 밖에 없다. 

이 모든 부작용은 개발 문화의 부재에서 오는 것이다. 제대로 된 스펙에 의해서 합리적인 일정을 제시하고 경영자는 이를 믿어줘야 한다. 처음에는 개발자들이 역량이 부족하여 나름대로 개발자들이 제시한 일정이 좀 틀릴 수도 있지만 개발자들은 최대한 합리적인 가능한 일정을 제시해야 한다. 그런 관계가 거듭되야 개발자도 역량이 향상되고 비즈니스 일정에 맞춰서 제품을 만들어 줄 수 있다.

혹자는 현실적으로 불가능한 일이라고 한다. 항상 일정이 너무 촉박하여 경영자는 절대로 개발자들이 제시한 일정을 따를 수 없다고 한다. 그래서 무모하게 짧은 일정을 제시한다고 한다. 경영자가 그렇게 하는 이유는 무지 때문이기도 하고 개발자들이 합리적으로 일정으 제시하지 못하기 때문이기도 하다. 가끔은 경영자와 개발자의 신뢰가 무너진 경우도 있다. 그렇게 해서는 평생을 가도 무모한 프로젝트만 진행하게 된다.

그 부작용은 개발자 사기저하, 비즈니스 일정이 꼬이고, 제품의 품질이 떨어진다.개발자들은 매일 야근에 고생을 하지만 일정 지연에 자주 내몰린다.

여기서 핵심은 경영자들의 이해이다. 그리고 개발자들도 제대로 된 분석, 설계 능력을 갖춰서 합리적인 개발 계획을 제시할 수 있어야 한다. 한번에 그렇게 될 수는 없지만, 경영자와의 신뢰 하에서 개발자에게 꾸준히 투자를 해줘야 개발자들도 그렇게 할 수 있는 역량이 올라가게 된다. 

image by A.K. Photography

많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.

문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.

실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.

스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.

그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.

교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다. 

물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.

보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다. 

소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.

image by sirwiseowl

우리나라 소프트웨어 회사들의 가장 큰 취약점 하나만 꼽으라고 하면 나는 개발문화를 꼽겠다. 문화란 오랫동안 습득된 구성원들의 공통된 행동 양식이기 때문에 개인이 전체의 문화를 짧은 시간에 바꾸기가 매우 어렵다. 특히 조직이 크면 클수록 문화를 바꾸는데 엄청난 시간과 비용이 필요하다.

하지만 개발문화의 개선 없이는 소프트웨어 개발 역량을 얘기하기가 어렵다. 소프트웨어 개발은 너무 복잡하기 때문에 획일화된 프로세스대로 따라 한다고 잘 할 수 없다. 하나 하나는 완벽해 보이지 않는 문화적인 활동들이 모여서 개발을 효과적으로 이끄는 것이다. 

효과적인 개발문화의 필요성을 먼저 깨달은 많은 개발자들도 조직 내에서 접목을 시도하다가 쓴맛을 봐온 것이 사실이다. 그만큼 집단을 바꾸는 것은 쉬운 일이 아니다.

조직 문화의 방향을 이끄는 가장 큰 힘은 바로 경영자의 마인드다. 누구나 공감하는 당연한 개발 문화도 최고 경영자가 몸으로 이해하지 못했다면 실패할 가능성이 99%이다. 지식으로 알고 있는 것은 언제든지 몸에 베인 행동 양식에 밀리게 되어 있다.

그래서 새로 시작하는 스타트업은 좋은 개발문화 사례를 만들 수 있는 최고의 장소가 된다. 대부분의 스타트업은 기술 주도적이고 소수의 인원으로 출발한다. 이들이 개발문화를 제대로 이해하고 필요성을 알고 있다면 좋은 개발문화를 가진 회사가 탄생할 가능성이 매우 높다.

실제로 실리콘벨리의 수많은 성공한 스타트업들은 기존의 기본적인 개발문화 위에 자신들만의 독특한 문화를 계속 더해감으로써 소프트웨어 업계 전체의 문화를 리드하고 있다.

그럼 스타트업이 가져야 할 개발문화가 어떤 것이 있는지 알아보기 전에 자가 진단을 먼저 한번 해보자. 아래 나열할 개발문화에 대한 의견을 어떻게 생각하는가?

1. 좋은 개발 문화에서는 개발이 더 느리지만 옳기 때문에 따라야 한다.

2. 좋은 개발 문화는 일부 개발을 느리게 하는 요소가 있지만 장기적으로 필요하므로 따라야 한다.

3. 좋은 개발 문화는 당장 현재의 프로젝트부터 빠르게 개발하기 위해서 필요하다. 장기적으로는 말할 나위도 없다.

일반적으로 정답은 3번이지만 이에 대해서 의문을 가지 있다면 좋은 개발 문화를 경험해보지 못했거나 비효율적으로 적용했었을 수 있다. 또한 회사마다 환경이 다르므로 가장 효율적인 문화도 조금씩 다르다. 가장 알맞은 문화를 만들고 발전시켜 나가는 것도 스스로 해야 할 일이다.

그럼 대부분의 스타트업이 가져야 할 공통적인 개발 문화는 어떤 것이 있을까? 여러가지가 있을 수 있지만 대표적인 것을 뽑아보자

첫째, 문서화이다.

소프트웨어 개발에 있어서 문서화의 필요성을 여기서 설명할 필요는 없을 것이다. 많은 회사들이 형식에 얽매인 과도한 문서화 시도로 문서화 정착에 실패를 해왔다면 스타트업에서는 형식적인 구속이 적기 때문에 가볍게 시작할 수 있다. 핵심 개발자들이 이를 주도할 수 있고 불필요한 문서는 만들지 않을 수 있다. 문서는 꼭 필요한 내용을 가장 적게 적는 것이 가장 좋고 형식은 크게 중요하지 않다. 간단한 프로토타입을 개발하기 위해서는 10분 정도 투자를 해서 한 페이지의 스펙을 적을 수 있다. 메모장에 정리를 해도 된다. 이런 개념은 기존기업에도 적용 되지만 큰 회사에서 이렇게 적용하기는 쉽지 않다. 문서를 잘 적고 스펙을 제대로 작성하는 것은 쉬운 일은 아니지만 시작이 반이라고 시작을 해야 역량이 꾸준히 증가한다.

둘째, 투명한 개발이다.

소프트웨어 개발에서 있어서 모든 정보를 투명하게 오픈하는 것이 좋다는 것은 이미 알려져 있다. 하지만 기존의 회사에서는 과도한 보안에 대한 우려 또는 기존 관습 때문에 정보 공개를 꺼려한다. 막상 투명하게 개발을 해본 사람들은 숨기려고 했던 일들이 별거 아니라는 것을 알게 되고, 공개를 함으로써 얻는 이득이 훨씬 크다는 것을 금방 알게 된다. 스타트업은 소수의 핵심 인력들이 시작하기 때문에 투명한 개발 문화를 갖추기 아주 좋은 환경이다. 이슈관리시스템을 제대로 활용하여 정보를 모두 공개하면서 개발하는 방법이 정착된다면 회사가 커져도 투명한 개발이 계속 유지될 것이다.

셋째, 수평적인 조직과 자율적인 관리다.

스타트업이야 말로 상명하복 관계를 벗어나 자율적으로 일할 수 있는 아주 좋은 기회다. 몇사람의 역할을 해야 할 스타트업의 개발자들이 시키는 일만 해서는 효율적으로 일하기 어렵다. 스스로 해야 할 일을 능동적으로 찾아서 자율적으로 해나가는 방법이 훨씬 효율적이다. 일부 잘못된 방향으로 일이 진행되는 경우도 있을 수 있지만, 투명한 개발을 하기 때문에 언제든지 누가 무슨 일을 하는지 다 감지가 되어서 잘못된 일을 계속 하는 것을 방지하는 장치가 다 되어 있다. 여러 문화가 잘 어우러져야 각각의 문화가 힘을 발휘한다.

넷째, 창의력과 오픈 마인드다.

많은 스타트업은 처음에 시작한 아이디어로 성공하지 않았다. 대부분은 초기 전략의 일부분 또는 전체가 바뀌었다. 스타트업에서는 개발자를 비롯하여 모든 직원들에게 창의력을 더 요구하게 되고 고정관념 없이 참신한 아이디어를 받아들일 수 있는 자세가 필요하다. 이는 좋은 문화를 넘어서 스타트업의 생존에 필요한 요소이다.

다섯째, 아끼는 문화다.

무엇을 아끼느냐 하면 바로 '돈'이다. 스타트업은 어느 정도 성공하기 전까지는 자금이 풍족하지 않기 마련이고 회사 돈을 자신의 돈처럼 아끼는 문화가 필요하다. 대부분의 스타트업은 초기 멤버와 주식을 공유하기 때문에 회사에 주인의식을 가지는 것이 그렇게 어렵지는 않다. 하지만 초기 투자에 성공하면 이런 문화를 잃어 버리는 경우가 많다. 좋은 사무실과 불필요한 비용 지출에 무뎌지기도 한다. 초심이 변하지 말아야 한다.

사실 스타트업의 3년 생존률은 5% 미만으로 높지는 않다. 마케팅이나 전략 또는 기술에서 실패할 수도 있다. 하지만 이런 좋은 개발 문화와 역량은 남는 것이고 재도전 시 가장 큰 무기가 될 수 있을 것이다. 또한 많은 스타트업이 생기고 이런 문화가 확산된다면 전체 소프트웨어 업계도 변화가 있을 것으로 생각한다.

이 글은 Tech it에 기고한 글입니다.

소프트웨어를 체계적으로 개발해 보겠다고 맘을 먹으면 가장 먼저 하는 것이 "문서작성"이다.

문서의 개수와 종류와 상관없이 문서작성 시 가장 중요한 것은 무엇일까?

사람마다 다르게 생각하겠지만, 내가 생각하기에 가장 중요한 것은 "눈높이 맞추기"이다.

문서의 "눈높이 맞추기"란 의외로 매우 어렵다.

첫째, 문서의 독자가 누구인지 파악해야 한다.

소프트웨어를 개발할 때 만드는 대표적인 문서들은 MRD(기획), SRS(분석), SDS(설계) 를 들 수 있다.

각 문서마다 독자가 다르다. 심지어는 하나의 문서에서도 각 장마다 독자가 다르기 때문에 각 문서를 읽을 독자의 눈높이 맞추는 것이 쉽지는 않다.

둘째, 독자를 파악했다면 해당 독자에게 문서를 통해서 전달해야 할 내용과 독자가 프로젝트에서의 역할이 무엇인지 생각해야 한다. 그렇게 해서 독자에게 필요한 내용을 전달해야 한다. 

더 많은 내용 또는 부족한 내용을 전달할 경우 문서로서의 가치가 떨어진다.

셋째, 독자의 눈높이에 맞는 용어를 사용해야 한다. 경영자가 읽어야 문서라면 경영자가 이해하는 용어로 적어야 한다. 영업부서가 봐야 하는 부분이라면 영업이 이해할 수 없는 전문용어를 써서는 안된다.

더불어 문서를 작성할 때 문서의 서두에 문서의 독자와 읽는 방법에 대해서 설명을 해주는 것이 좋다. 특히 각 장마다 독자와 읽는 방법을 설명해주면 문서를 읽는 사람은 그 안내에서 따라서 가장 효율적으로 문서를 읽을 수 있다.

"옳은 문서"가 좋은 것이 아니고 "읽기 좋은 문서"가 좋은 것이다. 맞는 내용이라고 하더라도 어렵게 작성했거나, 너무 많이 작성했다면 비효율적인 문서 작성을 하고 있는 것이다.

"읽기 좋은 문서"를 작성하기 위한 노력은 꾸준히 계속되어야 한다. 한두해 걸릴 일이 아니기 때문이다.

Image by evinella

소프트웨어 회사에서 꼭 필요한 개발문화 한가지를 꼽으라면 주저없이 "공유" 문화를 꼽는다.

"공유"의 문화야 말로 소프트웨어 회사를 가장 효율적으로 만들고 프로젝트를 효과적으로 진행할 수 있도록 하며 개발자들의 역량을 향상시키는 결정적인 문화이다.

"공유"의 문화가 잘 정착된 회사에서는 자연스럽게 문서화를 하며 시스템에 기록을 하고 소스코드에 주석을 남기고 필요한 리뷰를 진행한다.

하지만 공유의 문화가 부족한 회사에서는 자발적으로 공유의 활동이 잘 이루어지지 않는다.

물론 공유의 문화가 부족한 곳에서도 선도적인 개발자들이 공유의 문화를 정착하기 위해서 노력하고 있지만 역부족인 경우가 많다.

그 이유는 다른 개발자들의 협조를 이끌어내기가 어렵기 때문이다.

모든 사람이 다 공유를 하고 있는 상황이 아니라면 공유하는 사람만 손해를 보게 된다.

공유를 위해서 시간과 노력을 조금이라도 더 들였다. 하지만 공유를 하지 않는 사람들은 다른 사람이 공유한 결실은 얻으면서 자신의 것은 공유를 하지 않는다.

바빠서 그러기도 하고,

아직 습관이 안되서 그렇기도 하고,

귀찮아서 그러기도 하고,

공유하면 손해라고 생각하는 경우도 있다.

공유의 문화가 팽배한 회사는 서로 공유하는 것이 서로 이익이라고 몸으로 느끼고 있어서 자발적으로 자연스럽게 공유를 한다.

그럼 어떻게 공유의 문화를 정착할 수 있을까?

공유의 문화가 정착되기 전에는 회사의 규칙으로 강제화 해야 한다.

물론 너무 심하게 강제를 하면 반발하여 실패하기 쉽다.

너무 목표를 높게 잡아도 대부분 실패한다.

장기적인 계획을 하지고 단계적으로 시행해 나가야 한다.

첫번째가 이슈(버그)관리시스템을 적극적으로 사용하는 것이다. 모든 이슈와 버그는 시스템으로 모으고 최대한 메일과 전화를 줄이는 것이 그 시작이다.

두번째는 스펙을 작성하는 것이다. 스펙을 처음부터 제대로 쓰기는 어렵지만, 일단 프로젝트를 시작할 때 스펙문서를 작성하는 것을 규칙으로 두고 써보는 것이 좋다. 차츰 나아질 것이다.

세번쨰는 스펙을 리뷰하는 것이다. 스펙을 적고 리뷰를 해보면 그동안 얼마나 서로 모르고 프로젝트를 했다는 것이 조금씩 드러날 것이다.

이렇게 단계적으로 공유를 위한 제도를 강제로 적용하면 어느새 공유가 당연한 것으로 받아들여지는 때가 올것이다.

image by furiousgeorge81

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다.

보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속 하기를 원한다. 따라서 수많은 고정관념을 가지고 변화를 거부한다. 이를 극복하지 않으면 변화는 성공할 수 없다.

물론 제대로된 변화를 시도해야 한다는 전제조건이 필요하다. 어설픈 변화의 시도로 직원들만 고생하고 더 비효율적으로 변하는 변화도 수두록하다. 이러한 시도들이 쌓여 가면서 고정관념이 쌓인 것도 사실이다.

이러한 고정관념에는 어떠한 것들이 있는지 알아보고 극복해보도록 하자.

1. 전에 안해본줄 알아?

대부분은 과거의 잘못된 경험으로 인해 누적된 불신감이 변화에 거부감을 유발한다. 어설프게 시도한 과거의 경험은 잊어버리고 제대로 다시 해야 한다.

2. 어디 얼마나 잘되나 보자

회사에서 시도하는 변화를 무조건적으로 냉소적인 비판을 하는 경향이 있는 사람들이 있다. 이런 경우 강제로 따라오게 하던가 강제로도 안되는 직원들은 내보내는 것이 좋다.

3. 나는 바쁘니가 잘되면 따라갈께

누구나 나는 바빠서 변화할 시간이 없다고 하는데 그렇게 변화를 미루면 가치없는 일을 하는데 계속 더 바빠질 뿐이다. 적절한 시기에 결단을 해서 변화를 모색하지 않으면 안된다. 

4. 어차피 하가다 안되서 원래대로 돌아갈텐데

과거에 변화의 시도들이 여러차례 실패하여 원래대로 회귀했던 경험이 쌓여서 새로운 변화의 시도도 불신하며 따라가는 척만 하는 경향들이 있다. 직원들의 적극적인 참여 없이는 실패하기 쉽다. 무조건적인 외형적 변화보다 먼저 인식의 변화를 시키는 것이 필요하다.

5. 우리 회사가 하는일이 어련할려구

그동안 회사가 직원들에 신뢰를 주지 못하여 직원들의 믿음을 갖지 못하는 경우가 많다. 회사는 직원들의 신뢰에 대해서 소홀히 생각하는 경우가 많은데 이런 경우 변화의 흐름에 직원들을 동참시키기가 어려워진다.

6. 구관이 명관이다.

자신이 오랫동안 해왔던 방법을 무조건적으로 맹신하는 것이다. 그 방법이 지금까지 성공하는데 큰 역할을 했어도 앞으로 회사가 더욱 성장하는데는 큰 걸림돌이 되는 것이 일반적이다. 회사에서는 무조건적으로 위기 의식을 심어주기 보다는 변화가 필요한 실상을 직원들에게 제대로 이해 시키고 변화에 동참시키는 것이 필요하다.

7. 문서로 보고하라니까

주먹구구식으로 오랫동안 일을 하다가 체계적으로 바꾸려고 하면 무조건 모든 것은 문서로 작성하고 문서로 처리를 하려고 한다. 문서는 꼭 필요하지만 필요한 만큼보다 더 만들면 무조건 손해이다. 가장 좋은 것은 문서를 꼭 필요한 만큼만 최소로 만드는 것이고 회사의 규모에 맞게 가능하면 적게 만들어야 한다. 문조건 문서로 보고하라는 문서 지상주의는 오히려 변화를 방해한다.

8. 프로세스대로 해야지

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다.

Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을 한 적도 있지만 최근 동향에 대해서 여러가지 정보를 들을 수 있었다.

시간이 많이 흐르고 새로운 테크놀로지는 많이 나왔지만 소프트웨어를 개발하는 방식은 바뀌 것이 거의 없었다.

그 핵심을 요약해보면 다음과 같다.

• 소프트웨어를 개발할 때 가장 중요한 것은 스펙이다.
• 스펙을 작성하는데 가장 노력을 많이 들이고 고급엔지니어가 투입된다.
• 전체 개발 기간 중에서 스펙을 작성하는 분석 기간이 가장 길다.
• 스펙을 작성할 때 마케팅이 아주 중요하게 참여를 하고 모든 관련자와 스펙을 여러차례 철처하게 리뷰한다.
• 스펙이 완성되면 스펙에 모든 관련자가 사인을 한다.
• 스펙이 바뀌는 경우는 매우 드물다. 
• 예외적인 케이스에서만 스펙이 변경되고 스펙 변경시에는 프로세스를 따른다.
• 스펙을 바꾸면 개발자들이 어려워하고 프로젝트 기간이 늘어나기 때문에 다들 스펙을 바꾸면 안된다는 것을 잘 안다.
• Agile을 적용할 때도 스펙을 잘 작성한다. 대신 주기를 줄이고 빠르게 개발한다.
• 여러 사람이 개발을 나눠서 하기 위해서는 스펙을 잘 작성하고 컴포넌트를 잘 나눈다.

물론 한 개인의 의견이 실리콘밸린 전체 상황을 대변하는 것은 아니지만 다른 회사들도 크게 다르지 않을 것이다. 이러한 근본 원리는 10년전이나 크게 다르지 않다. Agile등의 새로운 기법들이 나와도 회사에 알맞게 적용을 할 뿐이고 근본은 바뀐 것이 하나도 없다.

한국 기업과도 일을 한 적이 있는데 대단한 불만을 토로하면서 다시는 한국 기업과는 일을 하지 않겠다고 한다.

한국 기업과 일을 할 때는 이러한 일들이 일어 났다고 한다.

• 요구사항을 문서로 달라고 하는데 주지 않고 몇마디로 설명만 해준다.
• 스펙을 작성해서 검토해 달라고 하는데 검토를 안해준다.
• 스펙을 완성해서 사인을 하라고 하는데 사인을 안한다.
• 스펙대로 다 만들었는데 UI를 보고 바꿔달라고 한다.
• 계약을 제대로 하지도 않는다.

대부분의 우리나라 소프트웨어 업체들의 부족한 부분도 10년 전이나 지금이나 크게 바뀌지 않았다. 분석 능력 등을 비롯한 기초역량이 부족한 것이다. 물론 기반과 경험이 부족한 상태에서 기초역량을 갖추는 것이 쉬운 일은 아니라는 것은 잘 알고 있다. 하지만 그 상태로 계속 발전해서 Global 경쟁에서 살아 남을 수 없다는 것도 알아야 한다.

우리를 현혹하는 신기한 기법보다 근본에 충실할 때다.

image by Calmsea