소프트웨어 개발과 가치에 대해

정해진 기간과 사용자가 느낄 수 있는 가치와 정기적인 배포

가치에 대한 이야기이다. 좋은 건지 나쁜 건지는 모르겠지만 지금까지 거쳐왔던 대부분의 개발팀들이 모두 주니어들끼리 복작 복작 뭔가 해보겠다고 두 팔 걷어붙였던 팀들이었고, 특히나 지금 속한 팀의 경우 놀랍게도 내가 유일한 학사 + 경력자이다 보니 자연스럽게 '개발 방법론'에 관심을 가지게 되었다. (내가 학사 + 경력자라고 팀에서 개발을 제일 잘하는 것은 아니다. 제일 못 한다) 

소프웨어 개발은 진짜 졸라게 복잡하다

최근 몇 달간 읽은 책들 쭉 살펴보니 '기술'에 대한 책 보다 '방법론'에 대한 책이 압도적으로 많았다. 전 세계의 소프트웨어 개발 대가들이 쓴 책들은 공통적으로 '정해진 기간 내에 사용자가 느낄 수 있는 최대한의 가치를 정기적으로 배포해야 한다'라는 느낌과 메시지를 던지고 있다. 물론 나 역시 그 부분에 대해 전적으로 동감한다.

하지만 정해진 기간 내에 사용자가 느낄 수 있는 최대한의 가치를 정기적으로 배포한다는 것은 개발은 한 번이라도 해본 사람이라면 느끼겠지만 정말 어려운 일이다. 아직 내가 시니어와 함께 일을 해본 적이 없어 경험하지 못한 것일 수도 있지만 내가 겪었던 개발 프로젝트들은 대부분 다음 두 가지의 테크를 탔다.

지금은 아니지만 언젠가 우리는 무슨무슨 기능까지 추가 개발해야 한다.
그 부분을 고려해서 큰 그림을 그려놓고 개발을 하자! 

이 경우에는 99% 확률로 처음 추정했던 개발 일정을 못 맞추게 된다. 그리고 개발팀은 점점 일정 못 맞추는 무능력한 팀으로 찍히게 된다. 학부생 시절 포함 비교적 최근까지도 이런 방식의 개발 프로젝트를 경험해 봤는데 절대적으로 성공하기 힘들다는 것을 깨달았다.

 큰 그림이고 나발이고 작은 기능이라도 당장 사용자가
쓸 수 있도록 만들고 배포부터 하자!

이 경우 기능 추가할 때마다 코드가 산으로 가서 짧은 기간 내에 아무도 손대려 하지 않는 괴물 같은 녀석이 된다. 이 녀석은 조만간 '레거시'라는 칭호를 얻게 되고 기존 개발팀 멤버들마저 팀에서 사라지게 된 뒤 새롭게 오게 된 멤버들만 남게 되었을 때 그들은 차라리 판을 새로 짜자고 외치게 된다. 그런데 새롭게 짠 그 판이 획기적으로 기가 막힌 소프트웨어가 되는 것을 별로 못 봤다. 그냥 뫼비우스의 띠 같은 느낌.

대단한 의미를 가지고 넣은 그림은 아니다. 그냥 뭔가 허전에 해보여 애자일 사이클 이미지를 넣어보았다.

가장 좋다고 생각하는 방법은 2번 케이스를 베이스로 깔고, 정기적이고 지속적인 리팩터링이 최선이라고 생각한다. 근데 이게 진짜 불가능에 가깝다고 느끼는 것이 대부분의 개발팀은 비즈니스에 휘둘리고, 개발이 비즈니스에 휘둘리게 되면 리팩터링? 그게 뭐죠 먹는 건가요? 우걱우걱.

물론 개발이 들어가기 전에 모든 개발 명세가 땋하고 나와 준다면 고통이 덜 하다. 하지만 (특히) 스타트업은 워낙 Agile 하게 움직이는 그룹이라 기대하기 굉장히 어려운 부분이고, 스타트업이 아니더라도 개발 명세가 중간에 말도 안 되게 바뀌어버린다거나 만들어 놓고 보니 다시 만드는 게 빠를 정도의 명세 수정이 발생한다는 내용은 동종업계의 지인들과 함께한 술자리에서 너무나도 자주 들었던 하소연이다.

프로젝트 매니지먼트에서 정말 힘든 것 중에 하나가 멤버들의 테스크 관리다. 제일 좋은 것은 다들 알아서 잘하는 것..

사실 이 문제를 해결할 수 있는 Silver-Bullet 같은 방법이 없다는 것은 이제는 너무나 잘 알고 있다. 그렇기 때문에 Scrum이니 Kanban이니 하는 방법론에서도 오랜 경력을 가진 아재들이 끊임없이 논쟁을 벌이고 있고, JIRA를 만든 Atlassian이 우리 돈을 가져가는 이유다. 완벽한 성공 다는 최선에 가까운 반정도의 성공(?)을 기대 수밖에 없는데 결국 경험이다. 성공은 경험에서 나오고 경험은 실패에서 나온다는 말을 누가 했더라.