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