복잡성의 설계자: 왜 당신의 간단한 작업이 이제는 여섯 스프린트를 필요로 하는가

Source: Dev.to

우리는 모두 그 사람을 만나본 적이 있다. 그들은 단순히 코드를 쓰는 것이 아니라 “생태계”를 만든다. 사무실 간식을 추적하는 간단한 CRUD 폼을 요청했는데, 갑자기 이벤트‑드리븐 마이크로서비스, 쿠버네티스 클러스터, 현재 네 줄의 데이터만 보유하고 있는 데이터베이스를 위한 맞춤형 GraphQL 래퍼가 왜 필요한지에 대한 3시간짜리 회의에 끌려 들어가게 된다.

이 사람이 바로 복잡성 아키텍트다. 그들은 비즈니스를 위해 만드는 것이 아니라, 자신의 지성을 위한 기념비를 만든다.

과잉 엔지니어링을 하고 있는 사람의 징후

• 아직 요청되지도 않은 기능에 대해 수십 개의 새로운 추상화를 포함한 PR을 만든다.
• “디커플링”을 지나치게 강조해서 실제 로직이 어디에 있는지조차 찾을 수 없게 만든다.
• 앱 사용자는 열두 명이고 그 중 세 명은 QA 팀일 뿐인데도 “스케일”이라는 단어를 가장 좋아한다.

왜 이것이 팀을 망치는가

복잡성은 매일 이자를 내는 부채다. 불필요한 코드 한 줄마다 테스트, 보안, 그리고 “다음 큰 프레임워크”가 등장했을 때 리팩터링해야 하는 비용이 발생한다.

진정한 시니어의 움직임: 급진적 단순함

그리 매력적이지는 않다. “서버리스 함수의 분산 메쉬를 관리했다” 라는 문구를 LinkedIn에 올릴 수는 없겠지만, 금요일까지 기능을 배포하고, 비즈니스는 수익을 내며, 사이드카 프록시가 존재론적 위기를 겪어 3시 AM에 PagerDuty 알림이 울리는 일도 없을 것이다.

복잡성 침식을 막는 방법

• 해결책에 당신이 들어본 적 없는 새로운 라이브러리 세 개가 필요하다면, 아마도 잘못된 것이다.
• 코드는 자산이 아니라 부채라는 점을 기억하라. 최고의 코드는 작성하지 않아도 되는 코드다.
• 사람들에게 어려운 일을 만들게 보상하지 마라. 지능은 얼마나 많은 복잡성을 다룰 수 있느냐가 아니라, 얼마나 많은 복잡성을 없앨 수 있느냐로 보여진다.

행동 촉구

다음에 누군가가 블로그 플랫폼에 마이크로서비스 아키텍처를 제안한다면, 세상을 위해 비즈니스 요구사항과 현실 점검을 건네라.

지금까지 유지보수해야 했던 가장 터무니없이 과잉 엔지니어링된 “솔루션”은 무엇인가요? 댓글에 남겨서 우리 모두가 자신의 기술 부채에 대해 조금이라도 위로받을 수 있게 해 주세요.