더 빨리 움직이면서 느려지는 우리를 위해서, 클린코더의 교훈
시작하며:
소프트웨어를 개발하는 우리는 종종 “빨리가는 것”과 “품질”을 정반대의 개념이라고 생각하는 경향이 있습니다.
빨리간다는 것은 속도의 정도(Amount)를 가지고 품질이라는 것 또한 품질의 정도(Amount)를 가지고 있는데 말이지요.
우리는 "빨리가면 품질을 희생해야"하고 "품질을 희생해야 빨리가는 것"이라 너무 쉽게 단정짓고 다음 과제에 뛰어듭니다.
모든 팀은 목적을 달성하기 위해서 노력을 하고 최선을 다해 움직입니다.
하지만 일부는 더 많이 노력할 수록 느려지고, 일부는 더 많이 노력할 수록 빨라집니다.
물론 노력과 지속함은 중요합니다만 단순히 이 두 가지가 팀의 속력을 결정하지 않습니다.
소프트웨어의 품질하면 "클린코드"라는 개념이 떠오릅니다.
클린코드는 단순히 좋은 관례, 좋은 가치 이상의 의미를 갖는 것으로 생각됩니다.
저는 클린코드가 사실상 우리의 속도를 표현한다고 생각합니다.
클린코드를 실천하며 키우는 효율적이고 지속 가능한 개발 프로세스가 우리의 속도를 결정할 것 입니다.
(**클린코드를 달성하는 것이 아닌 가꾸는 것으로 표현했습니다.)
그래서 오늘은 클린코드를 끊임없이 강조해온 로버트 C. 마틴의 2014년 예일 경영대학원 강연[1] 중 일부를 변역해서 공유드립니다. 글을 통해 우리 팀의 엔지니어링을 점검해보는 기회가 될 수 있기를 희망합니다.
번역본:
경력이 많은 분들 중에 혹시 나쁜 코드 때문에 일이 지연된 경험있으신 분, 손 한번 들어주시겠나요?
음.... 아직 젊은 분들은 손을 들지 않았네요.
그러면 경력 초기이신 분들에게 그럼 질문드리겠습니다.
혹시, 본인이 작성한 나쁜 코드 때문에 일이 지연된 경험이 있으신 분 있을까요?
나쁜 코드가 우리를 느리게 만든다는 것은 모두가 잘 알고 있습니다.
그런데도 우리는 그런 나쁜 코드를 왜 작성하는 거죠?
우리는 왜, 우리를 느리게 하는 코드를 작성하는 걸까요?
나쁜코드로 인해 얼마나 느려지죠? 정말 많이 느려집니다.
어떤 모듈을 만질 때마다 우리는 다시 한번 느려집니다.
나쁜 코드를 건드릴 때마다 우리는 또 다시 느려집니다.
"스스로를 느리게 만드는 코드를 왜 작성하고 있는건가요?" 라고 물으면 답변합니다.
“물론 빨리 가야 하기 때문이죠!" --이 논리적 모순에 대한 결말은 여러분에게 넘겨드리겠습니다.
오늘 제가 전달드리고 싶은 메시지는 이렇습니다.
엉망인 코드를 작성하면서 빨리 갈 수 없습니다.
서둘러 움직여서도 빨리갈 수 없습니다.
허겁지겁 코드를 작성하고, 정말 동작"만"하는 그런 제품을 만들고 가능한 한 빨리 배포하는 것이 빨리가는 것이 아닙니다.
빨리 가고 싶다면 잘해야 합니다.
선생님이 오래전에 이런 말씀을 하셨죠?
빨리 가고 싶다면 잘해야해! 라고요.
빨리 가고 싶다면 문제를 연구하고, 문제에 시간을 들여야 합니다.
빠르게 움직이기 보다는 신중하게, 의도적으로 움직여야 합니다.
정신없이 서두르기만하는 프로그래머는 결국 빨리갈수 없습니다.
신중하게 앉아 생각하다 코드 몇 줄 작성하고, 다시 또 코드를 살펴보다, 다른 것들도 조금씩 정리하면서 신중하게 프로그래머가 결국 빠르게 갑니다
- from 로버트 C. 마틴, “객체지향의 SOLID 원칙과 애자일 디자인” 강연 at Yale, school of management, 2014
원문 (영어):
How many of you of the old guys have been slowed down by really bad code?
And the young guys don't have their hands in the air right now.
How many of the young guys been slowed down by really bad code that you wrote, yesterday?
Yeah, we know the bad code slows us down.
Why did we write it?
Why do we write the code that slows us down?
How much does it slow us down?
It slows us down a lot.
And every time we touch the modules, we get slowed down.
Again, every time we touch the bad code, it slows us down.
Why do we write this stuff that slows us down?
And the answer to that is, "Well, we have to go fast".
I will leave you to deal with the logical inconsistency there.
My message to you today is this.
You don't go fast by writing crap.
You don't go fast by rushing.
You don't go fast by tearing through the code and just making it work and releasing it as fast as you can.
If you want to go fast, you do a good job.
Your grandmother told you this a long time ago, right?
If you want to go fast, you do well.
You take your time, you study the problem, you move deliberately, instead of rapidly.
A programmer who goes fast, a programmer, who is rushing like crazy, is guaranteed to go slow.
A programmer who sits carefully and thinks about it and types a few characters and looks at the code and cleans it a little bit and does this and that?
And he'll go fast
- from Robert C. Martin, “SOLID Principles of Object Oriented & Agile Design” lecture at Yale, school of management, 2014
마치며:
우리는 종종 빠른 결과를 추구하며 기본적인 원칙들을 잊곤 합니다.
심지어 이미 품질과 속도가 정반대의 개념이 아니라는 것을 알고 있습니다.
하지만 이해한 것과 믿는 것의 차이는 정말 위급한(Critical) 상황에서 드러납니다.
빨리 움직이지만 느려지고 있다면 이제 믿어야하는 시점이 된 것 같습니다.
품질과 속도는 사실 함께 가는 것이라는 것을 화끈하게 믿어버리고 다음 과제에 뛰어들어 보는 것을 추천드립니다.
의지가 될만한 가벼운 예시로 IT 공룡 Amazon은 2014 기준 1년간 개발환경, 운영환경 모두 포함해서 5천만번의 배포[2]를 했다고 합니다.
1년에 5천만번이면 1초에 1.6회 씩 배포하는 비현실적인 속도입니다.
하지만 그 누구도 Amazon의 소프트웨어 품질이 떨어진다고 생각하지 않습니다.
진정한 효율성과 속도는 신중함과 품질에서 나옵니다.
우리의 팀 모두 빨라질 수 있기를 희망합니다.
References:
[1] “SOLID Principles of Object Oriented & Agile Design” lecture by Robert C. Martin, at Yale school of management, 2014
[2] “The Story of Apollo - Amazon’s Deployment Engine” blog by Dr. Werner Vogels, CTO of Amazon, 2014