Agile이 우리 회사 문제를 해결해 줄 수 있을까?

소프트웨어 공학이라는 용어는 사용하기가 상당히 꺼려진다. 소프트웨어 공학이라는 용어를 듣는 사람들이 많은 오해를 하기 때문이다. 일단 듣는 순간 거부감을 가지는 사람들도 상당히 많다.

소프트웨어 공학이 무엇인지 사람마다 서로 다르게 생각하고 있다. 그럼 스스로 소프트웨어 공학을 어떻게 생각하고 있는지 골라보자. 소프트웨어 공학이란?

1. 소프트웨어를 체계적으로 개발하기 위한 방법이다.

2. 고객이 만족하는 소프트웨어를 개발하는 방법이다.

3. 소프트웨어를 여러 사람이 효과적으로 개발하기 위한 방법이다.

4. 유지보수가 용이한 소프트웨어를 개발하기 위한 방법이다.

5. 프로세스를 따라서 소프트웨어를 개발하기 위한 방법이다.

6. 품질이 좋은 소프트웨어를 개발하기 위한 방법이다.

7. 성능이 좋은 소프트웨어를 개발하기 위한 방법이다.

8. 야근을 하지 않고 소프트웨어를 개발하기 위한 방법이다.

9. 소프트웨어를 빠르게 개발하기 위한 방법이다.

소프트웨어 공학을 정확하게 이해하고 있지 못하다면 이중에서 하나를 고르는 것은 여간 헷갈리는 것이 아니다. 정답은 9번이다. 

소프트웨어 공학은 소프트웨어를 가장 적은 비용으로 가장 빠르게 개발하기 위한 방법을 모아 놓은 것이다. 

어디서 많이 듣던 얘기다. 소프트웨어를 빠르게 개발하자고 하는 것은 Agile이 아닌가?

옛날에는 소프트웨어를 늦게 개발했는데 Agile이라는 것이 나와서 그때부터 빨리 개발해야 하겠구나 해서 빨리 개발하기 시작한 것이 아니다. Agile 이전 몇십년 전부터 소프트웨어를 빨리 개발하는 방법에 집중 되어 왔었다. 즉 Agile이라는 용어가 나오기 전부터 Agile하게 개발을 해왔는데 용어를 만들고 그럴듯하게 포장을 하고 상품화를 한 측면이 있다. Agile에서 사용하는 수많은 기법들도 대부분 그 훨씬 이전부터 해오던 것이다. 

유사한 것 중에 UML이 있다. UML 탄생 이전에도 UML의 내용은 거의 다 있었지만 UML은 이들을 모으고 종합해서 상품화를 한 것이다. UML이 기여한 것은 툴을 제공하고 기법의 표준을 정리했지만, 많은 개발자들이 설계는 UML로 하는 것이라는 착각을 일으키게 해서 오히려 소프트웨어 업계를 혼란에 빠뜨린 경향이 있다.

소프트웨어 공학에서는 특정 기법이나 방법론을 써야 한다고 강요하고 있지 않다. 기법은 회사나 프로젝트의 성격에 알맞은 것을 취사선택 하면 된다.

가끔은 Waterfall과 비교를 하면서 Waterfall의 비효율성을 강조하는데 실제 Waterfall을 적용하여 개발하는 곳은 하나의 없다. 개발할 수도 없는데 비교를 하는 것이다. Waterfall은 99.9% 기업에서 적용은 못하지만 여러 방법론 또는 라이프사이클의 모델이 되는 것이다. 비교 대상이 아니다. 전세계적으로도 Waterfall대로 개발하는 프로젝트는 0.001%도 되지 않고 그렇게 할 필요도 없고 그럴 역량도 대부분 없다.

소프트웨어 개발을 잘하기 위해서 즉, 빠르게 개발하기 위해서 방법론만 적용한다고 되는 것은 아니다. 방법론은 소프트웨어 공학의 일부분일 뿐이다. 소프트웨어를 빨리 개발하기 위한 소프트웨어 공학에서 다루는 분야는 방법론 이외에도 분석, 설계, 구현, 테스트, 유지보수, 형상관리, 프로세스, 툴, 품질 등 많다.

특히 분석 즉, “스펙 작성”은 기법 좀 배워서 잘 할 수 있을 것으로 생각하면 오산이다. 수많은 소프트웨어 전문가가 스펙이 소프트웨어 개발에서 가장 어렵고 중요하다고 하는데 괜히 하는 소리가 아니다.

소프트웨어 개발에 문제를 깨닫고 Agile 등 새로운 것에 희망을 걸고 시도를 해본 많은 사람들이 있을 것이다. 그 성과는 어땠는가? Agile 등의 세미나를 많이 쫓아 다니면서 들어서 정말 회사에서 소프트웨어 개발 문제가 사라졌고 소프트웨어가 빨리 개발되고 있는지 스스로에게 물어보자. 그렇지 않다면 그 동안 Silver bullet을 쫓아다닌 것이다.

Silver bullet이란 늑대인간을 한번에 확실하게 죽일 수 있는 전설로 내려오는 탄환이다. 소프트웨어도 많은 사람들이 한방에 모든 문제를 해결해 줄 수 있는 전설의 탄환이 있을 것으로 생각해왔다.

개발 경력이 몇 년 안된 개발자는 잘 모르겠지만 경력이 20년이 넘은 개발자들은 Silver bullet의 역사를 잘 알 것이다. 20여 년 전에는 OOP가 소프트웨어 문제를 모두 해결해 줄 수 있을 줄 알았는데 그렇지 못했다. 그 뒤 CBD, XP가 지금은 Agile이 우리를 유혹하고 있다. 

확실한 것은 이 모두가 전혀 잘못된 방법이 아니라는 것이다. 단지 너무 맹목적으로 믿을 경우 문제가 되는 것이다.

과거에 ZDNet Korea에 기고한 "소프트웨어 개발방법론의 함정"이란 글도 참고하기 바란다.

우리나라에서는 특히나 Silver bullet 열풍이 더 거셌다. 이미 소프트웨어 공학과 개발문화가 정착된 소프트웨어 선진국에서는 필요한 것들을 쉽게 적당히 접목했는데 항상 목마른 우리나라 개발자들은 새로운 것이 나오면 그냥 다 해결 해 줄 것 같이 매달려오기를 벌써 20년이 넘었다.

앞으로 10년 후에도 또 새로운 방법론이나 기법을 가지고 이러고 있어서는 안된다. 기법이나 방법론이 잘못된 것은 하나도 없다. 적용하는 우리의 자세가 중요하다.

소프트웨어 공학은 배울 수가 없다. 경험으로 익히는 것이다. 그런데 방법론 전문가에게 배울 수 있을까? 배우는 것이 의미는 있다. 하지만 얻는 것은 크지 않다. 1%을 배운다면 실제 프로젝트에 적용해서 오랜 경험과 합쳐져야 100%가 된다. 방법론 전문가는 1%는 가르쳐 줄 수 있지만 100%는 본인은 실전 경험이 없거나 적기 때문에 알지도 못한다. 물론 그 1%가 없으면 방향을 못잡고 100%에 영원히 이르지 못할 수가 있다.

방법론이나 기법 전문가가 소프트웨어 전문가가 아니고 우리 개발자가 소프트웨어 전문가이다. 방법론 전문가는 결코 소프트웨어 전문가가 될 수 없다. 대부분은 실전 경험이 부족하기도 하고 실전 프로젝트를 할 시간도 없기 때문이다. 피아노는 치는 것은 초보인데 이론과 방법은 전문가인 사람이 피아니스트를 교육 시키거나 세미나에서 가르치는 격이다. 모르던 이론과 방법을 한번 듣는 정도의 의미가 있지 그 이상을 가르쳐줄 수 있다고 생각하면 착각이다. 또한 배운 그대로 따라 해야 하는 것도 아니다. 원리를 깨닫고 스스로 알맞게 적용해야 한다. 방법론 전문가는 방향과 기법을 알려주는 역할만 할 수 있을 뿐이다.

여러분들보다 소프트웨어 개발에 대해서 잘 모르는 방법론 전문가에게 해답을 구하다가는 "주화입마"를 입을 수 있다. 원리보다 이론이나 기법을 쫓다가 마를 입을 수 있다.

그럼 어떻게 해야 할까?

Silver bullet을 쫓지 말고 근본 원리를 깨닫기 위해서 노력해야 한다. 기법은 익히되 기법이 해결해 줄 것으로 너무 큰 기대를 하지 말아야 한다. 인식을 바꾸고 개발 문화를 정착 시키는데 더 큰 노력을 기울여야 한다. 방법론 전문가에게는 그런 관점으로 방법론을 배우고 소프트웨어 개발은 소프트웨어 전문가에게 배우는 것이다. 보통은 선배 개발자들이 소프트웨어 전문가이다. 하지만 우리나라에서는 회사 내부에 소프트웨어 전문가가 부족하니 외부에서 자꾸 찾으려는 경향이 있는데 방법론 전문가를 소프트웨어 전문가로 착각해서 너무 큰 것을 기대해서는 안 되는 것이다. 진짜 소프트웨어 전문가를 찾던지, 소프트웨어 전문가가 많은 회사로 옮기던지, 스스로 해나가는 수 밖에 없다.

바람직한 스타트업 SW 개발문화의 조건

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

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

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

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

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

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

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

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

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

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

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

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

첫째, 문서화이다.

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

둘째, 투명한 개발이다.

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

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

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

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

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

다섯째, 아끼는 문화다.

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

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

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

만남

나는 책과 블로그을 통해서 수많은 독자를 만난다.

그 중의 몇명은 Email이나 Facebook을 통해 교류를 하고 소수는 Offline에 만난다.

어제 블로그의 독자 한명을 만나서 소프트웨어 개발에 대한 즐거운 대화를 나누었다.

Offline에서는 Online이나 책을 통해서 전달할 수 없는 많은 것을 공유할 수 있다. 일반론이 아니고 현재 닥친 상황에 대해서 얘기를 하기 때문에 좀더 도움이 되는 대화가 오간다.

독자를 만나면 내가 도움을 주기도 하지만 나도 많이 배운다. 수많은 도메인 지식에 대해서 배우고 각 회사들의 사례를 익힌다.

내가 책을 쓰고 블로그를 꾸준히 운영하는 주된 목적은 독자들과 소프트웨어 개발에 대한 경험을 공유하여 좀더 좋은 개발환경을 만들어 나가는 것이다.

물론, 좋은 개발환경에서 뛰어난 선배들이 많이 있는 회사에서 일하는 것이 가장 좋은 방법이다. 실리콘밸리에는 이런 회사가 많지만 우리나라에는 솔직히 말해서 찾기가 그렇게 쉽지 않다. 그렇 좋은 환경에서는 2~3년만 일해도 개발 문화, 프로세스 등등 왠만한 것은 다 습득 가능하다. 실리콘밸리의 모든 회사가 다 좋은 것은 아니지만 상대적으로 좋은 회사가 더 많다.

우리나라 대부분의 개발자들은 그렇지 못한 환경에 있기 때문에 항상 갈증에 시달린다. 그렇다고 학원에서 배울 수 있는 내용도 아니고 세미나를 통해서도 해결이 되지 않는 것이다. 경험을 통해서 익히는 것인데 대부분은 시행착오를 겪으면서 아주 느리게 익히거나 포기를 한다.

독자와의 교류를 통해서 이러한 갈증을 조금이라도 해소할 수 있으면 좋겠다.

고객이 전문가

우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다.

예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다.

그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 정보를 주지 않아 나중에 요구사항이 많이 바뀌기가 일쑤이고 그로 인해서 프로젝트에서 손해도 많이 난다.

비단 공공분야만이 아니다. 소프트웨어 선진국에서는 기업이 소프트웨어 외주를 줄 때 해당 기업에서 충분히 분석, 설계 역량이 있고 스펙을 제대로 작성해서 외주를 주곤한다. 즉, 직접 개발할 역량도 충분히 있는데 비용이나 시간 상 외주를 주는 것이다.

그런데 우리나라에서 외주를 주는 형태를 보면 고객이 잘 모르기 때문에 대충 외주를 주고 개발 업체가 이거저거 정말 알아서 다 해줘야 할 때가 많다. 그러다 보니 계약도 불분명하고 다툼도 많다. 법정까지 가는 다툼도 많이 발생하지만 엉성한 계약서를 가지고 누구의 자잘못인지 따지기도 어렵다.

개발업체에서 스펙을 제대로 작성하기 위해서 고객 인터뷰를 하고 요구사항 분석을 해도 협조가 잘 되지 않는다. 정확한 인터뷰 대상 선정도 쉽지 않다. 업체에서 나름대로 최대한 노력해서 스펙을 작성해도 고객이 스펙을 충분히 검토해서 확인을 해주는 일도 드물다. 

일단 고객이 스펙을 충분히 잘 검토할 수 있는 실력이 부족한 경우가 많다. 그래서 스펙을 봐도 잘 모르기 때문에 잘 보지 않으려고 한다. 또, 개발해 놓으면 언제든지 바꿔달라고 하면 되는 것으로 착각을 해서 개발 전에 스펙을 잘 보지 않아도 된다고 생각한다. 심지어는 스펙을 잘 검토해서 확인을 해주면 나중에 바꿔달라고 못할지도 모른다는 생각도 한다.

이런 비전문가적인 고객들은 개발업체를 엄청 괴롭히지만 프로젝트에도 긍정적이지 않다. 이런 환경에서 좋은 아키텍처의 소프트웨어가 나오기 어렵다. 개발업체도 제대로 개발하고 싶겠지만 그냥 어떻게 검수만 나도 된다는 식으로 개발하기 쉽다. 서로에게 모두 손해가 되는 것이다.

외주, 즉 아웃소싱이 제대로 되려면 고객이 전문가가 되어야 하는 것이다.

회의록 작성 문화를 보면...

회의를 하면서 회의록을 작성하는 문화를 가지고 있는 회사들이 매우 많다. 회의록을 아예 작성하지 않는 회사도 있고, 작성을 해도 전혀 뒷처리가 안되는 회사도 있다.

회의는 회사의 가장 중요한 업무 중 하나이며 중요한 결정을 하고 부서간의 의견을 조정하고 업무를 나누고 서로 협업을 하기 위한 수단이다. 그런데 회의는 회의대로 진행하고 후속 조치를 제대로 하지 않는다면 반쪽 짜리 회의가 된다. 하지만 많은 회사들이 아직 회의 문화와 회의록 작성 문화가 아직 부족한 것이 현실이다.

아래 회의록에 관련된 질문 중에 우리 회사는 어디쯤 와 있을까? 

• 회의록은 따로 작성하지 않는다. 그냥 알아서 처리한다.
• 회의 참석자 중에 우연히 꼼꼼한 사람이 있으면 작성하기도 한다. 하지만 대대분 작성하지 않는다.
• 회의 시작전에 회의록 작성자를 꼭 지정하여 회의록을 작성한다.
• 회의록을 녹취록처럼 작성한다. 
• 회의록에는 회의에서 논의된 주요한 내용을 기록하고 결정사항, Action Item을 별도로 정리한다.
• 회의록에 결정 사항이 있기는 하지만 언제까지 누가 해야 하는지 적지는 않는다.
• Action item은 누가 언제까지 해야하는지 구체적으로 명시한다.
• 회의가 끝난 후 결정사항과 Action item을 참석자들에게 다시 한번 상기시킨다.
• 회의록은 회의 종류 후 바로 보내지 않고 별도로 정리해서 다음날 또는 그후에 보낸다.
• 회의록은 회의 참석자들에게만 Email로 배포한다.
• 회의록을 회의 참석자 외에도 관련자 모두에게 배포한다.
• 회의록의 Action item은 별로도 챙기지 않는다. 담당자가 알아서 진행한다.
• 회의록은 시스템에 저장이 되어서 철저하게 추적하고 챙긴다.

질문은 이것 저것 섞여 있지만 그 속에 어느 정도 힌트가 있다.

회의록에는 결정사항, Action item이 담당자와 due date까지 포함해서 적혀야 하며 회의가 끝나자마자 관련자 모두에게 배포를 해야하며 Action item은 잘 추적이 되어야 한다.

이렇게 하기 위해서 그냥 Email로 배포를 하는 것도 좋은 방법이지만 이슈관리시스템을 쓰는 것도 좋다.

일단 이슈관리시스템에 등록이 되면 보통 전직원에게 공유가 되고 Action item은 하나씩 sub-task나 이슈의 형태로 등록을 해 놓으면 철저하게 추적이되고 누락되는 일이 없다. 대충 처리하지 않고 뭉개고 싶은 일들도 이슈관리시스템에 등록된 이상 무시할 수 없는 일이 된다. 이슈관리시스템을 이용하는 것은 회의록을 잘 활용하기 위한 하나의 Tip이고 중요한 것은 회의와 회의록 문화이다.

이는 다른 개발 문화들보다 좀더 쉽게 정착할 수 있는 일이니 아직 부족하다고 생각하면 시도를 해보자.

Technical Career Path를 보장하는 방법

그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

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

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.