왜 하필 나선이죠?
이것이 상당히 설명하기 힘든 부분이다. “왜 하필 나선인가?”
솔직하게 말하자면, 왜 하필 나선인지는 그 형상이 아닌 반복적인 프로세스에 있다. 다시 말해, 계획, 위험분석, 개발, 평가 4단계를 4분면으로 쪼개어 순서대로 반복시키는 프로세스를 시각화하기에 가장 좋은 선이 나선이라서 그렇게 된 것 뿐이다.
그러니까 이것은 나선력이랑 딱히 상관 없다. 생명의 에너지, 시몬과 카미나의 그렌+라간 합체! 같은 소리처럼 보이게 이름을 지어 놔서 그렇지, 사실 나선과는 하등 상관 없다.
차라리 따지고 보면 이것은 꽤나 마음에 들지 않는 순환 구조이다. 봇치 더 록의 히로이 키쿠리의 ‘행복 스파이럴’같은 것에 가깝다.
뭔가 해결되지 않는 것 같은데 결과적으론 행복하다.
이 나선형 모델은 마찬가지로 “요구 사항이 들어왔다->계획을 짠다->고객이 싫어하면서 다시 따 오라고 한다->다시 따 온다->대충 해 보라고 해서 개발한다->고객한테 준다->마음에 안 든다->요구사항이 들어왔다” 순으로 굴러간다.
더 웃기는 것은, 이렇게 해서 굴려 보니 “고객이 만족하던데요?”라는 결과가 나왔다는 것이다. 그래, 고객은 만족하겠지, 엔지니어는 죽어 나가는 거고…
그리고 첨언하자면 놀랍게도 현대 최적화 프로세스의 절반도 이런 식이다. “프로그램이 느리다->빨리 서버 증설을->아무렇게나 짜면서 점차 사용량이 늘어납니다->일시적으로 프로그램이 잘 돌아갑니다->느리면 서버 증설만 생각하게 됩니다->예산이 바닥났어 이제 서버를 더 못 들여->프로그램이 느리다”
아무튼, 이것은 상당히 사견에 해당하는 말이지만 나선형 모델은 있는 그대로 도입되기에는 단순한 “스프린트 전략”이나 “크런치 모드 임기응변”은 될 수 있어도 전반적인 개발을 주도하기에는 많은 보완이 필요할 것 같다.
그래서, 앞선 포스트와 마찬가지로 구조적인 설명을 하기는 어렵다. 나름대로 최선을 다해 보도록 하겠다.
계획 및 정의
이 단계는 프로세스 계획 수립과 요구 사항 분석, 그리고 단계별 목표 수립이 이루어진다. 이 계획 수립 단계가 충분히 이루어지지 않으면 고객이 말한 것을 주먹구구식으로 틀어 막고 다음 프로세스를 돌리게 되기 때문에, 앞에서 비판한 것과 같이 “지옥의 나선”이 될 수 있다.
이 단계는 고객의 의도를 최대한 기술적으로 정밀하고 이견이 적은 명세로 산출해 내어야 하며, 그래야 다음 단계인 위험분석의 신뢰도가 높아진다.
위험분석
위험 분석은 결국 실제 개발된 코드가 아닌 계획에 의존한다. 그렇기 때문에 계획이 실제 구현될 코드와 이견 없이 1:1로 일치한다고 가정하고 위험 관리에 대한 촘촘하고 정량적인 분석과 평가를 해야 한다. 평가 결과에 따른 근거, 개발 여부, 예상되는 난점 등을 모두 위험 관리 계획서와 요구사항 분석서 등에 수록하는 편이 좋다.
개발
개발 단계에서는 구현 대상 기능에 대한 실제 구현과 단위 테스트가 수행된다. 이 때에 소스 코드와 진화적 프로토타입 작성이 이루어지기 때문에, 나선의 다음 회전에 영향을 주지 않으려면 위험분석 단계에서 개발 도중 생기는 예기치 못한 변경을 최소화해 두고 진행해야 한다.
고객의 평가
고객은 결과물을 받아 본 후에 시스템을 평가하고, 향후 목표계획을 줄 것이다. 순서 상으로는 마지막으로 나오니 “여기서 끝”처럼 보이지만 실제로는 이전 회전의 평가가 현재 회전의 계획 및 정의 단계의 거름이 되는 순환이다. 이러한 것을 잘 고려해서, 평가에 대해서도 충분히 치밀한 분석, 또한 가능/불가능 여부 등이 잘 논의되어야 한다.
나선형 모델의 장점
우선 나선형 모델의 장점은 고객의 요구가 명확하고 요구 사항이 명확할 때 빛을 발한다. 즉 연구소 R&D라서 “프로토콜의 목적성은 어떠해야 하며, 프로토콜은 반드시 IoT 기기와 서버 간의 통신에 있어서 Sawtooth 딜레이를 방어하는 기법이 있어야 한다. 서버는 여러 물리 기기가 연결된 HA 서버이고, 고가용성을 보장하기 위해 최소 3대의 Control Plane이 있어야 하며, Worker 노드에 대한 배치는 클라우드 오케스트레이션 도구에 맡기지 말고 직접 레이블링하며 정책을 기술할 수 있어야 한다”일 때는 이 모델이 빛을 발하지만, “동시 접속자 한 10만명, 이건 글로벌 이커머스를 노릴 거에요. 우리 벤처가 잘 될 수 있게 UI는 단순하게, 서버 백엔드는 무중단으로 해 주세요”에서는 잘 먹히지 않는다는 뜻이다. 그래서 이것의 장점은 “언제나 사용자 요구사항을 정확히 파악할 수밖에 없도록 구조적으로 강제”하는 것과 품질의 하한선이 높다는 것이다.
나선형 모델의 단점
그래서 나선형 모델은 대규모 R&D 개발 등에서 압도적으로 유리하나 지시가 정확하지 않은 고객을 상대하거나, 고객이 정해지지 않은 범용 소프트웨어를 개발할 때에는 제대로 흘러 가기가 힘들다. 즉 조직 내의 위험 관리 능력이 성공 여부에 영향을 끼치고, 조직 외의 위험 분석이 얼마나 정확한지도 영향을 끼친다. 정확한 요구 사항을 충족하지 못한 지점에서 개발 기간이 길어지고, 프로젝트 관리가 난해해지는 것은 진입 조건부터 이미 예견된 치명적인 단점이다.
그럼 우리 조직에는 뭐가 더 맞을까?
만약 당신이 있는 조직이 대규모 R&D 센터이고, 매번 마주하는 사람들이 공학 박사들이라면 당신의 상사가 애자일이나 나선형 모델을 도입하는 것은 제법 긍정적인 방향성을 불러올 것이다. 세부적인 사항 하나하나는 연구소 본부와의 회의를 통해서 명문화될 것이고, 코드 한 줄 한 줄이 명확한 요구 사항을 따르는 기술 문서에 맞게 진행될 것이다.
그러나 당신이 있는 조직이 평범한 SI 조직이라면 결국 이 조직은 폭포수 모델이나 V 모델을 벗어나는 것은 거의 도박이다. 고객은 대체로 기술적인 요구를 하는 방법도 모르는 비 IT 기업이거나 공공기관이고, 요구되는 프레임워크와 근무 방법론은 공무원에게 요구되는 그것이다. 이러한 환경에서 애자일이나 나선형 모델을 투입한다는 것은 장독에 뱀 독을 풀어 버리는 셈이다.
아직 이것은 SI에는 이르다
한국의 일반적인 SI 조직에서 애자일, 나선형 모델을 도입하는 것에 대해서는 아직 엔트리급 엔지니어인 내 나름대로도 경계해야 할 방법론이라고 생각한다. 많은 사람들이 서울이 실리콘 밸리라고 생각하고 일을 끌어 가려고 하는데, 서울은 실리콘 밸리는 커녕 션전(Shen Zhen)보다도 보수적인 80년대식 IT 조직이 압도적으로 많은 곳이다.
그리고 이러한 체계는 근 30-40년간 굳어졌고, 고객사는 여전히 요구하는 방법 자체가 폭포수를 전제한 문서를 전달한다. 이런 조직에서 애자일을 도입한다는 것 자체가 어불성설이다. 솔직하게 말하자면, 슬랙이나 노션의 도입조차도 아직은 형식적으로나 도입될 뿐이고 파격이라고 생각한다. 이러한 조직에서 문서를 기록하는 것은 그냥 평범한 NAS여도 할 수 있는 일이고, UI나 인터페이스만이 바뀐 채 실제로 노션이나 슬랙은 그러한 용도로 활용된다.
그렇다면 왜, 굳이 그렇게 해야 하는 것인가? 그리고, CI/CD도 어설프게 활용할 것인데 왜 단순한 Git 서버가 아닌 GitLab을 통째로 배포하는지도 아직은 이해가 되지 않는다.
여러모로 이러한 발전에 대해서 생각하게 되는 영화 속 대사가 있다.
“I guess you guys aren’t ready for that yet. But your kids are gonna love it.”
우리의 미래 세대는 적어도 권위적인 분위기에서 문서대로만 하는 “직공 내지는 안경 공장 인부”처럼 코딩하지 않기를 바라며 이번 포스트를 마친다.