2012년 9월 15일 토요일

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

댓글 6개:

  1. 위 문제에서 여러 개 골라도 되는 것으로 생각하고, 쭉 읽으면서 골랐는데, 9개를 다 골라 버렸습니다... 글을 읽고 생각해 보니 1~8 다 조금씩 답과 관련이 있지만, 그래도 제일 답은 9번이라고 생각합니다. 9번이 되면, 1~8은 거의 다 어느 정도 해결이 될테니까요.

    답글삭제
  2. 안녕하세요. 주의사신님
    1~8번은 9번의 효과이기도 하고 프로젝트의 성격에 따라서 목표가 아닐 수도 있습니다. ^^
    Silver bullet에 현혹되지 말자는, 특히 Agile을 맹신하지 말자는 것이 요지입니다. :)

    답글삭제
  3. 학문적인 연구가 퍼포먼스를 위한 것으로 전락해 버렸군요. ^^
    정답 자체를 9번이라고 못박아 놓으셨는데, 테스팅 공학은 말씀하신 요지의 정 반대 이야기들 뿐이네요.
    (소프트웨어 공학엔 테스팅도 포함이 되는 것이 맞지요?)
    소프트웨어 공학이라기 보다 개발 프로세스, 또는 방법론, 툴, 이라고 하는 것이 어울릴 것 같습니다.
    그러면 답이 9번이고, 글의 요지와 일치하는 것 같아요.

    답글삭제
  4. 안녕하세요. 엄준일님

    좋은 의견 감사합니다. 소프트웨어공학에서 다루는 분야는 글에서도 언급했듯이 분석, 설계, 구현, 테스트, 유지보수, 형상관리, 프로세스, 툴, 품질, 방법론 등 여러가지가 있습니다. 1~8번이 틀린 얘기가 아니고 "목적"에 포커스를 해서 9번이라는 의미입니다. ^^ 좀더 깊이 생각해보면 궁극의 목적은 가장 빠르게 가장 적은 비용으로 개발하는 것입니다. :) 나머지는 거의 맞지만 요구사항에 따라서 목표가 아닐 수도 있습니다. 다양한 의견 감사합니다.

    답글삭제
  5. 넓은 의미로 보자면 소프트웨어를 만드는데 공학적으로 접근하는 것이면 모두 소프트웨어 공학이 아닐까 합니다. 기계공학에도 위와 똑같은 잣대를 들이밀 수 있겠는데요, 1~9 에서 `소프트웨어`를 `기계`로 바꿔보면, 모든 항목이 기계공학에 포함되는 것을 알 수 있습니다. 물론 기계공학에서도 빨리 개발하는 것이 가장 중요한 목적이기는 합니다.

    답글삭제
  6. 저도 Agile 방법론이 silver bullet이 될 수 없다는 점은 동의합니다만, 그래도 여전히 현실 세계의 많은 문제를 해결해 줄 수 있다고 생각합니다.

    Agile 방법론이 실패하는 가장 큰 원인은 주객전도에 있다고 봅니다. 저는 Agile 방법론이 점진적 개선, 빠른 피드백을 통한 높은 품질의 소프트웨어 개발을 목표로 하는 개발 문화라고 생각합니다. 그리고 그 목표를 달성하기 위한 목표로 Pair programming이나 Continous Integration, TDD 등등의 세부 기법들이 존재하고요.

    그런데 저 뿐만 아니라 다른 개발 조직을 경험해 볼 때도 이런 세부 기법에 너무 집중한 나머지 프로젝트의 특성이나 팀의 구성원의 성향을 무시하고 세부 기법들을 과도하게 도입하고 강제하면서 부조화가 생겨나고 결국은 프로젝트 실패로 끝나는 경우가 많았습니다.

    결국 점진적 개선, 빠른 피드백을 통한 높은 품질의 소프트웨어 개발이란 목표를 위해서 Agile 방법론의 세부 실천 기법들을 취사 선택하고 이에 조직 구성원들의 동의를 이끌어 내는 것이 제일 중요하고

    만약 이런 접근을 통해 Agile 개발 방법론이 적용된다면, 개발 프로세스 상의 많은 문제들이 해소되거나 애초에 발생하지 않을 것이라고 생각합니다.

    ( 이런 믿음조차 맹목적이게 보일 수 있을지 모르겠습니다만… )

    답글삭제