[Plan] 그래서 그 '애자일' 이라는게 뭐에요?

개발자 및 기획자 등 소프트웨어 관련 IT 업계 구인 글에서는 꽤나 자주 볼 수 있는 단어가 있다.

'애자일' 이 바로 그 것이다.

개발자로써 공부할 때는 '그냥 이런 느낌이구나' 만 알고 넘어갔던 애자일에 대해 조금 더 자세히 알아보았다.

 

애자일?

애자일이란 새로운 언어나 프레임워크가 아니다.

어쩌면 불완전할수도 있지만 이 글을 보고 있는 여러분도 이미 경험해봤을 수도 있다.

 

간단하게 예를 들어보면

'스프린트', '스크럼' 등이다.

근래에는 정말 작은 단위인 개발 동아리 및 개인 팀 프로젝트 단위에서도 등장하는 단어들이다.

스프린트별 작업, 그리고 위클리 스크럼 등.

여기까지가 내가 이전까지 개발자로써 알고 있었던 간단한 느낌의 애자일이었다.

 

하지만 기획에 관심을 갖고 공부하는 지금, 나는 애자일에 대해 조금 더 자세히 알아야 할 필요가 있었다.

 

그래서 결국 이게 뭔데요?

반복이다. 정말 쉽게 말하면 'Repeat'. 말 그대로 반복이다.

내가 이해한 바를 조금 더 개발자스럽게 표현해보자면 'do While' 이라고 정의할 수 있다.

기획을 공부한 기간보다 개발을 공부한 기간이 압도적으로 길기에, 설명이 개발자 친화적일 수 있다.

 

간단하게 코드로 한번 짜보자.

 

fun Process(idea : Any) {
    Plan(idea)
    Design(idea)
    Develop(idea)
    
    // All Process include 'Modify'
}

 

프로덕트를 만드는 간단한 과정은 위와 같이 정의할 수 있다.

아이디어를 가지고 기획하고, 디자인하고, 개발한다.

물론 각 파트의 함축적인 작업에 대해서는 생략했다.

 

그리고 애자일을 간단하게 표현해보자

do {
    Process(idea)
    idea = UserFeedback(idea)
} while(!isSatisfied)

 

 

유의미한, 혹은 고객이 만족하는 결과가 나올 때 까지 짧은 Process를 반복한다.

하지만 한 Process 이후, 혹은 중간에 피드백을 지속적으로 수용한다.

 

조금 더 쉽게 예시를 들어보자. 이번에는 개발자스럽지 않게 글 위주로 예시를 들어보자.

예시로 '당근마켓' 을 들어보자.

 

당근마켓의 MVP를 만든다면, '유저 간 중고 거래' 가 핵심 기능이다.

그를 위해서는 아이템 목록, 아이템 상세, 유저 간 소통방식(쪽지 혹은 댓글) 이 포함되어야 한다.

위의 3가지 조건만 충족된다면 '유저 간 중고거래' 는 가능하기 때문이다.

 

그럼 우선 이 3가지 조건을 포함하는 프로토타입을 제작 후 출시한다.

그리고 시장의 반응에 따라 UX, 기능 등의 추가/제거 여부를 재고려한다.

우리는 필수적이라고 생각했으나 그렇지 않은 기능들, 혹은 그 반대의 경우도 있을 수 있다.

 

그리고 첫 프로토타입의 제작 이후에는 이러한 과정을 짧은 스프린트 단위로 반복한다.

유저의 입장에서는 '즉각적인 업데이트가 되는' 그리고 '유저의 의견 반영을 잘 해주는' 느낌을 받을 수 있을 것이다.

 

그럼 이게 무조건 좋은가요?

물론 이미 많은 유명한 기업들이 사용하는 데에는 그만한 이유가 있을 것이다.

당연히 좋고, 새로운 개념이니만큼 이전에 사용되던 개념들의 단점을 보완했을 것이다.

 

하지만 이 개념을 공부하면서 지속적으로 들었던 의문이 있다.

과연 이 '애자일 개발방법' 이 모든 경우에서 옳은가? 이다.

 

혹자는

대기업에서 쓰는데 당연히 좋은 것 아닌가요?

라고 말 할수도 있다.

 

하지만 이 애자일 개념에서 중요한 것은 '즉각적인 피드백의 여부' 이다.

대기업의 프로덕트는 그게 비록 알파버전일 지라도 사용하는 일반인 얼리어답터들이 많다.

그러므로 비록 프로토타입일지라도 그에 대한 피드백을 받기가 용이하다.

 

하지만 스타트업 및 중소기업에서 새로운 프로덕트를 위한 프로토타입을 출시했을 경우, 즉각적인 피드백을 받기엔 현실적으로 어려움이 있다고 생각한다.

세상에는 수많은 종류의 앱이 있고, 우리가 사용하는 앱은 한정적이다.

스타트업 및 중소기업에서 출시한 온전한 기능을 가진 앱 조차도 사용하지 않을 가능성이 많다는 의미이다.

그런데 이들이 심지어 온전하지 못한 프로토타입을 출시했을 때 시장의 피드백을 기대하기란 하늘의 별 따기가 아닐까?

 

그래서 내가 내린 결론은 이렇다.

'물론 좋다. 하지만 최초 제작 방식으로는 어울리지 않을 수도 있다.'

메인 프로덕트가 존재하고, 추가적인 기능 개발에서는 기업의 규모에 상관없이 분명 용이할 수 있다.

이미 사용자가 존재한다는 의미이고 즉각적인 피드백을 받을 가능성 또한 높다.

 

하지만 사용자층이 존재하지 않는다면 애자일스럽게 개발하는 의미가 많이 퇴색되지 않을까? 라고 생각한다.

 

그럼 또 다른 방법은 뭐가 있는데요?

아마 다음 주제인 폭포수형 (Waterfall) 개발방법론이 좋은 대안이 될 수 있을 것이다.

애자일 방법론을 탄생시킨 계기라고도 할 수 있는 전통의 방법론이다.

'이걸 보완한 게 애자일인데 다시 이걸 사용하는게 좋을 수도 있다고?' 라고 생각하신다면 이 다음 글을 참고해보셔도 좋을 것 같다.