2023년 기준, 피해야할 기술 / 솔루션 모음
인사업무와 실무자 기준에서 피해야할 기술 / 커리어 모음
2023년 기준, IT 분야에서 피해야할 기술과 솔루션들을 모아봤다. 일부는 쓰기에따라 괜찮은 기술들도 있지만. 대부분의 경우 실무에서 쓰기에는 좋지 못한 기술이 많다. 그러니 해당기술을 사용하는 프로젝트나 업체들은 유심히 체크하거나, 피하는 것을 권장한다. 또한 본인에게 그런 기술을 배울것을 권하는 업체들이나, 상사에 대해서도 주의하는 것이 좋다. 말 그대로 오래된 기술이거나, 장래에 이용전망이 어두운 기술이 대부분이기 때문이다. 만약 본인이 새로운 회사에 들어가거나, 타 업체와 계약을 맺어야할 경우. 사용중인 브라우저에 wappalyzer 플러그인을 설치하여, 그들의 웹 사이트에 사용된 개발 기술을 확인해보는것을 추천한다.
1. PHP (프론트엔드 / 백엔드)
PHP는 프론트엔드 개발자와 백엔드 개발자가 사용하는 개발언어들 중 하나다. 하지만 한국에서는 PHP 개발자들이 별로 선호받지 못하는데다, 기술력이 낮은 개발회사에서 PHP 기반의 프론트 / 백엔드를 사용하는 경우가 많다. 2023년 현재, 프론트엔드 기술은 React.js나 vue.js 같은 자바스크립트 프레임워크 2세대가 주로 사용되고있다. 백엔드 기술에 있어서는 node.js나 java + spring 기반인 곳이 대부분이다. 정말 특이한 경우가 아니라면 PHP 기반 프론트 / 백엔드 기술을 사용하는 업체나 프로젝트는 거르는게 좋다. 이 기술을 배운다하더라도 미래가 보장되는것도 아닌데다, 해외 기준으로도 별로 선호되지않는 기술이기 때문이다.
- PHP를 사용해서 개발하는 프로젝트는 진행하지도, 들어가지도 말자
- PHP 기반의 백엔드를 사용할 경우, 백엔드 처리 속도가 느려지는 문제가 발생하기 쉽다.
- 한국에서는 PHP를 잘 다루는 개발자를 찾기가 굉장히 어렵고, 구축 후에도 유지보수가 쉽지않다.
2. Jquery (프론트엔드)
Jquery는 프론트엔드 개발자 사용하는 자바스크립트 기반의 프레임워크들 중 하나다. 하지만 이미 국내와 해외 기준에서 2세대 자바스크립트 프레임워크인 React.js 나 Vue.js, Angular.js 등이 널리 퍼지고있다. 이런 기술변화로 인해 단순 HTML / CSS 퍼블리싱 기술조차 잘 쓰이지 않는게 현실이다. 그런 상황에서 1세대 자바스크립트 프레임워크인 Jquery를 사용한다는건, 업체의 기술력을 의심해볼 지점이다. 2023년 기준에서 개발자들에게 Jquery를 배워야한다는건, 과거에 만들어진 서비스를 유지보수시키는 용도 외엔 큰 의미가 없다. 그러니 Jquery를 사용하는 업체나, 신규 프로젝트가 있다면 해당 업체를 유심히 살펴볼 필요가 있다. Jquery는 2세대 프레임워크와는 연동이 되지도 않는다. 게다가 오래된 기술을 우회해서 사용하는 '생명 연장' 기술을 써서 연명하고있는 경우가 많다. 가능하면 이 기술을 신규 프로젝트에 사용하는건 피하도록 하자.
- Jquery는 2세대 자바스크립트 프레임워크가 등장하기 이전, 과거에 주로 사용되었던 기술이다.
- Jquery를 사용하는 개발자들 중에는, Jquery 버전조차 낮은 것을 사용하는 옛날 개발자들이 많다.
- Jquery와 React, Vue, angular 프레임워크는 서로 호환되는 지점이 거의 없다.
3. 워드프레스 기반 커스터마이징 (솔루션)
솔루션 기반 커스터마이징을 할 경우, 새로 개발하는것보다 난이도는 어렵고, 시간은 많이 잡아먹는 문제가 생긴다.당연한 이야기지만 이 기술에 능숙해진다해도 고급 설계와는 관계가 없는 지점이다. 심지어 워드프레스는 PHP 기반으로 만들어진 솔루션이다. 기존에 다른 글에서도 다룬 적이 있지만, 워드프레스는 여러 플러그인이란 개념을 통해 기능을 구현한다. 언뜻 보기에는 사용이 편리해보이지만, 업데이트가 불안정하고, 플러그인끼리 충돌이 일어나는 경우가 많다. 결국 쌩 코딩으로 새로 만드는 방향이 더 나은 경우가 종종 발생한다. 이런 워드프레스 기반 커스터마이징의 가장 큰 문제는 전문가를 찾기도 힘들고, 작업 단가가 높지도 않다는 지점에 있다. 개발사 입장에서는 노력이나 시간은 많이 들어가는데, 정당한 댓가를 받기는 어려운 기술이라는 것. 외부 서비스를 구축하는 업체 기준에서는 '피해야할 기술'이라고 할 수 있다.
- 워드프레스는 PHP 언어 기반의 솔루션이다. PHP가 가지는 단점을 대부분 그대로 가져오게된다.
- 워드프레스는 자체 플러그인들을 사용해 개발해야한다. 다만 플러그인이 서로 충돌하거나, 꼬일 가능성이 많다.
- 워드프레스 기반의 작업은 단가가 낮고, 설게적으로 복잡한 서비스를 만들기에는 적합하지 않다.
4. 쇼핑몰 솔루션 기반 커스터마이징 (솔루션)
솔루션 기반 커스터마이징은 대부분 좋은 결과를 보기가 어렵다. 일단 대부분의 국내 솔루션은 과거 버전의 자바스크립트 프레임워크나, PHP 같은 오래된 기술로 만들어진 경우가 많기 때문이다. 그래서 정규적으로 사용되는 신규 기술을 사용해 기능을 추가하거나, 내용을 변경하기가 쉽지 않다. 결국 솔루션 자체가 갖고있는 기술적 한계 때문에 개발자들이 옛날 기술을 배워야하는 경우가 생긴다. 이런 국내 솔루션 기반의 커스터마이징은 대부분 '개발 단가'를 낮추기위해 클라이언트들이 요구하는 경우가 많은데. 그만큼 좋은 결과물을 만들어내기가 어렵다고 생각하면 된다.설계자 입장에서도 오래된 솔루션을 뜯어서 분해해봐야하고, 개발자들도 그 안에 숨겨진 오래된 코드들을 일일히 연결해 신규 기능을 만들어야한다. 당연히 시간이 걸리는데에 비해 회사나 작업자가 얻어갈 경험치가 거의 없다. 내부서비스를 테스트하는 용도나 MVP 모델의 개발을 해서 시장조사를 하려는게 아닌 이상, 이 방식은 쓰지않는게 더 좋다.
- 쇼핑몰 솔루션들의 내부 기술은 대부분 오래된 jquery나 PHP 같은 기술들을 쓰는 경우가 많다.
- 쇼핑몰 솔루션은 커스터마이징할때 어떤 문제가 생길지 예상하기가 쉽지 않고, 작업 단가도 낮은 편이다.
- 꼭 필요한 지점에서 사용하려는 목적이 아닌 이상, 솔루션 기반 커스텀 작업을 하기보다 새로 만드는 것이 낫다.
5. 단순 데이터 스크래핑 기술 (기타 / 백엔드)
데이터를 스크래핑하는 봇 기술의 경우, 일반적인 구축개발과는 지향하는 방향이 조금 다르다. 개발 기술의 스킬트리에서 보면 주요기술이 아닌, 잔기술에 가깝기 때문이다. 그래서 일반적인 개발자라면 스크래핑에 대한 실험을 해보는 경우는 있어도, 스크래핑 기술 자체를 깊게 연마하는 사람은 많지 않다. 그렇기에 회사에서 데이터 스크래핑 엔진을 만드는 것이 아닌 이상, 이런 기술을 개발자가 배우는건 별로 추천하지않는다. 데이터 스크래핑 개별 작업단가가 낮은데다, 기술적으로 완성도가 높지 않아 지속적으로 유지보수를 해줘야한다. 시간은 많이 드는데, 개발자의 스킬트리에 크게 도움이 되지는 않는다. 물론 특정 서비스나 타 URL에 대한 스크래핑 작업을 통해, 서비스를 운영하는 경우라면 이야기가 다르다. 이 경우는 자체적인 스크래핑 기술을 연마해 지속적인 엔진 업데이트를 해줘야한다.
- 외부 API를 통해 가져올 수 없는 정보가 있다면, 스크래핑 기술이 유일한 해결책인 경우도 있다.
- 스크래핑 기술은 타 사이트나 URL의 구조가 바뀔 경우, 그들의 상황에 맞게 계속 업데이트를 해줘야한다.
- 데이터 스크래핑 기술을 통해 자체적인 서비스를 운영중인 경우가 아니라면, 개발자 입장에서는 시간낭비다.
6. HTML / CSS 퍼블리싱 (프론트엔드)
놀랍게도, 현대의 IT 개발환경에서는 HTML / CSS 퍼블리싱 기술이 거의 사용되지않는다. 대부분의 프론트엔드 작업이 React나 Vue, Angular 같은 자바스크립트 프레임워크 기술로 넘어갔기 때문이다. (Jquery는 제외) 그래서 HTML / CSS를 바탕으로 퍼블리싱 기술을 배운 사람들이 굳이 필요하지 않는 시대가 되었다. HTML / CSS 구조의가장 큰 문제는, 컴포넌트 단위로 개발을 하는 자바스크립트 프레임워크 (React, vue, angular)와 연동될 수 있는 지점이 거의 없기 때문이다. 말 그대로 옛날 기술이다보니, 굳이 쓸 필요가 없는 시대가 왔다고 보면 된다. 이런 이유에서 퍼블리싱 기술은 '속도를 기반으로 여러 작업물을 찍어내는' 방식 이외에는 별 쓸모가 없다. 심지어 React 기반 개발자는 API를 끌어다가 연결해주거나, 자바스크립트 기반의 기능구현이 가능하다. 그러니 일반 퍼블리셔보다 작업범위가 넓고, 연봉도 더 많이 받을 수 밖에 없다.
- HTML / CSS 퍼블리싱은 React와 같은 자바스크립트 프레임워크 개발기술로 대체되고있다.
- HTML / CSS 기술은 신규 기술과 호환되는 부분이 없고, 제한된 작업범위에만 사용될 수 있다.
- 유통기한이 지난 옛 기술이므로, 신규 인원이라면 이 기술을 배우는건 추천하지 않는다.
7. 그누보드 게시판 솔루션 (솔루션)
그누보드는 한국에서만 사용되는 게시판 형태의 솔루션이다. 8~90년대에 사용되었던 게시판 형태에 글을 쓰고, 댓글을 달 수 있는 형식의 게시판을 Jquery 바탕으로 구현해둔 구조다. 그렇다보니 신규 프레임워크와는 맞물리지않거나, 커스터마이징이 필요할때, 여러가지 시행착오를 겪을 수 밖에 없다. 만약 PHP와 함께 그누보드 솔루션이 사용되는 업체거나, 프로젝트라면 눈 딱 감고 거르는게 좋다. 작업단가가 낮은건 물론이고, 타 서비스 구축시 거의 사용되지않는 기술을 억지로 배워야하기 때문이다. 세상에는 여러가지 솔루션들이 있고, 그중에는 가끔 유용한 솔루션이 존재하는 경우도 있다. 하지만 그누보드는 절대 설계나 개발환경에 도움이 되는 솔루션이 아니라는 것만 기억해두자. 작업단가가 낮은건 물론이고, 기술적으로 실력이 부족한 업체들이 주로 사용한다고 보면 된다.
- 그누보드는 오래된 개발언어를 바탕으로 만들어진, 한국형 게시판 솔루션이다.
- 그누보드는 오래된 기술이라 신규 기술이나 프레임워크들과 호환성이 좋지 못한 편이다.
- 게시판조차 직접 구현하지못해, 솔루션을 사용하는 개발회사는 IT 생태계에 머물 필요가 없다고 보면 된다.
8. 메타버스 키워드가 들어간 서비스 (설계 / 기획 / 프론트엔드)
메타버스는 최근 몇년간 가장 쓸모없는 키워드들 중 하나다. 실제로 이 메타버스를 구현할 수 있는 회사는 거의 없다고 보면된다. 심지어 '메타버스' 키워드를 사용하면서 Unity나 Web GL, 3D 모델링에 대한 기술이 없는 곳이라면 더욱더 눈여겨볼 필요가 있다. 실제로 메타버스 컨셉의 서비스들은 3D 모델링을 사용하는 경우가 많다. 또한 웹 기술 기반에서는 3D 오브젝트를 구현하기위해 주로 Web GL 기술을 사용하게된다. 만약 해당 업체가 Web GL에 대한 기술이 충분하지 않다면, 일단 의심을 해볼 필요가 있다. 때로는 Unity 엔진을 바탕으로 앱 서비스를 만들어서, 3D 오브젝트를 사용하려는 경우도 있다. 하지만 이 경우 '엔진 자체의 무게로 인해, 낮은 속도'가 문제가 된다. Unity는 태생부터 앱서비스가 아닌 PC용 게임 개발을 위한 엔진이다. 그렇기에 애초에 모바일 환경에는 적합하지 않다. 에셋이 많아질수록 무게가 무거워지는데다, 최소한의 기능만 써도 원래 로딩속도가 느린 편이다. 그러니 모바일 환경에서는 극도로 경량화된 부분을 이용하거나, 속도향상을 위해 여러 커스터마이징이 필요해진다. 만약 메타버스라는 키워드를 남발하면서, Web GL이나 경량화된 3D 모델링, Unity 엔진 커스터마이징에 대해 잘 알지 못하는 곳이 있다면. 그 즉시 그곳을 떠나는 편이 좋다.
- 메타버스 서비스는 3D 모델링을 구현할 수 있는 기술이 필요한 경우가 많다.
- 3D 렌더링 구현을 위해서는 모바일 환경에서도 적용 가능한 Web GL기술이 대표적으로 사용된다.
- 모바일환경에서 Unity 엔진을 사용할 경우, 엔진의 자체 무게나, 에셋의 양에 따라 속도문제가 생기기쉽다.
- 단, Web GL이나, 3D 실시간 렌더링 기술을 제대로 구현할 수 있는 경우 - 회사의 좋은 경쟁력이 될 수 있다.
9. PPT 기반의 디자인가이드 (설계 / 디자인)
PPT는 대부분의 회사에서 자주 사용되는 도구들 중 하나다. 하지만 회사제안서나 PDF를 만들기 위한 목적이 아닌 경우, 좀 더 고민을 해볼 지점이 생긴다. PPT 기반의 디자인가이드는 약 20년 전부터 계속해서 사용되온 방식이다. 하지만 문서에서 표현해줄 수 있는 영역이 워낙 좁고, 제한이 많아 알아보기가 힘든 경우가 많다. 모바일 화면의 경우 크키가 작으니 적어도 2~3개 정도의 화면이 들어갈 수 있다. 하지만 PC 웹 기준으로는 PPT를 사용하는 것은 결코 효율적인 방식이 아니다. 실제 화면간 이동하는 설명글 (description)을 적기도 쉽지않고, 개별 페이지로 이동하는 URL등을 삽입하는 것도 불가능하기 때문이다. 개별 화면별 컴포넌트를 떼어 설명하기에도, 화면의 크기나 문서의 형식상 효율이 떨어진다. 이런 이유에서 Figma는 훨씬 효율적인 디자인가이드 도구가 되어준다. 넓은 캔버스 위에, 개별 화면간 이동과, 개별 화면간 컴포넌트 구성, 로직 내용까지 한번에 보여줄 수 있기 때문이다. 심지어 특정 컴포넌트에 대한 URL 기반 링크삽입도 가능하기 때문에, 넓은 캔버스가 가지는 탐색의 난이도도 훨씬 줄어들 수 있다. 심지어 Figma는 Web 기반 도구이기때문에 여러 사람이 동시에 접속해 작업하는 것에도 큰 문제가 없다.
- PPT 기반 가이드는 문서 자체의 특성상, 불필요한 규격이 많고, 페이지간 중복지점이 생기게된다.
- PPT 기반 가이드는 PPT 문서규격상 크기가 작아 서비스 FLOW를 확인하기 쉽지않다.
- PPT 기반 가이드는 실무작업보다 문서규격을 작성하는 방법을 배우는데 더 오랜 시간이 걸린다.
- PPT 기반 가이드는 동시에 여러 사람이 작업하기가 쉽지 않고, 화면이 많아질수록 속도도 느려진다.
10. 솔루션 방식 호스팅을 서버DB로 사용하는 경우 (백엔드)
서비스를 운영하는 곳을 기준으로 본다면, 어떤 솔루션이건 필요에 의해 사용할 수 있다. 개발환경에 대한 준비보다, 당장의 서비스와 매출이 더 중요하기 때문이다. 하지만 개발업체 기준에서, 솔루션 형태의 DB를 사용중이라면, 상식이 의심되는 수준의 문제가 된다. 백엔드에 대한 기술이 떨어지거나, AWS 등의 클라우드 서비스 구축 경험이 없는 곳일 수도 있기 때문이다. 게다가 신규 서비스를 제작해야하는 클라이언트가 솔루션 방식 호스팅을 사용하는 경우, 여러가지를 확인해보아야한다. DB환경에 호스팅 솔루션을 사용하는 서비스업체는, DB에 대한 설계나 기반기술에 대한 이해도가 높지 않은 경우가 많다. 그러니 기존의 DB 설계가 과연 '정상적으로 진행이 되었는지' 에 대해 체크가 필요하다. 심지어 AWS 등의 환경을 구축하고 이관처리를 할 때도, 기존 DB 구조가 엉망이라 문제가 발생할 가능성이 높다. 심지어 트래픽 양에 따른 비용지불이나, 유지비에 대한 개념조차 잘 알지못하는 경우도 있다. 그러니 클라이언트가 솔루션 방식 호스팅을 사용하려는경우, 구축 후에도 유지보수 문제가 생길 가능성이 높다.
- 솔루션 방식 호스팅은 트래픽 확장이나, 기능별 세팅의 자유도가 매우 떨어지는 편이다.
- 솔루션 방식 호스팅을 서버DB로 사용한다는건, 그 업체의 백엔드 지식수준이 매우 낮다는것을 의미한다.
- 솔루션 방식 호스팅에 심어진 DB를 AWS 등으로 이관시킬 경우, 이관과정에서 문제가 생길 가능성이 높다.
외부 서비스를 제작해야하는 경우, 프로젝트를 들어가기 이전부터 기술검토가 꼭 필요하다. 이 경우 기존 서비스에대한 조사나, 타 서비스에 대한 조사 과정에서 기술스택에 대해 조사하는 과정도 포함되어야한다. 만약 이런 지점을 고려하지않고 설계, 개발을 진행할 경우 - 예상하지 못한 문제가 계속해서 터질 수 있다는걸 기억해두자.
https://brunch.co.kr/@clay1987/302
