코딩은 줄이고, 생각은 더 많이 하기... 점진적으로 🔊 (Code Less, Think More… Incrementally! 🔊)

어떻게 Incremental Delivery가 문제를 보는 방식을 변화 시키는가

지난 글에서 Continuous Integration: A Merge Story에 관한 글을 썼다. 이 글에서 나는 Continuous Integration 원칙이 없었기 때문에 6 개월 짜리 프로젝트가 실패 할 수 밖에 없었던 이유에 대해서 설명 했다.
지금 생각해보면 다르게 적용 할 수 있던 몇 가지가 있다:
  • 가능하면 빨리 코드 변경 사항을 모든 사람의 작업에 통합 하는 것. 가급적이면 하루에 여러 번 통합 하는 것.
  • 코딩은 줄이고, 더 많이 생각 하기.
하지만 어떻게 이렇게 할 수 있을까?
개발 프로젝트에선 언제나 필수로 해야하는 도전이 있다. 그건 바로:
젠장, 이건 바뀔거야(Shit is gonna change).
만약에 완료하는데 몇 달이 걸릴 수 밖에 없는 일이 주어 진다면 어떻게 지속적인 통합을 매일 할 수 있을까?
질문에 대한 해답이 실행 가능하지 않다면 유일한 대안은 질문을 바꾸는 것이다.
"대형 프로젝트를 어떻게 완성 할 수 있을까?"라는 질문 대신 "어떻게하면 이 큰 프로젝트를 가장 작은 필요한 기능 단위로 분리 할 수 있을까?"라고 질문 하는게 더 좋다.
Incremental Delivery는 문제를 해결하기 위해 다양한 방법을 살펴 보는 것을 말한다. 그것은 최종 목표를 향해 바로 달려가는 대신 점차 큰 프로젝트를 전달하는 것을 목표로 한다.
이 유명한 만화가 이것을 아주 잘 얘기하고 있다 :
presentation
Incremental Delivery 아이디어를 요약 한 만화. 두 가지 예제가 있는데 하나는 상단에, 하나는 하단에 있다. 상단의 예에는 차를 만드는 4 단계의 "하지 말아야 하는 것(Not like this)"이 있다. 첫 번째 단계는 바퀴를 만들고 두 번째 단계는 새시(chassis)를 만들고 세 번째 단계는 셸(shell)을 만들고 마지막 단계에서 완성된 차를 만든다. 사용자는 마지막 단계를 제외하고 모든 단계에 만족하지 않는다. 하단의 예에는 "해야 하는 것(Like this)!"이 있다. 차를 만드는 5 단계. 첫 번째 단계는 스케이트를 만들고 두 번째 단계는 스쿠터를 만들고 세 번째 단계는 자전거를 만들고 네 번째 단계는 오토바이를 만들고 마지막 단계는 컨버터블 자동차를 만든다. 사용자는 첫 번째 단계에선 만족스럽지 않지만 두 번째 단계부터는 행복해질 것이다. 사용자 입장에선 위의 예제의 결과 보다 아래 예제의 결과에 대해서 더 만족 할 것이다.
하지만, 이 만화에서는 몇 가지 명확하지 않은 부분이 있다.
먼저, 상단의 예제에선 최종 자동차 모습은 컨버터블 차가 아니다. 그 이유는 어쩌면 그녀(또는 그)의 남편이 처음 자동차를 주문 했을 때 그들은 일반적인 차를 원했을 테지만, 개발 도중에 차 주인이 이혼을했고 마음이 바뀌었기 때문일 수도 있다. 그는 마음을 바꿔 컨버터블 차가 갖고 싶어 질지도 모른다.
첫 번째 예제에서 개발자는 이미 "큰 프로젝트"의 전체 그림을 생각하며 시작했다. 휠은 컨버터블이 아닌 모델 용으로 특별히 제작되었기 때문에 중간에 변경 될 가능성은 없다. 사용자는 그들이 주문했던 차를 받을 것이다. 비록 그들이 원한 차가 아니더라도.
결국, 차 주인은 "어쩔 수 없이" 행복 할 것이다.
두 번째 예제에서는 자동차를 만드는 것을 목표(solution)로 하기 보다는 더 빨리 움직이는 문제(problem)에 집중 했기 때문에 프로세스 전반에 걸쳐 다양한 변경 가능성이 있었다. 개발자들은 차 주인의 예상치 못한 결혼 생활 때문에 컨버터블 카를 만들게 됐다. 결국, 차주인은 그들이 요청한 것이 아닌, 원하는 것을 받을 수 있게 됐다.
차 주인은 더 행복 해졌다.
변경 될지도 모르는 일을 처리하는 가장 좋은 방법은 나중에 필요할 수도 있는 것을 추측하는 대신 필요한 것의 최소 한도를 개발하는 것이다.
만화에는 명확하지 않은 부분이 또 있다.
첫 번째 예에서는 자동차를 만드는 데 총 4 단계가 필요했다. 그러나, 아래의 예에선 컨버터블 차를 만드는 데 총 5 단계가 소요 됐다.
Incremental Delivery이 실제론 "더 빠른" 것은 아니라는 것을 보여준다. 기술적인 측면에서 "속도"를 더 적은 시간안에 완료 한 작업량으로 여긴다면, Incremental Delivery는 실제로 프로젝트를 완료하는 데 더 많은 시간이 걸릴 수 도 있다!
그러나 "속도"를 가치의 양으로 생각한다면, 무엇인가를 하는 데 더 많은 시간이 소요되지만 그것을 완료하는 데는 더 적은 시간이 걸릴 수 있다. 여기에서의 트릭(trick)은 최종 "큰 프로젝트"가 아니더라도 사용자를 행복하게 만들 수 있는 최소한의 실행 가능한 부분(the minimum viable piece of stuff)을 만드는 것이다.
요구사항은 변경 될 수 있고, 원래의 요구 사항은 쓸모 없게 되버릴 수 있다. 전에도 말했지만:
젠장, 이건 바뀔거야(Shit is gonna change).
우리가 할 수 있는 유일한 방법은 그 사실을 처음부터 받아들이고 그에 따라 계획을 세우는 것이다.
Incremental Delivery는 어떤 솔루션이 아니라 문제를 다루고 일을 줄이고 신속하게 처리 할 수 있게 해주는 것이다.
컨버터블 예제에서 개발자는 사용자가 원하는 것에 신경을 쓰지 않았다. 그들은 그저 올바른 방향으로 문제의 해결 방법을 개선하는 것을 목표로 삼았다.
노트: 이 만화 예제가 현실에 맞지 않다고 생각 할 수 있다 ... 자세한 내용은 이 답변을 참고하자.
이 원칙은 사용자 지향 제품(user-facing product) 개발 뿐만 아니라 거의 모든 프로젝트에 적용될 수 있다.
언제나 작은 부분에 대해 코딩을 하게 된다면, 당신이 해야하는 "큰 일(big task)"에 대한 당신의 비전을 바꿀 수있는 새로운 정보를 발견 할 수 있다. 또한 이것은 필요한 것 이상의 일을 피하고, 문제에 대한 자신의 이해에 변화를 수용하는 방법이기도하다.
당신이 몇개의 암호화폐 거래소에서 일부 구매/판매(buy/sell)를 시작했다고 가정 해보자. 그러나 이러한 거래는 현재 및 미래 판매에서 발생하는 이익/손실을 명확하게 볼 수 없다.
웹사이트를 만들 수 있다.
이 웹 사이트는 유저가 사용하는 모든 거래소의 API에 연결하여 차트를 제공한다. 차트에는 과거 판매에서 얻은 수익이 표시된다. 또한 코인을 지금 팔면 얼마나 이득을 얻을 수 있는 지도 표시된다.
이런 경우에 서버를 만들고, 어딘가에 호스팅을하고, 아키텍처를 계획하고, 차트 작성을위한 일부 오픈 소스 라이브러리를 살펴보고, 테스트 프레임 워크 등을 작성 해야 한다.
이렇게 만드는 데는 오랜 시간이 걸린다!
아니면, 작은 기능을 만들 수 있다.
이 함수는 구매/판매 작업에서 수익을 반환하며 Chrome DevTools에서 바로 실행 할 수 있.
이 경우 거의 아무런 노력 없이도 가치를 제공 할 것이다. 또한 추후에 구축 할 지도 모를 웹 사이트에 이 기능을 재사용 할 수도 있다.
"테스트 프레임워크" 대신에 console.log 문을 추가 할 수도 있다. 기능이 작동하는지 확인하기에 충분해야 한다. TDD를 사용하여 빌드 할 수도 있다!
더 나은 인터페이스를 제공하려면 서버가 필요하지 않을 수 있다. 몇 개의 텍스트 입력(input)이 있는 HTML 파일을 생성하고 파일 시스템에서 로컬로 바로 실행할 수 있다.
정말로 필요할 때 스태틱(static) 서버를 시작하고 HTML만 복사하면 된다.
점진적으로 다리를 만들 수는 없지만 강을 건너는 문제를 보는 방법은 다양하다.
에세이 "The Cathedral and Bazaar"는 오픈 소스에서 Incremental Delivery가 사용됨을 보여 줬다. 이것은 Linux의 개발에 사용되었다. 다음은 발췌 부분다:
Linus는 가장 효과적인 방법으로 공동 개발자(co-developers)로서 사용자를 대하고 있었다.
7. 빠르고, 자주 릴리즈 하라. 그리고 고객의 얘기를 듣자.
— 발췌 "The Cathedral And The Bazaar,” 1999
이 원칙은 결국 "가치있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시켜야 한다."라는 형태로 애자일 선언문으로 발전했다.
점진적 개발(incremental development)을 염두에 두지 않고 처음부터 큰 작업을 빌드하기 시작하면 매우 어려워 질 수 있다. 비록 당신이 코드를 작성한다고해서 그것이 당신이 가치를 창출하고 생산적이라는 것을 의미하지는 않는다.
솔류션을 보는 대신 문제를 살펴보자. 답을 보는 대신, 질문을 해보자.
엔지니어로서 우리는 진행 상황을 열심히 측정하는 경향이 있다. 그러나 우리는 더 똑똑하게 일해야 한다.
즉, 점진적으로 코드를 적게 작성하고 생각을 더 많이 하는 것을 의미한다.
잘못된 바퀴로 시작하지 않는지 확인하자...
...그렇지 않으면 보트를 놓칠 수도 있다.

읽어 주셔서 감사합니다. 의견이 있으면 Twitter, Facebook 또는 Github 에서 저를 찾아 주세요.



원문: