2000년 무렵부터일 것이다. 소프트웨어 업체의 이단아들이 애자일이란 말을 주문처럼 사용하기 시작했다.
힘들고 어려운 소프트웨어 개발 과정이 애자일 방법을 사용하면 마법처럼 해결된다는 것이다.
사전에서 애자일을 찾아보면 '민첩한, 기민한, 머리의 회전이 빠른'이라는 뜻을 갖는다고 나온다.
왜 사람들이 애자일 방법을 소프트웨어 개발 과정의 새로운 해결책으로 생각하고 있는지 살펴보고, 애자일 방법과 임베디드 소프트웨어의 관련성을 찾아보도록 하자.
애자일이란?
애자일 방법이 2000년 이후 새롭게 나타났지만, 그 내용은 사실 새로운 것이 아니다.
이제 반백 년이 넘은 소프트웨어 개발 기간 동안 재야의 고수들이 몸으로 익힌 사항을 정리한 것이라고 보면 된다.
소위 소프트웨어공학이라는 학문에서는 요구사항부터 시작해서 설계, 구현, 테스트를 거치면 완벽한 소프트웨어가 개발될 것이라고 생각했다.
그렇지만 사용자의 요구사항은 빈번하게 변경되고 완벽한 설계라고 생각했던 구조는 구현하면서 잘못된 길이었다는 것을 알게 된다.
아는 만큼 보인다는 말이 있다. 소프트웨어를 개발해보지 못한 사용자가 얼마만큼 알아서 완벽한 요구사항을 만들 것이며, 너무나 복잡한 소프트웨어를 직접 개발해보지 않고서 완벽한 설계가 나올 것인가?
애자일에서는 사람 냄새가 난다. 밤새 컴퓨터 앞에서 외롭게 자신만의 길을 가는 프로그래머로서의 사람이 아니라 함께 얘기하고 함께 고민하면서 문제를 풀어나가는 인간으로서의 사람 냄새가 난다. 애자일은 혁명이다.
역사는 아래로부터 혁명이 일어날 때 성공한다는 것을 보여줬다. 애자일은 힘든 소프트웨어 개발 과정을 극복하기 위해 분연히 일어난 개발자들로부터의 혁명이다.
XP의 실천사항 중 하나인 하루 8시간, 주당 40시간의 작업시간, 생각만 해도 즐거워진다.
애자일의 대표 XP
여러 가지 애자일 방법이 있지만 가장 유명한 XP 방법을 통해 애자일 방법을 알아보자. 윈도우 때문에 친숙해진 단어 XP가 애자일 방법에서는 eXtreme Programming을 의미한다.
어떤 사람은 익스트림이란 말에서 XP는 비행기에서 낙하산 하나만 주고 뛰어내리면서 개발을 완료하는 것이라고 말하기도 한다.
XP는 개발 기간이 얼마 남지 않은 극한의 상황에서도 서로 즐기면서 SW를 개발하는 방법을 의미한다. XP에서의 열네 가지 실천사항은 다음과 같다.
(1) Customer Team Member
'고객이 왕이다.' XP의 목표는 고객을 만족시키는 것이다.
그러나 이를 위해서 고객이 해야 할 일이 있다. 바로 고객이 직접 개발팀의 일원이 되어 개발 과정에 참여하는 것이다.
(2) User Stories
개발 중 가장 어려운 점은 고객의 요구가 바뀐다는 것이다.
사실 고객도 자신이 무엇을 원하는지 정확히 알지 못할 때가 많다.
사용자 스토리는 고객과 개발자가 대화를 할 수 있는 방법을 제공한다.
(3) Short Cycles
'백문이 불여일견.' 짧은 개발 주기에 일부 스토리카드를 완벽하게 개발한 후 고객에게 제공한다.
제품을 보고 고객이 다시 의견을 말하면서 점점 제품의 최종 목표가 드러날 것이다.
(4) Acceptance Tests
앞의 사용자 스토리는 제품의 목적을 적는 것이다.
스토리카드 작성 시점부터 목적을 증명하기 위한 방법을 생각하고 제품 개발 후 검사에 사용한다.
(5) Pair Programmig
모든 일이 혼자 하는 것보다 둘이 하는 것이 좋다. 프로그램 개발 역시 둘이 같이 하는 것이 좋다.
보통 드라이버와 네비게이터라는 말을 사용하는데 이는 초행길을 가면서 한 명은 운전을 하고 다른 한 명은 지도를 보면서 함께 목적지를 향해 안전하면서도 가장 빨리 가는 것을 비유해서 하는 말이다.
(6) Test-Driven Development(TDD)
XP에서 설계를 하지 않고 바로 코딩부터 한다고 하면 예전과 달라진 것이 무엇이냐고 묻기도 한다. 코딩부터 바로 시작하지만 엄격한 검사를 함께 하는 것이 차이점이다.
(7) Collective Ownership
거듭 기술한다. XP는 혼자서 작업하는 것이 아니다. 팀에서 작업한 모든 코드는 공동 소유한다.
목적이 좋다고 모든 것이 저절로 이루어지는 것은 아니다.
페어프로그램, TDD, 리팩토링, 표준 준수 등이 합쳐지기 때문에 공동 소유가 가능해진다.
(8) Continuous Integration
개발자가 작업 내용을 매일 계속해서 통합하고 테스트를 수행한다.
(9) Sustainable Pace
거의 항상 개발을 실력보다는 시간으로 해결하는 경향이 있다. 그러나 잦은 야근이 개발시간을 단축시켜주지는 않는다. 마라톤처럼 꾸준한 페이스를 유지하고 진행해야 한다.
(10) Open Workspace
훌륭한 개발자의 모습을 어두운 방 안에서 홀로 모니터만 쳐다보는 것이라고 생각한다면 이젠 제발 잊어라. 열린 공간에서 공통된 목표를 향해 함께 작업하는 것이 중요하다.
(11) The Planning Game
XP는 강압적인 방법론이 아니다. 개발자도 함께 계획을 결정하고 수행하는 방법론이다. 적절한 시간 조절을 위해 스토리카드가 활용된다.
(12) Simple Design
개발자는 멋진 코드를 만들기를 원한다. 멋진 코드는 누구나 쉽게, 또는 나중에 보더라도 쉽게 알아볼 수 있는 코드이다.
(13) Refactoring
처음부터 잘 할 수는 없다. 언제든지 자신의 코드가 마음에 안들면 수정할 수 있다. 테스트 주도 방법이 변경된 코드도 잘 작동된다는 것을 보장해준다.
(14) Metaphor
메타포란 말은 비유란 말이다. 다소 뜬금없는 단어지만, 전체 개발팀이 동일한 개념을 소유하고 있어야만 개발을 빨리 진행할 수 있다.
회의 도중, 개발 도중 서로 같은 말을 가지고 다르게 사용한다면 어떤 일이 벌어질까?
회사에서 회의를 조금만 해본 사람이라면 어떤 상황이 될 지 알 수 있을 것이다.
휴대폰용 SW 개발에 사용되는 애자일 방법
모바일 응용 SW는 사용자가 항상 휴대하고 다니는 모바일 단말기에서 동작하는 SW를 말한다.
모바일 응용 SW는 사용자와 쉽게 접할 수 있는 특징과 함께 모바일 단말기의 성능 영향을 받는다는 특징을 갖는다.
이와 같은 모바일 응용 SW의 특징을 만족시키기 위해 개발 초기에 UI 프로토타이핑을 수행하여 사용자의 요구를 적극적으로 수용하고, 빠른 개발을 위해 애자일 방법론을 따라야 한다.
핀란드에서는 모바일 응용 SW 개발을 위해 〈그림 1〉과 같은 MOBILE-D라는 방법론을 만들었다. MOBILE-D에서는 주 개발 기간동안 플래닝데이, 워킹데이, 릴리즈데이를 반복하면서 애자일 방법에 따라 개발을 진행한다.
애자일 방법이 임베디드 S/W에서는 어떻게 사용될까?
XP가 처음 나왔을 때는 소비자가 명확한 비즈니스 도메인에서만 사용할 수 있다고들 말했다.
빠른 개발이 필요하고 에러를 찾기 어려운 임베디드 환경의 특성상 XP가 제대로만 적용된다면 아주 효과적이다.
크로스컴파일 환경에서 자동 테스트가 쉽지 않기 때문에 임베디드 SW에 애자일 방법을 그대로 적용하기는 쉽지 않다.
그렇지만 부분적으로 임베디드 SW 환경에 애자일 방법이 적용되고 있고, 리팩토링이란 동일한 기능을 수행하면서 원하는 성능을 될 수 있는 한 최적화하는 것이란 개념도 나오고 있다.
댓글