‘NewDev’의 Tech 편향: 새로움이 효율성을 흐릴 때
Source: Dev.to
왜 15년 차 개발자 생활을 마친 뒤 PHP 플레인과 PostgreSQL로 기업 시스템을 구축하기로 선택했는가
6개월 전, 주니어 개발자가 나에게 물었다: “왜 React와 마이크로서비스를 안 쓰나요? 스택이 2010년 느낌이에요.” 그 질문에 나는 미소를 지으며 생각에 잠겼다. 나는 15년 동안 기업 시스템을 구축해 왔고, 기술이 등장하고 사라지는 모습을 보았다. 한 가지 교훈은 변하지 않는다: 기업용 소프트웨어는 기술 트렌드보다 오래 살아남아야 한다.
새로움에 대한 편향
요즘 팀들이 “프레임워크 새 버전이 나왔으니” 라는 이유만으로 안정적인 시스템을 다시 작성하는 모습을 본다. 한 사례로는 ERP를 AngularJS에서 Angular 15로 마이그레이션했는데, 새 기능은 제로였고 6개월이 걸렸다. 비즈니스는 같은 기능을 최신 의존성으로 유지하기 위해 20만 달러를 지불했다.
현실:
- PostgreSQL은 25년째 운영 중이다.
- PHP는 28년째 운영 중이다.
정말 작동하는 것을 바꿔야 할까?
과도한 아키텍처의 숨은 비용
다음과 같은 구조를 가진 시스템을 본다:
API Gateway → Auth Service → Business Logic → Database- 일일 100명 사용자에 마이크로서비스 15개.
- 기본 엔터티 3개에 GraphQL.
각 레이어는 지연, 장애 지점, 인지적 복잡성을 더한다. 고객 CRUD에 이렇게 복잡한 아키텍처가 정말 필요할까?
이력서 트렌드
지난 주에 이력서를 검토했다. 80 %가 React, Node.js, Docker를 언급했지만, “유지보수성”이나 “장기 안정성”에 대한 언급은 없었다. 압박은 이해하지만, 개발이 최신 기술을 수집하는 레이스가 되어서는 안 된다.
실제 사례
- 회계 시스템 (2015): PHP + PostgreSQL으로 구축했으며, 현재 4개의 팀이 유지 보수하고 있다. 핵심은 외부 의존성이 전혀 없고, 업데이트할
package.json이나 깨질composer.lock이 없다는 점이다. - Vue 2 → Vue 3 마이그레이션: 3개월 뒤에도 프로덕션 버그가 지속되었다. 비용: 개발 인력 50만 달러 + 불안정성으로 인한 고객 손실.
- Kubernetes 스타트업: 50명의 동시 사용자에게 서비스 메시와 서킷 브레이커를 적용했다. 시스템이 너무 복잡해 2명의 개발자만 이해했으며, 두 사람 모두 퇴사했다.
기업 소프트웨어 원칙
기업용 소프트웨어는 10 년 이상 지속되어야 한다. 이를 위해서는:
- 실험적이지 않은 성숙한 기술 사용.
- 최소(또는 전혀 없는) 의존성.
- 코드뿐 아니라 아키텍처 문서화.
- 레이어가 적을수록 장애 지점이 적다.
규칙: “비즈니스에 가치를 더하지 않으면 시스템에 포함시키지 않는다”.
권장 스택
- PHP 8.4 + PostgreSQL: 수십 년간 검증된 안정성.
- 직접 SQL: 최대 성능, 최소 오버헤드.
- 모듈당 Vanilla JavaScript: npm 의존성 제로.
신중한 선택의 결과
1년 전, 새로운 세무 시스템에서 React, TypeScript, GraphQL을 배제하기로 결정했다. 결과는 다음과 같다:
- 응답 시간 지속적으로 < 100 ms.
- 유지보수 비용 60 % 감소.
- 어느 개발자든 2일 안에 코드를 이해할 수 있음.
결정이 인기가 있었을까? 아니었다. 하지만 작동은 완벽했다.
기술 선택을 위한 질문
- 이것이 비즈니스를 위한가, 아니면 내 이력서를 위한가?
- 10년 동안 유지될 수 있는가?
- 주요 유지보수 담당자가 떠나면 어떻게 되는가?
소프트웨어 개발은 기술 패션쇼가 아니라, 비즈니스가 오래 운영될 수 있도록 기반을 다지는 일이다. 비록 그 기반이 “지루하다” 하더라도.
결론
10년 동안 버틸 수 있는 시스템을 원하나요, 아니면 트위터에서 보이는 최신 모습에 더 끌리나요?
댓글에 여러분의 경험과 의견을 공유해 주세요.
#opinion