지금까지 개발을 하며 느낀 생각들
개발에 관한 생각들
Hacker News 에서 이런 글을 보게 되었습니다. 아마존 엔지니어면서, 꽤 인기있는 오픈소스도 만들고 유지하는 저자가 쓴 6년간 SW개발을 하면서 바뀐 생각들에 관하여 쓴 내용입니다. 다른 면은 아니고 SW 개발 관련 토픽에 관한 내용인데, 읽으면서 공감되는 내용이 너무 많아서 간단히 요약해 봤습니다. 원문은 짧고 간결하지만 이유까지는 적지 않았기 때문에, 제가 개인적으로 느낀 내용들에 대해서 추가해 보았습니다.
Typed language 의 장점
이건 저도 많이 공감하는 내용인데, 큰 규모의 프로젝트로 갈수록 typed language의 필요성을 많이 느끼게 됩니다. 개발 할 때는 좀 더 신경써서 해야 하지만, 그만큼 안정성이 훨씬 높습니다. 저는 원래 C++/Java 계열로 프로그래밍 했었는데, 그러다가 Python을 접하고 그 자유도와 직관성에 놀랐고 다시 프로그래밍이 너무 재밌다고 느꼈었습니다. 그렇지만, Python으로 규모가 있는 프로젝트를 할 수록 static typing의 중요성을 뼈저리게 느끼고 있습니다. (물론 3.4 버전 부터 static typing기능을 지원하긴 합니다.)
스프린트 운영과 관련된 것
해당 글에서는 약간의 장점, 약간의 단점에 관해서 언급했는데 스프린트 운영은 단지 정해진 대로 하는 것이 중요한게 아니라 해당 팀의 환경이나 특성에 맞추어가는게 중요하다고 생각합니다. 저도 여러 팀을 거치면서 스탠드업 미팅이나 회고 시간이 시간낭비가 되는 경우를 많이 봤기 때문에, 이런 것들을 최대한 잘 조절해 가면서 항상 어떻게 하면 더 효율적으로 할 수 있을까를 많이 고민하게 되었습니다. 따라서, 정답은 없으며 다양한 시도를 통해 팀에 가장 잘 맞는 방향으로 하는게 맞는 것 같습니다.
SW 아키텍쳐의 중요성
다른 모든것보다 SW 아키텍쳐를 잘 잡는게 중요하다고 이야기 하고 있습니다. 아키텍쳐가 잘 잡히면 구현을 좀 못해도 별 문제 없지만, 이게 잘못되면 다른 것들이 다 망가진다는 이야기입니다. 저도 아주 동감하는 내용입니다.
Java는 그리 나쁜 언어가 아니다
Java가 광범위한 인기를 끈 후 그 단점을 분석하고 보완하는 다양한 언어가 나왔습니다. 저도 Java는 단점이 좀 있긴 해도 아직도 많이 발전중이고 좋은 언어라고 생각합니다. 다만 요즘에는 안드로이드와 백엔드 진영이 Java 대신 Kotlin을 많이 사용하는 추세이긴 하고, 다른 JVM 기반 언어들도 열심히 경쟁중이니 어떻게 될지 궁금하네요.
똑똑한 코드보다는 명확한 코드
이것도 꽤 동감가는 내용인데요, 한 명의 슈퍼스타가 뛰어난 코드를 만드는 시대는 지나간 것 같습니다. 많은 경우 최적화가 많이 되었지만 알아보기 힘든 코드보다는 명확하고 유지보수도 쉬운 코드가 더 좋은 경우가 많습니다. 물론 케바케이긴 하겠지만요.
나쁜 코드는 어떤 패러다임에서도 나올 수 있다.
함수형 패러다임과 같은 다양한 프로그래밍 패러다임이 있지만, 함수형 프로그래밍이 만병통치약은 아닙니다. 그게 중요한게 아니라 적재적소에 어떻게 잘 활용하는지가 중요하겠죠.
"Best Practice" 에 관해서
일반적으로 많은 기업들이 Best Practice라고 불리는 것을 따라갑니다. 하지만, 이건 상황마다 다르기 때문에 아무 생각없이 그것을 따라 가는 것은 개발자의 실력 향상에도 도움이 안 될 뿐더러, best 가 아닌 경우도 많습니다. 무작정 구글, 페이스북, 아마존이 한 베스트 프랙티스다! 하면서 따라하는게 아니라 항상 제품/서비스의 상황을 고려하여 설계하고 구현할 필요가 있을 것입니다.
필요도 없는데 Scalable System 을 만드는 것은 뻘짓
이것도 꽤 동감가는 이야기 입니다. 많은 엔지니어가 (특히 뛰어날수록) over engineering에 대한 욕구가 있습니다. 이게 나쁜 것은 절대 아닙니다만, 상황에 맞는 기술 선택과 설계가 중요할 것입니다. 또한, 필요도 없는데 너무 scalability 를 많이 고려하면 개발 효율성이 떨어지는 경험을 할 수도 있습니다. "scalable" 은 마법의 단어처럼 많은 선택을 정당화 하는데 쓰이는 경우가 많습니다만, 적정 기술을 사용하는게 중요할 것입니다. 중요한 것은 사용자이지 기술 자체가 아니니까요.
일반적으로 RDBMS가 NoSQL보다 낫다
저는 뭐가 더 낫다고 생각하지는 않고, 우리는 빅데이터니까 NoSQL 을 써야해! 라던가 NoSQL이 더 트렌디하잖아! 하면서 쓰는 회사들이 있어서 나오는 이야기 같습니다. RDBMS와 NoSQL 모두 장단점이 있기 때문에 깊이 이해한 후 정형화된 데이터라면 RDB를, 정형화되지 않은것이 많다면 NoSQL 계열을 선택하는 등 적절하게 부분 별로 맞는 기술을 선택하는게 제일 중요할 것입니다.
펜과 종이는 최고의 프로그래밍 툴이다.
이것도 꽤 동감가는 내용이었습니다. 저도 항상 노트북 옆에 펜과 종이가 있고, 설계를 하거나 알고리즘을 만들 때 마다 사용하고 있습니다. 저만 그런게 아니라는 점이 재밌네요.
Purity / Practicality 의 trade-off
함수의 순수성을 지키는 것에 관하여 집착하는 경우가 많은데요, 이런 것은 프로그래밍 기본 철학 중의 하나이기 때문에 특히 코드 리뷰 등을 할 때 걸고 넘어지는 경우도 있습니다. 하지만 우리가 해야 할 것은 적절한 시간 내로 적절한 제품을 만드는 것이기 때문에, 로직의 완벽성보다는 실용성에 중점을 둘 필요가 있습니다.
그냥 새로운 기술을 추가하는 것은 일반적으로 좋지 않은 선택이다
저도 개인적으로 많이 느낀 것인데, 어떤 목표를 달성하기 위해서 그냥 새로운 기술을 추가하거나 접목하는 것은 해결책이 되지 못하는 걸 많이 느꼈습니다. 엔지니어들이 기술에 과몰입 되는 경우가 꽤 있는데요, 많은 경우 기술을 추가한다고 문제가 해결되지는 않습니다.
YAGNI > SOLID > DRY
YAGNI (실제로 필요로 할 때 구현하는 것), SOLID (OOP의 설계원칙) , DRY (반복을 지양하는것) 의 순서로 중요하다고 이야기하고 있습니다. 즉, 이 말은 기술의 완성도에 집착을 하기보다는, 고객이 필요로 하는 서비스를 적절한 시간 내로 적절하게 만드는 것 (실용성) 이 중요하다는 이야기라고 보면 될 것 같습니다.
고객과 직접 이야기하는 것의 중요성
많은 경우 고객과 직접 이야기 하는 것이 문제 해결을 더 적은 시간에, 더 정확하게, 더 잘 해결할 수 있다고 이야기 하고 있습니다. 당연한 이야기입니다.
코딩 스타일, lint rule, 그 외 자질구레한 것에 집작하는 것에 대해
코드리뷰를 할 때 가끔 이런 케이스가 있는데요, 이런 것은 자동화 툴이 알아서 해줄 일이지 로직에 큰 영향을 끼치지 못합니다. 물론 팀 내의 스타일이나 룰을 정해놓는 것은 중요한 일입니다만, 이런 것을 굉장히 strict 하게 하는 것도 문제가 있다고 생각합니다.
code coverage 와 static analysis에 관해
원문의 저자는 code coverage 가 코드 퀄리티와 아무런 상관이 없다고 말하고, static analysis 는 유용하다고 말했습니다. 저도 이걸 보며 나만 그렇게 느낀 게 아니구나 하는 생각이 들었습니다. 물론 code coverage 도 유용한 경우가 있습니다만, 이런 것에 집착할 필요는 없다고 생각합니다. static analysis는 여러가지 다양한 서비스도 많고 오픈소스도 많은데, PR 마다 static analysis를 하는 것만으로도 꽤 많은 잠재 버그를 찾거나 퍼포먼스 개선을 할 수가 있습니다.
모놀리딕 시스템에 관해서
Microservice architecture 가 요즘 트렌드인데요, 당연하게도 장단점이 있습니다. 인터넷에 보면 마이크로서비스의 장점을 설명하는 글이 많지만 그에 못지않게 단점에 관한 글도 많습니다. 원문의 저자는 모놀리딕이 일반적으로 좋다고 이야기 했는데, 어느정도는 동감하는 내용입니다. 물론 팀이나 회사의 규모에 따라 MSA가 유리한 경우도 많습니다. 그리고 두 가지 방식을 어느정도 적절히 혼합해 사용하는 것도 괜찮을 것입니다. 정답은 없습니다. 환경과 상황에 맞는 최선의 선택을 하는 것이 중요할 것입니다.
TDD에 집착하는 것에 관해서
원문의 저자는 TDD에 집착하는 사람들이 다른 workflow를 받아들이지 못한다고 까는데요, 사실 저는 이정도로 TDD에 집착하는 사람들은 못 만나봤습니다. 다만, 원문 저자의 글을 보면 SW 개발 철학에 너무 과몰입되어 그런것에 집착하는 사람들에게 많이 데인 것 같은 느낌을 받았습니다. 가장 중요한 점은 개발자가 만들고 싶은 걸 만드는 게 아니라 사용자가 필요한 걸 만드는 것입니다. 개발 철학들은 물론 중요합니다만, 사용자가 필요로 하는 것을 만들기 위한 도구일 뿐입니다.
"엔지니어" 라고 불리지만 대부분의 결정은 그것을 뒷받침할 분석도, 데이터도, 숫자도 없다.
저도 많이 동감하는 내용입니다. 사실 자신의 결정이나 논리를 뒷받침하려면 데이터와 분석이 있어야 합니다만, 많은 경우 우리는 이런 것 없이 결정을 내리는 경우가 많습니다. 저도 최대한 데이터 기반 결정을 내리려고 노력합니다만, 속도가 중요한 스타트업 환경에서는 이게 쉽지 않은 경우가 많은 것 같습니다. 물론 급변하는 비즈니스 환경에서는 다 장단점이 있기는 합니다.
사실 어떻게 보면 당연한 내용이라고 할 수도 있겠습니다만, 저도 일하면서 많이 느꼈던 내용들입니다. 프로그램 자체의 높은 순수성이나 완벽성이 중요한 게 아니라, 사용자가 좋아하는 제품/서비스를 만드는 것이 가장 중요할 것입니다. 괜히 많은 성공한 기업들이 사용자 집착을 하는게 아닙니다. 개발자가 가장 중요하게 고려해야 할 점은 기술의 완벽성보다는 사용자가 필요한 것을 "개발" 해 주는 것입니다.
