Hype Driven Development

설레발 주도 개발

이 글은 Hype Driven Development 를 번역한 글입니다. 설레발 주도 개발은 임의로 붙인 단어입니다. 더 적절한 단어가 있으면 제안해주세요.

소프트웨어 개발 팀들은 자주 소프트웨어 구조 설계나 기술 스택을 결정합니다. 제대로 된 연구나 자신들의 프로젝트에 미치게 될 영향에 대한 진지한 고려 대신에 잘 알지도 못하는 오지랖, SNS, 소위 "핫"하다는 대세에 기반해서요. 저는 이런 경향을 설레발 주도 개발이라고 부릅니다. 그런 것의 해로움을 감지하고 더 전문적인 접근을 선호하는 것은 "견고한 소프트웨어 공학"이라고 부르고요. 이제부터 이것들이 어떻게 작동하고, 대안은 어떤 게 있는지 살펴봅시다.

새로운 기술 - 새로운 희망

혹시 어떤 팀이 가장 핫한 최신 기술을 프로젝트에 적용하는 과정을 본 적 있나요? 먼저 누군가가 블로그에서 글을 읽습니다. '이게 트위터에서 유행중이고 우린 방금 이거에 대한 컨퍼런스에서 엄청난 이야기를 듣고 돌아오는 길이야' 곧 이 팀은 그 빛나는 최신 기술(혹은 소프트웨어 설계 패러다임)을 사용하기 시작합니다. 하지만 신기술이 약속했던 더 빠른 생산성이나 더 나은 결과물을 얻게 되는 대신 곧 문제에 직면하게 됩니다. 그들의 개발 속도는 느려지고, 의욕은 점점 사라지고, 다음 버전을 내놓는 데에 문제가 생깁니다. 어떤 팀들은 버그를 고치는 데 급급해서 새로운 기술을 개발할 틈조차 없게 되기도 합니다. 이 문제들을 모두 해결하는 데에는 늘 '며칠만 더 일정이' 필요합니다.

설레발 주도 개발

설레발 주도 개발(Hype Driven Development - HDD)은 당신의 프로젝트에 다양한 방법으로 영향을 끼칩니다.

  • 레딧 주도 개발 - 팀, 혹은 개인이 기술적/구조적/설계 결정을 내릴 때 유명한 블로거의 글이나 레딧, 해커뉴스, 블로그, 트위터, 페이스북, 깃헙, 기타 SNS 등지에서 핫한 것에 기반을 두고 선택합니다.
  • 컨퍼런스 주도 개발 - 컨퍼런스에서 갓 돌아온 사람들에게 어떤 일이 일어나는지 유심히 살펴보세요. 사람들은 뭔가에 뽕이 차오른 상태입니다. 뽕은 양날의 검이죠. 충분한 고려 없이 새롭고 핫한 라이브러리/프레임워크/구조 설계 관점을 도입하는 것은 요단강 익스프레스의 티켓일 수도 있습니다.
  • 목소리 큰 놈 주도 결단 - 어떤 놈이 하루 웬종일 이 프레임워크/라이브러리/기술 에 대해 쉴 새 없이 떠들어댑니다. 물론 그 놈이 딱히 그걸 해 본 경험이 있는 것은 아니지만 귀에 딱지가 앉도록 떠든 결과 팀은 그 프레임워크/라이브러리/기술을 사용하기로 결정합니다.
  • 젬/라이브러리/플러그인 주도 개발 - 특히 루비 온 레일즈 커뮤니티에서, 가끔 아주 긴 젬 파일을 보곤 합니다. 그 젬 파일보다 긴 거라곤 오직 그 젬 파일을 로딩하는 데 걸리는 시간 뿐이죠. 이건 레일즈의 모든 문제를 반드시 젬으로만 해결해야 한다는 생각에서 발생하는 현상입니다. 어떤 건 그냥 두어줄만 코드에 추가하면 해결되는 문제인데도요. 하지만 우린 모든 문제를 라이브러리를 추가하거나, 플러그인을 깔거나, 젬을 받거나 프레임워크를 도입해서 해결하려고만 하죠.

  • 그리고 설레발 주도 개발만큼이나 유명한 행태에 대해서도 짚고 넘어가야 할 것 같습니다. 지식인 주도 개발 - 개발자들이 스택 오버플로(혹은 그냥 인터넷 아무데서나)에서 제대로 이해하지도 않은 코드를 그냥 복붙해 오는 방법론입니다.

HDD 는 팀을 어떻게 스스로 파멸시키는가

설레발의 문제점은 나쁜 결정을 내리도록 유도하기 쉽다는 것입니다. 설계 관점의 결정이건 기술 스택 결정이건 일단 잘못된 결정을 해버리면 팀 전체를 몇 달이고 몇 년이고 괴롭히곤 합니다. 최악의 경우 소프트웨어 엔지니어링에서 벌어질 수 있는 또 다른 아주아주아주 더러운 문제에 맞닿뜨리게 됩니다. 전부 뒤집어 엎고 다시 짜는거죠. 보통 이런건 망하게 마련입니다.

모든 악의 근원은 소셜 미디어인 것 같습니다. 새로운 아이디어가 테스트가 끝나기도 전에 잽싸게 전파되는 곳이죠. 사람들이 그것의 장단점에 대해 이해하는 것보다도 훨씬 빠르게 말이죠.

설레발 해부

대부분의 설레발은 비슷한 구조를 가지고 있습니다.

1단계: 진짜 문제와 해결책

그들은 문제가 있는 회사에 있습니다. 회사의 한 팀이 이 문제에 대한 해결책은 현재의 기술 스택이나 구조를 넘어서는 일이라 판단합니다. 회사는 새로운 프레임워크나 라이브러리, 혹은 패러다임을 만들어 곧 그 문제를 해결합니다.

2단계: 발표, 자랑질, 키워드

이 팀은 넘나 신나서 그들의 결과물을 세상에 보여주고, 블로그에 포스트를 싸지르고 컨퍼런스에 가서 약을 팝니다. 대부분의 경우 그들이 해결한 것이 제법 중요한 문제였기 때문에, 이런 중요한 문제에 대한 인상적인 해결책을 자랑스럽게 뽐내죠. 사람들은 이 신기술에 흥분합니다. 문제는 이 흥분한 사람들이 모두 이 솔루션으로 해결할 수 있는 문제가 정확히 뭔지, 이 솔루션의 자세한 내용이 뭔지 이해하고 있 지는 않다는 것입니다. 이건 말 그대로 중요한 문제에 대한 중요한 해법입니다. 트윗 한 번, 채팅 한 번, 블로그 포스팅 하나 가지고 설명할 수 있는 게 아니죠. SNS, 블로그, 컨퍼런트의 대화 세션등으로 핵심적인 메시지는 흐려집니다.

3단계: 빠돌이 탄생

모든 설레발 주도 개발자들이 블로그 글을 읽고 컨퍼런스에 참여했습니다. 곧 세계 전역의 많은 팀들이 새로운 기술을 사용하기 시작합니다. 흐릿한 메시지 때문에 몇몇 팀은 성급하게 이 신기술 도입을 결정합니다. 심지어 이 기술이 팀의 실제 문제를 전혀 해결해주지 못하는데도 말이죠. 그 팀은 아직은 이 신기술이 자신들의 문제를 해결하는데 도움이 될 거란 기대를 가지고 있습니다.

4단계: 실망

스프린트가 계속되면서, 이 신기술은 사람들이 기대했던 것 만큼 팀에 도움이 되질 않고 오히려 더 일을 늘리기만 합니다. 더 많은 학습이 필요하고 코드는 수없이 재작성됩니다. 팀은 지치고 관리자는 빡칩니다. 사람들은 속았다는 느낌을 받게 됩니다.

5단계: 현실 인식

마침내 팀은 뒤를 돌아보고 새로운 기술 도입에 따른 대가가 무엇이었는지, 이게 대체 뭘 위한 기술이었는지를 깨닫습니다. 그들은 드디어 현명해집니다...다음번 설레발이 닥쳐오기 전까지는.

설레발의 예제:

설레발의 몇몇 실례들을 살펴보고 어떤 식으로 진행되는지를 확인해봅시다.

예제 1 : 리액트JS

1단계: 페이스북이 문제에 직면합니다. 페이스북과 같은 복잡한 웹 앱을 만들다 보면 아주 복잡한 상태 관리 이벤트로 정신이 넘나 사납고 어플리케이션 상태가 어떻게 되어가고 있는지를 추적하기가 어렵습니다.

2단계: 페이스북이 함수형, 가상 DOM, 컴포넌트 같은 유행어로 새로운 패러다임 약을 팔기 시작합니다.

3단계: 빠돌이: "페이스북이 새 시대의 프론트엔드 프레임워크를 만들었다! 이제 모든 것들을 리액트로 다시 만들자!"

4단계: 아주 많은 일들이 진행되지만 별다른 성과는 나오지 않습니다.

5단계: 리액트는 실시간 알림이 아주 많은 단일 페이지 웹 앱을 만드는데에 아주 훌륭하지만, 그보다 간단한 케이스에는 딱히 필요 없는 물건이었습니다.

예제 2 : TDD는 죽었다 by DHH

1단계: 데이빗(David Heinemeier Hansson, DHH : 루비온레일즈 프레임워크 개발자)은 레일즈가 객체지향에 적합한 구조가 아니라서 레일즈로 TDD를 진행하기가 어렵다는 걸 깨닫습니다. 따라서 실용적인 관점에서 테스트 작성을 때려칩니다.

2단계: 데이빗의 블로그 글과 컨퍼런스 발표에서 설레발이 시작됩니다. 설레발 키워드는 'TDD는 죽었다'입니다.

3단계: 테스트를 때려치자! 우리 존잘님이 그러셨어! 애초에 테스트 같은 거 쓴 적도 없지만, 이제 테스트 하는 척조차 안하겠다 이거야!

4단계: 잠깐! 왠지 전보다도 더 되는 게 없는데...우리는 버그덩어리 코드를 만들었어

5단계: "TDD는 죽거나 살아있거나 한 게 아님. TDD는 API 변경이나 초보자의 미숙한 기술이나 기존의 설계 등에 대한 리스크를 포함한 기회비용을 대표함." - 켄트 벡

예제3 : 마이크로서비스

1단계: 커다란 단일 어플리케이션은 확장이 어렵습니다. 이걸 여러 서비스로 나눠버리면 초당 요청 처리수의 관점에서나 여러개의 팀의 협업 관점에서나 확장하기 쉬워집니다.

2단계: 설레발 키워드 : 확장성, 느슨한 의존성, 단일 어플리케이션

3단계: 뭐든지 다 서비스로 재작성하자! 우리 코드가 '스파게티 코드'인 건 다 단일 어플리케이션 구조 때문이야! 모든걸 마이크로 서비스로 다시 만들어야해!

4단계: 헐랭! 앱 개발이 넘나 느리고 배포가 엿같은데다 여러 시스템에서 버그를 추적하는게 넘나 빡세..

5단계: 마이크로서비스는 팀에 아주 많은 개발 스킬을 요구하고, 대부분의 경우는 마이크로서비스를 도입하지 않고도 시스템과 팀에 대한 적절한 투자를 통해 확장성을 해결할 수 있습니다. 심각한 확장성 이슈를 맞닿뜨리기 전까지는 마이크로서비스도입은 낭비입니다. 마이크로 서비스는 추출되는 것이지 작성되는 것이 아닙니다. 최소한 그 정도 수준은 되어야 마이크로 서비스를 사용 할 수 있습니다.

예제 4 : NoSQL

1단계: SQL 데이타베이스들은 아주 많은 양의 요청이나 구조화되지 않은 데이터를 처리하기가 어렵습니다. 세계 곳곳에서 새로운 세대의 데이터베이스를 개발하기 시작합니다.

2단계: 설레발 키워드 : 확장성, 빅데이터, 고성능

3단계: 우리의 데이터베이스는 넘나 느리고 규모도 충분히 크지 않아! 우린 NoSQL이 필요해!

4단계: 테이블 조인이 필요한가요? 그런거 없습니다. 단순한 SQL 조작도 커다란 도전이 되어 버립니다. 개발 속도는 점점 느려지고 핵심적인 문제들은 해결되지 않습니다.

5단계: NoSQL 은 아주 특정한 문제들에 대한 해법입니다(아주 많은 양의 데이터, 구조화 되지 않은 데이터, 혹은 아주 많은 처리량 등). SQL 은 실제로 아주 훌륭한 도구이며, 적절하게 사용하기만 한다면 많은 양의 데이터와 높은 처리량을 감당할 수 있습니다. NoSQL 이 반드시 필요한 경우는 2016년 현재까지는 아주 드뭅니다.

예제 5 : 엘릭서와 피닉스(혹은 자신이 좋아하는 언어/프레임워크 짝을 넣어도 됩니다)

1단계: 루비 온 레일즈 같은 웹 프레임워크는 고성능 어플리케이션, 분산처리, 웹소켓 같은 것들에 맞지 않아.

2단계: 설레발 키워드 : 확장성, 고성능, 분산, 결함 내구도

3단계: 오매 시봉탱, 우리의 어플리케이션은 느리고 우리 채팅은 확장성이 없어!

4단계: 헐, 함수형 프로그램이랑 분산 처리 배우는거 생각보다 빡센데. 이제 우린 그냥 느린 게 아니고 개느려...

5단계: 엘릭서와 피닉스는 훌륭한 프레임워크입니다만 배우는 데 많은 노력이 필요합니다. 길게 보면 언젠가 특별히 고성능의 앱을 만들어야 할 때는 도움이 될 겁니다.

목록은 끝도 없이 늘어날 수 있습니다. 이 복잡한 컴퓨터 엔지니어링 업계에는 여러 분야에서 많은 설레발이 판치고 있습니다. 자바스크립트 계에서는 새로운 프레임워크가 매일 쏟아져 나옵니다. Node.js (키워드 : 이벤트 프로그래밍), 리액티브 프로그래밍, Meteor.js(키워드: 공유 상태), 프론트엔드 MVC, React.js. 수도 없습니다. 소프트웨어 공학에서도 새로운 구조들이 탄생합니다. 도메인 주도 개발, 헥사곤, DCI. 어떤 설레발을 제일 좋아하시나요?

우수 사례

그래서, 우리가 인터넷이나 다른 사람들의 의견에 의존해선 안된다면, 어떻게 하면 똘똘한 결정을 할 수 있을까요? 아래에 몇몇 좋은 예시들이 있습니다.

결정하기 전에 연구하고 테스트하기:

  • 스파이크 - 블로그가 아니라 경험을 통해 기술을 배우세요. 결정을 내리기 전에 하루 이틀 정도를 투자해 새로운 기술로 새로운 기능의 프로토타입을 만들어보세요. 팀이 이 기술의 장점과 단점을 분석하게 하세요. 경쟁 관계에 있는 몇몇 기술을 골라서 팀 내에서 각각의 기술로 프로토타입을 만들어 보도록 할 수도 있겠죠.

  • 해커톤 - 해커톤은 팀이 서로 다른 기술의 장단점을 인식할 수 있는 좋은 방법입니다. 하루 이틀 정도를 들여 전체 팀이 떠오르는 매력적인 신기술들을 사용해 보게 하세요. 이를 통해 팀은 자신들의 경험에 기반한 똘똘한 결정을 내릴 수 있게 됩니다.

그럼 대체 언제 적용할까?

  • 원론적인 관점에서, 투자 대비 아주 큰 효과가 기대될 때 입니다. 대부분의 기술들은 어떤 특정한 문제를 해결하기 위해 만들어졌습니다. 그 특정한 문제를 가지고 있나요? 그게 큰 문제인가요? 이 기술을 도입하면 시간을 많이 아낄 수 있나요? 이 기술을 새로 배워서 기존 코드를 갈아 엎는데 드는 비용보다 더 큰 효과를 얻을 수 있나요? 혹시 개발이 두 배로 늦어진다면? 혹시 네 배라면? 그래도 여전히 그만큼 가치가 있나요?
  • 훌륭한 팀은 더 많은 걸 할 수 있습니다. 어떤 팀들은 누구보다 빠르게 남들과는 다르게 새로운 가치를 받아들입니다. 그들은 자신들이 하는 일에 더 쉽게 질립니다. 이런 팀들에게는 새로운 기술을 더 자주 소개할 수 있겠죠. 그렇다고 그게 해커톤이나 스파이크를 안 해도 된다는 뜻은 아닙니다. 다른 경우, 혹시 팀이 새로운 가치를 받아들이는 데 어려움을 겪고 있다면 좀 더 주의깊게 접근할 필요가 있습니다.

올바른 사람을 고용하세요

  • 강력한 기술적 배경은 좋은 신호입니다. 다양한 패러다임을 알고, 프로그래밍 이론을 이해하고(알고리즘, 병렬처리 등), 좋은 엔지니어링 문화를 가진 사람들은 설레발에 영향을 덜 받습니다.
  • 경험 - 설레발은 젊은 개발자에게 더 잘 먹힙니다. 세월이 흐르면 사람들은 많은 기술들을 보고 많은 문제들을 만나면서 기술을 선택하는 데 있어서 더 균형잡힌 시각을 가지게 됩니다.