티스토리 뷰

반응형

 

안녕하세요, 미시깽입니다.

커뮤니티 사이트를 시작으로 포탈까지 개발자로서 일을 대했을때와 어느 정도 연차가 쌓이고 프로젝트 관리도 하며 전산행정 업무도 해보고 난 이후, 여행업계에서 IT총괄을 맡으면서 일을 대하는 제 모습은 참 많이 바뀌었습니다. 아마도 연차가 쌓이고, 전체 프로세스마다에서 업무를 하다보니 프로세스별 담당자에 대한 이해도도 높아지고, 웹개발만 하던 때와는 달리 프로젝트 전반에 대해 이해하기 시작했기 때문이 아닐까 싶습니다.

 

IT에는 수없이 많은 개발기술과 수없이 많은 업무분야로 나뉘어져 있고, 그만큼 해당 분야에 대한 전문가들도 참 많은게 현실입니다.  그래서 다양한 의견들도 많은데요, 사실 그 의견들이 모두 맞다고 혹은 모두 틀리다고도 할 수 없는게 IT가 아닐까 싶습니다. IT는 범위가 너무 넓고, 온라인 분야에서는 A라는 의견이 맞을 수 있지만, 시스템 분야에서는 전혀 안 맞을 수도 있습니다.  따라서 IT와 관련된 이론들은 다양하고 분야에 따라 달라지고, 많아질 수 있다고 생각합니다.

 

 

웹서비스에 최적화 된 개발방법론이란...

 

제가 맨 처음 커뮤니티 서비스에서 일을 한참 배우고 있을 때였습니다. 사이트 개편준비를 하던 때였던거 같은데요, 그때 한참 개발사수, DBA사수와 함께 UML을 그리며 회의를 하던 때가 있었습니다. 마치 학교다닐때 소프트웨어 공학시간에 했던 실습을 하는 것 같은... 느낌으로 여러가지 이야기를 했었는데요. 어렴풋이 기억에 남았던 이야기는 아직 웹서비스에 대한 개발방법론은 없는거 같다..였습니다. 이유는 기존에 나온 각종 개발방법론들은 웹서비스라기 보다는 네트워크를 기반으로 한 시스템에 탑재된 서비스에 한정되어 있는 것들이 대부분이란거죠.

 

 

예를 들어, 매장에서 카드결제할때 쓰는 POS시스템이라던가, 스마트폰 이전에 핸드폰에도 각종 시스템이 탑재되어 있는 것처럼.  아마도 해당 시스템 프로젝트를 위해 오랜시간동안 준비하고 고민해서 분석 및 설계, 개발, 테스트, 검증을 통한 일반적인 개발방법론을 적용해서 일년 혹은 2,3년까지도 시간과 비용을 투자해서 상품화(?)해서 내놓는 것일겁니다.

 

하지만 웹 서비스의 경우 일년에 한번 전면개편은 기본이고, 중간중간 트렌드에 맞게 부분 개편을 분기별로 밥 먹듯이 하는데, 시간과 비용을 투자하고 많은 고민을 해야하는 개발방법론이... 궁합이 맞을리는 없겠죠. 그리고 많은 웹서비스 회사의 윗 분들은 기다려주지 않는다는 공통된 특징이 있기도 하구요. 마치 오늘 오전에 이야기했으면 다음 날 점심 때쯤엔 이미 뭔가 되어있을거라 생각하는 분들도 많으니까요. 이런 개xx.. 니xx..


그래서 간혹... 웹서비스 개발하시는 분들은 "방법론 그딴거 필요없어. 따라서 학교 때 배운거 다~ 소용없다." 라고 이야기하시는 분들 있으시더라구요.  일단 돌아가게만 하면 되는거지 그딴 이론.. 웹에는 필요없다. 라고.. 그래서인지, 어느 날 잡지에서 "전공공부 필요 없다는 개발자는 웹만 한 사람일거다. 제대로 된 소프트웨어를 만드는 사람이라면 그런 말 하지 않는다." 라고 기고 된 글을 본 적이 있어서 울컥했네요.  전... 전공공부의 중요성을 뒤늦게 깨달은 한 사람이니까요. 흑.

 

 

애자일? 그게 뭐지?


얼마전 야메군과 이야기하다가 애자일이 마치 기획자가 컨셉기획안만 던져주면 디자이너와 개발자가 알아서 서비스를 만들어주는 것처럼 비춰져서 기획자가 일하기 쉬운 방법론으로 오해하고 있는 경우가 있더라는 이야기를 해주더군요.  그래서 오랜만에 애자일방법론에 대해 찾아보았는데, 애자일방법론(Agile software development)이 개발자에게 동기유발을 높인다는 기사가 있더라구요.

 

"애자일방법론, 개발자 동기유발 높인다" - 미디어 다음(디지털타임즈 2012.07.24)

 

"SW공학센터는 애자일 방법론의 짧은 개발주기와 참여자간의 활발한 상호작용이 피드백을 높여 개발자가 수행한 작업의 결과에 대한 인식수준이 향상된 것으로 분석된다고 설명했다."라는 내용이 기사 안에 있었습니다.


이게 전부는 아니겠지만, 분야마다 다른 이야기가 나온다는건 그만큼 애자일에 대해 관심을 가지고 있다는 것과 같겠죠.  그렇다면 애자일이 도대체 뭔데 이러는걸까요.  웹서비스에서도 어느 분야에 몸담고 계시느냐에 따라 들어보신 분들도 계시겠지만, 아닌 분들이 더 많지 않을까도 싶구요.  그래서 일단, 간단히 애자일에 대해 설명드려볼까 합니다.

 

애자일 방법론은 소프트웨어 엔지니어링에 대한 개념으로 개발방법에 있어서 계획을 가지지 못한 개방방법과 지나치게 계획이 많은 개발방법 사이에 타협점을 찾는 방법론 입니다.  이를 통해 적절한 수준의 예측을 통해 업무의 효율성을 높이고, 리스크를 줄일 수 있으며, 복잡한 절차를 준수하기 위해 일정이 늦어지는 것을 방지할 수 있다고 하는데, 2001년 1월.. 애자일 연합이라는 그룹에서 공동 선언서 형식으로 만들어진 "애자일 선언문" 그에 대한 개념을 엿볼 수 있습니다.

 

애자일 선언문

"우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써 소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와 같은 가치에 도달하게 되었다.  이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 보다 큰 무게를 둔다."

'프로세스와 도구'보다는 개성과 화합.

(개인과 상호작용을 프로세스와 도구보다 우선적으로 한다.)

 

1

 
Individuals and interactions over processes and tools.

'포괄적 문서화'보다는 동작하는 소프트웨어.

(작동하는 소프트웨어를 포괄적인 문서화보다 우선한다.)

 

2

 
Working software over comprehensive documentation.

'계약과 협상'보다는 고객과의 협력.

(고객과의 협업을 계약에 대한 협상보다 우선한다.)

 

3

  Customer collaboration over contract negotiation.

'계획준수' 보다는 변화에의 대응.

(변화에 대한 대응을 계획에 따르는 것보다 우선한다.)

 

4

 

Responding  to change over following a plan.

 

더불어, '애자일 소프트웨어의 12가지 원칙'이라는 이름으로 좀 더 구체적인 실전원칙이 있는데요, 다음과 같습니다.

 

애자일 소프트웨어의 12가지 원칙 

우리의 최우선 순위는, 가치 있는 소프트웨어

일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
 

1

 
Welcome changing requirements, even late in 
development. Agile processes harness change for the customer's competitive advantage.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

 

2

 
Deliver working software frequently, from a 
couple of weeks to a couple of months, with a 
preference to the shorter timescale.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

 

3

 
Business people and developers must work 
together daily throughout the project.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

 

4

   Business people and developers must work 
together daily throughout the project.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

 

5

 

Build projects around motivated individuals. 

Give them the environment and support they need, and trust them to get the job done.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

 

6

 

The most efficient and effective method of 

conveying information to and within a development team is face-to-face conversation.

작동하는 소프트웨어가 진척의 주된 척도이다.

 

7

 

Working software is the primary measure of progress.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

 

8

 

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

 

9

 

Continuous attention to technical excellence 

and good design enhances agility.

단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

 

10

 

Simplicity--the art of maximizing the amount 

of work not done--is essential.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

 

11

 

The best architectures, requirements, and designs emerge from self-organizing teams.

팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

 

12

 

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts 

its behavior accordingly.

 

아마 기획자 중 이 내용들을 슬쩍 훓터보신 분이라면, '개발 후반부일지라도 요구사항 변경을 환영해라..' 라는 문구를 보고 환호를 지르셨겠죠?  '뭐 이런 훌륭한 개발방법론이 있어!' 라고 말이죠.  하지만 한 줄 한 줄 꼼꼼이 읽어보시면, 애자일이란 건 기획자, 서비스운영자, 그리고 개발자가 모두 "함께" 일해야한다는걸 강조하고 있다는걸 느끼실 수 있습니다.

 

애자일의 원칙이란걸 지키기 위해서라면 끊임없이 업무범위 별 담당자들이 서로 대화하고, 요구하고, 피드백을 줘야 한다는걸 항목들 안에서 확인하실 수 있습니다.  다시 말해서, 기획자가 기획서만 틱 던져놓으면 애자일 방법론이 모든 것을 해결해주는 것이 아니라는 점 입니다.

 

애자일 방법론은 협업대상자들과의 반복적인 검증과정이 수반되어야 한다..

 

 

 

"기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다..." 라는건 개발자에게만 요구하는 원칙은 아닐거라 생각합니다. 기획자의 끊임없이 쏟아지는 관심과 피드백이 개발자의 기민함을 향상시키지만 한편으로 기획자에겐 자신의 아이디어를 끊임없이 보고 또 보면서 기획자로서의 기민함 또한 향상 시킬 수 있는 가장 효과적인 방법이라 생각합니다.

 

결국 이 원칙이라는 것은 기획, 디자인, 개발, 운영.. 등..서비스와 관련된 모든 사람들의 손발이 잘 맞아야하고 모두 동일한 서비스에 함께 관심을 가지고 자기 분야가 끝났다고 그 이후에 대해서 관심이 없는... 이런 문화는 옳지 않다는걸 설명하는게 아닐까 싶습니다.  간혹 애자일방법론에 대해 그 의미를 왜곡하거나 잘못 이해하는 분들을 간간히 볼 수 있는데, 애자일 방법론은 한마디로 개발자가 기계를 톱니바퀴처럼 끊임없이 일을 해야 하는.. 그런 방법이 아닌, 협업대상자들 모두가 끊임없이 의문을 제기하고 틀에 얽매이지 않고, 문제를 해결하려는 마인드를 갖는 것이 바로 애자일 방법론이 이야기하는 핵심이라는 점, 잊지 마시기 바랍니다.

 

다음 편에서는 애자일의 원칙을 기반으로 한 세분화된 방법론에 대해 설명하고, 이 방법론들을 웹에 적용했을 때의 여러 상황들을 합리적인 관점에서 정리해보도록 하겠습니다.

 

 

 

 

미시깽. 토끼같은 귀여운 딸래미 둘과 사과같은 남편과 살고 있는 웹개발 13년차.  아이러브스쿨과 SK커뮤니케이션즈 등을 거쳐, 국회입법조사처와 한국지역정보개발원에서 IT관련 빡센 행정업무를 경험하고, 세훈항운(주)에서 다시 웹개발을 시작, 자회사인 (주)온필에서 기술개발팀장으로 있으면서, 여행업이라는 새로운 분야에 대해 배우는 마음으로 시스템 개발에 매진 중.

 

 

 

반응형
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday