‘법틀’ 스타트업 개발 프로세스의 비화 ③

스타트업엔은 실제 스타트업기업에서 프로세스 개발과정에서 일어난 생생한 이야기를 시리즈로 다루고자 한다.

Agile의 폭풍이 10년 전부터 개발 프로세스의 핵심으로 또 따라야 할 트렌드로 유행을 탄 적이 있다. 또 약간 후였지만 TDD도 마찬가지다. Agile이나 TDD가 무엇인지에 대해서 여기서는 설명하지 않겠다. (구글에 검색해도 좋은 글들이 충분히 나온다.)

다만 실재 적용해본 입장에서 장단점을 적어보도록 하겠다. 우선 Agile에 대해서 논의해보기 전에 한 글을 일독 하기를 권한다.

구글에서 “Why agile nonsense”로 검색을 해보면, 왜 Agile이 구글에서는 말이 안 되는 프로세스인지를 “Quora.com”에서 상세히 설명하고 있다. 간단히 말해보자. 여러분이 2007년으로 돌아가서 크롬 브라우저를 만드는 엔지니어가 되었다고 해보자.

2주마다 유저의 반응을 보면서 이거 고치고 저거 고치면서 프로젝트를 완성할 수 있을까? 매일 아침 스크럼을 하면 XML/HTTP 파서 개발자가 무슨 말을 할까?

Dog-feeding이라는 구글의 프로세스는 매우 중요한 과정이지만 (실제로 사내에서 제품을 써보는 것이다.) 이것이 Agile 프로세스라 보기는 힘들다. 만리장성을 지으려면 매일매일 고민보다는 좀 더 큰 스케일의 설계와 계획이 필요하다.

Agile의 장점 중 한 가지는 점진적 진화에 상당히 강하다는 점에 있다. 실제로 이 프로세스를 돌려보면 스크럼 때 정해진 방향이 오후에 틀어지고 그 다음날 컨펌을 받는 경우도 허다하다. 즉 "설계문서가 이러니까 이렇게 해야 해!" 이런 압박이 덜하기 때문에 상당히 유연하고 또 경우에 따라서는 빠르게 적용이 가능하다.

Agile을 하려면 그냥 Task/Bug를 시간순으로 배분하는 것이 중요한 것이 아니라 실재 제품에 대한 Decision을 Agile의 단위로 하는 것이 중요하다. 그러기 위해서는 팀이 소규모여야 하고 또 결정 권한이 있는 사람은 모두 팀 단위로 Agile을 수행해야 한다.

또 한 가지 Agile의 장점을 꼽자면 개발자의 업무 로드를 정확히 알 수 있고 또 조절할 수 있다는 점이다.

6개월짜리 프로젝트 개발자 10명 가지고 돌려보면 꼭 1~2명은 그냥 논다. 머 완전히 놀지는 않겠지만 하는 둥 마는 둥 하다가 마감다가와서 사고 나면 다들 들어붙어서 그거 완성하느라 땀 빼는 일이 많이 일어난다.

Agile의 핵심 중 하나는 1주 2주 단위로 일을 자르고 이를 그 단위로 검증하는 것이다. 그렇기 때문에 4-5달 논다는 것은 어불성설이다. 1일은 놀 수 있어도 나머지 4일은 빡세게 일해야 한다. 자주 검증하고 체크하기 때문에 숨을 구멍이 적어지는 것이다.
 
Agile의 단점은 아까 위에서 잠깐 언급이 되었지만 이런 프로세스가 맞지 않는 프로젝트가 많다는 점이다.

구글 엔지니어 말대로 간단한 코드로 많은 사용자들을 호스팅 하는 UI 중심의 프로젝트에서는 효과를 볼 수 있는 점이 있지만, 기술적인 프로젝트나 대규모 프로젝트 혹은 처음 시작하는 프로젝트 등에서는 오히려 생산성에 방해가 될 수 있다. 즉 Agile을 선택하려면 현재 자신의 제품의 특성과 Phase를 잘 알고 적용해야 한다.

사실 이런 부분이 너무 커서 Agile 자체를 컨설팅을 위한 Term으로 여기는 개발자들도 있을 정도다. 즉 알고 변경해서 적용해야지 그냥 적용하기가 힘든 점이 있다.

또 한 가지 단점은 일정 관리가 힘들 수 있다는 점이다. 무언가 열심히 하는 듯한데 업데이트가 늦어지고 고객과의 약속을 앞두고 Agile 이란 말이 무색한 그냥 전투 모드가 되는 경우가 종종 있다. 굳이 다른 분야로 표현을 하자면 하루하루 열심히 삽질은 하는데 땅은 잘 안 파지는 것이다.

급할수록 돌아가라는 말이 있듯이 지금 파는 땅이 맞는지 또 삽은 제대로 갖추어져 있는지 굴삭기를 이용할 수 없는지 좀 큰 견지에서도 고민이 필요한 경우가 많은데 매주, 2주 단위로 스프린트를 기획하고 하루하루 스크럼에서 논의를 하다 보면 개발자들만의 착각에 빠져버리는 경우가 종종 발생한다.

Agile을 해본 경험으로 보자면 Agile 자체가 나쁘다고 생각하지는 않는다. 어찌 보면 잦은 검증이 주는 시원시원함이 있다. Agile 프로세스 자체를 상당히 옹호하는 사람도 있고 상당히 반대하는 사람도 있는 것으로 알고 있지만 필자는 Agile 프로세스는 적절히 적용만 한다면 쓸모 있는 프로세스라고 생각한다.

TDD는 조금 다르다. 필자의 생각은 기술 Oriented 되어 있는 제품이 아닌 이상 TDD를 전체 개발과정에 넣기는 부담스러운 면이 있다고 생각한다.

우선 UI 특성이 높은 제품에 UI 변경을 가할 때 Selenium으로 모든 Test Code를 미리 릴리즈해야 한다는 룰은 너무 Strict 하다. Test Automation은 가능할지 몰라도 모든 개발이 Test Driven이어야 한다는 점에는 동의하기 힘들다. 이것은 Test Coverage와는 또 다른 말이다.

TDD가 빛을 발하는 것은 API로 구성된 제품이다. 이럴 때는 Test Automation은 필수이고 TDD도 꽤 좋은 옵션이다. API 제품을 개발하고 배포하고 업그레이드해보면 알겠지만 머 하나 바뀌면 정말 어디서 어떻게 뻑이 나는 지가 거의 예술의 경지다.

상상하기 힘든 극단적인 API 사용 case에서 뻑이 나는데 대부분 신규 test case든 old test case든 어느 정도 API 수정 개발을 하면 필패라 할 만큼 Test에서 에러가 줄줄이 나온다.

이런 경우에는 먼저 Test Case를 쓰면서 이런 극단적인 경우나 예외 상황을 상상하는 것이 많은 도움이 되고 또 Test Case를 만들다가 API 구조를 바꾸어야 하는 일도 흔히 일어난다. TDD가 빛을 발하는 개발 분야인 것이다.

Agile과 TDD에 대해서 필자가 생각하는 부분을 정리해 보았다. 다음은 법틀에서 2019년 말에 개편하였던 개발 프로세스에 대해서 한 번 논의해 보도록 하겠다.