애자일 개발과 전통적인 소프트웨어 개발 방식의 함점

얼마 전 필자는 지인을 통한 이 바닥에서 잘 알려진 분을 통해 소프트웨어 개발에 필요한 사람을 찾는다는 소식을 듣고 연락을 취하여 좋은 프로젝트를 소개 받았다. 쉽게 말하면 알바 하나 건졌다. 난이도와 기간에 비해 높은 비용을 제시하였고, 재택 근무 조건으로 업체와 구두상으로 서로 계약에 합의하였다. 구두상의 협상의 합의가 타결되기 위해 이 틀 동안 분석/설계된 자료를 검토하여 질의응답도 있었다.

필자는 애자일 개발 기법을 공부하고 적용해 보면서 여러 가지 함정에 빠져보았다. 이전에 비슷한 글을 몇 번 쓴 적이 있는데, 참고하면 좋을 것 같다. 그리고 과거의 필자의 작은 지식이기 때문에 독자들은 동의하지 않는 부분도 있을 것이라고 생각한다. 잘못되거나 동의할 수 없는 부분이 있더라도 양해를 부탁하며 필자의 아티클을 읽어주길 부탁한다.

프로젝트의 요구 사항은 무엇이었나?

어쨌든 필자는 애자일은 양날의 검이라고 이야기한 바 있다. 누구의 손에 쥐어지는지에 따라 애자일의 가치와 방법은 변할 수 있다. 맞춤 정장처럼 누구에게나 꼭 맞는 폼이 나지 않는다. 더불어 애자일 팀의 팀 성숙도와 이해도에 따라 성공과 실패가 극단적으로 갈리기 때문에 필자는 항상 애자일에 대한 접근에 매우 조심스럽다.

프로젝트는 유명한 게임 업체의 기업 홈페이지인데, 최신 .NET 플랫폼을 이용하여 개발하지만, 발주처에서 제시한 개발 지침은 강도가 높았다. 문서화나 산출물과 같은 노가다 짙은 결과물 보다는 객체지향적인 개발과 추상화된 개발이 조건이 있었다. 필자 또한 기반 프레임워크 개발과 개발 프레임워크를 개발하고 컨설팅을 수행하던 경력이 있던 부분에 계약 업체에서 필자의 이력에 만족해 하는 눈치였다. (뭐 상상은 자유지요? ^^).

더불어 성능 테스트도 개발 완료 조건이 포함이 되어있었다. 이 부분 또한 4년 이상 성능 테스트 경험의 컨설팅을 수행하고, 이후 N모사에서 서버/웹/클라이언트 소프트웨어의 성능 테스트와 부하 테스트 시스템을 프로세스화하고, 테스트 시스템을 구축하여 전담하고 있었기 때문에, 이 부분에서 신뢰를 얻을 수 있었던 것 같다.

우선 기업 홈페이지의 특징을 간단하게 분류해 본다면, 정적인 페이지(HTML), 게시판, 그리고 채용 기능이다.

  • 첫 번째, 특히 채용 기능은 내부 시스템과 연동되는 가능성이 크고, 채용 프로세스가 기업의 문화마다 차이가 있다는 점에서 가장 투입되는 리소스가 많은 부분이라고 판단했다. 더불어 화면 기획서의 절반 이상을 차지 것이 채용 시스템 부분이었다.

  • 두 번째, 전반적으로 국지화나 다국어 지원인데, 동적인 데이터나 게시판과 같은 것도 다국어 지원이 필요한 부분이었다. 단순히 다국어라고 하면 동일하게 보여지는 콘텐트에 대한 다국어인지, 국지화에 따라 별도의 게시판인지에 대한 부분도 명확해야 한다.

  • 세 번째, 발주처의 지침에 따라 성능 테스트가 필요하다. 그런데 완전히 새로 개발되는 웹 페이지가 더 나은 성능을 제공하는지 판단하기 위해서는 기존 웹 페이지의 성능 지표가 필요하다. 그래야 더 나은 성능 개선에 대한 데이터와 지표를 제공할 수 있다. 다만, 문제는 이전의 성능 지표가 없다는 것과 그렇다면 이전 웹 페이지에 대한 성능 테스트를 재수행해야 하는지에 대한 여부이다. 그리고 최근의 인터프리터 언어는 객체지향 컴파일 언어보다 런타임에서 더 빠른 성능을 발휘할 수도 있기 때문에, 이 부분에서 반드시 더 좋은 성능을 낼 수 있다는 보장을 할 수 없다고 구두상으로 못박았다.

일전에 테스트한 node.js의 성능과 C++ 성능을 테스트한 바 있는데 필자의 눈을 의심할 만한 결과가 나왔다. 당연히 C++ 네이티브 코드가 더 빠를 것으로 예상했던 부분이 node.js의 자바스크립트 인터프리터 컴파일 결과가 훨씬 빨랐다는 점이다. 전체적으로 자바스크립트도 가비지(Garbage) 작업을 배제한 것이기도 하고, 이 부분은 이 아티클의 논점을 벗어나기 때문에 논외로 하겠다.

계획 없는 애자일은 항상 불안한 문제들을 내포하고 있다.

이제 프로젝트 이야기를 잠시 떠나 전통적인 개발 방식과 애자일 개발 방식에 대해 이야기를 하고 싶다.

전통적인 개발 방식은 워터 폴(Waterfall)이나 Top-Down 방식의 개발 방식이라고 부르기도 한다. 폭포의 물이 위에서 아래로 떨어지는 것처럼 최초의 정의(Definition)나 개요에 의해 요구사항이나 작업이 나열되는 방식이다. 큰 덩어리는 더 작은 덩어리로 쪼개어 정의되는데, 여기에 파생된 기능/비기능 작업이 정의가 된다. 그리고 기획자(기획 또는 분석가 등의 포괄한다는 의미)는 각 화면을 정의하고 기능/비기능의 정의와 링크가 된다. 때로는 화면 정의와 기능/비기능 정의가 하나의 문서로 통합시키기도 한다. 뭐 이건 프로젝트의 규모나 개발 방식에 따라 다를 수 있고 발주처나 누군가에 의해 템플릿화 된 부분이므로 큰 문제가 되지 않는다.

전통적인 개발 방식은 매우 체계적(?)이여서 체계 자체의 정의에 오류가 있다면 이후의 설계나 개발에 영향을 미치고, 전체 개발 일정에도 영향을 미치게 된다. 필자도 공감하는 부분이며, 이런 문제와 요구 사항, 그리고 도출되지 않는 일부 작업을 잘게 쪼개진 다음 이터레이션(Iteration) 포함시켜 납품 기간에 최대한 근접할 수 있는 유동적인 계획이 만들어진다. 유동적일 수 있는 계획들이지만, 그 유동성에 의해 개발팀에서 만족할 수 있는 일정과 개발 형태를 가져갈 수 있는 이점이 있다.

하지만 대부분 문제가 되는 부분들은 표면적으로 드러나지 않는다. 사실 눈에 보이는 문제는 문제도 아니다. 눈에 보이는 문제는 문제로 인식할 수 있기 때문에 당장이라도 해결하길 원하면 해결할 수 있고 일정에 포함시킬 수 있다. 그런데, 눈에 보이지 않는 아주 작은 문제는 나중에 핵폭탄이 될 수 있는 위력을 가지고 있다.

애자일 개발을 선호하는 초급의 사람들은 이런 핵폭탄급 문제를 먼저 제거하려고 하지 않는 경향이 있다. 위에서 언급한 것처럼 국문/영문 게시판이라는 정의는 자세하게 기능을 정의하기 전에는 매우 많은 위험성을 내포하고 있다.

국문/영문을 지원하는 게시판이 있다면 도출되지 않은 기능/비기능적인 문제들의 예이다.

  • 다수의 게시판 중에 모두 지원해야 하는지, 일부만 지원해야 하는지
  • 일부만 지원하면 어떤 게시판이 국문/영문을 지원해야 하는지
  • 국문/영문 게시판은 하나의 게시물이 국문/영문으로 지원하는 것인지,
  • 또는 국문/영문 게시판은 별도의 게시물을 게시할 수 있는 것인지,
  • 또는 둘 다 가능해야 하는지
  • 이와 같은 다양한 국문/영문 지원에 따라 댓글 기능은 분리되어야 하는지, 또는 어떻게 지원해야 하는지
  • 현재까지는 국문/영문이지만 더 지원해야 하는 언어가 생길 가능성은 얼마나 있는지
  • 국문/영문 그리고 댓글에 대해 관리자의 권한 정의는 어떻게 하는지
  • 그 외의 부분은 영업 비밀이므로 비공개 함.

채용 시스템이 내포하고 있는 문제점의 예이다.

  1. 영문 지원 여부가 확실하지 않다
  2. 영문을 지원한다면 영문 문화권의 채용 프로세스로 진행해야 하는지
  3. 현재의 주소 체계인 도/시/읍/번지가 데이터베이스 스키마에 종속적인데, 새로운 주소 체계를 지원할 것인지
  4. 그렇다면 두 가지 주소 체계 도입으로 주소 입력 프로세스와 기능/비기능적인 개발 소요 리소스 비용이 추가되는 것을 인지하고 있는지
  5. 그 외의 부분은 영업 비밀이므로 비공개 함.

위와 같이 기능/비기능이 명확하게 정의되지 않는 일부의 예이다. 만약 기능/비기능이 이해하기 쉽게 정의되지 않거나 애매모호하다면 무엇이 가장 힘들어지는가? 바로 '커뮤니케이션'이다. 이 비용이 얼마나 비싼지 소프트웨어 개발에 관심이 있는 분들이라면 익히 알고 있을 것이다. 그리고 비싼 커뮤니케이션 비용을 감수하더라도 추후에 발생 가능한 책임의 소지이다. 이메일이나 메신저로 기록이 남으면 다행이지만, 전화 연락을 통해 급하게 정의되는 기능/비기능이라면 빼도 박도 못하고 약자가 패자가 된다. 일반적으로 개발자가 패자가 되는 것이다.

애자일 선호하는 사람들이 범하는 오류

애자일 소프트웨어 개발 방식을 선호하는 사람들은 전통적인 개발 방식이 잘못되거나 비효율적이라고 생각하는 사람들이 있다. 물론, 모든 사람들이 그렇다는 것은 아니다. 개인적인 필자의 경험은 외부의 애자일 팀과 일할 때가 가장 힘들었다. 바로 전통적인 개발 방식의 설계 방식의 고민의 흔적이나 문서들이 전혀 없다. 대신, 내 팀이 애자일 팀이라면 정말 일하기는 편할 수 있다.

애자일 개발 방법에서는 불필요한 산출물은 최대한 만들지 않는 것을 선호한다. 그래서 애자일 기법 중 기능/비기능이나 설계적인 문서는 클래스의 주석으로 만들어서 Doc Generator와 같은 유틸리티로 주석에 기재한 명세를 문서화한다고 한다. 이런 이야기는 비단 애자일 책에서도 매번 나오는 이야기다.

그런데 여기에도 문제가 있다. 발주처에서 사용하는 문서 양식이 있다면 문서 양식을 맞추어야 한다. Doc Generator의 템플릿을 고쳐 써야 한다. 그리고 Doc Generator로 전달된 문서가 발주처의 담당자에 의해 수정이 되는 경우 다시 코드의 주석에 반영이 되어야 한다. 결국 양방향 동기화가 가능해야 한다. 물론, 기술적으로 MS WORD와 같은 문서는 Hidden Field Definition(숨김 필드)의 메타데이터 정보를 이용하여 양방향 동기화가 가능하다. 다만, 발주처의 문서 자체를 양방향 동기화에 맞게 바꾸어야 한다. 양방향 동기화가 가능성 있는 이야기처럼 들리겠지만, 실제로는 전혀 불가능할 수 있는 환경일 가능성이 더 크다. 발주처의 표준 문서 형태를 바꾼다는 것은 사실 권한 밖의 범위이다.

애자일의 성숙도와 개발 방식은 전통적인 개발 방법의 경험이 기반

필자는 프로젝트 구두 계약을 취소하였다. 생각했던 것 이상으로 정의되지 않은 채 진행되는 요소들이 너무 많아, 일정을 추정할 수 없을 지경이었다. 개발은 커녕 분석/설계된 데이터도 없었다. 하지만 데드라인은 정해져 있었고, 작은 기능/비기능 요소 중 핵폭탄이 될 수 있는 플루토늄이 너무 많았다.

계약서의 도장을 찍지 않은 채, 약 이 틀 정도 전달 받은 허술한 문서에 대해 커뮤니케이션 리소스를 상당히 빼앗겼다. 계약할 업체 또한 필자의 계약 취소 요청에 개발 일정 중 이 틀을 손해를 보게 된 것이다. 결국 필자를 포함한 양측 모두 이에 대해 상호 손해를 본 점에 대해 인정하고 그냥 그렇게 필자의 알바 건수는 끝이 났다.

이 알바 건으로 느낀 결론은 애자일의 성숙도와 개발 방식은 전통적인 개발 방법의 경험이 기반이 되어야 한다는 점이다. 계산하지 않고 생각하더라도 명확하게 정의되지 않는 기능/비기능에 대해 수시로 커뮤니케이션 하는 것과 빡 세게 정의한 후에 일부 도출되지 않는 부분에 대해서만 커뮤니케이션 하는 것과의 소요되는 비용이나 리소스의 차이는 엄청나게 크다. 그리고 기록으로 남기기 힘든 전화와 같은 수단으로 정의된 기능은 추후 책임의 소지를 가려내기 힘들다. 약자가 패자다.

애자일과 같은 기법들이나 책이 있다면 다시 한번 보도록 하자. 초기 설계와 분석이 얼마나 중요한지 말이다. 필자 또한 여러 애자일에 대한 책을 보았다만, 분석/설계가 강조가 되지 않았을 뿐 중요성에 대한 이야기는 분명 나와있다.

아래의 문구는 애자일 선언문이다.

다시 한번 곱씹어 볼 글귀이다. '문서화보다는 잘 동작하는 소프트웨어'는 '문서화'가 중요하지 않다는 이야기가 아니다. '문서화'도 중요하지만 '잘 동작하는 소프트웨어'에 가치를 두자는 것이다. '잘 동작하는 소프트웨어'를 위해 '문서화'가 필요하다면 문서화를 잘 하는 것이 '잘 동작하는 소프트웨어'를 위한 방법이다.

바라보는 관점에 따라 '잘 동작하는 소프트웨어'를 기한 내에 납품하는 것 자체가 '가치'이기도 하다. 이 '가치'에 대한 설명은 자신의 역할이나 위치에 따라 얼마든지 달라질 수 있다. 위의 애자일 선언문 또한 우리나라의 발주처인 '갑'부터 '을', '병', '정'이 보는 관점에 따라 추구하는 가치는 다를 수 있다. 물론 기업의 팀이나 조직에서도 관점에 따라 그 가치에 차이가 있을 수 있다.

누구를 위한 가치인가? 애자일은 소프트웨어 개발 방법을 정의하고 가치를 추구하는 것이지만, 그저 '빠른 개발', '가벼운 개발', '우리 팀만을 위한' 개발 방법이라면 다른 팀이나 타인에게 무척 괴로움을 줄 수도 있다는 것이다. 전통적인 개발 방법의 경험이 축적되고 그 이후에 애자일 경험이 축적되어야 올바른 방향과 가치 있는 '가치'가 창조되는 것이라 생각한다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요