[etc] - WebFrontEnd - 관련 불편한 관점의 해석 ~

https://yozm.wishket.com/magazine/detail/2287/?fbclid=IwAR0N1x_R9qSbrov1zpwv5ae0SYeZkETyISs632rG-yo5c-LtCiwDjOkDAag

유튜버 '수코딩'이 정리한 프론트엔드의 등장 배경 | 요즘IT

 

 

위 글에 대한..개인적인 견해~ 이러한 관점도 있을 수 있다 ~

개인적으로 필자도 FLASH 를 좋아하지는 않았다~

더욱이 필자는 백엔드 역할에 더 가깝다.
뭐 필자가 입문하던 시기에는 프론트 / 백 영역 구분이 없던 시절이었다~

재미난건 지금도 백오피스( 관리자 페이지 ) 부분은 프론트 없이 구성하는 서비스 들이 많다.

그리고 백 오피스의 트래픽은 정말 적을까..?
업무용이다 즉 업무시간동안 서비스 운영사 직원들이 줄기차게 접속한다.
과연 트래픽이 적을까...?

 

 

1. FLASH 의 몰락

- 최소한 대한민국에서 FLASH 의 몰락은     그냥 구글 애플의 지원 중단이 강제로 결정한 것이라 판단하는 편이     현실에 부합하지 않을까 하는 개인적인 생각     대한민국에서 나머지 요소들은...그닥..

2. FLASH 의 취약한보안...?

- 케이스 바이 케이스 일듯...컨텐츠 개발 과정에서 얼마나 보안에 대한 고려를 했느냐 하는 부분이 더 중요할듯..     어도비 플래시 플레이어 설치로 브라우져의 기능을 확장 그에 따라 더 많은 사용자 디바이스 자원에 접근이 가능해짐     -> 분명 보안상 좋지 않은 부분임 출입구가 커지만 방어하기 불편한 것은 당연함.  - 그렇다면 동일한 조건 - 공동인증서 - 관련 정책이     FLASH 보다 더 극단적으로 보안상 악영향이 크다 생각됨     공동인증서의 인증 방식 공개키 개인키 를 이용한 방식은 매우 강력한 보안성을 가지고 있다.     그런데.. 사용 방식이 문제이다.     취약한 보안의 대명사 Active X 설치 또는 별도 플러그인 설치를 강제하여     원격지에서 사용자 디바이스의 저장 매체를 뒤져서 인증서 파일을 찾는다.     원격지에서 개인 사용자의 저장 매체를 뒤지는 행위가 보안상 좋은가...?     이 행위 역시 브라우져 이외이 플러그인을 통한 디바이스 접근행위 이다...!!!     더욱 큰 부작용 대부분의 사용자 ( 국민 ) 들을 플러그인 강제 설치에 길들여 놓은 점.     따라서 경고창들 읽지도 않고     동의만 누르며 넘어가도록 국민들의 보안 의식을 박살내 놓은 부분은 보안상...거참...

  

3. FLASH 성능저하

이 부분은 케이스 바이 케이스 동일한 화질 음질 의 컨텐츠의 출력을 위해서 사용하는 컴퓨팅 자원의 크기의 문제 아닌가..? FLASH 컨텐츠가 동일 음질 화질 대비해서 컴퓨팅 자원의 소모가 비정상적으로 무거웠을까..?

3. FLASH 웹 접근성 문제

- 접근성의 문제 이건 웹 접근성 장비 기술 부족의 문제일 수 있음.     만약 FLASH 컨텐츠 자체서 음석을 제공하면 오히려 더 좋은 접근성을 가질 수도 있음.  - 접근성관련 법규에 의하여 강제적인 규제를 받는 규모의 서비스 자체가 많지 않음.     아울러 웹 접근성 장비의 규격에 맞는 형태의 대체 텍스트를 제공하면 법규상 문제가 없을듯...

4. 검색엔진들의 색인 생성의 어려움

- FLASH 컨텐츠 색인생성의 어려움 즉 검색엔진에서 읽어가기 어려운 부분이 존재함.     따라서 검색 엔진을 통한 마케팅에 불리한 요소는 존재함.  - 뭐 반대로 대체 텍스트를 잘 제공하면     이것도 케이스바이 케이스가 되지 않을까 하는 생각이..

5. 프론트 분리로 얻을 수 있는 장점..?

대한민국 외주용역업체( SI ) 관점  - 기존 프로젝트 인력구성 대비 인력 투입 분야의 증가를 명분으로 수주 견적 금액을 더 크게 산출하는데 유리함.  - 대부분의 발주처의 담당자들은 기술에 대한 학습이 부족한 상태     따라서 생소한 단어 하나 들어가면 뭔가 다른 경쟁사 보다 차별화 한거 처럼 보임.     즉 경쟁사 대비 수주의 유리함으로 작용하는 요소가 될 수 있음.

 

개발과정에서 발생할 수 있는 프론트 영역 분리의 장점  - 하나의 API( 백엔드 산출물 ) 를 이용하여     다양한 환경의 클라이언트 ( Web, AOS, IOS, Window, Linux etc. ) 에서 활용이 가능하다는 부분     예를 들어     각 환경마다 어플리케이션 전체를 개발할 경우     DB -> 서비스 환경단위 어플리케이션 의 구성을 가지게 된다.     즉 다양한 클라이언트 환경 마다 전체 프로젝트를 개발해야 한다.     DB -> API( 백엔드 산출물 ) -> 프론트  구성의 경우     API( 백엔드 산출물 )가 DB 와 프론트 사이의 미들웨어 역할을 하게 되어     클라이언트 환경과 무관하게  백엔드 개발 부담의 감소라는 부분이 장점으로 판단될 수 있다.     단 ) 역으로 API 의 문제는 연결된 모든 프론트 영역에 대한 장애로 이어질 수 있다.