GN⁺: 지루한 기술은 오래된 것이 아닌 성숙한 기술
(rubenerd.com)지루한 기술(Boring tech)의 의미
- NetBSD가 "지루하다"는 것은 최고의 칭찬임
- 시스템 관리자가 원하는 것은 예측 가능성, 놀람이 아님
-
기술이 지루하다는 것은 신뢰성이 높다는 뜻
- 많은 사람이 테스트하고 최적화한 결과
- 예상치 못한 동작이나 문서화 부족 문제 발생 가능성이 낮음
- 문제 발생 시 도움을 받을 커뮤니티나 자료가 존재
기술 환경의 복잡성
- 기술은 단독으로 존재하지 않으며 다양한 시스템과 상호작용 함
- 구성 요소가 많을수록 예기치 않은 문제가 발생할 가능성 증가
- 신기술이 항상 최선이 아니며, 검증된 안정적인 기술이 더 나은 선택이 될 수 있음
- Kubernetes 클러스터를 몇 개의 가상 머신으로 대체하고 안정성을 높인 사례 가 존재
"지루한 기술"에 대한 반론과 해석
-
Robert Roskam의 주장
- "지루한" 기술 = 오랫동안 존재해 온 기술이라는 가정은 틀릴 수 있음
- 보편성이 곧 이해도를 보장하는 것은 아님
- 오래된 기술이 항상 유지보수 가능한 것은 아님 (예: COBOL 시스템)
-
반박
- 오래되었다고 지루한 것이 아님 (예: Oracle은 복잡하고 유지보수 어려움)
- BSD는 지루한 기술이지만, 리눅스만큼 보편적이지 않음
- 나이가 아닌 성숙도(maturity) 가 중요
결론: 지루한 기술 = 성숙한 기술
- 오래된 기술 ≠ 성숙한 기술
- 성숙한 기술 = 코드, 문서화, 커뮤니티, 운영 경험이 축적된 기술
- NetBSD가 지루하다는 것은 신뢰성과 안정성이 높다는 의미로 최고의 찬사
예전에 긱뉴스에 올라왔던
업계에서 10년 있은 뒤, 마음이 바뀐 소프트웨어 개발 토픽들 (https://news.hada.io/topic?id=19081)에서
Java는 재미없어서 오히려 훌륭한 언어임
라는 글이 생각나네요
Hacker News 의견
-
지루한 기술이 좋다고 생각하는 이유는 제품의 실제 기술에 집중할 수 있게 해주기 때문임. SaaS 앱을 운영하면서 제품과 관련된 다양한 분야에서 최첨단 작업을 하고 있다고 생각함. 데이터베이스나 백엔드 프레임워크 같은 "뒤에서" 작동하는 것들은 최대한 지루하고 안정적으로 유지하는 것을 선호함. 프로젝트를 혼자 작업할 때 시간이 매우 제한적임. 고객이 신경 쓰지 않는 부분을 만지기보다는 제품의 흥미로운 새로운 기능을 개발하는 데 시간을 쓰고 싶음. 고객은 내가 Node 대신 Deno나 Bun을 사용하거나 NPM 대신 pnpm을 사용한다는 것을 알지 못하고 신경 쓰지 않음. 그들은 내 앱이 얼마나 잘 작동하는지, 어떤 기능이 있는지를 알고 있음
-
이 의견에 동의하지만, 개인적인 경험에서 이와 반대되는 관점을 제시하고 싶음. 많은 상황에서 누군가가 자신의 방식, 즉 조직이 개인적인 소프트웨어 선호도를 선택하도록 원할 때 "지루한" 선택이라고 부름. 지루하다고 부름으로써 그들의 _선호_를 대다수가 받아들이는 성숙하고 명백한 결정으로 특징지으며, 다른 것은 단지 소프트웨어 엔지니어들이 반짝이는 것을 쫓는 것이라고 함. 진실은 거의 항상 더 복잡함. 두 가지 솔루션 모두 장단점이 있음. 서로 다른 사람들에게 더 많이 또는 덜 공감되는 가치를 교환함. "지루하고 그래서 당연히 더 좋다"는 주장을 조심해야 함. 깊이 있는 논의 없이 다른 사람의 선호를 자신의 선호로 대체하는 방식이 되어서는 안 됨. 그렇지 않으면 실질적인 주장을 제시하지 않고 논쟁에서 이기려는 다른 오만한 시도와 다를 바 없음
-
"지루한" 기술에 "안정적"이라는 것을 추가하고 싶음. 특히 "안정적"이라는 것이 "충돌하지 않는다"는 의미가 아니라 "변하지 않는다"는 의미임. 일반적으로 오래된, 확립된 것들에서 이를 볼 수 있음. 그러나 이를 보장하는 것은 없음. 이는 종종 기술의 관리자가 특정 행동을 취한 결과임. 이는 종종 하위 호환성 측면에서 설명될 수 있음. 이는 안정성을 얻기 위해 추구할 수 있는 명확한 행동임. 그러나 범위를 크게 제한하는 것으로도 볼 수 있음. 예를 들어, 우리는 규모에 대해 이야기하는 것을 좋아하지만, 결코 보지 못할 규모를 위해 설계하고 구축할 필요는 없음
-
영원한 논쟁은 오래된 것 대 새로운 것, 지루한 것 대 흥미로운 것이 아님. 성숙함은 나이와 상관없이 성숙함임. 종속성을 업데이트할 때 시스템이 깨지거나, 모호한 기본값을 통해 예상치 못한 동작을 도입하거나, 추상화 계층을 탐색하도록 강요하는 시스템은 성숙하지 않음... (Spring과 Java 생태계를 보고 있음), 이는 오래되고 불안정함. 안정성, 예측 가능성, 잘 설계된 단순성이 성숙함을 정의함, 나이만으로는 아님. Python이 성숙하고 지루한가? 도구 체인 문제와 다양한 종류의 골칫거리가 있음... Go나 Rust 같은 새로운 언어는 이러한 도구 체인 문제를 모두 해결하고 최상의 방식으로 진정으로 지루하게 만듦
-
지루한 것은 직장을 찾지 않는 한 좋음. 지루한 기술에 집착하면 점차적으로 직업 시장에서 자신을 제거할 위험이 큼. 다음 고용주는 당신이 훌륭한 비즈니스 가치를 제공했다는 것에 신경 쓰지 않음. 대부분은 반짝이는 새로운 것을 원함. 현재 고용주의 광고를 읽을 때 내가 고용될 것이라고 생각하지 않음
-
GitHub에서 프로젝트가 성숙한 것인지 죽은 것인지 구별하기 어려움. 커밋이 무엇을 위한 것이든, 누군가가 지켜보고 유지하고 있으며, 새로운 문제가 빠르게 해결될 가능성이 있다는 신호임. 이는 새로운 것이 항상 그곳에서 이점을 가질 것임을 의미함
-
지루한 기술을 사용하여 승진하거나 고용된 사람은 없음. 내가 많은 구직 신청에 대한 답변을 받지 못하는 이유는 내가 한 작업의 대다수가 "지루한" 것이고, 내가 작성한 오픈 소스 코드의 대다수가 셸 스크립트이기 때문이라고 생각함. 모든 것이 훌륭하게 작동하고, 버그와 유지보수 비용이 전혀 없지만, 매력적이지 않음. 지적 엘리트주의가 내 역할을 정의했음 ("DevOps Engineer"는 문자 그대로 "클라우드의 시스템 관리자"임, 그러나 우리는 시스템을 관리하는 것을 <i>부끄러워해야</i> 하기 때문에 그렇게 말할 수 없음); 내 이력서가 "Python과 Shell"보다 "Go와 Rust"로 더 많았다면 즉시 고용되었을 것이라고 확신함
-
지루한 기술은 일을 끝내고, 우리가 해결하려는 문제에 집중할 수 있게 해줌, 대신 불필요한 일을 하지 않게 해줌
-
이 주제에 대해 Ask HN을 하려고 했지만, 이 게시물이 내 질문을 하기에 훌륭한 게시물이라고 생각함. 당신이 사용할 수 없을 정도로 지루한 기술은 무엇인가? 얼마나 오래 사용했는가? 나에게는 Vim, C, Python, Fedora, mutt 같은 것들이며 25-30년 동안 사용해왔음. 당신은 어떤가?
-
새로운 기술의 이점이 위험을 능가한다면 그것을 사용함. 도전은 증거를 평가하는 것임. 새로운 기술은 그들의 장점을 자랑하지만, 단점은 그렇게 크게 광고되지 않으며, 투자를 한 후에 종종 발견됨. "지루한" 또는 "흥미로운"은 잘못된 프레이밍임