빨리 만드는 게 제일 중요해 ^^
잘 만들 필요가 있을까?
빨리 만드는 것이 중요하다.
최근 위와 같은 이야기를 많이 들었다.
다양한 시도를 많이 하고, 빨리 피드백을 받아서 서비스를 성공시키기 위해서 빨리 만드는 것이 중요하다는 것이다. 이 말은 나도 적극 공감하는 말이다. 프로젝트 초기에 과도한 설계나 예외 상황 파악에 지나치게 시간을 들이는 것보다는 작은 기능이라도 피드백을 받을 수준으로 빨리 개발하는 것이 좋다고 생각한다. 이런 생각은 애자일에서 기인했고, Robert C. Martin이 한 다음과 같은 2가지 의견에 공감하기 때문이다.
1. 우리는 미래를 예측할 수 있는 마법의 구슬(Crystal Ball)이 없다.
우리의 예상은 틀릴 수 있다. 머피의 법칙처럼... 우리가 준비한 일은 안 일어나고, 우리가 대비하지 못했던 변경만 일어난다. 이런 변화를 예측할 마법의 구슬은 우리에게 없다. 도널드 럼스펠드 전 미국 국무장관은 세상에는 2가지 unknowns가 있다고 했다. known unknowns와 unknown unknowns가 그것인데, 우리는 마법의 구술이 없기 때문에 요구사항을 확정하고 이후의 변경을 불허하는 전략을 취할 수 없다는 것이 Robert C. Martin의 공감 가는 의견이다.
2. 요구사항을 작성하는 기획자는 그것이 구현되어 사용할 수 있을 때만이 진정으로 자신이 원했던 것인지 알 수 있다.
이 그림이 생각나는 분들이 많이 있을 것이다. 실제로 사용해 보기 전에는 자신이 원하는 것이 명확히 알기 어렵다. 특히 지금처럼 빠르게 만들어야 하고, 다양한 기술이 변화하고 있는 상황에서는...
그런데 이런 기운이 지나치게 강조되다 보니
잘 만들 필요가 없다
는 얘기도 많이 듣는 상황이 된 것 같다.
어차피 90% 이상은 실패해서 버려야 하는 코드이니 잘 만드려 노력할 필요 없이 빨리 만들기에 집중하자. 10% 미만으로 성공하게 되면 그때 다시 만들면 되는데, 다시 만드는 일은 내 일이 아닐 것이니 깨끗이 만들지 않아도 된다.
이런 얘기를 듣게 되었다.
이런 생각에 나는 동의할 수 없다. 2가지 이유에 기인한다.
1. 시간이 없어서, 빨리 만들기 위해 더럽더라고 빨리 만든다.
자동화된 빌드, 테스트, 배포 환경을 갖는 것은 모든 개발을 하기 위해서 반드시 필요한 일이다. 이 중 제일 어려운 것은 자동화된 테스트일 것이다. 이런 것이 없다면 매번 빌드, 테스트, 배포를 수작업으로 하게 되어 속도가 안 나게 된다. 서비스 오픈 전에 얼마나 많이 빌드, 테스트, 배포해야 할까? 이런 게 자동화 안되었다면 얼마나 느리게 개발하게 될까?
빌드, 배포는 여러 가지 자동화된 기술들이 많이 나와 있고, 어렵지 않게 적용할 수 있다. 하지만 테스트는 사람의 노력과 기술이 필요한 부분이다. 자동화된 테스트가 없다면 늘 서버에 배포해 놓고 눈으로 확인하는 더딘 작업이 수반될 것이다. 테스트가 늦게 수행되어 버그가 늦게 발견된다면 더 많은 버그 수정 비용이 발생한다. 빌드 때마다 자동화된 테스트가 수행되어 버그를 일찍 발견하였다면 더 적은 비용으로 버그를 수정할 수 있다.
한 번만 테스트를 한다면 자동화를 위해 노력하는 것보다 한번 수작업으로 하는 것이 효율적일 것이다. 하지만 테스트는 매우 많이 반복적으로 수행되어야 한다.
테스트를 작성할 시간이 없어서 후에 테스트를 수작업으로 한다면 더 느려질 것이다. 테스트를 적게 하거나 안 할 수는 없으니...
테스트부터 구현하는 것이 왜 시간이 오래 걸릴까? 원래 그럴까? 아님 실력이 부족한 것은 아닐까? 후자가 아닐까? 시간이 부족해서 테스트를 안 만든다는 사람에게 시간을 주면 자동화된 테스트를 정말 잘 만들 수 있을까? ㅎㅎ 아닐 것 같다. 알고 있다고 생각하고, 할 수 있다고 생각할 수는 있지만 실제로 해 보면 아닌 것을 발견하게 될 가능성이 높다. "아는 것", "할 수 있는 것", "하는 것" 모두 다른 것 같다.
2. MVP(Minimum Viable Product)에 어긋난다.
작은 기능이라도 완품으로 만들어서 피드백을 받고, 이를 기반으로 다음 기능을 완성해 나가는 방향으로 진행하는 것이 MVP에 적합하다고 생각한다.
MVP는 위 그럼에서 하단과 같아야 한다고 한다. 즉 가장 빨리 완품을 만들어서 피드백을 얻고, 이를 기반으로 변경하여 뭔가 더 나은 상품을 지속적으로 만들어 나가야 한다.
이렇게 개발하기 위해서는
계속 바꿀 수 있어야 한다. 바꿀 수 있으려면 유지 보수할 수 있도록 잘 만들어야 한다.
이 그림이 벤처, 애자일 등을 말하면서 깨끗하게는 필요 없고, 빨리만 만들면 된다고 말하는 것이 앞뒤가 안 맞는 이유인 것 같다.
여담으로 같이 일하는 어느 개발분과 이런 주제에 대해서 이야기를 나눌 때, "30대까지만 개발할 것이라면 모르지만 40대 이후에도 계속 개발하려면 깨끗하게 개발할 줄 알아야 한다"고 하시는 말씀을 들었다. 40대 이후 아니 50, 60대까지 개발자로 살려면 깨끗하게 개발하는 역량이 필요한 것 같다.
나는 풀 스택 개발자가 아니고 특히 프런트(HTML, Javascript, CSS, Android, iOS 등)가 약해서 전체를 빨리 만들지는 못한다. 고작 빨리 할 수 있는 것이 백엔드 서버일 것이다. 그것도 node, RoR, scala, playframework 등에 비해만 훨씬 느린 java, spring, spring-boot 등을 이용하는 것을 잘한다. 내 역량이 이리 부족하다 보니 이 글에 적는 내 생각이 다 맞는 것은 아닐 것이다. 그럼에도 불구하고 내 생각을 정리해 보았다.
